diff --git a/.dockerignore b/.dockerignore deleted file mode 100755 index 27d2dae2b493..000000000000 --- a/.dockerignore +++ /dev/null @@ -1,2 +0,0 @@ -*/node_modules -*.log diff --git a/.github/workflows/deploy-kusama-prod.yml b/.github/workflows/deploy-kusama-prod.yml index 53a0227fa8f3..29f2673369c6 100644 --- a/.github/workflows/deploy-kusama-prod.yml +++ b/.github/workflows/deploy-kusama-prod.yml @@ -21,11 +21,11 @@ jobs: git config --global user.name "Polkadot Wiki CI" echo "machine github.com login w3fdeploy password ${{ secrets.ACCESS_KEY }}" > ~/.netrc yarn && yarn kusama:build && GIT_USER=w3fdeploy PUBLISHING=true PROJECT_NAME=kusama-guide-hosting yarn run kusama:publish-gh-pages - + # setup ipfs cluster tools wget https://dist.ipfs.io/ipfs-cluster-ctl/v0.14.0/ipfs-cluster-ctl_v0.14.0_linux-amd64.tar.gz tar xf ./ipfs-cluster-ctl_v0.14.0_linux-amd64.tar.gz chmod +x ./ipfs-cluster-ctl/ipfs-cluster-ctl export PATH=$PATH:`pwd`/ipfs-cluster-ctl - node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER}}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD}} --websiteDir ./kusama-guide-v2/build --pinName kusama-guide \ No newline at end of file + node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER}}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD}} --websiteDir ./kusama-guide/build --pinName kusama-guide diff --git a/.github/workflows/deploy-kusama-staging.yml b/.github/workflows/deploy-kusama-staging.yml index 786f99b59c6e..43ea91817d28 100644 --- a/.github/workflows/deploy-kusama-staging.yml +++ b/.github/workflows/deploy-kusama-staging.yml @@ -51,9 +51,9 @@ jobs: git config --global user.email "polkadot-wiki-deploy@users.noreply.github.com" git config --global user.name "Polkadot Wiki CI" echo "machine github.com login w3fdeploy password ${{ secrets.ACCESS_KEY }}" > ~/.netrc - - yarn && yarn kusama:build && echo "staging.kusama.network" > kusama-guide-v2/static/CNAME && GIT_USER=w3fdeploy PUBLISHING=true PROJECT_NAME=kusama-guide-staging yarn run kusama:publish-gh-pages - + + yarn && yarn kusama:build && echo "staging.kusama.network" > kusama-guide/static/CNAME && GIT_USER=w3fdeploy PUBLISHING=true PROJECT_NAME=kusama-guide-staging yarn run kusama:publish-gh-pages + # setup ipfs cluster tools wget https://dist.ipfs.io/ipfs-cluster-ctl/v0.14.0/ipfs-cluster-ctl_v0.14.0_linux-amd64.tar.gz tar xf ./ipfs-cluster-ctl_v0.14.0_linux-amd64.tar.gz @@ -61,4 +61,4 @@ jobs: export PATH=$PATH:`pwd`/ipfs-cluster-ctl which ipfs-cluster-ctl - node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER }}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD }} --websiteDir ./kusama-guide-v2/build --pinName kusama-guide-staging + node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER }}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD }} --websiteDir ./kusama-guide/build --pinName kusama-guide-staging diff --git a/.github/workflows/deploy-polkadot-prod.yml b/.github/workflows/deploy-polkadot-prod.yml index 49bd0cae7d2d..9aa900be3a29 100644 --- a/.github/workflows/deploy-polkadot-prod.yml +++ b/.github/workflows/deploy-polkadot-prod.yml @@ -14,7 +14,7 @@ jobs: - uses: actions/setup-node@v2 with: node-version: "14" - + - name: Publish run: | git config --global user.email "polkadot-wiki-deploy@users.noreply.github.com" @@ -28,4 +28,4 @@ jobs: chmod +x ./ipfs-cluster-ctl/ipfs-cluster-ctl export PATH=$PATH:`pwd`/ipfs-cluster-ctl - node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER}}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD}} --websiteDir ./website-v2/build --pinName polkadot-wiki + node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER}}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD}} --websiteDir ./polkadot-wiki/build --pinName polkadot-wiki diff --git a/.github/workflows/deploy-polkadot-staging.yml b/.github/workflows/deploy-polkadot-staging.yml index dfd0f0108a47..aadb8e62aaa5 100644 --- a/.github/workflows/deploy-polkadot-staging.yml +++ b/.github/workflows/deploy-polkadot-staging.yml @@ -36,7 +36,7 @@ jobs: # uses: actions/upload-artifact@v2 # with: # name: polkadot-wiki - # path: website/static/polkadot-wiki.pdf + # path: polkadot-wiki/static/polkadot-wiki.pdf # - name: Build # run: yarn; yarn polkadot:build @@ -47,7 +47,7 @@ jobs: # id: ipfs_pdf # uses: aquiladev/ipfs-action@v0.1.4 # with: - # path: ./website/static/polkadot-wiki.pdf + # path: ./polkadot-wiki/static/polkadot-wiki.pdf # timeout: 120000 # - name: Inject @@ -58,7 +58,7 @@ jobs: # - name: Upload to IPFS # uses: aquiladev/ipfs-action@v0.1.4 # with: - # path: ./website/build/polkadot-wiki + # path: ./polkadot-wiki/build/polkadot-wiki # timeout: 120000 - name: Publish @@ -66,7 +66,7 @@ jobs: git config --global user.email "polkadot-wiki-deploy@users.noreply.github.com" git config --global user.name "Polkadot Wiki CI" echo "machine github.com login w3fdeploy password ${{ secrets.ACCESS_KEY }}" > ~/.netrc - yarn && yarn polkadot:build && echo "staging.polkadot.network" > website-v2/static/CNAME && GIT_USER=w3fdeploy PUBLISHING=true PROJECT_NAME=polkadot-wiki-staging yarn run polkadot:publish-gh-pages + yarn && yarn polkadot:build && echo "staging.polkadot.network" > polkadot-wiki/static/CNAME && GIT_USER=w3fdeploy PUBLISHING=true PROJECT_NAME=polkadot-wiki-staging yarn run polkadot:publish-gh-pages # setup ipfs cluster tools wget https://dist.ipfs.io/ipfs-cluster-ctl/v0.14.0/ipfs-cluster-ctl_v0.14.0_linux-amd64.tar.gz @@ -74,4 +74,12 @@ jobs: chmod +x ./ipfs-cluster-ctl/ipfs-cluster-ctl export PATH=$PATH:`pwd`/ipfs-cluster-ctl +<<<<<<< HEAD + node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER}}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD}} --websiteDir ./polkadot-wiki/build --pinName polkadot-wiki-staging +======= +<<<<<<< HEAD + node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER}}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD}} --websiteDir ./website/build --pinName polkadot-wiki-staging +======= node ./scripts/ipfs-cluster-pin.js --auth ${{ secrets.CLUSTER_BASIC_AUTH_USER}}:${{ secrets.CLUSTER_BASIC_AUTH_PASSWORD}} --websiteDir ./website-v2/build --pinName polkadot-wiki-staging +>>>>>>> master +>>>>>>> folder diff --git a/.github/workflows/generate-pdf.yml b/.github/workflows/generate-pdf.yml index f3ffea034c22..5bd18c947f3c 100644 --- a/.github/workflows/generate-pdf.yml +++ b/.github/workflows/generate-pdf.yml @@ -1,34 +1,35 @@ -name: Generate downloadable PDF - -on: - # Trigger the workflow on push or pull request, - # but only for the master branch - push: - branches: - - master - pull_request: - branches: - - master - -jobs: - generate-pdf: - name: Run the site and generate a PDF from it - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@master - - - name: Clone and run the site - run: | - yarn - yarn polkadot:start & - while ! nc -z localhost 3000; do - sleep 1 - echo waiting for website up... - done - yarn polkadot:pdf - - - name: Upload PDF - uses: actions/upload-artifact@v2 - with: - name: polkadot-wiki - path: website-v2/static/polkadot-wiki.pdf +name: Generate downloadable PDF + +on: + # Trigger the workflow on push or pull request, + # but only for the master branch + push: + branches: + - master + pull_request: + branches: + - master + +jobs: + generate-pdf: + name: Run the site and generate a PDF from it + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@master + + - name: Clone and run the site + run: | + yarn + yarn mirror + yarn polkadot:start & + while ! nc -z localhost 3000; do + sleep 1 + echo waiting for website up... + done + yarn polkadot:pdf + + - name: Upload PDF + uses: actions/upload-artifact@v2 + with: + name: polkadot-wiki + path: website/static/polkadot-wiki.pdf diff --git a/.gitignore b/.gitignore index 039a9e180a0b..9f2004973b2f 100644 --- a/.gitignore +++ b/.gitignore @@ -36,7 +36,7 @@ bower_components build/Release # Dependency directories -node_modules/ +node_modules/* jspm_packages/ # TypeScript v1 declaration files @@ -66,20 +66,21 @@ typings/ # Emacs backup files *~ -build +polkadot-wiki/build +kusama-guide/build build-script* **/mirror*.md .DS_Store kusama-guide/translated_docs/ -website/translated-docs/ -website/i18n/* +polkadot-wiki/translated-docs/ +polkadot-wiki/i18n/* kusama-guide/i18n/* .docusaurus computed-dict.json -website-v2/i18n/ -!website-v2/i18n/en/ -kusama-guide-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current/ +polkadot-wiki/i18n/ +!polkadot-wiki/i18n/en/ +kusama-guide/i18n/zh-CN/docusaurus-plugin-content-docs/current/ # Ignore because we don't need a 10MB file in VCS polkadot-wiki.pdf diff --git a/Dockerfile b/Dockerfile deleted file mode 100755 index d369844d5bdf..000000000000 --- a/Dockerfile +++ /dev/null @@ -1,10 +0,0 @@ -FROM node:8.11.4 - -WORKDIR /app/website - -EXPOSE 3000 35729 -COPY ./docs /app/docs -COPY ./website /app/website -RUN yarn install - -CMD ["yarn", "start"] diff --git a/README.md b/README.md index 0dbf95e22221..09d1574b814b 100644 --- a/README.md +++ b/README.md @@ -19,13 +19,12 @@ ## Contributing to Documentation -The Wiki is an open source project and we will review all issues and pull-requests created in this -repository. If you notice typos or grammatical errors, please feel free to directly create pull -requests with these corrections. +The Wiki is an open source project and we will review all issues and pull-requests created +in this repository. If you notice typos or grammatical errors, please feel free to directly create pull requests with +these corrections. -Larger contributions may start as issues to test the waters on the subject with the maintainers. It -is generally preferable to create a pull request over an issue to propose a change to the wiki -content. +Larger contributions may start as issues to test the waters on the subject with the maintainers. +It is generally preferable to create a pull request over an issue to propose a change to the wiki content. ### Running Locally @@ -33,8 +32,8 @@ Both the Polkadot Wiki and the Kusama Guide are built from the source files in t After cloning the source locally, you can start the websites with each of these respective commands (ensure you run `yarn` at the root of the repository first to install dependencies): -> The site is built using Docusaurus: you may need to install Docusaurus before running the Wiki -> locally. Using yarn, run `yarn upgrade @docusaurus/core@latest @docusaurus/preset-classic@latest`. +> The site is built using Docusaurus: you may need to install Docusaurus before running +> the Wiki locally. Using yarn, run `yarn upgrade @docusaurus/core@latest @docusaurus/preset-classic@latest`. ```zsh # For the Polkadot Wiki: @@ -60,12 +59,11 @@ Use the style guide from the #### Formatting -Use -[pretty-quick](https://prettier.io/docs/en/precommit.html#option-2-pretty-quickhttpsgithubcomazzpretty-quick) +Use [pretty-quick](https://prettier.io/docs/en/precommit.html#option-2-pretty-quickhttpsgithubcomazzpretty-quick) as a pre-commit formatting tool. -There is an automatic `pretty-quick` check that occurs pre-commit to format your changed/staged -files. +There is an automatic `pretty-quick` check that occurs pre-commit to format +your changed/staged files. To format markdown pages, run the following in the `docs` folder: @@ -77,17 +75,17 @@ To run pretty on the whole project, `npx pretty-quick`. ### Static Site Generator -The Wiki's latest version uses the [Docusaurus](https://docusaurus.io/) static website generator to -convert the Markdown docs into a documentation website. +The Wiki's latest version uses the [Docusaurus](https://docusaurus.io/) static website +generator to convert the Markdown docs into a documentation website. ### Search Engine -[Algolia DocSearch](https://docsearch.algolia.com/) is the search engine that is used, which is -built into Docusaurus. Indexing via Algolia provides faster lookup; the actual configuration for -lookup is located in another repository that's maintained by Algolia DocSearch. +[Algolia DocSearch](https://docsearch.algolia.com/) is the search engine that is used, which +is built into Docusaurus. Indexing via Algolia provides faster lookup; the actual configuration +for lookup is located in another repository that's maintained by Algolia DocSearch. -We have enabled searching on the Wiki by declaring the `algolia` section in the `siteConfig.js` file -in `scripts`, and defining an API key and index name that are provided by DocSearch. +We have enabled searching on the Wiki by declaring the `algolia` section in the `siteConfig.js` +file in `scripts`, and defining an API key and index name that are provided by DocSearch. ```js algolia: { @@ -100,13 +98,14 @@ in `scripts`, and defining an API key and index name that are provided by DocSea ``` If you would like to access and modify this, you can re-submit the documentation url via -[DocSearch Program](https://docsearch.algolia.com/apply/), where they will send a JavaScript snippet -that you can re-integrate into the configuration, similar to the one shown above. +[DocSearch Program](https://docsearch.algolia.com/apply/), where they will send +a JavaScript snippet that you can re-integrate into the configuration, similar to the +one shown above. ### Automated Deployments -The Polkadot wiki is built on the `gh-pages` branch and automatically deployed to GitHub Pages. The -Kusama wiki is also deployed to GitHub Pages (via a separate repository). +The Polkadot wiki is built on the `gh-pages` branch and automatically deployed to GitHub Pages. +The Kusama wiki is also deployed to GitHub Pages (via a separate repository). ### Mirror Pages @@ -144,8 +143,9 @@ burned. :kusama }} ``` To test the resolution, run `polkadot:build` and `kusama:build`, then `polkadot:inject` and -`kusama:inject`, respectively. Inspect the built files in the corresponding `build` folder under -`website` or `kusama-guide`. +`kusama:inject`, respectively. +Inspect the built files in the corresponding `build` folder under `website` or +`kusama-guide`. ## Internationalization diff --git a/crowdin.yaml b/crowdin.yaml index 7ac0e458bbbd..13cb96734314 100755 --- a/crowdin.yaml +++ b/crowdin.yaml @@ -4,11 +4,9 @@ base_path: "./" preserve_hierarchy: true files: - - - source: '/website-v2/i18n/en/**/*.json' - translation: '/website-v2/i18n/%locale%/**/%original_file_name%' + - source: "/polkadot-wiki/i18n/en/**/*.json" + translation: "/polkadot-wiki/i18n/%locale%/**/%original_file_name%" content_segmentation: 0 - - - source: '/docs/*.md' - translation: '/website-v2/i18n/%locale%/docusaurus-plugin-content-docs/current/%original_file_name%' + - source: "/docs/*.md" + translation: "/polkadot-wiki/i18n/%locale%/docusaurus-plugin-content-docs/current/%original_file_name%" content_segmentation: 0 diff --git a/docker-compose.yml b/docker-compose.yml deleted file mode 100755 index 6711192ae1e7..000000000000 --- a/docker-compose.yml +++ /dev/null @@ -1,18 +0,0 @@ -version: "3" - -services: - docusaurus: - build: . - ports: - - 3000:3000 - - 35729:35729 - volumes: - - ./docs:/app/docs - - ./website/blog:/app/website/blog - - ./website/core:/app/website/core - - ./website/i18n:/app/website/i18n - - ./website/pages:/app/website/pages - - ./website/static:/app/website/static - - ./website/sidebars.json:/app/website/sidebars.json - - ./website/siteConfig.js:/app/website/siteConfig.js - working_dir: /app/website diff --git a/docs/build-build-with-polkadot.md b/docs/build-build-with-polkadot.md deleted file mode 100644 index ff8e8159b893..000000000000 --- a/docs/build-build-with-polkadot.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: build-build-with-polkadot -title: Polkadot Builders Starter's Guide -sidebar_label: Polkadot Builders Starter's Guide ---- - -_This article is the maintained version of the blog post: -[Everything you Need to Know to Prepare for Polkadot](https://medium.com/polkadot-network/everything-you-need-to-know-to-prepare-for-polkadot-32d08b929735)._ - -Polkadot is a blockchain protocol with two goals: providing **shared security** among all connected -parachains and allowing all connected chains to **interoperate** by using -[XCMP](learn-crosschain.md). With the advent of [PDKs](build-pdk.md) like Parity Substrate and -Cumulus, the time it takes to develop and launch a new chain has dropped significantly. While before -it would take years to launch a new chain, now it may only take weeks or even days. - -This guide will walk you through the steps you can take today to get started building your vision -with Polkadot. It will explain the difference between a parachain and a smart contract (and why one -may be better suited for your application over the other). - -## Polkadot Ecosystem Networks - -- Mainnet: **Polkadot** -- Canary network: **Kusama** - - [Kusama](https://kusama.network/) is a value-bearing canary network that gets features before - Polkadot does... _expect chaos_... -- Official testnets: - - **Westend** - Functionality equal to the current Polkadot mainnet, with possible next-generation - testing of features from time to time that will eventually migrate onto Polkadot. Perma-testnet (is not reset back to genesis block). - - **Canvas** - Wasm based Smart Contract enabled testnet, primarily for `ink!` development. - - **Rococo** - Parachains and XCM testnet. Occasionally reset (started over again with a new genesis block). - -Polkadot mainnet has been running since May 2020 and has -[implementations in various programming languages](learn-implementations.md) ranging from Rust to -JavaScript. Currently, the leading implementation is built in Rust and built using the Substrate -framework. - -Tooling is rapidly evolving to interact with the network; there are so many ways to get started! - -But before you jump head-first into the code, you should consider the _kind_ of decentralized -application you want to make and understand the different paradigms available to developers who want -to build on Polkadot. - -## What is the difference between building a parachain, a parathread, or a smart contract? - -Polkadot provides several ways for you to deploy your application: as a smart contract on an existing -parachain, as your own parachain, or as a parathread. There are trade-offs when working with each of -these and reading this section will help you understand them. - -### Parachains & Parathreads - -Parachains are "parallel" chains containing their own runtime logic and benefit from the shared -security and the cross-chain messaging provided by the Polkadot Relay Chain. Parachains permit a -high degree of flexibility and customization but require more effort to create and maintain over -time. - -Parathreads are like parachains and enable the developer to have lower-level control of the logic of -their application. The main difference between the two is economic since parathreads will be much -less expensive to secure than a parachain. The lower costs of parathreads are due to the fact that -parathreads will only produce a block when they need to, unlike parachains, which have secured a -slot to produce a block at every block of the Relay Chain. When building a parathread, you will use -the same tools (like PDKs) and you get all of the benefits of building a parachain, without the -drawback of the cost. - -Parachains grant the creators more space to build the monetary system and other aspects of the chain -from the ground up. They will allow for more succinct and efficient execution of complex logic than -could ever be offered by a smart contract platform. Parachains also offer more flexibility in the -form of governance and can perform complete upgrades in a less controversial way than the current -process of hard-forks. - -Some examples of features you can have on a parachain or parathread: - -- Custom fee structure (for example, pay a flat fee for transactions or pay per byte). -- Custom monetary policy for the native token and local economy. -- Treasury to be funded through transitions in your state function. -- A governance mechanism that could manage a DAO that is responsible for allocating your on-chain - treasury. - -![build 1](./assets/build-1.png) - -Parachains open possibilities to construct complex runtime logic that would be too expensive to -execute with smart contracts. However, unlike smart contracts, parachains lack a mandatory gas -metering system entirely and could potentially be vulnerable to bugs that cause infinite loops -(something that is prevented by design in smart contracts). This vulnerability is mitigated by the -weight system that is implemented in Substrate -- although it places more of a burden on the -developer of the parachain to properly perform benchmarks. - -You may also decide to harness a combination of parachain, parathread, and smart contract. If you -have certain logic that requires loops and it cannot be removed, use the native parachain runtime to -handle all complex logic and the smart contract to call iteration. If you require off-chain data -from an oracle, you may want to use a parathread as an oracle feed that only triggers once every 24 -hours (this makes the most sense if the data is useful to other players in the Polkadot ecosystem -too). - -Most likely you’ve already realized that your application is better suited to be one or the other -(or a hybrid of them both), but if you need a quick recap to digest the information, you can use -this comparison chart as a cheat sheet: - -![build 2](./assets/build-2.png) - -> **Note:** The image above does not include parathreads, but as we mentioned before all the -> benefits of parachains apply just as well to parathreads. Parathreads, however, _are_ cheaper to -> deploy and maintain. So if they had a column on the table above, it would look like the parachain -> column with "Ease of deployment" and "Maintenance overhead" changed to `+`. - -### Smart Contracts - -A smart contract is simply some code that exists at an address on a chain and is callable by -external actors. The key part is that you actually have to put the code on chain before anyone can -start executing it! - -Deploying your smart contract on chain will vary slightly for whichever specific parachain you will -use, but generally you will send a special transaction that will create the smart contract on the -ledger. You will likely need to pay an associated fee for the initialization logic and any storage -that your contract consumes. - -On the Polkadot mainnet, there will be parachains that act as smart contract platforms. Smart -contracts are executable programs that exist on only a single chain and are limited in complexity. -Because they exist on a single chain, they can have smooth interoperability with other smart -contracts on the same chain. However, they will always be constrained and limited by the inherent -characteristics of their host chain. - -If there is a need to have a large amount of control over the design and features of your -application, a parachain is a better choice. Keep in mind, smart contracts can be used as a testing -ground before later being turned into full-fledged parachains. Smart contract platforms will usually -have convenient tooling like IDEs to facilitate quick iterations. A smart contract MVP could be -created to gauge user interest before putting in the work to build out a parachain. - -Each platform will have a different way of paying for and maintaining the state of your smart -contract. The different patterns you may see for paying for your smart contract include: - -- A transaction fee associated with deploying each transaction. -- A subscription model in which you pay some chain entity routinely for the usage of the platform. -- An access token model for which you need to hold a threshold of native tokens to use the platform - (EOS has something similar). Storage rent. -- Free trial or developer promotion. -- Most smart contract platforms use some form of gas to limit the number of operations a user can - perform. Users will be required to pay for the gas upfront and will be refunded for what they - don’t use. - -You will need to consider the storage and complexity of your smart contract to ensure that gas usage -stays within reasonable bounds. Storage will likely be expensive for whichever smart contract -platform you use, so it is necessary to keep as much data off-chain as possible. You may consider -using [IPFS](https://ipfs.io/) or [Storj](https://storj.io/) to keep the data and submitting only -the content address on chain. - ---- - -This guide now splits into two sections depending on whether you’ve decided on a smart contract or a -parachain to build your application. Feel free to read both sections or just the one that is -applicable to you. - -- [I want to build a parachain or parathread!](#so-you-want-to-build-a-parachain-or-parathread) -- [I want to build a smart contract!](#so-you-want-to-build-a-smart-contract) - -## So you want to build a parachain or parathread... - -Now that you have determined that building a parachain or parathread is the right approach for your -new project, the next step is to decide which framework to use. Frameworks for building a parachain -or parathread are known as parachain development kits ([PDK](build-pdk.md)s). Currently, the only -PDK available is Substrate and Cumulus from Parity Technologies. - -In the future, there will be many different PDKs available in different programming languages, just -like there are multiple [implementations of the Polkadot Host](learn-implementations.md). - -> **Call to Action:** Do you want to build a Parachain Development Kit from scratch? The Web3 -> Foundation is giving grants to teams who are doing this, learn more and apply on the -> [W3F grants page](https://grants.web3.foundation). - -### Get started with Substrate - -Substrate is the underlying framework on which Polkadot itself is built. It is a toolset for -blockchain innovators that provides the necessary building blocks for constructing a chain. It -includes a library of modular runtime plug-ins from which you can compose your chain logic. - -The best way to get started with Substrate is to explore the -[Substrate Developer Hub](https://substrate.dev/docs/en/), an online resource built and maintained -by [Parity Technologies](https://parity.io). - -### How to set up your parachain - -After creating your chain runtime logic with Substrate, you will be able to compile it down to a -Wasm executable. This Wasm code blob will contain the entire state transition function of your -chain, and is what you will need to deploy your project to Polkadot as either a parachain or -parathread. - -Validators on Polkadot will use the submitted Wasm code to validate the state transitions of your -chain or thread, but doing this requires some additional infrastructure. A validator needs some way -to stay up to date with the most recent state transitions, since Polkadot nodes will not be required -to also be nodes of your chain. - -This is where the collator node comes into play. A collator is a maintainer of your parachain and -performs the critical action of producing new block candidates for your chain and passing them to -Polkadot validators for inclusion in the Polkadot relay chain. - -Substrate comes with its own networking layer built-in but unfortunately only supports solo chains -(that is, chains that do not connect to the relay chain). However, there is the Cumulus extension -that includes a collator node and allows for your Substrate-built logic to be compatible with -Polkadot as either a parachain or parathread. - -#### Cumulus - -The goal of [Cumulus](build-cumulus.md) is to be an extension of Substrate that will make any -Substrate runtime compatible with Polkadot. - -It handles the network compatibility overhead that any parachain would need to implement to be -connected to Polkadot. This includes: - -- Cross-chain message passing (XCMP). -- Out-of-the-box Collator node setup. -- An embedded full client of the Relay Chain. -- Polkadot block authorship compatibility. - -Integrating Cumulus with your Substrate chain will port it into a parachain capable of working on -Polkadot with minimal modification, possibly as little work as importing a crate and adding a few -lines! - -### How to deploy your parachain or parathread in Polkadot - -#### Parachain - -In order to include your parachain into the Polkadot network, you will need to acquire a parachain -slot. - -Parachain slots will be sold in open auctions, the mechanics of which can be found on the -{{ polkadot: [parachain auction](learn-auction.md) :polkadot }} -{{ kusama: [parachain auction](mirror-learn-auction.md) :kusama }} page of the wiki. - -#### Parathread - -Parathreads will not require a parachain slot, so you will not need to engage in the candle auction -mechanism. Instead, you will be able to register your parathread code to the relay chain for a fee -and from then be able to start participating in the per-block auctions for inclusion of your state -transition into the relay chain. - -For more information on how parathread per-block auctions work, see the more detailed -{{ polkadot: [parathread](learn-parathreads.md) :polkadot }} -{{ kusama: [parathread](mirror-learn-parathreads.md) :kusama }} page. - -## So you want to build a smart contract... - -The Polkadot relay chain itself will not support smart contracts. However, since the parachains that -connect to Polkadot can support arbitrary state transitions, they can support smart contracts. - -Substrate presently supports smart contracts out-of-the-box in two ways: - -- The EVM pallet offered by [Frontier][]. -- The [Contracts pallet][substrate contracts] in the FRAME library for Wasm based contracts. - -### Frontier EVM Contracts - -[Frontier][] is the suite of tools that enables a Substrate chain to run Ethereum contacts (EVM) -natively with the same API/RPC interface Ethereum exposes on Substrate. Ethereum Addresses can also -be mapped directly to and from Substrate's SS58 sceme from existing accounts. - -### Contracts Pallet - -The experience of deploying to an EVM-based chain may be more familiar to developers that have -written smart contracts before. However, the Contracts pallet makes some notable improvements to the -design of the EVM: - -1. **Wasm**. The Contracts pallet uses WebAssembly as its compilation target. Any language that - compiles to Wasm can potentially be used to write smart contracts. Although it's better to have a - dedicated domain-specific language and for that reason Parity offers the [ink!](#ink) language. - -2. **Rent**. Contracts must pay rent or else hold a deposit suitably large enough in order to - justify its existence on-chain. When a contract does not uphold this, it may create what's called - a _tombstone_ which is a reference to the contract. In some conditions, the contract will be - deleted outright along with its storage if it does not maintain these requirements. - -3. **Caching**. Contracts are cached by default and therefore means they only need to be deployed - once and afterward be instantiated as many times as you want. This helps to keep the storage load - on the chain down to the minimum. On top of this, when a contract is no longer being used and the - _existential deposit_ is drained, the code will be erased from storage (known as reaping). - -### Ink - -[ink!](https://github.com/paritytech/ink) is a domain specific language for writing smart contracts -in Rust and compiles to Wasm code. As it states in its README, it is still in an experimental phase -so brave developers should be aware that they might have a bumpy - but workable - development -experience. There are some projects that have built projects in ink! with a decent level of -complexity such as Plasm's [Plasma contracts][plasm plasma], so it is mature enough to start -building interesting things. - -For interested developers, they can get started writing smart contracts using ink! by studying the -[examples](https://github.com/paritytech/ink/tree/master/examples) that were already written. These -can be used as guideposts to writing more complex logic that will be deployable on smart contract -parachains. - -ink! has laid much of the groundwork for a new smart contract stack that is based on a Wasm virtual -machine and compatible with Substrate chains. - -### It's still early - -It’s still very early for smart contracts on Polkadot and the development is only now stabilizing. -We are actively producing content to help developers get up to speed and will maintain the wiki with -the latest resources. You should also keep up to date with the following links: - -- [Edgeware][]. -- [Moonbeam][] -- [ink!](https://github.com/paritytech/ink). (Keep an eye out for content on the wiki tab.) -- [Substrate contracts pallet](https://github.com/paritytech/substrate/tree/master/frame/contracts). - -#### Edgeware - -One project that is live today with the smart contracts pallet is [Edgeware][edgeware]. Edgeware is -a permissionless platform for smart contracts and is conducting experiments with on-chain -governance. It is currently the best option for developers who have created their smart contracts -and want to deploy to a live environment. - -Edgeware intends to at some point connect to Polkadot as a parachain that allows for smart -contracts. At this point, the smart contracts would be able to interact with other pieces of the -Polkadot ecosystem through [XCMP](learn-crosschain.md). - -Edgeware general documentation can be found [here][edgeware documentation] and [how to deploy smart -contracts on Edgeware here][edgeware contracts documentation]. - -### Moonbeam - -[Moonbeam][] is another project that is planning to deploy to Polkadot as a parachain and will -support smart contracts. Since Moonbeam uses [Frontier][], an interoperability layer with existing -Ethereum tooling, it will support all applications that are written to target the EVM environment -with little friction. - -Try deploying a contract to Moonbeam by following their [documentation][moonbeam docs]. - -## Conclusion - -This guide has given you a mental model and shown the requisite resources to help you determine and -start building your project as a parachain or smart contract today. Even though the tooling is still -maturing, the advantage of being early will be the familiarity and head start on your project, -allowing you to innovate and create something truly new. - -If you have interesting ideas for parachains or smart contracts on Polkadot feel free to drop into -the [Polkadot Watercooler](https://matrix.to/#/#polkadot-watercooler:matrix.org) to talk about them. -Developers may be interested in joining the -[Polkadot Beginners Lounge](https://matrix.to/#/#polkadotnoobs:matrix.org) or -[Substrate Technical](https://matrix.to/#/#substrate-technical:matrix.org) to ask their questions. -As always, keep up to date with Polkadot and Kusama by following the -[social channels](community.md). - -Good luck! - -[substrate contracts]: https://github.com/paritytech/substrate/tree/master/frame/contracts -[edgeware]: https://edgewa.re -[edgeware documentation]: https://docs.edgewa.re/ -[edgeware contracts documentation]: https://contracts.edgewa.re/ -[plasm plasma]: https://github.com/staketechnologies/Plasm -[moonbeam]: https://moonbeam.network -[moonbeam docs]: https://docs.moonbeam.network/ -[frontier]: https://github.com/paritytech/frontier diff --git a/docs/build-hackathon.md b/docs/build-hackathon.md deleted file mode 100644 index 0e48b5d1cd4a..000000000000 --- a/docs/build-hackathon.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -id: build-hackathon -title: Hackathon -sidebar_label: Hackathon ---- - -As one of our objectives at Web3 Foundation is promoting the [Web3 technology stack][], we would -like to support any individual or team who wants to organize a hackathon that encourages more -developers to understand Polkadot and Substrate in your region or online. - -We are not only providing technical resources for you, but we can have someone from our team give a -hands-on workshop/presentation about the technology to help participants get started hacking on it -more quickly. - -## Ideas - -- NFT -- Bonded Tokens -- New governance pallets with different styles of voting & democracy -- Upgrade the TCR pallet -- IPFS integration -- Decentralized identity solutions -- Oracle pallet -- Implement Generalized State Channel/Plasma Chain -- Decentralized Exchange -- Tools for monitoring validator performance -- dApps across different parachains - -## Why you should host a hackathon? - -- Love to deliver the vision of Web3 -- Learn the bleeding-edge technology -- Believe the Web3 technology stack is suitable for developers to build their applications -- Like to make connections - -## How do hackathons differ from workshops? - -A hackathon is aimed at participants who want to deliver their prototype and demonstrate their ideas -to reality in a short period (few hours - one day). Workshops are aimed at familiarizing developers -with the underlying knowledge and tooling about the resources currently available for certain -technologies and how they can make use of it. - -## How can you run a hackathon in your city? - -1. Submit your application (Coming soon.) -2. Review -3. Decision -4. Follow up - -## How we can help - -- Provide technical resources/materials. -- Find a venue. -- Ensure the hackathon runs smoothly. - -## Past Hackathons - -- [Hackusama](https://hackusama.devpost.com/) - A 7-week online hackathon that was launched for - developers to "Build a Blockchain" or submit their wildest tools, visualizations, and ideas to the - "Open Hack" category. Many high quality submissions were received. -- [Hello World! by Polkadot](https://gitcoin.co/hackathon/polkadot/onboard) - A collaborative - hackathon celebrating the integration of Polkadot and Kusama into the Gitcoin platform. Had many - sets of smaller challenges that rewarded in either DOT or KSM. Opened from 15 October - 12 - November 2020. - -## Resources - -- [Substrate Knowledge Base](https://substrate.dev/docs/en/) - -## Support / Contact - -If you have any questions regarding organizing a hackathon, please free feel to contact us by -[email](mailto:events@web3.foundation) or ask us via -[Riot](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org) chat. - -[web3 technology stack]: http://wiki.web3.foundation/en/latest/tech_stack/tech_stack_overview/ diff --git a/docs/build-index.md b/docs/build-index.md deleted file mode 100644 index d2bda37bfd46..000000000000 --- a/docs/build-index.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: build-index -title: Builder's Portal -sidebar_label: Builder's Portal ---- - -Welcome to the builder's section of the Polkadot Wiki. - -Here, you will be able to find the most up-to-date information on the status of the development -tools in the Polkadot ecosystem. We are always adding new tools and frameworks as we learn about -them so if you are working on something that should be included please reach out to us on -[Element](https://app.element.io/#/room/#polkadot-watercooler:matrix.org). - -This section of the wiki is divided into the following parts: - -## Development Guide - -- [Starter's Guide](build-build-with-polkadot.md) - High level overview on choosing a parachain, - parathread, or smart contract for your project and how to get started. -- [Parachain Development Kits](build-pdk.md) - PDKs are toolkits for building parachains and - parathreads. -- [Smart Contracts](build-smart-contracts.md) - Smart contracts are fragments of custom logic that - can be deployed to a live chain. -- [Polkadot Wallets](build-wallets.md) - Learn about the supported wallets and how to manage - accounts. - -## Integration Guide - -This section is for service providers like wallets or node operators who want to learn how to -integrate Polkadot into their systems. - -- [Integration Initiation](build-integration.md) - The guide to the guide. -- [Polkadot Protocol Information](build-protocol-info.md) - General information and F.A.Q.s about - the Polkadot protocol, e.g. address formats. -- [Node Management](build-node-management.md) - A short overview of the Parity Polkadot client and - the most relevant options/flags for infrastructure providers. -- [Node Interaction](build-node-interaction.md) - Learn how to interact with your node via RPC. -- [Transaction Construction and Signing](build-transaction-construction.md) - Learn the transaction - format for Polkadot and how to construct and sign transactions offline. - -## Tools - -- [Tools](build-tools-index.md) - Maintained list of tools. -- [Subkey](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) - Command line utility for - generating and inspecting key pairs. -- [JS tools](https://github.com/polkadot-js/tools) - TypeScript tools for offline signing of - transactions, RPC calls, and more. - -## Resources - -- [Examples](#) - Example projects sourced from the community -- see what others are building. - -### Grants - -- [Grants](grants.md) - A list of all Polkadot-related projects given grants by the Web3 Foundation. - -### PSPs - -Polkadot Standards Proposals (PSPs) are standards for the Polkadot ecosystem. - -- [PSP GitHub Repository](https://github.com/w3f/PSPs) - Read, create, or discuss standards and - proposals. - -### Hackathon - -- [Resources For Running a Hackathon](build-hackathon.md) diff --git a/docs/build-pdk.md b/docs/build-pdk.md deleted file mode 100644 index 6a8f07045189..000000000000 --- a/docs/build-pdk.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -id: build-pdk -title: Parachain Development Kits (PDKs) -sidebar_label: Parachain Development Kits (PDKs) ---- - - - -Parachain development kits (PDKs) are a set of tools that make it easy for developers to create -Polkadot compatible [parachains](learn-parachains.md). - -## Why create a parachain? - -Before diving into what a PDK is and how it would be used, let's revisit _why_ a developer would -want to create a parachain and connect it to Polkadot. - -A parachain has two major value adds that make it a desirable choice for a developer over creating a -standalone chain: - -- _Shared security_ - removes the necessity of bootstrapping a chain's own validator set. -- _Cross-chain communication_ - allows parachains to interoperate with each other through the XCMP - protocol. - -Parachains can [lease the security](learn-security.md) of the Polkadot network by bonding -[DOT](learn-DOT.md) for a parachain slot. This means that the social costs of building a community -around your project and convincing validators to participate in your network security are reduced. -It is anticipated that Polkadot will have strong security, and decentralized application projects -wishing to benefit from this security would want to become a parachain. For more information on the -mechanic of leasing a parachain slot through a candle auction see [here](learn-auction.md). - -Any decentralized application or chain that wants to enable trustless messaging to other parachains -already connected to Polkadot would want to become a parachain. Interoperability between sovereign -chains involves certain constraints and complex protocols to enable across a wide breadth of chains. -With Polkadot, you will get this feature out of the box if your build your application as a -parachain. The [XCMP protocol](learn-crosschain.md) will allow any parachains to interoperate by -passing messages between them. Furthermore, as bridges to other chains are launched (such as those -to Bitcoin or Ethereum) the parachains will be able to operate with these as well. - -## What is a PDK? - -As mentioned, a PDK is a set of tools that allows developers to easily create a parachain. In -practice this means that the PDK will consist of a couple key components: - -- _State transition function_ - a way for your application to move from one state to another state. -- _Collator node_ - a type of peer-to-peer node in the Polkadot network with certain - responsibilities in regard to parachains. - -The state transition function (STF) can be any abstract way for an application to go from one state -to another state. The only constraint that Polkadot places on this STF is that it must be easily -verifiable -- usually though what we call a _witness_ or _proof_. It must be so because the Relay -Chain validators will need to check that each state it receives from the collator node is correct -without actually running through the entire computation. Some examples of these proofs include the -Proof-of-Validity blocks or zk-SNARKs, which require less computational resources to verify than -they do to generate. The verification asymmetry in proof generation of the STF is one of the -integral insights that allows Polkadot to scale while keeping high security guarantees. - -A collator node is one of the types of network maintainers in the Polkadot protocol. They are -responsible for **keeping availability** of the state of the parachain and the new states returned -from iteration of the state transition function. They must remain online in order to keep track of -the state and also of the XCMP messages that it will route between itself and other parachains. -Collator nodes are responsible for passing the succinct proofs to the Relay Chain validators, and -tracking the latest blocks from the Relay Chain. In essence, a collator node also acts as a light -client for the Polkadot Relay Chain. For more on collator nodes see [here](learn-collator.md). - -## What kind of PDKs exist? - -Currently the only PDK is Parity [Substrate](https://github.com/paritytech/substrate) and -[Cumulus](https://github.com/paritytech/cumulus). Substrate is a blockchain framework that provides -the basic building blocks of a blockchain (things like the networking layer, consensus, a Wasm -interpreter) and provides an intuitive way to construct your runtime. Substrate is made to ease the -process of creating a new chain, but it does not provide support for Polkadot compatibility -directly. For this reason, Cumulus, an added library will contain all of the Polkadot compatibility -glue code. Cumulus is still in development, but the idea is that it should be simple to take a -Substrate chain and add the parachain code by importing the crates and adding a single line of code. - -Substrate and Cumulus provide a PDK from the abstraction of the blockchain format, but it is not -necessary that a parachain even needs to be a blockchain. For example, a parachain just needs to -satisfy the two constraints listed above: _state transition function_ and _collator node_. -Everything else is up to the implementer of the PDK. - -One interesting idea for a PDK that would be nice to see is to have a -[roll-up](https://ethresear.ch/t/roll-up-roll-back-snark-side-chain-17000-tps/3675) kit that allowed -developers to create snark-based parachains. If we review the roll-up write-up, we see that the -system uses two roles: users that update **state** and an operator that **aggregates the state -updates** into a single on-chain update. It should be straightforward to see how we can translate -this to the parachain terms. The state transition function for a roll-up-like parachain would be -updating the state (in practice, most likely a merkle tree, which would be easily verifiable) from -the user inputs. The operator would act as the collator node, which would aggregate the state and -create the zk-SNARK proof that it would hand to the Relay Chain validators for verification. - -## Build a PDK - -If you or your team are interested in developing a PDK feel free to open an issue on the -[W3F collaboration repository](https://github.com/w3f/Web3-collaboration) for comment. There may be -grants available for this type of work. diff --git a/docs/build-protocol-info.md b/docs/build-protocol-info.md deleted file mode 100644 index a22ecb6dc409..000000000000 --- a/docs/build-protocol-info.md +++ /dev/null @@ -1,275 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - - - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be -specific to Polkadot, notable differences to other chains that you may have worked with, and -practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888_888), in which the stakeholders -decided to redenominate the DOT token. The redenomination does not change the number of base units -(called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be -1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the -[details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the -[results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1_248_326, which -occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) -`AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to -handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check -format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page]() -in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography.md) key pairs and signing -algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in -order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an -account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce -reset. Polkadot's ED is 1 DOT, while Kusama's is 33.3333 microKSM (0.0000333333 KSM). You can always -verify the existential deposit by checking the -[chain state](https://polkadot.js.org/apps/#/chainstate) for the constant -`balances.existentialDeposit`. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial -wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful -withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have -accounts reaped, as users could refund the address and try making transactions from it. The Balances -pallet provides a `transfer_keep_alive` function that will return an error and abort rather than -make the transfer if doing so would result in reaping the sender's account. - -> Note: The Statemint parachain has a lower existential deposit than the Relay Chain (0.1 DOT and -> 0.000003333 KSM) as well as lower transaction fees. It is highly recommended to handle balance -> transfers on Statemint. Statemint integration is discussed in the next page of the guide. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in -[`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). -Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in -staking and governance, for example. Reserved balance represents funds that have been set aside by -some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks -can operate on the same account, but they overlap rather than add. Locks are automatically added -onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these -are not customizable. For example, an account could have a free balance of 200 DOT with two locks on -it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a -transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT -such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases -over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, -however, see other extrinsics within the blocks that you decode. Find more information in the -[Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some -measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that -it is within some delta of their system clock. Inherents are not gossiped on the network, and only -block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay -a fee to have the transaction included on chain. Because the value of including signed transactions -on-chain can be recognized prior to execution, they can be gossiped on the network between nodes -with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or -Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For -example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, -the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash -checkpoint from which a transaction is valid and a validity period (also called "era" in some -places) that represents the number of blocks after the checkpoint for which the transaction is -valid. If the extrinsic is not included in a block within this validity window, it will be discarded -from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this -parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 -blocks (about four hours) at genesis. If the validity period is larger than the number of blocks -stored on-chain, then the transaction will only be valid as long as there is a block to check it -against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will -make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an -immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake -> that indexing services and custodians make. This error will cause major issues for your users. -> Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash -as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as -a fingerprint of the information within a transaction, and there are times when two transactions -with the same hash are both valid. In the case that one is invalid, the network properly handles the -transaction and does not charge a transaction fee to the sender nor consider the transaction in the -block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last -transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a -public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be -created from a public key account, but could also form from other means such as governance. These -origins do not have a nonce associated with them the way that an account does. For example, -governance might dispatch the same call with the same arguments multiple times, like “increase the -validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the -hash would be a reliable representative of the call, but its execution would have different effects -depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID -(height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of -extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a -transaction. This methodology is reflected in the Substrate codebase itself, for example to -[reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) -from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the -chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when -claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate -a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a -transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. -Make sure that you monitor events in each block for events that contain your addresses of interest. -Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a -"tip" to increase transaction priority during congested periods. See the -[transaction fee](learn-transaction-fees.md) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them -and interact directly with the chain data or implement your own codec, Polkadot encodes block and -transaction data using the -[SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Polkadot allows [runtime upgrades](learn-runtime-upgrades.md) without a hard fork. The runtime is a -Wasm binary stored on-chain and can be updated using your chain’s governance mechanism. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test -infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are -deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run -an archive node and listen for events and transactions to track all account activity. This -especially applies to _locking_ operations if you are calculating balance as the spendable balance, -i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted -except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order -to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a -long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms -like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/docs/build-smart-contracts.md b/docs/build-smart-contracts.md deleted file mode 100644 index 7ad373251799..000000000000 --- a/docs/build-smart-contracts.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -id: build-smart-contracts -title: Smart Contracts -sidebar_label: Smart Contracts ---- - -The Polkadot Relay Chain will not natively support smart contracts. However, parachains on Polkadot -will support smart contracts. There are already announced projects such as -[Edgeware](https://edgewa.re), and thanks to the Substrate built-in -[contract pallet](https://substrate.dev/rustdocs/latest/pallet_contracts/index.html), it is likely -that more parachains will support WebAssembly smart contracts. - -Additionally, there is the -[EVM Pallet](https://substrate.dev/docs/en/knowledgebase/smart-contracts/evm-pallet), which allows a -parachain to implement the Ethereum Virtual Machine, thereby supporting almost direct ports of -Ethereum contracts. Some of the projects using this approach are [Edgeware](https://edgewa.re), -[Moonbeam](https://moonbeam.network/) and [Frontier](https://github.com/paritytech/frontier). - -A video version of the recap of the smart contract situation on Polkadot and Kusama is available -[here](https://www.youtube.com/watch?v=fKHkFBXaUxQ). - -## Resources - -Here is the list of current resources available to developers who want to get started writing smart -contracts to deploy on parachains based on Substrate. - -- [Edgeware Contracts](https://contracts.edgewa.re) - Edgeware's documentation on Smart Contracts -- [ink!](https://github.com/paritytech/ink) - Parity's ink to write smart contracts. -- [Substrate Contracts Workshop](https://substrate.dev/substrate-contracts-workshop/#/) - a - walkthrough of the basics of writing and deploying an ERC20 token using `ink!`. - -## Examples - -Collected below are some community examples of smart contracts in `ink!`. **Are you working on a -smart contract example? Ask us to add it to this page!** - -- [Ownable](https://github.com/JesseAbram/foRust/) - Port of the OpenZeppelin `Ownable` contract. - -## Storage Rent - -Storage rent limits the footprint that a contract can have on the blockchain's storage. - -A contract deployed to the chain produces a code hash from which new instances of the chain can be -created, but there is currently no rent applied to the code hash itself. The rent applies only to -instances of this contract which have their own _contract accounts_. Deploying a code hash currently -has a one-time byte-fee applied to the transaction, but no recurring cost. - -An account of a contract instance is charged proportionally to the amount of storage its account -uses. When a contract's balance goes below a defined limit, the contract's account is turned into a -_tombstone_ (a hash of the contract's current state) and its storage is cleaned up. A tombstone -contract can be restored by providing the data that was cleaned up when it became a tombstone as -well as any additional funds needed to keep the contract alive. This fee will retroactively apply to -missed rent periods. - -Block producers or regular users of the chain can "poke" a smart contract if they think it ran out -of funds for rent. This will initiate the clean-up process and the _poker_ will get a finder's fee. - -## What is the difference between developing a smart contract versus a parachain? - -### Layer of Abstraction - -When you write a smart contract you are creating the instructions that will be deployed and -associated to a specific chain address. - -In comparison, a runtime module is the entire logic of a chain's state transitions (what's called a -state transition function). - -Smart contracts must consciously implement upgradeability while parachains will have the ability to -swap out their code entirely through a root command or via the governance pallet. - -When you build a smart contract, it will eventually be deployed to a target chain with its own -environment. Parachains allow the developer to declare the environment of their own chain, even -allowing others to write smart contracts for it. - -### Gas Fees - -Smart contracts must find a way to limit their own execution, or else full nodes are vulnerable to -DOS attacks. An infinite loop in a smart contract, for example, could consume the computational -resources of an entire chain, preventing others from using it. The -[halting problem](https://en.wikipedia.org/wiki/Halting_problem) shows that with a powerful enough -language, it is impossible to know ahead of time whether or not a program will ever cease execution. -Some platforms, such as Bitcoin, get around this constraint by providing a very restricted scripting -language. Others, such as Ethereum, "charge" the smart contract "gas" for the rights to execute -their code. If a smart contract does get into a state where execution will never halt, it eventually -runs out of gas, ceases execution, and any state transition that would have been made by the smart -contract is rolled back. Polkadot uses a _weight-fee model_ and not a _gas-metering model_. - -Parachains can implement arbitrarily powerful programming languages and also contain no notion of -gas for their own native logic. This means that some functionality is easier to implement for the -developer, but it also means there are some constructs, such as a loop without a terminating -condition, which should _never_ be implemented. Leaving certain logic, such as complex loops that -could possibly run indefinitely, to a non-smart contract layer, or even trying to eliminate it -entirely, will often be a wiser choice. Parachains try to be proactive, while smart contract -platforms are event-driven. - -## Resources - -- [When should I build a Substrate runtime versus a Substrate smart contract](https://stackoverflow.com/a/56041305) - - A technical standpoint that answers the question of when a developer might choose to develop a - runtime versus a smart contract. diff --git a/docs/build-transaction-construction.md b/docs/build-transaction-construction.md deleted file mode 100644 index 05b826a3f4f4..000000000000 --- a/docs/build-transaction-construction.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - - - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast -transactions. Like the other pages in this guide, this page demonstrates some of the available -tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info.md#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info.md#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. - If zero, the transaction is [immortal](build-protocol-info.md#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track -and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` -function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for -interacting with a Substrate client, including one called "Signer CLI" to create, sign, and -broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The -`signer sendOffline` command has the exact same API, but will not broadcast the transaction. -`submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a -valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to -`15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use -your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s -signature field, and send the transaction (or just return the serialized transaction if using -`sendOffline`). - -## Tx Wrapper Polkadot - -If you do not want to use the CLI for signing operations, Parity provides an SDK called -[TxWrapper Core](https://github.com/paritytech/txwrapper-core) to generate and sign transactions -offline. For Polkadot, Kusama, and select parachains, use the `txwrapper-polkadot` package. Other -Substrate-based chains will have their own `txwrapper-{chain}` implementations. See the -[examples](https://github.com/paritytech/txwrapper-core/blob/main/packages/txwrapper-examples/README.md) -for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper-polkadot'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper-polkadot'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper-polkadot"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper-polkadot'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper-polkadot"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper-core/blob/b213cabf50f18f0fe710817072a81596e1a53cae/packages/txwrapper-core/src/test-helpers/signWithAlice.ts -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper-polkadot"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper-polkadot’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or - `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified - as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See -[Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/docs/build-wallets.md b/docs/build-wallets.md deleted file mode 100644 index 1d6f828c6646..000000000000 --- a/docs/build-wallets.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: build-wallets -title: Polkadot Wallets -sidebar_label: Polkadot Wallets ---- - -## Polkadot Wallets - -The integration of a [wallet](glossary.md#wallet) with Polkadot allows for simple and easy access to -private keys and signing transactions. Below are some wallets that support Polkadot along with their -development statuses. - -[Polkadot support](https://support.polkadot.network/) can provide assistance with issues related to -Polkadot-JS, the Polkadot{.js} extension, or Parity Signer. For other wallet software, you should -contact the developers of that wallet. - -> Note that only Parity-developed wallets are listed on this page. Other third-party wallets are -> available, but are not listed here. - -## Encryption Enhancement - -Some newly generated `JSON` account files cannot be imported (restored) into older wallet software. -This is due to an enhanced encryption method, which is also noticeable in a slight delay when -encrypting/decrypting your wallet. If you are unable to load a `JSON` file, please ensure that you -are using the latest version of the wallet software. If you are still unable to load it, ensure that -the wallet software is using the latest version of the [Polkadot API](https://polkadot.js.org/api/). - -### Supported Wallets - -| Wallet Name | Development State | Team Name | Description | Custody | Supports | -| ------------------------------------------------------------------- | ----------------- | --------- | ----------------- | ------------- | -------- | -| [Parity Signer](https://www.parity.io/signer/) (see warning below) | Live | Parity | iOS and Android | Non-custodial | Staking | -| [Polkadot-js Desktop](https://github.com/polkadot-js/apps/releases) | Live | Parity | Win, Mac, Linux | Non-custodial | Staking | -| [Polkadot-js extension](https://github.com/polkadot-js/extension) | Live | Parity | Browser extension | Non-custodial | Staking | -| [Polkadot-js apps](https://polkadot.js.org/apps/#/accounts) | Live | Parity | Browser | Non-Custodial | Staking | - -> Warning: Parity Signer currently does not allow you to see the transaction you are signing. This -> means that you are at risk if connected to a compromised version of Polkadot-JS. A fix is being -> worked on; please see [this GitHub issue](https://github.com/paritytech/parity-signer/issues/724) -> for more details. diff --git a/docs/build/build-build-with-polkadot.md b/docs/build/build-build-with-polkadot.md new file mode 100644 index 000000000000..cad992a1322d --- /dev/null +++ b/docs/build/build-build-with-polkadot.md @@ -0,0 +1,351 @@ +--- +id: build-build-with-polkadot +title: Polkadot Builders Starter's Guide +sidebar_label: Polkadot Builders Starter's Guide +slug: ../build-build-with-polkadot +--- + +_This article is the maintained version of the blog post: +[Everything you Need to Know to Prepare for Polkadot](https://medium.com/polkadot-network/everything-you-need-to-know-to-prepare-for-polkadot-32d08b929735)._ + +Polkadot is a blockchain protocol with two goals: providing **shared security** among all connected +parachains and allowing all connected chains to **interoperate** by using +[XCMP](../learn/learn-crosschain.md). With the advent of [PDKs](build-pdk.md) like Parity Substrate and +Cumulus, the time it takes to develop and launch a new chain has dropped significantly. While before +it would take years to launch a new chain, now it may only take weeks or even days. + +This guide will walk you through the steps you can take today to get started building your vision +with Polkadot. It will explain the difference between a parachain and a smart contract (and why one +may be better suited for your application over the other). + +## Polkadot Ecosystem Networks + +- Mainnet: **Polkadot** +- Canary network: **Kusama** + - [Kusama](https://kusama.network/) is a value-bearing canary network that gets features before + Polkadot does... _expect chaos_... +- Official testnets: + - **Westend** - Functionality equal to the current Polkadot mainnet, with possible next-generation + testing of features from time to time that will eventually migrate onto Polkadot. Perma-testnet (is not reset back to genesis block). + - **Canvas** - Wasm based Smart Contract enabled testnet, primarily for `ink!` development. + - **Rococo** - Parachains and XCM testnet. Occasionally reset (started over again with a new genesis block). + +Polkadot mainnet has been running since May 2020 and has +[implementations in various programming languages](../learn/learn-implementations.md) ranging from Rust to +JavaScript. Currently, the leading implementation is built in Rust and built using the Substrate +framework. + +Tooling is rapidly evolving to interact with the network; there are so many ways to get started! + +But before you jump head-first into the code, you should consider the _kind_ of decentralized +application you want to make and understand the different paradigms available to developers who want +to build on Polkadot. + +## What is the difference between building a parachain, a parathread, or a smart contract? + +Polkadot provides several ways for you to deploy your application: as a smart contract on an existing +parachain, as your own parachain, or as a parathread. There are trade-offs when working with each of +these and reading this section will help you understand them. + +### Parachains & Parathreads + +Parachains are "parallel" chains containing their own runtime logic and benefit from the shared +security and the cross-chain messaging provided by the Polkadot Relay Chain. Parachains permit a +high degree of flexibility and customization but require more effort to create and maintain over +time. + +Parathreads are like parachains and enable the developer to have lower-level control of the logic of +their application. The main difference between the two is economic since parathreads will be much +less expensive to secure than a parachain. The lower costs of parathreads are due to the fact that +parathreads will only produce a block when they need to, unlike parachains, which have secured a +slot to produce a block at every block of the Relay Chain. When building a parathread, you will use +the same tools (like PDKs) and you get all of the benefits of building a parachain, without the +drawback of the cost. + +Parachains grant the creators more space to build the monetary system and other aspects of the chain +from the ground up. They will allow for more succinct and efficient execution of complex logic than +could ever be offered by a smart contract platform. Parachains also offer more flexibility in the +form of governance and can perform complete upgrades in a less controversial way than the current +process of hard-forks. + +Some examples of features you can have on a parachain or parathread: + +- Custom fee structure (for example, pay a flat fee for transactions or pay per byte). +- Custom monetary policy for the native token and local economy. +- Treasury to be funded through transitions in your state function. +- A governance mechanism that could manage a DAO that is responsible for allocating your on-chain + treasury. + +![build 1](../assets/build-1.png) + +Parachains open possibilities to construct complex runtime logic that would be too expensive to +execute with smart contracts. However, unlike smart contracts, parachains lack a mandatory gas +metering system entirely and could potentially be vulnerable to bugs that cause infinite loops +(something that is prevented by design in smart contracts). This vulnerability is mitigated by the +weight system that is implemented in Substrate -- although it places more of a burden on the +developer of the parachain to properly perform benchmarks. + +You may also decide to harness a combination of parachain, parathread, and smart contract. If you +have certain logic that requires loops and it cannot be removed, use the native parachain runtime to +handle all complex logic and the smart contract to call iteration. If you require off-chain data +from an oracle, you may want to use a parathread as an oracle feed that only triggers once every 24 +hours (this makes the most sense if the data is useful to other players in the Polkadot ecosystem +too). + +Most likely you’ve already realized that your application is better suited to be one or the other +(or a hybrid of them both), but if you need a quick recap to digest the information, you can use +this comparison chart as a cheat sheet: + +![build 2](../assets/build-2.png) + +> **Note:** The image above does not include parathreads, but as we mentioned before all the +> benefits of parachains apply just as well to parathreads. Parathreads, however, _are_ cheaper to +> deploy and maintain. So if they had a column on the table above, it would look like the parachain +> column with "Ease of deployment" and "Maintenance overhead" changed to `+`. + +### Smart Contracts + +A smart contract is simply some code that exists at an address on a chain and is callable by +external actors. The key part is that you actually have to put the code on chain before anyone can +start executing it! + +Deploying your smart contract on chain will vary slightly for whichever specific parachain you will +use, but generally you will send a special transaction that will create the smart contract on the +ledger. You will likely need to pay an associated fee for the initialization logic and any storage +that your contract consumes. + +On the Polkadot mainnet, there will be parachains that act as smart contract platforms. Smart +contracts are executable programs that exist on only a single chain and are limited in complexity. +Because they exist on a single chain, they can have smooth interoperability with other smart +contracts on the same chain. However, they will always be constrained and limited by the inherent +characteristics of their host chain. + +If there is a need to have a large amount of control over the design and features of your +application, a parachain is a better choice. Keep in mind, smart contracts can be used as a testing +ground before later being turned into full-fledged parachains. Smart contract platforms will usually +have convenient tooling like IDEs to facilitate quick iterations. A smart contract MVP could be +created to gauge user interest before putting in the work to build out a parachain. + +Each platform will have a different way of paying for and maintaining the state of your smart +contract. The different patterns you may see for paying for your smart contract include: + +- A transaction fee associated with deploying each transaction. +- A subscription model in which you pay some chain entity routinely for the usage of the platform. +- An access token model for which you need to hold a threshold of native tokens to use the platform + (EOS has something similar). Storage rent. +- Free trial or developer promotion. +- Most smart contract platforms use some form of gas to limit the number of operations a user can + perform. Users will be required to pay for the gas upfront and will be refunded for what they + don’t use. + +You will need to consider the storage and complexity of your smart contract to ensure that gas usage +stays within reasonable bounds. Storage will likely be expensive for whichever smart contract +platform you use, so it is necessary to keep as much data off-chain as possible. You may consider +using [IPFS](https://ipfs.io/) or [Storj](https://storj.io/) to keep the data and submitting only +the content address on chain. + +--- + +This guide now splits into two sections depending on whether you’ve decided on a smart contract or a +parachain to build your application. Feel free to read both sections or just the one that is +applicable to you. + +- [I want to build a parachain or parathread!](#so-you-want-to-build-a-parachain-or-parathread) +- [I want to build a smart contract!](#so-you-want-to-build-a-smart-contract) + +## So you want to build a parachain or parathread... + +Now that you have determined that building a parachain or parathread is the right approach for your +new project, the next step is to decide which framework to use. Frameworks for building a parachain +or parathread are known as parachain development kits ([PDK](build-pdk.md)s). Currently, the only +PDK available is Substrate and Cumulus from Parity Technologies. + +In the future, there will be many different PDKs available in different programming languages, just +like there are multiple [implementations of the Polkadot Host](../learn/learn-implementations.md). + +> **Call to Action:** Do you want to build a Parachain Development Kit from scratch? The Web3 +> Foundation is giving grants to teams who are doing this, learn more and apply on the +> [W3F grants page](https://grants.web3.foundation). + +### Get started with Substrate + +Substrate is the underlying framework on which Polkadot itself is built. It is a toolset for +blockchain innovators that provides the necessary building blocks for constructing a chain. It +includes a library of modular runtime plug-ins from which you can compose your chain logic. + +The best way to get started with Substrate is to explore the +[Substrate Developer Hub](https://substrate.dev/docs/en/), an online resource built and maintained +by [Parity Technologies](https://parity.io). + +### How to set up your parachain + +After creating your chain runtime logic with Substrate, you will be able to compile it down to a +Wasm executable. This Wasm code blob will contain the entire state transition function of your +chain, and is what you will need to deploy your project to Polkadot as either a parachain or +parathread. + +Validators on Polkadot will use the submitted Wasm code to validate the state transitions of your +chain or thread, but doing this requires some additional infrastructure. A validator needs some way +to stay up to date with the most recent state transitions, since Polkadot nodes will not be required +to also be nodes of your chain. + +This is where the collator node comes into play. A collator is a maintainer of your parachain and +performs the critical action of producing new block candidates for your chain and passing them to +Polkadot validators for inclusion in the Polkadot relay chain. + +Substrate comes with its own networking layer built-in but unfortunately only supports solo chains +(that is, chains that do not connect to the relay chain). However, there is the Cumulus extension +that includes a collator node and allows for your Substrate-built logic to be compatible with +Polkadot as either a parachain or parathread. + +#### Cumulus + +The goal of [Cumulus](build-cumulus.md) is to be an extension of Substrate that will make any +Substrate runtime compatible with Polkadot. + +It handles the network compatibility overhead that any parachain would need to implement to be +connected to Polkadot. This includes: + +- Cross-chain message passing (XCMP). +- Out-of-the-box Collator node setup. +- An embedded full client of the Relay Chain. +- Polkadot block authorship compatibility. + +Integrating Cumulus with your Substrate chain will port it into a parachain capable of working on +Polkadot with minimal modification, possibly as little work as importing a crate and adding a few +lines! + +### How to deploy your parachain or parathread in Polkadot + +#### Parachain + +In order to include your parachain into the Polkadot network, you will need to acquire a parachain +slot. + +Parachain slots will be sold in open auctions, the mechanics of which can be found on the +{{ polkadot: [parachain auction](../learn/learn-auction.md) :polkadot }} +{{ kusama: [parachain auction](../learn/mirror-learn-auction.md) :kusama }} page of the wiki. + +#### Parathread + +Parathreads will not require a parachain slot, so you will not need to engage in the candle auction +mechanism. Instead, you will be able to register your parathread code to the relay chain for a fee +and from then be able to start participating in the per-block auctions for inclusion of your state +transition into the relay chain. + +For more information on how parathread per-block auctions work, see the more detailed +{{ polkadot: [parathread](../learn/learn-parathreads.md) :polkadot }} +{{ kusama: [parathread](../learn/mirror-learn-parathreads.md) :kusama }} page. + +## So you want to build a smart contract... + +The Polkadot relay chain itself will not support smart contracts. However, since the parachains that +connect to Polkadot can support arbitrary state transitions, they can support smart contracts. + +Substrate presently supports smart contracts out-of-the-box in two ways: + +- The EVM pallet offered by [Frontier][]. +- The [Contracts pallet][substrate contracts] in the FRAME library for Wasm based contracts. + +### Frontier EVM Contracts + +[Frontier][] is the suite of tools that enables a Substrate chain to run Ethereum contacts (EVM) +natively with the same API/RPC interface Ethereum exposes on Substrate. Ethereum Addresses can also +be mapped directly to and from Substrate's SS58 sceme from existing accounts. + +### Contracts Pallet + +The experience of deploying to an EVM-based chain may be more familiar to developers that have +written smart contracts before. However, the Contracts pallet makes some notable improvements to the +design of the EVM: + +1. **Wasm**. The Contracts pallet uses WebAssembly as its compilation target. Any language that + compiles to Wasm can potentially be used to write smart contracts. Although it's better to have a + dedicated domain-specific language and for that reason Parity offers the [ink!](#ink) language. + +2. **Rent**. Contracts must pay rent or else hold a deposit suitably large enough in order to + justify its existence on-chain. When a contract does not uphold this, it may create what's called + a _tombstone_ which is a reference to the contract. In some conditions, the contract will be + deleted outright along with its storage if it does not maintain these requirements. + +3. **Caching**. Contracts are cached by default and therefore means they only need to be deployed + once and afterward be instantiated as many times as you want. This helps to keep the storage load + on the chain down to the minimum. On top of this, when a contract is no longer being used and the + _existential deposit_ is drained, the code will be erased from storage (known as reaping). + +### Ink + +[ink!](https://github.com/paritytech/ink) is a domain specific language for writing smart contracts +in Rust and compiles to Wasm code. As it states in its README, it is still in an experimental phase +so brave developers should be aware that they might have a bumpy - but workable - development +experience. There are some projects that have built projects in ink! with a decent level of +complexity such as Plasm's [Plasma contracts][plasm plasma], so it is mature enough to start +building interesting things. + +For interested developers, they can get started writing smart contracts using ink! by studying the +[examples](https://github.com/paritytech/ink/tree/master/examples) that were already written. These +can be used as guideposts to writing more complex logic that will be deployable on smart contract +parachains. + +ink! has laid much of the groundwork for a new smart contract stack that is based on a Wasm virtual +machine and compatible with Substrate chains. + +### It's still early + +It’s still very early for smart contracts on Polkadot and the development is only now stabilizing. +We are actively producing content to help developers get up to speed and will maintain the wiki with +the latest resources. You should also keep up to date with the following links: + +- [Edgeware][]. +- [Moonbeam][] +- [ink!](https://github.com/paritytech/ink). (Keep an eye out for content on the wiki tab.) +- [Substrate contracts pallet](https://github.com/paritytech/substrate/tree/master/frame/contracts). + +#### Edgeware + +One project that is live today with the smart contracts pallet is [Edgeware][edgeware]. Edgeware is +a permissionless platform for smart contracts and is conducting experiments with on-chain +governance. It is currently the best option for developers who have created their smart contracts +and want to deploy to a live environment. + +Edgeware intends to at some point connect to Polkadot as a parachain that allows for smart +contracts. At this point, the smart contracts would be able to interact with other pieces of the +Polkadot ecosystem through [XCMP](../learn/learn-crosschain.md). + +Edgeware general documentation can be found [here][edgeware documentation] and [how to deploy smart +contracts on Edgeware here][edgeware contracts documentation]. + +### Moonbeam + +[Moonbeam][] is another project that is planning to deploy to Polkadot as a parachain and will +support smart contracts. Since Moonbeam uses [Frontier][], an interoperability layer with existing +Ethereum tooling, it will support all applications that are written to target the EVM environment +with little friction. + +Try deploying a contract to Moonbeam by following their [documentation][moonbeam docs]. + +## Conclusion + +This guide has given you a mental model and shown the requisite resources to help you determine and +start building your project as a parachain or smart contract today. Even though the tooling is still +maturing, the advantage of being early will be the familiarity and head start on your project, +allowing you to innovate and create something truly new. + +If you have interesting ideas for parachains or smart contracts on Polkadot feel free to drop into +the [Polkadot Watercooler](https://matrix.to/#/#polkadot-watercooler:matrix.org) to talk about them. +Developers may be interested in joining the +[Polkadot Beginners Lounge](https://matrix.to/#/#polkadotnoobs:matrix.org) or +[Substrate Technical](https://matrix.to/#/#substrate-technical:matrix.org) to ask their questions. +As always, keep up to date with Polkadot and Kusama by following the +[social channels](../general/community.md). + +Good luck! + +[substrate contracts]: https://github.com/paritytech/substrate/tree/master/frame/contracts +[edgeware]: https://edgewa.re +[edgeware documentation]: https://docs.edgewa.re/ +[edgeware contracts documentation]: https://contracts.edgewa.re/ +[plasm plasma]: https://github.com/staketechnologies/Plasm +[moonbeam]: https://moonbeam.network +[moonbeam docs]: https://docs.moonbeam.network/ +[frontier]: https://github.com/paritytech/frontier diff --git a/docs/build-cumulus.md b/docs/build/build-cumulus.md similarity index 98% rename from docs/build-cumulus.md rename to docs/build/build-cumulus.md index 59d9059679ca..d1077e0390a5 100644 --- a/docs/build-cumulus.md +++ b/docs/build/build-cumulus.md @@ -2,6 +2,7 @@ id: build-cumulus title: Cumulus sidebar_label: Cumulus +slug: ../build-cumulus --- diff --git a/docs/build/build-hackathon.md b/docs/build/build-hackathon.md new file mode 100644 index 000000000000..5d057a805bf1 --- /dev/null +++ b/docs/build/build-hackathon.md @@ -0,0 +1,77 @@ +--- +id: build-hackathon +title: Hackathon +sidebar_label: Hackathon +slug: ../build-hackathon +--- + +As one of our objectives at Web3 Foundation is promoting the [Web3 technology stack][], we would +like to support any individual or team who wants to organize a hackathon that encourages more +developers to understand Polkadot and Substrate in your region or online. + +We are not only providing technical resources for you, but we can have someone from our team give a +hands-on workshop/presentation about the technology to help participants get started hacking on it +more quickly. + +## Ideas + +- NFT +- Bonded Tokens +- New governance pallets with different styles of voting & democracy +- Upgrade the TCR pallet +- IPFS integration +- Decentralized identity solutions +- Oracle pallet +- Implement Generalized State Channel/Plasma Chain +- Decentralized Exchange +- Tools for monitoring validator performance +- dApps across different parachains + +## Why you should host a hackathon? + +- Love to deliver the vision of Web3 +- Learn the bleeding-edge technology +- Believe the Web3 technology stack is suitable for developers to build their applications +- Like to make connections + +## How do hackathons differ from workshops? + +A hackathon is aimed at participants who want to deliver their prototype and demonstrate their ideas +to reality in a short period (few hours - one day). Workshops are aimed at familiarizing developers +with the underlying knowledge and tooling about the resources currently available for certain +technologies and how they can make use of it. + +## How can you run a hackathon in your city? + +1. Submit your application (Coming soon.) +2. Review +3. Decision +4. Follow up + +## How we can help + +- Provide technical resources/materials. +- Find a venue. +- Ensure the hackathon runs smoothly. + +## Past Hackathons + +- [Hackusama](https://hackusama.devpost.com/) - A 7-week online hackathon that was launched for + developers to "Build a Blockchain" or submit their wildest tools, visualizations, and ideas to the + "Open Hack" category. Many high quality submissions were received. +- [Hello World! by Polkadot](https://gitcoin.co/hackathon/polkadot/onboard) - A collaborative + hackathon celebrating the integration of Polkadot and Kusama into the Gitcoin platform. Had many + sets of smaller challenges that rewarded in either DOT or KSM. Opened from 15 October - 12 + November 2020. + +## Resources + +- [Substrate Knowledge Base](https://substrate.dev/docs/en/) + +## Support / Contact + +If you have any questions regarding organizing a hackathon, please free feel to contact us by +[email](mailto:events@web3.foundation) or ask us via +[Riot](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org) chat. + +[web3 technology stack]: http://wiki.web3.foundation/en/latest/tech_stack/tech_stack_overview/ diff --git a/docs/build/build-index.md b/docs/build/build-index.md new file mode 100644 index 000000000000..64d7ab8ba867 --- /dev/null +++ b/docs/build/build-index.md @@ -0,0 +1,67 @@ +--- +id: build-index +title: Builder's Portal +sidebar_label: Builder's Portal +slug: ../build-index +--- + +Welcome to the builder's section of the Polkadot Wiki. + +Here, you will be able to find the most up-to-date information on the status of the development +tools in the Polkadot ecosystem. We are always adding new tools and frameworks as we learn about +them so if you are working on something that should be included please reach out to us on +[Element](https://app.element.io/#/room/#polkadot-watercooler:matrix.org). + +This section of the wiki is divided into the following parts: + +## Development Guide + +- [Starter's Guide](build-build-with-polkadot.md) - High level overview on choosing a parachain, + parathread, or smart contract for your project and how to get started. +- [Parachain Development Kits](build-pdk.md) - PDKs are toolkits for building parachains and + parathreads. +- [Smart Contracts](build-smart-contracts.md) - Smart contracts are fragments of custom logic that + can be deployed to a live chain. +- [Polkadot Wallets](build-wallets.md) - Learn about the supported wallets and how to manage + accounts. + +## Integration Guide + +This section is for service providers like wallets or node operators who want to learn how to +integrate Polkadot into their systems. + +- [Integration Initiation](build-integration.md) - The guide to the guide. +- [Polkadot Protocol Information](build-protocol-info.md) - General information and F.A.Q.s about + the Polkadot protocol, e.g. address formats. +- [Node Management](build-node-management.md) - A short overview of the Parity Polkadot client and + the most relevant options/flags for infrastructure providers. +- [Node Interaction](build-node-interaction.md) - Learn how to interact with your node via RPC. +- [Transaction Construction and Signing](build-transaction-construction.md) - Learn the transaction + format for Polkadot and how to construct and sign transactions offline. + +## Tools + +- [Tools](build-tools-index.md) - Maintained list of tools. +- [Subkey](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) - Command line utility for + generating and inspecting key pairs. +- [JS tools](https://github.com/polkadot-js/tools) - TypeScript tools for offline signing of + transactions, RPC calls, and more. + +## Resources + +- [Examples](#) - Example projects sourced from the community -- see what others are building. + +### Grants + +- [Grants](../general/grants.md) - A list of all Polkadot-related projects given grants by the Web3 Foundation. + +### PSPs + +Polkadot Standards Proposals (PSPs) are standards for the Polkadot ecosystem. + +- [PSP GitHub Repository](https://github.com/w3f/PSPs) - Read, create, or discuss standards and + proposals. + +### Hackathon + +- [Resources For Running a Hackathon](build-hackathon.md) diff --git a/docs/build-integrate-assets.md b/docs/build/build-integrate-assets.md similarity index 99% rename from docs/build-integrate-assets.md rename to docs/build/build-integrate-assets.md index ce6b62a9a358..7db521151cf6 100644 --- a/docs/build-integrate-assets.md +++ b/docs/build/build-integrate-assets.md @@ -2,6 +2,7 @@ id: build-integrate-assets title: Assets on Polkadot sidebar_label: Integrating Assets +slug: ../build-integrate-assets --- The Polkadot Relay Chain does not natively support assets beyond DOT (likewise, KSM for Kusama). diff --git a/docs/build-integration.md b/docs/build/build-integration.md similarity index 96% rename from docs/build-integration.md rename to docs/build/build-integration.md index af62d6d1503e..5d3caecae246 100644 --- a/docs/build-integration.md +++ b/docs/build/build-integration.md @@ -2,6 +2,7 @@ id: build-integration title: Polkadot Integration Guide sidebar_label: Integration Initiation +slug: ../build-integration --- Welcome to the Polkadot integration guide. This guide will provide all the information you need to @@ -37,5 +38,5 @@ node and [TxWrapper Core](https://github.com/paritytech/txwrapper-core/) to cons transactions. Parity and Web3 Foundation will be able to provide the best support if you use these tools. -If your team would like support, join some of our [community channels](community.md) or contact +If your team would like support, join some of our [community channels](../general/community.md) or contact support@polkadot.network. diff --git a/docs/build-node-interaction.md b/docs/build/build-node-interaction.md similarity index 99% rename from docs/build-node-interaction.md rename to docs/build/build-node-interaction.md index 00fb608acd01..95412763b423 100644 --- a/docs/build-node-interaction.md +++ b/docs/build/build-node-interaction.md @@ -2,6 +2,7 @@ id: build-node-interaction title: Node Interaction sidebar_label: Node Interaction +slug: ../build-node-interaction --- This page will guide you through some basic interactions with your node. Always refer to the proper diff --git a/docs/build-node-management.md b/docs/build/build-node-management.md similarity index 92% rename from docs/build-node-management.md rename to docs/build/build-node-management.md index 835eee473da7..e2f904b0c6d9 100644 --- a/docs/build-node-management.md +++ b/docs/build/build-node-management.md @@ -2,6 +2,7 @@ id: build-node-management title: Node Management sidebar_label: Node Management +slug: ../build-node-management --- This page contains basic information about running a Parity Polkadot client. There are a lot of ways @@ -14,7 +15,7 @@ guide will always refer to the executable as `polkadot`. > link to instructions) for your client. If you are trying to run a validator, refer to this tutorial -[here](maintain-guides-how-to-validate-polkadot.md). +[here](../maintain/maintain-guides-how-to-validate-polkadot.md). ## Basic Node Operations @@ -53,7 +54,7 @@ with the `--rpc-port` and `--ws-port` options. To limit the hosts who can access **Execution** -The Parity Polkadot client implements a [Polkadot Host](learn-polkadot-host.md) and a native +The Parity Polkadot client implements a [Polkadot Host](../learn/learn-polkadot-host.md) and a native runtime. The runtime must compile to WebAssembly and is stored on-chain. If the client's runtime is the same spec as the runtime that is stored on-chain, then the client will execute blocks using the client binary. Otherwise, the client will execute the Wasm runtime from the chain. @@ -77,14 +78,14 @@ can set a custom path with `--base-path `. The keystore stores session keys, which are important for validator operations. -- [Polkadot documentation](learn-keys.md/#session-keys) +- [Polkadot documentation](../learn/learn-keys.md/#session-keys) - [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/session-keys) **`db`** The database stores blocks and the state trie. If you are running a validator node, it also stores GRANDPA pre-votes and pre-commits and the offchain-worker DB. Use caution when -[migrating validator nodes](maintain-guides-how-to-upgrade.md) to avoid equivocation. If you want to +[migrating validator nodes](../maintain/maintain-guides-how-to-upgrade.md) to avoid equivocation. If you want to start a new machine without resyncing, you can stop your node, back up the DB, and move it to a new machine. @@ -107,7 +108,7 @@ Web3 Foundation maintains [Polkadot Deployer](https://github.com/w3f/polkadot-de allows you to create local or remote cloud deployments of Polkadot nodes. See the README for instructions. -Validators, see the [validator setup guide](maintain-guides-how-to-use-polkadot-validator-setup.md) +Validators, see the [validator setup guide](../maintain/maintain-guides-how-to-use-polkadot-validator-setup.md) for information specific to deploying validator nodes. ## Monitoring and Telemetry diff --git a/docs/build-oracle.md b/docs/build/build-oracle.md similarity index 89% rename from docs/build-oracle.md rename to docs/build/build-oracle.md index fddaf6a68181..cad3b8d3c425 100644 --- a/docs/build-oracle.md +++ b/docs/build/build-oracle.md @@ -2,6 +2,7 @@ id: build-oracle title: Oracles sidebar_label: Oracles +slug: ../build-oracle --- In the blockchain context, an _oracle_ is a way to bring real-world data onto the blockchain so that @@ -33,8 +34,6 @@ baked into its specific model. As the Polkadot ecosystem develops and oracle par appear, this article will be updated with a comparison of the different solutions and the benefits and drawbacks that each provide. -[schellingcoin]: - https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ +[schellingcoin]: https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/ [chainlink]: https://polkadot.network/chainlink-reaches-milestone-with-polkadot/ -[feed pallet]: - https://github.com/smartcontractkit/chainlink-polkadot/blob/master/pallet-chainlink-feed/README.md +[feed pallet]: https://github.com/smartcontractkit/chainlink-polkadot/blob/master/pallet-chainlink-feed/README.md diff --git a/docs/build-parachains-rococo.md b/docs/build/build-parachains-rococo.md similarity index 85% rename from docs/build-parachains-rococo.md rename to docs/build/build-parachains-rococo.md index a0110b07f960..8223c472b623 100644 --- a/docs/build-parachains-rococo.md +++ b/docs/build/build-parachains-rococo.md @@ -2,29 +2,30 @@ id: build-parachains-rococo title: Rococo Parachain Testnet sidebar_label: Rococo Parachain Test Network +slug: ../build-parachains-rococo --- [Rococo](https://github.com/paritytech/cumulus#rococo-crown) is a Polkadot testnet built for testing -parachains. Unlike other testnets, Rococo allows parachains to interact with the [Relay Chain](glossary.md##relay-chain) -rather than running in isolation. Rococo utilizes [Cumulus](build-cumulus.md) and HRMP (Horizontal Relay-routed Message -Passing), which is also known as [XCMP-lite](learn-crosschain.md##xcmp-lite(hrmp)), in order to send transfers and messages +parachains. Unlike other testnets, Rococo allows parachains to interact with the [Relay Chain](../general/glossary.md##relay-chain) +rather than running in isolation. Rococo utilizes [Cumulus](build-cumulus.md) and HRMP (Horizontal Relay-routed Message +Passing), which is also known as [XCMP-lite](../learn/learn-crosschain.md###xcmp-lite-hrmp)), in order to send transfers and messages between parachains and the Relay Chain. -Messages are sent to the Relay Chain -> then from the Relay Chain to the desired parachain. Rococo -currently runs three test system parachains: Tick, Trick, and Track, as well as several externally developed +Messages are sent to the Relay Chain -> then from the Relay Chain to the desired parachain. Rococo +currently runs three test system parachains: Tick, Trick, and Track, as well as several externally developed parachains. ## What Parachains are on Rococo Now? You can view the list of included parachains on -[Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/parachains), +[Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/parachains), and a list of [proposed parachains](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/parachains/proposals). ## Obtaining ROC -ROC is the native testnet token on the Rococo testnet, and are available in the -[Rococo Faucet](https://app.element.io/#/room/#rococo-faucet:matrix.org) channel on Matrix. +ROC is the native testnet token on the Rococo testnet, and are available in the +[Rococo Faucet](https://app.element.io/#/room/#rococo-faucet:matrix.org) channel on Matrix. To receive ROC tokens, send the following command on the channel: ``` @@ -51,7 +52,7 @@ selecting any parachain of choice. For the purpose of these following examples, Rococo testnet "Custom Node" underneath "Development", following the [parachain workshop](https://substrate.dev/cumulus-workshop/). -![parachains on polkadotjs](assets/polkadotjs_network_parachains.png) +![parachains on polkadotjs](../assets/polkadotjs_network_parachains.png) ## How to make Cross Chain transfers @@ -72,7 +73,7 @@ For example, we can send tokens from Alice's account on the Relay Chain to her a parachain 200. To do so, we will need to head to the "Network" > "Parachains" tab and click on the "Transfer to chain" button. -![rococo downward transfer](assets/rococo/rococo-downward-transfer.png) +![rococo downward transfer](../assets/rococo/rococo-downward-transfer.png) Notice here, that we can select which parachain to send the funds to, specify the amount to be sent, and add any comments or a memo for the transfer. @@ -83,7 +84,7 @@ Upward transfers occur _from_ a parachain _to_ an account on the Relay Chain. To kind of transfer, we need to be connected to a parachain node on the network and be on the "Network" > "Parachains" tab. Click on the "Transfer to chain" button. -![rococo upward transfer](assets/rococo/rococo-upward-transfer.png) +![rococo upward transfer](../assets/rococo/rococo-upward-transfer.png) Note that the toggle should be set to off, ensuring that the funds go to the Relay Chain and not another parachain. @@ -110,8 +111,8 @@ We can get that parachain account address, from our parachain 300's terminal: From Alice's account on the Relay Chain, she is able to send some amount to parachain 200's depository. -![rococo lateral transfer](assets/rococo/rococo-lateral-transfer.png) +![rococo lateral transfer](../assets/rococo/rococo-lateral-transfer.png) Alice is now able to send from her account on parachain 200 to her account on parachain 300. -![rococo lateral transfer part 2](assets/rococo/rococo-lateral-transfer2.png) +![rococo lateral transfer part 2](../assets/rococo/rococo-lateral-transfer2.png) diff --git a/docs/build/build-pdk.md b/docs/build/build-pdk.md new file mode 100644 index 000000000000..2366ccbad07f --- /dev/null +++ b/docs/build/build-pdk.md @@ -0,0 +1,94 @@ +--- +id: build-pdk +title: Parachain Development Kits (PDKs) +sidebar_label: Parachain Development Kits (PDKs) +slug: ../build-pdk +--- + +Parachain development kits (PDKs) are a set of tools that make it easy for developers to create +Polkadot compatible [parachains](../learn/learn-parachains.md). + +## Why create a parachain? + +Before diving into what a PDK is and how it would be used, let's revisit _why_ a developer would +want to create a parachain and connect it to Polkadot. + +A parachain has two major value adds that make it a desirable choice for a developer over creating a +standalone chain: + +- _Shared security_ - removes the necessity of bootstrapping a chain's own validator set. +- _Cross-chain communication_ - allows parachains to interoperate with each other through the XCMP + protocol. + +Parachains can [lease the security](../learn/learn-security.md) of the Polkadot network by bonding +[DOT](../learn/learn-DOT.md) for a parachain slot. This means that the social costs of building a community +around your project and convincing validators to participate in your network security are reduced. +It is anticipated that Polkadot will have strong security, and decentralized application projects +wishing to benefit from this security would want to become a parachain. For more information on the +mechanic of leasing a parachain slot through a candle auction see [here](../learn/learn-auction.md). + +Any decentralized application or chain that wants to enable trustless messaging to other parachains +already connected to Polkadot would want to become a parachain. Interoperability between sovereign +chains involves certain constraints and complex protocols to enable across a wide breadth of chains. +With Polkadot, you will get this feature out of the box if your build your application as a +parachain. The [XCMP protocol](../learn/learn-crosschain.md) will allow any parachains to interoperate by +passing messages between them. Furthermore, as bridges to other chains are launched (such as those +to Bitcoin or Ethereum) the parachains will be able to operate with these as well. + +## What is a PDK? + +As mentioned, a PDK is a set of tools that allows developers to easily create a parachain. In +practice this means that the PDK will consist of a couple key components: + +- _State transition function_ - a way for your application to move from one state to another state. +- _Collator node_ - a type of peer-to-peer node in the Polkadot network with certain + responsibilities in regard to parachains. + +The state transition function (STF) can be any abstract way for an application to go from one state +to another state. The only constraint that Polkadot places on this STF is that it must be easily +verifiable -- usually though what we call a _witness_ or _proof_. It must be so because the Relay +Chain validators will need to check that each state it receives from the collator node is correct +without actually running through the entire computation. Some examples of these proofs include the +Proof-of-Validity blocks or zk-SNARKs, which require less computational resources to verify than +they do to generate. The verification asymmetry in proof generation of the STF is one of the +integral insights that allows Polkadot to scale while keeping high security guarantees. + +A collator node is one of the types of network maintainers in the Polkadot protocol. They are +responsible for **keeping availability** of the state of the parachain and the new states returned +from iteration of the state transition function. They must remain online in order to keep track of +the state and also of the XCMP messages that it will route between itself and other parachains. +Collator nodes are responsible for passing the succinct proofs to the Relay Chain validators, and +tracking the latest blocks from the Relay Chain. In essence, a collator node also acts as a light +client for the Polkadot Relay Chain. For more on collator nodes see [here](../learn/learn-collator.md). + +## What kind of PDKs exist? + +Currently the only PDK is Parity [Substrate](https://github.com/paritytech/substrate) and +[Cumulus](https://github.com/paritytech/cumulus). Substrate is a blockchain framework that provides +the basic building blocks of a blockchain (things like the networking layer, consensus, a Wasm +interpreter) and provides an intuitive way to construct your runtime. Substrate is made to ease the +process of creating a new chain, but it does not provide support for Polkadot compatibility +directly. For this reason, Cumulus, an added library will contain all of the Polkadot compatibility +glue code. Cumulus is still in development, but the idea is that it should be simple to take a +Substrate chain and add the parachain code by importing the crates and adding a single line of code. + +Substrate and Cumulus provide a PDK from the abstraction of the blockchain format, but it is not +necessary that a parachain even needs to be a blockchain. For example, a parachain just needs to +satisfy the two constraints listed above: _state transition function_ and _collator node_. +Everything else is up to the implementer of the PDK. + +One interesting idea for a PDK that would be nice to see is to have a +[roll-up](https://ethresear.ch/t/roll-up-roll-back-snark-side-chain-17000-tps/3675) kit that allowed +developers to create snark-based parachains. If we review the roll-up write-up, we see that the +system uses two roles: users that update **state** and an operator that **aggregates the state +updates** into a single on-chain update. It should be straightforward to see how we can translate +this to the parachain terms. The state transition function for a roll-up-like parachain would be +updating the state (in practice, most likely a merkle tree, which would be easily verifiable) from +the user inputs. The operator would act as the collator node, which would aggregate the state and +create the zk-SNARK proof that it would hand to the Relay Chain validators for verification. + +## Build a PDK + +If you or your team are interested in developing a PDK feel free to open an issue on the +[W3F collaboration repository](https://github.com/w3f/Web3-collaboration) for comment. There may be +grants available for this type of work. diff --git a/docs/build/build-protocol-info.md b/docs/build/build-protocol-info.md new file mode 100644 index 000000000000..82bae305372d --- /dev/null +++ b/docs/build/build-protocol-info.md @@ -0,0 +1,274 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +slug: ../build-protocol-info +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be +specific to Polkadot, notable differences to other chains that you may have worked with, and +practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888_888), in which the stakeholders +decided to redenominate the DOT token. The redenomination does not change the number of base units +(called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be +1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the +[details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the +[results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1_248_326, which +occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) +`AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to +handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check +format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() +in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](../learn/learn-cryptography.md) key pairs and signing +algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in +order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an +account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce +reset. Polkadot's ED is 1 DOT, while Kusama's is 33.3333 microKSM (0.0000333333 KSM). You can always +verify the existential deposit by checking the +[chain state](https://polkadot.js.org/apps/#/chainstate) for the constant +`balances.existentialDeposit`. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial +wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful +withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have +accounts reaped, as users could refund the address and try making transactions from it. The Balances +pallet provides a `transfer_keep_alive` function that will return an error and abort rather than +make the transfer if doing so would result in reaping the sender's account. + +> Note: The Statemint parachain has a lower existential deposit than the Relay Chain (0.1 DOT and +> 0.000003333 KSM) as well as lower transaction fees. It is highly recommended to handle balance +> transfers on Statemint. Statemint integration is discussed in the next page of the guide. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in +[`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). +Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in +staking and governance, for example. Reserved balance represents funds that have been set aside by +some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks +can operate on the same account, but they overlap rather than add. Locks are automatically added +onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these +are not customizable. For example, an account could have a free balance of 200 DOT with two locks on +it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a +transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT +such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases +over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, +however, see other extrinsics within the blocks that you decode. Find more information in the +[Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some +measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that +it is within some delta of their system clock. Inherents are not gossiped on the network, and only +block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay +a fee to have the transaction included on chain. Because the value of including signed transactions +on-chain can be recognized prior to execution, they can be gossiped on the network between nodes +with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or +Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For +example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, +the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash +checkpoint from which a transaction is valid and a validity period (also called "era" in some +places) that represents the number of blocks after the checkpoint for which the transaction is +valid. If the extrinsic is not included in a block within this validity window, it will be discarded +from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this +parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 +blocks (about four hours) at genesis. If the validity period is larger than the number of blocks +stored on-chain, then the transaction will only be valid as long as there is a block to check it +against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will +make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an +immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake +> that indexing services and custodians make. This error will cause major issues for your users. +> Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash +as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as +a fingerprint of the information within a transaction, and there are times when two transactions +with the same hash are both valid. In the case that one is invalid, the network properly handles the +transaction and does not charge a transaction fee to the sender nor consider the transaction in the +block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last +transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a +public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be +created from a public key account, but could also form from other means such as governance. These +origins do not have a nonce associated with them the way that an account does. For example, +governance might dispatch the same call with the same arguments multiple times, like “increase the +validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the +hash would be a reliable representative of the call, but its execution would have different effects +depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID +(height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of +extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a +transaction. This methodology is reflected in the Substrate codebase itself, for example to +[reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) +from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the +chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when +claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate +a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a +transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. +Make sure that you monitor events in each block for events that contain your addresses of interest. +Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a +"tip" to increase transaction priority during congested periods. See the +[transaction fee](../learn/learn-transaction-fees.md) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them +and interact directly with the chain data or implement your own codec, Polkadot encodes block and +transaction data using the +[SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Polkadot allows [runtime upgrades](../learn/learn-runtime-upgrades.md) without a hard fork. The runtime is a +Wasm binary stored on-chain and can be updated using your chain’s governance mechanism. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test +infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are +deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run +an archive node and listen for events and transactions to track all account activity. This +especially applies to _locking_ operations if you are calculating balance as the spendable balance, +i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted +except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order +to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a +long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms +like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/docs/build/build-smart-contracts.md b/docs/build/build-smart-contracts.md new file mode 100644 index 000000000000..caefcfd5fd51 --- /dev/null +++ b/docs/build/build-smart-contracts.md @@ -0,0 +1,101 @@ +--- +id: build-smart-contracts +title: Smart Contracts +sidebar_label: Smart Contracts +slug: ../build-smart-contracts +--- + +The Polkadot Relay Chain will not natively support smart contracts. However, parachains on Polkadot +will support smart contracts. There are already announced projects such as +[Edgeware](https://edgewa.re), and thanks to the Substrate built-in +[contract pallet](https://substrate.dev/rustdocs/latest/pallet_contracts/index.html), it is likely +that more parachains will support WebAssembly smart contracts. + +Additionally, there is the +[EVM Pallet](https://substrate.dev/docs/en/knowledgebase/smart-contracts/evm-pallet), which allows a +parachain to implement the Ethereum Virtual Machine, thereby supporting almost direct ports of +Ethereum contracts. Some of the projects using this approach are [Edgeware](https://edgewa.re), +[Moonbeam](https://moonbeam.network/) and [Frontier](https://github.com/paritytech/frontier). + +A video version of the recap of the smart contract situation on Polkadot and Kusama is available +[here](https://www.youtube.com/watch?v=fKHkFBXaUxQ). + +## Resources + +Here is the list of current resources available to developers who want to get started writing smart +contracts to deploy on parachains based on Substrate. + +- [Edgeware Contracts](https://contracts.edgewa.re) - Edgeware's documentation on Smart Contracts +- [ink!](https://github.com/paritytech/ink) - Parity's ink to write smart contracts. +- [Substrate Contracts Workshop](https://substrate.dev/substrate-contracts-workshop/#/) - a + walkthrough of the basics of writing and deploying an ERC20 token using `ink!`. + +## Examples + +Collected below are some community examples of smart contracts in `ink!`. **Are you working on a +smart contract example? Ask us to add it to this page!** + +- [Ownable](https://github.com/JesseAbram/foRust/) - Port of the OpenZeppelin `Ownable` contract. + +## Storage Rent + +Storage rent limits the footprint that a contract can have on the blockchain's storage. + +A contract deployed to the chain produces a code hash from which new instances of the chain can be +created, but there is currently no rent applied to the code hash itself. The rent applies only to +instances of this contract which have their own _contract accounts_. Deploying a code hash currently +has a one-time byte-fee applied to the transaction, but no recurring cost. + +An account of a contract instance is charged proportionally to the amount of storage its account +uses. When a contract's balance goes below a defined limit, the contract's account is turned into a +_tombstone_ (a hash of the contract's current state) and its storage is cleaned up. A tombstone +contract can be restored by providing the data that was cleaned up when it became a tombstone as +well as any additional funds needed to keep the contract alive. This fee will retroactively apply to +missed rent periods. + +Block producers or regular users of the chain can "poke" a smart contract if they think it ran out +of funds for rent. This will initiate the clean-up process and the _poker_ will get a finder's fee. + +## What is the difference between developing a smart contract versus a parachain? + +### Layer of Abstraction + +When you write a smart contract you are creating the instructions that will be deployed and +associated to a specific chain address. + +In comparison, a runtime module is the entire logic of a chain's state transitions (what's called a +state transition function). + +Smart contracts must consciously implement upgradeability while parachains will have the ability to +swap out their code entirely through a root command or via the governance pallet. + +When you build a smart contract, it will eventually be deployed to a target chain with its own +environment. Parachains allow the developer to declare the environment of their own chain, even +allowing others to write smart contracts for it. + +### Gas Fees + +Smart contracts must find a way to limit their own execution, or else full nodes are vulnerable to +DOS attacks. An infinite loop in a smart contract, for example, could consume the computational +resources of an entire chain, preventing others from using it. The +[halting problem](https://en.wikipedia.org/wiki/Halting_problem) shows that with a powerful enough +language, it is impossible to know ahead of time whether or not a program will ever cease execution. +Some platforms, such as Bitcoin, get around this constraint by providing a very restricted scripting +language. Others, such as Ethereum, "charge" the smart contract "gas" for the rights to execute +their code. If a smart contract does get into a state where execution will never halt, it eventually +runs out of gas, ceases execution, and any state transition that would have been made by the smart +contract is rolled back. Polkadot uses a _weight-fee model_ and not a _gas-metering model_. + +Parachains can implement arbitrarily powerful programming languages and also contain no notion of +gas for their own native logic. This means that some functionality is easier to implement for the +developer, but it also means there are some constructs, such as a loop without a terminating +condition, which should _never_ be implemented. Leaving certain logic, such as complex loops that +could possibly run indefinitely, to a non-smart contract layer, or even trying to eliminate it +entirely, will often be a wiser choice. Parachains try to be proactive, while smart contract +platforms are event-driven. + +## Resources + +- [When should I build a Substrate runtime versus a Substrate smart contract](https://stackoverflow.com/a/56041305) - + A technical standpoint that answers the question of when a developer might choose to develop a + runtime versus a smart contract. diff --git a/docs/build/build-ss58-registry.md b/docs/build/build-ss58-registry.md new file mode 100644 index 000000000000..8050be3d8c05 --- /dev/null +++ b/docs/build/build-ss58-registry.md @@ -0,0 +1,80 @@ +--- +id: build-ss58-registry +title: SS58 Registry +sidebar_label: SS58 Registry +slug: ../build-ss58-registry +--- + +Substrate-based chains, including the Polkadot and Kusama relay chains, use an +[SS58 encoding]() for +their address formats. This page serves as a registry for teams to see which chain corresponds to a +given prefix, and which prefixes are availabe. + +| Prefix | Network | Name | Symbols | Decimals | Standard Account | Website | +| ------ | --------------------- | ----------------------------------------------------- | ----------------------------------------- | ---------------------- | ---------------- | ----------------------------- | +| 0 | polkadot | Polkadot Relay Chain | DOT | 10 | \*25519 | https://polkadot.network | +| 1 | null | Bare 32-bit Schnorr/Ristretto (S/R 25519) public key. | null | null | null | null | +| 2 | kusama | Kusama Relay Chain | KSM | 12 | \*25519 | https://kusama.network | +| 3 | null | Bare 32-bit Ed25519 public key. | null | null | null | null | +| 4 | katalchain | Katal Chain | null | null | \*25519 | null | +| 5 | plasm | Plasm Network | PLM | 15 | \*25519 | https://plasmnet.io | +| 6 | bifrost | Bifrost | BNC | 12 | \*25519 | https://bifrost.finance/ | +| 7 | edgeware | Edgeware | EDG | 18 | \*25519 | https://edgewa.re | +| 8 | karura | Karura | KAR | 12 | \*25519 | https://karura.network/ | +| 9 | reynolds | Laminar Reynolds Canary | REY | 18 | \*25519 | http://laminar.network/ | +| 10 | acala | Acala | ACA | 12 | \*25519 | https://acala.network/ | +| 11 | laminar | Laminar | LAMI | 18 | \*25519 | http://laminar.network/ | +| 12 | polymesh | Polymesh | POLYX | 6 | \*25519 | https://polymath.network/ | +| 13 | substratee | SubstraTEE | null | null | \*25519 | https://www.substratee.com | +| 14 | totem | Totem | XTX | 0 | \*25519 | https://totemaccounting.com | +| 15 | synesthesia | Synesthesia | SYN | 12 | \*25519 | https://synesthesia.network/ | +| 16 | kulupu | Kulupu | KLP | 12 | \*25519 | https://kulupu.network/ | +| 17 | dark | Dark Mainnet | null | null | \*25519 | null | +| 18 | darwinia | Darwinia Network | RING, KTON | 9, 9 | \*25519 | https://darwinia.network/ | +| 19 | geek | GeekCash | GEEK | 12 | \*25519 | https://geekcash.org | +| 20 | stafi | Stafi | FIS | 12 | \*25519 | https://stafi.io | +| 21 | dock-testnet | Dock Testnet | DCK | 6 | \*25519 | https://dock.io | +| 22 | dock-mainnet | Dock Mainnet | DCK | 6 | \*25519 | https://dock.io | +| 23 | shift | ShiftNrg | null | null | \*25519 | null | +| 24 | zero | ZERO | PLAY | 18 | \*25519 | https://zero.io | +| 25 | zero-alphaville | ZERO Alphaville | PLAY | 18 | \*25519 | https://zero.io | +| 26 | jupiter | Jupiter | jDOT | 10 | \*25519 | https://jupiter.patract.io | +| 28 | subsocial | Subsocial | null | null | \*25519 | null | +| 29 | cord | Dhiway CORD Network | DCU | 18 | \*25519 | https://dhiway.com/ | +| 30 | phala | Phala Network | PHA | 12 | \*25519 | https://phala.network | +| 31 | litentry | Litentry Network | LIT | 12 | \*25519 | https://litentry.com/ | +| 32 | robonomics | Robonomics | XRT | 9 | \*25519 | https://robonomics.network | +| 33 | datahighway | DataHighway | null | null | \*25519 | null | +| 34 | ares | Ares Protocol | ARES | 12 | \*25519 | https://www.aresprotocol.com/ | +| 35 | vln | Valiu Liquidity Network | USDv | 15 | \*25519 | https://valiu.com/ | +| 36 | centrifuge | Centrifuge Chain | CFG | 18 | \*25519 | https://centrifuge.io/ | +| 37 | nodle | Nodle Chain | NODL | 18 | \*25519 | https://nodle.io/ | +| 38 | kilt | KILT Chain | KILT | 18 | \*25519 | https://kilt.io/ | +| 39 | mathchain | MathChain mainnet | MATH | 18 | \*25519 | https://mathwallet.org | +| 40 | mathchain-testnet | MathChain testnet | MATH | 18 | \*25519 | https://mathwallet.org | +| 41 | poli | Polimec Chain | null | null | \*25519 | https://polimec.io/ | +| 42 | substrate | Substrate | null | null | \*25519 | https://substrate.dev/ | +| 43 | null | Bare 32-bit ECDSA SECP-256k1 public key. | null | null | null | null | +| 44 | chainx | ChainX | PCX | 8 | \*25519 | https://chainx.org/ | +| 45 | uniarts | UniArts Network | UART, UINK | 12, 12 | \*25519 | https://uniarts.me | +| 46 | reserved46 | This prefix is reserved. | null | null | null | null | +| 47 | reserved47 | This prefix is reserved. | null | null | null | null | +| 48 | neatcoin | Neatcoin Mainnet | NEAT | 12 | \*25519 | https://neatcoin.org | +| 63 | hydradx | HydraDX | HDX | 12 | \*25519 | https://hydradx.io | +| 65 | aventus | AvN Mainnet | AVT | 18 | \*25519 | https://aventus.io | +| 66 | crust | Crust Network | CRU | 12 | \*25519 | https://crust.network | +| 67 | equilibrium | Equilibrium Network | Unknown, USD, EQ, ETH, BTC, EOS, DOT, CRV | 0, 9, 9, 9, 9, 9, 9, 9 | \*25519 | https://equilibrium.io | +| 69 | sora | SORA Network | XOR | 18 | \*25519 | https://sora.org | +| 73 | zeitgeist | Zeitgeist | ZTG | 10 | \*25519 | https://zeitgeist.pm | +| 77 | manta | Manta network | MA | 12 | \*25519 | https://manta.network | +| 78 | calamari | Calamari: Manta Canary Network | KMA | 12 | \*25519 | https://manta.network | +| 98 | polkasmith | PolkaSmith Canary Network | PKS | 18 | \*25519 | https://polkafoundry.com | +| 99 | polkafoundry | PolkaFoundry Network | PKF | 18 | \*25519 | https://polkafoundry.com | +| 101 | origintrail-parachain | OriginTrail Parachain | TRAC | 18 | secp256k1 | https://origintrail.io | +| 110 | heiko | Heiko | HKO | 12 | \*25519 | https://parallel.fi/ | +| 136 | altair | Altair | AIR | 18 | \*25519 | https://centrifuge.io/ | +| 172 | parallel | Parallel | PARA | 12 | \*25519 | https://parallel.fi/ | +| 252 | social-network | Social Network | NET | 18 | \*25519 | https://social.network | +| 1284 | moonbeam | Moonbeam | GLMR | 18 | secp256k1 | https://moonbeam.network | +| 1285 | moonriver | Moonriver | MOVR | 18 | secp256k1 | https://moonbeam.network | +| 10041 | basilisk | Basilisk | BSX | 12 | \*25519 | https://bsx.fi | diff --git a/docs/build-tools-index.md b/docs/build/build-tools-index.md similarity index 99% rename from docs/build-tools-index.md rename to docs/build/build-tools-index.md index e1ac615b1386..6cad1eecb001 100644 --- a/docs/build-tools-index.md +++ b/docs/build/build-tools-index.md @@ -2,13 +2,12 @@ id: build-tools-index title: Tool Index sidebar_label: Tool Index +slug: ../build-tools-index --- - - Here we provide a list of tools available for your development needs. They are sorted by context. If you're actively maintaining a tool that might be useful to other Polkadot, Kusama or Substrate -developers, feel free to [add it in](contributing). +developers, feel free to [add it in](../general/contributing.md). ## Block Explorers diff --git a/docs/build/build-transaction-construction.md b/docs/build/build-transaction-construction.md new file mode 100644 index 000000000000..09d5048556d1 --- /dev/null +++ b/docs/build/build-transaction-construction.md @@ -0,0 +1,221 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +slug: ../build-transaction-construction +--- + + + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast +transactions. Like the other pages in this guide, this page demonstrates some of the available +tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info.md#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info.md#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. + If zero, the transaction is [immortal](build-protocol-info.md#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track +and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` +function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for +interacting with a Substrate client, including one called "Signer CLI" to create, sign, and +broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The +`signer sendOffline` command has the exact same API, but will not broadcast the transaction. +`submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a +valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to +`15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use +your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s +signature field, and send the transaction (or just return the serialized transaction if using +`sendOffline`). + +## Tx Wrapper Polkadot + +If you do not want to use the CLI for signing operations, Parity provides an SDK called +[TxWrapper Core](https://github.com/paritytech/txwrapper-core) to generate and sign transactions +offline. For Polkadot, Kusama, and select parachains, use the `txwrapper-polkadot` package. Other +Substrate-based chains will have their own `txwrapper-{chain}` implementations. See the +[examples](https://github.com/paritytech/txwrapper-core/blob/main/packages/txwrapper-examples/README.md) +for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper-polkadot'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper-polkadot'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper-polkadot"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper-polkadot'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper-polkadot"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper-core/blob/b213cabf50f18f0fe710817072a81596e1a53cae/packages/txwrapper-core/src/test-helpers/signWithAlice.ts +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper-polkadot"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper-polkadot’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or + `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified + as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See +[Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/docs/build/build-wallets.md b/docs/build/build-wallets.md new file mode 100644 index 000000000000..b7b6654c89f4 --- /dev/null +++ b/docs/build/build-wallets.md @@ -0,0 +1,41 @@ +--- +id: build-wallets +title: Polkadot Wallets +sidebar_label: Polkadot Wallets +slug: ../build-wallets +--- + +## Polkadot Wallets + +The integration of a [wallet](../general/glossary.md#wallet) with Polkadot allows for simple and easy access to +private keys and signing transactions. Below are some wallets that support Polkadot along with their +development statuses. + +[Polkadot support](https://support.polkadot.network/) can provide assistance with issues related to +Polkadot-JS, the Polkadot{.js} extension, or Parity Signer. For other wallet software, you should +contact the developers of that wallet. + +> Note that only Parity-developed wallets are listed on this page. Other third-party wallets are +> available, but are not listed here. + +## Encryption Enhancement + +Some newly generated `JSON` account files cannot be imported (restored) into older wallet software. +This is due to an enhanced encryption method, which is also noticeable in a slight delay when +encrypting/decrypting your wallet. If you are unable to load a `JSON` file, please ensure that you +are using the latest version of the wallet software. If you are still unable to load it, ensure that +the wallet software is using the latest version of the [Polkadot API](https://polkadot.js.org/api/). + +### Supported Wallets + +| Wallet Name | Development State | Team Name | Description | Custody | Supports | +| ------------------------------------------------------------------- | ----------------- | --------- | ----------------- | ------------- | -------- | +| [Parity Signer](https://www.parity.io/signer/) (see warning below) | Live | Parity | iOS and Android | Non-custodial | Staking | +| [Polkadot-js Desktop](https://github.com/polkadot-js/apps/releases) | Live | Parity | Win, Mac, Linux | Non-custodial | Staking | +| [Polkadot-js extension](https://github.com/polkadot-js/extension) | Live | Parity | Browser extension | Non-custodial | Staking | +| [Polkadot-js apps](https://polkadot.js.org/apps/#/accounts) | Live | Parity | Browser | Non-Custodial | Staking | + +> Warning: Parity Signer currently does not allow you to see the transaction you are signing. This +> means that you are at risk if connected to a compromised version of Polkadot-JS. A fix is being +> worked on; please see [this GitHub issue](https://github.com/paritytech/parity-signer/issues/724) +> for more details. diff --git a/docs/claims.md b/docs/claims.md deleted file mode 100644 index 56180171789b..000000000000 --- a/docs/claims.md +++ /dev/null @@ -1,266 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT -tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract -on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms -and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and -attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the -[making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims -period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough -> [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) -> and our video on -> [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT -tokens after genesis. There is no time limit for making your claim so feel free to do this whenever -you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT -> allocation. The two actions, "claim" and "attest", are done in a single transaction, but for the -> most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's -prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum -account. Go to their downloads page and ensure that you download the latest version for your -operating system. This is important because the latest version will always have the latest security -patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always -> find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the [account -generation][] page for generating a new Polkadot account. - -You can use the [claims guide](https://claims.polkadot.network/) to claim DOT that were purchased in -the form of DOT Allocation Indicators on Ethereum before June 30, 2020. These steps are broken down -in the remaining sections of this page. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in -case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware -device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity -signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for -maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the -account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your -screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens -that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the -hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the -Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. -Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account -that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI -immediately. - -Having trouble? Get support in the DOT [Claims Support][] channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot -recommend using any third party apps to do so. Manually specifying your transaction data, as -specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your -Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once -you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in -some way. One way would be to go to the Accounts page and "create" a new account, replacing the -generated seed or mnemonic with the one belonging to your account. The other way is by using the -Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than -entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the -left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that -tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS -that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you -don't see a notification or don't see the selector, please double check that the account has been -loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel -free to reach out for help in the [Claims Support][] channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the -transaction is included in the block, you will see a green success box appear in the upper right -corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. -All operations will use Parity Signer to sign the transaction, but will broadcast it via the -Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions -on the Parity Signer section in the [account generation][] page for generating a new Polkadot -account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to -the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the -Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of -addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large -notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. -If you don't see a notification or don't see the selector, please double check that the account has -been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As -always, feel free to reach out for help in the [Claims Support][] channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on -the authorize transaction window to generate the raw transaction. Next, you may be required to input -the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code -to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper -right corner and the DOT will be in your account. - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[claims app]: https://polkadot.js.org/apps/#/claims -[claims support]: - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io diff --git a/docs/community.md b/docs/community.md deleted file mode 100644 index b300fc2bad38..000000000000 --- a/docs/community.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -id: community -title: Community -sidebar_label: Community ---- - -The Polkadot community is expanding every day. Below are the most essential links to the community -channels. Keep in mind that no admin or moderator will ever DM you for any reason whatsoever without -prior contact and anyone doing so is likely trying to scam you. - -## General - -- [Polkadot GitHub](https://github.com/paritytech/polkadot/) - Parity maintained repository that - houses the Rust implementation of the Polkadot Host. -- [Polkadot Meetup Hub](https://www.notion.so/web3foundation/Polkadot-Meetup-Hub-4511c156770e4ba9936386d8be5fe5be) - - Information on hosting meetups, applying for funding, and materials for running it. -- [Polkadot Support Knowledgebase](https://support.polkadot.network/support/home) and - [Polkadot Support Email](mailto:support@polkadot.network) -- [Polkadot's Latest Research](https://research.web3.foundation/en/latest/polkadot/) - -### Events - -The Web3 Foundation hosts many events online and in-person. To check out our current and past -events, please refer to our public -[Notion page here](https://www.notion.so/Public-Events-Database-fdd2df4c29d04818a5dd403e2b85920d). - -## Matrix Chats - -We primarily use [Matrix](https://matrix.org) across the organization and to communicate with -community members. The application we use most often to interact with the Matrix protocol is the -[Element](https://app.element.io) messenger. - -- This wiki's public Matrix room is - [here](https://app.element.io/#/room/!nAtXmWUBTeFqgSKGgp:web3.foundation?via=web3.foundation). - -### Polkadot - -- [Polkadot Watercooler Chat](https://app.element.io/#/room/!FdCojkeGzZLSEoiecf:web3.foundation?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - - General room for talk about Polkadot. -- [Polkadot Validator Lounge](https://app.element.io/#/room/#polkadot-validator-lounge:matrix.org) - - Room for validators learning about setting up a node. -- [Polkadot Direction](https://app.element.io/#/room/!OwgojQyBzTlUQGGLhq:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - - Governance, and a place to discuss the future of Polkadot. -- [Polkadot Digest](https://matrix.to/#/!vMpYyTkvjXcevxSdsQ:web3.foundation) - News about what is - happening in the Polkadot ecosystem, published every weekday except holidays - -### Kusama - -- [Kusama Watercooler Chat](https://app.element.io/#/room/%23kusamawatercooler:polkadot.builders) - - General room for talk about Kusama. -- [Kusama Validator Lounge](https://app.element.io/#/room/!LhjZccBOqFNYKLdmbb:polkadot.builders?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - - Room for validators learning about setting up a node. -- [Kusama Direction](https://app.element.io/#/room/!QXMnIJzxlnVrvRzhUA:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - - Governance, and a place to discuss the future of Kusama. - -### Technical - -- [Substrate Technical](https://app.element.io/#/room/#substrate-technical:matrix.org) - More - advanced room for technical questions on building with Substrate. -- [Smart Contracts & Parity Ink!](https://app.element.io/#/room/!tYUCYdSvSYPMjWNDDD:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - - A room to discuss developing Substrate smart contracts using Parity Ink! - -## Socials - -### Chat - -- [Polkadot Discord](https://discord.gg/wGUDt2p) (RECOMMENDED) -- [Kusama Discord](https://discord.gg/JSJcRwz8fp) - -### Social media and forums - -- [Polkadot Twitter](https://twitter.com/Polkadot) -- [Kusama Twitter](https://twitter.com/kusamanetwork) -- [Web3 Foundation Twitter](https://twitter.com/web3foundation) - -- [Polkadot Reddit](https://www.reddit.com/r/polkadot) -- [Kusama Reddit](https://www.reddit.com/r/Kusama) - -- [Web3 Foundation YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) -- [Polkadot YouTube](https://www.youtube.com/channel/UCB7PbjuZLEba_znc7mEGNgw) -- [Kusama YouTube Channel](http://youtube.com/c/kusamanetwork) - -- [Polkadot Forum](https://forum.polkadot.network) -- [Kusama Forum](https://forum.kusama.network) - -### Blogs and tutorials - -- [Web3 Medium Blog](https://medium.com/@web3) -- [Polkadot Blog](https://polkadot.network/blog/) -- [Gavin Wood's Medium Blog](https://medium.com/@gavofyork) -- [Dotleap.com Tutorials](https://dotleap.com) - -### Newsletters - -- [Subscribe to the Polkadot newsletter](https://share.hsforms.com/1LL1CBwiASxC5pJUYZAiDVw4752a) - - official, infrequent -- [Dot Leap Newsletter](https://dotleap.substack.com/) - less official, weekly - -## Ecosystem - -- [Teams Building on Polkadot](https://polkaproject.com/) - Community maintained list of teams - building on Polkadot and/or Substrate. (Note that this may contain inaccuracies, as it's - unofficial) -- [Polkadot Stack](https://github.com/w3f/General-Grants-Program/blob/master/grants/polkadot_stack.md) - - if you're interested in seeing what's under development and where there's room for your - contributions. diff --git a/docs/contributing.md b/docs/contributing.md deleted file mode 100644 index b4b037a0167f..000000000000 --- a/docs/contributing.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -id: contributing -title: Contributing -sidebar_label: Contributing ---- - -The wiki was started and is maintained by the Web3 Foundation. It is an open source project and aims -to be the most extensive resource of knowledge on Polkadot and the Polkadot ecosystem. A large part -of the material currently focuses on Polkadot directly but it is not opposed to covering -informational material for community projects. - -**Please do not try to pull request any marketing material as this will be rejected.** - -Nonetheless, pull requests, discussions, and contributions from the community are encouraged. Active -community members who demonstrate a record of good contributions may be given write access to the -repository. - -Otherwise, Web3 Foundation holds the administrative position and final say on the content that is -included. Specifically, the Technical Education team at the foundation are most directly involved. - -> Check out the -> [How to Contribute to the Polkadot Wiki](https://www.youtube.com/watch?v=6i55KOcy7B0) video for -> steps on contributions. - -## How to Contribute - -You can contribute to the wiki on the -[w3f/polkadot-wiki GitHub repository](https://github.com/w3f/polkadot-wiki). Every page is a -[MarkDown](https://guides.github.com/features/mastering-markdown/) file, which is an easy to learn -syntax extension to plain text that makes creating links, rendering images, and nice-looking -formatting simple. - -Each page has an "Edit this page" link at the bottom of the content. By clicking it you are taken to -the GitHub sign-in page, where you can either log in or create an account. - -Once logged in, you'll be taken to the GitHub built-in text editor where you can make your edits -directly. When you've completed your changes, you can add any specific details on what was changed -and commit to a **new branch** to create a new Pull Request to the repository. From there one of the -maintainers will review your changes, and either merge them or request changes. - -![](./assets/contributing.png) ![](./assets/creating-pull-request.png) - -Remember that after you click "Propose Changes", you must also click on "Create Pull Request" on the -next page. - -![](./assets/creating-pull-request-2.png) - -## Rules - -There are a few basic ground-rules for contributors: - -1. **No `--force` pushes** or modifying the Git history in any way. -2. Pull requests are preferred to issues, especially for small changes such as typos. Issues should - be used for generic or broad-based changes or missing content. Suggestions and requests are - encouraged. -3. Only use **non-master branches**. -4. **Significant modifications**, even by contributors, ought to be subject to a **pull request** to - solicit feedback from other contributors. -5. Pull requests to solicit feedback are _encouraged_ for any other non-trivial contribution but - left to the discretion of the contributor. -6. Contributors should attempt to adhere to the prevailing `MarkDown` style, language, and layout. -7. Correct grammar should be used at all times. Pull requests with typos will not be merged until - fixed. -8. Care should be taken to remain as objective and informative as possible. There should be no - editorializing, and external bias should not be present. -9. We use a plugin called Prettier to standardize the style across documents. You can run this on - your local copy with `npx pretty-quick --staged`, but for simplicity we also have a bot which - runs this for us in your PRs. - -## Heritage - -This document is based on the -[Level contribution guidelines](https://github.com/Level/community/blob/master/CONTRIBUTING.md). diff --git a/docs/ambassadors.md b/docs/general/ambassadors.md similarity index 98% rename from docs/ambassadors.md rename to docs/general/ambassadors.md index d9f4f8ef576b..e54d0d52443a 100644 --- a/docs/ambassadors.md +++ b/docs/general/ambassadors.md @@ -2,6 +2,7 @@ id: ambassadors title: Polkadot Ambassador Programme sidebar_label: Polkadot Ambassador Programme +slug: ../ambassadors --- The Polkadot Ambassador Programme is an initiative ran by the Web3 Foundation to support potential diff --git a/docs/general/claims.md b/docs/general/claims.md new file mode 100644 index 000000000000..e0f03fc576a0 --- /dev/null +++ b/docs/general/claims.md @@ -0,0 +1,266 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +slug: ../claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT +tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract +on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms +and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and +attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the +[making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims +period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough +> [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) +> and our video on +> [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT +tokens after genesis. There is no time limit for making your claim so feel free to do this whenever +you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT +> allocation. The two actions, "claim" and "attest", are done in a single transaction, but for the +> most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's +prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum +account. Go to their downloads page and ensure that you download the latest version for your +operating system. This is important because the latest version will always have the latest security +patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always +> find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the [account +generation][] page for generating a new Polkadot account. + +You can use the [claims guide](https://claims.polkadot.network/) to claim DOT that were purchased in +the form of DOT Allocation Indicators on Ethereum before June 30, 2020. These steps are broken down +in the remaining sections of this page. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in +case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware +device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity +signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for +maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the +account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your +screen should look something like this: + +![claim-1](../assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens +that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](../assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](../assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the +hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](../assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](../assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](../assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](../assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the +Polkadot-JS UI and click "Confirm Claim." + +![claim-7](../assets/new-claims/claim-7.jpg) ![claim-8](../assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. +Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](../assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account +that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI +immediately. + +Having trouble? Get support in the DOT [Claims Support][] channel. + +![claim-10](../assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot +recommend using any third party apps to do so. Manually specifying your transaction data, as +specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your +Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once +you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in +some way. One way would be to go to the Accounts page and "create" a new account, replacing the +generated seed or mnemonic with the one belonging to your account. The other way is by using the +Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than +entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the +left navigation drawer. + +![claim-attest-1](../assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that +tells you that you need to sign an attestation. + +![claim-attest-2](../assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS +that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you +don't see a notification or don't see the selector, please double check that the account has been +loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel +free to reach out for help in the [Claims Support][] channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](../assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](../assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the +transaction is included in the block, you will see a green success box appear in the upper right +corner and the DOT will be in your account. + +![claim-attest-5](../assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. +All operations will use Parity Signer to sign the transaction, but will broadcast it via the +Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions +on the Parity Signer section in the [account generation][] page for generating a new Polkadot +account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to +the Accounts page first. + +### Make the Attestation + +![ps-claim-1](../assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](../assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](../assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](../assets/new-claims/ps-02.jpg) + +![ps-3](../assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the +Polkadot-JS Apps can decode it. + +![ps-claim-3](../assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of +addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large +notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. +If you don't see a notification or don't see the selector, please double check that the account has +been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As +always, feel free to reach out for help in the [Claims Support][] channel. + +![ps-claim-5](../assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](../assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](../assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](../assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on +the authorize transaction window to generate the raw transaction. Next, you may be required to input +the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code +to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](../assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper +right corner and the DOT will be in your account. + +[mycrypto]: https://download.mycrypto.com/ +[account generation]: ../learn/learn-account-generation.md +[claims app]: https://polkadot.js.org/apps/#/claims +[claims support]: https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io diff --git a/docs/general/community.md b/docs/general/community.md new file mode 100644 index 000000000000..18b7352ce60c --- /dev/null +++ b/docs/general/community.md @@ -0,0 +1,107 @@ +--- +id: community +title: Community +sidebar_label: Community +slug: ../community +--- + +The Polkadot community is expanding every day. Below are the most essential links to the community +channels. Keep in mind that no admin or moderator will ever DM you for any reason whatsoever without +prior contact and anyone doing so is likely trying to scam you. + +## General + +- [Polkadot GitHub](https://github.com/paritytech/polkadot/) - Parity maintained repository that + houses the Rust implementation of the Polkadot Host. +- [Polkadot Meetup Hub](https://www.notion.so/web3foundation/Polkadot-Meetup-Hub-4511c156770e4ba9936386d8be5fe5be) - + Information on hosting meetups, applying for funding, and materials for running it. +- [Polkadot Support Knowledgebase](https://support.polkadot.network/support/home) and + [Polkadot Support Email](mailto:support@polkadot.network) +- [Polkadot's Latest Research](https://research.web3.foundation/en/latest/polkadot/) + +### Events + +The Web3 Foundation hosts many events online and in-person. To check out our current and past +events, please refer to our public +[Notion page here](https://www.notion.so/Public-Events-Database-fdd2df4c29d04818a5dd403e2b85920d). + +## Matrix Chats + +We primarily use [Matrix](https://matrix.org) across the organization and to communicate with +community members. The application we use most often to interact with the Matrix protocol is the +[Element](https://app.element.io) messenger. + +- This wiki's public Matrix room is + [here](https://app.element.io/#/room/!nAtXmWUBTeFqgSKGgp:web3.foundation?via=web3.foundation). + +### Polkadot + +- [Polkadot Watercooler Chat](https://app.element.io/#/room/!FdCojkeGzZLSEoiecf:web3.foundation?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - + General room for talk about Polkadot. +- [Polkadot Validator Lounge](https://app.element.io/#/room/#polkadot-validator-lounge:matrix.org) - + Room for validators learning about setting up a node. +- [Polkadot Direction](https://app.element.io/#/room/!OwgojQyBzTlUQGGLhq:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - + Governance, and a place to discuss the future of Polkadot. +- [Polkadot Digest](https://matrix.to/#/!vMpYyTkvjXcevxSdsQ:web3.foundation) - News about what is + happening in the Polkadot ecosystem, published every weekday except holidays + +### Kusama + +- [Kusama Watercooler Chat](https://app.element.io/#/room/%23kusamawatercooler:polkadot.builders) - + General room for talk about Kusama. +- [Kusama Validator Lounge](https://app.element.io/#/room/!LhjZccBOqFNYKLdmbb:polkadot.builders?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - + Room for validators learning about setting up a node. +- [Kusama Direction](https://app.element.io/#/room/!QXMnIJzxlnVrvRzhUA:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - + Governance, and a place to discuss the future of Kusama. + +### Technical + +- [Substrate Technical](https://app.element.io/#/room/#substrate-technical:matrix.org) - More + advanced room for technical questions on building with Substrate. +- [Smart Contracts & Parity Ink!](https://app.element.io/#/room/!tYUCYdSvSYPMjWNDDD:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - + A room to discuss developing Substrate smart contracts using Parity Ink! + +## Socials + +### Chat + +- [Polkadot Discord](https://discord.gg/wGUDt2p) (RECOMMENDED) +- [Kusama Discord](https://discord.gg/JSJcRwz8fp) + +### Social media and forums + +- [Polkadot Twitter](https://twitter.com/Polkadot) +- [Kusama Twitter](https://twitter.com/kusamanetwork) +- [Web3 Foundation Twitter](https://twitter.com/web3foundation) + +- [Polkadot Reddit](https://www.reddit.com/r/polkadot) +- [Kusama Reddit](https://www.reddit.com/r/Kusama) + +- [Web3 Foundation YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) +- [Polkadot YouTube](https://www.youtube.com/channel/UCB7PbjuZLEba_znc7mEGNgw) +- [Kusama YouTube Channel](http://youtube.com/c/kusamanetwork) + +- [Polkadot Forum](https://forum.polkadot.network) +- [Kusama Forum](https://forum.kusama.network) + +### Blogs and tutorials + +- [Web3 Medium Blog](https://medium.com/@web3) +- [Polkadot Blog](https://polkadot.network/blog/) +- [Gavin Wood's Medium Blog](https://medium.com/@gavofyork) +- [Dotleap.com Tutorials](https://dotleap.com) + +### Newsletters + +- [Subscribe to the Polkadot newsletter](https://share.hsforms.com/1LL1CBwiASxC5pJUYZAiDVw4752a) - + official, infrequent +- [Dot Leap Newsletter](https://dotleap.substack.com/) - less official, weekly + +## Ecosystem + +- [Teams Building on Polkadot](https://polkaproject.com/) - Community maintained list of teams + building on Polkadot and/or Substrate. (Note that this may contain inaccuracies, as it's + unofficial) +- [Polkadot Stack](https://github.com/w3f/General-Grants-Program/blob/master/grants/polkadot_stack.md) - + if you're interested in seeing what's under development and where there's room for your + contributions. diff --git a/docs/general/contributing.md b/docs/general/contributing.md new file mode 100644 index 000000000000..2ce334a38c9c --- /dev/null +++ b/docs/general/contributing.md @@ -0,0 +1,73 @@ +--- +id: contributing +title: Contributing +sidebar_label: Contributing +slug: ../contributing +--- + +The wiki was started and is maintained by the Web3 Foundation. It is an open source project and aims +to be the most extensive resource of knowledge on Polkadot and the Polkadot ecosystem. A large part +of the material currently focuses on Polkadot directly but it is not opposed to covering +informational material for community projects. + +**Please do not try to pull request any marketing material as this will be rejected.** + +Nonetheless, pull requests, discussions, and contributions from the community are encouraged. Active +community members who demonstrate a record of good contributions may be given write access to the +repository. + +Otherwise, Web3 Foundation holds the administrative position and final say on the content that is +included. Specifically, the Technical Education team at the foundation are most directly involved. + +> Check out the +> [How to Contribute to the Polkadot Wiki](https://www.youtube.com/watch?v=6i55KOcy7B0) video for +> steps on contributions. + +## How to Contribute + +You can contribute to the wiki on the +[w3f/polkadot-wiki GitHub repository](https://github.com/w3f/polkadot-wiki). Every page is a +[MarkDown](https://guides.github.com/features/mastering-markdown/) file, which is an easy to learn +syntax extension to plain text that makes creating links, rendering images, and nice-looking +formatting simple. + +Each page has an "Edit this page" link at the bottom of the content. By clicking it you are taken to +the GitHub sign-in page, where you can either log in or create an account. + +Once logged in, you'll be taken to the GitHub built-in text editor where you can make your edits +directly. When you've completed your changes, you can add any specific details on what was changed +and commit to a **new branch** to create a new Pull Request to the repository. From there one of the +maintainers will review your changes, and either merge them or request changes. + +![](../assets/contributing.png) ![](../assets/creating-pull-request.png) + +Remember that after you click "Propose Changes", you must also click on "Create Pull Request" on the +next page. + +![](../assets/creating-pull-request-2.png) + +## Rules + +There are a few basic ground-rules for contributors: + +1. **No `--force` pushes** or modifying the Git history in any way. +2. Pull requests are preferred to issues, especially for small changes such as typos. Issues should + be used for generic or broad-based changes or missing content. Suggestions and requests are encouraged. +3. Only use **non-master branches**. +4. **Significant modifications**, even by contributors, ought to be subject to a **pull request** to + solicit feedback from other contributors. +5. Pull requests to solicit feedback are _encouraged_ for any other non-trivial contribution but + left to the discretion of the contributor. +6. Contributors should attempt to adhere to the prevailing `MarkDown` style, language, and layout. +7. Correct grammar should be used at all times. Pull requests with typos will not be merged until + fixed. +8. Care should be taken to remain as objective and informative as possible. There should be no + editorializing, and external bias should not be present. +9. We use a plugin called Prettier to standardize the style across documents. You can run this on + your local copy with `npx pretty-quick --staged`, but for simplicity we also have a bot which + runs this for us in your PRs. + +## Heritage + +This document is based on the +[Level contribution guidelines](https://github.com/Level/community/blob/master/CONTRIBUTING.md). diff --git a/docs/contributors.md b/docs/general/contributors.md similarity index 97% rename from docs/contributors.md rename to docs/general/contributors.md index 77275e5a2348..f14105979569 100644 --- a/docs/contributors.md +++ b/docs/general/contributors.md @@ -2,6 +2,7 @@ id: contributors title: Contributors sidebar_label: Contributors +slug: ../contributors --- ## Current Contributors @@ -13,7 +14,7 @@ and then feel free to get in touch with someone else on this list to verify the original inquiry. **Employee impersonation is a very common type of scam**. > For other ways of protecting yourself, please see -> [How to Protect Yourself from Scams](learn-scams). +> [How to Protect Yourself from Scams](scams.md). --- @@ -107,10 +108,10 @@ contribute to Web3 Foundation's vision by educating professionals and the genera - email: [alexander@web3.foundation](mailto:alexander@web3.foundation) - matrix / riot / element: [@alexander:web3.foundation](https://matrix.to/#/@alexander:web3.foundation) -Alex is a Technical Education Intern at the Web3 Foundation. He is preparing to receive his Computer Science B.S. +Alex is a Technical Education Intern at the Web3 Foundation. He is preparing to receive his Computer Science B.S. from San Francisco State University. Outside of his formal education, Alex has developed a deep passion for educating others -on decentralized systems and pushing forward the Web 3.0 vision. He has educational experience in cryptography, data privacy, -and enterprise security. +on decentralized systems and pushing forward the Web 3.0 vision. He has educational experience in cryptography, data privacy, +and enterprise security.

diff --git a/docs/ens.md b/docs/general/ens.md similarity index 91% rename from docs/ens.md rename to docs/general/ens.md index 94de84cc1ef9..eee5cd4eac65 100644 --- a/docs/ens.md +++ b/docs/general/ens.md @@ -2,6 +2,7 @@ id: ens title: Adding accounts to an ENS domain sidebar_label: Using ENS with DOT/KSM accounts +slug: ../ens --- ENS (Ethereum Name Service) is a distributed and open system of smart contracts on the Ethereum @@ -36,21 +37,21 @@ This guide is also available in video format [on Youtube](https://youtu.be/XKjZk The [ENS App](https://app.ens.domains) allows an ENS domain owner to inspect all records bound to the domain, and to add new ones. -![bruno.eth domain name in the ENS application](assets/ens/01-min.png) +![bruno.eth domain name in the ENS application](../assets/ens/01-min.png) In the example above, the domain `bruno.eth` has an Ethereum and a Bitcoin address attached. Let's attach a KSM account. First, click the `[+]` icon in the Records tab. -![The plus icon in the records tab](assets/ens/02-min.png) +![The plus icon in the records tab](../assets/ens/02-min.png) Then, pick "Other Addresses", "KSM", and input the Kusama address: -![Inputs needed to register a KSM address](assets/ens/03-min.png) +![Inputs needed to register a KSM address](../assets/ens/03-min.png) After clicking Save, your Ethereum wallet will ask you to confirm a transaction. Once processed, the record will show up on the domain's page: -![KSM address now visible in bruno.eth records](assets/ens/04-min.png) +![KSM address now visible in bruno.eth records](../assets/ens/04-min.png) The same process applies to adding your DOT address. diff --git a/docs/faq.md b/docs/general/faq.md similarity index 95% rename from docs/faq.md rename to docs/general/faq.md index b95345e702a7..fcd28996cf8e 100644 --- a/docs/faq.md +++ b/docs/general/faq.md @@ -2,6 +2,7 @@ id: faq title: Frequently Asked Questions (FAQs) sidebar_label: Frequently Asked Questions (FAQs) +slug: ../faq --- _This FAQ focuses on technical questions for users interested in developing applications for @@ -43,12 +44,12 @@ There is no central authority that decides on validators, so there is not per se that you can fill out. Registering as a validator is permissionless; in order to become one you must only set up a validator node and mark your intention to validate on chain. For detailed instruction on how to do this you can consult the -[Kusama validator guide](maintain-guides-how-to-validate-kusama.md) on validating for Kusama or the -[Polkadot validator guide](maintain-guides-how-to-validate-polkadot.md) for validating on Polkadot. +[Kusama validator guide](../maintain/kusama/maintain-guides-how-to-validate-kusama.md) on validating for Kusama or the +[Polkadot validator guide](../maintain/maintain-guides-how-to-validate-polkadot.md) for validating on Polkadot. However, once you've set up a validator and have registered your intention it does not mean that you will be included in the _active set_ right away. The validators are elected to the active set based -on the results of an election algorithm known as [Phragmén's method](learn-phragmen.md). Phragmén's +on the results of an election algorithm known as [Phragmén's method](../learn/learn-phragmen.md). Phragmén's method tries to accomplish two goals: 1) select `n` members from a larger set based on stake-weighted votes and 2) equalize the stake backing each validator as much as possible. @@ -62,7 +63,7 @@ validators if they apply and fit the requirements. Validators are rewarded from the inflation of the Relay Chain, transaction fees, and tips. However, they only take a percentage of the former two. More details can be read on the page for -[validator payouts](maintain-guides-validator-payout.md). +[validator payouts](../maintain/maintain-guides-validator-payout.md). ### What is the minimum stake necessary to be elected as an active validator? @@ -110,7 +111,7 @@ Chain, voting on finality, producing blocks in their decided slots, and verifyin transitions. Other projects may consider validators and "validating nodes" as separate entities. Finally, individuals may participate in the block production process indirectly by -[nominating](learn-nominator.md) validators. In this way, individuals who are not running a node can +[nominating](../learn/learn-nominator.md) validators. In this way, individuals who are not running a node can still share in staking rewards. ## Relay Chain @@ -164,7 +165,7 @@ The inflation rate is approximately 10% per year. A portion of the inflation is rewarded to validators for performing their duties, while another portion may go directly to the treasury. The exact percentage that goes into both varies and is based on the amount of DOT that are staked. Please see the article on -[inflation](learn-staking.md/#inflation) for more information. +[inflation](../learn/learn-staking.md/#inflation) for more information. ## Governance @@ -199,7 +200,7 @@ determined minority to overrule the vote of an apathetic majority in certain sit mechanism is known as Adaptive Quorum Biasing. This makes proposals have a varying threshold for approval or rejection based on what part of the governance protocol the proposal originated in. For details on the subtleties of Polkadot's governance system, please see the -[governance page](learn-governance.md). +[governance page](../learn/learn-governance.md). ## Parachains @@ -223,8 +224,8 @@ blocks when their usage and throughput makes it necessary. When a parachain loses an auction for renewal, that parachain has a few options. In most cases, becoming a parathread instead would be a suitable choice. Parathreads are still secured by the Relay Chain, but don't need to hold a parachain slot and can produce a block when its economically -feasible for them. For more on parachains please see the [parachains page](learn-parachains.md) and -for more on parathreads see [the parathreads page](learn-parathreads.md). +feasible for them. For more on parachains please see the [parachains page](../learn/learn-parachains.md) and +for more on parathreads see [the parathreads page](../learn/learn-parathreads.md). ## Networking @@ -270,7 +271,7 @@ integration between the two applications. ### What is the minimum amount of KSM / DOT I can have in my account? -Please see information about [Existential Deposits](build-protocol-info.md/#existential-deposit). +Please see information about [Existential Deposits](../build/build-protocol-info.md). ### What are the transfer fees for Kusama? diff --git a/docs/general/getting-started.md b/docs/general/getting-started.md new file mode 100644 index 000000000000..3f513dd372c4 --- /dev/null +++ b/docs/general/getting-started.md @@ -0,0 +1,182 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +slug: ../getting-started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the +core functionality. Our wiki has three main sections: Learn (for learners), Build (for people that +want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a +secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less +networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet +where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has +an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) +standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your +growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the +> [Governance page](../learn/learn-governance.md) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users +control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet +featured read-only, static, basic webpages. The online connected world at the time was only the +beginning of virtual data, identities, and more. The internet during this time was also called the +Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the +Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, +where users can read and write information plus publish their own for others to see. However, this +version of the web comes with downsides, dealing with data control, privacy issues, and trust. This +is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free +protocols. The goal is to transform the internet into a decentralized web, where users control their +own data and identity in a trust-free environment. The Web 3.0 movement aims to remove +intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the +> [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a +[sharded model]() where shards - called +"[parachains](../learn/learn-parachains.md)", allow transactions to be processed in parallel instead of +sequentially. Each parachain in the network has a unique state transition function (STF). Polkadot +has a Relay Chain acting as the main chain of the system. Based on Polkadot's design, as long as a +chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the +Polkadot network as a parachain. + +Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo +rigorous [availability and validity](../learn/learn-availability.md) checks before being added to the +finalized chain. As the Relay Chain provides the security guarantees, +[collators](../learn/learn-collator.md) - full nodes of these parachains - don't have any security +responsibilities, and thus do not require a robust incentive system. This is how the entire network +stays up to date with the many transactions that take place. + +![polkadot-relay-chain](../assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), +Polkadot has [bridge parachains](../learn/learn-bridges.md) that offer two-way compatibility, meaning that +transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](../learn/learn-crosschain.md) allows parachains to send messages +of any type to each other. The shared security and validation logic of the Relay Chain provide the +environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our +> [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of +[Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a +platform for everyone. This wiki offers a place for builders and maintainers to utilize +[tools](../build/build-tools-index.md) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to start familiarizing + yourself with blockchain concepts such as cryptography and networks, and how these play into + things like decentralization and cryptocurrency. + +This is recommended for users with backgrounds of all levels, and the course is free! + +### For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible + direction of implementing the Polkadot network. This paper uses rationale and technical details to + support why this direction is beneficial. This original white paper also explains how Polkadot's + core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that + describes the protocol in more technical terms. We would recommend reading this overview paper if + you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction + into its blockchain technology. This paper dives into the components of Polkadot but is + understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host + protocol specification, Polkadot's specification tests of the many components of the network, and + the Polkadot Runtime specification. This repo holds algorithms and explores how various processes + function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts + from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that + explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great + articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. + + #### To start interacting with Polkadot: + + - [Creating a Polkadot Account][account generation] + - [Sending a Balance transfer][transfer] + - [Staking as Nominator][nominator] + - [Running a Validator][validator] + - [Setting an Identity][identity] + - [Creating a Proxy Account][proxy] + - [Making Proposals and Voting for Referenda][democracy] + - [Running for the Council][council] + - [Voting for Councillors][council voting] + - [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build +and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the + Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; + can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and + Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of + Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - + Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - + Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain + on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community.md) - List of community rooms and channels to talk to others + about Polkadot. +- [Sample Applications](#) - Sample applications that are built on or currently being built for + Polkadot. +- [Contributing Guide](contributing.md) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for + specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: ../learn/learn-account-generation.md +[transfer]: ../learn/learn-balance-transfers.md +[nominator]: ../maintain/maintain-guides-how-to-nominate-polkadot.md +[validator]: ../maintain/maintain-guides-how-to-validate-polkadot.md +[identity]: ../learn/learn-identity.md +[proxy]: ../learn/learn-proxies.md +[democracy]: ../maintain/maintain-guides-democracy.md +[council]: ../maintain/maintain-guides-how-to-join-council.md +[council voting]: ../maintain/maintain-guides-how-to-vote-councillor.md +[treasury]: ../learn/learn-treasury.md +[kusama guide]: https://guide.kusama.network/ diff --git a/docs/glossary.md b/docs/general/glossary.md similarity index 99% rename from docs/glossary.md rename to docs/general/glossary.md index 3f15d3cf5c9f..99b97759ded4 100644 --- a/docs/glossary.md +++ b/docs/general/glossary.md @@ -2,6 +2,7 @@ id: glossary title: Glossary sidebar_label: Glossary +slug: ../glossary --- ## Active Nomination diff --git a/docs/general/grants.md b/docs/general/grants.md new file mode 100644 index 000000000000..803c7a6fa044 --- /dev/null +++ b/docs/general/grants.md @@ -0,0 +1,41 @@ +--- +id: grants +title: Web3 Foundation Grants +sidebar_label: Grants +slug: ../grants +--- + +The Web3 Foundation offers grants for open source software development and research around Substrate, +Polkadot, and Kusama. + +Applications and deliveries are tracked transparently on GitHub and disbursed in BTC, USDT or DAI. However, +you can also apply in private, get paid out in fiat and seek funding above the regular limits ($30,000 for +first-time applications and $100,000 for follow-up ones), if needed. + +More information regarding requirements, the application process, deliveries, etc., can be found in the +[Grants Program README](https://github.com/w3f/Open-Grants-Program). For guidance, there is also a list of +[previously accepted applications](https://github.com/w3f/Grants-Program/blob/master/docs/accepted_grant_applications.md) +and a list of [frequently asked questions](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md). + +## Alternative Funding Sources + +### Polkadot Treasury + +The Polkadot Treasury is a pot of on-chain funds collected through transaction fees, slashing, +staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both +Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](../learn/learn-treasury.md) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) +- [Crust Grants Program](https://github.com/crustio/Crust-Grants-Program) +- [HydraDX Grants and Bounties](https://docs.hydradx.io/new_deal) +- [Plasm Network Builders Program](https://github.com/PlasmNetwork/Builders-Program) diff --git a/docs/how-to-dyor.md b/docs/general/how-to-dyor.md similarity index 98% rename from docs/how-to-dyor.md rename to docs/general/how-to-dyor.md index 00534a64d549..c0d7de15aff4 100644 --- a/docs/how-to-dyor.md +++ b/docs/general/how-to-dyor.md @@ -2,6 +2,7 @@ id: how-to-dyor title: How to Identify Legitimate Projects sidebar_label: How to Identify Legitimate Projects +slug: ../how-to-dyor --- There are many projects that are being built, or intend to build, on both Polkadot and Kusama. @@ -132,8 +133,8 @@ on the Rococo testnet and they should be active in the [Rococo channel](https://matrix.to/#/!WuksvCDImqYSxvNmua:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). Of course, getting a parachain slot on either of the two main networks is not guaranteed and the -project will need to win the [auction](learn-auction.md) for the slots they're interested in, or -they may choose to be a [parathread](learn-parathreads.md) instead (although this should be +project will need to win the [auction](../learn/learn-auction.md) for the slots they're interested in, or +they may choose to be a [parathread](../learn/learn-parathreads.md) instead (although this should be clarified to their community). But testing their software on the Rococo testnet is certainly a strong indicator of the legitimacy of the project. @@ -226,7 +227,7 @@ module on polkadot.js.org, which you can test on the Rococo testnet [here](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/parachains/crowdloan). This issues a special transaction that locks your funds until the parachain slot lease period ends. You can learn more about crowdloans [here](https://kusama.network/auctions) and on our -[wiki](https://guide.kusama.network/docs/mirror-learn-crowdloans). +[wiki](../learn/mirror-learn-crowdloans.md). A legitimate team will never ask you to send them funds in order to participate in a crowdloan. That being said, some teams have been doing token sales or swaps in an attempt to get a head start in diff --git a/docs/general/kusama/kusama-adverserial-cheatsheet.md b/docs/general/kusama/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..1f235ff9f0d6 --- /dev/null +++ b/docs/general/kusama/kusama-adverserial-cheatsheet.md @@ -0,0 +1,27 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +slug: ../../kusama-adversarial-cheatsheet +--- + + + +Expect things to break on Kusama. To help you break some things, take a look at the following threat +model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/docs/kusama-bug-bounty.md b/docs/general/kusama/kusama-bug-bounty.md similarity index 98% rename from docs/kusama-bug-bounty.md rename to docs/general/kusama/kusama-bug-bounty.md index a545bad6a672..a37aba601e54 100644 --- a/docs/kusama-bug-bounty.md +++ b/docs/general/kusama/kusama-bug-bounty.md @@ -2,6 +2,7 @@ id: kusama-bug-bounty title: Bug Bounty sidebar_label: Bug Bounty +slug: ../../kusama-bug-bounty --- We call on our community and all bug bounty hunters to help identify bugs in Kusama. diff --git a/docs/kusama-claims.md b/docs/general/kusama/kusama-claims.md similarity index 88% rename from docs/kusama-claims.md rename to docs/general/kusama/kusama-claims.md index c19967343916..2b8755e1d938 100644 --- a/docs/kusama-claims.md +++ b/docs/general/kusama/kusama-claims.md @@ -2,6 +2,7 @@ id: kusama-claims title: Kusama Claims sidebar_label: Claims +slug: ../../kusama-claims --- The Kusama network is Polkadot's experimental, community-focused R&D network. If you held the DOT @@ -20,13 +21,13 @@ For most users, we recommend using the since it will allow you to store your encrypted keystore locally. In terms of hardware wallet support, you can use the [Kusama Ledger application](kusama-ledger.md), -or [Parity Signer](learn-account-generation.md#parity-signer). +or [Parity Signer](../../learn/learn-account-generation.md#parity-signer). Another option you may consider using is the Subkey command line utility, which will allow you to take extra steps to protect the security of your key. There are a variety of other wallets that you can use; see the -[Polkadot Wiki Wallets page](build-wallets.md). Many of these wallets support generating Kusama +[Polkadot Wiki Wallets page](../../build/build-wallets.md). Many of these wallets support generating Kusama accounts as well. ### Using Kusama Ledger application @@ -40,20 +41,20 @@ then proceed to step 2 below. [Chrome store](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd?hl=en) or [Firefox store](https://addons.mozilla.org/en-US/firefox/addon/polkadot-js-extension/). 2. Click on the settings button to change the network to "Kusama (canary)". 3. Create a new account by clicking on "Create new account (root or derived)". 4. Uncheck the option to create an account dervied from another seed. 5. Copy the seed phrase and store it somewhere safe. Don't share the seed phrase with anyone, you can use it to access your account if you forget your password or want to import your account - again. 6. Enter a name for the account and type a strong password (at least 6 characters). 7. Click on "Add the account with the generated seed". 8. You can copy the account's address to the clipboard by clicking on its identicon. @@ -122,12 +123,12 @@ enter `subkey --help` for more usage examples. 2. Navigate to the [Polkadot-JS UI Accounts Tab](https://polkadot.js.org/apps/#/accounts) and click on the "Add account" button. -![kusama add account](assets/kusama/kusama_add_account.png) +![kusama add account](../../assets/kusama/kusama_add_account.png) 3. Enter a name for your account and create a secure password. This password will be used to decrypt your account. The required text fields to complete are highlighted in pink. -![kusama create account](assets/kusama/kusama_create_account.png) +![kusama create account](../../assets/kusama/kusama_create_account.png) 4. Ignore the advanced options unless you want to change the type of cryptography used for your keys (we recommend "Schnorrkel (sr25519)"). You will have to enter an Account Name and a password to @@ -138,7 +139,7 @@ enter `subkey --help` for more usage examples. 5. Click "Save" and "Create and backup account". -![kusama save backup](assets/kusama/kusama_backup_account.png) +![kusama save backup](../../assets/kusama/kusama_backup_account.png) 6. Save your encrypted keystore locally. Ideally, you would also save it on an external hard drive or thumb drive, or print it out and be able to re-enter it later. You should not store it in @@ -148,7 +149,7 @@ enter `subkey --help` for more usage examples. 7. The account now appears in your Accounts tab and is backed up to the keystore you just saved. 8. Click on the DOT identicon to copy the address to the clipboard. - ![kusama copy address](assets/kusama/kusama_copy_address.png) + ![kusama copy address](../../assets/kusama/kusama_copy_address.png) ### Using Polkawallet @@ -161,7 +162,7 @@ enter `subkey --help` for more usage examples. phrase with anyone, you can use it to access your account if you forget your password or otherwise lose your keystore. - + 3. Name your account and make a strong password, make sure to write it down in another place, then click "Save". @@ -171,8 +172,8 @@ enter `subkey --help` for more usage examples. 5. Click on the pink QR Code symbol and select "Copy address" to copy your address to clipboard. - + 6. [Get the Kusama address from the Substrate address.](#kusama-from-substrate-address) @@ -231,7 +232,7 @@ maximum security), you can start by navigating to the Claims app on the Polkadot account you would like to claim the KSM into and click the blue "Continue" button to proceed. Your screen should look something like this: -![Claim Step 1](assets/kusama/claim/claim-1.png) +![Claim Step 1](../../assets/kusama/claim/claim-1.png) The hex encoded string that follows the sentence: "Pay KSM to the Kusama account:" is the hex-encoded public key of your Kusama account, minus the `0x` prefix. To verify that the public key @@ -241,23 +242,23 @@ The next step is to go to the MyCrypto application and click on "Sign & Verify M will prompt you to select a method for unlocking your wallet. After unlocking your wallet, you will copy and paste the outputted sentence into the input box. -![Claim Step 2](assets/kusama/claim/claim-2.png) +![Claim Step 2](../../assets/kusama/claim/claim-2.png) When you click "Sign Message" you will get a JSON output like the below: -![Claim Step 3](assets/kusama/claim/claim_3.png) +![Claim Step 3](../../assets/kusama/claim/claim_3.png) Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." -![Claim Step 3](assets/kusama/claim/claim-3.png) +![Claim Step 3](../../assets/kusama/claim/claim-3.png) At this point you will see a success message if everything went right and your KSM will now be in the account that you claimed to. Congratulations you can now participate in aspects of the Kusama -network such as [governance](learn-governance) and [staking](learn-staking.md). During the soft +network such as [governance](../../learn/learn-governance.md) and [staking](../../learn/learn-staking.md). During the soft launch period balance transfers will not be enabled. -![Claim Step 4](assets/kusama/claim/claim-4.png)] +![Claim Step 4](../../assets/kusama/claim/claim-4.png)] #### Verifying your Claim diff --git a/docs/general/kusama/kusama-coc.md b/docs/general/kusama/kusama-coc.md new file mode 100644 index 000000000000..99ac775cdae9 --- /dev/null +++ b/docs/general/kusama/kusama-coc.md @@ -0,0 +1,51 @@ +--- +id: kusama-coc +title: Kusama Code of Conduct +sidebar_label: Code of Conduct +slug: ../../kusama-coc +--- + +While Kusama has been its own network and has had its own ecosystem for a while now, it is still one +big experiment and we need your participation for it to continue being a great success. + +## Community + +We want to foster a sense of collaboration amongst ourselves and the open-source community. Kusma +participants exist to encourage the open exchange of ideas and expression and require an environment +that recognizes the inherent worth of every person and group. We are here to collaborate, discuss, +and even disagree. The key is doing this in a manner that comes from a place of respect and +professionalism. Participants in the Kusama network may consist of participants in an online forum, +on-chain governance participants, parachain deployment teams, validators, enthusiasts, and ecosystem +tool builders. We expect for there to be participation from all backgrounds but like to set some +social boundaries on how you may be treated and treat others. + +Kusama community members come from across the globe and are not bordered by race, gender, or +background. Community participants have read through the requisite resources and obtained sufficient +knowledge about Kusama and all related content. This knowledge equips the community with the +requisite information needed in the dispense of their duties as a participant. + +## Bugs + +Please understand that this network is, despite its success, an experiment with potential flaws, so +it’s appreciated that community members help report any sort of exploits directly to the team before +sharing publicly. Please see the [bug bounty program](kusama-bug-bounty.md). + +## Examples of Unacceptable Behavior + +Please note: these are just a few examples and you can always consult a team member if you have any +questions. + +- Angry aggressive comments towards individuals or other projects on any medium of communication. +- Knowingly distributing false information about Kusama or other projects. +- Harassing other individuals or projects. + +That said, please note that Kusama is an edgy and meme-friendly network, and community member +actions shouldn't be taken too seriously - try to assume jest before malice. + +## What To Do If You Witness or Are Subject To Unacceptable Behavior + +If you are being harassed, notice that someone else is being harassed, or have any other concerns +relating to harassment, please contact the administrator of the channel you’re in. + +This Code of Conduct may be revised at any time. We are always willing to revise this document based +on feedback from the Kusama participants and/or the Polkadot community. diff --git a/docs/kusama-community.md b/docs/general/kusama/kusama-community.md similarity index 99% rename from docs/kusama-community.md rename to docs/general/kusama/kusama-community.md index b31d09143357..61ee92f62e8b 100644 --- a/docs/kusama-community.md +++ b/docs/general/kusama/kusama-community.md @@ -2,10 +2,9 @@ id: kusama-community title: Kusama Community sidebar_label: Community +slug: ../../kusama-community --- - - The following is a list of official chats, forums, and social channels for the Kusama community. Keep in mind that no admin or moderator will ever DM you for any reason whatsoever without prior public contact and anyone doing so is likely trying to scam you. diff --git a/docs/kusama-endpoints.md b/docs/general/kusama/kusama-endpoints.md similarity index 83% rename from docs/kusama-endpoints.md rename to docs/general/kusama/kusama-endpoints.md index 1b12a657efcf..5c6a974ddbd9 100644 --- a/docs/kusama-endpoints.md +++ b/docs/general/kusama/kusama-endpoints.md @@ -2,10 +2,11 @@ id: kusama-endpoints title: Kusama Endpoints sidebar_label: Kusama Endpoints +slug: ../../kusama-endpoints --- When interacting with the [Kusama network][] via [Polkadot-JS Apps][] or other UIs and programmatic -methods, you'd ideally be running your own node ([text guide](maintain-sync.md), +methods, you'd ideally be running your own node ([text guide](../../maintain/maintain-sync.md), [video guide](https://www.youtube.com/watch?v=31DdfcxbAVs)). Granted, that's not something everyone wants to do, so convenience trumps ideals in most cases. To facilitate this convenience, Kusama has several public endpoints you can use for your apps provided by infrastructure and @@ -30,4 +31,4 @@ const{ ApiPromise, WsProvider } = require('@polkadot/api') or in Polkadot-JS Apps by clicking the top-left corner of the screen and selecting the appropriate option: - + diff --git a/docs/general/kusama/kusama-faucet.md b/docs/general/kusama/kusama-faucet.md new file mode 100644 index 000000000000..d874e23b229d --- /dev/null +++ b/docs/general/kusama/kusama-faucet.md @@ -0,0 +1,13 @@ +--- +id: kusama-faucet +title: Kusama Faucet +sidebar_label: Faucet +slug: ../../kusama-faucet +--- + +Due to high demand and spamming issues, the Kusama faucet is no longer in operation. The Web3 +Foundation has considered new ways to distribute KSM for people who need KSM to build. + +If you are interested in obtaining KSM for building or research, you can apply through the +[Treasury](../../learn/mirror-learn-treasury.md#creating-a-treasury-proposal) or receive a +[tip](../../learn/mirror-learn-treasury.md#tipping) for doing something cool in the community. diff --git a/docs/kusama-getting-started.md b/docs/general/kusama/kusama-getting-started.md similarity index 87% rename from docs/kusama-getting-started.md rename to docs/general/kusama/kusama-getting-started.md index ca24435c3df4..06a4a353c103 100644 --- a/docs/kusama-getting-started.md +++ b/docs/general/kusama/kusama-getting-started.md @@ -2,6 +2,7 @@ id: kusama-getting-started title: Getting Started sidebar_label: Getting Started +slug: ../../kusama-getting-started --- It's time to get started on the Kusama network! Please check out our recommended list for getting @@ -39,7 +40,7 @@ as well. [create-account]: kusama-claims.md [endpoints]: kusama-endpoints.md [tokens]: https://claim.kusama.network/ -[validator]: mirror-maintain-guides-how-to-validate-kusama.md -[nominator]: mirror-maintain-guides-how-to-nominate-kusama.md +[validator]: ../../maintain/kusama/mirror-maintain-guides-how-to-validate-kusama.md +[nominator]: ../../maintain/kusama/mirror-maintain-guides-how-to-nominate-kusama.md [polkadot wiki]: https://wiki.polkadot.network/ -[polkadot-builders]: build-index.md +[polkadot-builders]: ../../build/build-index.md diff --git a/docs/kusama-index.md b/docs/general/kusama/kusama-index.md similarity index 97% rename from docs/kusama-index.md rename to docs/general/kusama/kusama-index.md index 540e72122179..b821ec2ddb5b 100644 --- a/docs/kusama-index.md +++ b/docs/general/kusama/kusama-index.md @@ -2,6 +2,7 @@ id: kusama-index title: Kusama sidebar_label: Home +slug: ../../kusama-index --- Kusama is a "canary network" for Polkadot; an early release of the code that is available first and @@ -15,7 +16,7 @@ No Promises. On Kusama you can: - Explore the politics. Campaign as a councillor or vote for new runtime proposals using - [Democracy](maintain-guides-democracy.md). + [Democracy](../../maintain/maintain-guides-democracy.md). - Hone your validator set-up. The minimum requirement for staking as a validator on Kusama is much lower than it is expected for Polkadot. There are also programs in place such as [Thousand Validators][thousand validators] to help community validators rise the ranks. diff --git a/docs/general/kusama/kusama-ledger.md b/docs/general/kusama/kusama-ledger.md new file mode 100644 index 000000000000..6ac028fb2edb --- /dev/null +++ b/docs/general/kusama/kusama-ledger.md @@ -0,0 +1,232 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +slug: ../../kusama-ledger +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based +> browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X +devices. The Ledger devices are hardware wallets that keep your private key secured on a physical +device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most +of the available transaction types of the network (a notable exception is the "Batch" transaction +from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your +issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our +> [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed. +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're + up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps UI][apps]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. + ![The Kusama App in the Ledger Manager](../../assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the +> application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the +README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it +executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest +firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on +your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the +allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". +Navigate all the way to the right, verify the Identifier hash matches the one that is printed in +your terminal. Click both buttons on "Perform Installation" to install the application. It will ask +again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps UI + +### Loading Your Account + +[Polkadot-JS Apps UI][apps] already has an integration with the Ledger application so that your +device will work with the browser interface after installation. The functionality is currently gated +behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Kusama Ledger application, go to the "Settings" +tab in [Polkadot-JS Apps UI][apps]. Find the option for attaching Ledger devices and switch the +option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in Polkadot-JS Apps UI Settings](../../assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that +your Ledger device is unlocked and you have navigated into the Kusama application, then click this +button. + +![Add Ledger button in Polkadot-JS Apps UI](../../assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](../../assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger +device. The second dropdown lets you pick a derivation path - think of it like a formula from which +child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need +to confirm the USB connection through a popup like the one below when adding the Ledger device for +the first time: + +![Display the device connection popup](../../assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](../../assets/ledger/ledger-balance.png) + +You can now use this account to interact with Kusama on [Polkadot-JS Apps UI][apps] and it will +prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the +end of the row. This will open a new menu, here you can click the "Show address on hardware device" +option to display the address on your device. + +![Options menu of an account in the Accounts screen of Polkadot-JS Apps UI](../../assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on [Polkadot-JS +Apps UI][apps]. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you +can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger +account. At the far right of the row is located your account's DOT balance. If you expand the +balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](../../assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest +method is to use [Polkadot-JS Apps UI][apps]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your +> account will be unable to make transactions which would get its balance below the existential +> deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you +> will be able to go below existential deposit balance, causing your account to be deleted and any +> dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this +> might be the reason. + +A detailed guide on doing transfers is available [here](../../learn/learn-balance-transfers.md). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to +provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your +address will be shown in this sidebar, along with some other information. Another method is just +clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger +> by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware +> will intercept clicks and clipboard requests and can change your copied value in-flight, so being +> extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you +want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not + work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" + page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manually when you +want to remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda + they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a `democracy.removeVote(X)` extrinsic, where X = + the referendum you voted on and has an expired lock. Make sure you do it from the account with the + expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a `democracy.unlock(ACCOUNT)` extrinsic, where + ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +**NOTE**: Despite the Polkadot ledger application being compatible with both the Ledger Nano S and the +Ledger Nano X, none of the [Democracy](../../maintain/maintain-guides-democracy.md) extrinsics are available in the +light version. The following [repo by Zondax][] lists the currently supported Democracy extrinsics on +the full ledger. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) +or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[repo by zondax]: https://github.com/Zondax/ledger-polkadot#democracy +[apps]: https://kusama.dotapps.io +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/docs/general/kusama/kusama-parameters.md b/docs/general/kusama/kusama-parameters.md new file mode 100644 index 000000000000..31689c89ef7c --- /dev/null +++ b/docs/general/kusama/kusama-parameters.md @@ -0,0 +1,76 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +slug: ../../kusama-parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute +certainty of these parameter values, it is recommended you directly check the constants by looking +at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or +[storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except in the time slot duration itself. See +[Polkadot Parameters](../../maintain/maintain-polkadot-parameters.md) for more details on how Kusama's parameters +differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3_600 | + +\*_A maximum of one block per slot can be in a canonical chain. Occasionally, a slot will be without +a block in the chain. Thus, the times given are *estimates*. See [Consensus](../../learn/learn-consensus.md) for +more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100_800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100_800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115_200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14_400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14_400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604_800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1_800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3_600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3_600 | How often a new validator set is [elected](../../learn/learn-phragmen.md). | +| Bonding duration | 7 days | 604_800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604_800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86_400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily +redirected into the [Society](../../maintain/kusama/maintain-guides-society-kusama.md)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1_000_000_000_000, or one trillion) Plancks +make up a single KSM. diff --git a/docs/kusama-social-recovery.md b/docs/general/kusama/kusama-social-recovery.md similarity index 84% rename from docs/kusama-social-recovery.md rename to docs/general/kusama/kusama-social-recovery.md index e05c20af0300..75beaccd1fae 100644 --- a/docs/kusama-social-recovery.md +++ b/docs/general/kusama/kusama-social-recovery.md @@ -2,6 +2,7 @@ id: kusama-social-recovery title: Social Recovery sidebar_label: Account Recovery +slug: ../../kusama-social-recovery --- Managing an account is not an easy task. Many people have lost their private keys due to improper @@ -22,7 +23,7 @@ trust to help you recover the account when you lose the private key. To create a account, you will be required to set a `threshold` that is the number of your friends who need to approve the recovery process in order to recover your account. -![](assets/recovery/social-recovery-diag-1.png) +![](../../assets/recovery/social-recovery-diag-1.png) > Note: If you are recovering an account, ensure that your network is set to Kusama. You can do this > by selecting the network from the top right corner in the Polkadot-JS UI. @@ -32,11 +33,11 @@ page that shows all available accounts on your browser's local storage and Polka create a recoverable account, make sure that you have some KSMs to pay for the transaction fees. You will also need some for the reserve required by the account recovery setup. -![kusama accounts page](assets/kusama/kusama_social_recovery_accounts_page.png) +![kusama accounts page](../../assets/kusama/kusama_social_recovery_accounts_page.png) Then click the menu that is located beside the "send" button, and choose "Make recoverable". -![kusama accounts make recoverable](assets/kusama/kusama_make_recoverable.png) +![kusama accounts make recoverable](../../assets/kusama/kusama_make_recoverable.png) Now you need to provide the following information: @@ -60,14 +61,14 @@ recovery process. > acquired enough signatures to recover your account, they would still have to wait until the block > delay is passed in order to control your account. -![kusama accounts page2](assets/kusama/kusama_make_account_recoverable.png) +![kusama accounts page2](../../assets/kusama/kusama_make_account_recoverable.png) ## Recover your Account This section would be showing you how to initiate a recovery process and get back the balance that held in the lost account to the new account. -![](assets/recovery/social-recovery-diag-2.png) +![](../../assets/recovery/social-recovery-diag-2.png) The above diagram shows the whole process of recovering an account. @@ -77,68 +78,68 @@ The above diagram shows the whole process of recovering an account. Navigate to the menu that is located beside the send button in the row of your new account and click the "Initiate recover for another" option. -![kusama accounts initial recoverable](assets/kusama/kusama_make_recoverable.png) +![kusama accounts initial recoverable](../../assets/kusama/kusama_make_recoverable.png) Then input the address you would like to recover in the "recover this account" field and click "Start recovery". -![kusama accounts initial recoverable2](assets/kusama/kusama_make_account_initial.png) +![kusama accounts initial recoverable2](../../assets/kusama/kusama_make_account_initial.png) Once the transaction went through, some KSM will be locked to prevent malicious behavior. -![](assets/recovery/social-recovery-6.png) +![](../../assets/recovery/social-recovery-6.png) Now call your friends that you have set in the first section, but heading over to "Developer" > "Extrinsics" and using the recovery pallet. They are required to submit a `vouchRecovery` transaction. -![](assets/recovery/social-recovery-7.png) +![](../../assets/recovery/social-recovery-7.png) Once the threshold is reached and the block delay is passed, use the new account to submit a `claimRecovery` transaction that would set a proxy on behalf of your lost account. It means that you can still indirectly use the lost account to interact with the network. -![](assets/recovery/social-recovery-8.png) +![](../../assets/recovery/social-recovery-8.png) To see the proxy information, use your new account by calling the "recovery->proxy(Accountid)" function at the [Chain state](https://polkadot.js.org/apps/#/chainstate) page. It should point to your lost account. -![](assets/recovery/social-recovery-9.png) +![](../../assets/recovery/social-recovery-9.png) Next, in order to call the "closeRecovery" transaction, you can make use of the "asRecovered" function as your lost account to get the locked KSM. -![](assets/recovery/social-recovery-10.png) +![](../../assets/recovery/social-recovery-10.png) Once the transaction goes through, the reserved KSM from the "NEW-ACC" will have been moved to the lost account. This is a way of preventing someone from recovering other accounts maliciously. Imagine if someone tried to initiate recovery on your account, you can do this to slash their locked KSM. -![](assets/recovery/social-recovery-11.png) +![](../../assets/recovery/social-recovery-11.png) Moving on, we use the `asRecovered` function to submit the `removeRecovery` transaction on behalf of the lost account to release the reserved KSM from your lost account. -![](assets/recovery/social-recovery-12.png) +![](../../assets/recovery/social-recovery-12.png) Now your account balance should be transferable. -![](assets/recovery/social-recovery-13.png) +![](../../assets/recovery/social-recovery-13.png) Finally, transfer all of your available balance from the lost account to the new account. -![](assets/recovery/social-recovery-14.png) +![](../../assets/recovery/social-recovery-14.png) The recovery process is now complete and successful. -![](assets/recovery/social-recovery-15.png) +![](../../assets/recovery/social-recovery-15.png) > Note: There is still one possible way to recover the account without going through the recovery > process. That is by using the `Root` origin. However, in order to use root permissions, you will > need to either go through the council or submit a public proposal. To learn more about governance, -> see [here](learn-governance.md). +> see [here](../../learn/learn-governance.md). ## Further Reading diff --git a/docs/kusama-statemine-ledger.md b/docs/general/kusama/kusama-statemine-ledger.md similarity index 92% rename from docs/kusama-statemine-ledger.md rename to docs/general/kusama/kusama-statemine-ledger.md index 472ea10199e4..625c95329bca 100644 --- a/docs/kusama-statemine-ledger.md +++ b/docs/general/kusama/kusama-statemine-ledger.md @@ -2,6 +2,7 @@ id: kusama-statemine-ledger title: Using Ledger Devices with Statemine sidebar_label: Ledger Devices with Statemine +slug: ../../kusama-statemine-ledger --- > Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based @@ -102,7 +103,7 @@ tab in [Polkadot-JS Apps UI][apps]. Find the option for attaching Ledger devices option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB" (**but see note above**). -![Dropdown selector for allowing Ledger connections in Polkadot-JS Apps UI Settings](assets/ledger.png) +![Dropdown selector for allowing Ledger connections in Polkadot-JS Apps UI Settings](../../assets/ledger.png) Click "Save" to keep your settings. @@ -111,11 +112,11 @@ that your Ledger device is unlocked, Ledger Live is **closed** and you have [switched over](https://support.polkadot.network/support/solutions/articles/65000169778-how-to-switch-network-nodes) to the Statemine application, then click this button. -![Add Ledger button in Polkadot-JS Apps UI](assets/ledger/query-ledger.png) +![Add Ledger button in Polkadot-JS Apps UI](../../assets/ledger/query-ledger.png) A popup will appear asking you to select an account and derivation path. -![Picking an account and derivation path](assets/ledger/add-account.png) +![Picking an account and derivation path](../../assets/ledger/add-account.png) The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which @@ -125,11 +126,11 @@ Once you confirm your selection, depending on your browser and its security sett to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: -![Display the device connection popup](assets/ledger/query-device.png) +![Display the device connection popup](../../assets/ledger/query-device.png) You should now be able to scroll down and find a new account on the page with the type "ledger". -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) +![Displaying the Ledger account in the list](../../assets/ledger/ledger-balance.png) You can now use this account to interact with Statemine on [Polkadot-JS Apps UI][apps] and it will prompt your ledger for confirmation when you initiate a transaction. @@ -140,7 +141,7 @@ On the "Accounts" tab, find your Ledger-connected account. Click on the three ve end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. -![Options menu of an account in the Accounts screen of Polkadot-JS Apps UI](assets/ledger-4.png) +![Options menu of an account in the Accounts screen of Polkadot-JS Apps UI](../../assets/ledger-4.png) Here you can scroll through and make sure the address matches to what is displayed on [Polkadot-JS Apps UI][apps]. @@ -151,7 +152,7 @@ Once you have your account loaded on the "Accounts" tab it should show a row wit account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. -![Account row showing empty balance](assets/ledger/ledger-balance.png) +![Account row showing empty balance](../../assets/ledger/ledger-balance.png) ### Sending a Transfer @@ -177,7 +178,7 @@ method is to use [Polkadot-JS Apps UI][apps]. > dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this > might be the reason. -A detailed guide on doing transfers is available [here](learn-balance-transfers.md). +A detailed guide on doing transfers is available [here](../../learn/learn-balance-transfers.md). ### Receiving a Transfer @@ -207,11 +208,11 @@ account needs to be created first. To teleport KSM to the Relay chain follow these steps: -- Create an account outside your Ledger. Instructions can be found [here](learn-account-generation). +- Create an account outside your Ledger. Instructions can be found [here](../../learn/learn-account-generation.md). - Transfer the desired amount as described [above](#sending-a-transfer). If you want to send exactly the amount you want to teleport, don't forget take into account the fees for teleporting that will be deducted in the next step. -- Teleport your tokens following the instructions you will find [here](learn-teleport). +- Teleport your tokens following the instructions you will find [here](../../learn/learn-teleport.md). Teleporting **to** a Ledger account from a non-Ledger account doesn't require these extra steps. @@ -221,7 +222,6 @@ If you need support please send an email to [support@kusama.network](mailto:supp or visit [our Support page](https://support.polkadot.network). [ledger]: https://www.ledger.com/ -[apps]: - https://cloudflare-ipfs.com/ipns/dotapps.io/?rpc=wss%3A%2F%2Fkusama-statemine-rpc.paritytech.net#/explorer +[apps]: https://cloudflare-ipfs.com/ipns/dotapps.io/?rpc=wss%3A%2F%2Fkusama-statemine-rpc.paritytech.net#/explorer [prerelease instructions]: https://github.com/Zondax/ledger-statemine [releases page]: https://github.com/Zondax/ledger-statemine/releases diff --git a/docs/kusama-timeline.md b/docs/general/kusama/kusama-timeline.md similarity index 96% rename from docs/kusama-timeline.md rename to docs/general/kusama/kusama-timeline.md index 781f9ce042a4..bebfa12d8b01 100644 --- a/docs/kusama-timeline.md +++ b/docs/general/kusama/kusama-timeline.md @@ -2,6 +2,7 @@ id: kusama-timeline title: Kusama Timeline sidebar_label: Timeline +slug: ../../kusama-timeline --- Kusama network started as a Proof-of-Authority network and was transitioned to Proof-of-Stake on 28 @@ -58,7 +59,7 @@ parachains. Teams and projects looking to become an official parachain on the Kusama network have been working hard to bring their technologies to life, many of whom started a -[crowdloan campaign](learn-crowdloans.md##starting-a-crowdloan-campaign) in order to participate in +[crowdloan campaign](../../learn/learn-crowdloans.md##starting-a-crowdloan-campaign) in order to participate in the slot auctions. Once parachains are live, the community will determine which additional features and network diff --git a/docs/general/ledger.md b/docs/general/ledger.md new file mode 100644 index 000000000000..ba7544bdb6d1 --- /dev/null +++ b/docs/general/ledger.md @@ -0,0 +1,227 @@ +--- +id: ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +slug: ../ledger +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based +> browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X +devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that +does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports +most of the transaction types of the network (a notable exception is the "Batch" transaction from +the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your +issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our +> [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on + the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're + up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](../assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the +> application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the +README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it +executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest +firmware (1.6.1 at the time of writing). If everything is prepared, then type +`./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the +allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". +Navigate all the way to the right, verify the Identifier hash matches the one that is printed in +your terminal. Click both buttons on "Perform Installation" to install the application. It will ask +again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with +> normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will +work with the browser interface after installation. The functionality is currently gated behind a +feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" +tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the +default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not +seeing this it is because there is +[no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](../assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that +your Ledger device is unlocked and you have navigated into the Polkadot application, then click this +button. + +![Add Ledger button in PolkadotJS](../assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](../assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already +named your account, this will not change the existing name. The first dropdown lets you select an +account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick +a derivation path - think of it like a formula from which child accounts are generated. If in doubt, +pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need +to confirm the USB connection through a popup like the one below when adding the Ledger device for +the first time: + +![Display the device connection popup](../assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](../assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your +ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the +end of the row. This will open a new menu, here you can click the "Show address on hardware device" +option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](../assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS +Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you +can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger +account. At the far right of the row is located your account's DOT balance. If you expand the +balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](../assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the +[balance transfer page](../learn/learn-balance-transfers.md). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to +provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your +address will be shown in this sidebar, along with some other information. Another method is just +clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger +> by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware +> will intercept clicks and clipboard requests and can change your copied value in-flight, so being +> extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you +want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not + work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" + page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manually when you +want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda + they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = + the referendum you voted on and has an expired lock. Make sure you do it from the account with the + expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where + ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +**NOTE**: Despite the Polkadot ledger application being compatible with both the Ledger Nano S and the +Ledger Nano X, none of the [Democracy](../maintain/maintain-guides-democracy.md) extrinsics are available in the +light version. The following [repo by Zondax][] lists the currently supported Democracy extrinsics on +the full ledger. + +## Support + +If you need support please send an email to +[support@polkadot.network](mailto:support@polkadot.network) or visit our +[Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[repo by zondax]: https://github.com/Zondax/ledger-polkadot#democracy +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/docs/general/redenomination.md b/docs/general/redenomination.md new file mode 100644 index 000000000000..039359f0148a --- /dev/null +++ b/docs/general/redenomination.md @@ -0,0 +1,149 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +slug: ../redenomination +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> #1_248_328. + +While [DOT](../learn/learn-DOT.md) is the unit of currency on Polkadot that most people use when interacting +with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is +like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 +Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in +ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT +denominated to ten decimal places is generally referred to as "DOT". When the difference must be +made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our +> [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the +community of DOT holders. The community decided between four options, to change the DOT denomination +by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the +denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, +remained constant, while the DOT balance for all holders was increased by a factor of one hundred. +As one can see from the example below, the number of Plancks that a user has does not change, only +the number of Plancks that constitute a single DOT. A user with 1_000_000_000_000 Plancks still has +the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT +under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards +the social consensus around where to put the decimal place when we talk about what constitutes a +DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama +blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 +> DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the +> network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to +> achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that +making a redenomination would be simpler before the Polkadot chain was live. However, many in the +community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to +be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided +to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a +majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of +> Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor +> redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized +community of validators securing the network, Web3 Foundation decided to put the redenomination +topic up to a vote again. This time, the vote was explicitly binding — meaning that it would +be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at +best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as +an approval vote, with four available options. DOT holders could issue votes for any configuration +of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote +logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime +for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select +> only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a +> non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point +> that none is left for transacting and you would like to vote, please contact a representative of +> the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot +> split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, +> effective market capitalization and the underlying balances of every account remain completely +> unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the +> purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot +community for a final, binding decision. + +## The Outcome + +![redenomination](../assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one +third of the total DOT in the network participated in the vote. The redenominaton proposal passed +with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block +#1_248_328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT +redenomination was a purely front-end change. You still hold the same amount of Plancks after the +change, but now it will appear that you hold 100x more DOT. This change applies proportionally to +every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the +[`@polkadot/api`](https://yarnpkg.com/package/@polkadot/api) package — then there should be no +real changes that need to be made in your application. The denomination is technically a cosmetic +change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) +or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you +display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide][ecosystem guide] for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any +assistance in making sure your software is compatible with the redenomination. + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ +[ecosystem guide]: https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# diff --git a/docs/research.md b/docs/general/research.md similarity index 99% rename from docs/research.md rename to docs/general/research.md index 792826887042..c59ba93433d4 100644 --- a/docs/research.md +++ b/docs/general/research.md @@ -2,6 +2,7 @@ id: research title: Research Pages sidebar_label: Research Pages +slug: ../research --- The Polkadot [research pages](https://w3f-research.readthedocs.io/en/latest/Publications.html) are diff --git a/docs/general/scams.md b/docs/general/scams.md new file mode 100644 index 000000000000..577aaf7b65b7 --- /dev/null +++ b/docs/general/scams.md @@ -0,0 +1,161 @@ +--- +id: scams +title: How to Protect Yourself from Scams +sidebar_label: How to Protect Yourself from Scams +slug: ../scams +--- + +Scams have unfortunately made an impact on our community. It's important to stay alert and protect +yourself and your non-refundable crypto assets from scammers. If you ever feel you are being +scammed, please email [our support team](mailto:support@web3.foundation). + +## Essential rules: + +1. Never, ever, ever share your seed phrase or account password. +2. Do not trust anyone online. It is trivial for them to lie and change their identities. +3. [If you are scammed](#i-got-scammed---what-can-i-do), there is **likely nothing** that can be + done to recover your funds. If a scammer gets a hold of your seed phrase, they can transfer all + of your funds to their account in seconds. It is better to be safe than to risk all of your + tokens. +4. If it sounds too good to be true, it probably is. People, especially celebrities, do not give + away crypto for free. Even if they wanted to, they could just ask for your address as opposed to + having you send them tokens. +5. Scams are absolutely rife in this space. It is easy and cheap to set a scam up, and hard to shut + one down. Therefore, the onus is on the user to be as diligent as possible in avoiding them. +6. If you can, try to always verify new information that you see with an official source, such as + [Polkadot Network's official blog](../general/community.md) or + [Web3 Foundation support](mailto:support@polkadot.network). Often scammers will fake a website or + a blog post, but if you check it against a secondary source you will reduce the chances of being + scammed. + + > Important: With crowdloans active on the network, it is very important to know how to safely + > participate. Fake crowdloan campaigns may present an attractive target for scammers. If you are + > participating in a network-native crowdloan, **never send your tokens to an address.** Native + > crowdloan contributions are made with a special transaction using a campaign index, where the + > contributed assets remain locked until the end of the lease period. Legitimate teams will not + > ask you to send your assets to an address to participate in a network-native crowdloan. + +### Some Common Types of Scams + +- Private messages sent to you over Telegram, Twitter, and other social media - admins or employees + will never contact you. +- "Giveaways" advertising that you "send us some DOT/KSM, we'll send you double back". +- Sites where you need to enter your seed phrase in order to "sync" your account, claim tokens, + unblock transactions etc. +- Emails asking for DOT/KSM private keys/seeds/etc., posing as a member of any of our teams. +- Scammers will take official videos, add "giveaway" text around it so that it looks like the + giveaway is supported by Polkadot, Web3 Foundation, Parity, or another well-known entity. +- Many scammers will create nearly perfect imitations of sites - always triple-check the URL. +- People offering to help you stake or get rewards. +- People responding to questions that you asked publicly in a private chat. +- Advertisements pointing to imitations of sites asking you to enter your seed words. + +These are just some of the types of scams. Scammers are inventing new ones all the time. In general, +do not trust anyone messaging you that you did not message yourself, and be wary of anyone +attempting to help you or offer you a "deal". + +Scammers will often imitate usernames, profile pictures, etc. of well-known members of the +community. Often the differences in these accounts will be very minor, such as `joe_sm1th` or +`jo_smith` instead of `joe_smith`. + +Scammers will often make it seem like the "deal" is only available for a limited time. Do not be +tricked by this, it is always better to confirm than to risk losing everything. + +### Admins will never contact you directly + +If you've received a message from an admin over Telegram, ignore it. Our team members will never +personally message you. Our social media accounts are posted on our website and any new social media +accounts will be announced by our team. We will never offer to sell you DOT at a discount, air-drop +"rewards", or message you privately to help with a problem you posted publicly. Our social media can +be found below: + +- [Twitter](https://twitter.com/Polkadot) +- [Reddit](https://www.reddit.com/r/polkadot) +- [Discord](https://discord.gg/wGUDt2p) +- [Polkadot YouTube](https://www.youtube.com/channel/UCB7PbjuZLEba_znc7mEGNgw) +- [Polkadot Medium](https://medium.com/polkadot-network) +- [Our Community Page](../general/community.md) also lists more social media accounts that Web3 Foundation, + Polkadot, and Kusama have. + +### Keep your data secure + +You should _never_ share your seed phrase, password, private keys, or any other personal data with +anyone. If you are concerned a wallet could be fake, please check out our official list of supported +[wallets](../build/build-wallets.md). + +Some simple things that you can do to keep your assets and information secure from hackers: + +- Keep your seed phrase only on paper, in a secret and secure location. +- DO NOT keep your seed phrase on any electronic medium, like the cloud, on your computer, on a USB + drive, etc. +- Never enter your seed or mnemonic phrase directly into a website. +- Your seed phrase is meant as a backup in case you lose access to your wallet. Use it only for that + purpose and only in wallets you've used before and trust. +- Your passwords should be strong and unique. It is recommended that you use a + [password manager app](https://www.howtogeek.com/141500/why-you-should-use-a-password-manager-and-how-to-get-started/) + to create and store your passwords. +- Keep your computer free of malware. Although an antivirus can be of great help, it's not a + panacea. Safe browsing and downloading is the only way to be sure your computer is clean. +- Avoid installing browser extensions from sources you don't trust explicitly. +- Store your assets in cold storage, like a hardware wallet or + [Parity Signer](https://www.parity.io/signer/). + +### Always check the source + +For any potential scam, always be sure to do a background check on the source, i.e, look at any +username, email, Youtube channel name, URL, etc. If something seems fishy, that's because it likely +is. Never enter any personal data if you feel the source could be a scam. Feel free to check with +[support@polkadot.network](mailto:support@web3.foundation). + +### Check twice before sending DOT/KSM + +A good practice to take into consideration is to verify the address you are sending crypto to. If +you don't know that account, you probably shouldn't be sending your assets there. It's your +responsibility to make sure that you understand where you are sending your funds. Crypto is a +decentralized space and your only recourse if a mistake is made is by appealing to the council (who +usually will not get involved in matters of mistaken transfers - see below). + +### Install the Polkadot{.js} extension + +The extension uses crowd-sourced [anti-phishing measures](https://polkadot.js.org/phishing/) to +automatically prevent your browser from displaying known phishing or scam sites. They will be +blocked upon loading, helping to prevent you from visiting these sites and thus falling for them. + +### Our official sites + +You can use the following list of our official domains to make sure that you're visiting an official +site: + +- polkadot.network +- polkadot.io +- kusama.network +- web3.foundation +- parity.io +- substrate.dev +- substrate.io + +Of course, many projects building on Polkadot and Kusama that use similar names. If, however, a site +poses as Polkadot, Kusama, Web3 Foundation, or Parity on a domain not listed above, then it's most +likely a scam. + +Besides those, there are also `polkadot.js.org` and `dotapps.io` that host our web wallet and other +tools. + +## I Got Scammed - What Can I Do? + +In the unfortunate case of having fallen for a scam, there is likely nothing anyone can do to help +you restore your funds. Polkadot and Kusama are decentralized platforms and while we do have +governance functionality that could technically allow for funds freezing or refunds, it is +impossible to prove that you are the original owner, or that you did not sell the tokens and are +trying to reclaim them. Additionally, even with addresses that are obviously in possession of a +scammer, governance is a slow-moving process; even under ideal conditions, it would take over 56 +days to come into effect. The thief could easily monitor the network for governance proposals that +would affect their ill-gotten gains and move them to a new address before the proposal is enacted. + +You could put together a full account of the transactions and chat messages accompanied by +screenshots and explanations, but there are no guarantee stakeholders on the network will help you +restore the funds as it would set a dangerous precedent. In fact, there have been several attempts +on Polkadot in the past and none have been passed. It is safer for the network and for future users +to consider the money lost. Still, your detailed account of the situation might help prevent others +from falling for the same thing so we recommend retracing your steps and talking publicly about +them, if it's not too private. diff --git a/docs/general/thousand-validators.md b/docs/general/thousand-validators.md new file mode 100644 index 000000000000..5329f4affe1c --- /dev/null +++ b/docs/general/thousand-validators.md @@ -0,0 +1,111 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +slug: ../thousand-validators +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use +the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of +validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on +Kusama). It will nominate validators which fit all the requirements and are eligible. Of this pool, +it will nominate as many as possible although some validators which are eligible might not receive +nominations every round (due to the constraint of nominating a maximum of 16 validators per +nominator). If a validator is active during a single nomination period (the time after a new +nomination and before the next one) and does not break any of the requirements, it will have its +rank increased by 1. Validators with higher rank have performed well within the programme for a +longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](../maintain/maintain-guides-how-to-validate-polkadot.md) +as well as additional information on [validator secure](../maintain/maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and +fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here][identity instructions] for instructions) +- Connect to dedicated telemetry (use + `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on the latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama +Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / + `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / + `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / + `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators +to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This +can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. +> This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below +and fill in the [application form][polkadot 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here][identity instructions] for instructions) +- Connect to dedicated Telemetry (use + `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Minimum of 5_000 DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on the latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot +Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / + `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / + `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / + `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators +to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This +can be anywhere from a few validators receiving nominations from a single nominator to the max +of 16. + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 +[polkadot 1kv form]: https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform +[identity instructions]: ../learn/mirror-learn-identity.md#setting-an-identity diff --git a/docs/getting-started.md b/docs/getting-started.md deleted file mode 100644 index 32bfe5b34ee0..000000000000 --- a/docs/getting-started.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the -core functionality. Our wiki has three main sections: Learn (for learners), Build (for people that -want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a -secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less -networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet -where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has -an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) -standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your -growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the -> [Governance page](learn-governance.md) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users -control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet -featured read-only, static, basic webpages. The online connected world at the time was only the -beginning of virtual data, identities, and more. The internet during this time was also called the -Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the -Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, -where users can read and write information plus publish their own for others to see. However, this -version of the web comes with downsides, dealing with data control, privacy issues, and trust. This -is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free -protocols. The goal is to transform the internet into a decentralized web, where users control their -own data and identity in a trust-free environment. The Web 3.0 movement aims to remove -intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the -> [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a -[sharded model]() where shards - called -"[parachains](learn-parachains.md)", allow transactions to be processed in parallel instead of -sequentially. Each parachain in the network has a unique state transition function (STF). Polkadot -has a Relay Chain acting as the main chain of the system. Based on Polkadot's design, as long as a -chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the -Polkadot network as a parachain. - -Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo -rigorous [availability and validity](learn-availability.md) checks before being added to the -finalized chain. As the Relay Chain provides the security guarantees, -[collators](learn-collator.md) - full nodes of these parachains - don't have any security -responsibilities, and thus do not require a robust incentive system. This is how the entire network -stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), -Polkadot has [bridge parachains](learn-bridges.md) that offer two-way compatibility, meaning that -transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain.md) allows parachains to send messages -of any type to each other. The shared security and validation logic of the Relay Chain provide the -environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our -> [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of -[Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a -platform for everyone. This wiki offers a place for builders and maintainers to utilize -[tools](build-tools-index.md) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to start familiarizing - yourself with blockchain concepts such as cryptography and networks, and how these play into - things like decentralization and cryptocurrency. - -This is recommended for users with backgrounds of all levels, and the course is free! - -### For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible - direction of implementing the Polkadot network. This paper uses rationale and technical details to - support why this direction is beneficial. This original white paper also explains how Polkadot's - core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that - describes the protocol in more technical terms. We would recommend reading this overview paper if - you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction - into its blockchain technology. This paper dives into the components of Polkadot but is - understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host - protocol specification, Polkadot's specification tests of the many components of the network, and - the Polkadot Runtime specification. This repo holds algorithms and explores how various processes - function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts - from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that - explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great - articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. - - #### To start interacting with Polkadot: - - - [Creating a Polkadot Account][account generation] - - [Sending a Balance transfer][transfer] - - [Staking as Nominator][nominator] - - [Running a Validator][validator] - - [Setting an Identity][identity] - - [Creating a Proxy Account][proxy] - - [Making Proposals and Voting for Referenda][democracy] - - [Running for the Council][council] - - [Voting for Councillors][council voting] - - [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build -and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the - Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; - can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and - Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of - Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain - on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community.md) - List of community rooms and channels to talk to others - about Polkadot. -- [Sample Applications](#) - Sample applications that are built on or currently being built for - Polkadot. -- [Contributing Guide](contributing.md) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for - specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation.md -[transfer]: learn-balance-transfers.md -[nominator]: maintain-guides-how-to-nominate-polkadot.md -[validator]: maintain-guides-how-to-validate-polkadot.md -[identity]: learn-identity.md -[proxy]: learn-proxies.md -[democracy]: maintain-guides-democracy.md -[council]: maintain-guides-how-to-join-council.md -[council voting]: maintain-guides-how-to-vote-councillor.md -[treasury]: learn-treasury.md -[kusama guide]: https://guide.kusama.network/ diff --git a/docs/grants.md b/docs/grants.md deleted file mode 100644 index 38ac6c11d055..000000000000 --- a/docs/grants.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -id: grants -title: Web3 Foundation Grants -sidebar_label: Grants ---- - -The Web3 Foundation offers grants for open source software development and research around Substrate, -Polkadot, and Kusama. - -Applications and deliveries are tracked transparently on GitHub and disbursed in BTC, USDT or DAI. However, -you can also apply in private, get paid out in fiat and seek funding above the regular limits ($30,000 for -first-time applications and $100,000 for follow-up ones), if needed. - -More information regarding requirements, the application process, deliveries, etc., can be found in the -[Grants Program README](https://github.com/w3f/Open-Grants-Program). For guidance, there is also a list of -[previously accepted applications](https://github.com/w3f/Grants-Program/blob/master/docs/accepted_grant_applications.md) -and a list of [frequently asked questions](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md). - - -## Alternative Funding Sources - -### Polkadot Treasury - -The Polkadot Treasury is a pot of on-chain funds collected through transaction fees, slashing, -staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both -Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](learn-treasury.md) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) -- [Crust Grants Program](https://github.com/crustio/Crust-Grants-Program) -- [HydraDX Grants and Bounties](https://docs.hydradx.io/new_deal) -- [Plasm Network Builders Program](https://github.com/PlasmNetwork/Builders-Program) diff --git a/docs/kusama-adverserial-cheatsheet.md b/docs/kusama-adverserial-cheatsheet.md deleted file mode 100644 index c88e9860e565..000000000000 --- a/docs/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - - - -Expect things to break on Kusama. To help you break some things, take a look at the following threat -model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/docs/kusama-coc.md b/docs/kusama-coc.md deleted file mode 100644 index 68ef6a61779a..000000000000 --- a/docs/kusama-coc.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: kusama-coc -title: Kusama Code of Conduct -sidebar_label: Code of Conduct ---- - -While Kusama has been its own network and has had its own ecosystem for a while now, it is still one -big experiment and we need your participation for it to continue being a great success. - -## Community - -We want to foster a sense of collaboration amongst ourselves and the open-source community. Kusma -participants exist to encourage the open exchange of ideas and expression and require an environment -that recognizes the inherent worth of every person and group. We are here to collaborate, discuss, -and even disagree. The key is doing this in a manner that comes from a place of respect and -professionalism. Participants in the Kusama network may consist of participants in an online forum, -on-chain governance participants, parachain deployment teams, validators, enthusiasts, and ecosystem -tool builders. We expect for there to be participation from all backgrounds but like to set some -social boundaries on how you may be treated and treat others. - -Kusama community members come from across the globe and are not bordered by race, gender, or -background. Community participants have read through the requisite resources and obtained sufficient -knowledge about Kusama and all related content. This knowledge equips the community with the -requisite information needed in the dispense of their duties as a participant. - -## Bugs - -Please understand that this network is, despite its success, an experiment with potential flaws, so -it’s appreciated that community members help report any sort of exploits directly to the team before -sharing publicly. Please see the [bug bounty program](kusama-bug-bounty.md). - -## Examples of Unacceptable Behavior - -Please note: these are just a few examples and you can always consult a team member if you have any -questions. - -- Angry aggressive comments towards individuals or other projects on any medium of communication. -- Knowingly distributing false information about Kusama or other projects. -- Harassing other individuals or projects. - -That said, please note that Kusama is an edgy and meme-friendly network, and community member -actions shouldn't be taken too seriously - try to assume jest before malice. - -## What To Do If You Witness or Are Subject To Unacceptable Behavior - -If you are being harassed, notice that someone else is being harassed, or have any other concerns -relating to harassment, please contact the administrator of the channel you’re in. - -This Code of Conduct may be revised at any time. We are always willing to revise this document based -on feedback from the Kusama participants and/or the Polkadot community. diff --git a/docs/kusama-faucet.md b/docs/kusama-faucet.md deleted file mode 100644 index 862c35953b4b..000000000000 --- a/docs/kusama-faucet.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: kusama-faucet -title: Kusama Faucet -sidebar_label: Faucet ---- - -Due to high demand and spamming issues, the Kusama faucet is no longer in operation. The Web3 -Foundation has considered new ways to distribute KSM for people who need KSM to build. - -If you are interested in obtaining KSM for building or research, you can apply through the -[Treasury](mirror-learn-treasury.md#creating-a-treasury-proposal) or receive a -[tip](mirror-learn-treasury.md#tipping) for doing something cool in the community. diff --git a/docs/kusama-ledger.md b/docs/kusama-ledger.md deleted file mode 100644 index 1c8780b67551..000000000000 --- a/docs/kusama-ledger.md +++ /dev/null @@ -1,233 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - - - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based -> browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X -devices. The Ledger devices are hardware wallets that keep your private key secured on a physical -device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most -of the available transaction types of the network (a notable exception is the "Batch" transaction -from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your -issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our -> [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed. -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're - up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps UI][apps]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. - ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the -> application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the -README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it -executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest -firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on -your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the -allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". -Navigate all the way to the right, verify the Identifier hash matches the one that is printed in -your terminal. Click both buttons on "Perform Installation" to install the application. It will ask -again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps UI - -### Loading Your Account - -[Polkadot-JS Apps UI][apps] already has an integration with the Ledger application so that your -device will work with the browser interface after installation. The functionality is currently gated -behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Kusama Ledger application, go to the "Settings" -tab in [Polkadot-JS Apps UI][apps]. Find the option for attaching Ledger devices and switch the -option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in Polkadot-JS Apps UI Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that -your Ledger device is unlocked and you have navigated into the Kusama application, then click this -button. - -![Add Ledger button in Polkadot-JS Apps UI](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger -device. The second dropdown lets you pick a derivation path - think of it like a formula from which -child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need -to confirm the USB connection through a popup like the one below when adding the Ledger device for -the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Kusama on [Polkadot-JS Apps UI][apps] and it will -prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the -end of the row. This will open a new menu, here you can click the "Show address on hardware device" -option to display the address on your device. - -![Options menu of an account in the Accounts screen of Polkadot-JS Apps UI](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on [Polkadot-JS -Apps UI][apps]. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you -can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger -account. At the far right of the row is located your account's DOT balance. If you expand the -balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest -method is to use [Polkadot-JS Apps UI][apps]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your -> account will be unable to make transactions which would get its balance below the existential -> deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you -> will be able to go below existential deposit balance, causing your account to be deleted and any -> dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this -> might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers.md). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to -provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your -address will be shown in this sidebar, along with some other information. Another method is just -clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger -> by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware -> will intercept clicks and clipboard requests and can change your copied value in-flight, so being -> extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you -want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not - work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" - page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manually when you -want to remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda - they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a `democracy.removeVote(X)` extrinsic, where X = - the referendum you voted on and has an expired lock. Make sure you do it from the account with the - expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a `democracy.unlock(ACCOUNT)` extrinsic, where - ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -__NOTE__: Despite the Polkadot ledger application being compatible with both the Ledger Nano S and the -Ledger Nano X, none of the [Democracy](maintain-guides-democracy.md) extrinsics are available in the -light version. The following [repo by Zondax][] lists the currently supported Democracy extrinsics on -the full ledger. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) -or visit [our Support page](https://support.polkadot.network). - -[ledger]: https://www.ledger.com/ -[repo by Zondax]: https://github.com/Zondax/ledger-polkadot#democracy -[apps]: https://kusama.dotapps.io -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[polkascan]: https://polkascan.io/kusama -[subscan]: https://kusama.subscan.io/ diff --git a/docs/kusama-parameters.md b/docs/kusama-parameters.md deleted file mode 100644 index 568ed54b9fc0..000000000000 --- a/docs/kusama-parameters.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute -certainty of these parameter values, it is recommended you directly check the constants by looking -at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or -[storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except in the time slot duration itself. See -[Polkadot Parameters](maintain-polkadot-parameters.md) for more details on how Kusama's parameters -differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | ------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3_600 | - -\*_A maximum of one block per slot can be in a canonical chain. Occasionally, a slot will be without -a block in the chain. Thus, the times given are *estimates*. See [Consensus](learn-consensus.md) for -more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100_800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100_800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115_200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14_400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14_400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604_800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1_800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3_600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3_600 | How often a new validator set is [elected](learn-phragmen.md). | -| Bonding duration | 7 days | 604_800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604_800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86_400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily -redirected into the [Society](maintain-guides-society-kusama.md)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1_000_000_000_000, or one trillion) Plancks -make up a single KSM. diff --git a/docs/learn-DOT.md b/docs/learn-DOT.md deleted file mode 100644 index 7d8f10a8dce5..000000000000 --- a/docs/learn-DOT.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -id: learn-DOT -title: DOT -sidebar_label: DOT ---- - -## What is DOT? - -DOT is the native token of the Polkadot network in a similar way that BTC is the native token of -Bitcoin or Ether is the native token of the Ethereum blockchain. - -The smallest unit of account in a Substrate network (Polkadot, Kusama, etc.) is the Planck (a -reference to [Planck Length](https://en.wikipedia.org/wiki/Planck_length), the smallest possible -distance in the physical Universe). You can compare the Planck to Satoshis or Wei, while the DOT is -like a bitcoin or an ether. Kusama tokens (KSM) are equal to 1e12 Planck, and Polkadot mainnet DOT -is equal to 1e10 Planck. - -### Polkadot - -| Unit | Decimal Places | Example | -| --------------- | -------------- | ------------ | -| Planck | 0 | 0.0000000001 | -| Microdot (uDOT) | 4 | 0.0000010000 | -| Millidot (mDOT) | 7 | 0.0010000000 | -| Dot (DOT) | 10 | 1.0000000000 | -| Million (MDOT) | 16 | 1,000,000.00 | - -> Note: This changed at block #1*248_328. Previously, DOT was denominated as equal to 1e12 Planck, -> just like Kusama. This denomination is deprecated, and, if necessary, referred to as "DOT (old)". -> See [Redenomination of DOT](redenomination.md) for more details.* - -### Kusama - -| Unit | Decimal Places | Example | -| --------------- | -------------- | -------------- | -| Planck | 0 | 0.000000000001 | -| Point | 3 | 0.000000001000 | -| MicroKSM (uKSM) | 6 | 0.000001000000 | -| MilliKSM (mKSM) | 9 | 0.001000000000 | -| KSM | 12 | 1.000000000000 | - -## What are the uses of DOT? - -DOT serves three key functions in Polkadot: - -- to be used for governance of the network, -- to be staked for the operation of the network, -- to be bonded to connect a chain to Polkadot as a parachain. - -DOT can also serve ancillary functions by virtue of being a transferrable token. For example, DOT -stored in the Treasury can be sent to teams working on relevant projects for the Polkadot network. - -> These concepts have been further explained in the video -> [Usage of DOT and KSM on Polkadot and Kusama](https://www.youtube.com/watch?v=POfFgrMfkTo&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=7). - -### DOT for Governance - -The first function of DOT is to entitle holders to control the governance of the platform. Some -functions that are included under the governance mechanism include determining the fees of the -network, the addition or removal of parachains, and exceptional events such as upgrades and fixes to -the Polkadot platform. - -Polkadot will enable any holder of DOT to participate in governance. For details on how holders can -participate in governance, as well as their rights and responsibilities, see the -[governance page](learn-governance.md). - -### DOT for Consensus - -DOT will be used to facilitate the consensus mechanism that underpins Polkadot. For the platform to -function and allow for valid transactions to be carried out across parachains, Polkadot will rely on -holders of DOT to play active roles. Participants will put their DOT at risk (via staking) to -perform these functions. The staking of DOT acts as a disincentive for malicious participants who -will be punished by the network by getting their DOT slashed. The DOT required to participate in the -network will vary depending on the activity that is being performed, the duration the DOT will be -staked for, and the total number of DOT staked. - -### DOT for Parachain Slot Acquisition - -DOT will have the ability to be locked for a duration in order to secure a parachain slot in the -network. The DOT will be reserved during the slot lease and will be released back to the account -that reserved them after the duration of the lease has elapsed and the parachain is removed. You can -learn more about this aspect by reading about the [auctions](learn-auction.md) that govern parachain -slots. - -### Vesting - -DOT may have a lock placed on them to account for vesting funds. Like other types of locks, these -funds cannot be transferred but can be used in other parts of the protocol such as voting in -governance or being staked as a validator or nominator. - -Vesting funds are on a linear release schedule and unlock a constant number of tokens at each block. -Although the tokens are released in this manner, it does not get reflected on-chain automatically -since locks are [lazy](#lazy-vesting) and require an extrinsic to update. - -There are two ways that vesting schedules can be created. - -- One way is as part of the genesis configuration of the chain. In the case of Polkadot and Kusama, - the chain specification genesis script reads the state of the Polkadot Claims contract that exists - on the Ethereum blockchain and creates vesting schedules in genesis for all the allocations - registered as being vested. -- A second way is through an extrinsic type available in the Vesting pallet, `vested_transfer`. The - vested transfer function allows anyone to create a vesting schedule with a transfer of funds, as - long as the account for which the vesting schedule will be created does not already have one and - the transfer moves at least `MinVestedTransfer` funds, which is specified as a chain constant. - -Vesting schedules have three parameters, `locked`, `per_block`, and `starting_block`. The -configuration of these three fields dictate the amount of funds that are originally locked, the -slope of the unlock line and the block number for when the unlocking begins. - -#### Lazy Vesting - -Like [simple payouts](learn-simple-payouts.md), vesting is _lazy_, which means that someone must -explicitly call an extrinsic to update the lock that is placed on an account. - -- The `vest` extrinsic will update the lock that is placed on the caller. -- The `vest_other` will update the lock that is placed on another "target" account's funds. - -These extrinsics are exposed from the Vesting pallet. - -If you are using Polkadot-JS, when there are DOT available to vest for an account, then you will -have the ability to unlock DOT which has already vested from the -[Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![unbond](assets/unlock-vesting.png) - -#### Calculating When Vesting DOT Will Be Available - -Generally, you should be able to see from the [Accounts](https://polkadot.js.org/apps/#/accounts) by -looking at your accounts and seeing when the vesting will finish. However, some DOT vest with -"cliffs" - a single block where all the DOT are released, instead of vesting over time. In this -case, you will have to query the chain state directly to see when they will be available (since -technically, the vesting has not yet started - all of the vesting will occur in a single block in -the future). - -1. Navigate to the - [Chain State](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/chainstate) page on - Polkadot-JS. -2. Query chain state for `vesting.vesting(ACCOUNT_ID)` -3. Note the `startingBlock` where the unlock starts, and how much DOT is unlocked per block - (`perBlock`). -4. You will have to calculate the result into “human time". To do this, remember that there are - approximately 14’400 blocks per day, and you can see what the latest block is shown on the - [Explorer](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/explorer) page. - -## Obtaining Testnet DOT - -DOT are required to make transactions on the Polkadot network. Testnet DOT do not have any value -beside allowing you to experiment with the network. - -### Getting Westies - -The current testnet is called [Westend](maintain-networks.md#westend-test-network) and you can -obtain its native tokens by posting `!drip ` in the Matrix chatroom -[#westend_faucet:matrix.org](https://matrix.to/#/#westend_faucet:matrix.org). - -You can also make your own WNDs (testnet DOT) by [becoming a validator](learn-validator.md). - -### Westend - -| Unit | Decimal Places | Example | -| --------------- | -------------- | -------------- | -| Planck | 0 | 0.000000000001 | -| Point | 3 | 0.000000001000 | -| MicroWND (uWND) | 6 | 0.000001000000 | -| MilliWND (mWND) | 9 | 0.001000000000 | -| WND | 12 | 1.000000000000 | - -### Getting Rococo Tokens - -Rococo is a parachain testnet. Tokens are given directly to teams working on parachains or exploring -the [crosschain](learn-crosschain.md) message passing aspects of this testnet. General users can -obtain ROC by posting `!drip ` in the Matrix chatroom -[#rococo-faucet:matrix.org](https://matrix.to/#/#rococo-faucet:matrix.org). - -Learn more about Rococo on its [dedicated wiki page](build-parachains-rococo.md). - -## Kusama Tokens - -Unlike testnet DOT, Kusama tokens are not freely given away. Kusama tokens are available via the -[claims process](https://claim.kusama.network/) (if you had DOT at the time of Kusama genesis) or -through the [Treasury](learn-treasury.md). Alternatively, they can be obtained on the open market. - -## Polkadot Mainnet DOT - -Polkadot Mainnet DOT are not freely given away. If you purchased DOT in the original 2017 offering, -you may claim them via the [Polkadot claims process](https://claims.polkadot.network/). -Alternatively, they are available on the open market. diff --git a/docs/learn-account-generation.md b/docs/learn-account-generation.md deleted file mode 100644 index b58b17e5bffd..000000000000 --- a/docs/learn-account-generation.md +++ /dev/null @@ -1,353 +0,0 @@ ---- -id: learn-account-generation -title: Account Generation -sidebar_label: Account Generation -description: Step-by-step guides on generating a Polkadot account. ---- - -An address is the public part of a Polkadot account. The private part is the key used to access this -address. The public and private parts together make up a Polkadot account. - -There are several ways to generate a Polkadot account: - -- [Polkadot{.js} Browser Plugin](#polkadotjs-browser-plugin) **RECOMMENDED FOR MOST USERS** -- [Subkey](#subkey) **ADVANCED and MOST SECURE** -- [Polkadot-JS Apps](#polkadot-js-apps) -- [Parity Signer](#parity-signer) -- [Vanity Generator](#vanity-generator) -- [Ledger Hardware Wallet](learn-ledger.md) - -> If you prefer video instructions, we have an easy to follow guide -> [on YouTube](https://www.youtube.com/watch?v=hhUZ40ZWqkE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=19) - -## DISCLAIMER: Key Security - -The _only_ ways to get access to your account are via your secret seed or your account's JSON file -in combination with a password. You must keep them both secure and private. If you share them with -anyone they will have full access to your account, including all of your funds. This information is -a target for hackers and others with bad intentions - see also -[How to Recognize Scams](learn-scams.md). - -On this page, we recommend a variety of account generation methods that have various convenience and -security tradeoffs. Please review this page carefully before making your account so that you -understand the risks of the account generation method you choose and how to properly mitigate them -in order to keep your funds safe. - -### Storing your key safely - -The seed is your **key** to the account. Knowing the seed allows you, or anyone else who knows the -seed, to re-generate and control this account. - -It is imperative to store the seed somewhere safe, secret, and secure. If you lose access to your -account (i.e. you forget the password for your account's JSON file), you can re-create it by -entering the seed. This also means that somebody else can have control over your account if they -have access to your seed. - -For maximum security, the seed should be written down on paper or another non-digital device and -stored in a safe place. You may also want to protect your seed from physical damage, as well (e.g. -by storing in a sealed plastic bag to prevent water damage, storing it in a fireproof safe, etching -it in metal, etc.) It is recommended that you store multiple copies of the seed in geographically -separate locations (e.g., one in your home safe and one in a safety deposit box at your bank). - -You should -**not store your seed on any kind of computer that has or may have access to the internet in the future.** - -### Storing your account's JSON file - -The JSON file is encrypted with a password, which means you can import it into any wallet which -supports JSON imports, but to then use it, you need the password. You don't have to be as careful -with your JSON file's storage as you would with your seed (i.e. it can be on a USB drive near you), -but remember that in this case, your account is only as secure as the password you used to encrypt -it. Do not use easy to guess or hard to remember passwords. It is good practice to use a -[mnemonic password of four to five words](https://xkcd.com/936/). These are nearly impossible for -computers to guess due to the number of combinations possible, but much easier for humans to -remember. - -## Polkadot{.js} Browser Plugin - -The Polkadot{.js} plugin provides a reasonable balance of security and usability. It provides a -separate local mechanism to generate your address and interact with Polkadot. - -This method involves installing the Polkadot{.js} plugin and using it as a “virtual vault," separate -from your browser, to store your private keys. It also allows the signing of transactions and similar -functionality. - -It is still running on the same computer you use to connect to the internet with and thus is less -secure than using Parity Signer or other air-gapped approaches. - -### Install the Browser Plugin - -The browser plugin is available for both -[Google Chrome](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd?hl=en) -(and Chromium-based browsers like Brave) and -[FireFox](https://addons.mozilla.org/en-US/firefox/addon/polkadot-js-extension). - -If you would like to know more or review the code of the plugin yourself, you can visit the -[Github source repository](https://github.com/polkadot-js/extension). - -After installing the plugin, you should see the orange and white Polkadot{.js} logo in the menu bar -of your browser. - -![plugin-02](assets/accounts/polkadot_plugin_js_02.jpg) - -### Create Account - -Open the Polkadot{.js} browser extension by clicking the logo on the top bar of your browser. You -will see a browser popup, not unlike the one below. - -![Initial PolkadotJS popup](assets/accounts/polkadot_plugin_js_new_01.png) - -Click the big plus button or select "Create new account" from the small plus icon in the top right. -The Polkadot{.js} plugin will then use system randomness to make a new seed for you and display it -to you in the form of twelve words. - -![New seed](assets/accounts/polkadot_plugin_js_new_02.png) - -You should back up these words as [explained above](#storing-your-key-safely). It is imperative to -store the seed somewhere safe, secret, and secure. If you cannot access your account via -Polkadot{.js} for some reason, you can re-enter your seed through the "Add account menu" by -selecting "Import account from pre-existing seed". - -![New seed](assets/accounts/polkadot_plugin_js_new_03.png) - -### Name Account - -The account name is arbitrary and for your use only. It is not stored on the blockchain and will not -be visible to other users who look at your address via a block explorer. If you're juggling multiple -accounts, it helps to make this as descriptive and detailed as needed. - -### Enter Password - -The password will be used to encrypt this account's information. You will need to re-enter it when -using the account for any kind of outgoing transaction or when using it to cryptographically sign a -message. - -Note that this password does NOT protect your seed phrase. If someone knows the twelve words in your -mnemonic seed, they still have control over your account even if they do not know the password. - -### Set Address for Polkadot Mainnet - -Now we will ensure that the addresses are displayed as Polkadot mainnet addresses. - -Click on "Options" at the top of the plugin window, and under "Display address format for" select -"Polkadot Relay Chain". - -![New seed](assets/accounts/polkadot_plugin_js_new_04.png) - -Your address' format is only visual - the data used to derive this representation of your address -are the same, so you can use the same address on multiple chains. However, for privacy reasons, we -recommend creating a new address for each chain you're using. - -Our [Accounts page](learn-accounts.md#address-conversion-tools) also has a tool you can use to -convert your address between the different chain formats. - -You can copy your address by clicking on the account's icon while the desired chain format is -active. E.g. selecting "Substrate" as the format will change your address to start with the number -5, and clicking the colorful icon of your account will copy it in that format. While in Polkadot -mode (starts with 1), that format will be copied, and so on. - -## Subkey - -Subkey is recommended for technically advanced users who are comfortable with the command line and -compiling Rust code. Subkey allows you to generate keys on any device that can compile the code. -Subkey may also be useful for automated account generation using an air-gapped device. It is not -recommended for general users. - -For detailed build and usage instructions of subkey, please see -[here](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). - -![subkey-01](assets/accounts/subkey_01.jpg) - -## Polkadot-JS Apps - -> Please note! If you use this method to create your account and clear your cookies in your browser, -> your account will be lost forever if you do not [back it up](learn-account-restore.md). Make sure -> you store your seed phrase in a safe place, or download the account's JSON file if using the -> Polkadot{.js} browser extension. Learn more about account backup and restoration -> [here](learn-account-restore.md). - -Using the Polkadot-JS user interface without the plugin is **not recommended**. It is the least -secure way of generating an account. It should only be used if all of the other methods are not -feasible in your situation. - -### Go to Polkadot-JS Apps - -Navigate to [Polkadot-JS Apps](https://polkadot.js.org/apps) and click on "Accounts" underneath the -Accounts tab. It is located in the navigation bar at the top of your screen. - -![pjs-01](assets/accounts/polkadot_js_01.png) - -> To create an account on a different network than Polkadot, you'll need to click on the network -> selection in the top left corner of the navigation menu. A pop-up sidebar will appear listing -> live, testing, and custom node to choose from. Do remember to hit the "Switch" button when you -> want to switch your network. - -### Start Account Generation - -Click on the "Add Account" button. You should see a pop-up similar to the process encountered when -using the [Polkadot JS Extension method](#polkadotjs-browser-plugin) above. Follow the same -instructions and remember to [store your seed safely](#storing-your-key-safely)! - -### Create and Back-Up Account - -Click “Save” and your account will be created. It will also generate a -[backup JSON file](#storing-your-accounts-json-file) that you should safely store, ideally on a USB -off the computer you're using. You should not store it in cloud storage, email it to yourself, etc. - -You can use this backup file to restore your account. This backup file is not readable unless it is -decrypted with the password. - -### Multi-signature Accounts - -Multi-signature accounts are accounts created from several standard accounts (or even other -multi-sig accounts). For a full explanation, please see the -[Accounts Explainer section on multi-sigs](learn-accounts.md#multi-signature-accounts). - -On the [Accounts](https://polkadot.js.org/apps/#/accounts) tab, click the `Multisig` button. Enter -the threshold and add signatories. The threshold must be less than or equal to the number of -signatories. The threshold indicates how many members must agree for an extrinsic -submission to be successful. Click `Create` when done. - -![Multi-sig account creation](assets/accounts/create-multisig.png) - -This merely calculates the multi-signature's address and adds it to your UI. The account does not -exist yet, and is subject to the same -[Existential Deposit and Reaping](learn-accounts.md#existential-deposit-and-reaping) rules as -regular accounts. - -Suppose we funded it with some tokens, and now want to send from the multi-sig to another account. - -![Sending from multi-sig account](assets/accounts/send-from-multi.png) - -The next step is to sign the transaction from with enough accounts to meet the threshold; in the -above case, two out of three signatories must sign. - -![Signing from multi-sig account](assets/accounts/sign-from-multi-1.png) - -There is currently no indication of a pending transaction from a multi-sig in the UI. This means the -second signatory must **repeat the call in full** in order to sign it. In other words: - -- if Alice initiates a transaction from the multi-sig to Ferdie for 150 tokens, there will be a - pending transaction in the chain. -- if Bob initiates a transaction from the multi-sig to Ferdie for 250 tokens, there will be - **another** pending transaction in the chain, and the first one will not complete. -- because the threshold is 2/3, Charlie can now finalize either or both of these by repeating the - desired transaction. - -Other calls work the same - if a multi-sig wants to become a Council member, the candidacy -request has to come from the multi-sig, but be signed (re-requested) from each signatory until the -threshold is reached. - -Signatories should communicate off-chain to prevent many pending transactions and crossed -communication lines on-chain. - -> The bigger the multisig, the more of a deposit an account needs to put down when initiating a -> multi-sig call. This is to prevent chain storage spam with pending but never-resolved multi-sig -> transactions. Once a call is resolved (canceled or executed) the deposit is returned to the -> initiator. The deposit is not taken from the multi-sig's balance but from the initiator. - -For a more in-depth introduction into multi-signature accounts on Polkadot, please see -[the accounts page section on Multi-sigs](learn-accounts.md#multi-signature-accounts). - -## Parity Signer - -Parity Signer is a secure way of storing your DOT on an air-gapped device. It is highly recommended -that you turn off wifi, cellular network, Bluetooth, NFC, and any other communications methods after -installing it. The device needs to be offline and only you should be viewing the device screen. If -you have any communications methods turned on, you will see an "unshielded" icon in red in the -top-right corner that indicates your connection may not be secure. - -### Create Account - -Click "Create" to create an identity, or "recover" if you have previously backed up the recovery -phrase. You can have multiple identities on one device. Each identity can manage multiple addresses -on different networks. - -![Parity Signer Create Account 1](assets/accounts/ps-create-1.jpg) - -### Name Account - -Input the name for your identity and then click "Create". - -![Parity Signer Create Account 2](assets/accounts/ps-create-2.jpg) - -### Back Up Account - -Parity Signer will then generate a recovery phrase for you and display it in the form of 12 or 24 -words. - -You should write down this recovery phrase on paper and -[store it somewhere safe](#storing-your-key-safely). - -![Parity Signer Create Account 3](assets/accounts/ps-create-3.jpg) - -### Set PIN - -After confirming that you have backed up your seed, a new textbox will appear in which you can set a -PIN. The PIN code should contain at least 6 digits. If the PIN codes do not match, it will not allow -you to create an account. The PIN code will be used when signing any transaction, or to protect -sensitive operations such as deleting an identity or revealing the recovery phrase. - -Note that if someone knows the 12/24 words in your recovery phrase, they will still have control -over your account, even if they do not know the PIN. - -![Parity Signer Create Account 4](assets/accounts/ps-create-4.jpg) - -### Get Address - -Choose which network you would like to create an address for by clicking the name of the network. -For example, if you select "Polkadot", a new Polkadot address will be created for you under this -identity. - -![Parity Signer Create Account 5](assets/accounts/ps-create-5.jpg) - -There is currently no way to copy your address from Parity signer in plain text in order to send it -via text or email. You must use the QR method. - -### Your Address - -The address will be shown as a QR code. You can import your address to the Polkadot-JS Apps by going -to the [Accounts](https://polkadot.js.org/apps/#/accounts) page on an Internet-connected computer -and click "Add via QR", and following the instructions to add the account. An account created this -way will always require you to sign messages with your Parity Signer device. It will do this only by -scanning and displaying QR codes, leaving even someone with total control of your internet-connected -computer has a very small and limited scope for interacting with the Parity Signer device, which can -continue to keep your key safe. - -![Parity Signer Create Account 6](assets/accounts/ps-create-6.jpg) - -## Ledger Hardware Wallet - -To use a Ledger hardware wallet to create your address and keep your tokens in cold storage, follow -the instructions on our [Ledger hardware wallet guide page](learn-ledger.md). - -## Vanity Generator - -The vanity generator is a tool on [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts/vanity) -that lets you generate addresses that contain a specific substring. - -![Vanity Generator page](assets/polkadot_vanity_generator_page.png) - -The vanity generator takes the following parameters: - -- "Search for": The substring that you would like to include in your new address. -- "case sensitive": "Yes" if the search is case sensitive; "no" if not. -- "keypair crypto type": Specifies the type of account you'd like to generate; Schnorrkel is - recommended in most cases for its security. - -If you've filled out all details above and hit the "Start generation" button, a list of accounts -will start generating on your screen. Note that depending on the length of the substring and the -processing speed of your computer, it may take some time before any accounts appear. - -![Vanity Generator search](assets/polkadot_vanity_generate.png) - -The "Save" button will allow you to save the generated accounts - they are not saved if you do not -choose to do this. The next steps are identical to the -[steps above on creating an account on the UI](#polkadotjs), where a password and name need to be -filled in, and a backup file of your account will be downloaded. - -Note that the [Subkey tool](#subkey) also has vanity generation built-in, and is orders of magnitude -faster than the web version. If you need to generate addresses with longer strings, or need plenty -of them, we recommend using Subkey instead. - -![Vanity Generator chosen address](assets/polkadot_save_account.png) diff --git a/docs/learn-accounts.md b/docs/learn-accounts.md deleted file mode 100644 index 49b6ab65374a..000000000000 --- a/docs/learn-accounts.md +++ /dev/null @@ -1,666 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist -on-chain. For a more in-depth explanation of the cryptography behind them, please see -[the cryptography page](learn-cryptography.md). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check -from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix -that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined -[here](). - -It's important to understand that the different formats for different networks are **merely -different representations of the same public key in a private-public keypair** generated by an -address generation tool. This makes the addresses compatible across Substrate-based chains as long -as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find -> them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the -[supported curves and signature schemes](build-protocol-info.md#cryptography). Most wallets take -many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic -phrase in multiple wallets. Wallets that use different steps will arrive at a different set of -addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private -key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to -private key. A typical mnemonic phrase generated by [the Subkey tool](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) is shown below - -```js -"caution juice atom organ advance problem want pledge someone senior holiday very" -``` - -and its corresponding private/public key pair is shown below. - -``` -Secret seed (Private key): 0x056a6a4e203766ffbea3146967ef25e9daf677b14dc6f6ed8919b1983c9bebbc -Public key (SS58): 5F3sa2TJAWMqDhXG6jhV4N8ko9SxwGy8TpaNS1repo5EYjQX -``` - - - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the -entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 -rounds of PBKDF2 on the mnemonic. As such, the same mnemonic may generate different private keys on different wallets, due to the difference in the cryptographic algorithms used. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -If you would like to create and manage several accounts on the network using the same seed, you can use derivation paths. We can think of the derived accounts as child accounts of the root account created using the original mnemonic seed phrase. Many Polkadot key generation tools support hard and soft derivation. For instance, if you intend to create an account to be used on the Polkadot chain, you can derive a **hard key** child account using **//** after the mnemonic phrase. - -```js -"caution juice atom organ advance problem want pledge someone senior holiday very//0" -``` - -and a **soft key** child account using **/** after the mnemonic phrase - -```js -"caution juice atom organ advance problem want pledge someone senior holiday very/0" -``` -If you would like to create another account for usage on the Polkadot chain using the same seed, you can change the number at the end of the string above. For example, `/1`, `/2`, and `/3` will all create different derived accounts. - -You can use any letters or numbers in the derivation path as long as they make sense to you; they do not have to follow any specific pattern. You may also combine multiple derivations in your path, as well. For instance, `//bill//account//1` and `//john/polkadot/initial` are both valid. You will need to know both the seed and the derivation path in order to recreate a derived account, so you should either use a well-defined sequence (e.g. //0, //1, //2...) or be sure to write down any derivation paths you use. - -> It is not possible to generate a derived account without also knowing the derivation path. - -### Soft vs. Hard Derivation - -A soft derivation allows someone to potentially "go backwards" to figure out the private key of the initial account IF they know the private key of the derived account. It is also possible to determine that different accounts generated from the same seed are linked to that seed. A hard derivation path does not allow either of these - even if you know a derived private key, it's not feasible to figure out the private key of the root address, and it's impossible to prove that the first account is linked with the second. Both of these derivation methods have their use cases, given the private keys for all the derived accounts are fully secure. Unless you have a specific need for a soft derivation, it is recommended to generate the account using a hard derivation path. - -See the -[Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and -examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer -support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. -This will generate separate seeds for separate paths, which allows separate signing keys with the -same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may -correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses -unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the -[BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at -> the key for an address. Do not use custom derivation paths unless you are comfortable with your -> understanding of this topic. - - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across -multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible -methods for generating keys and signing messages. If you cannot find understandable documentation, -reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with -BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on -[Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document]() -states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in -Base58-check. If we try to -[decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a -Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is -`000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, -which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of -Polkadot. - -Let's take a look at Substrate addresses. If we decode -`5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get -`2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` -which when -[converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) -is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` -gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first -byte being `02`, just as specified. If we try a Kusama address that starts with a completely -different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the -first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems -counterintuitive that some addresses always have the same prefix and others like Kusama can vary -wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the -[Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used -to generate your account - the accounts are stored only in your browser, so purging the cache will -wipe your accounts as well. You would then have to recreate them using the seed phrase given to you -by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is -using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension -remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget -to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes -beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large -holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so -keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you -can securely stash away the seed phrase for your accounts and remove all traces of the accounts from -your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with -the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is -intended for users comfortable with using the command line and can seem intimidating, but is quite -approachable. Follow the instructions in the -[Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used -properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys -on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible -phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available -[here](learn-ledger.md). - -Alternatively, you might find other wallets on the [Wallet](build-wallets.md) page, but bear in mind -that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the -Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used -for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances -include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` -(`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that -are considered frozen (either `misc_frozen` or `fee_frozen`) and depends on the reason for which the -funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" -amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees -than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The **total** balance of the account is considered to be the sum of `free` and `reserved` funds in -the account. Reserved funds are held due to on-chain requirements and can usually be freed by making -some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity -is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The -account does not exist yet on-chain. For that, it needs the existential deposit: 0.0000333333 KSM -(on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account -will be wiped from the blockchain's state to conserve space, along with any funds in that address. -You do not lose access to the reaped address - as long as you have your private key or recovery -phrase, you can still use the address - but it needs a top-up of another existential deposit to be -able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account -before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot -construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on -Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than -making previews a bit faster. If a folder is completely empty save for such a file, you can remove -the folder to clear junk off your hard drive. That does not mean you lose access to this folder -forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. -It just means you want to keep your computer clean until you maybe end up needing this folder again, -and then recreate it. Your address is like this folder - it gets removed from the chain when nothing -is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember -version of an address. Claiming an index requires a deposit which is released when the index is -cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to -address X, that address will automatically be put into slot 3. Henceforth, you can send me money by -just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other -words, the slot frees up again. If someone creates a new account, they may end up using the same -index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a -deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a -`freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> -Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, -[this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built -into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be -verified by independent registrars to provide trustworthiness. To learn more about how to set or -release an identity, how to define sub-accounts, or how to become a registrar, please read -[this guide](learn-identity.md). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold -storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the -[proxies](learn-proxies.md) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature -account is composed of one or more addresses and a threshold. The threshold defines how many -signatories (participating addresses) need to agree on the submission of an extrinsic in order for -the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and -Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute -any call without Alice. A threshold is typically a number smaller than the total number of members -but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our -> [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One - signer can be on one computer, another can be on another, or in cold storage. This slows down your - interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively - govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A - multi-sig account could be a council member in Kusama's governance, where a set of community - members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or -altering the threshold is not possible and instead requires the dissolution of the current multi-sig -and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can -always calculate the address of a multi-sig just by knowing the members and the threshold, without -the account existing yet. This means one can send tokens to an address that does not exist yet, and -if the entities designated as the recipients come together in a new multi-sig under a matching -threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for -> generating sort the accounts for you, but if you are implementing your own sorting then be aware -> that the public keys are compared byte-for-byte and sorted ascending before being inserted in the -> payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For -a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` -[here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your -inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the -[Account Generation page](learn-account-generation.md#multi-signature-accounts). This is easier than -generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` -should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the -signatories to approve the call before finally executing it. When you create a new call or approve a -call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet -until the call is executed. The reason for the deposit is to place an economic cost on the storage -space that the multi-sig call takes up on the chain and discourage users from creating dangling -multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts -so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = -56 bytes) and the DepositFactor is equal to `deposit(0, 32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the -[Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.3401 | 200880000000 | 3340100000000 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, -Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw -call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` -while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the -call and execute the transaction, he will not need to place the deposit and Alice will receive her -deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](maintain-networks.md#westend-test-network) testnet -and [Polkadot.JS Apps](learn-balance-transfers.md#polkadot-js-apps) to create a 2-of-3 multisig -address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few -> notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that - initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact -book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the -toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig -member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account -to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the -destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate -the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. -Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an -address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', -and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you -click the dropdown under Alice's balance, you will see that a value equivalent to the multisig -deposit has been 'reserved', rendering that value untransferable until the multisig transaction -completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following -from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and - a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his -> computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a -> threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, -and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by -providing the same destination address and transfer amount (together, transaction parameters), -signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of -the transaction and the hash. These transaction parameters will allow Bob to produce and sign the -same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. -Note that 'Multisig message with call (for final approval)' is automatically enabled; this means -that, since the transaction will reached the signature threshold, it will execute the actual -transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has -released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different -networks. - -(placeholder for address changer) -
- - - -
- -Alternatively, use this [handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or -this [simple address convertor](https://polkadot-address-convertor.netlify.app/). - -### How to Verify a Public Key's Associated Address - -You can verify your public key's associated address through a series of inspection steps, where the -key is a base-16 (hexadecimal) address. - -#### Using Subkey to Retrieve Public Key from SS58 Address - -This is to showcase that the **SS58 address is based on the public key (aka "Account ID")** - -The Subkey Tool's -[Inspecting Keys](https://substrate.dev/docs/en/knowledgebase/integrate/subkey#inspecting-keys) -section explains how to use the `inspect` command to recalculate your key pair's public key and -address. - -Start by inspecting your account's Polkadot address by running the inspect command against your -account's address: - -```bash -$ subkey inspect 1a1LcBX6hGPKg5aQ6DXZpAHCCzWjckhea4sz3P1PvL3oc4F - -Public Key URI `1a1LcBX6hGPKg5aQ6DXZpAHCCzWjckhea4sz3P1PvL3oc4F` is account: - Network ID/version: polkadot - Public key (hex): 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce - Account ID: 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce - SS58 Address: 1a1LcBX6hGPKg5aQ6DXZpAHCCzWjckhea4sz3P1PvL3oc4F -``` - -Take note of the hexadecimal string for "Public key (hex)". This is your account's public key. - -Running the `inspect` command on your public key, the default SS58 address that is returned the -associated Substrate address. - -```bash -$ subkey inspect 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce - -Secret Key URI `0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce` is account: - Secret seed: 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce - Public key (hex): 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c - Account ID: 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c - SS58 Address: 5E6kwKEhrpVMnZvkBRFCzCcRnMXcft4HSaogYQtgtaw6QJ5s -``` - -Using the `--network` flag, you can define the network that you would like to inspect, where the -SS58 address will be based on that network. Now, running the `inspect` command with -`--network polkadot` return your original Polkadot address, thus verifying the public key. - -```bash -subkey inspect 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce --network polkadot - -Secret Key URI `0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce` is account: - Secret seed: 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce - Public key (hex): 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c - Account ID: 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c - SS58 Address: 13345eVmibkqE6wG94JD8MSadyXGNBcRX5YAhht3Sfxcaw9U -``` - -You will notice that the Subkey Tool recognizes the correct network of the address and returns the -associated public key. The public key is returned as a hexadecimal string (i.e. prefixed with -**"0x"**). **For both SS58 addresses, the same public key is returned.** - -#### Address Verification - -##### Consider the following example: - -![17](assets/accounts/pubkey-1.png) - -If you are comfortable enough to distinguish between each account parameter, you can prefix the -public key string with **"0x"** on your own: - -From: -`Pay DOTs to the Polkadot account:192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce`, -we prefix the address by "0x" -> -`0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce`. - -Using the [handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform), you can verify -both address associations to your public key. Copy your public key into the "Input Account or Public -Key" textbox and click "Transform" at the bottom. On the right-hand side, the addresses for Polkadot -and Substrate that are returned based on your public key should match with the ones you inspected. - -![18](assets/accounts/pubkey-2.png) - -> Note: You may have to scroll down to the bottom of the menu to find the Substrate address based on -> the menu listings. You will notice that there are many networks that also use the same Substrate -> address. - -You can verify your own public key verification by recalling that Polkadot addresses start with a -'1', whereas Substrate addresses generally start with a '5' (Kusama addresses start with a capital -letter). See [Addresses](learn-accounts.md#address-format) for more details. - -Furthermore, the [Utility Scripts](https://github.com/w3f/utility-scripts) can be referenced for how -the verification is performed: -[pubkeyToAddress.js](https://github.com/w3f/utility-scripts/blob/master/src/misc/pubkeyToAddress.js) -demonstrates how a Polkadot, Substrate, or Kusama address is interpreted by a single public key. - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An - explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill - Laboon and Chinmay Patel of BlockX Labs. diff --git a/docs/learn-architecture.md b/docs/learn-architecture.md deleted file mode 100644 index 30e1d5793d32..000000000000 --- a/docs/learn-architecture.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -id: learn-architecture -title: Architecture -sidebar_label: Architecture ---- - -Polkadot is a heterogeneous multichain with shared security and interoperability. - -# Components - -## Relay Chain - -The Relay Chain is the central chain of Polkadot. All validators of Polkadot are staked on the Relay -Chain in DOT and validate for the Relay Chain. The Relay Chain is composed of a relatively small -number of transaction types that include ways to interact with the governance mechanism, parachain -auctions, and participating in NPoS. The Relay Chain has deliberately minimal functionality - for -instance, smart contracts are not supported. The main responsibility is to coordinate the system as -a whole, including parachains. Other specific work is delegated to the parachains, which have -different implementations and features. - -## [Parachain](learn-parachains.md) and [Parathread](learn-parathreads.md) Slots - -Polkadot can support a number of execution slots. These slots are like cores on a computer's -processor (a modern laptop's processor may have eight cores, for example). Each one of these cores -can run one process at a time. Polkadot allows these slots using two subscription models: parachains -and parathreads. Parachains have a dedicated slot (core) for their chain and are like a process that -runs constantly. Parathreads share slots amongst a group, and are thus more like processes that need -to be woken up and run less frequently. - -Most of the computation that happens across the Polkadot network as a whole will be delegated to -specific parachain or parathread implementations that handle various use cases. Polkadot places no -constraints over what parachains can do besides that they must be able to generate a proof that can -be validated by the validators assigned to the parachain. This proof verifies the state transition -of the parachain. Some parachains may be specific to a particular application, others may focus on -specific features like smart contracts, privacy, or scalability — still, others might be -experimental architectures that are not necessarily blockchain in nature. - -Polkadot provides many ways to secure a slot for a parachain slot for a particular length of time. -Parathreads are part of a pool that shares slots and must-win auctions for individual blocks. -Parathreads and parachains have the same API; their difference is economic. Parachains will have to -reserve DOT for the duration of their slot lease; parathreads will pay on a per-block basis. -Parathreads can become parachains, and vice-versa. - -### [Shared Security](learn-security.md) - -Parachains connected to the Polkadot Relay Chain all share in the security of the Relay Chain. -Polkadot has a shared state between the Relay Chain and all of the connected parachains. If the -Relay Chain must revert for any reason, then all of the parachains would also revert. This is to -ensure that the validity of the entire system can persist and no individual part is corruptible. - -The shared state makes it so that the trust assumptions when using Polkadot parachains are only -those of the Relay Chain validator set and no other. Since the validator set on the Relay Chain is -expected to be secure with a large amount of stake put up to back it, parachains should benefit from -this security. - -## [Bridges](learn-bridges.md) - -A blockchain [bridge](glossary.md##bridge) is a connection that allows for arbitrary data to -transfer from one network to another. These chains are interoperable through the bridge but can -exist as standalone chains with different protocols, rules, and governance models. In Polkadot, -bridges connect to the relay chain and are secured through the Polkadot consensus mechanism, -maintained by [collators](##collators). - -Polkadot uses bridges to bridge the future of Web 3.0, as bridges are fundamental to Polkadot's -interoperable architecture by acting as a [secure and robust] communication channel for chains in -isolation. - -# Main Actors - -## Validators - -[Validators](glossary.md##validator), if elected to the validator set, produce blocks on the Relay -Chain. They also accept proofs of valid state transition from collators. In return, they will -receive staking rewards. - -## Nominators - -[Nominators](glossary.md##nominator) bond their stake to particular validators in order to help them -get into the active validator set and thus produce blocks for the chain. In return, nominators are -generally rewarded with a portion of the staking rewards from that validator. - -## Collators - -[Collators](glossary.md##collator) are full nodes on both a parachain and the Relay Chain. They -collect parachain transactions and produce state transition proofs for the validators on the Relay -Chain. They can also send and receive messages from other parachains using XCMP. - ---- - -## Whiteboard Series - -For a video overview of the architecture of Polkadot watch the video below for the whiteboard -interview with W3F researcher Alistair Stewart: - - diff --git a/docs/learn-availability.md b/docs/learn-availability.md deleted file mode 100644 index a2adae95c492..000000000000 --- a/docs/learn-availability.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be -efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are five phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the -validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and -> must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that -parachain's registered code. If the verification succeeds, then the validators will pass the -candidate block to the other validators in the gossip network. However, if the verification fails, -the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is -a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will -eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure-coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable -length. It is enough information for anyone that obtains the full PoV block to verify the state -transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the -[erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report -that they possess their piece of the code word. Once this threshold of validators has been reached, -the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be -recovered from a subset of the code and in absence of some portion of the code. A code is the -original message padded with some extra data that enables the reconstruction of the code in the case -of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon][reed solomon] -codes, which already enjoys a battle-tested application in technology outside the blockchain -industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct -any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without -requiring all validators to keep tabs on all the parachains. Instead, validators share smaller -pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the -validators can provide their pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full -parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen: Deprecated - -The idea of Fishermen is that they are full nodes of parachains, like collators, but perform a different role in relation to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. - -**Fishermen are not available on Kusama or Polkadot and are not planned for formal implementation, depsite previous proposals in the [AnV protocol](https://w3f-research.readthedocs.io/en/latest/polkadot/Availability_and_Validity.html).** - -## Further Resources - -- [Path of a Parachain Block][life of] - Article by Parity analyst Joe Petrowski expounding on the - validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity][anv paper] - Paper by the W3F Research Team that specifies the - availability and validity protocol in detail. - -[reed solomon]: https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction -[pruning]: https://example.org -[life of]: https://polkadot.network/the-path-of-a-parachain-block/ -[anv paper]: - https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV diff --git a/docs/learn-balance-transfers.md b/docs/learn-balance-transfers.md deleted file mode 100644 index 53ef00922ce2..000000000000 --- a/docs/learn-balance-transfers.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start -transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've -already [created an account](learn-account-generation.md) and have some funds that are ready to be -transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network, but this is the same process for -> Kusama. If you would like to switch to a different network, you can change it by clicking the top -> left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the **minimum amount of funds you must keep in the account -for it to remain active.** See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer -is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](./glossary.md#extrinsic) level, there are two main ways to transfer funds from one -account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to -send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount -that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from -cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do -not want to keep this account alive (for example, because you are moving all of your funds to a -different address). In this case, click on the "keep-alive" toggle at the bottom of the modal -window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` -will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As -a common use case for using normal transfers is to entirely clear out the account, a second toggle -will appear if you have the keep-alive check turned off that will send all the tokens in the -account, minus a transaction fee, to the destination address. - -Attempting to send less than the existential deposit to an account with 0 DOT will always fail, no -matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an -account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential -deposit of 1 DOT and the account cannot be initialized with such a low balance. - -> NOTE: Even if the transfer fails due to a keep-alive check, the transaction fee will be deducted -> from the sending account if you attempt to transfer. - -### Existing Reference Error - - - - - -If you are trying to reap an account and you recieve an error similar to "There is an existing -reference count on the sender account. As such the account cannot be reaped from the state", then -you have existing references to this account that must first be removed before it can be reaped. -References may still exist from: - -- Bonded tokens (most likely) -- Unpurged session keys (if you were prevously a validator) -- Token locks -- Existing recovery info -- Existing assets - -#### Bonded Tokens - -If you have tokens that are bonded, you will need to unbond them before you can reap your account. -Follow the instructions at [Unbonding and Rebonding](maintain-guides-how-to-unbond.md) to check if -you have bonded tokens, stop nominating (if necessary) and unbond your tokens. - -#### Purging Session Keys - -If you used this account to set up a validator and you did not purge your keys before unbonding your -tokens, you need to purge your keys. You can do this by seeing the -[How to Stop Validating](maintain-guides-how-to-stop-validating.md) page. This can also be checked -by checking `session.nextKeys` in the chain state for an existing key. - -#### Checking for Locks - -You can check for locks by querying `system.account(AccountId)` under `Developer > Chain state`. -Select your account, then click the "+" button next to the dropdowns, and check the relative `data` -JSON object. If you see a non-zero value for anything other than `free`, you have locks on your -account that need to get resolved. - -You can also check for locks by navigating to `Accounts > Accounts` in -[PolkadotJS Apps](https://polkadot.js.org/apps/#/). Then, click the dropdown arrow of the relevant -account under the 'balances' column. If it shows that some tokens are in a 'locked' state, you can -see why by hovering over the information icon next to it. - -#### Existing Recovery Info - -Currently, {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} does not use the -[Recovery Pallet](https://substrate.dev/docs/en/knowledgebase/runtime/frame#recovery), so this is -probably not the reason for your tokens having existing references. - -{{ kusama: On Kusama, you can check if recovery has been set up by checking the `recovery.recoverable(AccountId)` -chain state. This can be found under `Developer > Chain state` in [PolkadotJS Apps][polkadot-js apps]. :kusama }} - -#### Existing {{ polkadot: Non-DOT :polkadot }} {{ kusama: Non-KSM :kusama }} Assets - -Currently, {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} does not use the -[Assets Pallet](https://substrate.dev/docs/en/knowledgebase/runtime/frame#assets), so this is -probably not the reason for your tokens having existing references. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located -on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account -you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly -and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the -top-right corner of the screen when the transfer is included in a block. - -[polkadot-js apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/docs/learn-bridges.md b/docs/learn-bridges.md deleted file mode 100644 index ce46867dddbf..000000000000 --- a/docs/learn-bridges.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges -are ways for two economically sovereign and technologically diverse chains to communicate with each -other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more -decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however -there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has -not been too many that have been used heavily in production. For this reason, you can consider this -page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains -> such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native -> interoperability technology that allows parachains to trustlessly communicate, please see the -> dedicated [crosschain][] page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the -following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (e.g. Kusama `\<\>` Polkadot - bridge, since both networks' parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the - non-Substrate chain to bridge (e.g. Ethereum mainnet will have a bridge smart contract that - initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (e.g. Bitcoin), you - should use [XClaim][xclaim] or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a -Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level -parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama `\<\>` Polkadot -bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot -(non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is -possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, -etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge][] and the -efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a -combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers -of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum -chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance -denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract -on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check -> out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM][xclaim]) can be used to bridge, but should only be used when -other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by -a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since -it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts \<\> Polkadot) - -As explained by Dr. Gavin Wood in a [blog post][eth bridging blog] from late 2019, there are three -ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM \<\> Substrate \<\> Polkadot) - -The Interlay team has written a [specification][interlay] on a Bitcoin bridge that is based on the -[XCLAIM][] design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It -allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to -burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different -components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -There is now a -[reference implementation and testnet available](https://medium.com/interlay/polkabtc-beta-testnet-launch-2cc9ea7431b7). - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be -funding available from the W3F [grants program][]. Please first check that the chain you are -intending to bridge between hasn't already been built or is in the process of being built by another -team. More popular chains with clear use cases will be given priority, and novel bridge designs are -welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge - were awarded a grant in W3F Grants [Wave 5][] to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin \<\> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge][bifrost] - The Bifrost team was awarded a grant in W3F Grants [Wave 5][] to build a - bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded - a grant in [Wave 5][] to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge][interlay] - The Interlay team was awarded a grant in W3F grants [Wave 5][] - to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xpallets/gateway/bitcoin) - - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA - Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to - Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM][] - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges - using cryptocurrency-backed assets. - -[crosschain]: learn-crosschain.md -[parity bridge]: https://github.com/paritytech/parity-bridge -[interlay]: https://interlay.gitlab.io/polkabtc-spec/ -[xclaim]: https://eprint.iacr.org/2018/643.pdf -[bifrost]: https://github.com/bifrost-codes/bifrost -[wave 5]: https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096 -[eth bridging blog]: - https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13 -[grants program]: https://github.com/w3f/General-Grants-Program diff --git a/docs/learn-consensus.md b/docs/learn-consensus.md deleted file mode 100644 index a853503ba56e..000000000000 --- a/docs/learn-consensus.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: learn-consensus -title: Polkadot Consensus -sidebar_label: Polkadot Consensus -description: An explanation of the consensus model used in Polkadot and Kusama ---- - -## Why do we need consensus? - -Consensus is a method for coming to agreement over a shared state. In order for the state of the -blockchain to continue to build and move forward, all nodes in the network must agree and come to -consensus. It is the way that the nodes in a decentralized network are able to stay synced with each -other. Without consensus for the decentralized network of nodes in a blockchain, there is no way to -ensure that the state one node believes is true will be shared by the other nodes. Consensus aims to -provide the _objective_ view of the state amid participants who each have their own _subjective_ -views of the network. It is the process by which these nodes communicate and come to agreement, and -are able to build new blocks. - -## What are PoW and PoS? - -Proof of Work (PoW) and Proof of Stake (PoS) have been inaccurately used as short hand to refer to -consensus mechanisms of blockchains, but that does not capture the full picture. PoW is the method -for agreeing on a block author and part of the fuller [Nakamoto consensus](#nakamoto-consensus) that -also encompasses a chain selection algorithm (longest chain rule in Bitcoin). Similarly, PoS is a -set of rules for selecting the validator set and does not specify a chain selection rule or how a -chain might reach finality. PoS algorithms have traditionally been paired with an algorithm for -coming to Byzantine agreement between nodes. For example, [Tendermint](learn-comparisons-cosmos.md) -is a practical Byzantine fault tolerant algorithm that uses PoS as its validator set selection -method. - -## Why not Proof of Work? - -Although simple and effective in coming to a decentralized consensus on the next block producer, -proof of work with Nakamoto consensus consumes an incredible amount of energy, has no economic or -provable finality, and has no effective strategy in resisting cartels. - -## Probabilistic vs. provable finality - -A pure Nakamoto consensus blockchain that runs PoW is only able to achieve the notion of -_probabilistic finality_ and reach _eventual consensus_. Probabilistic finality means that under -some assumptions about the network and participants, if we see a few blocks building on a given -block, we can estimate the probability that it is final. Eventual consensus means that at some point -in the future, all nodes will agree on the truthfulness of one set of data. This eventual consensus -may take a long time and will not be able to be determined how long it will take ahead of time. -However, finality gadgets such as GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) -or Ethereum's Casper FFG (the Friendly Finality Gadget) are designed to give stronger and quicker -guarantees on the finality of blocks - specifically, that they can never be reverted after some -process of Byzantine agreements has taken place. The notion of irreversible consensus is known as -_provable finality._ - -In the [GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf), it is phrased -in this way: - -> We say an oracle A in a protocol is _eventually consistent_ if it returns the same value to all -> participants after some unspecified time. - -## What is GRANDPA/BABE? - -### Hybrid Consensus - -There are two protocols we use when we talk about the consensus protocol of Polkadot, GRANDPA and -BABE (Blind Assignment for Blockchain Extension). We talk about both of these because Polkadot uses -what is known as _hybrid consensus_. Hybrid consensus splits up the finality gadget from the block -production mechanism. - -This is a way of getting the benefits of probabilistic finality (the ability to always produce new -blocks) and provable finality (having a universal agreement on the canonical chain with no chance -for reversion) in Polkadot. It also avoids the corresponding drawbacks of each mechanism (the chance -of unknowingly following the wrong fork in probabilistic finality, and a chance for "stalling" - not -being able to produce new blocks - in provable finality). By combining these two mechanisms, -Polkadot allows for blocks to be rapidly produced, and the slower finality mechanism to run in a -separate process to finalize blocks without risking slower transaction processing or stalling. - -Hybrid consensus has been proposed in the past. Notably, it was proposed (now defunct) as a step in -Ethereum's transition to proof of stake in [EIP 1011](http://eips.ethereum.org/EIPS/eip-1011), which -specified [Casper FFG](#casper-ffg). - -### BABE - -BABE (Blind Assignment for Blockchain Extension) is the block production mechanism that runs between -the validator nodes and determines the authors of new blocks. BABE is comparable as an algorithm to -Ouroboros Praos, with some key differences in chain selection rule and slot time adjustments. BABE -assigns block production slots to validators according to stake and using the Polkadot -[randomness cycle](learn-randomness.md). - -Validators in Polkadot will participate in a lottery in every slot that will tell them whether or -not they are the block producer candidate for that slot. Slots are discrete units of time, nominally -6 seconds in length. Because of this randomness mechanism, multiple validators could be candidates -for the same slot. Other times, a slot could be empty, resulting in inconsistent block time. - -#### Multiple Validators per Slot - -When multiple validators are block producer candidates in a given slot, all will produce a block and -broadcast it to the network. At that point, it's a race. The validator whose block reaches most of -the network first wins. Depending on network topology and latency, both chains will continue to -build in some capacity, until finalization kicks in and amputates a fork. See Fork Choice below for -how that works. - -#### No Validators in Slot - -When no validators have rolled low enough in the randomness lottery to qualify for block production, -a slot can remain seemingly blockless. We avoid this by running a secondary, round-robin style -validator selection algorithm in the background. The validators selected to produce blocks through -this algorithm always produce blocks, but these _secondary_ blocks are ignored if the same slot also -produces a primary block from a [VRF-selected](learn-randomness.md) validator. Thus, a slot can have -either a _primary_ or a _secondary_ block, and no slots are ever skipped. - -For more details on BABE, please see the -[BABE paper](https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html). - -### GRANDPA: Finality gadget - -GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is the finality gadget that is -implemented for the Polkadot Relay Chain. - -It works in a partially synchronous network model as long as 2/3 of nodes are honest and can cope -with 1/5 Byzantine nodes in an asynchronous setting. - -A notable distinction is that GRANDPA reaches agreements on chains rather than blocks, greatly -speeding up the finalization process, even after long-term network partitioning or other networking -failures. - -In other words, as soon as more than 2/3 of validators attest to a chain containing a certain block, -all blocks leading up to that one are finalized at once. - -#### Protocol - -Please refer to [the GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) -for a full description of the protocol. - -#### Implementation - -The -[Substrate implementation of GRANDPA](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs) -is part of Substrate Frame. - -### Fork Choice - -Bringing BABE and GRANDPA together, the fork choice of Polkadot becomes clear. BABE must always -build on the chain that has been finalized by GRANDPA. When there are forks after the finalized -head, BABE provides probabilistic finality by building on the chain with the most primary blocks. - -![Best chain choice](assets/best_chain.png) - -In the above image, the black blocks are finalized, and the yellow blocks are not. Blocks marked -with a "1" are primary blocks; those marked with a "2" are secondary blocks. Even though the topmost -chain is the longest chain on the latest finalized block, it does not qualify because it has fewer -primaries at the time of evaluation than the one below it. - -## Comparisons - -### Nakamoto consensus - -Nakamoto consensus consists of the longest chain rule using proof of work as its sybil resistance -mechanism and leader election. - -Nakamoto consensus only gives us probabilistic finality. Probabilistic finality states that a block -in the past is only as safe as the number of confirmations it has, or the number of blocks that have -been built on top of it. As more blocks are built on top of a specific block in a Proof of Work -chain, more computational work has been expended behind this particular chain. However, it does not -guarantee that the chain containing the block will always remain the agreed-upon chain, since an -actor with unlimited resources could potentially build a competing chain and expend enough -computational resources to create a chain that did not contain a specific block. In such a -situation, the longest chain rule employed in Bitcoin and other proof of work chains would move to -this new chain as the canonical one. - -### PBFT / Tendermint - -Please see the [relevant section](learn-comparisons-cosmos.md#consensus) in the Cosmos comparison -article. - -### Casper FFG - -The two main differences between GRANDPA and Casper FFG are: - -- in GRANDPA, different voters can cast votes simultaneously for blocks at different heights -- GRANDPA only depends on finalized blocks to affect the fork-choice rule of the underlying block - production mechanism - -## Resources - -- [BABE paper](https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html) - The - academic description of the BABE protocol. -- [GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) - The academic - description of the GRANDPA finality gadget. Contains formal proofs of the algorithm. -- [Rust implementation](https://github.com/paritytech/finality-grandpa) - The reference - implementation and the accompanying - [Substrate pallet](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs). -- [Block Production and Finalization in Polkadot](https://www.crowdcast.io/e/polkadot-block-production) - - An explanation of how BABE and GRANDPA work together to produce and finalize blocks on Kusama, - with Bill Laboon. -- [Block Production and Finalization in Polkadot: Understanding the BABE and GRANDPA Protocols](https://www.youtube.com/watch?v=1CuTSluL7v4&t=4s) - - An academic talk by Bill Laboon, given at MIT Cryptoeconomic Systems 2020, describing Polkadot's - hybrid consensus model in-depth. diff --git a/docs/learn-crosschain.md b/docs/learn-crosschain.md deleted file mode 100644 index 2700d8b4f630..000000000000 --- a/docs/learn-crosschain.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -id: learn-crosschain -title: Cross-chain Message Passing (XCMP) -sidebar_label: Cross-chain Message Passing (XCMP) ---- - -Cross-chain transactions are resolved using a simple queuing mechanism based around a Merkle tree to -ensure fidelity. It is the task of the Relay Chain validators to move transactions on the output -queue of one parachain into the input queue of the destination parachain. However, only the -associated metadata is stored as a hash in the Relay Chain storage. - -The input and output queue are sometimes referred to in the codebase and associated documentation as -`ingress` and `egress` messages respectively. - -## Overview of XCMP - -XCMP is currently under development and the details are subject to change. However, the overall -architecture and design decisions are as follows: - -- Cross-chain messages will _not_ go on to the Relay Chain. -- Cross-chain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching - parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other - parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest - ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the - processing of the expected ingress messages to that parachain. - -XCMP queues must be initiated by first opening a channel between two parachains. The channel is -identified by both the sender and recipient parachains, meaning that it's a one-way channel. A pair -of parachains can have at most two channels between them, one for sending messages to the other -chain and another for receiving messages. The channel will require a deposit in DOT to be opened, -which will get returned when the channel is closed. - -## XCMP-Lite (HRMP) - -While XCMP is still being implemented, a stop-gap protocol (see definition below) known as -**Horizontal Relay-routed Message Passing (HRMP)** exists in its place. HRMP has the same interface -and functionality as XCMP but is much more demanding on resources since it stores all messages in -the Relay Chain storage. When XCMP has been implemented, HRMP is planned to be deprecated and phased -out in favor of it. - -> Note: A stop-gap protocol is a temporary substitute for the functionality that is not fully -> complete. While XCMP proper is still in development, HRMP is a working replacement. - -## Vertical Message Passing - -There are two kinds of Vertical Message Passing, Upward Message Passing (UMP) and Downward Message -Passing (DMP). UMP is used when a message originates on a parachain or a parathread to go from that -parachain up to the Relay Chain. DMP is used to go the other way around, when a message originates -from the Relay Chain and is destined for a parachain. Messages that are passed via DMP may originate -from a parachain. In which case, first UMP is used to communicate the message to the Relay Chain and -DMP is used to move it down to another parachain. - -## XCMP Message Format - -For a description of the XCMP message format please see the [xcm-format][] repository on GitHub. - -## How To Make Cross Chain Transfers - -You can try out cross-chain transfers on the the [Rococo](build-parachains-rococo.md) testnet. A -tutorial on downward, upward, and lateral transfers can be found -[here](build-parachains-rococo.md#how-to-make-cross-chain-transfers). - -## High-Level XCMP - -A smart contract that exists on parachain A will route a message to parachain B in which another -smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A, which initiates a new cross-chain message for -the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new cross-chain message into its outbound messages -queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages -(filtering by the `destination` field). When the collator of parachain B makes its next ping, it -will see this new message on parachain A and add it into its own inbound queue for processing into -the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for -parachain B will do the same. This is so that they will be able to verify the message transmission -happened. - -When the collator of parachain B is building the next block in its chain, it will process the new -message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset -transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was -processed. If the message was processed and all other aspects of the block are valid, the validator -will include this block for parachain B into the Relay Chain. - -Check out our animated video below that explores how XCMP works. - - - - - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/XCMP.html) - Full technical - description of cross-chain communication on the Web3 Foundation research wiki. -- [Messaging Overview](https://w3f.github.io/parachain-implementers-guide/messaging.html) - An - overview of the messaging schemes from the Parachain Implementor's guide. -- [XCM Format](https://github.com/paritytech/xcm-format) - Description of the high-level XCM format - sent via XCMP. - -[xcm-format]: https://github.com/paritytech/xcm-format diff --git a/docs/learn-cryptography.md b/docs/learn-cryptography.md deleted file mode 100644 index 246d7583cb9d..000000000000 --- a/docs/learn-cryptography.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some -knowledge about cryptographic primitives that are generally used in blockchains such as hashes, -elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used in Polkadot please see the more advanced -[research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is -[Blake2b](). Blake2 is considered to be -a very fast cryptographic hash function that is also used in the cryptocurrency -[Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as -its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses -Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits -over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set -and security assumptions. Additionally, it allows for native multisignature through -[signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the -[Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the -[Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 -curves like Curve25519. diff --git a/docs/learn-dyor.md b/docs/learn-dyor.md deleted file mode 100644 index 684e28472ce9..000000000000 --- a/docs/learn-dyor.md +++ /dev/null @@ -1,361 +0,0 @@ ---- -id: learn-dyor -title: How to Do Your Own Research (DYOR) -sidebar_label: How to Do Your Own Research ---- - -Many projects are being built, or intend to build, on both Polkadot and Kusama. However, many claim -to do so but have either no such intention, they don't have the resources to pull it through, or -they're outright trying to scam people by misusing the Polkadot and Kusama brands. - -Telling legitimate projects from the "not so honest" ones isn't always an easy task. This guide is -meant to help you find out how to do your research better when you come across a project that seems -interesting. What it's **not** meant to do, is label any single project as legitimate or not, or -make that decision for you. - -Furthermore, a legitimate project doesn't necessarily mean it will also be a successful one, and -**this guide is not meant to be viewed as financial or investment advice.** - -### "Powered by Polkadot" or "Polka" prefix clarification - -The statement "Powered by Polkadot" on many projects' sites is often a cause of confusion. This -usually means that the project is building, or intends to build, on the Polkadot ecosystem, using -[Substrate](https://substrate.dev). But any project can claim that, so the existence of this -statement on a project's site infers no information about the project's legitimacy, and it's -certainly not a "seal of approval" by Web3 Foundation. - -The same thing goes for projects that have the "Polka" prefix in their name. Many projects use that -to associate themselves with the ecosystem, some legitimately and others only to piggyback on -Polkadot's reputation. - -## "Hard" metrics to look for when you DYOR - -#### 1. Association with entities you trust - -New projects usually try to increase their credibility by associating themselves with well-known -entities. The thinking is simple: "These entities that have a good reputation trust us, so if you -trust them, by association, you should trust us too". Indeed, association with a trusted entity can -be a strong indicator of the legitimacy of a project. - -For example, if a project has received a -[Web3 Foundation Grant](https://github.com/w3f/Open-Grants-Program) and has achieved at least one -milestone, this is an indication that the project is indeed building on the Polkadot ecosystem, and -if they have delivered all of their milestones, then their code is most likely of reasonable -quality. - -And Web3 Foundation is not the only entity in the ecosystem that gives grants. There are other -reputable teams in the ecosystem that have developed platforms or prospective parachains and give -[grants](https://github.com/w3f/Open-Grants-Program#other-grant-programs) for projects to build on -or expand their project. These are also indicators that a project is committed to building on the -broader Polkadot ecosystem. - -Or receiving funding from VCs that you trust and are known to be involved with other reputable -Polkadot projects can also be a good indicator. Or participating in the -[Substrate Builders Program](https://www.substrate.io/builders-program/). - -**However**, claiming such associations and having them is not always the same thing. **You always -need to verify any claims a project makes**, and that's probably the most critical takeaway from -this guide. - -For example, if a project has the -[Web3 Foundation Grant badge](https://github.com/w3f/General-Grants-Program/blob/master/grants/grant-badge-guidelines.md) -on their site or claims to have received a grant, check to see if they have received one and that it -hasn't been terminated. The complete list of projects that have successfully applied for a grant can -be found -[here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md), -where you can see what each project has delivered and if, perhaps, their grant has been terminated. - -The same thing goes for VC funding or another grant, or any advertised association for that matter. -Check on the corresponding sites to make sure such claims are valid. - -Also, make sure you understand the _scope_ of the association. Going back to the Web3 grants -example, they have a precise scope. They are granted for specific deliverables, and the review team -only checks the code and evaluates these deliverables _of the particular project_. To make this more -tangible, you can check the scope of every Open Grants project -[here](https://github.com/w3f/Open-Grants-Program/tree/master/applications) and their evaluations -[here](https://github.com/w3f/Grant-Milestone-Delivery/tree/master/evaluations). - -So, having received a Web3 grant provides no information about the general practices of a team, the -longevity of the project besides the scope of the grant, or other projects the team might be -building, which is why the badge rules clearly state that it shouldn't be displayed on the team's -landing page. - -Similarly, if a project claims to have partnered with a reputable entity, verify its scope and if it -is indeed a partnership by searching their site for projects they have partnered with, their press -releases, or by contacting them directly. And if you see such claims about Web3 Foundation, you can -be sure they're false because Web3 Foundation **does not** partner with, or endorse, ecosystem -projects. - -#### 2. Open source - -An open-source project promotes transparency, builds trust, and ensures the project team isn't doing -something suspicious behind the scenes. Additionally, it makes it very easy to track the project's -progress and see how active the team is in developing it. - -That doesn't mean, though, that any closed source project isn't legitimate or the team behind it has -something to hide. Many teams choose to keep their code private to protect their intellectual -property. Several teams that wish to keep what what they're doing under wraps apply for a -[General Grant](https://github.com/w3f/General-Grants-Program). The applications are private, as is -their evaluation by the review team, but their deliverables are still open source. - -Another thing that an open-source project allows you to see is if they have copied any code from -other open sources. This isn't necessarily bad, since no one re-invents the wheel, but copied code -should attribute to the source. If it doesn't, this should raise some red flags because the project -team tries to feign expertise by passing someone else's code as their own. - -A forked repo is easy to spot since it points to the original repo, but partially copied code might -not be as easy to find. A quick -[search](https://duckduckgo.com/?q=search+for+copied+source+code+plagiarism&t=ffab&ia=web) can -provide you with some ways and tools to look for plagiarism. - -So, a project being closed source isn't necessarily a red flag, it just limits the ability to verify -the project in that regard, but there are indirect ways as described below. However, a project being -open source is undoubtedly a good, strong indicator of its legitimacy because shady or poor -practices seldom stay hidden for long in open source code. - -#### 3. Active development - -If a project team constantly updates their product, it is always a good indication that they are -serious and passionate about building. Regularly releasing new features and upgrades, fixing bugs, -updating their site and notifying the community of these changes are good earmarks of a legitimate -project. - -Additionally, active development _usually_ also means good development to be used as an _indirect_ -indicator for a closed source project. - -An open-source project, of course, provides the ability to monitor the development activity through -its GitHub repo directly. - -#### 4. Solid documentation - -The existence of solid documentation should be considered mandatory for any project that wants to be -taken seriously. A couple of years ago, this meant a whitepaper, but lately, we've seen a shift to -other forms of documentation, like wiki pages describing the various aspects. - -No matter the form of the documentation, it needs to exist, and the more detailed it is, the better. -This is where the project is explained in detail, and the prospective investor and user can read how -it works, its goals and how the team aims to attain them. - -The documentation will give you an idea of the technical expertise of the team, too. If they analyse -their technology and the technical aspects, they indicate that they know what they're doing. On the -other hand, if they focus only on tokenomics or analyse their project only in broad, vague terms, -perhaps that's an indication that they don't have a clear path to their goals. - -If you're looking for an example of what good documentation looks like, look no further than our own -[wiki](https://wiki.polkadot.network). Of course, you shouldn't expect to find such extensive -documentation on newly launched projects. Our wiki, after all, covers a whole ecosystem and was -populated over the course of years. And it's still updated all the time. But it's a good example of -the emphasis a good project should give on documentating what it does and how. - -#### 5. Reputable team - -Some teams display their team members prominently on their site, along with their social media -profiles (usually LinkedIn) and GitHub accounts, for development team members. This gives -prospective users and investors the ability to verify the team's credentials, track records and -expertise. - -But the keyword here is **verify**! Don't take what you see on the project's team at face value. -Look them up and verify their track record. Do a Google search for the team members mentioned. If it -comes up empty, or the only results are regarding the project, it's an indication that their team -members are fake. Their photos on their site, if there are any, will also probably be stock photos, -or in other words, also fake. These are usually easily recognisable, but here is a -[guide](https://helpdeskgeek.com/how-to/free-reverse-image-search-tools/) on how to do a reverse -image search, if you want to be thorough. - -In some other cases, some developers prefer to maintain their anonymity, using pseudonyms, or the -team members aren't mentioned at all. This isn't necessarily a bad thing. Perhaps the team is a -strong proponent of privacy, or they want their work to speak for itself. Still, you should try and -find out who's behind the project and what they're doing. For developers, their Github activity -might speak louder than being mentioned by name. Other team members might be heavily engaged in -their community, providing guidance and answers, which is always a good sign. - -But if the team are ghosts that don't show up anywhere and only engage with the community through -proxies, that's a red flag right there, and you should be very sceptical. - -Besides their community, projects that are serious about building on Polkadot usually engage with -the broader Polkadot community. They are active in the various -[Polkadot and Kusama channels](https://wiki.polkadot.network/docs/community/), and some of them are -[Polkadot Ambassadors](https://polkadot.network/polkadot-ambassador-program/), or generally -prominent members of the ecosystem. - -#### 6. Clear integration with Polkadot - -There are many ways for a project to build on Polkadot and Kusama. Perhaps the most direct one is to -aim to become a parachain. Some of the most notable Polkadot projects are already parachains on -Kusama or gearing up to become one, and most of them will shoot for a Polkadot parachain too when -they become live. - -Of course, getting a parachain slot on either of the two main networks is not guaranteed, and all -projects will need to win an [auction](https://kusama.network/auctions/) for a parachain slot. - -Verifying which projects are currently parachains on Kusama can be quickly done by visiting the -[parachains](https://polkadot.js.org/apps/#/parachains) page on polkadot.js.org/apps. In the -[parathreads](https://polkadot.js.org/apps/#/parachains/parathreads) page you can see which projects -are gearing up to claim a parachain slot, the -[auctions](https://polkadot.js.org/apps/#/parachains/auctions) page shows which projects are bidding -for the next slot, and the [crowdloan](https://polkadot.js.org/apps/#/parachains/crowdloan) page -which projects are gathering funds from their community to participate in auctions. - -But not all projects that build a chain using [Substrate](https://substrate.dev) aim to become a -parachain. Some use it simply because of its infrastructure to build their customised chain, without -any plans to connect to the Relay Chain. And other projects may aim to become a parachain only on -Kusama or directly on Polkadot. - -However, building a potential parachain is not the only way to build on Polkadot and expand its -ecosystem. A project might aim to build a DeFi platform on a parachain, launch a stablecoin or other -token on Statemint, build a decentralised exchange, or any other dApp that one might think of, -without ever touching the Relay Chain. And that's the beauty of Polkadot! - -But in all of those cases, their plans to build on Polkadot, whatever they may be, should be clearly -stated on their site and in their documentation. Most importantly, though, you should look for an -explanation of _how_ they plan to achieve that integration. A roadmap that places the integration at -some point in the future means close to nothing without clearly stating the steps to get there. And -these should be evaluated in tandem with your research on the technical expertise of the team. - -This is especially true for projects that are already running on another network, like on Ethereum -or Binance Smart Chain, and have issued tokens there. Many projects do that either to raise funds -and test their infrastructure or because they aim to build a "multi-chain" solution or both. But -because those projects aren't currently built on Substrate, the existence of a clear and robust -integration plan with Polkadot should be essential in your research to ensure that they will indeed -build on Polkadot one day. - -## "Soft" metrics - -The items above are what you should look at first when evaluating a project and should carry most of -the weight in your decision. The reason is that they are hard to fake or manipulate, provided, of -course, that you are able to verify the information found. Hence we called them "hard" metrics. - -But there are other things to look for that might point to a project's legitimacy but can be more -easily manipulated, so they shouldn't affect your decision heavily. These are called "soft" metrics. - -#### 1. Site quality - -The quality of a project's site could sometimes provide insights into the legitimacy of a project. A -poorly constructed site, with typos and grammatical errors, or poor styling, a site that's a -template without any serious effort to improve or change it, a site that holds little information -about the project, without links to their GitHub or other resources, and generally a site that -doesn't feel professional, are indications that the team is not serious about this project. - -But that doesn't mean that all well-designed sites are also solid projects. This is a soft metric, -after all. Many projects that don't have any plans to build anything substantial still have -excellent, or even beautiful-looking, sites. They put many resources into how they present -themselves visually to mislead. So, an excellent site doesn't necessarily indicate a legitimate -project, a poor site might indicate an illegitimate one, but the site quality alone usually isn't -enough to reach a conclusion. None of these metrics are; you need to look into all of them to make -an educated decision. - -#### 2. Social media presence - -Having a vibrant community is a good indication of a legitimate project. A team that engages with -their community gives updates, answers questions, holds AMAs, posts articles, is a team that's -interested in keeping their community members engaged and informed. - -At the same time, though, social media presence and engagement can be easily faked and manipulated. -Creating a Telegram group or a Discord server and filling it with thousands of bots is very easy. -Although any bot users need to be identified on Discord according to its terms, scammers don't care -about terms and conditions. - -A team that tweets five times a day or posts a Medium article every other day isn't necessarily -building something substantial. - -So, make sure that you verify that their social media presence and engagement is genuine. Join their -channels, ask questions and see first-hand what the community and the admins look like. If you're -seeing a lot of users posting very brief comments, like "Good project", "To the moon", "Thank you" -etc, without really engaging, be very skeptical and watch more closely, as these are probably bots. -Additionally, verify any information shared by the team on social media and check what other people -are saying. But verify those comments too, whether they're positive or negative. - -#### 3. Media presence - -Close to social media presence is media presence; third-party articles, mentions in YouTube videos -and general promotions of the project. - -When it comes to articles, the first thing to check is if the article is genuine coverage or a paid -press release, especially when a project puts this coverage prominently on their page. Or if the -author has any vested interest in promoting the project. You can check their previous articles to -see if they systematically "shill" this project or projects in general. - -The same thing, if not even more, goes for YouTubers and influencers in general. Many of them do -this for a living or as a way to "pump" projects they have invested in. Finding good influencers -that provide as objective info as possible usually involves its own separate research. - -That's not to say that media exposure is terrible. It is probably the most abundant source of -information outside the project itself, but at the same time, it requires extensive cross-checking -and verification of information. - -#### 4. Email communication - -Nowadays, many projects use Telegram, Discord, or similar apps for community engagement, as well as -the sole channel for communication and support. But having an email registered with their domain, -besides providing another channel of communication, can be considered an additional credibility -criterion. - -Furthermore, receiving emails from the project's domain makes it easy to verify that the -communication is authentic (but look out for spoofed emails!). On the other hand, communicating -through personal emails or using a public email provider, like Google or Yahoo, might point to a -not-too serious team or one that's spread too thin and could only be overlooked if the project is in -its very early stages. - -## Crowdloans - -With the recent launch of [parachains](mirror-learn-parachains.md) on Kusama, many projects that aim -to become a parachain launched a [crowdloan](mirror-learn-crowdloans.md) to gather the necessary -funds to participate in the [parachain auctions](mirror-learn-auction.md). But with all the buzz -around the Kusama parachain launch and the imminent Polkadot launch, many scams may also surface. -So, crowdloans need their own section to make sure that you're participating safely. - -First of all, only projects that aim to become a parachain should have a crowdloan. If a project -isn't a parachain candidate, there shouldn't be a crowdloan associated with it. - -The surest way to participate in a parachain crowdloan is the native way through the -[Crowdloan module](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/parachains/crowdloan) -on Polkadot-JS Apps. This issues a special extrinsic that locks your funds until the parachain slot -lease period ends and guarantees that you'll get your stake back after that. You can learn more -about crowdloans through the link above and [here](https://kusama.network/auctions). - -Many parachain candidates offer a way to participate through their site as well. But you should -ensure that they are using the crowdloan pallet in the background, and they're simply wrapping that -in a nicer, more user-friendly UI. If instead, their crowdloan interface _transfers_ funds to an -account, these funds will be totally under their control, and this means you need to fully trust -that the team will use the funds for the crowdloan, return your share to you when the lease period -ends or if they don’t get a spot, and will secure them properly. If they're doing something like -that, it should be explicitly mentioned in their site and documentation. - -That being said, some teams have been doing token sales or swaps in an attempt to get a head start -in raising funds for the auctions, but these are **not crowdloans** and still require full trust in -the team. So, if you plan to participate in these token swaps, make sure the project is reputable -and that you're getting the correct information through their official site and social media -channels. - -Similarly, several centralised exchanges are creating ways to participate in crowdloans through -their platforms, while some wallets are integrating crowdloan functionality to their apps. And more -are sure to follow. Any legitimate effort should be using the native crowdloans module in the -background and offering a more streamlined user experience. Making sure that's the case is necessary -before using these services, but in any case, it still involves trusting the exchange or the service -provider. - -### Additional material - -Fact-checking is a skill necessary not only for DYOR but for filtering out the ton of information -that we come across daily on the internet. If you're interested in learning more about how to check -facts and verify claims, have a look at the following material. - -1. A very nice YouTube series on the art of fact-checking that covers a lot of ground can be found - [here](https://www.youtube.com/watch?v=L4aNmdL3Hr0&list=PL8dPuuaLjXtN07XYqqWSKpPrtNDiCHTzU). -2. Another great resource on fact-checking, for those who prefer to read, can be found - [here](https://webliteracy.pressbooks.com). -3. Wikipedia article on [fact-checking](https://en.wikipedia.org/wiki/Fact-checking) - -Finally, you should also check our complementary guide on [how to identify scams](learn-scams.md). -It's not about projects but how to identify outright scams and avoid them, as well as how to protect -your sensitive information. - -### One last piece of advice - -Once you've read all this material and have done your research and have identified a project as -legitimate, one more thing you need to make sure of is that you understand what the project does and -what new thing it aims to bring to the ecosystem. - -This doesn't fall under fact-checking and verifying claims, but it's important to mention: fully -understanding what something does and its prospecive impact is an integral part of making an -informed decision, so don't overlook it. diff --git a/docs/learn-governance.md b/docs/learn-governance.md deleted file mode 100644 index e867ed2f831f..000000000000 --- a/docs/learn-governance.md +++ /dev/null @@ -1,444 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully overtime at -the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of -the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition -function stored on-chain and defined in a platform-neutral intermediate language (i.e. -[WebAssembly](learn-wasm.md)) and several on-chain voting mechanisms such as referenda with adaptive -super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon -by stake-weighted referenda. - -## Mechanism - -To make any changes to the network, the idea is to compose active token holders and the council -together to administrate a network upgrade decision. No matter whether the proposal is proposed by -the public (token holders) or the council, it finally will have to go through a referendum to let -all holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific -_proposal_ associated with it that takes the form of a privileged function call in the runtime (that -includes the most powerful call: `set_code`, which can switch out the entire code of the runtime, -achieving what would otherwise require a "hard fork"). - -Referenda are discrete events, have a fixed period where voting happens, and then are tallied and -the function call is made if the vote is approved. Referenda are always binary; your only options in -voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period between the -referendum ending and, assuming the proposal was approved, the changes being enacted. For the first -two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, -it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These -will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period -(number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens -to support it - this action is called _seconding_. The proposal with the highest amount of bonded -support will be selected to be a referendum in the next voting cycle. - -Note that this may be different from the absolute number of seconds; for instance, three accounts -bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will -be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a -referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of -stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", -below). - -Majority Council - When agreement from only a simple majority of council members occurs, the -referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency -referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming -there is at least one proposal in one of the queues. There is a queue for Council-approved proposals -and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the -top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose -turn it is to create a referendum that has no proposals (is empty), and proposals are waiting in the -other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same period, excluding emergency referenda. An -emergency referendum occurring at the same time as a regular referendum (either public- or -council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond -the end of the referendum. This is in order to ensure that some minimal economic buy-in to the -result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal -vote, given your stake. At the same time, holding only a small amount of tokens does not mean that -the holder cannot influence the referendum result, thanks to time-locking. You can read more about -this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our -> [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of -them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are -three different scenarios. We can use the following table for reference. - -| **Entity** | **Metric** | -| :--------------------------: | :--------------------------------------------: | -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the -voting result. For example, let's use the public proposal as an example, so the -`Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority -required increases with lower turnout. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low -turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low -turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the -proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the -[democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1_500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate -the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout -is low, therefore, based on the above result, the referendum will be rejected. In addition, only the -winning voter's tokens are locked. If the voters on the losing side of the referendum believe that -the outcome will have negative effects, their tokens are transferrable so they will not be locked -into the decision. Moreover, winning proposals are autonomously enacted only after some enactment -period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their -voting power by declaring how long they are willing to lock up their tokens, hence, the number of -votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods -double. - -| Lock Periods | Vote Multiplier | -| :----------: | :-------------: | -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in -total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are -allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from -transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long -the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the -council can use to alter the effective super-majority required to make it easier or more difficult -for a proposal to pass in the case that there is no clear majority of voting power backing it or -against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has a 25% turnout, the tally of "aye" votes has to reach 66% -for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has a 75% turnout, the tally of "aye" votes has to reach 54%, which means that -the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a -vote using "Negative Turnout Bias". In this case, it is easier to pass this proposal with low -turnout and requires a super-majority to reject. As more token holders participate in voting, the -bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has -to reach 34% for it to pass. - -In short, when the turnout rate is low, a super-majority is required to reject the proposal, which -means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it -becomes a simple majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority -against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an -on-chain entity comprising several actors, each represented as an on-chain account. On Polkadot, the -council currently consists of 13 members. This is expected to increase over the next few months to -24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will -be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury.md), the council is called upon primarily for -three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or -malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with -no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; -if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. - -Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous -support - will move to a public referendum under a neutral, majority-carries voting scheme. In the -case that all members of the council vote in favor of a motion, the vote is considered unanimous and -becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to -do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is -burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a -last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of -the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then -it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related -referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's -hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous -proposals that could be submitted with the same hash, i.e. -[proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain -text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy -system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a -fool-proof method of preventing invalid proposals from being submitted - a single changed character -in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist -invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen.md) process that -selects validators from the available pool based on nominations. However, token holders' votes for -councillors are isolated from any of the nominations they may have on validators. Council terms last -for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen.md) runs and the result will -choose the new councillors based on the vote configurations of all voters. The election also chooses -a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue -with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single -candidate from a list, a Phragmén election is a more expressive way to include each voters' views. -Token holders can treat it as a way to support as many candidates as they want. The election -algorithm will find a fair subset of the candidates that most closely matches the expressed -indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -| :---------------: | :-: | :------------: | :-: | :-: | :-: | -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidates A, B, D & E -keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -| :---------------: | :-: | :------------: | :-: | :-: | -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the -next election. After round 2, even though candidates A & B get the same number of votes in this -round, candidate A gets elected because after adding the older unused approvals, it is higher than -B. - -### Prime Members - -The council, being an instantiation of -[Substrate's Collective pallet](https://github.com/paritytech/substrate/tree/master/frame/collective), -implements what's called a _prime member_ whose vote acts as the default for other members that fail -to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members -abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft -approval" by not voting and letting the others vote. With the existence of a prime member, it forces -councillors to be explicit in their votes or have their vote counted for whatever is voted on by the -prime. - -## Technical Committee - -The Technical Committee was introduced in the -[Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one -of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The -Technical Committee is composed of the teams that have successfully implemented or specified either -a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee -via a simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are -fast-tracked for voting and implementation. These are used for emergency bug fixes or rapid -implementation of new but battle-tested features into the runtime. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active -referendum. Thus, with fast-tracked referenda it is possible to have two active referendums at the -same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances, you may want to appeal to the on-chain council to enact a change on your -behalf. One example of this circumstance is the case of lost or locked funds when the funds were -lost due to a human interface error (such as inputting an address for another network). Another -example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not -let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to -be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no -singular place where you are guaranteed to grab every councillor's ear with your message. However, -there are a handful of good places to start where you can get the attention of some of them. The -[Polkadot Direction][] matrix room is one such place. After creating an account and joining this -room, you can post a well-thought-through message here that lays down your case and provides -justification for why you think the council should consider enacting a change to the protocol on -your behalf. - -At some point you will likely need a place for a longer-form discussion. For this, making a post on -[Polkassembly][] is the recommended place to do so. When you write a post on Polkassembly make sure -you present all the evidence for your circumstances and state clearly what kind of change you would -suggest to the councillors to enact. Remember - the councillors do not need to make the change, it -is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. - Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar - explaining how governance works in Polkadot and Kusama. - -[polkadot direction]: https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io -[polkassembly]: https://polkadot.polkassembly.io/ diff --git a/docs/learn-implementations.md b/docs/learn-implementations.md deleted file mode 100644 index 1858a5d9a355..000000000000 --- a/docs/learn-implementations.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -id: learn-implementations -title: Polkadot Implementations -sidebar_label: Polkadot Implementations ---- - -# Polkadot Implementations - -Polkadot is the flagship protocol of the [Web3 Foundation][], and while Polkadot can be defined as -a protocol, a network, or, a type of infrastructure, it serves to be an ecosystem. For true -decentralization, there should be multiple implementations of Polkadot. Even being a *Layer 0* protocol -that attempts to build an interconnected, interoperable and secure Web3 ecosystem, Polkadot is a complex -piece of software, and its formal implementation depends on being built on top of a tech stack. - -> There is a countless number of development that is happening in the Polkadot ecosystem, though, this -> page will focus on implementations of Polkadot's underlying infrastructure (i.e. runtime, host). - -## Parity Technologies: A [Rustic Vision for Polkadot][] - -[Parity Technologies][] is often in the spotlight for its core development of Polkadot, and while this -is true, Parity Polkadot also serves to be the [Rust][] client. Parity has a rustic vision for Polkadot -through the use of their main product, [Substrate][]. Substrate can also be used for different -chains and different networks, but in the case of Polkadot, Substrate acts as the tech stack that is used -to implement Polkadot's sharded heterogeneous multi-chain model. What's important to realize is that Polkadot -can support parachains that are not built on Substrate, and, chains can also be built on Substrate which are not -required to be deployed onto Polkadot. - -> Parity focuses on blockchain infrastructure for the decentralised web, where they initially offered an -> Ethereum client (Parity Ethereum). Parity was hired by the Web3 Foundation to foster the development of the -> first implementation of Polkadot. - -With this in mind, we can point to some other implementations of Polkadot. Having different implementations -inherently promotes the decentralization of the technology and progresses it in a meaningful way. Other -implementations of Polkadot that exist, many of whom have received a [grant](grants.md) from the Web3 Foundation, -are in programming languages like Go, C++, and JavaScript. - -As stated in the Soramitsu grant announcement: - - It is critically important to have multiple implementations of the Polkadot protocol for a number - of reasons, including decentralization, knowledge dispersion, and better definitions of the - protocol... Multiple implementations of Polkadot improves network resilience and adds to the - decentralization of the network. The governance of the network is more democratized when multiple - teams build clients that run the nodes in the network. - -## Alternative Implementations - -### ChainSafe Systems: [Gossamer][] - -**Gossamer** is a Go implementation being built by [ChainSafe Systems](https://github.com/ChainSafeSystems), a blockchain -R&D firm based in Toronto, Canada that is also building an Eth2.0 Serenity client. They were awarded a grant from the Web3 -Foundation. - -### SORAMITSU: [Kagome][] - -**Kagome** is a C++ implementation of the Polkadot Host being built by [Soramitsu][], a Japanese digital identity -company that previously developed [Hyperledger Iroha][]. They were awarded a grant from the Web3 Foundation and released -the first version of Kagome in April 2020. As part of the process, they also released a [libp2p][] networking layer in C++. - -### Polkadot-JS Project: [Polkadot-JS][] - -**Polkadot-JS** is a [JavaScript client][] and offers a collection of tools, interfaces, and libraries for Polkadot and Substrate. - -### Other implementations that have received grants -- [Golkadot][] -- [Polkadot in Java][] - -[Web3 Foundation]: https://web3.foundation/ -[Parity Technologies]: https://www.parity.io/ -[Substrate]: https://www.substrate.io/ -[Rust]: https://www.rust-lang.org/ - -[ChainSafe Systems]: https://chainsafe.io/ -[SORAMITSU]: https://soramitsu.co.jp/ -[Polkadot-JS]: https://github.com/polkadot-js - -[Rustic vision for Polkadot]: https://github.com/paritytech/polkadot -[Gossamer]: https://github.com/ChainSafe/gossamer#a-go-implementation-of-the-polkadot-host -[Kagome]: https://github.com/soramitsu/kagome#intro -[Hyperledger Iroha]: https://iroha.tech -[libp2p]: https://github.com/soramitsu/libp2p-grpc -[JavaScript client]: https://github.com/polkadot-js/client - -[Golkadot]: https://github.com/opennetsys/golkadot -[Polkadot in Java]: https://github.com/polkadot-java \ No newline at end of file diff --git a/docs/learn-keys.md b/docs/learn-keys.md deleted file mode 100644 index 55723df9ff57..000000000000 --- a/docs/learn-keys.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -id: learn-keys -title: Polkadot Keys -sidebar_label: Polkadot Keys ---- - -Public and private keys are an important aspect of most crypto-systems and an essential component -that enables blockchains like Polkadot to exist. - -## Account Keys - -Account keys are keys that are meant to control funds. They can be either: - -- The vanilla `ed25519` implementation using Schnorr signatures. -- The Schnorrkel/Ristretto `sr25519` variant using Schnorr signatures. -- ECDSA signatures on secp256k1 - -There are no differences in security between `ed25519` and `sr25519` for simple signatures. - -We expect `ed25519` to be much better supported by commercial HSMs for the foreseeable future. - -At the same time, `sr25519` makes implementing more complex protocols safer. In particular, -`sr25519` comes with safer version of many protocols like HDKD common in the Bitcoin and Ethereum -ecosystem. - -### "Controller" and "Stash" Keys - -When we talk about "controller" and "stash" keys, we usually talk about them in the context of -running a validator or nominating DOT, but they are useful concepts for all users to know. Both keys -are types of account keys. They are distinguished by their intended use, not by an underlying -cryptographic difference. All the info mentioned in the parent section applies to these keys. When -creating new controller or stash keys, all cryptography supported by account keys are an available -option. - -The controller key is a semi-online key that will be in the direct control of a user, and used to -submit manual extrinsics. For validators or nominators, this means that the controller key will be -used to start or stop validating or nominating. Controller keys should hold some DOT to pay for -fees, but they should not be used to hold huge amounts or life savings. Since they will be exposed -to the internet with relative frequency, they should be treated carefully and occasionally replaced -with new ones. - -The stash key is a key that will, in most cases, be a cold wallet, existing on a piece of paper in a -safe or protected by layers of hardware security. It should rarely, if ever, be exposed to the -internet or used to submit extrinsics. The stash key is intended to hold a large amount of funds. It -should be thought of as a saving's account at a bank, which ideally is only ever touched in urgent -conditions. Or, perhaps a more apt metaphor is to think of it as buried treasure, hidden on some -random island and only known by the pirate who originally hid it. - -Since the stash key is kept offline, it must be set to have its funds bonded to a particular -controller. For non-spending actions, the controller has the funds of the stash behind it. For -example, in nominating, staking, or voting, the controller can indicate its preference with the -weight of the stash. It will never be able to actually move or claim the funds in the stash key. -However, if someone does obtain your controller key, they could use it for slashable behavior, so -you should still protect it and change it regularly. - -## Session Keys - -Session keys are hot keys that must be kept online by a validator to perform network operations. -Session keys are typically generated in the client, although they don't have to be. They are _not_ -meant to control funds and should only be used for their intended purpose. They can be changed -regularly; your controller only need create a certificate by signing a session public key and -broadcast this certificate via an extrinsic. - -Polkadot uses four session keys: - -- GRANDPA: ed25519 -- BABE: sr25519 -- I'm Online: sr25519 -- Parachain: sr25519 - -BABE requires keys suitable for use in a [Verifiable Random Function](learn-randomness.md/#vrfs) as -well as for digital signatures. Sr25519 keys have both capabilities and so are used for BABE. - -In the future, we plan to use a BLS key for GRANDPA because it allows for more efficient signature -aggregation. - -## FAQ - -### Why was `ed25519` selected over `secp256k1`? - -The original key derivation cryptography that was implemented for Polkadot and Substrate chains was -`ed25519`, which is a Schnorr signature algorithm implemented over the Edward's Curve 25519 (so -named due to the parameters of the curve equation). - -Most cryptocurrencies, including Bitcoin and Ethereum, currently use ECDSA signatures on the -secp256k1 curve. This curve is considered much more secure than NIST curves, which -[have possible backdoors from the NSA](#appendix-a-on-the-security-of-curves). The Curve25519 is -considered possibly _even more_ secure than this one and allows for easier implementation of Schnorr -signatures. A recent patent expiration on it has made it the preferred choice for use in Polkadot. - -The choice of using Schnorr signatures over using ECDSA is not so cut and dry. As stated in Jeff -Burdges' (a Web3 researcher) -[original forum post](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70/2) -on the topic: - -> There is one sacrifice we make by choosing Schnorr signatures over ECDSA signatures for account -> keys: Both require 64 bytes, but only ECDSA signatures communicate their public key. There are -> obsolete Schnorr variants that support recovering the public key from a signature, but they break -> important functionality like hierarchical deterministic key derivation. In consequence, Schnorr -> signatures often take an extra 32 bytes for the public key. - -But ultimately the benefits of using Schnorr signatures outweigh the tradeoffs, and future -optimizations may resolve the inefficiencies pointed out in the quote above. - -### What is `sr25519` and where did it come from? - -Some context: The Schnorr signatures over the Twisted Edward's Curve25519 are considered secure, -however Ed25519 has not been completely devoid of its bugs. Most notably, -[Monero and all other CryptoNote currencies](https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html) -were vulnerable to a double spend exploit that could have potentially led to undetected, infinite -inflation. - -These exploits were due to one peculiarity in Ed25519, which is known as its cofactor of 8. The -cofactor of a curve is an esoteric detail that could have dire consequences for the security of -implementation of more complex protocols. - -Conveniently, [Mike Hamburg's Decaf paper](https://www.shiftleft.org/papers/decaf/index.xhtml) -provides a possible path forward to solving this potential bug. Decaf is basically a way to take -Twisted Edward's Curves cofactor and mathematically change it with little cost to performance and -gains to security. - -The Decaf paper approach by the [Ristretto Group](https://ristretto.group/) was extended and -implemented in Rust to include cofactor-8 curves like the Curve25519 and makes Schnorr signatures -over the Edward's curve more secure. - -The Web3 Foundation has implemented a Schnorr signature library using the more secure Ristretto -compression over the Curve25519 in the [Schnorrkel](https://github.com/w3f/schnorrkel) repository. -Schnorrkel implements related protocols on top of this curve compression such as HDKD, MuSig, and a -verifiable random function (VRF). It also includes various minor improvements such as the hashing -scheme STROBE that can theoretically process huge amounts of data with only one call across the Wasm -boundary. - -The implementation of Schnorr signatures that is used in Polkadot and implements the Schnorrkel -protocols over the Ristretto compression of the Curve25519 is known as **sr25519**. - -### Are BLS signatures used in Polkadot? - -Not yet, but they will be. BLS signatures allow more efficient signature aggregation. Because -GRANDPA validators are usually signing the same thing (e.g. a block), it makes sense to aggregate -them, which can allow for other protocol optimizations. - -As stated in the BLS library's README, - -> Boneh-Lynn-Shacham (BLS) signatures have slow signing, very slow verification, require slow and -> much less secure pairing friendly curves, and tend towards dangerous malleability. Yet, BLS -> permits a diverse array of signature aggregation options far beyond any other known signature -> scheme, which makes BLS a preferred scheme for voting in consensus algorithms and for threshold -> signatures. - -Even though Schnorr signatures allow for signature aggregation, BLS signatures are much more -efficient in some fashions. For this reason it will be one of the session keys that will be used by -validators on the Polkadot network and critical to the GRANDPA finality gadget. - -## Resources - -- [Key discovery attack on BIP32-Ed25519](https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44) - - Forum post detailing a potential attack on BIP32-Ed25519. A motivation for transition to the - sr25519 variant. -- [Account signatures and keys in Polkadot](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70) - - Original forum post by Web3 researcher Jeff Burdges. -- [Are Schnorr signatures quantum computer resistant?](https://bitcoin.stackexchange.com/questions/57965/are-schnorr-signatures-quantum-computer-resistant/57977#57977) - -## Appendix A: On the security of curves - -From the -[introduction of Curve25519](https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n10) -into `libssl`: - -```text -The reason is the following: During summer of 2013, revelations from ex- -consultant at [the] NSA Edward Snowden gave proof that [the] NSA willingly inserts backdoors -into software, hardware components and published standards. While it is still -believed that the mathematics behind ECC (Elliptic-curve cryptography) are still sound and solid, -some people (including Bruce Schneier [SCHNEIER]), showed their lack of confidence -in NIST-published curves such as nistp256, nistp384, nistp521, for which constant -parameters (including the generator point) are defined without explanation. It -is also believed that [the] NSA had a word to say in their definition. These curves -are not the most secure or fastest possible for their key sizes [DJB], and -researchers think it is possible that NSA have ways of cracking NIST curves. -It is also interesting to note that SSH belongs to the list of protocols the NSA -claims to be able to eavesdrop. Having a secure replacement would make passive -attacks much harder if such a backdoor exists. - -However an alternative exists in the form of Curve25519. This algorithm has been -proposed in 2006 by DJB [Curve25519]. Its main strengths are its speed, its -constant-time run time (and resistance against side-channel attacks), and its -lack of nebulous hard-coded constants. -``` diff --git a/docs/learn-ledger.md b/docs/learn-ledger.md deleted file mode 100644 index f1b4c3b6c560..000000000000 --- a/docs/learn-ledger.md +++ /dev/null @@ -1,226 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based -> browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X -devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that -does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports -most of the transaction types of the network (a notable exception is the "Batch" transaction from -the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your -issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our -> [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on - the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're - up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the -> application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the -README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it -executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest -firmware (1.6.1 at the time of writing). If everything is prepared, then type -`./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the -allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". -Navigate all the way to the right, verify the Identifier hash matches the one that is printed in -your terminal. Click both buttons on "Perform Installation" to install the application. It will ask -again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with -> normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will -work with the browser interface after installation. The functionality is currently gated behind a -feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" -tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the -default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not -seeing this it is because there is -[no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that -your Ledger device is unlocked and you have navigated into the Polkadot application, then click this -button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already -named your account, this will not change the existing name. The first dropdown lets you select an -account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick -a derivation path - think of it like a formula from which child accounts are generated. If in doubt, -pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need -to confirm the USB connection through a popup like the one below when adding the Ledger device for -the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your -ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the -end of the row. This will open a new menu, here you can click the "Show address on hardware device" -option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS -Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you -can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger -account. At the far right of the row is located your account's DOT balance. If you expand the -balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the -[balance transfer page](learn-balance-transfers.md). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to -provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your -address will be shown in this sidebar, along with some other information. Another method is just -clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger -> by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware -> will intercept clicks and clipboard requests and can change your copied value in-flight, so being -> extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you -want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not - work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" - page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manually when you -want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda - they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = - the referendum you voted on and has an expired lock. Make sure you do it from the account with the - expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where - ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -__NOTE__: Despite the Polkadot ledger application being compatible with both the Ledger Nano S and the -Ledger Nano X, none of the [Democracy](maintain-guides-democracy.md) extrinsics are available in the -light version. The following [repo by Zondax][] lists the currently supported Democracy extrinsics on -the full ledger. - -## Support - -If you need support please send an email to -[support@polkadot.network](mailto:support@polkadot.network) or visit our -[Support Page](https://support.polkadot.network). - -[ledger]: https://www.ledger.com/ -[repo by Zondax]: https://github.com/Zondax/ledger-polkadot#democracy -[polkadot-js apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[polkascan]: https://polkascan.io/polkadot -[subscan]: https://polkadot.subscan.io/ diff --git a/docs/learn-parathreads.md b/docs/learn-parathreads.md deleted file mode 100644 index 20b2c844246d..000000000000 --- a/docs/learn-parathreads.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -id: learn-parathreads -title: Parathreads -sidebar_label: Parathreads ---- - -Parathreads are an idea for parachains to temporarily participate (on a block by block basis) in -Polkadot security without needing to lease a dedicated parachain slot. This is done through -economically sharing the scarce resource of a _parachain slot_ among a number of competing resources -(parathreads). Chains that otherwise would not be able to acquire a full parachain slot, or do not -find it economically sensible to do so, are enabled to participate in Polkadot's shared security -— albeit with an associated fee per executed block. It also offers a graceful off-ramp to -parachains that no longer require a dedicated parachain slot, but would like to continue using the -Relay Chain. - -## Origin - -According to [this talk](https://v.douyu.com/show/a4Jj7llO5q47Dk01) in Chengdu, the origin of the -idea came from similar notions in the limited resource of memory on early personal computers of the -late '80s and '90s. Since computers have a limited amount of physical memory, when an application -needs more, the computer can create virtual memory by using _swap space_ on a hard disk. Swap space -allows the capacity of a computer's memory to expand and for more processes to run concurrently with -the trade-off that some processes will take longer to progress. - -## How will Parathreads Operate? - -A portion of the parachain slots on the Relay Chain will be designated as part of the parathread -pool. In other words, some parachain slots will have no parachain attached to them and rather will -be used as a space for which the winner(s) of the block-by-block parathread fee auction can have -their block candidate included. - -Collators will offer a bid designated in DOT for inclusion of a parathread block candidate. The -Relay Chain block author is able to select from these bids to include a parathread block. The -obvious incentive is for them to accept the block candidate with the highest bid, which would bring -them the most profit. The tokens from the parathread bids will likely be split 80-20, meaning that -80% goes into Polkadot treasury and 20% goes to the block author. This is the same split that -applies also to transaction fees and, like many other parameters in Polkadot, can be changed through -a governance mechanism. - -## Parachain vs. Parathread - -Parachains and parathreads are very similar from a development perspective. One can imagine that a -chain developed with Substrate can at different points in its lifetime assume one of three states: -an independent chain with secured bridge, a parachain, or a parathread. It can switch between these -last two states with relatively minimal effort since the difference is more of an economic -distinction than a technological one. - -Parathreads have the exact same benefits for connecting to Polkadot that a full parachain has. -Namely, it is able to send messages to other para{chain,threads} through XCMP and it is secured -under the full economic security of Polkadot's validator set. - -The difference between parachains and parathreads is economic. Parachains must be registered through -a normal means of Polkadot, i.e. governance proposal or parachain slot auction. Parathreads have a -fixed fee for registration that would realistically be much lower than the cost of acquiring a -parachain slot. Similar to how DOT are locked for the duration of parachain slots and then returned -to the winner of the auction, the deposit for a parathread will be returned to the parathread after -the conclusion of its term. - -Registration of the parathread does not guarantee anything more than the registration of the -parathread code to the Polkadot Relay Chain. When a parathread progresses by producing a new block, -there is a fee that must be paid in order to participate in a per-block auction for inclusion in the -verification of the next Relay Chain block. All parathreads that are registered are competing in -this auction for their parathread to be included for progression. - -There are two interesting observations to make about parathreads. One, since they compete on a -per-block basis, it is similar to how transactions are included in Bitcoin or Ethereum. A similar -fee market will likely develop, which means that busier times will drive the price of parathread -inclusion up, while times of low activity will require lower fees. Two, this mechanism is markedly -different from the parachain mechanism, which guarantees inclusion as long as a parachain slot is -held; parathread registration grants no such right to the parathread. - -## Parathread Economics - -There are two sources of compensation for collators: - -1. Assuming a parathread has its own local token system, it pays the collators from the transaction - fees in its local token. If the parathread does not implement a local token, or its local token - has no value (e.g. it is used only for governance), then it can use DOT to incentivize collators. -2. Parathread protocol subsidy. A parathread can mint new tokens in order to provide additional - incentives for the collator. Probably, the amount of local tokens to mint for the parathread - would be a function of time, the more time that passes between parathread blocks that are - included in the Relay Chain, the more tokens the parathread is willing to subsidize in order to - be considered for inclusion. The exact implementation of this minting process could be through - local parathread inflation or via a stockpile of funds like a treasury. - -Collators may be paid in local parathread currency. However, the Relay Chain transacts with the -Polkadot universal currency (DOT) only. Collators must then submit block candidates with an -associated bid in DOT. - -## Parachain Slot Swaps - -It will be possible for a parachain that holds a parachain slot to swap this slot with a parathread -so that the parathread "upgrades" to a full parachain and the parachain becomes a parathread. The -chain can also stop being a chain and continue as a thread without swapping the slot. The slot, if -unoccupied, would be auctioned off in the next [auction period](learn-auction.md). - -This provides a graceful off-ramp for parachains that have reached the end of their lease and do not -have sufficient usage to justify renewal; they can remain registered on the Relay Chain but only -produce new blocks when they need to. - -Parathreads help ease the sharp stop of the parachain slot term by allowing parachains that are -still doing something useful to produce blocks, even if it is no longer economically viable to rent -a parachain slot. - -## Resources - -- [Parathreads: Pay-as-you-go Parachains](https://medium.com/polkadot-network/parathreads-pay-as-you-go-parachains-7440d23dde06) diff --git a/docs/learn-polkadot-host.md b/docs/learn-polkadot-host.md deleted file mode 100644 index e842f0fb1458..000000000000 --- a/docs/learn-polkadot-host.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: learn-polkadot-host -title: Polkadot Host (PH) -sidebar_label: Polkadot Host (PH) ---- - -The architecture of Polkadot can be divided into two different parts, the Polkadot _runtime_ and the -Polkadot _host_. The Polkadot runtime is the core state transition logic of the chain and can be -upgraded over the course of time and without the need for a hard fork. In comparison, the Polkadot -host is the environment in which the runtime executes and is expected to remain stable and mostly -static over the lifetime of Polkadot. - -The Polkadot host interacts with the Polkadot runtime in limited, and well-specified ways. For this -reason, implementation teams can build an alternative implementation of the Polkadot host while -treating the Polkadot runtime as a black box. For more details of the interactions between the host -and the runtime, please see the [specification][]. - -## Components of the Polkadot host - -- Networking components such as Libp2p that facilitates network interactions. -- State storage and the storage trie along with the database layer. -- Consensus engine for GRANDPA and BABE. -- Wasm interpreter and virtual machine. -- Low level primitives for a blockchain, such as cryptographic primitives like hash functions. - -A compiled Polkadot runtime, a blob of Wasm code, can be uploaded into the Polkadot host and used as -the logic for the execution of state transitions. Without a runtime, the Polkadot host is unable to -make state transitions or produce any blocks. - -## Diagram - -Below is a diagram that displays the Polkadot host surrounding the Polkadot runtime. Think of the -runtime (in white) as a component that can be inserted, swapped out, or removed entirely. While the -parts in grey are stable and can not change without an explicit hard fork. - -![polkadot host](assets/updated_pre.png) - -## Resources - -- [Polkadot Host Protocol Specification](https://github.com/w3f/polkadot-spec) - Incubator for the - Polkadot Host spec, including tests. -- [ChainSafe's Go PH](https://github.com/ChainSafeSystems/go-pre) is a 25-person development team - based in Toronto, Canada. ChainSafe is building an implementation of the beacon chain for Ethereum - 2.0 client in TypeScript and this Go implementation of Polkadot. - -[specification]: https://github.com/w3f/polkadot-spec/ diff --git a/docs/learn-randomness.md b/docs/learn-randomness.md deleted file mode 100644 index 036c82ed3d54..000000000000 --- a/docs/learn-randomness.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -id: learn-randomness -title: Randomness -sidebar_label: Randomness ---- - -Randomness in Proof of Stake blockchains is important for a fair and unpredictable distribution of -validator responsibilities. Computers are bad at random numbers because they are deterministic -devices (the same input always produces the same output). What people usually call random numbers on -a computer (such as in a gaming application), are _pseudo-random_ - that is, they depend on a -sufficiently random _seed_ provided by the user or another type of _oracle_, like a -[weather station for atmospheric noise](https://www.random.org/randomness/), your -[heart rate](https://mdpi.altmetric.com/details/47574324), or even -[lava lamps](https://en.wikipedia.org/wiki/Lavarand), from which it can generate a series of -seemingly-random numbers. But given the same seed, the same sequence will always be generated. - -Though, these inputs will vary based on time and space, and it would be impossible to get the same -result into all the nodes of a particular blockchain around the world. If nodes get different inputs -on which to build blocks, forks happen. Real-world entropy is not suitable for use as a seed for -blockchain randomness. - -There are two main approaches to blockchain randomness in production today: `RANDAO` and `VRF`. - -**Polkadot uses VRF.** - -## VRF - -A verifiable random function (VRF) is a mathematical operation that takes some input and produces a -random number along with a proof of authenticity that this random number was generated by the -submitter. The proof can be verified by any challenger to ensure the random number generation is -valid. - -The VRF used in Polkadot is roughly the same as the one used in Ouroboros Praos. Ouroboros -randomness is secure for block production and works well for [BABE](learn-consensus.md#BABE). Where -they differ is that Polkadot's VRF does not depend on a central clock (the problem becomes - whose -central clock?), rather, it depends on its own past results to determine present and future results, -and it uses slot numbers as a clock emulator, estimating time. - -### Here's how it works in detail: - -Slots are discrete units of time six seconds in length. Each slot can contain a block, but may not. -Slots make up [epochs](glossary.md##epoch) - on Polkadot, 2400 slots make one epoch, which makes -epochs four hours long. - -In every slot, each validator "rolls a die". They execute a function (the VRF) that takes as input -the following: - -- **The "secret key",** a key specifically made for these die rolls. -- **An epoch randomness value,** which is the hash of VRF values from the blocks in the epoch before - last (N-2), so past randomness affects the current pending randomness (N). -- **The slot number.** - -![](assets/VRF_babe.png) - -The output is two values: a `RESULT` (the random value) and a `PROOF` (a proof that the random value -was generated correctly). - -The `RESULT` is then compared to a _threshold_ defined in the implementation of the protocol -(specifically, in the Polkadot Host). If the value is less than the threshold, then the validator -who rolled this number is a viable block production candidate for that slot. The validator then -attempts to create a block and submits this block into the network along with the previously -obtained `PROOF` and `RESULT`. Under VRF, every validator rolls a number for themselves, checks it against a threshold, and produces a block if the random roll is under that threshold. - -The astute reader will notice that due to the way this works, some slots may have no validators as -block producer candidates because all validator candidates rolled too high and missed the threshold. -We clarify how we resolve this issue and make sure that Polkadot block times remain near -constant-time in the wiki page on [consensus](learn-consensus.md). - -## RANDAO - -An alternative method for getting randomness on-chain is the -[RANDAO](https://github.com/randao/randao) method from Ethereum. RANDAO requires each validator to -prepare by performing many thousands of hashes on some seed. Validators then publish the final hash -during a round and the random number is derived from every participant's entry into the game. As -long as one honest validator participates, the randomness is considered secure (non-economically -viable to attack). - -RANDAO is optionally augmented with VDF. - -### VDFs - -[Verifiable Delay Functions](https://vdfresearch.org/) are computations that take a prescribed -duration of time to complete, even on parallel computers. They produce unique output that can be -independently and efficiently verified in a public setting. By feeding the result of RANDAO into a -VDF, a delay is introduced that renders any attacker's attempt at influencing the current randomness -obsolete. - -VDFs will likely be implemented through ASIC devices that need to be run separately from the other -types of nodes. Although only one is enough to keep the system secure, and they will be open source -and distributed at nearly no charge, running them is neither cheap nor incentivized, producing -unnecessary friction for users of the blockchains opting for this method. - -## Resources - -- [Polkadot's research on blockchain randomness and sortition](https://w3f-research.readthedocs.io/en/latest/polkadot/block-production/Babe.html) - - contains reasoning for choices made along with proofs -- [Discussion on Randomness used in Polkadot](https://github.com/paritytech/ink/issues/57) - W3F - researchers discuss the randomness in Polkadot and when it is usable and under which assumptions. diff --git a/docs/learn-registrar.md b/docs/learn-registrar.md deleted file mode 100644 index 0845a3d8d020..000000000000 --- a/docs/learn-registrar.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -> **Warning**: The beta version of the new registrar service is available at -> https://registrar.web3.foundation/. The service as described in this guide is currently halted -> and will be deprecated soon. - -An on-chain identity is a good way to build up your reputation and let the community know more about -you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar -service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and -no fees on Polkadot (although there may be a small fee in the future). However, you will of course -need to reserve some DOT in your account while you have an identity, no matter which registrar you -use. For details on the amount necessary to reserve, as well as the identity system as a whole, see -the [identity](learn-identity.md) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys -> to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` -when setting an on-chain identity, these will be required to verify one by one by signing a -challenge message. Be aware that the `display name` cannot be too similar to others that have been -verified already. There is no need to set all of the fields when using the service. You are free to -set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community.md#polkadot) to ask questions if there is -anything unclear. - -## Setting an On-chain Identity - -### Filling out information - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to -> leave it blank when you fill in your identity information. - -Go to [Accounts](https://polkadot.js.org/apps/#/accounts) page in Polkadot-JS Apps. The easiest way -to add the built-in fields is to click the vertical three dots next to one's account and select "Set -on-chain identity". - -A popup will appear, offering the default fields. - -Currently, the registrar **only supports the following fields**: - -- Display Name -- Email -- Twitter -- Element (formerly known as Riot) - -![registrar](assets/registrar/1.jpg) - ---- - -If you try to register the other fields, such as: - -![registrar](assets/registrar/2.jpg) - -You will eventually be asked to update your information, as these are not yet supported by the -registrar. - -![registrar](assets/registrar/6.jpg) - ---- - -### Invoke transaction to set identity - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to -submit the transaction. - -Now you have set the identity information on-chain, but that is not verified yet, so you should see -a little grey icon beside your name. - -![registrar](assets/registrar/3.jpg) - -It is the time to interact with the W3F's verification bot by submitting the judgment request to the -W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to -[Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) -and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` -transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for -Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to -receive the verification requests from those platforms. As for Element, an invitation will be sent -by the bot named `W3F Registrar Verification`. - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether -> that is ours or not, ask in the Polkadot community chat first. - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/5.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the -PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" -field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification -chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your -address has been verified. This proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example -for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to -[Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS -and select your account, paste the "Challenge" data to the "sign the following data" field and click -"Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified -successfully. - -## Twitter Verification - -Lastly, if you have provided a Twitter handle, you would have to follow -[@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" -will do the trick. - -After waiting for a few minutes you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/12.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that -you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/13.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 -minutes. - -If everything has been verified successfully, you will see that your account verification status has -been marked as "reasonable" with a **green tick icon** on the -[Accounts](https://polkadot.js.org/apps/#/accounts) page. - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/docs/learn-scams.md b/docs/learn-scams.md deleted file mode 100644 index 9eeab092665c..000000000000 --- a/docs/learn-scams.md +++ /dev/null @@ -1,160 +0,0 @@ ---- -id: learn-scams -title: How to Protect Yourself from Scams -sidebar_label: How to Protect Yourself from Scams ---- - -Scams have unfortunately made an impact on our community. It's important to stay alert and protect -yourself and your non-refundable crypto assets from scammers. If you ever feel you are being -scammed, please email [our support team](mailto:support@web3.foundation). - -## Essential rules: - -1. Never, ever, ever share your seed phrase or account password. -2. Do not trust anyone online. It is trivial for them to lie and change their identities. -3. [If you are scammed](#i-got-scammed---what-can-i-do), there is **likely nothing** that can be - done to recover your funds. If a scammer gets a hold of your seed phrase, they can transfer all - of your funds to their account in seconds. It is better to be safe than to risk all of your - tokens. -4. If it sounds too good to be true, it probably is. People, especially celebrities, do not give - away crypto for free. Even if they wanted to, they could just ask for your address as opposed to - having you send them tokens. -5. Scams are absolutely rife in this space. It is easy and cheap to set a scam up, and hard to shut - one down. Therefore, the onus is on the user to be as diligent as possible in avoiding them. -6. If you can, try to always verify new information that you see with an official source, such as - [Polkadot Network's official blog](community.md) or - [Web3 Foundation support](mailto:support@polkadot.network). Often scammers will fake a website or - a blog post, but if you check it against a secondary source you will reduce the chances of being - scammed. - - > Important: With crowdloans active on the network, it is very important to know how to safely - > participate. Fake crowdloan campaigns may present an attractive target for scammers. If you are - > participating in a network-native crowdloan, **never send your tokens to an address.** Native - > crowdloan contributions are made with a special transaction using a campaign index, where the - > contributed assets remain locked until the end of the lease period. Legitimate teams will not - > ask you to send your assets to an address to participate in a network-native crowdloan. - -### Some Common Types of Scams - -- Private messages sent to you over Telegram, Twitter, and other social media - admins or employees - will never contact you. -- "Giveaways" advertising that you "send us some DOT/KSM, we'll send you double back". -- Sites where you need to enter your seed phrase in order to "sync" your account, claim tokens, - unblock transactions etc. -- Emails asking for DOT/KSM private keys/seeds/etc., posing as a member of any of our teams. -- Scammers will take official videos, add "giveaway" text around it so that it looks like the - giveaway is supported by Polkadot, Web3 Foundation, Parity, or another well-known entity. -- Many scammers will create nearly perfect imitations of sites - always triple-check the URL. -- People offering to help you stake or get rewards. -- People responding to questions that you asked publicly in a private chat. -- Advertisements pointing to imitations of sites asking you to enter your seed words. - -These are just some of the types of scams. Scammers are inventing new ones all the time. In general, -do not trust anyone messaging you that you did not message yourself, and be wary of anyone -attempting to help you or offer you a "deal". - -Scammers will often imitate usernames, profile pictures, etc. of well-known members of the -community. Often the differences in these accounts will be very minor, such as `joe_sm1th` or -`jo_smith` instead of `joe_smith`. - -Scammers will often make it seem like the "deal" is only available for a limited time. Do not be -tricked by this, it is always better to confirm than to risk losing everything. - -### Admins will never contact you directly - -If you've received a message from an admin over Telegram, ignore it. Our team members will never -personally message you. Our social media accounts are posted on our website and any new social media -accounts will be announced by our team. We will never offer to sell you DOT at a discount, air-drop -"rewards", or message you privately to help with a problem you posted publicly. Our social media can -be found below: - -- [Twitter](https://twitter.com/Polkadot) -- [Reddit](https://www.reddit.com/r/polkadot) -- [Discord](https://discord.gg/wGUDt2p) -- [Polkadot YouTube](https://www.youtube.com/channel/UCB7PbjuZLEba_znc7mEGNgw) -- [Polkadot Medium](https://medium.com/polkadot-network) -- [Our Community Page](community.md) also lists more social media accounts that Web3 Foundation, - Polkadot, and Kusama have. - -### Keep your data secure - -You should _never_ share your seed phrase, password, private keys, or any other personal data with -anyone. If you are concerned a wallet could be fake, please check out our official list of supported -wallets [here](build-wallets.md). - -Some simple things that you can do to keep your assets and information secure from hackers: - -- Keep your seed phrase only on paper, in a secret and secure location. -- DO NOT keep your seed phrase on any electronic medium, like the cloud, on your computer, on a USB - drive, etc. -- Never enter your seed or mnemonic phrase directly into a website. -- Your seed phrase is meant as a backup in case you lose access to your wallet. Use it only for that - purpose and only in wallets you've used before and trust. -- Your passwords should be strong and unique. It is recommended that you use a - [password manager app](https://www.howtogeek.com/141500/why-you-should-use-a-password-manager-and-how-to-get-started/) - to create and store your passwords. -- Keep your computer free of malware. Although an antivirus can be of great help, it's not a - panacea. Safe browsing and downloading is the only way to be sure your computer is clean. -- Avoid installing browser extensions from sources you don't trust explicitly. -- Store your assets in cold storage, like a hardware wallet or - [Parity Signer](https://www.parity.io/signer/). - -### Always check the source - -For any potential scam, always be sure to do a background check on the source, i.e, look at any -username, email, Youtube channel name, URL, etc. If something seems fishy, that's because it likely -is. Never enter any personal data if you feel the source could be a scam. Feel free to check with -[support@polkadot.network](mailto:support@web3.foundation). - -### Check twice before sending DOT/KSM - -A good practice to take into consideration is to verify the address you are sending crypto to. If -you don't know that account, you probably shouldn't be sending your assets there. It's your -responsibility to make sure that you understand where you are sending your funds. Crypto is a -decentralized space and your only recourse if a mistake is made is by appealing to the council (who -usually will not get involved in matters of mistaken transfers - see below). - -### Install the Polkadot{.js} extension - -The extension uses crowd-sourced [anti-phishing measures](https://polkadot.js.org/phishing/) to -automatically prevent your browser from displaying known phishing or scam sites. They will be -blocked upon loading, helping to prevent you from visiting these sites and thus falling for them. - -### Our official sites - -You can use the following list of our official domains to make sure that you're visiting an official -site: - -- polkadot.network -- polkadot.io -- kusama.network -- web3.foundation -- parity.io -- substrate.dev -- substrate.io - -Of course, many projects building on Polkadot and Kusama that use similar names. If, however, a site -poses as Polkadot, Kusama, Web3 Foundation, or Parity on a domain not listed above, then it's most -likely a scam. - -Besides those, there are also `polkadot.js.org` and `dotapps.io` that host our web wallet and other -tools. - -## I Got Scammed - What Can I Do? - -In the unfortunate case of having fallen for a scam, there is likely nothing anyone can do to help -you restore your funds. Polkadot and Kusama are decentralized platforms and while we do have -governance functionality that could technically allow for funds freezing or refunds, it is -impossible to prove that you are the original owner, or that you did not sell the tokens and are -trying to reclaim them. Additionally, even with addresses that are obviously in possession of a -scammer, governance is a slow-moving process; even under ideal conditions, it would take over 56 -days to come into effect. The thief could easily monitor the network for governance proposals that -would affect their ill-gotten gains and move them to a new address before the proposal is enacted. - -You could put together a full account of the transactions and chat messages accompanied by -screenshots and explanations, but there are no guarantee stakeholders on the network will help you -restore the funds as it would set a dangerous precedent. In fact, there have been several attempts -on Polkadot in the past and none have been passed. It is safer for the network and for future users -to consider the money lost. Still, your detailed account of the situation might help prevent others -from falling for the same thing so we recommend retracing your steps and talking publicly about -them, if it's not too private. diff --git a/docs/learn-spree.md b/docs/learn-spree.md deleted file mode 100644 index 49619fabf6ae..000000000000 --- a/docs/learn-spree.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -id: learn-spree -title: SPREE -sidebar_label: SPREE ---- - -Shared Protected Runtime Execution Enclaves (SPREE) sometimes referred to as "trust wormholes," are -fragments of logic comparable to runtime modules in Substrate, but live on the Polkadot Relay Chain -and may be opted into by parachains. - -SPREE in brief was described with the following properties and functions: - -- Parachains can opt-in to special runtime logic fragments (like smart contracts). -- These fragments have their own storage and own [XCMP](learn-crosschain.md) endpoint. -- All instances across parachains have identical logic. -- It executes alongside parachain logic. -- Protected: storage can not be altered by parachain logic; messages can not be faked from them by - parachains. - -## Origin - -On 28 March, 2019 u/Tawaren, a member of the Polkadot community, made a post on -[r/dot][polkadot reddit] called "SmartProtocols Idea" and laid out a proposal for [Smart -Protocols][smart protocols reddit post]. The core insight of the post was that XCMP had a -complication in that it was difficult to verify and prove code was executed on a parachain without -trust. A solution was to install the SmartProtocols in the Relay Chain that would be isolated blobs -of code with their own storage per instance that could only be changed through an interface with -each parachain. SmartProtocols are the precursor to SPREE. - -## What is a SPREE module? - -SPREE modules are fragments of logic (in concrete terms they are blobs of -[WebAssembly](learn-wasm.md) code) that are uploaded onto Polkadot through a governance mechanism or -by parachains. Once the blob is uploaded to Polkadot, all other parachains can decide to opt-in to -the logic. The SPREE module would retain its own storage independent of the parachain, but would be -callable through an interface with the parachain. Parachains will send messages to the SPREE module -synchronously. - -SPREE modules are important to the overall XCMP architecture because they give a guarantee to the -code that will be executed on destination parachains. While XCMP guarantees the delivery of a -message, it does not guarantee what code will be executed, i.e. how the receiving parachain will -interpret the message. While XCMP accomplishes trustless message passing, SPREE is the trustless -interpenetration of the message and a key part of the usefulness of XCMP. - -SPREE modules are like recipes in cookbooks. For example, if we give an order to a cook to make a -soufflé, and we’re decently confident in the ability of the cook, we have a vague idea of what will -be made but no actual surety of how it will be made. However, let’s say that a cook has the “Soufflé -Maker’s Manual” on their bookshelf and has committed themselves to only make souffles from this -book. Now we can also consult the same book that the cook has, and we have a precise understanding -of what will happen when we tell the cook to make a soufflé. In this example, “make a soufflé” was -the message in XCMP and the cookbook was the SPREE module. - -In concrete terms, SPREE modules could be useful for various functionality on Polkadot. One -suggested use case of SPREE modules is for a trustless decentralized exchange that is offered as -functionality to any parachain without any extra effort from parachain developers. One can imagine -this working by having a SPREE module that exposes the interface for the incrementing and -decrementing of balances of various assets based on a unique identifier. - -## Why? - -Sending messages across parachains in XCMP only ensures that the message will be delivered but does -not specify the code that will be executed, or how the message will be interpreted by the receiving -parachain. There would be ways around this such as requesting a verifiable receipt of the execution -from the receiving parachain, but in the naked case, the other parachain would have to be trusted. -Having shared code that exists in appendices that the parachain can opt-in to resolves the need for -trust and makes the execution of the appendices completely trustless. - -SPREE would be helpful to ensure that the same logic is shared between parachains in the SPREE -modules. An especially relevant use case would revolve around the use of token transfers across -parachains in which it is important that the sending and receiving parachains agree about how to -change the total supply of tokens and a basic interface. - -## Example - -![spree example](assets/SPREE/spree_module.png) - -The diagram above is a simplification of the Polkadot system. - -In this diagram, we see that the Wasm code for SPREE module "X" has been uploaded to the Polkadot -Relay Chain. The two cylinders "A" and "B" represent two distinct parachains that have both opted-in -to this SPREE module creating two distinct instances of it with their own XCMP endpoints "A.X" and -"B.X". - -In the example, we assume that this SPREE module "X" contains the functionality for incrementing of -decrementing the balance of a particular asset that is unique to this module. - -By initiating a transaction at A.X to decrease a particular balance by 1, a message over XCMP can be -trustlessly sent to B.X to increase a balance by 1. - -Collators, represented as the green triangle are responsible for relaying this message from -parachain A to parachain B, as well as maintaining the storage for each particular instance of A.X -and B.X for their respective parachains. They provide proofs of valid state transitions to the Relay -Chain validators represented as blue diamonds. - -Validators can validate the correct state transitions of SPREE modules A.X and B.X by being provided -with the previous state root of the SPREE module instances, the data of the XCMP message between the -instances, and the next state root of the instance. They do this validation by checking it against -the `validate` function as provided by the SPREE module API. Collators are expected to be able to -provide this information to progress their parachains. - -[polkadot reddit]: https://www.reddit.com/r/dot/ -[smart protocols reddit post]: https://www.reddit.com/r/dot/comments/b6kljn/smartprotocols_idea/ diff --git a/docs/learn-staking.md b/docs/learn-staking.md deleted file mode 100644 index 4f5de24b20de..000000000000 --- a/docs/learn-staking.md +++ /dev/null @@ -1,524 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It -is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors -who are interested in maintaining the network can run a validator node. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 -validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus.md/#babe), validating -parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with -their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. -Having more stake on a validator does not influence the amount of block rewards it receives. -However, there is a probabilistic component to reward calculation (discussed below), so rewards may -not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In -this way, the network incents the nomination of lower-staked validators to create an equally-staked -validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate validator candidates that you trust to help you earn rewards in the -chain's native token. You can take a look at the [nominator guide](learn-nominator.md) to understand -your responsibilities as a nominator, and the [validator docs](learn-validator.md) to understand -what you need to do as a validator. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies -are made public to all nominators, and a nominator in turn submits a list of any number of -candidates that it supports. In the next era, a certain number of validators having the most DOT -backing get elected and become active. - -There are no particular requirements to become a nominator, though we expect each nominator to -carefully track the performance and reputation of the validators they back. Nominating is _not_ a -"set and forget" operation. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their -associated votes as input, and outputs a set of validators. This "election solution" has to meet -certain requirements, such as maximizing the amount of stake to nominate validators and distributing -the stake backing validators as evenly as possible. The objectives of this election mechanism are to -maximize the security of the network, and achieve fair representation of the nominators. If you want -to know more about how NPoS works (e.g. election, running time complexity, etc.), please read -[here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator -pools**. A validator pool consists of the stake of an elected validator together with the nominators -backing it. - -If a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election -mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` -with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were -`k` nominators in different pools, each backing a single validator `i` with stake `s_i`. - -For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially -the **same amount of tokens** for equal work; they are NOT paid proportional to the stakes in each -pool. There is a probabilistic component to staking rewards in the form of -[era points](maintain-guides-validator-payout.md/#era-points) and -[tips](learn-transaction-fees.md#fee-calculation) but these should average out over time. - -Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's -commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the -nominators and validator. Notice in particular that the validator is rewarded twice: once in -commission fees for validating (if their commission rate is above 0%), and once for nominating -itself with stake. If a validator's commission is set to 100%, no tokens will be paid out to any -nominations in the validator pool. - -To estimate the inflation rate and how many tokens you can get each month as a nominator or -validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a -reference and play around with it by changing some parameters (e.g. how many days you would like to -stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though -it may not be entirely accurate since staking participation is changing dynamically, it works well -as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid -the same regardless of stake level, pools with less stake will generally pay more to nominators -per-token than pools with more stake. - -We thus give nominators an economic incentive to gradually shift their preferences to lower staked -validators that gain a sufficient amount of reputation. The reason for this is that we want the -stake across validator pools to be as evenly distributed as possible, to avoid a concentration of -power among a few validators. - -In the long term, we expect all validator pools to have similar levels of stake, with the stake -being higher for higher reputation validators (meaning that a nominator that is willing to risk more -by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual - value, which fluctuates, but merely an assumption for purposes of this example; to understand how - the actual minimal stake is calculated, see - [here](faq.md#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -| :-----------: | :--------------------: | :-------------------------: | :-----: | -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -| :-----------: | :--------------------: | :-------------------------: | :-----: | -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT -than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he -only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number -of nominators a validator may have, a validator does have a limit to how many nominators to which it -can pay rewards. - -In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be -modified via runtime upgrade. A validator with more than {{ polkadot_max_nominators }} nominators is -*oversubscribed*. When payouts occur, only the top {{ polkadot_max_nominators }} nominators as -measured by amount of stake allocated to that validator will receive rewards. All other nominators -are essentially "wasting" their stake - they used their nomination to elect that validator to the -active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator -offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount), -which means that validator pools with more stake get slashed more DOT. Again, this is done to -provide nominators with an economic incentive to shift their preferences and back less popular -validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission -fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the -same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, -each validator can choose between increasing their fees to earn more, or decreasing their fees to -attract more nominators and increase their chances of being elected. In the long term, we expect -that all validators will need to be cost efficient to remain competitive, and that validators with -higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a - Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, - meaning it stays offline all the time. You can also designate a Proxy account to vote in - [governance](learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about - nominating and validating. It sets preferences like payout account and commission. If you are a - validator, it also sets your [session keys](learn-keys.md/#session-keys). It only needs enough - funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can -protect themselves much better than in systems with only one key. As a rule, you lose security -anytime you use one key for multiple roles, or even if you use keys related by derivation. You -should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in -Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots are limited, most of those who wish to stake their DOT and contribute economic -security to the network will be nominators. - -Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to -consensus in GRANDPA, validate the state transition function of parachains, and possibly some other -responsibilities regarding data availability and [XCMP](learn-crosschain). - -Nominators, on the other hand, have far fewer responsibilities. Those include monitoring their -validators' performance (uptime), keeping an eye on changing commission rates (a validator can -change commission at any time), and general health monitoring of their and their validators' -account. Thus, while not set-it-and-forget-it, a nominator's experience is relatively hands-off -compared to a validator's. - -![staking](assets/NPoS/article-2.png) - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot - network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot - network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs -modified software) in the network. They and their nominators will get slashed by losing a percentage -of their bonded/staked DOT. - -Any slashed DOT will be added to the [Treasury](learn-treasury). The rationale for this (rather than -burning or distributing them as rewards) is that slashes may then be reverted by the Council by -simply paying out from the Treasury. This would be useful in situations such as a faulty runtime -causing slashing or forcing validators offline through no fault of their own. In the case of -legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem -through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular -ones, so we encourage nominators to shift their nominations to less popular validators to reduce -their possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, -and slashes are not mitigated by having other inactive or waiting nominations. They are also not -mitigated by the validator operator running separate validators; each validator is considered its -own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus -causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has -nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with -other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the -active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The -nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and -waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not -actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any -nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In -this case, the slash is proportionate to the amount staked to that specific validator. For instance, -if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash -of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their -stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to -both halves of their stake. Note that you cannot control the percentage of stake you have allocated -to each validator or choose who your active validator will be (except in the trivial case of -nominating a single validator). Staking allocations are controlled by the -[Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this -via -[Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). -The UI shows it per validator and then all the affected nominators along with the amounts. While -unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 -days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are -[defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). However, these -particular levels are not implemented or referred to in the code or in the system; they are meant as -guidelines for different levels of severity for offences. To understand how slash amounts are -calculated, see the equations in the section below. - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch][]. Generally no - slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the - stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to - any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting - in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass - collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a -validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as -unresponsive. Depending on the repeated offences and how many other validators were unresponsive or -offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators in the active set - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Let us run through a few examples to understand this equation. In all of the examples, assume that -there are 100 validators in the active set. - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to -reduce the risk of being slashed or chilled. A high availability setup is desirable, perhaps with -backup nodes that kick in **only once the original node is verifiably offline** (to avoid -double-signing and being slashed for equivocation - see below). A comprehensive guide on validator -setup is available [here](maintain-guides-secure-validator.md). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -Both GRANDPA and BABE equivocation use the same formula for calculating the slashing penalty: - - Let x = offenders, n = total no. validators in active set - - Min( (3 * x / n )^2, 1) - -As an example, assume that there are 100 validators in the active set, and one of them equivocates -in a slot (for our purposes, it does not matter whether it was a BABE or GRANDPA equivocation). This -is unlikely to be an attack on the network, but much more likely to be a misconfiguration of a -validator. The penalty would be Min(3 \* 1 / 100)^2, 1) = 0.0009, or a 0.09% slash for that -validator pool (i.e., all stake held by the validator and its nominators). - -Now assume that there is a group runnning several validators, and all of them have an issue in the -same slot. The penalty would be Min((3 _ 5 / 100)^2, 1) = 0.0225, or a 2.25% slash. If 20 validators -equivocate, this is a much more serious offence and possibly indicates a coordinated attack on the -network, and so the slash will be much greater - Min((3 _ 20 / 100)^2, 1) = 0.36, or a 36% slash on -all of these validators and their nominators. All slashed validators will also be chilled. - -From the example above, the risk in nominating or running many validators in the active set are -apparent. While rewards grow linearly (two validators will get you approximately twice as many -staking rewards as one), slashing grows exponentially. A single validator equivocating causes a -0.09% slash, two validators equivocating does not cause a 0.09 \* 2 = 0.18% slash, but rather a -0.36% slash - 4x as much as the single validator. - -Validators may run their nodes on multiple machines to make sure they can still perform validation -work in case one of their nodes goes down, but validator operators should be extremely careful in -setting these up. If they do not have good coordination to manage signing machines, equivocation is -possible, and equivocation offences are slashed at much higher rates than equivalent offline -offences. - -If a validator is reported for any one of the offences they will be removed from the validator set -([chilled](#chilling)) and they will not be paid while they are out. They will be considered -inactive immediately and will lose their nominators. They need to re-issue intent to validate and -again gather support from nominators. - -If you want to know more details about slashing, please look at our -[research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of stepping back from any nominating or validating. It can be done by a -validator or nominator at any time themselves, taking effect in the next era. It can also specifally -mean removing a validator from the active validator set by another validator, disqualifying them -from the set of electable candidates in the next NPoS cycle. - -Chilling may be voluntary and validator-initiated, e.g. if there is a planned outage in the -validator's surroundings or hosting provider, and the validator wants to exit to protect themselves -against slashing. When voluntary, chilling will keep the validator active in the current session, -but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment (initiated externally), being chilled carries an implied penalty -of being un-nominated. It also disables the validator for the remainder of the current era and -removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too -large, Polkadot will trigger a new validator election to get a full set. Disabled validators will -need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill][] page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does - not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, -rather than the sum. This ensures protection from overslashing. Likewise, the time span over which -maximum slashes are computed are finite and the validator is chilled with nominations withdrawn -after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, -once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is -already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. -Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and -calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, -rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, -there may be slight differences in your rewards from era to era, and even amongst validators in the -active set at the same time. These variations should cancel out over a long enough timeline. See the -page on [Validator Payout Guide](maintain-guides-validator-payout.md) for more information on how -these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you -nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot -and 21 days on Kusama. For more information on why this is so, see the page on -[simple payouts](learn-simple-payouts.md). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim -> them and some of your staking rewards will be lost. Additionally, if the validator unbonds all -> their own stake, any pending payouts will be lost. Since unbonding takes 28 days on Polkadot, -> nominators should check if they have pending payouts at least this often. - -### Claiming Rewards - -If you go to the Staking payouts page on -[Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators -that you have nominated in the past 84 eras and for which you have not yet received a payout. Each -one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone -who was nominating that validator during those eras, and anyone can call it. Therefore, you may not -see anything in this tab, yet still have received a payout if somebody (generally, but not -necessarily, another nominator or the validator operator) has triggered the payout for that -validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See -[the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) -for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3_600 * 6 seconds = 21_600 s = 6 hours - -``` - -Validators can create a cut of the reward (a commission) that is not shared with the nominators. -This cut is a percentage of the block reward, not an absolute value. After the commission gets -deducted, the remaining portion is based on their staked value and split between the validator and -all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify -`validator_commission = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT -would then be split between the validator and their nominators based on the proportion of stake each -nominator had. Note that validators can put up their own stake, and for this calculation, their -stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either -increasing the staked value or not increasing the staked value), or to a completely unrelated -account. By using the Extrinsics tab (`Developer -> Extrinsics -> Staking -> Bond`) you can also -send rewards to "None", effectively burning them. It is also possible to top-up / withdraw some -bonded DOT without having to un-stake all staked DOT. - -For specific details about validator payouts, please see -[this guide](maintain-guides-validator-payout.md). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be -approximately 10% annually, with validator rewards being a function of amount staked and the -remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

Source: Research - Web3 Foundation

- -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the staking overview at -[Polkadot-JS](https://polkadot.js.org/apps/#/staking). - -The above chart shows the inflation model of the network. Depending on the staking participation, -the distribution of the inflation to validators/nominators versus the treasury will change -dynamically to provide incentives to participate (or not participate) in staking. - -For instance, assuming that the ideal staking rate is 50%, all of the inflation would go to the -validators/nominators if 50% of all KSM / DOT are staked. Any deviation from the 50% - positive or -negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, -please see -[here](https://w3f-research.readthedocs.io/en/latest/polkadot/overview/2-token-economics.html). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual nominal return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has increased gradually to 297. The top bound -on the number of validators has not been determined yet, but should only be limited by the bandwidth -strain of the network due to peer-to-peer message passing. The estimate of the number of validators -that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has -900 validator slots in the active set. - -## Motion #103: New Minimum Nomination Bond - -At the time of writing (#6,339,031), Polkadot has a maximum nominator count of 22,500, and the current staking configuration prevents new nominators from joining. Motion #103 proposes new nomination limits to the Polkadot network, offering a temporary solution to increase the stability and security of the network. Note that this motion **does not** increase the maximum nominator count. - -The goal of this motion is to increase the minimum nomination bond, allowing new nominators that meet this requirement to particpate in the network's security. This motion will update the value of the minimum nominator bond from 40 DOTs to 80 DOTs and set a new parameter named `chill-threshold`. With `chill-threshold`, the permissionless `chill_other` may only be executed if, and only if, the current nominator count is greater than 90% of the maximum number of nominators. Any existing nominator can update their nomination preferences (amount of DOT bonded, number of nominators, etc.) to adjust to this change. A more permanent solution is in progress. - -**Parameters changed:** -minimum nominator bond : `40` -> `80` - -**Parameters added:** -chill-threshold: `90%` - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Validator setup](maintain-guides-secure-validator.md) - -[epoch]: glossary.md#epoch -[how to chill]: maintain-guides-how-to-chill.md diff --git a/docs/learn-transaction-fees.md b/docs/learn-transaction-fees.md deleted file mode 100644 index 78b0be83fad5..000000000000 --- a/docs/learn-transaction-fees.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -id: learn-transaction-fees -title: Transaction Fees -sidebar_label: Transaction Fees ---- - -Several resources in a blockchain network are limited, for example, storage and computation. -Transaction fees prevent individual users from consuming too many resources. Polkadot uses a -weight-based fee model as opposed to a gas-metering model. As such, fees are charged prior to -transaction execution; once the fee is paid, nodes will execute the transaction. - -[Web3 Foundation Research](https://w3f-research.readthedocs.io/en/latest/polkadot/overview/2-token-economics.html?highlight=transaction%20fee) -designed the Polkadot fee system with the following objectives: - -- Each Relay Chain block should be processed efficiently to avoid delays in block production. -- The growth rate of the Relay Chain should be bounded. -- Each block should have space for special, high-priority transactions like misconduct reports. -- The system should be able to handle spikes in demand. -- Fees should change slowly so that senders can accurately predict the fee for a given transaction. - -## Fee Calculation - -Fees on the Polkadot Relay Chain are calculated based on three parameters: - -- A per-byte fee (also known as the "length fee"). -- A weight fee. -- A tip (optional). - -The length fee is the product of a constant per-byte fee and the size of the transaction in bytes. - -Weights are a fixed number designed to manage the time it takes to validate a block. Each -transaction has a base weight that accounts for the overhead of inclusion (e.g. signature -verification) as well as a dispatch weight that accounts for the time to execute the transaction. -The total weight is multiplied by a per-weight fee to calculate the transaction's weight fee. - -Tips are an optional transaction fee that users can add to give a transaction higher priority. - -Together, these three fees constitute the inclusion fee. This fee is deducted from the sender's -account prior to transaction execution. A portion of the fee will go to the block producer and the -remainder will go to the [Treasury](learn-treasury.md). At Polkadot's genesis, this is set to 20% -and 80%, respectively. - -## Block Limits and Transaction Priority - -Blocks in Polkadot have both a maximum length (in bytes) and a maximum weight. Block producers will -fill blocks with transactions up to these limits. A portion of each block - currently 25% - is -reserved for critical transactions that are related to the chain's operation. Block producers will -only fill up to 75% of a block with normal transactions. Some examples of operational transactions: - -- Misbehavior reports -- Council operations -- Member operations in an election (e.g. renouncing candidacy) - -Block producers prioritize transactions based on each transaction's total fee. Since a portion of -the fee will go to the block producer, producers will include the transactions with the highest fees -to maximize their reward. - -## Fee Adjustment - -Transaction volume on blockchains is highly irregular, and therefore transaction fees need a -mechanism to adjust. However, users should be able to predict transaction fees. - -Polkadot uses a slow-adjusting fee mechanism with tips to balance these two considerations. In -addition to block _limits_, Polkadot also has a block fullness _target._ Fees increase or decrease -for the next block based on the fullness of the current block relative to the target. The per-weight -fee can change up to 30% in a 24 hour period. This rate captures long-term trends in demand, but not -short-term spikes. To consider short-term spikes, Polkadot uses tips on top of the length and weight -fees. Users can optionally add a tip to the fee to give the transaction a higher priority. - -## Shard Transactions - -The transactions that take place within Polkadot's shards - parachains and parathreads - do not -incur Relay Chain transaction fees. Users of shard applications do not even need to hold DOT tokens, -as each shard has its own economic model and may or may not have a token. There are, however, -situations where shards themselves make transactions on the Relay Chain. - -[Parachains](learn-parachains.md) have a dedicated slot on the Relay Chain for execution, so their -collators do not need to own DOT in order to include blocks. The parachain will make some -transactions itself, for example, opening or closing an [XCMP](learn-crosschain.md) channel, -participating in an [auction](learn-auction.md) to renew its slot, or upgrading its runtime. -Parachains have their own accounts on the Relay Chain and will need to use those funds to issue -transactions on the parachain's behalf. - -[Parathreads](learn-parathreads.md) will also make all the same transactions that a parachain might. -In addition, the collators need to participate in an auction every block to progress their chain. -The collators will need to have DOT to participate in these auctions. - -## Other Resource Limitation Strategies - -Transaction weight must be computable prior to execution, and therefore can only represent fixed -logic. Some transactions warrant limiting resources with other strategies. For example: - -- Bonds: Some transactions, like voting, may require a bond that will be returned or slashed after - an on-chain event. In the voting example, returned at the end of the election or slashed if the - voter tried anything malicious. -- Deposits: Some transactions, like setting an [identity](learn-identity.md) or claiming an index, - use storage space indefinitely. These require a deposit that will be returned if the user decides - to free storage (e.g. clear their ide). -- Burns: A transaction may burn funds internally based on its logic. For example, a transaction may - burn funds from the sender if it creates new storage entries, thus increasing the state size. -- Limits: Some limits are part of the protocol. For example, nominators can only nominate 16 - validators. This limits the complexity of [Phragmén](learn-phragmen.md). - -## Advanced - -This page only covered transactions that come from normal users. If you look at blocks in a block -explorer, though, you may see some "extrinsics" that look different from these transactions. In -Polkadot (and any chain built on Substrate), an extrinsic is a piece of information that comes from -outside the chain. Extrinsics fall into three categories: - -- Signed transactions -- Unsigned transactions -- Inherents - -This page only covered signed transactions, which is the way that most users will interact with -Polkadot. Signed transactions come from an account that has funds, and therefore Polkadot can charge -a transaction fee as a way to prevent spam. - -Unsigned transactions are for special cases where a user needs to submit an extrinsic from a key -pair that does not control funds. For example, when users -[claim their DOT tokens](https://claims.polkadot.network) after genesis, their DOT address doesn't -have any funds yet, so that uses an unsigned transaction. Validators also submit unsigned -transactions in the form of "heartbeat" messages to indicate that they are online. These heartbeats -must be signed by one of the validator's [session keys](learn-keys.md). Session keys never control -funds. Unsigned transactions are only used in special cases because, since Polkadot cannot charge a -fee for them, each one needs its own, custom validation logic. - -Finally, inherents are pieces of information that are not signed or included in the transaction -queue. As such, only the block author can add inherents to a block. Inherents are assumed to be -"true" simply because a sufficiently large number of validators have agreed on them being -reasonable. For example, Polkadot blocks include a timestamp inherent. There is no way to prove that -a timestamp is true the way one proves the desire to send funds with a signature. Rather, validators -accept or reject the block based on how reasonable they find the timestamp. In Polkadot, it must be -within some acceptable range of their own system clocks. - -## Learn More - -- [Web3 Foundation Research](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html#relay-chain-transaction-fees-and-per-block-transaction-limits) -- [Substrate Weights](https://substrate.dev/docs/en/knowledgebase/learn-substrate/weight) -- [Substrate Fees](https://substrate.dev/docs/en/knowledgebase/runtime/fees) -- [Extrinsics](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics) diff --git a/docs/learn-treasury.md b/docs/learn-treasury.md deleted file mode 100644 index 0da8ca71eb92..000000000000 --- a/docs/learn-treasury.md +++ /dev/null @@ -1,313 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, -[staking inefficiencies](learn-staking.md#inflation), etc. The funds held in the Treasury can be -spent by making a spending proposal that, if approved by the [Council](learn-governance.md#council), -will enter a waiting period before distribution. This waiting period is known as the budget period, -and its duration is subject to [governance](learn-governance.md), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can -without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a -percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% -on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to -[Society](https://guide.kusama.network/docs/maintain-guides-society-kusama) rather than being -burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit of at -least 5% of the proposed spend (see below for variations). This deposit will be slashed if the -proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#council), and how the funds -will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury - with a reward going to the entity that reported the validator (another validator). The reward is - taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the - remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking.md#inflation) is designed to be 10% in the first - year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in - staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to - the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to - the validators as reward. If the staking rate is greater than or less than 50%, then the - validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads.md) participate in a per-block auction for block - inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes - to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is -higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded -otherwise. These values are subject to [governance](learn-governance.md) so they may change in the -future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been -submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, -the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a -proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion -takes place on the following platforms: - -- Many community members participate in discussion in the - [Kusama Element (previously Riot)](https://matrix.to/#/#kusama:matrix.parity.io) chat or - [Polkadot Element](https://matrix.to/#//#polkadot:matrix.parity.io). -- The [Polkassembly](https://polkassembly.io) discussion platform that allows users to log in with - their Web3 address and automatically reads proposals from the chain, turning them into discussion - threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a - vote. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the -recommended way is using official Element channels like {{ polkadot: the -[Polkadot Watercooler](https://matrix.to/#/#polkadot-watercooler:web3.foundation) and -[Polkadot Direction room](https://matrix.to/#/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the -[Kusama Direction room](https://matrix.to/#/#kusama:matrix.parity.io) or the -[Kusama Watercooler](https://matrix.to/#/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps -[website](https://polkadot.js.org/apps). From the website, use either the -[extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then -`proposeSpend` and enter the desired amount and recipient, or use the -[Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values -mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start -voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and -purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It -is possible that one motion to accept and another motion to reject are both created. The proportions -to accept and reject Council proposals vary between accept or reject, and possibly depend on which -network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the -other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can -be suggested by anyone and are supported by members of the Council. Tips do not have any definite -value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not -the direct responsibility of the Council, and at some point the Council and the tippers may be -different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a -tip. During that timeframe, the other members of the tipping group can still issue their tips, but -do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will -be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required -to place them. This bond depends on the tip message length, and a fixed bond constant defined on -chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips -that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. -Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council -is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two -arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a -UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for -why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the -base deposit as set in the chain's parameter list plus the additional deposit per byte contained in -the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it -was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the -tippers. - -Since the tipper group is the same as the Council, the Council must now collectively (but also -independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of -the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the -tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, -the third tipper issued their tip before the end of the closing period, so all three were able to -make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of -the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury -proposals: Council members likely do not have the expertise to make a proper assessment of the -activities described in all proposals. Even if individual Councillors have that expertise, it is -highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts -called Curators: They can be defined as addresses with agency over a portion of the Treasury with -the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks -related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, -whose background and expertise is such that they are capable of determining when the task is -complete. Curators are selected by the Council after the bounty proposal passes, and need to add an -upfront payment to take the position. This deposit can be used to punish them if they act -maliciously. However, if they are successful in their task of getting someone to complete the bounty -work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to -invest their time and expertise in the task: this amount is included in the total value of the -bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid -to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues -the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, -and show project management skills or experience. These recommendations ensure an effective use of -the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of -objectives - that needs to be executed for a predefined treasury amount to be paid out. The -responsibility of assigning a payout address once the specified set of objectives is completed is -delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the -curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to -the payout address and a payout of the curator fee. The delay phase allows the Council to act if any -issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual -information. When a user submits a bounty spending proposal, they will probably need to find an -off-chain way to explain the proposal (any of the available community forums serve this purpose). -[This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) -can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the -curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create -sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on -the dedicated Bounty section under Governance. The development of a robust user interface to view -and manage bounties in the Polkadot Apps is still under development and it will serve Council -members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain -treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a -motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the -governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the -button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the -requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a -motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://matrix.to/#/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: Kusama Direction [channel](https://matrix.to/#/#kusama:matrix.parity.io) :kusama }} in -Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a -short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for -contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the -tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by -amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should -make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty -enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then -`Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is -important to note that those who received a reward after the bounty is completed, must claim the -specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator -closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this -[Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial -mindset, we may consider the possibility that the Council may at some point go rogue and attempt to -steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a -large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. -The burn aims to incentivize the complete spend of all treasury funds at every burn period, so -ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the -case that the burn on the Treasury could be so little that it does not matter - as is the case -currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the -community. Remember, the Council is voted in by the token holders, so they must do some campaigning -or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would -lose their social credibility. Furthermore, members of the Council are usually externally motivated -by the proper operation of the chain. This external motivation is either because they run businesses -that depend on the chain, or they have direct financial gain (through their holdings) of the token -value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council -majority may not be the token majority of the chain. This means that the token majority could vote -to replace the Council if they attempted this attack - or even reverse the treasury spend. They -would do this through a normal referendum. Two, there are time delays to treasury spends. They are -only enacted every spend period. This means that there will be some time to observe this attack is -taking place. The time delay then allows chain participants time to respond. The response may take -the form of governance measures or - in the most extreme cases a liquidation of their holdings and a -migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - - The Rust implementation of the Treasury. - ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/docs/learn-validator.md b/docs/learn-validator.md deleted file mode 100644 index dcf575be35e6..000000000000 --- a/docs/learn-validator.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -id: learn-validator -title: Validator -sidebar_label: Validator ---- - -Validators secure the [Relay Chain](learn-architecture.md#relay-chain) by staking DOT, validating -proofs from collators and participating in consensus with other validators. - -These participants play a crucial role in adding new blocks to the Relay Chain and, by extension, to -all parachains. This allows parties to complete cross-chain transactions via the Relay Chain. -Parachain validators participate in some form of off-chain consensus, and submit candidate receipts -to the tx pool for a block producer to include on-chain. The Relay Chain validators guarantee that -each parachain follows its unique rules and can pass messages between shards in a trust-free -environment. - -Validators perform two functions: - -1. **Verifying** that the information contained in an assigned set of parachain blocks is valid - (such as the identities of the transacting parties and the subject matter of the contract). -2. **Participating** in the consensus mechanism to produce the Relay Chain blocks based on validity - statements from other validators. Any instances of non-compliance with the consensus algorithms - result in punishment by removal of some or all of the validator’s staked DOT, thereby - discouraging bad actors. Good performance, however, will be rewarded, with validators receiving - block rewards (including transaction fees) in the form of DOT in exchange for their activities. - -## Guides - -- [How to Validate on Polkadot](maintain-guides-how-to-validate-polkadot.md) - Guide on how to set - up a validator on the Polkadot live network. -- [Validator Payout Overview](maintain-guides-validator-payout.md) - A short overview on how the - validator payout mechanism works. -- [How to run your validator as a systemd process](maintain-guides-how-to-systemd.md) - Guide on - running your validator as a `systemd` process so that it will run in the background and start - automatically on reboots. -- [How to Upgrade your Validator](maintain-guides-how-to-upgrade.md) - Guide for securely upgrading - your validator when you want to switch to a different machine or begin running the latest version - of client code. -- [How to Use Validator Setup](maintain-guides-how-to-use-polkadot-validator-setup.md) - Guide on how - to use Polkadot / Kusama validator setup. - -## Other References - -- [How to run a Polkadot node (Docker)](https://medium.com/@acvlls/setting-up-a-maintain-the-easy-way-3a885283091f) -- [A Serverless Failover Solution for Web3.0 Validator Nodes](https://medium.com/hackernoon/a-serverless-failover-solution-for-web-3-0-validator-nodes-e26b9d24c71d) - - Blog that details how to create a robust failover solution for running validators. -- [VPS list](maintain-guides-how-to-validate-kusama.md#vps-list) -- [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - - A place to chat about being a validator. -- [Slashing Consequences](learn-staking#slashing) - Learn more about slashing consequences for - running a validator node. -- [Why You Should be A Validator on Polkadot and Kusama](https://www.youtube.com/watch?v=0EmP0s6JOW4&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=2) -- [Roles and Responsibilities of a Validator](https://www.youtube.com/watch?v=riVg_Up_fCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=15) -- [Validating on Polkadot](https://www.crowdcast.io/e/validating-on-polkadot) - An explanation of - how to validate on Polkadot, with Joe Petrowski and David Dorgan of Parity Technologies, along - with Tim Ogilvie from Staked. - -## Security / Key Management - -- [Validator Security Overview](https://github.com/w3f/validator-security) - -## Monitoring Tools - -- [PANIC for Polkadot](https://github.com/SimplyVC/panic_polkadot) - A monitoring and alerting - solution for Polkadot / Kusama node -- [Polkadot Telemetry Service](https://telemetry.polkadot.io/#list/Kusama%20CC3) - Network - information, including what nodes are running on a given chain, what software versions they are - running, and sync status. -- [Other Useful Links](https://forum.web3.foundation/t/useful-links-for-validators/20) - -## Validator Stats - -- [HashQuark Staking Strategy](https://polkacube.hashquark.io/#/polkadot/strategy) - The HashQuark - staking strategy dashboard helps you choose the optimal set-up to maximize rewards, and provides - other useful network monitoring tools. -- [Polkastats](https://polkastats.io/) - Polkastats is a cleanly designed dashboard for validator - statistics. -- [YieldScan](https://yieldscan.app/) - Staking yield maximization platform, designed to minimize - effort. -- [Subscan Validators Page](https://kusama.subscan.io/validator) - Displays information on the - current validators - not as tailored for validators as the other sites. diff --git a/docs/learn/learn-DOT.md b/docs/learn/learn-DOT.md new file mode 100644 index 000000000000..80e556893acf --- /dev/null +++ b/docs/learn/learn-DOT.md @@ -0,0 +1,188 @@ +--- +id: learn-DOT +title: DOT +sidebar_label: DOT +slug: ../learn-DOT +--- + +## What is DOT? + +DOT is the native token of the Polkadot network in a similar way that BTC is the native token of +Bitcoin or Ether is the native token of the Ethereum blockchain. + +The smallest unit of account in a Substrate network (Polkadot, Kusama, etc.) is the Planck (a +reference to [Planck Length](https://en.wikipedia.org/wiki/Planck_length), the smallest possible +distance in the physical Universe). You can compare the Planck to Satoshis or Wei, while the DOT is +like a bitcoin or an ether. Kusama tokens (KSM) are equal to 1e12 Planck, and Polkadot mainnet DOT +is equal to 1e10 Planck. + +### Polkadot + +| Unit | Decimal Places | Example | +| --------------- | -------------- | ------------ | +| Planck | 0 | 0.0000000001 | +| Microdot (uDOT) | 4 | 0.0000010000 | +| Millidot (mDOT) | 7 | 0.0010000000 | +| Dot (DOT) | 10 | 1.0000000000 | +| Million (MDOT) | 16 | 1,000,000.00 | + +> Note: This changed at block #1*248_328. Previously, DOT was denominated as equal to 1e12 Planck, +> just like Kusama. This denomination is deprecated, and, if necessary, referred to as "DOT (old)". +> See [Redenomination of DOT](../general/redenomination.md) for more details.* + +### Kusama + +| Unit | Decimal Places | Example | +| --------------- | -------------- | -------------- | +| Planck | 0 | 0.000000000001 | +| Point | 3 | 0.000000001000 | +| MicroKSM (uKSM) | 6 | 0.000001000000 | +| MilliKSM (mKSM) | 9 | 0.001000000000 | +| KSM | 12 | 1.000000000000 | + +## What are the uses of DOT? + +DOT serves three key functions in Polkadot: + +- to be used for governance of the network, +- to be staked for the operation of the network, +- to be bonded to connect a chain to Polkadot as a parachain. + +DOT can also serve ancillary functions by virtue of being a transferrable token. For example, DOT +stored in the Treasury can be sent to teams working on relevant projects for the Polkadot network. + +> These concepts have been further explained in the video +> [Usage of DOT and KSM on Polkadot and Kusama](https://www.youtube.com/watch?v=POfFgrMfkTo&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=7). + +### DOT for Governance + +The first function of DOT is to entitle holders to control the governance of the platform. Some +functions that are included under the governance mechanism include determining the fees of the +network, the addition or removal of parachains, and exceptional events such as upgrades and fixes to +the Polkadot platform. + +Polkadot will enable any holder of DOT to participate in governance. For details on how holders can +participate in governance, as well as their rights and responsibilities, see the +[governance page](learn-governance.md). + +### DOT for Consensus + +DOT will be used to facilitate the consensus mechanism that underpins Polkadot. For the platform to +function and allow for valid transactions to be carried out across parachains, Polkadot will rely on +holders of DOT to play active roles. Participants will put their DOT at risk (via staking) to +perform these functions. The staking of DOT acts as a disincentive for malicious participants who +will be punished by the network by getting their DOT slashed. The DOT required to participate in the +network will vary depending on the activity that is being performed, the duration the DOT will be +staked for, and the total number of DOT staked. + +### DOT for Parachain Slot Acquisition + +DOT will have the ability to be locked for a duration in order to secure a parachain slot in the +network. The DOT will be reserved during the slot lease and will be released back to the account +that reserved them after the duration of the lease has elapsed and the parachain is removed. You can +learn more about this aspect by reading about the [auctions](learn-auction.md) that govern parachain +slots. + +### Vesting + +DOT may have a lock placed on them to account for vesting funds. Like other types of locks, these +funds cannot be transferred but can be used in other parts of the protocol such as voting in +governance or being staked as a validator or nominator. + +Vesting funds are on a linear release schedule and unlock a constant number of tokens at each block. +Although the tokens are released in this manner, it does not get reflected on-chain automatically +since locks are [lazy](#lazy-vesting) and require an extrinsic to update. + +There are two ways that vesting schedules can be created. + +- One way is as part of the genesis configuration of the chain. In the case of Polkadot and Kusama, + the chain specification genesis script reads the state of the Polkadot Claims contract that exists + on the Ethereum blockchain and creates vesting schedules in genesis for all the allocations + registered as being vested. +- A second way is through an extrinsic type available in the Vesting pallet, `vested_transfer`. The + vested transfer function allows anyone to create a vesting schedule with a transfer of funds, as + long as the account for which the vesting schedule will be created does not already have one and + the transfer moves at least `MinVestedTransfer` funds, which is specified as a chain constant. + +Vesting schedules have three parameters, `locked`, `per_block`, and `starting_block`. The +configuration of these three fields dictate the amount of funds that are originally locked, the +slope of the unlock line and the block number for when the unlocking begins. + +#### Lazy Vesting + +Like [simple payouts](learn-simple-payouts.md), vesting is _lazy_, which means that someone must +explicitly call an extrinsic to update the lock that is placed on an account. + +- The `vest` extrinsic will update the lock that is placed on the caller. +- The `vest_other` will update the lock that is placed on another "target" account's funds. + +These extrinsics are exposed from the Vesting pallet. + +If you are using Polkadot-JS, when there are DOT available to vest for an account, then you will +have the ability to unlock DOT which has already vested from the +[Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![unbond](../assets/unlock-vesting.png) + +#### Calculating When Vesting DOT Will Be Available + +Generally, you should be able to see from the [Accounts](https://polkadot.js.org/apps/#/accounts) by +looking at your accounts and seeing when the vesting will finish. However, some DOT vest with +"cliffs" - a single block where all the DOT are released, instead of vesting over time. In this +case, you will have to query the chain state directly to see when they will be available (since +technically, the vesting has not yet started - all of the vesting will occur in a single block in +the future). + +1. Navigate to the + [Chain State](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/chainstate) page on + Polkadot-JS. +2. Query chain state for `vesting.vesting(ACCOUNT_ID)` +3. Note the `startingBlock` where the unlock starts, and how much DOT is unlocked per block + (`perBlock`). +4. You will have to calculate the result into “human time". To do this, remember that there are + approximately 14’400 blocks per day, and you can see what the latest block is shown on the + [Explorer](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/explorer) page. + +## Obtaining Testnet DOT + +DOT are required to make transactions on the Polkadot network. Testnet DOT do not have any value +beside allowing you to experiment with the network. + +### Getting Westies + +The current testnet is called [Westend](../maintain/maintain-networks.md#westend-test-network) and you can +obtain its native tokens by posting `!drip ` in the Matrix chatroom +[#westend_faucet:matrix.org](https://matrix.to/#/#westend_faucet:matrix.org). + +You can also make your own WNDs (testnet DOT) by [becoming a validator](learn-validator.md). + +### Westend + +| Unit | Decimal Places | Example | +| --------------- | -------------- | -------------- | +| Planck | 0 | 0.000000000001 | +| Point | 3 | 0.000000001000 | +| MicroWND (uWND) | 6 | 0.000001000000 | +| MilliWND (mWND) | 9 | 0.001000000000 | +| WND | 12 | 1.000000000000 | + +### Getting Rococo Tokens + +Rococo is a parachain testnet. Tokens are given directly to teams working on parachains or exploring +the [crosschain](learn-crosschain.md) message passing aspects of this testnet. General users can +obtain ROC by posting `!drip ` in the Matrix chatroom +[#rococo-faucet:matrix.org](https://matrix.to/#/#rococo-faucet:matrix.org). + +Learn more about Rococo on its [dedicated wiki page](../build/build-parachains-rococo.md). + +## Kusama Tokens + +Unlike testnet DOT, Kusama tokens are not freely given away. Kusama tokens are available via the +[claims process](https://claim.kusama.network/) (if you had DOT at the time of Kusama genesis) or +through the [Treasury](learn-treasury.md). Alternatively, they can be obtained on the open market. + +## Polkadot Mainnet DOT + +Polkadot Mainnet DOT are not freely given away. If you purchased DOT in the original 2017 offering, +you may claim them via the [Polkadot claims process](https://claims.polkadot.network/). +Alternatively, they are available on the open market. diff --git a/docs/learn/learn-account-generation.md b/docs/learn/learn-account-generation.md new file mode 100644 index 000000000000..5fe8c91cbf36 --- /dev/null +++ b/docs/learn/learn-account-generation.md @@ -0,0 +1,354 @@ +--- +id: learn-account-generation +title: Account Generation +sidebar_label: Account Generation +description: Step-by-step guides on generating a Polkadot account. +slug: ../learn-account-generation +--- + +An address is the public part of a Polkadot account. The private part is the key used to access this +address. The public and private parts together make up a Polkadot account. + +There are several ways to generate a Polkadot account: + +- [Polkadot{.js} Browser Plugin](#polkadotjs-browser-plugin) **RECOMMENDED FOR MOST USERS** +- [Subkey](#subkey) **ADVANCED and MOST SECURE** +- [Polkadot-JS Apps](#polkadot-js-apps) +- [Parity Signer](#parity-signer) +- [Vanity Generator](#vanity-generator) +- [Ledger Hardware Wallet](../general/ledger.md) + +> If you prefer video instructions, we have an easy to follow guide +> [on YouTube](https://www.youtube.com/watch?v=hhUZ40ZWqkE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=19) + +## DISCLAIMER: Key Security + +The _only_ ways to get access to your account are via your secret seed or your account's JSON file +in combination with a password. You must keep them both secure and private. If you share them with +anyone they will have full access to your account, including all of your funds. This information is +a target for hackers and others with bad intentions - see also +[How to Recognize Scams](../general/scams.md). + +On this page, we recommend a variety of account generation methods that have various convenience and +security tradeoffs. Please review this page carefully before making your account so that you +understand the risks of the account generation method you choose and how to properly mitigate them +in order to keep your funds safe. + +### Storing your key safely + +The seed is your **key** to the account. Knowing the seed allows you, or anyone else who knows the +seed, to re-generate and control this account. + +It is imperative to store the seed somewhere safe, secret, and secure. If you lose access to your +account (i.e. you forget the password for your account's JSON file), you can re-create it by +entering the seed. This also means that somebody else can have control over your account if they +have access to your seed. + +For maximum security, the seed should be written down on paper or another non-digital device and +stored in a safe place. You may also want to protect your seed from physical damage, as well (e.g. +by storing in a sealed plastic bag to prevent water damage, storing it in a fireproof safe, etching +it in metal, etc.) It is recommended that you store multiple copies of the seed in geographically +separate locations (e.g., one in your home safe and one in a safety deposit box at your bank). + +You should +**not store your seed on any kind of computer that has or may have access to the internet in the future.** + +### Storing your account's JSON file + +The JSON file is encrypted with a password, which means you can import it into any wallet which +supports JSON imports, but to then use it, you need the password. You don't have to be as careful +with your JSON file's storage as you would with your seed (i.e. it can be on a USB drive near you), +but remember that in this case, your account is only as secure as the password you used to encrypt +it. Do not use easy to guess or hard to remember passwords. It is good practice to use a +[mnemonic password of four to five words](https://xkcd.com/936/). These are nearly impossible for +computers to guess due to the number of combinations possible, but much easier for humans to +remember. + +## Polkadot{.js} Browser Plugin + +The Polkadot{.js} plugin provides a reasonable balance of security and usability. It provides a +separate local mechanism to generate your address and interact with Polkadot. + +This method involves installing the Polkadot{.js} plugin and using it as a “virtual vault," separate +from your browser, to store your private keys. It also allows the signing of transactions and similar +functionality. + +It is still running on the same computer you use to connect to the internet with and thus is less +secure than using Parity Signer or other air-gapped approaches. + +### Install the Browser Plugin + +The browser plugin is available for both +[Google Chrome](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd?hl=en) +(and Chromium-based browsers like Brave) and +[FireFox](https://addons.mozilla.org/en-US/firefox/addon/polkadot-js-extension). + +If you would like to know more or review the code of the plugin yourself, you can visit the +[Github source repository](https://github.com/polkadot-js/extension). + +After installing the plugin, you should see the orange and white Polkadot{.js} logo in the menu bar +of your browser. + +![plugin-02](../assets/accounts/polkadot_plugin_js_02.jpg) + +### Create Account + +Open the Polkadot{.js} browser extension by clicking the logo on the top bar of your browser. You +will see a browser popup, not unlike the one below. + +![Initial PolkadotJS popup](../assets/accounts/polkadot_plugin_js_new_01.png) + +Click the big plus button or select "Create new account" from the small plus icon in the top right. +The Polkadot{.js} plugin will then use system randomness to make a new seed for you and display it +to you in the form of twelve words. + +![New seed](../assets/accounts/polkadot_plugin_js_new_02.png) + +You should back up these words as [explained above](#storing-your-key-safely). It is imperative to +store the seed somewhere safe, secret, and secure. If you cannot access your account via +Polkadot{.js} for some reason, you can re-enter your seed through the "Add account menu" by +selecting "Import account from pre-existing seed". + +![New seed](../assets/accounts/polkadot_plugin_js_new_03.png) + +### Name Account + +The account name is arbitrary and for your use only. It is not stored on the blockchain and will not +be visible to other users who look at your address via a block explorer. If you're juggling multiple +accounts, it helps to make this as descriptive and detailed as needed. + +### Enter Password + +The password will be used to encrypt this account's information. You will need to re-enter it when +using the account for any kind of outgoing transaction or when using it to cryptographically sign a +message. + +Note that this password does NOT protect your seed phrase. If someone knows the twelve words in your +mnemonic seed, they still have control over your account even if they do not know the password. + +### Set Address for Polkadot Mainnet + +Now we will ensure that the addresses are displayed as Polkadot mainnet addresses. + +Click on "Options" at the top of the plugin window, and under "Display address format for" select +"Polkadot Relay Chain". + +![New seed](../assets/accounts/polkadot_plugin_js_new_04.png) + +Your address' format is only visual - the data used to derive this representation of your address +are the same, so you can use the same address on multiple chains. However, for privacy reasons, we +recommend creating a new address for each chain you're using. + +Our [Accounts page](learn-accounts.md#address-conversion-tools) also has a tool you can use to +convert your address between the different chain formats. + +You can copy your address by clicking on the account's icon while the desired chain format is +active. E.g. selecting "Substrate" as the format will change your address to start with the number +5, and clicking the colorful icon of your account will copy it in that format. While in Polkadot +mode (starts with 1), that format will be copied, and so on. + +## Subkey + +Subkey is recommended for technically advanced users who are comfortable with the command line and +compiling Rust code. Subkey allows you to generate keys on any device that can compile the code. +Subkey may also be useful for automated account generation using an air-gapped device. It is not +recommended for general users. + +For detailed build and usage instructions of subkey, please see +[here](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). + +![subkey-01](../assets/accounts/subkey_01.jpg) + +## Polkadot-JS Apps + +> Please note! If you use this method to create your account and clear your cookies in your browser, +> your account will be lost forever if you do not [back it up](learn-account-restore.md). Make sure +> you store your seed phrase in a safe place, or download the account's JSON file if using the +> Polkadot{.js} browser extension. Learn more about account backup and restoration +> [here](learn-account-restore.md). + +Using the Polkadot-JS user interface without the plugin is **not recommended**. It is the least +secure way of generating an account. It should only be used if all of the other methods are not +feasible in your situation. + +### Go to Polkadot-JS Apps + +Navigate to [Polkadot-JS Apps](https://polkadot.js.org/apps) and click on "Accounts" underneath the +Accounts tab. It is located in the navigation bar at the top of your screen. + +![pjs-01](../assets/accounts/polkadot_js_01.png) + +> To create an account on a different network than Polkadot, you'll need to click on the network +> selection in the top left corner of the navigation menu. A pop-up sidebar will appear listing +> live, testing, and custom node to choose from. Do remember to hit the "Switch" button when you +> want to switch your network. + +### Start Account Generation + +Click on the "Add Account" button. You should see a pop-up similar to the process encountered when +using the [Polkadot JS Extension method](#polkadotjs-browser-plugin) above. Follow the same +instructions and remember to [store your seed safely](#storing-your-key-safely)! + +### Create and Back-Up Account + +Click “Save” and your account will be created. It will also generate a +[backup JSON file](#storing-your-accounts-json-file) that you should safely store, ideally on a USB +off the computer you're using. You should not store it in cloud storage, email it to yourself, etc. + +You can use this backup file to restore your account. This backup file is not readable unless it is +decrypted with the password. + +### Multi-signature Accounts + +Multi-signature accounts are accounts created from several standard accounts (or even other +multi-sig accounts). For a full explanation, please see the +[Accounts Explainer section on multi-sigs](learn-accounts.md#multi-signature-accounts). + +On the [Accounts](https://polkadot.js.org/apps/#/accounts) tab, click the `Multisig` button. Enter +the threshold and add signatories. The threshold must be less than or equal to the number of +signatories. The threshold indicates how many members must agree for an extrinsic +submission to be successful. Click `Create` when done. + +![Multi-sig account creation](../assets/accounts/create-multisig.png) + +This merely calculates the multi-signature's address and adds it to your UI. The account does not +exist yet, and is subject to the same +[Existential Deposit and Reaping](learn-accounts.md#existential-deposit-and-reaping) rules as +regular accounts. + +Suppose we funded it with some tokens, and now want to send from the multi-sig to another account. + +![Sending from multi-sig account](../assets/accounts/send-from-multi.png) + +The next step is to sign the transaction from with enough accounts to meet the threshold; in the +above case, two out of three signatories must sign. + +![Signing from multi-sig account](../assets/accounts/sign-from-multi-1.png) + +There is currently no indication of a pending transaction from a multi-sig in the UI. This means the +second signatory must **repeat the call in full** in order to sign it. In other words: + +- if Alice initiates a transaction from the multi-sig to Ferdie for 150 tokens, there will be a + pending transaction in the chain. +- if Bob initiates a transaction from the multi-sig to Ferdie for 250 tokens, there will be + **another** pending transaction in the chain, and the first one will not complete. +- because the threshold is 2/3, Charlie can now finalize either or both of these by repeating the + desired transaction. + +Other calls work the same - if a multi-sig wants to become a Council member, the candidacy +request has to come from the multi-sig, but be signed (re-requested) from each signatory until the +threshold is reached. + +Signatories should communicate off-chain to prevent many pending transactions and crossed +communication lines on-chain. + +> The bigger the multisig, the more of a deposit an account needs to put down when initiating a +> multi-sig call. This is to prevent chain storage spam with pending but never-resolved multi-sig +> transactions. Once a call is resolved (canceled or executed) the deposit is returned to the +> initiator. The deposit is not taken from the multi-sig's balance but from the initiator. + +For a more in-depth introduction into multi-signature accounts on Polkadot, please see +[the accounts page section on Multi-sigs](learn-accounts.md#multi-signature-accounts). + +## Parity Signer + +Parity Signer is a secure way of storing your DOT on an air-gapped device. It is highly recommended +that you turn off wifi, cellular network, Bluetooth, NFC, and any other communications methods after +installing it. The device needs to be offline and only you should be viewing the device screen. If +you have any communications methods turned on, you will see an "unshielded" icon in red in the +top-right corner that indicates your connection may not be secure. + +### Create Account + +Click "Create" to create an identity, or "recover" if you have previously backed up the recovery +phrase. You can have multiple identities on one device. Each identity can manage multiple addresses +on different networks. + +![Parity Signer Create Account 1](../assets/accounts/ps-create-1.jpg) + +### Name Account + +Input the name for your identity and then click "Create". + +![Parity Signer Create Account 2](../assets/accounts/ps-create-2.jpg) + +### Back Up Account + +Parity Signer will then generate a recovery phrase for you and display it in the form of 12 or 24 +words. + +You should write down this recovery phrase on paper and +[store it somewhere safe](#storing-your-key-safely). + +![Parity Signer Create Account 3](../assets/accounts/ps-create-3.jpg) + +### Set PIN + +After confirming that you have backed up your seed, a new textbox will appear in which you can set a +PIN. The PIN code should contain at least 6 digits. If the PIN codes do not match, it will not allow +you to create an account. The PIN code will be used when signing any transaction, or to protect +sensitive operations such as deleting an identity or revealing the recovery phrase. + +Note that if someone knows the 12/24 words in your recovery phrase, they will still have control +over your account, even if they do not know the PIN. + +![Parity Signer Create Account 4](../assets/accounts/ps-create-4.jpg) + +### Get Address + +Choose which network you would like to create an address for by clicking the name of the network. +For example, if you select "Polkadot", a new Polkadot address will be created for you under this +identity. + +![Parity Signer Create Account 5](../assets/accounts/ps-create-5.jpg) + +There is currently no way to copy your address from Parity signer in plain text in order to send it +via text or email. You must use the QR method. + +### Your Address + +The address will be shown as a QR code. You can import your address to the Polkadot-JS Apps by going +to the [Accounts](https://polkadot.js.org/apps/#/accounts) page on an Internet-connected computer +and click "Add via QR", and following the instructions to add the account. An account created this +way will always require you to sign messages with your Parity Signer device. It will do this only by +scanning and displaying QR codes, leaving even someone with total control of your internet-connected +computer has a very small and limited scope for interacting with the Parity Signer device, which can +continue to keep your key safe. + +![Parity Signer Create Account 6](../assets/accounts/ps-create-6.jpg) + +## Ledger Hardware Wallet + +To use a Ledger hardware wallet to create your address and keep your tokens in cold storage, follow +the instructions on our [Ledger hardware wallet guide page](../general/ledger.md). + +## Vanity Generator + +The vanity generator is a tool on [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts/vanity) +that lets you generate addresses that contain a specific substring. + +![Vanity Generator page](../assets/polkadot_vanity_generator_page.png) + +The vanity generator takes the following parameters: + +- "Search for": The substring that you would like to include in your new address. +- "case sensitive": "Yes" if the search is case sensitive; "no" if not. +- "keypair crypto type": Specifies the type of account you'd like to generate; Schnorrkel is + recommended in most cases for its security. + +If you've filled out all details above and hit the "Start generation" button, a list of accounts +will start generating on your screen. Note that depending on the length of the substring and the +processing speed of your computer, it may take some time before any accounts appear. + +![Vanity Generator search](../assets/polkadot_vanity_generate.png) + +The "Save" button will allow you to save the generated accounts - they are not saved if you do not +choose to do this. The next steps are identical to the +[steps above on creating an account on the UI](#polkadotjs), where a password and name need to be +filled in, and a backup file of your account will be downloaded. + +Note that the [Subkey tool](#subkey) also has vanity generation built-in, and is orders of magnitude +faster than the web version. If you need to generate addresses with longer strings, or need plenty +of them, we recommend using Subkey instead. + +![Vanity Generator chosen address](../assets/polkadot_save_account.png) diff --git a/docs/learn-account-restore.md b/docs/learn/learn-account-restore.md similarity index 87% rename from docs/learn-account-restore.md rename to docs/learn/learn-account-restore.md index fd1e796cc955..bd9e2c0a5d7d 100644 --- a/docs/learn-account-restore.md +++ b/docs/learn/learn-account-restore.md @@ -3,6 +3,7 @@ id: learn-account-restore title: Backing up and Restoring Accounts sidebar_label: Backing up and Restoring Accounts description: Step-by-step guides on backing up and restoring a Polkadot account. +slug: ../learn-account-restore --- Depending on what software you are using to access your account, there are various ways to back up @@ -21,7 +22,7 @@ To back up an account using the Polkadot{.js} browser plugin, open the extension desired account to back up. Click on the three dots beside the address to open up the account options menu. -![list-accounts-plugin](assets/accounts/polkadot.js_list_accounts.png) +![list-accounts-plugin](../assets/accounts/polkadot.js_list_accounts.png) Click on the Export Account button, which will then ask you for the password for that specific account. Once you enter the correct password, the browser will automatically download a `.json` file @@ -29,14 +30,14 @@ that will hold all the account restoration details that will be used when you re You should store this file securely. Note that you will need the password for this account to restore it. -![enter-password-plugin](assets/accounts/polkadot.js_enter_password.png) +![enter-password-plugin](../assets/accounts/polkadot.js_enter_password.png) To restore the account from this JSON file, once again open the Polkadot{.js} browser plugin. Click on the + button at the top. This will open up a menu wih several choices - select "Restore account from backup JSON file". The program then prompts you for the `.json` file which was download earlier and the password for that account. -![restore-account-plugin](assets/accounts/polkadot.js_restore_account.png) +![restore-account-plugin](../assets/accounts/polkadot.js_restore_account.png) Once these are filled out, and the "Restore" button has been pressed, you'll be taken back to the main page of the plugin. This account will now be listed with the rest of your accounts. @@ -47,19 +48,19 @@ If you're using the main Polkadot-JS UI, restoring an account will feel similar account on Polkadot-JS browser plugin. Navigate to the [Accounts page](https://polkadot.js.org/apps/#/accounts) of Polkadot-JS. -![click-account-restore-polkadot](assets/accounts/polkadot_click_restore.png) +![click-account-restore-polkadot](../assets/accounts/polkadot_click_restore.png) Click on the "Restore JSON" button, which will let you upload your `.json` file that you downloaded and enter your password for that account. This `.json` file holds all relevant data about the account to be used in account restoration. Note that you will need to enter your password here; the file cannot be unencrypted without it. -![restore-account-polkadot](assets/accounts/polkadot_restore_account.png) +![restore-account-polkadot](../assets/accounts/polkadot_restore_account.png) After you press the "Restore" button, you should see a green notification letting you know that your account has been restored. It will now be included in your accounts list on this browser. -![restore-complete-polkadot](assets/accounts/polkadot_restore_complete.png) +![restore-complete-polkadot](../assets/accounts/polkadot_restore_complete.png) ### Using an Existing Mnemonic Seed to Restore an Account @@ -77,7 +78,7 @@ creating a new account, rather adding that account onto the Polkadot-JS UI. Any same seed words will have control over that account on-chain. This is why it is so important to keep your seed words secret and safe. -![restore-using-json](assets/accounts/polkadot-js-existing-json.png) +![restore-using-json](../assets/accounts/polkadot-js-existing-json.png) Finally, click the "Save" button, then click the "Create and backup account" button. This will download the `.json` file which contains the data to be used in account restoration. You can use @@ -95,12 +96,12 @@ for details. On Parity Signer, click on the top-right user icon on the screen. Proceed to "+ Add Identity". On this screen, tap on the "recover existing identity" button. -![restore-using-parity](assets/parity_Signer_restore1.PNG) +![restore-using-parity](../assets/parity_Signer_restore1.PNG) Enter in the identity name and the mnemonic seed phrase from the account you'd like to restore. Set an identity PIN that will be used to unlock this account when you need to. -![restore-using-parity](assets/parity_Signer_restore2.PNG) +![restore-using-parity](../assets/parity_Signer_restore2.PNG) The identity has now been recovered and you can select a network to create the first account. diff --git a/docs/learn/learn-accounts.md b/docs/learn/learn-accounts.md new file mode 100644 index 000000000000..5e8cdba81bd2 --- /dev/null +++ b/docs/learn/learn-accounts.md @@ -0,0 +1,666 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +slug: ../learn-accounts +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist +on-chain. For a more in-depth explanation of the cryptography behind them, please see +[the cryptography page](learn-cryptography.md). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check +from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix +that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined +[here](). + +It's important to understand that the different formats for different networks are **merely +different representations of the same public key in a private-public keypair** generated by an +address generation tool. This makes the addresses compatible across Substrate-based chains as long +as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find +> them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the +[supported curves and signature schemes](../build/build-protocol-info.md#cryptography). Most wallets take +many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic +phrase in multiple wallets. Wallets that use different steps will arrive at a different set of +addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private +key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to +private key. A typical mnemonic phrase generated by [the Subkey tool](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) is shown below + +```js +"caution juice atom organ advance problem want pledge someone senior holiday very"; +``` + +and its corresponding private/public key pair is shown below. + +``` +Secret seed (Private key): 0x056a6a4e203766ffbea3146967ef25e9daf677b14dc6f6ed8919b1983c9bebbc +Public key (SS58): 5F3sa2TJAWMqDhXG6jhV4N8ko9SxwGy8TpaNS1repo5EYjQX +``` + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the +entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 +rounds of PBKDF2 on the mnemonic. As such, the same mnemonic may generate different private keys on different wallets, due to the difference in the cryptographic algorithms used. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +If you would like to create and manage several accounts on the network using the same seed, you can use derivation paths. We can think of the derived accounts as child accounts of the root account created using the original mnemonic seed phrase. Many Polkadot key generation tools support hard and soft derivation. For instance, if you intend to create an account to be used on the Polkadot chain, you can derive a **hard key** child account using **//** after the mnemonic phrase. + +```js +"caution juice atom organ advance problem want pledge someone senior holiday very//0"; +``` + +and a **soft key** child account using **/** after the mnemonic phrase + +```js +"caution juice atom organ advance problem want pledge someone senior holiday very/0"; +``` + +If you would like to create another account for usage on the Polkadot chain using the same seed, you can change the number at the end of the string above. For example, `/1`, `/2`, and `/3` will all create different derived accounts. + +You can use any letters or numbers in the derivation path as long as they make sense to you; they do not have to follow any specific pattern. You may also combine multiple derivations in your path, as well. For instance, `//bill//account//1` and `//john/polkadot/initial` are both valid. You will need to know both the seed and the derivation path in order to recreate a derived account, so you should either use a well-defined sequence (e.g. //0, //1, //2...) or be sure to write down any derivation paths you use. + +> It is not possible to generate a derived account without also knowing the derivation path. + +### Soft vs. Hard Derivation + +A soft derivation allows someone to potentially "go backwards" to figure out the private key of the initial account IF they know the private key of the derived account. It is also possible to determine that different accounts generated from the same seed are linked to that seed. A hard derivation path does not allow either of these - even if you know a derived private key, it's not feasible to figure out the private key of the root address, and it's impossible to prove that the first account is linked with the second. Both of these derivation methods have their use cases, given the private keys for all the derived accounts are fully secure. Unless you have a specific need for a soft derivation, it is recommended to generate the account using a hard derivation path. + +See the +[Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and +examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer +support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. +This will generate separate seeds for separate paths, which allows separate signing keys with the +same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may +correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses +unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the +[BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at +> the key for an address. Do not use custom derivation paths unless you are comfortable with your +> understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across +multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible +methods for generating keys and signing messages. If you cannot find understandable documentation, +reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with +BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on +[Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() +states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in +Base58-check. If we try to +[decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a +Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is +`000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, +which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of +Polkadot. + +Let's take a look at Substrate addresses. If we decode +`5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get +`2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` +which when +[converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) +is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` +gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first +byte being `02`, just as specified. If we try a Kusama address that starts with a completely +different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the +first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems +counterintuitive that some addresses always have the same prefix and others like Kusama can vary +wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the +[Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used +to generate your account - the accounts are stored only in your browser, so purging the cache will +wipe your accounts as well. You would then have to recreate them using the seed phrase given to you +by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is +using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension +remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget +to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes +beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large +holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so +keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you +can securely stash away the seed phrase for your accounts and remove all traces of the accounts from +your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with +the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is +intended for users comfortable with using the command line and can seem intimidating, but is quite +approachable. Follow the instructions in the +[Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used +properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys +on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible +phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available +[here](../general/ledger.md). + +Alternatively, you might find other wallets on the [Wallet](../build/build-wallets.md) page, but bear in mind +that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the +Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used +for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances +include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` +(`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that +are considered frozen (either `misc_frozen` or `fee_frozen`) and depends on the reason for which the +funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" +amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees +than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The **total** balance of the account is considered to be the sum of `free` and `reserved` funds in +the account. Reserved funds are held due to on-chain requirements and can usually be freed by making +some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity +is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The +account does not exist yet on-chain. For that, it needs the existential deposit: 0.0000333333 KSM +(on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account +will be wiped from the blockchain's state to conserve space, along with any funds in that address. +You do not lose access to the reaped address - as long as you have your private key or recovery +phrase, you can still use the address - but it needs a top-up of another existential deposit to be +able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account +before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot +construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on +Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than +making previews a bit faster. If a folder is completely empty save for such a file, you can remove +the folder to clear junk off your hard drive. That does not mean you lose access to this folder +forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. +It just means you want to keep your computer clean until you maybe end up needing this folder again, +and then recreate it. Your address is like this folder - it gets removed from the chain when nothing +is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember +version of an address. Claiming an index requires a deposit which is released when the index is +cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to +address X, that address will automatically be put into slot 3. Henceforth, you can send me money by +just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other +words, the slot frees up again. If someone creates a new account, they may end up using the same +index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a +deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a +`freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> +Extrinsics_ menu: + +![Indices extrinsics](../assets/accounts/index.png) + +To find available indices to claim, +[this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built +into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be +verified by independent registrars to provide trustworthiness. To learn more about how to set or +release an identity, how to define sub-accounts, or how to become a registrar, please read +[this guide](learn-identity.md). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold +storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the +[proxies](learn-proxies.md) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature +account is composed of one or more addresses and a threshold. The threshold defines how many +signatories (participating addresses) need to agree on the submission of an extrinsic in order for +the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and +Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute +any call without Alice. A threshold is typically a number smaller than the total number of members +but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our +> [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One + signer can be on one computer, another can be on another, or in cold storage. This slows down your + interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively + govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A + multi-sig account could be a council member in Kusama's governance, where a set of community + members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or +altering the threshold is not possible and instead requires the dissolution of the current multi-sig +and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can +always calculate the address of a multi-sig just by knowing the members and the threshold, without +the account existing yet. This means one can send tokens to an address that does not exist yet, and +if the entities designated as the recipients come together in a new multi-sig under a matching +threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for +> generating sort the accounts for you, but if you are implementing your own sorting then be aware +> that the public keys are compared byte-for-byte and sorted ascending before being inserted in the +> payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For +a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` +[here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your +inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the +[Account Generation page](learn-account-generation.md#multi-signature-accounts). This is easier than +generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` +should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the +signatories to approve the call before finally executing it. When you create a new call or approve a +call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet +until the call is executed. The reason for the deposit is to place an economic cost on the storage +space that the multi-sig call takes up on the chain and discourage users from creating dangling +multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts +so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = +56 bytes) and the DepositFactor is equal to `deposit(0, 32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the +[Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.3401 | 200880000000 | 3340100000000 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, +Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw +call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` +while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the +call and execute the transaction, he will not need to place the deposit and Alice will receive her +deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](../maintain/maintain-networks.md#westend-test-network) testnet +and [Polkadot.JS Apps](learn-balance-transfers.md#polkadot-js-apps) to create a 2-of-3 multisig +address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few +> notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that + initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](../assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact +book** under "Accounts > Address book". + +![Address book](../assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](../assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](../assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the +toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig +member addresses, with a value '2' for the threshold. + +![New multisig](../assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](../assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account +to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the +destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](../assets/accounts/multisig-6.png) ![7](../assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](../assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate +the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. +Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an +address locally) and a transfer amount, and click 'Make Transfer'. + +![10](../assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', +and sign the transaction. + +![11](../assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you +click the dropdown under Alice's balance, you will see that a value equivalent to the multisig +deposit has been 'reserved', rendering that value untransferable until the multisig transaction +completes. + +![12](../assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following +from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and + a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his +> computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a +> threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, +and that a pending transaction is displayed, too. + +![13](../assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by +providing the same destination address and transfer amount (together, transaction parameters), +signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of +the transaction and the hash. These transaction parameters will allow Bob to produce and sign the +same transaction (the same hash) that Alice signed earlier. + +![14](../assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. +Note that 'Multisig message with call (for final approval)' is automatically enabled; this means +that, since the transaction will reached the signature threshold, it will execute the actual +transaction on chain after adding the second signature. + +![15](../assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has +released the multisig transaction deposit. + +![16](../assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different +networks. + +(placeholder for address changer) + +
+ + + +
+ +Alternatively, use this [handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or +this [simple address convertor](https://polkadot-address-convertor.netlify.app/). + +### How to Verify a Public Key's Associated Address + +You can verify your public key's associated address through a series of inspection steps, where the +key is a base-16 (hexadecimal) address. + +#### Using Subkey to Retrieve Public Key from SS58 Address + +This is to showcase that the **SS58 address is based on the public key (aka "Account ID")** + +The Subkey Tool's +[Inspecting Keys](https://substrate.dev/docs/en/knowledgebase/integrate/subkey#inspecting-keys) +section explains how to use the `inspect` command to recalculate your key pair's public key and +address. + +Start by inspecting your account's Polkadot address by running the inspect command against your +account's address: + +```bash +$ subkey inspect 1a1LcBX6hGPKg5aQ6DXZpAHCCzWjckhea4sz3P1PvL3oc4F + +Public Key URI `1a1LcBX6hGPKg5aQ6DXZpAHCCzWjckhea4sz3P1PvL3oc4F` is account: + Network ID/version: polkadot + Public key (hex): 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce + Account ID: 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce + SS58 Address: 1a1LcBX6hGPKg5aQ6DXZpAHCCzWjckhea4sz3P1PvL3oc4F +``` + +Take note of the hexadecimal string for "Public key (hex)". This is your account's public key. + +Running the `inspect` command on your public key, the default SS58 address that is returned the +associated Substrate address. + +```bash +$ subkey inspect 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce + +Secret Key URI `0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce` is account: + Secret seed: 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce + Public key (hex): 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c + Account ID: 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c + SS58 Address: 5E6kwKEhrpVMnZvkBRFCzCcRnMXcft4HSaogYQtgtaw6QJ5s +``` + +Using the `--network` flag, you can define the network that you would like to inspect, where the +SS58 address will be based on that network. Now, running the `inspect` command with +`--network polkadot` return your original Polkadot address, thus verifying the public key. + +```bash +subkey inspect 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce --network polkadot + +Secret Key URI `0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce` is account: + Secret seed: 0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce + Public key (hex): 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c + Account ID: 0x5a095388156e3a68d4fb7cbaef981478e1a0be6d4998f00dffc3e4e9c60c104c + SS58 Address: 13345eVmibkqE6wG94JD8MSadyXGNBcRX5YAhht3Sfxcaw9U +``` + +You will notice that the Subkey Tool recognizes the correct network of the address and returns the +associated public key. The public key is returned as a hexadecimal string (i.e. prefixed with +**"0x"**). **For both SS58 addresses, the same public key is returned.** + +#### Address Verification + +##### Consider the following example: + +![17](../assets/accounts/pubkey-1.png) + +If you are comfortable enough to distinguish between each account parameter, you can prefix the +public key string with **"0x"** on your own: + +From: +`Pay DOTs to the Polkadot account:192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce`, +we prefix the address by "0x" -> +`0x192c3c7e5789b461fbf1c7f614ba5eed0b22efc507cda60a5e7fda8e046bcdce`. + +Using the [handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform), you can verify +both address associations to your public key. Copy your public key into the "Input Account or Public +Key" textbox and click "Transform" at the bottom. On the right-hand side, the addresses for Polkadot +and Substrate that are returned based on your public key should match with the ones you inspected. + +![18](../assets/accounts/pubkey-2.png) + +> Note: You may have to scroll down to the bottom of the menu to find the Substrate address based on +> the menu listings. You will notice that there are many networks that also use the same Substrate +> address. + +You can verify your own public key verification by recalling that Polkadot addresses start with a +'1', whereas Substrate addresses generally start with a '5' (Kusama addresses start with a capital +letter). See [Addresses](learn-accounts.md#address-format) for more details. + +Furthermore, the [Utility Scripts](https://github.com/w3f/utility-scripts) can be referenced for how +the verification is performed: +[pubkeyToAddress.js](https://github.com/w3f/utility-scripts/blob/master/src/misc/pubkeyToAddress.js) +demonstrates how a Polkadot, Substrate, or Kusama address is interpreted by a single public key. + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An + explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill + Laboon and Chinmay Patel of BlockX Labs. diff --git a/docs/learn/learn-architecture.md b/docs/learn/learn-architecture.md new file mode 100644 index 000000000000..46253901f60e --- /dev/null +++ b/docs/learn/learn-architecture.md @@ -0,0 +1,96 @@ +--- +id: learn-architecture +title: Architecture +sidebar_label: Architecture +slug: ../learn-architecture +--- + +Polkadot is a heterogeneous multichain with shared security and interoperability. + +# Components + +## Relay Chain + +The Relay Chain is the central chain of Polkadot. All validators of Polkadot are staked on the Relay +Chain in DOT and validate for the Relay Chain. The Relay Chain is composed of a relatively small +number of transaction types that include ways to interact with the governance mechanism, parachain +auctions, and participating in NPoS. The Relay Chain has deliberately minimal functionality - for +instance, smart contracts are not supported. The main responsibility is to coordinate the system as +a whole, including parachains. Other specific work is delegated to the parachains, which have +different implementations and features. + +## [Parachain](learn-parachains.md) and [Parathread](learn-parathreads.md) Slots + +Polkadot can support a number of execution slots. These slots are like cores on a computer's +processor (a modern laptop's processor may have eight cores, for example). Each one of these cores +can run one process at a time. Polkadot allows these slots using two subscription models: parachains +and parathreads. Parachains have a dedicated slot (core) for their chain and are like a process that +runs constantly. Parathreads share slots amongst a group, and are thus more like processes that need +to be woken up and run less frequently. + +Most of the computation that happens across the Polkadot network as a whole will be delegated to +specific parachain or parathread implementations that handle various use cases. Polkadot places no +constraints over what parachains can do besides that they must be able to generate a proof that can +be validated by the validators assigned to the parachain. This proof verifies the state transition +of the parachain. Some parachains may be specific to a particular application, others may focus on +specific features like smart contracts, privacy, or scalability — still, others might be +experimental architectures that are not necessarily blockchain in nature. + +Polkadot provides many ways to secure a slot for a parachain slot for a particular length of time. +Parathreads are part of a pool that shares slots and must-win auctions for individual blocks. +Parathreads and parachains have the same API; their difference is economic. Parachains will have to +reserve DOT for the duration of their slot lease; parathreads will pay on a per-block basis. +Parathreads can become parachains, and vice-versa. + +### [Shared Security](learn-security.md) + +Parachains connected to the Polkadot Relay Chain all share in the security of the Relay Chain. +Polkadot has a shared state between the Relay Chain and all of the connected parachains. If the +Relay Chain must revert for any reason, then all of the parachains would also revert. This is to +ensure that the validity of the entire system can persist and no individual part is corruptible. + +The shared state makes it so that the trust assumptions when using Polkadot parachains are only +those of the Relay Chain validator set and no other. Since the validator set on the Relay Chain is +expected to be secure with a large amount of stake put up to back it, parachains should benefit from +this security. + +## [Bridges](learn-bridges.md) + +A blockchain [bridge](../general/glossary.md##bridge) is a connection that allows for arbitrary data to +transfer from one network to another. These chains are interoperable through the bridge but can +exist as standalone chains with different protocols, rules, and governance models. In Polkadot, +bridges connect to the relay chain and are secured through the Polkadot consensus mechanism, +maintained by [collators](##collators). + +Polkadot uses bridges to bridge the future of Web 3.0, as bridges are fundamental to Polkadot's +interoperable architecture by acting as a [secure and robust] communication channel for chains in +isolation. + +# Main Actors + +## Validators + +[Validators](../general/glossary.md##validator), if elected to the validator set, produce blocks on the Relay +Chain. They also accept proofs of valid state transition from collators. In return, they will +receive staking rewards. + +## Nominators + +[Nominators](../general/glossary.md##nominator) bond their stake to particular validators in order to help them +get into the active validator set and thus produce blocks for the chain. In return, nominators are +generally rewarded with a portion of the staking rewards from that validator. + +## Collators + +[Collators](../general/glossary.md##collator) are full nodes on both a parachain and the Relay Chain. They +collect parachain transactions and produce state transition proofs for the validators on the Relay +Chain. They can also send and receive messages from other parachains using XCMP. + +--- + +## Whiteboard Series + +For a video overview of the architecture of Polkadot watch the video below for the whiteboard +interview with W3F researcher Alistair Stewart: + + diff --git a/docs/learn-auction.md b/docs/learn/learn-auction.md similarity index 98% rename from docs/learn-auction.md rename to docs/learn/learn-auction.md index a31aa2f0ee8c..9846312cc0e0 100644 --- a/docs/learn-auction.md +++ b/docs/learn/learn-auction.md @@ -2,6 +2,7 @@ id: learn-auction title: Parachain Slots Auction sidebar_label: Parachain Slots Auction +slug: ../learn-auction --- For a [parachain](learn-parachains.md) to be added to Polkadot it must inhabit one of the available @@ -61,7 +62,7 @@ to _grief_ honest bidders by sniping auctions. For this reason, [Vickrey auctions](https://en.wikipedia.org/wiki/Vickrey_auction), a variant of second price auction in which bids are hidden and only revealed in a later phase, have emerged as a well-regarded mechanic. For example, it is implemented as the mechanism to auction human readable -names on the [ENS](ens.md). The Candle auction is another solution that does not need the two-step +names on the [ENS](../general/ens.md). The Candle auction is another solution that does not need the two-step commit and reveal schemes (a main component of Vickrey auctions), and for this reason allows smart contracts to participate. diff --git a/docs/learn/learn-availability.md b/docs/learn/learn-availability.md new file mode 100644 index 000000000000..0f685db11588 --- /dev/null +++ b/docs/learn/learn-availability.md @@ -0,0 +1,96 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +slug: ../learn-availability +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be +efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are five phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the +validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and +> must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that +parachain's registered code. If the verification succeeds, then the validators will pass the +candidate block to the other validators in the gossip network. However, if the verification fails, +the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is +a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will +eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure-coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable +length. It is enough information for anyone that obtains the full PoV block to verify the state +transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the +[erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report +that they possess their piece of the code word. Once this threshold of validators has been reached, +the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be +recovered from a subset of the code and in absence of some portion of the code. A code is the +original message padded with some extra data that enables the reconstruction of the code in the case +of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon][reed solomon] +codes, which already enjoys a battle-tested application in technology outside the blockchain +industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct +any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without +requiring all validators to keep tabs on all the parachains. Instead, validators share smaller +pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the +validators can provide their pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full +parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen: Deprecated + +The idea of Fishermen is that they are full nodes of parachains, like collators, but perform a different role in relation to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. + +**Fishermen are not available on Kusama or Polkadot and are not planned for formal implementation, depsite previous proposals in the [AnV protocol](https://w3f-research.readthedocs.io/en/latest/polkadot/Availability_and_Validity.html).** + +## Further Resources + +- [Path of a Parachain Block][life of] - Article by Parity analyst Joe Petrowski expounding on the + validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity][anv paper] - Paper by the W3F Research Team that specifies the + availability and validity protocol in detail. + +[reed solomon]: https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction +[pruning]: https://example.org +[life of]: https://polkadot.network/the-path-of-a-parachain-block/ +[anv paper]: https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV diff --git a/docs/learn/learn-balance-transfers.md b/docs/learn/learn-balance-transfers.md new file mode 100644 index 000000000000..cb00053ca42a --- /dev/null +++ b/docs/learn/learn-balance-transfers.md @@ -0,0 +1,141 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +slug: ../learn-balance-transfers +--- + +Balance transfers are used to send balance from one account to another account. To start +transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've +already [created an account](learn-account-generation.md) and have some funds that are ready to be +transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network, but this is the same process for +> Kusama. If you would like to switch to a different network, you can change it by clicking the top +> left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](../assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the **minimum amount of funds you must keep in the account +for it to remain active.** See the [existential deposit][] section for more information. + +![transfer](../assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer +is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](../general/glossary.md#extrinsic) level, there are two main ways to transfer funds from one +account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to +send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount +that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from +cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do +not want to keep this account alive (for example, because you are moving all of your funds to a +different address). In this case, click on the "keep-alive" toggle at the bottom of the modal +window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` +will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As +a common use case for using normal transfers is to entirely clear out the account, a second toggle +will appear if you have the keep-alive check turned off that will send all the tokens in the +account, minus a transaction fee, to the destination address. + +Attempting to send less than the existential deposit to an account with 0 DOT will always fail, no +matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an +account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential +deposit of 1 DOT and the account cannot be initialized with such a low balance. + +> NOTE: Even if the transfer fails due to a keep-alive check, the transaction fee will be deducted +> from the sending account if you attempt to transfer. + +### Existing Reference Error + + + + + +If you are trying to reap an account and you recieve an error similar to "There is an existing +reference count on the sender account. As such the account cannot be reaped from the state", then +you have existing references to this account that must first be removed before it can be reaped. +References may still exist from: + +- Bonded tokens (most likely) +- Unpurged session keys (if you were prevously a validator) +- Token locks +- Existing recovery info +- Existing assets + +#### Bonded Tokens + +If you have tokens that are bonded, you will need to unbond them before you can reap your account. +Follow the instructions at [Unbonding and Rebonding](../maintain/maintain-guides-how-to-unbond.md) to check if +you have bonded tokens, stop nominating (if necessary) and unbond your tokens. + +#### Purging Session Keys + +If you used this account to set up a validator and you did not purge your keys before unbonding your +tokens, you need to purge your keys. You can do this by seeing the +[How to Stop Validating](../maintain/maintain-guides-how-to-stop-validating.md) page. This can also be checked +by checking `session.nextKeys` in the chain state for an existing key. + +#### Checking for Locks + +You can check for locks by querying `system.account(AccountId)` under `Developer > Chain state`. +Select your account, then click the "+" button next to the dropdowns, and check the relative `data` +JSON object. If you see a non-zero value for anything other than `free`, you have locks on your +account that need to get resolved. + +You can also check for locks by navigating to `Accounts > Accounts` in +[PolkadotJS Apps](https://polkadot.js.org/apps/#/). Then, click the dropdown arrow of the relevant +account under the 'balances' column. If it shows that some tokens are in a 'locked' state, you can +see why by hovering over the information icon next to it. + +#### Existing Recovery Info + +Currently, {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} does not use the +[Recovery Pallet](https://substrate.dev/docs/en/knowledgebase/runtime/frame#recovery), so this is +probably not the reason for your tokens having existing references. + +{{ kusama: On Kusama, you can check if recovery has been set up by checking the `recovery.recoverable(AccountId)` +chain state. This can be found under `Developer > Chain state` in [PolkadotJS Apps][polkadot-js apps]. :kusama }} + +#### Existing {{ polkadot: Non-DOT :polkadot }} {{ kusama: Non-KSM :kusama }} Assets + +Currently, {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} does not use the +[Assets Pallet](https://substrate.dev/docs/en/knowledgebase/runtime/frame#assets), so this is +probably not the reason for your tokens having existing references. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located +on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account +you will like to send funds from. + +![transfer](../assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly +and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the +top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: ../build/build-protocol-info.md#existential-deposit diff --git a/docs/learn/learn-bridges.md b/docs/learn/learn-bridges.md new file mode 100644 index 000000000000..9af8828a3059 --- /dev/null +++ b/docs/learn/learn-bridges.md @@ -0,0 +1,144 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +slug: ../learn-bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges +are ways for two economically sovereign and technologically diverse chains to communicate with each +other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more +decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however +there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has +not been too many that have been used heavily in production. For this reason, you can consider this +page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains +> such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native +> interoperability technology that allows parachains to trustlessly communicate, please see the +> dedicated [crosschain][] page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the +following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (e.g. Kusama `\<\>` Polkadot + bridge, since both networks' parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the + non-Substrate chain to bridge (e.g. Ethereum mainnet will have a bridge smart contract that + initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (e.g. Bitcoin), you + should use [XClaim][xclaim] or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a +Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level +parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama `\<\>` Polkadot +bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot +(non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is +possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, +etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge][] and the +efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a +combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers +of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum +chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance +denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract +on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check +> out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM][xclaim]) can be used to bridge, but should only be used when +other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by +a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since +it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts \<\> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post][eth bridging blog] from late 2019, there are three +ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM \<\> Substrate \<\> Polkadot) + +The Interlay team has written a [specification][interlay] on a Bitcoin bridge that is based on the +[XCLAIM][] design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It +allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to +burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different +components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +There is now a +[reference implementation and testnet available](https://medium.com/interlay/polkabtc-beta-testnet-launch-2cc9ea7431b7). + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be +funding available from the W3F [grants program][]. Please first check that the chain you are +intending to bridge between hasn't already been built or is in the process of being built by another +team. More popular chains with clear use cases will be given priority, and novel bridge designs are +welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge + were awarded a grant in W3F Grants [Wave 5][] to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin \<\> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge][bifrost] - The Bifrost team was awarded a grant in W3F Grants [Wave 5][] to build a + bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded + a grant in [Wave 5][] to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge][interlay] - The Interlay team was awarded a grant in W3F grants [Wave 5][] + to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xpallets/gateway/bitcoin) - + ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA + Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to + Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM][] - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges + using cryptocurrency-backed assets. + +[crosschain]: learn-crosschain.md +[parity bridge]: https://github.com/paritytech/parity-bridge +[interlay]: https://interlay.gitlab.io/polkabtc-spec/ +[xclaim]: https://eprint.iacr.org/2018/643.pdf +[bifrost]: https://github.com/bifrost-codes/bifrost +[wave 5]: https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096 +[eth bridging blog]: https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13 +[grants program]: https://github.com/w3f/General-Grants-Program diff --git a/docs/learn-collator.md b/docs/learn/learn-collator.md similarity index 92% rename from docs/learn-collator.md rename to docs/learn/learn-collator.md index 9623ca7152ef..0083b11930a1 100644 --- a/docs/learn-collator.md +++ b/docs/learn/learn-collator.md @@ -2,10 +2,9 @@ id: learn-collator title: Collator sidebar_label: Collator +slug: ../learn-collator --- - - Collators maintain parachains by collecting parachain transactions from users and producing state transition proofs for Relay Chain validators. In other words, collators maintain parachains by aggregating parachain transactions into parachain block candidates and producing state transition @@ -36,13 +35,13 @@ them to send messages from parachain A to parachain B. ### Collators in the Wild -Collators are being used on the [Rococo](build-parachains-rococo.md) testnet, and you can learn more +Collators are being used on the [Rococo](../build/build-parachains-rococo.md) testnet, and you can learn more about how they are used with Cumulus via the [Cumulus](https://github.com/paritytech/cumulus/) repository. ### Guides and Tools - [Workshop covering Cumulus and Collators](https://substrate.dev/cumulus-workshop/) -- [Rococo tesnet guide](build-parachains-rococo.md) +- [Rococo tesnet guide](../build/build-parachains-rococo.md) - [polkadot-launch](https://github.com/shawntabrizi/polkadot-launch) - a tool to quickly spin up a local Polkadot testnet based on some parameters like number of parachains, collator setup, etc. diff --git a/docs/learn-common-good-chains.md b/docs/learn/learn-common-good-chains.md similarity index 99% rename from docs/learn-common-good-chains.md rename to docs/learn/learn-common-good-chains.md index 0f9fe5df6ebd..b24431e481c3 100644 --- a/docs/learn-common-good-chains.md +++ b/docs/learn/learn-common-good-chains.md @@ -3,6 +3,7 @@ id: learn-common-goods title: Common Good Parachains sidebar_label: Common Good Parachains description: Common Good Parachains +slug: ../learn-common-goods --- ## Overview diff --git a/docs/learn-comparison-ethereum-2.md b/docs/learn/learn-comparison-ethereum-2.md similarity index 99% rename from docs/learn-comparison-ethereum-2.md rename to docs/learn/learn-comparison-ethereum-2.md index b0182a309524..a94bd43987e5 100644 --- a/docs/learn-comparison-ethereum-2.md +++ b/docs/learn/learn-comparison-ethereum-2.md @@ -2,6 +2,7 @@ id: learn-comparisons-ethereum-2 title: Polkadot and Ethereum 2.0 sidebar_label: Ethereum 2.0 +slug: ../learn-comparisons-ethereum-2 --- Polkadot and Ethereum 2.0 are both sharded blockchain protocols. As such, they provide scalability diff --git a/docs/learn-comparisons-cosmos.md b/docs/learn/learn-comparisons-cosmos.md similarity index 99% rename from docs/learn-comparisons-cosmos.md rename to docs/learn/learn-comparisons-cosmos.md index a0363d96f688..bdfcfcbb38b2 100644 --- a/docs/learn-comparisons-cosmos.md +++ b/docs/learn/learn-comparisons-cosmos.md @@ -2,6 +2,7 @@ id: learn-comparisons-cosmos title: Polkadot and Cosmos sidebar_label: Cosmos +slug: ../learn-comparisons-cosmos --- Polkadot and Cosmos are both protocols that provide an interface for different state machines to diff --git a/docs/learn-comparisons.md b/docs/learn/learn-comparisons.md similarity index 99% rename from docs/learn-comparisons.md rename to docs/learn/learn-comparisons.md index 920d933dbbb1..150bac1dd30a 100644 --- a/docs/learn-comparisons.md +++ b/docs/learn/learn-comparisons.md @@ -3,6 +3,7 @@ id: learn-comparisons title: Polkadot Comparisons sidebar_label: Other comparisons description: How does Polkadot compare to Ethereum 2, Cosmos, and other chains? +slug: ../learn-comparisons --- Polkadot is a blockchain technology but makes some innovations that sets it apart from other popular diff --git a/docs/learn/learn-consensus.md b/docs/learn/learn-consensus.md new file mode 100644 index 000000000000..4c8e5e243aae --- /dev/null +++ b/docs/learn/learn-consensus.md @@ -0,0 +1,195 @@ +--- +id: learn-consensus +title: Polkadot Consensus +sidebar_label: Polkadot Consensus +description: An explanation of the consensus model used in Polkadot and Kusama +slug: ../learn-consensus +--- + +## Why do we need consensus? + +Consensus is a method for coming to agreement over a shared state. In order for the state of the +blockchain to continue to build and move forward, all nodes in the network must agree and come to +consensus. It is the way that the nodes in a decentralized network are able to stay synced with each +other. Without consensus for the decentralized network of nodes in a blockchain, there is no way to +ensure that the state one node believes is true will be shared by the other nodes. Consensus aims to +provide the _objective_ view of the state amid participants who each have their own _subjective_ +views of the network. It is the process by which these nodes communicate and come to agreement, and +are able to build new blocks. + +## What are PoW and PoS? + +Proof of Work (PoW) and Proof of Stake (PoS) have been inaccurately used as short hand to refer to +consensus mechanisms of blockchains, but that does not capture the full picture. PoW is the method +for agreeing on a block author and part of the fuller [Nakamoto consensus](#nakamoto-consensus) that +also encompasses a chain selection algorithm (longest chain rule in Bitcoin). Similarly, PoS is a +set of rules for selecting the validator set and does not specify a chain selection rule or how a +chain might reach finality. PoS algorithms have traditionally been paired with an algorithm for +coming to Byzantine agreement between nodes. For example, [Tendermint](learn-comparisons-cosmos.md) +is a practical Byzantine fault tolerant algorithm that uses PoS as its validator set selection +method. + +## Why not Proof of Work? + +Although simple and effective in coming to a decentralized consensus on the next block producer, +proof of work with Nakamoto consensus consumes an incredible amount of energy, has no economic or +provable finality, and has no effective strategy in resisting cartels. + +## Probabilistic vs. provable finality + +A pure Nakamoto consensus blockchain that runs PoW is only able to achieve the notion of +_probabilistic finality_ and reach _eventual consensus_. Probabilistic finality means that under +some assumptions about the network and participants, if we see a few blocks building on a given +block, we can estimate the probability that it is final. Eventual consensus means that at some point +in the future, all nodes will agree on the truthfulness of one set of data. This eventual consensus +may take a long time and will not be able to be determined how long it will take ahead of time. +However, finality gadgets such as GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) +or Ethereum's Casper FFG (the Friendly Finality Gadget) are designed to give stronger and quicker +guarantees on the finality of blocks - specifically, that they can never be reverted after some +process of Byzantine agreements has taken place. The notion of irreversible consensus is known as +_provable finality._ + +In the [GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf), it is phrased +in this way: + +> We say an oracle A in a protocol is _eventually consistent_ if it returns the same value to all +> participants after some unspecified time. + +## What is GRANDPA/BABE? + +### Hybrid Consensus + +There are two protocols we use when we talk about the consensus protocol of Polkadot, GRANDPA and +BABE (Blind Assignment for Blockchain Extension). We talk about both of these because Polkadot uses +what is known as _hybrid consensus_. Hybrid consensus splits up the finality gadget from the block +production mechanism. + +This is a way of getting the benefits of probabilistic finality (the ability to always produce new +blocks) and provable finality (having a universal agreement on the canonical chain with no chance +for reversion) in Polkadot. It also avoids the corresponding drawbacks of each mechanism (the chance +of unknowingly following the wrong fork in probabilistic finality, and a chance for "stalling" - not +being able to produce new blocks - in provable finality). By combining these two mechanisms, +Polkadot allows for blocks to be rapidly produced, and the slower finality mechanism to run in a +separate process to finalize blocks without risking slower transaction processing or stalling. + +Hybrid consensus has been proposed in the past. Notably, it was proposed (now defunct) as a step in +Ethereum's transition to proof of stake in [EIP 1011](http://eips.ethereum.org/EIPS/eip-1011), which +specified [Casper FFG](#casper-ffg). + +### BABE + +BABE (Blind Assignment for Blockchain Extension) is the block production mechanism that runs between +the validator nodes and determines the authors of new blocks. BABE is comparable as an algorithm to +Ouroboros Praos, with some key differences in chain selection rule and slot time adjustments. BABE +assigns block production slots to validators according to stake and using the Polkadot +[randomness cycle](learn-randomness.md). + +Validators in Polkadot will participate in a lottery in every slot that will tell them whether or +not they are the block producer candidate for that slot. Slots are discrete units of time, nominally +6 seconds in length. Because of this randomness mechanism, multiple validators could be candidates +for the same slot. Other times, a slot could be empty, resulting in inconsistent block time. + +#### Multiple Validators per Slot + +When multiple validators are block producer candidates in a given slot, all will produce a block and +broadcast it to the network. At that point, it's a race. The validator whose block reaches most of +the network first wins. Depending on network topology and latency, both chains will continue to +build in some capacity, until finalization kicks in and amputates a fork. See Fork Choice below for +how that works. + +#### No Validators in Slot + +When no validators have rolled low enough in the randomness lottery to qualify for block production, +a slot can remain seemingly blockless. We avoid this by running a secondary, round-robin style +validator selection algorithm in the background. The validators selected to produce blocks through +this algorithm always produce blocks, but these _secondary_ blocks are ignored if the same slot also +produces a primary block from a [VRF-selected](learn-randomness.md) validator. Thus, a slot can have +either a _primary_ or a _secondary_ block, and no slots are ever skipped. + +For more details on BABE, please see the +[BABE paper](https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html). + +### GRANDPA: Finality gadget + +GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is the finality gadget that is +implemented for the Polkadot Relay Chain. + +It works in a partially synchronous network model as long as 2/3 of nodes are honest and can cope +with 1/5 Byzantine nodes in an asynchronous setting. + +A notable distinction is that GRANDPA reaches agreements on chains rather than blocks, greatly +speeding up the finalization process, even after long-term network partitioning or other networking +failures. + +In other words, as soon as more than 2/3 of validators attest to a chain containing a certain block, +all blocks leading up to that one are finalized at once. + +#### Protocol + +Please refer to [the GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) +for a full description of the protocol. + +#### Implementation + +The +[Substrate implementation of GRANDPA](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs) +is part of Substrate Frame. + +### Fork Choice + +Bringing BABE and GRANDPA together, the fork choice of Polkadot becomes clear. BABE must always +build on the chain that has been finalized by GRANDPA. When there are forks after the finalized +head, BABE provides probabilistic finality by building on the chain with the most primary blocks. + +![Best chain choice](../assets/best_chain.png) + +In the above image, the black blocks are finalized, and the yellow blocks are not. Blocks marked +with a "1" are primary blocks; those marked with a "2" are secondary blocks. Even though the topmost +chain is the longest chain on the latest finalized block, it does not qualify because it has fewer +primaries at the time of evaluation than the one below it. + +## Comparisons + +### Nakamoto consensus + +Nakamoto consensus consists of the longest chain rule using proof of work as its sybil resistance +mechanism and leader election. + +Nakamoto consensus only gives us probabilistic finality. Probabilistic finality states that a block +in the past is only as safe as the number of confirmations it has, or the number of blocks that have +been built on top of it. As more blocks are built on top of a specific block in a Proof of Work +chain, more computational work has been expended behind this particular chain. However, it does not +guarantee that the chain containing the block will always remain the agreed-upon chain, since an +actor with unlimited resources could potentially build a competing chain and expend enough +computational resources to create a chain that did not contain a specific block. In such a +situation, the longest chain rule employed in Bitcoin and other proof of work chains would move to +this new chain as the canonical one. + +### PBFT / Tendermint + +Please see the [relevant section](learn-comparisons-cosmos.md#consensus) in the Cosmos comparison +article. + +### Casper FFG + +The two main differences between GRANDPA and Casper FFG are: + +- in GRANDPA, different voters can cast votes simultaneously for blocks at different heights +- GRANDPA only depends on finalized blocks to affect the fork-choice rule of the underlying block + production mechanism + +## Resources + +- [BABE paper](https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html) - The + academic description of the BABE protocol. +- [GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) - The academic + description of the GRANDPA finality gadget. Contains formal proofs of the algorithm. +- [Rust implementation](https://github.com/paritytech/finality-grandpa) - The reference + implementation and the accompanying + [Substrate pallet](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs). +- [Block Production and Finalization in Polkadot](https://www.crowdcast.io/e/polkadot-block-production) - + An explanation of how BABE and GRANDPA work together to produce and finalize blocks on Kusama, + with Bill Laboon. +- [Block Production and Finalization in Polkadot: Understanding the BABE and GRANDPA Protocols](https://www.youtube.com/watch?v=1CuTSluL7v4&t=4s) - + An academic talk by Bill Laboon, given at MIT Cryptoeconomic Systems 2020, describing Polkadot's + hybrid consensus model in-depth. diff --git a/docs/learn/learn-crosschain.md b/docs/learn/learn-crosschain.md new file mode 100644 index 000000000000..24c6dbd45b12 --- /dev/null +++ b/docs/learn/learn-crosschain.md @@ -0,0 +1,120 @@ +--- +id: learn-crosschain +title: Cross-chain Message Passing (XCMP) +sidebar_label: Cross-chain Message Passing (XCMP) +slug: ../learn-crosschain +--- + +Cross-chain transactions are resolved using a simple queuing mechanism based around a Merkle tree to +ensure fidelity. It is the task of the Relay Chain validators to move transactions on the output +queue of one parachain into the input queue of the destination parachain. However, only the +associated metadata is stored as a hash in the Relay Chain storage. + +The input and output queue are sometimes referred to in the codebase and associated documentation as +`ingress` and `egress` messages respectively. + +## Overview of XCMP + +XCMP is currently under development and the details are subject to change. However, the overall +architecture and design decisions are as follows: + +- Cross-chain messages will _not_ go on to the Relay Chain. +- Cross-chain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching + parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other + parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest + ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the + processing of the expected ingress messages to that parachain. + +XCMP queues must be initiated by first opening a channel between two parachains. The channel is +identified by both the sender and recipient parachains, meaning that it's a one-way channel. A pair +of parachains can have at most two channels between them, one for sending messages to the other +chain and another for receiving messages. The channel will require a deposit in DOT to be opened, +which will get returned when the channel is closed. + +## XCMP-Lite (HRMP) + +While XCMP is still being implemented, a stop-gap protocol (see definition below) known as +**Horizontal Relay-routed Message Passing (HRMP)** exists in its place. HRMP has the same interface +and functionality as XCMP but is much more demanding on resources since it stores all messages in +the Relay Chain storage. When XCMP has been implemented, HRMP is planned to be deprecated and phased +out in favor of it. + +> Note: A stop-gap protocol is a temporary substitute for the functionality that is not fully +> complete. While XCMP proper is still in development, HRMP is a working replacement. + +## Vertical Message Passing + +There are two kinds of Vertical Message Passing, Upward Message Passing (UMP) and Downward Message +Passing (DMP). UMP is used when a message originates on a parachain or a parathread to go from that +parachain up to the Relay Chain. DMP is used to go the other way around, when a message originates +from the Relay Chain and is destined for a parachain. Messages that are passed via DMP may originate +from a parachain. In which case, first UMP is used to communicate the message to the Relay Chain and +DMP is used to move it down to another parachain. + +## XCMP Message Format + +For a description of the XCMP message format please see the [xcm-format][] repository on GitHub. + +## How To Make Cross Chain Transfers + +You can try out cross-chain transfers on the the [Rococo](../build/build-parachains-rococo.md) testnet. A +tutorial on downward, upward, and lateral transfers can be found +[here](../build/build-parachains-rococo.md#how-to-make-cross-chain-transfers). + +## High-Level XCMP + +A smart contract that exists on parachain A will route a message to parachain B in which another +smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A, which initiates a new cross-chain message for +the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new cross-chain message into its outbound messages +queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages +(filtering by the `destination` field). When the collator of parachain B makes its next ping, it +will see this new message on parachain A and add it into its own inbound queue for processing into +the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for +parachain B will do the same. This is so that they will be able to verify the message transmission +happened. + +When the collator of parachain B is building the next block in its chain, it will process the new +message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset +transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was +processed. If the message was processed and all other aspects of the block are valid, the validator +will include this block for parachain B into the Relay Chain. + +Check out our animated video below that explores how XCMP works. + + + + + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/XCMP.html) - Full technical + description of cross-chain communication on the Web3 Foundation research wiki. +- [Messaging Overview](https://w3f.github.io/parachain-implementers-guide/messaging.html) - An + overview of the messaging schemes from the Parachain Implementor's guide. +- [XCM Format](https://github.com/paritytech/xcm-format) - Description of the high-level XCM format + sent via XCMP. + +[xcm-format]: https://github.com/paritytech/xcm-format diff --git a/docs/learn-crowdloans.md b/docs/learn/learn-crowdloans.md similarity index 94% rename from docs/learn-crowdloans.md rename to docs/learn/learn-crowdloans.md index 1a4b4213f684..25204c513e55 100644 --- a/docs/learn-crowdloans.md +++ b/docs/learn/learn-crowdloans.md @@ -2,14 +2,15 @@ id: learn-crowdloans title: Parachain Crowdloans sidebar_label: Parachain Crowdloans +slug: ../learn-crowdloans --- {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} allows parachains to source tokens for their parachain bids in a decentralized crowdloan. > Note: For information on how to participate in the crowdloan and parachain auction testing on -> Rococo, please see the {{ polkadot: [Rococo page](build-parachains-rococo.md) :polkadot }} > -> {{ kusama: [Rococo page](mirror-build-parachains-rococo.md) :kusama }}. +> Rococo, please see the {{ polkadot: [Rococo page](../build/build-parachains-rococo.md) :polkadot }} > +> {{ kusama: [Rococo page](../build/mirror-build-parachains-rococo.md) :kusama }}. ## Starting a crowdloan campaign @@ -79,7 +80,7 @@ PolkadotJS apps also offers a breakdown of ongoing crowdloans on the Here is an exmaple of the crowdloans in play during the very first Kusama auction. -![crowdloan dashboard](assets/kusama-crowdloans.png) +![crowdloan dashboard](../assets/kusama-crowdloans.png) Furthermore, check out this video on [How to Participate in Crowdloans](https://www.youtube.com/watch?v=YrTxDufrcQM) for steps on how to diff --git a/docs/learn/learn-cryptography.md b/docs/learn/learn-cryptography.md new file mode 100644 index 000000000000..2a8e740477be --- /dev/null +++ b/docs/learn/learn-cryptography.md @@ -0,0 +1,37 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +slug: ../learn-cryptography +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some +knowledge about cryptographic primitives that are generally used in blockchains such as hashes, +elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used in Polkadot please see the more advanced +[research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is +[Blake2b](). Blake2 is considered to be +a very fast cryptographic hash function that is also used in the cryptocurrency +[Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as +its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses +Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits +over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set +and security assumptions. Additionally, it allows for native multisignature through +[signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the +[Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the +[Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 +curves like Curve25519. diff --git a/docs/learn/learn-governance.md b/docs/learn/learn-governance.md new file mode 100644 index 000000000000..a875f294291c --- /dev/null +++ b/docs/learn/learn-governance.md @@ -0,0 +1,445 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +slug: ../learn-governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully overtime at +the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of +the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition +function stored on-chain and defined in a platform-neutral intermediate language (i.e. +[WebAssembly](learn-wasm.md)) and several on-chain voting mechanisms such as referenda with adaptive +super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon +by stake-weighted referenda. + +## Mechanism + +To make any changes to the network, the idea is to compose active token holders and the council +together to administrate a network upgrade decision. No matter whether the proposal is proposed by +the public (token holders) or the council, it finally will have to go through a referendum to let +all holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific +_proposal_ associated with it that takes the form of a privileged function call in the runtime (that +includes the most powerful call: `set_code`, which can switch out the entire code of the runtime, +achieving what would otherwise require a "hard fork"). + +Referenda are discrete events, have a fixed period where voting happens, and then are tallied and +the function call is made if the vote is approved. Referenda are always binary; your only options in +voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period between the +referendum ending and, assuming the proposal was approved, the changes being enacted. For the first +two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, +it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These +will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period +(number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens +to support it - this action is called _seconding_. The proposal with the highest amount of bonded +support will be selected to be a referendum in the next voting cycle. + +Note that this may be different from the absolute number of seconds; for instance, three accounts +bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will +be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a +referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of +stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", +below). + +Majority Council - When agreement from only a simple majority of council members occurs, the +referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency +referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming +there is at least one proposal in one of the queues. There is a queue for Council-approved proposals +and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the +top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose +turn it is to create a referendum that has no proposals (is empty), and proposals are waiting in the +other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same period, excluding emergency referenda. An +emergency referendum occurring at the same time as a regular referendum (either public- or +council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond +the end of the referendum. This is in order to ensure that some minimal economic buy-in to the +result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal +vote, given your stake. At the same time, holding only a small amount of tokens does not mean that +the holder cannot influence the referendum result, thanks to time-locking. You can read more about +this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our +> [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of +them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are +three different scenarios. We can use the following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the +voting result. For example, let's use the public proposal as an example, so the +`Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority +required increases with lower turnout. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low +turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low +turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the +proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the +[democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1_500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate +the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout +is low, therefore, based on the above result, the referendum will be rejected. In addition, only the +winning voter's tokens are locked. If the voters on the losing side of the referendum believe that +the outcome will have negative effects, their tokens are transferrable so they will not be locked +into the decision. Moreover, winning proposals are autonomously enacted only after some enactment +period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their +voting power by declaring how long they are willing to lock up their tokens, hence, the number of +votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods +double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in +total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are +allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from +transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long +the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the +council can use to alter the effective super-majority required to make it easier or more difficult +for a proposal to pass in the case that there is no clear majority of voting power backing it or +against it. + +![](../assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has a 25% turnout, the tally of "aye" votes has to reach 66% +for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has a 75% turnout, the tally of "aye" votes has to reach 54%, which means that +the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a +vote using "Negative Turnout Bias". In this case, it is easier to pass this proposal with low +turnout and requires a super-majority to reject. As more token holders participate in voting, the +bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has +to reach 34% for it to pass. + +In short, when the turnout rate is low, a super-majority is required to reject the proposal, which +means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it +becomes a simple majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority +against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an +on-chain entity comprising several actors, each represented as an on-chain account. On Polkadot, the +council currently consists of 13 members. This is expected to increase over the next few months to +24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will +be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury.md), the council is called upon primarily for +three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or +malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with +no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; +if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. + +Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous +support - will move to a public referendum under a neutral, majority-carries voting scheme. In the +case that all members of the council vote in favor of a motion, the vote is considered unanimous and +becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to +do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is +burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a +last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of +the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then +it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related +referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's +hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous +proposals that could be submitted with the same hash, i.e. +[proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain +text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy +system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a +fool-proof method of preventing invalid proposals from being submitted - a single changed character +in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist +invalid. + +### How to be a council member? + +![](../assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen.md) process that +selects validators from the available pool based on nominations. However, token holders' votes for +councillors are isolated from any of the nominations they may have on validators. Council terms last +for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen.md) runs and the result will +choose the new councillors based on the vote configurations of all voters. The election also chooses +a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue +with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single +candidate from a list, a Phragmén election is a more expressive way to include each voters' views. +Token holders can treat it as a way to support as many candidates as they want. The election +algorithm will find a fair subset of the candidates that most closely matches the expressed +indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidates A, B, D & E +keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the +next election. After round 2, even though candidates A & B get the same number of votes in this +round, candidate A gets elected because after adding the older unused approvals, it is higher than +B. + +### Prime Members + +The council, being an instantiation of +[Substrate's Collective pallet](https://github.com/paritytech/substrate/tree/master/frame/collective), +implements what's called a _prime member_ whose vote acts as the default for other members that fail +to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members +abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft +approval" by not voting and letting the others vote. With the existence of a prime member, it forces +councillors to be explicit in their votes or have their vote counted for whatever is voted on by the +prime. + +## Technical Committee + +The Technical Committee was introduced in the +[Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one +of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The +Technical Committee is composed of the teams that have successfully implemented or specified either +a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee +via a simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are +fast-tracked for voting and implementation. These are used for emergency bug fixes or rapid +implementation of new but battle-tested features into the runtime. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active +referendum. Thus, with fast-tracked referenda it is possible to have two active referendums at the +same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances, you may want to appeal to the on-chain council to enact a change on your +behalf. One example of this circumstance is the case of lost or locked funds when the funds were +lost due to a human interface error (such as inputting an address for another network). Another +example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not +let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to +be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no +singular place where you are guaranteed to grab every councillor's ear with your message. However, +there are a handful of good places to start where you can get the attention of some of them. The +[Polkadot Direction][] matrix room is one such place. After creating an account and joining this +room, you can post a well-thought-through message here that lays down your case and provides +justification for why you think the council should consider enacting a change to the protocol on +your behalf. + +At some point you will likely need a place for a longer-form discussion. For this, making a post on +[Polkassembly][] is the recommended place to do so. When you write a post on Polkassembly make sure +you present all the evidence for your circumstances and state clearly what kind of change you would +suggest to the councillors to enact. Remember - the councillors do not need to make the change, it +is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. + Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar + explaining how governance works in Polkadot and Kusama. + +[polkadot direction]: https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io +[polkassembly]: https://polkadot.polkassembly.io/ diff --git a/docs/learn-identity.md b/docs/learn/learn-identity.md similarity index 92% rename from docs/learn-identity.md rename to docs/learn/learn-identity.md index d9e8eb83e486..5255611701a6 100644 --- a/docs/learn-identity.md +++ b/docs/learn/learn-identity.md @@ -2,6 +2,7 @@ id: learn-identity title: Identity sidebar_label: Identity +slug: ../learn-identity --- Polkadot provides a naming system that allows participants to add personal information to their @@ -24,12 +25,12 @@ polkadot.js/apps. First, select `identity` as the `selected constant query`. -![Identity as the selected constant query](assets/identity/17.jpg) +![Identity as the selected constant query](../assets/identity/17.jpg) Then on the right-hand side, you can select the constants that you would like to view and add them onto the webpage by clicking the "plus" icon at the end of the bar. -![Identity as the selected constant query](assets/identity/18.jpg) +![Identity as the selected constant query](../assets/identity/18.jpg) Each field can store up to 32 bytes of information, so the data must be less than that. When inputting the data manually through the [Extrinsics UI](https://polkadot.js.org/apps/#/extrinsics), @@ -38,11 +39,11 @@ a [UTF8 to bytes](https://onlineutf8tools.com/convert-utf8-to-bytes) converter c The easiest way to add the built-in fields is to click the gear icon next to your account and select "Set on-chain identity". -![Gear icon provides the option to set identity](assets/identity/01.jpg) +![Gear icon provides the option to set identity](../assets/identity/01.jpg) A popup will appear, offering the default fields. -![Identity field setup popup](assets/identity/02.jpg) +![Identity field setup popup](../assets/identity/02.jpg) To add custom fields beyond the default ones, use the Extrinsics UI to submit a raw transaction by first clicking "Add Item" and adding any field name you like. The example below adds a field @@ -53,18 +54,18 @@ it with the "None" option still selected. That is to say, every time you make a identity values, you need to re-submit the entire set of fields: the write operation is always "overwrite", never "append". -![Setting a custom field](assets/identity/03.jpg) +![Setting a custom field](../assets/identity/03.jpg) Note that custom fields are not shown in the UI by default: -![Only built-in fields are shown](assets/identity/04.jpg) +![Only built-in fields are shown](../assets/identity/04.jpg) The rendering of such custom values is, ultimately, up to the UI/dapp makers. In the case of PolkadotJS, the team prefers to only show official fields for now. If you want to check that the values are still stored, use the [Chain State UI](https://polkadot.js.org/apps/#/chainstate) to query the active account's identity info: -![Raw values of custom fields are available on-chain](assets/identity/05.jpg) +![Raw values of custom fields are available on-chain](../assets/identity/05.jpg) It is up to your own UI or dapp to then do with this data as it pleases. The data will remain available for querying via the Polkadot API, so you don't have to rely on the PolkadotJS UI. @@ -102,7 +103,7 @@ Here's how to submit a proposal to become a registrar: Go to the Democracy tab, select "Submit preimage", and input the information for this motion - notably which account you're nominating to be a registrar in the `identity.setRegistrar` function. -![Setting a registrar](assets/identity/12.jpg) +![Setting a registrar](../assets/identity/12.jpg) Copy the preimage hash. In the above image, that's `0x90a1b2f648fc4eaff4f236b9af9ead77c89ecac953225c5fafb069d27b7131b7`. Submit the preimage by signing @@ -113,7 +114,7 @@ field needs to be at least {{ identity_reserve_funds }} KSM. You can find out th querying the chain state under [Chain State](https://polkadot.js.org/apps/#/chainstate) -> Constants -> democracy -> minimumDeposit. -![Submitting a proposal](assets/identity/13.jpg) +![Submitting a proposal](../assets/identity/13.jpg) At this point, DOT holders can second the motion. With enough seconds, the motion will become a referendum, which is then voted on. If it passes, users will be able to request judgement from this @@ -158,7 +159,7 @@ you entered incorrect data or selected the wrong registrar). In this case, after request for judgement but before your identity has been judged, you can issue a call to cancel the judgement using an extrinsic. -![Cancel Registrar](assets/registrar_cancel_judgement.png) +![Cancel Registrar](../assets/registrar_cancel_judgement.png) To do this, first, go to the ["Extrinsics UI"](https://polkadot.js.org/apps/#/extrinsics) and select the `identity` pallet, then `cancelRequest`. Ensure that you are calling this from the correct @@ -194,7 +195,7 @@ To find out how to contact the registrar after the application for judgement or are, we can check their identity by adding them to our Address Book. Their identity will be automatically loaded. -![Chevdor is registrar #1](assets/identity/16.jpg) +![Chevdor is registrar #1](../assets/identity/16.jpg) ### Polkadot Registrars @@ -218,15 +219,15 @@ reach out to specific registrars individually if you want to be judged by those. Requesting judement follows the same process regardless of whether you're on the Kusama or Polkadot networks. Select one of the registrars from the query you made above. -![Requesting judgement](assets/identity/08.jpg) +![Requesting judgement](../assets/identity/08.jpg) This will make your identity go from unjudged: -![An unjudged identity](assets/identity/07.jpg) +![An unjudged identity](../assets/identity/07.jpg) To "waiting": -![A pending identity](assets/identity/09.jpg) +![A pending identity](../assets/identity/09.jpg) At this point, direct contact with the registrar is required - the contact info is in their identity as shown above. Each registrar will have their own set of procedures to verify your identity and @@ -235,7 +236,7 @@ values, and only once you've satisfied their requirements will the process conti Once the registrar has confirmed the identity, a green checkmark should appear next to your account name with the appropriate confidence level: -![A confirmed identity](assets/identity/10.jpg) +![A confirmed identity](../assets/identity/10.jpg) _Note that changing even a single field's value after you've been verified will un-verify your account and you will need to start the judgement process anew. However, you can still change fields @@ -258,7 +259,7 @@ parent sender account. The value to put into the Data field of each parent is th the sub-account. If omitted, the sub-account will inherit the parent's name and be displayed as `parent/parent` instead of `parent/child`. -![Sub account setup](assets/identity/06.jpg) +![Sub account setup](../assets/identity/06.jpg) Note that a deposit of {{ identity_sub_reserve_funds }} is required for every sub-account. @@ -266,7 +267,7 @@ You can use [polkadot.js/apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/chainstate/constants) again to verify this amount by querying the `identity.subAccountDeposit` constant. -![Sub account constant](assets/identity/19.jpg) +![Sub account constant](../assets/identity/19.jpg) ## Clearing and Killing an Identity diff --git a/docs/learn/learn-implementations.md b/docs/learn/learn-implementations.md new file mode 100644 index 000000000000..70ee8c6eba85 --- /dev/null +++ b/docs/learn/learn-implementations.md @@ -0,0 +1,83 @@ +--- +id: learn-implementations +title: Polkadot Implementations +sidebar_label: Polkadot Implementations +slug: ../learn-implementations +--- + +# Polkadot Implementations + +Polkadot is the flagship protocol of the [Web3 Foundation][], and while Polkadot can be defined as +a protocol, a network, or, a type of infrastructure, it serves to be an ecosystem. For true +decentralization, there should be multiple implementations of Polkadot. Even being a _Layer 0_ protocol +that attempts to build an interconnected, interoperable and secure Web3 ecosystem, Polkadot is a complex +piece of software, and its formal implementation depends on being built on top of a tech stack. + +> There is a countless number of development that is happening in the Polkadot ecosystem, though, this +> page will focus on implementations of Polkadot's underlying infrastructure (i.e. runtime, host). + +## Parity Technologies: A [Rustic Vision for Polkadot][] + +[Parity Technologies][] is often in the spotlight for its core development of Polkadot, and while this +is true, Parity Polkadot also serves to be the [Rust][] client. Parity has a rustic vision for Polkadot +through the use of their main product, [Substrate][]. Substrate can also be used for different +chains and different networks, but in the case of Polkadot, Substrate acts as the tech stack that is used +to implement Polkadot's sharded heterogeneous multi-chain model. What's important to realize is that Polkadot +can support parachains that are not built on Substrate, and, chains can also be built on Substrate which are not +required to be deployed onto Polkadot. + +> Parity focuses on blockchain infrastructure for the decentralised web, where they initially offered an +> Ethereum client (Parity Ethereum). Parity was hired by the Web3 Foundation to foster the development of the +> first implementation of Polkadot. + +With this in mind, we can point to some other implementations of Polkadot. Having different implementations +inherently promotes the decentralization of the technology and progresses it in a meaningful way. Other +implementations of Polkadot that exist, many of whom have received a [grant](../general/grants.md) from the Web3 Foundation, +are in programming languages like Go, C++, and JavaScript. + +As stated in the Soramitsu grant announcement: + + It is critically important to have multiple implementations of the Polkadot protocol for a number + of reasons, including decentralization, knowledge dispersion, and better definitions of the + protocol... Multiple implementations of Polkadot improves network resilience and adds to the + decentralization of the network. The governance of the network is more democratized when multiple + teams build clients that run the nodes in the network. + +## Alternative Implementations + +### ChainSafe Systems: [Gossamer][] + +**Gossamer** is a Go implementation being built by [ChainSafe Systems](https://github.com/ChainSafeSystems), a blockchain +R&D firm based in Toronto, Canada that is also building an Eth2.0 Serenity client. They were awarded a grant from the Web3 +Foundation. + +### SORAMITSU: [Kagome][] + +**Kagome** is a C++ implementation of the Polkadot Host being built by [Soramitsu][], a Japanese digital identity +company that previously developed [Hyperledger Iroha][]. They were awarded a grant from the Web3 Foundation and released +the first version of Kagome in April 2020. As part of the process, they also released a [libp2p][] networking layer in C++. + +### Polkadot-JS Project: [Polkadot-JS][] + +**Polkadot-JS** is a [JavaScript client][] and offers a collection of tools, interfaces, and libraries for Polkadot and Substrate. + +### Other implementations that have received grants + +- [Golkadot][] +- [Polkadot in Java][] + +[web3 foundation]: https://web3.foundation/ +[parity technologies]: https://www.parity.io/ +[substrate]: https://www.substrate.io/ +[rust]: https://www.rust-lang.org/ +[chainsafe systems]: https://chainsafe.io/ +[soramitsu]: https://soramitsu.co.jp/ +[polkadot-js]: https://github.com/polkadot-js +[rustic vision for polkadot]: https://github.com/paritytech/polkadot +[gossamer]: https://github.com/ChainSafe/gossamer#a-go-implementation-of-the-polkadot-host +[kagome]: https://github.com/soramitsu/kagome#intro +[hyperledger iroha]: https://iroha.tech +[libp2p]: https://github.com/soramitsu/libp2p-grpc +[javascript client]: https://github.com/polkadot-js/client +[golkadot]: https://github.com/opennetsys/golkadot +[polkadot in java]: https://github.com/polkadot-java diff --git a/docs/learn-implementers-guide.md b/docs/learn/learn-implementers-guide.md similarity index 92% rename from docs/learn-implementers-guide.md rename to docs/learn/learn-implementers-guide.md index b7911ddcfb1c..246cf75b9c08 100644 --- a/docs/learn-implementers-guide.md +++ b/docs/learn/learn-implementers-guide.md @@ -2,10 +2,11 @@ id: learn-implementers-guide title: Parachain Implementer's Guide sidebar_label: Parachain Implementer's Guide +slug: ../learn-implementers-guide --- The Parachain Implementer's Guide is still a significant work in progress and maintained by -[Parity](glossary.md##parity-technologies). +[Parity](../general/glossary.md##parity-technologies). ## Live version diff --git a/docs/learn/learn-keys.md b/docs/learn/learn-keys.md new file mode 100644 index 000000000000..9f4ae0441172 --- /dev/null +++ b/docs/learn/learn-keys.md @@ -0,0 +1,189 @@ +--- +id: learn-keys +title: Polkadot Keys +sidebar_label: Polkadot Keys +slug: ../learn-keys +--- + +Public and private keys are an important aspect of most crypto-systems and an essential component +that enables blockchains like Polkadot to exist. + +## Account Keys + +Account keys are keys that are meant to control funds. They can be either: + +- The vanilla `ed25519` implementation using Schnorr signatures. +- The Schnorrkel/Ristretto `sr25519` variant using Schnorr signatures. +- ECDSA signatures on secp256k1 + +There are no differences in security between `ed25519` and `sr25519` for simple signatures. + +We expect `ed25519` to be much better supported by commercial HSMs for the foreseeable future. + +At the same time, `sr25519` makes implementing more complex protocols safer. In particular, +`sr25519` comes with safer version of many protocols like HDKD common in the Bitcoin and Ethereum +ecosystem. + +### "Controller" and "Stash" Keys + +When we talk about "controller" and "stash" keys, we usually talk about them in the context of +running a validator or nominating DOT, but they are useful concepts for all users to know. Both keys +are types of account keys. They are distinguished by their intended use, not by an underlying +cryptographic difference. All the info mentioned in the parent section applies to these keys. When +creating new controller or stash keys, all cryptography supported by account keys are an available +option. + +The controller key is a semi-online key that will be in the direct control of a user, and used to +submit manual extrinsics. For validators or nominators, this means that the controller key will be +used to start or stop validating or nominating. Controller keys should hold some DOT to pay for +fees, but they should not be used to hold huge amounts or life savings. Since they will be exposed +to the internet with relative frequency, they should be treated carefully and occasionally replaced +with new ones. + +The stash key is a key that will, in most cases, be a cold wallet, existing on a piece of paper in a +safe or protected by layers of hardware security. It should rarely, if ever, be exposed to the +internet or used to submit extrinsics. The stash key is intended to hold a large amount of funds. It +should be thought of as a saving's account at a bank, which ideally is only ever touched in urgent +conditions. Or, perhaps a more apt metaphor is to think of it as buried treasure, hidden on some +random island and only known by the pirate who originally hid it. + +Since the stash key is kept offline, it must be set to have its funds bonded to a particular +controller. For non-spending actions, the controller has the funds of the stash behind it. For +example, in nominating, staking, or voting, the controller can indicate its preference with the +weight of the stash. It will never be able to actually move or claim the funds in the stash key. +However, if someone does obtain your controller key, they could use it for slashable behavior, so +you should still protect it and change it regularly. + +## Session Keys + +Session keys are hot keys that must be kept online by a validator to perform network operations. +Session keys are typically generated in the client, although they don't have to be. They are _not_ +meant to control funds and should only be used for their intended purpose. They can be changed +regularly; your controller only need create a certificate by signing a session public key and +broadcast this certificate via an extrinsic. + +Polkadot uses four session keys: + +- GRANDPA: ed25519 +- BABE: sr25519 +- I'm Online: sr25519 +- Parachain: sr25519 + +BABE requires keys suitable for use in a [Verifiable Random Function](learn-randomness.md/#vrfs) as +well as for digital signatures. Sr25519 keys have both capabilities and so are used for BABE. + +In the future, we plan to use a BLS key for GRANDPA because it allows for more efficient signature +aggregation. + +## FAQ + +### Why was `ed25519` selected over `secp256k1`? + +The original key derivation cryptography that was implemented for Polkadot and Substrate chains was +`ed25519`, which is a Schnorr signature algorithm implemented over the Edward's Curve 25519 (so +named due to the parameters of the curve equation). + +Most cryptocurrencies, including Bitcoin and Ethereum, currently use ECDSA signatures on the +secp256k1 curve. This curve is considered much more secure than NIST curves, which +[have possible backdoors from the NSA](#appendix-a-on-the-security-of-curves). The Curve25519 is +considered possibly _even more_ secure than this one and allows for easier implementation of Schnorr +signatures. A recent patent expiration on it has made it the preferred choice for use in Polkadot. + +The choice of using Schnorr signatures over using ECDSA is not so cut and dry. As stated in Jeff +Burdges' (a Web3 researcher) +[original forum post](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70/2) +on the topic: + +> There is one sacrifice we make by choosing Schnorr signatures over ECDSA signatures for account +> keys: Both require 64 bytes, but only ECDSA signatures communicate their public key. There are +> obsolete Schnorr variants that support recovering the public key from a signature, but they break +> important functionality like hierarchical deterministic key derivation. In consequence, Schnorr +> signatures often take an extra 32 bytes for the public key. + +But ultimately the benefits of using Schnorr signatures outweigh the tradeoffs, and future +optimizations may resolve the inefficiencies pointed out in the quote above. + +### What is `sr25519` and where did it come from? + +Some context: The Schnorr signatures over the Twisted Edward's Curve25519 are considered secure, +however Ed25519 has not been completely devoid of its bugs. Most notably, +[Monero and all other CryptoNote currencies](https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html) +were vulnerable to a double spend exploit that could have potentially led to undetected, infinite +inflation. + +These exploits were due to one peculiarity in Ed25519, which is known as its cofactor of 8. The +cofactor of a curve is an esoteric detail that could have dire consequences for the security of +implementation of more complex protocols. + +Conveniently, [Mike Hamburg's Decaf paper](https://www.shiftleft.org/papers/decaf/index.xhtml) +provides a possible path forward to solving this potential bug. Decaf is basically a way to take +Twisted Edward's Curves cofactor and mathematically change it with little cost to performance and +gains to security. + +The Decaf paper approach by the [Ristretto Group](https://ristretto.group/) was extended and +implemented in Rust to include cofactor-8 curves like the Curve25519 and makes Schnorr signatures +over the Edward's curve more secure. + +The Web3 Foundation has implemented a Schnorr signature library using the more secure Ristretto +compression over the Curve25519 in the [Schnorrkel](https://github.com/w3f/schnorrkel) repository. +Schnorrkel implements related protocols on top of this curve compression such as HDKD, MuSig, and a +verifiable random function (VRF). It also includes various minor improvements such as the hashing +scheme STROBE that can theoretically process huge amounts of data with only one call across the Wasm +boundary. + +The implementation of Schnorr signatures that is used in Polkadot and implements the Schnorrkel +protocols over the Ristretto compression of the Curve25519 is known as **sr25519**. + +### Are BLS signatures used in Polkadot? + +Not yet, but they will be. BLS signatures allow more efficient signature aggregation. Because +GRANDPA validators are usually signing the same thing (e.g. a block), it makes sense to aggregate +them, which can allow for other protocol optimizations. + +As stated in the BLS library's README, + +> Boneh-Lynn-Shacham (BLS) signatures have slow signing, very slow verification, require slow and +> much less secure pairing friendly curves, and tend towards dangerous malleability. Yet, BLS +> permits a diverse array of signature aggregation options far beyond any other known signature +> scheme, which makes BLS a preferred scheme for voting in consensus algorithms and for threshold +> signatures. + +Even though Schnorr signatures allow for signature aggregation, BLS signatures are much more +efficient in some fashions. For this reason it will be one of the session keys that will be used by +validators on the Polkadot network and critical to the GRANDPA finality gadget. + +## Resources + +- [Key discovery attack on BIP32-Ed25519](https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44) - + Forum post detailing a potential attack on BIP32-Ed25519. A motivation for transition to the + sr25519 variant. +- [Account signatures and keys in Polkadot](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70) - + Original forum post by Web3 researcher Jeff Burdges. +- [Are Schnorr signatures quantum computer resistant?](https://bitcoin.stackexchange.com/questions/57965/are-schnorr-signatures-quantum-computer-resistant/57977#57977) + +## Appendix A: On the security of curves + +From the +[introduction of Curve25519](https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n10) +into `libssl`: + +```text +The reason is the following: During summer of 2013, revelations from ex- +consultant at [the] NSA Edward Snowden gave proof that [the] NSA willingly inserts backdoors +into software, hardware components and published standards. While it is still +believed that the mathematics behind ECC (Elliptic-curve cryptography) are still sound and solid, +some people (including Bruce Schneier [SCHNEIER]), showed their lack of confidence +in NIST-published curves such as nistp256, nistp384, nistp521, for which constant +parameters (including the generator point) are defined without explanation. It +is also believed that [the] NSA had a word to say in their definition. These curves +are not the most secure or fastest possible for their key sizes [DJB], and +researchers think it is possible that NSA have ways of cracking NIST curves. +It is also interesting to note that SSH belongs to the list of protocols the NSA +claims to be able to eavesdrop. Having a secure replacement would make passive +attacks much harder if such a backdoor exists. + +However an alternative exists in the form of Curve25519. This algorithm has been +proposed in 2006 by DJB [Curve25519]. Its main strengths are its speed, its +constant-time run time (and resistance against side-channel attacks), and its +lack of nebulous hard-coded constants. +``` diff --git a/docs/learn-kusama-vs-polkadot.md b/docs/learn/learn-kusama-vs-polkadot.md similarity index 98% rename from docs/learn-kusama-vs-polkadot.md rename to docs/learn/learn-kusama-vs-polkadot.md index a0a2c36d9522..2f8761aed912 100644 --- a/docs/learn-kusama-vs-polkadot.md +++ b/docs/learn/learn-kusama-vs-polkadot.md @@ -2,6 +2,7 @@ id: learn-kusama-vs-polkadot title: What is the difference between Polkadot and Kusama? sidebar_label: Comparing Polkadot and Kusama +slug: ../learn-kusama-vs-polkadot --- Although they share many parts of their code, Polkadot and Kusama are independent, standalone @@ -28,7 +29,7 @@ decisions of their respective communities.** There are a few important distinctions to be made. -![polkadot_vs_kusama](assets/Cousins_2.png) +![polkadot_vs_kusama](../assets/Cousins_2.png) Both networks also have different circulating supplies. diff --git a/docs/learn-launch.md b/docs/learn/learn-launch.md similarity index 95% rename from docs/learn-launch.md rename to docs/learn/learn-launch.md index 7cf7416fb34f..eda6de41c09a 100644 --- a/docs/learn-launch.md +++ b/docs/learn/learn-launch.md @@ -3,6 +3,7 @@ id: learn-launch title: Polkadot Launch Phases sidebar_label: Polkadot Launch Phases description: An explanation of Polkadot's launch process and its individual phases +slug: ../learn-launch --- The Polkadot network has a phased roll-out plan, with important milestones toward decentralization @@ -45,13 +46,13 @@ under control of any centralized authority. ## Balance Transfers -To enable balance transfers, the community [made a public proposal](maintain-guides-democracy.md) +To enable balance transfers, the community [made a public proposal](../maintain/maintain-guides-democracy.md) for a runtime upgrade that lifted the restriction on balance transfers. Transfer functionality was subsequently enabled on Polkadot at block number 1_205_128 on August 18, 2020, at 16:39 UTC. ## Redenomination -On August 21, 2020, [redenomination](redenomination.md) of DOT, the native token on Polkadot, +On August 21, 2020, [redenomination](../general/redenomination.md) of DOT, the native token on Polkadot, occurred. From this date, one DOT (old) equals 100 new DOT. ## Core Functionality diff --git a/docs/learn-nominator.md b/docs/learn/learn-nominator.md similarity index 91% rename from docs/learn-nominator.md rename to docs/learn/learn-nominator.md index 2a75e1c9525c..2314df2455ef 100644 --- a/docs/learn-nominator.md +++ b/docs/learn/learn-nominator.md @@ -2,6 +2,7 @@ id: learn-nominator title: Nominator sidebar_label: Nominator +slug: ../learn-nominator --- Nominators secure the Relay Chain by selecting good validators and staking DOT. @@ -17,7 +18,7 @@ generate. While your DOT are staked by nominating a validator, they are 'locked' (bonded). You can receive new DOT in your account but you cannot stake as validator or transfer DOT away from your account. You -can [un-nominate at any time](maintain-guides-how-to-unbond.md) to stop staking your funds. Keep in +can [un-nominate at any time](../maintain/maintain-guides-how-to-unbond.md) to stop staking your funds. Keep in mind that the un-nomination is effective in the next era, and that un-nominating does not automatically unbond your funds. There is an unbonding period of 7 days on Kusama and 28 days on Polkadot before bonded funds can be transferred after issuing an unbond transaction. @@ -26,10 +27,10 @@ Polkadot before bonded funds can be transferred after issuing an unbond transact When you go to the [Account actions](https://polkadot.js.org/apps/#/staking/actions) under staking page, you should see your bonded accounts and nomination status. If not, you can follow -[this](maintain-guides-how-to-nominate-polkadot.md) guide to configure it first. Your nominations +[this](../maintain/maintain-guides-how-to-nominate-polkadot.md) guide to configure it first. Your nominations will be effective in the next era; eras are roughly 6 hours on Kusama and 24 hours on Polkadot. -![Nominations](assets/staking/polkadotjs_nominator_account.png) +![Nominations](../assets/staking/polkadotjs_nominator_account.png) Suppose you have nominated five validator candidates, and three out of five were elected to the active validator set, then you should see two of your nominations as "waiting", and most likely one @@ -107,7 +108,7 @@ continue operation. Independent validators that rely on the commission to cover help to keep the network decentralized. Commission is just one piece of the puzzle that you should consider when picking validators to nominate. -![Staking Returns](assets/staking/polkadotjs_nominators_target.png) +![Staking Returns](../assets/staking/polkadotjs_nominators_target.png) As a nominator, if you only want to know the profit each validator made for each era, you can go to the [Targets](https://polkadot.js.org/apps/#/staking/targets) section under the staking page by @@ -115,11 +116,11 @@ inputting the number of tokens you would like to stake to check it. Then, nomina higher profit. However, that does not guarantee the right way to evaluate the validators' overall performance. -It is worth taking into consideration "own stake" of a validator. This refers to the quantity of DOT -the validator has put up at stake themselves. A higher "own stake" amount can be considered +It is worth taking into consideration "own stake" of a validator. This refers to the quantity of DOT +the validator has put up at stake themselves. A higher "own stake" amount can be considered as having more "skin in the game". This can imply increased trustworthiness. However, a validator not -having a large amount of "own stake" is not automatically untrustworthy, as the validator could be -nominating from a different address. +having a large amount of "own stake" is not automatically untrustworthy, as the validator could be +nominating from a different address. ### Filter Out Validators With Undesirable Traits @@ -132,7 +133,7 @@ interested in filtering out. - **Single from operator** - Do not show groups of validators run by a single operator. - **No 20%+ comm** - Do not show any validators with a commission of 20% or higher. - **No at capacity** - Do not show any validators who are currently operating - [at capacity](glossary.md#capacity) (i.e., could potentially be oversubscribed). + [at capacity](../general/glossary.md#capacity) (i.e., could potentially be oversubscribed). - **Recent payouts** - Only show validators that have recently caused a [payout to be issued](learn-simple-payouts.md). Note that anyone can cause a payout to occur; it does not have to be the operator of a validator. @@ -150,7 +151,7 @@ likely would get fewer rewards than others. More importantly, when many validato [unreachable](learn-staking.md#unresponsiveness), those nominators who staked with them will be slashed. -![Validator Stats](assets/staking/polkadotjs_validator_stats.png) +![Validator Stats](../assets/staking/polkadotjs_validator_stats.png) Thus, to be a smart nominator, it would be better to query their [histories](https://polkadot.js.org/apps/#/staking/query/) to see statistics such as blocks @@ -171,9 +172,9 @@ etc.). ### Avoiding Oversubscribed Validators If you are not nominating with a large number of DOTs, you should try to avoid -[oversubscribed](glossary.md#oversubscribed) validators. It is not always easy to calculate if the +[oversubscribed](../general/glossary.md#oversubscribed) validators. It is not always easy to calculate if the validator selected will be oversubscribed in the next session; one way to avoid choosing potentially -oversubscribed validators is to filter out any that are [at capacity](glossary.md#capacity) on the +oversubscribed validators is to filter out any that are [at capacity](../general/glossary.md#capacity) on the Targets page. Finally, if you have a very small amount of DOTs, you may not be able to have your nomination fit @@ -194,7 +195,7 @@ details. ### Guides -- [Be a Nominator (Polkadot)](maintain-guides-how-to-nominate-polkadot.md) - Guide on nominating on +- [Be a Nominator (Polkadot)](../maintain/maintain-guides-how-to-nominate-polkadot.md) - Guide on nominating on the Kusama canary network. -- [Stop Being a Nominator (all networks)](maintain-guides-how-to-unbond.md) - Guide on stopping +- [Stop Being a Nominator (all networks)](../maintain/maintain-guides-how-to-unbond.md) - Guide on stopping nominations and withdrawing tokens. diff --git a/docs/learn-parachains.md b/docs/learn/learn-parachains.md similarity index 97% rename from docs/learn-parachains.md rename to docs/learn/learn-parachains.md index 56d01f5c4adf..1b2458389d83 100644 --- a/docs/learn-parachains.md +++ b/docs/learn/learn-parachains.md @@ -3,13 +3,14 @@ id: learn-parachains title: Parachains sidebar_label: Parachains description: An introductory guide to Polkadot Parachains. +slug: ../learn-parachains --- > Note: For information on how to participate in the crowdloan and parachain auction testing on -> Rococo, please see the {{ polkadot: [Rococo page](build-parachains-rococo.md) :polkadot }} > -> {{ kusama: [Rococo page](mirror-build-parachains-rococo.md) :kusama }}. +> Rococo, please see the {{ polkadot: [Rococo page](../build/build-parachains-rococo.md) :polkadot }} > +> {{ kusama: [Rococo page](../build/mirror-build-parachains-rococo.md) :kusama }}. -![One parachain](assets/network/one_parachain.png) +![One parachain](../assets/network/one_parachain.png) A parachain is an application-specific data structure that is globally coherent and validatable by the validators of the Relay Chain. Most commonly a parachain will take the form of a blockchain, but @@ -195,7 +196,7 @@ within [Cumulus](https://github.com/paritytech/cumulus). ### Parachain Development Kits (PDKs) Parachain Development Kits are a set of tools that enable developers to create their own -applications as parachains. For more info see [here](build-pdk.md). +applications as parachains. For more info see [here](../build/build-pdk.md). ### Deploying parachains diff --git a/docs/learn/learn-parathreads.md b/docs/learn/learn-parathreads.md new file mode 100644 index 000000000000..86132ca5ef45 --- /dev/null +++ b/docs/learn/learn-parathreads.md @@ -0,0 +1,108 @@ +--- +id: learn-parathreads +title: Parathreads +sidebar_label: Parathreads +slug: ../learn-parathreads +--- + +Parathreads are an idea for parachains to temporarily participate (on a block by block basis) in +Polkadot security without needing to lease a dedicated parachain slot. This is done through +economically sharing the scarce resource of a _parachain slot_ among a number of competing resources +(parathreads). Chains that otherwise would not be able to acquire a full parachain slot, or do not +find it economically sensible to do so, are enabled to participate in Polkadot's shared security +— albeit with an associated fee per executed block. It also offers a graceful off-ramp to +parachains that no longer require a dedicated parachain slot, but would like to continue using the +Relay Chain. + +## Origin + +According to [this talk](https://v.douyu.com/show/a4Jj7llO5q47Dk01) in Chengdu, the origin of the +idea came from similar notions in the limited resource of memory on early personal computers of the +late '80s and '90s. Since computers have a limited amount of physical memory, when an application +needs more, the computer can create virtual memory by using _swap space_ on a hard disk. Swap space +allows the capacity of a computer's memory to expand and for more processes to run concurrently with +the trade-off that some processes will take longer to progress. + +## How will Parathreads Operate? + +A portion of the parachain slots on the Relay Chain will be designated as part of the parathread +pool. In other words, some parachain slots will have no parachain attached to them and rather will +be used as a space for which the winner(s) of the block-by-block parathread fee auction can have +their block candidate included. + +Collators will offer a bid designated in DOT for inclusion of a parathread block candidate. The +Relay Chain block author is able to select from these bids to include a parathread block. The +obvious incentive is for them to accept the block candidate with the highest bid, which would bring +them the most profit. The tokens from the parathread bids will likely be split 80-20, meaning that +80% goes into Polkadot treasury and 20% goes to the block author. This is the same split that +applies also to transaction fees and, like many other parameters in Polkadot, can be changed through +a governance mechanism. + +## Parachain vs. Parathread + +Parachains and parathreads are very similar from a development perspective. One can imagine that a +chain developed with Substrate can at different points in its lifetime assume one of three states: +an independent chain with secured bridge, a parachain, or a parathread. It can switch between these +last two states with relatively minimal effort since the difference is more of an economic +distinction than a technological one. + +Parathreads have the exact same benefits for connecting to Polkadot that a full parachain has. +Namely, it is able to send messages to other para{chain,threads} through XCMP and it is secured +under the full economic security of Polkadot's validator set. + +The difference between parachains and parathreads is economic. Parachains must be registered through +a normal means of Polkadot, i.e. governance proposal or parachain slot auction. Parathreads have a +fixed fee for registration that would realistically be much lower than the cost of acquiring a +parachain slot. Similar to how DOT are locked for the duration of parachain slots and then returned +to the winner of the auction, the deposit for a parathread will be returned to the parathread after +the conclusion of its term. + +Registration of the parathread does not guarantee anything more than the registration of the +parathread code to the Polkadot Relay Chain. When a parathread progresses by producing a new block, +there is a fee that must be paid in order to participate in a per-block auction for inclusion in the +verification of the next Relay Chain block. All parathreads that are registered are competing in +this auction for their parathread to be included for progression. + +There are two interesting observations to make about parathreads. One, since they compete on a +per-block basis, it is similar to how transactions are included in Bitcoin or Ethereum. A similar +fee market will likely develop, which means that busier times will drive the price of parathread +inclusion up, while times of low activity will require lower fees. Two, this mechanism is markedly +different from the parachain mechanism, which guarantees inclusion as long as a parachain slot is +held; parathread registration grants no such right to the parathread. + +## Parathread Economics + +There are two sources of compensation for collators: + +1. Assuming a parathread has its own local token system, it pays the collators from the transaction + fees in its local token. If the parathread does not implement a local token, or its local token + has no value (e.g. it is used only for governance), then it can use DOT to incentivize collators. +2. Parathread protocol subsidy. A parathread can mint new tokens in order to provide additional + incentives for the collator. Probably, the amount of local tokens to mint for the parathread + would be a function of time, the more time that passes between parathread blocks that are + included in the Relay Chain, the more tokens the parathread is willing to subsidize in order to + be considered for inclusion. The exact implementation of this minting process could be through + local parathread inflation or via a stockpile of funds like a treasury. + +Collators may be paid in local parathread currency. However, the Relay Chain transacts with the +Polkadot universal currency (DOT) only. Collators must then submit block candidates with an +associated bid in DOT. + +## Parachain Slot Swaps + +It will be possible for a parachain that holds a parachain slot to swap this slot with a parathread +so that the parathread "upgrades" to a full parachain and the parachain becomes a parathread. The +chain can also stop being a chain and continue as a thread without swapping the slot. The slot, if +unoccupied, would be auctioned off in the next [auction period](learn-auction.md). + +This provides a graceful off-ramp for parachains that have reached the end of their lease and do not +have sufficient usage to justify renewal; they can remain registered on the Relay Chain but only +produce new blocks when they need to. + +Parathreads help ease the sharp stop of the parachain slot term by allowing parachains that are +still doing something useful to produce blocks, even if it is no longer economically viable to rent +a parachain slot. + +## Resources + +- [Parathreads: Pay-as-you-go Parachains](https://medium.com/polkadot-network/parathreads-pay-as-you-go-parachains-7440d23dde06) diff --git a/docs/learn-phragmen.md b/docs/learn/learn-phragmen.md similarity index 99% rename from docs/learn-phragmen.md rename to docs/learn/learn-phragmen.md index 346c00f031e7..ffd51cf4407a 100644 --- a/docs/learn-phragmen.md +++ b/docs/learn/learn-phragmen.md @@ -2,6 +2,7 @@ id: learn-phragmen title: Sequential Phragmén Method sidebar_label: Sequential Phragmén Method +slug: ../learn-phragmen --- ## What is the sequential Phragmén method? diff --git a/docs/learn/learn-polkadot-host.md b/docs/learn/learn-polkadot-host.md new file mode 100644 index 000000000000..190dd8b1545e --- /dev/null +++ b/docs/learn/learn-polkadot-host.md @@ -0,0 +1,47 @@ +--- +id: learn-polkadot-host +title: Polkadot Host (PH) +sidebar_label: Polkadot Host (PH) +slug: ../learn-polkadot-host +--- + +The architecture of Polkadot can be divided into two different parts, the Polkadot _runtime_ and the +Polkadot _host_. The Polkadot runtime is the core state transition logic of the chain and can be +upgraded over the course of time and without the need for a hard fork. In comparison, the Polkadot +host is the environment in which the runtime executes and is expected to remain stable and mostly +static over the lifetime of Polkadot. + +The Polkadot host interacts with the Polkadot runtime in limited, and well-specified ways. For this +reason, implementation teams can build an alternative implementation of the Polkadot host while +treating the Polkadot runtime as a black box. For more details of the interactions between the host +and the runtime, please see the [specification][]. + +## Components of the Polkadot host + +- Networking components such as Libp2p that facilitates network interactions. +- State storage and the storage trie along with the database layer. +- Consensus engine for GRANDPA and BABE. +- Wasm interpreter and virtual machine. +- Low level primitives for a blockchain, such as cryptographic primitives like hash functions. + +A compiled Polkadot runtime, a blob of Wasm code, can be uploaded into the Polkadot host and used as +the logic for the execution of state transitions. Without a runtime, the Polkadot host is unable to +make state transitions or produce any blocks. + +## Diagram + +Below is a diagram that displays the Polkadot host surrounding the Polkadot runtime. Think of the +runtime (in white) as a component that can be inserted, swapped out, or removed entirely. While the +parts in grey are stable and can not change without an explicit hard fork. + +![polkadot host](../assets/updated_pre.png) + +## Resources + +- [Polkadot Host Protocol Specification](https://github.com/w3f/polkadot-spec) - Incubator for the + Polkadot Host spec, including tests. +- [ChainSafe's Go PH](https://github.com/ChainSafeSystems/go-pre) is a 25-person development team + based in Toronto, Canada. ChainSafe is building an implementation of the beacon chain for Ethereum + 2.0 client in TypeScript and this Go implementation of Polkadot. + +[specification]: https://github.com/w3f/polkadot-spec/ diff --git a/docs/learn-proxies.md b/docs/learn/learn-proxies.md similarity index 94% rename from docs/learn-proxies.md rename to docs/learn/learn-proxies.md index d97564ee3283..41c6da7244ab 100644 --- a/docs/learn-proxies.md +++ b/docs/learn/learn-proxies.md @@ -2,6 +2,7 @@ id: learn-proxies title: Proxy Accounts sidebar_label: Proxy Accounts +slug: ../learn-proxies --- Polkadot provides a module that allows users to set proxy accounts to perform a limited number of @@ -43,7 +44,7 @@ balance transfers (including vested transfers). The "Governance" type will allow proxies to make transactions related to governance (i.e., from the Democracy, Council, Treasury, Technical Committee, and Elections pallets). -> See [Governance](maintain-guides-democracy.md#governance-proxies) for more information on +> See [Governance](../maintain/maintain-guides-democracy.md#governance-proxies) for more information on > governance proxies or watch our > [technical explainer video that explores this concept](https://www.youtube.com/watch?v=q5qLFhG4SDw&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=27&ab_channel=Polkadot). @@ -74,7 +75,7 @@ with anonymous proxies; once you remove the proxy relationship, the account will > Learn more about anonymous proxies from our > [technical explainer video](https://www.youtube.com/watch?v=iWq53zXo7dw&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=28&ab_channel=Polkadot). -![anonymous proxy](assets/proxy_anonymous_diagram.png) +![anonymous proxy](../assets/proxy_anonymous_diagram.png) ### Time Delayed Proxies @@ -100,7 +101,7 @@ Alice or Bob or even add in a new account into the anonymous proxy, the anonymou care of that change. If a multisig wanted to modify itself without an anonymous proxy, a whole new multisig would be created. -![anonymous mutlisig proxy](assets/multisig_proxy_diagram.png) +![anonymous mutlisig proxy](../assets/multisig_proxy_diagram.png) ## How to set up a Proxy @@ -109,7 +110,7 @@ multisig would be created. To set up a proxy, navigate to the [Polkadot-JS UI](https://polkadot.js.org/apps/#/extrinsics) and click on "Developer" > "Extrinsics". Here we will see a page that looks similar to this: -![proxy generation](assets/polkadot_generating_proxy.png) +![proxy generation](../assets/polkadot_generating_proxy.png) To add a proxy, click on the pallet selection dropdown menu. The dropdown is labeled "submit the following extrinsic". Select the `proxy` pallet, then the `addProxy` extrinsic (in the dropdown menu @@ -127,7 +128,7 @@ For anonymous proxies, a different function will need to be called, the `anonymous(proxy_type, index)`. This will let you select which kind of anonymous proxy you would like to set up if you choose, as well as the index. -![proxy generation](assets/polkadot_anon_proxy.png) +![proxy generation](../assets/polkadot_anon_proxy.png) ### Using Time Delayed Proxies @@ -135,7 +136,7 @@ When creating a proxy through the PolkadotJS application, we are provided a dela example we are creating a proxy with a delay value of 100, which means 100 blocks. 100 \* 6(minutes) = 600 minutes, or 10 hours. -![creating a time delayed proxy](assets/time_delay_proxy_screenshot.png) +![creating a time delayed proxy](../assets/time_delay_proxy_screenshot.png) ### Another way to create Proxies @@ -144,7 +145,7 @@ and then click the "Accounts" button. For each of the accounts you have on this button will let you create a proxy by using "Add proxy". This will open up a pop up onto your screen where you will be able to select the type of proxy for that specific account. -![proxy generation part 2](assets/polkadot_add_another_proxy.png) +![proxy generation part 2](../assets/polkadot_add_another_proxy.png) > Note: You cannot create an anonymous function from the Accounts page, you must be on the > Extrinsics page. @@ -156,7 +157,7 @@ this. The `killAnonymous()` function will let you remove an anonymous proxy. Bot `removeProxies()` and the `removeProxy()` will remove any other type of proxy but the former will remove all proxies made while the latter will remove one selected proxy. -![remove proxies](assets/polkadot_remove_proxy.png) +![remove proxies](../assets/polkadot_remove_proxy.png) ## How to view your Proxies @@ -168,7 +169,7 @@ the announcements and proxies functions. The proxies function will allow you to proxies for either one account or for all accounts (using the toggle will enable this). Proxy announcements are what time lock proxies do to announce they are going to conduct an action. -![view proxies](assets/polkadot_view_proxies.png) +![view proxies](../assets/polkadot_view_proxies.png) ## Putting It All Together @@ -177,7 +178,7 @@ you might use these accounts. Imagine you have one account as your primary token and don't want to access it very often, but you do want to participate in governance and staking. You could set Governance and Staking proxies. -![proxies](assets/regular_proxy_diagram.png) +![proxies](../assets/regular_proxy_diagram.png) In this example, the primary account A would only make two transactions to set account B as its governance proxy and account C as its staking proxy. Now, account B could participate in governance diff --git a/docs/learn/learn-randomness.md b/docs/learn/learn-randomness.md new file mode 100644 index 000000000000..284c9b8d4818 --- /dev/null +++ b/docs/learn/learn-randomness.md @@ -0,0 +1,99 @@ +--- +id: learn-randomness +title: Randomness +sidebar_label: Randomness +slug: ../learn-randomness +--- + +Randomness in Proof of Stake blockchains is important for a fair and unpredictable distribution of +validator responsibilities. Computers are bad at random numbers because they are deterministic +devices (the same input always produces the same output). What people usually call random numbers on +a computer (such as in a gaming application), are _pseudo-random_ - that is, they depend on a +sufficiently random _seed_ provided by the user or another type of _oracle_, like a +[weather station for atmospheric noise](https://www.random.org/randomness/), your +[heart rate](https://mdpi.altmetric.com/details/47574324), or even +[lava lamps](https://en.wikipedia.org/wiki/Lavarand), from which it can generate a series of +seemingly-random numbers. But given the same seed, the same sequence will always be generated. + +Though, these inputs will vary based on time and space, and it would be impossible to get the same +result into all the nodes of a particular blockchain around the world. If nodes get different inputs +on which to build blocks, forks happen. Real-world entropy is not suitable for use as a seed for +blockchain randomness. + +There are two main approaches to blockchain randomness in production today: `RANDAO` and `VRF`. + +**Polkadot uses VRF.** + +## VRF + +A verifiable random function (VRF) is a mathematical operation that takes some input and produces a +random number along with a proof of authenticity that this random number was generated by the +submitter. The proof can be verified by any challenger to ensure the random number generation is +valid. + +The VRF used in Polkadot is roughly the same as the one used in Ouroboros Praos. Ouroboros +randomness is secure for block production and works well for [BABE](learn-consensus.md#BABE). Where +they differ is that Polkadot's VRF does not depend on a central clock (the problem becomes - whose +central clock?), rather, it depends on its own past results to determine present and future results, +and it uses slot numbers as a clock emulator, estimating time. + +### Here's how it works in detail: + +Slots are discrete units of time six seconds in length. Each slot can contain a block, but may not. +Slots make up [epochs](../general/glossary.md##epoch) - on Polkadot, 2400 slots make one epoch, which makes +epochs four hours long. + +In every slot, each validator "rolls a die". They execute a function (the VRF) that takes as input +the following: + +- **The "secret key",** a key specifically made for these die rolls. +- **An epoch randomness value,** which is the hash of VRF values from the blocks in the epoch before + last (N-2), so past randomness affects the current pending randomness (N). +- **The slot number.** + +![](../assets/VRF_babe.png) + +The output is two values: a `RESULT` (the random value) and a `PROOF` (a proof that the random value +was generated correctly). + +The `RESULT` is then compared to a _threshold_ defined in the implementation of the protocol +(specifically, in the Polkadot Host). If the value is less than the threshold, then the validator +who rolled this number is a viable block production candidate for that slot. The validator then +attempts to create a block and submits this block into the network along with the previously +obtained `PROOF` and `RESULT`. Under VRF, every validator rolls a number for themselves, checks it against a threshold, and produces a block if the random roll is under that threshold. + +The astute reader will notice that due to the way this works, some slots may have no validators as +block producer candidates because all validator candidates rolled too high and missed the threshold. +We clarify how we resolve this issue and make sure that Polkadot block times remain near +constant-time in the wiki page on [consensus](learn-consensus.md). + +## RANDAO + +An alternative method for getting randomness on-chain is the +[RANDAO](https://github.com/randao/randao) method from Ethereum. RANDAO requires each validator to +prepare by performing many thousands of hashes on some seed. Validators then publish the final hash +during a round and the random number is derived from every participant's entry into the game. As +long as one honest validator participates, the randomness is considered secure (non-economically +viable to attack). + +RANDAO is optionally augmented with VDF. + +### VDFs + +[Verifiable Delay Functions](https://vdfresearch.org/) are computations that take a prescribed +duration of time to complete, even on parallel computers. They produce unique output that can be +independently and efficiently verified in a public setting. By feeding the result of RANDAO into a +VDF, a delay is introduced that renders any attacker's attempt at influencing the current randomness +obsolete. + +VDFs will likely be implemented through ASIC devices that need to be run separately from the other +types of nodes. Although only one is enough to keep the system secure, and they will be open source +and distributed at nearly no charge, running them is neither cheap nor incentivized, producing +unnecessary friction for users of the blockchains opting for this method. + +## Resources + +- [Polkadot's research on blockchain randomness and sortition](https://w3f-research.readthedocs.io/en/latest/polkadot/block-production/Babe.html) - + contains reasoning for choices made along with proofs +- [Discussion on Randomness used in Polkadot](https://github.com/paritytech/ink/issues/57) - W3F + researchers discuss the randomness in Polkadot and when it is usable and under which assumptions. diff --git a/docs/learn/learn-registrar.md b/docs/learn/learn-registrar.md new file mode 100644 index 000000000000..6b00993b05ac --- /dev/null +++ b/docs/learn/learn-registrar.md @@ -0,0 +1,172 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +slug: ../learn-registrar +--- + +> **Warning**: The beta version of the new registrar service is available at +> https://registrar.web3.foundation/. The service as described in this guide is currently halted +> and will be deprecated soon. + +An on-chain identity is a good way to build up your reputation and let the community know more about +you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar +service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and +no fees on Polkadot (although there may be a small fee in the future). However, you will of course +need to reserve some DOT in your account while you have an identity, no matter which registrar you +use. For details on the amount necessary to reserve, as well as the identity system as a whole, see +the [identity](learn-identity.md) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys +> to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` +when setting an on-chain identity, these will be required to verify one by one by signing a +challenge message. Be aware that the `display name` cannot be too similar to others that have been +verified already. There is no need to set all of the fields when using the service. You are free to +set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](../general/community.md#polkadot) to ask questions if there is +anything unclear. + +## Setting an On-chain Identity + +### Filling out information + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to +> leave it blank when you fill in your identity information. + +Go to [Accounts](https://polkadot.js.org/apps/#/accounts) page in Polkadot-JS Apps. The easiest way +to add the built-in fields is to click the vertical three dots next to one's account and select "Set +on-chain identity". + +A popup will appear, offering the default fields. + +Currently, the registrar **only supports the following fields**: + +- Display Name +- Email +- Twitter +- Element (formerly known as Riot) + +![registrar](../assets/registrar/1.jpg) + +--- + +If you try to register the other fields, such as: + +![registrar](../assets/registrar/2.jpg) + +You will eventually be asked to update your information, as these are not yet supported by the +registrar. + +![registrar](../assets/registrar/6.jpg) + +--- + +### Invoke transaction to set identity + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to +submit the transaction. + +Now you have set the identity information on-chain, but that is not verified yet, so you should see +a little grey icon beside your name. + +![registrar](../assets/registrar/3.jpg) + +It is the time to interact with the W3F's verification bot by submitting the judgment request to the +W3F's registrar. + +## Request Judgement + +![registrar](../assets/registrar/4.jpg) + +Go to +[Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) +and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` +transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for +Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to +receive the verification requests from those platforms. As for Element, an invitation will be sent +by the bot named `W3F Registrar Verification`. + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether +> that is ours or not, ask in the Polkadot community chat first. + +Once you accept the invitation, you should see the following information. + +![registrar](../assets/registrar/5.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the +PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" +field and click "Sign message". + +![registrar](../assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification +chat. + +![registrar](../assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your +address has been verified. This proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example +for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](../assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to +[Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS +and select your account, paste the "Challenge" data to the "sign the following data" field and click +"Sign message" + +![registrar](../assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](../assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified +successfully. + +## Twitter Verification + +Lastly, if you have provided a Twitter handle, you would have to follow +[@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" +will do the trick. + +After waiting for a few minutes you should receive a challenge similar to the previous two. + +![registrar](../assets/registrar/12.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that +you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](../assets/registrar/13.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 +minutes. + +If everything has been verified successfully, you will see that your account verification status has +been marked as "reasonable" with a **green tick icon** on the +[Accounts](https://polkadot.js.org/apps/#/accounts) page. + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/docs/learn-runtime-upgrades.md b/docs/learn/learn-runtime-upgrades.md similarity index 96% rename from docs/learn-runtime-upgrades.md rename to docs/learn/learn-runtime-upgrades.md index 102996c6b458..f776bd6f3bb9 100644 --- a/docs/learn-runtime-upgrades.md +++ b/docs/learn/learn-runtime-upgrades.md @@ -2,6 +2,7 @@ id: learn-runtime-upgrades title: Runtime Upgrades sidebar_label: Runtime Upgrades +slug: ../learn-runtime-upgrades --- # Runtime Upgrades @@ -58,7 +59,7 @@ releases. Infrastructure services including but not limited to the following: -- [Validators](maintain-guides-how-to-upgrade.md) +- [Validators](../maintain/maintain-guides-how-to-upgrade.md) - API services - Node-as-a-Service (NaaS) - General infrastructure management (e.g. block explorers, exchanges) @@ -72,13 +73,13 @@ timely manner, somethings to keep an eye out on is updating your parsing logic a changes to the available RPC clients, such as the [Substrate API Sidecar](https://github.com/paritytech/substrate-api-sidecar). -### For [Nominators](maintain-guides-how-to-nominate-polkadot.md) +### For [Nominators](../maintain/maintain-guides-how-to-nominate-polkadot.md) Runtime upgrades don't require any actions by a nominator, though, it is always encouraged to keep up-to-date and participate with the latest runtime upgrade motions and releases, while keeping an eye on how the nodes on the network are reacting to a new upgrade. -### For [Wallets](build-wallets.md) +### For [Wallets](../build/build-wallets.md) Wallets should look out for updates to the transaction lifecycle, such as tx broadcasting. An example would be constructing a transaction with a new spec, "n", but broadcasting it with a spec diff --git a/docs/learn-security.md b/docs/learn/learn-security.md similarity index 99% rename from docs/learn-security.md rename to docs/learn/learn-security.md index 923bac7f102d..3c192137d9b3 100644 --- a/docs/learn-security.md +++ b/docs/learn/learn-security.md @@ -2,10 +2,9 @@ id: learn-security title: Security of the network sidebar_label: Security of the network +slug: ../learn-security --- - - ## Shared security Shared security, sometimes referred in documentation as _pooled security_, is one of the unique diff --git a/docs/learn-simple-payouts.md b/docs/learn/learn-simple-payouts.md similarity index 94% rename from docs/learn-simple-payouts.md rename to docs/learn/learn-simple-payouts.md index b7db46ff663d..3baa057115fd 100644 --- a/docs/learn-simple-payouts.md +++ b/docs/learn/learn-simple-payouts.md @@ -2,6 +2,7 @@ id: learn-simple-payouts title: Simple Payouts sidebar_label: Simple Payouts +slug: ../learn-simple-payouts --- Polkadot and Kusama make stakers claim their rewards for past eras by submitting a transaction. This @@ -13,7 +14,7 @@ transactions would allow the block construction algorithm to process only a limi and ensure that the network maintains a constant block time. If all rewards were sent out in one block, this could cause serious issues with the stability of the network. -Simple payouts require one transaction per validator, per [era](glossary.md##era), to claim rewards. +Simple payouts require one transaction per validator, per [era](../general/glossary.md##era), to claim rewards. The reason Polkadot requires this is to avoid an attack where someone has several thousand accounts nominating a single validator. The major cost in reward distribution is mutating the accounts in storage, and Polkadot cannot pay out several thousand accounts in a single transaction. @@ -49,17 +50,17 @@ batches of eras at once. To claim rewards on Polkadot-JS UI, you will need to be in the "Payouts" tab underneath "Staking", which will list all the pending payouts for your stashes. -![pending-payouts](assets/polkadotjs_payout_page.png) +![pending-payouts](../assets/polkadotjs_payout_page.png) To then claim your reward, select the "Payout all" button. This will prompt you to select your stash accounts for payout. -![select-payouts](assets/polkadotjs_payout_popup.png) +![select-payouts](../assets/polkadotjs_payout_popup.png) Once you are done with payout, another screen will appear asking for you to sign and submit the transaction. -![transaction-payouts](assets/polkadotjs_payout_complete.png) +![transaction-payouts](../assets/polkadotjs_payout_complete.png) ## F.A.Q. and Cautionary Notes diff --git a/docs/learn/learn-spree.md b/docs/learn/learn-spree.md new file mode 100644 index 000000000000..5c9dcdc7b8a6 --- /dev/null +++ b/docs/learn/learn-spree.md @@ -0,0 +1,103 @@ +--- +id: learn-spree +title: SPREE +sidebar_label: SPREE +slug: ../learn-spree +--- + +Shared Protected Runtime Execution Enclaves (SPREE) sometimes referred to as "trust wormholes," are +fragments of logic comparable to runtime modules in Substrate, but live on the Polkadot Relay Chain +and may be opted into by parachains. + +SPREE in brief was described with the following properties and functions: + +- Parachains can opt-in to special runtime logic fragments (like smart contracts). +- These fragments have their own storage and own [XCMP](learn-crosschain.md) endpoint. +- All instances across parachains have identical logic. +- It executes alongside parachain logic. +- Protected: storage can not be altered by parachain logic; messages can not be faked from them by + parachains. + +## Origin + +On 28 March, 2019 u/Tawaren, a member of the Polkadot community, made a post on +[r/dot][polkadot reddit] called "SmartProtocols Idea" and laid out a proposal for [Smart +Protocols][smart protocols reddit post]. The core insight of the post was that XCMP had a +complication in that it was difficult to verify and prove code was executed on a parachain without +trust. A solution was to install the SmartProtocols in the Relay Chain that would be isolated blobs +of code with their own storage per instance that could only be changed through an interface with +each parachain. SmartProtocols are the precursor to SPREE. + +## What is a SPREE module? + +SPREE modules are fragments of logic (in concrete terms they are blobs of +[WebAssembly](learn-wasm.md) code) that are uploaded onto Polkadot through a governance mechanism or +by parachains. Once the blob is uploaded to Polkadot, all other parachains can decide to opt-in to +the logic. The SPREE module would retain its own storage independent of the parachain, but would be +callable through an interface with the parachain. Parachains will send messages to the SPREE module +synchronously. + +SPREE modules are important to the overall XCMP architecture because they give a guarantee to the +code that will be executed on destination parachains. While XCMP guarantees the delivery of a +message, it does not guarantee what code will be executed, i.e. how the receiving parachain will +interpret the message. While XCMP accomplishes trustless message passing, SPREE is the trustless +interpenetration of the message and a key part of the usefulness of XCMP. + +SPREE modules are like recipes in cookbooks. For example, if we give an order to a cook to make a +soufflé, and we’re decently confident in the ability of the cook, we have a vague idea of what will +be made but no actual surety of how it will be made. However, let’s say that a cook has the “Soufflé +Maker’s Manual” on their bookshelf and has committed themselves to only make souffles from this +book. Now we can also consult the same book that the cook has, and we have a precise understanding +of what will happen when we tell the cook to make a soufflé. In this example, “make a soufflé” was +the message in XCMP and the cookbook was the SPREE module. + +In concrete terms, SPREE modules could be useful for various functionality on Polkadot. One +suggested use case of SPREE modules is for a trustless decentralized exchange that is offered as +functionality to any parachain without any extra effort from parachain developers. One can imagine +this working by having a SPREE module that exposes the interface for the incrementing and +decrementing of balances of various assets based on a unique identifier. + +## Why? + +Sending messages across parachains in XCMP only ensures that the message will be delivered but does +not specify the code that will be executed, or how the message will be interpreted by the receiving +parachain. There would be ways around this such as requesting a verifiable receipt of the execution +from the receiving parachain, but in the naked case, the other parachain would have to be trusted. +Having shared code that exists in appendices that the parachain can opt-in to resolves the need for +trust and makes the execution of the appendices completely trustless. + +SPREE would be helpful to ensure that the same logic is shared between parachains in the SPREE +modules. An especially relevant use case would revolve around the use of token transfers across +parachains in which it is important that the sending and receiving parachains agree about how to +change the total supply of tokens and a basic interface. + +## Example + +![spree example](../assets/SPREE/spree_module.png) + +The diagram above is a simplification of the Polkadot system. + +In this diagram, we see that the Wasm code for SPREE module "X" has been uploaded to the Polkadot +Relay Chain. The two cylinders "A" and "B" represent two distinct parachains that have both opted-in +to this SPREE module creating two distinct instances of it with their own XCMP endpoints "A.X" and +"B.X". + +In the example, we assume that this SPREE module "X" contains the functionality for incrementing of +decrementing the balance of a particular asset that is unique to this module. + +By initiating a transaction at A.X to decrease a particular balance by 1, a message over XCMP can be +trustlessly sent to B.X to increase a balance by 1. + +Collators, represented as the green triangle are responsible for relaying this message from +parachain A to parachain B, as well as maintaining the storage for each particular instance of A.X +and B.X for their respective parachains. They provide proofs of valid state transitions to the Relay +Chain validators represented as blue diamonds. + +Validators can validate the correct state transitions of SPREE modules A.X and B.X by being provided +with the previous state root of the SPREE module instances, the data of the XCMP message between the +instances, and the next state root of the instance. They do this validation by checking it against +the `validate` function as provided by the SPREE module API. Collators are expected to be able to +provide this information to progress their parachains. + +[polkadot reddit]: https://www.reddit.com/r/dot/ +[smart protocols reddit post]: https://www.reddit.com/r/dot/comments/b6kljn/smartprotocols_idea/ diff --git a/docs/learn/learn-staking.md b/docs/learn/learn-staking.md new file mode 100644 index 000000000000..68ef30ad07af --- /dev/null +++ b/docs/learn/learn-staking.md @@ -0,0 +1,531 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +slug: ../learn-staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It +is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors +who are interested in maintaining the network can run a validator node. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 +validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus.md/#babe), validating +parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with +their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. +Having more stake on a validator does not influence the amount of block rewards it receives. +However, there is a probabilistic component to reward calculation (discussed below), so rewards may +not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In +this way, the network incents the nomination of lower-staked validators to create an equally-staked +validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate validator candidates that you trust to help you earn rewards in the +chain's native token. You can take a look at the [nominator guide](learn-nominator.md) to understand +your responsibilities as a nominator, and the [validator docs](learn-validator.md) to understand +what you need to do as a validator. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies +are made public to all nominators, and a nominator in turn submits a list of any number of +candidates that it supports. In the next era, a certain number of validators having the most DOT +backing get elected and become active. + +There are no particular requirements to become a nominator, though we expect each nominator to +carefully track the performance and reputation of the validators they back. Nominating is _not_ a +"set and forget" operation. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their +associated votes as input, and outputs a set of validators. This "election solution" has to meet +certain requirements, such as maximizing the amount of stake to nominate validators and distributing +the stake backing validators as evenly as possible. The objectives of this election mechanism are to +maximize the security of the network, and achieve fair representation of the nominators. If you want +to know more about how NPoS works (e.g. election, running time complexity, etc.), please read +[here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator +pools**. A validator pool consists of the stake of an elected validator together with the nominators +backing it. + +If a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election +mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` +with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were +`k` nominators in different pools, each backing a single validator `i` with stake `s_i`. + +For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially +the **same amount of tokens** for equal work, i.e. they are NOT paid proportional to the stakes in +each pool. There is a probabilistic component to staking rewards in the form of +[era points](../maintain/maintain-guides-validator-payout.md##era-points) and +[tips](learn-transaction-fees.md#fee-calculation) but these should average out over time. + +Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's +commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the +nominators and validator. Notice in particular that the validator is rewarded twice: once in +commission fees for validating (if their commission rate is above 0%), and once for nominating +itself with stake. If a validator's commission is set to 100%, no tokens will be paid out to any +nominations in the validator pool. + +To estimate the inflation rate and how many tokens you can get each month as a nominator or +validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a +reference and play around with it by changing some parameters (e.g. how many days you would like to +stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though +it may not be entirely accurate since staking participation is changing dynamically, it works well +as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid +the same regardless of stake level, pools with less stake will generally pay more to nominators +per-token than pools with more stake. + +We thus give nominators an economic incentive to gradually shift their preferences to lower staked +validators that gain a sufficient amount of reputation. The reason for this is that we want the +stake across validator pools to be as evenly distributed as possible, to avoid a concentration of +power among a few validators. + +In the long term, we expect all validator pools to have similar levels of stake, with the stake +being higher for higher reputation validators (meaning that a nominator that is willing to risk more +by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual + value, which fluctuates, but merely an assumption for purposes of this example; to understand how + the actual minimal stake is calculated, see + [here](../general/faq.md#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT +than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he +only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number +of nominators a validator may have, a validator does have a limit to how many nominators to which it +can pay rewards. + +In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be +modified via runtime upgrade. A validator with more than {{ polkadot_max_nominators }} nominators is +_oversubscribed_. When payouts occur, only the top {{ polkadot_max_nominators }} nominators as +measured by amount of stake allocated to that validator will receive rewards. All other nominators +are essentially "wasting" their stake - they used their nomination to elect that validator to the +active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator +offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount), +which means that validator pools with more stake get slashed more DOT. Again, this is done to +provide nominators with an economic incentive to shift their preferences and back less popular +validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission +fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the +same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, +each validator can choose between increasing their fees to earn more, or decreasing their fees to +attract more nominators and increase their chances of being elected. In the long term, we expect +that all validators will need to be cost efficient to remain competitive, and that validators with +higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](../assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a + Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, + meaning it stays offline all the time. You can also designate a Proxy account to vote in + [governance](learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about + nominating and validating. It sets preferences like payout account and commission. If you are a + validator, it also sets your [session keys](learn-keys.md/#session-keys). It only needs enough + funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can +protect themselves much better than in systems with only one key. As a rule, you lose security +anytime you use one key for multiple roles, or even if you use keys related by derivation. You +should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in +Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots are limited, most of those who wish to stake their DOT and contribute economic +security to the network will be nominators. + +Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to +consensus in GRANDPA, validate the state transition function of parachains, and possibly some other +responsibilities regarding data availability and [XCMP](learn-crosschain). + +Nominators, on the other hand, have far fewer responsibilities. Those include monitoring their +validators' performance (uptime), keeping an eye on changing commission rates (a validator can +change commission at any time), and general health monitoring of their and their validators' +account. Thus, while not set-it-and-forget-it, a nominator's experience is relatively hands-off +compared to a validators. + +![staking](../assets/NPoS/article-2.png) + +### Want to stake DOT? + +- [Nominator Guide](../maintain/maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot + network. +- [Validator Guide](../maintain/maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot + network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs +modified software) in the network. They and their nominators will get slashed by losing a percentage +of their bonded/staked DOT. + +Any slashed DOT will be added to the [Treasury](learn-treasury). The rationale for this (rather than +burning or distributing them as rewards) is that slashes may then be reverted by the Council by +simply paying out from the Treasury. This would be useful in situations such as a faulty runtime +causing slashing or forcing validators offline through no fault of their own. In the case of +legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem +through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular +ones, so we encourage nominators to shift their nominations to less popular validators to reduce +their possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, +and slashes are not mitigated by having other inactive or waiting nominations. They are also not +mitigated by the validator operator running separate validators; each validator is considered its +own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus +causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has +nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with +other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the +active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The +nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and +waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not +actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any +nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In +this case, the slash is proportionate to the amount staked to that specific validator. For instance, +if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash +of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their +stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to +both halves of their stake. Note that you cannot control the percentage of stake you have allocated +to each validator or choose who your active validator will be (except in the trivial case of +nominating a single validator). Staking allocations are controlled by the +[Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this +via +[Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). +The UI shows it per validator and then all the affected nominators along with the amounts. While +unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 +days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are +[defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). However, these +particular levels are not implemented or referred to in the code or in the system; they are meant as +guidelines for different levels of severity for offences. To understand how slash amounts are +calculated, see the equations in the section below. + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch][]. Generally no + slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the + stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to + any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting + in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass + collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a +validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as +unresponsive. Depending on the repeated offences and how many other validators were unresponsive or +offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators in the active set + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Let us run through a few examples to understand this equation. In all of the examples, assume that +there are 100 validators in the active set. + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to +reduce the risk of being slashed. A high availability setup is desirable, preferably with backup +nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing +and being slashed for equivocation - see below). A comprehensive guide on validator setup is +available [here](../maintain/maintain-guides-secure-validator.md). +reduce the risk of being slashed or chilled. A high availability setup is desirable, perhaps with +backup nodes that kick in **only once the original node is verifiably offline** (to avoid +double-signing and being slashed for equivocation - see below). A comprehensive guide on validator +setup is available [here](../maintain/maintain-guides-secure-validator.md). + +> > > > > > > master:docs/learn-staking.md + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +Both GRANDPA and BABE equivocation use the same formula for calculating the slashing penalty: + + Let x = offenders, n = total no. validators in active set + + Min( (3 * x / n )^2, 1) + +As an example, assume that there are 100 validators in the active set, and one of them equivocates +in a slot (for our purposes, it does not matter whether it was a BABE or GRANDPA equivocation). This +is unlikely to be an attack on the network, but much more likely to be a misconfiguration of a +validator. The penalty would be Min(3 \* 1 / 100)^2, 1) = 0.0009, or a 0.09% slash for that +validator pool (i.e., all stake held by the validator and its nominators). + +Now assume that there is a group runnning several validators, and all of them have an issue in the +same slot. The penalty would be Min((3 _ 5 / 100)^2, 1) = 0.0225, or a 2.25% slash. If 20 validators +equivocate, this is a much more serious offence and possibly indicates a coordinated attack on the +network, and so the slash will be much greater - Min((3 _ 20 / 100)^2, 1) = 0.36, or a 36% slash on +all of these validators and their nominators. All slashed validators will also be chilled. + +From the example above, the risk in nominating or running many validators in the active set are +apparent. While rewards grow linearly (two validators will get you approximately twice as many +staking rewards as one), slashing grows exponentially. A single validator equivocating causes a +0.09% slash, two validators equivocating does not cause a 0.09 \* 2 = 0.18% slash, but rather a +0.36% slash - 4x as much as the single validator. + +Validators may run their nodes on multiple machines to make sure they can still perform validation +work in case one of their nodes goes down, but validator operators should be extremely careful in +setting these up. If they do not have good coordination to manage signing machines, equivocation is +possible, and equivocation offences are slashed at much higher rates than equivalent offline +offences. + +If a validator is reported for any one of the offences they will be removed from the validator set +([chilled](#chilling)) and they will not be paid while they are out. They will be considered +inactive immediately and will lose their nominators. They need to re-issue intent to validate and +again gather support from nominators. + +If you want to know more details about slashing, please look at our +[research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of stepping back from any nominating or validating. It can be done by a +validator or nominator at any time themselves, taking effect in the next era. It can also specifally +mean removing a validator from the active validator set by another validator, disqualifying them +from the set of electable candidates in the next NPoS cycle. + +Chilling may be voluntary and validator-initiated, e.g. if there is a planned outage in the +validator's surroundings or hosting provider, and the validator wants to exit to protect themselves +against slashing. When voluntary, chilling will keep the validator active in the current session, +but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment (initiated externally), being chilled carries an implied penalty +of being un-nominated. It also disables the validator for the remainder of the current era and +removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too +large, Polkadot will trigger a new validator election to get a full set. Disabled validators will +need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill][] page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does + not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, +rather than the sum. This ensures protection from overslashing. Likewise, the time span over which +maximum slashes are computed are finite and the validator is chilled with nominations withdrawn +after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, +once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is +already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. +Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and +calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, +rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, +there may be slight differences in your rewards from era to era, and even amongst validators in the +active set at the same time. These variations should cancel out over a long enough timeline. See the +page on [Validator Payout Guide](../maintain/maintain-guides-validator-payout.md) for more information on how +these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you +nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot +and 21 days on Kusama. For more information on why this is so, see the page on +[simple payouts](learn-simple-payouts.md). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim +> them and some of your staking rewards will be lost. Additionally, if the validator unbonds all +> their own stake, any pending payouts will be lost. Since unbonding takes 28 days on Polkadot, +> nominators should check if they have pending payouts at least this often. + +### Claiming Rewards + +If you go to the Staking payouts page on +[Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators +that you have nominated in the past 84 eras and for which you have not yet received a payout. Each +one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone +who was nominating that validator during those eras, and anyone can call it. Therefore, you may not +see anything in this tab, yet still have received a payout if somebody (generally, but not +necessarily, another nominator or the validator operator) has triggered the payout for that +validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See +[the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) +for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3_600 * 6 seconds = 21_600 s = 6 hours + +``` + +Validators can create a cut of the reward (a commission) that is not shared with the nominators. +This cut is a percentage of the block reward, not an absolute value. After the commission gets +deducted, the remaining portion is based on their staked value and split between the validator and +all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify +`validator_commission = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT +would then be split between the validator and their nominators based on the proportion of stake each +nominator had. Note that validators can put up their own stake, and for this calculation, their +stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either +increasing the staked value or not increasing the staked value), or to a completely unrelated +account. By using the Extrinsics tab (`Developer -> Extrinsics -> Staking -> Bond`) you can also +send rewards to "None", effectively burning them. It is also possible to top-up / withdraw some +bonded DOT without having to un-stake all staked DOT. + +For specific details about validator payouts, please see +[this guide](../maintain/maintain-guides-validator-payout.md). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be +approximately 10% annually, with validator rewards being a function of amount staked and the +remainder going to treasury. + +![staking](../assets/NPoS/staking-participation-rate.png) + +

Source: Research - Web3 Foundation

+ +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the staking overview at +[Polkadot-JS](https://polkadot.js.org/apps/#/staking). + +The above chart shows the inflation model of the network. Depending on the staking participation, +the distribution of the inflation to validators/nominators versus the treasury will change +dynamically to provide incentives to participate (or not participate) in staking. + +For instance, assuming that the ideal staking rate is 50%, all of the inflation would go to the +validators/nominators if 50% of all KSM / DOT are staked. Any deviation from the 50% - positive or +negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, +please see +[here](https://w3f-research.readthedocs.io/en/latest/polkadot/overview/2-token-economics.html). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual nominal return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has increased gradually to 297. The top bound +on the number of validators has not been determined yet, but should only be limited by the bandwidth +strain of the network due to peer-to-peer message passing. The estimate of the number of validators +that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has +900 validator slots in the active set. + +## Motion #103: New Minimum Nomination Bond + +At the time of writing (#6,339,031), Polkadot has a maximum nominator count of 22,500, and the current staking configuration prevents new nominators from joining. Motion #103 proposes new nomination limits to the Polkadot network, offering a temporary solution to increase the stability and security of the network. Note that this motion **does not** increase the maximum nominator count. + +The goal of this motion is to increase the minimum nomination bond, allowing new nominators that meet this requirement to particpate in the network's security. This motion will update the value of the minimum nominator bond from 40 DOTs to 80 DOTs and set a new parameter named `chill-threshold`. With `chill-threshold`, the permissionless `chill_other` may only be executed if, and only if, the current nominator count is greater than 90% of the maximum number of nominators. Any existing nominator can update their nomination preferences (amount of DOT bonded, number of nominators, etc.) to adjust to this change. A more permanent solution is in progress. + +**Parameters changed:** +minimum nominator bond : `40` -> `80` + +**Parameters added:** +chill-threshold: `90%` + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - + Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Validator setup](../maintain/maintain-guides-secure-validator.md) + +[epoch]: ../general/glossary.md#epoch +[how to chill]: ../maintain/maintain-guides-how-to-chill.md diff --git a/docs/learn-teleport.md b/docs/learn/learn-teleport.md similarity index 96% rename from docs/learn-teleport.md rename to docs/learn/learn-teleport.md index de7bc38219bb..2ddcd97a922f 100644 --- a/docs/learn-teleport.md +++ b/docs/learn/learn-teleport.md @@ -2,6 +2,7 @@ id: learn-teleport title: Teleporting Assets To Other Parachains sidebar_label: Teleporting Assets +slug: ../learn-teleport --- One of the main properties that Polkadot and Kusama bring to the ecosystems is decentralied @@ -18,7 +19,7 @@ interface. 1. Navigate to [PolkadotJS Apps] and connect to the chain with the tokens you want to teleport. 2. Navigate to "Accounts > Teleport". This opens the 'teleport assets' interface: - ![transfer](assets/teleport_interface.png) + ![transfer](../assets/teleport_interface.png) 3. Fill out the transaction: 1. "send from account" - Select the account with the source tokens. 2. "destination chain" - Select the parachain you want to send the assets to. diff --git a/docs/learn/learn-transaction-fees.md b/docs/learn/learn-transaction-fees.md new file mode 100644 index 000000000000..54d38b91557f --- /dev/null +++ b/docs/learn/learn-transaction-fees.md @@ -0,0 +1,142 @@ +--- +id: learn-transaction-fees +title: Transaction Fees +sidebar_label: Transaction Fees +slug: ../learn-transaction-fees +--- + +Several resources in a blockchain network are limited, for example, storage and computation. +Transaction fees prevent individual users from consuming too many resources. Polkadot uses a +weight-based fee model as opposed to a gas-metering model. As such, fees are charged prior to +transaction execution; once the fee is paid, nodes will execute the transaction. + +[Web3 Foundation Research](https://w3f-research.readthedocs.io/en/latest/polkadot/overview/2-token-economics.html?highlight=transaction%20fee) +designed the Polkadot fee system with the following objectives: + +- Each Relay Chain block should be processed efficiently to avoid delays in block production. +- The growth rate of the Relay Chain should be bounded. +- Each block should have space for special, high-priority transactions like misconduct reports. +- The system should be able to handle spikes in demand. +- Fees should change slowly so that senders can accurately predict the fee for a given transaction. + +## Fee Calculation + +Fees on the Polkadot Relay Chain are calculated based on three parameters: + +- A per-byte fee (also known as the "length fee"). +- A weight fee. +- A tip (optional). + +The length fee is the product of a constant per-byte fee and the size of the transaction in bytes. + +Weights are a fixed number designed to manage the time it takes to validate a block. Each +transaction has a base weight that accounts for the overhead of inclusion (e.g. signature +verification) as well as a dispatch weight that accounts for the time to execute the transaction. +The total weight is multiplied by a per-weight fee to calculate the transaction's weight fee. + +Tips are an optional transaction fee that users can add to give a transaction higher priority. + +Together, these three fees constitute the inclusion fee. This fee is deducted from the sender's +account prior to transaction execution. A portion of the fee will go to the block producer and the +remainder will go to the [Treasury](learn-treasury.md). At Polkadot's genesis, this is set to 20% +and 80%, respectively. + +## Block Limits and Transaction Priority + +Blocks in Polkadot have both a maximum length (in bytes) and a maximum weight. Block producers will +fill blocks with transactions up to these limits. A portion of each block - currently 25% - is +reserved for critical transactions that are related to the chain's operation. Block producers will +only fill up to 75% of a block with normal transactions. Some examples of operational transactions: + +- Misbehavior reports +- Council operations +- Member operations in an election (e.g. renouncing candidacy) + +Block producers prioritize transactions based on each transaction's total fee. Since a portion of +the fee will go to the block producer, producers will include the transactions with the highest fees +to maximize their reward. + +## Fee Adjustment + +Transaction volume on blockchains is highly irregular, and therefore transaction fees need a +mechanism to adjust. However, users should be able to predict transaction fees. + +Polkadot uses a slow-adjusting fee mechanism with tips to balance these two considerations. In +addition to block _limits_, Polkadot also has a block fullness _target._ Fees increase or decrease +for the next block based on the fullness of the current block relative to the target. The per-weight +fee can change up to 30% in a 24 hour period. This rate captures long-term trends in demand, but not +short-term spikes. To consider short-term spikes, Polkadot uses tips on top of the length and weight +fees. Users can optionally add a tip to the fee to give the transaction a higher priority. + +## Shard Transactions + +The transactions that take place within Polkadot's shards - parachains and parathreads - do not +incur Relay Chain transaction fees. Users of shard applications do not even need to hold DOT tokens, +as each shard has its own economic model and may or may not have a token. There are, however, +situations where shards themselves make transactions on the Relay Chain. + +[Parachains](learn-parachains.md) have a dedicated slot on the Relay Chain for execution, so their +collators do not need to own DOT in order to include blocks. The parachain will make some +transactions itself, for example, opening or closing an [XCMP](learn-crosschain.md) channel, +participating in an [auction](learn-auction.md) to renew its slot, or upgrading its runtime. +Parachains have their own accounts on the Relay Chain and will need to use those funds to issue +transactions on the parachain's behalf. + +[Parathreads](learn-parathreads.md) will also make all the same transactions that a parachain might. +In addition, the collators need to participate in an auction every block to progress their chain. +The collators will need to have DOT to participate in these auctions. + +## Other Resource Limitation Strategies + +Transaction weight must be computable prior to execution, and therefore can only represent fixed +logic. Some transactions warrant limiting resources with other strategies. For example: + +- Bonds: Some transactions, like voting, may require a bond that will be returned or slashed after + an on-chain event. In the voting example, returned at the end of the election or slashed if the + voter tried anything malicious. +- Deposits: Some transactions, like setting an [identity](learn-identity.md) or claiming an index, + use storage space indefinitely. These require a deposit that will be returned if the user decides + to free storage (e.g. clear their ide). +- Burns: A transaction may burn funds internally based on its logic. For example, a transaction may + burn funds from the sender if it creates new storage entries, thus increasing the state size. +- Limits: Some limits are part of the protocol. For example, nominators can only nominate 16 + validators. This limits the complexity of [Phragmén](learn-phragmen.md). + +## Advanced + +This page only covered transactions that come from normal users. If you look at blocks in a block +explorer, though, you may see some "extrinsics" that look different from these transactions. In +Polkadot (and any chain built on Substrate), an extrinsic is a piece of information that comes from +outside the chain. Extrinsics fall into three categories: + +- Signed transactions +- Unsigned transactions +- Inherents + +This page only covered signed transactions, which is the way that most users will interact with +Polkadot. Signed transactions come from an account that has funds, and therefore Polkadot can charge +a transaction fee as a way to prevent spam. + +Unsigned transactions are for special cases where a user needs to submit an extrinsic from a key +pair that does not control funds. For example, when users +[claim their DOT tokens](https://claims.polkadot.network) after genesis, their DOT address doesn't +have any funds yet, so that uses an unsigned transaction. Validators also submit unsigned +transactions in the form of "heartbeat" messages to indicate that they are online. These heartbeats +must be signed by one of the validator's [session keys](learn-keys.md). Session keys never control +funds. Unsigned transactions are only used in special cases because, since Polkadot cannot charge a +fee for them, each one needs its own, custom validation logic. + +Finally, inherents are pieces of information that are not signed or included in the transaction +queue. As such, only the block author can add inherents to a block. Inherents are assumed to be +"true" simply because a sufficiently large number of validators have agreed on them being +reasonable. For example, Polkadot blocks include a timestamp inherent. There is no way to prove that +a timestamp is true the way one proves the desire to send funds with a signature. Rather, validators +accept or reject the block based on how reasonable they find the timestamp. In Polkadot, it must be +within some acceptable range of their own system clocks. + +## Learn More + +- [Web3 Foundation Research](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html#relay-chain-transaction-fees-and-per-block-transaction-limits) +- [Substrate Weights](https://substrate.dev/docs/en/knowledgebase/learn-substrate/weight) +- [Substrate Fees](https://substrate.dev/docs/en/knowledgebase/runtime/fees) +- [Extrinsics](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics) diff --git a/docs/learn/learn-treasury.md b/docs/learn/learn-treasury.md new file mode 100644 index 000000000000..5d0e535cc587 --- /dev/null +++ b/docs/learn/learn-treasury.md @@ -0,0 +1,314 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +slug: ../learn-treasury +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, +[staking inefficiencies](learn-staking.md#inflation), etc. The funds held in the Treasury can be +spent by making a spending proposal that, if approved by the [Council](learn-governance.md#council), +will enter a waiting period before distribution. This waiting period is known as the budget period, +and its duration is subject to [governance](learn-governance.md), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can +without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a +percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% +on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to +[Society](https://guide.kusama.network/docs/maintain-guides-society-kusama) rather than being +burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit of at +least 5% of the proposed spend (see below for variations). This deposit will be slashed if the +proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#council), and how the funds +will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury + with a reward going to the entity that reported the validator (another validator). The reward is + taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the + remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking.md#inflation) is designed to be 10% in the first + year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in + staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to + the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to + the validators as reward. If the staking rate is greater than or less than 50%, then the + validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads.md) participate in a per-block auction for block + inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes + to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is +higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded +otherwise. These values are subject to [governance](learn-governance.md) so they may change in the +future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been +submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, +the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a +proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion +takes place on the following platforms: + +- Many community members participate in discussion in the + [Kusama Element (previously Riot)](https://matrix.to/#/#kusama:matrix.parity.io) chat or + [Polkadot Element](https://matrix.to/#//#polkadot:matrix.parity.io). +- The [Polkassembly](https://polkassembly.io) discussion platform that allows users to log in with + their Web3 address and automatically reads proposals from the chain, turning them into discussion + threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a + vote. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the +recommended way is using official Element channels like {{ polkadot: the +[Polkadot Watercooler](https://matrix.to/#/#polkadot-watercooler:web3.foundation) and +[Polkadot Direction room](https://matrix.to/#/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the +[Kusama Direction room](https://matrix.to/#/#kusama:matrix.parity.io) or the +[Kusama Watercooler](https://matrix.to/#/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps +[website](https://polkadot.js.org/apps). From the website, use either the +[extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then +`proposeSpend` and enter the desired amount and recipient, or use the +[Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](../assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values +mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start +voting on it. + +![Pending proposals](../assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and +purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It +is possible that one motion to accept and another motion to reject are both created. The proportions +to accept and reject Council proposals vary between accept or reject, and possibly depend on which +network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the +other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](../assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can +be suggested by anyone and are supported by members of the Council. Tips do not have any definite +value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not +the direct responsibility of the Council, and at some point the Council and the tippers may be +different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a +tip. During that timeframe, the other members of the tipping group can still issue their tips, but +do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will +be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required +to place them. This bond depends on the tip message length, and a fixed bond constant defined on +chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips +that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. +Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council +is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two +arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a +UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for +why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the +base deposit as set in the chain's parameter list plus the additional deposit per byte contained in +the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it +was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the +tippers. + +Since the tipper group is the same as the Council, the Council must now collectively (but also +independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of +the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the +tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, +the third tipper issued their tip before the end of the closing period, so all three were able to +make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of +the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury +proposals: Council members likely do not have the expertise to make a proper assessment of the +activities described in all proposals. Even if individual Councillors have that expertise, it is +highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts +called Curators: They can be defined as addresses with agency over a portion of the Treasury with +the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks +related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, +whose background and expertise is such that they are capable of determining when the task is +complete. Curators are selected by the Council after the bounty proposal passes, and need to add an +upfront payment to take the position. This deposit can be used to punish them if they act +maliciously. However, if they are successful in their task of getting someone to complete the bounty +work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to +invest their time and expertise in the task: this amount is included in the total value of the +bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid +to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues +the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, +and show project management skills or experience. These recommendations ensure an effective use of +the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of +objectives - that needs to be executed for a predefined treasury amount to be paid out. The +responsibility of assigning a payout address once the specified set of objectives is completed is +delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the +curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to +the payout address and a payout of the curator fee. The delay phase allows the Council to act if any +issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual +information. When a user submits a bounty spending proposal, they will probably need to find an +off-chain way to explain the proposal (any of the available community forums serve this purpose). +[This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) +can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the +curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create +sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on +the dedicated Bounty section under Governance. The development of a robust user interface to view +and manage bounties in the Polkadot Apps is still under development and it will serve Council +members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain +treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a +motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the +governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the +button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the +requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a +motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://matrix.to/#/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: Kusama Direction [channel](https://matrix.to/#/#kusama:matrix.parity.io) :kusama }} in +Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a +short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for +contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the +tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by +amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should +make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty +enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then +`Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is +important to note that those who received a reward after the bounty is completed, must claim the +specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator +closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this +[Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial +mindset, we may consider the possibility that the Council may at some point go rogue and attempt to +steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a +large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. +The burn aims to incentivize the complete spend of all treasury funds at every burn period, so +ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the +case that the burn on the Treasury could be so little that it does not matter - as is the case +currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the +community. Remember, the Council is voted in by the token holders, so they must do some campaigning +or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would +lose their social credibility. Furthermore, members of the Council are usually externally motivated +by the proper operation of the chain. This external motivation is either because they run businesses +that depend on the chain, or they have direct financial gain (through their holdings) of the token +value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council +majority may not be the token majority of the chain. This means that the token majority could vote +to replace the Council if they attempted this attack - or even reverse the treasury spend. They +would do this through a normal referendum. Two, there are time delays to treasury spends. They are +only enacted every spend period. This means that there will be some time to observe this attack is +taking place. The time delay then allows chain participants time to respond. The response may take +the form of governance measures or - in the most extreme cases a liquidation of their holdings and a +migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - + The Rust implementation of the Treasury. + ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/docs/learn/learn-validator.md b/docs/learn/learn-validator.md new file mode 100644 index 000000000000..a093b5bb8237 --- /dev/null +++ b/docs/learn/learn-validator.md @@ -0,0 +1,82 @@ +--- +id: learn-validator +title: Validator +sidebar_label: Validator +slug: ../learn-validator +--- + +Validators secure the [Relay Chain](learn-architecture.md#relay-chain) by staking DOT, validating +proofs from collators and participating in consensus with other validators. + +These participants play a crucial role in adding new blocks to the Relay Chain and, by extension, to +all parachains. This allows parties to complete cross-chain transactions via the Relay Chain. +Parachain validators participate in some form of off-chain consensus, and submit candidate receipts +to the tx pool for a block producer to include on-chain. The Relay Chain validators guarantee that +each parachain follows its unique rules and can pass messages between shards in a trust-free +environment. + +Validators perform two functions: + +1. **Verifying** that the information contained in an assigned set of parachain blocks is valid + (such as the identities of the transacting parties and the subject matter of the contract). +2. **Participating** in the consensus mechanism to produce the Relay Chain blocks based on validity + statements from other validators. Any instances of non-compliance with the consensus algorithms + result in punishment by removal of some or all of the validator’s staked DOT, thereby + discouraging bad actors. Good performance, however, will be rewarded, with validators receiving + block rewards (including transaction fees) in the form of DOT in exchange for their activities. + +## Guides + +- [How to Validate on Polkadot](../maintain/maintain-guides-how-to-validate-polkadot.md) - Guide on how to set + up a validator on the Polkadot live network. +- [Validator Payout Overview](../maintain/maintain-guides-validator-payout.md) - A short overview on how the + validator payout mechanism works. +- [How to run your validator as a systemd process](../maintain/maintain-guides-how-to-systemd.md) - Guide on + running your validator as a `systemd` process so that it will run in the background and start + automatically on reboots. +- [How to Upgrade your Validator](../maintain/maintain-guides-how-to-upgrade.md) - Guide for securely upgrading + your validator when you want to switch to a different machine or begin running the latest version + of client code. +- [How to Use Validator Setup](../maintain/maintain-guides-how-to-use-polkadot-validator-setup.md) - Guide on how + to use Polkadot / Kusama validator setup. + +## Other References + +- [How to run a Polkadot node (Docker)](https://medium.com/@acvlls/setting-up-a-maintain-the-easy-way-3a885283091f) +- [A Serverless Failover Solution for Web3.0 Validator Nodes](https://medium.com/hackernoon/a-serverless-failover-solution-for-web-3-0-validator-nodes-e26b9d24c71d) - + Blog that details how to create a robust failover solution for running validators. +- [VPS list](../maintain/kusama/maintain-guides-how-to-validate-kusama.md##vps-list) +- [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - + A place to chat about being a validator. +- [Slashing Consequences](learn-staking#slashing) - Learn more about slashing consequences for + running a validator node. +- [Why You Should be A Validator on Polkadot and Kusama](https://www.youtube.com/watch?v=0EmP0s6JOW4&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=2) +- [Roles and Responsibilities of a Validator](https://www.youtube.com/watch?v=riVg_Up_fCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=15) +- [Validating on Polkadot](https://www.crowdcast.io/e/validating-on-polkadot) - An explanation of + how to validate on Polkadot, with Joe Petrowski and David Dorgan of Parity Technologies, along + with Tim Ogilvie from Staked. + +## Security / Key Management + +- [Validator Security Overview](https://github.com/w3f/validator-security) + +## Monitoring Tools + +- [PANIC for Polkadot](https://github.com/SimplyVC/panic_polkadot) - A monitoring and alerting + solution for Polkadot / Kusama node +- [Polkadot Telemetry Service](https://telemetry.polkadot.io/#list/Kusama%20CC3) - Network + information, including what nodes are running on a given chain, what software versions they are + running, and sync status. +- [Other Useful Links](https://forum.web3.foundation/t/useful-links-for-validators/20) + +## Validator Stats + +- [HashQuark Staking Strategy](https://polkacube.hashquark.io/#/polkadot/strategy) - The HashQuark + staking strategy dashboard helps you choose the optimal set-up to maximize rewards, and provides + other useful network monitoring tools. +- [Polkastats](https://polkastats.io/) - Polkastats is a cleanly designed dashboard for validator + statistics. +- [YieldScan](https://yieldscan.app/) - Staking yield maximization platform, designed to minimize + effort. +- [Subscan Validators Page](https://kusama.subscan.io/validator) - Displays information on the + current validators - not as tailored for validators as the other sites. diff --git a/docs/learn-video-tutorials.md b/docs/learn/learn-video-tutorials.md similarity index 98% rename from docs/learn-video-tutorials.md rename to docs/learn/learn-video-tutorials.md index 4196690348fc..80a008456465 100644 --- a/docs/learn-video-tutorials.md +++ b/docs/learn/learn-video-tutorials.md @@ -2,9 +2,11 @@ id: learn-video-tutorials title: Video Tutorials sidebar_label: Video Tutorials +slug: ../learn-video-tutorials --- ## Getting Started + - [Polkadot for Beginners](https://www.youtube.com/watch?v=kw8eu2VadFA&list=PLOyWqupZ-WGt-V6azbEcVuuIL_MbmgKhy) - [A walkthrough of Polkadot's UI](https://www.youtube.com/watch?v=mNStMPZjiHM) - [Polkadot Webinars](https://www.youtube.com/watch?v=9B10wX9Mphc&list=PLOyWqupZ-WGsLEJq0sRyvUD-pWuVwA5yg) @@ -13,6 +15,7 @@ sidebar_label: Video Tutorials ## Tutorials ### Accounts, Transfers and Staking + - [How to create Polkadot accounts](https://www.youtube.com/watch?v=hhUZ40ZWqkE) - [understanding Accounts and Keys](https://www.youtube.com/watch?v=zhfccevPqWI) - [How to Stake DOT/KSM with Ledger](https://www.youtube.com/watch?v=VN4S8MofEW8) @@ -22,20 +25,24 @@ sidebar_label: Video Tutorials - [Picking validators to Nominate (Stake)](https://youtu.be/ZMzhM1m4I-k) ### Governance + - [Voting on Referenda on Polkadot and Kusama](https://www.youtube.com/watch?v=BkbhhlsezGA) - [Voting for Polkadot and Kusama council](https://www.youtube.com/watch?v=837Vv3gdRzI) ### For validators + - [Validator Resouces](https://www.youtube.com/playlist?list=PLOyWqupZ-WGsM3O0t5iWgvMkivHnwE1C_) - [Why should you be a Validator](https://youtu.be/0EmP0s6JOW4) - [How to upgrade your node](https://youtu.be/5LtcdBR9F40) - [Roles and Responsibilities of a Validator](https://youtu.be/riVg_Up_fCg) ### Technical Content + - [Rust, Substrate and Polkadot](https://youtu.be/aVW_eG-IH7o) - [Instroduction to Substrate](https://youtu.be/-6BBIr-DmI4) ## Past and Ongoing Events + - [Encode Polkadot Club 2021](https://www.youtube.com/playlist?list=PLOyWqupZ-WGvgdDcF-dW4RVEoeFZiZmQc) - [Polkadot Decoded 2021](https://www.youtube.com/playlist?list=PLOyWqupZ-WGuAB8z_PkZD6f-IA6CUONFb) - [Polkadot Buildathon India 2021](https://www.youtube.com/playlist?list=PLOyWqupZ-WGtnuyctbnGPPyt6DSSXH1h3) diff --git a/docs/learn-wasm.md b/docs/learn/learn-wasm.md similarity index 99% rename from docs/learn-wasm.md rename to docs/learn/learn-wasm.md index a1a43adb2e88..14a806e04429 100644 --- a/docs/learn-wasm.md +++ b/docs/learn/learn-wasm.md @@ -2,6 +2,7 @@ id: learn-wasm title: WebAssembly (Wasm) sidebar_label: WebAssembly (Wasm) +slug: ../learn-wasm --- WebAssembly is used in Polkadot and Substrate as the compilation target for the runtime. diff --git a/docs/maintain-errors.md b/docs/maintain-errors.md deleted file mode 100644 index 2418d2d4c041..000000000000 --- a/docs/maintain-errors.md +++ /dev/null @@ -1,305 +0,0 @@ ---- -id: maintain-errors -title: Errors and How to Resolve Them -sidebar_label: Resolving Errors ---- - - - -Errors in Substrate-based chains are usually accompanied by descriptive messages. However, to read -these messages, a tool parsing the blockchain data needs to request _chain metadata_ from a node. -That metadata explains how to read the messages. One such tool with a built-in parser for chain -metadata is the [Polkadot-JS Apps UI](https://polkadot.js.org/apps). - -If this page does not answer your question, try searching for your problem at the -[Polkadot Knowledge Base](https://support.polkadot.network/) for more information on troubleshooting -your issue. - -## PolkadotJS Apps Explorer - -Here's how to find out the detailed error description through Polkadot-JS Apps. - -A typical failed transactions looks something like this: - -![Error while sending a transaction](assets/errors/01.jpg) - -The image displays only the error name as defined in the code, not its error message. Despite this -error being rather self-explanatory, let's find its details. - -In the [explorer tab](https://polkadot.js.org/apps/#/explorer), find the block in which this failure -occured. Then, expand the `system.ExtrinsicFailed` frame: - -![Error described](assets/errors/02.jpg) - -Notice how the `details` field contains a human-readable description of the error. Most errors will -have this, if looked up this way. - -[This block](https://polkadot.js.org/apps/#/explorer/query/0xa10104ed21dfe409c7871a975155766c5dd97e1e2ac7faf3c90f1f8dca89104b) -is a live example of the above. - -If you cannot look up the error this way, or there is no message in the `details` field, consult the -table below. - -## Polkascan and Subscan - -Polkascan and Subscan show the `ExtrinsicFailed` event when a transaction does not succeed -([example](https://polkascan.io/polkadot/event/2836233-3)). This event gives us the `error` and -`index` indices of the error but does not give us a nice message to understand what it means. We -will look up the error in the codebase ourselves to understand what went wrong. - -First, we should understand that the `index` number is the index of the pallet in the runtime from -which the error originated. The `error` is likewise the index of that pallet's errors which is the -exact one we're looking for. Both of these indices start counting from 0. - -For example, if `index` is 5 and `error` is 3, as in the example linked above, we need to look at -the runtime for the fourth error (index 3) in the sixth pallet (index 5). - -By looking at the -[runtime code](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L965) -we see that the pallet at index 5 is -[Balances](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L981). Now -we will check the Balances pallet's code which is hosted in the Substrate repository, and look for -the fourth error in the Error enum. According to -[its source](https://github.com/paritytech/substrate/blob/master/frame/balances/src/lib.rs#L396) the -error that we got is -[InsufficientBalance](https://github.com/paritytech/substrate/blob/master/frame/balances/src/lib.rs#L402) -or in other words "Balance too low to send value". - -## Common Errors - -The table below lists the most commonly encountered errors and ways to resolve them. - -| Error | Description | Solution | -| ------------------ | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| BadOrigin | You are not allowed to do this operation, e.g. trying to create a council motion with a non-council account. | Either switch to an account that has the necessary permissions, or check if the operation you're trying to execute is permitted at all (e.g. calling `system.setCode` to do a runtime upgrade directly, without voting). | -| BadProof | The transaction's signature seems invalid. | It's possible that the node you're connected to is following an obsolete fork - trying again after it catches up usually resolves the issue. To check for bigger problems, inspect the last finalized and current best block of the node you're connected to and compare the values to chain stats exposed by other nodes - are they in sync? If not, try connecting to a different node. | -| Future | Transaction nonce too high, i.e. it's "from the future". | Reduce the nonce to +1 of current nonce. Check current nonce by inspecting the address you're using to send the transaction. | -| Stale | Transaction nonce too low. | Increase the nonce to +1 of current nonce. Check current nonce by inspecting the address you're using to send the transaction. | -| ExhaustsResources | There aren't enough resources left in the current block to submit this transaction. | Try again in the next block. | -| Payment | Unable to pay for TX fee. | You might not have enough free balance to cover the fee this transaction would incur. | -| Temporarily banned | The transaction is temporarily banned. | The tx is already in pool. Either try on a different node, or wait to see if the initial transaction goes through. | - -## Error Table - -The below table is a reference to the errors that exists in Polkadot. It is generated from the -runtime's metadata. - -| Pallet | Error | Documentation | -| ----------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -| System (0) | | | -| | InvalidSpecName (0) | The name of specification does not match between the current runtime and the new runtime. | -| | SpecVersionNeedsToIncrease (1) | The specification version is not allowed to decrease between the current runtime and the new runtime. | -| | FailedToExtractRuntimeVersion (2) | Failed to extract the runtime version from the new runtime. Either calling `Core_version` or decoding `RuntimeVersion` failed. | -| | NonDefaultComposite (3) | Suicide called when the account has non-default composite data. | -| | NonZeroRefCount (4) | There is a non-zero reference count preventing the account from being purged. | -| Scheduler (1) | | | -| | FailedToSchedule (0) | Failed to schedule a call | -| | NotFound (1) | Cannot find the scheduled call. | -| | TargetBlockNumberInPast (2) | Given target block number is in the past. | -| | RescheduleNoChange (3) | Reschedule failed because it does not change scheduled time. | -| Balances (5) | | | -| | VestingBalance (0) | Vesting balance too high to send value | -| | LiquidityRestrictions (1) | Account liquidity restrictions prevent withdrawal | -| | Overflow (2) | Got an overflow after adding | -| | InsufficientBalance (3) | Balance too low to send value | -| | ExistentialDeposit (4) | Value too low to create account due to existential deposit | -| | KeepAlive (5) | Transfer/payment would kill account | -| | ExistingVestingSchedule (6) | A vesting schedule already exists for this account | -| | DeadAccount (7) | Beneficiary account must pre-exist | -| Authorship (6) | | | -| | InvalidUncleParent (0) | The uncle parent not in the chain. | -| | UnclesAlreadySet (1) | Uncles already set in the block. | -| | TooManyUncles (2) | Too many uncles. | -| | GenesisUncle (3) | The uncle is genesis. | -| | TooHighUncle (4) | The uncle is too high in chain. | -| | UncleAlreadyIncluded (5) | The uncle is already included. | -| | OldUncle (6) | The uncle isn't recent enough to be included. | -| Staking (7) | | | -| | NotController (0) | Not a controller account. | -| | NotStash (1) | Not a stash account. | -| | AlreadyBonded (2) | Stash is already bonded. | -| | AlreadyPaired (3) | Controller is already paired. | -| | EmptyTargets (4) | Targets cannot be empty. | -| | DuplicateIndex (5) | Duplicate index. | -| | InvalidSlashIndex (6) | Slash record index out of bounds. | -| | InsufficientValue (7) | Can not bond with value less than minimum balance. | -| | NoMoreChunks (8) | Can not schedule more unlock chunks. | -| | NoUnlockChunk (9) | Can not rebond without unlocking chunks. | -| | FundedTarget (10) | Attempting to target a stash that still has funds. | -| | InvalidEraToReward (11) | Invalid era to reward. | -| | InvalidNumberOfNominations (12) | Invalid number of nominations. | -| | NotSortedAndUnique (13) | Items are not sorted and unique. | -| | AlreadyClaimed (14) | Rewards for this era have already been claimed for this validator. | -| | OffchainElectionEarlySubmission (15) | The submitted result is received out of the open window. | -| | OffchainElectionWeakSubmission (16) | The submitted result is not as good as the one stored on chain. | -| | SnapshotUnavailable (17) | The snapshot data of the current window is missing. | -| | OffchainElectionBogusWinnerCount (18) | Incorrect number of winners were presented. | -| | OffchainElectionBogusWinner (19) | One of the submitted winners is not an active candidate on chain (index is out of range in snapshot). | -| | OffchainElectionBogusCompact (20) | Error while building the assignment type from the compact. This can happen if an index is invalid, or if the weights _overflow_. | -| | OffchainElectionBogusNominator (21) | One of the submitted nominators is not an active nominator on chain. | -| | OffchainElectionBogusNomination (22) | One of the submitted nominators has an edge to which they have not voted on chain. | -| | OffchainElectionSlashedNomination (23) | One of the submitted nominators has an edge which is submitted before the last non-zero slash of the target. | -| | OffchainElectionBogusSelfVote (24) | A self vote must only be originated from a validator to ONLY themselves. | -| | OffchainElectionBogusEdge (25) | The submitted result has unknown edges that are not among the presented winners. | -| | OffchainElectionBogusScore (26) | The claimed score does not match with the one computed from the data. | -| | OffchainElectionBogusElectionSize (27) | The election size is invalid. | -| | CallNotAllowed (28) | The call is not allowed at the given time due to restrictions of election period. | -| | IncorrectHistoryDepth (29) | Incorrect previous history depth input provided. | -| | IncorrectSlashingSpans (30) | Incorrect number of slashing spans provided. | -| Session (9) | | | -| | InvalidProof (0) | Invalid ownership proof. | -| | NoAssociatedValidatorId (1) | No associated validator ID for account. | -| | DuplicatedKey (2) | Registered duplicate key. | -| | NoKeys (3) | No keys are associated with this account. | -| Grandpa (11) | | | -| | PauseFailed (0) | Attempt to signal GRANDPA pause when the authority set isn't live (either paused or already pending pause). | -| | ResumeFailed (1) | Attempt to signal GRANDPA resume when the authority set isn't paused (either live or already pending resume). | -| | ChangePending (2) | Attempt to signal GRANDPA change with one already pending. | -| | TooSoon (3) | Cannot signal forced change so soon after last. | -| | InvalidKeyOwnershipProof (4) | A key ownership proof provided as part of an equivocation report is invalid. | -| | InvalidEquivocationProof (5) | An equivocation proof provided as part of an equivocation report is invalid. | -| | DuplicateOffenceReport (6) | A given equivocation report is valid but already previously reported. | -| ImOnline (12) | | | -| | InvalidKey (0) | Non existent public key. | -| | DuplicatedHeartbeat (1) | Duplicated heartbeat. | -| Democracy (14) | | | -| | ValueLow (0) | Value too low | -| | ProposalMissing (1) | Proposal does not exist | -| | BadIndex (2) | Unknown index | -| | AlreadyCanceled (3) | Cannot cancel the same proposal twice | -| | DuplicateProposal (4) | Proposal already made | -| | ProposalBlacklisted (5) | Proposal still blacklisted | -| | NotSimpleMajority (6) | Next external proposal not simple majority | -| | InvalidHash (7) | Invalid hash | -| | NoProposal (8) | No external proposal | -| | AlreadyVetoed (9) | Identity may not veto a proposal twice | -| | NotDelegated (10) | Not delegated | -| | DuplicatePreimage (11) | Preimage already noted | -| | NotImminent (12) | Not imminent | -| | TooEarly (13) | Too early | -| | Imminent (14) | Imminent | -| | PreimageMissing (15) | Preimage not found | -| | ReferendumInvalid (16) | Vote given for invalid referendum | -| | PreimageInvalid (17) | Invalid preimage | -| | NoneWaiting (18) | No proposals waiting | -| | NotLocked (19) | The target account does not have a lock. | -| | NotExpired (20) | The lock on the account to be unlocked has not yet expired. | -| | NotVoter (21) | The given account did not vote on the referendum. | -| | NoPermission (22) | The actor has no permission to conduct the action. | -| | AlreadyDelegating (23) | The account is already delegating. | -| | Overflow (24) | An unexpected integer overflow occurred. | -| | Underflow (25) | An unexpected integer underflow occurred. | -| | InsufficientFunds (26) | Too high a balance was provided that the account cannot afford. | -| | NotDelegating (27) | The account is not currently delegating. | -| | VotesExist (28) | The account currently has votes attached to it and the operation cannot succeed until these are removed, either through `unvote` or `reap_vote`. | -| | InstantNotAllowed (29) | The instant referendum origin is currently disallowed. | -| | Nonsense (30) | Delegation to oneself makes no sense. | -| | WrongUpperBound (31) | Invalid upper bound. | -| | MaxVotesReached (32) | Maximum number of votes reached. | -| | InvalidWitness (33) | The provided witness data is wrong. | -| | TooManyProposals (34) | Maximum number of proposals reached. | -| Council (15) | | | -| | NotMember (0) | Account is not a member | -| | DuplicateProposal (1) | Duplicate proposals not allowed | -| | ProposalMissing (2) | Proposal must exist | -| | WrongIndex (3) | Mismatched index | -| | DuplicateVote (4) | Duplicate vote ignored | -| | AlreadyInitialized (5) | Members are already initialized! | -| | TooEarly (6) | The close call was made too early, before the end of the voting. | -| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | -| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | -| | WrongProposalLength (9) | The given length bound for the proposal was too low. | -| TechnicalCommittee (16) | | | -| | NotMember (0) | Account is not a member | -| | DuplicateProposal (1) | Duplicate proposals not allowed | -| | ProposalMissing (2) | Proposal must exist | -| | WrongIndex (3) | Mismatched index | -| | DuplicateVote (4) | Duplicate vote ignored | -| | AlreadyInitialized (5) | Members are already initialized! | -| | TooEarly (6) | The close call was made too early, before the end of the voting. | -| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | -| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | -| | WrongProposalLength (9) | The given length bound for the proposal was too low. | -| ElectionsPhragmen (17) | | | -| | UnableToVote (0) | Cannot vote when no candidates or members exist. | -| | NoVotes (1) | Must vote for at least one candidate. | -| | TooManyVotes (2) | Cannot vote more than candidates. | -| | MaximumVotesExceeded (3) | Cannot vote more than maximum allowed. | -| | LowBalance (4) | Cannot vote with stake less than minimum balance. | -| | UnableToPayBond (5) | Voter can not pay voting bond. | -| | MustBeVoter (6) | Must be a voter. | -| | ReportSelf (7) | Cannot report self. | -| | DuplicatedCandidate (8) | Duplicated candidate submission. | -| | MemberSubmit (9) | Member cannot re-submit candidacy. | -| | RunnerSubmit (10) | Runner cannot re-submit candidacy. | -| | InsufficientCandidateFunds (11) | Candidate does not have enough funds. | -| | NotMember (12) | Not a member. | -| | InvalidCandidateCount (13) | The provided count of number of candidates is incorrect. | -| | InvalidVoteCount (14) | The provided count of number of votes is incorrect. | -| | InvalidRenouncing (15) | The renouncing origin presented a wrong `Renouncing` parameter. | -| | InvalidReplacement (16) | Prediction regarding replacement after member removal is wrong. | -| Treasury (19) | | | -| | InsufficientProposersBalance (0) | Proposer's balance is too low. | -| | InvalidIndex (1) | No proposal or bounty at that index. | -| | ReasonTooBig (2) | The reason given is just too big. | -| | AlreadyKnown (3) | The tip was already found/started. | -| | UnknownTip (4) | The tip hash is unknown. | -| | NotFinder (5) | The account attempting to retract the tip is not the finder of the tip. | -| | StillOpen (6) | The tip cannot be claimed/closed because there are not enough tippers yet. | -| | Premature (7) | The tip cannot be claimed/closed because it's still in the countdown period. | -| | UnexpectedStatus (8) | The bounty status is unexpected. | -| | RequireCurator (9) | Require bounty curator. | -| | InvalidValue (10) | Invalid bounty value. | -| | InvalidFee (11) | Invalid bounty fee. | -| | PendingPayout (12) | A bounty payout is pending. To cancel the bounty, you must unassign and slash the curator. | -| Claims (24) | | | -| | InvalidEthereumSignature (0) | Invalid Ethereum signature. | -| | SignerHasNoClaim (1) | Ethereum address has no claim. | -| | SenderHasNoClaim (2) | Account ID sending tx has no claim. | -| | PotUnderflow (3) | There's not enough in the pot to pay out some unvested amount. Generally implies a logic error. | -| | InvalidStatement (4) | A needed statement was not included. | -| | VestedBalanceExists (5) | The account already has a vested balance. | -| Vesting (25) | | | -| | NotVesting (0) | The account given is not vesting. | -| | ExistingVestingSchedule (1) | An existing vesting schedule already exists for this account that cannot be clobbered. | -| | AmountLow (2) | Amount being transferred is too low to create a vesting schedule. | -| Identity (28) | | | -| | TooManySubAccounts (0) | Too many subs-accounts. | -| | NotFound (1) | Account isn't found. | -| | NotNamed (2) | Account isn't named. | -| | EmptyIndex (3) | Empty index. | -| | FeeChanged (4) | Fee is changed. | -| | NoIdentity (5) | No identity found. | -| | StickyJudgement (6) | Sticky judgement. | -| | JudgementGiven (7) | Judgement given. | -| | InvalidJudgement (8) | Invalid judgement. | -| | InvalidIndex (9) | The index is invalid. | -| | InvalidTarget (10) | The target is invalid. | -| | TooManyFields (11) | Too many additional fields. | -| | TooManyRegistrars (12) | Maximum amount of registrars reached. Cannot add any more. | -| | AlreadyClaimed (13) | Account ID is already named. | -| | NotSub (14) | Sender is not a sub-account. | -| | NotOwned (15) | Sub-account isn't owned by sender. | -| Proxy (29) | | | -| | TooMany (0) | There are too many proxies registered or too many announcements pending. | -| | NotFound (1) | Proxy registration not found. | -| | NotProxy (2) | Sender is not a proxy of the account to be proxied. | -| | Unproxyable (3) | A call which is incompatible with the proxy type's filter was attempted. | -| | Duplicate (4) | Account is already a proxy. | -| | NoPermission (5) | Call may not be made by proxy because it may escalate its privileges. | -| | Unannounced (6) | Announcement, if made at all, was made too recently. | -| Multisig (30) | | | -| | MinimumThreshold (0) | Threshold must be 2 or greater. | -| | AlreadyApproved (1) | Call is already approved by this signatory. | -| | NoApprovalsNeeded (2) | Call doesn't need any (more) approvals. | -| | TooFewSignatories (3) | There are too few signatories in the list. | -| | TooManySignatories (4) | There are too many signatories in the list. | -| | SignatoriesOutOfOrder (5) | The signatories were provided out of order; they should be ordered. | -| | SenderInSignatories (6) | The sender was contained in the other signatories; it shouldn't be. | -| | NotFound (7) | Multisig operation not found when attempting to cancel. | -| | NotOwner (8) | Only the account that originally created the multisig is able to cancel it. | -| | NoTimepoint (9) | No timepoint was given, yet the multisig operation is already underway. | -| | WrongTimepoint (10) | A different timepoint was given to the multisig operation that is underway. | -| | UnexpectedTimepoint (11) | A timepoint was given, yet no multisig operation is underway. | -| | WeightTooLow (12) | The maximum weight information provided was too low. | -| | AlreadyStored (13) | The data to be stored is already stored. | diff --git a/docs/maintain-guides-how-to-join-council.md b/docs/maintain-guides-how-to-join-council.md deleted file mode 100644 index 7813fe17ff0e..000000000000 --- a/docs/maintain-guides-how-to-join-council.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: maintain-guides-how-to-join-council -title: Join the Council -sidebar_label: Join the Council ---- - - - -The council is an elected body of on-chain accounts that are intended to represent the passive -stakeholders of Polkadot and/or Kusama. The council has two major tasks in governance: proposing -referenda and vetoing dangerous or malicious referenda. For more information on the council, see the -[governance page](learn-governance.md#council). This guide will walk you through entering your -candidacy to the council. - -## Submit Candidacy - -Submitting your candidacy for the council requires a small bond of DOT / KSM. Unless your candidacy -wins, the bond will be forfeited. You can receive your bond back if you manually renounce your -candidacy before losing. Runners-up are selected after every round and are reserved members in case -one of the winners gets forcefully removed. - -> Currently the bond for submitting a council candidacy on Polkadot is 100 DOT, and 0.0033 KSM on -> Kusama. - -It is a good idea to announce your council intention before submitting your candidacy so that your -supporters will know when they can start to vote for you. You can also vote for yourself in case no -one else does. - -Go to [Polkadot Apps Dashboard](https://polkadot.js.org/apps) and navigate to the "Council" tab. -Click the button on the right that says "Submit Candidacy." - -![submit candidancy button](assets/council/polkadotjs_submit_candidancy.png) - -After making the transaction, you will see your account appear underneath the row "Candidates." - -![candidates list](assets/council/polkadotjs_candidates.png) - -It is a good idea now to lead by example and give yourself a vote. - -## Voting on Candidates - -Next to the button to submit candidacy is another button titled "Vote." You will click this button -to make a vote for yourself (optional). - -![voting button on UI](assets/council/polkadotjs_vote_button.png) - -The council uses [Phragmén](learn-phragmen.md) approval voting, which is also used in the validator -elections. This means that you can choose up to 16 distinct candidates to vote for and your stake -will equalize between them. For this guide, choose to approve your own candidacy by clicking on the -switch next to your account and changing it to say "Aye." - -![voting pop up on UI](assets/council/polkadotjs_voting.png) - -## Winning - -If you are one of the lucky ones to win a council election you will see your account move underneath -the row "Members". - -![council members list](assets/council/polkadotjs_council_members.png) - -Now you are able to participate on the council by making motions or voting proposals. To join in on -the active discussions, join the -[Polkadot Direction channel](https://matrix.to/#/#polkadot-direction:matrix.parity.io). diff --git a/docs/maintain-guides-how-to-monitor-your-node.md b/docs/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3ce3c1173fee..000000000000 --- a/docs/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,521 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - - - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with -[Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers -to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used -to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` -from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check -the latest release by going to their GitHub repository under the -[releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.26.0.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the -license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named -`prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and -`scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` - controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server - to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor -itself. As we want to have more precise information about the state of the Prometheus server we -reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and -`targets` determine where the exporters are running. The second exporter is capturing the data from -your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running -`promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the -`prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your -server is set up properly. - -```bash -level=info ts=2021-04-16T19:02:20.167Z caller=main.go:380 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2021-04-16T19:02:20.167Z caller=main.go:418 msg="Starting Prometheus" version="(version=2.26.0, branch=HEAD, revision=3cafc58827d1ebd1a67749f88be4218f0bab3d8d)" -level=info ts=2021-04-16T19:02:20.167Z caller=main.go:423 build_context="(go=go1.16.2, user=root@a67cafebe6d0, date=20210331-11:56:23)" -level=info ts=2021-04-16T19:02:20.167Z caller=main.go:424 host_details="(Linux 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 ubuntu2004 (none))" -level=info ts=2021-04-16T19:02:20.167Z caller=main.go:425 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2021-04-16T19:02:20.167Z caller=main.go:426 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2021-04-16T19:02:20.169Z caller=web.go:540 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2021-04-16T19:02:20.170Z caller=main.go:795 msg="Starting TSDB ..." -level=info ts=2021-04-16T19:02:20.171Z caller=tls_config.go:191 component=web msg="TLS is disabled." http2=false -level=info ts=2021-04-16T19:02:20.174Z caller=head.go:696 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2021-04-16T19:02:20.175Z caller=head.go:710 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=1.391446ms -level=info ts=2021-04-16T19:02:20.175Z caller=head.go:716 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2021-04-16T19:02:20.178Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=4 -level=info ts=2021-04-16T19:02:20.193Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=1 maxSegment=4 -level=info ts=2021-04-16T19:02:20.221Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=2 maxSegment=4 -level=info ts=2021-04-16T19:02:20.224Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=3 maxSegment=4 -level=info ts=2021-04-16T19:02:20.229Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=4 maxSegment=4 -level=info ts=2021-04-16T19:02:20.229Z caller=head.go:773 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=43.716µs wal_replay_duration=53.973285ms total_replay_duration=55.445308ms -level=info ts=2021-04-16T19:02:20.233Z caller=main.go:815 fs_type=EXT4_SUPER_MAGIC -level=info ts=2021-04-16T19:02:20.233Z caller=main.go:818 msg="TSDB started" -level=info ts=2021-04-16T19:02:20.233Z caller=main.go:944 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2021-04-16T19:02:20.234Z caller=main.go:975 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml totalDuration=824.115µs remote_storage=3.131µs web_handler=401ns query_engine=1.056µs scrape=236.454µs scrape_sd=45.432µs notify=723ns notify_sd=2.61µs rules=956ns -level=info ts=2021-04-16T19:02:20.234Z caller=main.go:767 msg="Server is ready to receive web requests." - -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus -interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create -a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that -it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by -re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the -following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.5.4_amd64.deb -sudo dpkg -i grafana_7.5.4_amd64.deb -``` - -If everything is fine, configure Grafana to auto-start on boot and then start the service. - -```bash -sudo systemctl daemon-reload -sudo systemctl enable grafana-server -sudo systemctl start grafana-server -``` - -You can now access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and -password is admin/admin. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file -> `/usr/share/grafana/conf/defaults.ini` with a command like -> `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something -> else. Then restart grafana with `sudo systemctl restart grafana-server`. - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click -`Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left -and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made -public. You can check what other dashboards are available via -[https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we -use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under -the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then -click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, -you should be able to monitor your node's performance such as the current block height, CPU, memory -usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or -notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or -others. In this guide, we will show you how to configure the email notifications using Gmail if your -node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -```bash -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an -`app password` in your Gmail account. For details, click -[here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted -in the previous command, but that is not of our use. We will create our `alertmanager.yml` file -under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to -change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the -`YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the -command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && sudo systemctl enable alertmanager && sudo systemctl start alertmanager && sudo systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To -install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo systemctl restart grafana-server -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the -top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is -used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. -Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following -config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all -the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert -will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 -minutes, an email notification will be sent. If you would like to learn more about the details of -the rule defining, go -[here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other -interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -```bash -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -```bash -sudo -u prometheus promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -```bash -sudo systemctl restart prometheus && sudo systemctl restart alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail -like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/docs/maintain-guides-how-to-unbond.md b/docs/maintain-guides-how-to-unbond.md deleted file mode 100644 index 336f6a3b47a7..000000000000 --- a/docs/maintain-guides-how-to-unbond.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: maintain-guides-how-to-unbond -title: Unbonding and Rebonding -sidebar_label: Unbonding and Rebonding ---- - -The following describes how to stop nominating or validating and retrieve your stake. Please note -that all networks on which you can nominate have a delayed exit period, called the _unbonding -period_, which serves as a cooldown. You will not be able to transfer your tokens before this period -has elapsed, and you will not receive any staking rewards during this period (as you are not -nominating any validators). - -### Step 1: Stop Nominating - -On the [Polkadot-JS Apps][] navigate to the "Staking" tab. - -On this tab click on the "Account Actions" tab at the top of the screen. - -Here, click "Stop Nominating" or "Stop Validating" (depending on your role) on an account you're -staking with and would like to free the funds for. This will "chill" the tokens. - -![Stop Nominating Button](assets/NPoS/unbond1.png) - -After you confirm this transaction, your tokens will remain _bonded_. This means they stay ready to -be distributed among nominees or used as validator self-stake again. To actually withdraw them, you -need to unbond. - -### Step 2: Unbonding an amount - -To unbond the amount, click the three dots next to the account you want to unbond tokens for, and -select "Unbond funds". - -![Unbonding](assets/NPoS/unbond2.png) - -Select the amount you wish to unbond and click Unbond, then confirm the transaction. If successful, -your balance will show as "unbonding" with an indicator of how many more blocks remain until the -amount is fully unlocked. - -This duration varies depending on the network you're on and will typically be four times as fast on -Kusama as it is on Polkadot. The unbounding period is 28 days on Polkadot, and 7 on Kusama. - -Once this process is complete, you will have to issue another, final transaction: Withdraw Unbonded, -which will be available in the same pop-up. You can also check how long you have to wait in order to -withdraw your stake in the -[Accounts](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/accounts) page by -expanding your account balance. There is a tiny icon beside the word "unbonding" that will -eventually become an unlock icon once the remaning blocks get passed. - -Then, you can click that icon directly to submit the withdraw transaction. Finally, your -transferrable balance will increase by the amount of tokens you've just fully unbonded. - -## Rebonding before the end of the unbonding period - -If you want to rebond your tokens before the unbonding period is over, you can do this by issuing a -`rebond` extrinsic. This allows you to bond your tokens that are still locked without waiting until -the end of the unbonding period. - -In order to do this, you will need to issue an extrinsic manually from [Polkadot-JS Apps][]. - -Go to the "Extrinsics" option that's located in the "Developer" dropdown in the top menu. - -![extrinsic menu](assets/rebonding-1.png) - -Select the "staking" pallet and the "rebond" extrinsic. Enter the amount of tokens that are -currently locked in unbonding that you want to rebond. Then click "Submit Transaction". - -![confirm](assets/rebonding-2.png) - -Confirm the transaction in the next pop-up. Once the transaction is included in the next block your -tokens will be rebonded again and you can start staking with them. - -[polkadot-js apps]: https://polkadot.js.org/apps diff --git a/docs/maintain-guides-how-to-upgrade.md b/docs/maintain-guides-how-to-upgrade.md deleted file mode 100644 index 15eaf4dd68c3..000000000000 --- a/docs/maintain-guides-how-to-upgrade.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -id: maintain-guides-how-to-upgrade -title: How to Upgrade Your Validator -sidebar_label: How to Upgrade Your Validator ---- - -Validators perform critical functions for the network, and as such, have strict uptime requirements. -Validators may have to go offline for periods of time to upgrade the client software or the host -machine. Usually, standard upgrades will only require you to stop your server, replace the binary -and spin it up again. Validators may also need to perform maintenance, such as resizing a disk, -where you cannot continue running the node on the current server. This guide will walk you through -upgrading your machine and keeping your validator online. - -The process can take several hours, so make sure you understand the instructions first and plan -accordingly. - -> Note: keep an eye out on new releases from the community and upgrade/downgrade accordingly. - -## Key Components - -### Session Keys - -Session keys are stored in the client and used to sign validator operations. They are what link your -validator node to your Controller account. You cannot change them mid-Session. - -[More info about keys in Polkadot.](learn-keys.md) - -### Database - -Validators keep a database with all of their votes. If two machines have the same Session keys but -different databases, they risk equivocating. For this reason, we will generate new Session keys each -time we change machines. - -[More info about equivocation.](learn-staking.md/#slashing) - -## Steps - -You will need to start a second validator to operate while you upgrade your primary. Throughout -these steps, we will refer to the validator that you are upgrading as "Validator A" and the second -one as "Validator B." - -### Session `N` - -1. Start a second node. Once it is synced, use the `--validator` flag. This is "Validator B." -2. Generate Session keys in Validator B. -3. Submit a `set_key` extrinsic from your Controller account with your new Session keys. -4. Take note of the Session that this extrinsic was executed in. - -**It is imperative that your Validator A keep running in this Session.** `set_key` only takes effect -in the next Session. - -### Session `N+1` - -Validator B is now acting as your validator. You can safely take Validator A offline. See note at -bottom. - -1. Stop Validator A. -1. Perform your system or client upgrade. -2. Start Validator A and sync the database. -3. Generate new Session keys in Validator A. -4. Submit a `set_key` extrinsic from your Controller account with your new Session keys for - Validator A. -5. Take note of the Session that this extrinsic was executed in. - -**Again, it is imperative that Validator B keep running until the next Session.** - -Once the Session changes, Validator A will take over. You can safely stop Validator B. - -**NOTE:** To verify that the Session has changed, make sure that a block in the new Session is -finalized. You should see log messages like this to indicate the change: - -``` -2019-10-28 21:44:13 Applying authority set change scheduled at block #450092 -2019-10-28 21:44:13 Applying GRANDPA set change to new set with 20 authorities -``` diff --git a/docs/maintain-guides-how-to-validate-kusama.md b/docs/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index caf5b0dd743d..000000000000 --- a/docs/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,525 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not -only your own stake, but also the stake of your current nominators. If you make a mistake and get -slashed, your money and your reputation will be at risk. However, running a validator can also be -very rewarding, knowing that you contribute to the security of a decentralized network while growing -your stash. - -**Warning:** It is highly recommended that you have significant system administration experience -before attempting to run your own validator. - -Since security is so important to running a successful validator, you should take a look at the -[validator setup](maintain-guides-secure-validator.md) information to make you understand the -factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a -[reference implementation for a validator set-up](https://github.com/w3f/polkadot-validator-setup) -that you can use by deploying yourself. As you progress in your journey as a validator, you will -likely want to use this repository as a _starting point_ for your own modifications and -customizations. - -If you need help, please reach out on the -[Kusama validator chat](https://app.element.io/#/room/#KusamaValidatorLounge:polkadot.builders) on -Matrix. The team and other validators are there to help answer questions and provide experience. You -can join directly in your web browser (link above) or using a client such as Element (formerly -Riot.im) using [this link](https://matrix.to/#/#KusamaValidatorLounge:polkadot.builders). - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed -[here](faq.md#What-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator-?). -Validators are elected based on [Phragmén's algorithm](learn-phragmen.md). To be elected into the -set, you need a minimum stake behind your validator. This stake can come from yourself or from -[nominators](learn-nominator.md). This means that as a minimum, you will need enough KSM to set up -Stash and Controller [accounts](learn-keys.md) with the existential deposit, plus a little extra for -transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an -insecure or improper setup may result in loss of KSM tokens! If you are not confident in your -ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node -instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may -choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are -comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be -similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that -validators run at least the standard hardware in order to ensure they are able to process all blocks -in time. The following are not _minimum requirements_ but if you decide to run with less than this -beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see -[here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. - Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to - be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a -validator, however you should be aware that if you are using less you may need to toggle some extra -optimizations in order to be equal to other validators that are running the standard. - -### Node Prerequisites: Install Rust and Dependencies - -Once you choose your cloud service provider and set-up your new server, the first thing you will do -is install Rust. - -If you have never installed Rust, you should do this first. - -If you have already installed Rust, run the following command to make sure you are using the latest -version. - -```sh -rustup update -``` - -If not, this command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -s -- -y -``` - -> If you do not have "curl" installed, run "sudo apt install curl" - -To configure your shell, run the following command. - -```sh -source $HOME/.cargo/env -``` - -Verify your installation. - -```sh -rustc --version -``` - -Finally, run this command to install the necessary dependencies for compiling and running the -Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the -following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to -synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all -the systems within the network. Currently it is required that validators' local clocks stay -reasonably in sync, so you should be running NTP or a similar service. You can check whether you -have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar -message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to -verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. -> If the clock is out of sync (even by a small amount), the blocks the validator produces may not -> get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but -> zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the -[paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source -code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, -but you should review the output from the "git tag" command to see a list of all the potential 0.8 -releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can -also find the latest Kusama version on the -[release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with -> `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -``` - -Run the following command to find the latest version. - -```sh -git tag -l | sort -V | grep -v -- '-rc' -``` - -Find the latest version; replace "VERSION" in the commmand below and run to change your branch. - -```sh -git checkout VERSION -./scripts/init.sh -``` - -Build native code with the cargo release profile. - -```sh -cargo build --release -``` - -**_This step will take a while (generally 10 - 40 minutes, depending on your hardware)._** - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be -> done by running: -> -> ```sh -> rustup install nightly-2021-06-09 -> rustup target add wasm32-unknown-unknown --toolchain nightly-2021-06-09 -> cargo +nightly-2021-06-09 build --release -> ``` -> -> You may also need to run the build more than once. -> -> If you would like to execute the tests, run the following command: -> -> ```sh -> cargo test --all -> ``` - -If you are interested in generating keys locally, you can also install `subkey` from the same -directory. You may then take the generated `subkey` executable and transfer it to an air-gapped -machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not -> in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure -> that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: -> `--unsafe-pruning --pruning `, but note that an archive node and non-archive -> node's databases are not compatible with each other, and to switch you will need to purge the -> chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -``` -2021-06-17 02:34:25 ---------------------------- -2021-06-17 02:34:25 This chain is not in any way -2021-06-17 02:34:25 endorsed by the -2021-06-17 02:34:25 KUSAMA FOUNDATION -2021-06-17 02:34:25 ---------------------------- -2021-06-17 02:34:25 Parity Polkadot -2021-06-17 02:34:25 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu -2021-06-17 02:34:25 ❤️ by Parity Technologies , 2017-2021 -2021-06-17 02:34:25 📋 Chain specification: Kusama -2021-06-17 02:34:25 🏷 Node name: obtainable-kitten-0716 -2021-06-17 02:34:25 👤 Role: FULL -2021-06-17 02:34:25 💾 Database: RocksDb at /root/.local/share/polkadot/chains/ksmcc3/db -2021-06-17 02:34:25 ⛓ Native runtime: kusama-9050 (parity-kusama-0.tx5.au2) -2021-06-17 02:34:25 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) -2021-06-17 02:34:25 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. -2021-06-17 02:34:26 ⏱ Loaded block-time = 6s from block 0xb0a8d493285c2df73290dfb7e61f870f17b41801197a149ca93654499ea3dafe -2021-06-17 02:34:26 👶 Creating empty BABE epoch changes on what appears to be first startup. -2021-06-17 02:34:26 🏷 Local node identity is: 12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB -2021-06-17 02:34:26 📦 Highest known block at #0 -2021-06-17 02:34:26 〽️ Prometheus server started at 127.0.0.1:9615 -2021-06-17 02:34:26 Listening for new connections on 127.0.0.1:9944. -``` - -Example of node sync: - -``` -2021-06-17 02:34:34 🔍 Discovered new external address for our node: /ip4/100.102.231.64/tcp/30333/ws/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB -2021-06-17 02:34:36 ⚙️ Syncing 409.2 bps, target=#8062689 (5 peers), best: #3477 (0x63ad…e046), finalized #3072 (0x0e4c…f587), ⬇ 153.2kiB/s ⬆ 12.9kiB/s -2021-06-17 02:34:37 🔍 Discovered new external address for our node: /ip4/100.111.175.0/tcp/30333/ws/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB -2021-06-17 02:34:38 🔍 Discovered new external address for our node: /ip4/100.100.176.0/tcp/30333/ws/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB -2021-06-17 02:34:41 ⚙️ Syncing 386.2 bps, target=#8062690 (7 peers), best: #5409 (0x1d76…8c3d), finalized #5121 (0x8ad1…b6dc), ⬇ 96.1kiB/s ⬆ 10.9kiB/s -2021-06-17 02:34:46 ⚙️ Syncing 394.8 bps, target=#8062691 (11 peers), best: #7383 (0x0689…6f1e), finalized #7168 (0x72a9…8d8c), ⬇ 352.9kiB/s ⬆ 5.1kiB/s -2021-06-17 02:34:51 ⚙️ Syncing 347.0 bps, target=#8062692 (12 peers), best: #9118 (0x66fc…cce3), finalized #8704 (0x14c9…705e), ⬇ 62.7kiB/s ⬆ 1.7kiB/s -``` - -The `--pruning=archive` flag is implied by the `--validator` flag, so it is only -required explicitly if you start your node without one of these two options. If you do not set your -pruning to archive node, even when not running in validator, you will need to -re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can -> be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note -> that **ParityDB is still experimental and should not be used in production.** If you want to test -> out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will -> require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes -to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to -STDOUT from the `polkadot` process) will tell you the latest block your node has processed and -verified. You can then compare that to the current highest block via -[Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the -[Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. -For this, you will create two accounts and make sure each of them have at least enough funds to pay -the fees for making transactions. Keep most of your funds in the stash account since it is meant to -be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from -your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network - and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on -"Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/kusama-dashboard-bonding.png) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make - sure that your Stash account contains _at least_ this much. You can, of course, stake more than - this. -- **Controller account** - Select the Controller account created earlier. This account will also - need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do - not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM - later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On - Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info - [here](learn-staking.md#reward-distribution). Starting with runtime version v2023 natively - included in client version [0.9.3](https://github.com/paritytech/polkadot/releases/tag/v0.9.3), - payouts can go to any custom address. If you'd like to redirect payments to an account that is - neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set - an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash -account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card -with all your accounts (note: you may need to refresh the screen). The bonded amount on the right -corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the -> current session keys that you made the `setKeys` transaction then you can use one of the two -> available RPC methods to query your node: -> [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) -> to check for a specific key or -> [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) -> to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you -will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for -some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -Similarly: - -``` -2021-06-17 02:47:05 ---------------------------- -2021-06-17 02:47:05 This chain is not in any way -2021-06-17 02:47:05 endorsed by the -2021-06-17 02:47:05 KUSAMA FOUNDATION -2021-06-17 02:47:05 ---------------------------- -2021-06-17 02:47:05 Parity Polkadot -2021-06-17 02:47:05 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu -2021-06-17 02:47:05 ❤️ by Parity Technologies , 2017-2021 -2021-06-17 02:47:05 📋 Chain specification: Kusama -2021-06-17 02:47:05 🏷 Node name: techedtest -2021-06-17 02:47:05 👤 Role: AUTHORITY -2021-06-17 02:47:05 💾 Database: RocksDb at /root/.local/share/polkadot/chains/ksmcc3/db -2021-06-17 02:47:05 ⛓ Native runtime: kusama-9050 (parity-kusama-0.tx5.au2) -2021-06-17 02:47:07 🏷 Local node identity is: 12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB -2021-06-17 02:47:07 📦 Highest known block at #139917 -2021-06-17 02:47:07 〽️ Prometheus server started at 127.0.0.1:9615 -2021-06-17 02:47:07 Listening for new connections on 127.0.0.1:9944. -2021-06-17 02:47:07 👶 Starting BABE Authorship worker -``` - -``` -2021-06-17 02:48:15 🔍 Discovered new external address for our node: /ip4/10.2.99.4/tcp/30333/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB - -2021-06-17 02:48:17 ⚙️ Syncing 235.6 bps, target=#8062826 (49 peers), best: #155136 (0x23ea…e4fc), finalized #154624 (0x234f…f6a0), ⬇ 380.0kiB/s ⬆ 57.4kiB/s -``` - -You can give your validator any name that you like, but note that others will be able to see it, and -it will be included in the list of all servers using the same telemetry server. Since numerous -people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what -associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](learn-keys.md#session-keys) in the client via the apps RPC. If -you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator -node. You can configure the apps dashboard to connect to the endpoint of your validator in the -Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you -will not be able to use this method since making RPC requests to this node would effect the local -keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore -for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your -node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's -keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option -and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node -is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four -public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what -associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set -Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` -in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/kusama-set-session-key-1.png) -![staking-session-result](assets/guides/how-to-validate/kusama-set-session-key-2.png) - -Submit this extrinsic and you are now ready to start validating. - -### Setup via Validator Tab - -![dashboard validate](assets/guides/how-to-validate/kusama-dashboard-validate-1.png) - -Here you will need to input the Keys from `rotateKeys`, which is the Hex output from -`author_rotateKeys`. The keys will show as pending until applied at the start of a new session. - -The "reward commission percentage" is the commission percentage that you can declare against your -validator's rewards. This is the rate that your validator will be commissioned with. - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. - The remaining will be split among your nominators. - -> Note: setting a commission rate of 100% suggests that you do not want your validator to receive -> nominations. - -You can also determine if you would like to receive nominations with the "allows new nominations" -option. - -![dashboard validate](assets/guides/how-to-validate/kusama-dashboard-validate-2.png) - -Click "Bond & Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the -network. At the top of the page, it shows how many validator slots are available as well as how many -nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to -double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/kusama-dashboard-staking.png) - -The validator set is refreshed every era. In the next era, if there is a slot available and your -node is selected to join the validator set, your node will become an active validator. Until then, -it will remain in the _waiting_ queue. If your validator is not selected to become part of the -validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if -you are not selected for the validator set in a particular era. However, it may be necessary to -increase the number of KSM staked or seek out nominators for your validator in order to join the -validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the -validator set, you are now running a Kusama validator! If you need help, reach out on the -[Kusama forum](https://forum.kusama.network/) or in the -[Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies -to provide support for community validators. If you are interested in applying for the programme, -you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover -other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build -the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/docs/maintain-guides-how-to-validate-polkadot.md b/docs/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e63f729a2f7f..000000000000 --- a/docs/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,532 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on -> Kusama, check out the -> [Kusama guide](https://guide.kusama.network/docs/mirror-maintain-guides-how-to-validate-kusama) -> instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not -only your own stake, but also the stake of your current nominators. If you make a mistake and get -slashed, your money and your reputation will be at risk. However, running a validator can also be -very rewarding, knowing that you contribute to the security of a decentralized network while growing -your stash. - -⚠️ -**`Warning: It is highly recommended that you have significant system administration experience before attempting to run your own validator.` -You must be able to handle technical issues and anomalies with your node which you must be able to -tackle yourself. Being a validator involves more than just executing the Polkadot binary.** - -Since security is so important to running a successful validator, you should take a look at the -[secure validator](maintain-guides-secure-validator.md) information to make sure you understand the -factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a -[reference implementation for a validator set-up](https://github.com/w3f/polkadot-validator-setup) -that you can use by deploying yourself (video walkthrough is available -[here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a -validator, you will likely want to use this repository as a _starting point_ for your own -modifications and customizations. - -If you need help, please reach out on the -[Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) -on Riot. The team and other validators are there to help answer questions and provide tips from -experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed -[here](faq.md/#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators -are elected based on [Phragmén's algorithm](learn-phragmen.md). To be elected into the set, you need -a minimum stake behind your validator. This stake can come from yourself or from -[nominators](learn-nominator.md). This means that as a minimum, you will need enough DOT to set up -Stash and Controller [accounts](learn-keys.md) with the existential deposit, plus a little extra for -transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an -insecure or improper setup may result in loss of DOT tokens! If you are not confident in your -ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node -instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may -choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are -comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be -similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that -validators run at least the standard hardware in order to ensure they are able to process all blocks -in time. The following are not _minimum requirements_ but if you decide to run with less than this -beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see -[here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. - Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to - be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a -validator, however you should be aware that if you are using less you may need to toggle some extra -optimizations in order to be equal to other validators that are running the standard. - -### Node Prerequisites: Install Rust and Dependencies - -Once you choose your cloud service provider and set-up your new server, the first thing you will do -is install Rust. - -If you have never installed Rust, you should do this first. - -If you have already installed Rust, run the following command to make sure you are using the latest -version. - -```sh -rustup update -``` - -If not, this command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -s -- -y -``` - -> If you do not have "curl" installed, run "sudo apt install curl" - -To configure your shell, run the following command. - -```sh -source $HOME/.cargo/env -``` - -Verify your installation. - -```sh -rustc --version -``` - -Finally, run this command to install the necessary dependencies for compiling and running the -Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the -following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to -synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all -the systems within the network. Currently it is required that validators' local clocks stay -reasonably in sync, so you should be running NTP or a similar service. You can check whether you -have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar -message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to -verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. -> If the clock is out of sync (even by a small amount), the blocks the validator produces may not -> get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but -> zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` binary - -You will need to build the `polkadot` binary from the -[paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source -code available in the **v0.9** branch. - -You should generally use the latest **0.9.x** tag. You should either review the output from the "git -tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list -of all the potential 0.9 releases. You should replace `VERSION` below with the latest build (i.e., -the highest number). You can also find the latest Kusama version on the -[release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with -> `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -``` - -Run the following command to find the latest version. - -```sh -git tag -l | sort -V | grep -v -- '-rc' -``` - -Find the latest version; replace "VERSION" in the commmand below and run to change your branch. - -```sh -git checkout VERSION -./scripts/init.sh -``` - -Build native code with the cargo release profile. - -```sh -cargo build --release -``` - -**_This step will take a while (generally 10 - 40 minutes, depending on your hardware)._** - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be -> done by running: -> -> ```sh -> rustup install nightly-2021-06-09 -> rustup target add wasm32-unknown-unknown --toolchain nightly-2021-06-09 -> cargo +nightly-2021-06-09 build --release -> ``` -> -> You may also need to run the build more than once. -> -> If you would like to execute the tests, run the following command: -> -> ```sh -> cargo test --all -> ``` - -If you are interested in generating keys locally, you can also install `subkey` from the same -directory. You may then take the generated `subkey` executable and transfer it to an air-gapped -machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not -> in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure -> that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: -> `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive -> node and non-archive node's databases are not compatible with each other, and to switch you will -> need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -``` -2021-06-17 03:07:07 Parity Polkadot -2021-06-17 03:07:07 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu -2021-06-17 03:07:07 ❤️ by Parity Technologies , 2017-2021 -2021-06-17 03:07:07 📋 Chain specification: Polkadot -2021-06-17 03:07:07 🏷 Node name: boiling-pet-7554 -2021-06-17 03:07:07 👤 Role: FULL -2021-06-17 03:07:07 💾 Database: RocksDb at /root/.local/share/polkadot/chains/polkadot/db -2021-06-17 03:07:07 ⛓ Native runtime: polkadot-9050 (parity-polkadot-0.tx7.au0) -2021-06-17 03:07:10 🏷 Local node identity is: 12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u -2021-06-17 03:07:10 📦 Highest known block at #17914 -2021-06-17 03:07:10 〽️ Prometheus server started at 127.0.0.1:9615 -2021-06-17 03:07:10 Listening for new connections on 127.0.0.1:9944. -``` - -Example of node sync: - -``` -2021-06-17 03:07:39 🔍 Discovered new external address for our node: /ip4/10.26.16.1/tcp/30333/ws/p2p/12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u -2021-06-17 03:07:40 ⚙️ Syncing 218.8 bps, target=#5553764 (17 peers), best: #24034 (0x08af…dcf5), finalized #23552 (0xd4f0…2642), ⬇ 173.5kiB/s ⬆ 12.7kiB/s -2021-06-17 03:07:45 ⚙️ Syncing 214.8 bps, target=#5553765 (20 peers), best: #25108 (0xb272…e800), finalized #25088 (0x94e6…8a9f), ⬇ 134.3kiB/s ⬆ 7.4kiB/s -2021-06-17 03:07:50 ⚙️ Syncing 214.8 bps, target=#5553766 (21 peers), best: #26182 (0xe7a5…01a2), finalized #26112 (0xcc29…b1a9), ⬇ 5.0kiB/s ⬆ 1.1kiB/s -2021-06-17 03:07:55 ⚙️ Syncing 138.4 bps, target=#5553767 (21 peers), best: #26874 (0xcf4b…6553), finalized #26624 (0x9dd9…27f8), ⬇ 18.9kiB/s ⬆ 2.0kiB/s -2021-06-17 03:08:00 ⚙️ Syncing 37.0 bps, target=#5553768 (22 peers), best: #27059 (0x5b73…6fc9), finalized #26624 (0x9dd9…27f8), ⬇ 14.3kiB/s ⬆ 4.4kiB/s -``` - -The `--pruning=archive` flag is implied by the `--validator` flag, so it is only -required explicitly if you start your node without one of these two options. If you do not set your -pruning to archive node, even when not running in validator mode, you will need to -re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can -> be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note -> that **ParityDB is still experimental and should not be used in production.** If you want to test -> out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will -> require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes -to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to -STDOUT from the `polkadot` process) will tell you the latest block your node has processed and -verified. You can then compare that to the current highest block via -[Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the -[PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. -For this, you will create two accounts and make sure each of them have at least enough funds to pay -the fees for making transactions. Keep most of your funds in the stash account since it is meant to -be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from -your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network - and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on -"Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.png) - -- **Stash account** - Select your Stash account. In this example, we will bond 1 DOT, where the - minimum bonding amount is 1. Make sure that your Stash account contains _at least_ this much. You - can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also - need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do - not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT - later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On - Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info - [here](learn-staking.md/#reward-distribution). Starting with runtime version v23 natively included - in client version [0.9.3](https://github.com/paritytech/polkadot/releases/tag/v0.9.3), payouts can - go to any custom address. If you'd like to redirect payments to an account that is neither the - controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange - address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash -account. - -![sign transaction](assets/guides/how-to-validate/polkadot-authorize-transaction-stash.png) - -After a few seconds, you should see an `ExtrinsicSuccess` message. - -Your bonded account will available under `Stashes`. You should now see a new card with all your -accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to -the funds bonded by the Stash account. - -![stash overview](assets/guides/how-to-validate/polkadot-stash-overview.png) - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the -> current session keys that you made the `setKeys` transaction then you can use one of the two -> available RPC methods to query your node: -> [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to -> check for a specific key or -> [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) -> to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you -will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -Similarly: - -``` -2021-06-17 03:12:08 Parity Polkadot -2021-06-17 03:12:08 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu -2021-06-17 03:12:08 ❤️ by Parity Technologies , 2017-2021 -2021-06-17 03:12:08 📋 Chain specification: Polkadot -2021-06-17 03:12:08 🏷 Node name: nateched-test -2021-06-17 03:12:08 👤 Role: AUTHORITY -2021-06-17 03:12:08 💾 Database: RocksDb at /root/.local/share/polkadot/chains/polkadot/db -2021-06-17 03:12:08 ⛓ Native runtime: polkadot-9050 (parity-polkadot-0.tx7.au0) -2021-06-17 03:12:12 🏷 Local node identity is: 12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u -2021-06-17 03:12:12 📦 Highest known block at #64673 -2021-06-17 03:12:12 〽️ Prometheus server started at 127.0.0.1:9615 -2021-06-17 03:12:12 Listening for new connections on 127.0.0.1:9944. -2021-06-17 03:12:12 👶 Starting BABE Authorship worker -``` - -``` -2021-06-17 03:12:16 🔍 Discovered new external address for our node: /ip4/10.26.11.1/tcp/30333/p2p/12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u -2021-06-17 03:12:17 ⚙️ Syncing, target=#5553810 (14 peers), best: #65068 (0x6da5…0662), finalized #65024 (0x4e84…d170), ⬇ 352.2kiB/s ⬆ 75.6kiB/s -``` - -You can give your validator any name that you like, but note that others will be able to see it, and -it will be included in the list of all servers using the same telemetry server. Since numerous -people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what -associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](learn-keys.md#session-keys) in the client via the apps RPC. If -you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator -node. You can configure the apps dashboard to connect to the endpoint of your validator in the -Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you -will not be able to use this method since making RPC requests to this node would effect the local -keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore -for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your -node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's -keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option -and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node -is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four -public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what -associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set -Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` -in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.png) -![staking-session-result](assets/guides/how-to-validate/set-session-key-2.png) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to -[Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this -will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -In this example, we used the name `techedtest` and have successfully located it upon searching: - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-telemetry.png) - -### Setup via Validator Tab - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-1.png) - -Here you will need to input the Keys from `rotateKeys`, which is the Hex output from -`author_rotateKeys`. The keys will show as pending until applied at the start of a new session. - -The "reward commission percentage" is the commission percentage that you can declare against your -validator's rewards. This is the rate that your validator will be commissioned with. - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. - The remaining will be split among your nominators. - -> Note: setting a commission rate of 100% suggests that you do not want your validator to receive -> nominations. - -You can also determine if you would like to receive nominations with the "allows new nominations" -option. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-2.png) - -Click "Bond & Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the -network. At the top of the page, it shows the number of validator slots that are available as well -as the number of nodes that have signaled their intention to be a validator. You can go to the -"Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.png) - -The validator set is refreshed every era. In the next era, if there is a slot available and your -node is selected to join the validator set, your node will become an active validator. Until then, -it will remain in the _waiting_ queue. If your validator is not selected to become part of the -validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if -you are not selected for the validator set in a particular era. However, it may be necessary to -increase the number of DOT staked or seek out nominators for your validator in order to join the -validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the -validator set, you are now running a Polkadot validator! If you need help, reach out on the -[Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies -to provide support for community validators. If you are interested in applying for the programme, -you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover -other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build -the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/docs/maintain-guides-secure-validator.md b/docs/maintain-guides-secure-validator.md deleted file mode 100644 index f1370c182f0e..000000000000 --- a/docs/maintain-guides-secure-validator.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -id: maintain-guides-secure-validator -title: Secure Validator -sidebar_label: Secure Validator ---- - -Validators in a Proof of Stake network are responsible for keeping the network in consensus and -verifying state transitions. As the number of validators is limited, validators in the set have the -responsibility to be online and faithfully execute their tasks. - -This primarily means that validators: - -- Must be high availability. -- Must have infrastructure that protects the validator's signing keys so that an attacker cannot - take control and commit slashable behavior. - -## High Availability - -High availability set-ups that involve redundant validator nodes may seem attractive at first. -However, they can be **very dangerous** if they are not set up perfectly. The reason for this is -that the session keys used by a validator should always be isolated to just a single node. -Replicating session keys across multiple nodes could lead to equivocation slashes or parachain -validity slashes which can make you lose **100% of your staked funds**. - -The good news is that 100% uptime of your validator is not really needed, as it has some buffer -within eras in order to go offline for a little while and upgrade. For this reason, we advise that -you only attempt a high availability set-up if **you're confident you know exactly what you're -doing.** - -Many expert validators have made mistakes in the past due to the handling of session keys. - -Remember, even if your validator goes offline for some time, the offline slash is much more -forgiving than the equivocation or parachain validity slashing. - -## Key Management - -See the [Polkadot Keys guide](learn-keys.md) for more information on keys. The keys that are of -primary concern for validator infrastructure are the Session keys. These keys sign messages related -to consensus and parachains. Although Session keys are _not_ account keys and therefore cannot -transfer funds, an attacker could use them to commit slashable behavior. - -Session keys are generated inside the node via RPC call. See the -[How to Validate guide](maintain-guides-how-to-validate-polkadot.md#set-session-keys) - -for instructions on setting Session keys. These should be generated and kept within your client. -When you generate new Session keys, you must submit an extrinsic (a Session certificate) from your -Controller key telling the chain your new Session keys. - -> **NOTE:** Session keys can also be generated outside the client and inserted into the client's -> keystore via RPC. For most users, we recommend using the key generation functionality within the -> client. - -### Signing Outside the Client - -In the future, Polkadot will support signing payloads outside the client so that keys can be stored -on another device, e.g. a hardware security module (HSM) or secure enclave. For the time being, -however, Session key signatures are performed within the client. - -> **NOTE:** HSMs are not a panacea. They do not incorporate any logic and will just sign and return -> whatever payload they receive. Therefore, an attacker who gains access to your validator node -> could still commit slashable behavior. - -## Monitoring Tools - -- [Telemetry](https://github.com/paritytech/substrate-telemetry) This tracks your node details - including the version you are running, block height, CPU & memory usage, block propagation time, - etc. - -- [Prometheus](https://prometheus.io/)-based monitoring stack, including - [Grafana](https://grafana.com) for dashboards and log aggregation. It includes alerting, querying, - visualization, and monitoring features and works for both cloud and on-premise systems. The data - from `substrate-telemetry` can be made available to Prometheus through exporters like - [this](https://github.com/w3f/substrate-telemetry-exporter). - -## Linux Best Practices - -- Never use the root user. -- Always update the security patches for your OS. -- Enable and set up a firewall. -- Never allow password-based SSH, only use key-based access. -- Disable non-essential SSH subsystems (banner, motd, scp, X11 forwarding) and harden your SSH - configuration - ([reasonable guide to begin with](https://stribika.github.io/2015/01/04/secure-secure-shell.html)). -- Back up your storage regularly. - -## Conclusions - -- At the moment, Polkadot/Substrate can't interact with HSM/SGX, so we need to provide the signing - key seeds to the validator machine. This key is kept in memory for signing operations and - persisted to disk (encrypted with a password). - -- Given that HA setups would always be at risk of double-signing and there's currently no built-in - mechanism to prevent it, we propose having a single instance of the validator to avoid slashing. - Slashing penalties for being offline are much less than those for equivocation. - -### Validators - -- Validators should only run the Polkadot binary, and they should not listen on any port other than - the configured p2p port. - -- Validators should run on bare-metal machines, as opposed to VMs. This will prevent some of the - availability issues with cloud providers, along with potential attacks from other VMs on the same - hardware. The provisioning of the validator machine should be automated and defined in code. This - code should be kept in private version control, reviewed, audited, and tested. - -- Session keys should be generated and provided in a secure way. - -- Polkadot should be started at boot and restarted if stopped for any reason (supervisor process). - -- Polkadot should run as a non-root user. - -### Monitoring - -- There should be an on-call rotation for managing the alerts. - -- There should be a clear protocol with actions to perform for each level of each alert and an - escalation policy. - -## Resources - -- [Figment Network's Full Disclosure of Cosmos Validator Infrastructure](https://medium.com/figment-networks/full-disclosure-figments-cosmos-validator-infrastructure-3bc707283967) -- [Certus One's Knowledge Base](https://kb.certus.one/) -- [EOS Block Producer Security List](https://github.com/slowmist/eos-bp-nodes-security-checklist) -- [HSM Policies and the Important of Validator Security](https://medium.com/loom-network/hsm-policies-and-the-importance-of-validator-security-ec8a4cc1b6f) diff --git a/docs/maintain-guides-society-kusama.md b/docs/maintain-guides-society-kusama.md deleted file mode 100644 index ad6c00b4f4bc..000000000000 --- a/docs/maintain-guides-society-kusama.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - - - -Kappa Sigma Mu is a membership club using the Substrate [Society][substrate pallet] pallet. It is an -economic game to incentivize users to join a society that coordinates around whatever the rules are -decided to be. The members of the society are incentivized to participate in the society via the -rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to -have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) -![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the -[Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the -[rules][kappa rules] to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set - to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the - society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their - membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the - number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend - their membership in the society. The rules for defending the membership are documented [in the - rules][kappa rules]. - -## Procedure - -Remember to take a look at the [rules][kappa rules] first. And since those rules are not enforced -entirely on-chain, it is recommended to join the -[Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask -any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the -[Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to -create a bid on their behalf by vouching for them. At every rotation period, as many bids as the -society pot can support will be selected. The selected bids will be moved to the candidate phase, -whereas bids that were not selected will stay in the bidder pool until they are selected or a user -chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and -declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the -[Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can -cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same -page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are -willing to give them a tip. An existing member can submit a `vouch` transaction through the -Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you -will be approved to join the society. Members will vote for all the candidates and the final outcome -will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each -> rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | --- | --- | --- | --- | --- | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a -final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the -candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If -they do not participate in voting, they will be punished with one strike per missing vote. If one -accumulates too many strikes, one's membership is suspended which means they may need to re-apply -and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the -randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this -case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the -selected vote as a reward for participating in the vote. The reward is escrowed for some period of -time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you -have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula -is defined [in the society pallet][substrate pallet] if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50_000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15_552_000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was -placed by a voucher, they will get back the reward that was set during vouching with the remainder -given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the -`Suspension Judgement Origin`) to determine if the candidate should go through the bidding process -again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during -the bidding. A few things you need to be aware of. First, you should vote on candidates who applied -for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It -is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will -be randomly selected as a defender. Then, other members can vote whether this defender should stay -in the society or not. A simple majority wins the vote. You can take a look [here][kappa rules] and -search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user -apply for the membership and requesting a tip. This is useful when a user does not have enough -balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the -> deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become -suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the -suspension judgment origin to determine if the member should re-enter society or be removed from -society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - -Rules about joining the Kusama society - -[substrate pallet]: https://substrate.dev/rustdocs/latest/pallet_society/index.html -[kappa rules]: - https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17 diff --git a/docs/maintain-guides-validator-payout.md b/docs/maintain-guides-validator-payout.md deleted file mode 100644 index dcd9d413531d..000000000000 --- a/docs/maintain-guides-validator-payout.md +++ /dev/null @@ -1,204 +0,0 @@ ---- -id: maintain-guides-validator-payout -title: Validator Payout Overview -sidebar_label: Validator Payout Overview ---- - -## Era Points - -For every era (a period of time approximately 6 hours in length in Kusama, and 24 hours in -Polkadot), validators are paid proportionally to the amount of _era points_ they have collected. Era -points are reward points earned for payable actions like: - -- issuing validity statements for [parachain](learn-parachains.md) blocks. -- producing a non-uncle block in the Relay Chain. -- producing a reference to a previously unreferenced uncle block. -- producing a referenced uncle block. - -_Note: An uncle block is a Relay Chain block that is valid in every regard, but which failed to -become canonical. This can happen when two or more validators are block producers in a single slot, -and the block produced by one validator reaches the next block producer before the others. We call -the lagging blocks uncle blocks._ - -Payments occur at the end of every era. - -## Payout Scheme - -No matter how much total stake is behind a validator, all validators split the block authoring -payout essentially equally. The payout of a specific validator, however, may differ based on -[era points](#era-points), as described above. Although there is a probabilistic component to -receiving era points, and they may be impacted slightly depending on factors such as network -connectivity, well-behaving validators should generally average out to having similar era point -totals over a large number of eras. - -Validators may also receive "tips" from senders as an incentive to include transactions in their -produced blocks. Validators will receive 100% of these tips directly. - -Validators will receive staking rewards in the form of the native token of that chain (KSM for -Kusama and DOT for Polkadot). - -For simplicity, the examples below will assume all validators have the same amount of era points, -and received no tips. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1): 18 tokens -Validator 2 Stake (v2): 9 tokens -Validator 3 Stake (v3): 8 tokens -Validator 4 Stake (v4): 7 tokens -Payout (p): 8 DOT - -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 tokens -``` - -Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a -validator is in the validator set, it will receive the same block reward as every other validator. -Validator `v1`, who had 18 tokens staked, received the same reward (2 tokens) in this era as `v4` -who had only 7 tokens staked. - -## Running Multiple Validators - -It is possible for a single entity to run multiple validators. Running multiple validators may -provide a better risk/reward ratio. Assuming you have enough DOT, or enough stake nominates your -validator, to ensure that your validators remain in the validator set, running multiple validators -will result in a higher return than running a single validator. - -For the following example, assume you have 18 DOT to stake. For simplicity's sake, we will ignore -nominators. Running a single validator, as in the example above, would net you 2 DOT in this era. - -Note that while DOT is used as an example, this same formula would apply to KSM when running a -validator on Kusama. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1): 18 DOT <- Your validator -Validator 2 Stake (v2): 9 DOT -Validator 3 Stake (v3): 8 DOT -Validator 4 Stake (v4): 7 DOT -Payout (p): 8 DOT - -Your payout = (p / v) * 1 = (8 / 4) * 1 = 2 -``` - -Running two validators, and splitting the stake equally, would result in the original validator `v4` -to be kicked out of the validator set, as only the top `v` validators (as measured by stake) are -selected to be in the validator set. More important, it would also double the reward that you get -from each era. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1): 9 DOT <- Your first validator -Validator 2 Stake (v2): 9 DOT <- Your second validator -Validator 3 Stake (v3): 9 DOT -Validator 4 Stake (v4): 8 DOT -Payout (p): 8 DOT - -Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 -``` - -With enough stake, you could run more than two validators. However, each validator must have enough -stake behind it to be in the validator set. - -The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather -than static, equilibrium. Potential validators will run different numbers of validators and apply -different amounts of stake to them as time goes on, and in response to the actions of other -validators on the network. - -## Slashing - -Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do -have enough DOT to run multiple validators, it is in your best interest to do so. A slash of 30% -will, of course, be more DOT for a validator with 18 DOT staked than one with 9 DOT staked. - -Running multiple validators does not absolve you of the consequences of misbehavior. Polkadot -punishes attacks that appear coordinated more severely than individual attacks. You should not, for -example, run multiple validators hosted on the same infrastructure. A proper multi-validator -configuration would ensure that they do not fail simultaneously. - -Nominators have the incentive to nominate the lowest-staked validator, as this will result in the -lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing -remains the same (since it is percentage-based), their rewards are higher since they will be a -higher proportion of the total stake allocated to that validator. - -To clarify this, let us imagine two validators, `v1` and `v2`. Assume both are in the active set, -have commission set to 0%, and are well-behaved. The only difference is that `v1` has 90 DOT -nominating it and `v2` only has 10. If you nominate `v1`, it now has `90 + 10 = 100` DOT, and you -will get 10% of the staking rewards for the next era. If you nominate `v2`, it now has -`10 + 10 = 20` DOT nominating it, and you will get 50% of the staking rewards for the next era. In -actuality, it would be quite rare to see such a large difference between the stake of validators, -but the same principle holds even for smaller differences. If there is a 10% slash of either -validator, then you will lose 1 DOT in each case. - -## Nominators and Validator Payments - -Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without -running a validator node yourself. Validators can choose to keep a percentage of the rewards due to -their validator to "reimburse" themselves for the cost of running a validator node. Other than that, -all rewards are shared based on the stake behind each validator. This includes the stake of the -validator itself, plus any stake bonded by nominators. - -> **NOTE:** Validators set their preference as a percentage of the block reward, _not_ an absolute -> number of DOT. Polkadot's block reward is based on the _total_ amount at stake, with the reward -> peaking when the amount staked is at 50% of the total supply. The commission is set as the amount -> taken by the validator; that is, 0% commission means that the validator does not receive any -> proportion of the rewards besides that owed to it from self-stake, and 100% commission means that -> the validator operator gets all rewards and gives none to its nominators. - -In the following examples, we can see the results of several different validator payment schemes and -split between nominator and validator stake. We will assume a single nominator for each validator. -However, there can be numerous nominators for each validator. Rewards are still distributed -proportionally - for example, if the total rewards to be given to nominators is 2 DOT, and there are -four nominators with equal stake bonded, each will receive 0.5 DOT. Note also that a single -nominator may stake different validators. - -Each validator in the example has selected a different validator payment (that is, a percentage of -the reward set aside directly for the validator before sharing with all bonded stake). The -validator's payment percentage (in DOT, although the same calculations work for KSM) is listed in -brackets (`[]`) next to each validator. Note that since the validator payment is public knowledge, -having a low or non-existent validator payment may attract more stake from nominators, since they -know they will receive a larger reward. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1) [20% commission]: 18 DOT (9 validator, 9 nominator) -Validator 2 Stake (v2) [40% commission]: 9 DOT (3 validator, 6 nominator) -Validator 3 Stake (v3) [10% commission]: 8 DOT (4 validator, 4 nominator) -Validator 4 Stake (v4) [ 0% commission]: 6 DOT (1 validator, 5 nominator) -Payout (p): 8 DOT - -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 DOT - -v1: -(0.2 * 2) = 0.4 DOT -> validator payment -(2 - 0.4) = 1.6 -> shared between all stake -(9 / 18) * 1.6 = 0.8 -> validator stake share -(9 / 18) * 1.6 = 0.8 -> nominator stake share -v1 validator total reward: 0.4 + 0.8 = 1.2 DOT -v1 nominator reward: 0.8 DOT - -v2: -(0.4 * 2) = 0.8 DOT -> validator payment -(2 - 0.8) = 1.2 -> shared between all stake -(3 / 9) * 1.2 = 0.4 -> validator stake share -(6 / 9) * 1.2 = 0.8 -> nominator stake share -v2 validator total reward: 0.8 + 0.4 = 1.2 DOT -v2 nominator reward: 0.8 DOT - -v3: -(0.1 * 2) = 0.2 DOT -> validator payment -(2 - 0.2) = 1.8 -> shared between all stake -(4 / 8) * 1.8 = 0.9 -> validator stake share -(4 / 8) * 1.8 = 0.9 -> nominator stake share -v3 validator total reward: 0.2 + 0.9 DOT = 1.1 DOT -v3 nominator reward: 0.9 DOT - -v4: -(0 * 2) = 0 DOT -> validator payment -(2 - 0) = 2.0 -> shared between all stake -(1 / 6) * 2 = 0.33 -> validator stake share -(5 / 6) * 2 = 1.67 -> nominator stake share -v4 validator total reward: 0 + 0.33 DOT = 0.33 DOT -v4 nominator reward: 1.67 DOT -``` diff --git a/docs/maintain-index.md b/docs/maintain-index.md deleted file mode 100644 index 100c11f07a2d..000000000000 --- a/docs/maintain-index.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: maintain-index -title: Network Maintainers -sidebar_label: Network Maintainers ---- - -Welcome to the network maintainers section of the Polkadot wiki. Here you will find information and -guides to set up a node and run the network. - -## Node - -- [Networks Guide](maintain-networks.md) - A list of the available Polkadot networks that you can - connect to with a node. -- [Set up a Full Node](maintain-sync.md) - Get up and started by syncing a full node for the Kusama - network. The steps in the guide will broadly apply also to any Substrate-based network (like - Polkadot). -- [Set up WSS using Nginx](maintain-wss.md) - Set up a Secure WebSockets server for your node's - WebSockets connection. - -## Collator - -- [Learn about Collators](learn-collator.md) - High level overview of collators and related links. - -## Nominator - -- [Learn about Nominators](learn-nominator.md) - High level overview of nominators and related - links. -- [Nomination Guide (Polkadot)](maintain-guides-how-to-nominate-polkadot.md) - Walkthrough on how to - nominate on the Polkadot network. -- [Nomination Guide (Kusama)](maintain-guides-how-to-nominate-kusama.md) - Walkthrough on how to - nominate on the Kusama canary network. -- [How to stop being a Nominator](maintain-guides-how-to-unbond.md) - Guide on how to stop - nominating. - -## Validator - -- [Learn about Validators](learn-validator.md) - High level overview of validator and related links. -- [Validator Payouts](maintain-guides-validator-payout.md) - Overview on how validator rewards are - calculated and paid. -- [Validation Guide (Polkadot)](maintain-guides-how-to-validate-polkadot.md) - Walkthrough on how to - validate on the Polkadot network. -- [Validation Guide (Kusama)](maintain-guides-how-to-validate-kusama.md) - Walkthrough on how to - validate on the Kusama canary network. -- [Using systemmd for the Validator Node](maintain-guides-how-to-systemd.md) - Configuring systemmd - with the Validator node. -- [Secure Validator](maintain-guides-secure-validator.md) - Best tips and practices for validating. -- [How to use Polkadot Validator Setup](maintain-guides-how-to-use-polkadot-validator-setup.md) - - Walkthrough on how to set up a validator securely. -- [How to upgrade a Validator Node](maintain-guides-how-to-upgrade.md) - Guide on upgrading your - validator node. -- [How to Chill](maintain-guides-how-to-chill.md) - Walkthrough on how to chill as a validator. -- [How to Stop Validating](maintain-guides-how-to-stop-validating.md) - Proper way to stop - validating. - -## Governance - -- [How to pariticipate in Governance](maintain-guides-democracy.md) - Walkthrough on how to - participate in governance. -- [How to join the Council][join the council] - Step by step guide for running for the Council. -- [How to vote for a Councillor][vote for councillors] - Step by step guide for voting for your - favorite councillors. - -[join the council]: maintain-guides-how-to-join-council.md -[vote for councillors]: maintain-guides-how-to-vote-councillor.md diff --git a/docs/maintain-polkadot-parameters.md b/docs/maintain-polkadot-parameters.md deleted file mode 100644 index b43e2faab2bd..000000000000 --- a/docs/maintain-polkadot-parameters.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute -certainty of these parameter values, it is recommended you directly check the constants by looking -at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or -[storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Polkadot generally runs at ¼th the speed of Kusama, except in the time slot duration -itself. See [Kusama Parameters](kusama-parameters) for more details on how Polkadot's parameters -differ from Kusama's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2_400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2_400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | ------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2_400 | -| Session | 4 hours | 2_400 | -| Era | 24 hours | 14_400 | - -\*_A maximum of one block per slot can be in a canonical chain. Occasionally, a slot will be without -a block in the chain. Thus, the times given are *estimates*. See [Consensus](learn-consensus.md) for -more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403_200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403_200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403_200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100_800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100_800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100_800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1_800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -As of June 30, 2021, the staking parameters have been modified to a minimum of 40 DOT to nominate, -and a maximum of 22_500 total nominators. As most of these parameters can be updated via on-chain -governance, please check the latest parameters on -[chain state](https://polkadot.js.org/apps/#/chainstate) (selected state query - staking - -minimumNominatorBond and maxNominatorsCount) - -| Polkadot | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14_400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14_400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403_200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403_200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345_600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10_000_000_000 or ten billion) -Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1*248_328 in an event -known as \_Denomination Day*. See [Redenomination](redenomination.md) for details. diff --git a/docs/maintain-sync.md b/docs/maintain-sync.md deleted file mode 100644 index 879288afb49f..000000000000 --- a/docs/maintain-sync.md +++ /dev/null @@ -1,264 +0,0 @@ ---- -id: maintain-sync -title: Set up a Full Node -sidebar_label: Set up a Full Node ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -If you're building dapps or products on a Substrate-based chain like Polkadot, Kusama or a custom -Substrate implementation, you probably want the ability to run a node-as-a-back-end. After all, it's -always better to rely on your own infrastructure than on a third-party-hosted one in this brave new -decentralized world. - -This guide will show you how to connect to [Polkadot network](https://polkadot.network/), but the -same process applies to any other [Substrate](https://substrate.dev/docs/en/)-based chain. First, -let's clarify the term _full node_. - -### Types of Nodes - -A blockchain's growth comes from a _genesis block_, _extrinsics_, and _events_. - -When a validator seals block 1, it takes the blockchain's state at block 0. It then applies all -pending changes on top of it, and emits the events that are the result of these changes. Later, the -state of the chain at block 1 is used in the same way to build the state of the chain at block 2, -and so on. Once two thirds of the validators agree on a specific block being valid, it is finalized. - -An **archive node** keeps all the past blocks. An archive node makes it convenient to query the past -state of the chain at any point in time. Finding out what an account's balance at a certain block -was, or which extrinsics resulted in a certain state change are fast operations when using an -archive node. However, an archive node takes up a lot of disk space - around Kusama's 1.6 millionth -block this was around 15 to 20GB. - -Archive nodes are used by utilities that need past information - like block explorers, council -scanners, discussion platforms like [Polkassembly](https://polkassembly.io), and others. They need -to be able to look at past on-chain data. - -A **full node** is _pruned_: it discards all finalized blocks older than a configurable number -except the genesis block: This is 256 blocks from the last finalized one, by default. A node that is -pruned this way requires much less space than an archive node. - -A full node may eventually be able to rebuild the entire chain with no additional information, and -become an archive node, but at he time of writing, this is not implemented. If you need to query -historical blocks past what you pruned, you need to purge your database and resync your node -starting in archive mode. Alternatively you can use a backup or snapshot of a trusted source to -avoid needing to sync from genesis with the network, and only need the blocks past that snapshot. - -Full nodes allow you to read the current state of the chain and to submit and validate extrinsics -directly on the network without relying on a centralized infrastructure provider. - -Another type of node is a **light node**. A light node has only the runtime and the current state, -but does not store past blocks and so cannot read historical data without requesting it from a node -that has it. Light nodes are useful for resource restricted devices. An interesting use-case of -light nodes is a Chrome extension, which is a node in its own right, running the runtime in [WASM -format](https://github.com/paritytech/substrate-light-ui) as well as a full or light node that is -completely encapsulated in WASM and can be integrated into webapps: -https://github.com/paritytech/smoldot#wasm-light-node - ---- - -## Setup Instructions - -This is not recommended if you're a validator. Please see the -[secure validator setup](maintain-guides-secure-validator.md) if you are running validator. - - - - - - Install Homebrew within the terminal by running: - ```bash - /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" - ``` - - Then, run: - ```bash - brew install openssl cmake llvm` - ``` - - - Install Rust in your terminal by running: - ```bash - curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - ``` - - Once Rust is installed, run the following command to clone and build the polkadot code: - ```bash - git clone https://github.com/paritytech/polkadot polkadot - cd polkadot - ./scripts/init.sh - cargo build --release - ``` - - Start your node: - {{ polkadot: - ```bash - ./target/release/polkadot --name "Your Node's Name" - ``` - :polkadot }} - {{ kusama: - ```bash - ./target/release/polkadot --name "Your Node's Name" --chain kusama - ``` - :kusama }} - - - Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot) - - - - - - Install [WSL](https://docs.microsoft.com/en-us/windows/wsl/install-win10). - - Install [Ubuntu](https://docs.microsoft.com/en-us/windows/wsl/install-win10) (same webpage). - - - Determine the latest version of the [Polkadot binary](https://github.com/paritytech/polkadot/releases). - - Download the correct Polkadot binary within Ubuntu by running the following command. Replace - `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): - ```bash - curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot - ``` - - - Then, run the following: - ```bash - sudo chmod +x polkadot - ``` - - Start your node: - {{ polkadot: - ```bash - ./target/release/polkadot --name "Your Node's Name" - ``` - :polkadot }} - {{ kusama: - ```bash - ./target/release/polkadot --name "Your Node's Name" --chain kusama - ``` - :kusama }} - - - Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot) - - - - - - Determine the latest version of the [Polkadot binary](https://github.com/paritytech/polkadot/releases). - - > The nature of pre-built binaries means that they may not work on your particular architecture or Linux distribution. - > If you see an error like `cannot execute binary file: Exec format error` it likely means the binary is not compatible - > with your system. You will either need to compile the [**source code**](#clone-and-build) or use [**Docker**](#using-docker). - - - Download the correct Polkadot binary within Ubuntu by running the following command. Replace - `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): - ```bash - curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot - ``` - - - Run the following: `sudo chmod +x polkadot` - - Run the following: - {{ polkadot: - ```bash - ./target/release/polkadot --name "Your Node's Name" - ``` - :polkadot }} - {{ kusama: - ```bash - ./target/release/polkadot --name "Your Node's Name" --chain kusama - ``` - :kusama }} - - - Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot) - - - - -## Get Substrate - -Follow instructions as outlined -[here](https://substrate.dev/docs/en/knowledgebase/getting-started) - note that Windows users will -have their work cut out for them. It's better to use a virtual machine instead. - -Test if the installation was successful by running `cargo --version`. - -```bash -λ cargo --version -cargo 1.41.0 (626f0f40e 2019-12-03) -``` - -## Clone and Build - -The [paritytech/polkadot](https://github.com/paritytech/polkadot) repo's master branch contains the -latest Polkadot code. - -```bash -git clone https://github.com/paritytech/polkadot polkadot -cd polkadot -./scripts/init.sh -cargo build --release -``` - -Alternatively, if you wish to use a specific release, you can check out a specific tag (`v0.8.3` in -the example below): - -```bash -git clone https://github.com/paritytech/polkadot polkadot -cd polkadot -git checkout tags/v0.8.3 -./scripts/init.sh -cargo build --release -``` - -## Run - -The built binary will be in the `target/release` folder, called `polkadot`. - -{{ polkadot: -```bash -./target/release/polkadot --name "Your Node's Name" -``` -:polkadot }} -{{ kusama: -```bash -./target/release/polkadot --name "Your Node's Name" --chain kusama -``` -:kusama }} - -Use the `--help` flag to find out which flags you can use when running the node. For example, if -[connecting to your node remotely](maintain-wss.md), you'll probably want to use `--ws-external` and -`--rpc-cors all`. - -The syncing process will take a while depending on your bandwidth, processing power, disk speed and -RAM. On a \$10 DigitalOcean droplet, the process can complete in some 36 hours. - -Congratulations, you're now syncing with Polkadot. Keep in mind that the process is identical when -using any other Substrate chain. - -## Running an Archive Node - -When running as a simple sync node (above), only the state of the past 256 blocks will be kept. When -validating, it defaults to [archive mode](#types-of-nodes). To keep the full state use the -`--pruning` flag: - -{{ polkadot: -```bash -./target/release/polkadot --name "My node's name" --pruning archive -``` -:polkadot }} -{{ kusama: -```bash -./target/release/polkadot --name "My node's name" --pruning archive --chain kusama -``` -:kusama }} - -It is possible to almost quadruple synchronization speed by using an additional flag: -`--wasm-execution Compiled`. Note that this uses much more CPU and RAM, so it should be turned off -after the node is in sync. - -## Using Docker - -Finally, you can use Docker to run your node in a container. Doing this is a bit more advanced so -it's best left up to those that either already have familiarity with docker, or have completed the -other set-up instructions in this guide. If you would like to connect to your node's WebSockets -ensure that you run you node with the `--rpc-external` and `--ws-external` commands. - -```zsh -docker run -p 9944:9944 parity/polkadot:v0.8.24 --name "calling_home_from_a_docker_container" --rpc-external --ws-external -``` diff --git a/docs/maintain-guides-how-to-nominate-kusama.md b/docs/maintain/kusama/maintain-guides-how-to-nominate-kusama.md similarity index 90% rename from docs/maintain-guides-how-to-nominate-kusama.md rename to docs/maintain/kusama/maintain-guides-how-to-nominate-kusama.md index c8262598fa28..4604e9335e9a 100644 --- a/docs/maintain-guides-how-to-nominate-kusama.md +++ b/docs/maintain/kusama/maintain-guides-how-to-nominate-kusama.md @@ -2,12 +2,11 @@ id: maintain-guides-how-to-nominate-kusama title: Be a Nominator (Kusama) sidebar_label: Nominator Guide +slug: ../../maintain-guides-how-to-nominate-kusama --- - - > The following information applies to the Kusama network. If you want to nominate on Polkadot, -> check out the [Polkadot guide](maintain-guides-how-to-validate-polkadot.md) instead. +> check out the [Polkadot guide](../maintain-guides-how-to-validate-polkadot.md) instead. Nominators are one type of participant in the staking subsystem of Polkadot. They are responsible for appointing their stake to the validators who are the second type of participant. By appointing @@ -68,7 +67,7 @@ estimate your earnings and this is where it's good to start picking favorites. The "Waiting" subsection ([link](https://polkadot.js.org/apps/#/staking/waiting)) lists all pending validators that are awaiting more nominations to enter the active validator set. Validators will stay in the waiting queue until they have enough KSM backing them (as allocated through the -[Phragmén election mechanism](learn-phragmen.md)). It is possible validator can remain in the queue +[Phragmén election mechanism](../../learn/learn-phragmen.md)). It is possible validator can remain in the queue for a very long time if they never get enough backing. The "Validator Stats" subsection ([link](https://polkadot.js.org/apps/#/staking/query)) allows you @@ -79,7 +78,7 @@ Pick "Account actions" underneath "Network" > "Staking", then click the "+ Nomin You will see a modal window that looks like the below: -![nominator-update-1](assets/kusama/kusama_nominator_popup.png) +![nominator-update-1](../../assets/kusama/kusama_nominator_popup.png) Select a "value bonded" that is **less** than the total amount of KSM you have, so you have some left over to pay transaction fees. Transaction fees are currently at least 0.01 KSM, but they are @@ -93,7 +92,7 @@ Choose whatever payment destination that makes sense to you. If you're unsure, y account (increase amount at stake)" to simply accrue the rewards into the amount you're staking and earn compound interest. -![Payout account selection dropdown with the custom account option highlighted](assets/payout/01.png) +![Payout account selection dropdown with the custom account option highlighted](../../assets/payout/01.png) > These concepts have been further explained in Polkadot's > [UI Walkthrough Video](https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8) @@ -101,14 +100,14 @@ earn compound interest. ### Step 2: Nominate a validator You are now bonded. Being bonded means your tokens are locked and could be -[slashed](learn-staking.md#slashing) if the validators you nominate misbehave. All bonded funds can -now be distributed to up to 24 validators. Be careful about the validators you choose since you will +[slashed](../../learn/learn-staking.md#slashing) if the validators you nominate misbehave. All bonded funds can +now be distributed to up to 16 validators. Be careful about the validators you choose since you will be slashed if your validator commits an offence. Click on "Nominate" on an account you've bonded and you will be presented with another popup asking you to select some validators. -![Nominating validators](assets/kusama/kusama_nominator_selection.png) +![Nominating validators](../../assets/kusama/kusama_nominator_selection.png) Select them, confirm the transaction, and you're done - you are now nominating. Your nominations will become active in the next era. Eras last six hours on Kusama - depending on when you do this, @@ -120,14 +119,14 @@ Assuming at least one of your nominations ends up in the active validator set, y rewards allocated to you. In order to claim them (i.e., add them to your account), you must manually claim them. To initiate a claim, you can do it yourself or have the validator that you staked for initiate a claim. This is to help optimize the effectiveness and storage of payouts on Kusama. See -the [Claiming Rewards](learn-staking.md#claiming-rewards) section of the Staking wiki page for more +the [Claiming Rewards](../../learn/learn-staking.md#claiming-rewards) section of the Staking wiki page for more details. ### Step 3: Stop nominating At some point, you might decide to stop nominating one or more validators. You can always change who you're nominating, but you cannot withdraw your tokens unless you unbond them. Detailed instructions -are available [here](maintain-guides-how-to-unbond.md). +are available [here](../maintain-guides-how-to-unbond.md). ## Using Command-Line Interface (CLI) @@ -204,5 +203,5 @@ After a few seconds, you should see the hash of the transaction and if you would nomination status, you can check that on the Polkadot-JS UI as well. [validators]: maintain-guides-how-to-validate-kusama.md -[keys]: learn-keys.md###"controller"-and-"stash"-keys -[account generation]: learn-account-generation.md +[keys]: ../../learn/learn-keys.md###"controller"-and-"stash"-keys +[account generation]: ../../learn/learn-account-generation.md diff --git a/docs/maintain/kusama/maintain-guides-how-to-validate-kusama.md b/docs/maintain/kusama/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..994eede8d289 --- /dev/null +++ b/docs/maintain/kusama/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,526 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +slug: ../../maintain-guides-how-to-validate-kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not +only your own stake, but also the stake of your current nominators. If you make a mistake and get +slashed, your money and your reputation will be at risk. However, running a validator can also be +very rewarding, knowing that you contribute to the security of a decentralized network while growing +your stash. + +**Warning:** It is highly recommended that you have significant system administration experience +before attempting to run your own validator. + +Since security is so important to running a successful validator, you should take a look at the +[validator setup](../maintain-guides-secure-validator.md) information to make you understand the +factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a +[reference implementation for a validator set-up](https://github.com/w3f/polkadot-validator-setup) +that you can use by deploying yourself. As you progress in your journey as a validator, you will +likely want to use this repository as a _starting point_ for your own modifications and +customizations. + +If you need help, please reach out on the +[Kusama validator chat](https://app.element.io/#/room/#KusamaValidatorLounge:polkadot.builders) on +Matrix. The team and other validators are there to help answer questions and provide experience. You +can join directly in your web browser (link above) or using a client such as Element (formerly +Riot.im) using [this link](https://matrix.to/#/#KusamaValidatorLounge:polkadot.builders). + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed +[here](../../general/faq.md#What-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator-?). +Validators are elected based on [Phragmén's algorithm](../../learn/learn-phragmen.md). To be elected into the +set, you need a minimum stake behind your validator. This stake can come from yourself or from +[nominators](../../learn/learn-nominator.md). This means that as a minimum, you will need enough KSM to set up +Stash and Controller [accounts](../../learn/learn-keys.md) with the existential deposit, plus a little extra for +transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an +insecure or improper setup may result in loss of KSM tokens! If you are not confident in your +ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node +instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may +choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are +comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be +similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that +validators run at least the standard hardware in order to ensure they are able to process all blocks +in time. The following are not _minimum requirements_ but if you decide to run with less than this +beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see +[here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. + Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to + be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a +validator, however you should be aware that if you are using less you may need to toggle some extra +optimizations in order to be equal to other validators that are running the standard. + +### Node Prerequisites: Install Rust and Dependencies + +Once you choose your cloud service provider and set-up your new server, the first thing you will do +is install Rust. + +If you have never installed Rust, you should do this first. + +If you have already installed Rust, run the following command to make sure you are using the latest +version. + +```sh +rustup update +``` + +If not, this command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh -s -- -y +``` + +> If you do not have "curl" installed, run "sudo apt install curl" + +To configure your shell, run the following command. + +```sh +source $HOME/.cargo/env +``` + +Verify your installation. + +```sh +rustc --version +``` + +Finally, run this command to install the necessary dependencies for compiling and running the +Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the +following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to +synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all +the systems within the network. Currently it is required that validators' local clocks stay +reasonably in sync, so you should be running NTP or a similar service. You can check whether you +have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar +message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to +verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. +> If the clock is out of sync (even by a small amount), the blocks the validator produces may not +> get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but +> zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the +[paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source +code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, +but you should review the output from the "git tag" command to see a list of all the potential 0.8 +releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can +also find the latest Kusama version on the +[release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with +> `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +``` + +Run the following command to find the latest version. + +```sh +git tag -l | sort -V | grep -v -- '-rc' +``` + +Find the latest version; replace "VERSION" in the commmand below and run to change your branch. + +```sh +git checkout VERSION +./scripts/init.sh +``` + +Build native code with the cargo release profile. + +```sh +cargo build --release +``` + +**_This step will take a while (generally 10 - 40 minutes, depending on your hardware)._** + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be +> done by running: +> +> ```sh +> rustup install nightly-2021-06-09 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2021-06-09 +> cargo +nightly-2021-06-09 build --release +> ``` +> +> You may also need to run the build more than once. +> +> If you would like to execute the tests, run the following command: +> +> ```sh +> cargo test --all +> ``` + +If you are interested in generating keys locally, you can also install `subkey` from the same +directory. You may then take the generated `subkey` executable and transfer it to an air-gapped +machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not +> in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure +> that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: +> `--unsafe-pruning --pruning `, but note that an archive node and non-archive +> node's databases are not compatible with each other, and to switch you will need to purge the +> chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +``` +2021-06-17 02:34:25 ---------------------------- +2021-06-17 02:34:25 This chain is not in any way +2021-06-17 02:34:25 endorsed by the +2021-06-17 02:34:25 KUSAMA FOUNDATION +2021-06-17 02:34:25 ---------------------------- +2021-06-17 02:34:25 Parity Polkadot +2021-06-17 02:34:25 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu +2021-06-17 02:34:25 ❤️ by Parity Technologies , 2017-2021 +2021-06-17 02:34:25 📋 Chain specification: Kusama +2021-06-17 02:34:25 🏷 Node name: obtainable-kitten-0716 +2021-06-17 02:34:25 👤 Role: FULL +2021-06-17 02:34:25 💾 Database: RocksDb at /root/.local/share/polkadot/chains/ksmcc3/db +2021-06-17 02:34:25 ⛓ Native runtime: kusama-9050 (parity-kusama-0.tx5.au2) +2021-06-17 02:34:25 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) +2021-06-17 02:34:25 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. +2021-06-17 02:34:26 ⏱ Loaded block-time = 6s from block 0xb0a8d493285c2df73290dfb7e61f870f17b41801197a149ca93654499ea3dafe +2021-06-17 02:34:26 👶 Creating empty BABE epoch changes on what appears to be first startup. +2021-06-17 02:34:26 🏷 Local node identity is: 12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB +2021-06-17 02:34:26 📦 Highest known block at #0 +2021-06-17 02:34:26 〽️ Prometheus server started at 127.0.0.1:9615 +2021-06-17 02:34:26 Listening for new connections on 127.0.0.1:9944. +``` + +Example of node sync: + +``` +2021-06-17 02:34:34 🔍 Discovered new external address for our node: /ip4/100.102.231.64/tcp/30333/ws/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB +2021-06-17 02:34:36 ⚙️ Syncing 409.2 bps, target=#8062689 (5 peers), best: #3477 (0x63ad…e046), finalized #3072 (0x0e4c…f587), ⬇ 153.2kiB/s ⬆ 12.9kiB/s +2021-06-17 02:34:37 🔍 Discovered new external address for our node: /ip4/100.111.175.0/tcp/30333/ws/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB +2021-06-17 02:34:38 🔍 Discovered new external address for our node: /ip4/100.100.176.0/tcp/30333/ws/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB +2021-06-17 02:34:41 ⚙️ Syncing 386.2 bps, target=#8062690 (7 peers), best: #5409 (0x1d76…8c3d), finalized #5121 (0x8ad1…b6dc), ⬇ 96.1kiB/s ⬆ 10.9kiB/s +2021-06-17 02:34:46 ⚙️ Syncing 394.8 bps, target=#8062691 (11 peers), best: #7383 (0x0689…6f1e), finalized #7168 (0x72a9…8d8c), ⬇ 352.9kiB/s ⬆ 5.1kiB/s +2021-06-17 02:34:51 ⚙️ Syncing 347.0 bps, target=#8062692 (12 peers), best: #9118 (0x66fc…cce3), finalized #8704 (0x14c9…705e), ⬇ 62.7kiB/s ⬆ 1.7kiB/s +``` + +The `--pruning=archive` flag is implied by the `--validator` flag, so it is only +required explicitly if you start your node without one of these two options. If you do not set your +pruning to archive node, even when not running in validator, you will need to +re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can +> be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note +> that **ParityDB is still experimental and should not be used in production.** If you want to test +> out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will +> require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes +to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to +STDOUT from the `polkadot` process) will tell you the latest block your node has processed and +verified. You can then compare that to the current highest block via +[Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the +[Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. +For this, you will create two accounts and make sure each of them have at least enough funds to pay +the fees for making transactions. Keep most of your funds in the stash account since it is meant to +be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from +your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network + and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on +"Account Actions", and then the "New stake" button. + +![dashboard bonding](../../assets/guides/how-to-validate/kusama-dashboard-bonding.png) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make + sure that your Stash account contains _at least_ this much. You can, of course, stake more than + this. +- **Controller account** - Select the Controller account created earlier. This account will also + need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do + not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM + later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On + Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info + [here](../../learn/learn-staking.md#reward-distribution). Starting with runtime version v2023 natively + included in client version [0.9.3](https://github.com/paritytech/polkadot/releases/tag/v0.9.3), + payouts can go to any custom address. If you'd like to redirect payments to an account that is + neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set + an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash +account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card +with all your accounts (note: you may need to refresh the screen). The bonded amount on the right +corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the +> current session keys that you made the `setKeys` transaction then you can use one of the two +> available RPC methods to query your node: +> [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) +> to check for a specific key or +> [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) +> to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you +will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for +some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +Similarly: + +``` +2021-06-17 02:47:05 ---------------------------- +2021-06-17 02:47:05 This chain is not in any way +2021-06-17 02:47:05 endorsed by the +2021-06-17 02:47:05 KUSAMA FOUNDATION +2021-06-17 02:47:05 ---------------------------- +2021-06-17 02:47:05 Parity Polkadot +2021-06-17 02:47:05 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu +2021-06-17 02:47:05 ❤️ by Parity Technologies , 2017-2021 +2021-06-17 02:47:05 📋 Chain specification: Kusama +2021-06-17 02:47:05 🏷 Node name: techedtest +2021-06-17 02:47:05 👤 Role: AUTHORITY +2021-06-17 02:47:05 💾 Database: RocksDb at /root/.local/share/polkadot/chains/ksmcc3/db +2021-06-17 02:47:05 ⛓ Native runtime: kusama-9050 (parity-kusama-0.tx5.au2) +2021-06-17 02:47:07 🏷 Local node identity is: 12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB +2021-06-17 02:47:07 📦 Highest known block at #139917 +2021-06-17 02:47:07 〽️ Prometheus server started at 127.0.0.1:9615 +2021-06-17 02:47:07 Listening for new connections on 127.0.0.1:9944. +2021-06-17 02:47:07 👶 Starting BABE Authorship worker +``` + +``` +2021-06-17 02:48:15 🔍 Discovered new external address for our node: /ip4/10.2.99.4/tcp/30333/p2p/12D3KooWLE7ivpuXJQpFVP4fuuutAqEsk8nrNEpuR3tddqnXgLPB + +2021-06-17 02:48:17 ⚙️ Syncing 235.6 bps, target=#8062826 (49 peers), best: #155136 (0x23ea…e4fc), finalized #154624 (0x234f…f6a0), ⬇ 380.0kiB/s ⬆ 57.4kiB/s +``` + +You can give your validator any name that you like, but note that others will be able to see it, and +it will be included in the list of all servers using the same telemetry server. Since numerous +people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what +associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](../../learn/learn-keys.md#session-keys) in the client via the apps RPC. If +you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator +node. You can configure the apps dashboard to connect to the endpoint of your validator in the +Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you +will not be able to use this method since making RPC requests to this node would effect the local +keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore +for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your +node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's +keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option +and remember to save the output that you get back for a later step. + +![Explorer RPC call](../../assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node +is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four +public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what +associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set +Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` +in the field and click "Set Session Key". + +![staking-change-session](../../assets/guides/how-to-validate/kusama-set-session-key-1.png) +![staking-session-result](../../assets/guides/how-to-validate/kusama-set-session-key-2.png) + +Submit this extrinsic and you are now ready to start validating. + +### Setup via Validator Tab + +![dashboard validate](../../assets/guides/how-to-validate/kusama-dashboard-validate-1.png) + +Here you will need to input the Keys from `rotateKeys`, which is the Hex output from +`author_rotateKeys`. The keys will show as pending until applied at the start of a new session. + +The "reward commission percentage" is the commission percentage that you can declare against your +validator's rewards. This is the rate that your validator will be commissioned with. + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. + The remaining will be split among your nominators. + +> Note: setting a commission rate of 100% suggests that you do not want your validator to receive +> nominations. + +You can also determine if you would like to receive nominations with the "allows new nominations" +option. + +![dashboard validate](../../assets/guides/how-to-validate/kusama-dashboard-validate-2.png) + +Click "Bond & Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the +network. At the top of the page, it shows how many validator slots are available as well as how many +nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to +double check to see whether your node is listed there. + +![staking queue](../../assets/guides/how-to-validate/kusama-dashboard-staking.png) + +The validator set is refreshed every era. In the next era, if there is a slot available and your +node is selected to join the validator set, your node will become an active validator. Until then, +it will remain in the _waiting_ queue. If your validator is not selected to become part of the +validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if +you are not selected for the validator set in a particular era. However, it may be necessary to +increase the number of KSM staked or seek out nominators for your validator in order to join the +validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the +validator set, you are now running a Kusama validator! If you need help, reach out on the +[Kusama forum](https://forum.kusama.network/) or in the +[Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies +to provide support for community validators. If you are interested in applying for the programme, +you can find more information [on the wiki page](../../general/thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](../../assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover +other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build +the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/docs/maintain/kusama/maintain-guides-society-kusama.md b/docs/maintain/kusama/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..ceba4ed601c9 --- /dev/null +++ b/docs/maintain/kusama/maintain-guides-society-kusama.md @@ -0,0 +1,183 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +slug: ../../maintain-guides-society-kusama +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society][substrate pallet] pallet. It is an +economic game to incentivize users to join a society that coordinates around whatever the rules are +decided to be. The members of the society are incentivized to participate in the society via the +rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to +have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](../../assets/kusama/kusama_society_page.png) +![Society Dashboard](../../assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the +[Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the +[rules][kappa rules] to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set + to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the + society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their + membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the + number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend + their membership in the society. The rules for defending the membership are documented [in the + rules][kappa rules]. + +## Procedure + +Remember to take a look at the [rules][kappa rules] first. And since those rules are not enforced +entirely on-chain, it is recommended to join the +[Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask +any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the +[Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to +create a bid on their behalf by vouching for them. At every rotation period, as many bids as the +society pot can support will be selected. The selected bids will be moved to the candidate phase, +whereas bids that were not selected will stay in the bidder pool until they are selected or a user +chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and +declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](../../assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the +[Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can +cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same +page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are +willing to give them a tip. An existing member can submit a `vouch` transaction through the +Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](../../assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you +will be approved to join the society. Members will vote for all the candidates and the final outcome +will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each +> rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a +final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the +candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If +they do not participate in voting, they will be punished with one strike per missing vote. If one +accumulates too many strikes, one's membership is suspended which means they may need to re-apply +and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the +randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this +case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the +selected vote as a reward for participating in the vote. The reward is escrowed for some period of +time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you +have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula +is defined [in the society pallet][substrate pallet] if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50_000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15_552_000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was +placed by a voucher, they will get back the reward that was set during vouching with the remainder +given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the +`Suspension Judgement Origin`) to determine if the candidate should go through the bidding process +again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during +the bidding. A few things you need to be aware of. First, you should vote on candidates who applied +for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It +is the same as the above mentioned lock-up formula. + +![Society Payout](../../assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will +be randomly selected as a defender. Then, other members can vote whether this defender should stay +in the society or not. A simple majority wins the vote. You can take a look [here][kappa rules] and +search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user +apply for the membership and requesting a tip. This is useful when a user does not have enough +balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the +> deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become +suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the +suspension judgment origin to determine if the member should re-enter society or be removed from +society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - +Rules about joining the Kusama society + +[substrate pallet]: https://substrate.dev/rustdocs/latest/pallet_society/index.html +[kappa rules]: https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17 diff --git a/docs/maintain/maintain-errors.md b/docs/maintain/maintain-errors.md new file mode 100644 index 000000000000..469782eadaf8 --- /dev/null +++ b/docs/maintain/maintain-errors.md @@ -0,0 +1,304 @@ +--- +id: maintain-errors +title: Errors and How to Resolve Them +sidebar_label: Resolving Errors +slug: ../maintain-errors +--- + +Errors in Substrate-based chains are usually accompanied by descriptive messages. However, to read +these messages, a tool parsing the blockchain data needs to request _chain metadata_ from a node. +That metadata explains how to read the messages. One such tool with a built-in parser for chain +metadata is the [Polkadot-JS Apps UI](https://polkadot.js.org/apps). + +If this page does not answer your question, try searching for your problem at the +[Polkadot Knowledge Base](https://support.polkadot.network/) for more information on troubleshooting +your issue. + +## PolkadotJS Apps Explorer + +Here's how to find out the detailed error description through Polkadot-JS Apps. + +A typical failed transactions looks something like this: + +![Error while sending a transaction](../assets/errors/01.jpg) + +The image displays only the error name as defined in the code, not its error message. Despite this +error being rather self-explanatory, let's find its details. + +In the [explorer tab](https://polkadot.js.org/apps/#/explorer), find the block in which this failure +occured. Then, expand the `system.ExtrinsicFailed` frame: + +![Error described](../assets/errors/02.jpg) + +Notice how the `details` field contains a human-readable description of the error. Most errors will +have this, if looked up this way. + +[This block](https://polkadot.js.org/apps/#/explorer/query/0xa10104ed21dfe409c7871a975155766c5dd97e1e2ac7faf3c90f1f8dca89104b) +is a live example of the above. + +If you cannot look up the error this way, or there is no message in the `details` field, consult the +table below. + +## Polkascan and Subscan + +Polkascan and Subscan show the `ExtrinsicFailed` event when a transaction does not succeed +([example](https://polkascan.io/polkadot/event/2836233-3)). This event gives us the `error` and +`index` indices of the error but does not give us a nice message to understand what it means. We +will look up the error in the codebase ourselves to understand what went wrong. + +First, we should understand that the `index` number is the index of the pallet in the runtime from +which the error originated. The `error` is likewise the index of that pallet's errors which is the +exact one we're looking for. Both of these indices start counting from 0. + +For example, if `index` is 5 and `error` is 3, as in the example linked above, we need to look at +the runtime for the fourth error (index 3) in the sixth pallet (index 5). + +By looking at the +[runtime code](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L965) +we see that the pallet at index 5 is +[Balances](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L981). Now +we will check the Balances pallet's code which is hosted in the Substrate repository, and look for +the fourth error in the Error enum. According to +[its source](https://github.com/paritytech/substrate/blob/master/frame/balances/src/lib.rs#L396) the +error that we got is +[InsufficientBalance](https://github.com/paritytech/substrate/blob/master/frame/balances/src/lib.rs#L402) +or in other words "Balance too low to send value". + +## Common Errors + +The table below lists the most commonly encountered errors and ways to resolve them. + +| Error | Description | Solution | +| ------------------ | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| BadOrigin | You are not allowed to do this operation, e.g. trying to create a council motion with a non-council account. | Either switch to an account that has the necessary permissions, or check if the operation you're trying to execute is permitted at all (e.g. calling `system.setCode` to do a runtime upgrade directly, without voting). | +| BadProof | The transaction's signature seems invalid. | It's possible that the node you're connected to is following an obsolete fork - trying again after it catches up usually resolves the issue. To check for bigger problems, inspect the last finalized and current best block of the node you're connected to and compare the values to chain stats exposed by other nodes - are they in sync? If not, try connecting to a different node. | +| Future | Transaction nonce too high, i.e. it's "from the future". | Reduce the nonce to +1 of current nonce. Check current nonce by inspecting the address you're using to send the transaction. | +| Stale | Transaction nonce too low. | Increase the nonce to +1 of current nonce. Check current nonce by inspecting the address you're using to send the transaction. | +| ExhaustsResources | There aren't enough resources left in the current block to submit this transaction. | Try again in the next block. | +| Payment | Unable to pay for TX fee. | You might not have enough free balance to cover the fee this transaction would incur. | +| Temporarily banned | The transaction is temporarily banned. | The tx is already in pool. Either try on a different node, or wait to see if the initial transaction goes through. | + +## Error Table + +The below table is a reference to the errors that exists in Polkadot. It is generated from the +runtime's metadata. + +| Pallet | Error | Documentation | +| ----------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | +| System (0) | | | +| | InvalidSpecName (0) | The name of specification does not match between the current runtime and the new runtime. | +| | SpecVersionNeedsToIncrease (1) | The specification version is not allowed to decrease between the current runtime and the new runtime. | +| | FailedToExtractRuntimeVersion (2) | Failed to extract the runtime version from the new runtime. Either calling `Core_version` or decoding `RuntimeVersion` failed. | +| | NonDefaultComposite (3) | Suicide called when the account has non-default composite data. | +| | NonZeroRefCount (4) | There is a non-zero reference count preventing the account from being purged. | +| Scheduler (1) | | | +| | FailedToSchedule (0) | Failed to schedule a call | +| | NotFound (1) | Cannot find the scheduled call. | +| | TargetBlockNumberInPast (2) | Given target block number is in the past. | +| | RescheduleNoChange (3) | Reschedule failed because it does not change scheduled time. | +| Balances (5) | | | +| | VestingBalance (0) | Vesting balance too high to send value | +| | LiquidityRestrictions (1) | Account liquidity restrictions prevent withdrawal | +| | Overflow (2) | Got an overflow after adding | +| | InsufficientBalance (3) | Balance too low to send value | +| | ExistentialDeposit (4) | Value too low to create account due to existential deposit | +| | KeepAlive (5) | Transfer/payment would kill account | +| | ExistingVestingSchedule (6) | A vesting schedule already exists for this account | +| | DeadAccount (7) | Beneficiary account must pre-exist | +| Authorship (6) | | | +| | InvalidUncleParent (0) | The uncle parent not in the chain. | +| | UnclesAlreadySet (1) | Uncles already set in the block. | +| | TooManyUncles (2) | Too many uncles. | +| | GenesisUncle (3) | The uncle is genesis. | +| | TooHighUncle (4) | The uncle is too high in chain. | +| | UncleAlreadyIncluded (5) | The uncle is already included. | +| | OldUncle (6) | The uncle isn't recent enough to be included. | +| Staking (7) | | | +| | NotController (0) | Not a controller account. | +| | NotStash (1) | Not a stash account. | +| | AlreadyBonded (2) | Stash is already bonded. | +| | AlreadyPaired (3) | Controller is already paired. | +| | EmptyTargets (4) | Targets cannot be empty. | +| | DuplicateIndex (5) | Duplicate index. | +| | InvalidSlashIndex (6) | Slash record index out of bounds. | +| | InsufficientValue (7) | Can not bond with value less than minimum balance. | +| | NoMoreChunks (8) | Can not schedule more unlock chunks. | +| | NoUnlockChunk (9) | Can not rebond without unlocking chunks. | +| | FundedTarget (10) | Attempting to target a stash that still has funds. | +| | InvalidEraToReward (11) | Invalid era to reward. | +| | InvalidNumberOfNominations (12) | Invalid number of nominations. | +| | NotSortedAndUnique (13) | Items are not sorted and unique. | +| | AlreadyClaimed (14) | Rewards for this era have already been claimed for this validator. | +| | OffchainElectionEarlySubmission (15) | The submitted result is received out of the open window. | +| | OffchainElectionWeakSubmission (16) | The submitted result is not as good as the one stored on chain. | +| | SnapshotUnavailable (17) | The snapshot data of the current window is missing. | +| | OffchainElectionBogusWinnerCount (18) | Incorrect number of winners were presented. | +| | OffchainElectionBogusWinner (19) | One of the submitted winners is not an active candidate on chain (index is out of range in snapshot). | +| | OffchainElectionBogusCompact (20) | Error while building the assignment type from the compact. This can happen if an index is invalid, or if the weights _overflow_. | +| | OffchainElectionBogusNominator (21) | One of the submitted nominators is not an active nominator on chain. | +| | OffchainElectionBogusNomination (22) | One of the submitted nominators has an edge to which they have not voted on chain. | +| | OffchainElectionSlashedNomination (23) | One of the submitted nominators has an edge which is submitted before the last non-zero slash of the target. | +| | OffchainElectionBogusSelfVote (24) | A self vote must only be originated from a validator to ONLY themselves. | +| | OffchainElectionBogusEdge (25) | The submitted result has unknown edges that are not among the presented winners. | +| | OffchainElectionBogusScore (26) | The claimed score does not match with the one computed from the data. | +| | OffchainElectionBogusElectionSize (27) | The election size is invalid. | +| | CallNotAllowed (28) | The call is not allowed at the given time due to restrictions of election period. | +| | IncorrectHistoryDepth (29) | Incorrect previous history depth input provided. | +| | IncorrectSlashingSpans (30) | Incorrect number of slashing spans provided. | +| Session (9) | | | +| | InvalidProof (0) | Invalid ownership proof. | +| | NoAssociatedValidatorId (1) | No associated validator ID for account. | +| | DuplicatedKey (2) | Registered duplicate key. | +| | NoKeys (3) | No keys are associated with this account. | +| Grandpa (11) | | | +| | PauseFailed (0) | Attempt to signal GRANDPA pause when the authority set isn't live (either paused or already pending pause). | +| | ResumeFailed (1) | Attempt to signal GRANDPA resume when the authority set isn't paused (either live or already pending resume). | +| | ChangePending (2) | Attempt to signal GRANDPA change with one already pending. | +| | TooSoon (3) | Cannot signal forced change so soon after last. | +| | InvalidKeyOwnershipProof (4) | A key ownership proof provided as part of an equivocation report is invalid. | +| | InvalidEquivocationProof (5) | An equivocation proof provided as part of an equivocation report is invalid. | +| | DuplicateOffenceReport (6) | A given equivocation report is valid but already previously reported. | +| ImOnline (12) | | | +| | InvalidKey (0) | Non existent public key. | +| | DuplicatedHeartbeat (1) | Duplicated heartbeat. | +| Democracy (14) | | | +| | ValueLow (0) | Value too low | +| | ProposalMissing (1) | Proposal does not exist | +| | BadIndex (2) | Unknown index | +| | AlreadyCanceled (3) | Cannot cancel the same proposal twice | +| | DuplicateProposal (4) | Proposal already made | +| | ProposalBlacklisted (5) | Proposal still blacklisted | +| | NotSimpleMajority (6) | Next external proposal not simple majority | +| | InvalidHash (7) | Invalid hash | +| | NoProposal (8) | No external proposal | +| | AlreadyVetoed (9) | Identity may not veto a proposal twice | +| | NotDelegated (10) | Not delegated | +| | DuplicatePreimage (11) | Preimage already noted | +| | NotImminent (12) | Not imminent | +| | TooEarly (13) | Too early | +| | Imminent (14) | Imminent | +| | PreimageMissing (15) | Preimage not found | +| | ReferendumInvalid (16) | Vote given for invalid referendum | +| | PreimageInvalid (17) | Invalid preimage | +| | NoneWaiting (18) | No proposals waiting | +| | NotLocked (19) | The target account does not have a lock. | +| | NotExpired (20) | The lock on the account to be unlocked has not yet expired. | +| | NotVoter (21) | The given account did not vote on the referendum. | +| | NoPermission (22) | The actor has no permission to conduct the action. | +| | AlreadyDelegating (23) | The account is already delegating. | +| | Overflow (24) | An unexpected integer overflow occurred. | +| | Underflow (25) | An unexpected integer underflow occurred. | +| | InsufficientFunds (26) | Too high a balance was provided that the account cannot afford. | +| | NotDelegating (27) | The account is not currently delegating. | +| | VotesExist (28) | The account currently has votes attached to it and the operation cannot succeed until these are removed, either through `unvote` or `reap_vote`. | +| | InstantNotAllowed (29) | The instant referendum origin is currently disallowed. | +| | Nonsense (30) | Delegation to oneself makes no sense. | +| | WrongUpperBound (31) | Invalid upper bound. | +| | MaxVotesReached (32) | Maximum number of votes reached. | +| | InvalidWitness (33) | The provided witness data is wrong. | +| | TooManyProposals (34) | Maximum number of proposals reached. | +| Council (15) | | | +| | NotMember (0) | Account is not a member | +| | DuplicateProposal (1) | Duplicate proposals not allowed | +| | ProposalMissing (2) | Proposal must exist | +| | WrongIndex (3) | Mismatched index | +| | DuplicateVote (4) | Duplicate vote ignored | +| | AlreadyInitialized (5) | Members are already initialized! | +| | TooEarly (6) | The close call was made too early, before the end of the voting. | +| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | +| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | +| | WrongProposalLength (9) | The given length bound for the proposal was too low. | +| TechnicalCommittee (16) | | | +| | NotMember (0) | Account is not a member | +| | DuplicateProposal (1) | Duplicate proposals not allowed | +| | ProposalMissing (2) | Proposal must exist | +| | WrongIndex (3) | Mismatched index | +| | DuplicateVote (4) | Duplicate vote ignored | +| | AlreadyInitialized (5) | Members are already initialized! | +| | TooEarly (6) | The close call was made too early, before the end of the voting. | +| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | +| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | +| | WrongProposalLength (9) | The given length bound for the proposal was too low. | +| ElectionsPhragmen (17) | | | +| | UnableToVote (0) | Cannot vote when no candidates or members exist. | +| | NoVotes (1) | Must vote for at least one candidate. | +| | TooManyVotes (2) | Cannot vote more than candidates. | +| | MaximumVotesExceeded (3) | Cannot vote more than maximum allowed. | +| | LowBalance (4) | Cannot vote with stake less than minimum balance. | +| | UnableToPayBond (5) | Voter can not pay voting bond. | +| | MustBeVoter (6) | Must be a voter. | +| | ReportSelf (7) | Cannot report self. | +| | DuplicatedCandidate (8) | Duplicated candidate submission. | +| | MemberSubmit (9) | Member cannot re-submit candidacy. | +| | RunnerSubmit (10) | Runner cannot re-submit candidacy. | +| | InsufficientCandidateFunds (11) | Candidate does not have enough funds. | +| | NotMember (12) | Not a member. | +| | InvalidCandidateCount (13) | The provided count of number of candidates is incorrect. | +| | InvalidVoteCount (14) | The provided count of number of votes is incorrect. | +| | InvalidRenouncing (15) | The renouncing origin presented a wrong `Renouncing` parameter. | +| | InvalidReplacement (16) | Prediction regarding replacement after member removal is wrong. | +| Treasury (19) | | | +| | InsufficientProposersBalance (0) | Proposer's balance is too low. | +| | InvalidIndex (1) | No proposal or bounty at that index. | +| | ReasonTooBig (2) | The reason given is just too big. | +| | AlreadyKnown (3) | The tip was already found/started. | +| | UnknownTip (4) | The tip hash is unknown. | +| | NotFinder (5) | The account attempting to retract the tip is not the finder of the tip. | +| | StillOpen (6) | The tip cannot be claimed/closed because there are not enough tippers yet. | +| | Premature (7) | The tip cannot be claimed/closed because it's still in the countdown period. | +| | UnexpectedStatus (8) | The bounty status is unexpected. | +| | RequireCurator (9) | Require bounty curator. | +| | InvalidValue (10) | Invalid bounty value. | +| | InvalidFee (11) | Invalid bounty fee. | +| | PendingPayout (12) | A bounty payout is pending. To cancel the bounty, you must unassign and slash the curator. | +| Claims (24) | | | +| | InvalidEthereumSignature (0) | Invalid Ethereum signature. | +| | SignerHasNoClaim (1) | Ethereum address has no claim. | +| | SenderHasNoClaim (2) | Account ID sending tx has no claim. | +| | PotUnderflow (3) | There's not enough in the pot to pay out some unvested amount. Generally implies a logic error. | +| | InvalidStatement (4) | A needed statement was not included. | +| | VestedBalanceExists (5) | The account already has a vested balance. | +| Vesting (25) | | | +| | NotVesting (0) | The account given is not vesting. | +| | ExistingVestingSchedule (1) | An existing vesting schedule already exists for this account that cannot be clobbered. | +| | AmountLow (2) | Amount being transferred is too low to create a vesting schedule. | +| Identity (28) | | | +| | TooManySubAccounts (0) | Too many subs-accounts. | +| | NotFound (1) | Account isn't found. | +| | NotNamed (2) | Account isn't named. | +| | EmptyIndex (3) | Empty index. | +| | FeeChanged (4) | Fee is changed. | +| | NoIdentity (5) | No identity found. | +| | StickyJudgement (6) | Sticky judgement. | +| | JudgementGiven (7) | Judgement given. | +| | InvalidJudgement (8) | Invalid judgement. | +| | InvalidIndex (9) | The index is invalid. | +| | InvalidTarget (10) | The target is invalid. | +| | TooManyFields (11) | Too many additional fields. | +| | TooManyRegistrars (12) | Maximum amount of registrars reached. Cannot add any more. | +| | AlreadyClaimed (13) | Account ID is already named. | +| | NotSub (14) | Sender is not a sub-account. | +| | NotOwned (15) | Sub-account isn't owned by sender. | +| Proxy (29) | | | +| | TooMany (0) | There are too many proxies registered or too many announcements pending. | +| | NotFound (1) | Proxy registration not found. | +| | NotProxy (2) | Sender is not a proxy of the account to be proxied. | +| | Unproxyable (3) | A call which is incompatible with the proxy type's filter was attempted. | +| | Duplicate (4) | Account is already a proxy. | +| | NoPermission (5) | Call may not be made by proxy because it may escalate its privileges. | +| | Unannounced (6) | Announcement, if made at all, was made too recently. | +| Multisig (30) | | | +| | MinimumThreshold (0) | Threshold must be 2 or greater. | +| | AlreadyApproved (1) | Call is already approved by this signatory. | +| | NoApprovalsNeeded (2) | Call doesn't need any (more) approvals. | +| | TooFewSignatories (3) | There are too few signatories in the list. | +| | TooManySignatories (4) | There are too many signatories in the list. | +| | SignatoriesOutOfOrder (5) | The signatories were provided out of order; they should be ordered. | +| | SenderInSignatories (6) | The sender was contained in the other signatories; it shouldn't be. | +| | NotFound (7) | Multisig operation not found when attempting to cancel. | +| | NotOwner (8) | Only the account that originally created the multisig is able to cancel it. | +| | NoTimepoint (9) | No timepoint was given, yet the multisig operation is already underway. | +| | WrongTimepoint (10) | A different timepoint was given to the multisig operation that is underway. | +| | UnexpectedTimepoint (11) | A timepoint was given, yet no multisig operation is underway. | +| | WeightTooLow (12) | The maximum weight information provided was too low. | +| | AlreadyStored (13) | The data to be stored is already stored. | diff --git a/docs/maintain-guides-democracy.md b/docs/maintain/maintain-guides-democracy.md similarity index 92% rename from docs/maintain-guides-democracy.md rename to docs/maintain/maintain-guides-democracy.md index 65088677fac4..05dbdf8afbbe 100644 --- a/docs/maintain-guides-democracy.md +++ b/docs/maintain/maintain-guides-democracy.md @@ -2,19 +2,20 @@ id: maintain-guides-democracy title: Participate in Democracy sidebar_label: Participate in Democracy +slug: ../maintain-guides-democracy --- The public referenda chamber is one of the three bodies of on-chain governance as it's instantiated in Polkadot and Kusama. The other two bodies are the [council](maintain-guides-how-to-join-council.md) and the -[technical committee](learn-governance.md#technical-committee). +[technical committee](../learn/learn-governance.md#technical-committee). Public referenda can be proposed and voted on by any token holder in the system as long as they provide a bond. After a proposal is made, others can agree with it by _seconding_ it and putting up tokens equal to the original bond. Every launch period, the most seconded proposal will be moved to the public referenda table where it can be voted upon. Voters who are willing to lock up their tokens for a greater duration of time can do so and get their vote amplified. For more details on -the governance system please see [here](learn-governance.md). +the governance system please see [here](../learn/learn-governance.md). This guide will instruct token holders how to propose and vote on public referenda using the Democracy module as it's implemented in Kusama. @@ -61,14 +62,14 @@ proposal may look something like the below image. The preimage hash would be hash and save it for the next step. There is no need to click Submit Preimage at this point, though you could. We'll go over that in the next section. -![submit preimage](assets/democracy/submit_preimage.png) +![submit preimage](../assets/democracy/submit_preimage.png) Now you will click on the "Submit proposal" button and enter the preimage hash in the input titled "preimage hash" and _at least_ the minimum deposit into the "locked balance" field. Click on the blue "Submit proposal" button and confirm the transaction. You should now see your proposal appear in the "proposals" column on the page. -![submit proposal](assets/democracy/submit_proposal.png) +![submit proposal](../assets/democracy/submit_proposal.png) Now your proposal is visible by anyone who accesses the chain and others can second it or submit a preimage. However, it's hard to tell what exactly this proposal does since it shows the hash of the @@ -76,7 +77,7 @@ action. Other holders will not be able to make a judgement for whether they seco someone submits the actual preimage for this proposal. In the next step you will submit the preimage. -![proposals](assets/democracy/proposals.png) +![proposals](../assets/democracy/proposals.png) ## Submitting a Preimage @@ -93,12 +94,12 @@ Click on the blue "Submit preimage" button and configure it to be the same as wh acquire the preimage hash. This time, instead of copying the hash to another tab, you will follow through and click "Submit preimage" and confirm the transaction. -![submit preimage](assets/democracy/submit_preimage.png) +![submit preimage](../assets/democracy/submit_preimage.png) Once the transaction is included you should see the UI update with the information for your already submitted proposal. -![proposals updated](assets/democracy/proposals_updated.png) +![proposals updated](../assets/democracy/proposals_updated.png) ## Seconding a Proposal @@ -122,16 +123,16 @@ restrictions are made on the number of times a single account can second a propo To second a proposal, navigate to the proposal you want to second and click on the "Second" button. -![second button](assets/democracy/second_button.png) +![second button](../assets/democracy/second_button.png) You will be prompted with the full details of the proposal (if the preimage has been submitted!) and can then broadcast the transaction by clicking the blue "Second" button. -![second confirm](assets/democracy/second_confirm.png) +![second confirm](../assets/democracy/second_confirm.png) Once successful you will see your second appear in the dropdown in the proposal details. -![second result](assets/democracy/second_result.png) +![second result](../assets/democracy/second_result.png) ## Voting on a Proposal @@ -160,11 +161,11 @@ you can make your vote count for 600% of the tokens that you hold. When you are comfortable with the decision you have made, click the blue "Vote" button to submit your transaction and wait for it to be included in a block. -![voting](assets/democracy/voting.png) +![voting](../assets/democracy/voting.png) ## Unlocking Locked Tokens -Like [vesting](learn-DOT.md#lazy-vesting), the tokens that are locked in democracy are unlocked +Like [vesting](../learn/learn-DOT.md#lazy-vesting), the tokens that are locked in democracy are unlocked lazily. This means that you, the user, must explicitly call an unlock extrinsic to make your funds available again after the lock expires. Unbonding is another term you hear a lot in Polkadot, it means withdrawing your DOT that was used in staking. To know more about it, please see @@ -175,13 +176,13 @@ You can do this from the "Accounts" page in First check that your account has a "democracy" lock by opening the details on your balance. In the example below the account has 150 KSM locked in democracy. -![democracy balance details](assets/democracy_balance_details.png) +![democracy balance details](../assets/democracy_balance_details.png) Now you can click the menu button on Apps and find the option that says "Clear expired democracy locks". After selecting this option you may confirm the transaction and your locks will be cleared when successful. -![democracy clear locks](assets/democracy_clear_locks.png) +![democracy clear locks](../assets/democracy_clear_locks.png) #### With a Ledger hardware wallet or Unlocking Very Old Locks @@ -200,12 +201,12 @@ The number of the referendum for which you voted is visible in an explorer such You need to press the "Submit Transaction" button to submit the extrinsic. -![democracy clear_lock_extrinsic_1](assets/democracy_clear_lock_extrinsic_1.png) +![democracy clear_lock_extrinsic_1](../assets/democracy_clear_lock_extrinsic_1.png) Now submit the following extrinsic: `democracy.unlock(target)`, where target is your your account address. -![democracy clear_lock_extrinsic_2](assets/democracy_clear_lock_extrinsic_2.png) +![democracy clear_lock_extrinsic_2](../assets/democracy_clear_lock_extrinsic_2.png) If you return to the [Accounts page](https://polkadot.js.org/apps/#/accounts), you should see that the democracy lock has been released. @@ -238,13 +239,13 @@ In the first input select the account you want to delegate to and in the second amount of your conviction. Remember, higher convictions means that your vote will be locked longer. So choose wisely! -![delegate](assets/democracy/delegate.png) +![delegate](../assets/democracy/delegate.png) After you send the delegate transaction, you can verify it went through by navigating to the "Chain State" tab and selecting the "democracy" and "delegations" options. You will see an output similar to below, showing the addresses to which you have delegated your voting power. -![delegate state](assets/democracy/delegate_state.png) +![delegate state](../assets/democracy/delegate_state.png) ## Undelegate a Vote @@ -263,7 +264,7 @@ The easiest way to do this is from the "Extrinsics" tab of Polkadot Apps. Select pallet and the "undelegate" transaction type. Ensure that you are sending the transaction from the account you want to clear of delegations. Click "Submit transaction" and confirm. -![undelegate](assets/democracy/undelegate.png) +![undelegate](../assets/democracy/undelegate.png) ## Voting with a Governance Proxy @@ -273,7 +274,7 @@ pallet, and you will specify the index of the referendum that is being voted, th "Aye" for approval or "Nay" for rejection), and the conviction, just like a normal vote. For more material on adding and removing Governance proxies, as well as other types, please see the -[Proxy page](learn-proxies.md). +[Proxy page](../learn/learn-proxies.md). ## Interpreting On-Chain Voting Data diff --git a/docs/maintain-guides-how-to-chill.md b/docs/maintain/maintain-guides-how-to-chill.md similarity index 96% rename from docs/maintain-guides-how-to-chill.md rename to docs/maintain/maintain-guides-how-to-chill.md index 4b63bd97d223..37a1cc48be7b 100644 --- a/docs/maintain-guides-how-to-chill.md +++ b/docs/maintain/maintain-guides-how-to-chill.md @@ -2,6 +2,7 @@ id: maintain-guides-how-to-chill title: How to Chill sidebar_label: How to Chill +slug: ../maintain-guides-how-to-chill --- Stakers can be in any one of the three states: validating, nominating, or chilling. When a staker @@ -17,7 +18,7 @@ the _stash_. > Note: If you need a refresher on the different responsibilities of the stash and controller > account when staking, take a look at the [accounts][] section in the general staking guide. -![staking](assets/NPoS/staking-keys_stash_controller.png) +![staking](../assets/NPoS/staking-keys_stash_controller.png) ## Chilling as a Nominator @@ -57,7 +58,6 @@ nominator under a heading that says "Redenomination required". If your validator involuntarily chilled, you will need to request your nominators to re-issue the nominate call in order to start nominating you again. - ## Chill Other An unbounded and unlimited number of nominators and validators in Polkadot's NPoS is just not possible due to constraints in the runtime. As a result, multiple checks are incorporated to keep the size of staking system manageable, like mandating minimum active bond requirements for both nominators and validators. When these requirements are modified through on-chain governance, they can be enforced only on the accounts that newly call `nominate` or `validate` after the update. The changes to the bonding parameters would not automatically chill the active accounts on-chain which do not meet the requirements. @@ -65,5 +65,4 @@ An unbounded and unlimited number of nominators and validators in Polkadot's NPo For instance, let us consider a scenario where the minimum staking requirement for nominators is changed from 20 DOTs to 40 DOTs. An account that was actively nominating with 20 DOTs before this update would still keep receiving staking rewards. To handle this corner case, the `chill_other` extrinsic was incorporated which also helps to keep things backwards compatible and safe. The `chill_other` extrinsic is permissionless and any third party user can target it on an account where the minimum active bond is not satisfied, and chill that account. The list of addresses of all the active validators and their nominators can be viewed by running [validator stats](https://github.com/w3f/validator-stats) script. [chill extrinsic]: https://substrate.dev/rustdocs/latest/pallet_staking/pallet/enum.Call.html#variant.chill - -[accounts]: learn-staking.md#accounts +[accounts]: ../learn/learn-staking.md#accounts diff --git a/docs/maintain/maintain-guides-how-to-join-council.md b/docs/maintain/maintain-guides-how-to-join-council.md new file mode 100644 index 000000000000..26ca1519ce8f --- /dev/null +++ b/docs/maintain/maintain-guides-how-to-join-council.md @@ -0,0 +1,62 @@ +--- +id: maintain-guides-how-to-join-council +title: Join the Council +sidebar_label: Join the Council +slug: ../maintain-guides-how-to-join-council +--- + +The council is an elected body of on-chain accounts that are intended to represent the passive +stakeholders of Polkadot and/or Kusama. The council has two major tasks in governance: proposing +referenda and vetoing dangerous or malicious referenda. For more information on the council, see the +[governance page](../learn/learn-governance.md#council). This guide will walk you through entering your +candidacy to the council. + +## Submit Candidacy + +Submitting your candidacy for the council requires a small bond of DOT / KSM. Unless your candidacy +wins, the bond will be forfeited. You can receive your bond back if you manually renounce your +candidacy before losing. Runners-up are selected after every round and are reserved members in case +one of the winners gets forcefully removed. + +> Currently the bond for submitting a council candidacy on Polkadot is 100 DOT, and 0.0033 KSM on +> Kusama. + +It is a good idea to announce your council intention before submitting your candidacy so that your +supporters will know when they can start to vote for you. You can also vote for yourself in case no +one else does. + +Go to [Polkadot Apps Dashboard](https://polkadot.js.org/apps) and navigate to the "Council" tab. +Click the button on the right that says "Submit Candidacy." + +![submit candidancy button](../assets/council/polkadotjs_submit_candidancy.png) + +After making the transaction, you will see your account appear underneath the row "Candidates." + +![candidates list](../assets/council/polkadotjs_candidates.png) + +It is a good idea now to lead by example and give yourself a vote. + +## Voting on Candidates + +Next to the button to submit candidacy is another button titled "Vote." You will click this button +to make a vote for yourself (optional). + +![voting button on UI](../assets/council/polkadotjs_vote_button.png) + +The council uses [Phragmén](../learn/learn-phragmen.md) approval voting, which is also used in the validator +elections. This means that you can choose up to 16 distinct candidates to vote for and your stake +will equalize between them. For this guide, choose to approve your own candidacy by clicking on the +switch next to your account and changing it to say "Aye." + +![voting pop up on UI](../assets/council/polkadotjs_voting.png) + +## Winning + +If you are one of the lucky ones to win a council election you will see your account move underneath +the row "Members". + +![council members list](../assets/council/polkadotjs_council_members.png) + +Now you are able to participate on the council by making motions or voting proposals. To join in on +the active discussions, join the +[Polkadot Direction channel](https://matrix.to/#/#polkadot-direction:matrix.parity.io). diff --git a/docs/maintain/maintain-guides-how-to-monitor-your-node.md b/docs/maintain/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..63009bd43b28 --- /dev/null +++ b/docs/maintain/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,520 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +slug: ../maintain-guides-how-to-monitor-your-node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with +[Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers +to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used +to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` +from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check +the latest release by going to their GitHub repository under the +[releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.26.0.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the +license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named +`prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and +`scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` + controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server + to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor +itself. As we want to have more precise information about the state of the Prometheus server we +reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and +`targets` determine where the exporters are running. The second exporter is capturing the data from +your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running +`promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the +`prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your +server is set up properly. + +```bash +level=info ts=2021-04-16T19:02:20.167Z caller=main.go:380 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2021-04-16T19:02:20.167Z caller=main.go:418 msg="Starting Prometheus" version="(version=2.26.0, branch=HEAD, revision=3cafc58827d1ebd1a67749f88be4218f0bab3d8d)" +level=info ts=2021-04-16T19:02:20.167Z caller=main.go:423 build_context="(go=go1.16.2, user=root@a67cafebe6d0, date=20210331-11:56:23)" +level=info ts=2021-04-16T19:02:20.167Z caller=main.go:424 host_details="(Linux 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 ubuntu2004 (none))" +level=info ts=2021-04-16T19:02:20.167Z caller=main.go:425 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2021-04-16T19:02:20.167Z caller=main.go:426 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2021-04-16T19:02:20.169Z caller=web.go:540 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2021-04-16T19:02:20.170Z caller=main.go:795 msg="Starting TSDB ..." +level=info ts=2021-04-16T19:02:20.171Z caller=tls_config.go:191 component=web msg="TLS is disabled." http2=false +level=info ts=2021-04-16T19:02:20.174Z caller=head.go:696 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2021-04-16T19:02:20.175Z caller=head.go:710 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=1.391446ms +level=info ts=2021-04-16T19:02:20.175Z caller=head.go:716 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2021-04-16T19:02:20.178Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=4 +level=info ts=2021-04-16T19:02:20.193Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=1 maxSegment=4 +level=info ts=2021-04-16T19:02:20.221Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=2 maxSegment=4 +level=info ts=2021-04-16T19:02:20.224Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=3 maxSegment=4 +level=info ts=2021-04-16T19:02:20.229Z caller=head.go:768 component=tsdb msg="WAL segment loaded" segment=4 maxSegment=4 +level=info ts=2021-04-16T19:02:20.229Z caller=head.go:773 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=43.716µs wal_replay_duration=53.973285ms total_replay_duration=55.445308ms +level=info ts=2021-04-16T19:02:20.233Z caller=main.go:815 fs_type=EXT4_SUPER_MAGIC +level=info ts=2021-04-16T19:02:20.233Z caller=main.go:818 msg="TSDB started" +level=info ts=2021-04-16T19:02:20.233Z caller=main.go:944 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2021-04-16T19:02:20.234Z caller=main.go:975 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml totalDuration=824.115µs remote_storage=3.131µs web_handler=401ns query_engine=1.056µs scrape=236.454µs scrape_sd=45.432µs notify=723ns notify_sd=2.61µs rules=956ns +level=info ts=2021-04-16T19:02:20.234Z caller=main.go:767 msg="Server is ready to receive web requests." + +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus +interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create +a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that +it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by +re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the +following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.5.4_amd64.deb +sudo dpkg -i grafana_7.5.4_amd64.deb +``` + +If everything is fine, configure Grafana to auto-start on boot and then start the service. + +```bash +sudo systemctl daemon-reload +sudo systemctl enable grafana-server +sudo systemctl start grafana-server +``` + +You can now access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and +password is admin/admin. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file +> `/usr/share/grafana/conf/defaults.ini` with a command like +> `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something +> else. Then restart grafana with `sudo systemctl restart grafana-server`. + +![grafana-1](../assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](../assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](../assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](../assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click +`Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](../assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left +and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made +public. You can check what other dashboards are available via +[https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we +use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under +the id field and click `Load`. + +![grafana-1](../assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then +click `Import`. + +![grafana-1](../assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, +you should be able to monitor your node's performance such as the current block height, CPU, memory +usage, etc. on the Grafana dashboard. + +![grafana-1](../assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or +notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or +others. In this guide, we will show you how to configure the email notifications using Gmail if your +node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +```bash +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an +`app password` in your Gmail account. For details, click +[here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](../assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted +in the previous command, but that is not of our use. We will create our `alertmanager.yml` file +under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to +change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the +`YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the +command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && sudo systemctl enable alertmanager && sudo systemctl start alertmanager && sudo systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To +install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo systemctl restart grafana-server +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](../assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the +top. + +![grafana-am-2](../assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](../assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is +used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. +Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](../assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following +config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all +the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert +will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 +minutes, an email notification will be sent. If you would like to learn more about the details of +the rule defining, go +[here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other +interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +```bash +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +```bash +sudo -u prometheus promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +```bash +sudo systemctl restart prometheus && sudo systemctl restart alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail +like below. + +![grafana-am-6](../assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/docs/maintain-guides-how-to-nominate-polkadot.md b/docs/maintain/maintain-guides-how-to-nominate-polkadot.md similarity index 92% rename from docs/maintain-guides-how-to-nominate-polkadot.md rename to docs/maintain/maintain-guides-how-to-nominate-polkadot.md index dd941cbf0610..da74ba7e2f48 100644 --- a/docs/maintain-guides-how-to-nominate-polkadot.md +++ b/docs/maintain/maintain-guides-how-to-nominate-polkadot.md @@ -2,6 +2,7 @@ id: maintain-guides-how-to-nominate-polkadot title: How to Nominate on Polkadot sidebar_label: How to Nominate on Polkadot +slug: ../maintain-guides-how-to-nominate-polkadot --- > The following information applies to the Polkadot network. If you want to nominate on Kusama, @@ -67,7 +68,7 @@ estimate your earnings and this is where it's good to start picking favorites. The "Waiting" subsection ([link](https://polkadot.js.org/apps/#/staking/waiting)) lists all pending validators that are awaiting more nominations to enter the active validator set. Validators will stay in the waiting queue until they have enough DOT backing them (as allocated through the -[Phragmén election mechanism](learn-phragmen.md)). It is possible validator can remain in the queue +[Phragmén election mechanism](../learn/learn-phragmen.md)). It is possible validator can remain in the queue for a very long time if they never get enough backing. The "Validator Stats" subsection ([link](https://polkadot.js.org/apps/#/staking/query)) allows you @@ -77,7 +78,7 @@ rewards, and slashes. Pick "Account actions", then click the "+ Nominator" button. You will see a modal window that looks like the below: -![nominator-update-1](assets/polkadotjs_nominate_button.png) +![nominator-update-1](../assets/polkadotjs_nominate_button.png) Select a "value bonded" that is **less** than the total amount of DOT you have, so you have some left over to pay transaction fees. Transaction fees are currently around 0.01 DOT, but they are @@ -91,7 +92,7 @@ Choose whatever payment destination that makes sense to you. If you're unsure, y account (increase amount at stake)" to simply accrue the rewards into the amount you're staking and earn compound interest. -![Payout account selection dropdown with the custom account option highlighted](assets/payout/01.png) +![Payout account selection dropdown with the custom account option highlighted](../assets/payout/01.png) > These concepts have been further explained in Polkadot's > [UI Walkthrough Video](https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8) @@ -99,16 +100,16 @@ earn compound interest. ### Step 2: Nominate a validator You are now bonded. Being bonded means your tokens are locked and could be -[slashed](learn-staking.md#slashing) if the validators you nominate misbehave. All bonded funds can +[slashed](../learn/learn-staking.md#slashing) if the validators you nominate misbehave. All bonded funds can now be distributed to up to 16 validators. Be careful about the validators you choose since you will be slashed if your validator commits an offence. Click on "Nominate" on an account you've bonded and you will be presented with another popup asking you to select up to 16 validators. Although you may choose up to 16 validators, due to the -[Phragmén](learn-phragmen.md) election algorithm your stake may be dispersed in different +[Phragmén](../learn/learn-phragmen.md) election algorithm your stake may be dispersed in different proportions to any subset or all of the validators your choose. -![Nominating validators](assets/polkadotjs_setup_nominator2.png) +![Nominating validators](../assets/polkadotjs_setup_nominator2.png) Select them, confirm the transaction, and you're done - you are now nominating. Your nominations will become active in the next era. Eras last twenty-four hours on Polkadot - depending on when you @@ -118,7 +119,7 @@ in the current era on the [Staking page](https://polkadot.js.org/apps/#/staking) Assuming at least one of your nominations ends up in the active validator set, you will start to get rewards allocated to you. In order to claim them (i.e., add them to your account), you must manually -claim them. See the [Claiming Rewards](learn-staking.md#claiming-rewards) section of the Staking +claim them. See the [Claiming Rewards](../learn/learn-staking.md#claiming-rewards) section of the Staking wiki page for more details. ### Step 3: Stop nominating @@ -203,5 +204,5 @@ After a few seconds, you should see the hash of the transaction and if you would nomination status, you can check that on the Polkadot-JS UI as well. [validators]: maintain-guides-how-to-validate-polkadot.md -[keys]: learn-keys.md###"controller"-and-"stash"-keys -[account generation]: learn-account-generation.md +[keys]: ../learn/learn-keys.md###"controller"-and-"stash"-keys +[account generation]: ../learn/learn-account-generation.md diff --git a/docs/maintain-guides-how-to-setup-a-validator-with-reverse-proxy.md b/docs/maintain/maintain-guides-how-to-setup-a-validator-with-reverse-proxy.md similarity index 84% rename from docs/maintain-guides-how-to-setup-a-validator-with-reverse-proxy.md rename to docs/maintain/maintain-guides-how-to-setup-a-validator-with-reverse-proxy.md index 774cc25cb695..2da42416ec7b 100644 --- a/docs/maintain-guides-how-to-setup-a-validator-with-reverse-proxy.md +++ b/docs/maintain/maintain-guides-how-to-setup-a-validator-with-reverse-proxy.md @@ -2,13 +2,14 @@ id: maintain-guides-how-to-setup-a-validator-with-reverse-proxy title: Set Up a Validator with NGINX Reverse Proxy sidebar_label: Set Up a Validator with NGINX Reverse Proxy +slug: ../maintain-guides-how-to-setup-a-validator-with-reverse-proxy --- -This guide assumes that you have already configured your hardware with the appropriate specs. It has the same configuration +This guide assumes that you have already configured your hardware with the appropriate specs. It has the same configuration as the [polkadot validator setup](https://github.com/w3f/polkadot-secure-validator). -> NOTE: Because validators of parachains need to have publicly accessible IP addresses and ports to receive connections from -> parachain collators, adding a proxy may potentially reduce connectivity and result in lower era points or the inability to +> NOTE: Because validators of parachains need to have publicly accessible IP addresses and ports to receive connections from +> parachain collators, adding a proxy may potentially reduce connectivity and result in lower era points or the inability to > validate parachain blocks. If using a proxy, it's recommended to keep an eye out on networking metrics. We will walk you through how to configure a reverse proxy using NGINX in front of your validator node. The @@ -16,16 +17,17 @@ validator uses the reverse proxy to filter traffic, whereby additional adjustmen ### 1. Firewall configuration -We will configure the firewall with [ufw](https://wiki.ubuntu.com/UncomplicatedFirewall). There needs to be three main ports -for this setup. +We will configure the firewall with [ufw](https://wiki.ubuntu.com/UncomplicatedFirewall). There needs to be three main ports +for this setup. + - An SSH port, commonly ssh/tcp port `22`. -- A proxy port -- p2p port: must be denied at the firewall level. +- A proxy port +- p2p port: must be denied at the firewall level. -In this example, we will assign the port number `2435` to the proxy port and the port number `30333` to the p2p port. +In this example, we will assign the port number `2435` to the proxy port and the port number `30333` to the p2p port. To enable the firewall and the use of the ports, allow SSH access. -> NOTE: For parachains, you will need to allow for both inbound and outbound traffic on the p2p port. Since the proxy +> NOTE: For parachains, you will need to allow for both inbound and outbound traffic on the p2p port. Since the proxy > port is the public-facing port, this will need to have inbound and outbound traffic open, with the normal p2p port closed. ```bash @@ -44,7 +46,9 @@ ufw reload # double check the firewall rules ufw verbose ``` -The `verbose` option shows some extra information about the firewall's behavior. + +The `verbose` option shows some extra information about the firewall's behavior. + ### 2. Basic log viewing We use [journald](https://www.loggly.com/blog/why-journald/) logs for basic log viewing. @@ -95,8 +99,8 @@ events{ } ``` -This will import and make use of the [NGINX stream module](https://nginx.org/en/docs/stream/ngx_stream_core_module.html). -In a nutshell, this module allows for continuous streaming of data in or out of the validator machine with all the benefits +This will import and make use of the [NGINX stream module](https://nginx.org/en/docs/stream/ngx_stream_core_module.html). +In a nutshell, this module allows for continuous streaming of data in or out of the validator machine with all the benefits of having an optimized reverse proxy. Next, create a folder called `/streams-enabled/` inside the `/etc/nginx/` directory and remove the default NGINX site. @@ -108,8 +112,9 @@ mkdir /etc/nginx/streams-enabled /etc/nginx/sites-enabled/default ``` -Now, inside the newly created directory `/etc/nginx/streams-enabled/`, create the proxy service file called -`polkadot-proxy.conf` with the following content: +Now, inside the newly created directory `/etc/nginx/streams-enabled/`, create the proxy service file called +`polkadot-proxy.conf` with the following content: + > Use the previously defined ports: port `2435` for the proxy port & port number `30333` for the p2p port. ```bash @@ -144,12 +149,12 @@ will use to connect to the NGINX reverse proxy. #### P2P Networking Nodes will use [libp2p](https://libp2p.io/) as the networking layer to establish peers and gossip -messages, but uses NGINX as a load balancer which acts as a *first listener* of the streaming data to help +messages, but uses NGINX as a load balancer which acts as a _first listener_ of the streaming data to help balance the load. ##### public-addr -`public-addr` - a flexible encoding of multiple layers of protocols into a human-readable addressing scheme. +`public-addr` - a flexible encoding of multiple layers of protocols into a human-readable addressing scheme. In our example, `/ip4//tcp/` is a valid `public-addr` that specifies wanting the network to reach the validator IPv4 address with TCP packets on the pre-defined proxy port. @@ -159,16 +164,16 @@ specifies wanting the network to reach the validator IPv4 address with TCP packe ##### listen-addr -`listen-addr` - the specification of what port the polkadot application will connect to the reverse proxy. -In our example, `/ip4/0.0.0.0/tcp/` -specifies that you want to listen to NGINX on the localhost address (`0.0.0.0`, or all interfaces), with TCP +`listen-addr` - the specification of what port the polkadot application will connect to the reverse proxy. +In our example, `/ip4/0.0.0.0/tcp/` +specifies that you want to listen to NGINX on the localhost address (`0.0.0.0`, or all interfaces), with TCP packets on the pre-defined p2p port. - `P2P_PORT` - the port that the polkadot application connects to NGINX. #### Starting the validator with the NGINX proxy -After retrieving the appropriate `IP_ADDRESS`, `PROXY_PORT` and `P2P_PORT` of the validator node, we can start the +After retrieving the appropriate `IP_ADDRESS`, `PROXY_PORT` and `P2P_PORT` of the validator node, we can start the validator. Start your validator with the `--validator` flag: diff --git a/docs/maintain-guides-how-to-stop-validating.md b/docs/maintain/maintain-guides-how-to-stop-validating.md similarity index 92% rename from docs/maintain-guides-how-to-stop-validating.md rename to docs/maintain/maintain-guides-how-to-stop-validating.md index 6b6c87c895a1..b6556dd0eedb 100644 --- a/docs/maintain-guides-how-to-stop-validating.md +++ b/docs/maintain/maintain-guides-how-to-stop-validating.md @@ -2,6 +2,7 @@ id: maintain-guides-how-to-stop-validating title: How to Stop Validating sidebar_label: How to Stop Validating +slug: ../maintain-guides-how-to-stop-validating --- If you wish to remain a validator or nominator (e.g. you're only stopping for planned downtime or @@ -21,7 +22,7 @@ extrinsics. To chill your validator or nominator, call the `staking.chill()` extrinsic. See the [How to Chill](maintain-guides-how-to-chill.md) page for more information. You can also -[claim your rewards](learn-simple-payouts.md#claiming-rewards) at this time. +[claim your rewards](../learn/learn-simple-payouts.md#claiming-rewards) at this time. ## Purge validator session keys diff --git a/docs/maintain-guides-how-to-systemd.md b/docs/maintain/maintain-guides-how-to-systemd.md similarity index 94% rename from docs/maintain-guides-how-to-systemd.md rename to docs/maintain/maintain-guides-how-to-systemd.md index f907904a972f..0236be1af01a 100644 --- a/docs/maintain-guides-how-to-systemd.md +++ b/docs/maintain/maintain-guides-how-to-systemd.md @@ -2,15 +2,14 @@ id: maintain-guides-how-to-systemd title: Using systemd for the Validator Node sidebar_label: Using systemd for the Validator Node +slug: ../maintain-guides-how-to-systemd --- - - You can run your validator as a [systemd](https://en.wikipedia.org/wiki/Systemd) process so that it will automatically restart on server reboots or crashes (and helps to avoid getting slashed!). Before following this guide you should have already set up your validator by following the -[How to validate](learn-validator.md) article. +[How to validate](../learn/learn-validator.md) article. First create a new unit file called `polkadot-validator.service` in `/etc/systemd/system/`. diff --git a/docs/maintain/maintain-guides-how-to-unbond.md b/docs/maintain/maintain-guides-how-to-unbond.md new file mode 100644 index 000000000000..77920b071ede --- /dev/null +++ b/docs/maintain/maintain-guides-how-to-unbond.md @@ -0,0 +1,73 @@ +--- +id: maintain-guides-how-to-unbond +title: Unbonding and Rebonding +sidebar_label: Unbonding and Rebonding +slug: ../maintain-guides-how-to-unbond +--- + +The following describes how to stop nominating or validating and retrieve your stake. Please note +that all networks on which you can nominate have a delayed exit period, called the _unbonding +period_, which serves as a cooldown. You will not be able to transfer your tokens before this period +has elapsed, and you will not receive any staking rewards during this period (as you are not +nominating any validators). + +### Step 1: Stop Nominating + +On the [Polkadot-JS Apps][] navigate to the "Staking" tab. + +On this tab click on the "Account Actions" tab at the top of the screen. + +Here, click "Stop Nominating" or "Stop Validating" (depending on your role) on an account you're +staking with and would like to free the funds for. This will "chill" the tokens. + +![Stop Nominating Button](../assets/NPoS/unbond1.png) + +After you confirm this transaction, your tokens will remain _bonded_. This means they stay ready to +be distributed among nominees or used as validator self-stake again. To actually withdraw them, you +need to unbond. + +### Step 2: Unbonding an amount + +To unbond the amount, click the three dots next to the account you want to unbond tokens for, and +select "Unbond funds". + +![Unbonding](../assets/NPoS/unbond2.png) + +Select the amount you wish to unbond and click Unbond, then confirm the transaction. If successful, +your balance will show as "unbonding" with an indicator of how many more blocks remain until the +amount is fully unlocked. + +This duration varies depending on the network you're on and will typically be four times as fast on +Kusama as it is on Polkadot. The unbounding period is 28 days on Polkadot, and 7 on Kusama. + +Once this process is complete, you will have to issue another, final transaction: Withdraw Unbonded, +which will be available in the same pop-up. You can also check how long you have to wait in order to +withdraw your stake in the +[Accounts](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/accounts) page by +expanding your account balance. There is a tiny icon beside the word "unbonding" that will +eventually become an unlock icon once the remaning blocks get passed. + +Then, you can click that icon directly to submit the withdraw transaction. Finally, your +transferrable balance will increase by the amount of tokens you've just fully unbonded. + +## Rebonding before the end of the unbonding period + +If you want to rebond your tokens before the unbonding period is over, you can do this by issuing a +`rebond` extrinsic. This allows you to bond your tokens that are still locked without waiting until +the end of the unbonding period. + +In order to do this, you will need to issue an extrinsic manually from [Polkadot-JS Apps][]. + +Go to the "Extrinsics" option that's located in the "Developer" dropdown in the top menu. + +![extrinsic menu](../assets/rebonding-1.png) + +Select the "staking" pallet and the "rebond" extrinsic. Enter the amount of tokens that are +currently locked in unbonding that you want to rebond. Then click "Submit Transaction". + +![confirm](../assets/rebonding-2.png) + +Confirm the transaction in the next pop-up. Once the transaction is included in the next block your +tokens will be rebonded again and you can start staking with them. + +[polkadot-js apps]: https://polkadot.js.org/apps diff --git a/docs/maintain/maintain-guides-how-to-upgrade.md b/docs/maintain/maintain-guides-how-to-upgrade.md new file mode 100644 index 000000000000..71446a419c9c --- /dev/null +++ b/docs/maintain/maintain-guides-how-to-upgrade.md @@ -0,0 +1,76 @@ +--- +id: maintain-guides-how-to-upgrade +title: How to Upgrade Your Validator +sidebar_label: How to Upgrade Your Validator +slug: ../maintain-guides-how-to-upgrade +--- + +Validators perform critical functions for the network, and as such, have strict uptime requirements. +Validators may have to go offline for periods of time to upgrade the client software or the host +machine. Usually, standard upgrades will only require you to stop your server, replace the binary +and spin it up again. Validators may also need to perform maintenance, such as resizing a disk, +where you cannot continue running the node on the current server. This guide will walk you through +upgrading your machine and keeping your validator online. + +The process can take several hours, so make sure you understand the instructions first and plan +accordingly. + +> Note: keep an eye out on new releases from the community and upgrade/downgrade accordingly. + +## Key Components + +### Session Keys + +Session keys are stored in the client and used to sign validator operations. They are what link your +validator node to your Controller account. You cannot change them mid-Session. + +[More info about keys in Polkadot.](../learn/learn-keys.md) + +### Database + +Validators keep a database with all of their votes. If two machines have the same Session keys but +different databases, they risk equivocating. For this reason, we will generate new Session keys each +time we change machines. + +[More info about equivocation.](../learn/learn-staking.md/#slashing) + +## Steps + +You will need to start a second validator to operate while you upgrade your primary. Throughout +these steps, we will refer to the validator that you are upgrading as "Validator A" and the second +one as "Validator B." + +### Session `N` + +1. Start a second node. Once it is synced, use the `--validator` flag. This is "Validator B." +2. Generate Session keys in Validator B. +3. Submit a `set_key` extrinsic from your Controller account with your new Session keys. +4. Take note of the Session that this extrinsic was executed in. + +**It is imperative that your Validator A keep running in this Session.** `set_key` only takes effect +in the next Session. + +### Session `N+1` + +Validator B is now acting as your validator. You can safely take Validator A offline. See note at +bottom. + +1. Stop Validator A. +1. Perform your system or client upgrade. +1. Start Validator A and sync the database. +1. Generate new Session keys in Validator A. +1. Submit a `set_key` extrinsic from your Controller account with your new Session keys for + Validator A. +1. Take note of the Session that this extrinsic was executed in. + +**Again, it is imperative that Validator B keep running until the next Session.** + +Once the Session changes, Validator A will take over. You can safely stop Validator B. + +**NOTE:** To verify that the Session has changed, make sure that a block in the new Session is +finalized. You should see log messages like this to indicate the change: + +``` +2019-10-28 21:44:13 Applying authority set change scheduled at block #450092 +2019-10-28 21:44:13 Applying GRANDPA set change to new set with 20 authorities +``` diff --git a/docs/maintain-guides-how-to-use-polkadot-validator-setup.md b/docs/maintain/maintain-guides-how-to-use-polkadot-validator-setup.md similarity index 96% rename from docs/maintain-guides-how-to-use-polkadot-validator-setup.md rename to docs/maintain/maintain-guides-how-to-use-polkadot-validator-setup.md index 915320cad84e..2d4c77a47171 100644 --- a/docs/maintain-guides-how-to-use-polkadot-validator-setup.md +++ b/docs/maintain/maintain-guides-how-to-use-polkadot-validator-setup.md @@ -2,32 +2,33 @@ id: maintain-guides-how-to-use-polkadot-validator-setup title: How to use Polkadot Validator Setup sidebar_label: How to use Polkadot Validator Setup +slug: ../maintain-guides-how-to-use-polkadot-validator-setup --- -# Polkadot Validator Setup +# Polkadot Validator Setup -The following guide will walk you through using Web3 Foundation's [polkadot validator setup][] to -offer a potential setup for your validator that aims to prevent some types of potential attacks -at the TCP layer and layers below. This will work for Polkadot and Kusama out of the box, and, +The following guide will walk you through using Web3 Foundation's [polkadot validator setup][] to +offer a potential setup for your validator that aims to prevent some types of potential attacks +at the TCP layer and layers below. This will work for Polkadot and Kusama out of the box, and, if you're using another Substrate-based chain, it should work with some tweaks. -> NOTE: This setup should not be assumed to include the best security practices. It is up to +> NOTE: This setup should not be assumed to include the best security practices. It is up to > you to add additional security hardening. -> Also, the current version of polkadot validator setup doesn't allow for the creation and +> Also, the current version of polkadot validator setup doesn't allow for the creation and > configuration of sentry nodes. There are two ways that the setup can be configured: -1. **Platform & Application Layer** which allows for configuring the credentials for - infrastructure providers, then executes the Terraform process to automatically deploy - the required machines (Platform Layer) and setup the Application Layer. This configuration +1. **Platform & Application Layer** which allows for configuring the credentials for + infrastructure providers, then executes the Terraform process to automatically deploy + the required machines (Platform Layer) and setup the Application Layer. This configuration uses [Terraform](https://www.terraform.io/) for defining and managing your infrastructure. -2. **Application Layer** which allows for setting up Debian-based machines, where you only - need basic SSH access and configure those in an inventory. The Ansible scripts will setup - the entire Application Layer. This configuration uses [Ansible](https://www.ansible.com/) - as an automation tool for setting up the VPN, Firewall, and the validator node. It supports +2. **Application Layer** which allows for setting up Debian-based machines, where you only + need basic SSH access and configure those in an inventory. The Ansible scripts will setup + the entire Application Layer. This configuration uses [Ansible](https://www.ansible.com/) + as an automation tool for setting up the VPN, Firewall, and the validator node. It supports a few different cloud providers such as AWS, Microsoft Azure, GCP, and Packet. > Please file an [issue][] if you would like to make a feature request or report a bug for this setup. diff --git a/docs/maintain/maintain-guides-how-to-validate-polkadot.md b/docs/maintain/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..869928a90c35 --- /dev/null +++ b/docs/maintain/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,533 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +slug: ../maintain-guides-how-to-validate-polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on +> Kusama, check out the +> [Kusama guide](kusama/mirror-maintain-guides-how-to-validate-kusama.md) +> instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not +only your own stake, but also the stake of your current nominators. If you make a mistake and get +slashed, your money and your reputation will be at risk. However, running a validator can also be +very rewarding, knowing that you contribute to the security of a decentralized network while growing +your stash. + +⚠️ +**`Warning: It is highly recommended that you have significant system administration experience before attempting to run your own validator.` +You must be able to handle technical issues and anomalies with your node which you must be able to +tackle yourself. Being a validator involves more than just executing the Polkadot binary.** + +Since security is so important to running a successful validator, you should take a look at the +[secure validator](maintain-guides-secure-validator.md) information to make sure you understand the +factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a +[reference implementation for a validator set-up](https://github.com/w3f/polkadot-validator-setup) +that you can use by deploying yourself (video walkthrough is available +[here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a +validator, you will likely want to use this repository as a _starting point_ for your own +modifications and customizations. + +If you need help, please reach out on the +[Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) +on Riot. The team and other validators are there to help answer questions and provide tips from +experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed +[here](../general/faq.md/#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators +are elected based on [Phragmén's algorithm](../learn/learn-phragmen.md). To be elected into the set, you need +a minimum stake behind your validator. This stake can come from yourself or from +[nominators](../learn/learn-nominator.md). This means that as a minimum, you will need enough DOT to set up +Stash and Controller [accounts](../learn/learn-keys.md) with the existential deposit, plus a little extra for +transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an +insecure or improper setup may result in loss of DOT tokens! If you are not confident in your +ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node +instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may +choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are +comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be +similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that +validators run at least the standard hardware in order to ensure they are able to process all blocks +in time. The following are not _minimum requirements_ but if you decide to run with less than this +beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see +[here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. + Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to + be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a +validator, however you should be aware that if you are using less you may need to toggle some extra +optimizations in order to be equal to other validators that are running the standard. + +### Node Prerequisites: Install Rust and Dependencies + +Once you choose your cloud service provider and set-up your new server, the first thing you will do +is install Rust. + +If you have never installed Rust, you should do this first. + +If you have already installed Rust, run the following command to make sure you are using the latest +version. + +```sh +rustup update +``` + +If not, this command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh -s -- -y +``` + +> If you do not have "curl" installed, run "sudo apt install curl" + +To configure your shell, run the following command. + +```sh +source $HOME/.cargo/env +``` + +Verify your installation. + +```sh +rustc --version +``` + +Finally, run this command to install the necessary dependencies for compiling and running the +Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the +following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to +synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all +the systems within the network. Currently it is required that validators' local clocks stay +reasonably in sync, so you should be running NTP or a similar service. You can check whether you +have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar +message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to +verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. +> If the clock is out of sync (even by a small amount), the blocks the validator produces may not +> get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but +> zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` binary + +You will need to build the `polkadot` binary from the +[paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source +code available in the **v0.9** branch. + +You should generally use the latest **0.9.x** tag. You should either review the output from the "git +tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list +of all the potential 0.9 releases. You should replace `VERSION` below with the latest build (i.e., +the highest number). You can also find the latest Kusama version on the +[release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with +> `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +``` + +Run the following command to find the latest version. + +```sh +git tag -l | sort -V | grep -v -- '-rc' +``` + +Find the latest version; replace "VERSION" in the commmand below and run to change your branch. + +```sh +git checkout VERSION +./scripts/init.sh +``` + +Build native code with the cargo release profile. + +```sh +cargo build --release +``` + +**_This step will take a while (generally 10 - 40 minutes, depending on your hardware)._** + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be +> done by running: +> +> ```sh +> rustup install nightly-2021-06-09 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2021-06-09 +> cargo +nightly-2021-06-09 build --release +> ``` +> +> You may also need to run the build more than once. +> +> If you would like to execute the tests, run the following command: +> +> ```sh +> cargo test --all +> ``` + +If you are interested in generating keys locally, you can also install `subkey` from the same +directory. You may then take the generated `subkey` executable and transfer it to an air-gapped +machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not +> in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure +> that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: +> `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive +> node and non-archive node's databases are not compatible with each other, and to switch you will +> need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +``` +2021-06-17 03:07:07 Parity Polkadot +2021-06-17 03:07:07 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu +2021-06-17 03:07:07 ❤️ by Parity Technologies , 2017-2021 +2021-06-17 03:07:07 📋 Chain specification: Polkadot +2021-06-17 03:07:07 🏷 Node name: boiling-pet-7554 +2021-06-17 03:07:07 👤 Role: FULL +2021-06-17 03:07:07 💾 Database: RocksDb at /root/.local/share/polkadot/chains/polkadot/db +2021-06-17 03:07:07 ⛓ Native runtime: polkadot-9050 (parity-polkadot-0.tx7.au0) +2021-06-17 03:07:10 🏷 Local node identity is: 12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u +2021-06-17 03:07:10 📦 Highest known block at #17914 +2021-06-17 03:07:10 〽️ Prometheus server started at 127.0.0.1:9615 +2021-06-17 03:07:10 Listening for new connections on 127.0.0.1:9944. +``` + +Example of node sync: + +``` +2021-06-17 03:07:39 🔍 Discovered new external address for our node: /ip4/10.26.16.1/tcp/30333/ws/p2p/12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u +2021-06-17 03:07:40 ⚙️ Syncing 218.8 bps, target=#5553764 (17 peers), best: #24034 (0x08af…dcf5), finalized #23552 (0xd4f0…2642), ⬇ 173.5kiB/s ⬆ 12.7kiB/s +2021-06-17 03:07:45 ⚙️ Syncing 214.8 bps, target=#5553765 (20 peers), best: #25108 (0xb272…e800), finalized #25088 (0x94e6…8a9f), ⬇ 134.3kiB/s ⬆ 7.4kiB/s +2021-06-17 03:07:50 ⚙️ Syncing 214.8 bps, target=#5553766 (21 peers), best: #26182 (0xe7a5…01a2), finalized #26112 (0xcc29…b1a9), ⬇ 5.0kiB/s ⬆ 1.1kiB/s +2021-06-17 03:07:55 ⚙️ Syncing 138.4 bps, target=#5553767 (21 peers), best: #26874 (0xcf4b…6553), finalized #26624 (0x9dd9…27f8), ⬇ 18.9kiB/s ⬆ 2.0kiB/s +2021-06-17 03:08:00 ⚙️ Syncing 37.0 bps, target=#5553768 (22 peers), best: #27059 (0x5b73…6fc9), finalized #26624 (0x9dd9…27f8), ⬇ 14.3kiB/s ⬆ 4.4kiB/s +``` + +The `--pruning=archive` flag is implied by the `--validator` flag, so it is only +required explicitly if you start your node without one of these two options. If you do not set your +pruning to archive node, even when not running in validator mode, you will need to +re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can +> be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note +> that **ParityDB is still experimental and should not be used in production.** If you want to test +> out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will +> require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes +to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to +STDOUT from the `polkadot` process) will tell you the latest block your node has processed and +verified. You can then compare that to the current highest block via +[Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the +[PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. +For this, you will create two accounts and make sure each of them have at least enough funds to pay +the fees for making transactions. Keep most of your funds in the stash account since it is meant to +be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from +your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network + and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on +"Account Actions", and then the "+ Stash" button. + +![dashboard bonding](../assets/guides/how-to-validate/polkadot-dashboard-bonding.png) + +- **Stash account** - Select your Stash account. In this example, we will bond 1 DOT, where the + minimum bonding amount is 1. Make sure that your Stash account contains _at least_ this much. You + can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also + need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do + not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT + later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On + Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info + [here](../learn/learn-staking.md/#reward-distribution). Starting with runtime version v23 natively included + in client version [0.9.3](https://github.com/paritytech/polkadot/releases/tag/v0.9.3), payouts can + go to any custom address. If you'd like to redirect payments to an account that is neither the + controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange + address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash +account. + +![sign transaction](../assets/guides/how-to-validate/polkadot-authorize-transaction-stash.png) + +After a few seconds, you should see an `ExtrinsicSuccess` message. + +Your bonded account will available under `Stashes`. You should now see a new card with all your +accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to +the funds bonded by the Stash account. + +![stash overview](../assets/guides/how-to-validate/polkadot-stash-overview.png) + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the +> current session keys that you made the `setKeys` transaction then you can use one of the two +> available RPC methods to query your node: +> [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to +> check for a specific key or +> [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) +> to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you +will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +Similarly: + +``` +2021-06-17 03:12:08 Parity Polkadot +2021-06-17 03:12:08 ✌️ version 0.9.5-95f6aa201-x86_64-linux-gnu +2021-06-17 03:12:08 ❤️ by Parity Technologies , 2017-2021 +2021-06-17 03:12:08 📋 Chain specification: Polkadot +2021-06-17 03:12:08 🏷 Node name: nateched-test +2021-06-17 03:12:08 👤 Role: AUTHORITY +2021-06-17 03:12:08 💾 Database: RocksDb at /root/.local/share/polkadot/chains/polkadot/db +2021-06-17 03:12:08 ⛓ Native runtime: polkadot-9050 (parity-polkadot-0.tx7.au0) +2021-06-17 03:12:12 🏷 Local node identity is: 12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u +2021-06-17 03:12:12 📦 Highest known block at #64673 +2021-06-17 03:12:12 〽️ Prometheus server started at 127.0.0.1:9615 +2021-06-17 03:12:12 Listening for new connections on 127.0.0.1:9944. +2021-06-17 03:12:12 👶 Starting BABE Authorship worker +``` + +``` +2021-06-17 03:12:16 🔍 Discovered new external address for our node: /ip4/10.26.11.1/tcp/30333/p2p/12D3KooWLtXFWf1oGrnxMGmPKPW54xWCHAXHbFh4Eap6KXmxoi9u +2021-06-17 03:12:17 ⚙️ Syncing, target=#5553810 (14 peers), best: #65068 (0x6da5…0662), finalized #65024 (0x4e84…d170), ⬇ 352.2kiB/s ⬆ 75.6kiB/s +``` + +You can give your validator any name that you like, but note that others will be able to see it, and +it will be included in the list of all servers using the same telemetry server. Since numerous +people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what +associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](../learn/learn-keys.md#session-keys) in the client via the apps RPC. If +you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator +node. You can configure the apps dashboard to connect to the endpoint of your validator in the +Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you +will not be able to use this method since making RPC requests to this node would effect the local +keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore +for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your +node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's +keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option +and remember to save the output that you get back for a later step. + +![Explorer RPC call](../assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node +is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four +public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what +associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set +Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` +in the field and click "Set Session Key". + +![staking-change-session](../assets/guides/how-to-validate/set-session-key-1.png) +![staking-session-result](../assets/guides/how-to-validate/set-session-key-2.png) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to +[Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this +will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +In this example, we used the name `techedtest` and have successfully located it upon searching: + +![dashboard validate](../assets/guides/how-to-validate/polkadot-dashboard-telemetry.png) + +### Setup via Validator Tab + +![dashboard validate](../assets/guides/how-to-validate/polkadot-dashboard-validate-1.png) + +Here you will need to input the Keys from `rotateKeys`, which is the Hex output from +`author_rotateKeys`. The keys will show as pending until applied at the start of a new session. + +The "reward commission percentage" is the commission percentage that you can declare against your +validator's rewards. This is the rate that your validator will be commissioned with. + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. + The remaining will be split among your nominators. + +> Note: setting a commission rate of 100% suggests that you do not want your validator to receive +> nominations. + +You can also determine if you would like to receive nominations with the "allows new nominations" +option. + +![dashboard validate](../assets/guides/how-to-validate/polkadot-dashboard-validate-2.png) + +Click "Bond & Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the +network. At the top of the page, it shows the number of validator slots that are available as well +as the number of nodes that have signaled their intention to be a validator. You can go to the +"Waiting" tab to double check to see whether your node is listed there. + +![staking queue](../assets/guides/how-to-validate/polkadot-dashboard-staking.png) + +The validator set is refreshed every era. In the next era, if there is a slot available and your +node is selected to join the validator set, your node will become an active validator. Until then, +it will remain in the _waiting_ queue. If your validator is not selected to become part of the +validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if +you are not selected for the validator set in a particular era. However, it may be necessary to +increase the number of DOT staked or seek out nominators for your validator in order to join the +validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the +validator set, you are now running a Polkadot validator! If you need help, reach out on the +[Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies +to provide support for community validators. If you are interested in applying for the programme, +you can find more information [on the wiki page](../general/thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](../assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover +other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build +the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/docs/maintain-guides-how-to-vote-councillor.md b/docs/maintain/maintain-guides-how-to-vote-councillor.md similarity index 93% rename from docs/maintain-guides-how-to-vote-councillor.md rename to docs/maintain/maintain-guides-how-to-vote-councillor.md index c3513bcdf6b6..76165f304784 100644 --- a/docs/maintain-guides-how-to-vote-councillor.md +++ b/docs/maintain/maintain-guides-how-to-vote-councillor.md @@ -2,12 +2,13 @@ id: maintain-guides-how-to-vote-councillor title: Voting for Councillors sidebar_label: Voting for Councillors +slug: ../maintain-guides-how-to-vote-councillor --- The council is an elected body of on-chain accounts that are intended to represent the passive stakeholders of Polkadot and/or Kusama. The council has two major tasks in governance: proposing referenda and vetoing dangerous or malicious referenda. For more information on the council, see the -[governance page](learn-governance.md#council). This guide will walk you through voting for +[governance page](../learn/learn-governance.md#council). This guide will walk you through voting for councillors in the elections. ## Voting for Councillors @@ -51,7 +52,7 @@ Go to the "Governance" > "Council" tab on the Under the "Council overview" tab, click on "Vote". -![](assets/council/polkadotjs_removeVoter.png) +![](../assets/council/polkadotjs_removeVoter.png) Issue the "Unvote all" option. diff --git a/docs/maintain/maintain-guides-secure-validator.md b/docs/maintain/maintain-guides-secure-validator.md new file mode 100644 index 000000000000..5070dd8bae3c --- /dev/null +++ b/docs/maintain/maintain-guides-secure-validator.md @@ -0,0 +1,125 @@ +--- +id: maintain-guides-secure-validator +title: Secure Validator +sidebar_label: Secure Validator +slug: ../maintain-guides-secure-validator +--- + +Validators in a Proof of Stake network are responsible for keeping the network in consensus and +verifying state transitions. As the number of validators is limited, validators in the set have the +responsibility to be online and faithfully execute their tasks. + +This primarily means that validators: + +- Must be high availability. +- Must have infrastructure that protects the validator's signing keys so that an attacker cannot + take control and commit slashable behavior. + +## High Availability + +High availability set-ups that involve redundant validator nodes may seem attractive at first. +However, they can be **very dangerous** if they are not set up perfectly. The reason for this is +that the session keys used by a validator should always be isolated to just a single node. +Replicating session keys across multiple nodes could lead to equivocation slashes or parachain +validity slashes which can make you lose **100% of your staked funds**. + +The good news is that 100% uptime of your validator is not really needed, as it has some buffer +within eras in order to go offline for a little while and upgrade. For this reason, we advise that +you only attempt a high availability set-up if **you're confident you know exactly what you're +doing.** + +Many expert validators have made mistakes in the past due to the handling of session keys. + +Remember, even if your validator goes offline for some time, the offline slash is much more +forgiving than the equivocation or parachain validity slashing. + +## Key Management + +See the [Polkadot Keys guide](../learn/learn-keys.md) for more information on keys. The keys that are of +primary concern for validator infrastructure are the Session keys. These keys sign messages related +to consensus and parachains. Although Session keys are _not_ account keys and therefore cannot +transfer funds, an attacker could use them to commit slashable behavior. + +Session keys are generated inside the node via RPC call. See the +[How to Validate guide](maintain-guides-how-to-validate-polkadot.md#set-session-keys) + +for instructions on setting Session keys. These should be generated and kept within your client. +When you generate new Session keys, you must submit an extrinsic (a Session certificate) from your +Controller key telling the chain your new Session keys. + +> **NOTE:** Session keys can also be generated outside the client and inserted into the client's +> keystore via RPC. For most users, we recommend using the key generation functionality within the +> client. + +### Signing Outside the Client + +In the future, Polkadot will support signing payloads outside the client so that keys can be stored +on another device, e.g. a hardware security module (HSM) or secure enclave. For the time being, +however, Session key signatures are performed within the client. + +> **NOTE:** HSMs are not a panacea. They do not incorporate any logic and will just sign and return +> whatever payload they receive. Therefore, an attacker who gains access to your validator node +> could still commit slashable behavior. + +## Monitoring Tools + +- [Telemetry](https://github.com/paritytech/substrate-telemetry) This tracks your node details + including the version you are running, block height, CPU & memory usage, block propagation time, + etc. + +- [Prometheus](https://prometheus.io/)-based monitoring stack, including + [Grafana](https://grafana.com) for dashboards and log aggregation. It includes alerting, querying, + visualization, and monitoring features and works for both cloud and on-premise systems. The data + from `substrate-telemetry` can be made available to Prometheus through exporters like + [this](https://github.com/w3f/substrate-telemetry-exporter). + +## Linux Best Practices + +- Never use the root user. +- Always update the security patches for your OS. +- Enable and set up a firewall. +- Never allow password-based SSH, only use key-based access. +- Disable non-essential SSH subsystems (banner, motd, scp, X11 forwarding) and harden your SSH + configuration + ([reasonable guide to begin with](https://stribika.github.io/2015/01/04/secure-secure-shell.html)). +- Back up your storage regularly. + +## Conclusions + +- At the moment, Polkadot/Substrate can't interact with HSM/SGX, so we need to provide the signing + key seeds to the validator machine. This key is kept in memory for signing operations and + persisted to disk (encrypted with a password). + +- Given that HA setups would always be at risk of double-signing and there's currently no built-in + mechanism to prevent it, we propose having a single instance of the validator to avoid slashing. + Slashing penalties for being offline are much less than those for equivocation. + +### Validators + +- Validators should only run the Polkadot binary, and they should not listen on any port other than + the configured p2p port. + +- Validators should run on bare-metal machines, as opposed to VMs. This will prevent some of the + availability issues with cloud providers, along with potential attacks from other VMs on the same + hardware. The provisioning of the validator machine should be automated and defined in code. This + code should be kept in private version control, reviewed, audited, and tested. + +- Session keys should be generated and provided in a secure way. + +- Polkadot should be started at boot and restarted if stopped for any reason (supervisor process). + +- Polkadot should run as a non-root user. + +### Monitoring + +- There should be an on-call rotation for managing the alerts. + +- There should be a clear protocol with actions to perform for each level of each alert and an + escalation policy. + +## Resources + +- [Figment Network's Full Disclosure of Cosmos Validator Infrastructure](https://medium.com/figment-networks/full-disclosure-figments-cosmos-validator-infrastructure-3bc707283967) +- [Certus One's Knowledge Base](https://kb.certus.one/) +- [EOS Block Producer Security List](https://github.com/slowmist/eos-bp-nodes-security-checklist) +- [HSM Policies and the Important of Validator Security](https://medium.com/loom-network/hsm-policies-and-the-importance-of-validator-security-ec8a4cc1b6f) diff --git a/docs/maintain/maintain-guides-validator-payout.md b/docs/maintain/maintain-guides-validator-payout.md new file mode 100644 index 000000000000..f2908dd28392 --- /dev/null +++ b/docs/maintain/maintain-guides-validator-payout.md @@ -0,0 +1,205 @@ +--- +id: maintain-guides-validator-payout +title: Validator Payout Overview +sidebar_label: Validator Payout Overview +slug: ../maintain-guides-validator-payout +--- + +## Era Points + +For every era (a period of time approximately 6 hours in length in Kusama, and 24 hours in +Polkadot), validators are paid proportionally to the amount of _era points_ they have collected. Era +points are reward points earned for payable actions like: + +- issuing validity statements for [parachain](../learn/learn-parachains.md) blocks. +- producing a non-uncle block in the Relay Chain. +- producing a reference to a previously unreferenced uncle block. +- producing a referenced uncle block. + +_Note: An uncle block is a Relay Chain block that is valid in every regard, but which failed to +become canonical. This can happen when two or more validators are block producers in a single slot, +and the block produced by one validator reaches the next block producer before the others. We call +the lagging blocks uncle blocks._ + +Payments occur at the end of every era. + +## Payout Scheme + +No matter how much total stake is behind a validator, all validators split the block authoring +payout essentially equally. The payout of a specific validator, however, may differ based on +[era points](#era-points), as described above. Although there is a probabilistic component to +receiving era points, and they may be impacted slightly depending on factors such as network +connectivity, well-behaving validators should generally average out to having similar era point +totals over a large number of eras. + +Validators may also receive "tips" from senders as an incentive to include transactions in their +produced blocks. Validators will receive 100% of these tips directly. + +Validators will receive staking rewards in the form of the native token of that chain (KSM for +Kusama and DOT for Polkadot). + +For simplicity, the examples below will assume all validators have the same amount of era points, +and received no tips. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1): 18 tokens +Validator 2 Stake (v2): 9 tokens +Validator 3 Stake (v3): 8 tokens +Validator 4 Stake (v4): 7 tokens +Payout (p): 8 DOT + +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 tokens +``` + +Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a +validator is in the validator set, it will receive the same block reward as every other validator. +Validator `v1`, who had 18 tokens staked, received the same reward (2 tokens) in this era as `v4` +who had only 7 tokens staked. + +## Running Multiple Validators + +It is possible for a single entity to run multiple validators. Running multiple validators may +provide a better risk/reward ratio. Assuming you have enough DOT, or enough stake nominates your +validator, to ensure that your validators remain in the validator set, running multiple validators +will result in a higher return than running a single validator. + +For the following example, assume you have 18 DOT to stake. For simplicity's sake, we will ignore +nominators. Running a single validator, as in the example above, would net you 2 DOT in this era. + +Note that while DOT is used as an example, this same formula would apply to KSM when running a +validator on Kusama. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1): 18 DOT <- Your validator +Validator 2 Stake (v2): 9 DOT +Validator 3 Stake (v3): 8 DOT +Validator 4 Stake (v4): 7 DOT +Payout (p): 8 DOT + +Your payout = (p / v) * 1 = (8 / 4) * 1 = 2 +``` + +Running two validators, and splitting the stake equally, would result in the original validator `v4` +to be kicked out of the validator set, as only the top `v` validators (as measured by stake) are +selected to be in the validator set. More important, it would also double the reward that you get +from each era. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1): 9 DOT <- Your first validator +Validator 2 Stake (v2): 9 DOT <- Your second validator +Validator 3 Stake (v3): 9 DOT +Validator 4 Stake (v4): 8 DOT +Payout (p): 8 DOT + +Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 +``` + +With enough stake, you could run more than two validators. However, each validator must have enough +stake behind it to be in the validator set. + +The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather +than static, equilibrium. Potential validators will run different numbers of validators and apply +different amounts of stake to them as time goes on, and in response to the actions of other +validators on the network. + +## Slashing + +Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do +have enough DOT to run multiple validators, it is in your best interest to do so. A slash of 30% +will, of course, be more DOT for a validator with 18 DOT staked than one with 9 DOT staked. + +Running multiple validators does not absolve you of the consequences of misbehavior. Polkadot +punishes attacks that appear coordinated more severely than individual attacks. You should not, for +example, run multiple validators hosted on the same infrastructure. A proper multi-validator +configuration would ensure that they do not fail simultaneously. + +Nominators have the incentive to nominate the lowest-staked validator, as this will result in the +lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing +remains the same (since it is percentage-based), their rewards are higher since they will be a +higher proportion of the total stake allocated to that validator. + +To clarify this, let us imagine two validators, `v1` and `v2`. Assume both are in the active set, +have commission set to 0%, and are well-behaved. The only difference is that `v1` has 90 DOT +nominating it and `v2` only has 10. If you nominate `v1`, it now has `90 + 10 = 100` DOT, and you +will get 10% of the staking rewards for the next era. If you nominate `v2`, it now has +`10 + 10 = 20` DOT nominating it, and you will get 50% of the staking rewards for the next era. In +actuality, it would be quite rare to see such a large difference between the stake of validators, +but the same principle holds even for smaller differences. If there is a 10% slash of either +validator, then you will lose 1 DOT in each case. + +## Nominators and Validator Payments + +Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without +running a validator node yourself. Validators can choose to keep a percentage of the rewards due to +their validator to "reimburse" themselves for the cost of running a validator node. Other than that, +all rewards are shared based on the stake behind each validator. This includes the stake of the +validator itself, plus any stake bonded by nominators. + +> **NOTE:** Validators set their preference as a percentage of the block reward, _not_ an absolute +> number of DOT. Polkadot's block reward is based on the _total_ amount at stake, with the reward +> peaking when the amount staked is at 50% of the total supply. The commission is set as the amount +> taken by the validator; that is, 0% commission means that the validator does not receive any +> proportion of the rewards besides that owed to it from self-stake, and 100% commission means that +> the validator operator gets all rewards and gives none to its nominators. + +In the following examples, we can see the results of several different validator payment schemes and +split between nominator and validator stake. We will assume a single nominator for each validator. +However, there can be numerous nominators for each validator. Rewards are still distributed +proportionally - for example, if the total rewards to be given to nominators is 2 DOT, and there are +four nominators with equal stake bonded, each will receive 0.5 DOT. Note also that a single +nominator may stake different validators. + +Each validator in the example has selected a different validator payment (that is, a percentage of +the reward set aside directly for the validator before sharing with all bonded stake). The +validator's payment percentage (in DOT, although the same calculations work for KSM) is listed in +brackets (`[]`) next to each validator. Note that since the validator payment is public knowledge, +having a low or non-existent validator payment may attract more stake from nominators, since they +know they will receive a larger reward. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1) [20% commission]: 18 DOT (9 validator, 9 nominator) +Validator 2 Stake (v2) [40% commission]: 9 DOT (3 validator, 6 nominator) +Validator 3 Stake (v3) [10% commission]: 8 DOT (4 validator, 4 nominator) +Validator 4 Stake (v4) [ 0% commission]: 6 DOT (1 validator, 5 nominator) +Payout (p): 8 DOT + +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 DOT + +v1: +(0.2 * 2) = 0.4 DOT -> validator payment +(2 - 0.4) = 1.6 -> shared between all stake +(9 / 18) * 1.6 = 0.8 -> validator stake share +(9 / 18) * 1.6 = 0.8 -> nominator stake share +v1 validator total reward: 0.4 + 0.8 = 1.2 DOT +v1 nominator reward: 0.8 DOT + +v2: +(0.4 * 2) = 0.8 DOT -> validator payment +(2 - 0.8) = 1.2 -> shared between all stake +(3 / 9) * 1.2 = 0.4 -> validator stake share +(6 / 9) * 1.2 = 0.8 -> nominator stake share +v2 validator total reward: 0.8 + 0.4 = 1.2 DOT +v2 nominator reward: 0.8 DOT + +v3: +(0.1 * 2) = 0.2 DOT -> validator payment +(2 - 0.2) = 1.8 -> shared between all stake +(4 / 8) * 1.8 = 0.9 -> validator stake share +(4 / 8) * 1.8 = 0.9 -> nominator stake share +v3 validator total reward: 0.2 + 0.9 DOT = 1.1 DOT +v3 nominator reward: 0.9 DOT + +v4: +(0 * 2) = 0 DOT -> validator payment +(2 - 0) = 2.0 -> shared between all stake +(1 / 6) * 2 = 0.33 -> validator stake share +(5 / 6) * 2 = 1.67 -> nominator stake share +v4 validator total reward: 0 + 0.33 DOT = 0.33 DOT +v4 nominator reward: 1.67 DOT +``` diff --git a/docs/maintain/maintain-index.md b/docs/maintain/maintain-index.md new file mode 100644 index 000000000000..b644a969c61d --- /dev/null +++ b/docs/maintain/maintain-index.md @@ -0,0 +1,65 @@ +--- +id: maintain-index +title: Network Maintainers +sidebar_label: Network Maintainers +slug: ../maintain-index +--- + +Welcome to the network maintainers section of the Polkadot wiki. Here you will find information and +guides to set up a node and run the network. + +## Node + +- [Networks Guide](maintain-networks.md) - A list of the available Polkadot networks that you can + connect to with a node. +- [Set up a Full Node](maintain-sync.md) - Get up and started by syncing a full node for the Kusama + network. The steps in the guide will broadly apply also to any Substrate-based network (like + Polkadot). +- [Set up WSS using Nginx](maintain-wss.md) - Set up a Secure WebSockets server for your node's + WebSockets connection. + +## Collator + +- [Learn about Collators](../learn/learn-collator.md) - High level overview of collators and related links. + +## Nominator + +- [Learn about Nominators](../learn/learn-nominator.md) - High level overview of nominators and related + links. +- [Nomination Guide (Polkadot)](maintain-guides-how-to-nominate-polkadot.md) - Walkthrough on how to + nominate on the Polkadot network. +- [Nomination Guide (Kusama)](kusama/maintain-guides-how-to-nominate-kusama.md) - Walkthrough on how to + nominate on the Kusama canary network. +- [How to stop being a Nominator](maintain-guides-how-to-unbond.md) - Guide on how to stop + nominating. + +## Validator + +- [Learn about Validators](../learn/learn-validator.md) - High level overview of validator and related links. +- [Validator Payouts](maintain-guides-validator-payout.md) - Overview on how validator rewards are + calculated and paid. +- [Validation Guide (Polkadot)](maintain-guides-how-to-validate-polkadot.md) - Walkthrough on how to + validate on the Polkadot network. +- [Validation Guide (Kusama)](kusama/maintain-guides-how-to-validate-kusama.md) - Walkthrough on how to + validate on the Kusama canary network. +- [Using systemmd for the Validator Node](maintain-guides-how-to-systemd.md) - Configuring systemmd + with the Validator node. +- [Secure Validator](maintain-guides-secure-validator.md) - Best tips and practices for validating. +- [How to use Polkadot Validator Setup](maintain-guides-how-to-use-polkadot-validator-setup.md) - + Walkthrough on how to set up a validator securely. +- [How to upgrade a Validator Node](maintain-guides-how-to-upgrade.md) - Guide on upgrading your + validator node. +- [How to Chill](maintain-guides-how-to-chill.md) - Walkthrough on how to chill as a validator. +- [How to Stop Validating](maintain-guides-how-to-stop-validating.md) - Proper way to stop + validating. + +## Governance + +- [How to pariticipate in Governance](maintain-guides-democracy.md) - Walkthrough on how to + participate in governance. +- [How to join the Council][join the council] - Step by step guide for running for the Council. +- [How to vote for a Councillor][vote for councillors] - Step by step guide for voting for your + favorite councillors. + +[join the council]: maintain-guides-how-to-join-council.md +[vote for councillors]: maintain-guides-how-to-vote-councillor.md diff --git a/docs/maintain-networks.md b/docs/maintain/maintain-networks.md similarity index 96% rename from docs/maintain-networks.md rename to docs/maintain/maintain-networks.md index b2ea66b5091b..bd588170a933 100644 --- a/docs/maintain-networks.md +++ b/docs/maintain/maintain-networks.md @@ -2,6 +2,7 @@ id: maintain-networks title: Networks sidebar_label: Networks +slug: ../maintain-networks --- Polkadot is built on top of Substrate, a modular framework for blockchains. One feature of Substrate @@ -65,7 +66,7 @@ Check that your node is connected by viewing it on #### Westend Faucet -Follow the instruction [here](learn-DOT.md#getting-westies) for instructions on acquiring Westies. +Follow the instruction [here](../learn/learn-DOT.md#getting-westies) for instructions on acquiring Westies. ### Differences diff --git a/docs/maintain/maintain-polkadot-parameters.md b/docs/maintain/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..ceb79a612361 --- /dev/null +++ b/docs/maintain/maintain-polkadot-parameters.md @@ -0,0 +1,84 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +slug: ../maintain-polkadot-parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute +certainty of these parameter values, it is recommended you directly check the constants by looking +at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or +[storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Polkadot generally runs at ¼th the speed of Kusama, except in the time slot duration +itself. See [Kusama Parameters](../general/kusama/kusama-parameters) for more details on how Polkadot's parameters +differ from Kusama's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2_400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2_400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2_400 | +| Session | 4 hours | 2_400 | +| Era | 24 hours | 14_400 | + +\*_A maximum of one block per slot can be in a canonical chain. Occasionally, a slot will be without +a block in the chain. Thus, the times given are *estimates*. See [Consensus](../learn/learn-consensus.md) for +more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403_200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403_200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403_200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100_800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100_800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100_800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1_800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +As of June 30, 2021, the staking parameters have been modified to a minimum of 40 DOT to nominate, +and a maximum of 22_500 total nominators. As most of these parameters can be updated via on-chain +governance, please check the latest parameters on +[chain state](https://polkadot.js.org/apps/#/chainstate) (selected state query - staking - +minimumNominatorBond and maxNominatorsCount) + +| Polkadot | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14_400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14_400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403_200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403_200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345_600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10_000_000_000 or ten billion) +Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1*248_328 in an event +known as \_Denomination Day*. See [Redenomination](../general/redenomination.md) for details. diff --git a/docs/maintain/maintain-sync.md b/docs/maintain/maintain-sync.md new file mode 100644 index 000000000000..9cd38a882394 --- /dev/null +++ b/docs/maintain/maintain-sync.md @@ -0,0 +1,292 @@ +--- +id: maintain-sync +title: Set up a Full Node +sidebar_label: Set up a Full Node +slug: ../maintain-sync +--- + +import Tabs from "@theme/Tabs"; +import TabItem from "@theme/TabItem"; + +If you're building dapps or products on a Substrate-based chain like Polkadot, Kusama or a custom +Substrate implementation, you probably want the ability to run a node-as-a-back-end. After all, it's +always better to rely on your own infrastructure than on a third-party-hosted one in this brave new +decentralized world. + +This guide will show you how to connect to [Polkadot network](https://polkadot.network/), but the +same process applies to any other [Substrate](https://substrate.dev/docs/en/)-based chain. First, +let's clarify the term _full node_. + +### Types of Nodes + +A blockchain's growth comes from a _genesis block_, _extrinsics_, and _events_. + +When a validator seals block 1, it takes the blockchain's state at block 0. It then applies all +pending changes on top of it, and emits the events that are the result of these changes. Later, the +state of the chain at block 1 is used in the same way to build the state of the chain at block 2, +and so on. Once two thirds of the validators agree on a specific block being valid, it is finalized. + +An **archive node** keeps all the past blocks. An archive node makes it convenient to query the past +state of the chain at any point in time. Finding out what an account's balance at a certain block +was, or which extrinsics resulted in a certain state change are fast operations when using an +archive node. However, an archive node takes up a lot of disk space - around Kusama's 1.6 millionth +block this was around 15 to 20GB. + +Archive nodes are used by utilities that need past information - like block explorers, council +scanners, discussion platforms like [Polkassembly](https://polkassembly.io), and others. They need +to be able to look at past on-chain data. + +A **full node** is _pruned_: it discards all finalized blocks older than a configurable number +except the genesis block: This is 256 blocks from the last finalized one, by default. A node that is +pruned this way requires much less space than an archive node. + +A full node may eventually be able to rebuild the entire chain with no additional information, and +become an archive node, but at he time of writing, this is not implemented. If you need to query +historical blocks past what you pruned, you need to purge your database and resync your node +starting in archive mode. Alternatively you can use a backup or snapshot of a trusted source to +avoid needing to sync from genesis with the network, and only need the blocks past that snapshot. + +Full nodes allow you to read the current state of the chain and to submit and validate extrinsics +directly on the network without relying on a centralized infrastructure provider. + +Another type of node is a **light node**. A light node has only the runtime and the current state, +but does not store past blocks and so cannot read historical data without requesting it from a node +that has it. Light nodes are useful for resource restricted devices. An interesting use-case of +light nodes is a Chrome extension, which is a node in its own right, running the runtime in [WASM +format](https://github.com/paritytech/substrate-light-ui) as well as a full or light node that is +completely encapsulated in WASM and can be integrated into webapps: +https://github.com/paritytech/smoldot#wasm-light-node + + + +--- + + + +## Setup Instructions + +This is not recommended if you're a validator. Please see the +[secure validator setup](maintain-guides-secure-validator.md) if you are running validator. + + + + +- Install Homebrew within the terminal by running: + ```bash + /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" + ``` +- Then, run: + + ```bash + brew install openssl cmake llvm` + ``` + +- Install Rust in your terminal by running: + ```bash + curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh + ``` +- Once Rust is installed, run the following command to clone and build the polkadot code: + ```bash + git clone https://github.com/paritytech/polkadot polkadot + cd polkadot + ./scripts/init.sh + cargo build --release + ``` +- Start your node: + {{ polkadot: + + ```bash + ./target/release/polkadot --name "Your Node's Name" + ``` + + :polkadot }} + {{ kusama: + + ```bash + ./target/release/polkadot --name "Your Node's Name" --chain kusama + ``` + + :kusama }} + +- Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot) + + + + +- Install [WSL](https://docs.microsoft.com/en-us/windows/wsl/install-win10). +- Install [Ubuntu](https://docs.microsoft.com/en-us/windows/wsl/install-win10) (same webpage). + +- Determine the latest version of the [Polkadot binary](https://github.com/paritytech/polkadot/releases). +- Download the correct Polkadot binary within Ubuntu by running the following command. Replace + `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): + + ```bash + curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot + ``` + +- Then, run the following: + ```bash + sudo chmod +x polkadot + ``` +- Start your node: + {{ polkadot: + + ```bash + ./target/release/polkadot --name "Your Node's Name" + ``` + + :polkadot }} + {{ kusama: + + ```bash + ./target/release/polkadot --name "Your Node's Name" --chain kusama + ``` + + :kusama }} + +- Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot) + + + + +- Determine the latest version of the [Polkadot binary](https://github.com/paritytech/polkadot/releases). + +> The nature of pre-built binaries means that they may not work on your particular architecture or Linux distribution. +> If you see an error like `cannot execute binary file: Exec format error` it likely means the binary is not compatible +> with your system. You will either need to compile the [**source code**](#clone-and-build) or use [**Docker**](#using-docker). + +- Download the correct Polkadot binary within Ubuntu by running the following command. Replace + `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): + + ```bash + curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot + ``` + +- Run the following: `sudo chmod +x polkadot` +- Run the following: + {{ polkadot: + + ```bash + ./target/release/polkadot --name "Your Node's Name" + ``` + + :polkadot }} + {{ kusama: + + ```bash + ./target/release/polkadot --name "Your Node's Name" --chain kusama + ``` + + :kusama }} + +- Find your node on [Telemetry](https://telemetry.polkadot.io/#list/Polkadot) + + + + +## Get Substrate + +Follow instructions as outlined +[here](https://substrate.dev/docs/en/knowledgebase/getting-started) - note that Windows users will +have their work cut out for them. It's better to use a virtual machine instead. + +Test if the installation was successful by running `cargo --version`. + +```bash +λ cargo --version +cargo 1.41.0 (626f0f40e 2019-12-03) +``` + +## Clone and Build + +The [paritytech/polkadot](https://github.com/paritytech/polkadot) repo's master branch contains the +latest Polkadot code. + +```bash +git clone https://github.com/paritytech/polkadot polkadot +cd polkadot +./scripts/init.sh +cargo build --release +``` + +Alternatively, if you wish to use a specific release, you can check out a specific tag (`v0.8.3` in +the example below): + +```bash +git clone https://github.com/paritytech/polkadot polkadot +cd polkadot +git checkout tags/v0.8.3 +./scripts/init.sh +cargo build --release +``` + +## Run + +The built binary will be in the `target/release` folder, called `polkadot`. + +{{ polkadot: + +```bash +./target/release/polkadot --name "Your Node's Name" +``` + +:polkadot }} +{{ kusama: + +```bash +./target/release/polkadot --name "Your Node's Name" --chain kusama +``` + +:kusama }} + +Use the `--help` flag to find out which flags you can use when running the node. For example, if +[connecting to your node remotely](maintain-wss.md), you'll probably want to use `--ws-external` and +`--rpc-cors all`. + +The syncing process will take a while depending on your bandwidth, processing power, disk speed and +RAM. On a \$10 DigitalOcean droplet, the process can complete in some 36 hours. + +Congratulations, you're now syncing with Polkadot. Keep in mind that the process is identical when +using any other Substrate chain. + +## Running an Archive Node + +When running as a simple sync node (above), only the state of the past 256 blocks will be kept. When +validating, it defaults to [archive mode](#types-of-nodes). To keep the full state use the +`--pruning` flag: + +{{ polkadot: + +```bash +./target/release/polkadot --name "My node's name" --pruning archive +``` + +:polkadot }} +{{ kusama: + +```bash +./target/release/polkadot --name "My node's name" --pruning archive --chain kusama +``` + +:kusama }} + +It is possible to almost quadruple synchronization speed by using an additional flag: +`--wasm-execution Compiled`. Note that this uses much more CPU and RAM, so it should be turned off +after the node is in sync. + +## Using Docker + +Finally, you can use Docker to run your node in a container. Doing this is a bit more advanced so +it's best left up to those that either already have familiarity with docker, or have completed the +other set-up instructions in this guide. If you would like to connect to your node's WebSockets +ensure that you run you node with the `--rpc-external` and `--ws-external` commands. + +```zsh +docker run -p 9944:9944 parity/polkadot:v0.8.24 --name "calling_home_from_a_docker_container" --rpc-external --ws-external +``` diff --git a/docs/maintain-wss.md b/docs/maintain/maintain-wss.md similarity index 97% rename from docs/maintain-wss.md rename to docs/maintain/maintain-wss.md index 015e93c06b49..280c31079d8b 100644 --- a/docs/maintain-wss.md +++ b/docs/maintain/maintain-wss.md @@ -2,6 +2,7 @@ id: maintain-wss title: Set up Secure WebSocket for Remote Connections sidebar_label: Set up Secure WebSocket for Remote Connections +slug: ../maintain-wss --- You might want to host a node on one server and then connect to it from a UI hosted on another, e.g. @@ -92,7 +93,7 @@ server { location / { try_files $uri $uri/ =404; - + proxy_buffering off; proxy_pass http://localhost:9944; proxy_set_header X-Real-IP $remote_addr; @@ -130,7 +131,7 @@ If you used the self-signed certificate approach, modern browsers will not let y websocket endpoint without that certificate being imported - they will emit an `NET:ERR_CERT_AUTHORITY_INVALID` message. -![ERR_CERT_AUTHORITY_INVALID](assets/wss/wss04.png) +![ERR_CERT_AUTHORITY_INVALID](../assets/wss/wss04.png) Every websocket connection bootstraps itself with `https` first, so to allow the certificate, visit the IP of your machine in the browser prefixed with `https`, like so: `https://MY_IP`. This should @@ -144,6 +145,6 @@ node. Activate the "Development" toggle and input your node's address - either t address. Remember to prefix with `wss://` and if you're using the 443 port, append `:443`, like so: `wss://example.com:443`. -![A sync-in-progress chain connected to Polkadot-JS UI](assets/maintain-wss-image.png) +![A sync-in-progress chain connected to Polkadot-JS UI](../assets/maintain-wss-image.png) Now you have a secure remote connect setup for your Substrate node. diff --git a/docs/redenomination.md b/docs/redenomination.md deleted file mode 100644 index c2d69d4bb226..000000000000 --- a/docs/redenomination.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> #1_248_328. - -While [DOT](learn-DOT.md) is the unit of currency on Polkadot that most people use when interacting -with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is -like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 -Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in -ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT -denominated to ten decimal places is generally referred to as "DOT". When the difference must be -made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our -> [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the -community of DOT holders. The community decided between four options, to change the DOT denomination -by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the -denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, -remained constant, while the DOT balance for all holders was increased by a factor of one hundred. -As one can see from the example below, the number of Plancks that a user has does not change, only -the number of Plancks that constitute a single DOT. A user with 1_000_000_000_000 Plancks still has -the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT -under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards -the social consensus around where to put the decimal place when we talk about what constitutes a -DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama -blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 -> DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the -> network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to -> achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that -making a redenomination would be simpler before the Polkadot chain was live. However, many in the -community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to -be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided -to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a -majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of -> Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor -> redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized -community of validators securing the network, Web3 Foundation decided to put the redenomination -topic up to a vote again. This time, the vote was explicitly binding — meaning that it would -be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at -best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as -an approval vote, with four available options. DOT holders could issue votes for any configuration -of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote -logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime -for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select -> only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a -> non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point -> that none is left for transacting and you would like to vote, please contact a representative of -> the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot -> split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, -> effective market capitalization and the underlying balances of every account remain completely -> unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the -> purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot -community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one -third of the total DOT in the network participated in the vote. The redenominaton proposal passed -with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -#1_248_328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT -redenomination was a purely front-end change. You still hold the same amount of Plancks after the -change, but now it will appear that you hold 100x more DOT. This change applies proportionally to -every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the -[`@polkadot/api`](https://yarnpkg.com/package/@polkadot/api) package — then there should be no -real changes that need to be made in your application. The denomination is technically a cosmetic -change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) -or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you -display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide][ecosystem guide] for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any -assistance in making sure your software is compatible with the redenomination. - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ -[ecosystem guide]: - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# diff --git a/docs/thousand-validators.md b/docs/thousand-validators.md deleted file mode 100644 index 3c1e4e31bcb8..000000000000 --- a/docs/thousand-validators.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use -the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of -validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on -Kusama). It will nominate validators which fit all the requirements and are eligible. Of this pool, -it will nominate as many as possible although some validators which are eligible might not receive -nominations every round (due to the constraint of nominating a maximum of 16 validators per -nominator). If a validator is active during a single nomination period (the time after a new -nomination and before the next one) and does not break any of the requirements, it will have its -rank increased by 1. Validators with higher rank have performed well within the programme for a -longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) -as well as additional information on [validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and -fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here][identity instructions] for instructions) -- Connect to dedicated telemetry (use - `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on the latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama -Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / - `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / - `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / - `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators -to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This -can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. -> This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below -and fill in the [application form][polkadot 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here][identity instructions] for instructions) -- Connect to dedicated Telemetry (use - `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Minimum of 5_000 DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on the latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot -Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / - `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / - `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / - `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators -to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This -can be anywhere from a few validators receiving nominations from a single nominator to the max -of 16. - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 -[polkadot 1kv form]: - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform -[identity instructions]: https://guide.kusama.network/docs/mirror-learn-identity#setting-an-identity diff --git a/kusama-guide-v2/i18n/zh-CN/code.json b/kusama-guide-v2/i18n/zh-CN/code.json deleted file mode 100644 index 97e1bec6ab94..000000000000 --- a/kusama-guide-v2/i18n/zh-CN/code.json +++ /dev/null @@ -1,194 +0,0 @@ -{ - "theme.NotFound.title": { - "message": "找不到页面", - "description": "The title of the 404 page" - }, - "theme.NotFound.p1": { - "message": "我们找不到您要找的页面。", - "description": "The first paragraph of the 404 page" - }, - "theme.NotFound.p2": { - "message": "请联系原始链接来源网站的所有者，并告知他们链接已损坏。", - "description": "The 2nd paragraph of the 404 page" - }, - "theme.AnnouncementBar.closeButtonAriaLabel": { - "message": "关闭", - "description": "The ARIA label for close button of announcement bar" - }, - "theme.blog.post.readingTime.plurals": { - "message": "{readingTime} 分钟阅读", - "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.tags.tagsListLabel": { - "message": "标签：", - "description": "The label alongside a tag list" - }, - "theme.blog.post.readMore": { - "message": "阅读更多", - "description": "The label used in blog post item excerpts to link to full blog posts" - }, - "theme.blog.paginator.navAriaLabel": { - "message": "博文列表分页导航", - "description": "The ARIA label for the blog pagination" - }, - "theme.blog.paginator.newerEntries": { - "message": "较新的博文", - "description": "The label used to navigate to the newer blog posts page (previous page)" - }, - "theme.blog.paginator.olderEntries": { - "message": "较旧的博文", - "description": "The label used to navigate to the older blog posts page (next page)" - }, - "theme.blog.post.paginator.navAriaLabel": { - "message": "博文分页导航", - "description": "The ARIA label for the blog posts pagination" - }, - "theme.blog.post.paginator.newerPost": { - "message": "较新一篇", - "description": "The blog post button label to navigate to the newer/previous post" - }, - "theme.blog.post.paginator.olderPost": { - "message": "较旧一篇", - "description": "The blog post button label to navigate to the older/next post" - }, - "theme.tags.tagsPageTitle": { - "message": "标签", - "description": "The title of the tag list page" - }, - "theme.blog.post.plurals": { - "message": "{count} 篇博文", - "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.tagTitle": { - "message": "{nPosts} 含有标签「{tagName}」", - "description": "The title of the page for a blog tag" - }, - "theme.tags.tagsPageLink": { - "message": "查看所有标签", - "description": "The label of the link targeting the tag list page" - }, - "theme.CodeBlock.copyButtonAriaLabel": { - "message": "复制代码到剪贴板", - "description": "The ARIA label for copy code blocks button" - }, - "theme.CodeBlock.copied": { - "message": "复制成功", - "description": "The copied button label on code blocks" - }, - "theme.CodeBlock.copy": { - "message": "复制", - "description": "The copy button label on code blocks" - }, - "theme.docs.sidebar.expandButtonTitle": { - "message": "展开侧边栏", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.sidebar.expandButtonAriaLabel": { - "message": "展开侧边栏", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.sidebar.collapseButtonTitle": { - "message": "收起侧边栏", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.docs.sidebar.collapseButtonAriaLabel": { - "message": "收起侧边栏", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.docs.sidebar.responsiveCloseButtonLabel": { - "message": "关闭菜单", - "description": "The ARIA label for close button of mobile doc sidebar" - }, - "theme.docs.sidebar.responsiveOpenButtonLabel": { - "message": "打开菜单", - "description": "The ARIA label for open button of mobile doc sidebar" - }, - "theme.docs.paginator.navAriaLabel": { - "message": "文档分页导航", - "description": "The ARIA label for the docs pagination" - }, - "theme.docs.paginator.previous": { - "message": "上一页", - "description": "The label used to navigate to the previous doc" - }, - "theme.docs.paginator.next": { - "message": "下一页", - "description": "The label used to navigate to the next doc" - }, - "theme.docs.versions.unreleasedVersionLabel": { - "message": "此为 {siteTitle} {versionLabel} 版尚未发行的文档。", - "description": "The label used to tell the user that he's browsing an unreleased doc version" - }, - "theme.docs.versions.unmaintainedVersionLabel": { - "message": "此为 {siteTitle} {versionLabel} 版的文档，现已不再积极维护。", - "description": "The label used to tell the user that he's browsing an unmaintained doc version" - }, - "theme.docs.versions.latestVersionSuggestionLabel": { - "message": "最新的文档请参阅 {latestVersionLink} ({versionLabel})。", - "description": "The label userd to tell the user that he's browsing an unmaintained doc version" - }, - "theme.docs.versions.latestVersionLinkLabel": { - "message": "最新版本", - "description": "The label used for the latest version suggestion link label" - }, - "theme.common.editThisPage": { - "message": "编辑此页", - "description": "The link label to edit the current page" - }, - "theme.common.headingLinkTitle": { - "message": "标题的直接链接", - "description": "Title for link to heading" - }, - "theme.lastUpdated.atDate": { - "message": "于 {date} ", - "description": "The words used to describe on which date a page has been last updated" - }, - "theme.lastUpdated.byUser": { - "message": "由 {user} ", - "description": "The words used to describe by who the page has been last updated" - }, - "theme.lastUpdated.lastUpdatedAtBy": { - "message": "最后{byUser}{atDate}更新", - "description": "The sentence used to display when a page has been last updated, and by who" - }, - "theme.common.skipToMainContent": { - "message": "跳到主要内容", - "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" - }, - "theme.SearchPage.documentsFound.plurals": { - "message": "找到 {count} 份文件", - "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.SearchPage.existingResultsTitle": { - "message": "「{query}」的搜索结果", - "description": "The search page title for non-empty query" - }, - "theme.SearchPage.emptyResultsTitle": { - "message": "在文档中搜索", - "description": "The search page title for empty query" - }, - "theme.SearchPage.inputPlaceholder": { - "message": "在此输入搜索字词", - "description": "The placeholder for search page input" - }, - "theme.SearchPage.inputLabel": { - "message": "搜索", - "description": "The ARIA label for search page input" - }, - "theme.SearchPage.algoliaLabel": { - "message": "通过 Algolia 搜索", - "description": "The ARIA label for Algolia mention" - }, - "theme.SearchPage.noResultsText": { - "message": "未找到任何结果", - "description": "The paragraph for empty search result" - }, - "theme.SearchPage.fetchingNewResults": { - "message": "正在获取新的搜索结果...", - "description": "The paragraph for fetching new search results" - }, - "theme.SearchBar.label": { - "message": "搜索", - "description": "The ARIA label and placeholder for search button" - } -} \ No newline at end of file diff --git a/kusama-guide-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current.json b/kusama-guide-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current.json deleted file mode 100644 index 22e533af38a0..000000000000 --- a/kusama-guide-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current.json +++ /dev/null @@ -1,22 +0,0 @@ -{ - "version.label": { - "message": "Next", - "description": "The label for version current" - }, - "sidebar.docs.category.Kumasa": { - "message": "Kumasa", - "description": "The label for category Kumasa in sidebar docs" - }, - "sidebar.docs.category.Get Started": { - "message": "Get Started", - "description": "The label for category Get Started in sidebar docs" - }, - "sidebar.docs.category.What to Try": { - "message": "What to Try", - "description": "The label for category What to Try in sidebar docs" - }, - "sidebar.docs.category.What to Break": { - "message": "What to Break", - "description": "The label for category What to Break in sidebar docs" - } -} \ No newline at end of file diff --git a/kusama-guide-v2/i18n/zh-CN/docusaurus-theme-classic/navbar.json b/kusama-guide-v2/i18n/zh-CN/docusaurus-theme-classic/navbar.json deleted file mode 100644 index f79d2c6027e4..000000000000 --- a/kusama-guide-v2/i18n/zh-CN/docusaurus-theme-classic/navbar.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "title": { - "message": "Guide", - "description": "The title in the navbar" - }, - "item.label.Get Started": { - "message": "Get Started", - "description": "Navbar item with label Get Started" - }, - "item.label.Docs": { - "message": "Docs", - "description": "Navbar item with label Docs" - } -} \ No newline at end of file diff --git a/kusama-guide-v2/postprocess.js b/kusama-guide-v2/postprocess.js deleted file mode 100644 index 7c308b992042..000000000000 --- a/kusama-guide-v2/postprocess.js +++ /dev/null @@ -1,11 +0,0 @@ -// postprocess.js -'use strict'; - -require('loud-rejection/register'); - -const path = require('path'); -const { postProcess } = require('../scripts/utils'); - -const buildDirectory = path.join(__dirname, 'build'); - -postProcess(buildDirectory); diff --git a/kusama-guide-v2/sidebars.js b/kusama-guide-v2/sidebars.js deleted file mode 100644 index 91952f2e05ba..000000000000 --- a/kusama-guide-v2/sidebars.js +++ /dev/null @@ -1,56 +0,0 @@ -module.exports = { - docs: [ - { - type: "category", - label: "Kusama", - items: [ - "kusama-index", - { - type: "category", - label: "Get Started", - items: [ - "kusama-getting-started", - "kusama-faucet", - "kusama-claims", - "kusama-endpoints", - "mirror-learn-balance-transfers", - "mirror-thousand-validators", - "mirror-learn-auction", - "mirror-learn-parachains", - "mirror-learn-parathreads", - "mirror-learn-crowdloans", - ], - }, - { - type: "category", - label: "What to Try", - items: [ - "mirror-maintain-guides-how-to-validate-kusama", - "mirror-maintain-guides-how-to-stop-validating", - "mirror-maintain-guides-how-to-nominate-kusama", - "mirror-learn-governance", - "mirror-learn-identity", - "mirror-learn-treasury", - "mirror-learn-registrar", - "mirror-build-build-with-polkadot", - "mirror-build-parachains-rococo", - "maintain-guides-society-kusama", - "kusama-social-recovery", - ], - }, - { - type: "category", - label: "What to Break", - items: ["mirror-maintain-errors", "kusama-bug-bounty", "kusama-adversarial-cheatsheet"], - }, - "mirror-ens", - "kusama-ledger", - "kusama-statemine-ledger", - "kusama-timeline", - "kusama-community", - "kusama-parameters", - "kusama-coc", - ], - }, - ], -}; diff --git a/kusama-guide-v2/src/css/customTheme.css b/kusama-guide-v2/src/css/customTheme.css deleted file mode 100644 index d5fba05a6410..000000000000 --- a/kusama-guide-v2/src/css/customTheme.css +++ /dev/null @@ -1,9 +0,0 @@ -:root{ - --ifm-color-primary-lightest: #FF2C9C; - --ifm-color-primary-lighter: #FF0A8C; - --ifm-color-primary-light: #FD0086; - --ifm-color-primary: #E6007A; - --ifm-color-primary-dark: #CF006E; - --ifm-color-primary-darker: #C40068; - --ifm-color-primary-darkest: #A10055; -} diff --git a/kusama-guide-v2/src/pages/index.js b/kusama-guide-v2/src/pages/index.js deleted file mode 100644 index b9dad53f8518..000000000000 --- a/kusama-guide-v2/src/pages/index.js +++ /dev/null @@ -1,115 +0,0 @@ -const React = require("react"); - -import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; -import Layout from "@theme/Layout"; - -function HomeSplash() { - const SplashContainer = (props) => ( -
-
{props.children}
-
- ); - - return ( - -
- -
- - ); -} - -export default function Index() { - const { siteConfig } = useDocusaurusContext(); - - const { baseUrl } = siteConfig; - const docsPart = "docs/"; - const docUrl = (doc) => `${baseUrl}${docsPart}${doc}`; - return ( - -
-
- -
-
-
-

- Kusama is an early, unaudited and unrefined release of Polkadot. Kusama will serve as - a proving ground, allowing teams and developers to build and deploy a parachain or try - out Polkadot’s governance, staking, nomination and validation functionality in a real - environment. -

-
-
-
-

What can you do with Kusama?

-
-
-
-

Become a Validator

-
-
-

- The minimum requirement for staking as a validator on Kusama is much lower than it - is expected for Polkadot. There are also programs in place such as{" "} - - Thousand Validators - {" "} - to help community validators rise the ranks. -

- - - -
-
-
-
-

Deploy Parachains

-

- Kusama will get the functionality required for parachains before Polkadot. This - includes participating in a parachain slot auction and composable applications. -

- - - -
-
-

Explore the politics

-

- Campaign as a councillor or vote for new runtime proposals using Democracy. -

- - - -
-
-
-
-

Join a cyber secret society

-

- The Kappa Sigma Mu fraternity asks you to get a Kusama tattoo to join. -

- - - -
-
-
-
- - ); -} diff --git a/kusama-guide-v2/src/theme/Footer.js b/kusama-guide-v2/src/theme/Footer.js deleted file mode 100644 index 25608cc24841..000000000000 --- a/kusama-guide-v2/src/theme/Footer.js +++ /dev/null @@ -1,69 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -import * as React from "react"; -import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; - -export default function Footer() { - const { siteConfig } = useDocusaurusContext(); - - const docUrl = (url) => `${siteConfig.baseUrl}docs/${url}`; - - return ( - - ); -} diff --git a/kusama-guide-v2/static/css/custom.css b/kusama-guide-v2/static/css/custom.css deleted file mode 100755 index 22a9217e5f0e..000000000000 --- a/kusama-guide-v2/static/css/custom.css +++ /dev/null @@ -1,559 +0,0 @@ -:root { - --ifm-color-primary: #e6007a; - --ifm-color-primary-dark: #cf006e; - --ifm-color-primary-darker: #c40068; - --ifm-color-primary-darkest: #a10055; - --ifm-color-primary-light: #fd0086; - --ifm-color-primary-lighter: #ff0a8c; - --ifm-color-primary-lightest: #ff2c9c; - --ifm-navbar-link-color: #ffffff; - --ifm-navbar-link-hover-color: #ffffff; - --docsearch-searchbox-focus-background: transparent; - --docsearch-text-color: rgb(2,2,2); -} - -@font-face { - font-family: "SpaceMono-Regular"; - src: url("../fonts/SpaceMono-Regular.ttf"); - src: url("../fonts/SpaceMono-Regular.ttf?#iefix") format("embedded-opentype"), - url("../fonts/SpaceMono-Regular.ttf") format("woff"), - url("../fonts/SpaceMono-Regular.ttf") format("truetype"), - url("../fonts/SpaceMono-Regular.ttf") format("svg"); -} - -/* ========================================================================== - General components - ========================================================================== */ - -/* Back to top button */ -#back-to-top { - left: 16px; - bottom: 26px; - background: var(--ifm-color-primary); - color: #fff; - height: 48px; - width: 48px; - z-index: 999; -} - -#back-to-top svg { - margin-top: 12px; -} - -#support_us { - color: white; - text-decoration: none; - font-weight: bold -} - -/* ========================================================================== - Sidebar - ========================================================================== */ - -button.menu__button { - box-shadow: 0 2px 5px 0 rgba(0,0,0,.26); -} - -.menu--responsive .menu__button { - background: var(--ifm-color-primary); - border-color: var(--ifm-color-primary); - color: white; -} - -.navbar-sidebar__brand { - background-color: black; - height: 50px; -} - -.navbar-sidebar--show .navbar__link--active { - color: #606770; -} - -/* ========================================================================== - Navigation bar - ========================================================================== */ - -.navbar.navbar--fixed-top { - background: black; -} - -.navbar.navbar--fixed-top .navbar__inner { - max-width: 1360px; - margin: 0 auto 0; -} - -.navbar__inner a.navbar__item svg[class^="iconExternalLink"] { - display: none -} - -.navbar__link { - background-color: black; - transition: background-color 0.3s -} - -.navbar__link:hover { - background-color: var(--ifm-color-primary); -} - -/* Menu button */ -button.navbar__toggle { - color: white; -} - -/* Logo */ -.navbar__brand:hover { - color: white -} - -.navbar__brand strong:hover { - color: white; -} - -.navbar .navbar__title { - display:block; - font-size:1.25em; - line-height:18px; - margin:0; - position:relative; -} - -/* Search bar */ -@media only screen and (max-width: 750px) { - .DocSearch.DocSearch-Button { - width: 36px; - padding-left: 8px; - } -} - -.DocSearch-Button-Keys { - display: none !important; -} - -button.DocSearch { - background-color:rgba(0,0,0,.2); - box-shadow: var(--docsearch-searchbox-shadow); - border-radius:20px; - color: white; - font-size:14px; - font-weight:300; - line-height:20px; - outline:none; - padding-left:25px; - position:relative; - transition:width .5s ease; - width:170px -} - -button.DocSearch-Button:active, button.DocSearch-Button:focus, button.DocSearch-Button:hover { - background: rgba(0,0,0,.2); - color: white; -} -button.DocSearch svg { - color: white !important; -} - -/* Languages menu */ - -.dropdown > a { - margin-left: 12px; - padding: 4px 8px !important; -} - -.dropdown__menu { - top: 35px; - text-align: center; - background-color: black; - padding: 0; - box-shadow: 0 4px 7px 0 rgba(255, 255, 255, 0.2); -} - -.dropdown__menu a { - color: white; - border-radius: 0; -} - -.dropdown__menu a:hover { - background-color: var(--ifm-color-primary); - color: white; -} - -.dropdown__menu a.dropdown__link--active { - background-color: black; -} - -.dropdown__menu a.dropdown__link--active:hover { - background-color: var(--ifm-color-primary); -} - -.dropdown a:first-child::after { - display: none !important -} - -/* ========================================================================== - Footer - ========================================================================== */ - -.nav-footer { - background: black; -} - -.nav-footer .row { - display: flex; - justify-content: center; -} - -.nav-footer .row .item { - padding-left: 16px; - color: rgba(255, 255, 255, 0.4); -} - -.nav-footer p { - color: rgba(255, 255, 255, 0.4); -} - -.nav-footer .row .item:hover { - color: #ffffff; -} - -#footer section.row { - margin: 0 !important -} - -.nav-footer { - background:#000; - border:none; - color:#202020; - font-size:15px; - -webkit-font-smoothing:antialiased; - -moz-osx-font-smoothing:grayscale; - font-weight:400; - line-height:24px; - padding-bottom:2em; - padding-top:2em; - position:relative -} -@media only screen and (min-width:1024px) { - .nav-footer { - flex-shrink:0 - } -} -.nav-footer .sitemap { - display:flex; - justify-content:space-between; - margin:0 auto 3em; - max-width:1080px -} -.nav-footer .sitemap div { - flex:1 -} -.nav-footer .sitemap .nav-home { - display:table; - height:72px; - margin:-12px 20px 0 0; - opacity:.4; - padding:10px; - transition:opacity .15s ease-in-out; - width:72px -} -.nav-footer .sitemap .nav-home:focus, -.nav-footer .sitemap .nav-home:hover { - opacity:1 -} -@media only screen and (max-width:735px) { - .nav-footer .sitemap { - display:flex; - flex-direction:column; - margin:0 2em 3em; - width:calc(100% - 4em) - } - .nav-footer .sitemap>div { - margin-bottom:18px - } -} -.nav-footer .sitemap a { - color:hsla(0,0%,100%,.6); - display:block; - margin:2px 0; - padding:3px 0 -} -.nav-footer .sitemap a:focus, -.nav-footer .sitemap a:hover, -.nav-footer .sitemap h5>a:focus, -.nav-footer .sitemap h5>a:hover { - color:#fff; - text-decoration:none -} -.nav-footer .sitemap h5, -.nav-footer .sitemap h6 { - margin:0 0 10px -} -.nav-footer .sitemap h5, -.nav-footer .sitemap h5>a, -.nav-footer .sitemap h6, -.nav-footer .sitemap h6>a { - color:#fff -} -.nav-footer .sitemap h5>a, -.nav-footer .sitemap h6>a { - margin:0 -10px -} -.nav-footer .fbOpenSource { - display:block; - margin:1em auto; - opacity:.4; - transition:opacity .15s ease-in-out; - width:170px -} -.nav-footer .fbOpenSource:hover { - opacity:1 -} -.nav-footer .copyright { - color:hsla(0,0%,100%,.4); - text-align:center -} -.nav-footer .social { - padding:5px 0 -} - -.bgColor { - background-color: black; -} - -.no-margin { - margin: 0 !important; - width: 100%; -} - -.main-wrapper { - left:0; - min-height: 100%; - position: relative; - z-index: 99 -} - -.main-wrapper::after { - background:rgba(0,0,0,.4); - content:""; - height:0; - opacity:0; - position:absolute; - right:0; - top:0; - transition:opacity .5s,width .1s .5s,height .1s .5s; - width:0 -} - -body { - font-family: "Muli", sans-serif !important; -} - -/* ========================================================================== - Doc page - ========================================================================== */ - -.docs-wrapper { - margin-left: auto; - margin-right: auto; - max-width: 1400px; - width: 100%; - padding-bottom: 50px; -} - -article blockquote { - background-color: rgba(255,229,100,.3); - border-left: 8px solid #ffe564; - padding: 15px 30px 15px 15px; -} - - -article iframe, article img { - display: block; - margin-left: auto; - margin-right: auto; - max-width: 100% -} - -/* ========================================================================== - Homepage - ========================================================================== */ - -.homepage-font { - font-family: "SpaceMono-Regular", "Helvetica", "Arial", sans-serif; -} - -.homeContainer { - background: white; - height: 50vh; -} - -.kusamaHomeContainer { - background: black; -} - -.main-wrapper .kusamaHomeContainer .wrapper { - margin:0 auto; - max-width:1360px; - padding:0 20px -} - -.main-wrapper .kusama-mainpage-row-validator { - background-color: white; -} - -.kusama-full-width { - width: 100%; - text-align: center; - margin: 50px; -} - -.kusama-full-width-main { - width: 60%; - text-align: center; - margin: 50px; - height: auto; -} - -.mainpage-row-placeholder { - background: black; - width: 100%; - height: 100px; - padding: 0; -} - -.kusama-mainpage-row-learn { - display: flex; - flex-flow: row wrap; - justify-content: center; - width: 100%; - padding: 1% 0; - color: white; - background: black; -} - -.kusama-mainpage-row { - display: flex; - flex-flow: row wrap; - justify-content: center; - width: 100%; - padding: 0; - color: white; - background: url("../img/kusama-pink-row.svg") center black; -} - -.kusama-mainpage-cyber-row { - display: flex; - flex-flow: row wrap; - justify-content: center; - width: 100%; - padding: 0; - color: white; - background: url("../img/Kusama-white-stencil.png") left center no-repeat black; - background-size: 40%; -} - -.kusama-mainpage-row-validator { - width: 100%; - display: flex; - padding: 0; - flex-flow: row wrap; - justify-content: center; - color: black; -} - -.kusama-mainpage-row-more { - display: flex; - flex-flow: row wrap; - justify-content: center; - width: 100%; - padding: 0; - color: white; - background: black; - border-bottom: 10px solid var(--ifm-color-primary); -} - -.kusama-mainpage-column { - width: 50%; - display: flex; - align-items: center; - padding: 2%; - text-align: center; - flex-flow: column; -} - -@media only screen and (min-device-width: 360px) and (max-device-width: 736px) { - .mainpage-column { - width: 100% !important; - } -} - -.kusama-mainpage-build-btn { - background: transparent; - border: 1px solid var(--ifm-color-primary); - color: var(--ifm-color-primary); - width: 100%; - font-weight: 500; - padding: 10px; - font-size: 14px; - margin-top: 24px; - text-align: center; - vertical-align: middle; - margin-bottom: 0.75rem !important; - display: inline-block; - line-height: 1.5; - cursor: pointer; -} - -.kusama-mainpage-build-btn:hover { - color: #00ffe1; - border-color: #00ffe1; -} - -.mainpage-build-btn:hover { - color: #00ffe1; - border: 1px solid #00ffe1; -} - -.mainpage-column { - width: 50%; - display: flex; - align-items: center; - padding: 5%; - text-align: center; - flex-flow: column; -} -@media only screen and (max-width: 700px) { - .docsContainer > .wrapper > .post { - padding-top: 50px; - } - - #docsNav { - top: 130px; - } - - a.navbar__link, a.navbar__link:hover, a.navbar__link:active { - color: black !important - } -} - -.nomargin { - margin: 0; -} - -@media print { - .docsNavContainer, - .navbar.navbar--fixed-top, - .github-fork-ribbon, - .toc, - .slidingNav, - .edit-page-link, - .docLastUpdate, - footer, - #back-to-top { - padding-top: 0; - display: none; - } - - .main-wrapper { - padding-top: 0; - } -} diff --git a/kusama-guide-v2/static/fonts/OFL.txt b/kusama-guide-v2/static/fonts/OFL.txt deleted file mode 100755 index 5bb7346e6a56..000000000000 --- a/kusama-guide-v2/static/fonts/OFL.txt +++ /dev/null @@ -1,93 +0,0 @@ -Copyright 2016 Google Inc. All Rights Reserved. - -This Font Software is licensed under the SIL Open Font License, Version 1.1. -This license is copied below, and is also available with a FAQ at: -http://scripts.sil.org/OFL - - ------------------------------------------------------------ -SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 ------------------------------------------------------------ - -PREAMBLE -The goals of the Open Font License (OFL) are to stimulate worldwide -development of collaborative font projects, to support the font creation -efforts of academic and linguistic communities, and to provide a free and -open framework in which fonts may be shared and improved in partnership -with others. - -The OFL allows the licensed fonts to be used, studied, modified and -redistributed freely as long as they are not sold by themselves. The -fonts, including any derivative works, can be bundled, embedded, -redistributed and/or sold with any software provided that any reserved -names are not used by derivative works. The fonts and derivatives, -however, cannot be released under any other type of license. The -requirement for fonts to remain under this license does not apply -to any document created using the fonts or their derivatives. - -DEFINITIONS -"Font Software" refers to the set of files released by the Copyright -Holder(s) under this license and clearly marked as such. This may -include source files, build scripts and documentation. - -"Reserved Font Name" refers to any names specified as such after the -copyright statement(s). - -"Original Version" refers to the collection of Font Software components as -distributed by the Copyright Holder(s). - -"Modified Version" refers to any derivative made by adding to, deleting, -or substituting -- in part or in whole -- any of the components of the -Original Version, by changing formats or by porting the Font Software to a -new environment. - -"Author" refers to any designer, engineer, programmer, technical -writer or other person who contributed to the Font Software. - -PERMISSION & CONDITIONS -Permission is hereby granted, free of charge, to any person obtaining -a copy of the Font Software, to use, study, copy, merge, embed, modify, -redistribute, and sell modified and unmodified copies of the Font -Software, subject to the following conditions: - -1) Neither the Font Software nor any of its individual components, -in Original or Modified Versions, may be sold by itself. - -2) Original or Modified Versions of the Font Software may be bundled, -redistributed and/or sold with any software, provided that each copy -contains the above copyright notice and this license. These can be -included either as stand-alone text files, human-readable headers or -in the appropriate machine-readable metadata fields within text or -binary files as long as those fields can be easily viewed by the user. - -3) No Modified Version of the Font Software may use the Reserved Font -Name(s) unless explicit written permission is granted by the corresponding -Copyright Holder. This restriction only applies to the primary font name as -presented to the users. - -4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font -Software shall not be used to promote, endorse or advertise any -Modified Version, except to acknowledge the contribution(s) of the -Copyright Holder(s) and the Author(s) or with their explicit written -permission. - -5) The Font Software, modified or unmodified, in part or in whole, -must be distributed entirely under this license, and must not be -distributed under any other license. The requirement for fonts to -remain under this license does not apply to any document created -using the Font Software. - -TERMINATION -This license becomes null and void if any of the above conditions are -not met. - -DISCLAIMER -THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, -EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT -OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE -COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL -DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING -FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM -OTHER DEALINGS IN THE FONT SOFTWARE. diff --git a/kusama-guide-v2/static/fonts/SpaceMono-Bold.ttf b/kusama-guide-v2/static/fonts/SpaceMono-Bold.ttf deleted file mode 100755 index 7e29074601be..000000000000 Binary files a/kusama-guide-v2/static/fonts/SpaceMono-Bold.ttf and /dev/null differ diff --git a/kusama-guide-v2/static/fonts/SpaceMono-BoldItalic.ttf b/kusama-guide-v2/static/fonts/SpaceMono-BoldItalic.ttf deleted file mode 100755 index f5ef8e3fb99f..000000000000 Binary files a/kusama-guide-v2/static/fonts/SpaceMono-BoldItalic.ttf and /dev/null differ diff --git a/kusama-guide-v2/static/fonts/SpaceMono-Regular.ttf b/kusama-guide-v2/static/fonts/SpaceMono-Regular.ttf deleted file mode 100755 index 9e12b74080dc..000000000000 Binary files a/kusama-guide-v2/static/fonts/SpaceMono-Regular.ttf and /dev/null differ diff --git a/kusama-guide-v2/static/fonts/SpaceMono-RegularItalic.ttf b/kusama-guide-v2/static/fonts/SpaceMono-RegularItalic.ttf deleted file mode 100755 index 20292d2e86f4..000000000000 Binary files a/kusama-guide-v2/static/fonts/SpaceMono-RegularItalic.ttf and /dev/null differ diff --git a/kusama-guide-v2/static/img/Kusama-white-stencil.png b/kusama-guide-v2/static/img/Kusama-white-stencil.png deleted file mode 100644 index 0fdabcf4debd..000000000000 Binary files a/kusama-guide-v2/static/img/Kusama-white-stencil.png and /dev/null differ diff --git a/kusama-guide-v2/static/img/Kusama_header_pink.png b/kusama-guide-v2/static/img/Kusama_header_pink.png deleted file mode 100644 index e453668154cc..000000000000 Binary files a/kusama-guide-v2/static/img/Kusama_header_pink.png and /dev/null differ diff --git a/kusama-guide-v2/static/img/Kusama_logotype_white_large.png b/kusama-guide-v2/static/img/Kusama_logotype_white_large.png deleted file mode 100644 index c1c1bf4e1e1a..000000000000 Binary files a/kusama-guide-v2/static/img/Kusama_logotype_white_large.png and /dev/null differ diff --git a/kusama-guide-v2/static/img/icon_validator.svg b/kusama-guide-v2/static/img/icon_validator.svg deleted file mode 100644 index 4bc832dafd66..000000000000 --- a/kusama-guide-v2/static/img/icon_validator.svg +++ /dev/null @@ -1 +0,0 @@ -icon-future-proof \ No newline at end of file diff --git a/kusama-guide-v2/static/img/kusama-pink-row.svg b/kusama-guide-v2/static/img/kusama-pink-row.svg deleted file mode 100644 index 553ad10066cf..000000000000 --- a/kusama-guide-v2/static/img/kusama-pink-row.svg +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - diff --git a/kusama-guide-v2/static/js/clipboard.min.js b/kusama-guide-v2/static/js/clipboard.min.js deleted file mode 100644 index 28650f3cc98a..000000000000 --- a/kusama-guide-v2/static/js/clipboard.min.js +++ /dev/null @@ -1,7 +0,0 @@ -/*! - * clipboard.js v2.0.6 - * https://clipboardjs.com/ - * - * Licensed MIT © Zeno Rocha - */ -!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.ClipboardJS=e():t.ClipboardJS=e()}(this,function(){return o={},r.m=n=[function(t,e){t.exports=function(t){var e;if("SELECT"===t.nodeName)t.focus(),e=t.value;else if("INPUT"===t.nodeName||"TEXTAREA"===t.nodeName){var n=t.hasAttribute("readonly");n||t.setAttribute("readonly",""),t.select(),t.setSelectionRange(0,t.value.length),n||t.removeAttribute("readonly"),e=t.value}else{t.hasAttribute("contenteditable")&&t.focus();var o=window.getSelection(),r=document.createRange();r.selectNodeContents(t),o.removeAllRanges(),o.addRange(r),e=o.toString()}return e}},function(t,e){function n(){}n.prototype={on:function(t,e,n){var o=this.e||(this.e={});return(o[t]||(o[t]=[])).push({fn:e,ctx:n}),this},once:function(t,e,n){var o=this;function r(){o.off(t,r),e.apply(n,arguments)}return r._=e,this.on(t,r,n)},emit:function(t){for(var e=[].slice.call(arguments,1),n=((this.e||(this.e={}))[t]||[]).slice(),o=0,r=n.length;o' + - icon + - '' + - label + - "" + - "
"; - return btn; - } - - function addButtons(codeBlockSelector, btn) { - document.querySelectorAll(codeBlockSelector).forEach(function (code) { - code.parentNode.appendChild(btn.cloneNode(true)); - }); - } - - const copyIcon = - ''; - - addButtons(".hljs", button("Copy", "Copy code to clipboard", copyIcon, "btnClipboard")); - - const clipboard = new ClipboardJS(".btnClipboard", { - target: function (trigger) { - return trigger.parentNode.querySelector("code"); - }, - }); - - clipboard.on("success", function (event) { - event.clearSelection(); - const textEl = event.trigger.querySelector(".btnIcon__label"); - textEl.textContent = "Copied"; - setTimeout(function () { - textEl.textContent = "Copy"; - }, 2000); - }); -}); diff --git a/kusama-guide-v2/static/js/custom.js b/kusama-guide-v2/static/js/custom.js deleted file mode 100644 index ebc556dd1af5..000000000000 --- a/kusama-guide-v2/static/js/custom.js +++ /dev/null @@ -1,93 +0,0 @@ -(function (funcName, baseObj) { - // The public function name defaults to window.docReady - // but you can pass in your own object and own function name and those will be used - // if you want to put them in a different namespace - funcName = funcName || "docReady"; - baseObj = baseObj || window; - var readyList = []; - var readyFired = false; - var readyEventHandlersInstalled = false; - - // call this when the document is ready - // this function protects itself against being called more than once - function ready() { - if (!readyFired) { - // this must be set to true before we start calling callbacks - readyFired = true; - for (var i = 0; i < readyList.length; i++) { - // if a callback here happens to add new ready handlers, - // the docReady() function will see that it already fired - // and will schedule the callback to run right after - // this event loop finishes so all handlers will still execute - // in order and no new ones will be added to the readyList - // while we are processing the list - readyList[i].fn.call(window, readyList[i].ctx); - } - // allow any closures held by these functions to free - readyList = []; - } - } - - function readyStateChange() { - if (document.readyState === "complete") { - ready(); - } - } - - // This is the one public interface - // docReady(fn, context); - // the context argument is optional - if present, it will be passed - // as an argument to the callback - baseObj[funcName] = function (callback, context) { - if (typeof callback !== "function") { - throw new TypeError("callback for docReady(fn) must be a function"); - } - // if ready has already fired, then just schedule the callback - // to fire asynchronously, but right away - if (readyFired) { - setTimeout(function () { - callback(context); - }, 1); - return; - } else { - // add the function and context to the list - readyList.push({ - fn: callback, - ctx: context, - }); - } - // if document already ready to go, schedule the ready function to run - if (document.readyState === "complete") { - setTimeout(ready, 1); - } else if (!readyEventHandlersInstalled) { - // otherwise if we don't have event handlers installed, install them - if (document.addEventListener) { - // first choice is DOMContentLoaded event - document.addEventListener("DOMContentLoaded", ready, false); - // backup is window load event - window.addEventListener("load", ready, false); - } else { - // must be IE - document.attachEvent("onreadystatechange", readyStateChange); - window.attachEvent("onload", ready); - } - readyEventHandlersInstalled = true; - } - }; -})("docReady", window); - -docReady(function () { - setTimeout(function () { - // Custom logic goes here - - // Insert "Improve this wiki ribbon": Done in docusaurus.config.js - - // Add fathom to footer - let script = document.createElement("script"); - script.setAttribute("src", "https://lion.kusama.network/script.js"); - script.setAttribute("site", "PNZSQVUV"); - document.querySelector("#footer").appendChild(script); - - // Force edit button to go to non-mirror page: Done in docusaurus.config.js - }, 1000); -}); diff --git a/kusama-guide/README.md b/kusama-guide/README.md deleted file mode 100755 index f3da77ff3424..000000000000 --- a/kusama-guide/README.md +++ /dev/null @@ -1,193 +0,0 @@ -This website was created with [Docusaurus](https://docusaurus.io/). - -# What's In This Document - -* [Get Started in 5 Minutes](#get-started-in-5-minutes) -* [Directory Structure](#directory-structure) -* [Editing Content](#editing-content) -* [Adding Content](#adding-content) -* [Full Documentation](#full-documentation) - -# Get Started in 5 Minutes - -1. Make sure all the dependencies for the website are installed: - -```sh -# Install dependencies -$ yarn -``` -2. Run your dev server: - -```sh -# Start the site -$ yarn start -``` - -## Directory Structure - -Your project file structure should look something like this - -``` -my-docusaurus/ - docs/ - doc-1.md - doc-2.md - doc-3.md - website/ - blog/ - 2016-3-11-oldest-post.md - 2017-10-24-newest-post.md - core/ - node_modules/ - pages/ - static/ - css/ - img/ - package.json - sidebar.json - siteConfig.js -``` - -# Editing Content - -## Editing an existing docs page - -Edit docs by navigating to `docs/` and editing the corresponding document: - -`docs/doc-to-be-edited.md` - -```markdown ---- -id: page-needs-edit -title: This Doc Needs To Be Edited ---- - -Edit me... -``` - -For more information about docs, click [here](https://docusaurus.io/docs/en/navigation) - -## Editing an existing blog post - -Edit blog posts by navigating to `website/blog` and editing the corresponding post: - -`website/blog/post-to-be-edited.md` -```markdown ---- -id: post-needs-edit -title: This Blog Post Needs To Be Edited ---- - -Edit me... -``` - -For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog) - -# Adding Content - -## Adding a new docs page to an existing sidebar - -1. Create the doc as a new markdown file in `/docs`, example `docs/newly-created-doc.md`: - -```md ---- -id: newly-created-doc -title: This Doc Needs To Be Edited ---- - -My new content here.. -``` - -1. Refer to that doc's ID in an existing sidebar in `website/sidebar.json`: - -```javascript -// Add newly-created-doc to the Getting Started category of docs -{ - "docs": { - "Getting Started": [ - "quick-start", - "newly-created-doc" // new doc here - ], - ... - }, - ... -} -``` - -For more information about adding new docs, click [here](https://docusaurus.io/docs/en/navigation) - -## Adding a new blog post - -1. Make sure there is a header link to your blog in `website/siteConfig.js`: - -`website/siteConfig.js` -```javascript -headerLinks: [ - ... - { blog: true, label: 'Blog' }, - ... -] -``` - -2. Create the blog post with the format `YYYY-MM-DD-My-Blog-Post-Title.md` in `website/blog`: - -`website/blog/2018-05-21-New-Blog-Post.md` - -```markdown ---- -author: Frank Li -authorURL: https://twitter.com/foobarbaz -authorFBID: 503283835 -title: New Blog Post ---- - -Lorem Ipsum... -``` - -For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog) - -## Adding items to your site's top navigation bar - -1. Add links to docs, custom pages or external links by editing the headerLinks field of `website/siteConfig.js`: - -`website/siteConfig.js` -```javascript -{ - headerLinks: [ - ... - /* you can add docs */ - { doc: 'my-examples', label: 'Examples' }, - /* you can add custom pages */ - { page: 'help', label: 'Help' }, - /* you can add external links */ - { href: 'https://github.com/facebook/Docusaurus', label: 'GitHub' }, - ... - ], - ... -} -``` - -For more information about the navigation bar, click [here](https://docusaurus.io/docs/en/navigation) - -## Adding custom pages - -1. Docusaurus uses React components to build pages. The components are saved as .js files in `website/pages/en`: -1. If you want your page to show up in your navigation header, you will need to update `website/siteConfig.js` to add to the `headerLinks` element: - -`website/siteConfig.js` -```javascript -{ - headerLinks: [ - ... - { page: 'my-new-custom-page', label: 'My New Custom Page' }, - ... - ], - ... -} -``` - -For more information about custom pages, click [here](https://docusaurus.io/docs/en/custom-pages). - -# Full Documentation - -Full documentation can be found on the [website](https://docusaurus.io/). diff --git a/kusama-guide/core/Footer.js b/kusama-guide/core/Footer.js deleted file mode 100755 index 2153e32a53ca..000000000000 --- a/kusama-guide/core/Footer.js +++ /dev/null @@ -1,94 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require("react"); - -class Footer extends React.Component { - docUrl(doc, language) { - const baseUrl = this.props.config.baseUrl; - const docsUrl = this.props.config.docsUrl; - const docsPart = `${docsUrl ? `${docsUrl}/` : ""}`; - const langPart = `${language ? `${language}/` : ""}`; - return `${baseUrl}${docsPart}${langPart}${doc}`; - } - - pageUrl(doc, language) { - const baseUrl = this.props.config.baseUrl; - return baseUrl + (language ? `${language}/` : "") + doc; - } - - render() { - return ( - - ); - } -} - -module.exports = Footer; diff --git a/kusama-guide-v2/docusaurus.config.js b/kusama-guide/docusaurus.config.js similarity index 100% rename from kusama-guide-v2/docusaurus.config.js rename to kusama-guide/docusaurus.config.js diff --git a/kusama-guide-v2/i18n.js b/kusama-guide/i18n.js similarity index 100% rename from kusama-guide-v2/i18n.js rename to kusama-guide/i18n.js diff --git a/kusama-guide/i18n/ar-SA.json b/kusama-guide/i18n/ar-SA.json deleted file mode 100644 index a76499388214..000000000000 --- a/kusama-guide/i18n/ar-SA.json +++ /dev/null @@ -1,273 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/ar.json b/kusama-guide/i18n/ar.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/kusama-guide/i18n/ar.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/es-ES.json b/kusama-guide/i18n/es-ES.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/es-ES.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/fi-FI.json b/kusama-guide/i18n/fi-FI.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/fi-FI.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/hi-IN.json b/kusama-guide/i18n/hi-IN.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/hi-IN.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/id-ID.json b/kusama-guide/i18n/id-ID.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/id-ID.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/ja-JP.json b/kusama-guide/i18n/ja-JP.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/ja-JP.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/ja.json b/kusama-guide/i18n/ja.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/kusama-guide/i18n/ja.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/ko-KR.json b/kusama-guide/i18n/ko-KR.json deleted file mode 100644 index 90b50c269d16..000000000000 --- a/kusama-guide/i18n/ko-KR.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "다음", - "previous": "이전", - "tagline": "폴카닷을 배우거나, 만들고, 노드를 돌리는 데 관심있는 사람들을 위한 허브", - "docs": { - "build-build-with-polkadot": { - "title": "폴카닷 개발자 새내기 가이드", - "sidebar_label": "폴카닷 개발자 새내기 가이드" - }, - "build-cumulus": { - "title": "큐뮬러스(뭉게구름)", - "sidebar_label": "큐뮬러스(뭉게구름)" - }, - "build-deploy-parachains": { - "title": "패러체인을 보고 배포하는 방법", - "sidebar_label": "패러체인을 보고 배포하는 방법" - }, - "build-dev-roadmap": { - "title": "개발자들을 위한 로드맵", - "sidebar_label": "개발자들을 위한 로드맵" - }, - "build-examples-index": { - "title": "사례들", - "sidebar_label": "사례들" - }, - "build-hackathon": { - "title": "해커톤", - "sidebar_label": "해커톤" - }, - "build-index": { - "title": "개발자 포탈", - "sidebar_label": "개발자 포탈" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "패러체인 개발 키트", - "sidebar_label": "패러체인 개발 키트" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "스마트 컨트랙트", - "sidebar_label": "스마트 컨트랙트" - }, - "build-tools-index": { - "title": "툴 목록", - "sidebar_label": "툴 목록" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "커뮤니티", - "sidebar_label": "커뮤니티" - }, - "contributing": { - "title": "기여하기", - "sidebar_label": "기여하기" - }, - "glossary": { - "title": "용어 정리", - "sidebar_label": "용어 정리" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "위키 목록", - "sidebar_label": "위키 목록" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "아키텍쳐", - "sidebar_label": "아키텍쳐" - }, - "learn-auction": { - "title": "패러체인 슬롯 경매", - "sidebar_label": "패러체인 슬롯 경매" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "브릿지들", - "sidebar_label": "브릿지들" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "디피니티" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "코스모스에 비교분석\n" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "다른 체인과의 비교분석" - }, - "learn-consensus": { - "title": "폴카닷의 컨센서스", - "sidebar_label": "폴카닷의 컨센서스" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "암호화체계 부연 설명", - "sidebar_label": "암호화체계 부연 설명" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "FAQ | 자주 묻는 문의사항", - "sidebar_label": "FAQ | 자주 묻는 문의사항" - }, - "learn-governance": { - "title": "거버넌스 (Governance)", - "sidebar_label": "거버넌스 (Governance)" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "폴카닷 구현체들", - "sidebar_label": "폴카닷 구현체들" - }, - "learn-introduction": { - "title": "폴카닷", - "sidebar_label": "폴카닷" - }, - "learn-keys": { - "title": "폴카닷 키들", - "sidebar_label": "폴카닷 키들" - }, - "learn-parachains": { - "title": "패러체인 (Parachains)", - "sidebar_label": "패러체인 (Parachains)" - }, - "learn-parathreads": { - "title": "패러쓰레드 (parathreads)", - "sidebar_label": "패러쓰레드 (parathreads)" - }, - "learn-phragmen": { - "title": "순차적 프라그멘 방법", - "sidebar_label": "순차적 프라그멘 방법" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "무작위 선택", - "sidebar_label": "무작위 선택" - }, - "learn-relevant-links": { - "title": "링크", - "sidebar_label": "링크" - }, - "learn-roadmap": { - "title": "로드맵", - "sidebar_label": "로드맵" - }, - "learn-security": { - "title": "네트워크의 보안", - "sidebar_label": "네트워크의 보안" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "스프리 (SPREE)", - "sidebar_label": "스프리 (SPREE)" - }, - "learn-staking": { - "title": "스테이킹", - "sidebar_label": "스테이킹" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "재무관리", - "sidebar_label": "재무관리" - }, - "learn-wasm": { - "title": "웹어셈블리 (WASM; Web Assembly)", - "sidebar_label": "웹어셈블리 (WASM; Web Assembly)" - }, - "maintain-collator": { - "title": "전달자 (Collator)", - "sidebar_label": "전달자 (Collator)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "의회에 출마하는 법", - "sidebar_label": "의회에 출마하는 법" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "노미네이터가 되어보세요 (알렉산더)", - "sidebar_label": "노미네이터가 되어보세요 (알렉산더)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "노미네이터가 되어보세요 (쿠사마)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "검증자 노드를 업그레이드하는 방법", - "sidebar_label": "검증자 노드를 업그레이드하는 방법" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "검증자 노드를 돌려보세요 (쿠사마)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "검증자 노드를 돌려보세요 (알렉산더)", - "sidebar_label": "검증자 노드를 돌려보세요 (알렉산더)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "의회원들에 투표하기", - "sidebar_label": "의회원들에 투표하기" - }, - "maintain-guides-secure-validator": { - "title": "안전한 검증자 노드", - "sidebar_label": "안전한 검증자 노드" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "검증자 보상 구조 정리", - "sidebar_label": "검증자 보상 구조 정리" - }, - "maintain-index": { - "title": "네트워크 메인테이너들", - "sidebar_label": "네트워크 메인테이너들" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "노미네이터", - "sidebar_label": "노미네이터" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "뉴스", - "sidebar_label": "뉴스" - }, - "research": { - "title": "연구 자료들", - "sidebar_label": "연구 자료들" - } - }, - "links": { - "Build": "개발", - "Learn": "학습", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "메인", - "Build": "개발", - "Learn": "학습", - "Maintain": "유지 및 보수", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "이 사이트의 [문서](/test-site/docs/en/doc1.html)에서 자세한 정보를 얻으세요.", - "Browse Docs|no description given": "문서 찾아보기", - "Ask questions about the documentation and project|no description given": "문서 및 프로젝트에 대해 질문하기", - "Join the community|no description given": "커뮤니티에 가입하세요", - "Find out what's new with this project|no description given": "이 프로젝트의 새로운 소식에 대해 알아봅시다.", - "Stay up to date|no description given": "최신 정보를 놓치지 마세요.", - "Need help?|no description given": "도움이 필요하세요?", - "This project is maintained by a dedicated group of people.|statement made to reader": "이 프로젝트는 이 분야에 집중하는 사람들에 의해서 유지 및 보수가 이루어지고 있습니다.", - "A scalable, heterogeneous multichain.|no description given": "스케일러블하고, 이종적인 멀티체인.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "폴카닷은 낮은 진입장벽으로 유연하고 자발적인 경제시스템들이 서로 폴카닷의 보호 아래 협력할 수 있도록 해주는 플랫폼입니다. 폴카닷은 블록체인 기술만이 아니며, 보다 합리적인 상호간의 디지털 의사 결정을 위한 혁명입니다.", - "Learn More|no description given": "더 알아보기", - "Build|no description given": "빌드해보세요", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "폴카닷은 개발자들이 상호운용성과 공유되는 보안을 이용하여 그들의 입맛에 맞는 블록체인들을 만들 수 있게 해줍니다.", - "Builder's Portal|no description given": "개발자 포탈", - "Validators|no description given": "검증자", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "검증자 노드를 돌려서 폴카닷 네트워크를 지키며 보상을 받아보세요.", - "Collators|no description given": "전달자 (Collators)", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "전달자를 돌려서 패러체인의 블록을 만든 다음 검증을 위해 밸리데이터한테 보내세요.", - "Become a Maintainer|no description given": "메인테이너가 되어보세요", - "Help Translate|recruit community translators for your project": "번역을 도와주세요", - "Edit this Doc|recruitment message asking to edit the doc source": "편집", - "Translate this Doc|recruitment message asking to translate the docs": "번역" - } -} diff --git a/kusama-guide/i18n/ko.json b/kusama-guide/i18n/ko.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/kusama-guide/i18n/ko.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/ru-RU.json b/kusama-guide/i18n/ru-RU.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/ru-RU.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/ru.json b/kusama-guide/i18n/ru.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/kusama-guide/i18n/ru.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/sk-SK.json b/kusama-guide/i18n/sk-SK.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/sk-SK.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/th-TH.json b/kusama-guide/i18n/th-TH.json deleted file mode 100644 index 9ed2539e7794..000000000000 --- a/kusama-guide/i18n/th-TH.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmen Method", - "sidebar_label": "Sequential Phragmen Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News", - "sidebar_label": "News" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/tr-TR.json b/kusama-guide/i18n/tr-TR.json deleted file mode 100644 index a76499388214..000000000000 --- a/kusama-guide/i18n/tr-TR.json +++ /dev/null @@ -1,273 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/tr.json b/kusama-guide/i18n/tr.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/kusama-guide/i18n/tr.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/kusama-guide/i18n/zh-CN.json b/kusama-guide/i18n/zh-CN.json deleted file mode 100644 index 4e6dbae3e0bd..000000000000 --- a/kusama-guide/i18n/zh-CN.json +++ /dev/null @@ -1,431 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "下一页", - "previous": "上一页", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot 開發者入门指南", - "sidebar_label": "Polkadot 開發者入门指南" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "如何查看及部署平行链", - "sidebar_label": "如何查看及部署平行链" - }, - "build-dev-roadmap": { - "title": "开发路线图", - "sidebar_label": "开发路线图" - }, - "build-examples-index": { - "title": "例子", - "sidebar_label": "例子" - }, - "build-hackathon": { - "title": "黑客马拉松", - "sidebar_label": "黑客马拉松" - }, - "build-index": { - "title": "开发者专页", - "sidebar_label": "开发者专页" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "平行链开发套件 (PDKs)", - "sidebar_label": "平行链开发套件(PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "智能合约", - "sidebar_label": "智能合约" - }, - "build-tools-index": { - "title": "工具索引", - "sidebar_label": "工具索引" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "community": { - "title": "社区", - "sidebar_label": "社区" - }, - "contributing": { - "title": "贡献", - "sidebar_label": "贡献" - }, - "glossary": { - "title": "专业术语", - "sidebar_label": "专业术语" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "维基索引", - "sidebar_label": "维基索引" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Polkadot 架构", - "sidebar_label": "Polkadot 架构" - }, - "learn-auction": { - "title": "平行链插槽拍卖", - "sidebar_label": "平行链插槽拍卖" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "桥接", - "sidebar_label": "桥接" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "与其它比较" - }, - "learn-consensus": { - "title": "Polkadot 共识机制", - "sidebar_label": "Polkadot 共识机制" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "密码学讲解", - "sidebar_label": "密码学讲解" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "常见问题", - "sidebar_label": "常见问题" - }, - "learn-governance": { - "title": "治理", - "sidebar_label": "治理" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "其它程序语言实现", - "sidebar_label": "其它程序语言实现" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "密匙", - "sidebar_label": "密匙" - }, - "learn-parachains": { - "title": "平行链", - "sidebar_label": "平行链" - }, - "learn-parathreads": { - "title": "平行线程", - "sidebar_label": "平行线程" - }, - "learn-phragmen": { - "title": "顺序弗拉格曼方法", - "sidebar_label": "顺序弗拉格曼方法" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-randomness": { - "title": "随机性", - "sidebar_label": "随机性" - }, - "learn-relevant-links": { - "title": "相关链接", - "sidebar_label": "相关链接" - }, - "learn-roadmap": { - "title": "路线图", - "sidebar_label": "路线图" - }, - "learn-security": { - "title": "网络安全", - "sidebar_label": "网络安全" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "抵押", - "sidebar_label": "抵押" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "财政库", - "sidebar_label": "财政库" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "收集人", - "sidebar_label": "收集人" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "加入议会", - "sidebar_label": "加入议会" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "成为提名人 (Alexander)", - "sidebar_label": "成为提名人 (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "成为提名人 (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "如何把节点设定为 `systemd` 进程运行", - "sidebar_label": "如何把节点设定为 `systemd` 进程运行" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "如何升级验证人节点", - "sidebar_label": "如何升级验证人节点" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "运行验证人 (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "运行验证人 (Alexander)", - "sidebar_label": "运行验证人 (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "投票选举议员", - "sidebar_label": "投票选举议员" - }, - "maintain-guides-secure-validator": { - "title": "安全验证人节点", - "sidebar_label": "安全验证人节点" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "验证人付款概述", - "sidebar_label": "验证人付款概述" - }, - "maintain-index": { - "title": "网络维护者", - "sidebar_label": "网络维护者" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "提名人", - "sidebar_label": "提名人" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "验证人", - "sidebar_label": "验证人" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "新闻", - "sidebar_label": "新闻" - }, - "research": { - "title": "研究专页", - "sidebar_label": "研究专页" - } - }, - "links": { - "Build": "建立", - "Learn": "学习", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "Main": "主要", - "Build": "建立", - "Learn": "学习", - "Maintain": "参与", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "浏览文档", - "Ask questions about the documentation and project|no description given": "询问有关文档和项目的问题", - "Join the community|no description given": "加入社区", - "Find out what's new with this project|no description given": "了解项目的最新发展", - "Stay up to date|no description given": "保持最新", - "Need help?|no description given": "需要协助?", - "This project is maintained by a dedicated group of people.|statement made to reader": "该项目由一群专职人员维护", - "A scalable, heterogeneous multichain.|no description given": "可扩容的异构多链。", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot 是一个平台，对于在 Polkadot的 共享安全保护伞内共同行动的灵活，自治的经济体，入门槛低。Polkadot 不仅是区块链技术的革命，而且是朝着建立更公平的点对点数字管辖区迈进的革命。", - "Learn More|no description given": "了解更多", - "Build|no description given": "开发", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot 使建设者和开发者能够创建适合他们需求的区块链，并从互操作性和共享安全性中受益。", - "Builder's Portal|no description given": "开发者入口", - "Validators|no description given": "验证人", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "运行验证人节点获得奖励同时帮助保护 Polkadot 网络。", - "Collators|no description given": "收集人", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "运行收集人打包平行链的区块并将其传递给验证人以进行验证。", - "Become a Maintainer|no description given": "成为参与者", - "Help Translate|recruit community translators for your project": "参与翻译", - "Edit this Doc|recruitment message asking to edit the doc source": "修改", - "Translate this Doc|recruitment message asking to translate the docs": "翻译" - } -} diff --git a/kusama-guide/languages.js b/kusama-guide/languages.js deleted file mode 100755 index 5f8dc4d01a1d..000000000000 --- a/kusama-guide/languages.js +++ /dev/null @@ -1,186 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const languages = [ - { - enabled: true, - name: 'English', - tag: 'en', - }, - { - enabled: false, - name: '日本語', - tag: 'ja', - }, - { - enabled: false, - name: 'العربية', - tag: 'ar', - }, - { - enabled: false, - name: 'Bosanski', - tag: 'bs-BA', - }, - { - enabled: false, - name: 'Català', - tag: 'ca', - }, - { - enabled: false, - name: 'Čeština', - tag: 'cs', - }, - { - enabled: false, - name: 'Dansk', - tag: 'da', - }, - { - enabled: false, - name: 'Deutsch', - tag: 'de', - }, - { - enabled: false, - name: 'Ελληνικά', - tag: 'el', - }, - { - enabled: false, - name: 'Español', - tag: 'es-ES', - }, - { - enabled: false, - name: 'فارسی', - tag: 'fa-IR', - }, - { - enabled: false, - name: 'Suomi', - tag: 'fi', - }, - { - enabled: false, - name: 'Français', - tag: 'fr', - }, - { - enabled: false, - name: 'עִברִית', - tag: 'he', - }, - { - enabled: false, - name: 'Magyar', - tag: 'hu', - }, - { - enabled: false, - name: 'Bahasa Indonesia', - tag: 'id-ID', - }, - { - enabled: false, - name: 'Italiano', - tag: 'it', - }, - { - enabled: false, - name: 'Afrikaans', - tag: 'af', - }, - { - enabled: false, - name: '한국어', - tag: 'ko', - }, - { - enabled: false, - name: 'मराठी', - tag: 'mr-IN', - }, - { - enabled: false, - name: 'Nederlands', - tag: 'nl', - }, - { - enabled: false, - name: 'Norsk', - tag: 'no-NO', - }, - { - enabled: false, - name: 'Polskie', - tag: 'pl', - }, - { - enabled: false, - name: 'Português', - tag: 'pt-PT', - }, - { - enabled: false, - name: 'Português (Brasil)', - tag: 'pt-BR', - }, - { - enabled: false, - name: 'Română', - tag: 'ro', - }, - { - enabled: false, - name: 'Русский', - tag: 'ru', - }, - { - enabled: false, - name: 'Slovenský', - tag: 'sk-SK', - }, - { - enabled: false, - name: 'Српски језик (Ћирилица)', - tag: 'sr', - }, - { - enabled: false, - name: 'Svenska', - tag: 'sv-SE', - }, - { - enabled: false, - name: 'Türkçe', - tag: 'tr', - }, - { - enabled: false, - name: 'Українська', - tag: 'uk', - }, - { - enabled: false, - name: 'Tiếng Việt', - tag: 'vi', - }, - { - enabled: true, - name: '中文', - tag: 'zh-CN', - }, - { - enabled: false, - name: '繁體中文', - tag: 'zh-TW', - }, -]; - -module.exports = languages; diff --git a/kusama-guide/pages/en/help-with-translations.js b/kusama-guide/pages/en/help-with-translations.js deleted file mode 100755 index 19dbc9cc00cd..000000000000 --- a/kusama-guide/pages/en/help-with-translations.js +++ /dev/null @@ -1,69 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require('react'); - -const CompLibrary = require('../../core/CompLibrary.js'); - -const Container = CompLibrary.Container; -const GridBlock = CompLibrary.GridBlock; - -const translate = require('../../server/translate.js').translate; - -class Help extends React.Component { - render() { - const supportLinks = [ - { - content: ( - - Learn more using the [documentation on this - site.](/test-site/docs/en/doc1.html) - - ), - title: Browse Docs, - }, - { - content: ( - - Ask questions about the documentation and project - - ), - title: Join the community, - }, - { - content: Find out what's new with this project, - title: Stay up to date, - }, - ]; - - return ( -
- -
-
-

- Need help? -

-
-

- - This project is maintained by a dedicated group of people. - -

- -
- -
- ); - } -} - -Help.defaultProps = { - language: 'en', -}; - -module.exports = Help; diff --git a/kusama-guide/pages/en/help.js b/kusama-guide/pages/en/help.js deleted file mode 100755 index 2b790e46037f..000000000000 --- a/kusama-guide/pages/en/help.js +++ /dev/null @@ -1,54 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require('react'); - -const CompLibrary = require('../../core/CompLibrary.js'); - -const Container = CompLibrary.Container; -const GridBlock = CompLibrary.GridBlock; - -function Help(props) { - const {config: siteConfig, language = ''} = props; - const {baseUrl, docsUrl} = siteConfig; - const docsPart = `${docsUrl ? `${docsUrl}/` : ''}`; - const langPart = `${language ? `${language}/` : ''}`; - const docUrl = doc => `${baseUrl}${docsPart}${langPart}${doc}`; - - const supportLinks = [ - { - content: `Learn more using the [documentation on this site.](${docUrl( - 'doc1.html', - )})`, - title: 'Browse Docs', - }, - { - content: 'Ask questions about the documentation and project', - title: 'Join the community', - }, - { - content: "Find out what's new with this project", - title: 'Stay up to date', - }, - ]; - - return ( -
- -
-
-

Need help?

-
-

This project is maintained by a dedicated group of people.

- -
- -
- ); -} - -module.exports = Help; diff --git a/kusama-guide/pages/en/index.js b/kusama-guide/pages/en/index.js deleted file mode 100644 index f933d0cac300..000000000000 --- a/kusama-guide/pages/en/index.js +++ /dev/null @@ -1,116 +0,0 @@ -const React = require("react"); - -const translate = require("../../server/translate.js").translate; - -class HomeSplash extends React.Component { - render() { - const SplashContainer = props => ( -
-
{props.children}
-
- ); - - return ( - -
- -
- - ); - } -} - -class Index extends React.Component { - render() { - const { config: siteConfig, language = "" } = this.props; - const { baseUrl, docsUrl } = siteConfig; - const docsPart = `${docsUrl ? `${docsUrl}/` : ""}`; - const langPart = `${language ? `${language}/` : ""}`; - const docUrl = doc => `${baseUrl}${docsPart}${langPart}${doc}`; - - return ( -
-
- -
-
-
-

- Kusama is an early, unaudited and unrefined release of Polkadot. Kusama will serve as - a proving ground, allowing teams and developers to build and deploy a parachain or try - out Polkadot’s governance, staking, nomination and validation functionality in a real - environment. -

-
-
-
-

What can you do with Kusama?

-
-
-
-

Become a Validator

-
-
-

- The minimum requirement for staking as a validator on Kusama is much lower than it - is expected for Polkadot. There are also programs in place such as{" "} - - Thousand Validators - {" "} - to help community validators rise the ranks. -

- - - -
-
-
-
-

Deploy Parachains

-

- Kusama will get the functionality required for parachains before Polkadot. This - includes participating in a parachain slot auction and composable applications. -

- - - -
-
-

Explore the politics

-

- Campaign as a councillor or vote for new runtime proposals using Democracy. -

- - - -
-
-
-
-

Join a cyber secret society

-

- The Kappa Sigma Mu fraternity asks you to get a Kusama tattoo to join. -

- - - -
-
-
-
- ); - } -} - -module.exports = Index; diff --git a/kusama-guide/pages/en/users.js b/kusama-guide/pages/en/users.js deleted file mode 100755 index 039dc39ffa50..000000000000 --- a/kusama-guide/pages/en/users.js +++ /dev/null @@ -1,48 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require('react'); - -const CompLibrary = require('../../core/CompLibrary.js'); - -const Container = CompLibrary.Container; - -class Users extends React.Component { - render() { - const {config: siteConfig} = this.props; - if ((siteConfig.users || []).length === 0) { - return null; - } - - const editUrl = `${siteConfig.repoUrl}/edit/master/website/siteConfig.js`; - const showcase = siteConfig.users.map(user => ( - - {user.caption} - - )); - - return ( -
- -
-
-

Who is Using This?

-

This project is used by many folks

-
-
{showcase}
-

Are you using this project?

- - Add your company - -
- -
- ); - } -} - -module.exports = Users; diff --git a/kusama-guide/postprocess.js b/kusama-guide/postprocess.js index 7c308b992042..b0cd2d843c66 100644 --- a/kusama-guide/postprocess.js +++ b/kusama-guide/postprocess.js @@ -1,11 +1,11 @@ // postprocess.js -'use strict'; +"use strict"; -require('loud-rejection/register'); +require("loud-rejection/register"); -const path = require('path'); -const { postProcess } = require('../scripts/utils'); +const path = require("path"); +const { postProcess } = require("../scripts/utils"); -const buildDirectory = path.join(__dirname, 'build'); +const buildDirectory = path.join(__dirname, "build"); postProcess(buildDirectory); diff --git a/kusama-guide/sidebars.js b/kusama-guide/sidebars.js new file mode 100644 index 000000000000..be2e18ff7076 --- /dev/null +++ b/kusama-guide/sidebars.js @@ -0,0 +1,60 @@ +module.exports = { + docs: [ + { + type: "category", + label: "Kusama", + items: [ + "general/kusama/kusama-index", + { + type: "category", + label: "Get Started", + items: [ + "general/kusama/kusama-getting-started", + "general/kusama/kusama-faucet", + "general/kusama/kusama-claims", + "general/kusama/kusama-endpoints", + "learn/learn-balance-transfers", + "learn/learn-auction", + "learn/learn-parachains", + "learn/learn-parathreads", + "learn/learn-crowdloans", + "general/thousand-validators", + ], + }, + { + type: "category", + label: "What to Try", + items: [ + "maintain/kusama/maintain-guides-how-to-validate-kusama", + "maintain/maintain-guides-how-to-stop-validating", + "maintain/kusama/maintain-guides-how-to-nominate-kusama", + "learn/learn-governance", + "learn/learn-identity", + "learn/learn-treasury", + "learn/learn-registrar", + "build/build-build-with-polkadot", + "build/build-parachains-rococo", + "maintain/kusama/maintain-guides-society-kusama", + "general/kusama/kusama-social-recovery", + ], + }, + { + type: "category", + label: "What to Break", + items: [ + "maintain/maintain-errors", + "general/kusama/kusama-bug-bounty", + "general/kusama/kusama-adversarial-cheatsheet", + ], + }, + "general/ens", + "general/kusama/kusama-ledger", + "general/kusama/kusama-statemine-ledger", + "general/kusama/kusama-timeline", + "general/kusama/kusama-community", + "general/kusama/kusama-parameters", + "general/kusama/kusama-coc", + ], + }, + ], +}; diff --git a/kusama-guide/sidebars.json b/kusama-guide/sidebars.json deleted file mode 100644 index 35d86da9f830..000000000000 --- a/kusama-guide/sidebars.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "docs": { - "Kusama": [ - "kusama-index", - { - "type": "subcategory", - "label": "Get Started", - "ids": [ - "kusama-getting-started", - "kusama-faucet", - "kusama-claims", - "kusama-endpoints", - "mirror-learn-balance-transfers", - "mirror-thousand-validators", - "mirror-learn-auction", - "mirror-learn-parachains", - "mirror-learn-parathreads", - "mirror-learn-crowdloans" - ] - }, - { - "type": "subcategory", - "label": "What to Try", - "ids": [ - "mirror-maintain-guides-how-to-validate-kusama", - "mirror-maintain-guides-how-to-stop-validating", - "mirror-maintain-guides-how-to-nominate-kusama", - "mirror-learn-governance", - "mirror-learn-identity", - "mirror-learn-treasury", - "mirror-learn-registrar", - "mirror-build-build-with-polkadot", - "mirror-build-parachains-rococo", - "maintain-guides-society-kusama", - "kusama-social-recovery" - ] - }, - { - "type": "subcategory", - "label": "What to Break", - "ids": ["mirror-maintain-errors", "kusama-bug-bounty", "kusama-adversarial-cheatsheet"] - }, - "mirror-ens", - "kusama-ledger", - "kusama-statemine-ledger", - "kusama-timeline", - "kusama-community", - "kusama-parameters", - "kusama-coc" - ] - } -} diff --git a/kusama-guide/siteConfig.js b/kusama-guide/siteConfig.js deleted file mode 100644 index bd5ce9ed66c4..000000000000 --- a/kusama-guide/siteConfig.js +++ /dev/null @@ -1,109 +0,0 @@ -const { baseUrlPattern } = require("../scripts/utils"); - -const isBuilding = process.env.BUILDING; -const isPub = process.env.PUBLISHING; - -const siteConfig = { - title: "Guide", // Title for your website. - tagline: "One-stop-shop for Kusama information.", - url: isPub ? "https://guide.kusama.network" : "", // Your website URL - baseUrl: isBuilding ? baseUrlPattern : "/", - projectName: isPub ? "kusama-guide-hosting" : "", - organizationName: "w3f", - cname: "guide.kusama.network", - - // For no header links in the top nav bar -> headerLinks: [], - headerLinks: [ - { doc: "kusama-getting-started", label: "Get Started" }, - { doc: "kusama-index", label: "Docs" }, - { search: true }, - { languages: true }, - ], - - /* path to images for header/footer */ - headerIcon: "./img/Kusama_logotype_white_large.png", - footerIcon: "./img/kusama-brand-assets/Kusama_Canary_white.png", - favicon: "./img/kusama-brand-assets/Kusama_Canary_white.png", - - /* Colors for website */ - colors: { - primaryColor: "#E6007A", - secondaryColor: "#000000", - }, - - algolia: { - apiKey: "53c6a4ab0d77c0755375a971c9b7cc3d", - indexName: "kusama_guide", - algoliaOptions: { - facetFilters: ["language:LANGUAGE"], - }, // Optional, if provided by Algolia - }, - - /* Custom fonts for website */ - fonts: { - myFont: ["Muli", "sans-serif"], - }, - - // This copyright info is used in /core/Footer.js and blog RSS/Atom feeds. - copyright: `Copyright © ${new Date().getFullYear()} Web3 Foundation`, - - highlight: { - // Highlight.js theme to use for syntax highlighting in code blocks. - theme: "default", - }, - - // Add custom scripts here that would be placed in - Polkadot Wiki - - - If you are not redirected automatically, follow this link. - - diff --git a/kusama-guide-v2/static/CNAME b/kusama-guide/static/CNAME similarity index 100% rename from kusama-guide-v2/static/CNAME rename to kusama-guide/static/CNAME diff --git a/kusama-guide/static/css/copycode.css b/kusama-guide/static/css/copycode.css index 37ac260da6fd..aa97eca12c13 100644 --- a/kusama-guide/static/css/copycode.css +++ b/kusama-guide/static/css/copycode.css @@ -1,40 +1,40 @@ -/* "Copy" code block button */ -pre { - position: relative; -} - -pre .btnIcon { - position: absolute; - top: 4px; - z-index: 2; - cursor: pointer; - border: 1px solid transparent; - padding: 3px; - color: black; - background-color: rgba(255, 255, 255, 0.7); - height: 30px; - transition: all 0.25s ease-out; -} - -pre .btnIcon:hover { - text-decoration: none; - border: 1px solid silver; -} - -.btnIcon__body { - align-items: center; - display: flex; -} - -.btnIcon svg { - fill: currentColor; - margin-right: 0.4em; -} - -.btnIcon__label { - font-size: 11px; -} - -.btnClipboard { - right: 10px; -} +/* "Copy" code block button */ +pre { + position: relative; +} + +pre .btnIcon { + position: absolute; + top: 4px; + z-index: 2; + cursor: pointer; + border: 1px solid transparent; + padding: 3px; + color: black; + background-color: rgba(255, 255, 255, 0.7); + height: 30px; + transition: all 0.25s ease-out; +} + +pre .btnIcon:hover { + text-decoration: none; + border: 1px solid silver; +} + +.btnIcon__body { + align-items: center; + display: flex; +} + +.btnIcon svg { + fill: currentColor; + margin-right: 0.4em; +} + +.btnIcon__label { + font-size: 11px; +} + +.btnClipboard { + right: 10px; +} diff --git a/kusama-guide/static/css/custom.css b/kusama-guide/static/css/custom.css index 6927e087879c..a37512d1d779 100755 --- a/kusama-guide/static/css/custom.css +++ b/kusama-guide/static/css/custom.css @@ -1,72 +1,200 @@ +:root { + --ifm-color-primary: #e6007a; + --ifm-color-primary-dark: #cf006e; + --ifm-color-primary-darker: #c40068; + --ifm-color-primary-darkest: #a10055; + --ifm-color-primary-light: #fd0086; + --ifm-color-primary-lighter: #ff0a8c; + --ifm-color-primary-lightest: #ff2c9c; + --ifm-navbar-link-color: #ffffff; + --ifm-navbar-link-hover-color: #ffffff; + --docsearch-searchbox-focus-background: transparent; + --docsearch-text-color: rgb(2, 2, 2); +} + @font-face { font-family: "SpaceMono-Regular"; - src: url("../fonts/SpaceMono-Regular.eot"); - src: url("../fonts/SpaceMono-Regular.eot?#iefix") format("embedded-opentype"), - url("../fonts/SpaceMono-Regular.woff") format("woff"), + src: url("../fonts/SpaceMono-Regular.ttf"); + src: url("../fonts/SpaceMono-Regular.ttf?#iefix") format("embedded-opentype"), + url("../fonts/SpaceMono-Regular.ttf") format("woff"), url("../fonts/SpaceMono-Regular.ttf") format("truetype"), - url("../fonts/SpaceMono-Regular.svg") format("svg"); - font-weight: normal; - font-style: normal; + url("../fonts/SpaceMono-Regular.ttf") format("svg"); } -.homepage-font { - font-family: "SpaceMono-Regular", "Helvetica", "Arial", sans-serif; +/* ========================================================================== + General components + ========================================================================== */ + +/* Back to top button */ +#back-to-top { + left: 16px; + bottom: 26px; + background: var(--ifm-color-primary); + color: #fff; + height: 48px; + width: 48px; + z-index: 999; } -@media only screen and (min-device-width: 360px) and (max-device-width: 736px) { - .mainpage-column { - width: 100% !important; - } +#back-to-top svg { + margin-top: 12px; } -@media only screen and (min-width: 1024px) { +#support_us { + color: white; + text-decoration: none; + font-weight: bold; +} + +/* ========================================================================== + Sidebar + ========================================================================== */ + +button.menu__button { + box-shadow: 0 2px 5px 0 rgba(0, 0, 0, 0.26); } -@media only screen and (max-width: 1023px) { +.menu--responsive .menu__button { + background: var(--ifm-color-primary); + border-color: var(--ifm-color-primary); + color: white; } -@media only screen and (min-width: 1400px) { +.navbar-sidebar__brand { + background-color: black; + height: 50px; } -@media only screen and (min-width: 1500px) { +.navbar-sidebar--show .navbar__link--active { + color: #606770; } -.myButton { - padding: 10px; - padding-left: 12px; - padding-right: 12px; +/* ========================================================================== + Navigation bar + ========================================================================== */ + +.navbar.navbar--fixed-top { background: black; +} + +.navbar.navbar--fixed-top .navbar__inner { + max-width: 1360px; + margin: 0 auto 0; +} + +.navbar__inner a.navbar__item svg[class^="iconExternalLink"] { + display: none; +} + +.navbar__link { + background-color: black; + transition: background-color 0.3s; +} + +.navbar__link:hover { + background-color: var(--ifm-color-primary); +} + +/* Menu button */ +button.navbar__toggle { color: white; - border: none; - font-size: 16px; } -#back-to-top { - background: #e6007a; +/* Logo */ +.navbar__brand:hover { + color: white; } -.myButton:hover { - background: #e6007a; - cursor: pointer; +.navbar__brand strong:hover { + color: white; +} + +.navbar .navbar__title { + display: block; + font-size: 1.25em; + line-height: 18px; + margin: 0; + position: relative; +} + +/* Search bar */ +@media only screen and (max-width: 750px) { + .DocSearch.DocSearch-Button { + width: 36px; + padding-left: 8px; + } +} + +.DocSearch-Button-Keys { + display: none !important; +} + +button.DocSearch { + background-color: rgba(0, 0, 0, 0.2); + box-shadow: var(--docsearch-searchbox-shadow); + border-radius: 20px; + color: white; + font-size: 14px; + font-weight: 300; + line-height: 20px; + outline: none; + padding-left: 25px; + position: relative; + transition: width 0.5s ease; + width: 170px; +} + +button.DocSearch-Button:active, +button.DocSearch-Button:focus, +button.DocSearch-Button:hover { + background: rgba(0, 0, 0, 0.2); + color: white; +} +button.DocSearch svg { + color: white !important; } -.navigationSlider .slidingNav ul li.siteNavGroupActive > a { +/* Languages menu */ + +.dropdown > a { + margin-left: 12px; + padding: 4px 8px !important; +} + +.dropdown__menu { + top: 35px; + text-align: center; background-color: black; + padding: 0; + box-shadow: 0 4px 7px 0 rgba(255, 255, 255, 0.2); } -.fixedHeaderContainer { - background: black; +.dropdown__menu a { + color: white; + border-radius: 0; } -.homeContainer { - background: white; - height: 50vh; +.dropdown__menu a:hover { + background-color: var(--ifm-color-primary); + color: white; } -.projectTitle { - color: black; +.dropdown__menu a.dropdown__link--active { + background-color: black; +} + +.dropdown__menu a.dropdown__link--active:hover { + background-color: var(--ifm-color-primary); +} + +.dropdown a:first-child::after { + display: none !important; } +/* ========================================================================== + Footer + ========================================================================== */ + .nav-footer { background: black; } @@ -89,66 +217,191 @@ color: #ffffff; } -.mainpage-row { - width: 100%; - display: flex; - padding: 10%; - padding-top: 0; - padding-bottom: 0; - flex-flow: row wrap; - justify-content: center; +#footer section.row { + margin: 0 !important; } -.mainpage-column { - width: 50%; +.nav-footer { + background: #000; + border: none; + color: #202020; + font-size: 15px; + -webkit-font-smoothing: antialiased; + -moz-osx-font-smoothing: grayscale; + font-weight: 400; + line-height: 24px; + padding-bottom: 2em; + padding-top: 2em; + position: relative; +} +@media only screen and (min-width: 1024px) { + .nav-footer { + flex-shrink: 0; + } +} +.nav-footer .sitemap { display: flex; - align-items: center; - padding: 5%; + justify-content: space-between; + margin: 0 auto 3em; + max-width: 1080px; +} +.nav-footer .sitemap div { + flex: 1; +} +.nav-footer .sitemap .nav-home { + display: table; + height: 72px; + margin: -12px 20px 0 0; + opacity: 0.4; + padding: 10px; + transition: opacity 0.15s ease-in-out; + width: 72px; +} +.nav-footer .sitemap .nav-home:focus, +.nav-footer .sitemap .nav-home:hover { + opacity: 1; +} +@media only screen and (max-width: 735px) { + .nav-footer .sitemap { + display: flex; + flex-direction: column; + margin: 0 2em 3em; + width: calc(100% - 4em); + } + .nav-footer .sitemap > div { + margin-bottom: 18px; + } +} +.nav-footer .sitemap a { + color: hsla(0, 0%, 100%, 0.6); + display: block; + margin: 2px 0; + padding: 3px 0; +} +.nav-footer .sitemap a:focus, +.nav-footer .sitemap a:hover, +.nav-footer .sitemap h5 > a:focus, +.nav-footer .sitemap h5 > a:hover { + color: #fff; + text-decoration: none; +} +.nav-footer .sitemap h5, +.nav-footer .sitemap h6 { + margin: 0 0 10px; +} +.nav-footer .sitemap h5, +.nav-footer .sitemap h5 > a, +.nav-footer .sitemap h6, +.nav-footer .sitemap h6 > a { + color: #fff; +} +.nav-footer .sitemap h5 > a, +.nav-footer .sitemap h6 > a { + margin: 0 -10px; +} +.nav-footer .fbOpenSource { + display: block; + margin: 1em auto; + opacity: 0.4; + transition: opacity 0.15s ease-in-out; + width: 170px; +} +.nav-footer .fbOpenSource:hover { + opacity: 1; +} +.nav-footer .copyright { + color: hsla(0, 0%, 100%, 0.4); text-align: center; - flex-flow: column; +} +.nav-footer .social { + padding: 5px 0; +} + +.bgColor { + background-color: black; } -.full-width { +.no-margin { + margin: 0 !important; width: 100%; - text-align: center; +} + +.main-wrapper { + left: 0; + min-height: 100%; + position: relative; + z-index: 99; +} + +.main-wrapper::after { + background: rgba(0, 0, 0, 0.4); + content: ""; + height: 0; + opacity: 0; + position: absolute; + right: 0; + top: 0; + transition: opacity 0.5s, width 0.1s 0.5s, height 0.1s 0.5s; + width: 0; } body { font-family: "Muli", sans-serif !important; } -.github-fork-ribbon { - position: fixed; - top: 0; - height: 30px; - z-index: 999999; - background: #e6007a; +/* ========================================================================== + Doc page + ========================================================================== */ + +.docs-wrapper { + margin-left: auto; + margin-right: auto; + max-width: 1400px; width: 100%; - display: flex; - justify-content: center; - align-items: center; - color: #ddd; - font-weight: 700; + padding-bottom: 50px; } -.github-fork-ribbon:hover { - color: white !important; +article blockquote { + background-color: rgba(255, 229, 100, 0.3); + border-left: 8px solid #ffe564; + padding: 15px 30px 15px 15px; } -.fixedHeaderContainer { - position: fixed; - top: 0; - margin-top: 30px; +article iframe, +article img { + display: block; + margin-left: auto; + margin-right: auto; + max-width: 100%; +} + +/* ========================================================================== + Homepage + ========================================================================== */ + +.homepage-font { + font-family: "SpaceMono-Regular", "Helvetica", "Arial", sans-serif; } -.logo { - padding-bottom: 10px; +.homeContainer { + background: white; + height: 50vh; } .kusamaHomeContainer { background: black; } +.main-wrapper .kusamaHomeContainer .wrapper { + margin: 0 auto; + max-width: 1360px; + padding: 0 20px; +} + +.main-wrapper .kusama-mainpage-row-validator { + background-color: white; +} + .kusama-full-width { width: 100%; text-align: center; @@ -163,94 +416,87 @@ body { } .mainpage-row-placeholder { - width: 100%; - display: flex; - padding: 0%; - padding-top: 0; - padding-bottom: 0; - flex-flow: row wrap; - justify-content: center; background: black; + width: 100%; height: 100px; + padding: 0; } .kusama-mainpage-row-learn { - width: 100%; display: flex; - padding: 0%; - padding-top: 1%; - padding-bottom: 1%; flex-flow: row wrap; justify-content: center; + width: 100%; + padding: 1% 0; color: white; background: black; } .kusama-mainpage-row { - width: 100%; display: flex; - padding: 0%; - padding-top: 0; - padding-bottom: 0; flex-flow: row wrap; justify-content: center; + width: 100%; + padding: 0; color: white; - background: black; - background-image: url("../img/kusama-pink-row.svg"); - background-position: center; - background: cover; + background: url("../img/kusama-pink-row.svg") center black; } .kusama-mainpage-cyber-row { - width: 100%; display: flex; - padding: 0%; - padding-top: 0; - padding-bottom: 0; flex-flow: row wrap; justify-content: center; + width: 100%; + padding: 0; color: white; - background: black; - background-image: url("../img/Kusama-white-stencil.png"); - background-position: left center; - background-repeat: no-repeat; + background: url("../img/Kusama-white-stencil.png") left center no-repeat black; background-size: 40%; } .kusama-mainpage-row-validator { width: 100%; display: flex; - padding: 0%; - padding-top: 0; - padding-bottom: 0; + padding: 0; flex-flow: row wrap; justify-content: center; color: black; } .kusama-mainpage-row-more { - width: 100%; display: flex; - padding: 0%; - padding-top: 0; - padding-bottom: 0; flex-flow: row wrap; justify-content: center; - background: black; + width: 100%; + padding: 0; color: white; - border-bottom: 10px solid #e6007a; + background: black; + border-bottom: 10px solid var(--ifm-color-primary); +} + +.kusama-mainpage-column { + width: 50%; + display: flex; + align-items: center; + padding: 2%; + text-align: center; + flex-flow: column; +} + +@media only screen and (min-device-width: 360px) and (max-device-width: 736px) { + .mainpage-column { + width: 100% !important; + } } .kusama-mainpage-build-btn { background: transparent; - border: 1px solid #e6007a; - color: #e6007a; + border: 1px solid var(--ifm-color-primary); + color: var(--ifm-color-primary); width: 100%; font-weight: 500; padding: 10px; font-size: 14px; margin-top: 24px; - margin-bottom: 12px; text-align: center; vertical-align: middle; margin-bottom: 0.75rem !important; @@ -259,24 +505,21 @@ body { cursor: pointer; } -.navigationSlider .slidingNav ul li.siteNavGroupActive > a { - background-color: black; -} - -.navigationSlider .slidingNav ul li.siteNavGroupActive > a:hover { - background-color: #e6007a; +.kusama-mainpage-build-btn:hover { + color: #00ffe1; + border-color: #00ffe1; } -.kusama-mainpage-build-btn:hover { +.mainpage-build-btn:hover { color: #00ffe1; border: 1px solid #00ffe1; } -.kusama-mainpage-column { +.mainpage-column { width: 50%; display: flex; align-items: center; - padding: 2%; + padding: 5%; text-align: center; flex-flow: column; } @@ -284,9 +527,16 @@ body { .docsContainer > .wrapper > .post { padding-top: 50px; } + #docsNav { top: 130px; } + + a.navbar__link, + a.navbar__link:hover, + a.navbar__link:active { + color: black !important; + } } .nomargin { @@ -295,7 +545,7 @@ body { @media print { .docsNavContainer, - .fixedHeaderContainer, + .navbar.navbar--fixed-top, .github-fork-ribbon, .toc, .slidingNav, @@ -307,7 +557,7 @@ body { display: none; } - .navPusher { + .main-wrapper { padding-top: 0; } } diff --git a/kusama-guide/static/fonts/OFL.txt b/kusama-guide/static/fonts/OFL.txt index 8109b5420444..5bb7346e6a56 100755 --- a/kusama-guide/static/fonts/OFL.txt +++ b/kusama-guide/static/fonts/OFL.txt @@ -1,93 +1,93 @@ -Copyright 2016 Google Inc. All Rights Reserved. - -This Font Software is licensed under the SIL Open Font License, Version 1.1. -This license is copied below, and is also available with a FAQ at: -http://scripts.sil.org/OFL - - ------------------------------------------------------------ -SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 ------------------------------------------------------------ - -PREAMBLE -The goals of the Open Font License (OFL) are to stimulate worldwide -development of collaborative font projects, to support the font creation -efforts of academic and linguistic communities, and to provide a free and -open framework in which fonts may be shared and improved in partnership -with others. - -The OFL allows the licensed fonts to be used, studied, modified and -redistributed freely as long as they are not sold by themselves. The -fonts, including any derivative works, can be bundled, embedded, -redistributed and/or sold with any software provided that any reserved -names are not used by derivative works. The fonts and derivatives, -however, cannot be released under any other type of license. The -requirement for fonts to remain under this license does not apply -to any document created using the fonts or their derivatives. - -DEFINITIONS -"Font Software" refers to the set of files released by the Copyright -Holder(s) under this license and clearly marked as such. This may -include source files, build scripts and documentation. - -"Reserved Font Name" refers to any names specified as such after the -copyright statement(s). - -"Original Version" refers to the collection of Font Software components as -distributed by the Copyright Holder(s). - -"Modified Version" refers to any derivative made by adding to, deleting, -or substituting -- in part or in whole -- any of the components of the -Original Version, by changing formats or by porting the Font Software to a -new environment. - -"Author" refers to any designer, engineer, programmer, technical -writer or other person who contributed to the Font Software. - -PERMISSION & CONDITIONS -Permission is hereby granted, free of charge, to any person obtaining -a copy of the Font Software, to use, study, copy, merge, embed, modify, -redistribute, and sell modified and unmodified copies of the Font -Software, subject to the following conditions: - -1) Neither the Font Software nor any of its individual components, -in Original or Modified Versions, may be sold by itself. - -2) Original or Modified Versions of the Font Software may be bundled, -redistributed and/or sold with any software, provided that each copy -contains the above copyright notice and this license. These can be -included either as stand-alone text files, human-readable headers or -in the appropriate machine-readable metadata fields within text or -binary files as long as those fields can be easily viewed by the user. - -3) No Modified Version of the Font Software may use the Reserved Font -Name(s) unless explicit written permission is granted by the corresponding -Copyright Holder. This restriction only applies to the primary font name as -presented to the users. - -4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font -Software shall not be used to promote, endorse or advertise any -Modified Version, except to acknowledge the contribution(s) of the -Copyright Holder(s) and the Author(s) or with their explicit written -permission. - -5) The Font Software, modified or unmodified, in part or in whole, -must be distributed entirely under this license, and must not be -distributed under any other license. The requirement for fonts to -remain under this license does not apply to any document created -using the Font Software. - -TERMINATION -This license becomes null and void if any of the above conditions are -not met. - -DISCLAIMER -THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, -EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT -OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE -COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL -DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING -FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM -OTHER DEALINGS IN THE FONT SOFTWARE. +Copyright 2016 Google Inc. All Rights Reserved. + +This Font Software is licensed under the SIL Open Font License, Version 1.1. +This license is copied below, and is also available with a FAQ at: +http://scripts.sil.org/OFL + + +----------------------------------------------------------- +SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 +----------------------------------------------------------- + +PREAMBLE +The goals of the Open Font License (OFL) are to stimulate worldwide +development of collaborative font projects, to support the font creation +efforts of academic and linguistic communities, and to provide a free and +open framework in which fonts may be shared and improved in partnership +with others. + +The OFL allows the licensed fonts to be used, studied, modified and +redistributed freely as long as they are not sold by themselves. The +fonts, including any derivative works, can be bundled, embedded, +redistributed and/or sold with any software provided that any reserved +names are not used by derivative works. The fonts and derivatives, +however, cannot be released under any other type of license. The +requirement for fonts to remain under this license does not apply +to any document created using the fonts or their derivatives. + +DEFINITIONS +"Font Software" refers to the set of files released by the Copyright +Holder(s) under this license and clearly marked as such. This may +include source files, build scripts and documentation. + +"Reserved Font Name" refers to any names specified as such after the +copyright statement(s). + +"Original Version" refers to the collection of Font Software components as +distributed by the Copyright Holder(s). + +"Modified Version" refers to any derivative made by adding to, deleting, +or substituting -- in part or in whole -- any of the components of the +Original Version, by changing formats or by porting the Font Software to a +new environment. + +"Author" refers to any designer, engineer, programmer, technical +writer or other person who contributed to the Font Software. + +PERMISSION & CONDITIONS +Permission is hereby granted, free of charge, to any person obtaining +a copy of the Font Software, to use, study, copy, merge, embed, modify, +redistribute, and sell modified and unmodified copies of the Font +Software, subject to the following conditions: + +1) Neither the Font Software nor any of its individual components, +in Original or Modified Versions, may be sold by itself. + +2) Original or Modified Versions of the Font Software may be bundled, +redistributed and/or sold with any software, provided that each copy +contains the above copyright notice and this license. These can be +included either as stand-alone text files, human-readable headers or +in the appropriate machine-readable metadata fields within text or +binary files as long as those fields can be easily viewed by the user. + +3) No Modified Version of the Font Software may use the Reserved Font +Name(s) unless explicit written permission is granted by the corresponding +Copyright Holder. This restriction only applies to the primary font name as +presented to the users. + +4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font +Software shall not be used to promote, endorse or advertise any +Modified Version, except to acknowledge the contribution(s) of the +Copyright Holder(s) and the Author(s) or with their explicit written +permission. + +5) The Font Software, modified or unmodified, in part or in whole, +must be distributed entirely under this license, and must not be +distributed under any other license. The requirement for fonts to +remain under this license does not apply to any document created +using the Font Software. + +TERMINATION +This license becomes null and void if any of the above conditions are +not met. + +DISCLAIMER +THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT +OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE +COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, +INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL +DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM +OTHER DEALINGS IN THE FONT SOFTWARE. diff --git a/kusama-guide/static/img/GRANDPA/chain-selection.png b/kusama-guide/static/img/GRANDPA/chain-selection.png deleted file mode 100644 index 84f61a894873..000000000000 Binary files a/kusama-guide/static/img/GRANDPA/chain-selection.png and /dev/null differ diff --git a/kusama-guide/static/img/Kusama-white-stencil.svg b/kusama-guide/static/img/Kusama-white-stencil.svg deleted file mode 100644 index f0841f4b5daf..000000000000 --- a/kusama-guide/static/img/Kusama-white-stencil.svg +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - diff --git a/kusama-guide-v2/static/img/Kusama_Canary_white.png b/kusama-guide/static/img/Kusama_Canary_white.png similarity index 100% rename from kusama-guide-v2/static/img/Kusama_Canary_white.png rename to kusama-guide/static/img/Kusama_Canary_white.png diff --git a/kusama-guide/static/img/Kusama_logotype_collage.png b/kusama-guide/static/img/Kusama_logotype_collage.png deleted file mode 100644 index 8e1a9efd99af..000000000000 Binary files a/kusama-guide/static/img/Kusama_logotype_collage.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/article-1.png b/kusama-guide/static/img/NPoS/article-1.png deleted file mode 100644 index bfb16b86bd91..000000000000 Binary files a/kusama-guide/static/img/NPoS/article-1.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/article-2.png b/kusama-guide/static/img/NPoS/article-2.png deleted file mode 100644 index 57290d4e12bc..000000000000 Binary files a/kusama-guide/static/img/NPoS/article-2.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/article-3.png b/kusama-guide/static/img/NPoS/article-3.png deleted file mode 100644 index 4a179111097c..000000000000 Binary files a/kusama-guide/static/img/NPoS/article-3.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/article-4.png b/kusama-guide/static/img/NPoS/article-4.png deleted file mode 100644 index 7440bf63c4c8..000000000000 Binary files a/kusama-guide/static/img/NPoS/article-4.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/article-5.png b/kusama-guide/static/img/NPoS/article-5.png deleted file mode 100644 index 2d5a995c0392..000000000000 Binary files a/kusama-guide/static/img/NPoS/article-5.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/nominate.png b/kusama-guide/static/img/NPoS/nominate.png deleted file mode 100644 index 78f069ef3384..000000000000 Binary files a/kusama-guide/static/img/NPoS/nominate.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/nominate2.png b/kusama-guide/static/img/NPoS/nominate2.png deleted file mode 100644 index 8d7ff0e7aa79..000000000000 Binary files a/kusama-guide/static/img/NPoS/nominate2.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/staking-keys.png b/kusama-guide/static/img/NPoS/staking-keys.png deleted file mode 100644 index d0085a4dc89c..000000000000 Binary files a/kusama-guide/static/img/NPoS/staking-keys.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/staking-participation-rate.png b/kusama-guide/static/img/NPoS/staking-participation-rate.png deleted file mode 100644 index 0d7cd1e98f8d..000000000000 Binary files a/kusama-guide/static/img/NPoS/staking-participation-rate.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/unbond1.png b/kusama-guide/static/img/NPoS/unbond1.png deleted file mode 100644 index 2dd3e0cce574..000000000000 Binary files a/kusama-guide/static/img/NPoS/unbond1.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/unbond2.png b/kusama-guide/static/img/NPoS/unbond2.png deleted file mode 100644 index 6b9591170af1..000000000000 Binary files a/kusama-guide/static/img/NPoS/unbond2.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/unbond3.png b/kusama-guide/static/img/NPoS/unbond3.png deleted file mode 100644 index 84a30f91371e..000000000000 Binary files a/kusama-guide/static/img/NPoS/unbond3.png and /dev/null differ diff --git a/kusama-guide/static/img/NPoS/unbond4.png b/kusama-guide/static/img/NPoS/unbond4.png deleted file mode 100644 index 22294f0aa75b..000000000000 Binary files a/kusama-guide/static/img/NPoS/unbond4.png and /dev/null differ diff --git a/kusama-guide/static/img/accounts/create-multisig.png b/kusama-guide/static/img/accounts/create-multisig.png deleted file mode 100644 index 4901c2b508ba..000000000000 Binary files a/kusama-guide/static/img/accounts/create-multisig.png and /dev/null differ diff --git a/kusama-guide/static/img/accounts/send-from-multi.png b/kusama-guide/static/img/accounts/send-from-multi.png deleted file mode 100644 index 8d4e863e5970..000000000000 Binary files a/kusama-guide/static/img/accounts/send-from-multi.png and /dev/null differ diff --git a/kusama-guide/static/img/accounts/sign-from-multi-1.png b/kusama-guide/static/img/accounts/sign-from-multi-1.png deleted file mode 100644 index fba15c56b496..000000000000 Binary files a/kusama-guide/static/img/accounts/sign-from-multi-1.png and /dev/null differ diff --git a/kusama-guide/static/img/build-1.png b/kusama-guide/static/img/build-1.png deleted file mode 100644 index 88e59b871480..000000000000 Binary files a/kusama-guide/static/img/build-1.png and /dev/null differ diff --git a/kusama-guide/static/img/build-2.png b/kusama-guide/static/img/build-2.png deleted file mode 100644 index baa316c17720..000000000000 Binary files a/kusama-guide/static/img/build-2.png and /dev/null differ diff --git a/kusama-guide/static/img/endpoints/kusama_endpoint_parity.png b/kusama-guide/static/img/endpoints/kusama_endpoint_parity.png deleted file mode 100644 index 59e3d088527f..000000000000 Binary files a/kusama-guide/static/img/endpoints/kusama_endpoint_parity.png and /dev/null differ diff --git a/kusama-guide/static/img/endpoints/kusama_endpoint_web3.png b/kusama-guide/static/img/endpoints/kusama_endpoint_web3.png deleted file mode 100644 index 0e514456797b..000000000000 Binary files a/kusama-guide/static/img/endpoints/kusama_endpoint_web3.png and /dev/null differ diff --git a/kusama-guide/static/img/errors/01.jpg b/kusama-guide/static/img/errors/01.jpg deleted file mode 100644 index 54993f533645..000000000000 Binary files a/kusama-guide/static/img/errors/01.jpg and /dev/null differ diff --git a/kusama-guide/static/img/errors/02.jpg b/kusama-guide/static/img/errors/02.jpg deleted file mode 100644 index 23070458ad47..000000000000 Binary files a/kusama-guide/static/img/errors/02.jpg and /dev/null differ diff --git a/kusama-guide/static/img/governance/AQB-electorate.png b/kusama-guide/static/img/governance/AQB-electorate.png deleted file mode 100644 index d46a4e873a2b..000000000000 Binary files a/kusama-guide/static/img/governance/AQB-electorate.png and /dev/null differ diff --git a/kusama-guide/static/img/governance/AQB.png b/kusama-guide/static/img/governance/AQB.png deleted file mode 100644 index 4b97d7a5af5a..000000000000 Binary files a/kusama-guide/static/img/governance/AQB.png and /dev/null differ diff --git a/kusama-guide/static/img/governance/Governance-diagram.png b/kusama-guide/static/img/governance/Governance-diagram.png deleted file mode 100644 index 0af3d47c90db..000000000000 Binary files a/kusama-guide/static/img/governance/Governance-diagram.png and /dev/null differ diff --git a/kusama-guide/static/img/governance/adaptive-quorum-biasing.png b/kusama-guide/static/img/governance/adaptive-quorum-biasing.png deleted file mode 100644 index 1eb06d447101..000000000000 Binary files a/kusama-guide/static/img/governance/adaptive-quorum-biasing.png and /dev/null differ diff --git a/kusama-guide/static/img/governance/approval-vote.png b/kusama-guide/static/img/governance/approval-vote.png deleted file mode 100644 index 0688e1e40e24..000000000000 Binary files a/kusama-guide/static/img/governance/approval-vote.png and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-nominate/nominating.jpg b/kusama-guide/static/img/guides/how-to-nominate/nominating.jpg deleted file mode 100644 index 60cd2e110ba9..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-nominate/nominating.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-nominate/nominating2.jpg b/kusama-guide/static/img/guides/how-to-nominate/nominating2.jpg deleted file mode 100644 index 79654c6e29a4..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-nominate/nominating2.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-bonding.jpg b/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-bonding.jpg deleted file mode 100644 index 71864676a117..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-bonding.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-create-account.jpg b/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-create-account.jpg deleted file mode 100644 index 7df13f786e53..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-create-account.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg b/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg deleted file mode 100644 index 224f9138458d..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-nominate/validators.png b/kusama-guide/static/img/guides/how-to-nominate/validators.png deleted file mode 100644 index 97ab8e488eb2..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-nominate/validators.png and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-bonding.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-bonding.jpg deleted file mode 100644 index 71864676a117..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-bonding.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-create-account.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-create-account.jpg deleted file mode 100644 index 7df13f786e53..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-create-account.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key-modal.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key-modal.jpg deleted file mode 100644 index eb49f806f0f3..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key-modal.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key.jpg deleted file mode 100644 index 224f9138458d..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-staking-queue.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-staking-queue.jpg deleted file mode 100644 index d720273702ff..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-staking-queue.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg deleted file mode 100644 index d0636b6a9878..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-validate.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-validate.jpg deleted file mode 100644 index 7526a095e5f8..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-dashboard-validate.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-node-seed.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-node-seed.jpg deleted file mode 100644 index 63c56d72ba1d..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-node-seed.jpg and /dev/null differ diff --git a/kusama-guide/static/img/guides/how-to-validate/polkadot-overview.jpg b/kusama-guide/static/img/guides/how-to-validate/polkadot-overview.jpg deleted file mode 100644 index 690c9d7e2cf2..000000000000 Binary files a/kusama-guide/static/img/guides/how-to-validate/polkadot-overview.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/01.jpg b/kusama-guide/static/img/identity/01.jpg deleted file mode 100644 index 2cb60d31021e..000000000000 Binary files a/kusama-guide/static/img/identity/01.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/02.jpg b/kusama-guide/static/img/identity/02.jpg deleted file mode 100644 index 624d14d9b263..000000000000 Binary files a/kusama-guide/static/img/identity/02.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/03.jpg b/kusama-guide/static/img/identity/03.jpg deleted file mode 100644 index d6d7f0e09738..000000000000 Binary files a/kusama-guide/static/img/identity/03.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/04.jpg b/kusama-guide/static/img/identity/04.jpg deleted file mode 100644 index aafacb605ea0..000000000000 Binary files a/kusama-guide/static/img/identity/04.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/05.jpg b/kusama-guide/static/img/identity/05.jpg deleted file mode 100644 index 32167bd3a681..000000000000 Binary files a/kusama-guide/static/img/identity/05.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/06.jpg b/kusama-guide/static/img/identity/06.jpg deleted file mode 100644 index 82444d1103c0..000000000000 Binary files a/kusama-guide/static/img/identity/06.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/07.jpg b/kusama-guide/static/img/identity/07.jpg deleted file mode 100644 index 655c57a6ac2a..000000000000 Binary files a/kusama-guide/static/img/identity/07.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/08.jpg b/kusama-guide/static/img/identity/08.jpg deleted file mode 100644 index 1f588b50a63e..000000000000 Binary files a/kusama-guide/static/img/identity/08.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/09.jpg b/kusama-guide/static/img/identity/09.jpg deleted file mode 100644 index f51250cea566..000000000000 Binary files a/kusama-guide/static/img/identity/09.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/10.jpg b/kusama-guide/static/img/identity/10.jpg deleted file mode 100644 index e689a85f23cf..000000000000 Binary files a/kusama-guide/static/img/identity/10.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/11.jpg b/kusama-guide/static/img/identity/11.jpg deleted file mode 100644 index 7ea56fc68f84..000000000000 Binary files a/kusama-guide/static/img/identity/11.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/12.jpg b/kusama-guide/static/img/identity/12.jpg deleted file mode 100644 index 5111c88ded7f..000000000000 Binary files a/kusama-guide/static/img/identity/12.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/13.jpg b/kusama-guide/static/img/identity/13.jpg deleted file mode 100644 index 992551249fe2..000000000000 Binary files a/kusama-guide/static/img/identity/13.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/14.jpg b/kusama-guide/static/img/identity/14.jpg deleted file mode 100644 index ba82bee6a756..000000000000 Binary files a/kusama-guide/static/img/identity/14.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/15.jpg b/kusama-guide/static/img/identity/15.jpg deleted file mode 100644 index 3a23c9edb551..000000000000 Binary files a/kusama-guide/static/img/identity/15.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/16.jpg b/kusama-guide/static/img/identity/16.jpg deleted file mode 100644 index 89541bce4100..000000000000 Binary files a/kusama-guide/static/img/identity/16.jpg and /dev/null differ diff --git a/kusama-guide/static/img/identity/clear.gif b/kusama-guide/static/img/identity/clear.gif deleted file mode 100644 index da24c875f0fb..000000000000 Binary files a/kusama-guide/static/img/identity/clear.gif and /dev/null differ diff --git a/kusama-guide/static/img/kusama-brand-assets/Kusama_Canary_white.png b/kusama-guide/static/img/kusama-brand-assets/Kusama_Canary_white.png deleted file mode 100644 index 1135d0c1e3aa..000000000000 Binary files a/kusama-guide/static/img/kusama-brand-assets/Kusama_Canary_white.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim-1.png b/kusama-guide/static/img/kusama/claim/claim-1.png deleted file mode 100644 index 965838661c18..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim-1.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim-2.png b/kusama-guide/static/img/kusama/claim/claim-2.png deleted file mode 100644 index ddd5843adc6f..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim-2.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim-3.png b/kusama-guide/static/img/kusama/claim/claim-3.png deleted file mode 100644 index 70693b090351..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim-3.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim-4.png b/kusama-guide/static/img/kusama/claim/claim-4.png deleted file mode 100644 index bc7fa439fc78..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim-4.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim_1.png b/kusama-guide/static/img/kusama/claim/claim_1.png deleted file mode 100644 index caa9b4c3645d..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim_1.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim_2.png b/kusama-guide/static/img/kusama/claim/claim_2.png deleted file mode 100644 index 65a676b48ae2..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim_2.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim_3.png b/kusama-guide/static/img/kusama/claim/claim_3.png deleted file mode 100644 index b657c46b604d..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim_3.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim_4.png b/kusama-guide/static/img/kusama/claim/claim_4.png deleted file mode 100644 index a227f4bc1f0b..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim_4.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/claim/claim_5.png b/kusama-guide/static/img/kusama/claim/claim_5.png deleted file mode 100644 index 1bc3c4be6199..000000000000 Binary files a/kusama-guide/static/img/kusama/claim/claim_5.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/create_account.png b/kusama-guide/static/img/kusama/create_account.png deleted file mode 100644 index 36a7c818ce4b..000000000000 Binary files a/kusama-guide/static/img/kusama/create_account.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/faucet_1.png b/kusama-guide/static/img/kusama/faucet_1.png deleted file mode 100644 index b701520e8129..000000000000 Binary files a/kusama-guide/static/img/kusama/faucet_1.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/faucet_2.png b/kusama-guide/static/img/kusama/faucet_2.png deleted file mode 100644 index b5026f160f29..000000000000 Binary files a/kusama-guide/static/img/kusama/faucet_2.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/faucet_3.png b/kusama-guide/static/img/kusama/faucet_3.png deleted file mode 100644 index 4074f00f938e..000000000000 Binary files a/kusama-guide/static/img/kusama/faucet_3.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/kusama_polkadotjs_add_account-1.png b/kusama-guide/static/img/kusama/kusama_polkadotjs_add_account-1.png deleted file mode 100644 index e94c07f93d6e..000000000000 Binary files a/kusama-guide/static/img/kusama/kusama_polkadotjs_add_account-1.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/kusama_polkadotjs_create.png b/kusama-guide/static/img/kusama/kusama_polkadotjs_create.png deleted file mode 100644 index 0c0e8c705a0e..000000000000 Binary files a/kusama-guide/static/img/kusama/kusama_polkadotjs_create.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/kusama_polkadotjs_final_account.png b/kusama-guide/static/img/kusama/kusama_polkadotjs_final_account.png deleted file mode 100644 index 978a36d2d340..000000000000 Binary files a/kusama-guide/static/img/kusama/kusama_polkadotjs_final_account.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/kusama_polkadotjs_mnemonicseed.jpg b/kusama-guide/static/img/kusama/kusama_polkadotjs_mnemonicseed.jpg deleted file mode 100644 index 968dfeac85b5..000000000000 Binary files a/kusama-guide/static/img/kusama/kusama_polkadotjs_mnemonicseed.jpg and /dev/null differ diff --git a/kusama-guide/static/img/kusama/kusama_polkadotjs_uncheck.png b/kusama-guide/static/img/kusama/kusama_polkadotjs_uncheck.png deleted file mode 100644 index 41965fda0029..000000000000 Binary files a/kusama-guide/static/img/kusama/kusama_polkadotjs_uncheck.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/polkadotui-copy-account-address.png b/kusama-guide/static/img/kusama/polkadotui-copy-account-address.png deleted file mode 100644 index e4944cb7f854..000000000000 Binary files a/kusama-guide/static/img/kusama/polkadotui-copy-account-address.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/polkadotui-create-your-account.png b/kusama-guide/static/img/kusama/polkadotui-create-your-account.png deleted file mode 100644 index ca2c62d32ab8..000000000000 Binary files a/kusama-guide/static/img/kusama/polkadotui-create-your-account.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/polkadotui-find-the-accounts-page.png b/kusama-guide/static/img/kusama/polkadotui-find-the-accounts-page.png deleted file mode 100644 index f448e53e80ed..000000000000 Binary files a/kusama-guide/static/img/kusama/polkadotui-find-the-accounts-page.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/polkadotui-select-add-account-on-accounts-page.png b/kusama-guide/static/img/kusama/polkadotui-select-add-account-on-accounts-page.png deleted file mode 100644 index 6a662784a7d7..000000000000 Binary files a/kusama-guide/static/img/kusama/polkadotui-select-add-account-on-accounts-page.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/polkawallet-accounts-page.jpg b/kusama-guide/static/img/kusama/polkawallet-accounts-page.jpg deleted file mode 100644 index c629e64bd427..000000000000 Binary files a/kusama-guide/static/img/kusama/polkawallet-accounts-page.jpg and /dev/null differ diff --git a/kusama-guide/static/img/kusama/polkawallet-copy-address.jpg b/kusama-guide/static/img/kusama/polkawallet-copy-address.jpg deleted file mode 100644 index 03ed52c7f112..000000000000 Binary files a/kusama-guide/static/img/kusama/polkawallet-copy-address.jpg and /dev/null differ diff --git a/kusama-guide/static/img/kusama/polkawallet-create-account.jpg b/kusama-guide/static/img/kusama/polkawallet-create-account.jpg deleted file mode 100644 index 28d500ae1a20..000000000000 Binary files a/kusama-guide/static/img/kusama/polkawallet-create-account.jpg and /dev/null differ diff --git a/kusama-guide/static/img/kusama/save_backup.png b/kusama-guide/static/img/kusama/save_backup.png deleted file mode 100644 index 262c63c54faa..000000000000 Binary files a/kusama-guide/static/img/kusama/save_backup.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/save_generated_account.png b/kusama-guide/static/img/kusama/save_generated_account.png deleted file mode 100644 index da0906b44464..000000000000 Binary files a/kusama-guide/static/img/kusama/save_generated_account.png and /dev/null differ diff --git a/kusama-guide/static/img/kusama/select_address.png b/kusama-guide/static/img/kusama/select_address.png deleted file mode 100644 index ecd8424d36cb..000000000000 Binary files a/kusama-guide/static/img/kusama/select_address.png and /dev/null differ diff --git a/kusama-guide/static/img/network/one_parachain.png b/kusama-guide/static/img/network/one_parachain.png deleted file mode 100644 index ce31d7644f3a..000000000000 Binary files a/kusama-guide/static/img/network/one_parachain.png and /dev/null differ diff --git a/kusama-guide/static/img/oss_logo.png b/kusama-guide/static/img/oss_logo.png deleted file mode 100755 index 8183e289b139..000000000000 Binary files a/kusama-guide/static/img/oss_logo.png and /dev/null differ diff --git a/kusama-guide/static/img/parachain/info.png b/kusama-guide/static/img/parachain/info.png deleted file mode 100644 index 46bdbc046dd4..000000000000 Binary files a/kusama-guide/static/img/parachain/info.png and /dev/null differ diff --git a/kusama-guide/static/img/parachain/referendum.png b/kusama-guide/static/img/parachain/referendum.png deleted file mode 100644 index babc91adeccc..000000000000 Binary files a/kusama-guide/static/img/parachain/referendum.png and /dev/null differ diff --git a/kusama-guide/static/img/parachain/register.png b/kusama-guide/static/img/parachain/register.png deleted file mode 100644 index 7d0aa189eca2..000000000000 Binary files a/kusama-guide/static/img/parachain/register.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-1.png b/kusama-guide/static/img/recovery/social-recovery-1.png deleted file mode 100644 index 9cf2dfbe039c..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-1.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-10.png b/kusama-guide/static/img/recovery/social-recovery-10.png deleted file mode 100644 index 1342fa8415f1..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-10.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-11.png b/kusama-guide/static/img/recovery/social-recovery-11.png deleted file mode 100644 index 93eee834dccc..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-11.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-12.png b/kusama-guide/static/img/recovery/social-recovery-12.png deleted file mode 100644 index 16b810354dad..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-12.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-13.png b/kusama-guide/static/img/recovery/social-recovery-13.png deleted file mode 100644 index ee964e572187..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-13.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-14.png b/kusama-guide/static/img/recovery/social-recovery-14.png deleted file mode 100644 index 20720228ada3..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-14.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-15.png b/kusama-guide/static/img/recovery/social-recovery-15.png deleted file mode 100644 index 66152aa72c35..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-15.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-2.png b/kusama-guide/static/img/recovery/social-recovery-2.png deleted file mode 100644 index 5cab63f0b30a..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-2.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-3.png b/kusama-guide/static/img/recovery/social-recovery-3.png deleted file mode 100644 index 799b80386d66..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-3.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-4.png b/kusama-guide/static/img/recovery/social-recovery-4.png deleted file mode 100644 index 5718370b9f09..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-4.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-5.png b/kusama-guide/static/img/recovery/social-recovery-5.png deleted file mode 100644 index 379a2542b846..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-5.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-6.png b/kusama-guide/static/img/recovery/social-recovery-6.png deleted file mode 100644 index 5c5ed97136ec..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-6.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-7.png b/kusama-guide/static/img/recovery/social-recovery-7.png deleted file mode 100644 index 3b0314e36d38..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-7.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-8.png b/kusama-guide/static/img/recovery/social-recovery-8.png deleted file mode 100644 index 9a867e8190b4..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-8.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-9.png b/kusama-guide/static/img/recovery/social-recovery-9.png deleted file mode 100644 index 7dcedf9ed01e..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-9.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-diag-1.png b/kusama-guide/static/img/recovery/social-recovery-diag-1.png deleted file mode 100644 index 34125519afae..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-diag-1.png and /dev/null differ diff --git a/kusama-guide/static/img/recovery/social-recovery-diag-2.png b/kusama-guide/static/img/recovery/social-recovery-diag-2.png deleted file mode 100644 index 2593cf9ad775..000000000000 Binary files a/kusama-guide/static/img/recovery/social-recovery-diag-2.png and /dev/null differ diff --git a/kusama-guide/static/img/staking/polkadotjs-staking-account-actions.jpg b/kusama-guide/static/img/staking/polkadotjs-staking-account-actions.jpg deleted file mode 100644 index f822e59ae0b1..000000000000 Binary files a/kusama-guide/static/img/staking/polkadotjs-staking-account-actions.jpg and /dev/null differ diff --git a/kusama-guide/static/img/staking/polkadotjs-staking-returns.jpg b/kusama-guide/static/img/staking/polkadotjs-staking-returns.jpg deleted file mode 100644 index 00aa2cd4291c..000000000000 Binary files a/kusama-guide/static/img/staking/polkadotjs-staking-returns.jpg and /dev/null differ diff --git a/kusama-guide/static/img/staking/polkadotjs-staking-validator-stats.jpg b/kusama-guide/static/img/staking/polkadotjs-staking-validator-stats.jpg deleted file mode 100644 index 10d313ff2361..000000000000 Binary files a/kusama-guide/static/img/staking/polkadotjs-staking-validator-stats.jpg and /dev/null differ diff --git a/kusama-guide/static/img/treasury/constants.jpg b/kusama-guide/static/img/treasury/constants.jpg deleted file mode 100644 index 76c6a53a4c7a..000000000000 Binary files a/kusama-guide/static/img/treasury/constants.jpg and /dev/null differ diff --git a/kusama-guide/static/img/treasury/motion.jpg b/kusama-guide/static/img/treasury/motion.jpg deleted file mode 100644 index be3e069884d8..000000000000 Binary files a/kusama-guide/static/img/treasury/motion.jpg and /dev/null differ diff --git a/kusama-guide/static/img/treasury/proposal.jpg b/kusama-guide/static/img/treasury/proposal.jpg deleted file mode 100644 index 3bf13cc3aaf0..000000000000 Binary files a/kusama-guide/static/img/treasury/proposal.jpg and /dev/null differ diff --git a/kusama-guide/static/img/treasury/propose.jpg b/kusama-guide/static/img/treasury/propose.jpg deleted file mode 100644 index 3b4e5fb188f2..000000000000 Binary files a/kusama-guide/static/img/treasury/propose.jpg and /dev/null differ diff --git a/kusama-guide/static/img/undraw_code_review.svg b/kusama-guide/static/img/undraw_code_review.svg deleted file mode 100755 index 56433417231c..000000000000 --- a/kusama-guide/static/img/undraw_code_review.svg +++ /dev/null @@ -1 +0,0 @@ -code review diff --git a/kusama-guide/static/img/undraw_monitor.svg b/kusama-guide/static/img/undraw_monitor.svg deleted file mode 100755 index c81d8ab17301..000000000000 --- a/kusama-guide/static/img/undraw_monitor.svg +++ /dev/null @@ -1 +0,0 @@ -monitor diff --git a/kusama-guide/static/img/undraw_note_list.svg b/kusama-guide/static/img/undraw_note_list.svg deleted file mode 100755 index e82c33bfd716..000000000000 --- a/kusama-guide/static/img/undraw_note_list.svg +++ /dev/null @@ -1 +0,0 @@ -note list diff --git a/kusama-guide/static/img/undraw_online.svg b/kusama-guide/static/img/undraw_online.svg deleted file mode 100755 index 7cc31ce006e9..000000000000 --- a/kusama-guide/static/img/undraw_online.svg +++ /dev/null @@ -1 +0,0 @@ -online diff --git a/kusama-guide/static/img/undraw_open_source.svg b/kusama-guide/static/img/undraw_open_source.svg deleted file mode 100755 index dbd7a2db8518..000000000000 --- a/kusama-guide/static/img/undraw_open_source.svg +++ /dev/null @@ -1 +0,0 @@ -open source diff --git a/kusama-guide/static/img/undraw_operating_system.svg b/kusama-guide/static/img/undraw_operating_system.svg deleted file mode 100755 index 60b7c806edb5..000000000000 --- a/kusama-guide/static/img/undraw_operating_system.svg +++ /dev/null @@ -1 +0,0 @@ -operating system diff --git a/kusama-guide/static/img/undraw_react.svg b/kusama-guide/static/img/undraw_react.svg deleted file mode 100755 index e3e60bb52699..000000000000 --- a/kusama-guide/static/img/undraw_react.svg +++ /dev/null @@ -1 +0,0 @@ -react diff --git a/kusama-guide/static/img/undraw_tweetstorm.svg b/kusama-guide/static/img/undraw_tweetstorm.svg deleted file mode 100755 index c957581db712..000000000000 --- a/kusama-guide/static/img/undraw_tweetstorm.svg +++ /dev/null @@ -1 +0,0 @@ -tweetstorm diff --git a/kusama-guide/static/img/undraw_youtube_tutorial.svg b/kusama-guide/static/img/undraw_youtube_tutorial.svg deleted file mode 100755 index 17d3f7776f12..000000000000 --- a/kusama-guide/static/img/undraw_youtube_tutorial.svg +++ /dev/null @@ -1 +0,0 @@ -youtube tutorial diff --git a/kusama-guide/static/img/updated_pre.png b/kusama-guide/static/img/updated_pre.png deleted file mode 100644 index 0e51b326903c..000000000000 Binary files a/kusama-guide/static/img/updated_pre.png and /dev/null differ diff --git a/kusama-guide/static/img/wechat_page_account.jpg b/kusama-guide/static/img/wechat_page_account.jpg deleted file mode 100644 index 4744570e91d0..000000000000 Binary files a/kusama-guide/static/img/wechat_page_account.jpg and /dev/null differ diff --git a/kusama-guide/static/img/wss/wss01.jpg b/kusama-guide/static/img/wss/wss01.jpg deleted file mode 100644 index 255ec003e8d3..000000000000 Binary files a/kusama-guide/static/img/wss/wss01.jpg and /dev/null differ diff --git a/kusama-guide/static/index.html b/kusama-guide/static/index.html deleted file mode 100644 index ba10d1978f91..000000000000 --- a/kusama-guide/static/index.html +++ /dev/null @@ -1,15 +0,0 @@ - - - - - - - Kusama Guide - - - If you are not redirected automatically, follow this - link. - - \ No newline at end of file diff --git a/kusama-guide/static/js/clipboard.min.js b/kusama-guide/static/js/clipboard.min.js index 28650f3cc98a..e09a1daf18d5 100644 --- a/kusama-guide/static/js/clipboard.min.js +++ b/kusama-guide/static/js/clipboard.min.js @@ -1,7 +1,614 @@ /*! * clipboard.js v2.0.6 * https://clipboardjs.com/ - * + * * Licensed MIT © Zeno Rocha */ -!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.ClipboardJS=e():t.ClipboardJS=e()}(this,function(){return o={},r.m=n=[function(t,e){t.exports=function(t){var e;if("SELECT"===t.nodeName)t.focus(),e=t.value;else if("INPUT"===t.nodeName||"TEXTAREA"===t.nodeName){var n=t.hasAttribute("readonly");n||t.setAttribute("readonly",""),t.select(),t.setSelectionRange(0,t.value.length),n||t.removeAttribute("readonly"),e=t.value}else{t.hasAttribute("contenteditable")&&t.focus();var o=window.getSelection(),r=document.createRange();r.selectNodeContents(t),o.removeAllRanges(),o.addRange(r),e=o.toString()}return e}},function(t,e){function n(){}n.prototype={on:function(t,e,n){var o=this.e||(this.e={});return(o[t]||(o[t]=[])).push({fn:e,ctx:n}),this},once:function(t,e,n){var o=this;function r(){o.off(t,r),e.apply(n,arguments)}return r._=e,this.on(t,r,n)},emit:function(t){for(var e=[].slice.call(arguments,1),n=((this.e||(this.e={}))[t]||[]).slice(),o=0,r=n.length;o' + - icon + - '' + - label + - "" + - "
"; - return btn; - } - - function addButtons(codeBlockSelector, btn) { - document.querySelectorAll(codeBlockSelector).forEach(function (code) { - code.parentNode.appendChild(btn.cloneNode(true)); - }); - } - - const copyIcon = - ''; - - addButtons(".hljs", button("Copy", "Copy code to clipboard", copyIcon, "btnClipboard")); - - const clipboard = new ClipboardJS(".btnClipboard", { - target: function (trigger) { - return trigger.parentNode.querySelector("code"); - }, - }); - - clipboard.on("success", function (event) { - event.clearSelection(); - const textEl = event.trigger.querySelector(".btnIcon__label"); - textEl.textContent = "Copied"; - setTimeout(function () { - textEl.textContent = "Copy"; - }, 2000); - }); -}); +// Turn off ESLint for this file because it's sent down to users as-is. +/* eslint-disable */ +window.addEventListener("load", function () { + function button(label, ariaLabel, icon, className) { + const btn = document.createElement("button"); + btn.classList.add("btnIcon", className); + btn.setAttribute("type", "button"); + btn.setAttribute("aria-label", ariaLabel); + btn.innerHTML = + '
' + + icon + + '' + + label + + "" + + "
"; + return btn; + } + + function addButtons(codeBlockSelector, btn) { + document.querySelectorAll(codeBlockSelector).forEach(function (code) { + code.parentNode.appendChild(btn.cloneNode(true)); + }); + } + + const copyIcon = + ''; + + addButtons( + ".hljs", + button("Copy", "Copy code to clipboard", copyIcon, "btnClipboard") + ); + + const clipboard = new ClipboardJS(".btnClipboard", { + target: function (trigger) { + return trigger.parentNode.querySelector("code"); + }, + }); + + clipboard.on("success", function (event) { + event.clearSelection(); + const textEl = event.trigger.querySelector(".btnIcon__label"); + textEl.textContent = "Copied"; + setTimeout(function () { + textEl.textContent = "Copy"; + }, 2000); + }); +}); diff --git a/kusama-guide/static/js/custom.js b/kusama-guide/static/js/custom.js index 46db470ad062..ebc556dd1af5 100644 --- a/kusama-guide/static/js/custom.js +++ b/kusama-guide/static/js/custom.js @@ -77,42 +77,17 @@ })("docReady", window); docReady(function () { - // Custom logic goes here + setTimeout(function () { + // Custom logic goes here - // Insert "Improve this wiki ribbon" - if ( - window.location.pathname !== "/" && - window.location.pathname !== "/index.html" && - window.location.pathname !== "/en" && - window.location.pathname !== "/en/" - ) { - let link = document.createElement("a"); - link.classList = "github-fork-ribbon"; - link.setAttribute("href", "contributing"); - link.setAttribute("title", "Contribute to this wiki"); - link.dataset.ribbon = "Contribute to this wiki"; - link.innerText = "Contribute to this wiki"; - document.querySelector("body").appendChild(link); - } else { - document.querySelector(".fixedHeaderContainer").classList += " nomargin"; - } - // ----------------- - - // Add fathom to footer + // Insert "Improve this wiki ribbon": Done in docusaurus.config.js - let script = document.createElement("script"); - script.setAttribute("src", "https://lion.kusama.network/script.js"); - script.setAttribute("site", "PNZSQVUV"); - document.querySelector("body footer").appendChild(script); + // Add fathom to footer + let script = document.createElement("script"); + script.setAttribute("src", "https://lion.kusama.network/script.js"); + script.setAttribute("site", "PNZSQVUV"); + document.querySelector("#footer").appendChild(script); - // Force edit button to go to non-mirror page - let button = document.querySelector("a.edit-page-link.button"); - if (button) { - button.setAttribute("href", button.getAttribute("href").replace("mirror-", "")); - } + // Force edit button to go to non-mirror page: Done in docusaurus.config.js + }, 1000); }); - -// Redirects -if (!location.href.indexOf("docs") === -1) { - location.href = "test/docs/en/kusama-index.html"; -} diff --git a/package.json b/package.json index 72bf66d9ed74..8aa2a544213f 100644 --- a/package.json +++ b/package.json @@ -1,49 +1,36 @@ { "scripts": { - "start": "yarn polkadot1:start", - "kusama1:start": "yarn mirror; yarn copy:translations; cd kusama-guide; docusaurus-start", - "kusama1:build": "BUILDING=true; yarn mirror; yarn copy:translations; cd kusama-guide; docusaurus-build; node ./postprocess", - "kusama1:inject": "node --experimental-json-modules scripts/inject.mjs --rootDir kusama-guide/build/kusama-guide-hosting", - "kusama1:publish-gh-pages": "yarn mirror; PUBLISHING=true; cd kusama-guide; docusaurus-publish", - "kusama1:pdf": "yarn mr-pdf --initialDocsURL=\"http://localhost:3000/docs/en/kusama-index\" --paginationSelector=\".docs-next.button\" --excludeSelectors=\".docs-prevnext\" --pdfFormat=\"A4\" --outputPDFFilename=\"kusama-guide/static/kusama-wiki.pdf\" --pdfMargin=\"30, 5, 10, 5\"", - "kusama1:remove": "node --experimental-json-modules scripts/removeUneeded.mjs ksm", - "polkadot1:start": "yarn generateRegistryTable; yarn mirror; cd website; docusaurus-start", - "polkadot1:build": "yarn generateRegistryTable; BUILDING=true; cd website; docusaurus-build; node ./postprocess", - "polkadot1:inject": "node --experimental-json-modules scripts/inject.mjs --rootDir website/build/polkadot-wiki --node wss://rpc.polkadot.io", - "polkadot1:publish-gh-pages": "yarn mirror; PUBLISHING=true; cd website; docusaurus-publish", - "polkadot1:pdf": "yarn mr-pdf --initialDocsURL=\"http://localhost:3000/docs/en/getting-started\" --paginationSelector=\".docs-next.button\" --excludeSelectors=\".docs-prevnext,.navigationSlider,#footer\" --pdfFormat=\"A4\" --outputPDFFilename=\"website/static/polkadot-wiki.pdf\" --pdfMargin=\"30, 5, 10, 5\"", - "polkadot1:uploadPdf": "node --experimental-json-modules scripts/ipfs-upload-pdf.mjs", - "polkadot1:remove": "node --experimental-json-modules scripts/removeUneeded.mjs dot", - "mirror1": "node --experimental-json-modules scripts/mirror.mjs", - "copy:translations": "cp -R website/translated_docs kusama-guide ", - "publish-gh-pages": "cd website; docusaurus-publish", + "kusama:clean": "shx rm -rf node_modules/.cache; docusaurus clear kusama-guide", + "kusama:start": "docusaurus start kusama-guide", + "prekusama:build": "npm-run-all -ln kusama:clean -p \"fetch --isPolkadot=false\" mirror kusama:copy-assets --aggregate-output", + "kusama:build": "cross-env BUILDING=true docusaurus build kusama-guide; node kusama-guide/postprocess", + "kusama:inject": "node --experimental-json-modules scripts/inject.mjs --rootDir kusama-guide/build/kusama-guide-hosting", + "kusama:publish-gh-pages": "cross-env PUBLISHING=true docusaurus deploy kusama-guide", + "kusama:copy-assets": "cp -R docs/assets kusama-guide/i18n/zh-CN/docusaurus-plugin-content-docs/current", + "kusama:i18n:download": "yarn polkadot:crowdin:download:zh-CN", + "kusama:i18n:copy-translations": "cp -R polkadot-wiki/i18n/zh-CN/docusaurus-plugin-content-docs/current kusama-guide/i18n/zh-CN/docusaurus-plugin-content-docs/current", + "kusama:pdf": "yarn pdf --initialDocURLs \"http://localhost:3000/docs/kusama-index\" --outputPDFFilename=\"kusama-guide/static/kusama-wiki.pdf\" --coverTitle=\"KUSAMA GUIDE\"", + "polkadot:clean": "shx rm -rf node_modules/.cache; docusaurus clear polkadot-wiki", + "polkadot:start": "yarn generateRegistryTable; docusaurus start polkadot-wiki", + "prepolkadot:build": "npm-run-all -ln polkadot:clean -p fetch generateRegistryTable mirror polkadot:copy-assets:* --aggregate-output", + "polkadot:build": "cross-env BUILDING=true docusaurus build polkadot-wiki; node polkadot-wiki/postprocess", + "polkadot:inject": "node --experimental-json-modules scripts/inject.mjs --rootDir polkadot-wiki/build/polkadot-wiki --node wss://rpc.polkadot.io", + "polkadot:publish-gh-pages": "cross-env PUBLISHING=true docusaurus deploy polkadot-wiki", + "polkadot:pdf": "yarn pdf --initialDocURLs \"http://localhost:3000/docs/getting-started\" --outputPDFFilename=\"polkadot-wiki/static/polkadot-wiki.pdf\" --coverTitle=\"POLKADOT WIKI\"", + "copy:translations": "cp -R polkadot-wiki/translated_docs kusama-guide ", + "publish-gh-pages": "cd polkadot-wiki; docusaurus-publish", "write-translations": "docusaurus-write-translations", "version": "docusaurus-version", "rename-version": "docusaurus-rename-version", "crowdin-upload": "crowdin --config ../crowdin-docs-v1.yaml upload sources --auto-update -b master", "crowdin-download": "crowdin --config ../crowdin-docs-v1.yaml download -b master", - "generateRegistryTable": "node --experimental-json-modules scripts/generateRegistryTable.mjs > docs/build-ss58-registry.md; npx pretty-quick --staged docs/build-ss58-registry.md --write", - "generateErrorTable": "node --experimental-json-modules scripts/generateErrorTable.mjs >> docs/maintain-errors.md ; npx pretty-quick --staged docs/maintain-errors.md --write", - "kusama:clean": "shx rm -rf node_modules/.cache; docusaurus clear kusama-guide-v2", - "kusama:start": "yarn mirror; docusaurus start kusama-guide-v2", - "prekusama:build": "npm-run-all -ln kusama:clean -p \"fetch --isPolkadot=false\" mirror kusama:copy-assets --aggregate-output", - "kusama:build": "cross-env BUILDING=true docusaurus build kusama-guide-v2; node kusama-guide-v2/postprocess", - "kusama:publish-gh-pages": "cross-env PUBLISHING=true docusaurus deploy kusama-guide-v2", - "kusama:copy-assets": "cp -R docs/assets kusama-guide-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current", - "kusama:i18n:download": "yarn polkadot:crowdin:download:zh-CN", - "kusama:i18n:copy-translations": "cp -R website-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current kusama-guide-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current", - "kusama:pdf": "yarn pdf --initialDocURLs \"http://localhost:3000/docs/kusama-index\" --outputPDFFilename=\"kusama-guide-v2/static/kusama-wiki.pdf\" --coverTitle=\"KUSAMA GUIDE\"", - "polkadot:clean": "shx rm -rf node_modules/.cache; docusaurus clear website-v2", - "polkadot:start": "yarn generateRegistryTable; docusaurus start website-v2", - "prepolkadot:build": "npm-run-all -ln polkadot:clean -p fetch generateRegistryTable mirror polkadot:copy-assets:* --aggregate-output", - "polkadot:build": "cross-env BUILDING=true docusaurus build website-v2; node website-v2/postprocess", - "polkadot:publish-gh-pages": "cross-env PUBLISHING=true docusaurus deploy website-v2", - "polkadot:pdf": "yarn pdf --initialDocURLs \"http://localhost:3000/docs/getting-started\" --outputPDFFilename=\"website-v2/static/polkadot-wiki.pdf\" --coverTitle=\"POLKADOT WIKI\"", + "generateRegistryTable": "node --experimental-json-modules scripts/generateRegistryTable.mjs > docs/build-ss58-registry.md", + "generateErrorTable": "node --experimental-json-modules scripts/generateErrorTable.mjs >> docs/maintain-errors.md", "polkadot:crowdin:upload:source": "crowdin upload sources --config ./crowdin.yaml -b master", "polkadot:crowdin:download:ru": "crowdin download --config ./crowdin.yaml -b master -l ru", "polkadot:crowdin:download:zh-CN": "crowdin download --config ./crowdin.yaml -b master -l zh-CN", - "polkadot:copy-assets:ru": "shx mkdir -p website-v2/i18n/ru-RU/docusaurus-plugin-content-docs/current; shx cp -R docs/assets website-v2/i18n/ru-RU/docusaurus-plugin-content-docs/current", - "polkadot:copy-assets:zh-CN": "shx mkdir -p website-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current; shx cp -R docs/assets website-v2/i18n/zh-CN/docusaurus-plugin-content-docs/current", + "polkadot:copy-assets:ru": "shx mkdir -p polkadot-wiki/i18n/ru-RU/docusaurus-plugin-content-docs/current; shx cp -R docs/assets polkadot-wiki/i18n/ru-RU/docusaurus-plugin-content-docs/current", + "polkadot:copy-assets:zh-CN": "shx mkdir -p polkadot-wiki/i18n/zh-CN/docusaurus-plugin-content-docs/current; shx cp -R docs/assets polkadot-wiki/i18n/zh-CN/docusaurus-plugin-content-docs/current", "pdf": "npx mr-pdf --contentSelector=\"article\" --paginationSelector=\".pagination-nav__item--next > a\" --pdfFormat=\"A4\" --pdfMargin=\"90,60,80,60\"", "fetch": "node --experimental-json-modules scripts/fetch.mjs --isPolkadot", "mirror": "node --experimental-json-modules scripts/mirror.mjs", @@ -55,10 +42,10 @@ "@actions/core": "^1.4.0", "@actions/github": "^5.0.0", "@crowdin/cli": "^3.6.4", - "@docusaurus/core": "2.0.0-beta.4", + "@docusaurus/core": "^2.0.0-beta.4", "@docusaurus/module-type-aliases": "^2.0.0-beta.4", "@docusaurus/plugin-client-redirects": "^2.0.0-beta.4", - "@docusaurus/preset-classic": "2.0.0-beta.4", + "@docusaurus/preset-classic": "^2.0.0-beta.4", "@octokit/rest": "^18.9.0", "@polkadot/api": "^5.4.1", "@polkadot/keyring": "^7.1.2", @@ -86,5 +73,10 @@ "@docusaurus/theme-live-codeblock": "^2.0.0-beta.4", "remark-docusaurus-tabs": "^0.1.0", "replace-in-file": "^6.2.0" + }, + "husky": { + "hooks": { + "pre-commit": "pretty-quick --staged" + } } } diff --git a/website-v2/docusaurus.config.js b/polkadot-wiki/docusaurus.config.js similarity index 94% rename from website-v2/docusaurus.config.js rename to polkadot-wiki/docusaurus.config.js index 6786b7c06404..9528aef7c251 100644 --- a/website-v2/docusaurus.config.js +++ b/polkadot-wiki/docusaurus.config.js @@ -46,6 +46,8 @@ module.exports = { onBrokenLinks: "log", onBrokenMarkdownLinks: "log", onDuplicateRoutes: "log", + onBrokenLinks: "throw", + onBrokenMarkdownLinks: "throw", presets: [ [ "@docusaurus/preset-classic", @@ -79,10 +81,14 @@ module.exports = { redirects: [ { to: "/", - from: ["/en/latest", "/en/"], }, ], + createRedirects: function (existPath) { + if (existPath === "/docs/general") { + return ["/docs/"]; + } + }, createRedirects: function (existingPath) { if (existingPath.startsWith("/docs/")) { return [ @@ -144,7 +150,7 @@ module.exports = { position: "right", }, { - to: "docs/contributing", + to: "docs/general/contributing", label: "Contribute", position: "right", }, diff --git a/website-v2/i18n.js b/polkadot-wiki/i18n.js similarity index 100% rename from website-v2/i18n.js rename to polkadot-wiki/i18n.js diff --git a/polkadot-wiki/languages.js b/polkadot-wiki/languages.js new file mode 100755 index 000000000000..98beee241694 --- /dev/null +++ b/polkadot-wiki/languages.js @@ -0,0 +1,186 @@ +/** + * Copyright (c) 2017-present, Facebook, Inc. + * + * This source code is licensed under the MIT license found in the + * LICENSE file in the root directory of this source tree. + */ + +const languages = [ + { + enabled: true, + name: "English", + tag: "en", + }, + { + enabled: false, + name: "日本語", + tag: "ja", + }, + { + enabled: false, + name: "العربية", + tag: "ar", + }, + { + enabled: false, + name: "Bosanski", + tag: "bs-BA", + }, + { + enabled: false, + name: "Català", + tag: "ca", + }, + { + enabled: false, + name: "Čeština", + tag: "cs", + }, + { + enabled: false, + name: "Dansk", + tag: "da", + }, + { + enabled: false, + name: "Deutsch", + tag: "de", + }, + { + enabled: false, + name: "Ελληνικά", + tag: "el", + }, + { + enabled: false, + name: "Español", + tag: "es-ES", + }, + { + enabled: false, + name: "فارسی", + tag: "fa-IR", + }, + { + enabled: false, + name: "Suomi", + tag: "fi", + }, + { + enabled: false, + name: "Français", + tag: "fr", + }, + { + enabled: false, + name: "עִברִית", + tag: "he", + }, + { + enabled: false, + name: "Magyar", + tag: "hu", + }, + { + enabled: false, + name: "Bahasa Indonesia", + tag: "id-ID", + }, + { + enabled: false, + name: "Italiano", + tag: "it", + }, + { + enabled: false, + name: "Afrikaans", + tag: "af", + }, + { + enabled: false, + name: "한국어", + tag: "ko", + }, + { + enabled: false, + name: "मराठी", + tag: "mr-IN", + }, + { + enabled: false, + name: "Nederlands", + tag: "nl", + }, + { + enabled: false, + name: "Norsk", + tag: "no-NO", + }, + { + enabled: false, + name: "Polskie", + tag: "pl", + }, + { + enabled: false, + name: "Português", + tag: "pt-PT", + }, + { + enabled: false, + name: "Português (Brasil)", + tag: "pt-BR", + }, + { + enabled: false, + name: "Română", + tag: "ro", + }, + { + enabled: true, + name: "Русский", + tag: "ru", + }, + { + enabled: false, + name: "Slovenský", + tag: "sk-SK", + }, + { + enabled: false, + name: "Српски језик (Ћирилица)", + tag: "sr", + }, + { + enabled: false, + name: "Svenska", + tag: "sv-SE", + }, + { + enabled: false, + name: "Türkçe", + tag: "tr", + }, + { + enabled: false, + name: "Українська", + tag: "uk", + }, + { + enabled: false, + name: "Tiếng Việt", + tag: "vi", + }, + { + enabled: true, + name: "中文", + tag: "zh-CN", + }, + { + enabled: false, + name: "繁體中文", + tag: "zh-TW", + }, +]; + +module.exports = languages; diff --git a/polkadot-wiki/pages/en/help-with-translations.js b/polkadot-wiki/pages/en/help-with-translations.js new file mode 100755 index 000000000000..9383187261ff --- /dev/null +++ b/polkadot-wiki/pages/en/help-with-translations.js @@ -0,0 +1,69 @@ +/** + * Copyright (c) 2017-present, Facebook, Inc. + * + * This source code is licensed under the MIT license found in the + * LICENSE file in the root directory of this source tree. + */ + +const React = require("react"); + +const CompLibrary = require("../../core/CompLibrary.js"); + +const Container = CompLibrary.Container; +const GridBlock = CompLibrary.GridBlock; + +const translate = require("../../server/translate.js").translate; + +class Help extends React.Component { + render() { + const supportLinks = [ + { + content: ( + + Learn more using the [documentation on this + site.](/test-site/docs/en/doc1.html) + + ), + title: Browse Docs, + }, + { + content: ( + + Ask questions about the documentation and project + + ), + title: Join the community, + }, + { + content: Find out what's new with this project, + title: Stay up to date, + }, + ]; + + return ( +
+ +
+
+

+ Need help? +

+
+

+ + This project is maintained by a dedicated group of people. + +

+ +
+ +
+ ); + } +} + +Help.defaultProps = { + language: "en", +}; + +module.exports = Help; diff --git a/polkadot-wiki/pages/en/help.js b/polkadot-wiki/pages/en/help.js new file mode 100755 index 000000000000..98c64615a561 --- /dev/null +++ b/polkadot-wiki/pages/en/help.js @@ -0,0 +1,54 @@ +/** + * Copyright (c) 2017-present, Facebook, Inc. + * + * This source code is licensed under the MIT license found in the + * LICENSE file in the root directory of this source tree. + */ + +const React = require("react"); + +const CompLibrary = require("../../core/CompLibrary.js"); + +const Container = CompLibrary.Container; +const GridBlock = CompLibrary.GridBlock; + +function Help(props) { + const { config: siteConfig, language = "" } = props; + const { baseUrl, docsUrl } = siteConfig; + const docsPart = `${docsUrl ? `${docsUrl}/` : ""}`; + const langPart = `${language ? `${language}/` : ""}`; + const docUrl = (doc) => `${baseUrl}${docsPart}${langPart}${doc}`; + + const supportLinks = [ + { + content: `Learn more using the [documentation on this site.](${docUrl( + "doc1.html" + )})`, + title: "Browse Docs", + }, + { + content: "Ask questions about the documentation and project", + title: "Join the community", + }, + { + content: "Find out what's new with this project", + title: "Stay up to date", + }, + ]; + + return ( +
+ +
+
+

Need help?

+
+

This project is maintained by a dedicated group of people.

+ +
+ +
+ ); +} + +module.exports = Help; diff --git a/polkadot-wiki/pages/en/index.js b/polkadot-wiki/pages/en/index.js new file mode 100644 index 000000000000..edb025d0ff1d --- /dev/null +++ b/polkadot-wiki/pages/en/index.js @@ -0,0 +1,167 @@ +/** + * Copyright (c) 2017-present, Facebook, Inc. + * + * This source code is licensed under the MIT license found in the + * LICENSE file in the root directory of this source tree. + */ + +const React = require("react"); + +const Container = require("react-bootstrap/Container"); +const Row = require("react-bootstrap/Row"); +const Col = require("react-bootstrap/Col"); + +class HomeNav extends React.Component { + render() { + // const {siteConfig, language = ''} = this.props; + + const NavContainer = (props) => ( +
+ + + {props.children} + + +
+ ); + + const NavItem = (props) => ( + + +
+

+ {props.title} +

+

{props.content}

+
+ + + ); + + return ( + + + + + + ); + } +} + +class HomeFooter extends React.Component { + render() { + const FooterContainer = (props) => ( +
+ + {props.children} + +
+ ); + + const LearnKusama = () => ( + + + +

+ Learn about Polkadot’s canary network Kusama +

+

+ Kusama is Polkadot’s “canary network”, a scalable, multi-chain + network for radical innovation and early stage Polkadot deployments. + For developers, Kusama is a proving ground for all things Polkadot + I.e runtime upgrades, on-chain governance, parachains, parathreads, + etc. +

+ + + + + + + + ); + + const ImproveWiki = () => ( + + + + language + +

Help improve this wiki

+

+ This wiki was started by and is maintained by Web3 Foundation. It is + an open-source-ish project and aims to be the most extensive + resource of knowledge on Polkadot and the Polkadot ecosystem. +

+ + + + + + + + + + + ); + + return ( + + + + + ); + } +} + +class Index extends React.Component { + render() { + const { config: siteConfig, language = "" } = this.props; + const { baseUrl, docsUrl } = siteConfig; + const docsPart = `${docsUrl ? `${docsUrl}/` : ""}`; + const langPart = `${language ? `${language}/` : ""}`; + const docUrl = (doc) => `${baseUrl}${docsPart}${langPart}${doc}`; + + return ( +
+ + +
+ ); + } +} + +module.exports = Index; diff --git a/polkadot-wiki/pages/en/users.js b/polkadot-wiki/pages/en/users.js new file mode 100755 index 000000000000..9147c97ded69 --- /dev/null +++ b/polkadot-wiki/pages/en/users.js @@ -0,0 +1,48 @@ +/** + * Copyright (c) 2017-present, Facebook, Inc. + * + * This source code is licensed under the MIT license found in the + * LICENSE file in the root directory of this source tree. + */ + +const React = require("react"); + +const CompLibrary = require("../../core/CompLibrary.js"); + +const Container = CompLibrary.Container; + +class Users extends React.Component { + render() { + const { config: siteConfig } = this.props; + if ((siteConfig.users || []).length === 0) { + return null; + } + + const editUrl = `${siteConfig.repoUrl}/edit/master/website/siteConfig.js`; + const showcase = siteConfig.users.map((user) => ( + + {user.caption} + + )); + + return ( +
+ +
+
+

Who is Using This?

+

This project is used by many folks

+
+
{showcase}
+

Are you using this project?

+ + Add your company + +
+ +
+ ); + } +} + +module.exports = Users; diff --git a/website-v2/postprocess.js b/polkadot-wiki/postprocess.js similarity index 100% rename from website-v2/postprocess.js rename to polkadot-wiki/postprocess.js diff --git a/polkadot-wiki/sidebars.js b/polkadot-wiki/sidebars.js new file mode 100644 index 000000000000..3ebf4dcc949d --- /dev/null +++ b/polkadot-wiki/sidebars.js @@ -0,0 +1,196 @@ +module.exports = { + docs: [ + { + type: "category", + label: "General", + items: [ + "general/getting-started", + "general/claims", + "general/redenomination", + "general/grants", + "general/thousand-validators", + "general/ambassadors", + "general/research", + "general/community", + "general/contributing", + "general/contributors", + "general/glossary", + "general/ens", + "general/ledger", + "general/scams", + "general/how-to-dyor", + "general/faq", + ], + }, + { + type: "category", + label: "Learn", + items: [ + "learn/learn-launch", + { + type: "category", + label: "Basics", + items: [ + "learn/learn-architecture", + "learn/learn-accounts", + "learn/learn-account-generation", + "learn/learn-account-restore", + "learn/learn-DOT", + "learn/learn-security", + "learn/learn-consensus", + "learn/learn-nominator", + "learn/learn-validator", + "learn/learn-collator", + "learn/learn-governance", + "learn/learn-identity", + "learn/learn-balance-transfers", + "learn/learn-transaction-fees", + "learn/learn-polkadot-host", + "learn/learn-treasury", + "learn/learn-registrar", + "learn/learn-runtime-upgrades", + ], + }, + { + type: "category", + label: "Parachains", + items: [ + "learn/learn-parachains", + "learn/learn-parathreads", + "learn/learn-bridges", + "learn/learn-common-goods", + "learn/learn-auction", + "learn/learn-crowdloans", + "learn/learn-teleport", + ], + }, + { + type: "category", + label: "Advanced", + items: [ + "learn/learn-staking", + "learn/learn-proxies", + "learn/learn-availability", + "learn/learn-randomness", + "learn/learn-crosschain", + "learn/learn-spree", + "learn/learn-wasm", + "learn/learn-phragmen", + "learn/learn-simple-payouts", + ], + }, + { + type: "category", + label: "Cryptography", + items: ["learn/learn-cryptography", "learn/learn-keys"], + }, + { + type: "category", + label: "Polkadot Comparisons", + items: [ + "learn/learn-kusama-vs-polkadot", + "learn/learn-comparisons-ethereum-2", + "learn/learn-comparisons-cosmos", + "learn/learn-comparisons", + ], + }, + "learn/learn-video-tutorials", + ], + }, + { + type: "category", + label: "Build", + items: [ + "build/build-index", + { + type: "category", + label: "Development Guide", + items: [ + "build/build-build-with-polkadot", + "build/build-pdk", + "learn/learn-implementers-guide", + "build/build-cumulus", + "build/build-parachains-rococo", + "build/build-smart-contracts", + "build/build-oracle", + "build/build-ss58-registry", + "build/build-wallets", + ], + }, + { + type: "category", + label: "Integration Guide", + items: [ + "build/build-integration", + "build/build-protocol-info", + "build/build-integrate-assets", + "build/build-node-management", + "build/build-node-interaction", + "build/build-transaction-construction", + ], + }, + { + type: "category", + label: "Tools", + items: ["build/build-tools-index"], + }, + { + type: "category", + label: "Resources", + items: ["build/build-hackathon"], + }, + ], + }, + { + type: "category", + label: "Maintain", + items: [ + "maintain/maintain-index", + "maintain/maintain-polkadot-parameters", + { + type: "category", + label: "Nodes and Dapps", + items: [ + "maintain/maintain-sync", + "maintain/maintain-networks", + "maintain/maintain-wss", + "maintain/maintain-errors", + ], + }, + { + type: "category", + label: "Nominator Guides", + items: [ + "maintain/maintain-guides-how-to-nominate-polkadot", + "maintain/maintain-guides-how-to-unbond", + ], + }, + { + type: "category", + label: "Validator Guides", + items: [ + "maintain/maintain-guides-how-to-validate-polkadot", + "maintain/maintain-guides-validator-payout", + "maintain/maintain-guides-how-to-systemd", + "maintain/maintain-guides-secure-validator", + "maintain/maintain-guides-how-to-use-polkadot-validator-setup", + "maintain/maintain-guides-how-to-setup-a-validator-with-reverse-proxy", + "maintain/maintain-guides-how-to-upgrade", + "maintain/maintain-guides-how-to-monitor-your-node", + "maintain/maintain-guides-how-to-chill", + "maintain/maintain-guides-how-to-stop-validating", + ], + }, + { + type: "category", + label: "Governance Guides", + items: [ + "maintain/maintain-guides-democracy", + "maintain/maintain-guides-how-to-join-council", + "maintain/maintain-guides-how-to-vote-councillor", + ], + }, + ], + }, + ], +}; diff --git a/polkadot-wiki/src/pages/index.js b/polkadot-wiki/src/pages/index.js new file mode 100644 index 000000000000..0fb67b075658 --- /dev/null +++ b/polkadot-wiki/src/pages/index.js @@ -0,0 +1,237 @@ +/** + * Copyright (c) 2017-present, Facebook, Inc. + * + * This source code is licensed under the MIT license found in the + * LICENSE file in the root directory of this source tree. + */ + +import * as React from "react"; + +import Container from "react-bootstrap/Container"; +import Row from "react-bootstrap/Row"; +import Col from "react-bootstrap/Col"; +import Translate from "@docusaurus/Translate"; +import Layout from "@theme/Layout"; +import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; + +import KusamaCanary from "@site/static/img/kusama_canary_white.svg"; + +function HomeNav() { + const NavContainer = ({ children }) => ( +
+ + {children} + +
+ ); + + const NavItem = ({ href, aosDelay, children }) => ( + + +
{children}
+ + + ); + + const NavItemTitle = ({ children }) => ( +

+ {children} +

+ ); + + const NavItemContent = ({ children }) => ( +

{children}

+ ); + + return ( + + + + + Learn + + + + + Polkadot is a sharded protocol that enables blockchain networks to + operate together seamlessly. + + + + + + + Build + + + + + Most up-to-date information on the status of the development tools + in the Polkadot ecosystem. + + + + + + + Maintain + + + + + Information and guides on how to deploy a node and run the network. + + + + + ); +} + +function HomeFooter() { + const FooterContainer = ({ children }) => ( +
+ + {children} + +
+ ); + + const LearnKusama = () => ( + + +

+ + Learn about Polkadot’s canary network Kusama + +

+

+ + Kusama is Polkadot’s “canary network”, a scalable, multi-chain network + for radical innovation and early stage Polkadot deployments. For + developers, Kusama is a proving ground for all things Polkadot I.e + runtime upgrades, on-chain governance, parachains, parathreads, etc. + +

+ + + ); + + const ImproveWiki = () => ( + + + language + +

+ + Help improve this wiki + +

+

+ + This wiki was started by and is maintained by Web3 Foundation. It is + an open-source-ish project and aims to be the most extensive resource + of knowledge on Polkadot and the Polkadot ecosystem. + +

+ + + ); + + return ( + + + + + ); +} + +export default function Index() { + const { siteConfig } = useDocusaurusContext(); + + return ( + +
+ + +
+ + ); +} + +function useDocUrl(url) { + const { siteConfig } = useDocusaurusContext(); + const { baseUrl } = siteConfig; + const docsPart = "docs/"; + return `${baseUrl}${docsPart}${url}`; +} diff --git a/polkadot-wiki/src/theme/Footer.js b/polkadot-wiki/src/theme/Footer.js new file mode 100644 index 000000000000..aa9d90c8e694 --- /dev/null +++ b/polkadot-wiki/src/theme/Footer.js @@ -0,0 +1,340 @@ +import * as React from "react"; + +import Container from "react-bootstrap/Container"; +import Row from "react-bootstrap/Row"; +import Col from "react-bootstrap/Col"; +import Button from "react-bootstrap/Button"; +import Translate, { translate } from "@docusaurus/Translate"; +import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; + +import Logo from "@site/static/img/logo-polkadot-light.svg"; + +function FooterNavColumn({ headline, children }) { + return ( + +
{headline}
+
    {children}
+ + ); +} + +function FooterSocialColumn() { + const SocialItem = ({ href, className }) => { + return ( +
  • + + + +
    • + ); + }; + + const Social = () => ( +
      + + + + + +
    + ); + + const Newsletter = () => ( + <> +

    + + Subscribe to the newsletter to hear about Polkadot updates and events. + +

    + + + ); + + return ( + + + + + ); +} + +function FooterLegalLink({ href, content }) { + return ( +
  • + + {content} + +
    • + ); +} + +function FooterLink({ href, content }) { + return ( +
  • + + {content} + +
    • + ); +} + +export default function Footer() { + const { siteConfig } = useDocusaurusContext(); + const { footer } = siteConfig.themeConfig; + + return ( +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + {footer && ( + + + + + + )} + +
      + + + + + {/* TODO: FIX the replacement */} + +
    + +     +     +
    + ); +} diff --git a/website-v2/static/CNAME b/polkadot-wiki/static/CNAME similarity index 100% rename from website-v2/static/CNAME rename to polkadot-wiki/static/CNAME diff --git a/kusama-guide-v2/static/css/copycode.css b/polkadot-wiki/static/css/copycode.css similarity index 100% rename from kusama-guide-v2/static/css/copycode.css rename to polkadot-wiki/static/css/copycode.css diff --git a/polkadot-wiki/static/css/custom.css b/polkadot-wiki/static/css/custom.css new file mode 100755 index 000000000000..a12e609f39cc --- /dev/null +++ b/polkadot-wiki/static/css/custom.css @@ -0,0 +1,597 @@ +:root { + --ifm-color-primary: #e6007a; + --ifm-color-primary-dark: #cf006e; + --ifm-color-primary-darker: #c40068; + --ifm-color-primary-darkest: #a10055; + --ifm-color-primary-light: #fd0086; + --ifm-color-primary-lighter: #ff0a8c; + --ifm-color-primary-lightest: #ff2c9c; + --secondaryColor: #172026; + --snowColor: #efefef; + --silverColor: #b7b8bb; + --nickelColor: #6d7278; + --blackColor: black; + --ifm-navbar-height: 50px; + --sansFontFamily: "Work Sans", sans-serif !important; + --docsearch-searchbox-background: white; + --docsearch-searchbox-shadow: var(--snowColor); + + --custom-code-block-background: #f6f8fa; + --custom-content-max-width: 1400px; +} + +body { + font-family: var(--sansFontFamily); +} + +/* ========================================================================== + Typography + ========================================================================== */ + +.h1, +.h2, +.h3, +.h4, +.h5, +.h6 { + margin-top: 0; +} + +/* ========================================================================== + General components + ========================================================================== */ + +/* Back to top button */ +#back-to-top { + left: 16px; + bottom: 26px; + background-color: #ebedf0; + color: #1c1e21; + height: 48px; + width: 48px; +} + +#back-to-top svg { + margin-top: 12px; +} + +/* Sidebar menu button */ +button.menu__button { + box-shadow: 0 2px 5px 0 rgba(0, 0, 0, 0.26); +} + +/* ========================================================================== + Navigation bar + ========================================================================== */ + +.navbar.navbar--fixed-top { + height: auto; +} + +.navbar__inner { + max-width: var(--custom-content-max-width); + margin-left: auto; + margin-right: auto; +} + +.navbar__inner a.navbar__item svg[class^="iconExternalLink"] { + display: none; +} + +/* Contribute button */ +@media only screen and (min-width: 1024px) { + .navbar__inner a.navbar__item[href*="contributing"] { + background: white; + color: var(--ifm-color-primary); + border: solid 1px var(--ifm-color-primary); + border-radius: 20px; + + height: 35px; + padding: 0 16px; + margin-left: 16px; + line-height: 35px; + font-size: 14px; + font-weight: bold; + } + + .navbar__inner a.navbar__item[href*="contributing"]:hover { + background: var(--ifm-color-primary); + color: white; + } +} + +/* Search button */ +.DocSearch.DocSearch-Button { + background-color: white; + color: var(--silverColor); + border: 1px solid var(--snowColor); + width: 170px; + cursor: text; +} + +@media only screen and (max-width: 750px) { + .DocSearch.DocSearch-Button { + width: 38px; + } +} + +.DocSearch.DocSearch-Button .DocSearch-Search-Icon { + color: var(--silverColor); +} + +.DocSearch.DocSearch-Button:hover .DocSearch-Search-Icon { + color: var(--secondaryColor); +} + +.DocSearch.DocSearch-Button .DocSearch-Button-Placeholder { + font-weight: 500; + font-size: 13px; +} + +.DocSearch.DocSearch-Button .DocSearch-Button-Keys { + display: none; +} + +/* Languages button */ +.navbar__inner .navbar__item:last-child { + margin-left: 5px; + margin-right: 5px; + opacity: 1; +} + +.navbar__inner .navbar__item:last-child a::after { + display: none; +} + +.navbar__inner .navbar__item:last-child .dropdown__menu { + right: 0; + top: 32px; + box-shadow: 0 1rem 3rem rgba(0, 0, 0, 0.175); + border-radius: 1.5rem; + text-align: center; +} + +.navbar__inner .navbar__item:last-child .dropdown__menu > li a { + padding: 12px 24px; + color: var(--secondaryColor); +} + +.navbar__inner + .navbar__item:last-child + .dropdown__menu + > li + a.dropdown__link--active { + color: var(--blackColor); + background-color: white; +} + +.navbar__inner + .navbar__item:last-child + .dropdown__menu + > li + a.dropdown__link--active:hover { + color: var(--ifm-color-primary); +} + +.navbar__inner .navbar__item:last-child .dropdown__menu > li a:hover { + background-color: var(--snowColor); + color: var(--ifm-color-primary); +} + +/* ========================================================================== + Home + ========================================================================== */ + +.homeContainer { + background: white; + text-align: center; +} + +.homeContainer a { + text-decoration: none; +} + +.text-dark { + color: var(--secondaryColor) !important; +} + +.homeNavContainer { + padding: 3rem 0; +} + +.homeNavItem { + -webkit-transition: all 0.15s ease-in-out; + transition: all 0.15s ease-in-out; + padding: 3rem 0; + border-radius: 3.25rem !important; +} + +.homeNavItem p { + max-width: 300px; +} + +@media (min-width: 992px) { + .homeNavContainer { + height: 90vh; + min-height: 600px; + max-height: 900px; + } + + .homeNavItem { + -webkit-transition: all 0.15s ease-in-out; + transition: all 0.15s ease-in-out; + height: 60vh; + max-height: 500px; + border-radius: 3.25rem !important; + margin-top: -3rem; + } + + .homeNavItem::after { + font-size: 1.5rem; + font-family: "Material Icons"; + content: "arrow_upward"; + -webkit-font-feature-settings: "liga"; + position: absolute; + left: 50%; + bottom: 3rem; + color: var(--silverColor); + opacity: 0; + -webkit-transform: translate(-50%, 0); + transform: translate(-50%, 0); + -webkit-transition: all 0.2s ease-in-out; + transition: all 0.2s ease-in-out; + } + + .homeNavItem:hover { + box-shadow: 0 1rem 3rem rgba(0, 0, 0, 0.04); + transform: translateY(-1rem); + } + + .homeNavItem:hover::after { + opacity: 1; + } + + .homeNavItem h2 { + font-size: 3.5rem; + font-weight: 400; + line-height: 1.2; + } +} + +@media (min-width: 1200px) { + .homeNavItem h2 { + font-size: 4.5rem; + font-weight: 400; + line-height: 1.2; + } +} + +/* ========================================================================== + Home Footer + ========================================================================== */ + +.homeFooterContainer { + padding: 6rem 0 4rem; + background-image: linear-gradient( + 217deg, + rgba(196, 0, 97, 0.8), + rgba(196, 0, 97, 0) 70% + ), + linear-gradient(127deg, rgba(230, 0, 122, 0.8), rgba(230, 0, 122, 0) 70%), + linear-gradient(336deg, rgba(103, 69, 210, 0.7), rgba(103, 69, 210, 0) 70%); + background-color: #e6007a; +} + +.homeFooterContainer .col-lg-6 { + display: flex; + flex-flow: column nowrap; + align-items: flex-start; + margin-bottom: 2rem; +} + +.homeFooterContainer .col-lg-6 > *:first-child { + margin-bottom: 1.3rem; +} + +.homeFooterContainer p { + margin-bottom: 2.5rem; +} + +/* ========================================================================== + Doc pages + ========================================================================== */ + +.docs-wrapper { + max-width: var(--custom-content-max-width); + margin: 0 auto; + padding-bottom: 80px; +} + +article blockquote { + background-color: rgba(255, 229, 100, 0.3); + border-left: 8px solid #ffe564; +} + +article img, +article iframe { + display: block; + margin-left: auto; + margin-right: auto; + max-width: 100%; +} + +/* two following style is a workaround to prevent the code blocks expand in mobile */ + +.prism-code { + background-color: var(--custom-code-block-background) !important; +} + +.prism-code > div { + width: 100px !important; +} + +/* Table of content */ +.table-of-contents__link:hover, +.table-of-contents__link:hover code, +.table-of-contents__link--active, +.table-of-contents__link--active code { + font-weight: 600; +} + +/* + Button + ========================================================================== */ + +.btn { + font-weight: 700; + border-radius: 1.5rem; + font-size: 16px; + padding: 8px 16px; +} +.btn:before { + width: 42px; + left: -42px; + border-radius: 1.5rem; +} +.btn-lg, +.btn-group-lg > .btn { + border-radius: 2rem; + padding: 16px 20px; +} +.btn-lg:before, +.btn-group-lg > .btn:before { + width: 58px; + left: -58px; + border-radius: 2rem; +} +.btn-sm, +.btn-group-sm > .btn { + border-radius: 1.5rem; + font-size: 16px; + padding: 8px 16px; +} +.btn-sm:before, +.btn-group-sm > .btn:before { + width: 42px; + left: -42px; + border-radius: 1.5rem; +} +.btn-primary { + color: var(--ifm-color-primary); + background-color: transparent; + border-color: var(--ifm-color-primary); + position: relative; + z-index: 1; + overflow: hidden; + border: solid 1px var(--ifm-color-primary); + transition: all 0.2s ease, border 1ms ease; + will-change: transform; + transform: scale(0.999); +} +.btn-primary:before { + content: ""; + height: 100%; + position: absolute; + top: 0; + background: var(--ifm-color-primary); + transition: all 0.2s ease; + will-change: transform; + color: transparent; + z-index: -1; + border: solid 1px var(--ifm-color-primary); +} +.btn-primary:hover, +.btn-primary:focus, +.btn-primary:active { + background: none; + color: white; + will-change: transform; + transform: scale(1.05); + border: solid 1px transparent; +} +.btn-primary:focus, +.btn-primary.focus { + box-shadow: 0 0 0.2rem 0.2rem rgba(0, 0, 0, 0.1); +} +.btn-primary:not(:disabled):not(.disabled):active { + background-color: transparent; +} +.btn-primary[type="submit"]:hover, +.btn-primary[type="submit"]:focus, +.btn-primary[type="submit"]:active { + background: var(--ifm-color-primary); +} +.btn-primary:hover:before, +.btn-primary:focus:before, +.btn-primary:active:before { + left: 0; + width: 100%; +} +.btn-bg-primary.btn-primary { + color: white !important; + border: solid 1px white; +} +.btn-bg-primary.btn-primary:hover, +.btn-bg-primary.btn-primary:focus, +.btn-bg-primary.btn-primary:active { + background: white; + color: var(--ifm-color-primary) !important; +} +.btn-bg-primary.btn-primary:before { + content: none; + height: 100%; + position: absolute; + top: 0; + background: white; + transition: all 0.2s ease; + will-change: transform; + color: transparent; + z-index: -1; + border: solid 1px white; +} +.btn-white { + color: white !important; +} + +/* ========================================================================== + Bootstrap fix + ========================================================================== */ + +.nav-footer.spacer-y-4 { + padding-top: 3rem; + padding-bottom: 3rem; +} + +.nav-footer.pb-4 { + padding-bottom: 2.25rem !important; +} + +.nav-footer .text-small { + font-size: 0.875rem; +} + +@media (min-width: 768px) { + .nav-footer.spacer-y-4 { + padding-top: 6rem; + padding-bottom: 6rem; + } + + .nav-footer .py-md-1 { + padding-bottom: 0.375rem !important; + padding-top: 0.375rem !important; + } +} + +/* ========================================================================== + Footer + ========================================================================== */ + +.nav-footer { + background: var(--secondaryColor); + border: none; + color: #202020; + font-size: 16px; + line-height: 24px; + position: relative; +} + +/* + Footer Nav + ========================================================================== */ + +.nav-footer h5 { + font-size: 1.25rem; + font-weight: 400; + letter-spacing: -0.04em; + margin-top: 0; +} + +.nav-footer a:hover { + text-decoration: none; +} + +.nav-footer a.text-white { + color: var(--silverColor) !important; +} + +.nav-footer a.text-white:visited { + color: var(--silverColor) !important; +} + +.nav-footer a.text-white:hover { + color: white !important; +} + +/* + Footer Social + ========================================================================== */ + +.list-social-links { + padding: 0; + list-style: none; + display: flex; +} + +footer .list-social-links i { + font-size: 1.2rem; +} + +footer .list-social-links a { + padding: 0.25rem 0.9rem; + text-decoration: none; +} + +footer [class^="socicon-"] { + line-height: 2; +} + +footer .list-social-links { + margin-left: 0; +} +footer .list-social-links li { + margin-top: 0 !important; +} + +footer .list-social-links a { + background: transparent !important; + border: 1px solid white; + color: white; + padding: 0.25rem 0.9rem; + display: block; + border-radius: 50%; +} + +/* + Footer Legal + ========================================================================== */ + +.footer-legal .navbar-brand { + display: block; + padding-bottom: 0; +} + +.footer-legal ul { + margin-bottom: 0; +} + +.footer-legal li + li { + margin-top: 0; +} + +.footer-legal .list-pipe-separator > li:not(:last-child) > a:after { + content: "|"; + margin: 0 0.375rem; + opacity: 0.5; +} + +.footer-legal a.text-white { + color: #b5aeae !important; +} + +.footer-legal a.text-white:visited { + color: #b5aeae !important; +} + +.footer-legal a.text-white:hover { + color: #fff !important; +} diff --git a/website-v2/static/css/socicon.css b/polkadot-wiki/static/css/socicon.css similarity index 100% rename from website-v2/static/css/socicon.css rename to polkadot-wiki/static/css/socicon.css diff --git a/website-v2/static/fonts/Socicon.eot b/polkadot-wiki/static/fonts/Socicon.eot similarity index 100% rename from website-v2/static/fonts/Socicon.eot rename to polkadot-wiki/static/fonts/Socicon.eot diff --git a/website-v2/static/fonts/Socicon.svg b/polkadot-wiki/static/fonts/Socicon.svg similarity index 100% rename from website-v2/static/fonts/Socicon.svg rename to polkadot-wiki/static/fonts/Socicon.svg diff --git a/website-v2/static/fonts/Socicon.ttf b/polkadot-wiki/static/fonts/Socicon.ttf similarity index 100% rename from website-v2/static/fonts/Socicon.ttf rename to polkadot-wiki/static/fonts/Socicon.ttf diff --git a/website-v2/static/fonts/Socicon.woff b/polkadot-wiki/static/fonts/Socicon.woff similarity index 100% rename from website-v2/static/fonts/Socicon.woff rename to polkadot-wiki/static/fonts/Socicon.woff diff --git a/website-v2/static/fonts/Socicon.woff2 b/polkadot-wiki/static/fonts/Socicon.woff2 similarity index 100% rename from website-v2/static/fonts/Socicon.woff2 rename to polkadot-wiki/static/fonts/Socicon.woff2 diff --git a/kusama-guide/static/img/PRE.png b/polkadot-wiki/static/img/PRE.png similarity index 100% rename from kusama-guide/static/img/PRE.png rename to polkadot-wiki/static/img/PRE.png diff --git a/kusama-guide/static/img/Polkadot_Logotype_color.png b/polkadot-wiki/static/img/Polkadot_Logotype_color.png similarity index 100% rename from kusama-guide/static/img/Polkadot_Logotype_color.png rename to polkadot-wiki/static/img/Polkadot_Logotype_color.png diff --git a/kusama-guide/static/img/Polkadot_Logotype_white.png b/polkadot-wiki/static/img/Polkadot_Logotype_white.png similarity index 100% rename from kusama-guide/static/img/Polkadot_Logotype_white.png rename to polkadot-wiki/static/img/Polkadot_Logotype_white.png diff --git a/kusama-guide/static/img/Polkadot_logotype_color.svg b/polkadot-wiki/static/img/Polkadot_logotype_color.svg similarity index 100% rename from kusama-guide/static/img/Polkadot_logotype_color.svg rename to polkadot-wiki/static/img/Polkadot_logotype_color.svg diff --git a/kusama-guide/static/img/Polkadot_symbol_color.png b/polkadot-wiki/static/img/Polkadot_symbol_color.png similarity index 100% rename from kusama-guide/static/img/Polkadot_symbol_color.png rename to polkadot-wiki/static/img/Polkadot_symbol_color.png diff --git a/kusama-guide/static/img/Polkadot_symbol_white.svg b/polkadot-wiki/static/img/Polkadot_symbol_white.svg similarity index 100% rename from kusama-guide/static/img/Polkadot_symbol_white.svg rename to polkadot-wiki/static/img/Polkadot_symbol_white.svg diff --git a/kusama-guide-v2/static/img/favicon.ico b/polkadot-wiki/static/img/favicon.ico similarity index 100% rename from kusama-guide-v2/static/img/favicon.ico rename to polkadot-wiki/static/img/favicon.ico diff --git a/kusama-guide-v2/static/img/icon_collator.svg b/polkadot-wiki/static/img/icon_collator.svg similarity index 100% rename from kusama-guide-v2/static/img/icon_collator.svg rename to polkadot-wiki/static/img/icon_collator.svg diff --git a/website-v2/static/img/kusama_canary_white.svg b/polkadot-wiki/static/img/kusama_canary_white.svg similarity index 100% rename from website-v2/static/img/kusama_canary_white.svg rename to polkadot-wiki/static/img/kusama_canary_white.svg diff --git a/website-v2/static/img/logo-polkadot-light.svg b/polkadot-wiki/static/img/logo-polkadot-light.svg similarity index 100% rename from website-v2/static/img/logo-polkadot-light.svg rename to polkadot-wiki/static/img/logo-polkadot-light.svg diff --git a/kusama-guide/static/img/logo.svg b/polkadot-wiki/static/img/logo.svg similarity index 100% rename from kusama-guide/static/img/logo.svg rename to polkadot-wiki/static/img/logo.svg diff --git a/website-v2/static/img/logo_polkadot_wiki.svg b/polkadot-wiki/static/img/logo_polkadot_wiki.svg similarity index 100% rename from website-v2/static/img/logo_polkadot_wiki.svg rename to polkadot-wiki/static/img/logo_polkadot_wiki.svg diff --git a/kusama-guide/static/img/parachain-roadmap.jpg b/polkadot-wiki/static/img/parachain-roadmap.jpg similarity index 100% rename from kusama-guide/static/img/parachain-roadmap.jpg rename to polkadot-wiki/static/img/parachain-roadmap.jpg diff --git a/kusama-guide/static/img/polkadot-wechat.jpg b/polkadot-wiki/static/img/polkadot-wechat.jpg similarity index 100% rename from kusama-guide/static/img/polkadot-wechat.jpg rename to polkadot-wiki/static/img/polkadot-wechat.jpg diff --git a/kusama-guide/static/img/polkadot_overview.svg b/polkadot-wiki/static/img/polkadot_overview.svg similarity index 100% rename from kusama-guide/static/img/polkadot_overview.svg rename to polkadot-wiki/static/img/polkadot_overview.svg diff --git a/kusama-guide/static/img/polkadot_ui_1.png b/polkadot-wiki/static/img/polkadot_ui_1.png similarity index 100% rename from kusama-guide/static/img/polkadot_ui_1.png rename to polkadot-wiki/static/img/polkadot_ui_1.png diff --git a/kusama-guide/static/img/polkadot_ui_2.png b/polkadot-wiki/static/img/polkadot_ui_2.png similarity index 100% rename from kusama-guide/static/img/polkadot_ui_2.png rename to polkadot-wiki/static/img/polkadot_ui_2.png diff --git a/kusama-guide/static/img/polkadot_ui_3.png b/polkadot-wiki/static/img/polkadot_ui_3.png similarity index 100% rename from kusama-guide/static/img/polkadot_ui_3.png rename to polkadot-wiki/static/img/polkadot_ui_3.png diff --git a/kusama-guide/static/img/spree.jpg b/polkadot-wiki/static/img/spree.jpg similarity index 100% rename from kusama-guide/static/img/spree.jpg rename to polkadot-wiki/static/img/spree.jpg diff --git a/website-v2/static/js/addressChanger.js b/polkadot-wiki/static/js/addressChanger.js similarity index 100% rename from website-v2/static/js/addressChanger.js rename to polkadot-wiki/static/js/addressChanger.js diff --git a/polkadot-wiki/static/js/clipboard.min.js b/polkadot-wiki/static/js/clipboard.min.js new file mode 100644 index 000000000000..e09a1daf18d5 --- /dev/null +++ b/polkadot-wiki/static/js/clipboard.min.js @@ -0,0 +1,614 @@ +/*! + * clipboard.js v2.0.6 + * https://clipboardjs.com/ + * + * Licensed MIT © Zeno Rocha + */ +!(function (t, e) { + "object" == typeof exports && "object" == typeof module + ? (module.exports = e()) + : "function" == typeof define && define.amd + ? define([], e) + : "object" == typeof exports + ? (exports.ClipboardJS = e()) + : (t.ClipboardJS = e()); +})(this, function () { + return ( + (o = {}), + (r.m = n = + [ + function (t, e) { + t.exports = function (t) { + var e; + if ("SELECT" === t.nodeName) t.focus(), (e = t.value); + else if ("INPUT" === t.nodeName || "TEXTAREA" === t.nodeName) { + var n = t.hasAttribute("readonly"); + n || t.setAttribute("readonly", ""), + t.select(), + t.setSelectionRange(0, t.value.length), + n || t.removeAttribute("readonly"), + (e = t.value); + } else { + t.hasAttribute("contenteditable") && t.focus(); + var o = window.getSelection(), + r = document.createRange(); + r.selectNodeContents(t), + o.removeAllRanges(), + o.addRange(r), + (e = o.toString()); + } + return e; + }; + }, + function (t, e) { + function n() {} + (n.prototype = { + on: function (t, e, n) { + var o = this.e || (this.e = {}); + return (o[t] || (o[t] = [])).push({ fn: e, ctx: n }), this; + }, + once: function (t, e, n) { + var o = this; + function r() { + o.off(t, r), e.apply(n, arguments); + } + return (r._ = e), this.on(t, r, n); + }, + emit: function (t) { + for ( + var e = [].slice.call(arguments, 1), + n = ((this.e || (this.e = {}))[t] || []).slice(), + o = 0, + r = n.length; + o < r; + o++ + ) + n[o].fn.apply(n[o].ctx, e); + return this; + }, + off: function (t, e) { + var n = this.e || (this.e = {}), + o = n[t], + r = []; + if (o && e) + for (var i = 0, a = o.length; i < a; i++) + o[i].fn !== e && o[i].fn._ !== e && r.push(o[i]); + return r.length ? (n[t] = r) : delete n[t], this; + }, + }), + (t.exports = n), + (t.exports.TinyEmitter = n); + }, + function (t, e, n) { + var d = n(3), + h = n(4); + t.exports = function (t, e, n) { + if (!t && !e && !n) throw new Error("Missing required arguments"); + if (!d.string(e)) + throw new TypeError("Second argument must be a String"); + if (!d.fn(n)) + throw new TypeError("Third argument must be a Function"); + if (d.node(t)) + return ( + (s = e), + (f = n), + (u = t).addEventListener(s, f), + { + destroy: function () { + u.removeEventListener(s, f); + }, + } + ); + if (d.nodeList(t)) + return ( + (a = t), + (c = e), + (l = n), + Array.prototype.forEach.call(a, function (t) { + t.addEventListener(c, l); + }), + { + destroy: function () { + Array.prototype.forEach.call(a, function (t) { + t.removeEventListener(c, l); + }); + }, + } + ); + if (d.string(t)) + return (o = t), (r = e), (i = n), h(document.body, o, r, i); + throw new TypeError( + "First argument must be a String, HTMLElement, HTMLCollection, or NodeList" + ); + var o, r, i, a, c, l, u, s, f; + }; + }, + function (t, n) { + (n.node = function (t) { + return void 0 !== t && t instanceof HTMLElement && 1 === t.nodeType; + }), + (n.nodeList = function (t) { + var e = Object.prototype.toString.call(t); + return ( + void 0 !== t && + ("[object NodeList]" === e || + "[object HTMLCollection]" === e) && + "length" in t && + (0 === t.length || n.node(t[0])) + ); + }), + (n.string = function (t) { + return "string" == typeof t || t instanceof String; + }), + (n.fn = function (t) { + return "[object Function]" === Object.prototype.toString.call(t); + }); + }, + function (t, e, n) { + var a = n(5); + function i(t, e, n, o, r) { + var i = function (e, n, t, o) { + return function (t) { + (t.delegateTarget = a(t.target, n)), + t.delegateTarget && o.call(e, t); + }; + }.apply(this, arguments); + return ( + t.addEventListener(n, i, r), + { + destroy: function () { + t.removeEventListener(n, i, r); + }, + } + ); + } + t.exports = function (t, e, n, o, r) { + return "function" == typeof t.addEventListener + ? i.apply(null, arguments) + : "function" == typeof n + ? i.bind(null, document).apply(null, arguments) + : ("string" == typeof t && (t = document.querySelectorAll(t)), + Array.prototype.map.call(t, function (t) { + return i(t, e, n, o, r); + })); + }; + }, + function (t, e) { + if ("undefined" != typeof Element && !Element.prototype.matches) { + var n = Element.prototype; + n.matches = + n.matchesSelector || + n.mozMatchesSelector || + n.msMatchesSelector || + n.oMatchesSelector || + n.webkitMatchesSelector; + } + t.exports = function (t, e) { + for (; t && 9 !== t.nodeType; ) { + if ("function" == typeof t.matches && t.matches(e)) return t; + t = t.parentNode; + } + }; + }, + function (t, e, n) { + "use strict"; + n.r(e); + var o = n(0), + r = n.n(o), + i = + "function" == typeof Symbol && "symbol" == typeof Symbol.iterator + ? function (t) { + return typeof t; + } + : function (t) { + return t && + "function" == typeof Symbol && + t.constructor === Symbol && + t !== Symbol.prototype + ? "symbol" + : typeof t; + }; + function a(t, e) { + for (var n = 0; n < e.length; n++) { + var o = e[n]; + (o.enumerable = o.enumerable || !1), + (o.configurable = !0), + "value" in o && (o.writable = !0), + Object.defineProperty(t, o.key, o); + } + } + function c(t) { + !(function (t, e) { + if (!(t instanceof e)) + throw new TypeError("Cannot call a class as a function"); + })(this, c), + this.resolveOptions(t), + this.initSelection(); + } + var l = + ((function (t, e, n) { + return e && a(t.prototype, e), n && a(t, n), t; + })(c, [ + { + key: "resolveOptions", + value: function (t) { + var e = 0 < arguments.length && void 0 !== t ? t : {}; + (this.action = e.action), + (this.container = e.container), + (this.emitter = e.emitter), + (this.target = e.target), + (this.text = e.text), + (this.trigger = e.trigger), + (this.selectedText = ""); + }, + }, + { + key: "initSelection", + value: function () { + this.text + ? this.selectFake() + : this.target && this.selectTarget(); + }, + }, + { + key: "selectFake", + value: function () { + var t = this, + e = "rtl" == document.documentElement.getAttribute("dir"); + this.removeFake(), + (this.fakeHandlerCallback = function () { + return t.removeFake(); + }), + (this.fakeHandler = + this.container.addEventListener( + "click", + this.fakeHandlerCallback + ) || !0), + (this.fakeElem = document.createElement("textarea")), + (this.fakeElem.style.fontSize = "12pt"), + (this.fakeElem.style.border = "0"), + (this.fakeElem.style.padding = "0"), + (this.fakeElem.style.margin = "0"), + (this.fakeElem.style.position = "absolute"), + (this.fakeElem.style[e ? "right" : "left"] = "-9999px"); + var n = + window.pageYOffset || document.documentElement.scrollTop; + (this.fakeElem.style.top = n + "px"), + this.fakeElem.setAttribute("readonly", ""), + (this.fakeElem.value = this.text), + this.container.appendChild(this.fakeElem), + (this.selectedText = r()(this.fakeElem)), + this.copyText(); + }, + }, + { + key: "removeFake", + value: function () { + this.fakeHandler && + (this.container.removeEventListener( + "click", + this.fakeHandlerCallback + ), + (this.fakeHandler = null), + (this.fakeHandlerCallback = null)), + this.fakeElem && + (this.container.removeChild(this.fakeElem), + (this.fakeElem = null)); + }, + }, + { + key: "selectTarget", + value: function () { + (this.selectedText = r()(this.target)), this.copyText(); + }, + }, + { + key: "copyText", + value: function () { + var e = void 0; + try { + e = document.execCommand(this.action); + } catch (t) { + e = !1; + } + this.handleResult(e); + }, + }, + { + key: "handleResult", + value: function (t) { + this.emitter.emit(t ? "success" : "error", { + action: this.action, + text: this.selectedText, + trigger: this.trigger, + clearSelection: this.clearSelection.bind(this), + }); + }, + }, + { + key: "clearSelection", + value: function () { + this.trigger && this.trigger.focus(), + document.activeElement.blur(), + window.getSelection().removeAllRanges(); + }, + }, + { + key: "destroy", + value: function () { + this.removeFake(); + }, + }, + { + key: "action", + set: function (t) { + var e = 0 < arguments.length && void 0 !== t ? t : "copy"; + if ( + ((this._action = e), + "copy" !== this._action && "cut" !== this._action) + ) + throw new Error( + 'Invalid "action" value, use either "copy" or "cut"' + ); + }, + get: function () { + return this._action; + }, + }, + { + key: "target", + set: function (t) { + if (void 0 !== t) { + if ( + !t || + "object" !== (void 0 === t ? "undefined" : i(t)) || + 1 !== t.nodeType + ) + throw new Error( + 'Invalid "target" value, use a valid Element' + ); + if ("copy" === this.action && t.hasAttribute("disabled")) + throw new Error( + 'Invalid "target" attribute. Please use "readonly" instead of "disabled" attribute' + ); + if ( + "cut" === this.action && + (t.hasAttribute("readonly") || + t.hasAttribute("disabled")) + ) + throw new Error( + 'Invalid "target" attribute. You can\'t cut text from elements with "readonly" or "disabled" attributes' + ); + this._target = t; + } + }, + get: function () { + return this._target; + }, + }, + ]), + c), + u = n(1), + s = n.n(u), + f = n(2), + d = n.n(f), + h = + "function" == typeof Symbol && "symbol" == typeof Symbol.iterator + ? function (t) { + return typeof t; + } + : function (t) { + return t && + "function" == typeof Symbol && + t.constructor === Symbol && + t !== Symbol.prototype + ? "symbol" + : typeof t; + }, + p = function (t, e, n) { + return e && y(t.prototype, e), n && y(t, n), t; + }; + function y(t, e) { + for (var n = 0; n < e.length; n++) { + var o = e[n]; + (o.enumerable = o.enumerable || !1), + (o.configurable = !0), + "value" in o && (o.writable = !0), + Object.defineProperty(t, o.key, o); + } + } + var m = + ((function (t, e) { + if ("function" != typeof e && null !== e) + throw new TypeError( + "Super expression must either be null or a function, not " + + typeof e + ); + (t.prototype = Object.create(e && e.prototype, { + constructor: { + value: t, + enumerable: !1, + writable: !0, + configurable: !0, + }, + })), + e && + (Object.setPrototypeOf + ? Object.setPrototypeOf(t, e) + : (t.__proto__ = e)); + })(v, s.a), + p( + v, + [ + { + key: "resolveOptions", + value: function (t) { + var e = 0 < arguments.length && void 0 !== t ? t : {}; + (this.action = + "function" == typeof e.action + ? e.action + : this.defaultAction), + (this.target = + "function" == typeof e.target + ? e.target + : this.defaultTarget), + (this.text = + "function" == typeof e.text + ? e.text + : this.defaultText), + (this.container = + "object" === h(e.container) + ? e.container + : document.body); + }, + }, + { + key: "listenClick", + value: function (t) { + var e = this; + this.listener = d()(t, "click", function (t) { + return e.onClick(t); + }); + }, + }, + { + key: "onClick", + value: function (t) { + var e = t.delegateTarget || t.currentTarget; + this.clipboardAction && (this.clipboardAction = null), + (this.clipboardAction = new l({ + action: this.action(e), + target: this.target(e), + text: this.text(e), + container: this.container, + trigger: e, + emitter: this, + })); + }, + }, + { + key: "defaultAction", + value: function (t) { + return b("action", t); + }, + }, + { + key: "defaultTarget", + value: function (t) { + var e = b("target", t); + if (e) return document.querySelector(e); + }, + }, + { + key: "defaultText", + value: function (t) { + return b("text", t); + }, + }, + { + key: "destroy", + value: function () { + this.listener.destroy(), + this.clipboardAction && + (this.clipboardAction.destroy(), + (this.clipboardAction = null)); + }, + }, + ], + [ + { + key: "isSupported", + value: function (t) { + var e = + 0 < arguments.length && void 0 !== t + ? t + : ["copy", "cut"], + n = "string" == typeof e ? [e] : e, + o = !!document.queryCommandSupported; + return ( + n.forEach(function (t) { + o = o && !!document.queryCommandSupported(t); + }), + o + ); + }, + }, + ] + ), + v); + function v(t, e) { + !(function (t, e) { + if (!(t instanceof e)) + throw new TypeError("Cannot call a class as a function"); + })(this, v); + var n = (function (t, e) { + if (!t) + throw new ReferenceError( + "this hasn't been initialised - super() hasn't been called" + ); + return !e || ("object" != typeof e && "function" != typeof e) + ? t + : e; + })(this, (v.__proto__ || Object.getPrototypeOf(v)).call(this)); + return n.resolveOptions(e), n.listenClick(t), n; + } + function b(t, e) { + var n = "data-clipboard-" + t; + if (e.hasAttribute(n)) return e.getAttribute(n); + } + e.default = m; + }, + ]), + (r.c = o), + (r.d = function (t, e, n) { + r.o(t, e) || Object.defineProperty(t, e, { enumerable: !0, get: n }); + }), + (r.r = function (t) { + "undefined" != typeof Symbol && + Symbol.toStringTag && + Object.defineProperty(t, Symbol.toStringTag, { value: "Module" }), + Object.defineProperty(t, "__esModule", { value: !0 }); + }), + (r.t = function (e, t) { + if ((1 & t && (e = r(e)), 8 & t)) return e; + if (4 & t && "object" == typeof e && e && e.__esModule) return e; + var n = Object.create(null); + if ( + (r.r(n), + Object.defineProperty(n, "default", { enumerable: !0, value: e }), + 2 & t && "string" != typeof e) + ) + for (var o in e) + r.d( + n, + o, + function (t) { + return e[t]; + }.bind(null, o) + ); + return n; + }), + (r.n = function (t) { + var e = + t && t.__esModule + ? function () { + return t.default; + } + : function () { + return t; + }; + return r.d(e, "a", e), e; + }), + (r.o = function (t, e) { + return Object.prototype.hasOwnProperty.call(t, e); + }), + (r.p = ""), + r((r.s = 6)).default + ); + function r(t) { + if (o[t]) return o[t].exports; + var e = (o[t] = { i: t, l: !1, exports: {} }); + return n[t].call(e.exports, e, e.exports, r), (e.l = !0), e.exports; + } + var n, o; +}); diff --git a/polkadot-wiki/static/js/copycode.js b/polkadot-wiki/static/js/copycode.js new file mode 100644 index 000000000000..0279288ca263 --- /dev/null +++ b/polkadot-wiki/static/js/copycode.js @@ -0,0 +1,47 @@ +// Turn off ESLint for this file because it's sent down to users as-is. +/* eslint-disable */ +window.addEventListener("load", function () { + function button(label, ariaLabel, icon, className) { + const btn = document.createElement("button"); + btn.classList.add("btnIcon", className); + btn.setAttribute("type", "button"); + btn.setAttribute("aria-label", ariaLabel); + btn.innerHTML = + '
    ' + + icon + + '' + + label + + "" + + "
    "; + return btn; + } + + function addButtons(codeBlockSelector, btn) { + document.querySelectorAll(codeBlockSelector).forEach(function (code) { + code.parentNode.appendChild(btn.cloneNode(true)); + }); + } + + const copyIcon = + ''; + + addButtons( + ".hljs", + button("Copy", "Copy code to clipboard", copyIcon, "btnClipboard") + ); + + const clipboard = new ClipboardJS(".btnClipboard", { + target: function (trigger) { + return trigger.parentNode.querySelector("code"); + }, + }); + + clipboard.on("success", function (event) { + event.clearSelection(); + const textEl = event.trigger.querySelector(".btnIcon__label"); + textEl.textContent = "Copied"; + setTimeout(function () { + textEl.textContent = "Copy"; + }, 2000); + }); +}); diff --git a/website-v2/static/js/custom.js b/polkadot-wiki/static/js/custom.js similarity index 100% rename from website-v2/static/js/custom.js rename to polkadot-wiki/static/js/custom.js diff --git a/polkadot-wiki/static/js/packaged/addressChanger.js b/polkadot-wiki/static/js/packaged/addressChanger.js new file mode 100644 index 000000000000..cf68518c73c3 --- /dev/null +++ b/polkadot-wiki/static/js/packaged/addressChanger.js @@ -0,0 +1,29534 @@ +!(function () { + return function A(e, t, i) { + function g(n, B) { + if (!t[n]) { + if (!e[n]) { + var I = "function" == typeof require && require; + if (!B && I) return I(n, !0); + if (r) return r(n, !0); + var o = new Error("Cannot find module '" + n + "'"); + throw ((o.code = "MODULE_NOT_FOUND"), o); + } + var a = (t[n] = { exports: {} }); + e[n][0].call( + a.exports, + function (A) { + return g(e[n][1][A] || A); + }, + a, + a.exports, + A, + e, + t, + i + ); + } + return t[n].exports; + } + for ( + var r = "function" == typeof require && require, n = 0; + n < i.length; + n++ + ) + g(i[n]); + return g; + }; +})()( + { + 1: [ + function (A, e, t) { + "use strict"; + const i = t; + (i.bignum = A("bn.js")), + (i.define = A("./asn1/api").define), + (i.base = A("./asn1/base")), + (i.constants = A("./asn1/constants")), + (i.decoders = A("./asn1/decoders")), + (i.encoders = A("./asn1/encoders")); + }, + { + "./asn1/api": 2, + "./asn1/base": 4, + "./asn1/constants": 8, + "./asn1/decoders": 10, + "./asn1/encoders": 13, + "bn.js": 15, + }, + ], + 2: [ + function (A, e, t) { + "use strict"; + const i = A("./encoders"), + g = A("./decoders"), + r = A("inherits"); + function n(A, e) { + (this.name = A), + (this.body = e), + (this.decoders = {}), + (this.encoders = {}); + } + (t.define = function (A, e) { + return new n(A, e); + }), + (n.prototype._createNamed = function (A) { + const e = this.name; + function t(A) { + this._initNamed(A, e); + } + return ( + r(t, A), + (t.prototype._initNamed = function (e, t) { + A.call(this, e, t); + }), + new t(this) + ); + }), + (n.prototype._getDecoder = function (A) { + return ( + (A = A || "der"), + this.decoders.hasOwnProperty(A) || + (this.decoders[A] = this._createNamed(g[A])), + this.decoders[A] + ); + }), + (n.prototype.decode = function (A, e, t) { + return this._getDecoder(e).decode(A, t); + }), + (n.prototype._getEncoder = function (A) { + return ( + (A = A || "der"), + this.encoders.hasOwnProperty(A) || + (this.encoders[A] = this._createNamed(i[A])), + this.encoders[A] + ); + }), + (n.prototype.encode = function (A, e, t) { + return this._getEncoder(e).encode(A, t); + }); + }, + { "./decoders": 10, "./encoders": 13, inherits: 134 }, + ], + 3: [ + function (A, e, t) { + "use strict"; + const i = A("inherits"), + g = A("../base/reporter").Reporter, + r = A("safer-buffer").Buffer; + function n(A, e) { + g.call(this, e), + r.isBuffer(A) + ? ((this.base = A), (this.offset = 0), (this.length = A.length)) + : this.error("Input not Buffer"); + } + function B(A, e) { + if (Array.isArray(A)) + (this.length = 0), + (this.value = A.map(function (A) { + return ( + B.isEncoderBuffer(A) || (A = new B(A, e)), + (this.length += A.length), + A + ); + }, this)); + else if ("number" == typeof A) { + if (!(0 <= A && A <= 255)) + return e.error("non-byte EncoderBuffer value"); + (this.value = A), (this.length = 1); + } else if ("string" == typeof A) + (this.value = A), (this.length = r.byteLength(A)); + else { + if (!r.isBuffer(A)) return e.error("Unsupported type: " + typeof A); + (this.value = A), (this.length = A.length); + } + } + i(n, g), + (t.DecoderBuffer = n), + (n.isDecoderBuffer = function (A) { + if (A instanceof n) return !0; + return ( + "object" == typeof A && + r.isBuffer(A.base) && + "DecoderBuffer" === A.constructor.name && + "number" == typeof A.offset && + "number" == typeof A.length && + "function" == typeof A.save && + "function" == typeof A.restore && + "function" == typeof A.isEmpty && + "function" == typeof A.readUInt8 && + "function" == typeof A.skip && + "function" == typeof A.raw + ); + }), + (n.prototype.save = function () { + return { + offset: this.offset, + reporter: g.prototype.save.call(this), + }; + }), + (n.prototype.restore = function (A) { + const e = new n(this.base); + return ( + (e.offset = A.offset), + (e.length = this.offset), + (this.offset = A.offset), + g.prototype.restore.call(this, A.reporter), + e + ); + }), + (n.prototype.isEmpty = function () { + return this.offset === this.length; + }), + (n.prototype.readUInt8 = function (A) { + return this.offset + 1 <= this.length + ? this.base.readUInt8(this.offset++, !0) + : this.error(A || "DecoderBuffer overrun"); + }), + (n.prototype.skip = function (A, e) { + if (!(this.offset + A <= this.length)) + return this.error(e || "DecoderBuffer overrun"); + const t = new n(this.base); + return ( + (t._reporterState = this._reporterState), + (t.offset = this.offset), + (t.length = this.offset + A), + (this.offset += A), + t + ); + }), + (n.prototype.raw = function (A) { + return this.base.slice(A ? A.offset : this.offset, this.length); + }), + (t.EncoderBuffer = B), + (B.isEncoderBuffer = function (A) { + if (A instanceof B) return !0; + return ( + "object" == typeof A && + "EncoderBuffer" === A.constructor.name && + "number" == typeof A.length && + "function" == typeof A.join + ); + }), + (B.prototype.join = function (A, e) { + return ( + A || (A = r.alloc(this.length)), + e || (e = 0), + 0 === this.length + ? A + : (Array.isArray(this.value) + ? this.value.forEach(function (t) { + t.join(A, e), (e += t.length); + }) + : ("number" == typeof this.value + ? (A[e] = this.value) + : "string" == typeof this.value + ? A.write(this.value, e) + : r.isBuffer(this.value) && this.value.copy(A, e), + (e += this.length)), + A) + ); + }); + }, + { "../base/reporter": 6, inherits: 134, "safer-buffer": 181 }, + ], + 4: [ + function (A, e, t) { + "use strict"; + const i = t; + (i.Reporter = A("./reporter").Reporter), + (i.DecoderBuffer = A("./buffer").DecoderBuffer), + (i.EncoderBuffer = A("./buffer").EncoderBuffer), + (i.Node = A("./node")); + }, + { "./buffer": 3, "./node": 5, "./reporter": 6 }, + ], + 5: [ + function (A, e, t) { + "use strict"; + const i = A("../base/reporter").Reporter, + g = A("../base/buffer").EncoderBuffer, + r = A("../base/buffer").DecoderBuffer, + n = A("minimalistic-assert"), + B = [ + "seq", + "seqof", + "set", + "setof", + "objid", + "bool", + "gentime", + "utctime", + "null_", + "enum", + "int", + "objDesc", + "bitstr", + "bmpstr", + "charstr", + "genstr", + "graphstr", + "ia5str", + "iso646str", + "numstr", + "octstr", + "printstr", + "t61str", + "unistr", + "utf8str", + "videostr", + ], + I = [ + "key", + "obj", + "use", + "optional", + "explicit", + "implicit", + "def", + "choice", + "any", + "contains", + ].concat(B); + function o(A, e, t) { + const i = {}; + (this._baseState = i), + (i.name = t), + (i.enc = A), + (i.parent = e || null), + (i.children = null), + (i.tag = null), + (i.args = null), + (i.reverseArgs = null), + (i.choice = null), + (i.optional = !1), + (i.any = !1), + (i.obj = !1), + (i.use = null), + (i.useDecoder = null), + (i.key = null), + (i.default = null), + (i.explicit = null), + (i.implicit = null), + (i.contains = null), + i.parent || ((i.children = []), this._wrap()); + } + e.exports = o; + const a = [ + "enc", + "parent", + "children", + "tag", + "args", + "reverseArgs", + "choice", + "optional", + "any", + "obj", + "use", + "alteredUse", + "key", + "default", + "explicit", + "implicit", + "contains", + ]; + (o.prototype.clone = function () { + const A = this._baseState, + e = {}; + a.forEach(function (t) { + e[t] = A[t]; + }); + const t = new this.constructor(e.parent); + return (t._baseState = e), t; + }), + (o.prototype._wrap = function () { + const A = this._baseState; + I.forEach(function (e) { + this[e] = function () { + const t = new this.constructor(this); + return A.children.push(t), t[e].apply(t, arguments); + }; + }, this); + }), + (o.prototype._init = function (A) { + const e = this._baseState; + n(null === e.parent), + A.call(this), + (e.children = e.children.filter(function (A) { + return A._baseState.parent === this; + }, this)), + n.equal( + e.children.length, + 1, + "Root node can have only one child" + ); + }), + (o.prototype._useArgs = function (A) { + const e = this._baseState, + t = A.filter(function (A) { + return A instanceof this.constructor; + }, this); + (A = A.filter(function (A) { + return !(A instanceof this.constructor); + }, this)), + 0 !== t.length && + (n(null === e.children), + (e.children = t), + t.forEach(function (A) { + A._baseState.parent = this; + }, this)), + 0 !== A.length && + (n(null === e.args), + (e.args = A), + (e.reverseArgs = A.map(function (A) { + if ("object" != typeof A || A.constructor !== Object) + return A; + const e = {}; + return ( + Object.keys(A).forEach(function (t) { + t == (0 | t) && (t |= 0); + const i = A[t]; + e[i] = t; + }), + e + ); + }))); + }), + [ + "_peekTag", + "_decodeTag", + "_use", + "_decodeStr", + "_decodeObjid", + "_decodeTime", + "_decodeNull", + "_decodeInt", + "_decodeBool", + "_decodeList", + "_encodeComposite", + "_encodeStr", + "_encodeObjid", + "_encodeTime", + "_encodeNull", + "_encodeInt", + "_encodeBool", + ].forEach(function (A) { + o.prototype[A] = function () { + const e = this._baseState; + throw new Error(A + " not implemented for encoding: " + e.enc); + }; + }), + B.forEach(function (A) { + o.prototype[A] = function () { + const e = this._baseState, + t = Array.prototype.slice.call(arguments); + return n(null === e.tag), (e.tag = A), this._useArgs(t), this; + }; + }), + (o.prototype.use = function (A) { + n(A); + const e = this._baseState; + return n(null === e.use), (e.use = A), this; + }), + (o.prototype.optional = function () { + return (this._baseState.optional = !0), this; + }), + (o.prototype.def = function (A) { + const e = this._baseState; + return ( + n(null === e.default), (e.default = A), (e.optional = !0), this + ); + }), + (o.prototype.explicit = function (A) { + const e = this._baseState; + return ( + n(null === e.explicit && null === e.implicit), + (e.explicit = A), + this + ); + }), + (o.prototype.implicit = function (A) { + const e = this._baseState; + return ( + n(null === e.explicit && null === e.implicit), + (e.implicit = A), + this + ); + }), + (o.prototype.obj = function () { + const A = this._baseState, + e = Array.prototype.slice.call(arguments); + return (A.obj = !0), 0 !== e.length && this._useArgs(e), this; + }), + (o.prototype.key = function (A) { + const e = this._baseState; + return n(null === e.key), (e.key = A), this; + }), + (o.prototype.any = function () { + return (this._baseState.any = !0), this; + }), + (o.prototype.choice = function (A) { + const e = this._baseState; + return ( + n(null === e.choice), + (e.choice = A), + this._useArgs( + Object.keys(A).map(function (e) { + return A[e]; + }) + ), + this + ); + }), + (o.prototype.contains = function (A) { + const e = this._baseState; + return n(null === e.use), (e.contains = A), this; + }), + (o.prototype._decode = function (A, e) { + const t = this._baseState; + if (null === t.parent) + return A.wrapResult(t.children[0]._decode(A, e)); + let i, + g = t.default, + n = !0, + B = null; + if ((null !== t.key && (B = A.enterKey(t.key)), t.optional)) { + let i = null; + if ( + (null !== t.explicit + ? (i = t.explicit) + : null !== t.implicit + ? (i = t.implicit) + : null !== t.tag && (i = t.tag), + null !== i || t.any) + ) { + if (((n = this._peekTag(A, i, t.any)), A.isError(n))) return n; + } else { + const i = A.save(); + try { + null === t.choice + ? this._decodeGeneric(t.tag, A, e) + : this._decodeChoice(A, e), + (n = !0); + } catch (A) { + n = !1; + } + A.restore(i); + } + } + if ((t.obj && n && (i = A.enterObject()), n)) { + if (null !== t.explicit) { + const e = this._decodeTag(A, t.explicit); + if (A.isError(e)) return e; + A = e; + } + const i = A.offset; + if (null === t.use && null === t.choice) { + let e; + t.any && (e = A.save()); + const i = this._decodeTag( + A, + null !== t.implicit ? t.implicit : t.tag, + t.any + ); + if (A.isError(i)) return i; + t.any ? (g = A.raw(e)) : (A = i); + } + if ( + (e && + e.track && + null !== t.tag && + e.track(A.path(), i, A.length, "tagged"), + e && + e.track && + null !== t.tag && + e.track(A.path(), A.offset, A.length, "content"), + t.any || + (g = + null === t.choice + ? this._decodeGeneric(t.tag, A, e) + : this._decodeChoice(A, e)), + A.isError(g)) + ) + return g; + if ( + (t.any || + null !== t.choice || + null === t.children || + t.children.forEach(function (t) { + t._decode(A, e); + }), + t.contains && ("octstr" === t.tag || "bitstr" === t.tag)) + ) { + const i = new r(g); + g = this._getUse(t.contains, A._reporterState.obj)._decode( + i, + e + ); + } + } + return ( + t.obj && n && (g = A.leaveObject(i)), + null === t.key || (null === g && !0 !== n) + ? null !== B && A.exitKey(B) + : A.leaveKey(B, t.key, g), + g + ); + }), + (o.prototype._decodeGeneric = function (A, e, t) { + const i = this._baseState; + return "seq" === A || "set" === A + ? null + : "seqof" === A || "setof" === A + ? this._decodeList(e, A, i.args[0], t) + : /str$/.test(A) + ? this._decodeStr(e, A, t) + : "objid" === A && i.args + ? this._decodeObjid(e, i.args[0], i.args[1], t) + : "objid" === A + ? this._decodeObjid(e, null, null, t) + : "gentime" === A || "utctime" === A + ? this._decodeTime(e, A, t) + : "null_" === A + ? this._decodeNull(e, t) + : "bool" === A + ? this._decodeBool(e, t) + : "objDesc" === A + ? this._decodeStr(e, A, t) + : "int" === A || "enum" === A + ? this._decodeInt(e, i.args && i.args[0], t) + : null !== i.use + ? this._getUse(i.use, e._reporterState.obj)._decode(e, t) + : e.error("unknown tag: " + A); + }), + (o.prototype._getUse = function (A, e) { + const t = this._baseState; + return ( + (t.useDecoder = this._use(A, e)), + n(null === t.useDecoder._baseState.parent), + (t.useDecoder = t.useDecoder._baseState.children[0]), + t.implicit !== t.useDecoder._baseState.implicit && + ((t.useDecoder = t.useDecoder.clone()), + (t.useDecoder._baseState.implicit = t.implicit)), + t.useDecoder + ); + }), + (o.prototype._decodeChoice = function (A, e) { + const t = this._baseState; + let i = null, + g = !1; + return ( + Object.keys(t.choice).some(function (r) { + const n = A.save(), + B = t.choice[r]; + try { + const t = B._decode(A, e); + if (A.isError(t)) return !1; + (i = { type: r, value: t }), (g = !0); + } catch (e) { + return A.restore(n), !1; + } + return !0; + }, this), + g ? i : A.error("Choice not matched") + ); + }), + (o.prototype._createEncoderBuffer = function (A) { + return new g(A, this.reporter); + }), + (o.prototype._encode = function (A, e, t) { + const i = this._baseState; + if (null !== i.default && i.default === A) return; + const g = this._encodeValue(A, e, t); + return void 0 === g || this._skipDefault(g, e, t) ? void 0 : g; + }), + (o.prototype._encodeValue = function (A, e, t) { + const g = this._baseState; + if (null === g.parent) + return g.children[0]._encode(A, e || new i()); + let r = null; + if (((this.reporter = e), g.optional && void 0 === A)) { + if (null === g.default) return; + A = g.default; + } + let n = null, + B = !1; + if (g.any) r = this._createEncoderBuffer(A); + else if (g.choice) r = this._encodeChoice(A, e); + else if (g.contains) + (n = this._getUse(g.contains, t)._encode(A, e)), (B = !0); + else if (g.children) + (n = g.children + .map(function (t) { + if ("null_" === t._baseState.tag) + return t._encode(null, e, A); + if (null === t._baseState.key) + return e.error("Child should have a key"); + const i = e.enterKey(t._baseState.key); + if ("object" != typeof A) + return e.error("Child expected, but input is not object"); + const g = t._encode(A[t._baseState.key], e, A); + return e.leaveKey(i), g; + }, this) + .filter(function (A) { + return A; + })), + (n = this._createEncoderBuffer(n)); + else if ("seqof" === g.tag || "setof" === g.tag) { + if (!g.args || 1 !== g.args.length) + return e.error("Too many args for : " + g.tag); + if (!Array.isArray(A)) + return e.error("seqof/setof, but data is not Array"); + const t = this.clone(); + (t._baseState.implicit = null), + (n = this._createEncoderBuffer( + A.map(function (t) { + const i = this._baseState; + return this._getUse(i.args[0], A)._encode(t, e); + }, t) + )); + } else + null !== g.use + ? (r = this._getUse(g.use, t)._encode(A, e)) + : ((n = this._encodePrimitive(g.tag, A)), (B = !0)); + if (!g.any && null === g.choice) { + const A = null !== g.implicit ? g.implicit : g.tag, + t = null === g.implicit ? "universal" : "context"; + null === A + ? null === g.use && + e.error("Tag could be omitted only for .use()") + : null === g.use && (r = this._encodeComposite(A, B, t, n)); + } + return ( + null !== g.explicit && + (r = this._encodeComposite(g.explicit, !1, "context", r)), + r + ); + }), + (o.prototype._encodeChoice = function (A, e) { + const t = this._baseState, + i = t.choice[A.type]; + return ( + i || + n( + !1, + A.type + + " not found in " + + JSON.stringify(Object.keys(t.choice)) + ), + i._encode(A.value, e) + ); + }), + (o.prototype._encodePrimitive = function (A, e) { + const t = this._baseState; + if (/str$/.test(A)) return this._encodeStr(e, A); + if ("objid" === A && t.args) + return this._encodeObjid(e, t.reverseArgs[0], t.args[1]); + if ("objid" === A) return this._encodeObjid(e, null, null); + if ("gentime" === A || "utctime" === A) + return this._encodeTime(e, A); + if ("null_" === A) return this._encodeNull(); + if ("int" === A || "enum" === A) + return this._encodeInt(e, t.args && t.reverseArgs[0]); + if ("bool" === A) return this._encodeBool(e); + if ("objDesc" === A) return this._encodeStr(e, A); + throw new Error("Unsupported tag: " + A); + }), + (o.prototype._isNumstr = function (A) { + return /^[0-9 ]*$/.test(A); + }), + (o.prototype._isPrintstr = function (A) { + return /^[A-Za-z0-9 '()+,-./:=?]*$/.test(A); + }); + }, + { + "../base/buffer": 3, + "../base/reporter": 6, + "minimalistic-assert": 140, + }, + ], + 6: [ + function (A, e, t) { + "use strict"; + const i = A("inherits"); + function g(A) { + this._reporterState = { + obj: null, + path: [], + options: A || {}, + errors: [], + }; + } + function r(A, e) { + (this.path = A), this.rethrow(e); + } + (t.Reporter = g), + (g.prototype.isError = function (A) { + return A instanceof r; + }), + (g.prototype.save = function () { + const A = this._reporterState; + return { obj: A.obj, pathLen: A.path.length }; + }), + (g.prototype.restore = function (A) { + const e = this._reporterState; + (e.obj = A.obj), (e.path = e.path.slice(0, A.pathLen)); + }), + (g.prototype.enterKey = function (A) { + return this._reporterState.path.push(A); + }), + (g.prototype.exitKey = function (A) { + const e = this._reporterState; + e.path = e.path.slice(0, A - 1); + }), + (g.prototype.leaveKey = function (A, e, t) { + const i = this._reporterState; + this.exitKey(A), null !== i.obj && (i.obj[e] = t); + }), + (g.prototype.path = function () { + return this._reporterState.path.join("/"); + }), + (g.prototype.enterObject = function () { + const A = this._reporterState, + e = A.obj; + return (A.obj = {}), e; + }), + (g.prototype.leaveObject = function (A) { + const e = this._reporterState, + t = e.obj; + return (e.obj = A), t; + }), + (g.prototype.error = function (A) { + let e; + const t = this._reporterState, + i = A instanceof r; + if ( + ((e = i + ? A + : new r( + t.path + .map(function (A) { + return "[" + JSON.stringify(A) + "]"; + }) + .join(""), + A.message || A, + A.stack + )), + !t.options.partial) + ) + throw e; + return i || t.errors.push(e), e; + }), + (g.prototype.wrapResult = function (A) { + const e = this._reporterState; + return e.options.partial + ? { result: this.isError(A) ? null : A, errors: e.errors } + : A; + }), + i(r, Error), + (r.prototype.rethrow = function (A) { + if ( + ((this.message = A + " at: " + (this.path || "(shallow)")), + Error.captureStackTrace && Error.captureStackTrace(this, r), + !this.stack) + ) + try { + throw new Error(this.message); + } catch (A) { + this.stack = A.stack; + } + return this; + }); + }, + { inherits: 134 }, + ], + 7: [ + function (A, e, t) { + "use strict"; + function i(A) { + const e = {}; + return ( + Object.keys(A).forEach(function (t) { + (0 | t) == t && (t |= 0); + const i = A[t]; + e[i] = t; + }), + e + ); + } + (t.tagClass = { + 0: "universal", + 1: "application", + 2: "context", + 3: "private", + }), + (t.tagClassByName = i(t.tagClass)), + (t.tag = { + 0: "end", + 1: "bool", + 2: "int", + 3: "bitstr", + 4: "octstr", + 5: "null_", + 6: "objid", + 7: "objDesc", + 8: "external", + 9: "real", + 10: "enum", + 11: "embed", + 12: "utf8str", + 13: "relativeOid", + 16: "seq", + 17: "set", + 18: "numstr", + 19: "printstr", + 20: "t61str", + 21: "videostr", + 22: "ia5str", + 23: "utctime", + 24: "gentime", + 25: "graphstr", + 26: "iso646str", + 27: "genstr", + 28: "unistr", + 29: "charstr", + 30: "bmpstr", + }), + (t.tagByName = i(t.tag)); + }, + {}, + ], + 8: [ + function (A, e, t) { + "use strict"; + const i = t; + (i._reverse = function (A) { + const e = {}; + return ( + Object.keys(A).forEach(function (t) { + (0 | t) == t && (t |= 0); + const i = A[t]; + e[i] = t; + }), + e + ); + }), + (i.der = A("./der")); + }, + { "./der": 7 }, + ], + 9: [ + function (A, e, t) { + "use strict"; + const i = A("inherits"), + g = A("bn.js"), + r = A("../base/buffer").DecoderBuffer, + n = A("../base/node"), + B = A("../constants/der"); + function I(A) { + (this.enc = "der"), + (this.name = A.name), + (this.entity = A), + (this.tree = new o()), + this.tree._init(A.body); + } + function o(A) { + n.call(this, "der", A); + } + function a(A, e) { + let t = A.readUInt8(e); + if (A.isError(t)) return t; + const i = B.tagClass[t >> 6], + g = 0 == (32 & t); + if (31 == (31 & t)) { + let i = t; + for (t = 0; 128 == (128 & i); ) { + if (((i = A.readUInt8(e)), A.isError(i))) return i; + (t <<= 7), (t |= 127 & i); + } + } else t &= 31; + return { cls: i, primitive: g, tag: t, tagStr: B.tag[t] }; + } + function Q(A, e, t) { + let i = A.readUInt8(t); + if (A.isError(i)) return i; + if (!e && 128 === i) return null; + if (0 == (128 & i)) return i; + const g = 127 & i; + if (g > 4) return A.error("length octect is too long"); + i = 0; + for (let e = 0; e < g; e++) { + i <<= 8; + const e = A.readUInt8(t); + if (A.isError(e)) return e; + i |= e; + } + return i; + } + (e.exports = I), + (I.prototype.decode = function (A, e) { + return ( + r.isDecoderBuffer(A) || (A = new r(A, e)), this.tree._decode(A, e) + ); + }), + i(o, n), + (o.prototype._peekTag = function (A, e, t) { + if (A.isEmpty()) return !1; + const i = A.save(), + g = a(A, 'Failed to peek tag: "' + e + '"'); + return A.isError(g) + ? g + : (A.restore(i), + g.tag === e || g.tagStr === e || g.tagStr + "of" === e || t); + }), + (o.prototype._decodeTag = function (A, e, t) { + const i = a(A, 'Failed to decode tag of "' + e + '"'); + if (A.isError(i)) return i; + let g = Q(A, i.primitive, 'Failed to get length of "' + e + '"'); + if (A.isError(g)) return g; + if (!t && i.tag !== e && i.tagStr !== e && i.tagStr + "of" !== e) + return A.error('Failed to match tag: "' + e + '"'); + if (i.primitive || null !== g) + return A.skip(g, 'Failed to match body of: "' + e + '"'); + const r = A.save(), + n = this._skipUntilEnd( + A, + 'Failed to skip indefinite length body: "' + this.tag + '"' + ); + return A.isError(n) + ? n + : ((g = A.offset - r.offset), + A.restore(r), + A.skip(g, 'Failed to match body of: "' + e + '"')); + }), + (o.prototype._skipUntilEnd = function (A, e) { + for (;;) { + const t = a(A, e); + if (A.isError(t)) return t; + const i = Q(A, t.primitive, e); + if (A.isError(i)) return i; + let g; + if ( + ((g = + t.primitive || null !== i + ? A.skip(i) + : this._skipUntilEnd(A, e)), + A.isError(g)) + ) + return g; + if ("end" === t.tagStr) break; + } + }), + (o.prototype._decodeList = function (A, e, t, i) { + const g = []; + for (; !A.isEmpty(); ) { + const e = this._peekTag(A, "end"); + if (A.isError(e)) return e; + const r = t.decode(A, "der", i); + if (A.isError(r) && e) break; + g.push(r); + } + return g; + }), + (o.prototype._decodeStr = function (A, e) { + if ("bitstr" === e) { + const e = A.readUInt8(); + return A.isError(e) ? e : { unused: e, data: A.raw() }; + } + if ("bmpstr" === e) { + const e = A.raw(); + if (e.length % 2 == 1) + return A.error( + "Decoding of string type: bmpstr length mismatch" + ); + let t = ""; + for (let A = 0; A < e.length / 2; A++) + t += String.fromCharCode(e.readUInt16BE(2 * A)); + return t; + } + if ("numstr" === e) { + const e = A.raw().toString("ascii"); + return this._isNumstr(e) + ? e + : A.error( + "Decoding of string type: numstr unsupported characters" + ); + } + if ("octstr" === e) return A.raw(); + if ("objDesc" === e) return A.raw(); + if ("printstr" === e) { + const e = A.raw().toString("ascii"); + return this._isPrintstr(e) + ? e + : A.error( + "Decoding of string type: printstr unsupported characters" + ); + } + return /str$/.test(e) + ? A.raw().toString() + : A.error("Decoding of string type: " + e + " unsupported"); + }), + (o.prototype._decodeObjid = function (A, e, t) { + let i; + const g = []; + let r = 0, + n = 0; + for (; !A.isEmpty(); ) + (r <<= 7), + (r |= 127 & (n = A.readUInt8())), + 0 == (128 & n) && (g.push(r), (r = 0)); + 128 & n && g.push(r); + const B = (g[0] / 40) | 0, + I = g[0] % 40; + if (((i = t ? g : [B, I].concat(g.slice(1))), e)) { + let A = e[i.join(" ")]; + void 0 === A && (A = e[i.join(".")]), void 0 !== A && (i = A); + } + return i; + }), + (o.prototype._decodeTime = function (A, e) { + const t = A.raw().toString(); + let i, g, r, n, B, I; + if ("gentime" === e) + (i = 0 | t.slice(0, 4)), + (g = 0 | t.slice(4, 6)), + (r = 0 | t.slice(6, 8)), + (n = 0 | t.slice(8, 10)), + (B = 0 | t.slice(10, 12)), + (I = 0 | t.slice(12, 14)); + else { + if ("utctime" !== e) + return A.error("Decoding " + e + " time is not supported yet"); + (i = 0 | t.slice(0, 2)), + (g = 0 | t.slice(2, 4)), + (r = 0 | t.slice(4, 6)), + (n = 0 | t.slice(6, 8)), + (B = 0 | t.slice(8, 10)), + (I = 0 | t.slice(10, 12)), + (i = i < 70 ? 2e3 + i : 1900 + i); + } + return Date.UTC(i, g - 1, r, n, B, I, 0); + }), + (o.prototype._decodeNull = function () { + return null; + }), + (o.prototype._decodeBool = function (A) { + const e = A.readUInt8(); + return A.isError(e) ? e : 0 !== e; + }), + (o.prototype._decodeInt = function (A, e) { + const t = A.raw(); + let i = new g(t); + return e && (i = e[i.toString(10)] || i), i; + }), + (o.prototype._use = function (A, e) { + return ( + "function" == typeof A && (A = A(e)), A._getDecoder("der").tree + ); + }); + }, + { + "../base/buffer": 3, + "../base/node": 5, + "../constants/der": 7, + "bn.js": 15, + inherits: 134, + }, + ], + 10: [ + function (A, e, t) { + "use strict"; + const i = t; + (i.der = A("./der")), (i.pem = A("./pem")); + }, + { "./der": 9, "./pem": 11 }, + ], + 11: [ + function (A, e, t) { + "use strict"; + const i = A("inherits"), + g = A("safer-buffer").Buffer, + r = A("./der"); + function n(A) { + r.call(this, A), (this.enc = "pem"); + } + i(n, r), + (e.exports = n), + (n.prototype.decode = function (A, e) { + const t = A.toString().split(/[\r\n]+/g), + i = e.label.toUpperCase(), + n = /^-----(BEGIN|END) ([^-]+)-----$/; + let B = -1, + I = -1; + for (let A = 0; A < t.length; A++) { + const e = t[A].match(n); + if (null !== e && e[2] === i) { + if (-1 !== B) { + if ("END" !== e[1]) break; + I = A; + break; + } + if ("BEGIN" !== e[1]) break; + B = A; + } + } + if (-1 === B || -1 === I) + throw new Error("PEM section not found for: " + i); + const o = t.slice(B + 1, I).join(""); + o.replace(/[^a-z0-9+/=]+/gi, ""); + const a = g.from(o, "base64"); + return r.prototype.decode.call(this, a, e); + }); + }, + { "./der": 9, inherits: 134, "safer-buffer": 181 }, + ], + 12: [ + function (A, e, t) { + "use strict"; + const i = A("inherits"), + g = A("safer-buffer").Buffer, + r = A("../base/node"), + n = A("../constants/der"); + function B(A) { + (this.enc = "der"), + (this.name = A.name), + (this.entity = A), + (this.tree = new I()), + this.tree._init(A.body); + } + function I(A) { + r.call(this, "der", A); + } + function o(A) { + return A < 10 ? "0" + A : A; + } + (e.exports = B), + (B.prototype.encode = function (A, e) { + return this.tree._encode(A, e).join(); + }), + i(I, r), + (I.prototype._encodeComposite = function (A, e, t, i) { + const r = (function (A, e, t, i) { + let g; + "seqof" === A ? (A = "seq") : "setof" === A && (A = "set"); + if (n.tagByName.hasOwnProperty(A)) g = n.tagByName[A]; + else { + if ("number" != typeof A || (0 | A) !== A) + return i.error("Unknown tag: " + A); + g = A; + } + if (g >= 31) + return i.error("Multi-octet tag encoding unsupported"); + e || (g |= 32); + return (g |= n.tagClassByName[t || "universal"] << 6); + })(A, e, t, this.reporter); + if (i.length < 128) { + const A = g.alloc(2); + return ( + (A[0] = r), (A[1] = i.length), this._createEncoderBuffer([A, i]) + ); + } + let B = 1; + for (let A = i.length; A >= 256; A >>= 8) B++; + const I = g.alloc(2 + B); + (I[0] = r), (I[1] = 128 | B); + for (let A = 1 + B, e = i.length; e > 0; A--, e >>= 8) + I[A] = 255 & e; + return this._createEncoderBuffer([I, i]); + }), + (I.prototype._encodeStr = function (A, e) { + if ("bitstr" === e) + return this._createEncoderBuffer([0 | A.unused, A.data]); + if ("bmpstr" === e) { + const e = g.alloc(2 * A.length); + for (let t = 0; t < A.length; t++) + e.writeUInt16BE(A.charCodeAt(t), 2 * t); + return this._createEncoderBuffer(e); + } + return "numstr" === e + ? this._isNumstr(A) + ? this._createEncoderBuffer(A) + : this.reporter.error( + "Encoding of string type: numstr supports only digits and space" + ) + : "printstr" === e + ? this._isPrintstr(A) + ? this._createEncoderBuffer(A) + : this.reporter.error( + "Encoding of string type: printstr supports only latin upper and lower case letters, digits, space, apostrophe, left and rigth parenthesis, plus sign, comma, hyphen, dot, slash, colon, equal sign, question mark" + ) + : /str$/.test(e) + ? this._createEncoderBuffer(A) + : "objDesc" === e + ? this._createEncoderBuffer(A) + : this.reporter.error( + "Encoding of string type: " + e + " unsupported" + ); + }), + (I.prototype._encodeObjid = function (A, e, t) { + if ("string" == typeof A) { + if (!e) + return this.reporter.error( + "string objid given, but no values map found" + ); + if (!e.hasOwnProperty(A)) + return this.reporter.error("objid not found in values map"); + A = e[A].split(/[\s.]+/g); + for (let e = 0; e < A.length; e++) A[e] |= 0; + } else if (Array.isArray(A)) { + A = A.slice(); + for (let e = 0; e < A.length; e++) A[e] |= 0; + } + if (!Array.isArray(A)) + return this.reporter.error( + "objid() should be either array or string, got: " + + JSON.stringify(A) + ); + if (!t) { + if (A[1] >= 40) + return this.reporter.error("Second objid identifier OOB"); + A.splice(0, 2, 40 * A[0] + A[1]); + } + let i = 0; + for (let e = 0; e < A.length; e++) { + let t = A[e]; + for (i++; t >= 128; t >>= 7) i++; + } + const r = g.alloc(i); + let n = r.length - 1; + for (let e = A.length - 1; e >= 0; e--) { + let t = A[e]; + for (r[n--] = 127 & t; (t >>= 7) > 0; ) r[n--] = 128 | (127 & t); + } + return this._createEncoderBuffer(r); + }), + (I.prototype._encodeTime = function (A, e) { + let t; + const i = new Date(A); + return ( + "gentime" === e + ? (t = [ + o(i.getUTCFullYear()), + o(i.getUTCMonth() + 1), + o(i.getUTCDate()), + o(i.getUTCHours()), + o(i.getUTCMinutes()), + o(i.getUTCSeconds()), + "Z", + ].join("")) + : "utctime" === e + ? (t = [ + o(i.getUTCFullYear() % 100), + o(i.getUTCMonth() + 1), + o(i.getUTCDate()), + o(i.getUTCHours()), + o(i.getUTCMinutes()), + o(i.getUTCSeconds()), + "Z", + ].join("")) + : this.reporter.error( + "Encoding " + e + " time is not supported yet" + ), + this._encodeStr(t, "octstr") + ); + }), + (I.prototype._encodeNull = function () { + return this._createEncoderBuffer(""); + }), + (I.prototype._encodeInt = function (A, e) { + if ("string" == typeof A) { + if (!e) + return this.reporter.error( + "String int or enum given, but no values map" + ); + if (!e.hasOwnProperty(A)) + return this.reporter.error( + "Values map doesn't contain: " + JSON.stringify(A) + ); + A = e[A]; + } + if ("number" != typeof A && !g.isBuffer(A)) { + const e = A.toArray(); + !A.sign && 128 & e[0] && e.unshift(0), (A = g.from(e)); + } + if (g.isBuffer(A)) { + let e = A.length; + 0 === A.length && e++; + const t = g.alloc(e); + return ( + A.copy(t), + 0 === A.length && (t[0] = 0), + this._createEncoderBuffer(t) + ); + } + if (A < 128) return this._createEncoderBuffer(A); + if (A < 256) return this._createEncoderBuffer([0, A]); + let t = 1; + for (let e = A; e >= 256; e >>= 8) t++; + const i = new Array(t); + for (let e = i.length - 1; e >= 0; e--) (i[e] = 255 & A), (A >>= 8); + return ( + 128 & i[0] && i.unshift(0), this._createEncoderBuffer(g.from(i)) + ); + }), + (I.prototype._encodeBool = function (A) { + return this._createEncoderBuffer(A ? 255 : 0); + }), + (I.prototype._use = function (A, e) { + return ( + "function" == typeof A && (A = A(e)), A._getEncoder("der").tree + ); + }), + (I.prototype._skipDefault = function (A, e, t) { + const i = this._baseState; + let g; + if (null === i.default) return !1; + const r = A.join(); + if ( + (void 0 === i.defaultBuffer && + (i.defaultBuffer = this._encodeValue(i.default, e, t).join()), + r.length !== i.defaultBuffer.length) + ) + return !1; + for (g = 0; g < r.length; g++) + if (r[g] !== i.defaultBuffer[g]) return !1; + return !0; + }); + }, + { + "../base/node": 5, + "../constants/der": 7, + inherits: 134, + "safer-buffer": 181, + }, + ], + 13: [ + function (A, e, t) { + "use strict"; + const i = t; + (i.der = A("./der")), (i.pem = A("./pem")); + }, + { "./der": 12, "./pem": 14 }, + ], + 14: [ + function (A, e, t) { + "use strict"; + const i = A("inherits"), + g = A("./der"); + function r(A) { + g.call(this, A), (this.enc = "pem"); + } + i(r, g), + (e.exports = r), + (r.prototype.encode = function (A, e) { + const t = g.prototype.encode.call(this, A).toString("base64"), + i = ["-----BEGIN " + e.label + "-----"]; + for (let A = 0; A < t.length; A += 64) i.push(t.slice(A, A + 64)); + return i.push("-----END " + e.label + "-----"), i.join("\n"); + }); + }, + { "./der": 12, inherits: 134 }, + ], + 15: [ + function (A, e, t) { + !(function (e, t) { + "use strict"; + function i(A, e) { + if (!A) throw new Error(e || "Assertion failed"); + } + function g(A, e) { + A.super_ = e; + var t = function () {}; + (t.prototype = e.prototype), + (A.prototype = new t()), + (A.prototype.constructor = A); + } + function r(A, e, t) { + if (r.isBN(A)) return A; + (this.negative = 0), + (this.words = null), + (this.length = 0), + (this.red = null), + null !== A && + (("le" !== e && "be" !== e) || ((t = e), (e = 10)), + this._init(A || 0, e || 10, t || "be")); + } + var n; + "object" == typeof e ? (e.exports = r) : (t.BN = r), + (r.BN = r), + (r.wordSize = 26); + try { + n = A("buffer").Buffer; + } catch (A) {} + function B(A, e, t) { + for (var i = 0, g = Math.min(A.length, t), r = e; r < g; r++) { + var n = A.charCodeAt(r) - 48; + (i <<= 4), + (i |= + n >= 49 && n <= 54 + ? n - 49 + 10 + : n >= 17 && n <= 22 + ? n - 17 + 10 + : 15 & n); + } + return i; + } + function I(A, e, t, i) { + for (var g = 0, r = Math.min(A.length, t), n = e; n < r; n++) { + var B = A.charCodeAt(n) - 48; + (g *= i), + (g += B >= 49 ? B - 49 + 10 : B >= 17 ? B - 17 + 10 : B); + } + return g; + } + (r.isBN = function (A) { + return ( + A instanceof r || + (null !== A && + "object" == typeof A && + A.constructor.wordSize === r.wordSize && + Array.isArray(A.words)) + ); + }), + (r.max = function (A, e) { + return A.cmp(e) > 0 ? A : e; + }), + (r.min = function (A, e) { + return A.cmp(e) < 0 ? A : e; + }), + (r.prototype._init = function (A, e, t) { + if ("number" == typeof A) return this._initNumber(A, e, t); + if ("object" == typeof A) return this._initArray(A, e, t); + "hex" === e && (e = 16), i(e === (0 | e) && e >= 2 && e <= 36); + var g = 0; + "-" === (A = A.toString().replace(/\s+/g, ""))[0] && g++, + 16 === e ? this._parseHex(A, g) : this._parseBase(A, e, g), + "-" === A[0] && (this.negative = 1), + this.strip(), + "le" === t && this._initArray(this.toArray(), e, t); + }), + (r.prototype._initNumber = function (A, e, t) { + A < 0 && ((this.negative = 1), (A = -A)), + A < 67108864 + ? ((this.words = [67108863 & A]), (this.length = 1)) + : A < 4503599627370496 + ? ((this.words = [67108863 & A, (A / 67108864) & 67108863]), + (this.length = 2)) + : (i(A < 9007199254740992), + (this.words = [67108863 & A, (A / 67108864) & 67108863, 1]), + (this.length = 3)), + "le" === t && this._initArray(this.toArray(), e, t); + }), + (r.prototype._initArray = function (A, e, t) { + if ((i("number" == typeof A.length), A.length <= 0)) + return (this.words = [0]), (this.length = 1), this; + (this.length = Math.ceil(A.length / 3)), + (this.words = new Array(this.length)); + for (var g = 0; g < this.length; g++) this.words[g] = 0; + var r, + n, + B = 0; + if ("be" === t) + for (g = A.length - 1, r = 0; g >= 0; g -= 3) + (n = A[g] | (A[g - 1] << 8) | (A[g - 2] << 16)), + (this.words[r] |= (n << B) & 67108863), + (this.words[r + 1] = (n >>> (26 - B)) & 67108863), + (B += 24) >= 26 && ((B -= 26), r++); + else if ("le" === t) + for (g = 0, r = 0; g < A.length; g += 3) + (n = A[g] | (A[g + 1] << 8) | (A[g + 2] << 16)), + (this.words[r] |= (n << B) & 67108863), + (this.words[r + 1] = (n >>> (26 - B)) & 67108863), + (B += 24) >= 26 && ((B -= 26), r++); + return this.strip(); + }), + (r.prototype._parseHex = function (A, e) { + (this.length = Math.ceil((A.length - e) / 6)), + (this.words = new Array(this.length)); + for (var t = 0; t < this.length; t++) this.words[t] = 0; + var i, + g, + r = 0; + for (t = A.length - 6, i = 0; t >= e; t -= 6) + (g = B(A, t, t + 6)), + (this.words[i] |= (g << r) & 67108863), + (this.words[i + 1] |= (g >>> (26 - r)) & 4194303), + (r += 24) >= 26 && ((r -= 26), i++); + t + 6 !== e && + ((g = B(A, e, t + 6)), + (this.words[i] |= (g << r) & 67108863), + (this.words[i + 1] |= (g >>> (26 - r)) & 4194303)), + this.strip(); + }), + (r.prototype._parseBase = function (A, e, t) { + (this.words = [0]), (this.length = 1); + for (var i = 0, g = 1; g <= 67108863; g *= e) i++; + i--, (g = (g / e) | 0); + for ( + var r = A.length - t, + n = r % i, + B = Math.min(r, r - n) + t, + o = 0, + a = t; + a < B; + a += i + ) + (o = I(A, a, a + i, e)), + this.imuln(g), + this.words[0] + o < 67108864 + ? (this.words[0] += o) + : this._iaddn(o); + if (0 !== n) { + var Q = 1; + for (o = I(A, a, A.length, e), a = 0; a < n; a++) Q *= e; + this.imuln(Q), + this.words[0] + o < 67108864 + ? (this.words[0] += o) + : this._iaddn(o); + } + }), + (r.prototype.copy = function (A) { + A.words = new Array(this.length); + for (var e = 0; e < this.length; e++) A.words[e] = this.words[e]; + (A.length = this.length), + (A.negative = this.negative), + (A.red = this.red); + }), + (r.prototype.clone = function () { + var A = new r(null); + return this.copy(A), A; + }), + (r.prototype._expand = function (A) { + for (; this.length < A; ) this.words[this.length++] = 0; + return this; + }), + (r.prototype.strip = function () { + for (; this.length > 1 && 0 === this.words[this.length - 1]; ) + this.length--; + return this._normSign(); + }), + (r.prototype._normSign = function () { + return ( + 1 === this.length && 0 === this.words[0] && (this.negative = 0), + this + ); + }), + (r.prototype.inspect = function () { + return (this.red ? ""; + }); + var o = [ + "", + "0", + "00", + "000", + "0000", + "00000", + "000000", + "0000000", + "00000000", + "000000000", + "0000000000", + "00000000000", + "000000000000", + "0000000000000", + "00000000000000", + "000000000000000", + "0000000000000000", + "00000000000000000", + "000000000000000000", + "0000000000000000000", + "00000000000000000000", + "000000000000000000000", + "0000000000000000000000", + "00000000000000000000000", + "000000000000000000000000", + "0000000000000000000000000", + ], + a = [ + 0, 0, 25, 16, 12, 11, 10, 9, 8, 8, 7, 7, 7, 7, 6, 6, 6, 6, 6, 6, + 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, + ], + Q = [ + 0, 0, 33554432, 43046721, 16777216, 48828125, 60466176, 40353607, + 16777216, 43046721, 1e7, 19487171, 35831808, 62748517, 7529536, + 11390625, 16777216, 24137569, 34012224, 47045881, 64e6, 4084101, + 5153632, 6436343, 7962624, 9765625, 11881376, 14348907, 17210368, + 20511149, 243e5, 28629151, 33554432, 39135393, 45435424, 52521875, + 60466176, + ]; + function C(A, e, t) { + t.negative = e.negative ^ A.negative; + var i = (A.length + e.length) | 0; + (t.length = i), (i = (i - 1) | 0); + var g = 0 | A.words[0], + r = 0 | e.words[0], + n = g * r, + B = 67108863 & n, + I = (n / 67108864) | 0; + t.words[0] = B; + for (var o = 1; o < i; o++) { + for ( + var a = I >>> 26, + Q = 67108863 & I, + C = Math.min(o, e.length - 1), + s = Math.max(0, o - A.length + 1); + s <= C; + s++ + ) { + var c = (o - s) | 0; + (a += + ((n = (g = 0 | A.words[c]) * (r = 0 | e.words[s]) + Q) / + 67108864) | + 0), + (Q = 67108863 & n); + } + (t.words[o] = 0 | Q), (I = 0 | a); + } + return 0 !== I ? (t.words[o] = 0 | I) : t.length--, t.strip(); + } + (r.prototype.toString = function (A, e) { + var t; + if (((A = A || 10), (e = 0 | e || 1), 16 === A || "hex" === A)) { + t = ""; + for (var g = 0, r = 0, n = 0; n < this.length; n++) { + var B = this.words[n], + I = (16777215 & ((B << g) | r)).toString(16); + (t = + 0 !== (r = (B >>> (24 - g)) & 16777215) || + n !== this.length - 1 + ? o[6 - I.length] + I + t + : I + t), + (g += 2) >= 26 && ((g -= 26), n--); + } + for (0 !== r && (t = r.toString(16) + t); t.length % e != 0; ) + t = "0" + t; + return 0 !== this.negative && (t = "-" + t), t; + } + if (A === (0 | A) && A >= 2 && A <= 36) { + var C = a[A], + s = Q[A]; + t = ""; + var c = this.clone(); + for (c.negative = 0; !c.isZero(); ) { + var h = c.modn(s).toString(A); + t = (c = c.idivn(s)).isZero() ? h + t : o[C - h.length] + h + t; + } + for (this.isZero() && (t = "0" + t); t.length % e != 0; ) + t = "0" + t; + return 0 !== this.negative && (t = "-" + t), t; + } + i(!1, "Base should be between 2 and 36"); + }), + (r.prototype.toNumber = function () { + var A = this.words[0]; + return ( + 2 === this.length + ? (A += 67108864 * this.words[1]) + : 3 === this.length && 1 === this.words[2] + ? (A += 4503599627370496 + 67108864 * this.words[1]) + : this.length > 2 && + i(!1, "Number can only safely store up to 53 bits"), + 0 !== this.negative ? -A : A + ); + }), + (r.prototype.toJSON = function () { + return this.toString(16); + }), + (r.prototype.toBuffer = function (A, e) { + return i(void 0 !== n), this.toArrayLike(n, A, e); + }), + (r.prototype.toArray = function (A, e) { + return this.toArrayLike(Array, A, e); + }), + (r.prototype.toArrayLike = function (A, e, t) { + var g = this.byteLength(), + r = t || Math.max(1, g); + i(g <= r, "byte array longer than desired length"), + i(r > 0, "Requested array length <= 0"), + this.strip(); + var n, + B, + I = "le" === e, + o = new A(r), + a = this.clone(); + if (I) { + for (B = 0; !a.isZero(); B++) + (n = a.andln(255)), a.iushrn(8), (o[B] = n); + for (; B < r; B++) o[B] = 0; + } else { + for (B = 0; B < r - g; B++) o[B] = 0; + for (B = 0; !a.isZero(); B++) + (n = a.andln(255)), a.iushrn(8), (o[r - B - 1] = n); + } + return o; + }), + Math.clz32 + ? (r.prototype._countBits = function (A) { + return 32 - Math.clz32(A); + }) + : (r.prototype._countBits = function (A) { + var e = A, + t = 0; + return ( + e >= 4096 && ((t += 13), (e >>>= 13)), + e >= 64 && ((t += 7), (e >>>= 7)), + e >= 8 && ((t += 4), (e >>>= 4)), + e >= 2 && ((t += 2), (e >>>= 2)), + t + e + ); + }), + (r.prototype._zeroBits = function (A) { + if (0 === A) return 26; + var e = A, + t = 0; + return ( + 0 == (8191 & e) && ((t += 13), (e >>>= 13)), + 0 == (127 & e) && ((t += 7), (e >>>= 7)), + 0 == (15 & e) && ((t += 4), (e >>>= 4)), + 0 == (3 & e) && ((t += 2), (e >>>= 2)), + 0 == (1 & e) && t++, + t + ); + }), + (r.prototype.bitLength = function () { + var A = this.words[this.length - 1], + e = this._countBits(A); + return 26 * (this.length - 1) + e; + }), + (r.prototype.zeroBits = function () { + if (this.isZero()) return 0; + for (var A = 0, e = 0; e < this.length; e++) { + var t = this._zeroBits(this.words[e]); + if (((A += t), 26 !== t)) break; + } + return A; + }), + (r.prototype.byteLength = function () { + return Math.ceil(this.bitLength() / 8); + }), + (r.prototype.toTwos = function (A) { + return 0 !== this.negative + ? this.abs().inotn(A).iaddn(1) + : this.clone(); + }), + (r.prototype.fromTwos = function (A) { + return this.testn(A - 1) + ? this.notn(A).iaddn(1).ineg() + : this.clone(); + }), + (r.prototype.isNeg = function () { + return 0 !== this.negative; + }), + (r.prototype.neg = function () { + return this.clone().ineg(); + }), + (r.prototype.ineg = function () { + return this.isZero() || (this.negative ^= 1), this; + }), + (r.prototype.iuor = function (A) { + for (; this.length < A.length; ) this.words[this.length++] = 0; + for (var e = 0; e < A.length; e++) + this.words[e] = this.words[e] | A.words[e]; + return this.strip(); + }), + (r.prototype.ior = function (A) { + return i(0 == (this.negative | A.negative)), this.iuor(A); + }), + (r.prototype.or = function (A) { + return this.length > A.length + ? this.clone().ior(A) + : A.clone().ior(this); + }), + (r.prototype.uor = function (A) { + return this.length > A.length + ? this.clone().iuor(A) + : A.clone().iuor(this); + }), + (r.prototype.iuand = function (A) { + var e; + e = this.length > A.length ? A : this; + for (var t = 0; t < e.length; t++) + this.words[t] = this.words[t] & A.words[t]; + return (this.length = e.length), this.strip(); + }), + (r.prototype.iand = function (A) { + return i(0 == (this.negative | A.negative)), this.iuand(A); + }), + (r.prototype.and = function (A) { + return this.length > A.length + ? this.clone().iand(A) + : A.clone().iand(this); + }), + (r.prototype.uand = function (A) { + return this.length > A.length + ? this.clone().iuand(A) + : A.clone().iuand(this); + }), + (r.prototype.iuxor = function (A) { + var e, t; + this.length > A.length + ? ((e = this), (t = A)) + : ((e = A), (t = this)); + for (var i = 0; i < t.length; i++) + this.words[i] = e.words[i] ^ t.words[i]; + if (this !== e) + for (; i < e.length; i++) this.words[i] = e.words[i]; + return (this.length = e.length), this.strip(); + }), + (r.prototype.ixor = function (A) { + return i(0 == (this.negative | A.negative)), this.iuxor(A); + }), + (r.prototype.xor = function (A) { + return this.length > A.length + ? this.clone().ixor(A) + : A.clone().ixor(this); + }), + (r.prototype.uxor = function (A) { + return this.length > A.length + ? this.clone().iuxor(A) + : A.clone().iuxor(this); + }), + (r.prototype.inotn = function (A) { + i("number" == typeof A && A >= 0); + var e = 0 | Math.ceil(A / 26), + t = A % 26; + this._expand(e), t > 0 && e--; + for (var g = 0; g < e; g++) + this.words[g] = 67108863 & ~this.words[g]; + return ( + t > 0 && + (this.words[g] = ~this.words[g] & (67108863 >> (26 - t))), + this.strip() + ); + }), + (r.prototype.notn = function (A) { + return this.clone().inotn(A); + }), + (r.prototype.setn = function (A, e) { + i("number" == typeof A && A >= 0); + var t = (A / 26) | 0, + g = A % 26; + return ( + this._expand(t + 1), + (this.words[t] = e + ? this.words[t] | (1 << g) + : this.words[t] & ~(1 << g)), + this.strip() + ); + }), + (r.prototype.iadd = function (A) { + var e, t, i; + if (0 !== this.negative && 0 === A.negative) + return ( + (this.negative = 0), + (e = this.isub(A)), + (this.negative ^= 1), + this._normSign() + ); + if (0 === this.negative && 0 !== A.negative) + return ( + (A.negative = 0), + (e = this.isub(A)), + (A.negative = 1), + e._normSign() + ); + this.length > A.length + ? ((t = this), (i = A)) + : ((t = A), (i = this)); + for (var g = 0, r = 0; r < i.length; r++) + (e = (0 | t.words[r]) + (0 | i.words[r]) + g), + (this.words[r] = 67108863 & e), + (g = e >>> 26); + for (; 0 !== g && r < t.length; r++) + (e = (0 | t.words[r]) + g), + (this.words[r] = 67108863 & e), + (g = e >>> 26); + if (((this.length = t.length), 0 !== g)) + (this.words[this.length] = g), this.length++; + else if (t !== this) + for (; r < t.length; r++) this.words[r] = t.words[r]; + return this; + }), + (r.prototype.add = function (A) { + var e; + return 0 !== A.negative && 0 === this.negative + ? ((A.negative = 0), (e = this.sub(A)), (A.negative ^= 1), e) + : 0 === A.negative && 0 !== this.negative + ? ((this.negative = 0), + (e = A.sub(this)), + (this.negative = 1), + e) + : this.length > A.length + ? this.clone().iadd(A) + : A.clone().iadd(this); + }), + (r.prototype.isub = function (A) { + if (0 !== A.negative) { + A.negative = 0; + var e = this.iadd(A); + return (A.negative = 1), e._normSign(); + } + if (0 !== this.negative) + return ( + (this.negative = 0), + this.iadd(A), + (this.negative = 1), + this._normSign() + ); + var t, + i, + g = this.cmp(A); + if (0 === g) + return ( + (this.negative = 0), + (this.length = 1), + (this.words[0] = 0), + this + ); + g > 0 ? ((t = this), (i = A)) : ((t = A), (i = this)); + for (var r = 0, n = 0; n < i.length; n++) + (r = (e = (0 | t.words[n]) - (0 | i.words[n]) + r) >> 26), + (this.words[n] = 67108863 & e); + for (; 0 !== r && n < t.length; n++) + (r = (e = (0 | t.words[n]) + r) >> 26), + (this.words[n] = 67108863 & e); + if (0 === r && n < t.length && t !== this) + for (; n < t.length; n++) this.words[n] = t.words[n]; + return ( + (this.length = Math.max(this.length, n)), + t !== this && (this.negative = 1), + this.strip() + ); + }), + (r.prototype.sub = function (A) { + return this.clone().isub(A); + }); + var s = function (A, e, t) { + var i, + g, + r, + n = A.words, + B = e.words, + I = t.words, + o = 0, + a = 0 | n[0], + Q = 8191 & a, + C = a >>> 13, + s = 0 | n[1], + c = 8191 & s, + h = s >>> 13, + f = 0 | n[2], + E = 8191 & f, + u = f >>> 13, + d = 0 | n[3], + l = 8191 & d, + w = d >>> 13, + p = 0 | n[4], + D = 8191 & p, + b = p >>> 13, + y = 0 | n[5], + M = 8191 & y, + m = y >>> 13, + G = 0 | n[6], + k = 8191 & G, + F = G >>> 13, + N = 0 | n[7], + S = 8191 & N, + Y = N >>> 13, + v = 0 | n[8], + K = 8191 & v, + U = v >>> 13, + J = 0 | n[9], + H = 8191 & J, + R = J >>> 13, + q = 0 | B[0], + L = 8191 & q, + x = q >>> 13, + Z = 0 | B[1], + j = 8191 & Z, + W = Z >>> 13, + O = 0 | B[2], + P = 8191 & O, + V = O >>> 13, + X = 0 | B[3], + z = 8191 & X, + T = X >>> 13, + _ = 0 | B[4], + $ = 8191 & _, + AA = _ >>> 13, + eA = 0 | B[5], + tA = 8191 & eA, + iA = eA >>> 13, + gA = 0 | B[6], + rA = 8191 & gA, + nA = gA >>> 13, + BA = 0 | B[7], + IA = 8191 & BA, + oA = BA >>> 13, + aA = 0 | B[8], + QA = 8191 & aA, + CA = aA >>> 13, + sA = 0 | B[9], + cA = 8191 & sA, + hA = sA >>> 13; + (t.negative = A.negative ^ e.negative), (t.length = 19); + var fA = + (((o + (i = Math.imul(Q, L))) | 0) + + ((8191 & (g = ((g = Math.imul(Q, x)) + Math.imul(C, L)) | 0)) << + 13)) | + 0; + (o = + ((((r = Math.imul(C, x)) + (g >>> 13)) | 0) + (fA >>> 26)) | 0), + (fA &= 67108863), + (i = Math.imul(c, L)), + (g = ((g = Math.imul(c, x)) + Math.imul(h, L)) | 0), + (r = Math.imul(h, x)); + var EA = + (((o + (i = (i + Math.imul(Q, j)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, W)) | 0) + Math.imul(C, j)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, W)) | 0) + (g >>> 13)) | 0) + + (EA >>> 26)) | + 0), + (EA &= 67108863), + (i = Math.imul(E, L)), + (g = ((g = Math.imul(E, x)) + Math.imul(u, L)) | 0), + (r = Math.imul(u, x)), + (i = (i + Math.imul(c, j)) | 0), + (g = ((g = (g + Math.imul(c, W)) | 0) + Math.imul(h, j)) | 0), + (r = (r + Math.imul(h, W)) | 0); + var uA = + (((o + (i = (i + Math.imul(Q, P)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, V)) | 0) + Math.imul(C, P)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, V)) | 0) + (g >>> 13)) | 0) + + (uA >>> 26)) | + 0), + (uA &= 67108863), + (i = Math.imul(l, L)), + (g = ((g = Math.imul(l, x)) + Math.imul(w, L)) | 0), + (r = Math.imul(w, x)), + (i = (i + Math.imul(E, j)) | 0), + (g = ((g = (g + Math.imul(E, W)) | 0) + Math.imul(u, j)) | 0), + (r = (r + Math.imul(u, W)) | 0), + (i = (i + Math.imul(c, P)) | 0), + (g = ((g = (g + Math.imul(c, V)) | 0) + Math.imul(h, P)) | 0), + (r = (r + Math.imul(h, V)) | 0); + var dA = + (((o + (i = (i + Math.imul(Q, z)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, T)) | 0) + Math.imul(C, z)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, T)) | 0) + (g >>> 13)) | 0) + + (dA >>> 26)) | + 0), + (dA &= 67108863), + (i = Math.imul(D, L)), + (g = ((g = Math.imul(D, x)) + Math.imul(b, L)) | 0), + (r = Math.imul(b, x)), + (i = (i + Math.imul(l, j)) | 0), + (g = ((g = (g + Math.imul(l, W)) | 0) + Math.imul(w, j)) | 0), + (r = (r + Math.imul(w, W)) | 0), + (i = (i + Math.imul(E, P)) | 0), + (g = ((g = (g + Math.imul(E, V)) | 0) + Math.imul(u, P)) | 0), + (r = (r + Math.imul(u, V)) | 0), + (i = (i + Math.imul(c, z)) | 0), + (g = ((g = (g + Math.imul(c, T)) | 0) + Math.imul(h, z)) | 0), + (r = (r + Math.imul(h, T)) | 0); + var lA = + (((o + (i = (i + Math.imul(Q, $)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, AA)) | 0) + Math.imul(C, $)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, AA)) | 0) + (g >>> 13)) | 0) + + (lA >>> 26)) | + 0), + (lA &= 67108863), + (i = Math.imul(M, L)), + (g = ((g = Math.imul(M, x)) + Math.imul(m, L)) | 0), + (r = Math.imul(m, x)), + (i = (i + Math.imul(D, j)) | 0), + (g = ((g = (g + Math.imul(D, W)) | 0) + Math.imul(b, j)) | 0), + (r = (r + Math.imul(b, W)) | 0), + (i = (i + Math.imul(l, P)) | 0), + (g = ((g = (g + Math.imul(l, V)) | 0) + Math.imul(w, P)) | 0), + (r = (r + Math.imul(w, V)) | 0), + (i = (i + Math.imul(E, z)) | 0), + (g = ((g = (g + Math.imul(E, T)) | 0) + Math.imul(u, z)) | 0), + (r = (r + Math.imul(u, T)) | 0), + (i = (i + Math.imul(c, $)) | 0), + (g = ((g = (g + Math.imul(c, AA)) | 0) + Math.imul(h, $)) | 0), + (r = (r + Math.imul(h, AA)) | 0); + var wA = + (((o + (i = (i + Math.imul(Q, tA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, iA)) | 0) + Math.imul(C, tA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, iA)) | 0) + (g >>> 13)) | 0) + + (wA >>> 26)) | + 0), + (wA &= 67108863), + (i = Math.imul(k, L)), + (g = ((g = Math.imul(k, x)) + Math.imul(F, L)) | 0), + (r = Math.imul(F, x)), + (i = (i + Math.imul(M, j)) | 0), + (g = ((g = (g + Math.imul(M, W)) | 0) + Math.imul(m, j)) | 0), + (r = (r + Math.imul(m, W)) | 0), + (i = (i + Math.imul(D, P)) | 0), + (g = ((g = (g + Math.imul(D, V)) | 0) + Math.imul(b, P)) | 0), + (r = (r + Math.imul(b, V)) | 0), + (i = (i + Math.imul(l, z)) | 0), + (g = ((g = (g + Math.imul(l, T)) | 0) + Math.imul(w, z)) | 0), + (r = (r + Math.imul(w, T)) | 0), + (i = (i + Math.imul(E, $)) | 0), + (g = ((g = (g + Math.imul(E, AA)) | 0) + Math.imul(u, $)) | 0), + (r = (r + Math.imul(u, AA)) | 0), + (i = (i + Math.imul(c, tA)) | 0), + (g = ((g = (g + Math.imul(c, iA)) | 0) + Math.imul(h, tA)) | 0), + (r = (r + Math.imul(h, iA)) | 0); + var pA = + (((o + (i = (i + Math.imul(Q, rA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, nA)) | 0) + Math.imul(C, rA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, nA)) | 0) + (g >>> 13)) | 0) + + (pA >>> 26)) | + 0), + (pA &= 67108863), + (i = Math.imul(S, L)), + (g = ((g = Math.imul(S, x)) + Math.imul(Y, L)) | 0), + (r = Math.imul(Y, x)), + (i = (i + Math.imul(k, j)) | 0), + (g = ((g = (g + Math.imul(k, W)) | 0) + Math.imul(F, j)) | 0), + (r = (r + Math.imul(F, W)) | 0), + (i = (i + Math.imul(M, P)) | 0), + (g = ((g = (g + Math.imul(M, V)) | 0) + Math.imul(m, P)) | 0), + (r = (r + Math.imul(m, V)) | 0), + (i = (i + Math.imul(D, z)) | 0), + (g = ((g = (g + Math.imul(D, T)) | 0) + Math.imul(b, z)) | 0), + (r = (r + Math.imul(b, T)) | 0), + (i = (i + Math.imul(l, $)) | 0), + (g = ((g = (g + Math.imul(l, AA)) | 0) + Math.imul(w, $)) | 0), + (r = (r + Math.imul(w, AA)) | 0), + (i = (i + Math.imul(E, tA)) | 0), + (g = ((g = (g + Math.imul(E, iA)) | 0) + Math.imul(u, tA)) | 0), + (r = (r + Math.imul(u, iA)) | 0), + (i = (i + Math.imul(c, rA)) | 0), + (g = ((g = (g + Math.imul(c, nA)) | 0) + Math.imul(h, rA)) | 0), + (r = (r + Math.imul(h, nA)) | 0); + var DA = + (((o + (i = (i + Math.imul(Q, IA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, oA)) | 0) + Math.imul(C, IA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, oA)) | 0) + (g >>> 13)) | 0) + + (DA >>> 26)) | + 0), + (DA &= 67108863), + (i = Math.imul(K, L)), + (g = ((g = Math.imul(K, x)) + Math.imul(U, L)) | 0), + (r = Math.imul(U, x)), + (i = (i + Math.imul(S, j)) | 0), + (g = ((g = (g + Math.imul(S, W)) | 0) + Math.imul(Y, j)) | 0), + (r = (r + Math.imul(Y, W)) | 0), + (i = (i + Math.imul(k, P)) | 0), + (g = ((g = (g + Math.imul(k, V)) | 0) + Math.imul(F, P)) | 0), + (r = (r + Math.imul(F, V)) | 0), + (i = (i + Math.imul(M, z)) | 0), + (g = ((g = (g + Math.imul(M, T)) | 0) + Math.imul(m, z)) | 0), + (r = (r + Math.imul(m, T)) | 0), + (i = (i + Math.imul(D, $)) | 0), + (g = ((g = (g + Math.imul(D, AA)) | 0) + Math.imul(b, $)) | 0), + (r = (r + Math.imul(b, AA)) | 0), + (i = (i + Math.imul(l, tA)) | 0), + (g = ((g = (g + Math.imul(l, iA)) | 0) + Math.imul(w, tA)) | 0), + (r = (r + Math.imul(w, iA)) | 0), + (i = (i + Math.imul(E, rA)) | 0), + (g = ((g = (g + Math.imul(E, nA)) | 0) + Math.imul(u, rA)) | 0), + (r = (r + Math.imul(u, nA)) | 0), + (i = (i + Math.imul(c, IA)) | 0), + (g = ((g = (g + Math.imul(c, oA)) | 0) + Math.imul(h, IA)) | 0), + (r = (r + Math.imul(h, oA)) | 0); + var bA = + (((o + (i = (i + Math.imul(Q, QA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, CA)) | 0) + Math.imul(C, QA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, CA)) | 0) + (g >>> 13)) | 0) + + (bA >>> 26)) | + 0), + (bA &= 67108863), + (i = Math.imul(H, L)), + (g = ((g = Math.imul(H, x)) + Math.imul(R, L)) | 0), + (r = Math.imul(R, x)), + (i = (i + Math.imul(K, j)) | 0), + (g = ((g = (g + Math.imul(K, W)) | 0) + Math.imul(U, j)) | 0), + (r = (r + Math.imul(U, W)) | 0), + (i = (i + Math.imul(S, P)) | 0), + (g = ((g = (g + Math.imul(S, V)) | 0) + Math.imul(Y, P)) | 0), + (r = (r + Math.imul(Y, V)) | 0), + (i = (i + Math.imul(k, z)) | 0), + (g = ((g = (g + Math.imul(k, T)) | 0) + Math.imul(F, z)) | 0), + (r = (r + Math.imul(F, T)) | 0), + (i = (i + Math.imul(M, $)) | 0), + (g = ((g = (g + Math.imul(M, AA)) | 0) + Math.imul(m, $)) | 0), + (r = (r + Math.imul(m, AA)) | 0), + (i = (i + Math.imul(D, tA)) | 0), + (g = ((g = (g + Math.imul(D, iA)) | 0) + Math.imul(b, tA)) | 0), + (r = (r + Math.imul(b, iA)) | 0), + (i = (i + Math.imul(l, rA)) | 0), + (g = ((g = (g + Math.imul(l, nA)) | 0) + Math.imul(w, rA)) | 0), + (r = (r + Math.imul(w, nA)) | 0), + (i = (i + Math.imul(E, IA)) | 0), + (g = ((g = (g + Math.imul(E, oA)) | 0) + Math.imul(u, IA)) | 0), + (r = (r + Math.imul(u, oA)) | 0), + (i = (i + Math.imul(c, QA)) | 0), + (g = ((g = (g + Math.imul(c, CA)) | 0) + Math.imul(h, QA)) | 0), + (r = (r + Math.imul(h, CA)) | 0); + var yA = + (((o + (i = (i + Math.imul(Q, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, hA)) | 0) + Math.imul(C, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, hA)) | 0) + (g >>> 13)) | 0) + + (yA >>> 26)) | + 0), + (yA &= 67108863), + (i = Math.imul(H, j)), + (g = ((g = Math.imul(H, W)) + Math.imul(R, j)) | 0), + (r = Math.imul(R, W)), + (i = (i + Math.imul(K, P)) | 0), + (g = ((g = (g + Math.imul(K, V)) | 0) + Math.imul(U, P)) | 0), + (r = (r + Math.imul(U, V)) | 0), + (i = (i + Math.imul(S, z)) | 0), + (g = ((g = (g + Math.imul(S, T)) | 0) + Math.imul(Y, z)) | 0), + (r = (r + Math.imul(Y, T)) | 0), + (i = (i + Math.imul(k, $)) | 0), + (g = ((g = (g + Math.imul(k, AA)) | 0) + Math.imul(F, $)) | 0), + (r = (r + Math.imul(F, AA)) | 0), + (i = (i + Math.imul(M, tA)) | 0), + (g = ((g = (g + Math.imul(M, iA)) | 0) + Math.imul(m, tA)) | 0), + (r = (r + Math.imul(m, iA)) | 0), + (i = (i + Math.imul(D, rA)) | 0), + (g = ((g = (g + Math.imul(D, nA)) | 0) + Math.imul(b, rA)) | 0), + (r = (r + Math.imul(b, nA)) | 0), + (i = (i + Math.imul(l, IA)) | 0), + (g = ((g = (g + Math.imul(l, oA)) | 0) + Math.imul(w, IA)) | 0), + (r = (r + Math.imul(w, oA)) | 0), + (i = (i + Math.imul(E, QA)) | 0), + (g = ((g = (g + Math.imul(E, CA)) | 0) + Math.imul(u, QA)) | 0), + (r = (r + Math.imul(u, CA)) | 0); + var MA = + (((o + (i = (i + Math.imul(c, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(c, hA)) | 0) + Math.imul(h, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(h, hA)) | 0) + (g >>> 13)) | 0) + + (MA >>> 26)) | + 0), + (MA &= 67108863), + (i = Math.imul(H, P)), + (g = ((g = Math.imul(H, V)) + Math.imul(R, P)) | 0), + (r = Math.imul(R, V)), + (i = (i + Math.imul(K, z)) | 0), + (g = ((g = (g + Math.imul(K, T)) | 0) + Math.imul(U, z)) | 0), + (r = (r + Math.imul(U, T)) | 0), + (i = (i + Math.imul(S, $)) | 0), + (g = ((g = (g + Math.imul(S, AA)) | 0) + Math.imul(Y, $)) | 0), + (r = (r + Math.imul(Y, AA)) | 0), + (i = (i + Math.imul(k, tA)) | 0), + (g = ((g = (g + Math.imul(k, iA)) | 0) + Math.imul(F, tA)) | 0), + (r = (r + Math.imul(F, iA)) | 0), + (i = (i + Math.imul(M, rA)) | 0), + (g = ((g = (g + Math.imul(M, nA)) | 0) + Math.imul(m, rA)) | 0), + (r = (r + Math.imul(m, nA)) | 0), + (i = (i + Math.imul(D, IA)) | 0), + (g = ((g = (g + Math.imul(D, oA)) | 0) + Math.imul(b, IA)) | 0), + (r = (r + Math.imul(b, oA)) | 0), + (i = (i + Math.imul(l, QA)) | 0), + (g = ((g = (g + Math.imul(l, CA)) | 0) + Math.imul(w, QA)) | 0), + (r = (r + Math.imul(w, CA)) | 0); + var mA = + (((o + (i = (i + Math.imul(E, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(E, hA)) | 0) + Math.imul(u, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(u, hA)) | 0) + (g >>> 13)) | 0) + + (mA >>> 26)) | + 0), + (mA &= 67108863), + (i = Math.imul(H, z)), + (g = ((g = Math.imul(H, T)) + Math.imul(R, z)) | 0), + (r = Math.imul(R, T)), + (i = (i + Math.imul(K, $)) | 0), + (g = ((g = (g + Math.imul(K, AA)) | 0) + Math.imul(U, $)) | 0), + (r = (r + Math.imul(U, AA)) | 0), + (i = (i + Math.imul(S, tA)) | 0), + (g = ((g = (g + Math.imul(S, iA)) | 0) + Math.imul(Y, tA)) | 0), + (r = (r + Math.imul(Y, iA)) | 0), + (i = (i + Math.imul(k, rA)) | 0), + (g = ((g = (g + Math.imul(k, nA)) | 0) + Math.imul(F, rA)) | 0), + (r = (r + Math.imul(F, nA)) | 0), + (i = (i + Math.imul(M, IA)) | 0), + (g = ((g = (g + Math.imul(M, oA)) | 0) + Math.imul(m, IA)) | 0), + (r = (r + Math.imul(m, oA)) | 0), + (i = (i + Math.imul(D, QA)) | 0), + (g = ((g = (g + Math.imul(D, CA)) | 0) + Math.imul(b, QA)) | 0), + (r = (r + Math.imul(b, CA)) | 0); + var GA = + (((o + (i = (i + Math.imul(l, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(l, hA)) | 0) + Math.imul(w, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(w, hA)) | 0) + (g >>> 13)) | 0) + + (GA >>> 26)) | + 0), + (GA &= 67108863), + (i = Math.imul(H, $)), + (g = ((g = Math.imul(H, AA)) + Math.imul(R, $)) | 0), + (r = Math.imul(R, AA)), + (i = (i + Math.imul(K, tA)) | 0), + (g = ((g = (g + Math.imul(K, iA)) | 0) + Math.imul(U, tA)) | 0), + (r = (r + Math.imul(U, iA)) | 0), + (i = (i + Math.imul(S, rA)) | 0), + (g = ((g = (g + Math.imul(S, nA)) | 0) + Math.imul(Y, rA)) | 0), + (r = (r + Math.imul(Y, nA)) | 0), + (i = (i + Math.imul(k, IA)) | 0), + (g = ((g = (g + Math.imul(k, oA)) | 0) + Math.imul(F, IA)) | 0), + (r = (r + Math.imul(F, oA)) | 0), + (i = (i + Math.imul(M, QA)) | 0), + (g = ((g = (g + Math.imul(M, CA)) | 0) + Math.imul(m, QA)) | 0), + (r = (r + Math.imul(m, CA)) | 0); + var kA = + (((o + (i = (i + Math.imul(D, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(D, hA)) | 0) + Math.imul(b, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(b, hA)) | 0) + (g >>> 13)) | 0) + + (kA >>> 26)) | + 0), + (kA &= 67108863), + (i = Math.imul(H, tA)), + (g = ((g = Math.imul(H, iA)) + Math.imul(R, tA)) | 0), + (r = Math.imul(R, iA)), + (i = (i + Math.imul(K, rA)) | 0), + (g = ((g = (g + Math.imul(K, nA)) | 0) + Math.imul(U, rA)) | 0), + (r = (r + Math.imul(U, nA)) | 0), + (i = (i + Math.imul(S, IA)) | 0), + (g = ((g = (g + Math.imul(S, oA)) | 0) + Math.imul(Y, IA)) | 0), + (r = (r + Math.imul(Y, oA)) | 0), + (i = (i + Math.imul(k, QA)) | 0), + (g = ((g = (g + Math.imul(k, CA)) | 0) + Math.imul(F, QA)) | 0), + (r = (r + Math.imul(F, CA)) | 0); + var FA = + (((o + (i = (i + Math.imul(M, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(M, hA)) | 0) + Math.imul(m, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(m, hA)) | 0) + (g >>> 13)) | 0) + + (FA >>> 26)) | + 0), + (FA &= 67108863), + (i = Math.imul(H, rA)), + (g = ((g = Math.imul(H, nA)) + Math.imul(R, rA)) | 0), + (r = Math.imul(R, nA)), + (i = (i + Math.imul(K, IA)) | 0), + (g = ((g = (g + Math.imul(K, oA)) | 0) + Math.imul(U, IA)) | 0), + (r = (r + Math.imul(U, oA)) | 0), + (i = (i + Math.imul(S, QA)) | 0), + (g = ((g = (g + Math.imul(S, CA)) | 0) + Math.imul(Y, QA)) | 0), + (r = (r + Math.imul(Y, CA)) | 0); + var NA = + (((o + (i = (i + Math.imul(k, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(k, hA)) | 0) + Math.imul(F, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(F, hA)) | 0) + (g >>> 13)) | 0) + + (NA >>> 26)) | + 0), + (NA &= 67108863), + (i = Math.imul(H, IA)), + (g = ((g = Math.imul(H, oA)) + Math.imul(R, IA)) | 0), + (r = Math.imul(R, oA)), + (i = (i + Math.imul(K, QA)) | 0), + (g = ((g = (g + Math.imul(K, CA)) | 0) + Math.imul(U, QA)) | 0), + (r = (r + Math.imul(U, CA)) | 0); + var SA = + (((o + (i = (i + Math.imul(S, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(S, hA)) | 0) + Math.imul(Y, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(Y, hA)) | 0) + (g >>> 13)) | 0) + + (SA >>> 26)) | + 0), + (SA &= 67108863), + (i = Math.imul(H, QA)), + (g = ((g = Math.imul(H, CA)) + Math.imul(R, QA)) | 0), + (r = Math.imul(R, CA)); + var YA = + (((o + (i = (i + Math.imul(K, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(K, hA)) | 0) + Math.imul(U, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(U, hA)) | 0) + (g >>> 13)) | 0) + + (YA >>> 26)) | + 0), + (YA &= 67108863); + var vA = + (((o + (i = Math.imul(H, cA))) | 0) + + ((8191 & + (g = ((g = Math.imul(H, hA)) + Math.imul(R, cA)) | 0)) << + 13)) | + 0; + return ( + (o = + ((((r = Math.imul(R, hA)) + (g >>> 13)) | 0) + (vA >>> 26)) | + 0), + (vA &= 67108863), + (I[0] = fA), + (I[1] = EA), + (I[2] = uA), + (I[3] = dA), + (I[4] = lA), + (I[5] = wA), + (I[6] = pA), + (I[7] = DA), + (I[8] = bA), + (I[9] = yA), + (I[10] = MA), + (I[11] = mA), + (I[12] = GA), + (I[13] = kA), + (I[14] = FA), + (I[15] = NA), + (I[16] = SA), + (I[17] = YA), + (I[18] = vA), + 0 !== o && ((I[19] = o), t.length++), + t + ); + }; + function c(A, e, t) { + return new h().mulp(A, e, t); + } + function h(A, e) { + (this.x = A), (this.y = e); + } + Math.imul || (s = C), + (r.prototype.mulTo = function (A, e) { + var t = this.length + A.length; + return 10 === this.length && 10 === A.length + ? s(this, A, e) + : t < 63 + ? C(this, A, e) + : t < 1024 + ? (function (A, e, t) { + (t.negative = e.negative ^ A.negative), + (t.length = A.length + e.length); + for (var i = 0, g = 0, r = 0; r < t.length - 1; r++) { + var n = g; + g = 0; + for ( + var B = 67108863 & i, + I = Math.min(r, e.length - 1), + o = Math.max(0, r - A.length + 1); + o <= I; + o++ + ) { + var a = r - o, + Q = (0 | A.words[a]) * (0 | e.words[o]), + C = 67108863 & Q; + (B = 67108863 & (C = (C + B) | 0)), + (g += + (n = + ((n = (n + ((Q / 67108864) | 0)) | 0) + + (C >>> 26)) | + 0) >>> 26), + (n &= 67108863); + } + (t.words[r] = B), (i = n), (n = g); + } + return 0 !== i ? (t.words[r] = i) : t.length--, t.strip(); + })(this, A, e) + : c(this, A, e); + }), + (h.prototype.makeRBT = function (A) { + for ( + var e = new Array(A), t = r.prototype._countBits(A) - 1, i = 0; + i < A; + i++ + ) + e[i] = this.revBin(i, t, A); + return e; + }), + (h.prototype.revBin = function (A, e, t) { + if (0 === A || A === t - 1) return A; + for (var i = 0, g = 0; g < e; g++) + (i |= (1 & A) << (e - g - 1)), (A >>= 1); + return i; + }), + (h.prototype.permute = function (A, e, t, i, g, r) { + for (var n = 0; n < r; n++) (i[n] = e[A[n]]), (g[n] = t[A[n]]); + }), + (h.prototype.transform = function (A, e, t, i, g, r) { + this.permute(r, A, e, t, i, g); + for (var n = 1; n < g; n <<= 1) + for ( + var B = n << 1, + I = Math.cos((2 * Math.PI) / B), + o = Math.sin((2 * Math.PI) / B), + a = 0; + a < g; + a += B + ) + for (var Q = I, C = o, s = 0; s < n; s++) { + var c = t[a + s], + h = i[a + s], + f = t[a + s + n], + E = i[a + s + n], + u = Q * f - C * E; + (E = Q * E + C * f), + (f = u), + (t[a + s] = c + f), + (i[a + s] = h + E), + (t[a + s + n] = c - f), + (i[a + s + n] = h - E), + s !== B && + ((u = I * Q - o * C), (C = I * C + o * Q), (Q = u)); + } + }), + (h.prototype.guessLen13b = function (A, e) { + var t = 1 | Math.max(e, A), + i = 1 & t, + g = 0; + for (t = (t / 2) | 0; t; t >>>= 1) g++; + return 1 << (g + 1 + i); + }), + (h.prototype.conjugate = function (A, e, t) { + if (!(t <= 1)) + for (var i = 0; i < t / 2; i++) { + var g = A[i]; + (A[i] = A[t - i - 1]), + (A[t - i - 1] = g), + (g = e[i]), + (e[i] = -e[t - i - 1]), + (e[t - i - 1] = -g); + } + }), + (h.prototype.normalize13b = function (A, e) { + for (var t = 0, i = 0; i < e / 2; i++) { + var g = + 8192 * Math.round(A[2 * i + 1] / e) + + Math.round(A[2 * i] / e) + + t; + (A[i] = 67108863 & g), + (t = g < 67108864 ? 0 : (g / 67108864) | 0); + } + return A; + }), + (h.prototype.convert13b = function (A, e, t, g) { + for (var r = 0, n = 0; n < e; n++) + (r += 0 | A[n]), + (t[2 * n] = 8191 & r), + (r >>>= 13), + (t[2 * n + 1] = 8191 & r), + (r >>>= 13); + for (n = 2 * e; n < g; ++n) t[n] = 0; + i(0 === r), i(0 == (-8192 & r)); + }), + (h.prototype.stub = function (A) { + for (var e = new Array(A), t = 0; t < A; t++) e[t] = 0; + return e; + }), + (h.prototype.mulp = function (A, e, t) { + var i = 2 * this.guessLen13b(A.length, e.length), + g = this.makeRBT(i), + r = this.stub(i), + n = new Array(i), + B = new Array(i), + I = new Array(i), + o = new Array(i), + a = new Array(i), + Q = new Array(i), + C = t.words; + (C.length = i), + this.convert13b(A.words, A.length, n, i), + this.convert13b(e.words, e.length, o, i), + this.transform(n, r, B, I, i, g), + this.transform(o, r, a, Q, i, g); + for (var s = 0; s < i; s++) { + var c = B[s] * a[s] - I[s] * Q[s]; + (I[s] = B[s] * Q[s] + I[s] * a[s]), (B[s] = c); + } + return ( + this.conjugate(B, I, i), + this.transform(B, I, C, r, i, g), + this.conjugate(C, r, i), + this.normalize13b(C, i), + (t.negative = A.negative ^ e.negative), + (t.length = A.length + e.length), + t.strip() + ); + }), + (r.prototype.mul = function (A) { + var e = new r(null); + return ( + (e.words = new Array(this.length + A.length)), this.mulTo(A, e) + ); + }), + (r.prototype.mulf = function (A) { + var e = new r(null); + return ( + (e.words = new Array(this.length + A.length)), c(this, A, e) + ); + }), + (r.prototype.imul = function (A) { + return this.clone().mulTo(A, this); + }), + (r.prototype.imuln = function (A) { + i("number" == typeof A), i(A < 67108864); + for (var e = 0, t = 0; t < this.length; t++) { + var g = (0 | this.words[t]) * A, + r = (67108863 & g) + (67108863 & e); + (e >>= 26), + (e += (g / 67108864) | 0), + (e += r >>> 26), + (this.words[t] = 67108863 & r); + } + return 0 !== e && ((this.words[t] = e), this.length++), this; + }), + (r.prototype.muln = function (A) { + return this.clone().imuln(A); + }), + (r.prototype.sqr = function () { + return this.mul(this); + }), + (r.prototype.isqr = function () { + return this.imul(this.clone()); + }), + (r.prototype.pow = function (A) { + var e = (function (A) { + for ( + var e = new Array(A.bitLength()), t = 0; + t < e.length; + t++ + ) { + var i = (t / 26) | 0, + g = t % 26; + e[t] = (A.words[i] & (1 << g)) >>> g; + } + return e; + })(A); + if (0 === e.length) return new r(1); + for ( + var t = this, i = 0; + i < e.length && 0 === e[i]; + i++, t = t.sqr() + ); + if (++i < e.length) + for (var g = t.sqr(); i < e.length; i++, g = g.sqr()) + 0 !== e[i] && (t = t.mul(g)); + return t; + }), + (r.prototype.iushln = function (A) { + i("number" == typeof A && A >= 0); + var e, + t = A % 26, + g = (A - t) / 26, + r = (67108863 >>> (26 - t)) << (26 - t); + if (0 !== t) { + var n = 0; + for (e = 0; e < this.length; e++) { + var B = this.words[e] & r, + I = ((0 | this.words[e]) - B) << t; + (this.words[e] = I | n), (n = B >>> (26 - t)); + } + n && ((this.words[e] = n), this.length++); + } + if (0 !== g) { + for (e = this.length - 1; e >= 0; e--) + this.words[e + g] = this.words[e]; + for (e = 0; e < g; e++) this.words[e] = 0; + this.length += g; + } + return this.strip(); + }), + (r.prototype.ishln = function (A) { + return i(0 === this.negative), this.iushln(A); + }), + (r.prototype.iushrn = function (A, e, t) { + var g; + i("number" == typeof A && A >= 0), + (g = e ? (e - (e % 26)) / 26 : 0); + var r = A % 26, + n = Math.min((A - r) / 26, this.length), + B = 67108863 ^ ((67108863 >>> r) << r), + I = t; + if (((g -= n), (g = Math.max(0, g)), I)) { + for (var o = 0; o < n; o++) I.words[o] = this.words[o]; + I.length = n; + } + if (0 === n); + else if (this.length > n) + for (this.length -= n, o = 0; o < this.length; o++) + this.words[o] = this.words[o + n]; + else (this.words[0] = 0), (this.length = 1); + var a = 0; + for (o = this.length - 1; o >= 0 && (0 !== a || o >= g); o--) { + var Q = 0 | this.words[o]; + (this.words[o] = (a << (26 - r)) | (Q >>> r)), (a = Q & B); + } + return ( + I && 0 !== a && (I.words[I.length++] = a), + 0 === this.length && ((this.words[0] = 0), (this.length = 1)), + this.strip() + ); + }), + (r.prototype.ishrn = function (A, e, t) { + return i(0 === this.negative), this.iushrn(A, e, t); + }), + (r.prototype.shln = function (A) { + return this.clone().ishln(A); + }), + (r.prototype.ushln = function (A) { + return this.clone().iushln(A); + }), + (r.prototype.shrn = function (A) { + return this.clone().ishrn(A); + }), + (r.prototype.ushrn = function (A) { + return this.clone().iushrn(A); + }), + (r.prototype.testn = function (A) { + i("number" == typeof A && A >= 0); + var e = A % 26, + t = (A - e) / 26, + g = 1 << e; + return !(this.length <= t) && !!(this.words[t] & g); + }), + (r.prototype.imaskn = function (A) { + i("number" == typeof A && A >= 0); + var e = A % 26, + t = (A - e) / 26; + if ( + (i( + 0 === this.negative, + "imaskn works only with positive numbers" + ), + this.length <= t) + ) + return this; + if ( + (0 !== e && t++, + (this.length = Math.min(t, this.length)), + 0 !== e) + ) { + var g = 67108863 ^ ((67108863 >>> e) << e); + this.words[this.length - 1] &= g; + } + return this.strip(); + }), + (r.prototype.maskn = function (A) { + return this.clone().imaskn(A); + }), + (r.prototype.iaddn = function (A) { + return ( + i("number" == typeof A), + i(A < 67108864), + A < 0 + ? this.isubn(-A) + : 0 !== this.negative + ? 1 === this.length && (0 | this.words[0]) < A + ? ((this.words[0] = A - (0 | this.words[0])), + (this.negative = 0), + this) + : ((this.negative = 0), + this.isubn(A), + (this.negative = 1), + this) + : this._iaddn(A) + ); + }), + (r.prototype._iaddn = function (A) { + this.words[0] += A; + for (var e = 0; e < this.length && this.words[e] >= 67108864; e++) + (this.words[e] -= 67108864), + e === this.length - 1 + ? (this.words[e + 1] = 1) + : this.words[e + 1]++; + return (this.length = Math.max(this.length, e + 1)), this; + }), + (r.prototype.isubn = function (A) { + if ((i("number" == typeof A), i(A < 67108864), A < 0)) + return this.iaddn(-A); + if (0 !== this.negative) + return ( + (this.negative = 0), this.iaddn(A), (this.negative = 1), this + ); + if ( + ((this.words[0] -= A), 1 === this.length && this.words[0] < 0) + ) + (this.words[0] = -this.words[0]), (this.negative = 1); + else + for (var e = 0; e < this.length && this.words[e] < 0; e++) + (this.words[e] += 67108864), (this.words[e + 1] -= 1); + return this.strip(); + }), + (r.prototype.addn = function (A) { + return this.clone().iaddn(A); + }), + (r.prototype.subn = function (A) { + return this.clone().isubn(A); + }), + (r.prototype.iabs = function () { + return (this.negative = 0), this; + }), + (r.prototype.abs = function () { + return this.clone().iabs(); + }), + (r.prototype._ishlnsubmul = function (A, e, t) { + var g, + r, + n = A.length + t; + this._expand(n); + var B = 0; + for (g = 0; g < A.length; g++) { + r = (0 | this.words[g + t]) + B; + var I = (0 | A.words[g]) * e; + (B = ((r -= 67108863 & I) >> 26) - ((I / 67108864) | 0)), + (this.words[g + t] = 67108863 & r); + } + for (; g < this.length - t; g++) + (B = (r = (0 | this.words[g + t]) + B) >> 26), + (this.words[g + t] = 67108863 & r); + if (0 === B) return this.strip(); + for (i(-1 === B), B = 0, g = 0; g < this.length; g++) + (B = (r = -(0 | this.words[g]) + B) >> 26), + (this.words[g] = 67108863 & r); + return (this.negative = 1), this.strip(); + }), + (r.prototype._wordDiv = function (A, e) { + var t = (this.length, A.length), + i = this.clone(), + g = A, + n = 0 | g.words[g.length - 1]; + 0 !== (t = 26 - this._countBits(n)) && + ((g = g.ushln(t)), + i.iushln(t), + (n = 0 | g.words[g.length - 1])); + var B, + I = i.length - g.length; + if ("mod" !== e) { + ((B = new r(null)).length = I + 1), + (B.words = new Array(B.length)); + for (var o = 0; o < B.length; o++) B.words[o] = 0; + } + var a = i.clone()._ishlnsubmul(g, 1, I); + 0 === a.negative && ((i = a), B && (B.words[I] = 1)); + for (var Q = I - 1; Q >= 0; Q--) { + var C = + 67108864 * (0 | i.words[g.length + Q]) + + (0 | i.words[g.length + Q - 1]); + for ( + C = Math.min((C / n) | 0, 67108863), i._ishlnsubmul(g, C, Q); + 0 !== i.negative; + + ) + C--, + (i.negative = 0), + i._ishlnsubmul(g, 1, Q), + i.isZero() || (i.negative ^= 1); + B && (B.words[Q] = C); + } + return ( + B && B.strip(), + i.strip(), + "div" !== e && 0 !== t && i.iushrn(t), + { div: B || null, mod: i } + ); + }), + (r.prototype.divmod = function (A, e, t) { + return ( + i(!A.isZero()), + this.isZero() + ? { div: new r(0), mod: new r(0) } + : 0 !== this.negative && 0 === A.negative + ? ((B = this.neg().divmod(A, e)), + "mod" !== e && (g = B.div.neg()), + "div" !== e && + ((n = B.mod.neg()), t && 0 !== n.negative && n.iadd(A)), + { div: g, mod: n }) + : 0 === this.negative && 0 !== A.negative + ? ((B = this.divmod(A.neg(), e)), + "mod" !== e && (g = B.div.neg()), + { div: g, mod: B.mod }) + : 0 != (this.negative & A.negative) + ? ((B = this.neg().divmod(A.neg(), e)), + "div" !== e && + ((n = B.mod.neg()), t && 0 !== n.negative && n.isub(A)), + { div: B.div, mod: n }) + : A.length > this.length || this.cmp(A) < 0 + ? { div: new r(0), mod: this } + : 1 === A.length + ? "div" === e + ? { div: this.divn(A.words[0]), mod: null } + : "mod" === e + ? { div: null, mod: new r(this.modn(A.words[0])) } + : { + div: this.divn(A.words[0]), + mod: new r(this.modn(A.words[0])), + } + : this._wordDiv(A, e) + ); + var g, n, B; + }), + (r.prototype.div = function (A) { + return this.divmod(A, "div", !1).div; + }), + (r.prototype.mod = function (A) { + return this.divmod(A, "mod", !1).mod; + }), + (r.prototype.umod = function (A) { + return this.divmod(A, "mod", !0).mod; + }), + (r.prototype.divRound = function (A) { + var e = this.divmod(A); + if (e.mod.isZero()) return e.div; + var t = 0 !== e.div.negative ? e.mod.isub(A) : e.mod, + i = A.ushrn(1), + g = A.andln(1), + r = t.cmp(i); + return r < 0 || (1 === g && 0 === r) + ? e.div + : 0 !== e.div.negative + ? e.div.isubn(1) + : e.div.iaddn(1); + }), + (r.prototype.modn = function (A) { + i(A <= 67108863); + for ( + var e = (1 << 26) % A, t = 0, g = this.length - 1; + g >= 0; + g-- + ) + t = (e * t + (0 | this.words[g])) % A; + return t; + }), + (r.prototype.idivn = function (A) { + i(A <= 67108863); + for (var e = 0, t = this.length - 1; t >= 0; t--) { + var g = (0 | this.words[t]) + 67108864 * e; + (this.words[t] = (g / A) | 0), (e = g % A); + } + return this.strip(); + }), + (r.prototype.divn = function (A) { + return this.clone().idivn(A); + }), + (r.prototype.egcd = function (A) { + i(0 === A.negative), i(!A.isZero()); + var e = this, + t = A.clone(); + e = 0 !== e.negative ? e.umod(A) : e.clone(); + for ( + var g = new r(1), + n = new r(0), + B = new r(0), + I = new r(1), + o = 0; + e.isEven() && t.isEven(); + + ) + e.iushrn(1), t.iushrn(1), ++o; + for (var a = t.clone(), Q = e.clone(); !e.isZero(); ) { + for ( + var C = 0, s = 1; + 0 == (e.words[0] & s) && C < 26; + ++C, s <<= 1 + ); + if (C > 0) + for (e.iushrn(C); C-- > 0; ) + (g.isOdd() || n.isOdd()) && (g.iadd(a), n.isub(Q)), + g.iushrn(1), + n.iushrn(1); + for ( + var c = 0, h = 1; + 0 == (t.words[0] & h) && c < 26; + ++c, h <<= 1 + ); + if (c > 0) + for (t.iushrn(c); c-- > 0; ) + (B.isOdd() || I.isOdd()) && (B.iadd(a), I.isub(Q)), + B.iushrn(1), + I.iushrn(1); + e.cmp(t) >= 0 + ? (e.isub(t), g.isub(B), n.isub(I)) + : (t.isub(e), B.isub(g), I.isub(n)); + } + return { a: B, b: I, gcd: t.iushln(o) }; + }), + (r.prototype._invmp = function (A) { + i(0 === A.negative), i(!A.isZero()); + var e = this, + t = A.clone(); + e = 0 !== e.negative ? e.umod(A) : e.clone(); + for ( + var g, n = new r(1), B = new r(0), I = t.clone(); + e.cmpn(1) > 0 && t.cmpn(1) > 0; + + ) { + for ( + var o = 0, a = 1; + 0 == (e.words[0] & a) && o < 26; + ++o, a <<= 1 + ); + if (o > 0) + for (e.iushrn(o); o-- > 0; ) + n.isOdd() && n.iadd(I), n.iushrn(1); + for ( + var Q = 0, C = 1; + 0 == (t.words[0] & C) && Q < 26; + ++Q, C <<= 1 + ); + if (Q > 0) + for (t.iushrn(Q); Q-- > 0; ) + B.isOdd() && B.iadd(I), B.iushrn(1); + e.cmp(t) >= 0 ? (e.isub(t), n.isub(B)) : (t.isub(e), B.isub(n)); + } + return (g = 0 === e.cmpn(1) ? n : B).cmpn(0) < 0 && g.iadd(A), g; + }), + (r.prototype.gcd = function (A) { + if (this.isZero()) return A.abs(); + if (A.isZero()) return this.abs(); + var e = this.clone(), + t = A.clone(); + (e.negative = 0), (t.negative = 0); + for (var i = 0; e.isEven() && t.isEven(); i++) + e.iushrn(1), t.iushrn(1); + for (;;) { + for (; e.isEven(); ) e.iushrn(1); + for (; t.isEven(); ) t.iushrn(1); + var g = e.cmp(t); + if (g < 0) { + var r = e; + (e = t), (t = r); + } else if (0 === g || 0 === t.cmpn(1)) break; + e.isub(t); + } + return t.iushln(i); + }), + (r.prototype.invm = function (A) { + return this.egcd(A).a.umod(A); + }), + (r.prototype.isEven = function () { + return 0 == (1 & this.words[0]); + }), + (r.prototype.isOdd = function () { + return 1 == (1 & this.words[0]); + }), + (r.prototype.andln = function (A) { + return this.words[0] & A; + }), + (r.prototype.bincn = function (A) { + i("number" == typeof A); + var e = A % 26, + t = (A - e) / 26, + g = 1 << e; + if (this.length <= t) + return this._expand(t + 1), (this.words[t] |= g), this; + for (var r = g, n = t; 0 !== r && n < this.length; n++) { + var B = 0 | this.words[n]; + (r = (B += r) >>> 26), (B &= 67108863), (this.words[n] = B); + } + return 0 !== r && ((this.words[n] = r), this.length++), this; + }), + (r.prototype.isZero = function () { + return 1 === this.length && 0 === this.words[0]; + }), + (r.prototype.cmpn = function (A) { + var e, + t = A < 0; + if (0 !== this.negative && !t) return -1; + if (0 === this.negative && t) return 1; + if ((this.strip(), this.length > 1)) e = 1; + else { + t && (A = -A), i(A <= 67108863, "Number is too big"); + var g = 0 | this.words[0]; + e = g === A ? 0 : g < A ? -1 : 1; + } + return 0 !== this.negative ? 0 | -e : e; + }), + (r.prototype.cmp = function (A) { + if (0 !== this.negative && 0 === A.negative) return -1; + if (0 === this.negative && 0 !== A.negative) return 1; + var e = this.ucmp(A); + return 0 !== this.negative ? 0 | -e : e; + }), + (r.prototype.ucmp = function (A) { + if (this.length > A.length) return 1; + if (this.length < A.length) return -1; + for (var e = 0, t = this.length - 1; t >= 0; t--) { + var i = 0 | this.words[t], + g = 0 | A.words[t]; + if (i !== g) { + i < g ? (e = -1) : i > g && (e = 1); + break; + } + } + return e; + }), + (r.prototype.gtn = function (A) { + return 1 === this.cmpn(A); + }), + (r.prototype.gt = function (A) { + return 1 === this.cmp(A); + }), + (r.prototype.gten = function (A) { + return this.cmpn(A) >= 0; + }), + (r.prototype.gte = function (A) { + return this.cmp(A) >= 0; + }), + (r.prototype.ltn = function (A) { + return -1 === this.cmpn(A); + }), + (r.prototype.lt = function (A) { + return -1 === this.cmp(A); + }), + (r.prototype.lten = function (A) { + return this.cmpn(A) <= 0; + }), + (r.prototype.lte = function (A) { + return this.cmp(A) <= 0; + }), + (r.prototype.eqn = function (A) { + return 0 === this.cmpn(A); + }), + (r.prototype.eq = function (A) { + return 0 === this.cmp(A); + }), + (r.red = function (A) { + return new p(A); + }), + (r.prototype.toRed = function (A) { + return ( + i(!this.red, "Already a number in reduction context"), + i(0 === this.negative, "red works only with positives"), + A.convertTo(this)._forceRed(A) + ); + }), + (r.prototype.fromRed = function () { + return ( + i( + this.red, + "fromRed works only with numbers in reduction context" + ), + this.red.convertFrom(this) + ); + }), + (r.prototype._forceRed = function (A) { + return (this.red = A), this; + }), + (r.prototype.forceRed = function (A) { + return ( + i(!this.red, "Already a number in reduction context"), + this._forceRed(A) + ); + }), + (r.prototype.redAdd = function (A) { + return ( + i(this.red, "redAdd works only with red numbers"), + this.red.add(this, A) + ); + }), + (r.prototype.redIAdd = function (A) { + return ( + i(this.red, "redIAdd works only with red numbers"), + this.red.iadd(this, A) + ); + }), + (r.prototype.redSub = function (A) { + return ( + i(this.red, "redSub works only with red numbers"), + this.red.sub(this, A) + ); + }), + (r.prototype.redISub = function (A) { + return ( + i(this.red, "redISub works only with red numbers"), + this.red.isub(this, A) + ); + }), + (r.prototype.redShl = function (A) { + return ( + i(this.red, "redShl works only with red numbers"), + this.red.shl(this, A) + ); + }), + (r.prototype.redMul = function (A) { + return ( + i(this.red, "redMul works only with red numbers"), + this.red._verify2(this, A), + this.red.mul(this, A) + ); + }), + (r.prototype.redIMul = function (A) { + return ( + i(this.red, "redMul works only with red numbers"), + this.red._verify2(this, A), + this.red.imul(this, A) + ); + }), + (r.prototype.redSqr = function () { + return ( + i(this.red, "redSqr works only with red numbers"), + this.red._verify1(this), + this.red.sqr(this) + ); + }), + (r.prototype.redISqr = function () { + return ( + i(this.red, "redISqr works only with red numbers"), + this.red._verify1(this), + this.red.isqr(this) + ); + }), + (r.prototype.redSqrt = function () { + return ( + i(this.red, "redSqrt works only with red numbers"), + this.red._verify1(this), + this.red.sqrt(this) + ); + }), + (r.prototype.redInvm = function () { + return ( + i(this.red, "redInvm works only with red numbers"), + this.red._verify1(this), + this.red.invm(this) + ); + }), + (r.prototype.redNeg = function () { + return ( + i(this.red, "redNeg works only with red numbers"), + this.red._verify1(this), + this.red.neg(this) + ); + }), + (r.prototype.redPow = function (A) { + return ( + i(this.red && !A.red, "redPow(normalNum)"), + this.red._verify1(this), + this.red.pow(this, A) + ); + }); + var f = { k256: null, p224: null, p192: null, p25519: null }; + function E(A, e) { + (this.name = A), + (this.p = new r(e, 16)), + (this.n = this.p.bitLength()), + (this.k = new r(1).iushln(this.n).isub(this.p)), + (this.tmp = this._tmp()); + } + function u() { + E.call( + this, + "k256", + "ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f" + ); + } + function d() { + E.call( + this, + "p224", + "ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001" + ); + } + function l() { + E.call( + this, + "p192", + "ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff" + ); + } + function w() { + E.call( + this, + "25519", + "7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed" + ); + } + function p(A) { + if ("string" == typeof A) { + var e = r._prime(A); + (this.m = e.p), (this.prime = e); + } else + i(A.gtn(1), "modulus must be greater than 1"), + (this.m = A), + (this.prime = null); + } + function D(A) { + p.call(this, A), + (this.shift = this.m.bitLength()), + this.shift % 26 != 0 && (this.shift += 26 - (this.shift % 26)), + (this.r = new r(1).iushln(this.shift)), + (this.r2 = this.imod(this.r.sqr())), + (this.rinv = this.r._invmp(this.m)), + (this.minv = this.rinv.mul(this.r).isubn(1).div(this.m)), + (this.minv = this.minv.umod(this.r)), + (this.minv = this.r.sub(this.minv)); + } + (E.prototype._tmp = function () { + var A = new r(null); + return (A.words = new Array(Math.ceil(this.n / 13))), A; + }), + (E.prototype.ireduce = function (A) { + var e, + t = A; + do { + this.split(t, this.tmp), + (e = (t = (t = this.imulK(t)).iadd(this.tmp)).bitLength()); + } while (e > this.n); + var i = e < this.n ? -1 : t.ucmp(this.p); + return ( + 0 === i + ? ((t.words[0] = 0), (t.length = 1)) + : i > 0 + ? t.isub(this.p) + : void 0 !== t.strip + ? t.strip() + : t._strip(), + t + ); + }), + (E.prototype.split = function (A, e) { + A.iushrn(this.n, 0, e); + }), + (E.prototype.imulK = function (A) { + return A.imul(this.k); + }), + g(u, E), + (u.prototype.split = function (A, e) { + for (var t = Math.min(A.length, 9), i = 0; i < t; i++) + e.words[i] = A.words[i]; + if (((e.length = t), A.length <= 9)) + return (A.words[0] = 0), void (A.length = 1); + var g = A.words[9]; + for ( + e.words[e.length++] = 4194303 & g, i = 10; + i < A.length; + i++ + ) { + var r = 0 | A.words[i]; + (A.words[i - 10] = ((4194303 & r) << 4) | (g >>> 22)), (g = r); + } + (g >>>= 22), + (A.words[i - 10] = g), + 0 === g && A.length > 10 ? (A.length -= 10) : (A.length -= 9); + }), + (u.prototype.imulK = function (A) { + (A.words[A.length] = 0), + (A.words[A.length + 1] = 0), + (A.length += 2); + for (var e = 0, t = 0; t < A.length; t++) { + var i = 0 | A.words[t]; + (e += 977 * i), + (A.words[t] = 67108863 & e), + (e = 64 * i + ((e / 67108864) | 0)); + } + return ( + 0 === A.words[A.length - 1] && + (A.length--, 0 === A.words[A.length - 1] && A.length--), + A + ); + }), + g(d, E), + g(l, E), + g(w, E), + (w.prototype.imulK = function (A) { + for (var e = 0, t = 0; t < A.length; t++) { + var i = 19 * (0 | A.words[t]) + e, + g = 67108863 & i; + (i >>>= 26), (A.words[t] = g), (e = i); + } + return 0 !== e && (A.words[A.length++] = e), A; + }), + (r._prime = function (A) { + if (f[A]) return f[A]; + var e; + if ("k256" === A) e = new u(); + else if ("p224" === A) e = new d(); + else if ("p192" === A) e = new l(); + else { + if ("p25519" !== A) throw new Error("Unknown prime " + A); + e = new w(); + } + return (f[A] = e), e; + }), + (p.prototype._verify1 = function (A) { + i(0 === A.negative, "red works only with positives"), + i(A.red, "red works only with red numbers"); + }), + (p.prototype._verify2 = function (A, e) { + i( + 0 == (A.negative | e.negative), + "red works only with positives" + ), + i(A.red && A.red === e.red, "red works only with red numbers"); + }), + (p.prototype.imod = function (A) { + return this.prime + ? this.prime.ireduce(A)._forceRed(this) + : A.umod(this.m)._forceRed(this); + }), + (p.prototype.neg = function (A) { + return A.isZero() ? A.clone() : this.m.sub(A)._forceRed(this); + }), + (p.prototype.add = function (A, e) { + this._verify2(A, e); + var t = A.add(e); + return t.cmp(this.m) >= 0 && t.isub(this.m), t._forceRed(this); + }), + (p.prototype.iadd = function (A, e) { + this._verify2(A, e); + var t = A.iadd(e); + return t.cmp(this.m) >= 0 && t.isub(this.m), t; + }), + (p.prototype.sub = function (A, e) { + this._verify2(A, e); + var t = A.sub(e); + return t.cmpn(0) < 0 && t.iadd(this.m), t._forceRed(this); + }), + (p.prototype.isub = function (A, e) { + this._verify2(A, e); + var t = A.isub(e); + return t.cmpn(0) < 0 && t.iadd(this.m), t; + }), + (p.prototype.shl = function (A, e) { + return this._verify1(A), this.imod(A.ushln(e)); + }), + (p.prototype.imul = function (A, e) { + return this._verify2(A, e), this.imod(A.imul(e)); + }), + (p.prototype.mul = function (A, e) { + return this._verify2(A, e), this.imod(A.mul(e)); + }), + (p.prototype.isqr = function (A) { + return this.imul(A, A.clone()); + }), + (p.prototype.sqr = function (A) { + return this.mul(A, A); + }), + (p.prototype.sqrt = function (A) { + if (A.isZero()) return A.clone(); + var e = this.m.andln(3); + if ((i(e % 2 == 1), 3 === e)) { + var t = this.m.add(new r(1)).iushrn(2); + return this.pow(A, t); + } + for ( + var g = this.m.subn(1), n = 0; + !g.isZero() && 0 === g.andln(1); + + ) + n++, g.iushrn(1); + i(!g.isZero()); + var B = new r(1).toRed(this), + I = B.redNeg(), + o = this.m.subn(1).iushrn(1), + a = this.m.bitLength(); + for ( + a = new r(2 * a * a).toRed(this); + 0 !== this.pow(a, o).cmp(I); + + ) + a.redIAdd(I); + for ( + var Q = this.pow(a, g), + C = this.pow(A, g.addn(1).iushrn(1)), + s = this.pow(A, g), + c = n; + 0 !== s.cmp(B); + + ) { + for (var h = s, f = 0; 0 !== h.cmp(B); f++) h = h.redSqr(); + i(f < c); + var E = this.pow(Q, new r(1).iushln(c - f - 1)); + (C = C.redMul(E)), (Q = E.redSqr()), (s = s.redMul(Q)), (c = f); + } + return C; + }), + (p.prototype.invm = function (A) { + var e = A._invmp(this.m); + return 0 !== e.negative + ? ((e.negative = 0), this.imod(e).redNeg()) + : this.imod(e); + }), + (p.prototype.pow = function (A, e) { + if (e.isZero()) return new r(1).toRed(this); + if (0 === e.cmpn(1)) return A.clone(); + var t = new Array(16); + (t[0] = new r(1).toRed(this)), (t[1] = A); + for (var i = 2; i < t.length; i++) t[i] = this.mul(t[i - 1], A); + var g = t[0], + n = 0, + B = 0, + I = e.bitLength() % 26; + for (0 === I && (I = 26), i = e.length - 1; i >= 0; i--) { + for (var o = e.words[i], a = I - 1; a >= 0; a--) { + var Q = (o >> a) & 1; + g !== t[0] && (g = this.sqr(g)), + 0 !== Q || 0 !== n + ? ((n <<= 1), + (n |= Q), + (4 === ++B || (0 === i && 0 === a)) && + ((g = this.mul(g, t[n])), (B = 0), (n = 0))) + : (B = 0); + } + I = 26; + } + return g; + }), + (p.prototype.convertTo = function (A) { + var e = A.umod(this.m); + return e === A ? e.clone() : e; + }), + (p.prototype.convertFrom = function (A) { + var e = A.clone(); + return (e.red = null), e; + }), + (r.mont = function (A) { + return new D(A); + }), + g(D, p), + (D.prototype.convertTo = function (A) { + return this.imod(A.ushln(this.shift)); + }), + (D.prototype.convertFrom = function (A) { + var e = this.imod(A.mul(this.rinv)); + return (e.red = null), e; + }), + (D.prototype.imul = function (A, e) { + if (A.isZero() || e.isZero()) + return (A.words[0] = 0), (A.length = 1), A; + var t = A.imul(e), + i = t + .maskn(this.shift) + .mul(this.minv) + .imaskn(this.shift) + .mul(this.m), + g = t.isub(i).iushrn(this.shift), + r = g; + return ( + g.cmp(this.m) >= 0 + ? (r = g.isub(this.m)) + : g.cmpn(0) < 0 && (r = g.iadd(this.m)), + r._forceRed(this) + ); + }), + (D.prototype.mul = function (A, e) { + if (A.isZero() || e.isZero()) return new r(0)._forceRed(this); + var t = A.mul(e), + i = t + .maskn(this.shift) + .mul(this.minv) + .imaskn(this.shift) + .mul(this.m), + g = t.isub(i).iushrn(this.shift), + n = g; + return ( + g.cmp(this.m) >= 0 + ? (n = g.isub(this.m)) + : g.cmpn(0) < 0 && (n = g.iadd(this.m)), + n._forceRed(this) + ); + }), + (D.prototype.invm = function (A) { + return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this); + }); + })(void 0 === e || e, this); + }, + { buffer: 19 }, + ], + 16: [ + function (A, e, t) { + "use strict"; + (t.byteLength = function (A) { + var e = o(A), + t = e[0], + i = e[1]; + return (3 * (t + i)) / 4 - i; + }), + (t.toByteArray = function (A) { + var e, + t, + i = o(A), + n = i[0], + B = i[1], + I = new r( + (function (A, e, t) { + return (3 * (e + t)) / 4 - t; + })(0, n, B) + ), + a = 0, + Q = B > 0 ? n - 4 : n; + for (t = 0; t < Q; t += 4) + (e = + (g[A.charCodeAt(t)] << 18) | + (g[A.charCodeAt(t + 1)] << 12) | + (g[A.charCodeAt(t + 2)] << 6) | + g[A.charCodeAt(t + 3)]), + (I[a++] = (e >> 16) & 255), + (I[a++] = (e >> 8) & 255), + (I[a++] = 255 & e); + 2 === B && + ((e = (g[A.charCodeAt(t)] << 2) | (g[A.charCodeAt(t + 1)] >> 4)), + (I[a++] = 255 & e)); + 1 === B && + ((e = + (g[A.charCodeAt(t)] << 10) | + (g[A.charCodeAt(t + 1)] << 4) | + (g[A.charCodeAt(t + 2)] >> 2)), + (I[a++] = (e >> 8) & 255), + (I[a++] = 255 & e)); + return I; + }), + (t.fromByteArray = function (A) { + for ( + var e, t = A.length, g = t % 3, r = [], n = 0, B = t - g; + n < B; + n += 16383 + ) + r.push(a(A, n, n + 16383 > B ? B : n + 16383)); + 1 === g + ? ((e = A[t - 1]), r.push(i[e >> 2] + i[(e << 4) & 63] + "==")) + : 2 === g && + ((e = (A[t - 2] << 8) + A[t - 1]), + r.push(i[e >> 10] + i[(e >> 4) & 63] + i[(e << 2) & 63] + "=")); + return r.join(""); + }); + for ( + var i = [], + g = [], + r = "undefined" != typeof Uint8Array ? Uint8Array : Array, + n = + "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", + B = 0, + I = n.length; + B < I; + ++B + ) + (i[B] = n[B]), (g[n.charCodeAt(B)] = B); + function o(A) { + var e = A.length; + if (e % 4 > 0) + throw new Error("Invalid string. Length must be a multiple of 4"); + var t = A.indexOf("="); + return -1 === t && (t = e), [t, t === e ? 0 : 4 - (t % 4)]; + } + function a(A, e, t) { + for (var g, r, n = [], B = e; B < t; B += 3) + (g = + ((A[B] << 16) & 16711680) + + ((A[B + 1] << 8) & 65280) + + (255 & A[B + 2])), + n.push( + i[((r = g) >> 18) & 63] + + i[(r >> 12) & 63] + + i[(r >> 6) & 63] + + i[63 & r] + ); + return n.join(""); + } + (g["-".charCodeAt(0)] = 62), (g["_".charCodeAt(0)] = 63); + }, + {}, + ], + 17: [ + function (A, e, t) { + !(function (e, t) { + "use strict"; + function i(A, e) { + if (!A) throw new Error(e || "Assertion failed"); + } + function g(A, e) { + A.super_ = e; + var t = function () {}; + (t.prototype = e.prototype), + (A.prototype = new t()), + (A.prototype.constructor = A); + } + function r(A, e, t) { + if (r.isBN(A)) return A; + (this.negative = 0), + (this.words = null), + (this.length = 0), + (this.red = null), + null !== A && + (("le" !== e && "be" !== e) || ((t = e), (e = 10)), + this._init(A || 0, e || 10, t || "be")); + } + var n; + "object" == typeof e ? (e.exports = r) : (t.BN = r), + (r.BN = r), + (r.wordSize = 26); + try { + n = A("buffer").Buffer; + } catch (A) {} + function B(A, e, t) { + for ( + var g = 0, r = Math.min(A.length, t), n = 0, B = e; + B < r; + B++ + ) { + var I, + o = A.charCodeAt(B) - 48; + (g <<= 4), + (g |= I = + o >= 49 && o <= 54 + ? o - 49 + 10 + : o >= 17 && o <= 22 + ? o - 17 + 10 + : o), + (n |= I); + } + return i(!(240 & n), "Invalid character in " + A), g; + } + function I(A, e, t, g) { + for ( + var r = 0, n = 0, B = Math.min(A.length, t), I = e; + I < B; + I++ + ) { + var o = A.charCodeAt(I) - 48; + (r *= g), + (n = o >= 49 ? o - 49 + 10 : o >= 17 ? o - 17 + 10 : o), + i(o >= 0 && n < g, "Invalid character"), + (r += n); + } + return r; + } + function o(A, e) { + (A.words = e.words), + (A.length = e.length), + (A.negative = e.negative), + (A.red = e.red); + } + if ( + ((r.isBN = function (A) { + return ( + A instanceof r || + (null !== A && + "object" == typeof A && + A.constructor.wordSize === r.wordSize && + Array.isArray(A.words)) + ); + }), + (r.max = function (A, e) { + return A.cmp(e) > 0 ? A : e; + }), + (r.min = function (A, e) { + return A.cmp(e) < 0 ? A : e; + }), + (r.prototype._init = function (A, e, t) { + if ("number" == typeof A) return this._initNumber(A, e, t); + if ("object" == typeof A) return this._initArray(A, e, t); + "hex" === e && (e = 16), i(e === (0 | e) && e >= 2 && e <= 36); + var g = 0; + "-" === (A = A.toString().replace(/\s+/g, ""))[0] && g++, + 16 === e ? this._parseHex(A, g) : this._parseBase(A, e, g), + "-" === A[0] && (this.negative = 1), + this._strip(), + "le" === t && this._initArray(this.toArray(), e, t); + }), + (r.prototype._initNumber = function (A, e, t) { + A < 0 && ((this.negative = 1), (A = -A)), + A < 67108864 + ? ((this.words = [67108863 & A]), (this.length = 1)) + : A < 4503599627370496 + ? ((this.words = [67108863 & A, (A / 67108864) & 67108863]), + (this.length = 2)) + : (i(A < 9007199254740992), + (this.words = [67108863 & A, (A / 67108864) & 67108863, 1]), + (this.length = 3)), + "le" === t && this._initArray(this.toArray(), e, t); + }), + (r.prototype._initArray = function (A, e, t) { + if ((i("number" == typeof A.length), A.length <= 0)) + return (this.words = [0]), (this.length = 1), this; + (this.length = Math.ceil(A.length / 3)), + (this.words = new Array(this.length)); + for (var g = 0; g < this.length; g++) this.words[g] = 0; + var r, + n, + B = 0; + if ("be" === t) + for (g = A.length - 1, r = 0; g >= 0; g -= 3) + (n = A[g] | (A[g - 1] << 8) | (A[g - 2] << 16)), + (this.words[r] |= (n << B) & 67108863), + (this.words[r + 1] = (n >>> (26 - B)) & 67108863), + (B += 24) >= 26 && ((B -= 26), r++); + else if ("le" === t) + for (g = 0, r = 0; g < A.length; g += 3) + (n = A[g] | (A[g + 1] << 8) | (A[g + 2] << 16)), + (this.words[r] |= (n << B) & 67108863), + (this.words[r + 1] = (n >>> (26 - B)) & 67108863), + (B += 24) >= 26 && ((B -= 26), r++); + return this._strip(); + }), + (r.prototype._parseHex = function (A, e) { + (this.length = Math.ceil((A.length - e) / 6)), + (this.words = new Array(this.length)); + for (var t = 0; t < this.length; t++) this.words[t] = 0; + var i, + g, + r = 0; + for (t = A.length - 6, i = 0; t >= e; t -= 6) + (g = B(A, t, t + 6)), + (this.words[i] |= (g << r) & 67108863), + (this.words[i + 1] |= (g >>> (26 - r)) & 4194303), + (r += 24) >= 26 && ((r -= 26), i++); + t + 6 !== e && + ((g = B(A, e, t + 6)), + (this.words[i] |= (g << r) & 67108863), + (this.words[i + 1] |= (g >>> (26 - r)) & 4194303)), + this._strip(); + }), + (r.prototype._parseBase = function (A, e, t) { + (this.words = [0]), (this.length = 1); + for (var i = 0, g = 1; g <= 67108863; g *= e) i++; + i--, (g = (g / e) | 0); + for ( + var r = A.length - t, + n = r % i, + B = Math.min(r, r - n) + t, + o = 0, + a = t; + a < B; + a += i + ) + (o = I(A, a, a + i, e)), + this.imuln(g), + this.words[0] + o < 67108864 + ? (this.words[0] += o) + : this._iaddn(o); + if (0 !== n) { + var Q = 1; + for (o = I(A, a, A.length, e), a = 0; a < n; a++) Q *= e; + this.imuln(Q), + this.words[0] + o < 67108864 + ? (this.words[0] += o) + : this._iaddn(o); + } + }), + (r.prototype.copy = function (A) { + A.words = new Array(this.length); + for (var e = 0; e < this.length; e++) A.words[e] = this.words[e]; + (A.length = this.length), + (A.negative = this.negative), + (A.red = this.red); + }), + (r.prototype._move = function (A) { + o(A, this); + }), + (r.prototype.clone = function () { + var A = new r(null); + return this.copy(A), A; + }), + (r.prototype._expand = function (A) { + for (; this.length < A; ) this.words[this.length++] = 0; + return this; + }), + (r.prototype._strip = function () { + for (; this.length > 1 && 0 === this.words[this.length - 1]; ) + this.length--; + return this._normSign(); + }), + (r.prototype._normSign = function () { + return ( + 1 === this.length && 0 === this.words[0] && (this.negative = 0), + this + ); + }), + "undefined" != typeof Symbol && "function" == typeof Symbol.for) + ) + try { + r.prototype[Symbol.for("nodejs.util.inspect.custom")] = a; + } catch (A) { + r.prototype.inspect = a; + } + else r.prototype.inspect = a; + function a() { + return (this.red ? ""; + } + var Q = [ + "", + "0", + "00", + "000", + "0000", + "00000", + "000000", + "0000000", + "00000000", + "000000000", + "0000000000", + "00000000000", + "000000000000", + "0000000000000", + "00000000000000", + "000000000000000", + "0000000000000000", + "00000000000000000", + "000000000000000000", + "0000000000000000000", + "00000000000000000000", + "000000000000000000000", + "0000000000000000000000", + "00000000000000000000000", + "000000000000000000000000", + "0000000000000000000000000", + ], + C = [ + 0, 0, 25, 16, 12, 11, 10, 9, 8, 8, 7, 7, 7, 7, 6, 6, 6, 6, 6, 6, + 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, + ], + s = [ + 0, 0, 33554432, 43046721, 16777216, 48828125, 60466176, 40353607, + 16777216, 43046721, 1e7, 19487171, 35831808, 62748517, 7529536, + 11390625, 16777216, 24137569, 34012224, 47045881, 64e6, 4084101, + 5153632, 6436343, 7962624, 9765625, 11881376, 14348907, 17210368, + 20511149, 243e5, 28629151, 33554432, 39135393, 45435424, 52521875, + 60466176, + ]; + (r.prototype.toString = function (A, e) { + var t; + if (((A = A || 10), (e = 0 | e || 1), 16 === A || "hex" === A)) { + t = ""; + for (var g = 0, r = 0, n = 0; n < this.length; n++) { + var B = this.words[n], + I = (16777215 & ((B << g) | r)).toString(16); + (t = + 0 !== (r = (B >>> (24 - g)) & 16777215) || + n !== this.length - 1 + ? Q[6 - I.length] + I + t + : I + t), + (g += 2) >= 26 && ((g -= 26), n--); + } + for (0 !== r && (t = r.toString(16) + t); t.length % e != 0; ) + t = "0" + t; + return 0 !== this.negative && (t = "-" + t), t; + } + if (A === (0 | A) && A >= 2 && A <= 36) { + var o = C[A], + a = s[A]; + t = ""; + var c = this.clone(); + for (c.negative = 0; !c.isZero(); ) { + var h = c.modrn(a).toString(A); + t = (c = c.idivn(a)).isZero() ? h + t : Q[o - h.length] + h + t; + } + for (this.isZero() && (t = "0" + t); t.length % e != 0; ) + t = "0" + t; + return 0 !== this.negative && (t = "-" + t), t; + } + i(!1, "Base should be between 2 and 36"); + }), + (r.prototype.toNumber = function () { + var A = this.words[0]; + return ( + 2 === this.length + ? (A += 67108864 * this.words[1]) + : 3 === this.length && 1 === this.words[2] + ? (A += 4503599627370496 + 67108864 * this.words[1]) + : this.length > 2 && + i(!1, "Number can only safely store up to 53 bits"), + 0 !== this.negative ? -A : A + ); + }), + (r.prototype.toJSON = function () { + return this.toString(16, 2); + }), + n && + (r.prototype.toBuffer = function (A, e) { + return this.toArrayLike(n, A, e); + }), + (r.prototype.toArray = function (A, e) { + return this.toArrayLike(Array, A, e); + }); + function c(A, e, t) { + t.negative = e.negative ^ A.negative; + var i = (A.length + e.length) | 0; + (t.length = i), (i = (i - 1) | 0); + var g = 0 | A.words[0], + r = 0 | e.words[0], + n = g * r, + B = 67108863 & n, + I = (n / 67108864) | 0; + t.words[0] = B; + for (var o = 1; o < i; o++) { + for ( + var a = I >>> 26, + Q = 67108863 & I, + C = Math.min(o, e.length - 1), + s = Math.max(0, o - A.length + 1); + s <= C; + s++ + ) { + var c = (o - s) | 0; + (a += + ((n = (g = 0 | A.words[c]) * (r = 0 | e.words[s]) + Q) / + 67108864) | + 0), + (Q = 67108863 & n); + } + (t.words[o] = 0 | Q), (I = 0 | a); + } + return 0 !== I ? (t.words[o] = 0 | I) : t.length--, t._strip(); + } + (r.prototype.toArrayLike = function (A, e, t) { + this._strip(); + var g = this.byteLength(), + r = t || Math.max(1, g); + i(g <= r, "byte array longer than desired length"), + i(r > 0, "Requested array length <= 0"); + var n = (function (A, e) { + return A.allocUnsafe ? A.allocUnsafe(e) : new A(e); + })(A, r); + return this["_toArrayLike" + ("le" === e ? "LE" : "BE")](n, g), n; + }), + (r.prototype._toArrayLikeLE = function (A, e) { + for (var t = 0, i = 0, g = 0, r = 0; g < this.length; g++) { + var n = (this.words[g] << r) | i; + (A[t++] = 255 & n), + t < A.length && (A[t++] = (n >> 8) & 255), + t < A.length && (A[t++] = (n >> 16) & 255), + 6 === r + ? (t < A.length && (A[t++] = (n >> 24) & 255), + (i = 0), + (r = 0)) + : ((i = n >>> 24), (r += 2)); + } + if (t < A.length) for (A[t++] = i; t < A.length; ) A[t++] = 0; + }), + (r.prototype._toArrayLikeBE = function (A, e) { + for ( + var t = A.length - 1, i = 0, g = 0, r = 0; + g < this.length; + g++ + ) { + var n = (this.words[g] << r) | i; + (A[t--] = 255 & n), + t >= 0 && (A[t--] = (n >> 8) & 255), + t >= 0 && (A[t--] = (n >> 16) & 255), + 6 === r + ? (t >= 0 && (A[t--] = (n >> 24) & 255), (i = 0), (r = 0)) + : ((i = n >>> 24), (r += 2)); + } + if (t >= 0) for (A[t--] = i; t >= 0; ) A[t--] = 0; + }), + Math.clz32 + ? (r.prototype._countBits = function (A) { + return 32 - Math.clz32(A); + }) + : (r.prototype._countBits = function (A) { + var e = A, + t = 0; + return ( + e >= 4096 && ((t += 13), (e >>>= 13)), + e >= 64 && ((t += 7), (e >>>= 7)), + e >= 8 && ((t += 4), (e >>>= 4)), + e >= 2 && ((t += 2), (e >>>= 2)), + t + e + ); + }), + (r.prototype._zeroBits = function (A) { + if (0 === A) return 26; + var e = A, + t = 0; + return ( + 0 == (8191 & e) && ((t += 13), (e >>>= 13)), + 0 == (127 & e) && ((t += 7), (e >>>= 7)), + 0 == (15 & e) && ((t += 4), (e >>>= 4)), + 0 == (3 & e) && ((t += 2), (e >>>= 2)), + 0 == (1 & e) && t++, + t + ); + }), + (r.prototype.bitLength = function () { + var A = this.words[this.length - 1], + e = this._countBits(A); + return 26 * (this.length - 1) + e; + }), + (r.prototype.zeroBits = function () { + if (this.isZero()) return 0; + for (var A = 0, e = 0; e < this.length; e++) { + var t = this._zeroBits(this.words[e]); + if (((A += t), 26 !== t)) break; + } + return A; + }), + (r.prototype.byteLength = function () { + return Math.ceil(this.bitLength() / 8); + }), + (r.prototype.toTwos = function (A) { + return 0 !== this.negative + ? this.abs().inotn(A).iaddn(1) + : this.clone(); + }), + (r.prototype.fromTwos = function (A) { + return this.testn(A - 1) + ? this.notn(A).iaddn(1).ineg() + : this.clone(); + }), + (r.prototype.isNeg = function () { + return 0 !== this.negative; + }), + (r.prototype.neg = function () { + return this.clone().ineg(); + }), + (r.prototype.ineg = function () { + return this.isZero() || (this.negative ^= 1), this; + }), + (r.prototype.iuor = function (A) { + for (; this.length < A.length; ) this.words[this.length++] = 0; + for (var e = 0; e < A.length; e++) + this.words[e] = this.words[e] | A.words[e]; + return this._strip(); + }), + (r.prototype.ior = function (A) { + return i(0 == (this.negative | A.negative)), this.iuor(A); + }), + (r.prototype.or = function (A) { + return this.length > A.length + ? this.clone().ior(A) + : A.clone().ior(this); + }), + (r.prototype.uor = function (A) { + return this.length > A.length + ? this.clone().iuor(A) + : A.clone().iuor(this); + }), + (r.prototype.iuand = function (A) { + var e; + e = this.length > A.length ? A : this; + for (var t = 0; t < e.length; t++) + this.words[t] = this.words[t] & A.words[t]; + return (this.length = e.length), this._strip(); + }), + (r.prototype.iand = function (A) { + return i(0 == (this.negative | A.negative)), this.iuand(A); + }), + (r.prototype.and = function (A) { + return this.length > A.length + ? this.clone().iand(A) + : A.clone().iand(this); + }), + (r.prototype.uand = function (A) { + return this.length > A.length + ? this.clone().iuand(A) + : A.clone().iuand(this); + }), + (r.prototype.iuxor = function (A) { + var e, t; + this.length > A.length + ? ((e = this), (t = A)) + : ((e = A), (t = this)); + for (var i = 0; i < t.length; i++) + this.words[i] = e.words[i] ^ t.words[i]; + if (this !== e) + for (; i < e.length; i++) this.words[i] = e.words[i]; + return (this.length = e.length), this._strip(); + }), + (r.prototype.ixor = function (A) { + return i(0 == (this.negative | A.negative)), this.iuxor(A); + }), + (r.prototype.xor = function (A) { + return this.length > A.length + ? this.clone().ixor(A) + : A.clone().ixor(this); + }), + (r.prototype.uxor = function (A) { + return this.length > A.length + ? this.clone().iuxor(A) + : A.clone().iuxor(this); + }), + (r.prototype.inotn = function (A) { + i("number" == typeof A && A >= 0); + var e = 0 | Math.ceil(A / 26), + t = A % 26; + this._expand(e), t > 0 && e--; + for (var g = 0; g < e; g++) + this.words[g] = 67108863 & ~this.words[g]; + return ( + t > 0 && + (this.words[g] = ~this.words[g] & (67108863 >> (26 - t))), + this._strip() + ); + }), + (r.prototype.notn = function (A) { + return this.clone().inotn(A); + }), + (r.prototype.setn = function (A, e) { + i("number" == typeof A && A >= 0); + var t = (A / 26) | 0, + g = A % 26; + return ( + this._expand(t + 1), + (this.words[t] = e + ? this.words[t] | (1 << g) + : this.words[t] & ~(1 << g)), + this._strip() + ); + }), + (r.prototype.iadd = function (A) { + var e, t, i; + if (0 !== this.negative && 0 === A.negative) + return ( + (this.negative = 0), + (e = this.isub(A)), + (this.negative ^= 1), + this._normSign() + ); + if (0 === this.negative && 0 !== A.negative) + return ( + (A.negative = 0), + (e = this.isub(A)), + (A.negative = 1), + e._normSign() + ); + this.length > A.length + ? ((t = this), (i = A)) + : ((t = A), (i = this)); + for (var g = 0, r = 0; r < i.length; r++) + (e = (0 | t.words[r]) + (0 | i.words[r]) + g), + (this.words[r] = 67108863 & e), + (g = e >>> 26); + for (; 0 !== g && r < t.length; r++) + (e = (0 | t.words[r]) + g), + (this.words[r] = 67108863 & e), + (g = e >>> 26); + if (((this.length = t.length), 0 !== g)) + (this.words[this.length] = g), this.length++; + else if (t !== this) + for (; r < t.length; r++) this.words[r] = t.words[r]; + return this; + }), + (r.prototype.add = function (A) { + var e; + return 0 !== A.negative && 0 === this.negative + ? ((A.negative = 0), (e = this.sub(A)), (A.negative ^= 1), e) + : 0 === A.negative && 0 !== this.negative + ? ((this.negative = 0), + (e = A.sub(this)), + (this.negative = 1), + e) + : this.length > A.length + ? this.clone().iadd(A) + : A.clone().iadd(this); + }), + (r.prototype.isub = function (A) { + if (0 !== A.negative) { + A.negative = 0; + var e = this.iadd(A); + return (A.negative = 1), e._normSign(); + } + if (0 !== this.negative) + return ( + (this.negative = 0), + this.iadd(A), + (this.negative = 1), + this._normSign() + ); + var t, + i, + g = this.cmp(A); + if (0 === g) + return ( + (this.negative = 0), + (this.length = 1), + (this.words[0] = 0), + this + ); + g > 0 ? ((t = this), (i = A)) : ((t = A), (i = this)); + for (var r = 0, n = 0; n < i.length; n++) + (r = (e = (0 | t.words[n]) - (0 | i.words[n]) + r) >> 26), + (this.words[n] = 67108863 & e); + for (; 0 !== r && n < t.length; n++) + (r = (e = (0 | t.words[n]) + r) >> 26), + (this.words[n] = 67108863 & e); + if (0 === r && n < t.length && t !== this) + for (; n < t.length; n++) this.words[n] = t.words[n]; + return ( + (this.length = Math.max(this.length, n)), + t !== this && (this.negative = 1), + this._strip() + ); + }), + (r.prototype.sub = function (A) { + return this.clone().isub(A); + }); + var h = function (A, e, t) { + var i, + g, + r, + n = A.words, + B = e.words, + I = t.words, + o = 0, + a = 0 | n[0], + Q = 8191 & a, + C = a >>> 13, + s = 0 | n[1], + c = 8191 & s, + h = s >>> 13, + f = 0 | n[2], + E = 8191 & f, + u = f >>> 13, + d = 0 | n[3], + l = 8191 & d, + w = d >>> 13, + p = 0 | n[4], + D = 8191 & p, + b = p >>> 13, + y = 0 | n[5], + M = 8191 & y, + m = y >>> 13, + G = 0 | n[6], + k = 8191 & G, + F = G >>> 13, + N = 0 | n[7], + S = 8191 & N, + Y = N >>> 13, + v = 0 | n[8], + K = 8191 & v, + U = v >>> 13, + J = 0 | n[9], + H = 8191 & J, + R = J >>> 13, + q = 0 | B[0], + L = 8191 & q, + x = q >>> 13, + Z = 0 | B[1], + j = 8191 & Z, + W = Z >>> 13, + O = 0 | B[2], + P = 8191 & O, + V = O >>> 13, + X = 0 | B[3], + z = 8191 & X, + T = X >>> 13, + _ = 0 | B[4], + $ = 8191 & _, + AA = _ >>> 13, + eA = 0 | B[5], + tA = 8191 & eA, + iA = eA >>> 13, + gA = 0 | B[6], + rA = 8191 & gA, + nA = gA >>> 13, + BA = 0 | B[7], + IA = 8191 & BA, + oA = BA >>> 13, + aA = 0 | B[8], + QA = 8191 & aA, + CA = aA >>> 13, + sA = 0 | B[9], + cA = 8191 & sA, + hA = sA >>> 13; + (t.negative = A.negative ^ e.negative), (t.length = 19); + var fA = + (((o + (i = Math.imul(Q, L))) | 0) + + ((8191 & (g = ((g = Math.imul(Q, x)) + Math.imul(C, L)) | 0)) << + 13)) | + 0; + (o = + ((((r = Math.imul(C, x)) + (g >>> 13)) | 0) + (fA >>> 26)) | 0), + (fA &= 67108863), + (i = Math.imul(c, L)), + (g = ((g = Math.imul(c, x)) + Math.imul(h, L)) | 0), + (r = Math.imul(h, x)); + var EA = + (((o + (i = (i + Math.imul(Q, j)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, W)) | 0) + Math.imul(C, j)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, W)) | 0) + (g >>> 13)) | 0) + + (EA >>> 26)) | + 0), + (EA &= 67108863), + (i = Math.imul(E, L)), + (g = ((g = Math.imul(E, x)) + Math.imul(u, L)) | 0), + (r = Math.imul(u, x)), + (i = (i + Math.imul(c, j)) | 0), + (g = ((g = (g + Math.imul(c, W)) | 0) + Math.imul(h, j)) | 0), + (r = (r + Math.imul(h, W)) | 0); + var uA = + (((o + (i = (i + Math.imul(Q, P)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, V)) | 0) + Math.imul(C, P)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, V)) | 0) + (g >>> 13)) | 0) + + (uA >>> 26)) | + 0), + (uA &= 67108863), + (i = Math.imul(l, L)), + (g = ((g = Math.imul(l, x)) + Math.imul(w, L)) | 0), + (r = Math.imul(w, x)), + (i = (i + Math.imul(E, j)) | 0), + (g = ((g = (g + Math.imul(E, W)) | 0) + Math.imul(u, j)) | 0), + (r = (r + Math.imul(u, W)) | 0), + (i = (i + Math.imul(c, P)) | 0), + (g = ((g = (g + Math.imul(c, V)) | 0) + Math.imul(h, P)) | 0), + (r = (r + Math.imul(h, V)) | 0); + var dA = + (((o + (i = (i + Math.imul(Q, z)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, T)) | 0) + Math.imul(C, z)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, T)) | 0) + (g >>> 13)) | 0) + + (dA >>> 26)) | + 0), + (dA &= 67108863), + (i = Math.imul(D, L)), + (g = ((g = Math.imul(D, x)) + Math.imul(b, L)) | 0), + (r = Math.imul(b, x)), + (i = (i + Math.imul(l, j)) | 0), + (g = ((g = (g + Math.imul(l, W)) | 0) + Math.imul(w, j)) | 0), + (r = (r + Math.imul(w, W)) | 0), + (i = (i + Math.imul(E, P)) | 0), + (g = ((g = (g + Math.imul(E, V)) | 0) + Math.imul(u, P)) | 0), + (r = (r + Math.imul(u, V)) | 0), + (i = (i + Math.imul(c, z)) | 0), + (g = ((g = (g + Math.imul(c, T)) | 0) + Math.imul(h, z)) | 0), + (r = (r + Math.imul(h, T)) | 0); + var lA = + (((o + (i = (i + Math.imul(Q, $)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, AA)) | 0) + Math.imul(C, $)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, AA)) | 0) + (g >>> 13)) | 0) + + (lA >>> 26)) | + 0), + (lA &= 67108863), + (i = Math.imul(M, L)), + (g = ((g = Math.imul(M, x)) + Math.imul(m, L)) | 0), + (r = Math.imul(m, x)), + (i = (i + Math.imul(D, j)) | 0), + (g = ((g = (g + Math.imul(D, W)) | 0) + Math.imul(b, j)) | 0), + (r = (r + Math.imul(b, W)) | 0), + (i = (i + Math.imul(l, P)) | 0), + (g = ((g = (g + Math.imul(l, V)) | 0) + Math.imul(w, P)) | 0), + (r = (r + Math.imul(w, V)) | 0), + (i = (i + Math.imul(E, z)) | 0), + (g = ((g = (g + Math.imul(E, T)) | 0) + Math.imul(u, z)) | 0), + (r = (r + Math.imul(u, T)) | 0), + (i = (i + Math.imul(c, $)) | 0), + (g = ((g = (g + Math.imul(c, AA)) | 0) + Math.imul(h, $)) | 0), + (r = (r + Math.imul(h, AA)) | 0); + var wA = + (((o + (i = (i + Math.imul(Q, tA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, iA)) | 0) + Math.imul(C, tA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, iA)) | 0) + (g >>> 13)) | 0) + + (wA >>> 26)) | + 0), + (wA &= 67108863), + (i = Math.imul(k, L)), + (g = ((g = Math.imul(k, x)) + Math.imul(F, L)) | 0), + (r = Math.imul(F, x)), + (i = (i + Math.imul(M, j)) | 0), + (g = ((g = (g + Math.imul(M, W)) | 0) + Math.imul(m, j)) | 0), + (r = (r + Math.imul(m, W)) | 0), + (i = (i + Math.imul(D, P)) | 0), + (g = ((g = (g + Math.imul(D, V)) | 0) + Math.imul(b, P)) | 0), + (r = (r + Math.imul(b, V)) | 0), + (i = (i + Math.imul(l, z)) | 0), + (g = ((g = (g + Math.imul(l, T)) | 0) + Math.imul(w, z)) | 0), + (r = (r + Math.imul(w, T)) | 0), + (i = (i + Math.imul(E, $)) | 0), + (g = ((g = (g + Math.imul(E, AA)) | 0) + Math.imul(u, $)) | 0), + (r = (r + Math.imul(u, AA)) | 0), + (i = (i + Math.imul(c, tA)) | 0), + (g = ((g = (g + Math.imul(c, iA)) | 0) + Math.imul(h, tA)) | 0), + (r = (r + Math.imul(h, iA)) | 0); + var pA = + (((o + (i = (i + Math.imul(Q, rA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, nA)) | 0) + Math.imul(C, rA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, nA)) | 0) + (g >>> 13)) | 0) + + (pA >>> 26)) | + 0), + (pA &= 67108863), + (i = Math.imul(S, L)), + (g = ((g = Math.imul(S, x)) + Math.imul(Y, L)) | 0), + (r = Math.imul(Y, x)), + (i = (i + Math.imul(k, j)) | 0), + (g = ((g = (g + Math.imul(k, W)) | 0) + Math.imul(F, j)) | 0), + (r = (r + Math.imul(F, W)) | 0), + (i = (i + Math.imul(M, P)) | 0), + (g = ((g = (g + Math.imul(M, V)) | 0) + Math.imul(m, P)) | 0), + (r = (r + Math.imul(m, V)) | 0), + (i = (i + Math.imul(D, z)) | 0), + (g = ((g = (g + Math.imul(D, T)) | 0) + Math.imul(b, z)) | 0), + (r = (r + Math.imul(b, T)) | 0), + (i = (i + Math.imul(l, $)) | 0), + (g = ((g = (g + Math.imul(l, AA)) | 0) + Math.imul(w, $)) | 0), + (r = (r + Math.imul(w, AA)) | 0), + (i = (i + Math.imul(E, tA)) | 0), + (g = ((g = (g + Math.imul(E, iA)) | 0) + Math.imul(u, tA)) | 0), + (r = (r + Math.imul(u, iA)) | 0), + (i = (i + Math.imul(c, rA)) | 0), + (g = ((g = (g + Math.imul(c, nA)) | 0) + Math.imul(h, rA)) | 0), + (r = (r + Math.imul(h, nA)) | 0); + var DA = + (((o + (i = (i + Math.imul(Q, IA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, oA)) | 0) + Math.imul(C, IA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, oA)) | 0) + (g >>> 13)) | 0) + + (DA >>> 26)) | + 0), + (DA &= 67108863), + (i = Math.imul(K, L)), + (g = ((g = Math.imul(K, x)) + Math.imul(U, L)) | 0), + (r = Math.imul(U, x)), + (i = (i + Math.imul(S, j)) | 0), + (g = ((g = (g + Math.imul(S, W)) | 0) + Math.imul(Y, j)) | 0), + (r = (r + Math.imul(Y, W)) | 0), + (i = (i + Math.imul(k, P)) | 0), + (g = ((g = (g + Math.imul(k, V)) | 0) + Math.imul(F, P)) | 0), + (r = (r + Math.imul(F, V)) | 0), + (i = (i + Math.imul(M, z)) | 0), + (g = ((g = (g + Math.imul(M, T)) | 0) + Math.imul(m, z)) | 0), + (r = (r + Math.imul(m, T)) | 0), + (i = (i + Math.imul(D, $)) | 0), + (g = ((g = (g + Math.imul(D, AA)) | 0) + Math.imul(b, $)) | 0), + (r = (r + Math.imul(b, AA)) | 0), + (i = (i + Math.imul(l, tA)) | 0), + (g = ((g = (g + Math.imul(l, iA)) | 0) + Math.imul(w, tA)) | 0), + (r = (r + Math.imul(w, iA)) | 0), + (i = (i + Math.imul(E, rA)) | 0), + (g = ((g = (g + Math.imul(E, nA)) | 0) + Math.imul(u, rA)) | 0), + (r = (r + Math.imul(u, nA)) | 0), + (i = (i + Math.imul(c, IA)) | 0), + (g = ((g = (g + Math.imul(c, oA)) | 0) + Math.imul(h, IA)) | 0), + (r = (r + Math.imul(h, oA)) | 0); + var bA = + (((o + (i = (i + Math.imul(Q, QA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, CA)) | 0) + Math.imul(C, QA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, CA)) | 0) + (g >>> 13)) | 0) + + (bA >>> 26)) | + 0), + (bA &= 67108863), + (i = Math.imul(H, L)), + (g = ((g = Math.imul(H, x)) + Math.imul(R, L)) | 0), + (r = Math.imul(R, x)), + (i = (i + Math.imul(K, j)) | 0), + (g = ((g = (g + Math.imul(K, W)) | 0) + Math.imul(U, j)) | 0), + (r = (r + Math.imul(U, W)) | 0), + (i = (i + Math.imul(S, P)) | 0), + (g = ((g = (g + Math.imul(S, V)) | 0) + Math.imul(Y, P)) | 0), + (r = (r + Math.imul(Y, V)) | 0), + (i = (i + Math.imul(k, z)) | 0), + (g = ((g = (g + Math.imul(k, T)) | 0) + Math.imul(F, z)) | 0), + (r = (r + Math.imul(F, T)) | 0), + (i = (i + Math.imul(M, $)) | 0), + (g = ((g = (g + Math.imul(M, AA)) | 0) + Math.imul(m, $)) | 0), + (r = (r + Math.imul(m, AA)) | 0), + (i = (i + Math.imul(D, tA)) | 0), + (g = ((g = (g + Math.imul(D, iA)) | 0) + Math.imul(b, tA)) | 0), + (r = (r + Math.imul(b, iA)) | 0), + (i = (i + Math.imul(l, rA)) | 0), + (g = ((g = (g + Math.imul(l, nA)) | 0) + Math.imul(w, rA)) | 0), + (r = (r + Math.imul(w, nA)) | 0), + (i = (i + Math.imul(E, IA)) | 0), + (g = ((g = (g + Math.imul(E, oA)) | 0) + Math.imul(u, IA)) | 0), + (r = (r + Math.imul(u, oA)) | 0), + (i = (i + Math.imul(c, QA)) | 0), + (g = ((g = (g + Math.imul(c, CA)) | 0) + Math.imul(h, QA)) | 0), + (r = (r + Math.imul(h, CA)) | 0); + var yA = + (((o + (i = (i + Math.imul(Q, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, hA)) | 0) + Math.imul(C, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, hA)) | 0) + (g >>> 13)) | 0) + + (yA >>> 26)) | + 0), + (yA &= 67108863), + (i = Math.imul(H, j)), + (g = ((g = Math.imul(H, W)) + Math.imul(R, j)) | 0), + (r = Math.imul(R, W)), + (i = (i + Math.imul(K, P)) | 0), + (g = ((g = (g + Math.imul(K, V)) | 0) + Math.imul(U, P)) | 0), + (r = (r + Math.imul(U, V)) | 0), + (i = (i + Math.imul(S, z)) | 0), + (g = ((g = (g + Math.imul(S, T)) | 0) + Math.imul(Y, z)) | 0), + (r = (r + Math.imul(Y, T)) | 0), + (i = (i + Math.imul(k, $)) | 0), + (g = ((g = (g + Math.imul(k, AA)) | 0) + Math.imul(F, $)) | 0), + (r = (r + Math.imul(F, AA)) | 0), + (i = (i + Math.imul(M, tA)) | 0), + (g = ((g = (g + Math.imul(M, iA)) | 0) + Math.imul(m, tA)) | 0), + (r = (r + Math.imul(m, iA)) | 0), + (i = (i + Math.imul(D, rA)) | 0), + (g = ((g = (g + Math.imul(D, nA)) | 0) + Math.imul(b, rA)) | 0), + (r = (r + Math.imul(b, nA)) | 0), + (i = (i + Math.imul(l, IA)) | 0), + (g = ((g = (g + Math.imul(l, oA)) | 0) + Math.imul(w, IA)) | 0), + (r = (r + Math.imul(w, oA)) | 0), + (i = (i + Math.imul(E, QA)) | 0), + (g = ((g = (g + Math.imul(E, CA)) | 0) + Math.imul(u, QA)) | 0), + (r = (r + Math.imul(u, CA)) | 0); + var MA = + (((o + (i = (i + Math.imul(c, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(c, hA)) | 0) + Math.imul(h, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(h, hA)) | 0) + (g >>> 13)) | 0) + + (MA >>> 26)) | + 0), + (MA &= 67108863), + (i = Math.imul(H, P)), + (g = ((g = Math.imul(H, V)) + Math.imul(R, P)) | 0), + (r = Math.imul(R, V)), + (i = (i + Math.imul(K, z)) | 0), + (g = ((g = (g + Math.imul(K, T)) | 0) + Math.imul(U, z)) | 0), + (r = (r + Math.imul(U, T)) | 0), + (i = (i + Math.imul(S, $)) | 0), + (g = ((g = (g + Math.imul(S, AA)) | 0) + Math.imul(Y, $)) | 0), + (r = (r + Math.imul(Y, AA)) | 0), + (i = (i + Math.imul(k, tA)) | 0), + (g = ((g = (g + Math.imul(k, iA)) | 0) + Math.imul(F, tA)) | 0), + (r = (r + Math.imul(F, iA)) | 0), + (i = (i + Math.imul(M, rA)) | 0), + (g = ((g = (g + Math.imul(M, nA)) | 0) + Math.imul(m, rA)) | 0), + (r = (r + Math.imul(m, nA)) | 0), + (i = (i + Math.imul(D, IA)) | 0), + (g = ((g = (g + Math.imul(D, oA)) | 0) + Math.imul(b, IA)) | 0), + (r = (r + Math.imul(b, oA)) | 0), + (i = (i + Math.imul(l, QA)) | 0), + (g = ((g = (g + Math.imul(l, CA)) | 0) + Math.imul(w, QA)) | 0), + (r = (r + Math.imul(w, CA)) | 0); + var mA = + (((o + (i = (i + Math.imul(E, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(E, hA)) | 0) + Math.imul(u, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(u, hA)) | 0) + (g >>> 13)) | 0) + + (mA >>> 26)) | + 0), + (mA &= 67108863), + (i = Math.imul(H, z)), + (g = ((g = Math.imul(H, T)) + Math.imul(R, z)) | 0), + (r = Math.imul(R, T)), + (i = (i + Math.imul(K, $)) | 0), + (g = ((g = (g + Math.imul(K, AA)) | 0) + Math.imul(U, $)) | 0), + (r = (r + Math.imul(U, AA)) | 0), + (i = (i + Math.imul(S, tA)) | 0), + (g = ((g = (g + Math.imul(S, iA)) | 0) + Math.imul(Y, tA)) | 0), + (r = (r + Math.imul(Y, iA)) | 0), + (i = (i + Math.imul(k, rA)) | 0), + (g = ((g = (g + Math.imul(k, nA)) | 0) + Math.imul(F, rA)) | 0), + (r = (r + Math.imul(F, nA)) | 0), + (i = (i + Math.imul(M, IA)) | 0), + (g = ((g = (g + Math.imul(M, oA)) | 0) + Math.imul(m, IA)) | 0), + (r = (r + Math.imul(m, oA)) | 0), + (i = (i + Math.imul(D, QA)) | 0), + (g = ((g = (g + Math.imul(D, CA)) | 0) + Math.imul(b, QA)) | 0), + (r = (r + Math.imul(b, CA)) | 0); + var GA = + (((o + (i = (i + Math.imul(l, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(l, hA)) | 0) + Math.imul(w, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(w, hA)) | 0) + (g >>> 13)) | 0) + + (GA >>> 26)) | + 0), + (GA &= 67108863), + (i = Math.imul(H, $)), + (g = ((g = Math.imul(H, AA)) + Math.imul(R, $)) | 0), + (r = Math.imul(R, AA)), + (i = (i + Math.imul(K, tA)) | 0), + (g = ((g = (g + Math.imul(K, iA)) | 0) + Math.imul(U, tA)) | 0), + (r = (r + Math.imul(U, iA)) | 0), + (i = (i + Math.imul(S, rA)) | 0), + (g = ((g = (g + Math.imul(S, nA)) | 0) + Math.imul(Y, rA)) | 0), + (r = (r + Math.imul(Y, nA)) | 0), + (i = (i + Math.imul(k, IA)) | 0), + (g = ((g = (g + Math.imul(k, oA)) | 0) + Math.imul(F, IA)) | 0), + (r = (r + Math.imul(F, oA)) | 0), + (i = (i + Math.imul(M, QA)) | 0), + (g = ((g = (g + Math.imul(M, CA)) | 0) + Math.imul(m, QA)) | 0), + (r = (r + Math.imul(m, CA)) | 0); + var kA = + (((o + (i = (i + Math.imul(D, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(D, hA)) | 0) + Math.imul(b, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(b, hA)) | 0) + (g >>> 13)) | 0) + + (kA >>> 26)) | + 0), + (kA &= 67108863), + (i = Math.imul(H, tA)), + (g = ((g = Math.imul(H, iA)) + Math.imul(R, tA)) | 0), + (r = Math.imul(R, iA)), + (i = (i + Math.imul(K, rA)) | 0), + (g = ((g = (g + Math.imul(K, nA)) | 0) + Math.imul(U, rA)) | 0), + (r = (r + Math.imul(U, nA)) | 0), + (i = (i + Math.imul(S, IA)) | 0), + (g = ((g = (g + Math.imul(S, oA)) | 0) + Math.imul(Y, IA)) | 0), + (r = (r + Math.imul(Y, oA)) | 0), + (i = (i + Math.imul(k, QA)) | 0), + (g = ((g = (g + Math.imul(k, CA)) | 0) + Math.imul(F, QA)) | 0), + (r = (r + Math.imul(F, CA)) | 0); + var FA = + (((o + (i = (i + Math.imul(M, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(M, hA)) | 0) + Math.imul(m, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(m, hA)) | 0) + (g >>> 13)) | 0) + + (FA >>> 26)) | + 0), + (FA &= 67108863), + (i = Math.imul(H, rA)), + (g = ((g = Math.imul(H, nA)) + Math.imul(R, rA)) | 0), + (r = Math.imul(R, nA)), + (i = (i + Math.imul(K, IA)) | 0), + (g = ((g = (g + Math.imul(K, oA)) | 0) + Math.imul(U, IA)) | 0), + (r = (r + Math.imul(U, oA)) | 0), + (i = (i + Math.imul(S, QA)) | 0), + (g = ((g = (g + Math.imul(S, CA)) | 0) + Math.imul(Y, QA)) | 0), + (r = (r + Math.imul(Y, CA)) | 0); + var NA = + (((o + (i = (i + Math.imul(k, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(k, hA)) | 0) + Math.imul(F, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(F, hA)) | 0) + (g >>> 13)) | 0) + + (NA >>> 26)) | + 0), + (NA &= 67108863), + (i = Math.imul(H, IA)), + (g = ((g = Math.imul(H, oA)) + Math.imul(R, IA)) | 0), + (r = Math.imul(R, oA)), + (i = (i + Math.imul(K, QA)) | 0), + (g = ((g = (g + Math.imul(K, CA)) | 0) + Math.imul(U, QA)) | 0), + (r = (r + Math.imul(U, CA)) | 0); + var SA = + (((o + (i = (i + Math.imul(S, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(S, hA)) | 0) + Math.imul(Y, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(Y, hA)) | 0) + (g >>> 13)) | 0) + + (SA >>> 26)) | + 0), + (SA &= 67108863), + (i = Math.imul(H, QA)), + (g = ((g = Math.imul(H, CA)) + Math.imul(R, QA)) | 0), + (r = Math.imul(R, CA)); + var YA = + (((o + (i = (i + Math.imul(K, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(K, hA)) | 0) + Math.imul(U, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(U, hA)) | 0) + (g >>> 13)) | 0) + + (YA >>> 26)) | + 0), + (YA &= 67108863); + var vA = + (((o + (i = Math.imul(H, cA))) | 0) + + ((8191 & + (g = ((g = Math.imul(H, hA)) + Math.imul(R, cA)) | 0)) << + 13)) | + 0; + return ( + (o = + ((((r = Math.imul(R, hA)) + (g >>> 13)) | 0) + (vA >>> 26)) | + 0), + (vA &= 67108863), + (I[0] = fA), + (I[1] = EA), + (I[2] = uA), + (I[3] = dA), + (I[4] = lA), + (I[5] = wA), + (I[6] = pA), + (I[7] = DA), + (I[8] = bA), + (I[9] = yA), + (I[10] = MA), + (I[11] = mA), + (I[12] = GA), + (I[13] = kA), + (I[14] = FA), + (I[15] = NA), + (I[16] = SA), + (I[17] = YA), + (I[18] = vA), + 0 !== o && ((I[19] = o), t.length++), + t + ); + }; + function f(A, e, t) { + (t.negative = e.negative ^ A.negative), + (t.length = A.length + e.length); + for (var i = 0, g = 0, r = 0; r < t.length - 1; r++) { + var n = g; + g = 0; + for ( + var B = 67108863 & i, + I = Math.min(r, e.length - 1), + o = Math.max(0, r - A.length + 1); + o <= I; + o++ + ) { + var a = r - o, + Q = (0 | A.words[a]) * (0 | e.words[o]), + C = 67108863 & Q; + (B = 67108863 & (C = (C + B) | 0)), + (g += + (n = + ((n = (n + ((Q / 67108864) | 0)) | 0) + (C >>> 26)) | + 0) >>> 26), + (n &= 67108863); + } + (t.words[r] = B), (i = n), (n = g); + } + return 0 !== i ? (t.words[r] = i) : t.length--, t._strip(); + } + function E(A, e, t) { + return f(A, e, t); + } + function u(A, e) { + (this.x = A), (this.y = e); + } + Math.imul || (h = c), + (r.prototype.mulTo = function (A, e) { + var t = this.length + A.length; + return 10 === this.length && 10 === A.length + ? h(this, A, e) + : t < 63 + ? c(this, A, e) + : t < 1024 + ? f(this, A, e) + : E(this, A, e); + }), + (u.prototype.makeRBT = function (A) { + for ( + var e = new Array(A), t = r.prototype._countBits(A) - 1, i = 0; + i < A; + i++ + ) + e[i] = this.revBin(i, t, A); + return e; + }), + (u.prototype.revBin = function (A, e, t) { + if (0 === A || A === t - 1) return A; + for (var i = 0, g = 0; g < e; g++) + (i |= (1 & A) << (e - g - 1)), (A >>= 1); + return i; + }), + (u.prototype.permute = function (A, e, t, i, g, r) { + for (var n = 0; n < r; n++) (i[n] = e[A[n]]), (g[n] = t[A[n]]); + }), + (u.prototype.transform = function (A, e, t, i, g, r) { + this.permute(r, A, e, t, i, g); + for (var n = 1; n < g; n <<= 1) + for ( + var B = n << 1, + I = Math.cos((2 * Math.PI) / B), + o = Math.sin((2 * Math.PI) / B), + a = 0; + a < g; + a += B + ) + for (var Q = I, C = o, s = 0; s < n; s++) { + var c = t[a + s], + h = i[a + s], + f = t[a + s + n], + E = i[a + s + n], + u = Q * f - C * E; + (E = Q * E + C * f), + (f = u), + (t[a + s] = c + f), + (i[a + s] = h + E), + (t[a + s + n] = c - f), + (i[a + s + n] = h - E), + s !== B && + ((u = I * Q - o * C), (C = I * C + o * Q), (Q = u)); + } + }), + (u.prototype.guessLen13b = function (A, e) { + var t = 1 | Math.max(e, A), + i = 1 & t, + g = 0; + for (t = (t / 2) | 0; t; t >>>= 1) g++; + return 1 << (g + 1 + i); + }), + (u.prototype.conjugate = function (A, e, t) { + if (!(t <= 1)) + for (var i = 0; i < t / 2; i++) { + var g = A[i]; + (A[i] = A[t - i - 1]), + (A[t - i - 1] = g), + (g = e[i]), + (e[i] = -e[t - i - 1]), + (e[t - i - 1] = -g); + } + }), + (u.prototype.normalize13b = function (A, e) { + for (var t = 0, i = 0; i < e / 2; i++) { + var g = + 8192 * Math.round(A[2 * i + 1] / e) + + Math.round(A[2 * i] / e) + + t; + (A[i] = 67108863 & g), + (t = g < 67108864 ? 0 : (g / 67108864) | 0); + } + return A; + }), + (u.prototype.convert13b = function (A, e, t, g) { + for (var r = 0, n = 0; n < e; n++) + (r += 0 | A[n]), + (t[2 * n] = 8191 & r), + (r >>>= 13), + (t[2 * n + 1] = 8191 & r), + (r >>>= 13); + for (n = 2 * e; n < g; ++n) t[n] = 0; + i(0 === r), i(0 == (-8192 & r)); + }), + (u.prototype.stub = function (A) { + for (var e = new Array(A), t = 0; t < A; t++) e[t] = 0; + return e; + }), + (u.prototype.mulp = function (A, e, t) { + var i = 2 * this.guessLen13b(A.length, e.length), + g = this.makeRBT(i), + r = this.stub(i), + n = new Array(i), + B = new Array(i), + I = new Array(i), + o = new Array(i), + a = new Array(i), + Q = new Array(i), + C = t.words; + (C.length = i), + this.convert13b(A.words, A.length, n, i), + this.convert13b(e.words, e.length, o, i), + this.transform(n, r, B, I, i, g), + this.transform(o, r, a, Q, i, g); + for (var s = 0; s < i; s++) { + var c = B[s] * a[s] - I[s] * Q[s]; + (I[s] = B[s] * Q[s] + I[s] * a[s]), (B[s] = c); + } + return ( + this.conjugate(B, I, i), + this.transform(B, I, C, r, i, g), + this.conjugate(C, r, i), + this.normalize13b(C, i), + (t.negative = A.negative ^ e.negative), + (t.length = A.length + e.length), + t._strip() + ); + }), + (r.prototype.mul = function (A) { + var e = new r(null); + return ( + (e.words = new Array(this.length + A.length)), this.mulTo(A, e) + ); + }), + (r.prototype.mulf = function (A) { + var e = new r(null); + return ( + (e.words = new Array(this.length + A.length)), E(this, A, e) + ); + }), + (r.prototype.imul = function (A) { + return this.clone().mulTo(A, this); + }), + (r.prototype.imuln = function (A) { + var e = A < 0; + e && (A = -A), i("number" == typeof A), i(A < 67108864); + for (var t = 0, g = 0; g < this.length; g++) { + var r = (0 | this.words[g]) * A, + n = (67108863 & r) + (67108863 & t); + (t >>= 26), + (t += (r / 67108864) | 0), + (t += n >>> 26), + (this.words[g] = 67108863 & n); + } + return ( + 0 !== t && ((this.words[g] = t), this.length++), + e ? this.ineg() : this + ); + }), + (r.prototype.muln = function (A) { + return this.clone().imuln(A); + }), + (r.prototype.sqr = function () { + return this.mul(this); + }), + (r.prototype.isqr = function () { + return this.imul(this.clone()); + }), + (r.prototype.pow = function (A) { + var e = (function (A) { + for ( + var e = new Array(A.bitLength()), t = 0; + t < e.length; + t++ + ) { + var i = (t / 26) | 0, + g = t % 26; + e[t] = (A.words[i] >>> g) & 1; + } + return e; + })(A); + if (0 === e.length) return new r(1); + for ( + var t = this, i = 0; + i < e.length && 0 === e[i]; + i++, t = t.sqr() + ); + if (++i < e.length) + for (var g = t.sqr(); i < e.length; i++, g = g.sqr()) + 0 !== e[i] && (t = t.mul(g)); + return t; + }), + (r.prototype.iushln = function (A) { + i("number" == typeof A && A >= 0); + var e, + t = A % 26, + g = (A - t) / 26, + r = (67108863 >>> (26 - t)) << (26 - t); + if (0 !== t) { + var n = 0; + for (e = 0; e < this.length; e++) { + var B = this.words[e] & r, + I = ((0 | this.words[e]) - B) << t; + (this.words[e] = I | n), (n = B >>> (26 - t)); + } + n && ((this.words[e] = n), this.length++); + } + if (0 !== g) { + for (e = this.length - 1; e >= 0; e--) + this.words[e + g] = this.words[e]; + for (e = 0; e < g; e++) this.words[e] = 0; + this.length += g; + } + return this._strip(); + }), + (r.prototype.ishln = function (A) { + return i(0 === this.negative), this.iushln(A); + }), + (r.prototype.iushrn = function (A, e, t) { + var g; + i("number" == typeof A && A >= 0), + (g = e ? (e - (e % 26)) / 26 : 0); + var r = A % 26, + n = Math.min((A - r) / 26, this.length), + B = 67108863 ^ ((67108863 >>> r) << r), + I = t; + if (((g -= n), (g = Math.max(0, g)), I)) { + for (var o = 0; o < n; o++) I.words[o] = this.words[o]; + I.length = n; + } + if (0 === n); + else if (this.length > n) + for (this.length -= n, o = 0; o < this.length; o++) + this.words[o] = this.words[o + n]; + else (this.words[0] = 0), (this.length = 1); + var a = 0; + for (o = this.length - 1; o >= 0 && (0 !== a || o >= g); o--) { + var Q = 0 | this.words[o]; + (this.words[o] = (a << (26 - r)) | (Q >>> r)), (a = Q & B); + } + return ( + I && 0 !== a && (I.words[I.length++] = a), + 0 === this.length && ((this.words[0] = 0), (this.length = 1)), + this._strip() + ); + }), + (r.prototype.ishrn = function (A, e, t) { + return i(0 === this.negative), this.iushrn(A, e, t); + }), + (r.prototype.shln = function (A) { + return this.clone().ishln(A); + }), + (r.prototype.ushln = function (A) { + return this.clone().iushln(A); + }), + (r.prototype.shrn = function (A) { + return this.clone().ishrn(A); + }), + (r.prototype.ushrn = function (A) { + return this.clone().iushrn(A); + }), + (r.prototype.testn = function (A) { + i("number" == typeof A && A >= 0); + var e = A % 26, + t = (A - e) / 26, + g = 1 << e; + return !(this.length <= t) && !!(this.words[t] & g); + }), + (r.prototype.imaskn = function (A) { + i("number" == typeof A && A >= 0); + var e = A % 26, + t = (A - e) / 26; + if ( + (i( + 0 === this.negative, + "imaskn works only with positive numbers" + ), + this.length <= t) + ) + return this; + if ( + (0 !== e && t++, + (this.length = Math.min(t, this.length)), + 0 !== e) + ) { + var g = 67108863 ^ ((67108863 >>> e) << e); + this.words[this.length - 1] &= g; + } + return this._strip(); + }), + (r.prototype.maskn = function (A) { + return this.clone().imaskn(A); + }), + (r.prototype.iaddn = function (A) { + return ( + i("number" == typeof A), + i(A < 67108864), + A < 0 + ? this.isubn(-A) + : 0 !== this.negative + ? 1 === this.length && (0 | this.words[0]) <= A + ? ((this.words[0] = A - (0 | this.words[0])), + (this.negative = 0), + this) + : ((this.negative = 0), + this.isubn(A), + (this.negative = 1), + this) + : this._iaddn(A) + ); + }), + (r.prototype._iaddn = function (A) { + this.words[0] += A; + for (var e = 0; e < this.length && this.words[e] >= 67108864; e++) + (this.words[e] -= 67108864), + e === this.length - 1 + ? (this.words[e + 1] = 1) + : this.words[e + 1]++; + return (this.length = Math.max(this.length, e + 1)), this; + }), + (r.prototype.isubn = function (A) { + if ((i("number" == typeof A), i(A < 67108864), A < 0)) + return this.iaddn(-A); + if (0 !== this.negative) + return ( + (this.negative = 0), this.iaddn(A), (this.negative = 1), this + ); + if ( + ((this.words[0] -= A), 1 === this.length && this.words[0] < 0) + ) + (this.words[0] = -this.words[0]), (this.negative = 1); + else + for (var e = 0; e < this.length && this.words[e] < 0; e++) + (this.words[e] += 67108864), (this.words[e + 1] -= 1); + return this._strip(); + }), + (r.prototype.addn = function (A) { + return this.clone().iaddn(A); + }), + (r.prototype.subn = function (A) { + return this.clone().isubn(A); + }), + (r.prototype.iabs = function () { + return (this.negative = 0), this; + }), + (r.prototype.abs = function () { + return this.clone().iabs(); + }), + (r.prototype._ishlnsubmul = function (A, e, t) { + var g, + r, + n = A.length + t; + this._expand(n); + var B = 0; + for (g = 0; g < A.length; g++) { + r = (0 | this.words[g + t]) + B; + var I = (0 | A.words[g]) * e; + (B = ((r -= 67108863 & I) >> 26) - ((I / 67108864) | 0)), + (this.words[g + t] = 67108863 & r); + } + for (; g < this.length - t; g++) + (B = (r = (0 | this.words[g + t]) + B) >> 26), + (this.words[g + t] = 67108863 & r); + if (0 === B) return this._strip(); + for (i(-1 === B), B = 0, g = 0; g < this.length; g++) + (B = (r = -(0 | this.words[g]) + B) >> 26), + (this.words[g] = 67108863 & r); + return (this.negative = 1), this._strip(); + }), + (r.prototype._wordDiv = function (A, e) { + var t = (this.length, A.length), + i = this.clone(), + g = A, + n = 0 | g.words[g.length - 1]; + 0 !== (t = 26 - this._countBits(n)) && + ((g = g.ushln(t)), + i.iushln(t), + (n = 0 | g.words[g.length - 1])); + var B, + I = i.length - g.length; + if ("mod" !== e) { + ((B = new r(null)).length = I + 1), + (B.words = new Array(B.length)); + for (var o = 0; o < B.length; o++) B.words[o] = 0; + } + var a = i.clone()._ishlnsubmul(g, 1, I); + 0 === a.negative && ((i = a), B && (B.words[I] = 1)); + for (var Q = I - 1; Q >= 0; Q--) { + var C = + 67108864 * (0 | i.words[g.length + Q]) + + (0 | i.words[g.length + Q - 1]); + for ( + C = Math.min((C / n) | 0, 67108863), i._ishlnsubmul(g, C, Q); + 0 !== i.negative; + + ) + C--, + (i.negative = 0), + i._ishlnsubmul(g, 1, Q), + i.isZero() || (i.negative ^= 1); + B && (B.words[Q] = C); + } + return ( + B && B._strip(), + i._strip(), + "div" !== e && 0 !== t && i.iushrn(t), + { div: B || null, mod: i } + ); + }), + (r.prototype.divmod = function (A, e, t) { + return ( + i(!A.isZero()), + this.isZero() + ? { div: new r(0), mod: new r(0) } + : 0 !== this.negative && 0 === A.negative + ? ((B = this.neg().divmod(A, e)), + "mod" !== e && (g = B.div.neg()), + "div" !== e && + ((n = B.mod.neg()), t && 0 !== n.negative && n.iadd(A)), + { div: g, mod: n }) + : 0 === this.negative && 0 !== A.negative + ? ((B = this.divmod(A.neg(), e)), + "mod" !== e && (g = B.div.neg()), + { div: g, mod: B.mod }) + : 0 != (this.negative & A.negative) + ? ((B = this.neg().divmod(A.neg(), e)), + "div" !== e && + ((n = B.mod.neg()), t && 0 !== n.negative && n.isub(A)), + { div: B.div, mod: n }) + : A.length > this.length || this.cmp(A) < 0 + ? { div: new r(0), mod: this } + : 1 === A.length + ? "div" === e + ? { div: this.divn(A.words[0]), mod: null } + : "mod" === e + ? { div: null, mod: new r(this.modrn(A.words[0])) } + : { + div: this.divn(A.words[0]), + mod: new r(this.modrn(A.words[0])), + } + : this._wordDiv(A, e) + ); + var g, n, B; + }), + (r.prototype.div = function (A) { + return this.divmod(A, "div", !1).div; + }), + (r.prototype.mod = function (A) { + return this.divmod(A, "mod", !1).mod; + }), + (r.prototype.umod = function (A) { + return this.divmod(A, "mod", !0).mod; + }), + (r.prototype.divRound = function (A) { + var e = this.divmod(A); + if (e.mod.isZero()) return e.div; + var t = 0 !== e.div.negative ? e.mod.isub(A) : e.mod, + i = A.ushrn(1), + g = A.andln(1), + r = t.cmp(i); + return r < 0 || (1 === g && 0 === r) + ? e.div + : 0 !== e.div.negative + ? e.div.isubn(1) + : e.div.iaddn(1); + }), + (r.prototype.modrn = function (A) { + var e = A < 0; + e && (A = -A), i(A <= 67108863); + for ( + var t = (1 << 26) % A, g = 0, r = this.length - 1; + r >= 0; + r-- + ) + g = (t * g + (0 | this.words[r])) % A; + return e ? -g : g; + }), + (r.prototype.modn = function (A) { + return this.modrn(A); + }), + (r.prototype.idivn = function (A) { + var e = A < 0; + e && (A = -A), i(A <= 67108863); + for (var t = 0, g = this.length - 1; g >= 0; g--) { + var r = (0 | this.words[g]) + 67108864 * t; + (this.words[g] = (r / A) | 0), (t = r % A); + } + return this._strip(), e ? this.ineg() : this; + }), + (r.prototype.divn = function (A) { + return this.clone().idivn(A); + }), + (r.prototype.egcd = function (A) { + i(0 === A.negative), i(!A.isZero()); + var e = this, + t = A.clone(); + e = 0 !== e.negative ? e.umod(A) : e.clone(); + for ( + var g = new r(1), + n = new r(0), + B = new r(0), + I = new r(1), + o = 0; + e.isEven() && t.isEven(); + + ) + e.iushrn(1), t.iushrn(1), ++o; + for (var a = t.clone(), Q = e.clone(); !e.isZero(); ) { + for ( + var C = 0, s = 1; + 0 == (e.words[0] & s) && C < 26; + ++C, s <<= 1 + ); + if (C > 0) + for (e.iushrn(C); C-- > 0; ) + (g.isOdd() || n.isOdd()) && (g.iadd(a), n.isub(Q)), + g.iushrn(1), + n.iushrn(1); + for ( + var c = 0, h = 1; + 0 == (t.words[0] & h) && c < 26; + ++c, h <<= 1 + ); + if (c > 0) + for (t.iushrn(c); c-- > 0; ) + (B.isOdd() || I.isOdd()) && (B.iadd(a), I.isub(Q)), + B.iushrn(1), + I.iushrn(1); + e.cmp(t) >= 0 + ? (e.isub(t), g.isub(B), n.isub(I)) + : (t.isub(e), B.isub(g), I.isub(n)); + } + return { a: B, b: I, gcd: t.iushln(o) }; + }), + (r.prototype._invmp = function (A) { + i(0 === A.negative), i(!A.isZero()); + var e = this, + t = A.clone(); + e = 0 !== e.negative ? e.umod(A) : e.clone(); + for ( + var g, n = new r(1), B = new r(0), I = t.clone(); + e.cmpn(1) > 0 && t.cmpn(1) > 0; + + ) { + for ( + var o = 0, a = 1; + 0 == (e.words[0] & a) && o < 26; + ++o, a <<= 1 + ); + if (o > 0) + for (e.iushrn(o); o-- > 0; ) + n.isOdd() && n.iadd(I), n.iushrn(1); + for ( + var Q = 0, C = 1; + 0 == (t.words[0] & C) && Q < 26; + ++Q, C <<= 1 + ); + if (Q > 0) + for (t.iushrn(Q); Q-- > 0; ) + B.isOdd() && B.iadd(I), B.iushrn(1); + e.cmp(t) >= 0 ? (e.isub(t), n.isub(B)) : (t.isub(e), B.isub(n)); + } + return (g = 0 === e.cmpn(1) ? n : B).cmpn(0) < 0 && g.iadd(A), g; + }), + (r.prototype.gcd = function (A) { + if (this.isZero()) return A.abs(); + if (A.isZero()) return this.abs(); + var e = this.clone(), + t = A.clone(); + (e.negative = 0), (t.negative = 0); + for (var i = 0; e.isEven() && t.isEven(); i++) + e.iushrn(1), t.iushrn(1); + for (;;) { + for (; e.isEven(); ) e.iushrn(1); + for (; t.isEven(); ) t.iushrn(1); + var g = e.cmp(t); + if (g < 0) { + var r = e; + (e = t), (t = r); + } else if (0 === g || 0 === t.cmpn(1)) break; + e.isub(t); + } + return t.iushln(i); + }), + (r.prototype.invm = function (A) { + return this.egcd(A).a.umod(A); + }), + (r.prototype.isEven = function () { + return 0 == (1 & this.words[0]); + }), + (r.prototype.isOdd = function () { + return 1 == (1 & this.words[0]); + }), + (r.prototype.andln = function (A) { + return this.words[0] & A; + }), + (r.prototype.bincn = function (A) { + i("number" == typeof A); + var e = A % 26, + t = (A - e) / 26, + g = 1 << e; + if (this.length <= t) + return this._expand(t + 1), (this.words[t] |= g), this; + for (var r = g, n = t; 0 !== r && n < this.length; n++) { + var B = 0 | this.words[n]; + (r = (B += r) >>> 26), (B &= 67108863), (this.words[n] = B); + } + return 0 !== r && ((this.words[n] = r), this.length++), this; + }), + (r.prototype.isZero = function () { + return 1 === this.length && 0 === this.words[0]; + }), + (r.prototype.cmpn = function (A) { + var e, + t = A < 0; + if (0 !== this.negative && !t) return -1; + if (0 === this.negative && t) return 1; + if ((this._strip(), this.length > 1)) e = 1; + else { + t && (A = -A), i(A <= 67108863, "Number is too big"); + var g = 0 | this.words[0]; + e = g === A ? 0 : g < A ? -1 : 1; + } + return 0 !== this.negative ? 0 | -e : e; + }), + (r.prototype.cmp = function (A) { + if (0 !== this.negative && 0 === A.negative) return -1; + if (0 === this.negative && 0 !== A.negative) return 1; + var e = this.ucmp(A); + return 0 !== this.negative ? 0 | -e : e; + }), + (r.prototype.ucmp = function (A) { + if (this.length > A.length) return 1; + if (this.length < A.length) return -1; + for (var e = 0, t = this.length - 1; t >= 0; t--) { + var i = 0 | this.words[t], + g = 0 | A.words[t]; + if (i !== g) { + i < g ? (e = -1) : i > g && (e = 1); + break; + } + } + return e; + }), + (r.prototype.gtn = function (A) { + return 1 === this.cmpn(A); + }), + (r.prototype.gt = function (A) { + return 1 === this.cmp(A); + }), + (r.prototype.gten = function (A) { + return this.cmpn(A) >= 0; + }), + (r.prototype.gte = function (A) { + return this.cmp(A) >= 0; + }), + (r.prototype.ltn = function (A) { + return -1 === this.cmpn(A); + }), + (r.prototype.lt = function (A) { + return -1 === this.cmp(A); + }), + (r.prototype.lten = function (A) { + return this.cmpn(A) <= 0; + }), + (r.prototype.lte = function (A) { + return this.cmp(A) <= 0; + }), + (r.prototype.eqn = function (A) { + return 0 === this.cmpn(A); + }), + (r.prototype.eq = function (A) { + return 0 === this.cmp(A); + }), + (r.red = function (A) { + return new y(A); + }), + (r.prototype.toRed = function (A) { + return ( + i(!this.red, "Already a number in reduction context"), + i(0 === this.negative, "red works only with positives"), + A.convertTo(this)._forceRed(A) + ); + }), + (r.prototype.fromRed = function () { + return ( + i( + this.red, + "fromRed works only with numbers in reduction context" + ), + this.red.convertFrom(this) + ); + }), + (r.prototype._forceRed = function (A) { + return (this.red = A), this; + }), + (r.prototype.forceRed = function (A) { + return ( + i(!this.red, "Already a number in reduction context"), + this._forceRed(A) + ); + }), + (r.prototype.redAdd = function (A) { + return ( + i(this.red, "redAdd works only with red numbers"), + this.red.add(this, A) + ); + }), + (r.prototype.redIAdd = function (A) { + return ( + i(this.red, "redIAdd works only with red numbers"), + this.red.iadd(this, A) + ); + }), + (r.prototype.redSub = function (A) { + return ( + i(this.red, "redSub works only with red numbers"), + this.red.sub(this, A) + ); + }), + (r.prototype.redISub = function (A) { + return ( + i(this.red, "redISub works only with red numbers"), + this.red.isub(this, A) + ); + }), + (r.prototype.redShl = function (A) { + return ( + i(this.red, "redShl works only with red numbers"), + this.red.shl(this, A) + ); + }), + (r.prototype.redMul = function (A) { + return ( + i(this.red, "redMul works only with red numbers"), + this.red._verify2(this, A), + this.red.mul(this, A) + ); + }), + (r.prototype.redIMul = function (A) { + return ( + i(this.red, "redMul works only with red numbers"), + this.red._verify2(this, A), + this.red.imul(this, A) + ); + }), + (r.prototype.redSqr = function () { + return ( + i(this.red, "redSqr works only with red numbers"), + this.red._verify1(this), + this.red.sqr(this) + ); + }), + (r.prototype.redISqr = function () { + return ( + i(this.red, "redISqr works only with red numbers"), + this.red._verify1(this), + this.red.isqr(this) + ); + }), + (r.prototype.redSqrt = function () { + return ( + i(this.red, "redSqrt works only with red numbers"), + this.red._verify1(this), + this.red.sqrt(this) + ); + }), + (r.prototype.redInvm = function () { + return ( + i(this.red, "redInvm works only with red numbers"), + this.red._verify1(this), + this.red.invm(this) + ); + }), + (r.prototype.redNeg = function () { + return ( + i(this.red, "redNeg works only with red numbers"), + this.red._verify1(this), + this.red.neg(this) + ); + }), + (r.prototype.redPow = function (A) { + return ( + i(this.red && !A.red, "redPow(normalNum)"), + this.red._verify1(this), + this.red.pow(this, A) + ); + }); + var d = { k256: null, p224: null, p192: null, p25519: null }; + function l(A, e) { + (this.name = A), + (this.p = new r(e, 16)), + (this.n = this.p.bitLength()), + (this.k = new r(1).iushln(this.n).isub(this.p)), + (this.tmp = this._tmp()); + } + function w() { + l.call( + this, + "k256", + "ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f" + ); + } + function p() { + l.call( + this, + "p224", + "ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001" + ); + } + function D() { + l.call( + this, + "p192", + "ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff" + ); + } + function b() { + l.call( + this, + "25519", + "7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed" + ); + } + function y(A) { + if ("string" == typeof A) { + var e = r._prime(A); + (this.m = e.p), (this.prime = e); + } else + i(A.gtn(1), "modulus must be greater than 1"), + (this.m = A), + (this.prime = null); + } + function M(A) { + y.call(this, A), + (this.shift = this.m.bitLength()), + this.shift % 26 != 0 && (this.shift += 26 - (this.shift % 26)), + (this.r = new r(1).iushln(this.shift)), + (this.r2 = this.imod(this.r.sqr())), + (this.rinv = this.r._invmp(this.m)), + (this.minv = this.rinv.mul(this.r).isubn(1).div(this.m)), + (this.minv = this.minv.umod(this.r)), + (this.minv = this.r.sub(this.minv)); + } + (l.prototype._tmp = function () { + var A = new r(null); + return (A.words = new Array(Math.ceil(this.n / 13))), A; + }), + (l.prototype.ireduce = function (A) { + var e, + t = A; + do { + this.split(t, this.tmp), + (e = (t = (t = this.imulK(t)).iadd(this.tmp)).bitLength()); + } while (e > this.n); + var i = e < this.n ? -1 : t.ucmp(this.p); + return ( + 0 === i + ? ((t.words[0] = 0), (t.length = 1)) + : i > 0 + ? t.isub(this.p) + : void 0 !== t.strip + ? t.strip() + : t._strip(), + t + ); + }), + (l.prototype.split = function (A, e) { + A.iushrn(this.n, 0, e); + }), + (l.prototype.imulK = function (A) { + return A.imul(this.k); + }), + g(w, l), + (w.prototype.split = function (A, e) { + for (var t = Math.min(A.length, 9), i = 0; i < t; i++) + e.words[i] = A.words[i]; + if (((e.length = t), A.length <= 9)) + return (A.words[0] = 0), void (A.length = 1); + var g = A.words[9]; + for ( + e.words[e.length++] = 4194303 & g, i = 10; + i < A.length; + i++ + ) { + var r = 0 | A.words[i]; + (A.words[i - 10] = ((4194303 & r) << 4) | (g >>> 22)), (g = r); + } + (g >>>= 22), + (A.words[i - 10] = g), + 0 === g && A.length > 10 ? (A.length -= 10) : (A.length -= 9); + }), + (w.prototype.imulK = function (A) { + (A.words[A.length] = 0), + (A.words[A.length + 1] = 0), + (A.length += 2); + for (var e = 0, t = 0; t < A.length; t++) { + var i = 0 | A.words[t]; + (e += 977 * i), + (A.words[t] = 67108863 & e), + (e = 64 * i + ((e / 67108864) | 0)); + } + return ( + 0 === A.words[A.length - 1] && + (A.length--, 0 === A.words[A.length - 1] && A.length--), + A + ); + }), + g(p, l), + g(D, l), + g(b, l), + (b.prototype.imulK = function (A) { + for (var e = 0, t = 0; t < A.length; t++) { + var i = 19 * (0 | A.words[t]) + e, + g = 67108863 & i; + (i >>>= 26), (A.words[t] = g), (e = i); + } + return 0 !== e && (A.words[A.length++] = e), A; + }), + (r._prime = function (A) { + if (d[A]) return d[A]; + var e; + if ("k256" === A) e = new w(); + else if ("p224" === A) e = new p(); + else if ("p192" === A) e = new D(); + else { + if ("p25519" !== A) throw new Error("Unknown prime " + A); + e = new b(); + } + return (d[A] = e), e; + }), + (y.prototype._verify1 = function (A) { + i(0 === A.negative, "red works only with positives"), + i(A.red, "red works only with red numbers"); + }), + (y.prototype._verify2 = function (A, e) { + i( + 0 == (A.negative | e.negative), + "red works only with positives" + ), + i(A.red && A.red === e.red, "red works only with red numbers"); + }), + (y.prototype.imod = function (A) { + return this.prime + ? this.prime.ireduce(A)._forceRed(this) + : (o(A, A.umod(this.m)._forceRed(this)), A); + }), + (y.prototype.neg = function (A) { + return A.isZero() ? A.clone() : this.m.sub(A)._forceRed(this); + }), + (y.prototype.add = function (A, e) { + this._verify2(A, e); + var t = A.add(e); + return t.cmp(this.m) >= 0 && t.isub(this.m), t._forceRed(this); + }), + (y.prototype.iadd = function (A, e) { + this._verify2(A, e); + var t = A.iadd(e); + return t.cmp(this.m) >= 0 && t.isub(this.m), t; + }), + (y.prototype.sub = function (A, e) { + this._verify2(A, e); + var t = A.sub(e); + return t.cmpn(0) < 0 && t.iadd(this.m), t._forceRed(this); + }), + (y.prototype.isub = function (A, e) { + this._verify2(A, e); + var t = A.isub(e); + return t.cmpn(0) < 0 && t.iadd(this.m), t; + }), + (y.prototype.shl = function (A, e) { + return this._verify1(A), this.imod(A.ushln(e)); + }), + (y.prototype.imul = function (A, e) { + return this._verify2(A, e), this.imod(A.imul(e)); + }), + (y.prototype.mul = function (A, e) { + return this._verify2(A, e), this.imod(A.mul(e)); + }), + (y.prototype.isqr = function (A) { + return this.imul(A, A.clone()); + }), + (y.prototype.sqr = function (A) { + return this.mul(A, A); + }), + (y.prototype.sqrt = function (A) { + if (A.isZero()) return A.clone(); + var e = this.m.andln(3); + if ((i(e % 2 == 1), 3 === e)) { + var t = this.m.add(new r(1)).iushrn(2); + return this.pow(A, t); + } + for ( + var g = this.m.subn(1), n = 0; + !g.isZero() && 0 === g.andln(1); + + ) + n++, g.iushrn(1); + i(!g.isZero()); + var B = new r(1).toRed(this), + I = B.redNeg(), + o = this.m.subn(1).iushrn(1), + a = this.m.bitLength(); + for ( + a = new r(2 * a * a).toRed(this); + 0 !== this.pow(a, o).cmp(I); + + ) + a.redIAdd(I); + for ( + var Q = this.pow(a, g), + C = this.pow(A, g.addn(1).iushrn(1)), + s = this.pow(A, g), + c = n; + 0 !== s.cmp(B); + + ) { + for (var h = s, f = 0; 0 !== h.cmp(B); f++) h = h.redSqr(); + i(f < c); + var E = this.pow(Q, new r(1).iushln(c - f - 1)); + (C = C.redMul(E)), (Q = E.redSqr()), (s = s.redMul(Q)), (c = f); + } + return C; + }), + (y.prototype.invm = function (A) { + var e = A._invmp(this.m); + return 0 !== e.negative + ? ((e.negative = 0), this.imod(e).redNeg()) + : this.imod(e); + }), + (y.prototype.pow = function (A, e) { + if (e.isZero()) return new r(1).toRed(this); + if (0 === e.cmpn(1)) return A.clone(); + var t = new Array(16); + (t[0] = new r(1).toRed(this)), (t[1] = A); + for (var i = 2; i < t.length; i++) t[i] = this.mul(t[i - 1], A); + var g = t[0], + n = 0, + B = 0, + I = e.bitLength() % 26; + for (0 === I && (I = 26), i = e.length - 1; i >= 0; i--) { + for (var o = e.words[i], a = I - 1; a >= 0; a--) { + var Q = (o >> a) & 1; + g !== t[0] && (g = this.sqr(g)), + 0 !== Q || 0 !== n + ? ((n <<= 1), + (n |= Q), + (4 === ++B || (0 === i && 0 === a)) && + ((g = this.mul(g, t[n])), (B = 0), (n = 0))) + : (B = 0); + } + I = 26; + } + return g; + }), + (y.prototype.convertTo = function (A) { + var e = A.umod(this.m); + return e === A ? e.clone() : e; + }), + (y.prototype.convertFrom = function (A) { + var e = A.clone(); + return (e.red = null), e; + }), + (r.mont = function (A) { + return new M(A); + }), + g(M, y), + (M.prototype.convertTo = function (A) { + return this.imod(A.ushln(this.shift)); + }), + (M.prototype.convertFrom = function (A) { + var e = this.imod(A.mul(this.rinv)); + return (e.red = null), e; + }), + (M.prototype.imul = function (A, e) { + if (A.isZero() || e.isZero()) + return (A.words[0] = 0), (A.length = 1), A; + var t = A.imul(e), + i = t + .maskn(this.shift) + .mul(this.minv) + .imaskn(this.shift) + .mul(this.m), + g = t.isub(i).iushrn(this.shift), + r = g; + return ( + g.cmp(this.m) >= 0 + ? (r = g.isub(this.m)) + : g.cmpn(0) < 0 && (r = g.iadd(this.m)), + r._forceRed(this) + ); + }), + (M.prototype.mul = function (A, e) { + if (A.isZero() || e.isZero()) return new r(0)._forceRed(this); + var t = A.mul(e), + i = t + .maskn(this.shift) + .mul(this.minv) + .imaskn(this.shift) + .mul(this.m), + g = t.isub(i).iushrn(this.shift), + n = g; + return ( + g.cmp(this.m) >= 0 + ? (n = g.isub(this.m)) + : g.cmpn(0) < 0 && (n = g.iadd(this.m)), + n._forceRed(this) + ); + }), + (M.prototype.invm = function (A) { + return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this); + }); + })(void 0 === e || e, this); + }, + { buffer: 19 }, + ], + 18: [ + function (A, e, t) { + var i; + function g(A) { + this.rand = A; + } + if ( + ((e.exports = function (A) { + return i || (i = new g(null)), i.generate(A); + }), + (e.exports.Rand = g), + (g.prototype.generate = function (A) { + return this._rand(A); + }), + (g.prototype._rand = function (A) { + if (this.rand.getBytes) return this.rand.getBytes(A); + for (var e = new Uint8Array(A), t = 0; t < e.length; t++) + e[t] = this.rand.getByte(); + return e; + }), + "object" == typeof self) + ) + self.crypto && self.crypto.getRandomValues + ? (g.prototype._rand = function (A) { + var e = new Uint8Array(A); + return self.crypto.getRandomValues(e), e; + }) + : self.msCrypto && self.msCrypto.getRandomValues + ? (g.prototype._rand = function (A) { + var e = new Uint8Array(A); + return self.msCrypto.getRandomValues(e), e; + }) + : "object" == typeof window && + (g.prototype._rand = function () { + throw new Error("Not implemented yet"); + }); + else + try { + var r = A("crypto"); + if ("function" != typeof r.randomBytes) + throw new Error("Not supported"); + g.prototype._rand = function (A) { + return r.randomBytes(A); + }; + } catch (A) {} + }, + { crypto: 19 }, + ], + 19: [function (A, e, t) {}, {}], + 20: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer; + function g(A) { + i.isBuffer(A) || (A = i.from(A)); + for (var e = (A.length / 4) | 0, t = new Array(e), g = 0; g < e; g++) + t[g] = A.readUInt32BE(4 * g); + return t; + } + function r(A) { + for (; 0 < A.length; A++) A[0] = 0; + } + function n(A, e, t, i, g) { + for ( + var r, + n, + B, + I, + o = t[0], + a = t[1], + Q = t[2], + C = t[3], + s = A[0] ^ e[0], + c = A[1] ^ e[1], + h = A[2] ^ e[2], + f = A[3] ^ e[3], + E = 4, + u = 1; + u < g; + u++ + ) + (r = + o[s >>> 24] ^ + a[(c >>> 16) & 255] ^ + Q[(h >>> 8) & 255] ^ + C[255 & f] ^ + e[E++]), + (n = + o[c >>> 24] ^ + a[(h >>> 16) & 255] ^ + Q[(f >>> 8) & 255] ^ + C[255 & s] ^ + e[E++]), + (B = + o[h >>> 24] ^ + a[(f >>> 16) & 255] ^ + Q[(s >>> 8) & 255] ^ + C[255 & c] ^ + e[E++]), + (I = + o[f >>> 24] ^ + a[(s >>> 16) & 255] ^ + Q[(c >>> 8) & 255] ^ + C[255 & h] ^ + e[E++]), + (s = r), + (c = n), + (h = B), + (f = I); + return ( + (r = + ((i[s >>> 24] << 24) | + (i[(c >>> 16) & 255] << 16) | + (i[(h >>> 8) & 255] << 8) | + i[255 & f]) ^ + e[E++]), + (n = + ((i[c >>> 24] << 24) | + (i[(h >>> 16) & 255] << 16) | + (i[(f >>> 8) & 255] << 8) | + i[255 & s]) ^ + e[E++]), + (B = + ((i[h >>> 24] << 24) | + (i[(f >>> 16) & 255] << 16) | + (i[(s >>> 8) & 255] << 8) | + i[255 & c]) ^ + e[E++]), + (I = + ((i[f >>> 24] << 24) | + (i[(s >>> 16) & 255] << 16) | + (i[(c >>> 8) & 255] << 8) | + i[255 & h]) ^ + e[E++]), + [(r >>>= 0), (n >>>= 0), (B >>>= 0), (I >>>= 0)] + ); + } + var B = [0, 1, 2, 4, 8, 16, 32, 64, 128, 27, 54], + I = (function () { + for (var A = new Array(256), e = 0; e < 256; e++) + A[e] = e < 128 ? e << 1 : (e << 1) ^ 283; + for ( + var t = [], + i = [], + g = [[], [], [], []], + r = [[], [], [], []], + n = 0, + B = 0, + I = 0; + I < 256; + ++I + ) { + var o = B ^ (B << 1) ^ (B << 2) ^ (B << 3) ^ (B << 4); + (o = (o >>> 8) ^ (255 & o) ^ 99), (t[n] = o), (i[o] = n); + var a = A[n], + Q = A[a], + C = A[Q], + s = (257 * A[o]) ^ (16843008 * o); + (g[0][n] = (s << 24) | (s >>> 8)), + (g[1][n] = (s << 16) | (s >>> 16)), + (g[2][n] = (s << 8) | (s >>> 24)), + (g[3][n] = s), + (s = (16843009 * C) ^ (65537 * Q) ^ (257 * a) ^ (16843008 * n)), + (r[0][o] = (s << 24) | (s >>> 8)), + (r[1][o] = (s << 16) | (s >>> 16)), + (r[2][o] = (s << 8) | (s >>> 24)), + (r[3][o] = s), + 0 === n + ? (n = B = 1) + : ((n = a ^ A[A[A[C ^ a]]]), (B ^= A[A[B]])); + } + return { SBOX: t, INV_SBOX: i, SUB_MIX: g, INV_SUB_MIX: r }; + })(); + function o(A) { + (this._key = g(A)), this._reset(); + } + (o.blockSize = 16), + (o.keySize = 32), + (o.prototype.blockSize = o.blockSize), + (o.prototype.keySize = o.keySize), + (o.prototype._reset = function () { + for ( + var A = this._key, + e = A.length, + t = e + 6, + i = 4 * (t + 1), + g = [], + r = 0; + r < e; + r++ + ) + g[r] = A[r]; + for (r = e; r < i; r++) { + var n = g[r - 1]; + r % e == 0 + ? ((n = (n << 8) | (n >>> 24)), + (n = + (I.SBOX[n >>> 24] << 24) | + (I.SBOX[(n >>> 16) & 255] << 16) | + (I.SBOX[(n >>> 8) & 255] << 8) | + I.SBOX[255 & n]), + (n ^= B[(r / e) | 0] << 24)) + : e > 6 && + r % e == 4 && + (n = + (I.SBOX[n >>> 24] << 24) | + (I.SBOX[(n >>> 16) & 255] << 16) | + (I.SBOX[(n >>> 8) & 255] << 8) | + I.SBOX[255 & n]), + (g[r] = g[r - e] ^ n); + } + for (var o = [], a = 0; a < i; a++) { + var Q = i - a, + C = g[Q - (a % 4 ? 0 : 4)]; + o[a] = + a < 4 || Q <= 4 + ? C + : I.INV_SUB_MIX[0][I.SBOX[C >>> 24]] ^ + I.INV_SUB_MIX[1][I.SBOX[(C >>> 16) & 255]] ^ + I.INV_SUB_MIX[2][I.SBOX[(C >>> 8) & 255]] ^ + I.INV_SUB_MIX[3][I.SBOX[255 & C]]; + } + (this._nRounds = t), + (this._keySchedule = g), + (this._invKeySchedule = o); + }), + (o.prototype.encryptBlockRaw = function (A) { + return n( + (A = g(A)), + this._keySchedule, + I.SUB_MIX, + I.SBOX, + this._nRounds + ); + }), + (o.prototype.encryptBlock = function (A) { + var e = this.encryptBlockRaw(A), + t = i.allocUnsafe(16); + return ( + t.writeUInt32BE(e[0], 0), + t.writeUInt32BE(e[1], 4), + t.writeUInt32BE(e[2], 8), + t.writeUInt32BE(e[3], 12), + t + ); + }), + (o.prototype.decryptBlock = function (A) { + var e = (A = g(A))[1]; + (A[1] = A[3]), (A[3] = e); + var t = n( + A, + this._invKeySchedule, + I.INV_SUB_MIX, + I.INV_SBOX, + this._nRounds + ), + r = i.allocUnsafe(16); + return ( + r.writeUInt32BE(t[0], 0), + r.writeUInt32BE(t[3], 4), + r.writeUInt32BE(t[2], 8), + r.writeUInt32BE(t[1], 12), + r + ); + }), + (o.prototype.scrub = function () { + r(this._keySchedule), r(this._invKeySchedule), r(this._key); + }), + (e.exports.AES = o); + }, + { "safe-buffer": 180 }, + ], + 21: [ + function (A, e, t) { + var i = A("./aes"), + g = A("safe-buffer").Buffer, + r = A("cipher-base"), + n = A("inherits"), + B = A("./ghash"), + I = A("buffer-xor"), + o = A("./incr32"); + function a(A, e, t, n) { + r.call(this); + var I = g.alloc(4, 0); + this._cipher = new i.AES(e); + var a = this._cipher.encryptBlock(I); + (this._ghash = new B(a)), + (t = (function (A, e, t) { + if (12 === e.length) + return ( + (A._finID = g.concat([e, g.from([0, 0, 0, 1])])), + g.concat([e, g.from([0, 0, 0, 2])]) + ); + var i = new B(t), + r = e.length, + n = r % 16; + i.update(e), + n && ((n = 16 - n), i.update(g.alloc(n, 0))), + i.update(g.alloc(8, 0)); + var I = 8 * r, + a = g.alloc(8); + a.writeUIntBE(I, 0, 8), i.update(a), (A._finID = i.state); + var Q = g.from(A._finID); + return o(Q), Q; + })(this, t, a)), + (this._prev = g.from(t)), + (this._cache = g.allocUnsafe(0)), + (this._secCache = g.allocUnsafe(0)), + (this._decrypt = n), + (this._alen = 0), + (this._len = 0), + (this._mode = A), + (this._authTag = null), + (this._called = !1); + } + n(a, r), + (a.prototype._update = function (A) { + if (!this._called && this._alen) { + var e = 16 - (this._alen % 16); + e < 16 && ((e = g.alloc(e, 0)), this._ghash.update(e)); + } + this._called = !0; + var t = this._mode.encrypt(this, A); + return ( + this._decrypt ? this._ghash.update(A) : this._ghash.update(t), + (this._len += A.length), + t + ); + }), + (a.prototype._final = function () { + if (this._decrypt && !this._authTag) + throw new Error( + "Unsupported state or unable to authenticate data" + ); + var A = I( + this._ghash.final(8 * this._alen, 8 * this._len), + this._cipher.encryptBlock(this._finID) + ); + if ( + this._decrypt && + (function (A, e) { + var t = 0; + A.length !== e.length && t++; + for (var i = Math.min(A.length, e.length), g = 0; g < i; ++g) + t += A[g] ^ e[g]; + return t; + })(A, this._authTag) + ) + throw new Error( + "Unsupported state or unable to authenticate data" + ); + (this._authTag = A), this._cipher.scrub(); + }), + (a.prototype.getAuthTag = function () { + if (this._decrypt || !g.isBuffer(this._authTag)) + throw new Error( + "Attempting to get auth tag in unsupported state" + ); + return this._authTag; + }), + (a.prototype.setAuthTag = function (A) { + if (!this._decrypt) + throw new Error( + "Attempting to set auth tag in unsupported state" + ); + this._authTag = A; + }), + (a.prototype.setAAD = function (A) { + if (this._called) + throw new Error("Attempting to set AAD in unsupported state"); + this._ghash.update(A), (this._alen += A.length); + }), + (e.exports = a); + }, + { + "./aes": 20, + "./ghash": 25, + "./incr32": 26, + "buffer-xor": 63, + "cipher-base": 65, + inherits: 134, + "safe-buffer": 180, + }, + ], + 22: [ + function (A, e, t) { + var i = A("./encrypter"), + g = A("./decrypter"), + r = A("./modes/list.json"); + (t.createCipher = t.Cipher = i.createCipher), + (t.createCipheriv = t.Cipheriv = i.createCipheriv), + (t.createDecipher = t.Decipher = g.createDecipher), + (t.createDecipheriv = t.Decipheriv = g.createDecipheriv), + (t.listCiphers = t.getCiphers = + function () { + return Object.keys(r); + }); + }, + { "./decrypter": 23, "./encrypter": 24, "./modes/list.json": 34 }, + ], + 23: [ + function (A, e, t) { + var i = A("./authCipher"), + g = A("safe-buffer").Buffer, + r = A("./modes"), + n = A("./streamCipher"), + B = A("cipher-base"), + I = A("./aes"), + o = A("evp_bytestokey"); + function a(A, e, t) { + B.call(this), + (this._cache = new Q()), + (this._last = void 0), + (this._cipher = new I.AES(e)), + (this._prev = g.from(t)), + (this._mode = A), + (this._autopadding = !0); + } + function Q() { + this.cache = g.allocUnsafe(0); + } + function C(A, e, t) { + var B = r[A.toLowerCase()]; + if (!B) throw new TypeError("invalid suite type"); + if ( + ("string" == typeof t && (t = g.from(t)), + "GCM" !== B.mode && t.length !== B.iv) + ) + throw new TypeError("invalid iv length " + t.length); + if (("string" == typeof e && (e = g.from(e)), e.length !== B.key / 8)) + throw new TypeError("invalid key length " + e.length); + return "stream" === B.type + ? new n(B.module, e, t, !0) + : "auth" === B.type + ? new i(B.module, e, t, !0) + : new a(B.module, e, t); + } + A("inherits")(a, B), + (a.prototype._update = function (A) { + var e, t; + this._cache.add(A); + for (var i = []; (e = this._cache.get(this._autopadding)); ) + (t = this._mode.decrypt(this, e)), i.push(t); + return g.concat(i); + }), + (a.prototype._final = function () { + var A = this._cache.flush(); + if (this._autopadding) + return (function (A) { + var e = A[15]; + if (e < 1 || e > 16) throw new Error("unable to decrypt data"); + var t = -1; + for (; ++t < e; ) + if (A[t + (16 - e)] !== e) + throw new Error("unable to decrypt data"); + if (16 === e) return; + return A.slice(0, 16 - e); + })(this._mode.decrypt(this, A)); + if (A) throw new Error("data not multiple of block length"); + }), + (a.prototype.setAutoPadding = function (A) { + return (this._autopadding = !!A), this; + }), + (Q.prototype.add = function (A) { + this.cache = g.concat([this.cache, A]); + }), + (Q.prototype.get = function (A) { + var e; + if (A) { + if (this.cache.length > 16) + return ( + (e = this.cache.slice(0, 16)), + (this.cache = this.cache.slice(16)), + e + ); + } else if (this.cache.length >= 16) + return ( + (e = this.cache.slice(0, 16)), + (this.cache = this.cache.slice(16)), + e + ); + return null; + }), + (Q.prototype.flush = function () { + if (this.cache.length) return this.cache; + }), + (t.createDecipher = function (A, e) { + var t = r[A.toLowerCase()]; + if (!t) throw new TypeError("invalid suite type"); + var i = o(e, !1, t.key, t.iv); + return C(A, i.key, i.iv); + }), + (t.createDecipheriv = C); + }, + { + "./aes": 20, + "./authCipher": 21, + "./modes": 33, + "./streamCipher": 36, + "cipher-base": 65, + evp_bytestokey: 103, + inherits: 134, + "safe-buffer": 180, + }, + ], + 24: [ + function (A, e, t) { + var i = A("./modes"), + g = A("./authCipher"), + r = A("safe-buffer").Buffer, + n = A("./streamCipher"), + B = A("cipher-base"), + I = A("./aes"), + o = A("evp_bytestokey"); + function a(A, e, t) { + B.call(this), + (this._cache = new C()), + (this._cipher = new I.AES(e)), + (this._prev = r.from(t)), + (this._mode = A), + (this._autopadding = !0); + } + A("inherits")(a, B), + (a.prototype._update = function (A) { + var e, t; + this._cache.add(A); + for (var i = []; (e = this._cache.get()); ) + (t = this._mode.encrypt(this, e)), i.push(t); + return r.concat(i); + }); + var Q = r.alloc(16, 16); + function C() { + this.cache = r.allocUnsafe(0); + } + function s(A, e, t) { + var B = i[A.toLowerCase()]; + if (!B) throw new TypeError("invalid suite type"); + if (("string" == typeof e && (e = r.from(e)), e.length !== B.key / 8)) + throw new TypeError("invalid key length " + e.length); + if ( + ("string" == typeof t && (t = r.from(t)), + "GCM" !== B.mode && t.length !== B.iv) + ) + throw new TypeError("invalid iv length " + t.length); + return "stream" === B.type + ? new n(B.module, e, t) + : "auth" === B.type + ? new g(B.module, e, t) + : new a(B.module, e, t); + } + (a.prototype._final = function () { + var A = this._cache.flush(); + if (this._autopadding) + return (A = this._mode.encrypt(this, A)), this._cipher.scrub(), A; + if (!A.equals(Q)) + throw ( + (this._cipher.scrub(), + new Error("data not multiple of block length")) + ); + }), + (a.prototype.setAutoPadding = function (A) { + return (this._autopadding = !!A), this; + }), + (C.prototype.add = function (A) { + this.cache = r.concat([this.cache, A]); + }), + (C.prototype.get = function () { + if (this.cache.length > 15) { + var A = this.cache.slice(0, 16); + return (this.cache = this.cache.slice(16)), A; + } + return null; + }), + (C.prototype.flush = function () { + for ( + var A = 16 - this.cache.length, e = r.allocUnsafe(A), t = -1; + ++t < A; + + ) + e.writeUInt8(A, t); + return r.concat([this.cache, e]); + }), + (t.createCipheriv = s), + (t.createCipher = function (A, e) { + var t = i[A.toLowerCase()]; + if (!t) throw new TypeError("invalid suite type"); + var g = o(e, !1, t.key, t.iv); + return s(A, g.key, g.iv); + }); + }, + { + "./aes": 20, + "./authCipher": 21, + "./modes": 33, + "./streamCipher": 36, + "cipher-base": 65, + evp_bytestokey: 103, + inherits: 134, + "safe-buffer": 180, + }, + ], + 25: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer, + g = i.alloc(16, 0); + function r(A) { + var e = i.allocUnsafe(16); + return ( + e.writeUInt32BE(A[0] >>> 0, 0), + e.writeUInt32BE(A[1] >>> 0, 4), + e.writeUInt32BE(A[2] >>> 0, 8), + e.writeUInt32BE(A[3] >>> 0, 12), + e + ); + } + function n(A) { + (this.h = A), + (this.state = i.alloc(16, 0)), + (this.cache = i.allocUnsafe(0)); + } + (n.prototype.ghash = function (A) { + for (var e = -1; ++e < A.length; ) this.state[e] ^= A[e]; + this._multiply(); + }), + (n.prototype._multiply = function () { + for ( + var A, + e, + t, + i = [ + (A = this.h).readUInt32BE(0), + A.readUInt32BE(4), + A.readUInt32BE(8), + A.readUInt32BE(12), + ], + g = [0, 0, 0, 0], + n = -1; + ++n < 128; + + ) { + for ( + 0 != (this.state[~~(n / 8)] & (1 << (7 - (n % 8)))) && + ((g[0] ^= i[0]), + (g[1] ^= i[1]), + (g[2] ^= i[2]), + (g[3] ^= i[3])), + t = 0 != (1 & i[3]), + e = 3; + e > 0; + e-- + ) + i[e] = (i[e] >>> 1) | ((1 & i[e - 1]) << 31); + (i[0] = i[0] >>> 1), t && (i[0] = i[0] ^ (225 << 24)); + } + this.state = r(g); + }), + (n.prototype.update = function (A) { + var e; + for ( + this.cache = i.concat([this.cache, A]); + this.cache.length >= 16; + + ) + (e = this.cache.slice(0, 16)), + (this.cache = this.cache.slice(16)), + this.ghash(e); + }), + (n.prototype.final = function (A, e) { + return ( + this.cache.length && this.ghash(i.concat([this.cache, g], 16)), + this.ghash(r([0, A, 0, e])), + this.state + ); + }), + (e.exports = n); + }, + { "safe-buffer": 180 }, + ], + 26: [ + function (A, e, t) { + e.exports = function (A) { + for (var e, t = A.length; t--; ) { + if (255 !== (e = A.readUInt8(t))) { + e++, A.writeUInt8(e, t); + break; + } + A.writeUInt8(0, t); + } + }; + }, + {}, + ], + 27: [ + function (A, e, t) { + var i = A("buffer-xor"); + (t.encrypt = function (A, e) { + var t = i(e, A._prev); + return (A._prev = A._cipher.encryptBlock(t)), A._prev; + }), + (t.decrypt = function (A, e) { + var t = A._prev; + A._prev = e; + var g = A._cipher.decryptBlock(e); + return i(g, t); + }); + }, + { "buffer-xor": 63 }, + ], + 28: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer, + g = A("buffer-xor"); + function r(A, e, t) { + var r = e.length, + n = g(e, A._cache); + return ( + (A._cache = A._cache.slice(r)), + (A._prev = i.concat([A._prev, t ? e : n])), + n + ); + } + t.encrypt = function (A, e, t) { + for (var g, n = i.allocUnsafe(0); e.length; ) { + if ( + (0 === A._cache.length && + ((A._cache = A._cipher.encryptBlock(A._prev)), + (A._prev = i.allocUnsafe(0))), + !(A._cache.length <= e.length)) + ) { + n = i.concat([n, r(A, e, t)]); + break; + } + (g = A._cache.length), + (n = i.concat([n, r(A, e.slice(0, g), t)])), + (e = e.slice(g)); + } + return n; + }; + }, + { "buffer-xor": 63, "safe-buffer": 180 }, + ], + 29: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer; + function g(A, e, t) { + for (var i, g, n, B = -1, I = 0; ++B < 8; ) + (i = A._cipher.encryptBlock(A._prev)), + (g = e & (1 << (7 - B)) ? 128 : 0), + (I += (128 & (n = i[0] ^ g)) >> B % 8), + (A._prev = r(A._prev, t ? g : n)); + return I; + } + function r(A, e) { + var t = A.length, + g = -1, + r = i.allocUnsafe(A.length); + for (A = i.concat([A, i.from([e])]); ++g < t; ) + r[g] = (A[g] << 1) | (A[g + 1] >> 7); + return r; + } + t.encrypt = function (A, e, t) { + for (var r = e.length, n = i.allocUnsafe(r), B = -1; ++B < r; ) + n[B] = g(A, e[B], t); + return n; + }; + }, + { "safe-buffer": 180 }, + ], + 30: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer; + function g(A, e, t) { + var g = A._cipher.encryptBlock(A._prev)[0] ^ e; + return ( + (A._prev = i.concat([A._prev.slice(1), i.from([t ? e : g])])), g + ); + } + t.encrypt = function (A, e, t) { + for (var r = e.length, n = i.allocUnsafe(r), B = -1; ++B < r; ) + n[B] = g(A, e[B], t); + return n; + }; + }, + { "safe-buffer": 180 }, + ], + 31: [ + function (A, e, t) { + var i = A("buffer-xor"), + g = A("safe-buffer").Buffer, + r = A("../incr32"); + function n(A) { + var e = A._cipher.encryptBlockRaw(A._prev); + return r(A._prev), e; + } + t.encrypt = function (A, e) { + var t = Math.ceil(e.length / 16), + r = A._cache.length; + A._cache = g.concat([A._cache, g.allocUnsafe(16 * t)]); + for (var B = 0; B < t; B++) { + var I = n(A), + o = r + 16 * B; + A._cache.writeUInt32BE(I[0], o + 0), + A._cache.writeUInt32BE(I[1], o + 4), + A._cache.writeUInt32BE(I[2], o + 8), + A._cache.writeUInt32BE(I[3], o + 12); + } + var a = A._cache.slice(0, e.length); + return (A._cache = A._cache.slice(e.length)), i(e, a); + }; + }, + { "../incr32": 26, "buffer-xor": 63, "safe-buffer": 180 }, + ], + 32: [ + function (A, e, t) { + (t.encrypt = function (A, e) { + return A._cipher.encryptBlock(e); + }), + (t.decrypt = function (A, e) { + return A._cipher.decryptBlock(e); + }); + }, + {}, + ], + 33: [ + function (A, e, t) { + var i = { + ECB: A("./ecb"), + CBC: A("./cbc"), + CFB: A("./cfb"), + CFB8: A("./cfb8"), + CFB1: A("./cfb1"), + OFB: A("./ofb"), + CTR: A("./ctr"), + GCM: A("./ctr"), + }, + g = A("./list.json"); + for (var r in g) g[r].module = i[g[r].mode]; + e.exports = g; + }, + { + "./cbc": 27, + "./cfb": 28, + "./cfb1": 29, + "./cfb8": 30, + "./ctr": 31, + "./ecb": 32, + "./list.json": 34, + "./ofb": 35, + }, + ], + 34: [ + function (A, e, t) { + e.exports = { + "aes-128-ecb": { + cipher: "AES", + key: 128, + iv: 0, + mode: "ECB", + type: "block", + }, + "aes-192-ecb": { + cipher: "AES", + key: 192, + iv: 0, + mode: "ECB", + type: "block", + }, + "aes-256-ecb": { + cipher: "AES", + key: 256, + iv: 0, + mode: "ECB", + type: "block", + }, + "aes-128-cbc": { + cipher: "AES", + key: 128, + iv: 16, + mode: "CBC", + type: "block", + }, + "aes-192-cbc": { + cipher: "AES", + key: 192, + iv: 16, + mode: "CBC", + type: "block", + }, + "aes-256-cbc": { + cipher: "AES", + key: 256, + iv: 16, + mode: "CBC", + type: "block", + }, + aes128: { + cipher: "AES", + key: 128, + iv: 16, + mode: "CBC", + type: "block", + }, + aes192: { + cipher: "AES", + key: 192, + iv: 16, + mode: "CBC", + type: "block", + }, + aes256: { + cipher: "AES", + key: 256, + iv: 16, + mode: "CBC", + type: "block", + }, + "aes-128-cfb": { + cipher: "AES", + key: 128, + iv: 16, + mode: "CFB", + type: "stream", + }, + "aes-192-cfb": { + cipher: "AES", + key: 192, + iv: 16, + mode: "CFB", + type: "stream", + }, + "aes-256-cfb": { + cipher: "AES", + key: 256, + iv: 16, + mode: "CFB", + type: "stream", + }, + "aes-128-cfb8": { + cipher: "AES", + key: 128, + iv: 16, + mode: "CFB8", + type: "stream", + }, + "aes-192-cfb8": { + cipher: "AES", + key: 192, + iv: 16, + mode: "CFB8", + type: "stream", + }, + "aes-256-cfb8": { + cipher: "AES", + key: 256, + iv: 16, + mode: "CFB8", + type: "stream", + }, + "aes-128-cfb1": { + cipher: "AES", + key: 128, + iv: 16, + mode: "CFB1", + type: "stream", + }, + "aes-192-cfb1": { + cipher: "AES", + key: 192, + iv: 16, + mode: "CFB1", + type: "stream", + }, + "aes-256-cfb1": { + cipher: "AES", + key: 256, + iv: 16, + mode: "CFB1", + type: "stream", + }, + "aes-128-ofb": { + cipher: "AES", + key: 128, + iv: 16, + mode: "OFB", + type: "stream", + }, + "aes-192-ofb": { + cipher: "AES", + key: 192, + iv: 16, + mode: "OFB", + type: "stream", + }, + "aes-256-ofb": { + cipher: "AES", + key: 256, + iv: 16, + mode: "OFB", + type: "stream", + }, + "aes-128-ctr": { + cipher: "AES", + key: 128, + iv: 16, + mode: "CTR", + type: "stream", + }, + "aes-192-ctr": { + cipher: "AES", + key: 192, + iv: 16, + mode: "CTR", + type: "stream", + }, + "aes-256-ctr": { + cipher: "AES", + key: 256, + iv: 16, + mode: "CTR", + type: "stream", + }, + "aes-128-gcm": { + cipher: "AES", + key: 128, + iv: 12, + mode: "GCM", + type: "auth", + }, + "aes-192-gcm": { + cipher: "AES", + key: 192, + iv: 12, + mode: "GCM", + type: "auth", + }, + "aes-256-gcm": { + cipher: "AES", + key: 256, + iv: 12, + mode: "GCM", + type: "auth", + }, + }; + }, + {}, + ], + 35: [ + function (A, e, t) { + (function (e) { + var i = A("buffer-xor"); + function g(A) { + return (A._prev = A._cipher.encryptBlock(A._prev)), A._prev; + } + t.encrypt = function (A, t) { + for (; A._cache.length < t.length; ) + A._cache = e.concat([A._cache, g(A)]); + var r = A._cache.slice(0, t.length); + return (A._cache = A._cache.slice(t.length)), i(t, r); + }; + }.call(this, A("buffer").Buffer)); + }, + { buffer: 64, "buffer-xor": 63 }, + ], + 36: [ + function (A, e, t) { + var i = A("./aes"), + g = A("safe-buffer").Buffer, + r = A("cipher-base"); + function n(A, e, t, n) { + r.call(this), + (this._cipher = new i.AES(e)), + (this._prev = g.from(t)), + (this._cache = g.allocUnsafe(0)), + (this._secCache = g.allocUnsafe(0)), + (this._decrypt = n), + (this._mode = A); + } + A("inherits")(n, r), + (n.prototype._update = function (A) { + return this._mode.encrypt(this, A, this._decrypt); + }), + (n.prototype._final = function () { + this._cipher.scrub(); + }), + (e.exports = n); + }, + { "./aes": 20, "cipher-base": 65, inherits: 134, "safe-buffer": 180 }, + ], + 37: [ + function (A, e, t) { + var i = A("browserify-des"), + g = A("browserify-aes/browser"), + r = A("browserify-aes/modes"), + n = A("browserify-des/modes"), + B = A("evp_bytestokey"); + function I(A, e, t) { + if (((A = A.toLowerCase()), r[A])) return g.createCipheriv(A, e, t); + if (n[A]) return new i({ key: e, iv: t, mode: A }); + throw new TypeError("invalid suite type"); + } + function o(A, e, t) { + if (((A = A.toLowerCase()), r[A])) return g.createDecipheriv(A, e, t); + if (n[A]) return new i({ key: e, iv: t, mode: A, decrypt: !0 }); + throw new TypeError("invalid suite type"); + } + (t.createCipher = t.Cipher = + function (A, e) { + var t, i; + if (((A = A.toLowerCase()), r[A])) (t = r[A].key), (i = r[A].iv); + else { + if (!n[A]) throw new TypeError("invalid suite type"); + (t = 8 * n[A].key), (i = n[A].iv); + } + var g = B(e, !1, t, i); + return I(A, g.key, g.iv); + }), + (t.createCipheriv = t.Cipheriv = I), + (t.createDecipher = t.Decipher = + function (A, e) { + var t, i; + if (((A = A.toLowerCase()), r[A])) (t = r[A].key), (i = r[A].iv); + else { + if (!n[A]) throw new TypeError("invalid suite type"); + (t = 8 * n[A].key), (i = n[A].iv); + } + var g = B(e, !1, t, i); + return o(A, g.key, g.iv); + }), + (t.createDecipheriv = t.Decipheriv = o), + (t.listCiphers = t.getCiphers = + function () { + return Object.keys(n).concat(g.getCiphers()); + }); + }, + { + "browserify-aes/browser": 22, + "browserify-aes/modes": 33, + "browserify-des": 38, + "browserify-des/modes": 39, + evp_bytestokey: 103, + }, + ], + 38: [ + function (A, e, t) { + var i = A("cipher-base"), + g = A("des.js"), + r = A("inherits"), + n = A("safe-buffer").Buffer, + B = { + "des-ede3-cbc": g.CBC.instantiate(g.EDE), + "des-ede3": g.EDE, + "des-ede-cbc": g.CBC.instantiate(g.EDE), + "des-ede": g.EDE, + "des-cbc": g.CBC.instantiate(g.DES), + "des-ecb": g.DES, + }; + function I(A) { + i.call(this); + var e, + t = A.mode.toLowerCase(), + g = B[t]; + e = A.decrypt ? "decrypt" : "encrypt"; + var r = A.key; + n.isBuffer(r) || (r = n.from(r)), + ("des-ede" !== t && "des-ede-cbc" !== t) || + (r = n.concat([r, r.slice(0, 8)])); + var I = A.iv; + n.isBuffer(I) || (I = n.from(I)), + (this._des = g.create({ key: r, iv: I, type: e })); + } + (B.des = B["des-cbc"]), + (B.des3 = B["des-ede3-cbc"]), + (e.exports = I), + r(I, i), + (I.prototype._update = function (A) { + return n.from(this._des.update(A)); + }), + (I.prototype._final = function () { + return n.from(this._des.final()); + }); + }, + { "cipher-base": 65, "des.js": 74, inherits: 134, "safe-buffer": 180 }, + ], + 39: [ + function (A, e, t) { + (t["des-ecb"] = { key: 8, iv: 0 }), + (t["des-cbc"] = t.des = { key: 8, iv: 8 }), + (t["des-ede3-cbc"] = t.des3 = { key: 24, iv: 8 }), + (t["des-ede3"] = { key: 24, iv: 0 }), + (t["des-ede-cbc"] = { key: 16, iv: 8 }), + (t["des-ede"] = { key: 16, iv: 0 }); + }, + {}, + ], + 40: [ + function (A, e, t) { + (function (t) { + var i = A("bn.js"), + g = A("randombytes"); + function r(A, e) { + var g = (function (A) { + var e = n(A); + return { + blinder: e + .toRed(i.mont(A.modulus)) + .redPow(new i(A.publicExponent)) + .fromRed(), + unblinder: e.invm(A.modulus), + }; + })(e), + r = e.modulus.byteLength(), + B = (i.mont(e.modulus), new i(A).mul(g.blinder).umod(e.modulus)), + I = B.toRed(i.mont(e.prime1)), + o = B.toRed(i.mont(e.prime2)), + a = e.coefficient, + Q = e.prime1, + C = e.prime2, + s = I.redPow(e.exponent1), + c = o.redPow(e.exponent2); + (s = s.fromRed()), (c = c.fromRed()); + var h = s.isub(c).imul(a).umod(Q); + return ( + h.imul(C), + c.iadd(h), + new t(c.imul(g.unblinder).umod(e.modulus).toArray(!1, r)) + ); + } + function n(A) { + for ( + var e = A.modulus.byteLength(), t = new i(g(e)); + t.cmp(A.modulus) >= 0 || !t.umod(A.prime1) || !t.umod(A.prime2); + + ) + t = new i(g(e)); + return t; + } + (e.exports = r), (r.getr = n); + }.call(this, A("buffer").Buffer)); + }, + { "bn.js": 41, buffer: 64, randombytes: 162 }, + ], + 41: [ + function (A, e, t) { + arguments[4][15][0].apply(t, arguments); + }, + { buffer: 19, dup: 15 }, + ], + 42: [ + function (A, e, t) { + e.exports = A("./browser/algorithms.json"); + }, + { "./browser/algorithms.json": 43 }, + ], + 43: [ + function (A, e, t) { + e.exports = { + sha224WithRSAEncryption: { + sign: "rsa", + hash: "sha224", + id: "302d300d06096086480165030402040500041c", + }, + "RSA-SHA224": { + sign: "ecdsa/rsa", + hash: "sha224", + id: "302d300d06096086480165030402040500041c", + }, + sha256WithRSAEncryption: { + sign: "rsa", + hash: "sha256", + id: "3031300d060960864801650304020105000420", + }, + "RSA-SHA256": { + sign: "ecdsa/rsa", + hash: "sha256", + id: "3031300d060960864801650304020105000420", + }, + sha384WithRSAEncryption: { + sign: "rsa", + hash: "sha384", + id: "3041300d060960864801650304020205000430", + }, + "RSA-SHA384": { + sign: "ecdsa/rsa", + hash: "sha384", + id: "3041300d060960864801650304020205000430", + }, + sha512WithRSAEncryption: { + sign: "rsa", + hash: "sha512", + id: "3051300d060960864801650304020305000440", + }, + "RSA-SHA512": { + sign: "ecdsa/rsa", + hash: "sha512", + id: "3051300d060960864801650304020305000440", + }, + "RSA-SHA1": { + sign: "rsa", + hash: "sha1", + id: "3021300906052b0e03021a05000414", + }, + "ecdsa-with-SHA1": { sign: "ecdsa", hash: "sha1", id: "" }, + sha256: { sign: "ecdsa", hash: "sha256", id: "" }, + sha224: { sign: "ecdsa", hash: "sha224", id: "" }, + sha384: { sign: "ecdsa", hash: "sha384", id: "" }, + sha512: { sign: "ecdsa", hash: "sha512", id: "" }, + "DSA-SHA": { sign: "dsa", hash: "sha1", id: "" }, + "DSA-SHA1": { sign: "dsa", hash: "sha1", id: "" }, + DSA: { sign: "dsa", hash: "sha1", id: "" }, + "DSA-WITH-SHA224": { sign: "dsa", hash: "sha224", id: "" }, + "DSA-SHA224": { sign: "dsa", hash: "sha224", id: "" }, + "DSA-WITH-SHA256": { sign: "dsa", hash: "sha256", id: "" }, + "DSA-SHA256": { sign: "dsa", hash: "sha256", id: "" }, + "DSA-WITH-SHA384": { sign: "dsa", hash: "sha384", id: "" }, + "DSA-SHA384": { sign: "dsa", hash: "sha384", id: "" }, + "DSA-WITH-SHA512": { sign: "dsa", hash: "sha512", id: "" }, + "DSA-SHA512": { sign: "dsa", hash: "sha512", id: "" }, + "DSA-RIPEMD160": { sign: "dsa", hash: "rmd160", id: "" }, + ripemd160WithRSA: { + sign: "rsa", + hash: "rmd160", + id: "3021300906052b2403020105000414", + }, + "RSA-RIPEMD160": { + sign: "rsa", + hash: "rmd160", + id: "3021300906052b2403020105000414", + }, + md5WithRSAEncryption: { + sign: "rsa", + hash: "md5", + id: "3020300c06082a864886f70d020505000410", + }, + "RSA-MD5": { + sign: "rsa", + hash: "md5", + id: "3020300c06082a864886f70d020505000410", + }, + }; + }, + {}, + ], + 44: [ + function (A, e, t) { + e.exports = { + "1.3.132.0.10": "secp256k1", + "1.3.132.0.33": "p224", + "1.2.840.10045.3.1.1": "p192", + "1.2.840.10045.3.1.7": "p256", + "1.3.132.0.34": "p384", + "1.3.132.0.35": "p521", + }; + }, + {}, + ], + 45: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer, + g = A("create-hash"), + r = A("readable-stream"), + n = A("inherits"), + B = A("./sign"), + I = A("./verify"), + o = A("./algorithms.json"); + function a(A) { + r.Writable.call(this); + var e = o[A]; + if (!e) throw new Error("Unknown message digest"); + (this._hashType = e.hash), + (this._hash = g(e.hash)), + (this._tag = e.id), + (this._signType = e.sign); + } + function Q(A) { + r.Writable.call(this); + var e = o[A]; + if (!e) throw new Error("Unknown message digest"); + (this._hash = g(e.hash)), + (this._tag = e.id), + (this._signType = e.sign); + } + function C(A) { + return new a(A); + } + function s(A) { + return new Q(A); + } + Object.keys(o).forEach(function (A) { + (o[A].id = i.from(o[A].id, "hex")), (o[A.toLowerCase()] = o[A]); + }), + n(a, r.Writable), + (a.prototype._write = function (A, e, t) { + this._hash.update(A), t(); + }), + (a.prototype.update = function (A, e) { + return ( + "string" == typeof A && (A = i.from(A, e)), + this._hash.update(A), + this + ); + }), + (a.prototype.sign = function (A, e) { + this.end(); + var t = this._hash.digest(), + i = B(t, A, this._hashType, this._signType, this._tag); + return e ? i.toString(e) : i; + }), + n(Q, r.Writable), + (Q.prototype._write = function (A, e, t) { + this._hash.update(A), t(); + }), + (Q.prototype.update = function (A, e) { + return ( + "string" == typeof A && (A = i.from(A, e)), + this._hash.update(A), + this + ); + }), + (Q.prototype.verify = function (A, e, t) { + "string" == typeof e && (e = i.from(e, t)), this.end(); + var g = this._hash.digest(); + return I(e, g, A, this._signType, this._tag); + }), + (e.exports = { Sign: C, Verify: s, createSign: C, createVerify: s }); + }, + { + "./algorithms.json": 43, + "./sign": 46, + "./verify": 47, + "create-hash": 69, + inherits: 134, + "readable-stream": 62, + "safe-buffer": 180, + }, + ], + 46: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer, + g = A("create-hmac"), + r = A("browserify-rsa"), + n = A("elliptic").ec, + B = A("bn.js"), + I = A("parse-asn1"), + o = A("./curves.json"); + function a(A, e, t, r) { + if ((A = i.from(A.toArray())).length < e.byteLength()) { + var n = i.alloc(e.byteLength() - A.length); + A = i.concat([n, A]); + } + var B = t.length, + I = (function (A, e) { + A = (A = Q(A, e)).mod(e); + var t = i.from(A.toArray()); + if (t.length < e.byteLength()) { + var g = i.alloc(e.byteLength() - t.length); + t = i.concat([g, t]); + } + return t; + })(t, e), + o = i.alloc(B); + o.fill(1); + var a = i.alloc(B); + return ( + (a = g(r, a) + .update(o) + .update(i.from([0])) + .update(A) + .update(I) + .digest()), + (o = g(r, a).update(o).digest()), + { + k: (a = g(r, a) + .update(o) + .update(i.from([1])) + .update(A) + .update(I) + .digest()), + v: (o = g(r, a).update(o).digest()), + } + ); + } + function Q(A, e) { + var t = new B(A), + i = (A.length << 3) - e.bitLength(); + return i > 0 && t.ishrn(i), t; + } + function C(A, e, t) { + var r, n; + do { + for (r = i.alloc(0); 8 * r.length < A.bitLength(); ) + (e.v = g(t, e.k).update(e.v).digest()), (r = i.concat([r, e.v])); + (n = Q(r, A)), + (e.k = g(t, e.k) + .update(e.v) + .update(i.from([0])) + .digest()), + (e.v = g(t, e.k).update(e.v).digest()); + } while (-1 !== n.cmp(A)); + return n; + } + function s(A, e, t, i) { + return A.toRed(B.mont(t)).redPow(e).fromRed().mod(i); + } + (e.exports = function (A, e, t, g, c) { + var h = I(e); + if (h.curve) { + if ("ecdsa" !== g && "ecdsa/rsa" !== g) + throw new Error("wrong private key type"); + return (function (A, e) { + var t = o[e.curve.join(".")]; + if (!t) throw new Error("unknown curve " + e.curve.join(".")); + var g = new n(t).keyFromPrivate(e.privateKey).sign(A); + return i.from(g.toDER()); + })(A, h); + } + if ("dsa" === h.type) { + if ("dsa" !== g) throw new Error("wrong private key type"); + return (function (A, e, t) { + for ( + var g, + r = e.params.priv_key, + n = e.params.p, + I = e.params.q, + o = e.params.g, + c = new B(0), + h = Q(A, I).mod(I), + f = !1, + E = a(r, I, A, t); + !1 === f; + + ) + (g = C(I, E, t)), + (c = s(o, g, n, I)), + 0 === + (f = g + .invm(I) + .imul(h.add(r.mul(c))) + .mod(I)).cmpn(0) && ((f = !1), (c = new B(0))); + return (function (A, e) { + (A = A.toArray()), + (e = e.toArray()), + 128 & A[0] && (A = [0].concat(A)), + 128 & e[0] && (e = [0].concat(e)); + var t = [48, A.length + e.length + 4, 2, A.length]; + return (t = t.concat(A, [2, e.length], e)), i.from(t); + })(c, f); + })(A, h, t); + } + if ("rsa" !== g && "ecdsa/rsa" !== g) + throw new Error("wrong private key type"); + A = i.concat([c, A]); + for ( + var f = h.modulus.byteLength(), E = [0, 1]; + A.length + E.length + 1 < f; + + ) + E.push(255); + E.push(0); + for (var u = -1; ++u < A.length; ) E.push(A[u]); + return r(E, h); + }), + (e.exports.getKey = a), + (e.exports.makeKey = C); + }, + { + "./curves.json": 44, + "bn.js": 17, + "browserify-rsa": 40, + "create-hmac": 71, + elliptic: 85, + "parse-asn1": 146, + "safe-buffer": 180, + }, + ], + 47: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer, + g = A("bn.js"), + r = A("elliptic").ec, + n = A("parse-asn1"), + B = A("./curves.json"); + function I(A, e) { + if (A.cmpn(0) <= 0) throw new Error("invalid sig"); + if (A.cmp(e) >= e) throw new Error("invalid sig"); + } + e.exports = function (A, e, t, o, a) { + var Q = n(t); + if ("ec" === Q.type) { + if ("ecdsa" !== o && "ecdsa/rsa" !== o) + throw new Error("wrong public key type"); + return (function (A, e, t) { + var i = B[t.data.algorithm.curve.join(".")]; + if (!i) + throw new Error( + "unknown curve " + t.data.algorithm.curve.join(".") + ); + var g = new r(i), + n = t.data.subjectPrivateKey.data; + return g.verify(e, A, n); + })(A, e, Q); + } + if ("dsa" === Q.type) { + if ("dsa" !== o) throw new Error("wrong public key type"); + return (function (A, e, t) { + var i = t.data.p, + r = t.data.q, + B = t.data.g, + o = t.data.pub_key, + a = n.signature.decode(A, "der"), + Q = a.s, + C = a.r; + I(Q, r), I(C, r); + var s = g.mont(i), + c = Q.invm(r); + return ( + 0 === + B.toRed(s) + .redPow(new g(e).mul(c).mod(r)) + .fromRed() + .mul(o.toRed(s).redPow(C.mul(c).mod(r)).fromRed()) + .mod(i) + .mod(r) + .cmp(C) + ); + })(A, e, Q); + } + if ("rsa" !== o && "ecdsa/rsa" !== o) + throw new Error("wrong public key type"); + e = i.concat([a, e]); + for ( + var C = Q.modulus.byteLength(), s = [1], c = 0; + e.length + s.length + 2 < C; + + ) + s.push(255), c++; + s.push(0); + for (var h = -1; ++h < e.length; ) s.push(e[h]); + s = i.from(s); + var f = g.mont(Q.modulus); + (A = (A = new g(A).toRed(f)).redPow(new g(Q.publicExponent))), + (A = i.from(A.fromRed().toArray())); + var E = c < 8 ? 1 : 0; + for ( + C = Math.min(A.length, s.length), + A.length !== s.length && (E = 1), + h = -1; + ++h < C; + + ) + E |= A[h] ^ s[h]; + return 0 === E; + }; + }, + { + "./curves.json": 44, + "bn.js": 17, + elliptic: 85, + "parse-asn1": 146, + "safe-buffer": 180, + }, + ], + 48: [ + function (A, e, t) { + "use strict"; + var i = {}; + function g(A, e, t) { + t || (t = Error); + var g = (function (A) { + var t, i; + function g(t, i, g) { + return ( + A.call( + this, + (function (A, t, i) { + return "string" == typeof e ? e : e(A, t, i); + })(t, i, g) + ) || this + ); + } + return ( + (i = A), + ((t = g).prototype = Object.create(i.prototype)), + (t.prototype.constructor = t), + (t.__proto__ = i), + g + ); + })(t); + (g.prototype.name = t.name), (g.prototype.code = A), (i[A] = g); + } + function r(A, e) { + if (Array.isArray(A)) { + var t = A.length; + return ( + (A = A.map(function (A) { + return String(A); + })), + t > 2 + ? "one of " + .concat(e, " ") + .concat(A.slice(0, t - 1).join(", "), ", or ") + A[t - 1] + : 2 === t + ? "one of ".concat(e, " ").concat(A[0], " or ").concat(A[1]) + : "of ".concat(e, " ").concat(A[0]) + ); + } + return "of ".concat(e, " ").concat(String(A)); + } + g( + "ERR_INVALID_OPT_VALUE", + function (A, e) { + return 'The value "' + e + '" is invalid for option "' + A + '"'; + }, + TypeError + ), + g( + "ERR_INVALID_ARG_TYPE", + function (A, e, t) { + var i, g, n, B; + if ( + ("string" == typeof e && + ((g = "not "), e.substr(!n || n < 0 ? 0 : +n, g.length) === g) + ? ((i = "must not be"), (e = e.replace(/^not /, ""))) + : (i = "must be"), + (function (A, e, t) { + return ( + (void 0 === t || t > A.length) && (t = A.length), + A.substring(t - e.length, t) === e + ); + })(A, " argument")) + ) + B = "The ".concat(A, " ").concat(i, " ").concat(r(e, "type")); + else { + var I = (function (A, e, t) { + return ( + "number" != typeof t && (t = 0), + !(t + e.length > A.length) && -1 !== A.indexOf(e, t) + ); + })(A, ".") + ? "property" + : "argument"; + B = 'The "' + .concat(A, '" ') + .concat(I, " ") + .concat(i, " ") + .concat(r(e, "type")); + } + return (B += ". Received type ".concat(typeof t)); + }, + TypeError + ), + g("ERR_STREAM_PUSH_AFTER_EOF", "stream.push() after EOF"), + g("ERR_METHOD_NOT_IMPLEMENTED", function (A) { + return "The " + A + " method is not implemented"; + }), + g("ERR_STREAM_PREMATURE_CLOSE", "Premature close"), + g("ERR_STREAM_DESTROYED", function (A) { + return "Cannot call " + A + " after a stream was destroyed"; + }), + g("ERR_MULTIPLE_CALLBACK", "Callback called multiple times"), + g("ERR_STREAM_CANNOT_PIPE", "Cannot pipe, not readable"), + g("ERR_STREAM_WRITE_AFTER_END", "write after end"), + g( + "ERR_STREAM_NULL_VALUES", + "May not write null values to stream", + TypeError + ), + g( + "ERR_UNKNOWN_ENCODING", + function (A) { + return "Unknown encoding: " + A; + }, + TypeError + ), + g( + "ERR_STREAM_UNSHIFT_AFTER_END_EVENT", + "stream.unshift() after end event" + ), + (e.exports.codes = i); + }, + {}, + ], + 49: [ + function (A, e, t) { + (function (t) { + "use strict"; + var i = + Object.keys || + function (A) { + var e = []; + for (var t in A) e.push(t); + return e; + }; + e.exports = o; + var g = A("./_stream_readable"), + r = A("./_stream_writable"); + A("inherits")(o, g); + for (var n = i(r.prototype), B = 0; B < n.length; B++) { + var I = n[B]; + o.prototype[I] || (o.prototype[I] = r.prototype[I]); + } + function o(A) { + if (!(this instanceof o)) return new o(A); + g.call(this, A), + r.call(this, A), + (this.allowHalfOpen = !0), + A && + (!1 === A.readable && (this.readable = !1), + !1 === A.writable && (this.writable = !1), + !1 === A.allowHalfOpen && + ((this.allowHalfOpen = !1), this.once("end", a))); + } + function a() { + this._writableState.ended || t.nextTick(Q, this); + } + function Q(A) { + A.end(); + } + Object.defineProperty(o.prototype, "writableHighWaterMark", { + enumerable: !1, + get: function () { + return this._writableState.highWaterMark; + }, + }), + Object.defineProperty(o.prototype, "writableBuffer", { + enumerable: !1, + get: function () { + return this._writableState && this._writableState.getBuffer(); + }, + }), + Object.defineProperty(o.prototype, "writableLength", { + enumerable: !1, + get: function () { + return this._writableState.length; + }, + }), + Object.defineProperty(o.prototype, "destroyed", { + enumerable: !1, + get: function () { + return ( + void 0 !== this._readableState && + void 0 !== this._writableState && + this._readableState.destroyed && + this._writableState.destroyed + ); + }, + set: function (A) { + void 0 !== this._readableState && + void 0 !== this._writableState && + ((this._readableState.destroyed = A), + (this._writableState.destroyed = A)); + }, + }); + }.call(this, A("_process"))); + }, + { + "./_stream_readable": 51, + "./_stream_writable": 53, + _process: 154, + inherits: 134, + }, + ], + 50: [ + function (A, e, t) { + "use strict"; + e.exports = g; + var i = A("./_stream_transform"); + function g(A) { + if (!(this instanceof g)) return new g(A); + i.call(this, A); + } + A("inherits")(g, i), + (g.prototype._transform = function (A, e, t) { + t(null, A); + }); + }, + { "./_stream_transform": 52, inherits: 134 }, + ], + 51: [ + function (A, e, t) { + (function (t, i) { + "use strict"; + var g; + (e.exports = y), (y.ReadableState = b); + A("events").EventEmitter; + var r = function (A, e) { + return A.listeners(e).length; + }, + n = A("./internal/streams/stream"), + B = A("buffer").Buffer, + I = i.Uint8Array || function () {}; + var o, + a = A("util"); + o = a && a.debuglog ? a.debuglog("stream") : function () {}; + var Q, + C, + s, + c = A("./internal/streams/buffer_list"), + h = A("./internal/streams/destroy"), + f = A("./internal/streams/state").getHighWaterMark, + E = A("../errors").codes, + u = E.ERR_INVALID_ARG_TYPE, + d = E.ERR_STREAM_PUSH_AFTER_EOF, + l = E.ERR_METHOD_NOT_IMPLEMENTED, + w = E.ERR_STREAM_UNSHIFT_AFTER_END_EVENT; + A("inherits")(y, n); + var p = h.errorOrDestroy, + D = ["error", "close", "destroy", "pause", "resume"]; + function b(e, t, i) { + (g = g || A("./_stream_duplex")), + (e = e || {}), + "boolean" != typeof i && (i = t instanceof g), + (this.objectMode = !!e.objectMode), + i && + (this.objectMode = this.objectMode || !!e.readableObjectMode), + (this.highWaterMark = f(this, e, "readableHighWaterMark", i)), + (this.buffer = new c()), + (this.length = 0), + (this.pipes = null), + (this.pipesCount = 0), + (this.flowing = null), + (this.ended = !1), + (this.endEmitted = !1), + (this.reading = !1), + (this.sync = !0), + (this.needReadable = !1), + (this.emittedReadable = !1), + (this.readableListening = !1), + (this.resumeScheduled = !1), + (this.paused = !0), + (this.emitClose = !1 !== e.emitClose), + (this.autoDestroy = !!e.autoDestroy), + (this.destroyed = !1), + (this.defaultEncoding = e.defaultEncoding || "utf8"), + (this.awaitDrain = 0), + (this.readingMore = !1), + (this.decoder = null), + (this.encoding = null), + e.encoding && + (Q || (Q = A("string_decoder/").StringDecoder), + (this.decoder = new Q(e.encoding)), + (this.encoding = e.encoding)); + } + function y(e) { + if (((g = g || A("./_stream_duplex")), !(this instanceof y))) + return new y(e); + var t = this instanceof g; + (this._readableState = new b(e, this, t)), + (this.readable = !0), + e && + ("function" == typeof e.read && (this._read = e.read), + "function" == typeof e.destroy && (this._destroy = e.destroy)), + n.call(this); + } + function M(A, e, t, i, g) { + o("readableAddChunk", e); + var r, + n = A._readableState; + if (null === e) + (n.reading = !1), + (function (A, e) { + if ((o("onEofChunk"), e.ended)) return; + if (e.decoder) { + var t = e.decoder.end(); + t && + t.length && + (e.buffer.push(t), + (e.length += e.objectMode ? 1 : t.length)); + } + (e.ended = !0), + e.sync + ? F(A) + : ((e.needReadable = !1), + e.emittedReadable || ((e.emittedReadable = !0), N(A))); + })(A, n); + else if ( + (g || + (r = (function (A, e) { + var t; + (i = e), + B.isBuffer(i) || + i instanceof I || + "string" == typeof e || + void 0 === e || + A.objectMode || + (t = new u( + "chunk", + ["string", "Buffer", "Uint8Array"], + e + )); + var i; + return t; + })(n, e)), + r) + ) + p(A, r); + else if (n.objectMode || (e && e.length > 0)) + if ( + ("string" == typeof e || + n.objectMode || + Object.getPrototypeOf(e) === B.prototype || + (e = (function (A) { + return B.from(A); + })(e)), + i) + ) + n.endEmitted ? p(A, new w()) : m(A, n, e, !0); + else if (n.ended) p(A, new d()); + else { + if (n.destroyed) return !1; + (n.reading = !1), + n.decoder && !t + ? ((e = n.decoder.write(e)), + n.objectMode || 0 !== e.length ? m(A, n, e, !1) : S(A, n)) + : m(A, n, e, !1); + } + else i || ((n.reading = !1), S(A, n)); + return !n.ended && (n.length < n.highWaterMark || 0 === n.length); + } + function m(A, e, t, i) { + e.flowing && 0 === e.length && !e.sync + ? ((e.awaitDrain = 0), A.emit("data", t)) + : ((e.length += e.objectMode ? 1 : t.length), + i ? e.buffer.unshift(t) : e.buffer.push(t), + e.needReadable && F(A)), + S(A, e); + } + Object.defineProperty(y.prototype, "destroyed", { + enumerable: !1, + get: function () { + return ( + void 0 !== this._readableState && this._readableState.destroyed + ); + }, + set: function (A) { + this._readableState && (this._readableState.destroyed = A); + }, + }), + (y.prototype.destroy = h.destroy), + (y.prototype._undestroy = h.undestroy), + (y.prototype._destroy = function (A, e) { + e(A); + }), + (y.prototype.push = function (A, e) { + var t, + i = this._readableState; + return ( + i.objectMode + ? (t = !0) + : "string" == typeof A && + ((e = e || i.defaultEncoding) !== i.encoding && + ((A = B.from(A, e)), (e = "")), + (t = !0)), + M(this, A, e, !1, t) + ); + }), + (y.prototype.unshift = function (A) { + return M(this, A, null, !0, !1); + }), + (y.prototype.isPaused = function () { + return !1 === this._readableState.flowing; + }), + (y.prototype.setEncoding = function (e) { + Q || (Q = A("string_decoder/").StringDecoder); + var t = new Q(e); + (this._readableState.decoder = t), + (this._readableState.encoding = + this._readableState.decoder.encoding); + for ( + var i = this._readableState.buffer.head, g = ""; + null !== i; + + ) + (g += t.write(i.data)), (i = i.next); + return ( + this._readableState.buffer.clear(), + "" !== g && this._readableState.buffer.push(g), + (this._readableState.length = g.length), + this + ); + }); + var G = 1073741824; + function k(A, e) { + return A <= 0 || (0 === e.length && e.ended) + ? 0 + : e.objectMode + ? 1 + : A != A + ? e.flowing && e.length + ? e.buffer.head.data.length + : e.length + : (A > e.highWaterMark && + (e.highWaterMark = (function (A) { + return ( + A >= G + ? (A = G) + : (A--, + (A |= A >>> 1), + (A |= A >>> 2), + (A |= A >>> 4), + (A |= A >>> 8), + (A |= A >>> 16), + A++), + A + ); + })(A)), + A <= e.length + ? A + : e.ended + ? e.length + : ((e.needReadable = !0), 0)); + } + function F(A) { + var e = A._readableState; + o("emitReadable", e.needReadable, e.emittedReadable), + (e.needReadable = !1), + e.emittedReadable || + (o("emitReadable", e.flowing), + (e.emittedReadable = !0), + t.nextTick(N, A)); + } + function N(A) { + var e = A._readableState; + o("emitReadable_", e.destroyed, e.length, e.ended), + e.destroyed || + (!e.length && !e.ended) || + (A.emit("readable"), (e.emittedReadable = !1)), + (e.needReadable = + !e.flowing && !e.ended && e.length <= e.highWaterMark), + J(A); + } + function S(A, e) { + e.readingMore || ((e.readingMore = !0), t.nextTick(Y, A, e)); + } + function Y(A, e) { + for ( + ; + !e.reading && + !e.ended && + (e.length < e.highWaterMark || (e.flowing && 0 === e.length)); + + ) { + var t = e.length; + if ((o("maybeReadMore read 0"), A.read(0), t === e.length)) break; + } + e.readingMore = !1; + } + function v(A) { + var e = A._readableState; + (e.readableListening = A.listenerCount("readable") > 0), + e.resumeScheduled && !e.paused + ? (e.flowing = !0) + : A.listenerCount("data") > 0 && A.resume(); + } + function K(A) { + o("readable nexttick read 0"), A.read(0); + } + function U(A, e) { + o("resume", e.reading), + e.reading || A.read(0), + (e.resumeScheduled = !1), + A.emit("resume"), + J(A), + e.flowing && !e.reading && A.read(0); + } + function J(A) { + var e = A._readableState; + for (o("flow", e.flowing); e.flowing && null !== A.read(); ); + } + function H(A, e) { + return 0 === e.length + ? null + : (e.objectMode + ? (t = e.buffer.shift()) + : !A || A >= e.length + ? ((t = e.decoder + ? e.buffer.join("") + : 1 === e.buffer.length + ? e.buffer.first() + : e.buffer.concat(e.length)), + e.buffer.clear()) + : (t = e.buffer.consume(A, e.decoder)), + t); + var t; + } + function R(A) { + var e = A._readableState; + o("endReadable", e.endEmitted), + e.endEmitted || ((e.ended = !0), t.nextTick(q, e, A)); + } + function q(A, e) { + if ( + (o("endReadableNT", A.endEmitted, A.length), + !A.endEmitted && + 0 === A.length && + ((A.endEmitted = !0), + (e.readable = !1), + e.emit("end"), + A.autoDestroy)) + ) { + var t = e._writableState; + (!t || (t.autoDestroy && t.finished)) && e.destroy(); + } + } + function L(A, e) { + for (var t = 0, i = A.length; t < i; t++) if (A[t] === e) return t; + return -1; + } + (y.prototype.read = function (A) { + o("read", A), (A = parseInt(A, 10)); + var e = this._readableState, + t = A; + if ( + (0 !== A && (e.emittedReadable = !1), + 0 === A && + e.needReadable && + ((0 !== e.highWaterMark + ? e.length >= e.highWaterMark + : e.length > 0) || + e.ended)) + ) + return ( + o("read: emitReadable", e.length, e.ended), + 0 === e.length && e.ended ? R(this) : F(this), + null + ); + if (0 === (A = k(A, e)) && e.ended) + return 0 === e.length && R(this), null; + var i, + g = e.needReadable; + return ( + o("need readable", g), + (0 === e.length || e.length - A < e.highWaterMark) && + o("length less than watermark", (g = !0)), + e.ended || e.reading + ? o("reading or ended", (g = !1)) + : g && + (o("do read"), + (e.reading = !0), + (e.sync = !0), + 0 === e.length && (e.needReadable = !0), + this._read(e.highWaterMark), + (e.sync = !1), + e.reading || (A = k(t, e))), + null === (i = A > 0 ? H(A, e) : null) + ? ((e.needReadable = e.length <= e.highWaterMark), (A = 0)) + : ((e.length -= A), (e.awaitDrain = 0)), + 0 === e.length && + (e.ended || (e.needReadable = !0), + t !== A && e.ended && R(this)), + null !== i && this.emit("data", i), + i + ); + }), + (y.prototype._read = function (A) { + p(this, new l("_read()")); + }), + (y.prototype.pipe = function (A, e) { + var i = this, + g = this._readableState; + switch (g.pipesCount) { + case 0: + g.pipes = A; + break; + case 1: + g.pipes = [g.pipes, A]; + break; + default: + g.pipes.push(A); + } + (g.pipesCount += 1), o("pipe count=%d opts=%j", g.pipesCount, e); + var n = + (!e || !1 !== e.end) && A !== t.stdout && A !== t.stderr + ? I + : f; + function B(e, t) { + o("onunpipe"), + e === i && + t && + !1 === t.hasUnpiped && + ((t.hasUnpiped = !0), + o("cleanup"), + A.removeListener("close", c), + A.removeListener("finish", h), + A.removeListener("drain", a), + A.removeListener("error", s), + A.removeListener("unpipe", B), + i.removeListener("end", I), + i.removeListener("end", f), + i.removeListener("data", C), + (Q = !0), + !g.awaitDrain || + (A._writableState && !A._writableState.needDrain) || + a()); + } + function I() { + o("onend"), A.end(); + } + g.endEmitted ? t.nextTick(n) : i.once("end", n), + A.on("unpipe", B); + var a = (function (A) { + return function () { + var e = A._readableState; + o("pipeOnDrain", e.awaitDrain), + e.awaitDrain && e.awaitDrain--, + 0 === e.awaitDrain && + r(A, "data") && + ((e.flowing = !0), J(A)); + }; + })(i); + A.on("drain", a); + var Q = !1; + function C(e) { + o("ondata"); + var t = A.write(e); + o("dest.write", t), + !1 === t && + (((1 === g.pipesCount && g.pipes === A) || + (g.pipesCount > 1 && -1 !== L(g.pipes, A))) && + !Q && + (o("false write response, pause", g.awaitDrain), + g.awaitDrain++), + i.pause()); + } + function s(e) { + o("onerror", e), + f(), + A.removeListener("error", s), + 0 === r(A, "error") && p(A, e); + } + function c() { + A.removeListener("finish", h), f(); + } + function h() { + o("onfinish"), A.removeListener("close", c), f(); + } + function f() { + o("unpipe"), i.unpipe(A); + } + return ( + i.on("data", C), + (function (A, e, t) { + if ("function" == typeof A.prependListener) + return A.prependListener(e, t); + A._events && A._events[e] + ? Array.isArray(A._events[e]) + ? A._events[e].unshift(t) + : (A._events[e] = [t, A._events[e]]) + : A.on(e, t); + })(A, "error", s), + A.once("close", c), + A.once("finish", h), + A.emit("pipe", i), + g.flowing || (o("pipe resume"), i.resume()), + A + ); + }), + (y.prototype.unpipe = function (A) { + var e = this._readableState, + t = { hasUnpiped: !1 }; + if (0 === e.pipesCount) return this; + if (1 === e.pipesCount) + return A && A !== e.pipes + ? this + : (A || (A = e.pipes), + (e.pipes = null), + (e.pipesCount = 0), + (e.flowing = !1), + A && A.emit("unpipe", this, t), + this); + if (!A) { + var i = e.pipes, + g = e.pipesCount; + (e.pipes = null), (e.pipesCount = 0), (e.flowing = !1); + for (var r = 0; r < g; r++) + i[r].emit("unpipe", this, { hasUnpiped: !1 }); + return this; + } + var n = L(e.pipes, A); + return -1 === n + ? this + : (e.pipes.splice(n, 1), + (e.pipesCount -= 1), + 1 === e.pipesCount && (e.pipes = e.pipes[0]), + A.emit("unpipe", this, t), + this); + }), + (y.prototype.on = function (A, e) { + var i = n.prototype.on.call(this, A, e), + g = this._readableState; + return ( + "data" === A + ? ((g.readableListening = this.listenerCount("readable") > 0), + !1 !== g.flowing && this.resume()) + : "readable" === A && + (g.endEmitted || + g.readableListening || + ((g.readableListening = g.needReadable = !0), + (g.flowing = !1), + (g.emittedReadable = !1), + o("on readable", g.length, g.reading), + g.length ? F(this) : g.reading || t.nextTick(K, this))), + i + ); + }), + (y.prototype.addListener = y.prototype.on), + (y.prototype.removeListener = function (A, e) { + var i = n.prototype.removeListener.call(this, A, e); + return "readable" === A && t.nextTick(v, this), i; + }), + (y.prototype.removeAllListeners = function (A) { + var e = n.prototype.removeAllListeners.apply(this, arguments); + return ( + ("readable" !== A && void 0 !== A) || t.nextTick(v, this), e + ); + }), + (y.prototype.resume = function () { + var A = this._readableState; + return ( + A.flowing || + (o("resume"), + (A.flowing = !A.readableListening), + (function (A, e) { + e.resumeScheduled || + ((e.resumeScheduled = !0), t.nextTick(U, A, e)); + })(this, A)), + (A.paused = !1), + this + ); + }), + (y.prototype.pause = function () { + return ( + o("call pause flowing=%j", this._readableState.flowing), + !1 !== this._readableState.flowing && + (o("pause"), + (this._readableState.flowing = !1), + this.emit("pause")), + (this._readableState.paused = !0), + this + ); + }), + (y.prototype.wrap = function (A) { + var e = this, + t = this._readableState, + i = !1; + for (var g in (A.on("end", function () { + if ((o("wrapped end"), t.decoder && !t.ended)) { + var A = t.decoder.end(); + A && A.length && e.push(A); + } + e.push(null); + }), + A.on("data", function (g) { + (o("wrapped data"), + t.decoder && (g = t.decoder.write(g)), + !t.objectMode || (null !== g && void 0 !== g)) && + (t.objectMode || (g && g.length)) && + (e.push(g) || ((i = !0), A.pause())); + }), + A)) + void 0 === this[g] && + "function" == typeof A[g] && + (this[g] = (function (e) { + return function () { + return A[e].apply(A, arguments); + }; + })(g)); + for (var r = 0; r < D.length; r++) + A.on(D[r], this.emit.bind(this, D[r])); + return ( + (this._read = function (e) { + o("wrapped _read", e), i && ((i = !1), A.resume()); + }), + this + ); + }), + "function" == typeof Symbol && + (y.prototype[Symbol.asyncIterator] = function () { + return ( + void 0 === C && (C = A("./internal/streams/async_iterator")), + C(this) + ); + }), + Object.defineProperty(y.prototype, "readableHighWaterMark", { + enumerable: !1, + get: function () { + return this._readableState.highWaterMark; + }, + }), + Object.defineProperty(y.prototype, "readableBuffer", { + enumerable: !1, + get: function () { + return this._readableState && this._readableState.buffer; + }, + }), + Object.defineProperty(y.prototype, "readableFlowing", { + enumerable: !1, + get: function () { + return this._readableState.flowing; + }, + set: function (A) { + this._readableState && (this._readableState.flowing = A); + }, + }), + (y._fromList = H), + Object.defineProperty(y.prototype, "readableLength", { + enumerable: !1, + get: function () { + return this._readableState.length; + }, + }), + "function" == typeof Symbol && + (y.from = function (e, t) { + return ( + void 0 === s && (s = A("./internal/streams/from")), s(y, e, t) + ); + }); + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { + "../errors": 48, + "./_stream_duplex": 49, + "./internal/streams/async_iterator": 54, + "./internal/streams/buffer_list": 55, + "./internal/streams/destroy": 56, + "./internal/streams/from": 58, + "./internal/streams/state": 60, + "./internal/streams/stream": 61, + _process: 154, + buffer: 64, + events: 102, + inherits: 134, + "string_decoder/": 191, + util: 19, + }, + ], + 52: [ + function (A, e, t) { + "use strict"; + e.exports = o; + var i = A("../errors").codes, + g = i.ERR_METHOD_NOT_IMPLEMENTED, + r = i.ERR_MULTIPLE_CALLBACK, + n = i.ERR_TRANSFORM_ALREADY_TRANSFORMING, + B = i.ERR_TRANSFORM_WITH_LENGTH_0, + I = A("./_stream_duplex"); + function o(A) { + if (!(this instanceof o)) return new o(A); + I.call(this, A), + (this._transformState = { + afterTransform: function (A, e) { + var t = this._transformState; + t.transforming = !1; + var i = t.writecb; + if (null === i) return this.emit("error", new r()); + (t.writechunk = null), + (t.writecb = null), + null != e && this.push(e), + i(A); + var g = this._readableState; + (g.reading = !1), + (g.needReadable || g.length < g.highWaterMark) && + this._read(g.highWaterMark); + }.bind(this), + needTransform: !1, + transforming: !1, + writecb: null, + writechunk: null, + writeencoding: null, + }), + (this._readableState.needReadable = !0), + (this._readableState.sync = !1), + A && + ("function" == typeof A.transform && + (this._transform = A.transform), + "function" == typeof A.flush && (this._flush = A.flush)), + this.on("prefinish", a); + } + function a() { + var A = this; + "function" != typeof this._flush || this._readableState.destroyed + ? Q(this, null, null) + : this._flush(function (e, t) { + Q(A, e, t); + }); + } + function Q(A, e, t) { + if (e) return A.emit("error", e); + if ((null != t && A.push(t), A._writableState.length)) throw new B(); + if (A._transformState.transforming) throw new n(); + return A.push(null); + } + A("inherits")(o, I), + (o.prototype.push = function (A, e) { + return ( + (this._transformState.needTransform = !1), + I.prototype.push.call(this, A, e) + ); + }), + (o.prototype._transform = function (A, e, t) { + t(new g("_transform()")); + }), + (o.prototype._write = function (A, e, t) { + var i = this._transformState; + if ( + ((i.writecb = t), + (i.writechunk = A), + (i.writeencoding = e), + !i.transforming) + ) { + var g = this._readableState; + (i.needTransform || + g.needReadable || + g.length < g.highWaterMark) && + this._read(g.highWaterMark); + } + }), + (o.prototype._read = function (A) { + var e = this._transformState; + null === e.writechunk || e.transforming + ? (e.needTransform = !0) + : ((e.transforming = !0), + this._transform( + e.writechunk, + e.writeencoding, + e.afterTransform + )); + }), + (o.prototype._destroy = function (A, e) { + I.prototype._destroy.call(this, A, function (A) { + e(A); + }); + }); + }, + { "../errors": 48, "./_stream_duplex": 49, inherits: 134 }, + ], + 53: [ + function (A, e, t) { + (function (t, i) { + "use strict"; + function g(A) { + var e = this; + (this.next = null), + (this.entry = null), + (this.finish = function () { + !(function (A, e, t) { + var i = A.entry; + A.entry = null; + for (; i; ) { + var g = i.callback; + e.pendingcb--, g(t), (i = i.next); + } + e.corkedRequestsFree.next = A; + })(e, A); + }); + } + var r; + (e.exports = y), (y.WritableState = b); + var n = { deprecate: A("util-deprecate") }, + B = A("./internal/streams/stream"), + I = A("buffer").Buffer, + o = i.Uint8Array || function () {}; + var a, + Q = A("./internal/streams/destroy"), + C = A("./internal/streams/state").getHighWaterMark, + s = A("../errors").codes, + c = s.ERR_INVALID_ARG_TYPE, + h = s.ERR_METHOD_NOT_IMPLEMENTED, + f = s.ERR_MULTIPLE_CALLBACK, + E = s.ERR_STREAM_CANNOT_PIPE, + u = s.ERR_STREAM_DESTROYED, + d = s.ERR_STREAM_NULL_VALUES, + l = s.ERR_STREAM_WRITE_AFTER_END, + w = s.ERR_UNKNOWN_ENCODING, + p = Q.errorOrDestroy; + function D() {} + function b(e, i, n) { + (r = r || A("./_stream_duplex")), + (e = e || {}), + "boolean" != typeof n && (n = i instanceof r), + (this.objectMode = !!e.objectMode), + n && + (this.objectMode = this.objectMode || !!e.writableObjectMode), + (this.highWaterMark = C(this, e, "writableHighWaterMark", n)), + (this.finalCalled = !1), + (this.needDrain = !1), + (this.ending = !1), + (this.ended = !1), + (this.finished = !1), + (this.destroyed = !1); + var B = !1 === e.decodeStrings; + (this.decodeStrings = !B), + (this.defaultEncoding = e.defaultEncoding || "utf8"), + (this.length = 0), + (this.writing = !1), + (this.corked = 0), + (this.sync = !0), + (this.bufferProcessing = !1), + (this.onwrite = function (A) { + !(function (A, e) { + var i = A._writableState, + g = i.sync, + r = i.writecb; + if ("function" != typeof r) throw new f(); + if ( + ((function (A) { + (A.writing = !1), + (A.writecb = null), + (A.length -= A.writelen), + (A.writelen = 0); + })(i), + e) + ) + !(function (A, e, i, g, r) { + --e.pendingcb, + i + ? (t.nextTick(r, g), + t.nextTick(N, A, e), + (A._writableState.errorEmitted = !0), + p(A, g)) + : (r(g), + (A._writableState.errorEmitted = !0), + p(A, g), + N(A, e)); + })(A, i, g, e, r); + else { + var n = k(i) || A.destroyed; + n || + i.corked || + i.bufferProcessing || + !i.bufferedRequest || + G(A, i), + g ? t.nextTick(m, A, i, n, r) : m(A, i, n, r); + } + })(i, A); + }), + (this.writecb = null), + (this.writelen = 0), + (this.bufferedRequest = null), + (this.lastBufferedRequest = null), + (this.pendingcb = 0), + (this.prefinished = !1), + (this.errorEmitted = !1), + (this.emitClose = !1 !== e.emitClose), + (this.autoDestroy = !!e.autoDestroy), + (this.bufferedRequestCount = 0), + (this.corkedRequestsFree = new g(this)); + } + function y(e) { + var t = this instanceof (r = r || A("./_stream_duplex")); + if (!t && !a.call(y, this)) return new y(e); + (this._writableState = new b(e, this, t)), + (this.writable = !0), + e && + ("function" == typeof e.write && (this._write = e.write), + "function" == typeof e.writev && (this._writev = e.writev), + "function" == typeof e.destroy && (this._destroy = e.destroy), + "function" == typeof e.final && (this._final = e.final)), + B.call(this); + } + function M(A, e, t, i, g, r, n) { + (e.writelen = i), + (e.writecb = n), + (e.writing = !0), + (e.sync = !0), + e.destroyed + ? e.onwrite(new u("write")) + : t + ? A._writev(g, e.onwrite) + : A._write(g, r, e.onwrite), + (e.sync = !1); + } + function m(A, e, t, i) { + t || + (function (A, e) { + 0 === e.length && + e.needDrain && + ((e.needDrain = !1), A.emit("drain")); + })(A, e), + e.pendingcb--, + i(), + N(A, e); + } + function G(A, e) { + e.bufferProcessing = !0; + var t = e.bufferedRequest; + if (A._writev && t && t.next) { + var i = e.bufferedRequestCount, + r = new Array(i), + n = e.corkedRequestsFree; + n.entry = t; + for (var B = 0, I = !0; t; ) + (r[B] = t), t.isBuf || (I = !1), (t = t.next), (B += 1); + (r.allBuffers = I), + M(A, e, !0, e.length, r, "", n.finish), + e.pendingcb++, + (e.lastBufferedRequest = null), + n.next + ? ((e.corkedRequestsFree = n.next), (n.next = null)) + : (e.corkedRequestsFree = new g(e)), + (e.bufferedRequestCount = 0); + } else { + for (; t; ) { + var o = t.chunk, + a = t.encoding, + Q = t.callback; + if ( + (M(A, e, !1, e.objectMode ? 1 : o.length, o, a, Q), + (t = t.next), + e.bufferedRequestCount--, + e.writing) + ) + break; + } + null === t && (e.lastBufferedRequest = null); + } + (e.bufferedRequest = t), (e.bufferProcessing = !1); + } + function k(A) { + return ( + A.ending && + 0 === A.length && + null === A.bufferedRequest && + !A.finished && + !A.writing + ); + } + function F(A, e) { + A._final(function (t) { + e.pendingcb--, + t && p(A, t), + (e.prefinished = !0), + A.emit("prefinish"), + N(A, e); + }); + } + function N(A, e) { + var i = k(e); + if ( + i && + ((function (A, e) { + e.prefinished || + e.finalCalled || + ("function" != typeof A._final || e.destroyed + ? ((e.prefinished = !0), A.emit("prefinish")) + : (e.pendingcb++, + (e.finalCalled = !0), + t.nextTick(F, A, e))); + })(A, e), + 0 === e.pendingcb && + ((e.finished = !0), A.emit("finish"), e.autoDestroy)) + ) { + var g = A._readableState; + (!g || (g.autoDestroy && g.endEmitted)) && A.destroy(); + } + return i; + } + A("inherits")(y, B), + (b.prototype.getBuffer = function () { + for (var A = this.bufferedRequest, e = []; A; ) + e.push(A), (A = A.next); + return e; + }), + (function () { + try { + Object.defineProperty(b.prototype, "buffer", { + get: n.deprecate( + function () { + return this.getBuffer(); + }, + "_writableState.buffer is deprecated. Use _writableState.getBuffer instead.", + "DEP0003" + ), + }); + } catch (A) {} + })(), + "function" == typeof Symbol && + Symbol.hasInstance && + "function" == typeof Function.prototype[Symbol.hasInstance] + ? ((a = Function.prototype[Symbol.hasInstance]), + Object.defineProperty(y, Symbol.hasInstance, { + value: function (A) { + return ( + !!a.call(this, A) || + (this === y && A && A._writableState instanceof b) + ); + }, + })) + : (a = function (A) { + return A instanceof this; + }), + (y.prototype.pipe = function () { + p(this, new E()); + }), + (y.prototype.write = function (A, e, i) { + var g, + r = this._writableState, + n = !1, + B = !r.objectMode && ((g = A), I.isBuffer(g) || g instanceof o); + return ( + B && + !I.isBuffer(A) && + (A = (function (A) { + return I.from(A); + })(A)), + "function" == typeof e && ((i = e), (e = null)), + B ? (e = "buffer") : e || (e = r.defaultEncoding), + "function" != typeof i && (i = D), + r.ending + ? (function (A, e) { + var i = new l(); + p(A, i), t.nextTick(e, i); + })(this, i) + : (B || + (function (A, e, i, g) { + var r; + return ( + null === i + ? (r = new d()) + : "string" == typeof i || + e.objectMode || + (r = new c("chunk", ["string", "Buffer"], i)), + !r || (p(A, r), t.nextTick(g, r), !1) + ); + })(this, r, A, i)) && + (r.pendingcb++, + (n = (function (A, e, t, i, g, r) { + if (!t) { + var n = (function (A, e, t) { + A.objectMode || + !1 === A.decodeStrings || + "string" != typeof e || + (e = I.from(e, t)); + return e; + })(e, i, g); + i !== n && ((t = !0), (g = "buffer"), (i = n)); + } + var B = e.objectMode ? 1 : i.length; + e.length += B; + var o = e.length < e.highWaterMark; + o || (e.needDrain = !0); + if (e.writing || e.corked) { + var a = e.lastBufferedRequest; + (e.lastBufferedRequest = { + chunk: i, + encoding: g, + isBuf: t, + callback: r, + next: null, + }), + a + ? (a.next = e.lastBufferedRequest) + : (e.bufferedRequest = e.lastBufferedRequest), + (e.bufferedRequestCount += 1); + } else M(A, e, !1, B, i, g, r); + return o; + })(this, r, B, A, e, i))), + n + ); + }), + (y.prototype.cork = function () { + this._writableState.corked++; + }), + (y.prototype.uncork = function () { + var A = this._writableState; + A.corked && + (A.corked--, + A.writing || + A.corked || + A.bufferProcessing || + !A.bufferedRequest || + G(this, A)); + }), + (y.prototype.setDefaultEncoding = function (A) { + if ( + ("string" == typeof A && (A = A.toLowerCase()), + !( + [ + "hex", + "utf8", + "utf-8", + "ascii", + "binary", + "base64", + "ucs2", + "ucs-2", + "utf16le", + "utf-16le", + "raw", + ].indexOf((A + "").toLowerCase()) > -1 + )) + ) + throw new w(A); + return (this._writableState.defaultEncoding = A), this; + }), + Object.defineProperty(y.prototype, "writableBuffer", { + enumerable: !1, + get: function () { + return this._writableState && this._writableState.getBuffer(); + }, + }), + Object.defineProperty(y.prototype, "writableHighWaterMark", { + enumerable: !1, + get: function () { + return this._writableState.highWaterMark; + }, + }), + (y.prototype._write = function (A, e, t) { + t(new h("_write()")); + }), + (y.prototype._writev = null), + (y.prototype.end = function (A, e, i) { + var g = this._writableState; + return ( + "function" == typeof A + ? ((i = A), (A = null), (e = null)) + : "function" == typeof e && ((i = e), (e = null)), + null !== A && void 0 !== A && this.write(A, e), + g.corked && ((g.corked = 1), this.uncork()), + g.ending || + (function (A, e, i) { + (e.ending = !0), + N(A, e), + i && (e.finished ? t.nextTick(i) : A.once("finish", i)); + (e.ended = !0), (A.writable = !1); + })(this, g, i), + this + ); + }), + Object.defineProperty(y.prototype, "writableLength", { + enumerable: !1, + get: function () { + return this._writableState.length; + }, + }), + Object.defineProperty(y.prototype, "destroyed", { + enumerable: !1, + get: function () { + return ( + void 0 !== this._writableState && + this._writableState.destroyed + ); + }, + set: function (A) { + this._writableState && (this._writableState.destroyed = A); + }, + }), + (y.prototype.destroy = Q.destroy), + (y.prototype._undestroy = Q.undestroy), + (y.prototype._destroy = function (A, e) { + e(A); + }); + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { + "../errors": 48, + "./_stream_duplex": 49, + "./internal/streams/destroy": 56, + "./internal/streams/state": 60, + "./internal/streams/stream": 61, + _process: 154, + buffer: 64, + inherits: 134, + "util-deprecate": 193, + }, + ], + 54: [ + function (A, e, t) { + (function (t) { + "use strict"; + var i; + function g(A, e, t) { + return ( + e in A + ? Object.defineProperty(A, e, { + value: t, + enumerable: !0, + configurable: !0, + writable: !0, + }) + : (A[e] = t), + A + ); + } + var r = A("./end-of-stream"), + n = Symbol("lastResolve"), + B = Symbol("lastReject"), + I = Symbol("error"), + o = Symbol("ended"), + a = Symbol("lastPromise"), + Q = Symbol("handlePromise"), + C = Symbol("stream"); + function s(A, e) { + return { value: A, done: e }; + } + function c(A) { + var e = A[n]; + if (null !== e) { + var t = A[C].read(); + null !== t && + ((A[a] = null), (A[n] = null), (A[B] = null), e(s(t, !1))); + } + } + var h = Object.getPrototypeOf(function () {}), + f = Object.setPrototypeOf( + (g( + (i = { + get stream() { + return this[C]; + }, + next: function () { + var A = this, + e = this[I]; + if (null !== e) return Promise.reject(e); + if (this[o]) return Promise.resolve(s(void 0, !0)); + if (this[C].destroyed) + return new Promise(function (e, i) { + t.nextTick(function () { + A[I] ? i(A[I]) : e(s(void 0, !0)); + }); + }); + var i, + g = this[a]; + if (g) + i = new Promise( + (function (A, e) { + return function (t, i) { + A.then(function () { + e[o] ? t(s(void 0, !0)) : e[Q](t, i); + }, i); + }; + })(g, this) + ); + else { + var r = this[C].read(); + if (null !== r) return Promise.resolve(s(r, !1)); + i = new Promise(this[Q]); + } + return (this[a] = i), i; + }, + }), + Symbol.asyncIterator, + function () { + return this; + } + ), + g(i, "return", function () { + var A = this; + return new Promise(function (e, t) { + A[C].destroy(null, function (A) { + A ? t(A) : e(s(void 0, !0)); + }); + }); + }), + i), + h + ); + e.exports = function (A) { + var e, + i = Object.create( + f, + (g((e = {}), C, { value: A, writable: !0 }), + g(e, n, { value: null, writable: !0 }), + g(e, B, { value: null, writable: !0 }), + g(e, I, { value: null, writable: !0 }), + g(e, o, { value: A._readableState.endEmitted, writable: !0 }), + g(e, Q, { + value: function (A, e) { + var t = i[C].read(); + t + ? ((i[a] = null), + (i[n] = null), + (i[B] = null), + A(s(t, !1))) + : ((i[n] = A), (i[B] = e)); + }, + writable: !0, + }), + e) + ); + return ( + (i[a] = null), + r(A, function (A) { + if (A && "ERR_STREAM_PREMATURE_CLOSE" !== A.code) { + var e = i[B]; + return ( + null !== e && + ((i[a] = null), (i[n] = null), (i[B] = null), e(A)), + void (i[I] = A) + ); + } + var t = i[n]; + null !== t && + ((i[a] = null), + (i[n] = null), + (i[B] = null), + t(s(void 0, !0))), + (i[o] = !0); + }), + A.on( + "readable", + function (A) { + t.nextTick(c, A); + }.bind(null, i) + ), + i + ); + }; + }.call(this, A("_process"))); + }, + { "./end-of-stream": 57, _process: 154 }, + ], + 55: [ + function (A, e, t) { + "use strict"; + function i(A, e) { + var t = Object.keys(A); + if (Object.getOwnPropertySymbols) { + var i = Object.getOwnPropertySymbols(A); + e && + (i = i.filter(function (e) { + return Object.getOwnPropertyDescriptor(A, e).enumerable; + })), + t.push.apply(t, i); + } + return t; + } + function g(A, e, t) { + return ( + e in A + ? Object.defineProperty(A, e, { + value: t, + enumerable: !0, + configurable: !0, + writable: !0, + }) + : (A[e] = t), + A + ); + } + function r(A, e) { + for (var t = 0; t < e.length; t++) { + var i = e[t]; + (i.enumerable = i.enumerable || !1), + (i.configurable = !0), + "value" in i && (i.writable = !0), + Object.defineProperty(A, i.key, i); + } + } + var n = A("buffer").Buffer, + B = A("util").inspect, + I = (B && B.custom) || "inspect"; + e.exports = (function () { + function A() { + !(function (A, e) { + if (!(A instanceof e)) + throw new TypeError("Cannot call a class as a function"); + })(this, A), + (this.head = null), + (this.tail = null), + (this.length = 0); + } + var e, t, o; + return ( + (e = A), + (t = [ + { + key: "push", + value: function (A) { + var e = { data: A, next: null }; + this.length > 0 ? (this.tail.next = e) : (this.head = e), + (this.tail = e), + ++this.length; + }, + }, + { + key: "unshift", + value: function (A) { + var e = { data: A, next: this.head }; + 0 === this.length && (this.tail = e), + (this.head = e), + ++this.length; + }, + }, + { + key: "shift", + value: function () { + if (0 !== this.length) { + var A = this.head.data; + return ( + 1 === this.length + ? (this.head = this.tail = null) + : (this.head = this.head.next), + --this.length, + A + ); + } + }, + }, + { + key: "clear", + value: function () { + (this.head = this.tail = null), (this.length = 0); + }, + }, + { + key: "join", + value: function (A) { + if (0 === this.length) return ""; + for (var e = this.head, t = "" + e.data; (e = e.next); ) + t += A + e.data; + return t; + }, + }, + { + key: "concat", + value: function (A) { + if (0 === this.length) return n.alloc(0); + for ( + var e, + t, + i, + g = n.allocUnsafe(A >>> 0), + r = this.head, + B = 0; + r; + + ) + (e = r.data), + (t = g), + (i = B), + n.prototype.copy.call(e, t, i), + (B += r.data.length), + (r = r.next); + return g; + }, + }, + { + key: "consume", + value: function (A, e) { + var t; + return ( + A < this.head.data.length + ? ((t = this.head.data.slice(0, A)), + (this.head.data = this.head.data.slice(A))) + : (t = + A === this.head.data.length + ? this.shift() + : e + ? this._getString(A) + : this._getBuffer(A)), + t + ); + }, + }, + { + key: "first", + value: function () { + return this.head.data; + }, + }, + { + key: "_getString", + value: function (A) { + var e = this.head, + t = 1, + i = e.data; + for (A -= i.length; (e = e.next); ) { + var g = e.data, + r = A > g.length ? g.length : A; + if ( + (r === g.length ? (i += g) : (i += g.slice(0, A)), + 0 === (A -= r)) + ) { + r === g.length + ? (++t, + e.next + ? (this.head = e.next) + : (this.head = this.tail = null)) + : ((this.head = e), (e.data = g.slice(r))); + break; + } + ++t; + } + return (this.length -= t), i; + }, + }, + { + key: "_getBuffer", + value: function (A) { + var e = n.allocUnsafe(A), + t = this.head, + i = 1; + for (t.data.copy(e), A -= t.data.length; (t = t.next); ) { + var g = t.data, + r = A > g.length ? g.length : A; + if ((g.copy(e, e.length - A, 0, r), 0 === (A -= r))) { + r === g.length + ? (++i, + t.next + ? (this.head = t.next) + : (this.head = this.tail = null)) + : ((this.head = t), (t.data = g.slice(r))); + break; + } + ++i; + } + return (this.length -= i), e; + }, + }, + { + key: I, + value: function (A, e) { + return B( + this, + (function (A) { + for (var e = 1; e < arguments.length; e++) { + var t = null != arguments[e] ? arguments[e] : {}; + e % 2 + ? i(Object(t), !0).forEach(function (e) { + g(A, e, t[e]); + }) + : Object.getOwnPropertyDescriptors + ? Object.defineProperties( + A, + Object.getOwnPropertyDescriptors(t) + ) + : i(Object(t)).forEach(function (e) { + Object.defineProperty( + A, + e, + Object.getOwnPropertyDescriptor(t, e) + ); + }); + } + return A; + })({}, e, { depth: 0, customInspect: !1 }) + ); + }, + }, + ]) && r(e.prototype, t), + o && r(e, o), + A + ); + })(); + }, + { buffer: 64, util: 19 }, + ], + 56: [ + function (A, e, t) { + (function (A) { + "use strict"; + function t(A, e) { + g(A, e), i(A); + } + function i(A) { + (A._writableState && !A._writableState.emitClose) || + (A._readableState && !A._readableState.emitClose) || + A.emit("close"); + } + function g(A, e) { + A.emit("error", e); + } + e.exports = { + destroy: function (e, r) { + var n = this, + B = this._readableState && this._readableState.destroyed, + I = this._writableState && this._writableState.destroyed; + return B || I + ? (r + ? r(e) + : e && + (this._writableState + ? this._writableState.errorEmitted || + ((this._writableState.errorEmitted = !0), + A.nextTick(g, this, e)) + : A.nextTick(g, this, e)), + this) + : (this._readableState && (this._readableState.destroyed = !0), + this._writableState && (this._writableState.destroyed = !0), + this._destroy(e || null, function (e) { + !r && e + ? n._writableState + ? n._writableState.errorEmitted + ? A.nextTick(i, n) + : ((n._writableState.errorEmitted = !0), + A.nextTick(t, n, e)) + : A.nextTick(t, n, e) + : r + ? (A.nextTick(i, n), r(e)) + : A.nextTick(i, n); + }), + this); + }, + undestroy: function () { + this._readableState && + ((this._readableState.destroyed = !1), + (this._readableState.reading = !1), + (this._readableState.ended = !1), + (this._readableState.endEmitted = !1)), + this._writableState && + ((this._writableState.destroyed = !1), + (this._writableState.ended = !1), + (this._writableState.ending = !1), + (this._writableState.finalCalled = !1), + (this._writableState.prefinished = !1), + (this._writableState.finished = !1), + (this._writableState.errorEmitted = !1)); + }, + errorOrDestroy: function (A, e) { + var t = A._readableState, + i = A._writableState; + (t && t.autoDestroy) || (i && i.autoDestroy) + ? A.destroy(e) + : A.emit("error", e); + }, + }; + }.call(this, A("_process"))); + }, + { _process: 154 }, + ], + 57: [ + function (A, e, t) { + "use strict"; + var i = A("../../../errors").codes.ERR_STREAM_PREMATURE_CLOSE; + function g() {} + e.exports = function A(e, t, r) { + if ("function" == typeof t) return A(e, null, t); + t || (t = {}), + (r = (function (A) { + var e = !1; + return function () { + if (!e) { + e = !0; + for ( + var t = arguments.length, i = new Array(t), g = 0; + g < t; + g++ + ) + i[g] = arguments[g]; + A.apply(this, i); + } + }; + })(r || g)); + var n = t.readable || (!1 !== t.readable && e.readable), + B = t.writable || (!1 !== t.writable && e.writable), + I = function () { + e.writable || a(); + }, + o = e._writableState && e._writableState.finished, + a = function () { + (B = !1), (o = !0), n || r.call(e); + }, + Q = e._readableState && e._readableState.endEmitted, + C = function () { + (n = !1), (Q = !0), B || r.call(e); + }, + s = function (A) { + r.call(e, A); + }, + c = function () { + var A; + return n && !Q + ? ((e._readableState && e._readableState.ended) || + (A = new i()), + r.call(e, A)) + : B && !o + ? ((e._writableState && e._writableState.ended) || + (A = new i()), + r.call(e, A)) + : void 0; + }, + h = function () { + e.req.on("finish", a); + }; + return ( + (function (A) { + return A.setHeader && "function" == typeof A.abort; + })(e) + ? (e.on("complete", a), + e.on("abort", c), + e.req ? h() : e.on("request", h)) + : B && !e._writableState && (e.on("end", I), e.on("close", I)), + e.on("end", C), + e.on("finish", a), + !1 !== t.error && e.on("error", s), + e.on("close", c), + function () { + e.removeListener("complete", a), + e.removeListener("abort", c), + e.removeListener("request", h), + e.req && e.req.removeListener("finish", a), + e.removeListener("end", I), + e.removeListener("close", I), + e.removeListener("finish", a), + e.removeListener("end", C), + e.removeListener("error", s), + e.removeListener("close", c); + } + ); + }; + }, + { "../../../errors": 48 }, + ], + 58: [ + function (A, e, t) { + e.exports = function () { + throw new Error("Readable.from is not available in the browser"); + }; + }, + {}, + ], + 59: [ + function (A, e, t) { + "use strict"; + var i; + var g = A("../../../errors").codes, + r = g.ERR_MISSING_ARGS, + n = g.ERR_STREAM_DESTROYED; + function B(A) { + if (A) throw A; + } + function I(A) { + A(); + } + function o(A, e) { + return A.pipe(e); + } + e.exports = function () { + for (var e = arguments.length, t = new Array(e), g = 0; g < e; g++) + t[g] = arguments[g]; + var a, + Q = (function (A) { + return A.length + ? "function" != typeof A[A.length - 1] + ? B + : A.pop() + : B; + })(t); + if ((Array.isArray(t[0]) && (t = t[0]), t.length < 2)) + throw new r("streams"); + var C = t.map(function (e, g) { + var r = g < t.length - 1; + return (function (e, t, g, r) { + r = (function (A) { + var e = !1; + return function () { + e || ((e = !0), A.apply(void 0, arguments)); + }; + })(r); + var B = !1; + e.on("close", function () { + B = !0; + }), + void 0 === i && (i = A("./end-of-stream")), + i(e, { readable: t, writable: g }, function (A) { + if (A) return r(A); + (B = !0), r(); + }); + var I = !1; + return function (A) { + if (!B && !I) + return ( + (I = !0), + (function (A) { + return A.setHeader && "function" == typeof A.abort; + })(e) + ? e.abort() + : "function" == typeof e.destroy + ? e.destroy() + : void r(A || new n("pipe")) + ); + }; + })(e, r, g > 0, function (A) { + a || (a = A), A && C.forEach(I), r || (C.forEach(I), Q(a)); + }); + }); + return t.reduce(o); + }; + }, + { "../../../errors": 48, "./end-of-stream": 57 }, + ], + 60: [ + function (A, e, t) { + "use strict"; + var i = A("../../../errors").codes.ERR_INVALID_OPT_VALUE; + e.exports = { + getHighWaterMark: function (A, e, t, g) { + var r = (function (A, e, t) { + return null != A.highWaterMark + ? A.highWaterMark + : e + ? A[t] + : null; + })(e, g, t); + if (null != r) { + if (!isFinite(r) || Math.floor(r) !== r || r < 0) + throw new i(g ? t : "highWaterMark", r); + return Math.floor(r); + } + return A.objectMode ? 16 : 16384; + }, + }; + }, + { "../../../errors": 48 }, + ], + 61: [ + function (A, e, t) { + e.exports = A("events").EventEmitter; + }, + { events: 102 }, + ], + 62: [ + function (A, e, t) { + ((t = e.exports = A("./lib/_stream_readable.js")).Stream = t), + (t.Readable = t), + (t.Writable = A("./lib/_stream_writable.js")), + (t.Duplex = A("./lib/_stream_duplex.js")), + (t.Transform = A("./lib/_stream_transform.js")), + (t.PassThrough = A("./lib/_stream_passthrough.js")), + (t.finished = A("./lib/internal/streams/end-of-stream.js")), + (t.pipeline = A("./lib/internal/streams/pipeline.js")); + }, + { + "./lib/_stream_duplex.js": 49, + "./lib/_stream_passthrough.js": 50, + "./lib/_stream_readable.js": 51, + "./lib/_stream_transform.js": 52, + "./lib/_stream_writable.js": 53, + "./lib/internal/streams/end-of-stream.js": 57, + "./lib/internal/streams/pipeline.js": 59, + }, + ], + 63: [ + function (A, e, t) { + (function (A) { + e.exports = function (e, t) { + for ( + var i = Math.min(e.length, t.length), g = new A(i), r = 0; + r < i; + ++r + ) + g[r] = e[r] ^ t[r]; + return g; + }; + }.call(this, A("buffer").Buffer)); + }, + { buffer: 64 }, + ], + 64: [ + function (A, e, t) { + (function (e) { + "use strict"; + var i = A("base64-js"), + g = A("ieee754"); + (t.Buffer = e), + (t.SlowBuffer = function (A) { + +A != A && (A = 0); + return e.alloc(+A); + }), + (t.INSPECT_MAX_BYTES = 50); + var r = 2147483647; + function n(A) { + if (A > r) + throw new RangeError( + 'The value "' + A + '" is invalid for option "size"' + ); + var t = new Uint8Array(A); + return (t.__proto__ = e.prototype), t; + } + function e(A, e, t) { + if ("number" == typeof A) { + if ("string" == typeof e) + throw new TypeError( + 'The "string" argument must be of type string. Received type number' + ); + return o(A); + } + return B(A, e, t); + } + function B(A, t, i) { + if ("string" == typeof A) + return (function (A, t) { + ("string" == typeof t && "" !== t) || (t = "utf8"); + if (!e.isEncoding(t)) + throw new TypeError("Unknown encoding: " + t); + var i = 0 | C(A, t), + g = n(i), + r = g.write(A, t); + r !== i && (g = g.slice(0, r)); + return g; + })(A, t); + if (ArrayBuffer.isView(A)) return a(A); + if (null == A) + throw TypeError( + "The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type " + + typeof A + ); + if (R(A, ArrayBuffer) || (A && R(A.buffer, ArrayBuffer))) + return (function (A, t, i) { + if (t < 0 || A.byteLength < t) + throw new RangeError('"offset" is outside of buffer bounds'); + if (A.byteLength < t + (i || 0)) + throw new RangeError('"length" is outside of buffer bounds'); + var g; + g = + void 0 === t && void 0 === i + ? new Uint8Array(A) + : void 0 === i + ? new Uint8Array(A, t) + : new Uint8Array(A, t, i); + return (g.__proto__ = e.prototype), g; + })(A, t, i); + if ("number" == typeof A) + throw new TypeError( + 'The "value" argument must not be of type number. Received type number' + ); + var g = A.valueOf && A.valueOf(); + if (null != g && g !== A) return e.from(g, t, i); + var r = (function (A) { + if (e.isBuffer(A)) { + var t = 0 | Q(A.length), + i = n(t); + return 0 === i.length ? i : (A.copy(i, 0, 0, t), i); + } + if (void 0 !== A.length) + return "number" != typeof A.length || q(A.length) ? n(0) : a(A); + if ("Buffer" === A.type && Array.isArray(A.data)) + return a(A.data); + })(A); + if (r) return r; + if ( + "undefined" != typeof Symbol && + null != Symbol.toPrimitive && + "function" == typeof A[Symbol.toPrimitive] + ) + return e.from(A[Symbol.toPrimitive]("string"), t, i); + throw new TypeError( + "The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type " + + typeof A + ); + } + function I(A) { + if ("number" != typeof A) + throw new TypeError('"size" argument must be of type number'); + if (A < 0) + throw new RangeError( + 'The value "' + A + '" is invalid for option "size"' + ); + } + function o(A) { + return I(A), n(A < 0 ? 0 : 0 | Q(A)); + } + function a(A) { + for ( + var e = A.length < 0 ? 0 : 0 | Q(A.length), t = n(e), i = 0; + i < e; + i += 1 + ) + t[i] = 255 & A[i]; + return t; + } + function Q(A) { + if (A >= r) + throw new RangeError( + "Attempt to allocate Buffer larger than maximum size: 0x" + + r.toString(16) + + " bytes" + ); + return 0 | A; + } + function C(A, t) { + if (e.isBuffer(A)) return A.length; + if (ArrayBuffer.isView(A) || R(A, ArrayBuffer)) return A.byteLength; + if ("string" != typeof A) + throw new TypeError( + 'The "string" argument must be one of type string, Buffer, or ArrayBuffer. Received type ' + + typeof A + ); + var i = A.length, + g = arguments.length > 2 && !0 === arguments[2]; + if (!g && 0 === i) return 0; + for (var r = !1; ; ) + switch (t) { + case "ascii": + case "latin1": + case "binary": + return i; + case "utf8": + case "utf-8": + return U(A).length; + case "ucs2": + case "ucs-2": + case "utf16le": + case "utf-16le": + return 2 * i; + case "hex": + return i >>> 1; + case "base64": + return J(A).length; + default: + if (r) return g ? -1 : U(A).length; + (t = ("" + t).toLowerCase()), (r = !0); + } + } + function s(A, e, t) { + var i = A[e]; + (A[e] = A[t]), (A[t] = i); + } + function c(A, t, i, g, r) { + if (0 === A.length) return -1; + if ( + ("string" == typeof i + ? ((g = i), (i = 0)) + : i > 2147483647 + ? (i = 2147483647) + : i < -2147483648 && (i = -2147483648), + q((i = +i)) && (i = r ? 0 : A.length - 1), + i < 0 && (i = A.length + i), + i >= A.length) + ) { + if (r) return -1; + i = A.length - 1; + } else if (i < 0) { + if (!r) return -1; + i = 0; + } + if (("string" == typeof t && (t = e.from(t, g)), e.isBuffer(t))) + return 0 === t.length ? -1 : h(A, t, i, g, r); + if ("number" == typeof t) + return ( + (t &= 255), + "function" == typeof Uint8Array.prototype.indexOf + ? r + ? Uint8Array.prototype.indexOf.call(A, t, i) + : Uint8Array.prototype.lastIndexOf.call(A, t, i) + : h(A, [t], i, g, r) + ); + throw new TypeError("val must be string, number or Buffer"); + } + function h(A, e, t, i, g) { + var r, + n = 1, + B = A.length, + I = e.length; + if ( + void 0 !== i && + ("ucs2" === (i = String(i).toLowerCase()) || + "ucs-2" === i || + "utf16le" === i || + "utf-16le" === i) + ) { + if (A.length < 2 || e.length < 2) return -1; + (n = 2), (B /= 2), (I /= 2), (t /= 2); + } + function o(A, e) { + return 1 === n ? A[e] : A.readUInt16BE(e * n); + } + if (g) { + var a = -1; + for (r = t; r < B; r++) + if (o(A, r) === o(e, -1 === a ? 0 : r - a)) { + if ((-1 === a && (a = r), r - a + 1 === I)) return a * n; + } else -1 !== a && (r -= r - a), (a = -1); + } else + for (t + I > B && (t = B - I), r = t; r >= 0; r--) { + for (var Q = !0, C = 0; C < I; C++) + if (o(A, r + C) !== o(e, C)) { + Q = !1; + break; + } + if (Q) return r; + } + return -1; + } + function f(A, e, t, i) { + t = Number(t) || 0; + var g = A.length - t; + i ? (i = Number(i)) > g && (i = g) : (i = g); + var r = e.length; + i > r / 2 && (i = r / 2); + for (var n = 0; n < i; ++n) { + var B = parseInt(e.substr(2 * n, 2), 16); + if (q(B)) return n; + A[t + n] = B; + } + return n; + } + function E(A, e, t, i) { + return H(U(e, A.length - t), A, t, i); + } + function u(A, e, t, i) { + return H( + (function (A) { + for (var e = [], t = 0; t < A.length; ++t) + e.push(255 & A.charCodeAt(t)); + return e; + })(e), + A, + t, + i + ); + } + function d(A, e, t, i) { + return u(A, e, t, i); + } + function l(A, e, t, i) { + return H(J(e), A, t, i); + } + function w(A, e, t, i) { + return H( + (function (A, e) { + for ( + var t, i, g, r = [], n = 0; + n < A.length && !((e -= 2) < 0); + ++n + ) + (t = A.charCodeAt(n)), + (i = t >> 8), + (g = t % 256), + r.push(g), + r.push(i); + return r; + })(e, A.length - t), + A, + t, + i + ); + } + function p(A, e, t) { + return 0 === e && t === A.length + ? i.fromByteArray(A) + : i.fromByteArray(A.slice(e, t)); + } + function D(A, e, t) { + t = Math.min(A.length, t); + for (var i = [], g = e; g < t; ) { + var r, + n, + B, + I, + o = A[g], + a = null, + Q = o > 239 ? 4 : o > 223 ? 3 : o > 191 ? 2 : 1; + if (g + Q <= t) + switch (Q) { + case 1: + o < 128 && (a = o); + break; + case 2: + 128 == (192 & (r = A[g + 1])) && + (I = ((31 & o) << 6) | (63 & r)) > 127 && + (a = I); + break; + case 3: + (r = A[g + 1]), + (n = A[g + 2]), + 128 == (192 & r) && + 128 == (192 & n) && + (I = ((15 & o) << 12) | ((63 & r) << 6) | (63 & n)) > + 2047 && + (I < 55296 || I > 57343) && + (a = I); + break; + case 4: + (r = A[g + 1]), + (n = A[g + 2]), + (B = A[g + 3]), + 128 == (192 & r) && + 128 == (192 & n) && + 128 == (192 & B) && + (I = + ((15 & o) << 18) | + ((63 & r) << 12) | + ((63 & n) << 6) | + (63 & B)) > 65535 && + I < 1114112 && + (a = I); + } + null === a + ? ((a = 65533), (Q = 1)) + : a > 65535 && + ((a -= 65536), + i.push(((a >>> 10) & 1023) | 55296), + (a = 56320 | (1023 & a))), + i.push(a), + (g += Q); + } + return (function (A) { + var e = A.length; + if (e <= b) return String.fromCharCode.apply(String, A); + var t = "", + i = 0; + for (; i < e; ) + t += String.fromCharCode.apply(String, A.slice(i, (i += b))); + return t; + })(i); + } + (t.kMaxLength = r), + (e.TYPED_ARRAY_SUPPORT = (function () { + try { + var A = new Uint8Array(1); + return ( + (A.__proto__ = { + __proto__: Uint8Array.prototype, + foo: function () { + return 42; + }, + }), + 42 === A.foo() + ); + } catch (A) { + return !1; + } + })()), + e.TYPED_ARRAY_SUPPORT || + "undefined" == typeof console || + "function" != typeof console.error || + console.error( + "This browser lacks typed array (Uint8Array) support which is required by `buffer` v5.x. Use `buffer` v4.x if you require old browser support." + ), + Object.defineProperty(e.prototype, "parent", { + enumerable: !0, + get: function () { + if (e.isBuffer(this)) return this.buffer; + }, + }), + Object.defineProperty(e.prototype, "offset", { + enumerable: !0, + get: function () { + if (e.isBuffer(this)) return this.byteOffset; + }, + }), + "undefined" != typeof Symbol && + null != Symbol.species && + e[Symbol.species] === e && + Object.defineProperty(e, Symbol.species, { + value: null, + configurable: !0, + enumerable: !1, + writable: !1, + }), + (e.poolSize = 8192), + (e.from = function (A, e, t) { + return B(A, e, t); + }), + (e.prototype.__proto__ = Uint8Array.prototype), + (e.__proto__ = Uint8Array), + (e.alloc = function (A, e, t) { + return (function (A, e, t) { + return ( + I(A), + A <= 0 + ? n(A) + : void 0 !== e + ? "string" == typeof t + ? n(A).fill(e, t) + : n(A).fill(e) + : n(A) + ); + })(A, e, t); + }), + (e.allocUnsafe = function (A) { + return o(A); + }), + (e.allocUnsafeSlow = function (A) { + return o(A); + }), + (e.isBuffer = function (A) { + return null != A && !0 === A._isBuffer && A !== e.prototype; + }), + (e.compare = function (A, t) { + if ( + (R(A, Uint8Array) && (A = e.from(A, A.offset, A.byteLength)), + R(t, Uint8Array) && (t = e.from(t, t.offset, t.byteLength)), + !e.isBuffer(A) || !e.isBuffer(t)) + ) + throw new TypeError( + 'The "buf1", "buf2" arguments must be one of type Buffer or Uint8Array' + ); + if (A === t) return 0; + for ( + var i = A.length, g = t.length, r = 0, n = Math.min(i, g); + r < n; + ++r + ) + if (A[r] !== t[r]) { + (i = A[r]), (g = t[r]); + break; + } + return i < g ? -1 : g < i ? 1 : 0; + }), + (e.isEncoding = function (A) { + switch (String(A).toLowerCase()) { + case "hex": + case "utf8": + case "utf-8": + case "ascii": + case "latin1": + case "binary": + case "base64": + case "ucs2": + case "ucs-2": + case "utf16le": + case "utf-16le": + return !0; + default: + return !1; + } + }), + (e.concat = function (A, t) { + if (!Array.isArray(A)) + throw new TypeError( + '"list" argument must be an Array of Buffers' + ); + if (0 === A.length) return e.alloc(0); + var i; + if (void 0 === t) + for (t = 0, i = 0; i < A.length; ++i) t += A[i].length; + var g = e.allocUnsafe(t), + r = 0; + for (i = 0; i < A.length; ++i) { + var n = A[i]; + if ((R(n, Uint8Array) && (n = e.from(n)), !e.isBuffer(n))) + throw new TypeError( + '"list" argument must be an Array of Buffers' + ); + n.copy(g, r), (r += n.length); + } + return g; + }), + (e.byteLength = C), + (e.prototype._isBuffer = !0), + (e.prototype.swap16 = function () { + var A = this.length; + if (A % 2 != 0) + throw new RangeError( + "Buffer size must be a multiple of 16-bits" + ); + for (var e = 0; e < A; e += 2) s(this, e, e + 1); + return this; + }), + (e.prototype.swap32 = function () { + var A = this.length; + if (A % 4 != 0) + throw new RangeError( + "Buffer size must be a multiple of 32-bits" + ); + for (var e = 0; e < A; e += 4) + s(this, e, e + 3), s(this, e + 1, e + 2); + return this; + }), + (e.prototype.swap64 = function () { + var A = this.length; + if (A % 8 != 0) + throw new RangeError( + "Buffer size must be a multiple of 64-bits" + ); + for (var e = 0; e < A; e += 8) + s(this, e, e + 7), + s(this, e + 1, e + 6), + s(this, e + 2, e + 5), + s(this, e + 3, e + 4); + return this; + }), + (e.prototype.toString = function () { + var A = this.length; + return 0 === A + ? "" + : 0 === arguments.length + ? D(this, 0, A) + : function (A, e, t) { + var i = !1; + if (((void 0 === e || e < 0) && (e = 0), e > this.length)) + return ""; + if ( + ((void 0 === t || t > this.length) && (t = this.length), + t <= 0) + ) + return ""; + if ((t >>>= 0) <= (e >>>= 0)) return ""; + for (A || (A = "utf8"); ; ) + switch (A) { + case "hex": + return m(this, e, t); + case "utf8": + case "utf-8": + return D(this, e, t); + case "ascii": + return y(this, e, t); + case "latin1": + case "binary": + return M(this, e, t); + case "base64": + return p(this, e, t); + case "ucs2": + case "ucs-2": + case "utf16le": + case "utf-16le": + return G(this, e, t); + default: + if (i) throw new TypeError("Unknown encoding: " + A); + (A = (A + "").toLowerCase()), (i = !0); + } + }.apply(this, arguments); + }), + (e.prototype.toLocaleString = e.prototype.toString), + (e.prototype.equals = function (A) { + if (!e.isBuffer(A)) + throw new TypeError("Argument must be a Buffer"); + return this === A || 0 === e.compare(this, A); + }), + (e.prototype.inspect = function () { + var A = "", + e = t.INSPECT_MAX_BYTES; + return ( + (A = this.toString("hex", 0, e) + .replace(/(.{2})/g, "$1 ") + .trim()), + this.length > e && (A += " ... "), + "" + ); + }), + (e.prototype.compare = function (A, t, i, g, r) { + if ( + (R(A, Uint8Array) && (A = e.from(A, A.offset, A.byteLength)), + !e.isBuffer(A)) + ) + throw new TypeError( + 'The "target" argument must be one of type Buffer or Uint8Array. Received type ' + + typeof A + ); + if ( + (void 0 === t && (t = 0), + void 0 === i && (i = A ? A.length : 0), + void 0 === g && (g = 0), + void 0 === r && (r = this.length), + t < 0 || i > A.length || g < 0 || r > this.length) + ) + throw new RangeError("out of range index"); + if (g >= r && t >= i) return 0; + if (g >= r) return -1; + if (t >= i) return 1; + if (((t >>>= 0), (i >>>= 0), (g >>>= 0), (r >>>= 0), this === A)) + return 0; + for ( + var n = r - g, + B = i - t, + I = Math.min(n, B), + o = this.slice(g, r), + a = A.slice(t, i), + Q = 0; + Q < I; + ++Q + ) + if (o[Q] !== a[Q]) { + (n = o[Q]), (B = a[Q]); + break; + } + return n < B ? -1 : B < n ? 1 : 0; + }), + (e.prototype.includes = function (A, e, t) { + return -1 !== this.indexOf(A, e, t); + }), + (e.prototype.indexOf = function (A, e, t) { + return c(this, A, e, t, !0); + }), + (e.prototype.lastIndexOf = function (A, e, t) { + return c(this, A, e, t, !1); + }), + (e.prototype.write = function (A, e, t, i) { + if (void 0 === e) (i = "utf8"), (t = this.length), (e = 0); + else if (void 0 === t && "string" == typeof e) + (i = e), (t = this.length), (e = 0); + else { + if (!isFinite(e)) + throw new Error( + "Buffer.write(string, encoding, offset[, length]) is no longer supported" + ); + (e >>>= 0), + isFinite(t) + ? ((t >>>= 0), void 0 === i && (i = "utf8")) + : ((i = t), (t = void 0)); + } + var g = this.length - e; + if ( + ((void 0 === t || t > g) && (t = g), + (A.length > 0 && (t < 0 || e < 0)) || e > this.length) + ) + throw new RangeError("Attempt to write outside buffer bounds"); + i || (i = "utf8"); + for (var r = !1; ; ) + switch (i) { + case "hex": + return f(this, A, e, t); + case "utf8": + case "utf-8": + return E(this, A, e, t); + case "ascii": + return u(this, A, e, t); + case "latin1": + case "binary": + return d(this, A, e, t); + case "base64": + return l(this, A, e, t); + case "ucs2": + case "ucs-2": + case "utf16le": + case "utf-16le": + return w(this, A, e, t); + default: + if (r) throw new TypeError("Unknown encoding: " + i); + (i = ("" + i).toLowerCase()), (r = !0); + } + }), + (e.prototype.toJSON = function () { + return { + type: "Buffer", + data: Array.prototype.slice.call(this._arr || this, 0), + }; + }); + var b = 4096; + function y(A, e, t) { + var i = ""; + t = Math.min(A.length, t); + for (var g = e; g < t; ++g) i += String.fromCharCode(127 & A[g]); + return i; + } + function M(A, e, t) { + var i = ""; + t = Math.min(A.length, t); + for (var g = e; g < t; ++g) i += String.fromCharCode(A[g]); + return i; + } + function m(A, e, t) { + var i = A.length; + (!e || e < 0) && (e = 0), (!t || t < 0 || t > i) && (t = i); + for (var g = "", r = e; r < t; ++r) g += K(A[r]); + return g; + } + function G(A, e, t) { + for (var i = A.slice(e, t), g = "", r = 0; r < i.length; r += 2) + g += String.fromCharCode(i[r] + 256 * i[r + 1]); + return g; + } + function k(A, e, t) { + if (A % 1 != 0 || A < 0) throw new RangeError("offset is not uint"); + if (A + e > t) + throw new RangeError("Trying to access beyond buffer length"); + } + function F(A, t, i, g, r, n) { + if (!e.isBuffer(A)) + throw new TypeError( + '"buffer" argument must be a Buffer instance' + ); + if (t > r || t < n) + throw new RangeError('"value" argument is out of bounds'); + if (i + g > A.length) throw new RangeError("Index out of range"); + } + function N(A, e, t, i, g, r) { + if (t + i > A.length) throw new RangeError("Index out of range"); + if (t < 0) throw new RangeError("Index out of range"); + } + function S(A, e, t, i, r) { + return ( + (e = +e), + (t >>>= 0), + r || N(A, 0, t, 4), + g.write(A, e, t, i, 23, 4), + t + 4 + ); + } + function Y(A, e, t, i, r) { + return ( + (e = +e), + (t >>>= 0), + r || N(A, 0, t, 8), + g.write(A, e, t, i, 52, 8), + t + 8 + ); + } + (e.prototype.slice = function (A, t) { + var i = this.length; + (A = ~~A), + (t = void 0 === t ? i : ~~t), + A < 0 ? (A += i) < 0 && (A = 0) : A > i && (A = i), + t < 0 ? (t += i) < 0 && (t = 0) : t > i && (t = i), + t < A && (t = A); + var g = this.subarray(A, t); + return (g.__proto__ = e.prototype), g; + }), + (e.prototype.readUIntLE = function (A, e, t) { + (A >>>= 0), (e >>>= 0), t || k(A, e, this.length); + for (var i = this[A], g = 1, r = 0; ++r < e && (g *= 256); ) + i += this[A + r] * g; + return i; + }), + (e.prototype.readUIntBE = function (A, e, t) { + (A >>>= 0), (e >>>= 0), t || k(A, e, this.length); + for (var i = this[A + --e], g = 1; e > 0 && (g *= 256); ) + i += this[A + --e] * g; + return i; + }), + (e.prototype.readUInt8 = function (A, e) { + return (A >>>= 0), e || k(A, 1, this.length), this[A]; + }), + (e.prototype.readUInt16LE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 2, this.length), + this[A] | (this[A + 1] << 8) + ); + }), + (e.prototype.readUInt16BE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 2, this.length), + (this[A] << 8) | this[A + 1] + ); + }), + (e.prototype.readUInt32LE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 4, this.length), + (this[A] | (this[A + 1] << 8) | (this[A + 2] << 16)) + + 16777216 * this[A + 3] + ); + }), + (e.prototype.readUInt32BE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 4, this.length), + 16777216 * this[A] + + ((this[A + 1] << 16) | (this[A + 2] << 8) | this[A + 3]) + ); + }), + (e.prototype.readIntLE = function (A, e, t) { + (A >>>= 0), (e >>>= 0), t || k(A, e, this.length); + for (var i = this[A], g = 1, r = 0; ++r < e && (g *= 256); ) + i += this[A + r] * g; + return i >= (g *= 128) && (i -= Math.pow(2, 8 * e)), i; + }), + (e.prototype.readIntBE = function (A, e, t) { + (A >>>= 0), (e >>>= 0), t || k(A, e, this.length); + for (var i = e, g = 1, r = this[A + --i]; i > 0 && (g *= 256); ) + r += this[A + --i] * g; + return r >= (g *= 128) && (r -= Math.pow(2, 8 * e)), r; + }), + (e.prototype.readInt8 = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 1, this.length), + 128 & this[A] ? -1 * (255 - this[A] + 1) : this[A] + ); + }), + (e.prototype.readInt16LE = function (A, e) { + (A >>>= 0), e || k(A, 2, this.length); + var t = this[A] | (this[A + 1] << 8); + return 32768 & t ? 4294901760 | t : t; + }), + (e.prototype.readInt16BE = function (A, e) { + (A >>>= 0), e || k(A, 2, this.length); + var t = this[A + 1] | (this[A] << 8); + return 32768 & t ? 4294901760 | t : t; + }), + (e.prototype.readInt32LE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 4, this.length), + this[A] | + (this[A + 1] << 8) | + (this[A + 2] << 16) | + (this[A + 3] << 24) + ); + }), + (e.prototype.readInt32BE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 4, this.length), + (this[A] << 24) | + (this[A + 1] << 16) | + (this[A + 2] << 8) | + this[A + 3] + ); + }), + (e.prototype.readFloatLE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 4, this.length), + g.read(this, A, !0, 23, 4) + ); + }), + (e.prototype.readFloatBE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 4, this.length), + g.read(this, A, !1, 23, 4) + ); + }), + (e.prototype.readDoubleLE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 8, this.length), + g.read(this, A, !0, 52, 8) + ); + }), + (e.prototype.readDoubleBE = function (A, e) { + return ( + (A >>>= 0), + e || k(A, 8, this.length), + g.read(this, A, !1, 52, 8) + ); + }), + (e.prototype.writeUIntLE = function (A, e, t, i) { + ((A = +A), (e >>>= 0), (t >>>= 0), i) || + F(this, A, e, t, Math.pow(2, 8 * t) - 1, 0); + var g = 1, + r = 0; + for (this[e] = 255 & A; ++r < t && (g *= 256); ) + this[e + r] = (A / g) & 255; + return e + t; + }), + (e.prototype.writeUIntBE = function (A, e, t, i) { + ((A = +A), (e >>>= 0), (t >>>= 0), i) || + F(this, A, e, t, Math.pow(2, 8 * t) - 1, 0); + var g = t - 1, + r = 1; + for (this[e + g] = 255 & A; --g >= 0 && (r *= 256); ) + this[e + g] = (A / r) & 255; + return e + t; + }), + (e.prototype.writeUInt8 = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 1, 255, 0), + (this[e] = 255 & A), + e + 1 + ); + }), + (e.prototype.writeUInt16LE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 2, 65535, 0), + (this[e] = 255 & A), + (this[e + 1] = A >>> 8), + e + 2 + ); + }), + (e.prototype.writeUInt16BE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 2, 65535, 0), + (this[e] = A >>> 8), + (this[e + 1] = 255 & A), + e + 2 + ); + }), + (e.prototype.writeUInt32LE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 4, 4294967295, 0), + (this[e + 3] = A >>> 24), + (this[e + 2] = A >>> 16), + (this[e + 1] = A >>> 8), + (this[e] = 255 & A), + e + 4 + ); + }), + (e.prototype.writeUInt32BE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 4, 4294967295, 0), + (this[e] = A >>> 24), + (this[e + 1] = A >>> 16), + (this[e + 2] = A >>> 8), + (this[e + 3] = 255 & A), + e + 4 + ); + }), + (e.prototype.writeIntLE = function (A, e, t, i) { + if (((A = +A), (e >>>= 0), !i)) { + var g = Math.pow(2, 8 * t - 1); + F(this, A, e, t, g - 1, -g); + } + var r = 0, + n = 1, + B = 0; + for (this[e] = 255 & A; ++r < t && (n *= 256); ) + A < 0 && 0 === B && 0 !== this[e + r - 1] && (B = 1), + (this[e + r] = (((A / n) >> 0) - B) & 255); + return e + t; + }), + (e.prototype.writeIntBE = function (A, e, t, i) { + if (((A = +A), (e >>>= 0), !i)) { + var g = Math.pow(2, 8 * t - 1); + F(this, A, e, t, g - 1, -g); + } + var r = t - 1, + n = 1, + B = 0; + for (this[e + r] = 255 & A; --r >= 0 && (n *= 256); ) + A < 0 && 0 === B && 0 !== this[e + r + 1] && (B = 1), + (this[e + r] = (((A / n) >> 0) - B) & 255); + return e + t; + }), + (e.prototype.writeInt8 = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 1, 127, -128), + A < 0 && (A = 255 + A + 1), + (this[e] = 255 & A), + e + 1 + ); + }), + (e.prototype.writeInt16LE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 2, 32767, -32768), + (this[e] = 255 & A), + (this[e + 1] = A >>> 8), + e + 2 + ); + }), + (e.prototype.writeInt16BE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 2, 32767, -32768), + (this[e] = A >>> 8), + (this[e + 1] = 255 & A), + e + 2 + ); + }), + (e.prototype.writeInt32LE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 4, 2147483647, -2147483648), + (this[e] = 255 & A), + (this[e + 1] = A >>> 8), + (this[e + 2] = A >>> 16), + (this[e + 3] = A >>> 24), + e + 4 + ); + }), + (e.prototype.writeInt32BE = function (A, e, t) { + return ( + (A = +A), + (e >>>= 0), + t || F(this, A, e, 4, 2147483647, -2147483648), + A < 0 && (A = 4294967295 + A + 1), + (this[e] = A >>> 24), + (this[e + 1] = A >>> 16), + (this[e + 2] = A >>> 8), + (this[e + 3] = 255 & A), + e + 4 + ); + }), + (e.prototype.writeFloatLE = function (A, e, t) { + return S(this, A, e, !0, t); + }), + (e.prototype.writeFloatBE = function (A, e, t) { + return S(this, A, e, !1, t); + }), + (e.prototype.writeDoubleLE = function (A, e, t) { + return Y(this, A, e, !0, t); + }), + (e.prototype.writeDoubleBE = function (A, e, t) { + return Y(this, A, e, !1, t); + }), + (e.prototype.copy = function (A, t, i, g) { + if (!e.isBuffer(A)) + throw new TypeError("argument should be a Buffer"); + if ( + (i || (i = 0), + g || 0 === g || (g = this.length), + t >= A.length && (t = A.length), + t || (t = 0), + g > 0 && g < i && (g = i), + g === i) + ) + return 0; + if (0 === A.length || 0 === this.length) return 0; + if (t < 0) throw new RangeError("targetStart out of bounds"); + if (i < 0 || i >= this.length) + throw new RangeError("Index out of range"); + if (g < 0) throw new RangeError("sourceEnd out of bounds"); + g > this.length && (g = this.length), + A.length - t < g - i && (g = A.length - t + i); + var r = g - i; + if ( + this === A && + "function" == typeof Uint8Array.prototype.copyWithin + ) + this.copyWithin(t, i, g); + else if (this === A && i < t && t < g) + for (var n = r - 1; n >= 0; --n) A[n + t] = this[n + i]; + else Uint8Array.prototype.set.call(A, this.subarray(i, g), t); + return r; + }), + (e.prototype.fill = function (A, t, i, g) { + if ("string" == typeof A) { + if ( + ("string" == typeof t + ? ((g = t), (t = 0), (i = this.length)) + : "string" == typeof i && ((g = i), (i = this.length)), + void 0 !== g && "string" != typeof g) + ) + throw new TypeError("encoding must be a string"); + if ("string" == typeof g && !e.isEncoding(g)) + throw new TypeError("Unknown encoding: " + g); + if (1 === A.length) { + var r = A.charCodeAt(0); + (("utf8" === g && r < 128) || "latin1" === g) && (A = r); + } + } else "number" == typeof A && (A &= 255); + if (t < 0 || this.length < t || this.length < i) + throw new RangeError("Out of range index"); + if (i <= t) return this; + var n; + if ( + ((t >>>= 0), + (i = void 0 === i ? this.length : i >>> 0), + A || (A = 0), + "number" == typeof A) + ) + for (n = t; n < i; ++n) this[n] = A; + else { + var B = e.isBuffer(A) ? A : e.from(A, g), + I = B.length; + if (0 === I) + throw new TypeError( + 'The value "' + A + '" is invalid for argument "value"' + ); + for (n = 0; n < i - t; ++n) this[n + t] = B[n % I]; + } + return this; + }); + var v = /[^+/0-9A-Za-z-_]/g; + function K(A) { + return A < 16 ? "0" + A.toString(16) : A.toString(16); + } + function U(A, e) { + var t; + e = e || 1 / 0; + for (var i = A.length, g = null, r = [], n = 0; n < i; ++n) { + if ((t = A.charCodeAt(n)) > 55295 && t < 57344) { + if (!g) { + if (t > 56319) { + (e -= 3) > -1 && r.push(239, 191, 189); + continue; + } + if (n + 1 === i) { + (e -= 3) > -1 && r.push(239, 191, 189); + continue; + } + g = t; + continue; + } + if (t < 56320) { + (e -= 3) > -1 && r.push(239, 191, 189), (g = t); + continue; + } + t = 65536 + (((g - 55296) << 10) | (t - 56320)); + } else g && (e -= 3) > -1 && r.push(239, 191, 189); + if (((g = null), t < 128)) { + if ((e -= 1) < 0) break; + r.push(t); + } else if (t < 2048) { + if ((e -= 2) < 0) break; + r.push((t >> 6) | 192, (63 & t) | 128); + } else if (t < 65536) { + if ((e -= 3) < 0) break; + r.push((t >> 12) | 224, ((t >> 6) & 63) | 128, (63 & t) | 128); + } else { + if (!(t < 1114112)) throw new Error("Invalid code point"); + if ((e -= 4) < 0) break; + r.push( + (t >> 18) | 240, + ((t >> 12) & 63) | 128, + ((t >> 6) & 63) | 128, + (63 & t) | 128 + ); + } + } + return r; + } + function J(A) { + return i.toByteArray( + (function (A) { + if ( + (A = (A = A.split("=")[0]).trim().replace(v, "")).length < 2 + ) + return ""; + for (; A.length % 4 != 0; ) A += "="; + return A; + })(A) + ); + } + function H(A, e, t, i) { + for (var g = 0; g < i && !(g + t >= e.length || g >= A.length); ++g) + e[g + t] = A[g]; + return g; + } + function R(A, e) { + return ( + A instanceof e || + (null != A && + null != A.constructor && + null != A.constructor.name && + A.constructor.name === e.name) + ); + } + function q(A) { + return A != A; + } + }.call(this, A("buffer").Buffer)); + }, + { "base64-js": 16, buffer: 64, ieee754: 133 }, + ], + 65: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer, + g = A("stream").Transform, + r = A("string_decoder").StringDecoder; + function n(A) { + g.call(this), + (this.hashMode = "string" == typeof A), + this.hashMode + ? (this[A] = this._finalOrDigest) + : (this.final = this._finalOrDigest), + this._final && ((this.__final = this._final), (this._final = null)), + (this._decoder = null), + (this._encoding = null); + } + A("inherits")(n, g), + (n.prototype.update = function (A, e, t) { + "string" == typeof A && (A = i.from(A, e)); + var g = this._update(A); + return this.hashMode ? this : (t && (g = this._toString(g, t)), g); + }), + (n.prototype.setAutoPadding = function () {}), + (n.prototype.getAuthTag = function () { + throw new Error("trying to get auth tag in unsupported state"); + }), + (n.prototype.setAuthTag = function () { + throw new Error("trying to set auth tag in unsupported state"); + }), + (n.prototype.setAAD = function () { + throw new Error("trying to set aad in unsupported state"); + }), + (n.prototype._transform = function (A, e, t) { + var i; + try { + this.hashMode ? this._update(A) : this.push(this._update(A)); + } catch (A) { + i = A; + } finally { + t(i); + } + }), + (n.prototype._flush = function (A) { + var e; + try { + this.push(this.__final()); + } catch (A) { + e = A; + } + A(e); + }), + (n.prototype._finalOrDigest = function (A) { + var e = this.__final() || i.alloc(0); + return A && (e = this._toString(e, A, !0)), e; + }), + (n.prototype._toString = function (A, e, t) { + if ( + (this._decoder || + ((this._decoder = new r(e)), (this._encoding = e)), + this._encoding !== e) + ) + throw new Error("can't switch encodings"); + var i = this._decoder.write(A); + return t && (i += this._decoder.end()), i; + }), + (e.exports = n); + }, + { inherits: 134, "safe-buffer": 180, stream: 190, string_decoder: 191 }, + ], + 66: [ + function (A, e, t) { + (function (A) { + function e(A) { + return Object.prototype.toString.call(A); + } + (t.isArray = function (A) { + return Array.isArray ? Array.isArray(A) : "[object Array]" === e(A); + }), + (t.isBoolean = function (A) { + return "boolean" == typeof A; + }), + (t.isNull = function (A) { + return null === A; + }), + (t.isNullOrUndefined = function (A) { + return null == A; + }), + (t.isNumber = function (A) { + return "number" == typeof A; + }), + (t.isString = function (A) { + return "string" == typeof A; + }), + (t.isSymbol = function (A) { + return "symbol" == typeof A; + }), + (t.isUndefined = function (A) { + return void 0 === A; + }), + (t.isRegExp = function (A) { + return "[object RegExp]" === e(A); + }), + (t.isObject = function (A) { + return "object" == typeof A && null !== A; + }), + (t.isDate = function (A) { + return "[object Date]" === e(A); + }), + (t.isError = function (A) { + return "[object Error]" === e(A) || A instanceof Error; + }), + (t.isFunction = function (A) { + return "function" == typeof A; + }), + (t.isPrimitive = function (A) { + return ( + null === A || + "boolean" == typeof A || + "number" == typeof A || + "string" == typeof A || + "symbol" == typeof A || + void 0 === A + ); + }), + (t.isBuffer = A.isBuffer); + }.call(this, { isBuffer: A("../../is-buffer/index.js") })); + }, + { "../../is-buffer/index.js": 135 }, + ], + 67: [ + function (A, e, t) { + (function (t) { + var i = A("elliptic"), + g = A("bn.js"); + e.exports = function (A) { + return new n(A); + }; + var r = { + secp256k1: { name: "secp256k1", byteLength: 32 }, + secp224r1: { name: "p224", byteLength: 28 }, + prime256v1: { name: "p256", byteLength: 32 }, + prime192v1: { name: "p192", byteLength: 24 }, + ed25519: { name: "ed25519", byteLength: 32 }, + secp384r1: { name: "p384", byteLength: 48 }, + secp521r1: { name: "p521", byteLength: 66 }, + }; + function n(A) { + (this.curveType = r[A]), + this.curveType || (this.curveType = { name: A }), + (this.curve = new i.ec(this.curveType.name)), + (this.keys = void 0); + } + function B(A, e, i) { + Array.isArray(A) || (A = A.toArray()); + var g = new t(A); + if (i && g.length < i) { + var r = new t(i - g.length); + r.fill(0), (g = t.concat([r, g])); + } + return e ? g.toString(e) : g; + } + (r.p224 = r.secp224r1), + (r.p256 = r.secp256r1 = r.prime256v1), + (r.p192 = r.secp192r1 = r.prime192v1), + (r.p384 = r.secp384r1), + (r.p521 = r.secp521r1), + (n.prototype.generateKeys = function (A, e) { + return ( + (this.keys = this.curve.genKeyPair()), this.getPublicKey(A, e) + ); + }), + (n.prototype.computeSecret = function (A, e, i) { + return ( + (e = e || "utf8"), + t.isBuffer(A) || (A = new t(A, e)), + B( + this.curve + .keyFromPublic(A) + .getPublic() + .mul(this.keys.getPrivate()) + .getX(), + i, + this.curveType.byteLength + ) + ); + }), + (n.prototype.getPublicKey = function (A, e) { + var t = this.keys.getPublic("compressed" === e, !0); + return ( + "hybrid" === e && + (t[t.length - 1] % 2 ? (t[0] = 7) : (t[0] = 6)), + B(t, A) + ); + }), + (n.prototype.getPrivateKey = function (A) { + return B(this.keys.getPrivate(), A); + }), + (n.prototype.setPublicKey = function (A, e) { + return ( + (e = e || "utf8"), + t.isBuffer(A) || (A = new t(A, e)), + this.keys._importPublic(A), + this + ); + }), + (n.prototype.setPrivateKey = function (A, e) { + (e = e || "utf8"), t.isBuffer(A) || (A = new t(A, e)); + var i = new g(A); + return ( + (i = i.toString(16)), + (this.keys = this.curve.genKeyPair()), + this.keys._importPrivate(i), + this + ); + }); + }.call(this, A("buffer").Buffer)); + }, + { "bn.js": 68, buffer: 64, elliptic: 85 }, + ], + 68: [ + function (A, e, t) { + arguments[4][15][0].apply(t, arguments); + }, + { buffer: 19, dup: 15 }, + ], + 69: [ + function (A, e, t) { + "use strict"; + var i = A("inherits"), + g = A("md5.js"), + r = A("ripemd160"), + n = A("sha.js"), + B = A("cipher-base"); + function I(A) { + B.call(this, "digest"), (this._hash = A); + } + i(I, B), + (I.prototype._update = function (A) { + this._hash.update(A); + }), + (I.prototype._final = function () { + return this._hash.digest(); + }), + (e.exports = function (A) { + return "md5" === (A = A.toLowerCase()) + ? new g() + : "rmd160" === A || "ripemd160" === A + ? new r() + : new I(n(A)); + }); + }, + { + "cipher-base": 65, + inherits: 134, + "md5.js": 137, + ripemd160: 179, + "sha.js": 183, + }, + ], + 70: [ + function (A, e, t) { + var i = A("md5.js"); + e.exports = function (A) { + return new i().update(A).digest(); + }; + }, + { "md5.js": 137 }, + ], + 71: [ + function (A, e, t) { + "use strict"; + var i = A("inherits"), + g = A("./legacy"), + r = A("cipher-base"), + n = A("safe-buffer").Buffer, + B = A("create-hash/md5"), + I = A("ripemd160"), + o = A("sha.js"), + a = n.alloc(128); + function Q(A, e) { + r.call(this, "digest"), "string" == typeof e && (e = n.from(e)); + var t = "sha512" === A || "sha384" === A ? 128 : 64; + ((this._alg = A), (this._key = e), e.length > t) + ? (e = ("rmd160" === A ? new I() : o(A)).update(e).digest()) + : e.length < t && (e = n.concat([e, a], t)); + for ( + var i = (this._ipad = n.allocUnsafe(t)), + g = (this._opad = n.allocUnsafe(t)), + B = 0; + B < t; + B++ + ) + (i[B] = 54 ^ e[B]), (g[B] = 92 ^ e[B]); + (this._hash = "rmd160" === A ? new I() : o(A)), this._hash.update(i); + } + i(Q, r), + (Q.prototype._update = function (A) { + this._hash.update(A); + }), + (Q.prototype._final = function () { + var A = this._hash.digest(); + return ("rmd160" === this._alg ? new I() : o(this._alg)) + .update(this._opad) + .update(A) + .digest(); + }), + (e.exports = function (A, e) { + return "rmd160" === (A = A.toLowerCase()) || "ripemd160" === A + ? new Q("rmd160", e) + : "md5" === A + ? new g(B, e) + : new Q(A, e); + }); + }, + { + "./legacy": 72, + "cipher-base": 65, + "create-hash/md5": 70, + inherits: 134, + ripemd160: 179, + "safe-buffer": 180, + "sha.js": 183, + }, + ], + 72: [ + function (A, e, t) { + "use strict"; + var i = A("inherits"), + g = A("safe-buffer").Buffer, + r = A("cipher-base"), + n = g.alloc(128), + B = 64; + function I(A, e) { + r.call(this, "digest"), + "string" == typeof e && (e = g.from(e)), + (this._alg = A), + (this._key = e), + e.length > B + ? (e = A(e)) + : e.length < B && (e = g.concat([e, n], B)); + for ( + var t = (this._ipad = g.allocUnsafe(B)), + i = (this._opad = g.allocUnsafe(B)), + I = 0; + I < B; + I++ + ) + (t[I] = 54 ^ e[I]), (i[I] = 92 ^ e[I]); + this._hash = [t]; + } + i(I, r), + (I.prototype._update = function (A) { + this._hash.push(A); + }), + (I.prototype._final = function () { + var A = this._alg(g.concat(this._hash)); + return this._alg(g.concat([this._opad, A])); + }), + (e.exports = I); + }, + { "cipher-base": 65, inherits: 134, "safe-buffer": 180 }, + ], + 73: [ + function (A, e, t) { + "use strict"; + (t.randomBytes = + t.rng = + t.pseudoRandomBytes = + t.prng = + A("randombytes")), + (t.createHash = t.Hash = A("create-hash")), + (t.createHmac = t.Hmac = A("create-hmac")); + var i = A("browserify-sign/algos"), + g = Object.keys(i), + r = [ + "sha1", + "sha224", + "sha256", + "sha384", + "sha512", + "md5", + "rmd160", + ].concat(g); + t.getHashes = function () { + return r; + }; + var n = A("pbkdf2"); + (t.pbkdf2 = n.pbkdf2), (t.pbkdf2Sync = n.pbkdf2Sync); + var B = A("browserify-cipher"); + (t.Cipher = B.Cipher), + (t.createCipher = B.createCipher), + (t.Cipheriv = B.Cipheriv), + (t.createCipheriv = B.createCipheriv), + (t.Decipher = B.Decipher), + (t.createDecipher = B.createDecipher), + (t.Decipheriv = B.Decipheriv), + (t.createDecipheriv = B.createDecipheriv), + (t.getCiphers = B.getCiphers), + (t.listCiphers = B.listCiphers); + var I = A("diffie-hellman"); + (t.DiffieHellmanGroup = I.DiffieHellmanGroup), + (t.createDiffieHellmanGroup = I.createDiffieHellmanGroup), + (t.getDiffieHellman = I.getDiffieHellman), + (t.createDiffieHellman = I.createDiffieHellman), + (t.DiffieHellman = I.DiffieHellman); + var o = A("browserify-sign"); + (t.createSign = o.createSign), + (t.Sign = o.Sign), + (t.createVerify = o.createVerify), + (t.Verify = o.Verify), + (t.createECDH = A("create-ecdh")); + var a = A("public-encrypt"); + (t.publicEncrypt = a.publicEncrypt), + (t.privateEncrypt = a.privateEncrypt), + (t.publicDecrypt = a.publicDecrypt), + (t.privateDecrypt = a.privateDecrypt); + var Q = A("randomfill"); + (t.randomFill = Q.randomFill), + (t.randomFillSync = Q.randomFillSync), + (t.createCredentials = function () { + throw new Error( + [ + "sorry, createCredentials is not implemented yet", + "we accept pull requests", + "https://github.com/crypto-browserify/crypto-browserify", + ].join("\n") + ); + }), + (t.constants = { + DH_CHECK_P_NOT_SAFE_PRIME: 2, + DH_CHECK_P_NOT_PRIME: 1, + DH_UNABLE_TO_CHECK_GENERATOR: 4, + DH_NOT_SUITABLE_GENERATOR: 8, + NPN_ENABLED: 1, + ALPN_ENABLED: 1, + RSA_PKCS1_PADDING: 1, + RSA_SSLV23_PADDING: 2, + RSA_NO_PADDING: 3, + RSA_PKCS1_OAEP_PADDING: 4, + RSA_X931_PADDING: 5, + RSA_PKCS1_PSS_PADDING: 6, + POINT_CONVERSION_COMPRESSED: 2, + POINT_CONVERSION_UNCOMPRESSED: 4, + POINT_CONVERSION_HYBRID: 6, + }); + }, + { + "browserify-cipher": 37, + "browserify-sign": 45, + "browserify-sign/algos": 42, + "create-ecdh": 67, + "create-hash": 69, + "create-hmac": 71, + "diffie-hellman": 80, + pbkdf2: 147, + "public-encrypt": 155, + randombytes: 162, + randomfill: 163, + }, + ], + 74: [ + function (A, e, t) { + "use strict"; + (t.utils = A("./des/utils")), + (t.Cipher = A("./des/cipher")), + (t.DES = A("./des/des")), + (t.CBC = A("./des/cbc")), + (t.EDE = A("./des/ede")); + }, + { + "./des/cbc": 75, + "./des/cipher": 76, + "./des/des": 77, + "./des/ede": 78, + "./des/utils": 79, + }, + ], + 75: [ + function (A, e, t) { + "use strict"; + var i = A("minimalistic-assert"), + g = A("inherits"), + r = {}; + (t.instantiate = function (A) { + function e(e) { + A.call(this, e), this._cbcInit(); + } + g(e, A); + for (var t = Object.keys(r), i = 0; i < t.length; i++) { + var n = t[i]; + e.prototype[n] = r[n]; + } + return ( + (e.create = function (A) { + return new e(A); + }), + e + ); + }), + (r._cbcInit = function () { + var A = new (function (A) { + i.equal(A.length, 8, "Invalid IV length"), + (this.iv = new Array(8)); + for (var e = 0; e < this.iv.length; e++) this.iv[e] = A[e]; + })(this.options.iv); + this._cbcState = A; + }), + (r._update = function (A, e, t, i) { + var g = this._cbcState, + r = this.constructor.super_.prototype, + n = g.iv; + if ("encrypt" === this.type) { + for (var B = 0; B < this.blockSize; B++) n[B] ^= A[e + B]; + r._update.call(this, n, 0, t, i); + for (B = 0; B < this.blockSize; B++) n[B] = t[i + B]; + } else { + r._update.call(this, A, e, t, i); + for (B = 0; B < this.blockSize; B++) t[i + B] ^= n[B]; + for (B = 0; B < this.blockSize; B++) n[B] = A[e + B]; + } + }); + }, + { inherits: 134, "minimalistic-assert": 140 }, + ], + 76: [ + function (A, e, t) { + "use strict"; + var i = A("minimalistic-assert"); + function g(A) { + (this.options = A), + (this.type = this.options.type), + (this.blockSize = 8), + this._init(), + (this.buffer = new Array(this.blockSize)), + (this.bufferOff = 0); + } + (e.exports = g), + (g.prototype._init = function () {}), + (g.prototype.update = function (A) { + return 0 === A.length + ? [] + : "decrypt" === this.type + ? this._updateDecrypt(A) + : this._updateEncrypt(A); + }), + (g.prototype._buffer = function (A, e) { + for ( + var t = Math.min( + this.buffer.length - this.bufferOff, + A.length - e + ), + i = 0; + i < t; + i++ + ) + this.buffer[this.bufferOff + i] = A[e + i]; + return (this.bufferOff += t), t; + }), + (g.prototype._flushBuffer = function (A, e) { + return ( + this._update(this.buffer, 0, A, e), + (this.bufferOff = 0), + this.blockSize + ); + }), + (g.prototype._updateEncrypt = function (A) { + var e = 0, + t = 0, + i = ((this.bufferOff + A.length) / this.blockSize) | 0, + g = new Array(i * this.blockSize); + 0 !== this.bufferOff && + ((e += this._buffer(A, e)), + this.bufferOff === this.buffer.length && + (t += this._flushBuffer(g, t))); + for ( + var r = A.length - ((A.length - e) % this.blockSize); + e < r; + e += this.blockSize + ) + this._update(A, e, g, t), (t += this.blockSize); + for (; e < A.length; e++, this.bufferOff++) + this.buffer[this.bufferOff] = A[e]; + return g; + }), + (g.prototype._updateDecrypt = function (A) { + for ( + var e = 0, + t = 0, + i = Math.ceil((this.bufferOff + A.length) / this.blockSize) - 1, + g = new Array(i * this.blockSize); + i > 0; + i-- + ) + (e += this._buffer(A, e)), (t += this._flushBuffer(g, t)); + return (e += this._buffer(A, e)), g; + }), + (g.prototype.final = function (A) { + var e, t; + return ( + A && (e = this.update(A)), + (t = + "encrypt" === this.type + ? this._finalEncrypt() + : this._finalDecrypt()), + e ? e.concat(t) : t + ); + }), + (g.prototype._pad = function (A, e) { + if (0 === e) return !1; + for (; e < A.length; ) A[e++] = 0; + return !0; + }), + (g.prototype._finalEncrypt = function () { + if (!this._pad(this.buffer, this.bufferOff)) return []; + var A = new Array(this.blockSize); + return this._update(this.buffer, 0, A, 0), A; + }), + (g.prototype._unpad = function (A) { + return A; + }), + (g.prototype._finalDecrypt = function () { + i.equal( + this.bufferOff, + this.blockSize, + "Not enough data to decrypt" + ); + var A = new Array(this.blockSize); + return this._flushBuffer(A, 0), this._unpad(A); + }); + }, + { "minimalistic-assert": 140 }, + ], + 77: [ + function (A, e, t) { + "use strict"; + var i = A("minimalistic-assert"), + g = A("inherits"), + r = A("./utils"), + n = A("./cipher"); + function B(A) { + n.call(this, A); + var e = new (function () { + (this.tmp = new Array(2)), (this.keys = null); + })(); + (this._desState = e), this.deriveKeys(e, A.key); + } + g(B, n), + (e.exports = B), + (B.create = function (A) { + return new B(A); + }); + var I = [1, 1, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1]; + (B.prototype.deriveKeys = function (A, e) { + (A.keys = new Array(32)), + i.equal(e.length, this.blockSize, "Invalid key length"); + var t = r.readUInt32BE(e, 0), + g = r.readUInt32BE(e, 4); + r.pc1(t, g, A.tmp, 0), (t = A.tmp[0]), (g = A.tmp[1]); + for (var n = 0; n < A.keys.length; n += 2) { + var B = I[n >>> 1]; + (t = r.r28shl(t, B)), (g = r.r28shl(g, B)), r.pc2(t, g, A.keys, n); + } + }), + (B.prototype._update = function (A, e, t, i) { + var g = this._desState, + n = r.readUInt32BE(A, e), + B = r.readUInt32BE(A, e + 4); + r.ip(n, B, g.tmp, 0), + (n = g.tmp[0]), + (B = g.tmp[1]), + "encrypt" === this.type + ? this._encrypt(g, n, B, g.tmp, 0) + : this._decrypt(g, n, B, g.tmp, 0), + (n = g.tmp[0]), + (B = g.tmp[1]), + r.writeUInt32BE(t, n, i), + r.writeUInt32BE(t, B, i + 4); + }), + (B.prototype._pad = function (A, e) { + for (var t = A.length - e, i = e; i < A.length; i++) A[i] = t; + return !0; + }), + (B.prototype._unpad = function (A) { + for (var e = A[A.length - 1], t = A.length - e; t < A.length; t++) + i.equal(A[t], e); + return A.slice(0, A.length - e); + }), + (B.prototype._encrypt = function (A, e, t, i, g) { + for (var n = e, B = t, I = 0; I < A.keys.length; I += 2) { + var o = A.keys[I], + a = A.keys[I + 1]; + r.expand(B, A.tmp, 0), (o ^= A.tmp[0]), (a ^= A.tmp[1]); + var Q = r.substitute(o, a), + C = B; + (B = (n ^ r.permute(Q)) >>> 0), (n = C); + } + r.rip(B, n, i, g); + }), + (B.prototype._decrypt = function (A, e, t, i, g) { + for (var n = t, B = e, I = A.keys.length - 2; I >= 0; I -= 2) { + var o = A.keys[I], + a = A.keys[I + 1]; + r.expand(n, A.tmp, 0), (o ^= A.tmp[0]), (a ^= A.tmp[1]); + var Q = r.substitute(o, a), + C = n; + (n = (B ^ r.permute(Q)) >>> 0), (B = C); + } + r.rip(n, B, i, g); + }); + }, + { + "./cipher": 76, + "./utils": 79, + inherits: 134, + "minimalistic-assert": 140, + }, + ], + 78: [ + function (A, e, t) { + "use strict"; + var i = A("minimalistic-assert"), + g = A("inherits"), + r = A("./cipher"), + n = A("./des"); + function B(A) { + r.call(this, A); + var e = new (function (A, e) { + i.equal(e.length, 24, "Invalid key length"); + var t = e.slice(0, 8), + g = e.slice(8, 16), + r = e.slice(16, 24); + this.ciphers = + "encrypt" === A + ? [ + n.create({ type: "encrypt", key: t }), + n.create({ type: "decrypt", key: g }), + n.create({ type: "encrypt", key: r }), + ] + : [ + n.create({ type: "decrypt", key: r }), + n.create({ type: "encrypt", key: g }), + n.create({ type: "decrypt", key: t }), + ]; + })(this.type, this.options.key); + this._edeState = e; + } + g(B, r), + (e.exports = B), + (B.create = function (A) { + return new B(A); + }), + (B.prototype._update = function (A, e, t, i) { + var g = this._edeState; + g.ciphers[0]._update(A, e, t, i), + g.ciphers[1]._update(t, i, t, i), + g.ciphers[2]._update(t, i, t, i); + }), + (B.prototype._pad = n.prototype._pad), + (B.prototype._unpad = n.prototype._unpad); + }, + { + "./cipher": 76, + "./des": 77, + inherits: 134, + "minimalistic-assert": 140, + }, + ], + 79: [ + function (A, e, t) { + "use strict"; + (t.readUInt32BE = function (A, e) { + return ( + ((A[0 + e] << 24) | + (A[1 + e] << 16) | + (A[2 + e] << 8) | + A[3 + e]) >>> + 0 + ); + }), + (t.writeUInt32BE = function (A, e, t) { + (A[0 + t] = e >>> 24), + (A[1 + t] = (e >>> 16) & 255), + (A[2 + t] = (e >>> 8) & 255), + (A[3 + t] = 255 & e); + }), + (t.ip = function (A, e, t, i) { + for (var g = 0, r = 0, n = 6; n >= 0; n -= 2) { + for (var B = 0; B <= 24; B += 8) + (g <<= 1), (g |= (e >>> (B + n)) & 1); + for (B = 0; B <= 24; B += 8) + (g <<= 1), (g |= (A >>> (B + n)) & 1); + } + for (n = 6; n >= 0; n -= 2) { + for (B = 1; B <= 25; B += 8) + (r <<= 1), (r |= (e >>> (B + n)) & 1); + for (B = 1; B <= 25; B += 8) + (r <<= 1), (r |= (A >>> (B + n)) & 1); + } + (t[i + 0] = g >>> 0), (t[i + 1] = r >>> 0); + }), + (t.rip = function (A, e, t, i) { + for (var g = 0, r = 0, n = 0; n < 4; n++) + for (var B = 24; B >= 0; B -= 8) + (g <<= 1), + (g |= (e >>> (B + n)) & 1), + (g <<= 1), + (g |= (A >>> (B + n)) & 1); + for (n = 4; n < 8; n++) + for (B = 24; B >= 0; B -= 8) + (r <<= 1), + (r |= (e >>> (B + n)) & 1), + (r <<= 1), + (r |= (A >>> (B + n)) & 1); + (t[i + 0] = g >>> 0), (t[i + 1] = r >>> 0); + }), + (t.pc1 = function (A, e, t, i) { + for (var g = 0, r = 0, n = 7; n >= 5; n--) { + for (var B = 0; B <= 24; B += 8) + (g <<= 1), (g |= (e >> (B + n)) & 1); + for (B = 0; B <= 24; B += 8) (g <<= 1), (g |= (A >> (B + n)) & 1); + } + for (B = 0; B <= 24; B += 8) (g <<= 1), (g |= (e >> (B + n)) & 1); + for (n = 1; n <= 3; n++) { + for (B = 0; B <= 24; B += 8) (r <<= 1), (r |= (e >> (B + n)) & 1); + for (B = 0; B <= 24; B += 8) (r <<= 1), (r |= (A >> (B + n)) & 1); + } + for (B = 0; B <= 24; B += 8) (r <<= 1), (r |= (A >> (B + n)) & 1); + (t[i + 0] = g >>> 0), (t[i + 1] = r >>> 0); + }), + (t.r28shl = function (A, e) { + return ((A << e) & 268435455) | (A >>> (28 - e)); + }); + var i = [ + 14, 11, 17, 4, 27, 23, 25, 0, 13, 22, 7, 18, 5, 9, 16, 24, 2, 20, 12, + 21, 1, 8, 15, 26, 15, 4, 25, 19, 9, 1, 26, 16, 5, 11, 23, 8, 12, 7, + 17, 0, 22, 3, 10, 14, 6, 20, 27, 24, + ]; + (t.pc2 = function (A, e, t, g) { + for (var r = 0, n = 0, B = i.length >>> 1, I = 0; I < B; I++) + (r <<= 1), (r |= (A >>> i[I]) & 1); + for (I = B; I < i.length; I++) (n <<= 1), (n |= (e >>> i[I]) & 1); + (t[g + 0] = r >>> 0), (t[g + 1] = n >>> 0); + }), + (t.expand = function (A, e, t) { + var i = 0, + g = 0; + i = ((1 & A) << 5) | (A >>> 27); + for (var r = 23; r >= 15; r -= 4) (i <<= 6), (i |= (A >>> r) & 63); + for (r = 11; r >= 3; r -= 4) (g |= (A >>> r) & 63), (g <<= 6); + (g |= ((31 & A) << 1) | (A >>> 31)), + (e[t + 0] = i >>> 0), + (e[t + 1] = g >>> 0); + }); + var g = [ + 14, 0, 4, 15, 13, 7, 1, 4, 2, 14, 15, 2, 11, 13, 8, 1, 3, 10, 10, 6, + 6, 12, 12, 11, 5, 9, 9, 5, 0, 3, 7, 8, 4, 15, 1, 12, 14, 8, 8, 2, 13, + 4, 6, 9, 2, 1, 11, 7, 15, 5, 12, 11, 9, 3, 7, 14, 3, 10, 10, 0, 5, 6, + 0, 13, 15, 3, 1, 13, 8, 4, 14, 7, 6, 15, 11, 2, 3, 8, 4, 14, 9, 12, 7, + 0, 2, 1, 13, 10, 12, 6, 0, 9, 5, 11, 10, 5, 0, 13, 14, 8, 7, 10, 11, + 1, 10, 3, 4, 15, 13, 4, 1, 2, 5, 11, 8, 6, 12, 7, 6, 12, 9, 0, 3, 5, + 2, 14, 15, 9, 10, 13, 0, 7, 9, 0, 14, 9, 6, 3, 3, 4, 15, 6, 5, 10, 1, + 2, 13, 8, 12, 5, 7, 14, 11, 12, 4, 11, 2, 15, 8, 1, 13, 1, 6, 10, 4, + 13, 9, 0, 8, 6, 15, 9, 3, 8, 0, 7, 11, 4, 1, 15, 2, 14, 12, 3, 5, 11, + 10, 5, 14, 2, 7, 12, 7, 13, 13, 8, 14, 11, 3, 5, 0, 6, 6, 15, 9, 0, + 10, 3, 1, 4, 2, 7, 8, 2, 5, 12, 11, 1, 12, 10, 4, 14, 15, 9, 10, 3, 6, + 15, 9, 0, 0, 6, 12, 10, 11, 1, 7, 13, 13, 8, 15, 9, 1, 4, 3, 5, 14, + 11, 5, 12, 2, 7, 8, 2, 4, 14, 2, 14, 12, 11, 4, 2, 1, 12, 7, 4, 10, 7, + 11, 13, 6, 1, 8, 5, 5, 0, 3, 15, 15, 10, 13, 3, 0, 9, 14, 8, 9, 6, 4, + 11, 2, 8, 1, 12, 11, 7, 10, 1, 13, 14, 7, 2, 8, 13, 15, 6, 9, 15, 12, + 0, 5, 9, 6, 10, 3, 4, 0, 5, 14, 3, 12, 10, 1, 15, 10, 4, 15, 2, 9, 7, + 2, 12, 6, 9, 8, 5, 0, 6, 13, 1, 3, 13, 4, 14, 14, 0, 7, 11, 5, 3, 11, + 8, 9, 4, 14, 3, 15, 2, 5, 12, 2, 9, 8, 5, 12, 15, 3, 10, 7, 11, 0, 14, + 4, 1, 10, 7, 1, 6, 13, 0, 11, 8, 6, 13, 4, 13, 11, 0, 2, 11, 14, 7, + 15, 4, 0, 9, 8, 1, 13, 10, 3, 14, 12, 3, 9, 5, 7, 12, 5, 2, 10, 15, 6, + 8, 1, 6, 1, 6, 4, 11, 11, 13, 13, 8, 12, 1, 3, 4, 7, 10, 14, 7, 10, 9, + 15, 5, 6, 0, 8, 15, 0, 14, 5, 2, 9, 3, 2, 12, 13, 1, 2, 15, 8, 13, 4, + 8, 6, 10, 15, 3, 11, 7, 1, 4, 10, 12, 9, 5, 3, 6, 14, 11, 5, 0, 0, 14, + 12, 9, 7, 2, 7, 2, 11, 1, 4, 14, 1, 7, 9, 4, 12, 10, 14, 8, 2, 13, 0, + 15, 6, 12, 10, 9, 13, 0, 15, 3, 3, 5, 5, 6, 8, 11, + ]; + t.substitute = function (A, e) { + for (var t = 0, i = 0; i < 4; i++) { + (t <<= 4), (t |= g[64 * i + ((A >>> (18 - 6 * i)) & 63)]); + } + for (i = 0; i < 4; i++) { + (t <<= 4), (t |= g[256 + 64 * i + ((e >>> (18 - 6 * i)) & 63)]); + } + return t >>> 0; + }; + var r = [ + 16, 25, 12, 11, 3, 20, 4, 15, 31, 17, 9, 6, 27, 14, 1, 22, 30, 24, 8, + 18, 0, 5, 29, 23, 13, 19, 2, 26, 10, 21, 28, 7, + ]; + (t.permute = function (A) { + for (var e = 0, t = 0; t < r.length; t++) + (e <<= 1), (e |= (A >>> r[t]) & 1); + return e >>> 0; + }), + (t.padSplit = function (A, e, t) { + for (var i = A.toString(2); i.length < e; ) i = "0" + i; + for (var g = [], r = 0; r < e; r += t) g.push(i.slice(r, r + t)); + return g.join(" "); + }); + }, + {}, + ], + 80: [ + function (A, e, t) { + (function (e) { + var i = A("./lib/generatePrime"), + g = A("./lib/primes.json"), + r = A("./lib/dh"); + var n = { binary: !0, hex: !0, base64: !0 }; + (t.DiffieHellmanGroup = + t.createDiffieHellmanGroup = + t.getDiffieHellman = + function (A) { + var t = new e(g[A].prime, "hex"), + i = new e(g[A].gen, "hex"); + return new r(t, i); + }), + (t.createDiffieHellman = t.DiffieHellman = + function A(t, g, B, I) { + return e.isBuffer(g) || void 0 === n[g] + ? A(t, "binary", g, B) + : ((g = g || "binary"), + (I = I || "binary"), + (B = B || new e([2])), + e.isBuffer(B) || (B = new e(B, I)), + "number" == typeof t + ? new r(i(t, B), B, !0) + : (e.isBuffer(t) || (t = new e(t, g)), new r(t, B, !0))); + }); + }.call(this, A("buffer").Buffer)); + }, + { + "./lib/dh": 81, + "./lib/generatePrime": 82, + "./lib/primes.json": 83, + buffer: 64, + }, + ], + 81: [ + function (A, e, t) { + (function (t) { + var i = A("bn.js"), + g = new (A("miller-rabin"))(), + r = new i(24), + n = new i(11), + B = new i(10), + I = new i(3), + o = new i(7), + a = A("./generatePrime"), + Q = A("randombytes"); + function C(A, e) { + return ( + (e = e || "utf8"), + t.isBuffer(A) || (A = new t(A, e)), + (this._pub = new i(A)), + this + ); + } + function s(A, e) { + return ( + (e = e || "utf8"), + t.isBuffer(A) || (A = new t(A, e)), + (this._priv = new i(A)), + this + ); + } + e.exports = h; + var c = {}; + function h(A, e, t) { + this.setGenerator(e), + (this.__prime = new i(A)), + (this._prime = i.mont(this.__prime)), + (this._primeLen = A.length), + (this._pub = void 0), + (this._priv = void 0), + (this._primeCode = void 0), + t + ? ((this.setPublicKey = C), (this.setPrivateKey = s)) + : (this._primeCode = 8); + } + function f(A, e) { + var i = new t(A.toArray()); + return e ? i.toString(e) : i; + } + Object.defineProperty(h.prototype, "verifyError", { + enumerable: !0, + get: function () { + return ( + "number" != typeof this._primeCode && + (this._primeCode = (function (A, e) { + var t = e.toString("hex"), + i = [t, A.toString(16)].join("_"); + if (i in c) return c[i]; + var Q, + C = 0; + if ( + A.isEven() || + !a.simpleSieve || + !a.fermatTest(A) || + !g.test(A) + ) + return ( + (C += 1), + (C += "02" === t || "05" === t ? 8 : 4), + (c[i] = C), + C + ); + switch ((g.test(A.shrn(1)) || (C += 2), t)) { + case "02": + A.mod(r).cmp(n) && (C += 8); + break; + case "05": + (Q = A.mod(B)).cmp(I) && Q.cmp(o) && (C += 8); + break; + default: + C += 4; + } + return (c[i] = C), C; + })(this.__prime, this.__gen)), + this._primeCode + ); + }, + }), + (h.prototype.generateKeys = function () { + return ( + this._priv || (this._priv = new i(Q(this._primeLen))), + (this._pub = this._gen + .toRed(this._prime) + .redPow(this._priv) + .fromRed()), + this.getPublicKey() + ); + }), + (h.prototype.computeSecret = function (A) { + var e = (A = (A = new i(A)).toRed(this._prime)) + .redPow(this._priv) + .fromRed(), + g = new t(e.toArray()), + r = this.getPrime(); + if (g.length < r.length) { + var n = new t(r.length - g.length); + n.fill(0), (g = t.concat([n, g])); + } + return g; + }), + (h.prototype.getPublicKey = function (A) { + return f(this._pub, A); + }), + (h.prototype.getPrivateKey = function (A) { + return f(this._priv, A); + }), + (h.prototype.getPrime = function (A) { + return f(this.__prime, A); + }), + (h.prototype.getGenerator = function (A) { + return f(this._gen, A); + }), + (h.prototype.setGenerator = function (A, e) { + return ( + (e = e || "utf8"), + t.isBuffer(A) || (A = new t(A, e)), + (this.__gen = A), + (this._gen = new i(A)), + this + ); + }); + }.call(this, A("buffer").Buffer)); + }, + { + "./generatePrime": 82, + "bn.js": 84, + buffer: 64, + "miller-rabin": 138, + randombytes: 162, + }, + ], + 82: [ + function (A, e, t) { + var i = A("randombytes"); + (e.exports = u), (u.simpleSieve = f), (u.fermatTest = E); + var g = A("bn.js"), + r = new g(24), + n = new (A("miller-rabin"))(), + B = new g(1), + I = new g(2), + o = new g(5), + a = (new g(16), new g(8), new g(10)), + Q = new g(3), + C = (new g(7), new g(11)), + s = new g(4), + c = (new g(12), null); + function h() { + if (null !== c) return c; + var A = []; + A[0] = 2; + for (var e = 1, t = 3; t < 1048576; t += 2) { + for ( + var i = Math.ceil(Math.sqrt(t)), g = 0; + g < e && A[g] <= i && t % A[g] != 0; + g++ + ); + (e !== g && A[g] <= i) || (A[e++] = t); + } + return (c = A), A; + } + function f(A) { + for (var e = h(), t = 0; t < e.length; t++) + if (0 === A.modn(e[t])) return 0 === A.cmpn(e[t]); + return !0; + } + function E(A) { + var e = g.mont(A); + return 0 === I.toRed(e).redPow(A.subn(1)).fromRed().cmpn(1); + } + function u(A, e) { + if (A < 16) return new g(2 === e || 5 === e ? [140, 123] : [140, 39]); + var t, c; + for (e = new g(e); ; ) { + for (t = new g(i(Math.ceil(A / 8))); t.bitLength() > A; ) + t.ishrn(1); + if ((t.isEven() && t.iadd(B), t.testn(1) || t.iadd(I), e.cmp(I))) { + if (!e.cmp(o)) for (; t.mod(a).cmp(Q); ) t.iadd(s); + } else for (; t.mod(r).cmp(C); ) t.iadd(s); + if ( + f((c = t.shrn(1))) && + f(t) && + E(c) && + E(t) && + n.test(c) && + n.test(t) + ) + return t; + } + } + }, + { "bn.js": 84, "miller-rabin": 138, randombytes: 162 }, + ], + 83: [ + function (A, e, t) { + e.exports = { + modp1: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a63a3620ffffffffffffffff", + }, + modp2: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece65381ffffffffffffffff", + }, + modp5: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca237327ffffffffffffffff", + }, + modp14: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aacaa68ffffffffffffffff", + }, + modp15: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a93ad2caffffffffffffffff", + }, + modp16: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c934063199ffffffffffffffff", + }, + modp17: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dcc4024ffffffffffffffff", + }, + modp18: { + gen: "02", + prime: + "ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dbe115974a3926f12fee5e438777cb6a932df8cd8bec4d073b931ba3bc832b68d9dd300741fa7bf8afc47ed2576f6936ba424663aab639c5ae4f5683423b4742bf1c978238f16cbe39d652de3fdb8befc848ad922222e04a4037c0713eb57a81a23f0c73473fc646cea306b4bcbc8862f8385ddfa9d4b7fa2c087e879683303ed5bdd3a062b3cf5b3a278a66d2a13f83f44f82ddf310ee074ab6a364597e899a0255dc164f31cc50846851df9ab48195ded7ea1b1d510bd7ee74d73faf36bc31ecfa268359046f4eb879f924009438b481c6cd7889a002ed5ee382bc9190da6fc026e479558e4475677e9aa9e3050e2765694dfc81f56e880b96e7160c980dd98edd3dfffffffffffffffff", + }, + }; + }, + {}, + ], + 84: [ + function (A, e, t) { + arguments[4][15][0].apply(t, arguments); + }, + { buffer: 19, dup: 15 }, + ], + 85: [ + function (A, e, t) { + "use strict"; + var i = t; + (i.version = A("../package.json").version), + (i.utils = A("./elliptic/utils")), + (i.rand = A("brorand")), + (i.curve = A("./elliptic/curve")), + (i.curves = A("./elliptic/curves")), + (i.ec = A("./elliptic/ec")), + (i.eddsa = A("./elliptic/eddsa")); + }, + { + "../package.json": 101, + "./elliptic/curve": 88, + "./elliptic/curves": 91, + "./elliptic/ec": 92, + "./elliptic/eddsa": 95, + "./elliptic/utils": 99, + brorand: 18, + }, + ], + 86: [ + function (A, e, t) { + "use strict"; + var i = A("bn.js"), + g = A("../utils"), + r = g.getNAF, + n = g.getJSF, + B = g.assert; + function I(A, e) { + (this.type = A), + (this.p = new i(e.p, 16)), + (this.red = e.prime ? i.red(e.prime) : i.mont(this.p)), + (this.zero = new i(0).toRed(this.red)), + (this.one = new i(1).toRed(this.red)), + (this.two = new i(2).toRed(this.red)), + (this.n = e.n && new i(e.n, 16)), + (this.g = e.g && this.pointFromJSON(e.g, e.gRed)), + (this._wnafT1 = new Array(4)), + (this._wnafT2 = new Array(4)), + (this._wnafT3 = new Array(4)), + (this._wnafT4 = new Array(4)), + (this._bitLength = this.n ? this.n.bitLength() : 0); + var t = this.n && this.p.div(this.n); + !t || t.cmpn(100) > 0 + ? (this.redN = null) + : ((this._maxwellTrick = !0), (this.redN = this.n.toRed(this.red))); + } + function o(A, e) { + (this.curve = A), (this.type = e), (this.precomputed = null); + } + (e.exports = I), + (I.prototype.point = function () { + throw new Error("Not implemented"); + }), + (I.prototype.validate = function () { + throw new Error("Not implemented"); + }), + (I.prototype._fixedNafMul = function (A, e) { + B(A.precomputed); + var t = A._getDoubles(), + i = r(e, 1, this._bitLength), + g = (1 << (t.step + 1)) - (t.step % 2 == 0 ? 2 : 1); + g /= 3; + for (var n = [], I = 0; I < i.length; I += t.step) { + var o = 0; + for (e = I + t.step - 1; e >= I; e--) o = (o << 1) + i[e]; + n.push(o); + } + for ( + var a = this.jpoint(null, null, null), + Q = this.jpoint(null, null, null), + C = g; + C > 0; + C-- + ) { + for (I = 0; I < n.length; I++) { + (o = n[I]) === C + ? (Q = Q.mixedAdd(t.points[I])) + : o === -C && (Q = Q.mixedAdd(t.points[I].neg())); + } + a = a.add(Q); + } + return a.toP(); + }), + (I.prototype._wnafMul = function (A, e) { + var t = 4, + i = A._getNAFPoints(t); + t = i.wnd; + for ( + var g = i.points, + n = r(e, t, this._bitLength), + I = this.jpoint(null, null, null), + o = n.length - 1; + o >= 0; + o-- + ) { + for (e = 0; o >= 0 && 0 === n[o]; o--) e++; + if ((o >= 0 && e++, (I = I.dblp(e)), o < 0)) break; + var a = n[o]; + B(0 !== a), + (I = + "affine" === A.type + ? a > 0 + ? I.mixedAdd(g[(a - 1) >> 1]) + : I.mixedAdd(g[(-a - 1) >> 1].neg()) + : a > 0 + ? I.add(g[(a - 1) >> 1]) + : I.add(g[(-a - 1) >> 1].neg())); + } + return "affine" === A.type ? I.toP() : I; + }), + (I.prototype._wnafMulAdd = function (A, e, t, i, g) { + for ( + var B = this._wnafT1, + I = this._wnafT2, + o = this._wnafT3, + a = 0, + Q = 0; + Q < i; + Q++ + ) { + var C = (y = e[Q])._getNAFPoints(A); + (B[Q] = C.wnd), (I[Q] = C.points); + } + for (Q = i - 1; Q >= 1; Q -= 2) { + var s = Q - 1, + c = Q; + if (1 === B[s] && 1 === B[c]) { + var h = [e[s], null, null, e[c]]; + 0 === e[s].y.cmp(e[c].y) + ? ((h[1] = e[s].add(e[c])), + (h[2] = e[s].toJ().mixedAdd(e[c].neg()))) + : 0 === e[s].y.cmp(e[c].y.redNeg()) + ? ((h[1] = e[s].toJ().mixedAdd(e[c])), + (h[2] = e[s].add(e[c].neg()))) + : ((h[1] = e[s].toJ().mixedAdd(e[c])), + (h[2] = e[s].toJ().mixedAdd(e[c].neg()))); + var f = [-3, -1, -5, -7, 0, 7, 5, 1, 3], + E = n(t[s], t[c]); + (a = Math.max(E[0].length, a)), + (o[s] = new Array(a)), + (o[c] = new Array(a)); + for (var u = 0; u < a; u++) { + var d = 0 | E[0][u], + l = 0 | E[1][u]; + (o[s][u] = f[3 * (d + 1) + (l + 1)]), + (o[c][u] = 0), + (I[s] = h); + } + } else + (o[s] = r(t[s], B[s], this._bitLength)), + (o[c] = r(t[c], B[c], this._bitLength)), + (a = Math.max(o[s].length, a)), + (a = Math.max(o[c].length, a)); + } + var w = this.jpoint(null, null, null), + p = this._wnafT4; + for (Q = a; Q >= 0; Q--) { + for (var D = 0; Q >= 0; ) { + var b = !0; + for (u = 0; u < i; u++) + (p[u] = 0 | o[u][Q]), 0 !== p[u] && (b = !1); + if (!b) break; + D++, Q--; + } + if ((Q >= 0 && D++, (w = w.dblp(D)), Q < 0)) break; + for (u = 0; u < i; u++) { + var y, + M = p[u]; + 0 !== M && + (M > 0 + ? (y = I[u][(M - 1) >> 1]) + : M < 0 && (y = I[u][(-M - 1) >> 1].neg()), + (w = "affine" === y.type ? w.mixedAdd(y) : w.add(y))); + } + } + for (Q = 0; Q < i; Q++) I[Q] = null; + return g ? w : w.toP(); + }), + (I.BasePoint = o), + (o.prototype.eq = function () { + throw new Error("Not implemented"); + }), + (o.prototype.validate = function () { + return this.curve.validate(this); + }), + (I.prototype.decodePoint = function (A, e) { + A = g.toArray(A, e); + var t = this.p.byteLength(); + if ( + (4 === A[0] || 6 === A[0] || 7 === A[0]) && + A.length - 1 == 2 * t + ) + return ( + 6 === A[0] + ? B(A[A.length - 1] % 2 == 0) + : 7 === A[0] && B(A[A.length - 1] % 2 == 1), + this.point(A.slice(1, 1 + t), A.slice(1 + t, 1 + 2 * t)) + ); + if ((2 === A[0] || 3 === A[0]) && A.length - 1 === t) + return this.pointFromX(A.slice(1, 1 + t), 3 === A[0]); + throw new Error("Unknown point format"); + }), + (o.prototype.encodeCompressed = function (A) { + return this.encode(A, !0); + }), + (o.prototype._encode = function (A) { + var e = this.curve.p.byteLength(), + t = this.getX().toArray("be", e); + return A + ? [this.getY().isEven() ? 2 : 3].concat(t) + : [4].concat(t, this.getY().toArray("be", e)); + }), + (o.prototype.encode = function (A, e) { + return g.encode(this._encode(e), A); + }), + (o.prototype.precompute = function (A) { + if (this.precomputed) return this; + var e = { doubles: null, naf: null, beta: null }; + return ( + (e.naf = this._getNAFPoints(8)), + (e.doubles = this._getDoubles(4, A)), + (e.beta = this._getBeta()), + (this.precomputed = e), + this + ); + }), + (o.prototype._hasDoubles = function (A) { + if (!this.precomputed) return !1; + var e = this.precomputed.doubles; + return ( + !!e && e.points.length >= Math.ceil((A.bitLength() + 1) / e.step) + ); + }), + (o.prototype._getDoubles = function (A, e) { + if (this.precomputed && this.precomputed.doubles) + return this.precomputed.doubles; + for (var t = [this], i = this, g = 0; g < e; g += A) { + for (var r = 0; r < A; r++) i = i.dbl(); + t.push(i); + } + return { step: A, points: t }; + }), + (o.prototype._getNAFPoints = function (A) { + if (this.precomputed && this.precomputed.naf) + return this.precomputed.naf; + for ( + var e = [this], + t = (1 << A) - 1, + i = 1 === t ? null : this.dbl(), + g = 1; + g < t; + g++ + ) + e[g] = e[g - 1].add(i); + return { wnd: A, points: e }; + }), + (o.prototype._getBeta = function () { + return null; + }), + (o.prototype.dblp = function (A) { + for (var e = this, t = 0; t < A; t++) e = e.dbl(); + return e; + }); + }, + { "../utils": 99, "bn.js": 100 }, + ], + 87: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = A("bn.js"), + r = A("inherits"), + n = A("./base"), + B = i.assert; + function I(A) { + (this.twisted = 1 != (0 | A.a)), + (this.mOneA = this.twisted && -1 == (0 | A.a)), + (this.extended = this.mOneA), + n.call(this, "edwards", A), + (this.a = new g(A.a, 16).umod(this.red.m)), + (this.a = this.a.toRed(this.red)), + (this.c = new g(A.c, 16).toRed(this.red)), + (this.c2 = this.c.redSqr()), + (this.d = new g(A.d, 16).toRed(this.red)), + (this.dd = this.d.redAdd(this.d)), + B(!this.twisted || 0 === this.c.fromRed().cmpn(1)), + (this.oneC = 1 == (0 | A.c)); + } + function o(A, e, t, i, r) { + n.BasePoint.call(this, A, "projective"), + null === e && null === t && null === i + ? ((this.x = this.curve.zero), + (this.y = this.curve.one), + (this.z = this.curve.one), + (this.t = this.curve.zero), + (this.zOne = !0)) + : ((this.x = new g(e, 16)), + (this.y = new g(t, 16)), + (this.z = i ? new g(i, 16) : this.curve.one), + (this.t = r && new g(r, 16)), + this.x.red || (this.x = this.x.toRed(this.curve.red)), + this.y.red || (this.y = this.y.toRed(this.curve.red)), + this.z.red || (this.z = this.z.toRed(this.curve.red)), + this.t && + !this.t.red && + (this.t = this.t.toRed(this.curve.red)), + (this.zOne = this.z === this.curve.one), + this.curve.extended && + !this.t && + ((this.t = this.x.redMul(this.y)), + this.zOne || (this.t = this.t.redMul(this.z.redInvm())))); + } + r(I, n), + (e.exports = I), + (I.prototype._mulA = function (A) { + return this.mOneA ? A.redNeg() : this.a.redMul(A); + }), + (I.prototype._mulC = function (A) { + return this.oneC ? A : this.c.redMul(A); + }), + (I.prototype.jpoint = function (A, e, t, i) { + return this.point(A, e, t, i); + }), + (I.prototype.pointFromX = function (A, e) { + (A = new g(A, 16)).red || (A = A.toRed(this.red)); + var t = A.redSqr(), + i = this.c2.redSub(this.a.redMul(t)), + r = this.one.redSub(this.c2.redMul(this.d).redMul(t)), + n = i.redMul(r.redInvm()), + B = n.redSqrt(); + if (0 !== B.redSqr().redSub(n).cmp(this.zero)) + throw new Error("invalid point"); + var I = B.fromRed().isOdd(); + return ( + ((e && !I) || (!e && I)) && (B = B.redNeg()), this.point(A, B) + ); + }), + (I.prototype.pointFromY = function (A, e) { + (A = new g(A, 16)).red || (A = A.toRed(this.red)); + var t = A.redSqr(), + i = t.redSub(this.c2), + r = t.redMul(this.d).redMul(this.c2).redSub(this.a), + n = i.redMul(r.redInvm()); + if (0 === n.cmp(this.zero)) { + if (e) throw new Error("invalid point"); + return this.point(this.zero, A); + } + var B = n.redSqrt(); + if (0 !== B.redSqr().redSub(n).cmp(this.zero)) + throw new Error("invalid point"); + return ( + B.fromRed().isOdd() !== e && (B = B.redNeg()), this.point(B, A) + ); + }), + (I.prototype.validate = function (A) { + if (A.isInfinity()) return !0; + A.normalize(); + var e = A.x.redSqr(), + t = A.y.redSqr(), + i = e.redMul(this.a).redAdd(t), + g = this.c2.redMul(this.one.redAdd(this.d.redMul(e).redMul(t))); + return 0 === i.cmp(g); + }), + r(o, n.BasePoint), + (I.prototype.pointFromJSON = function (A) { + return o.fromJSON(this, A); + }), + (I.prototype.point = function (A, e, t, i) { + return new o(this, A, e, t, i); + }), + (o.fromJSON = function (A, e) { + return new o(A, e[0], e[1], e[2]); + }), + (o.prototype.inspect = function () { + return this.isInfinity() + ? "" + : ""; + }), + (o.prototype.isInfinity = function () { + return ( + 0 === this.x.cmpn(0) && + (0 === this.y.cmp(this.z) || + (this.zOne && 0 === this.y.cmp(this.curve.c))) + ); + }), + (o.prototype._extDbl = function () { + var A = this.x.redSqr(), + e = this.y.redSqr(), + t = this.z.redSqr(); + t = t.redIAdd(t); + var i = this.curve._mulA(A), + g = this.x.redAdd(this.y).redSqr().redISub(A).redISub(e), + r = i.redAdd(e), + n = r.redSub(t), + B = i.redSub(e), + I = g.redMul(n), + o = r.redMul(B), + a = g.redMul(B), + Q = n.redMul(r); + return this.curve.point(I, o, Q, a); + }), + (o.prototype._projDbl = function () { + var A, + e, + t, + i = this.x.redAdd(this.y).redSqr(), + g = this.x.redSqr(), + r = this.y.redSqr(); + if (this.curve.twisted) { + var n = (o = this.curve._mulA(g)).redAdd(r); + if (this.zOne) + (A = i.redSub(g).redSub(r).redMul(n.redSub(this.curve.two))), + (e = n.redMul(o.redSub(r))), + (t = n.redSqr().redSub(n).redSub(n)); + else { + var B = this.z.redSqr(), + I = n.redSub(B).redISub(B); + (A = i.redSub(g).redISub(r).redMul(I)), + (e = n.redMul(o.redSub(r))), + (t = n.redMul(I)); + } + } else { + var o = g.redAdd(r); + (B = this.curve._mulC(this.z).redSqr()), + (I = o.redSub(B).redSub(B)); + (A = this.curve._mulC(i.redISub(o)).redMul(I)), + (e = this.curve._mulC(o).redMul(g.redISub(r))), + (t = o.redMul(I)); + } + return this.curve.point(A, e, t); + }), + (o.prototype.dbl = function () { + return this.isInfinity() + ? this + : this.curve.extended + ? this._extDbl() + : this._projDbl(); + }), + (o.prototype._extAdd = function (A) { + var e = this.y.redSub(this.x).redMul(A.y.redSub(A.x)), + t = this.y.redAdd(this.x).redMul(A.y.redAdd(A.x)), + i = this.t.redMul(this.curve.dd).redMul(A.t), + g = this.z.redMul(A.z.redAdd(A.z)), + r = t.redSub(e), + n = g.redSub(i), + B = g.redAdd(i), + I = t.redAdd(e), + o = r.redMul(n), + a = B.redMul(I), + Q = r.redMul(I), + C = n.redMul(B); + return this.curve.point(o, a, C, Q); + }), + (o.prototype._projAdd = function (A) { + var e, + t, + i = this.z.redMul(A.z), + g = i.redSqr(), + r = this.x.redMul(A.x), + n = this.y.redMul(A.y), + B = this.curve.d.redMul(r).redMul(n), + I = g.redSub(B), + o = g.redAdd(B), + a = this.x + .redAdd(this.y) + .redMul(A.x.redAdd(A.y)) + .redISub(r) + .redISub(n), + Q = i.redMul(I).redMul(a); + return ( + this.curve.twisted + ? ((e = i.redMul(o).redMul(n.redSub(this.curve._mulA(r)))), + (t = I.redMul(o))) + : ((e = i.redMul(o).redMul(n.redSub(r))), + (t = this.curve._mulC(I).redMul(o))), + this.curve.point(Q, e, t) + ); + }), + (o.prototype.add = function (A) { + return this.isInfinity() + ? A + : A.isInfinity() + ? this + : this.curve.extended + ? this._extAdd(A) + : this._projAdd(A); + }), + (o.prototype.mul = function (A) { + return this._hasDoubles(A) + ? this.curve._fixedNafMul(this, A) + : this.curve._wnafMul(this, A); + }), + (o.prototype.mulAdd = function (A, e, t) { + return this.curve._wnafMulAdd(1, [this, e], [A, t], 2, !1); + }), + (o.prototype.jmulAdd = function (A, e, t) { + return this.curve._wnafMulAdd(1, [this, e], [A, t], 2, !0); + }), + (o.prototype.normalize = function () { + if (this.zOne) return this; + var A = this.z.redInvm(); + return ( + (this.x = this.x.redMul(A)), + (this.y = this.y.redMul(A)), + this.t && (this.t = this.t.redMul(A)), + (this.z = this.curve.one), + (this.zOne = !0), + this + ); + }), + (o.prototype.neg = function () { + return this.curve.point( + this.x.redNeg(), + this.y, + this.z, + this.t && this.t.redNeg() + ); + }), + (o.prototype.getX = function () { + return this.normalize(), this.x.fromRed(); + }), + (o.prototype.getY = function () { + return this.normalize(), this.y.fromRed(); + }), + (o.prototype.eq = function (A) { + return ( + this === A || + (0 === this.getX().cmp(A.getX()) && + 0 === this.getY().cmp(A.getY())) + ); + }), + (o.prototype.eqXToP = function (A) { + var e = A.toRed(this.curve.red).redMul(this.z); + if (0 === this.x.cmp(e)) return !0; + for (var t = A.clone(), i = this.curve.redN.redMul(this.z); ; ) { + if ((t.iadd(this.curve.n), t.cmp(this.curve.p) >= 0)) return !1; + if ((e.redIAdd(i), 0 === this.x.cmp(e))) return !0; + } + }), + (o.prototype.toP = o.prototype.normalize), + (o.prototype.mixedAdd = o.prototype.add); + }, + { "../utils": 99, "./base": 86, "bn.js": 100, inherits: 134 }, + ], + 88: [ + function (A, e, t) { + "use strict"; + var i = t; + (i.base = A("./base")), + (i.short = A("./short")), + (i.mont = A("./mont")), + (i.edwards = A("./edwards")); + }, + { "./base": 86, "./edwards": 87, "./mont": 89, "./short": 90 }, + ], + 89: [ + function (A, e, t) { + "use strict"; + var i = A("bn.js"), + g = A("inherits"), + r = A("./base"), + n = A("../utils"); + function B(A) { + r.call(this, "mont", A), + (this.a = new i(A.a, 16).toRed(this.red)), + (this.b = new i(A.b, 16).toRed(this.red)), + (this.i4 = new i(4).toRed(this.red).redInvm()), + (this.two = new i(2).toRed(this.red)), + (this.a24 = this.i4.redMul(this.a.redAdd(this.two))); + } + function I(A, e, t) { + r.BasePoint.call(this, A, "projective"), + null === e && null === t + ? ((this.x = this.curve.one), (this.z = this.curve.zero)) + : ((this.x = new i(e, 16)), + (this.z = new i(t, 16)), + this.x.red || (this.x = this.x.toRed(this.curve.red)), + this.z.red || (this.z = this.z.toRed(this.curve.red))); + } + g(B, r), + (e.exports = B), + (B.prototype.validate = function (A) { + var e = A.normalize().x, + t = e.redSqr(), + i = t.redMul(e).redAdd(t.redMul(this.a)).redAdd(e); + return 0 === i.redSqrt().redSqr().cmp(i); + }), + g(I, r.BasePoint), + (B.prototype.decodePoint = function (A, e) { + return this.point(n.toArray(A, e), 1); + }), + (B.prototype.point = function (A, e) { + return new I(this, A, e); + }), + (B.prototype.pointFromJSON = function (A) { + return I.fromJSON(this, A); + }), + (I.prototype.precompute = function () {}), + (I.prototype._encode = function () { + return this.getX().toArray("be", this.curve.p.byteLength()); + }), + (I.fromJSON = function (A, e) { + return new I(A, e[0], e[1] || A.one); + }), + (I.prototype.inspect = function () { + return this.isInfinity() + ? "" + : ""; + }), + (I.prototype.isInfinity = function () { + return 0 === this.z.cmpn(0); + }), + (I.prototype.dbl = function () { + var A = this.x.redAdd(this.z).redSqr(), + e = this.x.redSub(this.z).redSqr(), + t = A.redSub(e), + i = A.redMul(e), + g = t.redMul(e.redAdd(this.curve.a24.redMul(t))); + return this.curve.point(i, g); + }), + (I.prototype.add = function () { + throw new Error("Not supported on Montgomery curve"); + }), + (I.prototype.diffAdd = function (A, e) { + var t = this.x.redAdd(this.z), + i = this.x.redSub(this.z), + g = A.x.redAdd(A.z), + r = A.x.redSub(A.z).redMul(t), + n = g.redMul(i), + B = e.z.redMul(r.redAdd(n).redSqr()), + I = e.x.redMul(r.redISub(n).redSqr()); + return this.curve.point(B, I); + }), + (I.prototype.mul = function (A) { + for ( + var e = A.clone(), + t = this, + i = this.curve.point(null, null), + g = []; + 0 !== e.cmpn(0); + e.iushrn(1) + ) + g.push(e.andln(1)); + for (var r = g.length - 1; r >= 0; r--) + 0 === g[r] + ? ((t = t.diffAdd(i, this)), (i = i.dbl())) + : ((i = t.diffAdd(i, this)), (t = t.dbl())); + return i; + }), + (I.prototype.mulAdd = function () { + throw new Error("Not supported on Montgomery curve"); + }), + (I.prototype.jumlAdd = function () { + throw new Error("Not supported on Montgomery curve"); + }), + (I.prototype.eq = function (A) { + return 0 === this.getX().cmp(A.getX()); + }), + (I.prototype.normalize = function () { + return ( + (this.x = this.x.redMul(this.z.redInvm())), + (this.z = this.curve.one), + this + ); + }), + (I.prototype.getX = function () { + return this.normalize(), this.x.fromRed(); + }); + }, + { "../utils": 99, "./base": 86, "bn.js": 100, inherits: 134 }, + ], + 90: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = A("bn.js"), + r = A("inherits"), + n = A("./base"), + B = i.assert; + function I(A) { + n.call(this, "short", A), + (this.a = new g(A.a, 16).toRed(this.red)), + (this.b = new g(A.b, 16).toRed(this.red)), + (this.tinv = this.two.redInvm()), + (this.zeroA = 0 === this.a.fromRed().cmpn(0)), + (this.threeA = 0 === this.a.fromRed().sub(this.p).cmpn(-3)), + (this.endo = this._getEndomorphism(A)), + (this._endoWnafT1 = new Array(4)), + (this._endoWnafT2 = new Array(4)); + } + function o(A, e, t, i) { + n.BasePoint.call(this, A, "affine"), + null === e && null === t + ? ((this.x = null), (this.y = null), (this.inf = !0)) + : ((this.x = new g(e, 16)), + (this.y = new g(t, 16)), + i && + (this.x.forceRed(this.curve.red), + this.y.forceRed(this.curve.red)), + this.x.red || (this.x = this.x.toRed(this.curve.red)), + this.y.red || (this.y = this.y.toRed(this.curve.red)), + (this.inf = !1)); + } + function a(A, e, t, i) { + n.BasePoint.call(this, A, "jacobian"), + null === e && null === t && null === i + ? ((this.x = this.curve.one), + (this.y = this.curve.one), + (this.z = new g(0))) + : ((this.x = new g(e, 16)), + (this.y = new g(t, 16)), + (this.z = new g(i, 16))), + this.x.red || (this.x = this.x.toRed(this.curve.red)), + this.y.red || (this.y = this.y.toRed(this.curve.red)), + this.z.red || (this.z = this.z.toRed(this.curve.red)), + (this.zOne = this.z === this.curve.one); + } + r(I, n), + (e.exports = I), + (I.prototype._getEndomorphism = function (A) { + if (this.zeroA && this.g && this.n && 1 === this.p.modn(3)) { + var e, t; + if (A.beta) e = new g(A.beta, 16).toRed(this.red); + else { + var i = this._getEndoRoots(this.p); + e = (e = i[0].cmp(i[1]) < 0 ? i[0] : i[1]).toRed(this.red); + } + if (A.lambda) t = new g(A.lambda, 16); + else { + var r = this._getEndoRoots(this.n); + 0 === this.g.mul(r[0]).x.cmp(this.g.x.redMul(e)) + ? (t = r[0]) + : ((t = r[1]), + B(0 === this.g.mul(t).x.cmp(this.g.x.redMul(e)))); + } + return { + beta: e, + lambda: t, + basis: A.basis + ? A.basis.map(function (A) { + return { a: new g(A.a, 16), b: new g(A.b, 16) }; + }) + : this._getEndoBasis(t), + }; + } + }), + (I.prototype._getEndoRoots = function (A) { + var e = A === this.p ? this.red : g.mont(A), + t = new g(2).toRed(e).redInvm(), + i = t.redNeg(), + r = new g(3).toRed(e).redNeg().redSqrt().redMul(t); + return [i.redAdd(r).fromRed(), i.redSub(r).fromRed()]; + }), + (I.prototype._getEndoBasis = function (A) { + for ( + var e, + t, + i, + r, + n, + B, + I, + o, + a, + Q = this.n.ushrn(Math.floor(this.n.bitLength() / 2)), + C = A, + s = this.n.clone(), + c = new g(1), + h = new g(0), + f = new g(0), + E = new g(1), + u = 0; + 0 !== C.cmpn(0); + + ) { + var d = s.div(C); + (o = s.sub(d.mul(C))), (a = f.sub(d.mul(c))); + var l = E.sub(d.mul(h)); + if (!i && o.cmp(Q) < 0) + (e = I.neg()), (t = c), (i = o.neg()), (r = a); + else if (i && 2 == ++u) break; + (I = o), (s = C), (C = o), (f = c), (c = a), (E = h), (h = l); + } + (n = o.neg()), (B = a); + var w = i.sqr().add(r.sqr()); + return ( + n.sqr().add(B.sqr()).cmp(w) >= 0 && ((n = e), (B = t)), + i.negative && ((i = i.neg()), (r = r.neg())), + n.negative && ((n = n.neg()), (B = B.neg())), + [ + { a: i, b: r }, + { a: n, b: B }, + ] + ); + }), + (I.prototype._endoSplit = function (A) { + var e = this.endo.basis, + t = e[0], + i = e[1], + g = i.b.mul(A).divRound(this.n), + r = t.b.neg().mul(A).divRound(this.n), + n = g.mul(t.a), + B = r.mul(i.a), + I = g.mul(t.b), + o = r.mul(i.b); + return { k1: A.sub(n).sub(B), k2: I.add(o).neg() }; + }), + (I.prototype.pointFromX = function (A, e) { + (A = new g(A, 16)).red || (A = A.toRed(this.red)); + var t = A.redSqr() + .redMul(A) + .redIAdd(A.redMul(this.a)) + .redIAdd(this.b), + i = t.redSqrt(); + if (0 !== i.redSqr().redSub(t).cmp(this.zero)) + throw new Error("invalid point"); + var r = i.fromRed().isOdd(); + return ( + ((e && !r) || (!e && r)) && (i = i.redNeg()), this.point(A, i) + ); + }), + (I.prototype.validate = function (A) { + if (A.inf) return !0; + var e = A.x, + t = A.y, + i = this.a.redMul(e), + g = e.redSqr().redMul(e).redIAdd(i).redIAdd(this.b); + return 0 === t.redSqr().redISub(g).cmpn(0); + }), + (I.prototype._endoWnafMulAdd = function (A, e, t) { + for ( + var i = this._endoWnafT1, g = this._endoWnafT2, r = 0; + r < A.length; + r++ + ) { + var n = this._endoSplit(e[r]), + B = A[r], + I = B._getBeta(); + n.k1.negative && (n.k1.ineg(), (B = B.neg(!0))), + n.k2.negative && (n.k2.ineg(), (I = I.neg(!0))), + (i[2 * r] = B), + (i[2 * r + 1] = I), + (g[2 * r] = n.k1), + (g[2 * r + 1] = n.k2); + } + for ( + var o = this._wnafMulAdd(1, i, g, 2 * r, t), a = 0; + a < 2 * r; + a++ + ) + (i[a] = null), (g[a] = null); + return o; + }), + r(o, n.BasePoint), + (I.prototype.point = function (A, e, t) { + return new o(this, A, e, t); + }), + (I.prototype.pointFromJSON = function (A, e) { + return o.fromJSON(this, A, e); + }), + (o.prototype._getBeta = function () { + if (this.curve.endo) { + var A = this.precomputed; + if (A && A.beta) return A.beta; + var e = this.curve.point( + this.x.redMul(this.curve.endo.beta), + this.y + ); + if (A) { + var t = this.curve, + i = function (A) { + return t.point(A.x.redMul(t.endo.beta), A.y); + }; + (A.beta = e), + (e.precomputed = { + beta: null, + naf: A.naf && { + wnd: A.naf.wnd, + points: A.naf.points.map(i), + }, + doubles: A.doubles && { + step: A.doubles.step, + points: A.doubles.points.map(i), + }, + }); + } + return e; + } + }), + (o.prototype.toJSON = function () { + return this.precomputed + ? [ + this.x, + this.y, + this.precomputed && { + doubles: this.precomputed.doubles && { + step: this.precomputed.doubles.step, + points: this.precomputed.doubles.points.slice(1), + }, + naf: this.precomputed.naf && { + wnd: this.precomputed.naf.wnd, + points: this.precomputed.naf.points.slice(1), + }, + }, + ] + : [this.x, this.y]; + }), + (o.fromJSON = function (A, e, t) { + "string" == typeof e && (e = JSON.parse(e)); + var i = A.point(e[0], e[1], t); + if (!e[2]) return i; + function g(e) { + return A.point(e[0], e[1], t); + } + var r = e[2]; + return ( + (i.precomputed = { + beta: null, + doubles: r.doubles && { + step: r.doubles.step, + points: [i].concat(r.doubles.points.map(g)), + }, + naf: r.naf && { + wnd: r.naf.wnd, + points: [i].concat(r.naf.points.map(g)), + }, + }), + i + ); + }), + (o.prototype.inspect = function () { + return this.isInfinity() + ? "" + : ""; + }), + (o.prototype.isInfinity = function () { + return this.inf; + }), + (o.prototype.add = function (A) { + if (this.inf) return A; + if (A.inf) return this; + if (this.eq(A)) return this.dbl(); + if (this.neg().eq(A)) return this.curve.point(null, null); + if (0 === this.x.cmp(A.x)) return this.curve.point(null, null); + var e = this.y.redSub(A.y); + 0 !== e.cmpn(0) && (e = e.redMul(this.x.redSub(A.x).redInvm())); + var t = e.redSqr().redISub(this.x).redISub(A.x), + i = e.redMul(this.x.redSub(t)).redISub(this.y); + return this.curve.point(t, i); + }), + (o.prototype.dbl = function () { + if (this.inf) return this; + var A = this.y.redAdd(this.y); + if (0 === A.cmpn(0)) return this.curve.point(null, null); + var e = this.curve.a, + t = this.x.redSqr(), + i = A.redInvm(), + g = t.redAdd(t).redIAdd(t).redIAdd(e).redMul(i), + r = g.redSqr().redISub(this.x.redAdd(this.x)), + n = g.redMul(this.x.redSub(r)).redISub(this.y); + return this.curve.point(r, n); + }), + (o.prototype.getX = function () { + return this.x.fromRed(); + }), + (o.prototype.getY = function () { + return this.y.fromRed(); + }), + (o.prototype.mul = function (A) { + return ( + (A = new g(A, 16)), + this.isInfinity() + ? this + : this._hasDoubles(A) + ? this.curve._fixedNafMul(this, A) + : this.curve.endo + ? this.curve._endoWnafMulAdd([this], [A]) + : this.curve._wnafMul(this, A) + ); + }), + (o.prototype.mulAdd = function (A, e, t) { + var i = [this, e], + g = [A, t]; + return this.curve.endo + ? this.curve._endoWnafMulAdd(i, g) + : this.curve._wnafMulAdd(1, i, g, 2); + }), + (o.prototype.jmulAdd = function (A, e, t) { + var i = [this, e], + g = [A, t]; + return this.curve.endo + ? this.curve._endoWnafMulAdd(i, g, !0) + : this.curve._wnafMulAdd(1, i, g, 2, !0); + }), + (o.prototype.eq = function (A) { + return ( + this === A || + (this.inf === A.inf && + (this.inf || (0 === this.x.cmp(A.x) && 0 === this.y.cmp(A.y)))) + ); + }), + (o.prototype.neg = function (A) { + if (this.inf) return this; + var e = this.curve.point(this.x, this.y.redNeg()); + if (A && this.precomputed) { + var t = this.precomputed, + i = function (A) { + return A.neg(); + }; + e.precomputed = { + naf: t.naf && { wnd: t.naf.wnd, points: t.naf.points.map(i) }, + doubles: t.doubles && { + step: t.doubles.step, + points: t.doubles.points.map(i), + }, + }; + } + return e; + }), + (o.prototype.toJ = function () { + return this.inf + ? this.curve.jpoint(null, null, null) + : this.curve.jpoint(this.x, this.y, this.curve.one); + }), + r(a, n.BasePoint), + (I.prototype.jpoint = function (A, e, t) { + return new a(this, A, e, t); + }), + (a.prototype.toP = function () { + if (this.isInfinity()) return this.curve.point(null, null); + var A = this.z.redInvm(), + e = A.redSqr(), + t = this.x.redMul(e), + i = this.y.redMul(e).redMul(A); + return this.curve.point(t, i); + }), + (a.prototype.neg = function () { + return this.curve.jpoint(this.x, this.y.redNeg(), this.z); + }), + (a.prototype.add = function (A) { + if (this.isInfinity()) return A; + if (A.isInfinity()) return this; + var e = A.z.redSqr(), + t = this.z.redSqr(), + i = this.x.redMul(e), + g = A.x.redMul(t), + r = this.y.redMul(e.redMul(A.z)), + n = A.y.redMul(t.redMul(this.z)), + B = i.redSub(g), + I = r.redSub(n); + if (0 === B.cmpn(0)) + return 0 !== I.cmpn(0) + ? this.curve.jpoint(null, null, null) + : this.dbl(); + var o = B.redSqr(), + a = o.redMul(B), + Q = i.redMul(o), + C = I.redSqr().redIAdd(a).redISub(Q).redISub(Q), + s = I.redMul(Q.redISub(C)).redISub(r.redMul(a)), + c = this.z.redMul(A.z).redMul(B); + return this.curve.jpoint(C, s, c); + }), + (a.prototype.mixedAdd = function (A) { + if (this.isInfinity()) return A.toJ(); + if (A.isInfinity()) return this; + var e = this.z.redSqr(), + t = this.x, + i = A.x.redMul(e), + g = this.y, + r = A.y.redMul(e).redMul(this.z), + n = t.redSub(i), + B = g.redSub(r); + if (0 === n.cmpn(0)) + return 0 !== B.cmpn(0) + ? this.curve.jpoint(null, null, null) + : this.dbl(); + var I = n.redSqr(), + o = I.redMul(n), + a = t.redMul(I), + Q = B.redSqr().redIAdd(o).redISub(a).redISub(a), + C = B.redMul(a.redISub(Q)).redISub(g.redMul(o)), + s = this.z.redMul(n); + return this.curve.jpoint(Q, C, s); + }), + (a.prototype.dblp = function (A) { + if (0 === A) return this; + if (this.isInfinity()) return this; + if (!A) return this.dbl(); + if (this.curve.zeroA || this.curve.threeA) { + for (var e = this, t = 0; t < A; t++) e = e.dbl(); + return e; + } + var i = this.curve.a, + g = this.curve.tinv, + r = this.x, + n = this.y, + B = this.z, + I = B.redSqr().redSqr(), + o = n.redAdd(n); + for (t = 0; t < A; t++) { + var a = r.redSqr(), + Q = o.redSqr(), + C = Q.redSqr(), + s = a.redAdd(a).redIAdd(a).redIAdd(i.redMul(I)), + c = r.redMul(Q), + h = s.redSqr().redISub(c.redAdd(c)), + f = c.redISub(h), + E = s.redMul(f); + E = E.redIAdd(E).redISub(C); + var u = o.redMul(B); + t + 1 < A && (I = I.redMul(C)), (r = h), (B = u), (o = E); + } + return this.curve.jpoint(r, o.redMul(g), B); + }), + (a.prototype.dbl = function () { + return this.isInfinity() + ? this + : this.curve.zeroA + ? this._zeroDbl() + : this.curve.threeA + ? this._threeDbl() + : this._dbl(); + }), + (a.prototype._zeroDbl = function () { + var A, e, t; + if (this.zOne) { + var i = this.x.redSqr(), + g = this.y.redSqr(), + r = g.redSqr(), + n = this.x.redAdd(g).redSqr().redISub(i).redISub(r); + n = n.redIAdd(n); + var B = i.redAdd(i).redIAdd(i), + I = B.redSqr().redISub(n).redISub(n), + o = r.redIAdd(r); + (o = (o = o.redIAdd(o)).redIAdd(o)), + (A = I), + (e = B.redMul(n.redISub(I)).redISub(o)), + (t = this.y.redAdd(this.y)); + } else { + var a = this.x.redSqr(), + Q = this.y.redSqr(), + C = Q.redSqr(), + s = this.x.redAdd(Q).redSqr().redISub(a).redISub(C); + s = s.redIAdd(s); + var c = a.redAdd(a).redIAdd(a), + h = c.redSqr(), + f = C.redIAdd(C); + (f = (f = f.redIAdd(f)).redIAdd(f)), + (A = h.redISub(s).redISub(s)), + (e = c.redMul(s.redISub(A)).redISub(f)), + (t = (t = this.y.redMul(this.z)).redIAdd(t)); + } + return this.curve.jpoint(A, e, t); + }), + (a.prototype._threeDbl = function () { + var A, e, t; + if (this.zOne) { + var i = this.x.redSqr(), + g = this.y.redSqr(), + r = g.redSqr(), + n = this.x.redAdd(g).redSqr().redISub(i).redISub(r); + n = n.redIAdd(n); + var B = i.redAdd(i).redIAdd(i).redIAdd(this.curve.a), + I = B.redSqr().redISub(n).redISub(n); + A = I; + var o = r.redIAdd(r); + (o = (o = o.redIAdd(o)).redIAdd(o)), + (e = B.redMul(n.redISub(I)).redISub(o)), + (t = this.y.redAdd(this.y)); + } else { + var a = this.z.redSqr(), + Q = this.y.redSqr(), + C = this.x.redMul(Q), + s = this.x.redSub(a).redMul(this.x.redAdd(a)); + s = s.redAdd(s).redIAdd(s); + var c = C.redIAdd(C), + h = (c = c.redIAdd(c)).redAdd(c); + (A = s.redSqr().redISub(h)), + (t = this.y.redAdd(this.z).redSqr().redISub(Q).redISub(a)); + var f = Q.redSqr(); + (f = (f = (f = f.redIAdd(f)).redIAdd(f)).redIAdd(f)), + (e = s.redMul(c.redISub(A)).redISub(f)); + } + return this.curve.jpoint(A, e, t); + }), + (a.prototype._dbl = function () { + var A = this.curve.a, + e = this.x, + t = this.y, + i = this.z, + g = i.redSqr().redSqr(), + r = e.redSqr(), + n = t.redSqr(), + B = r.redAdd(r).redIAdd(r).redIAdd(A.redMul(g)), + I = e.redAdd(e), + o = (I = I.redIAdd(I)).redMul(n), + a = B.redSqr().redISub(o.redAdd(o)), + Q = o.redISub(a), + C = n.redSqr(); + C = (C = (C = C.redIAdd(C)).redIAdd(C)).redIAdd(C); + var s = B.redMul(Q).redISub(C), + c = t.redAdd(t).redMul(i); + return this.curve.jpoint(a, s, c); + }), + (a.prototype.trpl = function () { + if (!this.curve.zeroA) return this.dbl().add(this); + var A = this.x.redSqr(), + e = this.y.redSqr(), + t = this.z.redSqr(), + i = e.redSqr(), + g = A.redAdd(A).redIAdd(A), + r = g.redSqr(), + n = this.x.redAdd(e).redSqr().redISub(A).redISub(i), + B = (n = (n = (n = n.redIAdd(n)).redAdd(n).redIAdd(n)).redISub( + r + )).redSqr(), + I = i.redIAdd(i); + I = (I = (I = I.redIAdd(I)).redIAdd(I)).redIAdd(I); + var o = g.redIAdd(n).redSqr().redISub(r).redISub(B).redISub(I), + a = e.redMul(o); + a = (a = a.redIAdd(a)).redIAdd(a); + var Q = this.x.redMul(B).redISub(a); + Q = (Q = Q.redIAdd(Q)).redIAdd(Q); + var C = this.y.redMul(o.redMul(I.redISub(o)).redISub(n.redMul(B))); + C = (C = (C = C.redIAdd(C)).redIAdd(C)).redIAdd(C); + var s = this.z.redAdd(n).redSqr().redISub(t).redISub(B); + return this.curve.jpoint(Q, C, s); + }), + (a.prototype.mul = function (A, e) { + return (A = new g(A, e)), this.curve._wnafMul(this, A); + }), + (a.prototype.eq = function (A) { + if ("affine" === A.type) return this.eq(A.toJ()); + if (this === A) return !0; + var e = this.z.redSqr(), + t = A.z.redSqr(); + if (0 !== this.x.redMul(t).redISub(A.x.redMul(e)).cmpn(0)) + return !1; + var i = e.redMul(this.z), + g = t.redMul(A.z); + return 0 === this.y.redMul(g).redISub(A.y.redMul(i)).cmpn(0); + }), + (a.prototype.eqXToP = function (A) { + var e = this.z.redSqr(), + t = A.toRed(this.curve.red).redMul(e); + if (0 === this.x.cmp(t)) return !0; + for (var i = A.clone(), g = this.curve.redN.redMul(e); ; ) { + if ((i.iadd(this.curve.n), i.cmp(this.curve.p) >= 0)) return !1; + if ((t.redIAdd(g), 0 === this.x.cmp(t))) return !0; + } + }), + (a.prototype.inspect = function () { + return this.isInfinity() + ? "" + : ""; + }), + (a.prototype.isInfinity = function () { + return 0 === this.z.cmpn(0); + }); + }, + { "../utils": 99, "./base": 86, "bn.js": 100, inherits: 134 }, + ], + 91: [ + function (A, e, t) { + "use strict"; + var i, + g = t, + r = A("hash.js"), + n = A("./curve"), + B = A("./utils").assert; + function I(A) { + "short" === A.type + ? (this.curve = new n.short(A)) + : "edwards" === A.type + ? (this.curve = new n.edwards(A)) + : (this.curve = new n.mont(A)), + (this.g = this.curve.g), + (this.n = this.curve.n), + (this.hash = A.hash), + B(this.g.validate(), "Invalid curve"), + B(this.g.mul(this.n).isInfinity(), "Invalid curve, G*N != O"); + } + function o(A, e) { + Object.defineProperty(g, A, { + configurable: !0, + enumerable: !0, + get: function () { + var t = new I(e); + return ( + Object.defineProperty(g, A, { + configurable: !0, + enumerable: !0, + value: t, + }), + t + ); + }, + }); + } + (g.PresetCurve = I), + o("p192", { + type: "short", + prime: "p192", + p: "ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff", + a: "ffffffff ffffffff ffffffff fffffffe ffffffff fffffffc", + b: "64210519 e59c80e7 0fa7e9ab 72243049 feb8deec c146b9b1", + n: "ffffffff ffffffff ffffffff 99def836 146bc9b1 b4d22831", + hash: r.sha256, + gRed: !1, + g: [ + "188da80e b03090f6 7cbf20eb 43a18800 f4ff0afd 82ff1012", + "07192b95 ffc8da78 631011ed 6b24cdd5 73f977a1 1e794811", + ], + }), + o("p224", { + type: "short", + prime: "p224", + p: "ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001", + a: "ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff fffffffe", + b: "b4050a85 0c04b3ab f5413256 5044b0b7 d7bfd8ba 270b3943 2355ffb4", + n: "ffffffff ffffffff ffffffff ffff16a2 e0b8f03e 13dd2945 5c5c2a3d", + hash: r.sha256, + gRed: !1, + g: [ + "b70e0cbd 6bb4bf7f 321390b9 4a03c1d3 56c21122 343280d6 115c1d21", + "bd376388 b5f723fb 4c22dfe6 cd4375a0 5a074764 44d58199 85007e34", + ], + }), + o("p256", { + type: "short", + prime: null, + p: "ffffffff 00000001 00000000 00000000 00000000 ffffffff ffffffff ffffffff", + a: "ffffffff 00000001 00000000 00000000 00000000 ffffffff ffffffff fffffffc", + b: "5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f6 3bce3c3e 27d2604b", + n: "ffffffff 00000000 ffffffff ffffffff bce6faad a7179e84 f3b9cac2 fc632551", + hash: r.sha256, + gRed: !1, + g: [ + "6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0 f4a13945 d898c296", + "4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ece cbb64068 37bf51f5", + ], + }), + o("p384", { + type: "short", + prime: null, + p: "ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe ffffffff 00000000 00000000 ffffffff", + a: "ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe ffffffff 00000000 00000000 fffffffc", + b: "b3312fa7 e23ee7e4 988e056b e3f82d19 181d9c6e fe814112 0314088f 5013875a c656398d 8a2ed19d 2a85c8ed d3ec2aef", + n: "ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff c7634d81 f4372ddf 581a0db2 48b0a77a ecec196a ccc52973", + hash: r.sha384, + gRed: !1, + g: [ + "aa87ca22 be8b0537 8eb1c71e f320ad74 6e1d3b62 8ba79b98 59f741e0 82542a38 5502f25d bf55296c 3a545e38 72760ab7", + "3617de4a 96262c6f 5d9e98bf 9292dc29 f8f41dbd 289a147c e9da3113 b5f0b8c0 0a60b1ce 1d7e819d 7a431d7c 90ea0e5f", + ], + }), + o("p521", { + type: "short", + prime: null, + p: "000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff", + a: "000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffc", + b: "00000051 953eb961 8e1c9a1f 929a21a0 b68540ee a2da725b 99b315f3 b8b48991 8ef109e1 56193951 ec7e937b 1652c0bd 3bb1bf07 3573df88 3d2c34f1 ef451fd4 6b503f00", + n: "000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffa 51868783 bf2f966b 7fcc0148 f709a5d0 3bb5c9b8 899c47ae bb6fb71e 91386409", + hash: r.sha512, + gRed: !1, + g: [ + "000000c6 858e06b7 0404e9cd 9e3ecb66 2395b442 9c648139 053fb521 f828af60 6b4d3dba a14b5e77 efe75928 fe1dc127 a2ffa8de 3348b3c1 856a429b f97e7e31 c2e5bd66", + "00000118 39296a78 9a3bc004 5c8a5fb4 2c7d1bd9 98f54449 579b4468 17afbd17 273e662c 97ee7299 5ef42640 c550b901 3fad0761 353c7086 a272c240 88be9476 9fd16650", + ], + }), + o("curve25519", { + type: "mont", + prime: "p25519", + p: "7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed", + a: "76d06", + b: "1", + n: "1000000000000000 0000000000000000 14def9dea2f79cd6 5812631a5cf5d3ed", + hash: r.sha256, + gRed: !1, + g: ["9"], + }), + o("ed25519", { + type: "edwards", + prime: "p25519", + p: "7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed", + a: "-1", + c: "1", + d: "52036cee2b6ffe73 8cc740797779e898 00700a4d4141d8ab 75eb4dca135978a3", + n: "1000000000000000 0000000000000000 14def9dea2f79cd6 5812631a5cf5d3ed", + hash: r.sha256, + gRed: !1, + g: [ + "216936d3cd6e53fec0a4e231fdd6dc5c692cc7609525a7b2c9562d608f25d51a", + "6666666666666666666666666666666666666666666666666666666666666658", + ], + }); + try { + i = A("./precomputed/secp256k1"); + } catch (A) { + i = void 0; + } + o("secp256k1", { + type: "short", + prime: "k256", + p: "ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f", + a: "0", + b: "7", + n: "ffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141", + h: "1", + hash: r.sha256, + beta: "7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee", + lambda: + "5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72", + basis: [ + { + a: "3086d221a7d46bcde86c90e49284eb15", + b: "-e4437ed6010e88286f547fa90abfe4c3", + }, + { + a: "114ca50f7a8e2f3f657c1108d9d44cfd8", + b: "3086d221a7d46bcde86c90e49284eb15", + }, + ], + gRed: !1, + g: [ + "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798", + "483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8", + i, + ], + }); + }, + { + "./curve": 88, + "./precomputed/secp256k1": 98, + "./utils": 99, + "hash.js": 120, + }, + ], + 92: [ + function (A, e, t) { + "use strict"; + var i = A("bn.js"), + g = A("hmac-drbg"), + r = A("../utils"), + n = A("../curves"), + B = A("brorand"), + I = r.assert, + o = A("./key"), + a = A("./signature"); + function Q(A) { + if (!(this instanceof Q)) return new Q(A); + "string" == typeof A && + (I(n.hasOwnProperty(A), "Unknown curve " + A), (A = n[A])), + A instanceof n.PresetCurve && (A = { curve: A }), + (this.curve = A.curve.curve), + (this.n = this.curve.n), + (this.nh = this.n.ushrn(1)), + (this.g = this.curve.g), + (this.g = A.curve.g), + this.g.precompute(A.curve.n.bitLength() + 1), + (this.hash = A.hash || A.curve.hash); + } + (e.exports = Q), + (Q.prototype.keyPair = function (A) { + return new o(this, A); + }), + (Q.prototype.keyFromPrivate = function (A, e) { + return o.fromPrivate(this, A, e); + }), + (Q.prototype.keyFromPublic = function (A, e) { + return o.fromPublic(this, A, e); + }), + (Q.prototype.genKeyPair = function (A) { + A || (A = {}); + for ( + var e = new g({ + hash: this.hash, + pers: A.pers, + persEnc: A.persEnc || "utf8", + entropy: A.entropy || B(this.hash.hmacStrength), + entropyEnc: (A.entropy && A.entropyEnc) || "utf8", + nonce: this.n.toArray(), + }), + t = this.n.byteLength(), + r = this.n.sub(new i(2)); + ; + + ) { + var n = new i(e.generate(t)); + if (!(n.cmp(r) > 0)) return n.iaddn(1), this.keyFromPrivate(n); + } + }), + (Q.prototype._truncateToN = function (A, e) { + var t = 8 * A.byteLength() - this.n.bitLength(); + return ( + t > 0 && (A = A.ushrn(t)), + !e && A.cmp(this.n) >= 0 ? A.sub(this.n) : A + ); + }), + (Q.prototype.sign = function (A, e, t, r) { + "object" == typeof t && ((r = t), (t = null)), + r || (r = {}), + (e = this.keyFromPrivate(e, t)), + (A = this._truncateToN(new i(A, 16))); + for ( + var n = this.n.byteLength(), + B = e.getPrivate().toArray("be", n), + I = A.toArray("be", n), + o = new g({ + hash: this.hash, + entropy: B, + nonce: I, + pers: r.pers, + persEnc: r.persEnc || "utf8", + }), + Q = this.n.sub(new i(1)), + C = 0; + ; + C++ + ) { + var s = r.k ? r.k(C) : new i(o.generate(this.n.byteLength())); + if ( + !((s = this._truncateToN(s, !0)).cmpn(1) <= 0 || s.cmp(Q) >= 0) + ) { + var c = this.g.mul(s); + if (!c.isInfinity()) { + var h = c.getX(), + f = h.umod(this.n); + if (0 !== f.cmpn(0)) { + var E = s.invm(this.n).mul(f.mul(e.getPrivate()).iadd(A)); + if (0 !== (E = E.umod(this.n)).cmpn(0)) { + var u = + (c.getY().isOdd() ? 1 : 0) | (0 !== h.cmp(f) ? 2 : 0); + return ( + r.canonical && + E.cmp(this.nh) > 0 && + ((E = this.n.sub(E)), (u ^= 1)), + new a({ r: f, s: E, recoveryParam: u }) + ); + } + } + } + } + } + }), + (Q.prototype.verify = function (A, e, t, g) { + (A = this._truncateToN(new i(A, 16))), + (t = this.keyFromPublic(t, g)); + var r = (e = new a(e, "hex")).r, + n = e.s; + if (r.cmpn(1) < 0 || r.cmp(this.n) >= 0) return !1; + if (n.cmpn(1) < 0 || n.cmp(this.n) >= 0) return !1; + var B, + I = n.invm(this.n), + o = I.mul(A).umod(this.n), + Q = I.mul(r).umod(this.n); + return this.curve._maxwellTrick + ? !(B = this.g.jmulAdd(o, t.getPublic(), Q)).isInfinity() && + B.eqXToP(r) + : !(B = this.g.mulAdd(o, t.getPublic(), Q)).isInfinity() && + 0 === B.getX().umod(this.n).cmp(r); + }), + (Q.prototype.recoverPubKey = function (A, e, t, g) { + I((3 & t) === t, "The recovery param is more than two bits"), + (e = new a(e, g)); + var r = this.n, + n = new i(A), + B = e.r, + o = e.s, + Q = 1 & t, + C = t >> 1; + if (B.cmp(this.curve.p.umod(this.curve.n)) >= 0 && C) + throw new Error("Unable to find sencond key candinate"); + B = C + ? this.curve.pointFromX(B.add(this.curve.n), Q) + : this.curve.pointFromX(B, Q); + var s = e.r.invm(r), + c = r.sub(n).mul(s).umod(r), + h = o.mul(s).umod(r); + return this.g.mulAdd(c, B, h); + }), + (Q.prototype.getKeyRecoveryParam = function (A, e, t, i) { + if (null !== (e = new a(e, i)).recoveryParam) + return e.recoveryParam; + for (var g = 0; g < 4; g++) { + var r; + try { + r = this.recoverPubKey(A, e, g); + } catch (A) { + continue; + } + if (r.eq(t)) return g; + } + throw new Error("Unable to find valid recovery factor"); + }); + }, + { + "../curves": 91, + "../utils": 99, + "./key": 93, + "./signature": 94, + "bn.js": 100, + brorand: 18, + "hmac-drbg": 132, + }, + ], + 93: [ + function (A, e, t) { + "use strict"; + var i = A("bn.js"), + g = A("../utils").assert; + function r(A, e) { + (this.ec = A), + (this.priv = null), + (this.pub = null), + e.priv && this._importPrivate(e.priv, e.privEnc), + e.pub && this._importPublic(e.pub, e.pubEnc); + } + (e.exports = r), + (r.fromPublic = function (A, e, t) { + return e instanceof r ? e : new r(A, { pub: e, pubEnc: t }); + }), + (r.fromPrivate = function (A, e, t) { + return e instanceof r ? e : new r(A, { priv: e, privEnc: t }); + }), + (r.prototype.validate = function () { + var A = this.getPublic(); + return A.isInfinity() + ? { result: !1, reason: "Invalid public key" } + : A.validate() + ? A.mul(this.ec.curve.n).isInfinity() + ? { result: !0, reason: null } + : { result: !1, reason: "Public key * N != O" } + : { result: !1, reason: "Public key is not a point" }; + }), + (r.prototype.getPublic = function (A, e) { + return ( + "string" == typeof A && ((e = A), (A = null)), + this.pub || (this.pub = this.ec.g.mul(this.priv)), + e ? this.pub.encode(e, A) : this.pub + ); + }), + (r.prototype.getPrivate = function (A) { + return "hex" === A ? this.priv.toString(16, 2) : this.priv; + }), + (r.prototype._importPrivate = function (A, e) { + (this.priv = new i(A, e || 16)), + (this.priv = this.priv.umod(this.ec.curve.n)); + }), + (r.prototype._importPublic = function (A, e) { + if (A.x || A.y) + return ( + "mont" === this.ec.curve.type + ? g(A.x, "Need x coordinate") + : ("short" !== this.ec.curve.type && + "edwards" !== this.ec.curve.type) || + g(A.x && A.y, "Need both x and y coordinate"), + void (this.pub = this.ec.curve.point(A.x, A.y)) + ); + this.pub = this.ec.curve.decodePoint(A, e); + }), + (r.prototype.derive = function (A) { + return A.mul(this.priv).getX(); + }), + (r.prototype.sign = function (A, e, t) { + return this.ec.sign(A, this, e, t); + }), + (r.prototype.verify = function (A, e) { + return this.ec.verify(A, e, this); + }), + (r.prototype.inspect = function () { + return ( + "" + ); + }); + }, + { "../utils": 99, "bn.js": 100 }, + ], + 94: [ + function (A, e, t) { + "use strict"; + var i = A("bn.js"), + g = A("../utils"), + r = g.assert; + function n(A, e) { + if (A instanceof n) return A; + this._importDER(A, e) || + (r(A.r && A.s, "Signature without r or s"), + (this.r = new i(A.r, 16)), + (this.s = new i(A.s, 16)), + void 0 === A.recoveryParam + ? (this.recoveryParam = null) + : (this.recoveryParam = A.recoveryParam)); + } + function B(A, e) { + var t = A[e.place++]; + if (!(128 & t)) return t; + var i = 15 & t; + if (0 === i || i > 4) return !1; + for (var g = 0, r = 0, n = e.place; r < i; r++, n++) + (g <<= 8), (g |= A[n]), (g >>>= 0); + return !(g <= 127) && ((e.place = n), g); + } + function I(A) { + for ( + var e = 0, t = A.length - 1; + !A[e] && !(128 & A[e + 1]) && e < t; + + ) + e++; + return 0 === e ? A : A.slice(e); + } + function o(A, e) { + if (e < 128) A.push(e); + else { + var t = 1 + ((Math.log(e) / Math.LN2) >>> 3); + for (A.push(128 | t); --t; ) A.push((e >>> (t << 3)) & 255); + A.push(e); + } + } + (e.exports = n), + (n.prototype._importDER = function (A, e) { + A = g.toArray(A, e); + var t = new (function () { + this.place = 0; + })(); + if (48 !== A[t.place++]) return !1; + var r = B(A, t); + if (!1 === r) return !1; + if (r + t.place !== A.length) return !1; + if (2 !== A[t.place++]) return !1; + var n = B(A, t); + if (!1 === n) return !1; + var I = A.slice(t.place, n + t.place); + if (((t.place += n), 2 !== A[t.place++])) return !1; + var o = B(A, t); + if (!1 === o) return !1; + if (A.length !== o + t.place) return !1; + var a = A.slice(t.place, o + t.place); + if (0 === I[0]) { + if (!(128 & I[1])) return !1; + I = I.slice(1); + } + if (0 === a[0]) { + if (!(128 & a[1])) return !1; + a = a.slice(1); + } + return ( + (this.r = new i(I)), + (this.s = new i(a)), + (this.recoveryParam = null), + !0 + ); + }), + (n.prototype.toDER = function (A) { + var e = this.r.toArray(), + t = this.s.toArray(); + for ( + 128 & e[0] && (e = [0].concat(e)), + 128 & t[0] && (t = [0].concat(t)), + e = I(e), + t = I(t); + !(t[0] || 128 & t[1]); + + ) + t = t.slice(1); + var i = [2]; + o(i, e.length), (i = i.concat(e)).push(2), o(i, t.length); + var r = i.concat(t), + n = [48]; + return o(n, r.length), (n = n.concat(r)), g.encode(n, A); + }); + }, + { "../utils": 99, "bn.js": 100 }, + ], + 95: [ + function (A, e, t) { + "use strict"; + var i = A("hash.js"), + g = A("../curves"), + r = A("../utils"), + n = r.assert, + B = r.parseBytes, + I = A("./key"), + o = A("./signature"); + function a(A) { + if ( + (n("ed25519" === A, "only tested with ed25519 so far"), + !(this instanceof a)) + ) + return new a(A); + A = g[A].curve; + (this.curve = A), + (this.g = A.g), + this.g.precompute(A.n.bitLength() + 1), + (this.pointClass = A.point().constructor), + (this.encodingLength = Math.ceil(A.n.bitLength() / 8)), + (this.hash = i.sha512); + } + (e.exports = a), + (a.prototype.sign = function (A, e) { + A = B(A); + var t = this.keyFromSecret(e), + i = this.hashInt(t.messagePrefix(), A), + g = this.g.mul(i), + r = this.encodePoint(g), + n = this.hashInt(r, t.pubBytes(), A).mul(t.priv()), + I = i.add(n).umod(this.curve.n); + return this.makeSignature({ R: g, S: I, Rencoded: r }); + }), + (a.prototype.verify = function (A, e, t) { + (A = B(A)), (e = this.makeSignature(e)); + var i = this.keyFromPublic(t), + g = this.hashInt(e.Rencoded(), i.pubBytes(), A), + r = this.g.mul(e.S()); + return e.R().add(i.pub().mul(g)).eq(r); + }), + (a.prototype.hashInt = function () { + for (var A = this.hash(), e = 0; e < arguments.length; e++) + A.update(arguments[e]); + return r.intFromLE(A.digest()).umod(this.curve.n); + }), + (a.prototype.keyFromPublic = function (A) { + return I.fromPublic(this, A); + }), + (a.prototype.keyFromSecret = function (A) { + return I.fromSecret(this, A); + }), + (a.prototype.makeSignature = function (A) { + return A instanceof o ? A : new o(this, A); + }), + (a.prototype.encodePoint = function (A) { + var e = A.getY().toArray("le", this.encodingLength); + return ( + (e[this.encodingLength - 1] |= A.getX().isOdd() ? 128 : 0), e + ); + }), + (a.prototype.decodePoint = function (A) { + var e = (A = r.parseBytes(A)).length - 1, + t = A.slice(0, e).concat(-129 & A[e]), + i = 0 != (128 & A[e]), + g = r.intFromLE(t); + return this.curve.pointFromY(g, i); + }), + (a.prototype.encodeInt = function (A) { + return A.toArray("le", this.encodingLength); + }), + (a.prototype.decodeInt = function (A) { + return r.intFromLE(A); + }), + (a.prototype.isPoint = function (A) { + return A instanceof this.pointClass; + }); + }, + { + "../curves": 91, + "../utils": 99, + "./key": 96, + "./signature": 97, + "hash.js": 120, + }, + ], + 96: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = i.assert, + r = i.parseBytes, + n = i.cachedProperty; + function B(A, e) { + (this.eddsa = A), + (this._secret = r(e.secret)), + A.isPoint(e.pub) + ? (this._pub = e.pub) + : (this._pubBytes = r(e.pub)); + } + (B.fromPublic = function (A, e) { + return e instanceof B ? e : new B(A, { pub: e }); + }), + (B.fromSecret = function (A, e) { + return e instanceof B ? e : new B(A, { secret: e }); + }), + (B.prototype.secret = function () { + return this._secret; + }), + n(B, "pubBytes", function () { + return this.eddsa.encodePoint(this.pub()); + }), + n(B, "pub", function () { + return this._pubBytes + ? this.eddsa.decodePoint(this._pubBytes) + : this.eddsa.g.mul(this.priv()); + }), + n(B, "privBytes", function () { + var A = this.eddsa, + e = this.hash(), + t = A.encodingLength - 1, + i = e.slice(0, A.encodingLength); + return (i[0] &= 248), (i[t] &= 127), (i[t] |= 64), i; + }), + n(B, "priv", function () { + return this.eddsa.decodeInt(this.privBytes()); + }), + n(B, "hash", function () { + return this.eddsa.hash().update(this.secret()).digest(); + }), + n(B, "messagePrefix", function () { + return this.hash().slice(this.eddsa.encodingLength); + }), + (B.prototype.sign = function (A) { + return ( + g(this._secret, "KeyPair can only verify"), + this.eddsa.sign(A, this) + ); + }), + (B.prototype.verify = function (A, e) { + return this.eddsa.verify(A, e, this); + }), + (B.prototype.getSecret = function (A) { + return ( + g(this._secret, "KeyPair is public only"), + i.encode(this.secret(), A) + ); + }), + (B.prototype.getPublic = function (A) { + return i.encode(this.pubBytes(), A); + }), + (e.exports = B); + }, + { "../utils": 99 }, + ], + 97: [ + function (A, e, t) { + "use strict"; + var i = A("bn.js"), + g = A("../utils"), + r = g.assert, + n = g.cachedProperty, + B = g.parseBytes; + function I(A, e) { + (this.eddsa = A), + "object" != typeof e && (e = B(e)), + Array.isArray(e) && + (e = { + R: e.slice(0, A.encodingLength), + S: e.slice(A.encodingLength), + }), + r(e.R && e.S, "Signature without R or S"), + A.isPoint(e.R) && (this._R = e.R), + e.S instanceof i && (this._S = e.S), + (this._Rencoded = Array.isArray(e.R) ? e.R : e.Rencoded), + (this._Sencoded = Array.isArray(e.S) ? e.S : e.Sencoded); + } + n(I, "S", function () { + return this.eddsa.decodeInt(this.Sencoded()); + }), + n(I, "R", function () { + return this.eddsa.decodePoint(this.Rencoded()); + }), + n(I, "Rencoded", function () { + return this.eddsa.encodePoint(this.R()); + }), + n(I, "Sencoded", function () { + return this.eddsa.encodeInt(this.S()); + }), + (I.prototype.toBytes = function () { + return this.Rencoded().concat(this.Sencoded()); + }), + (I.prototype.toHex = function () { + return g.encode(this.toBytes(), "hex").toUpperCase(); + }), + (e.exports = I); + }, + { "../utils": 99, "bn.js": 100 }, + ], + 98: [ + function (A, e, t) { + e.exports = { + doubles: { + step: 4, + points: [ + [ + "e60fce93b59e9ec53011aabc21c23e97b2a31369b87a5ae9c44ee89e2a6dec0a", + "f7e3507399e595929db99f34f57937101296891e44d23f0be1f32cce69616821", + ], + [ + "8282263212c609d9ea2a6e3e172de238d8c39cabd5ac1ca10646e23fd5f51508", + "11f8a8098557dfe45e8256e830b60ace62d613ac2f7b17bed31b6eaff6e26caf", + ], + [ + "175e159f728b865a72f99cc6c6fc846de0b93833fd2222ed73fce5b551e5b739", + "d3506e0d9e3c79eba4ef97a51ff71f5eacb5955add24345c6efa6ffee9fed695", + ], + [ + "363d90d447b00c9c99ceac05b6262ee053441c7e55552ffe526bad8f83ff4640", + "4e273adfc732221953b445397f3363145b9a89008199ecb62003c7f3bee9de9", + ], + [ + "8b4b5f165df3c2be8c6244b5b745638843e4a781a15bcd1b69f79a55dffdf80c", + "4aad0a6f68d308b4b3fbd7813ab0da04f9e336546162ee56b3eff0c65fd4fd36", + ], + [ + "723cbaa6e5db996d6bf771c00bd548c7b700dbffa6c0e77bcb6115925232fcda", + "96e867b5595cc498a921137488824d6e2660a0653779494801dc069d9eb39f5f", + ], + [ + "eebfa4d493bebf98ba5feec812c2d3b50947961237a919839a533eca0e7dd7fa", + "5d9a8ca3970ef0f269ee7edaf178089d9ae4cdc3a711f712ddfd4fdae1de8999", + ], + [ + "100f44da696e71672791d0a09b7bde459f1215a29b3c03bfefd7835b39a48db0", + "cdd9e13192a00b772ec8f3300c090666b7ff4a18ff5195ac0fbd5cd62bc65a09", + ], + [ + "e1031be262c7ed1b1dc9227a4a04c017a77f8d4464f3b3852c8acde6e534fd2d", + "9d7061928940405e6bb6a4176597535af292dd419e1ced79a44f18f29456a00d", + ], + [ + "feea6cae46d55b530ac2839f143bd7ec5cf8b266a41d6af52d5e688d9094696d", + "e57c6b6c97dce1bab06e4e12bf3ecd5c981c8957cc41442d3155debf18090088", + ], + [ + "da67a91d91049cdcb367be4be6ffca3cfeed657d808583de33fa978bc1ec6cb1", + "9bacaa35481642bc41f463f7ec9780e5dec7adc508f740a17e9ea8e27a68be1d", + ], + [ + "53904faa0b334cdda6e000935ef22151ec08d0f7bb11069f57545ccc1a37b7c0", + "5bc087d0bc80106d88c9eccac20d3c1c13999981e14434699dcb096b022771c8", + ], + [ + "8e7bcd0bd35983a7719cca7764ca906779b53a043a9b8bcaeff959f43ad86047", + "10b7770b2a3da4b3940310420ca9514579e88e2e47fd68b3ea10047e8460372a", + ], + [ + "385eed34c1cdff21e6d0818689b81bde71a7f4f18397e6690a841e1599c43862", + "283bebc3e8ea23f56701de19e9ebf4576b304eec2086dc8cc0458fe5542e5453", + ], + [ + "6f9d9b803ecf191637c73a4413dfa180fddf84a5947fbc9c606ed86c3fac3a7", + "7c80c68e603059ba69b8e2a30e45c4d47ea4dd2f5c281002d86890603a842160", + ], + [ + "3322d401243c4e2582a2147c104d6ecbf774d163db0f5e5313b7e0e742d0e6bd", + "56e70797e9664ef5bfb019bc4ddaf9b72805f63ea2873af624f3a2e96c28b2a0", + ], + [ + "85672c7d2de0b7da2bd1770d89665868741b3f9af7643397721d74d28134ab83", + "7c481b9b5b43b2eb6374049bfa62c2e5e77f17fcc5298f44c8e3094f790313a6", + ], + [ + "948bf809b1988a46b06c9f1919413b10f9226c60f668832ffd959af60c82a0a", + "53a562856dcb6646dc6b74c5d1c3418c6d4dff08c97cd2bed4cb7f88d8c8e589", + ], + [ + "6260ce7f461801c34f067ce0f02873a8f1b0e44dfc69752accecd819f38fd8e8", + "bc2da82b6fa5b571a7f09049776a1ef7ecd292238051c198c1a84e95b2b4ae17", + ], + [ + "e5037de0afc1d8d43d8348414bbf4103043ec8f575bfdc432953cc8d2037fa2d", + "4571534baa94d3b5f9f98d09fb990bddbd5f5b03ec481f10e0e5dc841d755bda", + ], + [ + "e06372b0f4a207adf5ea905e8f1771b4e7e8dbd1c6a6c5b725866a0ae4fce725", + "7a908974bce18cfe12a27bb2ad5a488cd7484a7787104870b27034f94eee31dd", + ], + [ + "213c7a715cd5d45358d0bbf9dc0ce02204b10bdde2a3f58540ad6908d0559754", + "4b6dad0b5ae462507013ad06245ba190bb4850f5f36a7eeddff2c27534b458f2", + ], + [ + "4e7c272a7af4b34e8dbb9352a5419a87e2838c70adc62cddf0cc3a3b08fbd53c", + "17749c766c9d0b18e16fd09f6def681b530b9614bff7dd33e0b3941817dcaae6", + ], + [ + "fea74e3dbe778b1b10f238ad61686aa5c76e3db2be43057632427e2840fb27b6", + "6e0568db9b0b13297cf674deccb6af93126b596b973f7b77701d3db7f23cb96f", + ], + [ + "76e64113f677cf0e10a2570d599968d31544e179b760432952c02a4417bdde39", + "c90ddf8dee4e95cf577066d70681f0d35e2a33d2b56d2032b4b1752d1901ac01", + ], + [ + "c738c56b03b2abe1e8281baa743f8f9a8f7cc643df26cbee3ab150242bcbb891", + "893fb578951ad2537f718f2eacbfbbbb82314eef7880cfe917e735d9699a84c3", + ], + [ + "d895626548b65b81e264c7637c972877d1d72e5f3a925014372e9f6588f6c14b", + "febfaa38f2bc7eae728ec60818c340eb03428d632bb067e179363ed75d7d991f", + ], + [ + "b8da94032a957518eb0f6433571e8761ceffc73693e84edd49150a564f676e03", + "2804dfa44805a1e4d7c99cc9762808b092cc584d95ff3b511488e4e74efdf6e7", + ], + [ + "e80fea14441fb33a7d8adab9475d7fab2019effb5156a792f1a11778e3c0df5d", + "eed1de7f638e00771e89768ca3ca94472d155e80af322ea9fcb4291b6ac9ec78", + ], + [ + "a301697bdfcd704313ba48e51d567543f2a182031efd6915ddc07bbcc4e16070", + "7370f91cfb67e4f5081809fa25d40f9b1735dbf7c0a11a130c0d1a041e177ea1", + ], + [ + "90ad85b389d6b936463f9d0512678de208cc330b11307fffab7ac63e3fb04ed4", + "e507a3620a38261affdcbd9427222b839aefabe1582894d991d4d48cb6ef150", + ], + [ + "8f68b9d2f63b5f339239c1ad981f162ee88c5678723ea3351b7b444c9ec4c0da", + "662a9f2dba063986de1d90c2b6be215dbbea2cfe95510bfdf23cbf79501fff82", + ], + [ + "e4f3fb0176af85d65ff99ff9198c36091f48e86503681e3e6686fd5053231e11", + "1e63633ad0ef4f1c1661a6d0ea02b7286cc7e74ec951d1c9822c38576feb73bc", + ], + [ + "8c00fa9b18ebf331eb961537a45a4266c7034f2f0d4e1d0716fb6eae20eae29e", + "efa47267fea521a1a9dc343a3736c974c2fadafa81e36c54e7d2a4c66702414b", + ], + [ + "e7a26ce69dd4829f3e10cec0a9e98ed3143d084f308b92c0997fddfc60cb3e41", + "2a758e300fa7984b471b006a1aafbb18d0a6b2c0420e83e20e8a9421cf2cfd51", + ], + [ + "b6459e0ee3662ec8d23540c223bcbdc571cbcb967d79424f3cf29eb3de6b80ef", + "67c876d06f3e06de1dadf16e5661db3c4b3ae6d48e35b2ff30bf0b61a71ba45", + ], + [ + "d68a80c8280bb840793234aa118f06231d6f1fc67e73c5a5deda0f5b496943e8", + "db8ba9fff4b586d00c4b1f9177b0e28b5b0e7b8f7845295a294c84266b133120", + ], + [ + "324aed7df65c804252dc0270907a30b09612aeb973449cea4095980fc28d3d5d", + "648a365774b61f2ff130c0c35aec1f4f19213b0c7e332843967224af96ab7c84", + ], + [ + "4df9c14919cde61f6d51dfdbe5fee5dceec4143ba8d1ca888e8bd373fd054c96", + "35ec51092d8728050974c23a1d85d4b5d506cdc288490192ebac06cad10d5d", + ], + [ + "9c3919a84a474870faed8a9c1cc66021523489054d7f0308cbfc99c8ac1f98cd", + "ddb84f0f4a4ddd57584f044bf260e641905326f76c64c8e6be7e5e03d4fc599d", + ], + [ + "6057170b1dd12fdf8de05f281d8e06bb91e1493a8b91d4cc5a21382120a959e5", + "9a1af0b26a6a4807add9a2daf71df262465152bc3ee24c65e899be932385a2a8", + ], + [ + "a576df8e23a08411421439a4518da31880cef0fba7d4df12b1a6973eecb94266", + "40a6bf20e76640b2c92b97afe58cd82c432e10a7f514d9f3ee8be11ae1b28ec8", + ], + [ + "7778a78c28dec3e30a05fe9629de8c38bb30d1f5cf9a3a208f763889be58ad71", + "34626d9ab5a5b22ff7098e12f2ff580087b38411ff24ac563b513fc1fd9f43ac", + ], + [ + "928955ee637a84463729fd30e7afd2ed5f96274e5ad7e5cb09eda9c06d903ac", + "c25621003d3f42a827b78a13093a95eeac3d26efa8a8d83fc5180e935bcd091f", + ], + [ + "85d0fef3ec6db109399064f3a0e3b2855645b4a907ad354527aae75163d82751", + "1f03648413a38c0be29d496e582cf5663e8751e96877331582c237a24eb1f962", + ], + [ + "ff2b0dce97eece97c1c9b6041798b85dfdfb6d8882da20308f5404824526087e", + "493d13fef524ba188af4c4dc54d07936c7b7ed6fb90e2ceb2c951e01f0c29907", + ], + [ + "827fbbe4b1e880ea9ed2b2e6301b212b57f1ee148cd6dd28780e5e2cf856e241", + "c60f9c923c727b0b71bef2c67d1d12687ff7a63186903166d605b68baec293ec", + ], + [ + "eaa649f21f51bdbae7be4ae34ce6e5217a58fdce7f47f9aa7f3b58fa2120e2b3", + "be3279ed5bbbb03ac69a80f89879aa5a01a6b965f13f7e59d47a5305ba5ad93d", + ], + [ + "e4a42d43c5cf169d9391df6decf42ee541b6d8f0c9a137401e23632dda34d24f", + "4d9f92e716d1c73526fc99ccfb8ad34ce886eedfa8d8e4f13a7f7131deba9414", + ], + [ + "1ec80fef360cbdd954160fadab352b6b92b53576a88fea4947173b9d4300bf19", + "aeefe93756b5340d2f3a4958a7abbf5e0146e77f6295a07b671cdc1cc107cefd", + ], + [ + "146a778c04670c2f91b00af4680dfa8bce3490717d58ba889ddb5928366642be", + "b318e0ec3354028add669827f9d4b2870aaa971d2f7e5ed1d0b297483d83efd0", + ], + [ + "fa50c0f61d22e5f07e3acebb1aa07b128d0012209a28b9776d76a8793180eef9", + "6b84c6922397eba9b72cd2872281a68a5e683293a57a213b38cd8d7d3f4f2811", + ], + [ + "da1d61d0ca721a11b1a5bf6b7d88e8421a288ab5d5bba5220e53d32b5f067ec2", + "8157f55a7c99306c79c0766161c91e2966a73899d279b48a655fba0f1ad836f1", + ], + [ + "a8e282ff0c9706907215ff98e8fd416615311de0446f1e062a73b0610d064e13", + "7f97355b8db81c09abfb7f3c5b2515888b679a3e50dd6bd6cef7c73111f4cc0c", + ], + [ + "174a53b9c9a285872d39e56e6913cab15d59b1fa512508c022f382de8319497c", + "ccc9dc37abfc9c1657b4155f2c47f9e6646b3a1d8cb9854383da13ac079afa73", + ], + [ + "959396981943785c3d3e57edf5018cdbe039e730e4918b3d884fdff09475b7ba", + "2e7e552888c331dd8ba0386a4b9cd6849c653f64c8709385e9b8abf87524f2fd", + ], + [ + "d2a63a50ae401e56d645a1153b109a8fcca0a43d561fba2dbb51340c9d82b151", + "e82d86fb6443fcb7565aee58b2948220a70f750af484ca52d4142174dcf89405", + ], + [ + "64587e2335471eb890ee7896d7cfdc866bacbdbd3839317b3436f9b45617e073", + "d99fcdd5bf6902e2ae96dd6447c299a185b90a39133aeab358299e5e9faf6589", + ], + [ + "8481bde0e4e4d885b3a546d3e549de042f0aa6cea250e7fd358d6c86dd45e458", + "38ee7b8cba5404dd84a25bf39cecb2ca900a79c42b262e556d64b1b59779057e", + ], + [ + "13464a57a78102aa62b6979ae817f4637ffcfed3c4b1ce30bcd6303f6caf666b", + "69be159004614580ef7e433453ccb0ca48f300a81d0942e13f495a907f6ecc27", + ], + [ + "bc4a9df5b713fe2e9aef430bcc1dc97a0cd9ccede2f28588cada3a0d2d83f366", + "d3a81ca6e785c06383937adf4b798caa6e8a9fbfa547b16d758d666581f33c1", + ], + [ + "8c28a97bf8298bc0d23d8c749452a32e694b65e30a9472a3954ab30fe5324caa", + "40a30463a3305193378fedf31f7cc0eb7ae784f0451cb9459e71dc73cbef9482", + ], + [ + "8ea9666139527a8c1dd94ce4f071fd23c8b350c5a4bb33748c4ba111faccae0", + "620efabbc8ee2782e24e7c0cfb95c5d735b783be9cf0f8e955af34a30e62b945", + ], + [ + "dd3625faef5ba06074669716bbd3788d89bdde815959968092f76cc4eb9a9787", + "7a188fa3520e30d461da2501045731ca941461982883395937f68d00c644a573", + ], + [ + "f710d79d9eb962297e4f6232b40e8f7feb2bc63814614d692c12de752408221e", + "ea98e67232d3b3295d3b535532115ccac8612c721851617526ae47a9c77bfc82", + ], + ], + }, + naf: { + wnd: 7, + points: [ + [ + "f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9", + "388f7b0f632de8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672", + ], + [ + "2f8bde4d1a07209355b4a7250a5c5128e88b84bddc619ab7cba8d569b240efe4", + "d8ac222636e5e3d6d4dba9dda6c9c426f788271bab0d6840dca87d3aa6ac62d6", + ], + [ + "5cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc", + "6aebca40ba255960a3178d6d861a54dba813d0b813fde7b5a5082628087264da", + ], + [ + "acd484e2f0c7f65309ad178a9f559abde09796974c57e714c35f110dfc27ccbe", + "cc338921b0a7d9fd64380971763b61e9add888a4375f8e0f05cc262ac64f9c37", + ], + [ + "774ae7f858a9411e5ef4246b70c65aac5649980be5c17891bbec17895da008cb", + "d984a032eb6b5e190243dd56d7b7b365372db1e2dff9d6a8301d74c9c953c61b", + ], + [ + "f28773c2d975288bc7d1d205c3748651b075fbc6610e58cddeeddf8f19405aa8", + "ab0902e8d880a89758212eb65cdaf473a1a06da521fa91f29b5cb52db03ed81", + ], + [ + "d7924d4f7d43ea965a465ae3095ff41131e5946f3c85f79e44adbcf8e27e080e", + "581e2872a86c72a683842ec228cc6defea40af2bd896d3a5c504dc9ff6a26b58", + ], + [ + "defdea4cdb677750a420fee807eacf21eb9898ae79b9768766e4faa04a2d4a34", + "4211ab0694635168e997b0ead2a93daeced1f4a04a95c0f6cfb199f69e56eb77", + ], + [ + "2b4ea0a797a443d293ef5cff444f4979f06acfebd7e86d277475656138385b6c", + "85e89bc037945d93b343083b5a1c86131a01f60c50269763b570c854e5c09b7a", + ], + [ + "352bbf4a4cdd12564f93fa332ce333301d9ad40271f8107181340aef25be59d5", + "321eb4075348f534d59c18259dda3e1f4a1b3b2e71b1039c67bd3d8bcf81998c", + ], + [ + "2fa2104d6b38d11b0230010559879124e42ab8dfeff5ff29dc9cdadd4ecacc3f", + "2de1068295dd865b64569335bd5dd80181d70ecfc882648423ba76b532b7d67", + ], + [ + "9248279b09b4d68dab21a9b066edda83263c3d84e09572e269ca0cd7f5453714", + "73016f7bf234aade5d1aa71bdea2b1ff3fc0de2a887912ffe54a32ce97cb3402", + ], + [ + "daed4f2be3a8bf278e70132fb0beb7522f570e144bf615c07e996d443dee8729", + "a69dce4a7d6c98e8d4a1aca87ef8d7003f83c230f3afa726ab40e52290be1c55", + ], + [ + "c44d12c7065d812e8acf28d7cbb19f9011ecd9e9fdf281b0e6a3b5e87d22e7db", + "2119a460ce326cdc76c45926c982fdac0e106e861edf61c5a039063f0e0e6482", + ], + [ + "6a245bf6dc698504c89a20cfded60853152b695336c28063b61c65cbd269e6b4", + "e022cf42c2bd4a708b3f5126f16a24ad8b33ba48d0423b6efd5e6348100d8a82", + ], + [ + "1697ffa6fd9de627c077e3d2fe541084ce13300b0bec1146f95ae57f0d0bd6a5", + "b9c398f186806f5d27561506e4557433a2cf15009e498ae7adee9d63d01b2396", + ], + [ + "605bdb019981718b986d0f07e834cb0d9deb8360ffb7f61df982345ef27a7479", + "2972d2de4f8d20681a78d93ec96fe23c26bfae84fb14db43b01e1e9056b8c49", + ], + [ + "62d14dab4150bf497402fdc45a215e10dcb01c354959b10cfe31c7e9d87ff33d", + "80fc06bd8cc5b01098088a1950eed0db01aa132967ab472235f5642483b25eaf", + ], + [ + "80c60ad0040f27dade5b4b06c408e56b2c50e9f56b9b8b425e555c2f86308b6f", + "1c38303f1cc5c30f26e66bad7fe72f70a65eed4cbe7024eb1aa01f56430bd57a", + ], + [ + "7a9375ad6167ad54aa74c6348cc54d344cc5dc9487d847049d5eabb0fa03c8fb", + "d0e3fa9eca8726909559e0d79269046bdc59ea10c70ce2b02d499ec224dc7f7", + ], + [ + "d528ecd9b696b54c907a9ed045447a79bb408ec39b68df504bb51f459bc3ffc9", + "eecf41253136e5f99966f21881fd656ebc4345405c520dbc063465b521409933", + ], + [ + "49370a4b5f43412ea25f514e8ecdad05266115e4a7ecb1387231808f8b45963", + "758f3f41afd6ed428b3081b0512fd62a54c3f3afbb5b6764b653052a12949c9a", + ], + [ + "77f230936ee88cbbd73df930d64702ef881d811e0e1498e2f1c13eb1fc345d74", + "958ef42a7886b6400a08266e9ba1b37896c95330d97077cbbe8eb3c7671c60d6", + ], + [ + "f2dac991cc4ce4b9ea44887e5c7c0bce58c80074ab9d4dbaeb28531b7739f530", + "e0dedc9b3b2f8dad4da1f32dec2531df9eb5fbeb0598e4fd1a117dba703a3c37", + ], + [ + "463b3d9f662621fb1b4be8fbbe2520125a216cdfc9dae3debcba4850c690d45b", + "5ed430d78c296c3543114306dd8622d7c622e27c970a1de31cb377b01af7307e", + ], + [ + "f16f804244e46e2a09232d4aff3b59976b98fac14328a2d1a32496b49998f247", + "cedabd9b82203f7e13d206fcdf4e33d92a6c53c26e5cce26d6579962c4e31df6", + ], + [ + "caf754272dc84563b0352b7a14311af55d245315ace27c65369e15f7151d41d1", + "cb474660ef35f5f2a41b643fa5e460575f4fa9b7962232a5c32f908318a04476", + ], + [ + "2600ca4b282cb986f85d0f1709979d8b44a09c07cb86d7c124497bc86f082120", + "4119b88753c15bd6a693b03fcddbb45d5ac6be74ab5f0ef44b0be9475a7e4b40", + ], + [ + "7635ca72d7e8432c338ec53cd12220bc01c48685e24f7dc8c602a7746998e435", + "91b649609489d613d1d5e590f78e6d74ecfc061d57048bad9e76f302c5b9c61", + ], + [ + "754e3239f325570cdbbf4a87deee8a66b7f2b33479d468fbc1a50743bf56cc18", + "673fb86e5bda30fb3cd0ed304ea49a023ee33d0197a695d0c5d98093c536683", + ], + [ + "e3e6bd1071a1e96aff57859c82d570f0330800661d1c952f9fe2694691d9b9e8", + "59c9e0bba394e76f40c0aa58379a3cb6a5a2283993e90c4167002af4920e37f5", + ], + [ + "186b483d056a033826ae73d88f732985c4ccb1f32ba35f4b4cc47fdcf04aa6eb", + "3b952d32c67cf77e2e17446e204180ab21fb8090895138b4a4a797f86e80888b", + ], + [ + "df9d70a6b9876ce544c98561f4be4f725442e6d2b737d9c91a8321724ce0963f", + "55eb2dafd84d6ccd5f862b785dc39d4ab157222720ef9da217b8c45cf2ba2417", + ], + [ + "5edd5cc23c51e87a497ca815d5dce0f8ab52554f849ed8995de64c5f34ce7143", + "efae9c8dbc14130661e8cec030c89ad0c13c66c0d17a2905cdc706ab7399a868", + ], + [ + "290798c2b6476830da12fe02287e9e777aa3fba1c355b17a722d362f84614fba", + "e38da76dcd440621988d00bcf79af25d5b29c094db2a23146d003afd41943e7a", + ], + [ + "af3c423a95d9f5b3054754efa150ac39cd29552fe360257362dfdecef4053b45", + "f98a3fd831eb2b749a93b0e6f35cfb40c8cd5aa667a15581bc2feded498fd9c6", + ], + [ + "766dbb24d134e745cccaa28c99bf274906bb66b26dcf98df8d2fed50d884249a", + "744b1152eacbe5e38dcc887980da38b897584a65fa06cedd2c924f97cbac5996", + ], + [ + "59dbf46f8c94759ba21277c33784f41645f7b44f6c596a58ce92e666191abe3e", + "c534ad44175fbc300f4ea6ce648309a042ce739a7919798cd85e216c4a307f6e", + ], + [ + "f13ada95103c4537305e691e74e9a4a8dd647e711a95e73cb62dc6018cfd87b8", + "e13817b44ee14de663bf4bc808341f326949e21a6a75c2570778419bdaf5733d", + ], + [ + "7754b4fa0e8aced06d4167a2c59cca4cda1869c06ebadfb6488550015a88522c", + "30e93e864e669d82224b967c3020b8fa8d1e4e350b6cbcc537a48b57841163a2", + ], + [ + "948dcadf5990e048aa3874d46abef9d701858f95de8041d2a6828c99e2262519", + "e491a42537f6e597d5d28a3224b1bc25df9154efbd2ef1d2cbba2cae5347d57e", + ], + [ + "7962414450c76c1689c7b48f8202ec37fb224cf5ac0bfa1570328a8a3d7c77ab", + "100b610ec4ffb4760d5c1fc133ef6f6b12507a051f04ac5760afa5b29db83437", + ], + [ + "3514087834964b54b15b160644d915485a16977225b8847bb0dd085137ec47ca", + "ef0afbb2056205448e1652c48e8127fc6039e77c15c2378b7e7d15a0de293311", + ], + [ + "d3cc30ad6b483e4bc79ce2c9dd8bc54993e947eb8df787b442943d3f7b527eaf", + "8b378a22d827278d89c5e9be8f9508ae3c2ad46290358630afb34db04eede0a4", + ], + [ + "1624d84780732860ce1c78fcbfefe08b2b29823db913f6493975ba0ff4847610", + "68651cf9b6da903e0914448c6cd9d4ca896878f5282be4c8cc06e2a404078575", + ], + [ + "733ce80da955a8a26902c95633e62a985192474b5af207da6df7b4fd5fc61cd4", + "f5435a2bd2badf7d485a4d8b8db9fcce3e1ef8e0201e4578c54673bc1dc5ea1d", + ], + [ + "15d9441254945064cf1a1c33bbd3b49f8966c5092171e699ef258dfab81c045c", + "d56eb30b69463e7234f5137b73b84177434800bacebfc685fc37bbe9efe4070d", + ], + [ + "a1d0fcf2ec9de675b612136e5ce70d271c21417c9d2b8aaaac138599d0717940", + "edd77f50bcb5a3cab2e90737309667f2641462a54070f3d519212d39c197a629", + ], + [ + "e22fbe15c0af8ccc5780c0735f84dbe9a790badee8245c06c7ca37331cb36980", + "a855babad5cd60c88b430a69f53a1a7a38289154964799be43d06d77d31da06", + ], + [ + "311091dd9860e8e20ee13473c1155f5f69635e394704eaa74009452246cfa9b3", + "66db656f87d1f04fffd1f04788c06830871ec5a64feee685bd80f0b1286d8374", + ], + [ + "34c1fd04d301be89b31c0442d3e6ac24883928b45a9340781867d4232ec2dbdf", + "9414685e97b1b5954bd46f730174136d57f1ceeb487443dc5321857ba73abee", + ], + [ + "f219ea5d6b54701c1c14de5b557eb42a8d13f3abbcd08affcc2a5e6b049b8d63", + "4cb95957e83d40b0f73af4544cccf6b1f4b08d3c07b27fb8d8c2962a400766d1", + ], + [ + "d7b8740f74a8fbaab1f683db8f45de26543a5490bca627087236912469a0b448", + "fa77968128d9c92ee1010f337ad4717eff15db5ed3c049b3411e0315eaa4593b", + ], + [ + "32d31c222f8f6f0ef86f7c98d3a3335ead5bcd32abdd94289fe4d3091aa824bf", + "5f3032f5892156e39ccd3d7915b9e1da2e6dac9e6f26e961118d14b8462e1661", + ], + [ + "7461f371914ab32671045a155d9831ea8793d77cd59592c4340f86cbc18347b5", + "8ec0ba238b96bec0cbdddcae0aa442542eee1ff50c986ea6b39847b3cc092ff6", + ], + [ + "ee079adb1df1860074356a25aa38206a6d716b2c3e67453d287698bad7b2b2d6", + "8dc2412aafe3be5c4c5f37e0ecc5f9f6a446989af04c4e25ebaac479ec1c8c1e", + ], + [ + "16ec93e447ec83f0467b18302ee620f7e65de331874c9dc72bfd8616ba9da6b5", + "5e4631150e62fb40d0e8c2a7ca5804a39d58186a50e497139626778e25b0674d", + ], + [ + "eaa5f980c245f6f038978290afa70b6bd8855897f98b6aa485b96065d537bd99", + "f65f5d3e292c2e0819a528391c994624d784869d7e6ea67fb18041024edc07dc", + ], + [ + "78c9407544ac132692ee1910a02439958ae04877151342ea96c4b6b35a49f51", + "f3e0319169eb9b85d5404795539a5e68fa1fbd583c064d2462b675f194a3ddb4", + ], + [ + "494f4be219a1a77016dcd838431aea0001cdc8ae7a6fc688726578d9702857a5", + "42242a969283a5f339ba7f075e36ba2af925ce30d767ed6e55f4b031880d562c", + ], + [ + "a598a8030da6d86c6bc7f2f5144ea549d28211ea58faa70ebf4c1e665c1fe9b5", + "204b5d6f84822c307e4b4a7140737aec23fc63b65b35f86a10026dbd2d864e6b", + ], + [ + "c41916365abb2b5d09192f5f2dbeafec208f020f12570a184dbadc3e58595997", + "4f14351d0087efa49d245b328984989d5caf9450f34bfc0ed16e96b58fa9913", + ], + [ + "841d6063a586fa475a724604da03bc5b92a2e0d2e0a36acfe4c73a5514742881", + "73867f59c0659e81904f9a1c7543698e62562d6744c169ce7a36de01a8d6154", + ], + [ + "5e95bb399a6971d376026947f89bde2f282b33810928be4ded112ac4d70e20d5", + "39f23f366809085beebfc71181313775a99c9aed7d8ba38b161384c746012865", + ], + [ + "36e4641a53948fd476c39f8a99fd974e5ec07564b5315d8bf99471bca0ef2f66", + "d2424b1b1abe4eb8164227b085c9aa9456ea13493fd563e06fd51cf5694c78fc", + ], + [ + "336581ea7bfbbb290c191a2f507a41cf5643842170e914faeab27c2c579f726", + "ead12168595fe1be99252129b6e56b3391f7ab1410cd1e0ef3dcdcabd2fda224", + ], + [ + "8ab89816dadfd6b6a1f2634fcf00ec8403781025ed6890c4849742706bd43ede", + "6fdcef09f2f6d0a044e654aef624136f503d459c3e89845858a47a9129cdd24e", + ], + [ + "1e33f1a746c9c5778133344d9299fcaa20b0938e8acff2544bb40284b8c5fb94", + "60660257dd11b3aa9c8ed618d24edff2306d320f1d03010e33a7d2057f3b3b6", + ], + [ + "85b7c1dcb3cec1b7ee7f30ded79dd20a0ed1f4cc18cbcfcfa410361fd8f08f31", + "3d98a9cdd026dd43f39048f25a8847f4fcafad1895d7a633c6fed3c35e999511", + ], + [ + "29df9fbd8d9e46509275f4b125d6d45d7fbe9a3b878a7af872a2800661ac5f51", + "b4c4fe99c775a606e2d8862179139ffda61dc861c019e55cd2876eb2a27d84b", + ], + [ + "a0b1cae06b0a847a3fea6e671aaf8adfdfe58ca2f768105c8082b2e449fce252", + "ae434102edde0958ec4b19d917a6a28e6b72da1834aff0e650f049503a296cf2", + ], + [ + "4e8ceafb9b3e9a136dc7ff67e840295b499dfb3b2133e4ba113f2e4c0e121e5", + "cf2174118c8b6d7a4b48f6d534ce5c79422c086a63460502b827ce62a326683c", + ], + [ + "d24a44e047e19b6f5afb81c7ca2f69080a5076689a010919f42725c2b789a33b", + "6fb8d5591b466f8fc63db50f1c0f1c69013f996887b8244d2cdec417afea8fa3", + ], + [ + "ea01606a7a6c9cdd249fdfcfacb99584001edd28abbab77b5104e98e8e3b35d4", + "322af4908c7312b0cfbfe369f7a7b3cdb7d4494bc2823700cfd652188a3ea98d", + ], + [ + "af8addbf2b661c8a6c6328655eb96651252007d8c5ea31be4ad196de8ce2131f", + "6749e67c029b85f52a034eafd096836b2520818680e26ac8f3dfbcdb71749700", + ], + [ + "e3ae1974566ca06cc516d47e0fb165a674a3dabcfca15e722f0e3450f45889", + "2aeabe7e4531510116217f07bf4d07300de97e4874f81f533420a72eeb0bd6a4", + ], + [ + "591ee355313d99721cf6993ffed1e3e301993ff3ed258802075ea8ced397e246", + "b0ea558a113c30bea60fc4775460c7901ff0b053d25ca2bdeee98f1a4be5d196", + ], + [ + "11396d55fda54c49f19aa97318d8da61fa8584e47b084945077cf03255b52984", + "998c74a8cd45ac01289d5833a7beb4744ff536b01b257be4c5767bea93ea57a4", + ], + [ + "3c5d2a1ba39c5a1790000738c9e0c40b8dcdfd5468754b6405540157e017aa7a", + "b2284279995a34e2f9d4de7396fc18b80f9b8b9fdd270f6661f79ca4c81bd257", + ], + [ + "cc8704b8a60a0defa3a99a7299f2e9c3fbc395afb04ac078425ef8a1793cc030", + "bdd46039feed17881d1e0862db347f8cf395b74fc4bcdc4e940b74e3ac1f1b13", + ], + [ + "c533e4f7ea8555aacd9777ac5cad29b97dd4defccc53ee7ea204119b2889b197", + "6f0a256bc5efdf429a2fb6242f1a43a2d9b925bb4a4b3a26bb8e0f45eb596096", + ], + [ + "c14f8f2ccb27d6f109f6d08d03cc96a69ba8c34eec07bbcf566d48e33da6593", + "c359d6923bb398f7fd4473e16fe1c28475b740dd098075e6c0e8649113dc3a38", + ], + [ + "a6cbc3046bc6a450bac24789fa17115a4c9739ed75f8f21ce441f72e0b90e6ef", + "21ae7f4680e889bb130619e2c0f95a360ceb573c70603139862afd617fa9b9f", + ], + [ + "347d6d9a02c48927ebfb86c1359b1caf130a3c0267d11ce6344b39f99d43cc38", + "60ea7f61a353524d1c987f6ecec92f086d565ab687870cb12689ff1e31c74448", + ], + [ + "da6545d2181db8d983f7dcb375ef5866d47c67b1bf31c8cf855ef7437b72656a", + "49b96715ab6878a79e78f07ce5680c5d6673051b4935bd897fea824b77dc208a", + ], + [ + "c40747cc9d012cb1a13b8148309c6de7ec25d6945d657146b9d5994b8feb1111", + "5ca560753be2a12fc6de6caf2cb489565db936156b9514e1bb5e83037e0fa2d4", + ], + [ + "4e42c8ec82c99798ccf3a610be870e78338c7f713348bd34c8203ef4037f3502", + "7571d74ee5e0fb92a7a8b33a07783341a5492144cc54bcc40a94473693606437", + ], + [ + "3775ab7089bc6af823aba2e1af70b236d251cadb0c86743287522a1b3b0dedea", + "be52d107bcfa09d8bcb9736a828cfa7fac8db17bf7a76a2c42ad961409018cf7", + ], + [ + "cee31cbf7e34ec379d94fb814d3d775ad954595d1314ba8846959e3e82f74e26", + "8fd64a14c06b589c26b947ae2bcf6bfa0149ef0be14ed4d80f448a01c43b1c6d", + ], + [ + "b4f9eaea09b6917619f6ea6a4eb5464efddb58fd45b1ebefcdc1a01d08b47986", + "39e5c9925b5a54b07433a4f18c61726f8bb131c012ca542eb24a8ac07200682a", + ], + [ + "d4263dfc3d2df923a0179a48966d30ce84e2515afc3dccc1b77907792ebcc60e", + "62dfaf07a0f78feb30e30d6295853ce189e127760ad6cf7fae164e122a208d54", + ], + [ + "48457524820fa65a4f8d35eb6930857c0032acc0a4a2de422233eeda897612c4", + "25a748ab367979d98733c38a1fa1c2e7dc6cc07db2d60a9ae7a76aaa49bd0f77", + ], + [ + "dfeeef1881101f2cb11644f3a2afdfc2045e19919152923f367a1767c11cceda", + "ecfb7056cf1de042f9420bab396793c0c390bde74b4bbdff16a83ae09a9a7517", + ], + [ + "6d7ef6b17543f8373c573f44e1f389835d89bcbc6062ced36c82df83b8fae859", + "cd450ec335438986dfefa10c57fea9bcc521a0959b2d80bbf74b190dca712d10", + ], + [ + "e75605d59102a5a2684500d3b991f2e3f3c88b93225547035af25af66e04541f", + "f5c54754a8f71ee540b9b48728473e314f729ac5308b06938360990e2bfad125", + ], + [ + "eb98660f4c4dfaa06a2be453d5020bc99a0c2e60abe388457dd43fefb1ed620c", + "6cb9a8876d9cb8520609af3add26cd20a0a7cd8a9411131ce85f44100099223e", + ], + [ + "13e87b027d8514d35939f2e6892b19922154596941888336dc3563e3b8dba942", + "fef5a3c68059a6dec5d624114bf1e91aac2b9da568d6abeb2570d55646b8adf1", + ], + [ + "ee163026e9fd6fe017c38f06a5be6fc125424b371ce2708e7bf4491691e5764a", + "1acb250f255dd61c43d94ccc670d0f58f49ae3fa15b96623e5430da0ad6c62b2", + ], + [ + "b268f5ef9ad51e4d78de3a750c2dc89b1e626d43505867999932e5db33af3d80", + "5f310d4b3c99b9ebb19f77d41c1dee018cf0d34fd4191614003e945a1216e423", + ], + [ + "ff07f3118a9df035e9fad85eb6c7bfe42b02f01ca99ceea3bf7ffdba93c4750d", + "438136d603e858a3a5c440c38eccbaddc1d2942114e2eddd4740d098ced1f0d8", + ], + [ + "8d8b9855c7c052a34146fd20ffb658bea4b9f69e0d825ebec16e8c3ce2b526a1", + "cdb559eedc2d79f926baf44fb84ea4d44bcf50fee51d7ceb30e2e7f463036758", + ], + [ + "52db0b5384dfbf05bfa9d472d7ae26dfe4b851ceca91b1eba54263180da32b63", + "c3b997d050ee5d423ebaf66a6db9f57b3180c902875679de924b69d84a7b375", + ], + [ + "e62f9490d3d51da6395efd24e80919cc7d0f29c3f3fa48c6fff543becbd43352", + "6d89ad7ba4876b0b22c2ca280c682862f342c8591f1daf5170e07bfd9ccafa7d", + ], + [ + "7f30ea2476b399b4957509c88f77d0191afa2ff5cb7b14fd6d8e7d65aaab1193", + "ca5ef7d4b231c94c3b15389a5f6311e9daff7bb67b103e9880ef4bff637acaec", + ], + [ + "5098ff1e1d9f14fb46a210fada6c903fef0fb7b4a1dd1d9ac60a0361800b7a00", + "9731141d81fc8f8084d37c6e7542006b3ee1b40d60dfe5362a5b132fd17ddc0", + ], + [ + "32b78c7de9ee512a72895be6b9cbefa6e2f3c4ccce445c96b9f2c81e2778ad58", + "ee1849f513df71e32efc3896ee28260c73bb80547ae2275ba497237794c8753c", + ], + [ + "e2cb74fddc8e9fbcd076eef2a7c72b0ce37d50f08269dfc074b581550547a4f7", + "d3aa2ed71c9dd2247a62df062736eb0baddea9e36122d2be8641abcb005cc4a4", + ], + [ + "8438447566d4d7bedadc299496ab357426009a35f235cb141be0d99cd10ae3a8", + "c4e1020916980a4da5d01ac5e6ad330734ef0d7906631c4f2390426b2edd791f", + ], + [ + "4162d488b89402039b584c6fc6c308870587d9c46f660b878ab65c82c711d67e", + "67163e903236289f776f22c25fb8a3afc1732f2b84b4e95dbda47ae5a0852649", + ], + [ + "3fad3fa84caf0f34f0f89bfd2dcf54fc175d767aec3e50684f3ba4a4bf5f683d", + "cd1bc7cb6cc407bb2f0ca647c718a730cf71872e7d0d2a53fa20efcdfe61826", + ], + [ + "674f2600a3007a00568c1a7ce05d0816c1fb84bf1370798f1c69532faeb1a86b", + "299d21f9413f33b3edf43b257004580b70db57da0b182259e09eecc69e0d38a5", + ], + [ + "d32f4da54ade74abb81b815ad1fb3b263d82d6c692714bcff87d29bd5ee9f08f", + "f9429e738b8e53b968e99016c059707782e14f4535359d582fc416910b3eea87", + ], + [ + "30e4e670435385556e593657135845d36fbb6931f72b08cb1ed954f1e3ce3ff6", + "462f9bce619898638499350113bbc9b10a878d35da70740dc695a559eb88db7b", + ], + [ + "be2062003c51cc3004682904330e4dee7f3dcd10b01e580bf1971b04d4cad297", + "62188bc49d61e5428573d48a74e1c655b1c61090905682a0d5558ed72dccb9bc", + ], + [ + "93144423ace3451ed29e0fb9ac2af211cb6e84a601df5993c419859fff5df04a", + "7c10dfb164c3425f5c71a3f9d7992038f1065224f72bb9d1d902a6d13037b47c", + ], + [ + "b015f8044f5fcbdcf21ca26d6c34fb8197829205c7b7d2a7cb66418c157b112c", + "ab8c1e086d04e813744a655b2df8d5f83b3cdc6faa3088c1d3aea1454e3a1d5f", + ], + [ + "d5e9e1da649d97d89e4868117a465a3a4f8a18de57a140d36b3f2af341a21b52", + "4cb04437f391ed73111a13cc1d4dd0db1693465c2240480d8955e8592f27447a", + ], + [ + "d3ae41047dd7ca065dbf8ed77b992439983005cd72e16d6f996a5316d36966bb", + "bd1aeb21ad22ebb22a10f0303417c6d964f8cdd7df0aca614b10dc14d125ac46", + ], + [ + "463e2763d885f958fc66cdd22800f0a487197d0a82e377b49f80af87c897b065", + "bfefacdb0e5d0fd7df3a311a94de062b26b80c61fbc97508b79992671ef7ca7f", + ], + [ + "7985fdfd127c0567c6f53ec1bb63ec3158e597c40bfe747c83cddfc910641917", + "603c12daf3d9862ef2b25fe1de289aed24ed291e0ec6708703a5bd567f32ed03", + ], + [ + "74a1ad6b5f76e39db2dd249410eac7f99e74c59cb83d2d0ed5ff1543da7703e9", + "cc6157ef18c9c63cd6193d83631bbea0093e0968942e8c33d5737fd790e0db08", + ], + [ + "30682a50703375f602d416664ba19b7fc9bab42c72747463a71d0896b22f6da3", + "553e04f6b018b4fa6c8f39e7f311d3176290d0e0f19ca73f17714d9977a22ff8", + ], + [ + "9e2158f0d7c0d5f26c3791efefa79597654e7a2b2464f52b1ee6c1347769ef57", + "712fcdd1b9053f09003a3481fa7762e9ffd7c8ef35a38509e2fbf2629008373", + ], + [ + "176e26989a43c9cfeba4029c202538c28172e566e3c4fce7322857f3be327d66", + "ed8cc9d04b29eb877d270b4878dc43c19aefd31f4eee09ee7b47834c1fa4b1c3", + ], + [ + "75d46efea3771e6e68abb89a13ad747ecf1892393dfc4f1b7004788c50374da8", + "9852390a99507679fd0b86fd2b39a868d7efc22151346e1a3ca4726586a6bed8", + ], + [ + "809a20c67d64900ffb698c4c825f6d5f2310fb0451c869345b7319f645605721", + "9e994980d9917e22b76b061927fa04143d096ccc54963e6a5ebfa5f3f8e286c1", + ], + [ + "1b38903a43f7f114ed4500b4eac7083fdefece1cf29c63528d563446f972c180", + "4036edc931a60ae889353f77fd53de4a2708b26b6f5da72ad3394119daf408f9", + ], + ], + }, + }; + }, + {}, + ], + 99: [ + function (A, e, t) { + "use strict"; + var i = t, + g = A("bn.js"), + r = A("minimalistic-assert"), + n = A("minimalistic-crypto-utils"); + (i.assert = r), + (i.toArray = n.toArray), + (i.zero2 = n.zero2), + (i.toHex = n.toHex), + (i.encode = n.encode), + (i.getNAF = function (A, e, t) { + var i = new Array(Math.max(A.bitLength(), t) + 1); + i.fill(0); + for ( + var g = 1 << (e + 1), r = A.clone(), n = 0; + n < i.length; + n++ + ) { + var B, + I = r.andln(g - 1); + r.isOdd() + ? ((B = I > (g >> 1) - 1 ? (g >> 1) - I : I), r.isubn(B)) + : (B = 0), + (i[n] = B), + r.iushrn(1); + } + return i; + }), + (i.getJSF = function (A, e) { + var t = [[], []]; + (A = A.clone()), (e = e.clone()); + for (var i = 0, g = 0; A.cmpn(-i) > 0 || e.cmpn(-g) > 0; ) { + var r, + n, + B, + I = (A.andln(3) + i) & 3, + o = (e.andln(3) + g) & 3; + 3 === I && (I = -1), + 3 === o && (o = -1), + (r = + 0 == (1 & I) + ? 0 + : (3 != (B = (A.andln(7) + i) & 7) && 5 !== B) || 2 !== o + ? I + : -I), + t[0].push(r), + (n = + 0 == (1 & o) + ? 0 + : (3 != (B = (e.andln(7) + g) & 7) && 5 !== B) || 2 !== I + ? o + : -o), + t[1].push(n), + 2 * i === r + 1 && (i = 1 - i), + 2 * g === n + 1 && (g = 1 - g), + A.iushrn(1), + e.iushrn(1); + } + return t; + }), + (i.cachedProperty = function (A, e, t) { + var i = "_" + e; + A.prototype[e] = function () { + return void 0 !== this[i] ? this[i] : (this[i] = t.call(this)); + }; + }), + (i.parseBytes = function (A) { + return "string" == typeof A ? i.toArray(A, "hex") : A; + }), + (i.intFromLE = function (A) { + return new g(A, "hex", "le"); + }); + }, + { + "bn.js": 100, + "minimalistic-assert": 140, + "minimalistic-crypto-utils": 141, + }, + ], + 100: [ + function (A, e, t) { + arguments[4][15][0].apply(t, arguments); + }, + { buffer: 19, dup: 15 }, + ], + 101: [ + function (A, e, t) { + e.exports = { + _from: "elliptic@^6.5.3", + _id: "elliptic@6.5.3", + _inBundle: !1, + _integrity: + "sha512-IMqzv5wNQf+E6aHeIqATs0tOLeOTwj1QKbRcS3jBbYkl5oLAserA8yJTT7/VyHUYG91PRmPyeQDObKLPpeS4dw==", + _location: "/browserify/elliptic", + _phantomChildren: {}, + _requested: { + type: "range", + registry: !0, + raw: "elliptic@^6.5.3", + name: "elliptic", + escapedName: "elliptic", + rawSpec: "^6.5.3", + saveSpec: null, + fetchSpec: "^6.5.3", + }, + _requiredBy: [ + "/browserify/browserify-sign", + "/browserify/create-ecdh", + ], + _resolved: "https://registry.npmjs.org/elliptic/-/elliptic-6.5.3.tgz", + _shasum: "cb59eb2efdaf73a0bd78ccd7015a62ad6e0f93d6", + _spec: "elliptic@^6.5.3", + _where: + "/home/volt/.npm/_npx/29682/lib/node_modules/browserify/node_modules/browserify-sign", + author: { name: "Fedor Indutny", email: "fedor@indutny.com" }, + bugs: { url: "https://github.com/indutny/elliptic/issues" }, + bundleDependencies: !1, + dependencies: { + "bn.js": "^4.4.0", + brorand: "^1.0.1", + "hash.js": "^1.0.0", + "hmac-drbg": "^1.0.0", + inherits: "^2.0.1", + "minimalistic-assert": "^1.0.0", + "minimalistic-crypto-utils": "^1.0.0", + }, + deprecated: !1, + description: "EC cryptography", + devDependencies: { + brfs: "^1.4.3", + coveralls: "^3.0.8", + grunt: "^1.0.4", + "grunt-browserify": "^5.0.0", + "grunt-cli": "^1.2.0", + "grunt-contrib-connect": "^1.0.0", + "grunt-contrib-copy": "^1.0.0", + "grunt-contrib-uglify": "^1.0.1", + "grunt-mocha-istanbul": "^3.0.1", + "grunt-saucelabs": "^9.0.1", + istanbul: "^0.4.2", + jscs: "^3.0.7", + jshint: "^2.10.3", + mocha: "^6.2.2", + }, + files: ["lib"], + homepage: "https://github.com/indutny/elliptic", + keywords: ["EC", "Elliptic", "curve", "Cryptography"], + license: "MIT", + main: "lib/elliptic.js", + name: "elliptic", + repository: { + type: "git", + url: "git+ssh://git@github.com/indutny/elliptic.git", + }, + scripts: { + jscs: "jscs benchmarks/*.js lib/*.js lib/**/*.js lib/**/**/*.js test/index.js", + jshint: + "jscs benchmarks/*.js lib/*.js lib/**/*.js lib/**/**/*.js test/index.js", + lint: "npm run jscs && npm run jshint", + test: "npm run lint && npm run unit", + unit: "istanbul test _mocha --reporter=spec test/index.js", + version: "grunt dist && git add dist/", + }, + version: "6.5.3", + }; + }, + {}, + ], + 102: [ + function (A, e, t) { + var i = + Object.create || + function (A) { + var e = function () {}; + return (e.prototype = A), new e(); + }, + g = + Object.keys || + function (A) { + var e = []; + for (var t in A) + Object.prototype.hasOwnProperty.call(A, t) && e.push(t); + return t; + }, + r = + Function.prototype.bind || + function (A) { + var e = this; + return function () { + return e.apply(A, arguments); + }; + }; + function n() { + (this._events && + Object.prototype.hasOwnProperty.call(this, "_events")) || + ((this._events = i(null)), (this._eventsCount = 0)), + (this._maxListeners = this._maxListeners || void 0); + } + (e.exports = n), + (n.EventEmitter = n), + (n.prototype._events = void 0), + (n.prototype._maxListeners = void 0); + var B, + I = 10; + try { + var o = {}; + Object.defineProperty && Object.defineProperty(o, "x", { value: 0 }), + (B = 0 === o.x); + } catch (A) { + B = !1; + } + function a(A) { + return void 0 === A._maxListeners + ? n.defaultMaxListeners + : A._maxListeners; + } + function Q(A, e, t, g) { + var r, n, B; + if ("function" != typeof t) + throw new TypeError('"listener" argument must be a function'); + if ( + ((n = A._events) + ? (n.newListener && + (A.emit("newListener", e, t.listener ? t.listener : t), + (n = A._events)), + (B = n[e])) + : ((n = A._events = i(null)), (A._eventsCount = 0)), + B) + ) { + if ( + ("function" == typeof B + ? (B = n[e] = g ? [t, B] : [B, t]) + : g + ? B.unshift(t) + : B.push(t), + !B.warned && (r = a(A)) && r > 0 && B.length > r) + ) { + B.warned = !0; + var I = new Error( + "Possible EventEmitter memory leak detected. " + + B.length + + ' "' + + String(e) + + '" listeners added. Use emitter.setMaxListeners() to increase limit.' + ); + (I.name = "MaxListenersExceededWarning"), + (I.emitter = A), + (I.type = e), + (I.count = B.length), + "object" == typeof console && + console.warn && + console.warn("%s: %s", I.name, I.message); + } + } else (B = n[e] = t), ++A._eventsCount; + return A; + } + function C() { + if (!this.fired) + switch ( + (this.target.removeListener(this.type, this.wrapFn), + (this.fired = !0), + arguments.length) + ) { + case 0: + return this.listener.call(this.target); + case 1: + return this.listener.call(this.target, arguments[0]); + case 2: + return this.listener.call( + this.target, + arguments[0], + arguments[1] + ); + case 3: + return this.listener.call( + this.target, + arguments[0], + arguments[1], + arguments[2] + ); + default: + for ( + var A = new Array(arguments.length), e = 0; + e < A.length; + ++e + ) + A[e] = arguments[e]; + this.listener.apply(this.target, A); + } + } + function s(A, e, t) { + var i = { + fired: !1, + wrapFn: void 0, + target: A, + type: e, + listener: t, + }, + g = r.call(C, i); + return (g.listener = t), (i.wrapFn = g), g; + } + function c(A, e, t) { + var i = A._events; + if (!i) return []; + var g = i[e]; + return g + ? "function" == typeof g + ? t + ? [g.listener || g] + : [g] + : t + ? (function (A) { + for (var e = new Array(A.length), t = 0; t < e.length; ++t) + e[t] = A[t].listener || A[t]; + return e; + })(g) + : f(g, g.length) + : []; + } + function h(A) { + var e = this._events; + if (e) { + var t = e[A]; + if ("function" == typeof t) return 1; + if (t) return t.length; + } + return 0; + } + function f(A, e) { + for (var t = new Array(e), i = 0; i < e; ++i) t[i] = A[i]; + return t; + } + B + ? Object.defineProperty(n, "defaultMaxListeners", { + enumerable: !0, + get: function () { + return I; + }, + set: function (A) { + if ("number" != typeof A || A < 0 || A != A) + throw new TypeError( + '"defaultMaxListeners" must be a positive number' + ); + I = A; + }, + }) + : (n.defaultMaxListeners = I), + (n.prototype.setMaxListeners = function (A) { + if ("number" != typeof A || A < 0 || isNaN(A)) + throw new TypeError('"n" argument must be a positive number'); + return (this._maxListeners = A), this; + }), + (n.prototype.getMaxListeners = function () { + return a(this); + }), + (n.prototype.emit = function (A) { + var e, + t, + i, + g, + r, + n, + B = "error" === A; + if ((n = this._events)) B = B && null == n.error; + else if (!B) return !1; + if (B) { + if ( + (arguments.length > 1 && (e = arguments[1]), e instanceof Error) + ) + throw e; + var I = new Error('Unhandled "error" event. (' + e + ")"); + throw ((I.context = e), I); + } + if (!(t = n[A])) return !1; + var o = "function" == typeof t; + switch ((i = arguments.length)) { + case 1: + !(function (A, e, t) { + if (e) A.call(t); + else + for (var i = A.length, g = f(A, i), r = 0; r < i; ++r) + g[r].call(t); + })(t, o, this); + break; + case 2: + !(function (A, e, t, i) { + if (e) A.call(t, i); + else + for (var g = A.length, r = f(A, g), n = 0; n < g; ++n) + r[n].call(t, i); + })(t, o, this, arguments[1]); + break; + case 3: + !(function (A, e, t, i, g) { + if (e) A.call(t, i, g); + else + for (var r = A.length, n = f(A, r), B = 0; B < r; ++B) + n[B].call(t, i, g); + })(t, o, this, arguments[1], arguments[2]); + break; + case 4: + !(function (A, e, t, i, g, r) { + if (e) A.call(t, i, g, r); + else + for (var n = A.length, B = f(A, n), I = 0; I < n; ++I) + B[I].call(t, i, g, r); + })(t, o, this, arguments[1], arguments[2], arguments[3]); + break; + default: + for (g = new Array(i - 1), r = 1; r < i; r++) + g[r - 1] = arguments[r]; + !(function (A, e, t, i) { + if (e) A.apply(t, i); + else + for (var g = A.length, r = f(A, g), n = 0; n < g; ++n) + r[n].apply(t, i); + })(t, o, this, g); + } + return !0; + }), + (n.prototype.addListener = function (A, e) { + return Q(this, A, e, !1); + }), + (n.prototype.on = n.prototype.addListener), + (n.prototype.prependListener = function (A, e) { + return Q(this, A, e, !0); + }), + (n.prototype.once = function (A, e) { + if ("function" != typeof e) + throw new TypeError('"listener" argument must be a function'); + return this.on(A, s(this, A, e)), this; + }), + (n.prototype.prependOnceListener = function (A, e) { + if ("function" != typeof e) + throw new TypeError('"listener" argument must be a function'); + return this.prependListener(A, s(this, A, e)), this; + }), + (n.prototype.removeListener = function (A, e) { + var t, g, r, n, B; + if ("function" != typeof e) + throw new TypeError('"listener" argument must be a function'); + if (!(g = this._events)) return this; + if (!(t = g[A])) return this; + if (t === e || t.listener === e) + 0 == --this._eventsCount + ? (this._events = i(null)) + : (delete g[A], + g.removeListener && + this.emit("removeListener", A, t.listener || e)); + else if ("function" != typeof t) { + for (r = -1, n = t.length - 1; n >= 0; n--) + if (t[n] === e || t[n].listener === e) { + (B = t[n].listener), (r = n); + break; + } + if (r < 0) return this; + 0 === r + ? t.shift() + : (function (A, e) { + for ( + var t = e, i = t + 1, g = A.length; + i < g; + t += 1, i += 1 + ) + A[t] = A[i]; + A.pop(); + })(t, r), + 1 === t.length && (g[A] = t[0]), + g.removeListener && this.emit("removeListener", A, B || e); + } + return this; + }), + (n.prototype.removeAllListeners = function (A) { + var e, t, r; + if (!(t = this._events)) return this; + if (!t.removeListener) + return ( + 0 === arguments.length + ? ((this._events = i(null)), (this._eventsCount = 0)) + : t[A] && + (0 == --this._eventsCount + ? (this._events = i(null)) + : delete t[A]), + this + ); + if (0 === arguments.length) { + var n, + B = g(t); + for (r = 0; r < B.length; ++r) + "removeListener" !== (n = B[r]) && this.removeAllListeners(n); + return ( + this.removeAllListeners("removeListener"), + (this._events = i(null)), + (this._eventsCount = 0), + this + ); + } + if ("function" == typeof (e = t[A])) this.removeListener(A, e); + else if (e) + for (r = e.length - 1; r >= 0; r--) this.removeListener(A, e[r]); + return this; + }), + (n.prototype.listeners = function (A) { + return c(this, A, !0); + }), + (n.prototype.rawListeners = function (A) { + return c(this, A, !1); + }), + (n.listenerCount = function (A, e) { + return "function" == typeof A.listenerCount + ? A.listenerCount(e) + : h.call(A, e); + }), + (n.prototype.listenerCount = h), + (n.prototype.eventNames = function () { + return this._eventsCount > 0 ? Reflect.ownKeys(this._events) : []; + }); + }, + {}, + ], + 103: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer, + g = A("md5.js"); + e.exports = function (A, e, t, r) { + if ( + (i.isBuffer(A) || (A = i.from(A, "binary")), + e && (i.isBuffer(e) || (e = i.from(e, "binary")), 8 !== e.length)) + ) + throw new RangeError("salt should be Buffer with 8 byte length"); + for ( + var n = t / 8, B = i.alloc(n), I = i.alloc(r || 0), o = i.alloc(0); + n > 0 || r > 0; + + ) { + var a = new g(); + a.update(o), a.update(A), e && a.update(e), (o = a.digest()); + var Q = 0; + if (n > 0) { + var C = B.length - n; + (Q = Math.min(n, o.length)), o.copy(B, C, 0, Q), (n -= Q); + } + if (Q < o.length && r > 0) { + var s = I.length - r, + c = Math.min(r, o.length - Q); + o.copy(I, s, Q, Q + c), (r -= c); + } + } + return o.fill(0), { key: B, iv: I }; + }; + }, + { "md5.js": 137, "safe-buffer": 180 }, + ], + 104: [ + function (A, e, t) { + "use strict"; + var i = A("safe-buffer").Buffer, + g = A("readable-stream").Transform; + function r(A) { + g.call(this), + (this._block = i.allocUnsafe(A)), + (this._blockSize = A), + (this._blockOffset = 0), + (this._length = [0, 0, 0, 0]), + (this._finalized = !1); + } + A("inherits")(r, g), + (r.prototype._transform = function (A, e, t) { + var i = null; + try { + this.update(A, e); + } catch (A) { + i = A; + } + t(i); + }), + (r.prototype._flush = function (A) { + var e = null; + try { + this.push(this.digest()); + } catch (A) { + e = A; + } + A(e); + }), + (r.prototype.update = function (A, e) { + if ( + ((function (A, e) { + if (!i.isBuffer(A) && "string" != typeof A) + throw new TypeError(e + " must be a string or a buffer"); + })(A, "Data"), + this._finalized) + ) + throw new Error("Digest already called"); + i.isBuffer(A) || (A = i.from(A, e)); + for ( + var t = this._block, g = 0; + this._blockOffset + A.length - g >= this._blockSize; + + ) { + for (var r = this._blockOffset; r < this._blockSize; ) + t[r++] = A[g++]; + this._update(), (this._blockOffset = 0); + } + for (; g < A.length; ) t[this._blockOffset++] = A[g++]; + for (var n = 0, B = 8 * A.length; B > 0; ++n) + (this._length[n] += B), + (B = (this._length[n] / 4294967296) | 0) > 0 && + (this._length[n] -= 4294967296 * B); + return this; + }), + (r.prototype._update = function () { + throw new Error("_update is not implemented"); + }), + (r.prototype.digest = function (A) { + if (this._finalized) throw new Error("Digest already called"); + this._finalized = !0; + var e = this._digest(); + void 0 !== A && (e = e.toString(A)), + this._block.fill(0), + (this._blockOffset = 0); + for (var t = 0; t < 4; ++t) this._length[t] = 0; + return e; + }), + (r.prototype._digest = function () { + throw new Error("_digest is not implemented"); + }), + (e.exports = r); + }, + { inherits: 134, "readable-stream": 119, "safe-buffer": 180 }, + ], + 105: [ + function (A, e, t) { + arguments[4][48][0].apply(t, arguments); + }, + { dup: 48 }, + ], + 106: [ + function (A, e, t) { + arguments[4][49][0].apply(t, arguments); + }, + { + "./_stream_readable": 108, + "./_stream_writable": 110, + _process: 154, + dup: 49, + inherits: 134, + }, + ], + 107: [ + function (A, e, t) { + arguments[4][50][0].apply(t, arguments); + }, + { "./_stream_transform": 109, dup: 50, inherits: 134 }, + ], + 108: [ + function (A, e, t) { + arguments[4][51][0].apply(t, arguments); + }, + { + "../errors": 105, + "./_stream_duplex": 106, + "./internal/streams/async_iterator": 111, + "./internal/streams/buffer_list": 112, + "./internal/streams/destroy": 113, + "./internal/streams/from": 115, + "./internal/streams/state": 117, + "./internal/streams/stream": 118, + _process: 154, + buffer: 64, + dup: 51, + events: 102, + inherits: 134, + "string_decoder/": 191, + util: 19, + }, + ], + 109: [ + function (A, e, t) { + arguments[4][52][0].apply(t, arguments); + }, + { "../errors": 105, "./_stream_duplex": 106, dup: 52, inherits: 134 }, + ], + 110: [ + function (A, e, t) { + arguments[4][53][0].apply(t, arguments); + }, + { + "../errors": 105, + "./_stream_duplex": 106, + "./internal/streams/destroy": 113, + "./internal/streams/state": 117, + "./internal/streams/stream": 118, + _process: 154, + buffer: 64, + dup: 53, + inherits: 134, + "util-deprecate": 193, + }, + ], + 111: [ + function (A, e, t) { + arguments[4][54][0].apply(t, arguments); + }, + { "./end-of-stream": 114, _process: 154, dup: 54 }, + ], + 112: [ + function (A, e, t) { + arguments[4][55][0].apply(t, arguments); + }, + { buffer: 64, dup: 55, util: 19 }, + ], + 113: [ + function (A, e, t) { + arguments[4][56][0].apply(t, arguments); + }, + { _process: 154, dup: 56 }, + ], + 114: [ + function (A, e, t) { + arguments[4][57][0].apply(t, arguments); + }, + { "../../../errors": 105, dup: 57 }, + ], + 115: [ + function (A, e, t) { + arguments[4][58][0].apply(t, arguments); + }, + { dup: 58 }, + ], + 116: [ + function (A, e, t) { + arguments[4][59][0].apply(t, arguments); + }, + { "../../../errors": 105, "./end-of-stream": 114, dup: 59 }, + ], + 117: [ + function (A, e, t) { + arguments[4][60][0].apply(t, arguments); + }, + { "../../../errors": 105, dup: 60 }, + ], + 118: [ + function (A, e, t) { + arguments[4][61][0].apply(t, arguments); + }, + { dup: 61, events: 102 }, + ], + 119: [ + function (A, e, t) { + arguments[4][62][0].apply(t, arguments); + }, + { + "./lib/_stream_duplex.js": 106, + "./lib/_stream_passthrough.js": 107, + "./lib/_stream_readable.js": 108, + "./lib/_stream_transform.js": 109, + "./lib/_stream_writable.js": 110, + "./lib/internal/streams/end-of-stream.js": 114, + "./lib/internal/streams/pipeline.js": 116, + dup: 62, + }, + ], + 120: [ + function (A, e, t) { + var i = t; + (i.utils = A("./hash/utils")), + (i.common = A("./hash/common")), + (i.sha = A("./hash/sha")), + (i.ripemd = A("./hash/ripemd")), + (i.hmac = A("./hash/hmac")), + (i.sha1 = i.sha.sha1), + (i.sha256 = i.sha.sha256), + (i.sha224 = i.sha.sha224), + (i.sha384 = i.sha.sha384), + (i.sha512 = i.sha.sha512), + (i.ripemd160 = i.ripemd.ripemd160); + }, + { + "./hash/common": 121, + "./hash/hmac": 122, + "./hash/ripemd": 123, + "./hash/sha": 124, + "./hash/utils": 131, + }, + ], + 121: [ + function (A, e, t) { + "use strict"; + var i = A("./utils"), + g = A("minimalistic-assert"); + function r() { + (this.pending = null), + (this.pendingTotal = 0), + (this.blockSize = this.constructor.blockSize), + (this.outSize = this.constructor.outSize), + (this.hmacStrength = this.constructor.hmacStrength), + (this.padLength = this.constructor.padLength / 8), + (this.endian = "big"), + (this._delta8 = this.blockSize / 8), + (this._delta32 = this.blockSize / 32); + } + (t.BlockHash = r), + (r.prototype.update = function (A, e) { + if ( + ((A = i.toArray(A, e)), + this.pending + ? (this.pending = this.pending.concat(A)) + : (this.pending = A), + (this.pendingTotal += A.length), + this.pending.length >= this._delta8) + ) { + var t = (A = this.pending).length % this._delta8; + (this.pending = A.slice(A.length - t, A.length)), + 0 === this.pending.length && (this.pending = null), + (A = i.join32(A, 0, A.length - t, this.endian)); + for (var g = 0; g < A.length; g += this._delta32) + this._update(A, g, g + this._delta32); + } + return this; + }), + (r.prototype.digest = function (A) { + return ( + this.update(this._pad()), + g(null === this.pending), + this._digest(A) + ); + }), + (r.prototype._pad = function () { + var A = this.pendingTotal, + e = this._delta8, + t = e - ((A + this.padLength) % e), + i = new Array(t + this.padLength); + i[0] = 128; + for (var g = 1; g < t; g++) i[g] = 0; + if (((A <<= 3), "big" === this.endian)) { + for (var r = 8; r < this.padLength; r++) i[g++] = 0; + (i[g++] = 0), + (i[g++] = 0), + (i[g++] = 0), + (i[g++] = 0), + (i[g++] = (A >>> 24) & 255), + (i[g++] = (A >>> 16) & 255), + (i[g++] = (A >>> 8) & 255), + (i[g++] = 255 & A); + } else + for ( + i[g++] = 255 & A, + i[g++] = (A >>> 8) & 255, + i[g++] = (A >>> 16) & 255, + i[g++] = (A >>> 24) & 255, + i[g++] = 0, + i[g++] = 0, + i[g++] = 0, + i[g++] = 0, + r = 8; + r < this.padLength; + r++ + ) + i[g++] = 0; + return i; + }); + }, + { "./utils": 131, "minimalistic-assert": 140 }, + ], + 122: [ + function (A, e, t) { + "use strict"; + var i = A("./utils"), + g = A("minimalistic-assert"); + function r(A, e, t) { + if (!(this instanceof r)) return new r(A, e, t); + (this.Hash = A), + (this.blockSize = A.blockSize / 8), + (this.outSize = A.outSize / 8), + (this.inner = null), + (this.outer = null), + this._init(i.toArray(e, t)); + } + (e.exports = r), + (r.prototype._init = function (A) { + A.length > this.blockSize && + (A = new this.Hash().update(A).digest()), + g(A.length <= this.blockSize); + for (var e = A.length; e < this.blockSize; e++) A.push(0); + for (e = 0; e < A.length; e++) A[e] ^= 54; + for ( + this.inner = new this.Hash().update(A), e = 0; + e < A.length; + e++ + ) + A[e] ^= 106; + this.outer = new this.Hash().update(A); + }), + (r.prototype.update = function (A, e) { + return this.inner.update(A, e), this; + }), + (r.prototype.digest = function (A) { + return this.outer.update(this.inner.digest()), this.outer.digest(A); + }); + }, + { "./utils": 131, "minimalistic-assert": 140 }, + ], + 123: [ + function (A, e, t) { + "use strict"; + var i = A("./utils"), + g = A("./common"), + r = i.rotl32, + n = i.sum32, + B = i.sum32_3, + I = i.sum32_4, + o = g.BlockHash; + function a() { + if (!(this instanceof a)) return new a(); + o.call(this), + (this.h = [ + 1732584193, 4023233417, 2562383102, 271733878, 3285377520, + ]), + (this.endian = "little"); + } + function Q(A, e, t, i) { + return A <= 15 + ? e ^ t ^ i + : A <= 31 + ? (e & t) | (~e & i) + : A <= 47 + ? (e | ~t) ^ i + : A <= 63 + ? (e & i) | (t & ~i) + : e ^ (t | ~i); + } + function C(A) { + return A <= 15 + ? 0 + : A <= 31 + ? 1518500249 + : A <= 47 + ? 1859775393 + : A <= 63 + ? 2400959708 + : 2840853838; + } + function s(A) { + return A <= 15 + ? 1352829926 + : A <= 31 + ? 1548603684 + : A <= 47 + ? 1836072691 + : A <= 63 + ? 2053994217 + : 0; + } + i.inherits(a, o), + (t.ripemd160 = a), + (a.blockSize = 512), + (a.outSize = 160), + (a.hmacStrength = 192), + (a.padLength = 64), + (a.prototype._update = function (A, e) { + for ( + var t = this.h[0], + i = this.h[1], + g = this.h[2], + o = this.h[3], + a = this.h[4], + u = t, + d = i, + l = g, + w = o, + p = a, + D = 0; + D < 80; + D++ + ) { + var b = n(r(I(t, Q(D, i, g, o), A[c[D] + e], C(D)), f[D]), a); + (t = a), + (a = o), + (o = r(g, 10)), + (g = i), + (i = b), + (b = n( + r(I(u, Q(79 - D, d, l, w), A[h[D] + e], s(D)), E[D]), + p + )), + (u = p), + (p = w), + (w = r(l, 10)), + (l = d), + (d = b); + } + (b = B(this.h[1], g, w)), + (this.h[1] = B(this.h[2], o, p)), + (this.h[2] = B(this.h[3], a, u)), + (this.h[3] = B(this.h[4], t, d)), + (this.h[4] = B(this.h[0], i, l)), + (this.h[0] = b); + }), + (a.prototype._digest = function (A) { + return "hex" === A + ? i.toHex32(this.h, "little") + : i.split32(this.h, "little"); + }); + var c = [ + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 7, 4, 13, 1, + 10, 6, 15, 3, 12, 0, 9, 5, 2, 14, 11, 8, 3, 10, 14, 4, 9, 15, 8, 1, + 2, 7, 0, 6, 13, 11, 5, 12, 1, 9, 11, 10, 0, 8, 12, 4, 13, 3, 7, 15, + 14, 5, 6, 2, 4, 0, 5, 9, 7, 12, 2, 10, 14, 1, 3, 8, 11, 6, 15, 13, + ], + h = [ + 5, 14, 7, 0, 9, 2, 11, 4, 13, 6, 15, 8, 1, 10, 3, 12, 6, 11, 3, 7, + 0, 13, 5, 10, 14, 15, 8, 12, 4, 9, 1, 2, 15, 5, 1, 3, 7, 14, 6, 9, + 11, 8, 12, 2, 10, 0, 4, 13, 8, 6, 4, 1, 3, 11, 15, 0, 5, 12, 2, 13, + 9, 7, 10, 14, 12, 15, 10, 4, 1, 5, 8, 7, 6, 2, 13, 14, 0, 3, 9, 11, + ], + f = [ + 11, 14, 15, 12, 5, 8, 7, 9, 11, 13, 14, 15, 6, 7, 9, 8, 7, 6, 8, 13, + 11, 9, 7, 15, 7, 12, 15, 9, 11, 7, 13, 12, 11, 13, 6, 7, 14, 9, 13, + 15, 14, 8, 13, 6, 5, 12, 7, 5, 11, 12, 14, 15, 14, 15, 9, 8, 9, 14, + 5, 6, 8, 6, 5, 12, 9, 15, 5, 11, 6, 8, 13, 12, 5, 12, 13, 14, 11, 8, + 5, 6, + ], + E = [ + 8, 9, 9, 11, 13, 15, 15, 5, 7, 7, 8, 11, 14, 14, 12, 6, 9, 13, 15, + 7, 12, 8, 9, 11, 7, 7, 12, 7, 6, 15, 13, 11, 9, 7, 15, 11, 8, 6, 6, + 14, 12, 13, 5, 14, 13, 13, 7, 5, 15, 5, 8, 11, 14, 14, 6, 14, 6, 9, + 12, 9, 12, 5, 15, 8, 8, 5, 12, 9, 12, 5, 14, 6, 8, 13, 6, 5, 15, 13, + 11, 11, + ]; + }, + { "./common": 121, "./utils": 131 }, + ], + 124: [ + function (A, e, t) { + "use strict"; + (t.sha1 = A("./sha/1")), + (t.sha224 = A("./sha/224")), + (t.sha256 = A("./sha/256")), + (t.sha384 = A("./sha/384")), + (t.sha512 = A("./sha/512")); + }, + { + "./sha/1": 125, + "./sha/224": 126, + "./sha/256": 127, + "./sha/384": 128, + "./sha/512": 129, + }, + ], + 125: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = A("../common"), + r = A("./common"), + n = i.rotl32, + B = i.sum32, + I = i.sum32_5, + o = r.ft_1, + a = g.BlockHash, + Q = [1518500249, 1859775393, 2400959708, 3395469782]; + function C() { + if (!(this instanceof C)) return new C(); + a.call(this), + (this.h = [ + 1732584193, 4023233417, 2562383102, 271733878, 3285377520, + ]), + (this.W = new Array(80)); + } + i.inherits(C, a), + (e.exports = C), + (C.blockSize = 512), + (C.outSize = 160), + (C.hmacStrength = 80), + (C.padLength = 64), + (C.prototype._update = function (A, e) { + for (var t = this.W, i = 0; i < 16; i++) t[i] = A[e + i]; + for (; i < t.length; i++) + t[i] = n(t[i - 3] ^ t[i - 8] ^ t[i - 14] ^ t[i - 16], 1); + var g = this.h[0], + r = this.h[1], + a = this.h[2], + C = this.h[3], + s = this.h[4]; + for (i = 0; i < t.length; i++) { + var c = ~~(i / 20), + h = I(n(g, 5), o(c, r, a, C), s, t[i], Q[c]); + (s = C), (C = a), (a = n(r, 30)), (r = g), (g = h); + } + (this.h[0] = B(this.h[0], g)), + (this.h[1] = B(this.h[1], r)), + (this.h[2] = B(this.h[2], a)), + (this.h[3] = B(this.h[3], C)), + (this.h[4] = B(this.h[4], s)); + }), + (C.prototype._digest = function (A) { + return "hex" === A + ? i.toHex32(this.h, "big") + : i.split32(this.h, "big"); + }); + }, + { "../common": 121, "../utils": 131, "./common": 130 }, + ], + 126: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = A("./256"); + function r() { + if (!(this instanceof r)) return new r(); + g.call(this), + (this.h = [ + 3238371032, 914150663, 812702999, 4144912697, 4290775857, + 1750603025, 1694076839, 3204075428, + ]); + } + i.inherits(r, g), + (e.exports = r), + (r.blockSize = 512), + (r.outSize = 224), + (r.hmacStrength = 192), + (r.padLength = 64), + (r.prototype._digest = function (A) { + return "hex" === A + ? i.toHex32(this.h.slice(0, 7), "big") + : i.split32(this.h.slice(0, 7), "big"); + }); + }, + { "../utils": 131, "./256": 127 }, + ], + 127: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = A("../common"), + r = A("./common"), + n = A("minimalistic-assert"), + B = i.sum32, + I = i.sum32_4, + o = i.sum32_5, + a = r.ch32, + Q = r.maj32, + C = r.s0_256, + s = r.s1_256, + c = r.g0_256, + h = r.g1_256, + f = g.BlockHash, + E = [ + 1116352408, 1899447441, 3049323471, 3921009573, 961987163, + 1508970993, 2453635748, 2870763221, 3624381080, 310598401, + 607225278, 1426881987, 1925078388, 2162078206, 2614888103, + 3248222580, 3835390401, 4022224774, 264347078, 604807628, 770255983, + 1249150122, 1555081692, 1996064986, 2554220882, 2821834349, + 2952996808, 3210313671, 3336571891, 3584528711, 113926993, + 338241895, 666307205, 773529912, 1294757372, 1396182291, 1695183700, + 1986661051, 2177026350, 2456956037, 2730485921, 2820302411, + 3259730800, 3345764771, 3516065817, 3600352804, 4094571909, + 275423344, 430227734, 506948616, 659060556, 883997877, 958139571, + 1322822218, 1537002063, 1747873779, 1955562222, 2024104815, + 2227730452, 2361852424, 2428436474, 2756734187, 3204031479, + 3329325298, + ]; + function u() { + if (!(this instanceof u)) return new u(); + f.call(this), + (this.h = [ + 1779033703, 3144134277, 1013904242, 2773480762, 1359893119, + 2600822924, 528734635, 1541459225, + ]), + (this.k = E), + (this.W = new Array(64)); + } + i.inherits(u, f), + (e.exports = u), + (u.blockSize = 512), + (u.outSize = 256), + (u.hmacStrength = 192), + (u.padLength = 64), + (u.prototype._update = function (A, e) { + for (var t = this.W, i = 0; i < 16; i++) t[i] = A[e + i]; + for (; i < t.length; i++) + t[i] = I(h(t[i - 2]), t[i - 7], c(t[i - 15]), t[i - 16]); + var g = this.h[0], + r = this.h[1], + f = this.h[2], + E = this.h[3], + u = this.h[4], + d = this.h[5], + l = this.h[6], + w = this.h[7]; + for (n(this.k.length === t.length), i = 0; i < t.length; i++) { + var p = o(w, s(u), a(u, d, l), this.k[i], t[i]), + D = B(C(g), Q(g, r, f)); + (w = l), + (l = d), + (d = u), + (u = B(E, p)), + (E = f), + (f = r), + (r = g), + (g = B(p, D)); + } + (this.h[0] = B(this.h[0], g)), + (this.h[1] = B(this.h[1], r)), + (this.h[2] = B(this.h[2], f)), + (this.h[3] = B(this.h[3], E)), + (this.h[4] = B(this.h[4], u)), + (this.h[5] = B(this.h[5], d)), + (this.h[6] = B(this.h[6], l)), + (this.h[7] = B(this.h[7], w)); + }), + (u.prototype._digest = function (A) { + return "hex" === A + ? i.toHex32(this.h, "big") + : i.split32(this.h, "big"); + }); + }, + { + "../common": 121, + "../utils": 131, + "./common": 130, + "minimalistic-assert": 140, + }, + ], + 128: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = A("./512"); + function r() { + if (!(this instanceof r)) return new r(); + g.call(this), + (this.h = [ + 3418070365, 3238371032, 1654270250, 914150663, 2438529370, + 812702999, 355462360, 4144912697, 1731405415, 4290775857, + 2394180231, 1750603025, 3675008525, 1694076839, 1203062813, + 3204075428, + ]); + } + i.inherits(r, g), + (e.exports = r), + (r.blockSize = 1024), + (r.outSize = 384), + (r.hmacStrength = 192), + (r.padLength = 128), + (r.prototype._digest = function (A) { + return "hex" === A + ? i.toHex32(this.h.slice(0, 12), "big") + : i.split32(this.h.slice(0, 12), "big"); + }); + }, + { "../utils": 131, "./512": 129 }, + ], + 129: [ + function (A, e, t) { + "use strict"; + var i = A("../utils"), + g = A("../common"), + r = A("minimalistic-assert"), + n = i.rotr64_hi, + B = i.rotr64_lo, + I = i.shr64_hi, + o = i.shr64_lo, + a = i.sum64, + Q = i.sum64_hi, + C = i.sum64_lo, + s = i.sum64_4_hi, + c = i.sum64_4_lo, + h = i.sum64_5_hi, + f = i.sum64_5_lo, + E = g.BlockHash, + u = [ + 1116352408, 3609767458, 1899447441, 602891725, 3049323471, + 3964484399, 3921009573, 2173295548, 961987163, 4081628472, + 1508970993, 3053834265, 2453635748, 2937671579, 2870763221, + 3664609560, 3624381080, 2734883394, 310598401, 1164996542, + 607225278, 1323610764, 1426881987, 3590304994, 1925078388, + 4068182383, 2162078206, 991336113, 2614888103, 633803317, + 3248222580, 3479774868, 3835390401, 2666613458, 4022224774, + 944711139, 264347078, 2341262773, 604807628, 2007800933, 770255983, + 1495990901, 1249150122, 1856431235, 1555081692, 3175218132, + 1996064986, 2198950837, 2554220882, 3999719339, 2821834349, + 766784016, 2952996808, 2566594879, 3210313671, 3203337956, + 3336571891, 1034457026, 3584528711, 2466948901, 113926993, + 3758326383, 338241895, 168717936, 666307205, 1188179964, 773529912, + 1546045734, 1294757372, 1522805485, 1396182291, 2643833823, + 1695183700, 2343527390, 1986661051, 1014477480, 2177026350, + 1206759142, 2456956037, 344077627, 2730485921, 1290863460, + 2820302411, 3158454273, 3259730800, 3505952657, 3345764771, + 106217008, 3516065817, 3606008344, 3600352804, 1432725776, + 4094571909, 1467031594, 275423344, 851169720, 430227734, 3100823752, + 506948616, 1363258195, 659060556, 3750685593, 883997877, 3785050280, + 958139571, 3318307427, 1322822218, 3812723403, 1537002063, + 2003034995, 1747873779, 3602036899, 1955562222, 1575990012, + 2024104815, 1125592928, 2227730452, 2716904306, 2361852424, + 442776044, 2428436474, 593698344, 2756734187, 3733110249, + 3204031479, 2999351573, 3329325298, 3815920427, 3391569614, + 3928383900, 3515267271, 566280711, 3940187606, 3454069534, + 4118630271, 4000239992, 116418474, 1914138554, 174292421, + 2731055270, 289380356, 3203993006, 460393269, 320620315, 685471733, + 587496836, 852142971, 1086792851, 1017036298, 365543100, 1126000580, + 2618297676, 1288033470, 3409855158, 1501505948, 4234509866, + 1607167915, 987167468, 1816402316, 1246189591, + ]; + function d() { + if (!(this instanceof d)) return new d(); + E.call(this), + (this.h = [ + 1779033703, 4089235720, 3144134277, 2227873595, 1013904242, + 4271175723, 2773480762, 1595750129, 1359893119, 2917565137, + 2600822924, 725511199, 528734635, 4215389547, 1541459225, + 327033209, + ]), + (this.k = u), + (this.W = new Array(160)); + } + function l(A, e, t, i, g) { + var r = (A & t) ^ (~A & g); + return r < 0 && (r += 4294967296), r; + } + function w(A, e, t, i, g, r) { + var n = (e & i) ^ (~e & r); + return n < 0 && (n += 4294967296), n; + } + function p(A, e, t, i, g) { + var r = (A & t) ^ (A & g) ^ (t & g); + return r < 0 && (r += 4294967296), r; + } + function D(A, e, t, i, g, r) { + var n = (e & i) ^ (e & r) ^ (i & r); + return n < 0 && (n += 4294967296), n; + } + function b(A, e) { + var t = n(A, e, 28) ^ n(e, A, 2) ^ n(e, A, 7); + return t < 0 && (t += 4294967296), t; + } + function y(A, e) { + var t = B(A, e, 28) ^ B(e, A, 2) ^ B(e, A, 7); + return t < 0 && (t += 4294967296), t; + } + function M(A, e) { + var t = n(A, e, 14) ^ n(A, e, 18) ^ n(e, A, 9); + return t < 0 && (t += 4294967296), t; + } + function m(A, e) { + var t = B(A, e, 14) ^ B(A, e, 18) ^ B(e, A, 9); + return t < 0 && (t += 4294967296), t; + } + function G(A, e) { + var t = n(A, e, 1) ^ n(A, e, 8) ^ I(A, e, 7); + return t < 0 && (t += 4294967296), t; + } + function k(A, e) { + var t = B(A, e, 1) ^ B(A, e, 8) ^ o(A, e, 7); + return t < 0 && (t += 4294967296), t; + } + function F(A, e) { + var t = n(A, e, 19) ^ n(e, A, 29) ^ I(A, e, 6); + return t < 0 && (t += 4294967296), t; + } + function N(A, e) { + var t = B(A, e, 19) ^ B(e, A, 29) ^ o(A, e, 6); + return t < 0 && (t += 4294967296), t; + } + i.inherits(d, E), + (e.exports = d), + (d.blockSize = 1024), + (d.outSize = 512), + (d.hmacStrength = 192), + (d.padLength = 128), + (d.prototype._prepareBlock = function (A, e) { + for (var t = this.W, i = 0; i < 32; i++) t[i] = A[e + i]; + for (; i < t.length; i += 2) { + var g = F(t[i - 4], t[i - 3]), + r = N(t[i - 4], t[i - 3]), + n = t[i - 14], + B = t[i - 13], + I = G(t[i - 30], t[i - 29]), + o = k(t[i - 30], t[i - 29]), + a = t[i - 32], + Q = t[i - 31]; + (t[i] = s(g, r, n, B, I, o, a, Q)), + (t[i + 1] = c(g, r, n, B, I, o, a, Q)); + } + }), + (d.prototype._update = function (A, e) { + this._prepareBlock(A, e); + var t = this.W, + i = this.h[0], + g = this.h[1], + n = this.h[2], + B = this.h[3], + I = this.h[4], + o = this.h[5], + s = this.h[6], + c = this.h[7], + E = this.h[8], + u = this.h[9], + d = this.h[10], + G = this.h[11], + k = this.h[12], + F = this.h[13], + N = this.h[14], + S = this.h[15]; + r(this.k.length === t.length); + for (var Y = 0; Y < t.length; Y += 2) { + var v = N, + K = S, + U = M(E, u), + J = m(E, u), + H = l(E, u, d, G, k), + R = w(E, u, d, G, k, F), + q = this.k[Y], + L = this.k[Y + 1], + x = t[Y], + Z = t[Y + 1], + j = h(v, K, U, J, H, R, q, L, x, Z), + W = f(v, K, U, J, H, R, q, L, x, Z); + (v = b(i, g)), + (K = y(i, g)), + (U = p(i, g, n, B, I)), + (J = D(i, g, n, B, I, o)); + var O = Q(v, K, U, J), + P = C(v, K, U, J); + (N = k), + (S = F), + (k = d), + (F = G), + (d = E), + (G = u), + (E = Q(s, c, j, W)), + (u = C(c, c, j, W)), + (s = I), + (c = o), + (I = n), + (o = B), + (n = i), + (B = g), + (i = Q(j, W, O, P)), + (g = C(j, W, O, P)); + } + a(this.h, 0, i, g), + a(this.h, 2, n, B), + a(this.h, 4, I, o), + a(this.h, 6, s, c), + a(this.h, 8, E, u), + a(this.h, 10, d, G), + a(this.h, 12, k, F), + a(this.h, 14, N, S); + }), + (d.prototype._digest = function (A) { + return "hex" === A + ? i.toHex32(this.h, "big") + : i.split32(this.h, "big"); + }); + }, + { "../common": 121, "../utils": 131, "minimalistic-assert": 140 }, + ], + 130: [ + function (A, e, t) { + "use strict"; + var i = A("../utils").rotr32; + function g(A, e, t) { + return (A & e) ^ (~A & t); + } + function r(A, e, t) { + return (A & e) ^ (A & t) ^ (e & t); + } + function n(A, e, t) { + return A ^ e ^ t; + } + (t.ft_1 = function (A, e, t, i) { + return 0 === A + ? g(e, t, i) + : 1 === A || 3 === A + ? n(e, t, i) + : 2 === A + ? r(e, t, i) + : void 0; + }), + (t.ch32 = g), + (t.maj32 = r), + (t.p32 = n), + (t.s0_256 = function (A) { + return i(A, 2) ^ i(A, 13) ^ i(A, 22); + }), + (t.s1_256 = function (A) { + return i(A, 6) ^ i(A, 11) ^ i(A, 25); + }), + (t.g0_256 = function (A) { + return i(A, 7) ^ i(A, 18) ^ (A >>> 3); + }), + (t.g1_256 = function (A) { + return i(A, 17) ^ i(A, 19) ^ (A >>> 10); + }); + }, + { "../utils": 131 }, + ], + 131: [ + function (A, e, t) { + "use strict"; + var i = A("minimalistic-assert"), + g = A("inherits"); + function r(A, e) { + return ( + 55296 == (64512 & A.charCodeAt(e)) && + !(e < 0 || e + 1 >= A.length) && + 56320 == (64512 & A.charCodeAt(e + 1)) + ); + } + function n(A) { + return ( + ((A >>> 24) | + ((A >>> 8) & 65280) | + ((A << 8) & 16711680) | + ((255 & A) << 24)) >>> + 0 + ); + } + function B(A) { + return 1 === A.length ? "0" + A : A; + } + function I(A) { + return 7 === A.length + ? "0" + A + : 6 === A.length + ? "00" + A + : 5 === A.length + ? "000" + A + : 4 === A.length + ? "0000" + A + : 3 === A.length + ? "00000" + A + : 2 === A.length + ? "000000" + A + : 1 === A.length + ? "0000000" + A + : A; + } + (t.inherits = g), + (t.toArray = function (A, e) { + if (Array.isArray(A)) return A.slice(); + if (!A) return []; + var t = []; + if ("string" == typeof A) + if (e) { + if ("hex" === e) + for ( + (A = A.replace(/[^a-z0-9]+/gi, "")).length % 2 != 0 && + (A = "0" + A), + g = 0; + g < A.length; + g += 2 + ) + t.push(parseInt(A[g] + A[g + 1], 16)); + } else + for (var i = 0, g = 0; g < A.length; g++) { + var n = A.charCodeAt(g); + n < 128 + ? (t[i++] = n) + : n < 2048 + ? ((t[i++] = (n >> 6) | 192), (t[i++] = (63 & n) | 128)) + : r(A, g) + ? ((n = + 65536 + + ((1023 & n) << 10) + + (1023 & A.charCodeAt(++g))), + (t[i++] = (n >> 18) | 240), + (t[i++] = ((n >> 12) & 63) | 128), + (t[i++] = ((n >> 6) & 63) | 128), + (t[i++] = (63 & n) | 128)) + : ((t[i++] = (n >> 12) | 224), + (t[i++] = ((n >> 6) & 63) | 128), + (t[i++] = (63 & n) | 128)); + } + else for (g = 0; g < A.length; g++) t[g] = 0 | A[g]; + return t; + }), + (t.toHex = function (A) { + for (var e = "", t = 0; t < A.length; t++) + e += B(A[t].toString(16)); + return e; + }), + (t.htonl = n), + (t.toHex32 = function (A, e) { + for (var t = "", i = 0; i < A.length; i++) { + var g = A[i]; + "little" === e && (g = n(g)), (t += I(g.toString(16))); + } + return t; + }), + (t.zero2 = B), + (t.zero8 = I), + (t.join32 = function (A, e, t, g) { + var r = t - e; + i(r % 4 == 0); + for ( + var n = new Array(r / 4), B = 0, I = e; + B < n.length; + B++, I += 4 + ) { + var o; + (o = + "big" === g + ? (A[I] << 24) | (A[I + 1] << 16) | (A[I + 2] << 8) | A[I + 3] + : (A[I + 3] << 24) | + (A[I + 2] << 16) | + (A[I + 1] << 8) | + A[I]), + (n[B] = o >>> 0); + } + return n; + }), + (t.split32 = function (A, e) { + for ( + var t = new Array(4 * A.length), i = 0, g = 0; + i < A.length; + i++, g += 4 + ) { + var r = A[i]; + "big" === e + ? ((t[g] = r >>> 24), + (t[g + 1] = (r >>> 16) & 255), + (t[g + 2] = (r >>> 8) & 255), + (t[g + 3] = 255 & r)) + : ((t[g + 3] = r >>> 24), + (t[g + 2] = (r >>> 16) & 255), + (t[g + 1] = (r >>> 8) & 255), + (t[g] = 255 & r)); + } + return t; + }), + (t.rotr32 = function (A, e) { + return (A >>> e) | (A << (32 - e)); + }), + (t.rotl32 = function (A, e) { + return (A << e) | (A >>> (32 - e)); + }), + (t.sum32 = function (A, e) { + return (A + e) >>> 0; + }), + (t.sum32_3 = function (A, e, t) { + return (A + e + t) >>> 0; + }), + (t.sum32_4 = function (A, e, t, i) { + return (A + e + t + i) >>> 0; + }), + (t.sum32_5 = function (A, e, t, i, g) { + return (A + e + t + i + g) >>> 0; + }), + (t.sum64 = function (A, e, t, i) { + var g = A[e], + r = (i + A[e + 1]) >>> 0, + n = (r < i ? 1 : 0) + t + g; + (A[e] = n >>> 0), (A[e + 1] = r); + }), + (t.sum64_hi = function (A, e, t, i) { + return (((e + i) >>> 0 < e ? 1 : 0) + A + t) >>> 0; + }), + (t.sum64_lo = function (A, e, t, i) { + return (e + i) >>> 0; + }), + (t.sum64_4_hi = function (A, e, t, i, g, r, n, B) { + var I = 0, + o = e; + return ( + (I += (o = (o + i) >>> 0) < e ? 1 : 0), + (I += (o = (o + r) >>> 0) < r ? 1 : 0), + (A + t + g + n + (I += (o = (o + B) >>> 0) < B ? 1 : 0)) >>> 0 + ); + }), + (t.sum64_4_lo = function (A, e, t, i, g, r, n, B) { + return (e + i + r + B) >>> 0; + }), + (t.sum64_5_hi = function (A, e, t, i, g, r, n, B, I, o) { + var a = 0, + Q = e; + return ( + (a += (Q = (Q + i) >>> 0) < e ? 1 : 0), + (a += (Q = (Q + r) >>> 0) < r ? 1 : 0), + (a += (Q = (Q + B) >>> 0) < B ? 1 : 0), + (A + t + g + n + I + (a += (Q = (Q + o) >>> 0) < o ? 1 : 0)) >>> 0 + ); + }), + (t.sum64_5_lo = function (A, e, t, i, g, r, n, B, I, o) { + return (e + i + r + B + o) >>> 0; + }), + (t.rotr64_hi = function (A, e, t) { + return ((e << (32 - t)) | (A >>> t)) >>> 0; + }), + (t.rotr64_lo = function (A, e, t) { + return ((A << (32 - t)) | (e >>> t)) >>> 0; + }), + (t.shr64_hi = function (A, e, t) { + return A >>> t; + }), + (t.shr64_lo = function (A, e, t) { + return ((A << (32 - t)) | (e >>> t)) >>> 0; + }); + }, + { inherits: 134, "minimalistic-assert": 140 }, + ], + 132: [ + function (A, e, t) { + "use strict"; + var i = A("hash.js"), + g = A("minimalistic-crypto-utils"), + r = A("minimalistic-assert"); + function n(A) { + if (!(this instanceof n)) return new n(A); + (this.hash = A.hash), + (this.predResist = !!A.predResist), + (this.outLen = this.hash.outSize), + (this.minEntropy = A.minEntropy || this.hash.hmacStrength), + (this._reseed = null), + (this.reseedInterval = null), + (this.K = null), + (this.V = null); + var e = g.toArray(A.entropy, A.entropyEnc || "hex"), + t = g.toArray(A.nonce, A.nonceEnc || "hex"), + i = g.toArray(A.pers, A.persEnc || "hex"); + r( + e.length >= this.minEntropy / 8, + "Not enough entropy. Minimum is: " + this.minEntropy + " bits" + ), + this._init(e, t, i); + } + (e.exports = n), + (n.prototype._init = function (A, e, t) { + var i = A.concat(e).concat(t); + (this.K = new Array(this.outLen / 8)), + (this.V = new Array(this.outLen / 8)); + for (var g = 0; g < this.V.length; g++) + (this.K[g] = 0), (this.V[g] = 1); + this._update(i), + (this._reseed = 1), + (this.reseedInterval = 281474976710656); + }), + (n.prototype._hmac = function () { + return new i.hmac(this.hash, this.K); + }), + (n.prototype._update = function (A) { + var e = this._hmac().update(this.V).update([0]); + A && (e = e.update(A)), + (this.K = e.digest()), + (this.V = this._hmac().update(this.V).digest()), + A && + ((this.K = this._hmac() + .update(this.V) + .update([1]) + .update(A) + .digest()), + (this.V = this._hmac().update(this.V).digest())); + }), + (n.prototype.reseed = function (A, e, t, i) { + "string" != typeof e && ((i = t), (t = e), (e = null)), + (A = g.toArray(A, e)), + (t = g.toArray(t, i)), + r( + A.length >= this.minEntropy / 8, + "Not enough entropy. Minimum is: " + this.minEntropy + " bits" + ), + this._update(A.concat(t || [])), + (this._reseed = 1); + }), + (n.prototype.generate = function (A, e, t, i) { + if (this._reseed > this.reseedInterval) + throw new Error("Reseed is required"); + "string" != typeof e && ((i = t), (t = e), (e = null)), + t && ((t = g.toArray(t, i || "hex")), this._update(t)); + for (var r = []; r.length < A; ) + (this.V = this._hmac().update(this.V).digest()), + (r = r.concat(this.V)); + var n = r.slice(0, A); + return this._update(t), this._reseed++, g.encode(n, e); + }); + }, + { + "hash.js": 120, + "minimalistic-assert": 140, + "minimalistic-crypto-utils": 141, + }, + ], + 133: [ + function (A, e, t) { + (t.read = function (A, e, t, i, g) { + var r, + n, + B = 8 * g - i - 1, + I = (1 << B) - 1, + o = I >> 1, + a = -7, + Q = t ? g - 1 : 0, + C = t ? -1 : 1, + s = A[e + Q]; + for ( + Q += C, r = s & ((1 << -a) - 1), s >>= -a, a += B; + a > 0; + r = 256 * r + A[e + Q], Q += C, a -= 8 + ); + for ( + n = r & ((1 << -a) - 1), r >>= -a, a += i; + a > 0; + n = 256 * n + A[e + Q], Q += C, a -= 8 + ); + if (0 === r) r = 1 - o; + else { + if (r === I) return n ? NaN : (1 / 0) * (s ? -1 : 1); + (n += Math.pow(2, i)), (r -= o); + } + return (s ? -1 : 1) * n * Math.pow(2, r - i); + }), + (t.write = function (A, e, t, i, g, r) { + var n, + B, + I, + o = 8 * r - g - 1, + a = (1 << o) - 1, + Q = a >> 1, + C = 23 === g ? Math.pow(2, -24) - Math.pow(2, -77) : 0, + s = i ? 0 : r - 1, + c = i ? 1 : -1, + h = e < 0 || (0 === e && 1 / e < 0) ? 1 : 0; + for ( + e = Math.abs(e), + isNaN(e) || e === 1 / 0 + ? ((B = isNaN(e) ? 1 : 0), (n = a)) + : ((n = Math.floor(Math.log(e) / Math.LN2)), + e * (I = Math.pow(2, -n)) < 1 && (n--, (I *= 2)), + (e += n + Q >= 1 ? C / I : C * Math.pow(2, 1 - Q)) * I >= + 2 && (n++, (I /= 2)), + n + Q >= a + ? ((B = 0), (n = a)) + : n + Q >= 1 + ? ((B = (e * I - 1) * Math.pow(2, g)), (n += Q)) + : ((B = e * Math.pow(2, Q - 1) * Math.pow(2, g)), + (n = 0))); + g >= 8; + A[t + s] = 255 & B, s += c, B /= 256, g -= 8 + ); + for ( + n = (n << g) | B, o += g; + o > 0; + A[t + s] = 255 & n, s += c, n /= 256, o -= 8 + ); + A[t + s - c] |= 128 * h; + }); + }, + {}, + ], + 134: [ + function (A, e, t) { + "function" == typeof Object.create + ? (e.exports = function (A, e) { + e && + ((A.super_ = e), + (A.prototype = Object.create(e.prototype, { + constructor: { + value: A, + enumerable: !1, + writable: !0, + configurable: !0, + }, + }))); + }) + : (e.exports = function (A, e) { + if (e) { + A.super_ = e; + var t = function () {}; + (t.prototype = e.prototype), + (A.prototype = new t()), + (A.prototype.constructor = A); + } + }); + }, + {}, + ], + 135: [ + function (A, e, t) { + function i(A) { + return ( + !!A.constructor && + "function" == typeof A.constructor.isBuffer && + A.constructor.isBuffer(A) + ); + } + e.exports = function (A) { + return ( + null != A && + (i(A) || + (function (A) { + return ( + "function" == typeof A.readFloatLE && + "function" == typeof A.slice && + i(A.slice(0, 0)) + ); + })(A) || + !!A._isBuffer) + ); + }; + }, + {}, + ], + 136: [ + function (A, e, t) { + var i = {}.toString; + e.exports = + Array.isArray || + function (A) { + return "[object Array]" == i.call(A); + }; + }, + {}, + ], + 137: [ + function (A, e, t) { + "use strict"; + var i = A("inherits"), + g = A("hash-base"), + r = A("safe-buffer").Buffer, + n = new Array(16); + function B() { + g.call(this, 64), + (this._a = 1732584193), + (this._b = 4023233417), + (this._c = 2562383102), + (this._d = 271733878); + } + function I(A, e) { + return (A << e) | (A >>> (32 - e)); + } + function o(A, e, t, i, g, r, n) { + return (I((A + ((e & t) | (~e & i)) + g + r) | 0, n) + e) | 0; + } + function a(A, e, t, i, g, r, n) { + return (I((A + ((e & i) | (t & ~i)) + g + r) | 0, n) + e) | 0; + } + function Q(A, e, t, i, g, r, n) { + return (I((A + (e ^ t ^ i) + g + r) | 0, n) + e) | 0; + } + function C(A, e, t, i, g, r, n) { + return (I((A + (t ^ (e | ~i)) + g + r) | 0, n) + e) | 0; + } + i(B, g), + (B.prototype._update = function () { + for (var A = n, e = 0; e < 16; ++e) + A[e] = this._block.readInt32LE(4 * e); + var t = this._a, + i = this._b, + g = this._c, + r = this._d; + (i = C( + (i = C( + (i = C( + (i = C( + (i = Q( + (i = Q( + (i = Q( + (i = Q( + (i = a( + (i = a( + (i = a( + (i = a( + (i = o( + (i = o( + (i = o( + (i = o( + i, + (g = o( + g, + (r = o( + r, + (t = o( + t, + i, + g, + r, + A[0], + 3614090360, + 7 + )), + i, + g, + A[1], + 3905402710, + 12 + )), + t, + i, + A[2], + 606105819, + 17 + )), + r, + t, + A[3], + 3250441966, + 22 + )), + (g = o( + g, + (r = o( + r, + (t = o( + t, + i, + g, + r, + A[4], + 4118548399, + 7 + )), + i, + g, + A[5], + 1200080426, + 12 + )), + t, + i, + A[6], + 2821735955, + 17 + )), + r, + t, + A[7], + 4249261313, + 22 + )), + (g = o( + g, + (r = o( + r, + (t = o( + t, + i, + g, + r, + A[8], + 1770035416, + 7 + )), + i, + g, + A[9], + 2336552879, + 12 + )), + t, + i, + A[10], + 4294925233, + 17 + )), + r, + t, + A[11], + 2304563134, + 22 + )), + (g = o( + g, + (r = o( + r, + (t = o( + t, + i, + g, + r, + A[12], + 1804603682, + 7 + )), + i, + g, + A[13], + 4254626195, + 12 + )), + t, + i, + A[14], + 2792965006, + 17 + )), + r, + t, + A[15], + 1236535329, + 22 + )), + (g = a( + g, + (r = a( + r, + (t = a( + t, + i, + g, + r, + A[1], + 4129170786, + 5 + )), + i, + g, + A[6], + 3225465664, + 9 + )), + t, + i, + A[11], + 643717713, + 14 + )), + r, + t, + A[0], + 3921069994, + 20 + )), + (g = a( + g, + (r = a( + r, + (t = a(t, i, g, r, A[5], 3593408605, 5)), + i, + g, + A[10], + 38016083, + 9 + )), + t, + i, + A[15], + 3634488961, + 14 + )), + r, + t, + A[4], + 3889429448, + 20 + )), + (g = a( + g, + (r = a( + r, + (t = a(t, i, g, r, A[9], 568446438, 5)), + i, + g, + A[14], + 3275163606, + 9 + )), + t, + i, + A[3], + 4107603335, + 14 + )), + r, + t, + A[8], + 1163531501, + 20 + )), + (g = a( + g, + (r = a( + r, + (t = a(t, i, g, r, A[13], 2850285829, 5)), + i, + g, + A[2], + 4243563512, + 9 + )), + t, + i, + A[7], + 1735328473, + 14 + )), + r, + t, + A[12], + 2368359562, + 20 + )), + (g = Q( + g, + (r = Q( + r, + (t = Q(t, i, g, r, A[5], 4294588738, 4)), + i, + g, + A[8], + 2272392833, + 11 + )), + t, + i, + A[11], + 1839030562, + 16 + )), + r, + t, + A[14], + 4259657740, + 23 + )), + (g = Q( + g, + (r = Q( + r, + (t = Q(t, i, g, r, A[1], 2763975236, 4)), + i, + g, + A[4], + 1272893353, + 11 + )), + t, + i, + A[7], + 4139469664, + 16 + )), + r, + t, + A[10], + 3200236656, + 23 + )), + (g = Q( + g, + (r = Q( + r, + (t = Q(t, i, g, r, A[13], 681279174, 4)), + i, + g, + A[0], + 3936430074, + 11 + )), + t, + i, + A[3], + 3572445317, + 16 + )), + r, + t, + A[6], + 76029189, + 23 + )), + (g = Q( + g, + (r = Q( + r, + (t = Q(t, i, g, r, A[9], 3654602809, 4)), + i, + g, + A[12], + 3873151461, + 11 + )), + t, + i, + A[15], + 530742520, + 16 + )), + r, + t, + A[2], + 3299628645, + 23 + )), + (g = C( + g, + (r = C( + r, + (t = C(t, i, g, r, A[0], 4096336452, 6)), + i, + g, + A[7], + 1126891415, + 10 + )), + t, + i, + A[14], + 2878612391, + 15 + )), + r, + t, + A[5], + 4237533241, + 21 + )), + (g = C( + g, + (r = C( + r, + (t = C(t, i, g, r, A[12], 1700485571, 6)), + i, + g, + A[3], + 2399980690, + 10 + )), + t, + i, + A[10], + 4293915773, + 15 + )), + r, + t, + A[1], + 2240044497, + 21 + )), + (g = C( + g, + (r = C( + r, + (t = C(t, i, g, r, A[8], 1873313359, 6)), + i, + g, + A[15], + 4264355552, + 10 + )), + t, + i, + A[6], + 2734768916, + 15 + )), + r, + t, + A[13], + 1309151649, + 21 + )), + (g = C( + g, + (r = C( + r, + (t = C(t, i, g, r, A[4], 4149444226, 6)), + i, + g, + A[11], + 3174756917, + 10 + )), + t, + i, + A[2], + 718787259, + 15 + )), + r, + t, + A[9], + 3951481745, + 21 + )), + (this._a = (this._a + t) | 0), + (this._b = (this._b + i) | 0), + (this._c = (this._c + g) | 0), + (this._d = (this._d + r) | 0); + }), + (B.prototype._digest = function () { + (this._block[this._blockOffset++] = 128), + this._blockOffset > 56 && + (this._block.fill(0, this._blockOffset, 64), + this._update(), + (this._blockOffset = 0)), + this._block.fill(0, this._blockOffset, 56), + this._block.writeUInt32LE(this._length[0], 56), + this._block.writeUInt32LE(this._length[1], 60), + this._update(); + var A = r.allocUnsafe(16); + return ( + A.writeInt32LE(this._a, 0), + A.writeInt32LE(this._b, 4), + A.writeInt32LE(this._c, 8), + A.writeInt32LE(this._d, 12), + A + ); + }), + (e.exports = B); + }, + { "hash-base": 104, inherits: 134, "safe-buffer": 180 }, + ], + 138: [ + function (A, e, t) { + var i = A("bn.js"), + g = A("brorand"); + function r(A) { + this.rand = A || new g.Rand(); + } + (e.exports = r), + (r.create = function (A) { + return new r(A); + }), + (r.prototype._randbelow = function (A) { + var e = A.bitLength(), + t = Math.ceil(e / 8); + do { + var g = new i(this.rand.generate(t)); + } while (g.cmp(A) >= 0); + return g; + }), + (r.prototype._randrange = function (A, e) { + var t = e.sub(A); + return A.add(this._randbelow(t)); + }), + (r.prototype.test = function (A, e, t) { + var g = A.bitLength(), + r = i.mont(A), + n = new i(1).toRed(r); + e || (e = Math.max(1, (g / 48) | 0)); + for (var B = A.subn(1), I = 0; !B.testn(I); I++); + for (var o = A.shrn(I), a = B.toRed(r); e > 0; e--) { + var Q = this._randrange(new i(2), B); + t && t(Q); + var C = Q.toRed(r).redPow(o); + if (0 !== C.cmp(n) && 0 !== C.cmp(a)) { + for (var s = 1; s < I; s++) { + if (0 === (C = C.redSqr()).cmp(n)) return !1; + if (0 === C.cmp(a)) break; + } + if (s === I) return !1; + } + } + return !0; + }), + (r.prototype.getDivisor = function (A, e) { + var t = A.bitLength(), + g = i.mont(A), + r = new i(1).toRed(g); + e || (e = Math.max(1, (t / 48) | 0)); + for (var n = A.subn(1), B = 0; !n.testn(B); B++); + for (var I = A.shrn(B), o = n.toRed(g); e > 0; e--) { + var a = this._randrange(new i(2), n), + Q = A.gcd(a); + if (0 !== Q.cmpn(1)) return Q; + var C = a.toRed(g).redPow(I); + if (0 !== C.cmp(r) && 0 !== C.cmp(o)) { + for (var s = 1; s < B; s++) { + if (0 === (C = C.redSqr()).cmp(r)) + return C.fromRed().subn(1).gcd(A); + if (0 === C.cmp(o)) break; + } + if (s === B) return (C = C.redSqr()).fromRed().subn(1).gcd(A); + } + } + return !1; + }); + }, + { "bn.js": 139, brorand: 18 }, + ], + 139: [ + function (A, e, t) { + arguments[4][15][0].apply(t, arguments); + }, + { buffer: 19, dup: 15 }, + ], + 140: [ + function (A, e, t) { + function i(A, e) { + if (!A) throw new Error(e || "Assertion failed"); + } + (e.exports = i), + (i.equal = function (A, e, t) { + if (A != e) + throw new Error(t || "Assertion failed: " + A + " != " + e); + }); + }, + {}, + ], + 141: [ + function (A, e, t) { + "use strict"; + var i = t; + function g(A) { + return 1 === A.length ? "0" + A : A; + } + function r(A) { + for (var e = "", t = 0; t < A.length; t++) e += g(A[t].toString(16)); + return e; + } + (i.toArray = function (A, e) { + if (Array.isArray(A)) return A.slice(); + if (!A) return []; + var t = []; + if ("string" != typeof A) { + for (var i = 0; i < A.length; i++) t[i] = 0 | A[i]; + return t; + } + if ("hex" === e) + for ( + (A = A.replace(/[^a-z0-9]+/gi, "")).length % 2 != 0 && + (A = "0" + A), + i = 0; + i < A.length; + i += 2 + ) + t.push(parseInt(A[i] + A[i + 1], 16)); + else + for (i = 0; i < A.length; i++) { + var g = A.charCodeAt(i), + r = g >> 8, + n = 255 & g; + r ? t.push(r, n) : t.push(n); + } + return t; + }), + (i.zero2 = g), + (i.toHex = r), + (i.encode = function (A, e) { + return "hex" === e ? r(A) : A; + }); + }, + {}, + ], + 142: [ + function (A, e, t) { + e.exports = { + "2.16.840.1.101.3.4.1.1": "aes-128-ecb", + "2.16.840.1.101.3.4.1.2": "aes-128-cbc", + "2.16.840.1.101.3.4.1.3": "aes-128-ofb", + "2.16.840.1.101.3.4.1.4": "aes-128-cfb", + "2.16.840.1.101.3.4.1.21": "aes-192-ecb", + "2.16.840.1.101.3.4.1.22": "aes-192-cbc", + "2.16.840.1.101.3.4.1.23": "aes-192-ofb", + "2.16.840.1.101.3.4.1.24": "aes-192-cfb", + "2.16.840.1.101.3.4.1.41": "aes-256-ecb", + "2.16.840.1.101.3.4.1.42": "aes-256-cbc", + "2.16.840.1.101.3.4.1.43": "aes-256-ofb", + "2.16.840.1.101.3.4.1.44": "aes-256-cfb", + }; + }, + {}, + ], + 143: [ + function (A, e, t) { + "use strict"; + var i = A("asn1.js"); + t.certificate = A("./certificate"); + var g = i.define("RSAPrivateKey", function () { + this.seq().obj( + this.key("version").int(), + this.key("modulus").int(), + this.key("publicExponent").int(), + this.key("privateExponent").int(), + this.key("prime1").int(), + this.key("prime2").int(), + this.key("exponent1").int(), + this.key("exponent2").int(), + this.key("coefficient").int() + ); + }); + t.RSAPrivateKey = g; + var r = i.define("RSAPublicKey", function () { + this.seq().obj( + this.key("modulus").int(), + this.key("publicExponent").int() + ); + }); + t.RSAPublicKey = r; + var n = i.define("SubjectPublicKeyInfo", function () { + this.seq().obj( + this.key("algorithm").use(B), + this.key("subjectPublicKey").bitstr() + ); + }); + t.PublicKey = n; + var B = i.define("AlgorithmIdentifier", function () { + this.seq().obj( + this.key("algorithm").objid(), + this.key("none").null_().optional(), + this.key("curve").objid().optional(), + this.key("params") + .seq() + .obj( + this.key("p").int(), + this.key("q").int(), + this.key("g").int() + ) + .optional() + ); + }), + I = i.define("PrivateKeyInfo", function () { + this.seq().obj( + this.key("version").int(), + this.key("algorithm").use(B), + this.key("subjectPrivateKey").octstr() + ); + }); + t.PrivateKey = I; + var o = i.define("EncryptedPrivateKeyInfo", function () { + this.seq().obj( + this.key("algorithm") + .seq() + .obj( + this.key("id").objid(), + this.key("decrypt") + .seq() + .obj( + this.key("kde") + .seq() + .obj( + this.key("id").objid(), + this.key("kdeparams") + .seq() + .obj( + this.key("salt").octstr(), + this.key("iters").int() + ) + ), + this.key("cipher") + .seq() + .obj(this.key("algo").objid(), this.key("iv").octstr()) + ) + ), + this.key("subjectPrivateKey").octstr() + ); + }); + t.EncryptedPrivateKey = o; + var a = i.define("DSAPrivateKey", function () { + this.seq().obj( + this.key("version").int(), + this.key("p").int(), + this.key("q").int(), + this.key("g").int(), + this.key("pub_key").int(), + this.key("priv_key").int() + ); + }); + (t.DSAPrivateKey = a), + (t.DSAparam = i.define("DSAparam", function () { + this.int(); + })); + var Q = i.define("ECPrivateKey", function () { + this.seq().obj( + this.key("version").int(), + this.key("privateKey").octstr(), + this.key("parameters").optional().explicit(0).use(C), + this.key("publicKey").optional().explicit(1).bitstr() + ); + }); + t.ECPrivateKey = Q; + var C = i.define("ECParameters", function () { + this.choice({ namedCurve: this.objid() }); + }); + t.signature = i.define("signature", function () { + this.seq().obj(this.key("r").int(), this.key("s").int()); + }); + }, + { "./certificate": 144, "asn1.js": 1 }, + ], + 144: [ + function (A, e, t) { + "use strict"; + var i = A("asn1.js"), + g = i.define("Time", function () { + this.choice({ + utcTime: this.utctime(), + generalTime: this.gentime(), + }); + }), + r = i.define("AttributeTypeValue", function () { + this.seq().obj(this.key("type").objid(), this.key("value").any()); + }), + n = i.define("AlgorithmIdentifier", function () { + this.seq().obj( + this.key("algorithm").objid(), + this.key("parameters").optional(), + this.key("curve").objid().optional() + ); + }), + B = i.define("SubjectPublicKeyInfo", function () { + this.seq().obj( + this.key("algorithm").use(n), + this.key("subjectPublicKey").bitstr() + ); + }), + I = i.define("RelativeDistinguishedName", function () { + this.setof(r); + }), + o = i.define("RDNSequence", function () { + this.seqof(I); + }), + a = i.define("Name", function () { + this.choice({ rdnSequence: this.use(o) }); + }), + Q = i.define("Validity", function () { + this.seq().obj( + this.key("notBefore").use(g), + this.key("notAfter").use(g) + ); + }), + C = i.define("Extension", function () { + this.seq().obj( + this.key("extnID").objid(), + this.key("critical").bool().def(!1), + this.key("extnValue").octstr() + ); + }), + s = i.define("TBSCertificate", function () { + this.seq().obj( + this.key("version").explicit(0).int().optional(), + this.key("serialNumber").int(), + this.key("signature").use(n), + this.key("issuer").use(a), + this.key("validity").use(Q), + this.key("subject").use(a), + this.key("subjectPublicKeyInfo").use(B), + this.key("issuerUniqueID").implicit(1).bitstr().optional(), + this.key("subjectUniqueID").implicit(2).bitstr().optional(), + this.key("extensions").explicit(3).seqof(C).optional() + ); + }), + c = i.define("X509Certificate", function () { + this.seq().obj( + this.key("tbsCertificate").use(s), + this.key("signatureAlgorithm").use(n), + this.key("signatureValue").bitstr() + ); + }); + e.exports = c; + }, + { "asn1.js": 1 }, + ], + 145: [ + function (A, e, t) { + var i = + /Proc-Type: 4,ENCRYPTED[\n\r]+DEK-Info: AES-((?:128)|(?:192)|(?:256))-CBC,([0-9A-H]+)[\n\r]+([0-9A-z\n\r+/=]+)[\n\r]+/m, + g = /^-----BEGIN ((?:.*? KEY)|CERTIFICATE)-----/m, + r = + /^-----BEGIN ((?:.*? KEY)|CERTIFICATE)-----([0-9A-z\n\r+/=]+)-----END \1-----$/m, + n = A("evp_bytestokey"), + B = A("browserify-aes"), + I = A("safe-buffer").Buffer; + e.exports = function (A, e) { + var t, + o = A.toString(), + a = o.match(i); + if (a) { + var Q = "aes" + a[1], + C = I.from(a[2], "hex"), + s = I.from(a[3].replace(/[\r\n]/g, ""), "base64"), + c = n(e, C.slice(0, 8), parseInt(a[1], 10)).key, + h = [], + f = B.createDecipheriv(Q, c, C); + h.push(f.update(s)), h.push(f.final()), (t = I.concat(h)); + } else { + var E = o.match(r); + t = I.from(E[2].replace(/[\r\n]/g, ""), "base64"); + } + return { tag: o.match(g)[1], data: t }; + }; + }, + { "browserify-aes": 22, evp_bytestokey: 103, "safe-buffer": 180 }, + ], + 146: [ + function (A, e, t) { + var i = A("./asn1"), + g = A("./aesid.json"), + r = A("./fixProc"), + n = A("browserify-aes"), + B = A("pbkdf2"), + I = A("safe-buffer").Buffer; + function o(A) { + var e; + "object" != typeof A || + I.isBuffer(A) || + ((e = A.passphrase), (A = A.key)), + "string" == typeof A && (A = I.from(A)); + var t, + o, + a = r(A, e), + Q = a.tag, + C = a.data; + switch (Q) { + case "CERTIFICATE": + o = i.certificate.decode(C, "der").tbsCertificate + .subjectPublicKeyInfo; + case "PUBLIC KEY": + switch ( + (o || (o = i.PublicKey.decode(C, "der")), + (t = o.algorithm.algorithm.join("."))) + ) { + case "1.2.840.113549.1.1.1": + return i.RSAPublicKey.decode(o.subjectPublicKey.data, "der"); + case "1.2.840.10045.2.1": + return ( + (o.subjectPrivateKey = o.subjectPublicKey), + { type: "ec", data: o } + ); + case "1.2.840.10040.4.1": + return ( + (o.algorithm.params.pub_key = i.DSAparam.decode( + o.subjectPublicKey.data, + "der" + )), + { type: "dsa", data: o.algorithm.params } + ); + default: + throw new Error("unknown key id " + t); + } + case "ENCRYPTED PRIVATE KEY": + C = (function (A, e) { + var t = A.algorithm.decrypt.kde.kdeparams.salt, + i = parseInt( + A.algorithm.decrypt.kde.kdeparams.iters.toString(), + 10 + ), + r = g[A.algorithm.decrypt.cipher.algo.join(".")], + o = A.algorithm.decrypt.cipher.iv, + a = A.subjectPrivateKey, + Q = parseInt(r.split("-")[1], 10) / 8, + C = B.pbkdf2Sync(e, t, i, Q, "sha1"), + s = n.createDecipheriv(r, C, o), + c = []; + return c.push(s.update(a)), c.push(s.final()), I.concat(c); + })((C = i.EncryptedPrivateKey.decode(C, "der")), e); + case "PRIVATE KEY": + switch ( + (t = (o = i.PrivateKey.decode( + C, + "der" + )).algorithm.algorithm.join(".")) + ) { + case "1.2.840.113549.1.1.1": + return i.RSAPrivateKey.decode(o.subjectPrivateKey, "der"); + case "1.2.840.10045.2.1": + return { + curve: o.algorithm.curve, + privateKey: i.ECPrivateKey.decode( + o.subjectPrivateKey, + "der" + ).privateKey, + }; + case "1.2.840.10040.4.1": + return ( + (o.algorithm.params.priv_key = i.DSAparam.decode( + o.subjectPrivateKey, + "der" + )), + { type: "dsa", params: o.algorithm.params } + ); + default: + throw new Error("unknown key id " + t); + } + case "RSA PUBLIC KEY": + return i.RSAPublicKey.decode(C, "der"); + case "RSA PRIVATE KEY": + return i.RSAPrivateKey.decode(C, "der"); + case "DSA PRIVATE KEY": + return { type: "dsa", params: i.DSAPrivateKey.decode(C, "der") }; + case "EC PRIVATE KEY": + return { + curve: (C = i.ECPrivateKey.decode(C, "der")).parameters.value, + privateKey: C.privateKey, + }; + default: + throw new Error("unknown key type " + Q); + } + } + (e.exports = o), (o.signature = i.signature); + }, + { + "./aesid.json": 142, + "./asn1": 143, + "./fixProc": 145, + "browserify-aes": 22, + pbkdf2: 147, + "safe-buffer": 180, + }, + ], + 147: [ + function (A, e, t) { + (t.pbkdf2 = A("./lib/async")), (t.pbkdf2Sync = A("./lib/sync")); + }, + { "./lib/async": 148, "./lib/sync": 151 }, + ], + 148: [ + function (A, e, t) { + (function (t, i) { + var g, + r = A("safe-buffer").Buffer, + n = A("./precondition"), + B = A("./default-encoding"), + I = A("./sync"), + o = A("./to-buffer"), + a = i.crypto && i.crypto.subtle, + Q = { + sha: "SHA-1", + "sha-1": "SHA-1", + sha1: "SHA-1", + sha256: "SHA-256", + "sha-256": "SHA-256", + sha384: "SHA-384", + "sha-384": "SHA-384", + "sha-512": "SHA-512", + sha512: "SHA-512", + }, + C = []; + function s(A, e, t, i, g) { + return a + .importKey("raw", A, { name: "PBKDF2" }, !1, ["deriveBits"]) + .then(function (A) { + return a.deriveBits( + { name: "PBKDF2", salt: e, iterations: t, hash: { name: g } }, + A, + i << 3 + ); + }) + .then(function (A) { + return r.from(A); + }); + } + e.exports = function (A, e, c, h, f, E) { + "function" == typeof f && ((E = f), (f = void 0)); + var u = Q[(f = f || "sha1").toLowerCase()]; + if (!u || "function" != typeof i.Promise) + return t.nextTick(function () { + var t; + try { + t = I(A, e, c, h, f); + } catch (A) { + return E(A); + } + E(null, t); + }); + if ( + (n(c, h), + (A = o(A, B, "Password")), + (e = o(e, B, "Salt")), + "function" != typeof E) + ) + throw new Error("No callback provided to pbkdf2"); + !(function (A, e) { + A.then( + function (A) { + t.nextTick(function () { + e(null, A); + }); + }, + function (A) { + t.nextTick(function () { + e(A); + }); + } + ); + })( + (function (A) { + if (i.process && !i.process.browser) return Promise.resolve(!1); + if (!a || !a.importKey || !a.deriveBits) + return Promise.resolve(!1); + if (void 0 !== C[A]) return C[A]; + var e = s((g = g || r.alloc(8)), g, 10, 128, A) + .then(function () { + return !0; + }) + .catch(function () { + return !1; + }); + return (C[A] = e), e; + })(u).then(function (t) { + return t ? s(A, e, c, h, u) : I(A, e, c, h, f); + }), + E + ); + }; + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { + "./default-encoding": 149, + "./precondition": 150, + "./sync": 151, + "./to-buffer": 152, + _process: 154, + "safe-buffer": 180, + }, + ], + 149: [ + function (A, e, t) { + (function (A) { + var t; + if (A.browser) t = "utf-8"; + else if (A.version) { + t = + parseInt(A.version.split(".")[0].slice(1), 10) >= 6 + ? "utf-8" + : "binary"; + } else t = "utf-8"; + e.exports = t; + }.call(this, A("_process"))); + }, + { _process: 154 }, + ], + 150: [ + function (A, e, t) { + var i = Math.pow(2, 30) - 1; + e.exports = function (A, e) { + if ("number" != typeof A) + throw new TypeError("Iterations not a number"); + if (A < 0) throw new TypeError("Bad iterations"); + if ("number" != typeof e) + throw new TypeError("Key length not a number"); + if (e < 0 || e > i || e != e) throw new TypeError("Bad key length"); + }; + }, + {}, + ], + 151: [ + function (A, e, t) { + var i = A("create-hash/md5"), + g = A("ripemd160"), + r = A("sha.js"), + n = A("safe-buffer").Buffer, + B = A("./precondition"), + I = A("./default-encoding"), + o = A("./to-buffer"), + a = n.alloc(128), + Q = { + md5: 16, + sha1: 20, + sha224: 28, + sha256: 32, + sha384: 48, + sha512: 64, + rmd160: 20, + ripemd160: 20, + }; + function C(A, e, t) { + var B = (function (A) { + return "rmd160" === A || "ripemd160" === A + ? function (A) { + return new g().update(A).digest(); + } + : "md5" === A + ? i + : function (e) { + return r(A).update(e).digest(); + }; + })(A), + I = "sha512" === A || "sha384" === A ? 128 : 64; + e.length > I ? (e = B(e)) : e.length < I && (e = n.concat([e, a], I)); + for ( + var o = n.allocUnsafe(I + Q[A]), C = n.allocUnsafe(I + Q[A]), s = 0; + s < I; + s++ + ) + (o[s] = 54 ^ e[s]), (C[s] = 92 ^ e[s]); + var c = n.allocUnsafe(I + t + 4); + o.copy(c, 0, 0, I), + (this.ipad1 = c), + (this.ipad2 = o), + (this.opad = C), + (this.alg = A), + (this.blocksize = I), + (this.hash = B), + (this.size = Q[A]); + } + (C.prototype.run = function (A, e) { + return ( + A.copy(e, this.blocksize), + this.hash(e).copy(this.opad, this.blocksize), + this.hash(this.opad) + ); + }), + (e.exports = function (A, e, t, i, g) { + B(t, i), (A = o(A, I, "Password")), (e = o(e, I, "Salt")); + var r = new C((g = g || "sha1"), A, e.length), + a = n.allocUnsafe(i), + s = n.allocUnsafe(e.length + 4); + e.copy(s, 0, 0, e.length); + for ( + var c = 0, h = Q[g], f = Math.ceil(i / h), E = 1; + E <= f; + E++ + ) { + s.writeUInt32BE(E, e.length); + for (var u = r.run(s, r.ipad1), d = u, l = 1; l < t; l++) { + d = r.run(d, r.ipad2); + for (var w = 0; w < h; w++) u[w] ^= d[w]; + } + u.copy(a, c), (c += h); + } + return a; + }); + }, + { + "./default-encoding": 149, + "./precondition": 150, + "./to-buffer": 152, + "create-hash/md5": 70, + ripemd160: 179, + "safe-buffer": 180, + "sha.js": 183, + }, + ], + 152: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer; + e.exports = function (A, e, t) { + if (i.isBuffer(A)) return A; + if ("string" == typeof A) return i.from(A, e); + if (ArrayBuffer.isView(A)) return i.from(A.buffer); + throw new TypeError( + t + " must be a string, a Buffer, a typed array or a DataView" + ); + }; + }, + { "safe-buffer": 180 }, + ], + 153: [ + function (A, e, t) { + (function (A) { + "use strict"; + void 0 === A || + !A.version || + 0 === A.version.indexOf("v0.") || + (0 === A.version.indexOf("v1.") && 0 !== A.version.indexOf("v1.8.")) + ? (e.exports = { + nextTick: function (e, t, i, g) { + if ("function" != typeof e) + throw new TypeError( + '"callback" argument must be a function' + ); + var r, + n, + B = arguments.length; + switch (B) { + case 0: + case 1: + return A.nextTick(e); + case 2: + return A.nextTick(function () { + e.call(null, t); + }); + case 3: + return A.nextTick(function () { + e.call(null, t, i); + }); + case 4: + return A.nextTick(function () { + e.call(null, t, i, g); + }); + default: + for (r = new Array(B - 1), n = 0; n < r.length; ) + r[n++] = arguments[n]; + return A.nextTick(function () { + e.apply(null, r); + }); + } + }, + }) + : (e.exports = A); + }.call(this, A("_process"))); + }, + { _process: 154 }, + ], + 154: [ + function (A, e, t) { + var i, + g, + r = (e.exports = {}); + function n() { + throw new Error("setTimeout has not been defined"); + } + function B() { + throw new Error("clearTimeout has not been defined"); + } + function I(A) { + if (i === setTimeout) return setTimeout(A, 0); + if ((i === n || !i) && setTimeout) + return (i = setTimeout), setTimeout(A, 0); + try { + return i(A, 0); + } catch (e) { + try { + return i.call(null, A, 0); + } catch (e) { + return i.call(this, A, 0); + } + } + } + !(function () { + try { + i = "function" == typeof setTimeout ? setTimeout : n; + } catch (A) { + i = n; + } + try { + g = "function" == typeof clearTimeout ? clearTimeout : B; + } catch (A) { + g = B; + } + })(); + var o, + a = [], + Q = !1, + C = -1; + function s() { + Q && + o && + ((Q = !1), + o.length ? (a = o.concat(a)) : (C = -1), + a.length && c()); + } + function c() { + if (!Q) { + var A = I(s); + Q = !0; + for (var e = a.length; e; ) { + for (o = a, a = []; ++C < e; ) o && o[C].run(); + (C = -1), (e = a.length); + } + (o = null), + (Q = !1), + (function (A) { + if (g === clearTimeout) return clearTimeout(A); + if ((g === B || !g) && clearTimeout) + return (g = clearTimeout), clearTimeout(A); + try { + g(A); + } catch (e) { + try { + return g.call(null, A); + } catch (e) { + return g.call(this, A); + } + } + })(A); + } + } + function h(A, e) { + (this.fun = A), (this.array = e); + } + function f() {} + (r.nextTick = function (A) { + var e = new Array(arguments.length - 1); + if (arguments.length > 1) + for (var t = 1; t < arguments.length; t++) e[t - 1] = arguments[t]; + a.push(new h(A, e)), 1 !== a.length || Q || I(c); + }), + (h.prototype.run = function () { + this.fun.apply(null, this.array); + }), + (r.title = "browser"), + (r.browser = !0), + (r.env = {}), + (r.argv = []), + (r.version = ""), + (r.versions = {}), + (r.on = f), + (r.addListener = f), + (r.once = f), + (r.off = f), + (r.removeListener = f), + (r.removeAllListeners = f), + (r.emit = f), + (r.prependListener = f), + (r.prependOnceListener = f), + (r.listeners = function (A) { + return []; + }), + (r.binding = function (A) { + throw new Error("process.binding is not supported"); + }), + (r.cwd = function () { + return "/"; + }), + (r.chdir = function (A) { + throw new Error("process.chdir is not supported"); + }), + (r.umask = function () { + return 0; + }); + }, + {}, + ], + 155: [ + function (A, e, t) { + (t.publicEncrypt = A("./publicEncrypt")), + (t.privateDecrypt = A("./privateDecrypt")), + (t.privateEncrypt = function (A, e) { + return t.publicEncrypt(A, e, !0); + }), + (t.publicDecrypt = function (A, e) { + return t.privateDecrypt(A, e, !0); + }); + }, + { "./privateDecrypt": 158, "./publicEncrypt": 159 }, + ], + 156: [ + function (A, e, t) { + var i = A("create-hash"), + g = A("safe-buffer").Buffer; + function r(A) { + var e = g.allocUnsafe(4); + return e.writeUInt32BE(A, 0), e; + } + e.exports = function (A, e) { + for (var t, n = g.alloc(0), B = 0; n.length < e; ) + (t = r(B++)), + (n = g.concat([n, i("sha1").update(A).update(t).digest()])); + return n.slice(0, e); + }; + }, + { "create-hash": 69, "safe-buffer": 180 }, + ], + 157: [ + function (A, e, t) { + arguments[4][15][0].apply(t, arguments); + }, + { buffer: 19, dup: 15 }, + ], + 158: [ + function (A, e, t) { + var i = A("parse-asn1"), + g = A("./mgf"), + r = A("./xor"), + n = A("bn.js"), + B = A("browserify-rsa"), + I = A("create-hash"), + o = A("./withPublic"), + a = A("safe-buffer").Buffer; + e.exports = function (A, e, t) { + var Q; + Q = A.padding ? A.padding : t ? 1 : 4; + var C, + s = i(A), + c = s.modulus.byteLength(); + if (e.length > c || new n(e).cmp(s.modulus) >= 0) + throw new Error("decryption error"); + C = t ? o(new n(e), s) : B(e, s); + var h = a.alloc(c - C.length); + if (((C = a.concat([h, C], c)), 4 === Q)) + return (function (A, e) { + var t = A.modulus.byteLength(), + i = I("sha1").update(a.alloc(0)).digest(), + n = i.length; + if (0 !== e[0]) throw new Error("decryption error"); + var B = e.slice(1, n + 1), + o = e.slice(n + 1), + Q = r(B, g(o, n)), + C = r(o, g(Q, t - n - 1)); + if ( + (function (A, e) { + (A = a.from(A)), (e = a.from(e)); + var t = 0, + i = A.length; + A.length !== e.length && + (t++, (i = Math.min(A.length, e.length))); + var g = -1; + for (; ++g < i; ) t += A[g] ^ e[g]; + return t; + })(i, C.slice(0, n)) + ) + throw new Error("decryption error"); + var s = n; + for (; 0 === C[s]; ) s++; + if (1 !== C[s++]) throw new Error("decryption error"); + return C.slice(s); + })(s, C); + if (1 === Q) + return (function (A, e, t) { + var i = e.slice(0, 2), + g = 2, + r = 0; + for (; 0 !== e[g++]; ) + if (g >= e.length) { + r++; + break; + } + var n = e.slice(2, g - 1); + (("0002" !== i.toString("hex") && !t) || + ("0001" !== i.toString("hex") && t)) && + r++; + n.length < 8 && r++; + if (r) throw new Error("decryption error"); + return e.slice(g); + })(0, C, t); + if (3 === Q) return C; + throw new Error("unknown padding"); + }; + }, + { + "./mgf": 156, + "./withPublic": 160, + "./xor": 161, + "bn.js": 157, + "browserify-rsa": 40, + "create-hash": 69, + "parse-asn1": 146, + "safe-buffer": 180, + }, + ], + 159: [ + function (A, e, t) { + var i = A("parse-asn1"), + g = A("randombytes"), + r = A("create-hash"), + n = A("./mgf"), + B = A("./xor"), + I = A("bn.js"), + o = A("./withPublic"), + a = A("browserify-rsa"), + Q = A("safe-buffer").Buffer; + e.exports = function (A, e, t) { + var C; + C = A.padding ? A.padding : t ? 1 : 4; + var s, + c = i(A); + if (4 === C) + s = (function (A, e) { + var t = A.modulus.byteLength(), + i = e.length, + o = r("sha1").update(Q.alloc(0)).digest(), + a = o.length, + C = 2 * a; + if (i > t - C - 2) throw new Error("message too long"); + var s = Q.alloc(t - i - C - 2), + c = t - a - 1, + h = g(a), + f = B(Q.concat([o, s, Q.alloc(1, 1), e], c), n(h, c)), + E = B(h, n(f, a)); + return new I(Q.concat([Q.alloc(1), E, f], t)); + })(c, e); + else if (1 === C) + s = (function (A, e, t) { + var i, + r = e.length, + n = A.modulus.byteLength(); + if (r > n - 11) throw new Error("message too long"); + i = t + ? Q.alloc(n - r - 3, 255) + : (function (A) { + var e, + t = Q.allocUnsafe(A), + i = 0, + r = g(2 * A), + n = 0; + for (; i < A; ) + n === r.length && ((r = g(2 * A)), (n = 0)), + (e = r[n++]) && (t[i++] = e); + return t; + })(n - r - 3); + return new I( + Q.concat([Q.from([0, t ? 1 : 2]), i, Q.alloc(1), e], n) + ); + })(c, e, t); + else { + if (3 !== C) throw new Error("unknown padding"); + if ((s = new I(e)).cmp(c.modulus) >= 0) + throw new Error("data too long for modulus"); + } + return t ? a(s, c) : o(s, c); + }; + }, + { + "./mgf": 156, + "./withPublic": 160, + "./xor": 161, + "bn.js": 157, + "browserify-rsa": 40, + "create-hash": 69, + "parse-asn1": 146, + randombytes: 162, + "safe-buffer": 180, + }, + ], + 160: [ + function (A, e, t) { + var i = A("bn.js"), + g = A("safe-buffer").Buffer; + e.exports = function (A, e) { + return g.from( + A.toRed(i.mont(e.modulus)) + .redPow(new i(e.publicExponent)) + .fromRed() + .toArray() + ); + }; + }, + { "bn.js": 157, "safe-buffer": 180 }, + ], + 161: [ + function (A, e, t) { + e.exports = function (A, e) { + for (var t = A.length, i = -1; ++i < t; ) A[i] ^= e[i]; + return A; + }; + }, + {}, + ], + 162: [ + function (A, e, t) { + (function (t, i) { + "use strict"; + var g = 65536, + r = 4294967295; + var n = A("safe-buffer").Buffer, + B = i.crypto || i.msCrypto; + B && B.getRandomValues + ? (e.exports = function (A, e) { + if (A > r) + throw new RangeError("requested too many random bytes"); + var i = n.allocUnsafe(A); + if (A > 0) + if (A > g) + for (var I = 0; I < A; I += g) + B.getRandomValues(i.slice(I, I + g)); + else B.getRandomValues(i); + if ("function" == typeof e) + return t.nextTick(function () { + e(null, i); + }); + return i; + }) + : (e.exports = function () { + throw new Error( + "Secure random number generation is not supported by this browser.\nUse Chrome, Firefox or Internet Explorer 11" + ); + }); + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { _process: 154, "safe-buffer": 180 }, + ], + 163: [ + function (A, e, t) { + (function (e, i) { + "use strict"; + function g() { + throw new Error( + "secure random number generation not supported by this browser\nuse chrome, FireFox or Internet Explorer 11" + ); + } + var r = A("safe-buffer"), + n = A("randombytes"), + B = r.Buffer, + I = r.kMaxLength, + o = i.crypto || i.msCrypto, + a = Math.pow(2, 32) - 1; + function Q(A, e) { + if ("number" != typeof A || A != A) + throw new TypeError("offset must be a number"); + if (A > a || A < 0) throw new TypeError("offset must be a uint32"); + if (A > I || A > e) throw new RangeError("offset out of range"); + } + function C(A, e, t) { + if ("number" != typeof A || A != A) + throw new TypeError("size must be a number"); + if (A > a || A < 0) throw new TypeError("size must be a uint32"); + if (A + e > t || A > I) throw new RangeError("buffer too small"); + } + function s(A, t, i, g) { + if (e.browser) { + var r = A.buffer, + B = new Uint8Array(r, t, i); + return ( + o.getRandomValues(B), + g + ? void e.nextTick(function () { + g(null, A); + }) + : A + ); + } + if (!g) return n(i).copy(A, t), A; + n(i, function (e, i) { + if (e) return g(e); + i.copy(A, t), g(null, A); + }); + } + (o && o.getRandomValues) || !e.browser + ? ((t.randomFill = function (A, e, t, g) { + if (!(B.isBuffer(A) || A instanceof i.Uint8Array)) + throw new TypeError( + '"buf" argument must be a Buffer or Uint8Array' + ); + if ("function" == typeof e) (g = e), (e = 0), (t = A.length); + else if ("function" == typeof t) (g = t), (t = A.length - e); + else if ("function" != typeof g) + throw new TypeError('"cb" argument must be a function'); + return Q(e, A.length), C(t, e, A.length), s(A, e, t, g); + }), + (t.randomFillSync = function (A, e, t) { + void 0 === e && (e = 0); + if (!(B.isBuffer(A) || A instanceof i.Uint8Array)) + throw new TypeError( + '"buf" argument must be a Buffer or Uint8Array' + ); + Q(e, A.length), void 0 === t && (t = A.length - e); + return C(t, e, A.length), s(A, e, t); + })) + : ((t.randomFill = g), (t.randomFillSync = g)); + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { _process: 154, randombytes: 162, "safe-buffer": 180 }, + ], + 164: [ + function (A, e, t) { + e.exports = A("./lib/_stream_duplex.js"); + }, + { "./lib/_stream_duplex.js": 165 }, + ], + 165: [ + function (A, e, t) { + "use strict"; + var i = A("process-nextick-args"), + g = + Object.keys || + function (A) { + var e = []; + for (var t in A) e.push(t); + return e; + }; + e.exports = Q; + var r = Object.create(A("core-util-is")); + r.inherits = A("inherits"); + var n = A("./_stream_readable"), + B = A("./_stream_writable"); + r.inherits(Q, n); + for (var I = g(B.prototype), o = 0; o < I.length; o++) { + var a = I[o]; + Q.prototype[a] || (Q.prototype[a] = B.prototype[a]); + } + function Q(A) { + if (!(this instanceof Q)) return new Q(A); + n.call(this, A), + B.call(this, A), + A && !1 === A.readable && (this.readable = !1), + A && !1 === A.writable && (this.writable = !1), + (this.allowHalfOpen = !0), + A && !1 === A.allowHalfOpen && (this.allowHalfOpen = !1), + this.once("end", C); + } + function C() { + this.allowHalfOpen || + this._writableState.ended || + i.nextTick(s, this); + } + function s(A) { + A.end(); + } + Object.defineProperty(Q.prototype, "writableHighWaterMark", { + enumerable: !1, + get: function () { + return this._writableState.highWaterMark; + }, + }), + Object.defineProperty(Q.prototype, "destroyed", { + get: function () { + return ( + void 0 !== this._readableState && + void 0 !== this._writableState && + this._readableState.destroyed && + this._writableState.destroyed + ); + }, + set: function (A) { + void 0 !== this._readableState && + void 0 !== this._writableState && + ((this._readableState.destroyed = A), + (this._writableState.destroyed = A)); + }, + }), + (Q.prototype._destroy = function (A, e) { + this.push(null), this.end(), i.nextTick(e, A); + }); + }, + { + "./_stream_readable": 167, + "./_stream_writable": 169, + "core-util-is": 66, + inherits: 134, + "process-nextick-args": 153, + }, + ], + 166: [ + function (A, e, t) { + "use strict"; + e.exports = r; + var i = A("./_stream_transform"), + g = Object.create(A("core-util-is")); + function r(A) { + if (!(this instanceof r)) return new r(A); + i.call(this, A); + } + (g.inherits = A("inherits")), + g.inherits(r, i), + (r.prototype._transform = function (A, e, t) { + t(null, A); + }); + }, + { "./_stream_transform": 168, "core-util-is": 66, inherits: 134 }, + ], + 167: [ + function (A, e, t) { + (function (t, i) { + "use strict"; + var g = A("process-nextick-args"); + e.exports = d; + var r, + n = A("isarray"); + d.ReadableState = u; + A("events").EventEmitter; + var B = function (A, e) { + return A.listeners(e).length; + }, + I = A("./internal/streams/stream"), + o = A("safe-buffer").Buffer, + a = i.Uint8Array || function () {}; + var Q = Object.create(A("core-util-is")); + Q.inherits = A("inherits"); + var C = A("util"), + s = void 0; + s = C && C.debuglog ? C.debuglog("stream") : function () {}; + var c, + h = A("./internal/streams/BufferList"), + f = A("./internal/streams/destroy"); + Q.inherits(d, I); + var E = ["error", "close", "destroy", "pause", "resume"]; + function u(e, t) { + (r = r || A("./_stream_duplex")), (e = e || {}); + var i = t instanceof r; + (this.objectMode = !!e.objectMode), + i && + (this.objectMode = this.objectMode || !!e.readableObjectMode); + var g = e.highWaterMark, + n = e.readableHighWaterMark, + B = this.objectMode ? 16 : 16384; + (this.highWaterMark = + g || 0 === g ? g : i && (n || 0 === n) ? n : B), + (this.highWaterMark = Math.floor(this.highWaterMark)), + (this.buffer = new h()), + (this.length = 0), + (this.pipes = null), + (this.pipesCount = 0), + (this.flowing = null), + (this.ended = !1), + (this.endEmitted = !1), + (this.reading = !1), + (this.sync = !0), + (this.needReadable = !1), + (this.emittedReadable = !1), + (this.readableListening = !1), + (this.resumeScheduled = !1), + (this.destroyed = !1), + (this.defaultEncoding = e.defaultEncoding || "utf8"), + (this.awaitDrain = 0), + (this.readingMore = !1), + (this.decoder = null), + (this.encoding = null), + e.encoding && + (c || (c = A("string_decoder/").StringDecoder), + (this.decoder = new c(e.encoding)), + (this.encoding = e.encoding)); + } + function d(e) { + if (((r = r || A("./_stream_duplex")), !(this instanceof d))) + return new d(e); + (this._readableState = new u(e, this)), + (this.readable = !0), + e && + ("function" == typeof e.read && (this._read = e.read), + "function" == typeof e.destroy && (this._destroy = e.destroy)), + I.call(this); + } + function l(A, e, t, i, g) { + var r, + n = A._readableState; + null === e + ? ((n.reading = !1), + (function (A, e) { + if (e.ended) return; + if (e.decoder) { + var t = e.decoder.end(); + t && + t.length && + (e.buffer.push(t), + (e.length += e.objectMode ? 1 : t.length)); + } + (e.ended = !0), b(A); + })(A, n)) + : (g || + (r = (function (A, e) { + var t; + (i = e), + o.isBuffer(i) || + i instanceof a || + "string" == typeof e || + void 0 === e || + A.objectMode || + (t = new TypeError("Invalid non-string/buffer chunk")); + var i; + return t; + })(n, e)), + r + ? A.emit("error", r) + : n.objectMode || (e && e.length > 0) + ? ("string" == typeof e || + n.objectMode || + Object.getPrototypeOf(e) === o.prototype || + (e = (function (A) { + return o.from(A); + })(e)), + i + ? n.endEmitted + ? A.emit( + "error", + new Error("stream.unshift() after end event") + ) + : w(A, n, e, !0) + : n.ended + ? A.emit("error", new Error("stream.push() after EOF")) + : ((n.reading = !1), + n.decoder && !t + ? ((e = n.decoder.write(e)), + n.objectMode || 0 !== e.length + ? w(A, n, e, !1) + : M(A, n)) + : w(A, n, e, !1))) + : i || (n.reading = !1)); + return (function (A) { + return ( + !A.ended && + (A.needReadable || A.length < A.highWaterMark || 0 === A.length) + ); + })(n); + } + function w(A, e, t, i) { + e.flowing && 0 === e.length && !e.sync + ? (A.emit("data", t), A.read(0)) + : ((e.length += e.objectMode ? 1 : t.length), + i ? e.buffer.unshift(t) : e.buffer.push(t), + e.needReadable && b(A)), + M(A, e); + } + Object.defineProperty(d.prototype, "destroyed", { + get: function () { + return ( + void 0 !== this._readableState && this._readableState.destroyed + ); + }, + set: function (A) { + this._readableState && (this._readableState.destroyed = A); + }, + }), + (d.prototype.destroy = f.destroy), + (d.prototype._undestroy = f.undestroy), + (d.prototype._destroy = function (A, e) { + this.push(null), e(A); + }), + (d.prototype.push = function (A, e) { + var t, + i = this._readableState; + return ( + i.objectMode + ? (t = !0) + : "string" == typeof A && + ((e = e || i.defaultEncoding) !== i.encoding && + ((A = o.from(A, e)), (e = "")), + (t = !0)), + l(this, A, e, !1, t) + ); + }), + (d.prototype.unshift = function (A) { + return l(this, A, null, !0, !1); + }), + (d.prototype.isPaused = function () { + return !1 === this._readableState.flowing; + }), + (d.prototype.setEncoding = function (e) { + return ( + c || (c = A("string_decoder/").StringDecoder), + (this._readableState.decoder = new c(e)), + (this._readableState.encoding = e), + this + ); + }); + var p = 8388608; + function D(A, e) { + return A <= 0 || (0 === e.length && e.ended) + ? 0 + : e.objectMode + ? 1 + : A != A + ? e.flowing && e.length + ? e.buffer.head.data.length + : e.length + : (A > e.highWaterMark && + (e.highWaterMark = (function (A) { + return ( + A >= p + ? (A = p) + : (A--, + (A |= A >>> 1), + (A |= A >>> 2), + (A |= A >>> 4), + (A |= A >>> 8), + (A |= A >>> 16), + A++), + A + ); + })(A)), + A <= e.length + ? A + : e.ended + ? e.length + : ((e.needReadable = !0), 0)); + } + function b(A) { + var e = A._readableState; + (e.needReadable = !1), + e.emittedReadable || + (s("emitReadable", e.flowing), + (e.emittedReadable = !0), + e.sync ? g.nextTick(y, A) : y(A)); + } + function y(A) { + s("emit readable"), A.emit("readable"), F(A); + } + function M(A, e) { + e.readingMore || ((e.readingMore = !0), g.nextTick(m, A, e)); + } + function m(A, e) { + for ( + var t = e.length; + !e.reading && + !e.flowing && + !e.ended && + e.length < e.highWaterMark && + (s("maybeReadMore read 0"), A.read(0), t !== e.length); + + ) + t = e.length; + e.readingMore = !1; + } + function G(A) { + s("readable nexttick read 0"), A.read(0); + } + function k(A, e) { + e.reading || (s("resume read 0"), A.read(0)), + (e.resumeScheduled = !1), + (e.awaitDrain = 0), + A.emit("resume"), + F(A), + e.flowing && !e.reading && A.read(0); + } + function F(A) { + var e = A._readableState; + for (s("flow", e.flowing); e.flowing && null !== A.read(); ); + } + function N(A, e) { + return 0 === e.length + ? null + : (e.objectMode + ? (t = e.buffer.shift()) + : !A || A >= e.length + ? ((t = e.decoder + ? e.buffer.join("") + : 1 === e.buffer.length + ? e.buffer.head.data + : e.buffer.concat(e.length)), + e.buffer.clear()) + : (t = (function (A, e, t) { + var i; + A < e.head.data.length + ? ((i = e.head.data.slice(0, A)), + (e.head.data = e.head.data.slice(A))) + : (i = + A === e.head.data.length + ? e.shift() + : t + ? (function (A, e) { + var t = e.head, + i = 1, + g = t.data; + A -= g.length; + for (; (t = t.next); ) { + var r = t.data, + n = A > r.length ? r.length : A; + if ( + (n === r.length + ? (g += r) + : (g += r.slice(0, A)), + 0 === (A -= n)) + ) { + n === r.length + ? (++i, + t.next + ? (e.head = t.next) + : (e.head = e.tail = null)) + : ((e.head = t), (t.data = r.slice(n))); + break; + } + ++i; + } + return (e.length -= i), g; + })(A, e) + : (function (A, e) { + var t = o.allocUnsafe(A), + i = e.head, + g = 1; + i.data.copy(t), (A -= i.data.length); + for (; (i = i.next); ) { + var r = i.data, + n = A > r.length ? r.length : A; + if ( + (r.copy(t, t.length - A, 0, n), + 0 === (A -= n)) + ) { + n === r.length + ? (++g, + i.next + ? (e.head = i.next) + : (e.head = e.tail = null)) + : ((e.head = i), (i.data = r.slice(n))); + break; + } + ++g; + } + return (e.length -= g), t; + })(A, e)); + return i; + })(A, e.buffer, e.decoder)), + t); + var t; + } + function S(A) { + var e = A._readableState; + if (e.length > 0) + throw new Error('"endReadable()" called on non-empty stream'); + e.endEmitted || ((e.ended = !0), g.nextTick(Y, e, A)); + } + function Y(A, e) { + A.endEmitted || + 0 !== A.length || + ((A.endEmitted = !0), (e.readable = !1), e.emit("end")); + } + function v(A, e) { + for (var t = 0, i = A.length; t < i; t++) if (A[t] === e) return t; + return -1; + } + (d.prototype.read = function (A) { + s("read", A), (A = parseInt(A, 10)); + var e = this._readableState, + t = A; + if ( + (0 !== A && (e.emittedReadable = !1), + 0 === A && + e.needReadable && + (e.length >= e.highWaterMark || e.ended)) + ) + return ( + s("read: emitReadable", e.length, e.ended), + 0 === e.length && e.ended ? S(this) : b(this), + null + ); + if (0 === (A = D(A, e)) && e.ended) + return 0 === e.length && S(this), null; + var i, + g = e.needReadable; + return ( + s("need readable", g), + (0 === e.length || e.length - A < e.highWaterMark) && + s("length less than watermark", (g = !0)), + e.ended || e.reading + ? s("reading or ended", (g = !1)) + : g && + (s("do read"), + (e.reading = !0), + (e.sync = !0), + 0 === e.length && (e.needReadable = !0), + this._read(e.highWaterMark), + (e.sync = !1), + e.reading || (A = D(t, e))), + null === (i = A > 0 ? N(A, e) : null) + ? ((e.needReadable = !0), (A = 0)) + : (e.length -= A), + 0 === e.length && + (e.ended || (e.needReadable = !0), + t !== A && e.ended && S(this)), + null !== i && this.emit("data", i), + i + ); + }), + (d.prototype._read = function (A) { + this.emit("error", new Error("_read() is not implemented")); + }), + (d.prototype.pipe = function (A, e) { + var i = this, + r = this._readableState; + switch (r.pipesCount) { + case 0: + r.pipes = A; + break; + case 1: + r.pipes = [r.pipes, A]; + break; + default: + r.pipes.push(A); + } + (r.pipesCount += 1), s("pipe count=%d opts=%j", r.pipesCount, e); + var I = + (!e || !1 !== e.end) && A !== t.stdout && A !== t.stderr + ? a + : d; + function o(e, t) { + s("onunpipe"), + e === i && + t && + !1 === t.hasUnpiped && + ((t.hasUnpiped = !0), + s("cleanup"), + A.removeListener("close", E), + A.removeListener("finish", u), + A.removeListener("drain", Q), + A.removeListener("error", f), + A.removeListener("unpipe", o), + i.removeListener("end", a), + i.removeListener("end", d), + i.removeListener("data", h), + (C = !0), + !r.awaitDrain || + (A._writableState && !A._writableState.needDrain) || + Q()); + } + function a() { + s("onend"), A.end(); + } + r.endEmitted ? g.nextTick(I) : i.once("end", I), + A.on("unpipe", o); + var Q = (function (A) { + return function () { + var e = A._readableState; + s("pipeOnDrain", e.awaitDrain), + e.awaitDrain && e.awaitDrain--, + 0 === e.awaitDrain && + B(A, "data") && + ((e.flowing = !0), F(A)); + }; + })(i); + A.on("drain", Q); + var C = !1; + var c = !1; + function h(e) { + s("ondata"), + (c = !1), + !1 !== A.write(e) || + c || + (((1 === r.pipesCount && r.pipes === A) || + (r.pipesCount > 1 && -1 !== v(r.pipes, A))) && + !C && + (s( + "false write response, pause", + i._readableState.awaitDrain + ), + i._readableState.awaitDrain++, + (c = !0)), + i.pause()); + } + function f(e) { + s("onerror", e), + d(), + A.removeListener("error", f), + 0 === B(A, "error") && A.emit("error", e); + } + function E() { + A.removeListener("finish", u), d(); + } + function u() { + s("onfinish"), A.removeListener("close", E), d(); + } + function d() { + s("unpipe"), i.unpipe(A); + } + return ( + i.on("data", h), + (function (A, e, t) { + if ("function" == typeof A.prependListener) + return A.prependListener(e, t); + A._events && A._events[e] + ? n(A._events[e]) + ? A._events[e].unshift(t) + : (A._events[e] = [t, A._events[e]]) + : A.on(e, t); + })(A, "error", f), + A.once("close", E), + A.once("finish", u), + A.emit("pipe", i), + r.flowing || (s("pipe resume"), i.resume()), + A + ); + }), + (d.prototype.unpipe = function (A) { + var e = this._readableState, + t = { hasUnpiped: !1 }; + if (0 === e.pipesCount) return this; + if (1 === e.pipesCount) + return A && A !== e.pipes + ? this + : (A || (A = e.pipes), + (e.pipes = null), + (e.pipesCount = 0), + (e.flowing = !1), + A && A.emit("unpipe", this, t), + this); + if (!A) { + var i = e.pipes, + g = e.pipesCount; + (e.pipes = null), (e.pipesCount = 0), (e.flowing = !1); + for (var r = 0; r < g; r++) i[r].emit("unpipe", this, t); + return this; + } + var n = v(e.pipes, A); + return -1 === n + ? this + : (e.pipes.splice(n, 1), + (e.pipesCount -= 1), + 1 === e.pipesCount && (e.pipes = e.pipes[0]), + A.emit("unpipe", this, t), + this); + }), + (d.prototype.on = function (A, e) { + var t = I.prototype.on.call(this, A, e); + if ("data" === A) + !1 !== this._readableState.flowing && this.resume(); + else if ("readable" === A) { + var i = this._readableState; + i.endEmitted || + i.readableListening || + ((i.readableListening = i.needReadable = !0), + (i.emittedReadable = !1), + i.reading ? i.length && b(this) : g.nextTick(G, this)); + } + return t; + }), + (d.prototype.addListener = d.prototype.on), + (d.prototype.resume = function () { + var A = this._readableState; + return ( + A.flowing || + (s("resume"), + (A.flowing = !0), + (function (A, e) { + e.resumeScheduled || + ((e.resumeScheduled = !0), g.nextTick(k, A, e)); + })(this, A)), + this + ); + }), + (d.prototype.pause = function () { + return ( + s("call pause flowing=%j", this._readableState.flowing), + !1 !== this._readableState.flowing && + (s("pause"), + (this._readableState.flowing = !1), + this.emit("pause")), + this + ); + }), + (d.prototype.wrap = function (A) { + var e = this, + t = this._readableState, + i = !1; + for (var g in (A.on("end", function () { + if ((s("wrapped end"), t.decoder && !t.ended)) { + var A = t.decoder.end(); + A && A.length && e.push(A); + } + e.push(null); + }), + A.on("data", function (g) { + (s("wrapped data"), + t.decoder && (g = t.decoder.write(g)), + !t.objectMode || (null !== g && void 0 !== g)) && + (t.objectMode || (g && g.length)) && + (e.push(g) || ((i = !0), A.pause())); + }), + A)) + void 0 === this[g] && + "function" == typeof A[g] && + (this[g] = (function (e) { + return function () { + return A[e].apply(A, arguments); + }; + })(g)); + for (var r = 0; r < E.length; r++) + A.on(E[r], this.emit.bind(this, E[r])); + return ( + (this._read = function (e) { + s("wrapped _read", e), i && ((i = !1), A.resume()); + }), + this + ); + }), + Object.defineProperty(d.prototype, "readableHighWaterMark", { + enumerable: !1, + get: function () { + return this._readableState.highWaterMark; + }, + }), + (d._fromList = N); + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { + "./_stream_duplex": 165, + "./internal/streams/BufferList": 170, + "./internal/streams/destroy": 171, + "./internal/streams/stream": 172, + _process: 154, + "core-util-is": 66, + events: 102, + inherits: 134, + isarray: 136, + "process-nextick-args": 153, + "safe-buffer": 173, + "string_decoder/": 174, + util: 19, + }, + ], + 168: [ + function (A, e, t) { + "use strict"; + e.exports = r; + var i = A("./_stream_duplex"), + g = Object.create(A("core-util-is")); + function r(A) { + if (!(this instanceof r)) return new r(A); + i.call(this, A), + (this._transformState = { + afterTransform: function (A, e) { + var t = this._transformState; + t.transforming = !1; + var i = t.writecb; + if (!i) + return this.emit( + "error", + new Error("write callback called multiple times") + ); + (t.writechunk = null), + (t.writecb = null), + null != e && this.push(e), + i(A); + var g = this._readableState; + (g.reading = !1), + (g.needReadable || g.length < g.highWaterMark) && + this._read(g.highWaterMark); + }.bind(this), + needTransform: !1, + transforming: !1, + writecb: null, + writechunk: null, + writeencoding: null, + }), + (this._readableState.needReadable = !0), + (this._readableState.sync = !1), + A && + ("function" == typeof A.transform && + (this._transform = A.transform), + "function" == typeof A.flush && (this._flush = A.flush)), + this.on("prefinish", n); + } + function n() { + var A = this; + "function" == typeof this._flush + ? this._flush(function (e, t) { + B(A, e, t); + }) + : B(this, null, null); + } + function B(A, e, t) { + if (e) return A.emit("error", e); + if ((null != t && A.push(t), A._writableState.length)) + throw new Error("Calling transform done when ws.length != 0"); + if (A._transformState.transforming) + throw new Error("Calling transform done when still transforming"); + return A.push(null); + } + (g.inherits = A("inherits")), + g.inherits(r, i), + (r.prototype.push = function (A, e) { + return ( + (this._transformState.needTransform = !1), + i.prototype.push.call(this, A, e) + ); + }), + (r.prototype._transform = function (A, e, t) { + throw new Error("_transform() is not implemented"); + }), + (r.prototype._write = function (A, e, t) { + var i = this._transformState; + if ( + ((i.writecb = t), + (i.writechunk = A), + (i.writeencoding = e), + !i.transforming) + ) { + var g = this._readableState; + (i.needTransform || + g.needReadable || + g.length < g.highWaterMark) && + this._read(g.highWaterMark); + } + }), + (r.prototype._read = function (A) { + var e = this._transformState; + null !== e.writechunk && e.writecb && !e.transforming + ? ((e.transforming = !0), + this._transform( + e.writechunk, + e.writeencoding, + e.afterTransform + )) + : (e.needTransform = !0); + }), + (r.prototype._destroy = function (A, e) { + var t = this; + i.prototype._destroy.call(this, A, function (A) { + e(A), t.emit("close"); + }); + }); + }, + { "./_stream_duplex": 165, "core-util-is": 66, inherits: 134 }, + ], + 169: [ + function (A, e, t) { + (function (t, i, g) { + "use strict"; + var r = A("process-nextick-args"); + function n(A) { + var e = this; + (this.next = null), + (this.entry = null), + (this.finish = function () { + !(function (A, e, t) { + var i = A.entry; + A.entry = null; + for (; i; ) { + var g = i.callback; + e.pendingcb--, g(t), (i = i.next); + } + e.corkedRequestsFree + ? (e.corkedRequestsFree.next = A) + : (e.corkedRequestsFree = A); + })(e, A); + }); + } + e.exports = u; + var B, + I = + !t.browser && + ["v0.10", "v0.9."].indexOf(t.version.slice(0, 5)) > -1 + ? g + : r.nextTick; + u.WritableState = E; + var o = Object.create(A("core-util-is")); + o.inherits = A("inherits"); + var a = { deprecate: A("util-deprecate") }, + Q = A("./internal/streams/stream"), + C = A("safe-buffer").Buffer, + s = i.Uint8Array || function () {}; + var c, + h = A("./internal/streams/destroy"); + function f() {} + function E(e, t) { + (B = B || A("./_stream_duplex")), (e = e || {}); + var i = t instanceof B; + (this.objectMode = !!e.objectMode), + i && + (this.objectMode = this.objectMode || !!e.writableObjectMode); + var g = e.highWaterMark, + o = e.writableHighWaterMark, + a = this.objectMode ? 16 : 16384; + (this.highWaterMark = + g || 0 === g ? g : i && (o || 0 === o) ? o : a), + (this.highWaterMark = Math.floor(this.highWaterMark)), + (this.finalCalled = !1), + (this.needDrain = !1), + (this.ending = !1), + (this.ended = !1), + (this.finished = !1), + (this.destroyed = !1); + var Q = !1 === e.decodeStrings; + (this.decodeStrings = !Q), + (this.defaultEncoding = e.defaultEncoding || "utf8"), + (this.length = 0), + (this.writing = !1), + (this.corked = 0), + (this.sync = !0), + (this.bufferProcessing = !1), + (this.onwrite = function (A) { + !(function (A, e) { + var t = A._writableState, + i = t.sync, + g = t.writecb; + if ( + ((function (A) { + (A.writing = !1), + (A.writecb = null), + (A.length -= A.writelen), + (A.writelen = 0); + })(t), + e) + ) + !(function (A, e, t, i, g) { + --e.pendingcb, + t + ? (r.nextTick(g, i), + r.nextTick(b, A, e), + (A._writableState.errorEmitted = !0), + A.emit("error", i)) + : (g(i), + (A._writableState.errorEmitted = !0), + A.emit("error", i), + b(A, e)); + })(A, t, i, e, g); + else { + var n = p(t); + n || + t.corked || + t.bufferProcessing || + !t.bufferedRequest || + w(A, t), + i ? I(l, A, t, n, g) : l(A, t, n, g); + } + })(t, A); + }), + (this.writecb = null), + (this.writelen = 0), + (this.bufferedRequest = null), + (this.lastBufferedRequest = null), + (this.pendingcb = 0), + (this.prefinished = !1), + (this.errorEmitted = !1), + (this.bufferedRequestCount = 0), + (this.corkedRequestsFree = new n(this)); + } + function u(e) { + if ( + ((B = B || A("./_stream_duplex")), + !(c.call(u, this) || this instanceof B)) + ) + return new u(e); + (this._writableState = new E(e, this)), + (this.writable = !0), + e && + ("function" == typeof e.write && (this._write = e.write), + "function" == typeof e.writev && (this._writev = e.writev), + "function" == typeof e.destroy && (this._destroy = e.destroy), + "function" == typeof e.final && (this._final = e.final)), + Q.call(this); + } + function d(A, e, t, i, g, r, n) { + (e.writelen = i), + (e.writecb = n), + (e.writing = !0), + (e.sync = !0), + t ? A._writev(g, e.onwrite) : A._write(g, r, e.onwrite), + (e.sync = !1); + } + function l(A, e, t, i) { + t || + (function (A, e) { + 0 === e.length && + e.needDrain && + ((e.needDrain = !1), A.emit("drain")); + })(A, e), + e.pendingcb--, + i(), + b(A, e); + } + function w(A, e) { + e.bufferProcessing = !0; + var t = e.bufferedRequest; + if (A._writev && t && t.next) { + var i = e.bufferedRequestCount, + g = new Array(i), + r = e.corkedRequestsFree; + r.entry = t; + for (var B = 0, I = !0; t; ) + (g[B] = t), t.isBuf || (I = !1), (t = t.next), (B += 1); + (g.allBuffers = I), + d(A, e, !0, e.length, g, "", r.finish), + e.pendingcb++, + (e.lastBufferedRequest = null), + r.next + ? ((e.corkedRequestsFree = r.next), (r.next = null)) + : (e.corkedRequestsFree = new n(e)), + (e.bufferedRequestCount = 0); + } else { + for (; t; ) { + var o = t.chunk, + a = t.encoding, + Q = t.callback; + if ( + (d(A, e, !1, e.objectMode ? 1 : o.length, o, a, Q), + (t = t.next), + e.bufferedRequestCount--, + e.writing) + ) + break; + } + null === t && (e.lastBufferedRequest = null); + } + (e.bufferedRequest = t), (e.bufferProcessing = !1); + } + function p(A) { + return ( + A.ending && + 0 === A.length && + null === A.bufferedRequest && + !A.finished && + !A.writing + ); + } + function D(A, e) { + A._final(function (t) { + e.pendingcb--, + t && A.emit("error", t), + (e.prefinished = !0), + A.emit("prefinish"), + b(A, e); + }); + } + function b(A, e) { + var t = p(e); + return ( + t && + (!(function (A, e) { + e.prefinished || + e.finalCalled || + ("function" == typeof A._final + ? (e.pendingcb++, + (e.finalCalled = !0), + r.nextTick(D, A, e)) + : ((e.prefinished = !0), A.emit("prefinish"))); + })(A, e), + 0 === e.pendingcb && ((e.finished = !0), A.emit("finish"))), + t + ); + } + o.inherits(u, Q), + (E.prototype.getBuffer = function () { + for (var A = this.bufferedRequest, e = []; A; ) + e.push(A), (A = A.next); + return e; + }), + (function () { + try { + Object.defineProperty(E.prototype, "buffer", { + get: a.deprecate( + function () { + return this.getBuffer(); + }, + "_writableState.buffer is deprecated. Use _writableState.getBuffer instead.", + "DEP0003" + ), + }); + } catch (A) {} + })(), + "function" == typeof Symbol && + Symbol.hasInstance && + "function" == typeof Function.prototype[Symbol.hasInstance] + ? ((c = Function.prototype[Symbol.hasInstance]), + Object.defineProperty(u, Symbol.hasInstance, { + value: function (A) { + return ( + !!c.call(this, A) || + (this === u && A && A._writableState instanceof E) + ); + }, + })) + : (c = function (A) { + return A instanceof this; + }), + (u.prototype.pipe = function () { + this.emit("error", new Error("Cannot pipe, not readable")); + }), + (u.prototype.write = function (A, e, t) { + var i, + g = this._writableState, + n = !1, + B = !g.objectMode && ((i = A), C.isBuffer(i) || i instanceof s); + return ( + B && + !C.isBuffer(A) && + (A = (function (A) { + return C.from(A); + })(A)), + "function" == typeof e && ((t = e), (e = null)), + B ? (e = "buffer") : e || (e = g.defaultEncoding), + "function" != typeof t && (t = f), + g.ended + ? (function (A, e) { + var t = new Error("write after end"); + A.emit("error", t), r.nextTick(e, t); + })(this, t) + : (B || + (function (A, e, t, i) { + var g = !0, + n = !1; + return ( + null === t + ? (n = new TypeError( + "May not write null values to stream" + )) + : "string" == typeof t || + void 0 === t || + e.objectMode || + (n = new TypeError( + "Invalid non-string/buffer chunk" + )), + n && (A.emit("error", n), r.nextTick(i, n), (g = !1)), + g + ); + })(this, g, A, t)) && + (g.pendingcb++, + (n = (function (A, e, t, i, g, r) { + if (!t) { + var n = (function (A, e, t) { + A.objectMode || + !1 === A.decodeStrings || + "string" != typeof e || + (e = C.from(e, t)); + return e; + })(e, i, g); + i !== n && ((t = !0), (g = "buffer"), (i = n)); + } + var B = e.objectMode ? 1 : i.length; + e.length += B; + var I = e.length < e.highWaterMark; + I || (e.needDrain = !0); + if (e.writing || e.corked) { + var o = e.lastBufferedRequest; + (e.lastBufferedRequest = { + chunk: i, + encoding: g, + isBuf: t, + callback: r, + next: null, + }), + o + ? (o.next = e.lastBufferedRequest) + : (e.bufferedRequest = e.lastBufferedRequest), + (e.bufferedRequestCount += 1); + } else d(A, e, !1, B, i, g, r); + return I; + })(this, g, B, A, e, t))), + n + ); + }), + (u.prototype.cork = function () { + this._writableState.corked++; + }), + (u.prototype.uncork = function () { + var A = this._writableState; + A.corked && + (A.corked--, + A.writing || + A.corked || + A.finished || + A.bufferProcessing || + !A.bufferedRequest || + w(this, A)); + }), + (u.prototype.setDefaultEncoding = function (A) { + if ( + ("string" == typeof A && (A = A.toLowerCase()), + !( + [ + "hex", + "utf8", + "utf-8", + "ascii", + "binary", + "base64", + "ucs2", + "ucs-2", + "utf16le", + "utf-16le", + "raw", + ].indexOf((A + "").toLowerCase()) > -1 + )) + ) + throw new TypeError("Unknown encoding: " + A); + return (this._writableState.defaultEncoding = A), this; + }), + Object.defineProperty(u.prototype, "writableHighWaterMark", { + enumerable: !1, + get: function () { + return this._writableState.highWaterMark; + }, + }), + (u.prototype._write = function (A, e, t) { + t(new Error("_write() is not implemented")); + }), + (u.prototype._writev = null), + (u.prototype.end = function (A, e, t) { + var i = this._writableState; + "function" == typeof A + ? ((t = A), (A = null), (e = null)) + : "function" == typeof e && ((t = e), (e = null)), + null !== A && void 0 !== A && this.write(A, e), + i.corked && ((i.corked = 1), this.uncork()), + i.ending || + i.finished || + (function (A, e, t) { + (e.ending = !0), + b(A, e), + t && (e.finished ? r.nextTick(t) : A.once("finish", t)); + (e.ended = !0), (A.writable = !1); + })(this, i, t); + }), + Object.defineProperty(u.prototype, "destroyed", { + get: function () { + return ( + void 0 !== this._writableState && + this._writableState.destroyed + ); + }, + set: function (A) { + this._writableState && (this._writableState.destroyed = A); + }, + }), + (u.prototype.destroy = h.destroy), + (u.prototype._undestroy = h.undestroy), + (u.prototype._destroy = function (A, e) { + this.end(), e(A); + }); + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {}, + A("timers").setImmediate + )); + }, + { + "./_stream_duplex": 165, + "./internal/streams/destroy": 171, + "./internal/streams/stream": 172, + _process: 154, + "core-util-is": 66, + inherits: 134, + "process-nextick-args": 153, + "safe-buffer": 173, + timers: 192, + "util-deprecate": 193, + }, + ], + 170: [ + function (A, e, t) { + "use strict"; + var i = A("safe-buffer").Buffer, + g = A("util"); + (e.exports = (function () { + function A() { + !(function (A, e) { + if (!(A instanceof e)) + throw new TypeError("Cannot call a class as a function"); + })(this, A), + (this.head = null), + (this.tail = null), + (this.length = 0); + } + return ( + (A.prototype.push = function (A) { + var e = { data: A, next: null }; + this.length > 0 ? (this.tail.next = e) : (this.head = e), + (this.tail = e), + ++this.length; + }), + (A.prototype.unshift = function (A) { + var e = { data: A, next: this.head }; + 0 === this.length && (this.tail = e), + (this.head = e), + ++this.length; + }), + (A.prototype.shift = function () { + if (0 !== this.length) { + var A = this.head.data; + return ( + 1 === this.length + ? (this.head = this.tail = null) + : (this.head = this.head.next), + --this.length, + A + ); + } + }), + (A.prototype.clear = function () { + (this.head = this.tail = null), (this.length = 0); + }), + (A.prototype.join = function (A) { + if (0 === this.length) return ""; + for (var e = this.head, t = "" + e.data; (e = e.next); ) + t += A + e.data; + return t; + }), + (A.prototype.concat = function (A) { + if (0 === this.length) return i.alloc(0); + if (1 === this.length) return this.head.data; + for ( + var e, t, g, r = i.allocUnsafe(A >>> 0), n = this.head, B = 0; + n; + + ) + (e = n.data), + (t = r), + (g = B), + e.copy(t, g), + (B += n.data.length), + (n = n.next); + return r; + }), + A + ); + })()), + g && + g.inspect && + g.inspect.custom && + (e.exports.prototype[g.inspect.custom] = function () { + var A = g.inspect({ length: this.length }); + return this.constructor.name + " " + A; + }); + }, + { "safe-buffer": 173, util: 19 }, + ], + 171: [ + function (A, e, t) { + "use strict"; + var i = A("process-nextick-args"); + function g(A, e) { + A.emit("error", e); + } + e.exports = { + destroy: function (A, e) { + var t = this, + r = this._readableState && this._readableState.destroyed, + n = this._writableState && this._writableState.destroyed; + return r || n + ? (e + ? e(A) + : !A || + (this._writableState && this._writableState.errorEmitted) || + i.nextTick(g, this, A), + this) + : (this._readableState && (this._readableState.destroyed = !0), + this._writableState && (this._writableState.destroyed = !0), + this._destroy(A || null, function (A) { + !e && A + ? (i.nextTick(g, t, A), + t._writableState && (t._writableState.errorEmitted = !0)) + : e && e(A); + }), + this); + }, + undestroy: function () { + this._readableState && + ((this._readableState.destroyed = !1), + (this._readableState.reading = !1), + (this._readableState.ended = !1), + (this._readableState.endEmitted = !1)), + this._writableState && + ((this._writableState.destroyed = !1), + (this._writableState.ended = !1), + (this._writableState.ending = !1), + (this._writableState.finished = !1), + (this._writableState.errorEmitted = !1)); + }, + }; + }, + { "process-nextick-args": 153 }, + ], + 172: [ + function (A, e, t) { + arguments[4][61][0].apply(t, arguments); + }, + { dup: 61, events: 102 }, + ], + 173: [ + function (A, e, t) { + var i = A("buffer"), + g = i.Buffer; + function r(A, e) { + for (var t in A) e[t] = A[t]; + } + function n(A, e, t) { + return g(A, e, t); + } + g.from && g.alloc && g.allocUnsafe && g.allocUnsafeSlow + ? (e.exports = i) + : (r(i, t), (t.Buffer = n)), + r(g, n), + (n.from = function (A, e, t) { + if ("number" == typeof A) + throw new TypeError("Argument must not be a number"); + return g(A, e, t); + }), + (n.alloc = function (A, e, t) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + var i = g(A); + return ( + void 0 !== e + ? "string" == typeof t + ? i.fill(e, t) + : i.fill(e) + : i.fill(0), + i + ); + }), + (n.allocUnsafe = function (A) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + return g(A); + }), + (n.allocUnsafeSlow = function (A) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + return i.SlowBuffer(A); + }); + }, + { buffer: 64 }, + ], + 174: [ + function (A, e, t) { + "use strict"; + var i = A("safe-buffer").Buffer, + g = + i.isEncoding || + function (A) { + switch ((A = "" + A) && A.toLowerCase()) { + case "hex": + case "utf8": + case "utf-8": + case "ascii": + case "binary": + case "base64": + case "ucs2": + case "ucs-2": + case "utf16le": + case "utf-16le": + case "raw": + return !0; + default: + return !1; + } + }; + function r(A) { + var e; + switch ( + ((this.encoding = (function (A) { + var e = (function (A) { + if (!A) return "utf8"; + for (var e; ; ) + switch (A) { + case "utf8": + case "utf-8": + return "utf8"; + case "ucs2": + case "ucs-2": + case "utf16le": + case "utf-16le": + return "utf16le"; + case "latin1": + case "binary": + return "latin1"; + case "base64": + case "ascii": + case "hex": + return A; + default: + if (e) return; + (A = ("" + A).toLowerCase()), (e = !0); + } + })(A); + if ("string" != typeof e && (i.isEncoding === g || !g(A))) + throw new Error("Unknown encoding: " + A); + return e || A; + })(A)), + this.encoding) + ) { + case "utf16le": + (this.text = I), (this.end = o), (e = 4); + break; + case "utf8": + (this.fillLast = B), (e = 4); + break; + case "base64": + (this.text = a), (this.end = Q), (e = 3); + break; + default: + return (this.write = C), void (this.end = s); + } + (this.lastNeed = 0), + (this.lastTotal = 0), + (this.lastChar = i.allocUnsafe(e)); + } + function n(A) { + return A <= 127 + ? 0 + : A >> 5 == 6 + ? 2 + : A >> 4 == 14 + ? 3 + : A >> 3 == 30 + ? 4 + : A >> 6 == 2 + ? -1 + : -2; + } + function B(A) { + var e = this.lastTotal - this.lastNeed, + t = (function (A, e, t) { + if (128 != (192 & e[0])) return (A.lastNeed = 0), "�"; + if (A.lastNeed > 1 && e.length > 1) { + if (128 != (192 & e[1])) return (A.lastNeed = 1), "�"; + if (A.lastNeed > 2 && e.length > 2 && 128 != (192 & e[2])) + return (A.lastNeed = 2), "�"; + } + })(this, A); + return void 0 !== t + ? t + : this.lastNeed <= A.length + ? (A.copy(this.lastChar, e, 0, this.lastNeed), + this.lastChar.toString(this.encoding, 0, this.lastTotal)) + : (A.copy(this.lastChar, e, 0, A.length), + void (this.lastNeed -= A.length)); + } + function I(A, e) { + if ((A.length - e) % 2 == 0) { + var t = A.toString("utf16le", e); + if (t) { + var i = t.charCodeAt(t.length - 1); + if (i >= 55296 && i <= 56319) + return ( + (this.lastNeed = 2), + (this.lastTotal = 4), + (this.lastChar[0] = A[A.length - 2]), + (this.lastChar[1] = A[A.length - 1]), + t.slice(0, -1) + ); + } + return t; + } + return ( + (this.lastNeed = 1), + (this.lastTotal = 2), + (this.lastChar[0] = A[A.length - 1]), + A.toString("utf16le", e, A.length - 1) + ); + } + function o(A) { + var e = A && A.length ? this.write(A) : ""; + if (this.lastNeed) { + var t = this.lastTotal - this.lastNeed; + return e + this.lastChar.toString("utf16le", 0, t); + } + return e; + } + function a(A, e) { + var t = (A.length - e) % 3; + return 0 === t + ? A.toString("base64", e) + : ((this.lastNeed = 3 - t), + (this.lastTotal = 3), + 1 === t + ? (this.lastChar[0] = A[A.length - 1]) + : ((this.lastChar[0] = A[A.length - 2]), + (this.lastChar[1] = A[A.length - 1])), + A.toString("base64", e, A.length - t)); + } + function Q(A) { + var e = A && A.length ? this.write(A) : ""; + return this.lastNeed + ? e + this.lastChar.toString("base64", 0, 3 - this.lastNeed) + : e; + } + function C(A) { + return A.toString(this.encoding); + } + function s(A) { + return A && A.length ? this.write(A) : ""; + } + (t.StringDecoder = r), + (r.prototype.write = function (A) { + if (0 === A.length) return ""; + var e, t; + if (this.lastNeed) { + if (void 0 === (e = this.fillLast(A))) return ""; + (t = this.lastNeed), (this.lastNeed = 0); + } else t = 0; + return t < A.length + ? e + ? e + this.text(A, t) + : this.text(A, t) + : e || ""; + }), + (r.prototype.end = function (A) { + var e = A && A.length ? this.write(A) : ""; + return this.lastNeed ? e + "�" : e; + }), + (r.prototype.text = function (A, e) { + var t = (function (A, e, t) { + var i = e.length - 1; + if (i < t) return 0; + var g = n(e[i]); + if (g >= 0) return g > 0 && (A.lastNeed = g - 1), g; + if (--i < t || -2 === g) return 0; + if ((g = n(e[i])) >= 0) return g > 0 && (A.lastNeed = g - 2), g; + if (--i < t || -2 === g) return 0; + if ((g = n(e[i])) >= 0) + return g > 0 && (2 === g ? (g = 0) : (A.lastNeed = g - 3)), g; + return 0; + })(this, A, e); + if (!this.lastNeed) return A.toString("utf8", e); + this.lastTotal = t; + var i = A.length - (t - this.lastNeed); + return A.copy(this.lastChar, 0, i), A.toString("utf8", e, i); + }), + (r.prototype.fillLast = function (A) { + if (this.lastNeed <= A.length) + return ( + A.copy( + this.lastChar, + this.lastTotal - this.lastNeed, + 0, + this.lastNeed + ), + this.lastChar.toString(this.encoding, 0, this.lastTotal) + ); + A.copy(this.lastChar, this.lastTotal - this.lastNeed, 0, A.length), + (this.lastNeed -= A.length); + }); + }, + { "safe-buffer": 173 }, + ], + 175: [ + function (A, e, t) { + e.exports = A("./readable").PassThrough; + }, + { "./readable": 176 }, + ], + 176: [ + function (A, e, t) { + ((t = e.exports = A("./lib/_stream_readable.js")).Stream = t), + (t.Readable = t), + (t.Writable = A("./lib/_stream_writable.js")), + (t.Duplex = A("./lib/_stream_duplex.js")), + (t.Transform = A("./lib/_stream_transform.js")), + (t.PassThrough = A("./lib/_stream_passthrough.js")); + }, + { + "./lib/_stream_duplex.js": 165, + "./lib/_stream_passthrough.js": 166, + "./lib/_stream_readable.js": 167, + "./lib/_stream_transform.js": 168, + "./lib/_stream_writable.js": 169, + }, + ], + 177: [ + function (A, e, t) { + e.exports = A("./readable").Transform; + }, + { "./readable": 176 }, + ], + 178: [ + function (A, e, t) { + e.exports = A("./lib/_stream_writable.js"); + }, + { "./lib/_stream_writable.js": 169 }, + ], + 179: [ + function (A, e, t) { + "use strict"; + var i = A("buffer").Buffer, + g = A("inherits"), + r = A("hash-base"), + n = new Array(16), + B = [ + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 7, 4, 13, 1, + 10, 6, 15, 3, 12, 0, 9, 5, 2, 14, 11, 8, 3, 10, 14, 4, 9, 15, 8, 1, + 2, 7, 0, 6, 13, 11, 5, 12, 1, 9, 11, 10, 0, 8, 12, 4, 13, 3, 7, 15, + 14, 5, 6, 2, 4, 0, 5, 9, 7, 12, 2, 10, 14, 1, 3, 8, 11, 6, 15, 13, + ], + I = [ + 5, 14, 7, 0, 9, 2, 11, 4, 13, 6, 15, 8, 1, 10, 3, 12, 6, 11, 3, 7, + 0, 13, 5, 10, 14, 15, 8, 12, 4, 9, 1, 2, 15, 5, 1, 3, 7, 14, 6, 9, + 11, 8, 12, 2, 10, 0, 4, 13, 8, 6, 4, 1, 3, 11, 15, 0, 5, 12, 2, 13, + 9, 7, 10, 14, 12, 15, 10, 4, 1, 5, 8, 7, 6, 2, 13, 14, 0, 3, 9, 11, + ], + o = [ + 11, 14, 15, 12, 5, 8, 7, 9, 11, 13, 14, 15, 6, 7, 9, 8, 7, 6, 8, 13, + 11, 9, 7, 15, 7, 12, 15, 9, 11, 7, 13, 12, 11, 13, 6, 7, 14, 9, 13, + 15, 14, 8, 13, 6, 5, 12, 7, 5, 11, 12, 14, 15, 14, 15, 9, 8, 9, 14, + 5, 6, 8, 6, 5, 12, 9, 15, 5, 11, 6, 8, 13, 12, 5, 12, 13, 14, 11, 8, + 5, 6, + ], + a = [ + 8, 9, 9, 11, 13, 15, 15, 5, 7, 7, 8, 11, 14, 14, 12, 6, 9, 13, 15, + 7, 12, 8, 9, 11, 7, 7, 12, 7, 6, 15, 13, 11, 9, 7, 15, 11, 8, 6, 6, + 14, 12, 13, 5, 14, 13, 13, 7, 5, 15, 5, 8, 11, 14, 14, 6, 14, 6, 9, + 12, 9, 12, 5, 15, 8, 8, 5, 12, 9, 12, 5, 14, 6, 8, 13, 6, 5, 15, 13, + 11, 11, + ], + Q = [0, 1518500249, 1859775393, 2400959708, 2840853838], + C = [1352829926, 1548603684, 1836072691, 2053994217, 0]; + function s() { + r.call(this, 64), + (this._a = 1732584193), + (this._b = 4023233417), + (this._c = 2562383102), + (this._d = 271733878), + (this._e = 3285377520); + } + function c(A, e) { + return (A << e) | (A >>> (32 - e)); + } + function h(A, e, t, i, g, r, n, B) { + return (c((A + (e ^ t ^ i) + r + n) | 0, B) + g) | 0; + } + function f(A, e, t, i, g, r, n, B) { + return (c((A + ((e & t) | (~e & i)) + r + n) | 0, B) + g) | 0; + } + function E(A, e, t, i, g, r, n, B) { + return (c((A + ((e | ~t) ^ i) + r + n) | 0, B) + g) | 0; + } + function u(A, e, t, i, g, r, n, B) { + return (c((A + ((e & i) | (t & ~i)) + r + n) | 0, B) + g) | 0; + } + function d(A, e, t, i, g, r, n, B) { + return (c((A + (e ^ (t | ~i)) + r + n) | 0, B) + g) | 0; + } + g(s, r), + (s.prototype._update = function () { + for (var A = n, e = 0; e < 16; ++e) + A[e] = this._block.readInt32LE(4 * e); + for ( + var t = 0 | this._a, + i = 0 | this._b, + g = 0 | this._c, + r = 0 | this._d, + s = 0 | this._e, + l = 0 | this._a, + w = 0 | this._b, + p = 0 | this._c, + D = 0 | this._d, + b = 0 | this._e, + y = 0; + y < 80; + y += 1 + ) { + var M, m; + y < 16 + ? ((M = h(t, i, g, r, s, A[B[y]], Q[0], o[y])), + (m = d(l, w, p, D, b, A[I[y]], C[0], a[y]))) + : y < 32 + ? ((M = f(t, i, g, r, s, A[B[y]], Q[1], o[y])), + (m = u(l, w, p, D, b, A[I[y]], C[1], a[y]))) + : y < 48 + ? ((M = E(t, i, g, r, s, A[B[y]], Q[2], o[y])), + (m = E(l, w, p, D, b, A[I[y]], C[2], a[y]))) + : y < 64 + ? ((M = u(t, i, g, r, s, A[B[y]], Q[3], o[y])), + (m = f(l, w, p, D, b, A[I[y]], C[3], a[y]))) + : ((M = d(t, i, g, r, s, A[B[y]], Q[4], o[y])), + (m = h(l, w, p, D, b, A[I[y]], C[4], a[y]))), + (t = s), + (s = r), + (r = c(g, 10)), + (g = i), + (i = M), + (l = b), + (b = D), + (D = c(p, 10)), + (p = w), + (w = m); + } + var G = (this._b + g + D) | 0; + (this._b = (this._c + r + b) | 0), + (this._c = (this._d + s + l) | 0), + (this._d = (this._e + t + w) | 0), + (this._e = (this._a + i + p) | 0), + (this._a = G); + }), + (s.prototype._digest = function () { + (this._block[this._blockOffset++] = 128), + this._blockOffset > 56 && + (this._block.fill(0, this._blockOffset, 64), + this._update(), + (this._blockOffset = 0)), + this._block.fill(0, this._blockOffset, 56), + this._block.writeUInt32LE(this._length[0], 56), + this._block.writeUInt32LE(this._length[1], 60), + this._update(); + var A = i.alloc ? i.alloc(20) : new i(20); + return ( + A.writeInt32LE(this._a, 0), + A.writeInt32LE(this._b, 4), + A.writeInt32LE(this._c, 8), + A.writeInt32LE(this._d, 12), + A.writeInt32LE(this._e, 16), + A + ); + }), + (e.exports = s); + }, + { buffer: 64, "hash-base": 104, inherits: 134 }, + ], + 180: [ + function (A, e, t) { + var i = A("buffer"), + g = i.Buffer; + function r(A, e) { + for (var t in A) e[t] = A[t]; + } + function n(A, e, t) { + return g(A, e, t); + } + g.from && g.alloc && g.allocUnsafe && g.allocUnsafeSlow + ? (e.exports = i) + : (r(i, t), (t.Buffer = n)), + (n.prototype = Object.create(g.prototype)), + r(g, n), + (n.from = function (A, e, t) { + if ("number" == typeof A) + throw new TypeError("Argument must not be a number"); + return g(A, e, t); + }), + (n.alloc = function (A, e, t) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + var i = g(A); + return ( + void 0 !== e + ? "string" == typeof t + ? i.fill(e, t) + : i.fill(e) + : i.fill(0), + i + ); + }), + (n.allocUnsafe = function (A) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + return g(A); + }), + (n.allocUnsafeSlow = function (A) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + return i.SlowBuffer(A); + }); + }, + { buffer: 64 }, + ], + 181: [ + function (A, e, t) { + (function (t) { + "use strict"; + var i, + g = A("buffer"), + r = g.Buffer, + n = {}; + for (i in g) + g.hasOwnProperty(i) && + "SlowBuffer" !== i && + "Buffer" !== i && + (n[i] = g[i]); + var B = (n.Buffer = {}); + for (i in r) + r.hasOwnProperty(i) && + "allocUnsafe" !== i && + "allocUnsafeSlow" !== i && + (B[i] = r[i]); + if ( + ((n.Buffer.prototype = r.prototype), + (B.from && B.from !== Uint8Array.from) || + (B.from = function (A, e, t) { + if ("number" == typeof A) + throw new TypeError( + 'The "value" argument must not be of type number. Received type ' + + typeof A + ); + if (A && void 0 === A.length) + throw new TypeError( + "The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type " + + typeof A + ); + return r(A, e, t); + }), + B.alloc || + (B.alloc = function (A, e, t) { + if ("number" != typeof A) + throw new TypeError( + 'The "size" argument must be of type number. Received type ' + + typeof A + ); + if (A < 0 || A >= 2 * (1 << 30)) + throw new RangeError( + 'The value "' + A + '" is invalid for option "size"' + ); + var i = r(A); + return ( + e && 0 !== e.length + ? "string" == typeof t + ? i.fill(e, t) + : i.fill(e) + : i.fill(0), + i + ); + }), + !n.kStringMaxLength) + ) + try { + n.kStringMaxLength = t.binding("buffer").kStringMaxLength; + } catch (A) {} + n.constants || + ((n.constants = { MAX_LENGTH: n.kMaxLength }), + n.kStringMaxLength && + (n.constants.MAX_STRING_LENGTH = n.kStringMaxLength)), + (e.exports = n); + }.call(this, A("_process"))); + }, + { _process: 154, buffer: 64 }, + ], + 182: [ + function (A, e, t) { + var i = A("safe-buffer").Buffer; + function g(A, e) { + (this._block = i.alloc(A)), + (this._finalSize = e), + (this._blockSize = A), + (this._len = 0); + } + (g.prototype.update = function (A, e) { + "string" == typeof A && ((e = e || "utf8"), (A = i.from(A, e))); + for ( + var t = this._block, + g = this._blockSize, + r = A.length, + n = this._len, + B = 0; + B < r; + + ) { + for (var I = n % g, o = Math.min(r - B, g - I), a = 0; a < o; a++) + t[I + a] = A[B + a]; + (B += o), (n += o) % g == 0 && this._update(t); + } + return (this._len += r), this; + }), + (g.prototype.digest = function (A) { + var e = this._len % this._blockSize; + (this._block[e] = 128), + this._block.fill(0, e + 1), + e >= this._finalSize && + (this._update(this._block), this._block.fill(0)); + var t = 8 * this._len; + if (t <= 4294967295) + this._block.writeUInt32BE(t, this._blockSize - 4); + else { + var i = (4294967295 & t) >>> 0, + g = (t - i) / 4294967296; + this._block.writeUInt32BE(g, this._blockSize - 8), + this._block.writeUInt32BE(i, this._blockSize - 4); + } + this._update(this._block); + var r = this._hash(); + return A ? r.toString(A) : r; + }), + (g.prototype._update = function () { + throw new Error("_update must be implemented by subclass"); + }), + (e.exports = g); + }, + { "safe-buffer": 180 }, + ], + 183: [ + function (A, e, t) { + ((t = e.exports = + function (A) { + A = A.toLowerCase(); + var e = t[A]; + if (!e) + throw new Error( + A + " is not supported (we accept pull requests)" + ); + return new e(); + }).sha = A("./sha")), + (t.sha1 = A("./sha1")), + (t.sha224 = A("./sha224")), + (t.sha256 = A("./sha256")), + (t.sha384 = A("./sha384")), + (t.sha512 = A("./sha512")); + }, + { + "./sha": 184, + "./sha1": 185, + "./sha224": 186, + "./sha256": 187, + "./sha384": 188, + "./sha512": 189, + }, + ], + 184: [ + function (A, e, t) { + var i = A("inherits"), + g = A("./hash"), + r = A("safe-buffer").Buffer, + n = [1518500249, 1859775393, -1894007588, -899497514], + B = new Array(80); + function I() { + this.init(), (this._w = B), g.call(this, 64, 56); + } + function o(A) { + return (A << 30) | (A >>> 2); + } + function a(A, e, t, i) { + return 0 === A + ? (e & t) | (~e & i) + : 2 === A + ? (e & t) | (e & i) | (t & i) + : e ^ t ^ i; + } + i(I, g), + (I.prototype.init = function () { + return ( + (this._a = 1732584193), + (this._b = 4023233417), + (this._c = 2562383102), + (this._d = 271733878), + (this._e = 3285377520), + this + ); + }), + (I.prototype._update = function (A) { + for ( + var e, + t = this._w, + i = 0 | this._a, + g = 0 | this._b, + r = 0 | this._c, + B = 0 | this._d, + I = 0 | this._e, + Q = 0; + Q < 16; + ++Q + ) + t[Q] = A.readInt32BE(4 * Q); + for (; Q < 80; ++Q) + t[Q] = t[Q - 3] ^ t[Q - 8] ^ t[Q - 14] ^ t[Q - 16]; + for (var C = 0; C < 80; ++C) { + var s = ~~(C / 20), + c = + 0 | + ((((e = i) << 5) | (e >>> 27)) + + a(s, g, r, B) + + I + + t[C] + + n[s]); + (I = B), (B = r), (r = o(g)), (g = i), (i = c); + } + (this._a = (i + this._a) | 0), + (this._b = (g + this._b) | 0), + (this._c = (r + this._c) | 0), + (this._d = (B + this._d) | 0), + (this._e = (I + this._e) | 0); + }), + (I.prototype._hash = function () { + var A = r.allocUnsafe(20); + return ( + A.writeInt32BE(0 | this._a, 0), + A.writeInt32BE(0 | this._b, 4), + A.writeInt32BE(0 | this._c, 8), + A.writeInt32BE(0 | this._d, 12), + A.writeInt32BE(0 | this._e, 16), + A + ); + }), + (e.exports = I); + }, + { "./hash": 182, inherits: 134, "safe-buffer": 180 }, + ], + 185: [ + function (A, e, t) { + var i = A("inherits"), + g = A("./hash"), + r = A("safe-buffer").Buffer, + n = [1518500249, 1859775393, -1894007588, -899497514], + B = new Array(80); + function I() { + this.init(), (this._w = B), g.call(this, 64, 56); + } + function o(A) { + return (A << 5) | (A >>> 27); + } + function a(A) { + return (A << 30) | (A >>> 2); + } + function Q(A, e, t, i) { + return 0 === A + ? (e & t) | (~e & i) + : 2 === A + ? (e & t) | (e & i) | (t & i) + : e ^ t ^ i; + } + i(I, g), + (I.prototype.init = function () { + return ( + (this._a = 1732584193), + (this._b = 4023233417), + (this._c = 2562383102), + (this._d = 271733878), + (this._e = 3285377520), + this + ); + }), + (I.prototype._update = function (A) { + for ( + var e, + t = this._w, + i = 0 | this._a, + g = 0 | this._b, + r = 0 | this._c, + B = 0 | this._d, + I = 0 | this._e, + C = 0; + C < 16; + ++C + ) + t[C] = A.readInt32BE(4 * C); + for (; C < 80; ++C) + t[C] = + ((e = t[C - 3] ^ t[C - 8] ^ t[C - 14] ^ t[C - 16]) << 1) | + (e >>> 31); + for (var s = 0; s < 80; ++s) { + var c = ~~(s / 20), + h = (o(i) + Q(c, g, r, B) + I + t[s] + n[c]) | 0; + (I = B), (B = r), (r = a(g)), (g = i), (i = h); + } + (this._a = (i + this._a) | 0), + (this._b = (g + this._b) | 0), + (this._c = (r + this._c) | 0), + (this._d = (B + this._d) | 0), + (this._e = (I + this._e) | 0); + }), + (I.prototype._hash = function () { + var A = r.allocUnsafe(20); + return ( + A.writeInt32BE(0 | this._a, 0), + A.writeInt32BE(0 | this._b, 4), + A.writeInt32BE(0 | this._c, 8), + A.writeInt32BE(0 | this._d, 12), + A.writeInt32BE(0 | this._e, 16), + A + ); + }), + (e.exports = I); + }, + { "./hash": 182, inherits: 134, "safe-buffer": 180 }, + ], + 186: [ + function (A, e, t) { + var i = A("inherits"), + g = A("./sha256"), + r = A("./hash"), + n = A("safe-buffer").Buffer, + B = new Array(64); + function I() { + this.init(), (this._w = B), r.call(this, 64, 56); + } + i(I, g), + (I.prototype.init = function () { + return ( + (this._a = 3238371032), + (this._b = 914150663), + (this._c = 812702999), + (this._d = 4144912697), + (this._e = 4290775857), + (this._f = 1750603025), + (this._g = 1694076839), + (this._h = 3204075428), + this + ); + }), + (I.prototype._hash = function () { + var A = n.allocUnsafe(28); + return ( + A.writeInt32BE(this._a, 0), + A.writeInt32BE(this._b, 4), + A.writeInt32BE(this._c, 8), + A.writeInt32BE(this._d, 12), + A.writeInt32BE(this._e, 16), + A.writeInt32BE(this._f, 20), + A.writeInt32BE(this._g, 24), + A + ); + }), + (e.exports = I); + }, + { "./hash": 182, "./sha256": 187, inherits: 134, "safe-buffer": 180 }, + ], + 187: [ + function (A, e, t) { + var i = A("inherits"), + g = A("./hash"), + r = A("safe-buffer").Buffer, + n = [ + 1116352408, 1899447441, 3049323471, 3921009573, 961987163, + 1508970993, 2453635748, 2870763221, 3624381080, 310598401, + 607225278, 1426881987, 1925078388, 2162078206, 2614888103, + 3248222580, 3835390401, 4022224774, 264347078, 604807628, 770255983, + 1249150122, 1555081692, 1996064986, 2554220882, 2821834349, + 2952996808, 3210313671, 3336571891, 3584528711, 113926993, + 338241895, 666307205, 773529912, 1294757372, 1396182291, 1695183700, + 1986661051, 2177026350, 2456956037, 2730485921, 2820302411, + 3259730800, 3345764771, 3516065817, 3600352804, 4094571909, + 275423344, 430227734, 506948616, 659060556, 883997877, 958139571, + 1322822218, 1537002063, 1747873779, 1955562222, 2024104815, + 2227730452, 2361852424, 2428436474, 2756734187, 3204031479, + 3329325298, + ], + B = new Array(64); + function I() { + this.init(), (this._w = B), g.call(this, 64, 56); + } + function o(A, e, t) { + return t ^ (A & (e ^ t)); + } + function a(A, e, t) { + return (A & e) | (t & (A | e)); + } + function Q(A) { + return ( + ((A >>> 2) | (A << 30)) ^ + ((A >>> 13) | (A << 19)) ^ + ((A >>> 22) | (A << 10)) + ); + } + function C(A) { + return ( + ((A >>> 6) | (A << 26)) ^ + ((A >>> 11) | (A << 21)) ^ + ((A >>> 25) | (A << 7)) + ); + } + function s(A) { + return ((A >>> 7) | (A << 25)) ^ ((A >>> 18) | (A << 14)) ^ (A >>> 3); + } + i(I, g), + (I.prototype.init = function () { + return ( + (this._a = 1779033703), + (this._b = 3144134277), + (this._c = 1013904242), + (this._d = 2773480762), + (this._e = 1359893119), + (this._f = 2600822924), + (this._g = 528734635), + (this._h = 1541459225), + this + ); + }), + (I.prototype._update = function (A) { + for ( + var e, + t = this._w, + i = 0 | this._a, + g = 0 | this._b, + r = 0 | this._c, + B = 0 | this._d, + I = 0 | this._e, + c = 0 | this._f, + h = 0 | this._g, + f = 0 | this._h, + E = 0; + E < 16; + ++E + ) + t[E] = A.readInt32BE(4 * E); + for (; E < 64; ++E) + t[E] = + 0 | + (((((e = t[E - 2]) >>> 17) | (e << 15)) ^ + ((e >>> 19) | (e << 13)) ^ + (e >>> 10)) + + t[E - 7] + + s(t[E - 15]) + + t[E - 16]); + for (var u = 0; u < 64; ++u) { + var d = (f + C(I) + o(I, c, h) + n[u] + t[u]) | 0, + l = (Q(i) + a(i, g, r)) | 0; + (f = h), + (h = c), + (c = I), + (I = (B + d) | 0), + (B = r), + (r = g), + (g = i), + (i = (d + l) | 0); + } + (this._a = (i + this._a) | 0), + (this._b = (g + this._b) | 0), + (this._c = (r + this._c) | 0), + (this._d = (B + this._d) | 0), + (this._e = (I + this._e) | 0), + (this._f = (c + this._f) | 0), + (this._g = (h + this._g) | 0), + (this._h = (f + this._h) | 0); + }), + (I.prototype._hash = function () { + var A = r.allocUnsafe(32); + return ( + A.writeInt32BE(this._a, 0), + A.writeInt32BE(this._b, 4), + A.writeInt32BE(this._c, 8), + A.writeInt32BE(this._d, 12), + A.writeInt32BE(this._e, 16), + A.writeInt32BE(this._f, 20), + A.writeInt32BE(this._g, 24), + A.writeInt32BE(this._h, 28), + A + ); + }), + (e.exports = I); + }, + { "./hash": 182, inherits: 134, "safe-buffer": 180 }, + ], + 188: [ + function (A, e, t) { + var i = A("inherits"), + g = A("./sha512"), + r = A("./hash"), + n = A("safe-buffer").Buffer, + B = new Array(160); + function I() { + this.init(), (this._w = B), r.call(this, 128, 112); + } + i(I, g), + (I.prototype.init = function () { + return ( + (this._ah = 3418070365), + (this._bh = 1654270250), + (this._ch = 2438529370), + (this._dh = 355462360), + (this._eh = 1731405415), + (this._fh = 2394180231), + (this._gh = 3675008525), + (this._hh = 1203062813), + (this._al = 3238371032), + (this._bl = 914150663), + (this._cl = 812702999), + (this._dl = 4144912697), + (this._el = 4290775857), + (this._fl = 1750603025), + (this._gl = 1694076839), + (this._hl = 3204075428), + this + ); + }), + (I.prototype._hash = function () { + var A = n.allocUnsafe(48); + function e(e, t, i) { + A.writeInt32BE(e, i), A.writeInt32BE(t, i + 4); + } + return ( + e(this._ah, this._al, 0), + e(this._bh, this._bl, 8), + e(this._ch, this._cl, 16), + e(this._dh, this._dl, 24), + e(this._eh, this._el, 32), + e(this._fh, this._fl, 40), + A + ); + }), + (e.exports = I); + }, + { "./hash": 182, "./sha512": 189, inherits: 134, "safe-buffer": 180 }, + ], + 189: [ + function (A, e, t) { + var i = A("inherits"), + g = A("./hash"), + r = A("safe-buffer").Buffer, + n = [ + 1116352408, 3609767458, 1899447441, 602891725, 3049323471, + 3964484399, 3921009573, 2173295548, 961987163, 4081628472, + 1508970993, 3053834265, 2453635748, 2937671579, 2870763221, + 3664609560, 3624381080, 2734883394, 310598401, 1164996542, + 607225278, 1323610764, 1426881987, 3590304994, 1925078388, + 4068182383, 2162078206, 991336113, 2614888103, 633803317, + 3248222580, 3479774868, 3835390401, 2666613458, 4022224774, + 944711139, 264347078, 2341262773, 604807628, 2007800933, 770255983, + 1495990901, 1249150122, 1856431235, 1555081692, 3175218132, + 1996064986, 2198950837, 2554220882, 3999719339, 2821834349, + 766784016, 2952996808, 2566594879, 3210313671, 3203337956, + 3336571891, 1034457026, 3584528711, 2466948901, 113926993, + 3758326383, 338241895, 168717936, 666307205, 1188179964, 773529912, + 1546045734, 1294757372, 1522805485, 1396182291, 2643833823, + 1695183700, 2343527390, 1986661051, 1014477480, 2177026350, + 1206759142, 2456956037, 344077627, 2730485921, 1290863460, + 2820302411, 3158454273, 3259730800, 3505952657, 3345764771, + 106217008, 3516065817, 3606008344, 3600352804, 1432725776, + 4094571909, 1467031594, 275423344, 851169720, 430227734, 3100823752, + 506948616, 1363258195, 659060556, 3750685593, 883997877, 3785050280, + 958139571, 3318307427, 1322822218, 3812723403, 1537002063, + 2003034995, 1747873779, 3602036899, 1955562222, 1575990012, + 2024104815, 1125592928, 2227730452, 2716904306, 2361852424, + 442776044, 2428436474, 593698344, 2756734187, 3733110249, + 3204031479, 2999351573, 3329325298, 3815920427, 3391569614, + 3928383900, 3515267271, 566280711, 3940187606, 3454069534, + 4118630271, 4000239992, 116418474, 1914138554, 174292421, + 2731055270, 289380356, 3203993006, 460393269, 320620315, 685471733, + 587496836, 852142971, 1086792851, 1017036298, 365543100, 1126000580, + 2618297676, 1288033470, 3409855158, 1501505948, 4234509866, + 1607167915, 987167468, 1816402316, 1246189591, + ], + B = new Array(160); + function I() { + this.init(), (this._w = B), g.call(this, 128, 112); + } + function o(A, e, t) { + return t ^ (A & (e ^ t)); + } + function a(A, e, t) { + return (A & e) | (t & (A | e)); + } + function Q(A, e) { + return ( + ((A >>> 28) | (e << 4)) ^ + ((e >>> 2) | (A << 30)) ^ + ((e >>> 7) | (A << 25)) + ); + } + function C(A, e) { + return ( + ((A >>> 14) | (e << 18)) ^ + ((A >>> 18) | (e << 14)) ^ + ((e >>> 9) | (A << 23)) + ); + } + function s(A, e) { + return ((A >>> 1) | (e << 31)) ^ ((A >>> 8) | (e << 24)) ^ (A >>> 7); + } + function c(A, e) { + return ( + ((A >>> 1) | (e << 31)) ^ + ((A >>> 8) | (e << 24)) ^ + ((A >>> 7) | (e << 25)) + ); + } + function h(A, e) { + return ((A >>> 19) | (e << 13)) ^ ((e >>> 29) | (A << 3)) ^ (A >>> 6); + } + function f(A, e) { + return ( + ((A >>> 19) | (e << 13)) ^ + ((e >>> 29) | (A << 3)) ^ + ((A >>> 6) | (e << 26)) + ); + } + function E(A, e) { + return A >>> 0 < e >>> 0 ? 1 : 0; + } + i(I, g), + (I.prototype.init = function () { + return ( + (this._ah = 1779033703), + (this._bh = 3144134277), + (this._ch = 1013904242), + (this._dh = 2773480762), + (this._eh = 1359893119), + (this._fh = 2600822924), + (this._gh = 528734635), + (this._hh = 1541459225), + (this._al = 4089235720), + (this._bl = 2227873595), + (this._cl = 4271175723), + (this._dl = 1595750129), + (this._el = 2917565137), + (this._fl = 725511199), + (this._gl = 4215389547), + (this._hl = 327033209), + this + ); + }), + (I.prototype._update = function (A) { + for ( + var e = this._w, + t = 0 | this._ah, + i = 0 | this._bh, + g = 0 | this._ch, + r = 0 | this._dh, + B = 0 | this._eh, + I = 0 | this._fh, + u = 0 | this._gh, + d = 0 | this._hh, + l = 0 | this._al, + w = 0 | this._bl, + p = 0 | this._cl, + D = 0 | this._dl, + b = 0 | this._el, + y = 0 | this._fl, + M = 0 | this._gl, + m = 0 | this._hl, + G = 0; + G < 32; + G += 2 + ) + (e[G] = A.readInt32BE(4 * G)), + (e[G + 1] = A.readInt32BE(4 * G + 4)); + for (; G < 160; G += 2) { + var k = e[G - 30], + F = e[G - 30 + 1], + N = s(k, F), + S = c(F, k), + Y = h((k = e[G - 4]), (F = e[G - 4 + 1])), + v = f(F, k), + K = e[G - 14], + U = e[G - 14 + 1], + J = e[G - 32], + H = e[G - 32 + 1], + R = (S + U) | 0, + q = (N + K + E(R, S)) | 0; + (q = + ((q = (q + Y + E((R = (R + v) | 0), v)) | 0) + + J + + E((R = (R + H) | 0), H)) | + 0), + (e[G] = q), + (e[G + 1] = R); + } + for (var L = 0; L < 160; L += 2) { + (q = e[L]), (R = e[L + 1]); + var x = a(t, i, g), + Z = a(l, w, p), + j = Q(t, l), + W = Q(l, t), + O = C(B, b), + P = C(b, B), + V = n[L], + X = n[L + 1], + z = o(B, I, u), + T = o(b, y, M), + _ = (m + P) | 0, + $ = (d + O + E(_, m)) | 0; + $ = + (($ = + (($ = ($ + z + E((_ = (_ + T) | 0), T)) | 0) + + V + + E((_ = (_ + X) | 0), X)) | + 0) + + q + + E((_ = (_ + R) | 0), R)) | + 0; + var AA = (W + Z) | 0, + eA = (j + x + E(AA, W)) | 0; + (d = u), + (m = M), + (u = I), + (M = y), + (I = B), + (y = b), + (B = (r + $ + E((b = (D + _) | 0), D)) | 0), + (r = g), + (D = p), + (g = i), + (p = w), + (i = t), + (w = l), + (t = ($ + eA + E((l = (_ + AA) | 0), _)) | 0); + } + (this._al = (this._al + l) | 0), + (this._bl = (this._bl + w) | 0), + (this._cl = (this._cl + p) | 0), + (this._dl = (this._dl + D) | 0), + (this._el = (this._el + b) | 0), + (this._fl = (this._fl + y) | 0), + (this._gl = (this._gl + M) | 0), + (this._hl = (this._hl + m) | 0), + (this._ah = (this._ah + t + E(this._al, l)) | 0), + (this._bh = (this._bh + i + E(this._bl, w)) | 0), + (this._ch = (this._ch + g + E(this._cl, p)) | 0), + (this._dh = (this._dh + r + E(this._dl, D)) | 0), + (this._eh = (this._eh + B + E(this._el, b)) | 0), + (this._fh = (this._fh + I + E(this._fl, y)) | 0), + (this._gh = (this._gh + u + E(this._gl, M)) | 0), + (this._hh = (this._hh + d + E(this._hl, m)) | 0); + }), + (I.prototype._hash = function () { + var A = r.allocUnsafe(64); + function e(e, t, i) { + A.writeInt32BE(e, i), A.writeInt32BE(t, i + 4); + } + return ( + e(this._ah, this._al, 0), + e(this._bh, this._bl, 8), + e(this._ch, this._cl, 16), + e(this._dh, this._dl, 24), + e(this._eh, this._el, 32), + e(this._fh, this._fl, 40), + e(this._gh, this._gl, 48), + e(this._hh, this._hl, 56), + A + ); + }), + (e.exports = I); + }, + { "./hash": 182, inherits: 134, "safe-buffer": 180 }, + ], + 190: [ + function (A, e, t) { + e.exports = g; + var i = A("events").EventEmitter; + function g() { + i.call(this); + } + A("inherits")(g, i), + (g.Readable = A("readable-stream/readable.js")), + (g.Writable = A("readable-stream/writable.js")), + (g.Duplex = A("readable-stream/duplex.js")), + (g.Transform = A("readable-stream/transform.js")), + (g.PassThrough = A("readable-stream/passthrough.js")), + (g.Stream = g), + (g.prototype.pipe = function (A, e) { + var t = this; + function g(e) { + A.writable && !1 === A.write(e) && t.pause && t.pause(); + } + function r() { + t.readable && t.resume && t.resume(); + } + t.on("data", g), + A.on("drain", r), + A._isStdio || + (e && !1 === e.end) || + (t.on("end", B), t.on("close", I)); + var n = !1; + function B() { + n || ((n = !0), A.end()); + } + function I() { + n || ((n = !0), "function" == typeof A.destroy && A.destroy()); + } + function o(A) { + if ((a(), 0 === i.listenerCount(this, "error"))) throw A; + } + function a() { + t.removeListener("data", g), + A.removeListener("drain", r), + t.removeListener("end", B), + t.removeListener("close", I), + t.removeListener("error", o), + A.removeListener("error", o), + t.removeListener("end", a), + t.removeListener("close", a), + A.removeListener("close", a); + } + return ( + t.on("error", o), + A.on("error", o), + t.on("end", a), + t.on("close", a), + A.on("close", a), + A.emit("pipe", t), + A + ); + }); + }, + { + events: 102, + inherits: 134, + "readable-stream/duplex.js": 164, + "readable-stream/passthrough.js": 175, + "readable-stream/readable.js": 176, + "readable-stream/transform.js": 177, + "readable-stream/writable.js": 178, + }, + ], + 191: [ + function (A, e, t) { + arguments[4][174][0].apply(t, arguments); + }, + { dup: 174, "safe-buffer": 180 }, + ], + 192: [ + function (A, e, t) { + (function (e, i) { + var g = A("process/browser.js").nextTick, + r = Function.prototype.apply, + n = Array.prototype.slice, + B = {}, + I = 0; + function o(A, e) { + (this._id = A), (this._clearFn = e); + } + (t.setTimeout = function () { + return new o(r.call(setTimeout, window, arguments), clearTimeout); + }), + (t.setInterval = function () { + return new o( + r.call(setInterval, window, arguments), + clearInterval + ); + }), + (t.clearTimeout = t.clearInterval = + function (A) { + A.close(); + }), + (o.prototype.unref = o.prototype.ref = function () {}), + (o.prototype.close = function () { + this._clearFn.call(window, this._id); + }), + (t.enroll = function (A, e) { + clearTimeout(A._idleTimeoutId), (A._idleTimeout = e); + }), + (t.unenroll = function (A) { + clearTimeout(A._idleTimeoutId), (A._idleTimeout = -1); + }), + (t._unrefActive = t.active = + function (A) { + clearTimeout(A._idleTimeoutId); + var e = A._idleTimeout; + e >= 0 && + (A._idleTimeoutId = setTimeout(function () { + A._onTimeout && A._onTimeout(); + }, e)); + }), + (t.setImmediate = + "function" == typeof e + ? e + : function (A) { + var e = I++, + i = !(arguments.length < 2) && n.call(arguments, 1); + return ( + (B[e] = !0), + g(function () { + B[e] && + (i ? A.apply(null, i) : A.call(null), + t.clearImmediate(e)); + }), + e + ); + }), + (t.clearImmediate = + "function" == typeof i + ? i + : function (A) { + delete B[A]; + }); + }.call(this, A("timers").setImmediate, A("timers").clearImmediate)); + }, + { "process/browser.js": 154, timers: 192 }, + ], + 193: [ + function (A, e, t) { + (function (A) { + function t(e) { + try { + if (!A.localStorage) return !1; + } catch (A) { + return !1; + } + var t = A.localStorage[e]; + return null != t && "true" === String(t).toLowerCase(); + } + e.exports = function (A, e) { + if (t("noDeprecation")) return A; + var i = !1; + return function () { + if (!i) { + if (t("throwDeprecation")) throw new Error(e); + t("traceDeprecation") ? console.trace(e) : console.warn(e), + (i = !0); + } + return A.apply(this, arguments); + }; + }; + }.call( + this, + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + {}, + ], + 194: [ + function (A, e, t) { + "function" == typeof Object.create + ? (e.exports = function (A, e) { + (A.super_ = e), + (A.prototype = Object.create(e.prototype, { + constructor: { + value: A, + enumerable: !1, + writable: !0, + configurable: !0, + }, + })); + }) + : (e.exports = function (A, e) { + A.super_ = e; + var t = function () {}; + (t.prototype = e.prototype), + (A.prototype = new t()), + (A.prototype.constructor = A); + }); + }, + {}, + ], + 195: [ + function (A, e, t) { + e.exports = function (A) { + return ( + A && + "object" == typeof A && + "function" == typeof A.copy && + "function" == typeof A.fill && + "function" == typeof A.readUInt8 + ); + }; + }, + {}, + ], + 196: [ + function (A, e, t) { + (function (e, i) { + var g = /%[sdj%]/g; + (t.format = function (A) { + if (!E(A)) { + for (var e = [], t = 0; t < arguments.length; t++) + e.push(B(arguments[t])); + return e.join(" "); + } + t = 1; + for ( + var i = arguments, + r = i.length, + n = String(A).replace(g, function (A) { + if ("%%" === A) return "%"; + if (t >= r) return A; + switch (A) { + case "%s": + return String(i[t++]); + case "%d": + return Number(i[t++]); + case "%j": + try { + return JSON.stringify(i[t++]); + } catch (A) { + return "[Circular]"; + } + default: + return A; + } + }), + I = i[t]; + t < r; + I = i[++t] + ) + h(I) || !l(I) ? (n += " " + I) : (n += " " + B(I)); + return n; + }), + (t.deprecate = function (A, g) { + if (u(i.process)) + return function () { + return t.deprecate(A, g).apply(this, arguments); + }; + if (!0 === e.noDeprecation) return A; + var r = !1; + return function () { + if (!r) { + if (e.throwDeprecation) throw new Error(g); + e.traceDeprecation ? console.trace(g) : console.error(g), + (r = !0); + } + return A.apply(this, arguments); + }; + }); + var r, + n = {}; + function B(A, e) { + var i = { seen: [], stylize: o }; + return ( + arguments.length >= 3 && (i.depth = arguments[2]), + arguments.length >= 4 && (i.colors = arguments[3]), + c(e) ? (i.showHidden = e) : e && t._extend(i, e), + u(i.showHidden) && (i.showHidden = !1), + u(i.depth) && (i.depth = 2), + u(i.colors) && (i.colors = !1), + u(i.customInspect) && (i.customInspect = !0), + i.colors && (i.stylize = I), + a(i, A, i.depth) + ); + } + function I(A, e) { + var t = B.styles[e]; + return t + ? "[" + B.colors[t][0] + "m" + A + "[" + B.colors[t][1] + "m" + : A; + } + function o(A, e) { + return A; + } + function a(A, e, i) { + if ( + A.customInspect && + e && + D(e.inspect) && + e.inspect !== t.inspect && + (!e.constructor || e.constructor.prototype !== e) + ) { + var g = e.inspect(i, A); + return E(g) || (g = a(A, g, i)), g; + } + var r = (function (A, e) { + if (u(e)) return A.stylize("undefined", "undefined"); + if (E(e)) { + var t = + "'" + + JSON.stringify(e) + .replace(/^"|"$/g, "") + .replace(/'/g, "\\'") + .replace(/\\"/g, '"') + + "'"; + return A.stylize(t, "string"); + } + if (f(e)) return A.stylize("" + e, "number"); + if (c(e)) return A.stylize("" + e, "boolean"); + if (h(e)) return A.stylize("null", "null"); + })(A, e); + if (r) return r; + var n = Object.keys(e), + B = (function (A) { + var e = {}; + return ( + A.forEach(function (A, t) { + e[A] = !0; + }), + e + ); + })(n); + if ( + (A.showHidden && (n = Object.getOwnPropertyNames(e)), + p(e) && + (n.indexOf("message") >= 0 || n.indexOf("description") >= 0)) + ) + return Q(e); + if (0 === n.length) { + if (D(e)) { + var I = e.name ? ": " + e.name : ""; + return A.stylize("[Function" + I + "]", "special"); + } + if (d(e)) + return A.stylize(RegExp.prototype.toString.call(e), "regexp"); + if (w(e)) + return A.stylize(Date.prototype.toString.call(e), "date"); + if (p(e)) return Q(e); + } + var o, + l = "", + b = !1, + y = ["{", "}"]; + (s(e) && ((b = !0), (y = ["[", "]"])), D(e)) && + (l = " [Function" + (e.name ? ": " + e.name : "") + "]"); + return ( + d(e) && (l = " " + RegExp.prototype.toString.call(e)), + w(e) && (l = " " + Date.prototype.toUTCString.call(e)), + p(e) && (l = " " + Q(e)), + 0 !== n.length || (b && 0 != e.length) + ? i < 0 + ? d(e) + ? A.stylize(RegExp.prototype.toString.call(e), "regexp") + : A.stylize("[Object]", "special") + : (A.seen.push(e), + (o = b + ? (function (A, e, t, i, g) { + for (var r = [], n = 0, B = e.length; n < B; ++n) + m(e, String(n)) + ? r.push(C(A, e, t, i, String(n), !0)) + : r.push(""); + return ( + g.forEach(function (g) { + g.match(/^\d+$/) || r.push(C(A, e, t, i, g, !0)); + }), + r + ); + })(A, e, i, B, n) + : n.map(function (t) { + return C(A, e, i, B, t, b); + })), + A.seen.pop(), + (function (A, e, t) { + if ( + A.reduce(function (A, e) { + return ( + 0, + e.indexOf("\n") >= 0 && 0, + A + e.replace(/\u001b\[\d\d?m/g, "").length + 1 + ); + }, 0) > 60 + ) + return ( + t[0] + + ("" === e ? "" : e + "\n ") + + " " + + A.join(",\n ") + + " " + + t[1] + ); + return t[0] + e + " " + A.join(", ") + " " + t[1]; + })(o, l, y)) + : y[0] + l + y[1] + ); + } + function Q(A) { + return "[" + Error.prototype.toString.call(A) + "]"; + } + function C(A, e, t, i, g, r) { + var n, B, I; + if ( + ((I = Object.getOwnPropertyDescriptor(e, g) || { value: e[g] }) + .get + ? (B = I.set + ? A.stylize("[Getter/Setter]", "special") + : A.stylize("[Getter]", "special")) + : I.set && (B = A.stylize("[Setter]", "special")), + m(i, g) || (n = "[" + g + "]"), + B || + (A.seen.indexOf(I.value) < 0 + ? (B = h(t) + ? a(A, I.value, null) + : a(A, I.value, t - 1)).indexOf("\n") > -1 && + (B = r + ? B.split("\n") + .map(function (A) { + return " " + A; + }) + .join("\n") + .substr(2) + : "\n" + + B.split("\n") + .map(function (A) { + return " " + A; + }) + .join("\n")) + : (B = A.stylize("[Circular]", "special"))), + u(n)) + ) { + if (r && g.match(/^\d+$/)) return B; + (n = JSON.stringify("" + g)).match(/^"([a-zA-Z_][a-zA-Z_0-9]*)"$/) + ? ((n = n.substr(1, n.length - 2)), (n = A.stylize(n, "name"))) + : ((n = n + .replace(/'/g, "\\'") + .replace(/\\"/g, '"') + .replace(/(^"|"$)/g, "'")), + (n = A.stylize(n, "string"))); + } + return n + ": " + B; + } + function s(A) { + return Array.isArray(A); + } + function c(A) { + return "boolean" == typeof A; + } + function h(A) { + return null === A; + } + function f(A) { + return "number" == typeof A; + } + function E(A) { + return "string" == typeof A; + } + function u(A) { + return void 0 === A; + } + function d(A) { + return l(A) && "[object RegExp]" === b(A); + } + function l(A) { + return "object" == typeof A && null !== A; + } + function w(A) { + return l(A) && "[object Date]" === b(A); + } + function p(A) { + return l(A) && ("[object Error]" === b(A) || A instanceof Error); + } + function D(A) { + return "function" == typeof A; + } + function b(A) { + return Object.prototype.toString.call(A); + } + function y(A) { + return A < 10 ? "0" + A.toString(10) : A.toString(10); + } + (t.debuglog = function (A) { + if ( + (u(r) && (r = e.env.NODE_DEBUG || ""), + (A = A.toUpperCase()), + !n[A]) + ) + if (new RegExp("\\b" + A + "\\b", "i").test(r)) { + var i = e.pid; + n[A] = function () { + var e = t.format.apply(t, arguments); + console.error("%s %d: %s", A, i, e); + }; + } else n[A] = function () {}; + return n[A]; + }), + (t.inspect = B), + (B.colors = { + bold: [1, 22], + italic: [3, 23], + underline: [4, 24], + inverse: [7, 27], + white: [37, 39], + grey: [90, 39], + black: [30, 39], + blue: [34, 39], + cyan: [36, 39], + green: [32, 39], + magenta: [35, 39], + red: [31, 39], + yellow: [33, 39], + }), + (B.styles = { + special: "cyan", + number: "yellow", + boolean: "yellow", + undefined: "grey", + null: "bold", + string: "green", + date: "magenta", + regexp: "red", + }), + (t.isArray = s), + (t.isBoolean = c), + (t.isNull = h), + (t.isNullOrUndefined = function (A) { + return null == A; + }), + (t.isNumber = f), + (t.isString = E), + (t.isSymbol = function (A) { + return "symbol" == typeof A; + }), + (t.isUndefined = u), + (t.isRegExp = d), + (t.isObject = l), + (t.isDate = w), + (t.isError = p), + (t.isFunction = D), + (t.isPrimitive = function (A) { + return ( + null === A || + "boolean" == typeof A || + "number" == typeof A || + "string" == typeof A || + "symbol" == typeof A || + void 0 === A + ); + }), + (t.isBuffer = A("./support/isBuffer")); + var M = [ + "Jan", + "Feb", + "Mar", + "Apr", + "May", + "Jun", + "Jul", + "Aug", + "Sep", + "Oct", + "Nov", + "Dec", + ]; + function m(A, e) { + return Object.prototype.hasOwnProperty.call(A, e); + } + (t.log = function () { + var A, e; + console.log( + "%s - %s", + ((A = new Date()), + (e = [y(A.getHours()), y(A.getMinutes()), y(A.getSeconds())].join( + ":" + )), + [A.getDate(), M[A.getMonth()], e].join(" ")), + t.format.apply(t, arguments) + ); + }), + (t.inherits = A("inherits")), + (t._extend = function (A, e) { + if (!e || !l(e)) return A; + for (var t = Object.keys(e), i = t.length; i--; ) + A[t[i]] = e[t[i]]; + return A; + }); + }.call( + this, + A("_process"), + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { "./support/isBuffer": 195, _process: 154, inherits: 194 }, + ], + 197: [ + function (A, e, t) { + e.exports = function (A, e) { + if (!Object.prototype.hasOwnProperty.call(A, e)) + throw new TypeError( + "attempted to use private field on non-instance" + ); + return A; + }; + }, + {}, + ], + 198: [ + function (A, e, t) { + var i = 0; + e.exports = function (A) { + return "__private_" + i++ + "_" + A; + }; + }, + {}, + ], + 199: [ + function (A, e, t) { + e.exports = function (A, e, t) { + return ( + e in A + ? Object.defineProperty(A, e, { + value: t, + enumerable: !0, + configurable: !0, + writable: !0, + }) + : (A[e] = t), + A + ); + }; + }, + {}, + ], + 200: [ + function (A, e, t) { + e.exports = function (A) { + return A && A.__esModule ? A : { default: A }; + }; + }, + {}, + ], + 201: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + const e = 35 === A.length, + t = A.length - (e ? 2 : 1), + i = (0, g.default)(A.subarray(0, t)); + return [ + e + ? A[A.length - 2] === i[0] && A[A.length - 1] === i[1] + : A[A.length - 1] === i[0], + t, + ]; + }); + var g = i(A("./sshash")); + }, + { "./sshash": 206, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 202: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e, t = 99) { + if ((0, r.isU8a)(A) || (0, r.isHex)(A)) return (0, r.u8aToU8a)(A); + const i = (0, r.bufferToU8a)(g.default.decode(A)), + I = (e) => `Decoding ${A}: ${e}`; + (0, r.assert)( + B.default.allowedEncodedLengths.includes(i.length), + I("Invalid decoded address length") + ); + const [o, a] = (0, n.default)(i); + return ( + (0, r.assert)(e || o, I("Invalid decoded address checksum")), + i.slice(1, a) + ); + }); + var g = i(A("bs58")), + r = A("@polkadot/util"), + n = i(A("./checkChecksum")), + B = i(A("./defaults")); + }, + { + "./checkChecksum": 201, + "./defaults": 203, + "@babel/runtime/helpers/interopRequireDefault": 200, + "@polkadot/util": 246, + bs58: 317, + }, + ], + 203: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = void 0); + var i = { + allowedDecodedLengths: [1, 2, 4, 8, 32], + allowedEncodedLengths: [3, 4, 6, 10, 35], + allowedPrefix: A("./ss58").allowedSS58, + prefix: 42, + }; + t.default = i; + }, + { "./ss58": 205 }, + ], + 204: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = B.default.prefix) { + const t = (0, n.default)(A); + (0, r.assert)( + B.default.allowedDecodedLengths.includes(t.length), + `Expected a valid key to convert, with length ${B.default.allowedDecodedLengths.join( + ", " + )}` + ); + const i = 32 === t.length, + o = (0, r.u8aConcat)(new Uint8Array([e]), t), + a = (0, I.default)(o); + return g.default.encode( + (0, r.u8aToBuffer)((0, r.u8aConcat)(o, a.subarray(0, i ? 2 : 1))) + ); + }); + var g = i(A("bs58")), + r = A("@polkadot/util"), + n = i(A("./decode")), + B = i(A("./defaults")), + I = i(A("./sshash")); + }, + { + "./decode": 202, + "./defaults": 203, + "./sshash": 206, + "@babel/runtime/helpers/interopRequireDefault": 200, + "@polkadot/util": 246, + bs58: 317, + }, + ], + 205: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.allowedSS58 = void 0); + t.allowedSS58 = [0, 1, 2, 3, 16, 17, 20, 42, 43, 68, 69]; + }, + {}, + ], + 206: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, r.default)((0, g.u8aConcat)(n, A), 512); + }); + var g = A("@polkadot/util"), + r = i(A("../blake2/asU8a")); + const n = (0, g.stringToU8a)("SS58PRE"); + }, + { + "../blake2/asU8a": 207, + "@babel/runtime/helpers/interopRequireDefault": 200, + "@polkadot/util": 246, + }, + ], + 207: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = 256, t = null, i = !1) { + const B = Math.ceil(e / 8); + return (0, n.isReady)() && !i + ? (0, n.blake2b)((0, r.u8aToU8a)(A), (0, r.u8aToU8a)(t), B) + : g.default.blake2b((0, r.u8aToU8a)(A), t, B); + }); + var g = i(A("blakejs")), + r = A("@polkadot/util"), + n = A("@polkadot/wasm-crypto"); + }, + { + "@babel/runtime/helpers/interopRequireDefault": 200, + "@polkadot/util": 246, + "@polkadot/wasm-crypto": 301, + blakejs: 314, + }, + ], + 208: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = !0) { + return A.filter( + (A) => !(0, r.default)(A) && (e || !(0, g.default)(A)) + ); + }); + var g = i(A("../is/null")), + r = i(A("../is/undefined")); + }, + { + "../is/null": 259, + "../is/undefined": 267, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 209: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "arrayFilter", { + enumerable: !0, + get: function () { + return g.default; + }, + }); + var g = i(A("./filter")); + }, + { "./filter": 208, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 210: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e) { + if (!A) throw new Error((0, g.default)(e) ? e() : e); + }); + var g = i(A("./is/function")); + }, + { + "./is/function": 253, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 211: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.BN_THOUSAND = + t.BN_HUNDRED = + t.BN_TEN = + t.BN_ONE = + t.BN_ZERO = + void 0); + var g = i(A("bn.js")); + const r = new g.default(0); + t.BN_ZERO = r; + const n = new g.default(1); + t.BN_ONE = n; + const B = new g.default(10); + t.BN_TEN = B; + const I = new g.default(100); + t.BN_HUNDRED = I; + const o = new g.default(1e3); + t.BN_THOUSAND = o; + }, + { "@babel/runtime/helpers/interopRequireDefault": 200, "bn.js": 316 }, + ], + 212: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = void 0); + var g = i(A("../hex/toBn")).default; + t.default = g; + }, + { + "../hex/toBn": 242, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 213: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }); + var g = { + bnFromHex: !0, + bnMax: !0, + bnMin: !0, + bnSqrt: !0, + bnToBn: !0, + bnToHex: !0, + bnToU8a: !0, + }; + Object.defineProperty(t, "bnFromHex", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "bnMax", { + enumerable: !0, + get: function () { + return B.default; + }, + }), + Object.defineProperty(t, "bnMin", { + enumerable: !0, + get: function () { + return I.default; + }, + }), + Object.defineProperty(t, "bnSqrt", { + enumerable: !0, + get: function () { + return o.default; + }, + }), + Object.defineProperty(t, "bnToBn", { + enumerable: !0, + get: function () { + return a.default; + }, + }), + Object.defineProperty(t, "bnToHex", { + enumerable: !0, + get: function () { + return Q.default; + }, + }), + Object.defineProperty(t, "bnToU8a", { + enumerable: !0, + get: function () { + return C.default; + }, + }); + var r = A("./consts"); + Object.keys(r).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return r[A]; + }, + })); + }); + var n = i(A("./fromHex")), + B = i(A("./max")), + I = i(A("./min")), + o = i(A("./sqrt")), + a = i(A("./toBn")), + Q = i(A("./toHex")), + C = i(A("./toU8a")); + }, + { + "./consts": 211, + "./fromHex": 212, + "./max": 214, + "./min": 215, + "./sqrt": 216, + "./toBn": 217, + "./toHex": 218, + "./toU8a": 219, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 214: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (...A) { + return ( + (0, r.default)( + A && A.length >= 1, + "Must provide one or more BN arguments" + ), + A.reduce((A, e) => g.default.max(A, e), A[0]) + ); + }); + var g = i(A("bn.js")), + r = i(A("../assert")); + }, + { + "../assert": 210, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 215: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (...A) { + return ( + (0, r.default)( + A && A.length >= 1, + "Must provide one or more BN arguments" + ), + A.reduce((A, e) => g.default.min(A, e), A[0]) + ); + }); + var g = i(A("bn.js")), + r = i(A("../assert")); + }, + { + "../assert": 210, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 216: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return ( + (0, r.default)( + A.gten(0), + "square root of negative numbers is not supported" + ), + A.ltn(2) + ? A + : (function A(e, t) { + const i = e.div(t).add(t).shrn(1); + return t.eq(i) || t.eq(i.subn(1)) ? t : A(e, i); + })(A, new g.default(1)) + ); + }); + var g = i(A("bn.js")), + r = i(A("../assert")); + }, + { + "../assert": 210, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 217: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + if (!A) return new g.default(0); + if ((0, B.default)(A)) return (0, I.default)(A.toString()); + if ((0, r.default)(A)) return new g.default(A.toString()); + return g.default.isBN(A) + ? A + : (0, n.default)(A) + ? A.toBn() + : new g.default(A); + }); + var g = i(A("bn.js")), + r = i(A("../is/bigInt")), + n = i(A("../is/toBn")), + B = i(A("../is/hex")), + I = i(A("../hex/toBn")); + }, + { + "../hex/toBn": 242, + "../is/bigInt": 247, + "../is/hex": 254, + "../is/toBn": 265, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 218: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = void 0); + var g = i(A("@babel/runtime/helpers/defineProperty")), + r = i(A("../is/number")), + n = i(A("./toU8a")), + B = A("../u8a"); + function I(A, e) { + var t = Object.keys(A); + if (Object.getOwnPropertySymbols) { + var i = Object.getOwnPropertySymbols(A); + e && + (i = i.filter(function (e) { + return Object.getOwnPropertyDescriptor(A, e).enumerable; + })), + t.push.apply(t, i); + } + return t; + } + const o = "0x00"; + var a = function ( + A, + e = { bitLength: -1, isLe: !1, isNegative: !1 }, + t + ) { + if (!A) return o; + const i = (function (A) { + for (var e = 1; e < arguments.length; e++) { + var t = null != arguments[e] ? arguments[e] : {}; + e % 2 + ? I(Object(t), !0).forEach(function (e) { + (0, g.default)(A, e, t[e]); + }) + : Object.getOwnPropertyDescriptors + ? Object.defineProperties( + A, + Object.getOwnPropertyDescriptors(t) + ) + : I(Object(t)).forEach(function (e) { + Object.defineProperty( + A, + e, + Object.getOwnPropertyDescriptor(t, e) + ); + }); + } + return A; + })( + { isLe: !1, isNegative: !1 }, + (0, r.default)(e) ? { bitLength: e, isLe: t } : e + ); + return (0, B.u8aToHex)((0, n.default)(A, i)); + }; + t.default = a; + }, + { + "../is/number": 260, + "../u8a": 293, + "./toU8a": 219, + "@babel/runtime/helpers/defineProperty": 199, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 219: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = void 0); + var g = i(A("@babel/runtime/helpers/defineProperty")), + r = i(A("../is/number")), + n = i(A("./toBn")); + function B(A, e) { + var t = Object.keys(A); + if (Object.getOwnPropertySymbols) { + var i = Object.getOwnPropertySymbols(A); + e && + (i = i.filter(function (e) { + return Object.getOwnPropertyDescriptor(A, e).enumerable; + })), + t.push.apply(t, i); + } + return t; + } + var I = function ( + A, + e = { bitLength: -1, isLe: !0, isNegative: !1 }, + t + ) { + const i = (function (A) { + for (var e = 1; e < arguments.length; e++) { + var t = null != arguments[e] ? arguments[e] : {}; + e % 2 + ? B(Object(t), !0).forEach(function (e) { + (0, g.default)(A, e, t[e]); + }) + : Object.getOwnPropertyDescriptors + ? Object.defineProperties( + A, + Object.getOwnPropertyDescriptors(t) + ) + : B(Object(t)).forEach(function (e) { + Object.defineProperty( + A, + e, + Object.getOwnPropertyDescriptor(t, e) + ); + }); + } + return A; + })( + { bitLength: -1, isLe: !0, isNegative: !1 }, + (0, r.default)(e) ? { bitLength: e, isLe: t } : e + ), + I = (0, n.default)(A), + o = + -1 === i.bitLength + ? Math.ceil(I.bitLength() / 8) + : Math.ceil((i.bitLength || 0) / 8); + if (!A) + return -1 === i.bitLength ? new Uint8Array() : new Uint8Array(o); + const a = new Uint8Array(o), + Q = i.isNegative ? I.toTwos(8 * o) : I; + return a.set(Q.toArray(i.isLe ? "le" : "be", o), 0), a; + }; + t.default = I; + }, + { + "../is/number": 260, + "./toBn": 217, + "@babel/runtime/helpers/defineProperty": 199, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 220: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "bufferToU8a", { + enumerable: !0, + get: function () { + return g.default; + }, + }); + var g = i(A("./toU8a")); + }, + { "./toU8a": 221, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 221: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return new Uint8Array(A || []); + }); + }, + {}, + ], + 222: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, g.u8aConcat)((0, r.default)(A.length), A); + }); + var g = A("../u8a"), + r = i(A("./toU8a")); + }, + { + "../u8a": 293, + "./toU8a": 227, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 223: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.DEFAULT_BITLENGTH = void 0); + t.DEFAULT_BITLENGTH = 32; + }, + {}, + ], + 224: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = n.DEFAULT_BITLENGTH) { + const t = (0, r.u8aToU8a)(A), + i = 3 & t[0]; + if (0 === i) return [1, new g.default(t[0]).shrn(2)]; + if (1 === i) return [2, (0, r.u8aToBn)(t.slice(0, 2), !0).shrn(2)]; + if (2 === i) return [4, (0, r.u8aToBn)(t.slice(0, 4), !0).shrn(2)]; + const B = 1 + new g.default(t[0]).shrn(2).addn(4).toNumber(); + return [B, (0, r.u8aToBn)(t.subarray(1, B), !0)]; + }); + var g = i(A("bn.js")), + r = A("../u8a"), + n = A("./defaults"); + }, + { + "../u8a": 293, + "./defaults": 223, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 225: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "compactAddLength", { + enumerable: !0, + get: function () { + return g.default; + }, + }), + Object.defineProperty(t, "compactStripLength", { + enumerable: !0, + get: function () { + return r.default; + }, + }), + Object.defineProperty(t, "compactFromU8a", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "compactToU8a", { + enumerable: !0, + get: function () { + return B.default; + }, + }); + var g = i(A("./addLength")), + r = i(A("./stripLength")), + n = i(A("./fromU8a")), + B = i(A("./toU8a")); + }, + { + "./addLength": 222, + "./fromU8a": 224, + "./stripLength": 226, + "./toU8a": 227, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 226: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = g.DEFAULT_BITLENGTH) { + const [t, i] = (0, r.default)(A, e), + n = t + i.toNumber(); + return [n, A.subarray(t, n)]; + }); + var g = A("./defaults"), + r = i(A("./fromU8a")); + }, + { + "./defaults": 223, + "./fromU8a": 224, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 227: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + const e = (0, n.bnToBn)(A); + if (e.lte(I)) return new Uint8Array([e.toNumber() << 2]); + if (e.lte(o)) return (0, n.bnToU8a)(e.shln(2).addn(1), 16, !0); + if (e.lte(a)) return (0, n.bnToU8a)(e.shln(2).addn(2), 32, !0); + const t = (0, n.bnToU8a)(e); + let i = t.length; + for (; 0 === t[i - 1]; ) i--; + return ( + (0, r.default)( + i >= 4, + "Previous tests match anyting less than 2^30; qed" + ), + (0, B.u8aConcat)( + new Uint8Array([3 + ((i - 4) << 2)]), + t.subarray(0, i) + ) + ); + }); + var g = i(A("bn.js")), + r = i(A("../assert")), + n = A("../bn"), + B = A("../u8a"); + const I = new g.default(2).pow(new g.default(6)).subn(1), + o = new g.default(2).pow(new g.default(14)).subn(1), + a = new g.default(2).pow(new g.default(30)).subn(1); + }, + { + "../assert": 210, + "../bn": 213, + "../u8a": 293, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 228: [ + function (A, e, t) { + (function (e) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function ({ name: A, version: t }, i) { + const n = "undefined" != typeof window ? window : e; + n.__polkadotjs || (n.__polkadotjs = {}); + if ( + ((0, g.default)( + A.startsWith("@polkadot"), + `Invalid package descriptor ${A}` + ), + (n.__polkadotjs[A] = [ + ...(n.__polkadotjs[A] || []), + { path: i || "", version: t }, + ]), + 1 !== n.__polkadotjs[A].length) + ) { + const e = (function (A) { + const e = A.map((A) => + (0, r.default)(A) ? { version: A } : A + ), + t = e.reduce( + (A, { version: e }) => Math.max(A, e.length), + 0 + ); + return e + .map( + ({ path: A, version: e }) => + `\t${e.padEnd(t)}\t${ + ((A = A), !A || A.length < 5 ? "" : A) + }` + ) + .join("\n"); + var i; + })(n.__polkadotjs[A]); + console.warn( + `Multiple instances of ${A} detected, ensure that there is only one package in your dependency tree.\n${e}` + ); + } + }); + var g = i(A("./assert")), + r = i(A("./is/string")); + }.call( + this, + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { + "./assert": 210, + "./is/string": 263, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 229: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function A(e) { + if (!e) return a; + if (e < 1e3) return n(n({}, a), {}, { milliseconds: e }); + const t = e / 1e3; + if (t < 60) { + const i = Math.floor(t); + return o(n(n({}, a), {}, { seconds: i }), A(e - 1e3 * i)); + } + const i = t / 60; + if (i < 60) { + const t = Math.floor(i); + return o(n(n({}, a), {}, { minutes: t }), A(e - 60 * t * 1e3)); + } + const g = i / 60; + if (g < 24) { + const t = Math.floor(g); + return o(n(n({}, a), {}, { hours: t }), A(e - t * B * 1e3)); + } + const r = Math.floor(g / 24); + return o(n(n({}, a), {}, { days: r }), A(e - r * I * 1e3)); + }); + var g = i(A("@babel/runtime/helpers/defineProperty")); + function r(A, e) { + var t = Object.keys(A); + if (Object.getOwnPropertySymbols) { + var i = Object.getOwnPropertySymbols(A); + e && + (i = i.filter(function (e) { + return Object.getOwnPropertyDescriptor(A, e).enumerable; + })), + t.push.apply(t, i); + } + return t; + } + function n(A) { + for (var e = 1; e < arguments.length; e++) { + var t = null != arguments[e] ? arguments[e] : {}; + e % 2 + ? r(Object(t), !0).forEach(function (e) { + (0, g.default)(A, e, t[e]); + }) + : Object.getOwnPropertyDescriptors + ? Object.defineProperties(A, Object.getOwnPropertyDescriptors(t)) + : r(Object(t)).forEach(function (e) { + Object.defineProperty( + A, + e, + Object.getOwnPropertyDescriptor(t, e) + ); + }); + } + return A; + } + const B = 3600, + I = 24 * B; + function o(A, e) { + return { + days: A.days + e.days, + hours: A.hours + e.hours, + milliseconds: A.milliseconds + e.milliseconds, + minutes: A.minutes + e.minutes, + seconds: A.seconds + e.seconds, + }; + } + const a = { + days: 0, + hours: 0, + milliseconds: 0, + minutes: 0, + seconds: 0, + }; + }, + { + "@babel/runtime/helpers/defineProperty": 199, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 230: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = void 0); + var g = i(A("../bn/toBn")), + r = i(A("../is/boolean")), + n = i(A("../is/undefined")), + B = i(A("./formatDecimal")), + I = A("./si"); + let o = 0, + a = I.SI[I.SI_MID].text; + const Q = function (A, e = !0, t = o) { + let i = (0, g.default)(A).toString(); + if (0 === i.length || "0" === i) return "0"; + const n = i[0].startsWith("-"); + n && (i = i.substr(1)); + const { + decimals: a = t, + forceUnit: Q, + withSi: C = !0, + withSiFull: s = !1, + withUnit: c = !0, + } = (0, r.default)(e) ? { withSi: e } : e, + h = (0, I.calcSi)(i, a, Q), + f = i.length - (a + h.power), + E = i.substr(0, f), + u = `${`${new Array(1 + (f < 0 ? 0 - f : 0)).join("0")}${i}`.substr( + f < 0 ? 0 : f + )}000`.substr(0, 3), + d = + C || s + ? "-" === h.value + ? c + ? ` ${(0, r.default)(c) ? h.text : c}` + : "" + : `${s ? ` ${h.text}` : h.value}${ + c ? ` ${(0, r.default)(c) ? I.SI[I.SI_MID].text : c}` : "" + }` + : ""; + return `${n ? "-" : ""}${(0, B.default)(E || "0")}.${u}${d}`; + }; + (Q.calcSi = (A, e = o) => (0, I.calcSi)(A, e)), + (Q.findSi = I.findSi), + (Q.getDefaults = () => ({ decimals: o, unit: a })), + (Q.getOptions = (A = o) => + I.SI.filter(({ power: e }) => !(e < 0) || A + e >= 0)), + (Q.setDefaults = ({ decimals: A, unit: e }) => { + (o = (0, n.default)(A) ? o : A), + (a = (0, n.default)(e) ? a : e), + (I.SI[I.SI_MID].text = a); + }); + var C = Q; + t.default = C; + }, + { + "../bn/toBn": 217, + "../is/boolean": 249, + "../is/undefined": 267, + "./formatDecimal": 232, + "./si": 236, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 231: [ + function (A, e, t) { + "use strict"; + function i(A) { + return A.toString().padStart(2, "0"); + } + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + const e = A.getFullYear().toString(), + t = i(A.getMonth() + 1), + g = i(A.getDate()), + r = i(A.getHours()), + n = i(A.getMinutes()), + B = i(A.getSeconds()); + return `${e}-${t}-${g} ${r}:${n}:${B}`; + }); + }, + {}, + ], + 232: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + const e = A[0].startsWith("-"), + t = e ? A.substr(1).match(i) : A.match(i); + return t ? `${e ? "-" : ""}${t.join(",")}` : A; + }); + const i = new RegExp("(\\d+?)(?=(\\d{3})+(?!\\d)|$)", "g"); + }, + {}, + ], + 233: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e) { + const t = (A && A.getTime()) || 0, + i = (function A(e) { + if (e) { + if ((0, r.default)(e)) return A(e.toBn()); + if (e instanceof Date) return A(e.getTime()); + if (e instanceof g.default) return A(e.toNumber()); + } + return e || 0; + })(e); + let n = "0.0s"; + if (t && i) { + const A = Math.max(Math.abs(t - i), 0) / 1e3; + n = + A < 15 + ? `${A.toFixed(1)}s` + : A < 60 + ? `${0 | A}s` + : A < 3600 + ? `${(A / 60) | 0}m` + : `${(A / 3600) | 0}h`; + } + return n; + }); + var g = i(A("bn.js")), + r = i(A("../is/toBn")); + }, + { + "../is/toBn": 265, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 234: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, r.default)((0, g.default)(A).toString()); + }); + var g = i(A("../bn/toBn")), + r = i(A("./formatDecimal")); + }, + { + "../bn/toBn": 217, + "./formatDecimal": 232, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 235: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "formatBalance", { + enumerable: !0, + get: function () { + return g.default; + }, + }), + Object.defineProperty(t, "formatDate", { + enumerable: !0, + get: function () { + return r.default; + }, + }), + Object.defineProperty(t, "formatDecimal", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "formatElapsed", { + enumerable: !0, + get: function () { + return B.default; + }, + }), + Object.defineProperty(t, "formatNumber", { + enumerable: !0, + get: function () { + return I.default; + }, + }), + Object.defineProperty(t, "calcSi", { + enumerable: !0, + get: function () { + return o.calcSi; + }, + }), + Object.defineProperty(t, "findSi", { + enumerable: !0, + get: function () { + return o.findSi; + }, + }); + var g = i(A("./formatBalance")), + r = i(A("./formatDate")), + n = i(A("./formatDecimal")), + B = i(A("./formatElapsed")), + I = i(A("./formatNumber")), + o = A("./si"); + }, + { + "./formatBalance": 230, + "./formatDate": 231, + "./formatDecimal": 232, + "./formatElapsed": 233, + "./formatNumber": 234, + "./si": 236, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 236: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.findSi = r), + (t.calcSi = function (A, e, t) { + if (t) return r(t); + const n = i - 1 + Math.ceil((A.length - e) / 3); + return g[n] || g[n < 0 ? 0 : g.length - 1]; + }), + (t.SI = t.SI_MID = void 0); + const i = 8; + t.SI_MID = i; + const g = [ + { power: -24, text: "yocto", value: "y" }, + { power: -21, text: "zepto", value: "z" }, + { power: -18, text: "atto", value: "a" }, + { power: -15, text: "femto", value: "f" }, + { power: -12, text: "pico", value: "p" }, + { power: -9, text: "nano", value: "n" }, + { power: -6, text: "micro", value: "µ" }, + { power: -3, text: "milli", value: "m" }, + { power: 0, text: "Unit", value: "-" }, + { power: 3, text: "Kilo", value: "k" }, + { power: 6, text: "Mega", value: "M" }, + { power: 9, text: "Giga", value: "G" }, + { power: 12, text: "Tera", value: "T" }, + { power: 15, text: "Peta", value: "P" }, + { power: 18, text: "Exa", value: "E" }, + { power: 21, text: "Zeta", value: "Z" }, + { power: 24, text: "Yotta", value: "Y" }, + ]; + function r(A) { + for (let e = 0; e < g.length; e++) if (g[e].value === A) return g[e]; + return g[i]; + } + t.SI = g; + }, + {}, + ], + 237: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + if (A && (0, g.default)(A)) return A; + return `0x${A && A.length % 2 == 1 ? "0" : ""}${A || ""}`; + }); + var g = i(A("./hasPrefix")); + }, + { + "./hasPrefix": 239, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 238: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = -1, t = !1) { + const i = Math.ceil(e / 4), + n = i + 2; + return (0, g.default)( + -1 === e || A.length === n || (!t && A.length < n) + ? (0, r.default)(A) + : A.length > n + ? (0, r.default)(A).slice(-1 * i) + : `${"0".repeat(i)}${(0, r.default)(A)}`.slice(-1 * i) + ); + }); + var g = i(A("./addPrefix")), + r = i(A("./stripPrefix")); + }, + { + "./addPrefix": 237, + "./stripPrefix": 241, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 239: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return !( + !A || + !(0, g.default)(A, -1, !0) || + "0x" !== A.substr(0, 2) + ); + }); + var g = i(A("../is/hex")); + }, + { "../is/hex": 254, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 240: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "hexAddPrefix", { + enumerable: !0, + get: function () { + return g.default; + }, + }), + Object.defineProperty(t, "hexFixLength", { + enumerable: !0, + get: function () { + return r.default; + }, + }), + Object.defineProperty(t, "hexHasPrefix", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "hexStripPrefix", { + enumerable: !0, + get: function () { + return B.default; + }, + }), + Object.defineProperty(t, "hexToBn", { + enumerable: !0, + get: function () { + return I.default; + }, + }), + Object.defineProperty(t, "hexToNumber", { + enumerable: !0, + get: function () { + return o.default; + }, + }), + Object.defineProperty(t, "hexToString", { + enumerable: !0, + get: function () { + return a.default; + }, + }), + Object.defineProperty(t, "hexToU8a", { + enumerable: !0, + get: function () { + return Q.default; + }, + }); + var g = i(A("./addPrefix")), + r = i(A("./fixLength")), + n = i(A("./hasPrefix")), + B = i(A("./stripPrefix")), + I = i(A("./toBn")), + o = i(A("./toNumber")), + a = i(A("./toString")), + Q = i(A("./toU8a")); + }, + { + "./addPrefix": 237, + "./fixLength": 238, + "./hasPrefix": 239, + "./stripPrefix": 241, + "./toBn": 242, + "./toNumber": 243, + "./toString": 244, + "./toU8a": 245, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 241: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + if (!A) return ""; + if ((0, g.default)(A)) return A.substr(2); + if (r.test(A)) return A; + throw new Error(`Invalid hex ${A} passed to hexStripPrefix`); + }); + var g = i(A("./hasPrefix")); + const r = /^[a-fA-F0-9]+$/; + }, + { + "./hasPrefix": 239, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 242: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = { isLe: !1, isNegative: !1 }) { + if (!A) return new r.default(0); + const t = (function (A) { + for (var e = 1; e < arguments.length; e++) { + var t = null != arguments[e] ? arguments[e] : {}; + e % 2 + ? I(Object(t), !0).forEach(function (e) { + (0, g.default)(A, e, t[e]); + }) + : Object.getOwnPropertyDescriptors + ? Object.defineProperties( + A, + Object.getOwnPropertyDescriptors(t) + ) + : I(Object(t)).forEach(function (e) { + Object.defineProperty( + A, + e, + Object.getOwnPropertyDescriptor(t, e) + ); + }); + } + return A; + })( + { isLe: !1, isNegative: !1 }, + (0, n.default)(e) ? { isLe: e } : e + ), + i = (0, B.default)(A), + o = new r.default( + (t.isLe + ? (function (A) { + return (A.match(new RegExp(".{1,2}", "g")) || []) + .reverse() + .join(""); + })(i) + : i) || "00", + 16 + ); + return t.isNegative ? o.fromTwos(4 * i.length) : o; + }); + var g = i(A("@babel/runtime/helpers/defineProperty")), + r = i(A("bn.js")), + n = i(A("../is/boolean")), + B = i(A("./stripPrefix")); + function I(A, e) { + var t = Object.keys(A); + if (Object.getOwnPropertySymbols) { + var i = Object.getOwnPropertySymbols(A); + e && + (i = i.filter(function (e) { + return Object.getOwnPropertyDescriptor(A, e).enumerable; + })), + t.push.apply(t, i); + } + return t; + } + }, + { + "../is/boolean": 249, + "./stripPrefix": 241, + "@babel/runtime/helpers/defineProperty": 199, + "@babel/runtime/helpers/interopRequireDefault": 200, + "bn.js": 316, + }, + ], + 243: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return A ? (0, g.default)(A).toNumber() : NaN; + }); + var g = i(A("./toBn")); + }, + { "./toBn": 242, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 244: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, g.default)((0, r.default)(A)); + }); + var g = i(A("../u8a/toString")), + r = i(A("./toU8a")); + }, + { + "../u8a/toString": 298, + "./toU8a": 245, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 245: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = -1) { + if (!A) return new Uint8Array(); + (0, g.default)( + (0, r.default)(A), + `Expected hex value to convert, found '${A}'` + ); + const t = (0, n.default)(A), + i = t.length / 2, + B = Math.ceil(-1 === e ? i : e / 8), + I = new Uint8Array(B), + o = Math.max(0, B - i); + for (let A = 0; A < B; A++) + I[A + o] = parseInt(t.substr(2 * A, 2), 16); + return I; + }); + var g = i(A("../assert")), + r = i(A("../is/hex")), + n = i(A("./stripPrefix")); + }, + { + "../assert": 210, + "../is/hex": 254, + "./stripPrefix": 241, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 246: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }); + var g = { + assert: !0, + detectPackage: !0, + extractTime: !0, + logger: !0, + promisify: !0, + }; + Object.defineProperty(t, "assert", { + enumerable: !0, + get: function () { + return r.default; + }, + }), + Object.defineProperty(t, "detectPackage", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "extractTime", { + enumerable: !0, + get: function () { + return B.default; + }, + }), + Object.defineProperty(t, "logger", { + enumerable: !0, + get: function () { + return I.default; + }, + }), + Object.defineProperty(t, "promisify", { + enumerable: !0, + get: function () { + return o.default; + }, + }), + A("./polyfill"); + var r = i(A("./assert")), + n = i(A("./detectPackage")), + B = i(A("./extractTime")), + I = i(A("./logger")), + o = i(A("./promisify")), + a = A("./array"); + Object.keys(a).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return a[A]; + }, + })); + }); + var Q = A("./bn"); + Object.keys(Q).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return Q[A]; + }, + })); + }); + var C = A("./buffer"); + Object.keys(C).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return C[A]; + }, + })); + }); + var s = A("./compact"); + Object.keys(s).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return s[A]; + }, + })); + }); + var c = A("./format"); + Object.keys(c).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return c[A]; + }, + })); + }); + var h = A("./hex"); + Object.keys(h).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return h[A]; + }, + })); + }); + var f = A("./is"); + Object.keys(f).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return f[A]; + }, + })); + }); + var E = A("./number"); + Object.keys(E).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return E[A]; + }, + })); + }); + var u = A("./string"); + Object.keys(u).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return u[A]; + }, + })); + }); + var d = A("./u8a"); + Object.keys(d).forEach(function (A) { + "default" !== A && + "__esModule" !== A && + (Object.prototype.hasOwnProperty.call(g, A) || + Object.defineProperty(t, A, { + enumerable: !0, + get: function () { + return d[A]; + }, + })); + }); + }, + { + "./array": 209, + "./assert": 210, + "./bn": 213, + "./buffer": 220, + "./compact": 225, + "./detectPackage": 228, + "./extractTime": 229, + "./format": 235, + "./hex": 240, + "./is": 255, + "./logger": 268, + "./number": 272, + "./polyfill": 276, + "./promisify": 282, + "./string": 284, + "./u8a": 293, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 247: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return "bigint" == typeof A; + }); + }, + {}, + ], + 248: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return g.default.isBN(A); + }); + var g = i(A("bn.js")); + }, + { "@babel/runtime/helpers/interopRequireDefault": 200, "bn.js": 316 }, + ], + 249: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return "boolean" == typeof A; + }); + }, + {}, + ], + 250: [ + function (A, e, t) { + (function (e) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, g.default)(A, e); + }); + var g = i(A("./instanceOf")); + }.call(this, A("buffer").Buffer)); + }, + { + "./instanceOf": 256, + "@babel/runtime/helpers/interopRequireDefault": 200, + buffer: 64, + }, + ], + 251: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e) { + return !!e && (A === e || A.isPrototypeOf(e)); + }); + }, + {}, + ], + 252: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, g.default)(A, Error); + }); + var g = i(A("./instanceOf")); + }, + { + "./instanceOf": 256, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 253: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return "function" == typeof A; + }); + }, + {}, + ], + 254: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = -1, t = !1) { + const i = "0x" === A || ((0, g.default)(A) && r.test(A.toString())); + if (i && -1 !== e) return A.length === 2 + Math.ceil(e / 4); + return i && (t || A.length % 2 == 0); + }); + var g = i(A("./string")); + const r = /^0x[a-fA-F0-9]+$/; + }, + { "./string": 263, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 255: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "isBigInt", { + enumerable: !0, + get: function () { + return g.default; + }, + }), + Object.defineProperty(t, "isBn", { + enumerable: !0, + get: function () { + return r.default; + }, + }), + Object.defineProperty(t, "isBuffer", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "isBoolean", { + enumerable: !0, + get: function () { + return B.default; + }, + }), + Object.defineProperty(t, "isChildClass", { + enumerable: !0, + get: function () { + return I.default; + }, + }), + Object.defineProperty(t, "isError", { + enumerable: !0, + get: function () { + return o.default; + }, + }), + Object.defineProperty(t, "isFunction", { + enumerable: !0, + get: function () { + return a.default; + }, + }), + Object.defineProperty(t, "isHex", { + enumerable: !0, + get: function () { + return Q.default; + }, + }), + Object.defineProperty(t, "isInstanceOf", { + enumerable: !0, + get: function () { + return C.default; + }, + }), + Object.defineProperty(t, "isIp", { + enumerable: !0, + get: function () { + return s.default; + }, + }), + Object.defineProperty(t, "isJsonObject", { + enumerable: !0, + get: function () { + return c.default; + }, + }), + Object.defineProperty(t, "isNull", { + enumerable: !0, + get: function () { + return h.default; + }, + }), + Object.defineProperty(t, "isNumber", { + enumerable: !0, + get: function () { + return f.default; + }, + }), + Object.defineProperty(t, "isObject", { + enumerable: !0, + get: function () { + return E.default; + }, + }), + Object.defineProperty(t, "isObservable", { + enumerable: !0, + get: function () { + return u.default; + }, + }), + Object.defineProperty(t, "isString", { + enumerable: !0, + get: function () { + return d.default; + }, + }), + Object.defineProperty(t, "isTestChain", { + enumerable: !0, + get: function () { + return l.default; + }, + }), + Object.defineProperty(t, "isToBn", { + enumerable: !0, + get: function () { + return w.default; + }, + }), + Object.defineProperty(t, "isU8a", { + enumerable: !0, + get: function () { + return p.default; + }, + }), + Object.defineProperty(t, "isUndefined", { + enumerable: !0, + get: function () { + return D.default; + }, + }); + var g = i(A("./bigInt")), + r = i(A("./bn")), + n = i(A("./buffer")), + B = i(A("./boolean")), + I = i(A("./childClass")), + o = i(A("./error")), + a = i(A("./function")), + Q = i(A("./hex")), + C = i(A("./instanceOf")), + s = i(A("./ip")), + c = i(A("./jsonObject")), + h = i(A("./null")), + f = i(A("./number")), + E = i(A("./object")), + u = i(A("./observable")), + d = i(A("./string")), + l = i(A("./testChain")), + w = i(A("./toBn")), + p = i(A("./u8a")), + D = i(A("./undefined")); + }, + { + "./bigInt": 247, + "./bn": 248, + "./boolean": 249, + "./buffer": 250, + "./childClass": 251, + "./error": 252, + "./function": 253, + "./hex": 254, + "./instanceOf": 256, + "./ip": 257, + "./jsonObject": 258, + "./null": 259, + "./number": 260, + "./object": 261, + "./observable": 262, + "./string": 263, + "./testChain": 264, + "./toBn": 265, + "./u8a": 266, + "./undefined": 267, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 256: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e) { + return A instanceof e; + }); + }, + {}, + ], + 257: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e) { + if ("v4" === e) return g.default.v4({ exact: !0 }).test(A); + if ("v6" === e) return g.default.v6({ exact: !0 }).test(A); + return (0, g.default)({ exact: !0 }).test(A); + }); + var g = i(A("ip-regex")); + }, + { "@babel/runtime/helpers/interopRequireDefault": 200, "ip-regex": 320 }, + ], + 258: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + const e = "string" != typeof A ? JSON.stringify(A) : A; + try { + const A = JSON.parse(e); + return "object" == typeof A && null !== A; + } catch (A) { + return !1; + } + }); + }, + {}, + ], + 259: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return null === A; + }); + }, + {}, + ], + 260: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return "number" == typeof A; + }); + }, + {}, + ], + 261: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return "object" == typeof A; + }); + }, + {}, + ], + 262: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, r.default)(A) && (0, g.default)(A.next); + }); + var g = i(A("./function")), + r = i(A("./object")); + }, + { + "./function": 253, + "./object": 261, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 263: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return "string" == typeof A || A instanceof String; + }); + }, + {}, + ], + 264: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + if (!A) return !1; + return !!i.test(A.toString()); + }); + const i = new RegExp("(Development|Local Testnet)$"); + }, + {}, + ], + 265: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return !!A && (0, g.default)(A.toBn); + }); + var g = i(A("./function")); + }, + { + "./function": 253, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 266: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, g.default)(A, Uint8Array); + }); + var g = i(A("./instanceOf")); + }, + { + "./instanceOf": 256, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 267: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return void 0 === A; + }); + }, + {}, + ], + 268: [ + function (A, e, t) { + (function (e) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.format = c), + (t.default = function (A) { + const t = `${A.toUpperCase()}:`.padStart(16); + let i; + try { + const t = "test" === e.env.NODE_ENV, + g = (e.env.DEBUG || "").split(","); + i = t || !!g.find((e) => A.startsWith(e)); + } catch (A) { + i = !1; + } + return { + debug: i ? (...A) => h("debug", t, A) : f, + error: (...A) => h("error", t, A), + log: (...A) => h("log", t, A), + noop: f, + warn: (...A) => h("warn", t, A), + }; + }); + var g = i(A("chalk")), + r = i(A("./format/formatDate")), + n = i(A("./is/bn")), + B = i(A("./is/buffer")), + I = i(A("./is/function")), + o = i(A("./is/object")), + a = i(A("./is/u8a")), + Q = i(A("./u8a/toHex")); + const C = { debug: "log", error: "error", log: "log", warn: "warn" }, + s = { + debug: g.default.gray, + error: g.default.red, + log: g.default.reset, + warn: g.default.yellow, + }; + function c(A) { + return Array.isArray(A) + ? A.map(c) + : (0, n.default)(A) + ? A.toString() + : (0, B.default)(A) + ? `0x${A.toString("hex")}` + : (0, a.default)(A) + ? (0, Q.default)(A) + : A && (0, o.default)(A) && A.constructor === Object + ? (function (A) { + return Object.keys(A).reduce( + (e, t) => ((e[t] = c(A[t])), e), + {} + ); + })(A) + : A; + } + function h(A, e, t) { + if (1 === t.length && (0, I.default)(t[0])) { + const i = t[0](); + return h(A, e, Array.isArray(i) ? i : [i]); + } + const i = (e) => s[A](e); + console[C[A]](i((0, r.default)(new Date())), i(e), ...t.map(c)); + } + function f() {} + }.call(this, A("_process"))); + }, + { + "./format/formatDate": 231, + "./is/bn": 248, + "./is/buffer": 250, + "./is/function": 253, + "./is/object": 261, + "./is/u8a": 266, + "./u8a/toHex": 297, + "@babel/runtime/helpers/interopRequireDefault": 200, + _process: 154, + chalk: 269, + }, + ], + 269: [ + function (A, e, t) { + "use strict"; + const i = A("ansi-styles"), + { stdout: g, stderr: r } = A("supports-color"), + { stringReplaceAll: n, stringEncaseCRLFWithFirstIndex: B } = + A("./util"), + { isArray: I } = Array, + o = ["ansi", "ansi", "ansi256", "ansi16m"], + a = Object.create(null); + class Q { + constructor(A) { + return C(A); + } + } + const C = (A) => { + const e = {}; + return ( + ((A, e = {}) => { + if ( + e.level && + !(Number.isInteger(e.level) && e.level >= 0 && e.level <= 3) + ) + throw new Error( + "The `level` option should be an integer from 0 to 3" + ); + const t = g ? g.level : 0; + A.level = void 0 === e.level ? t : e.level; + })(e, A), + (e.template = (...A) => l(e.template, ...A)), + Object.setPrototypeOf(e, s.prototype), + Object.setPrototypeOf(e.template, e), + (e.template.constructor = () => { + throw new Error( + "`chalk.constructor()` is deprecated. Use `new chalk.Instance()` instead." + ); + }), + (e.template.Instance = Q), + e.template + ); + }; + function s(A) { + return C(A); + } + for (const [A, e] of Object.entries(i)) + a[A] = { + get() { + const t = E( + this, + f(e.open, e.close, this._styler), + this._isEmpty + ); + return Object.defineProperty(this, A, { value: t }), t; + }, + }; + a.visible = { + get() { + const A = E(this, this._styler, !0); + return Object.defineProperty(this, "visible", { value: A }), A; + }, + }; + const c = [ + "rgb", + "hex", + "keyword", + "hsl", + "hsv", + "hwb", + "ansi", + "ansi256", + ]; + for (const A of c) + a[A] = { + get() { + const { level: e } = this; + return function (...t) { + const g = f( + i.color[o[e]][A](...t), + i.color.close, + this._styler + ); + return E(this, g, this._isEmpty); + }; + }, + }; + for (const A of c) { + a["bg" + A[0].toUpperCase() + A.slice(1)] = { + get() { + const { level: e } = this; + return function (...t) { + const g = f( + i.bgColor[o[e]][A](...t), + i.bgColor.close, + this._styler + ); + return E(this, g, this._isEmpty); + }; + }, + }; + } + const h = Object.defineProperties(() => {}, { + ...a, + level: { + enumerable: !0, + get() { + return this._generator.level; + }, + set(A) { + this._generator.level = A; + }, + }, + }), + f = (A, e, t) => { + let i, g; + return ( + void 0 === t + ? ((i = A), (g = e)) + : ((i = t.openAll + A), (g = e + t.closeAll)), + { open: A, close: e, openAll: i, closeAll: g, parent: t } + ); + }, + E = (A, e, t) => { + const i = (...A) => + I(A[0]) && I(A[0].raw) + ? u(i, l(i, ...A)) + : u(i, 1 === A.length ? "" + A[0] : A.join(" ")); + return ( + Object.setPrototypeOf(i, h), + (i._generator = A), + (i._styler = e), + (i._isEmpty = t), + i + ); + }, + u = (A, e) => { + if (A.level <= 0 || !e) return A._isEmpty ? "" : e; + let t = A._styler; + if (void 0 === t) return e; + const { openAll: i, closeAll: g } = t; + if (-1 !== e.indexOf("")) + for (; void 0 !== t; ) + (e = n(e, t.close, t.open)), (t = t.parent); + const r = e.indexOf("\n"); + return -1 !== r && (e = B(e, g, i, r)), i + e + g; + }; + let d; + const l = (e, ...t) => { + const [i] = t; + if (!I(i) || !I(i.raw)) return t.join(" "); + const g = t.slice(1), + r = [i.raw[0]]; + for (let A = 1; A < i.length; A++) + r.push( + String(g[A - 1]).replace(/[{}\\]/g, "\\$&"), + String(i.raw[A]) + ); + return void 0 === d && (d = A("./templates")), d(e, r.join("")); + }; + Object.defineProperties(s.prototype, a); + const w = s(); + (w.supportsColor = g), + (w.stderr = s({ level: r ? r.level : 0 })), + (w.stderr.supportsColor = r), + (e.exports = w); + }, + { + "./templates": 270, + "./util": 271, + "ansi-styles": 307, + "supports-color": 322, + }, + ], + 270: [ + function (A, e, t) { + "use strict"; + const i = + /(?:\\(u(?:[a-f\d]{4}|\{[a-f\d]{1,6}\})|x[a-f\d]{2}|.))|(?:\{(~)?(\w+(?:\([^)]*\))?(?:\.\w+(?:\([^)]*\))?)*)(?:[ \t]|(?=\r?\n)))|(\})|((?:.|[\r\n\f])+?)/gi, + g = /(?:^|\.)(\w+)(?:\(([^)]*)\))?/g, + r = /^(['"])((?:\\.|(?!\1)[^\\])*)\1$/, + n = /\\(u(?:[a-f\d]{4}|{[a-f\d]{1,6}})|x[a-f\d]{2}|.)|([^\\])/gi, + B = new Map([ + ["n", "\n"], + ["r", "\r"], + ["t", "\t"], + ["b", "\b"], + ["f", "\f"], + ["v", "\v"], + ["0", "\0"], + ["\\", "\\"], + ["e", ""], + ["a", ""], + ]); + function I(A) { + const e = "u" === A[0], + t = "{" === A[1]; + return (e && !t && 5 === A.length) || ("x" === A[0] && 3 === A.length) + ? String.fromCharCode(parseInt(A.slice(1), 16)) + : e && t + ? String.fromCodePoint(parseInt(A.slice(2, -1), 16)) + : B.get(A) || A; + } + function o(A, e) { + const t = [], + i = e.trim().split(/\s*,\s*/g); + let g; + for (const e of i) { + const i = Number(e); + if (Number.isNaN(i)) { + if (!(g = e.match(r))) + throw new Error( + `Invalid Chalk template style argument: ${e} (in style '${A}')` + ); + t.push(g[2].replace(n, (A, e, t) => (e ? I(e) : t))); + } else t.push(i); + } + return t; + } + function a(A, e) { + const t = {}; + for (const A of e) + for (const e of A.styles) t[e[0]] = A.inverse ? null : e.slice(1); + let i = A; + for (const [A, e] of Object.entries(t)) + if (Array.isArray(e)) { + if (!(A in i)) throw new Error(`Unknown Chalk style: ${A}`); + i = e.length > 0 ? i[A](...e) : i[A]; + } + return i; + } + e.exports = (A, e) => { + const t = [], + r = []; + let n = []; + if ( + (e.replace(i, (e, i, B, Q, C, s) => { + if (i) n.push(I(i)); + else if (Q) { + const e = n.join(""); + (n = []), + r.push(0 === t.length ? e : a(A, t)(e)), + t.push({ + inverse: B, + styles: (function (A) { + g.lastIndex = 0; + const e = []; + let t; + for (; null !== (t = g.exec(A)); ) { + const A = t[1]; + if (t[2]) { + const i = o(A, t[2]); + e.push([A].concat(i)); + } else e.push([A]); + } + return e; + })(Q), + }); + } else if (C) { + if (0 === t.length) + throw new Error( + "Found extraneous } in Chalk template literal" + ); + r.push(a(A, t)(n.join(""))), (n = []), t.pop(); + } else n.push(s); + }), + r.push(n.join("")), + t.length > 0) + ) { + const A = `Chalk template literal is missing ${ + t.length + } closing bracket${1 === t.length ? "" : "s"} (\`}\`)`; + throw new Error(A); + } + return r.join(""); + }; + }, + {}, + ], + 271: [ + function (A, e, t) { + "use strict"; + e.exports = { + stringReplaceAll: (A, e, t) => { + let i = A.indexOf(e); + if (-1 === i) return A; + const g = e.length; + let r = 0, + n = ""; + do { + (n += A.substr(r, i - r) + e + t), + (r = i + g), + (i = A.indexOf(e, r)); + } while (-1 !== i); + return (n += A.substr(r)); + }, + stringEncaseCRLFWithFirstIndex: (A, e, t, i) => { + let g = 0, + r = ""; + do { + const n = "\r" === A[i - 1]; + (r += + A.substr(g, (n ? i - 1 : i) - g) + e + (n ? "\r\n" : "\n") + t), + (g = i + 1), + (i = A.indexOf("\n", g)); + } while (-1 !== i); + return (r += A.substr(g)); + }, + }; + }, + {}, + ], + 272: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "numberToHex", { + enumerable: !0, + get: function () { + return g.default; + }, + }), + Object.defineProperty(t, "numberToU8a", { + enumerable: !0, + get: function () { + return r.default; + }, + }); + var g = i(A("./toHex")), + r = i(A("./toU8a")); + }, + { + "./toHex": 273, + "./toU8a": 274, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 273: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = -1) { + if ((0, n.default)(A) || (0, r.default)(A) || isNaN(A)) return "0x"; + return (0, g.default)(A.toString(16), e, !0); + }); + var g = i(A("../hex/fixLength")), + r = i(A("../is/null")), + n = i(A("../is/undefined")); + }, + { + "../hex/fixLength": 238, + "../is/null": 259, + "../is/undefined": 267, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 274: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = -1) { + if (!A || isNaN(A)) return new Uint8Array(); + return (0, g.default)((0, r.default)(A, e)); + }); + var g = i(A("../hex/toU8a")), + r = i(A("./toHex")); + }, + { + "../hex/toU8a": 245, + "./toHex": 273, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 275: [ + function (A, e, t) { + "use strict"; + Array.prototype.fill || + (Array.prototype.fill = function (A, e = 0, t) { + if (!this) throw new TypeError("this is null or not defined"); + const i = Object(this), + g = i.length >>> 0, + r = e >> 0; + let n = r < 0 ? Math.max(g + r, 0) : Math.min(r, g); + const B = void 0 === t ? g : t >> 0, + I = B < 0 ? Math.max(g + B, 0) : Math.min(B, g); + for (; n < I; ) (i[n] = A), n++; + return i; + }), + Uint8Array.prototype.fill || + (Uint8Array.prototype.fill = Array.prototype.fill); + }, + {}, + ], + 276: [ + function (A, e, t) { + "use strict"; + A("./fill"), + A("./padEnd"), + A("./padStart"), + A("./setPrototypeOf"), + A("./textDecoder"), + A("./textEncoder"); + }, + { + "./fill": 275, + "./padEnd": 277, + "./padStart": 278, + "./setPrototypeOf": 279, + "./textDecoder": 280, + "./textEncoder": 281, + }, + ], + 277: [ + function (A, e, t) { + "use strict"; + String.prototype.padEnd || + (String.prototype.padEnd = function (A, e = " ") { + let t = String(this); + for (; t.length < A; ) t += e; + return t; + }); + }, + {}, + ], + 278: [ + function (A, e, t) { + "use strict"; + String.prototype.padStart || + (String.prototype.padStart = function (A, e = " ") { + let t = String(this); + for (; t.length < A; ) t = e + t; + return t; + }); + }, + {}, + ], + 279: [ + function (A, e, t) { + "use strict"; + Object.setPrototypeOf || + (Object.setPrototypeOf = function (A, e) { + return (A.__proto__ = e), A; + }); + }, + {}, + ], + 280: [ + function (A, e, t) { + (function (e) { + "use strict"; + if ("undefined" == typeof TextDecoder) + try { + const { TextDecoder: t } = A("util"); + e.TextDecoder = t; + } catch (A) {} + }.call( + this, + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { util: 196 }, + ], + 281: [ + function (A, e, t) { + (function (e) { + "use strict"; + var t = A("@babel/runtime/helpers/interopRequireDefault"), + i = t(A("@babel/runtime/helpers/classPrivateFieldLooseBase")), + g = t(A("@babel/runtime/helpers/classPrivateFieldLooseKey")); + if ("undefined" == typeof TextEncoder) + try { + var r, n; + const { TextEncoder: t } = A("util"); + e.TextEncoder = + ((r = class { + constructor() { + Object.defineProperty(this, n, { + writable: !0, + value: void 0, + }), + ((0, i.default)(this, n)[n] = new t()); + } + encode(A) { + const e = (0, i.default)(this, n)[n].encode(A); + return Uint8Array.from(e); + } + }), + (n = (0, g.default)("encoder")), + r); + } catch (A) {} + }.call( + this, + "undefined" != typeof global + ? global + : "undefined" != typeof self + ? self + : "undefined" != typeof window + ? window + : {} + )); + }, + { + "@babel/runtime/helpers/classPrivateFieldLooseBase": 197, + "@babel/runtime/helpers/classPrivateFieldLooseKey": 198, + "@babel/runtime/helpers/interopRequireDefault": 200, + util: 196, + }, + ], + 282: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e, ...t) { + return new Promise((i, g) => { + e.apply( + A, + t.concat((A, e) => { + A ? g(A) : i(e); + }) + ); + }); + }); + }, + {}, + ], + 283: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = void 0); + var g = i(A("camelcase")).default; + t.default = g; + }, + { "@babel/runtime/helpers/interopRequireDefault": 200, camelcase: 318 }, + ], + 284: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "stringCamelCase", { + enumerable: !0, + get: function () { + return g.default; + }, + }), + Object.defineProperty(t, "stringLowerFirst", { + enumerable: !0, + get: function () { + return r.default; + }, + }), + Object.defineProperty(t, "stringShorten", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "stringToHex", { + enumerable: !0, + get: function () { + return B.default; + }, + }), + Object.defineProperty(t, "stringToU8a", { + enumerable: !0, + get: function () { + return I.default; + }, + }), + Object.defineProperty(t, "stringUpperFirst", { + enumerable: !0, + get: function () { + return o.default; + }, + }); + var g = i(A("./camelCase")), + r = i(A("./lowerFirst")), + n = i(A("./shorten")), + B = i(A("./toHex")), + I = i(A("./toU8a")), + o = i(A("./upperFirst")); + }, + { + "./camelCase": 283, + "./lowerFirst": 285, + "./shorten": 286, + "./toHex": 287, + "./toU8a": 288, + "./upperFirst": 289, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 285: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return A ? A.charAt(0).toLowerCase() + A.slice(1) : ""; + }); + }, + {}, + ], + 286: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = 6) { + if (A.length <= 2 + 2 * e) return A; + return `${A.substr(0, e)}…${A.slice(-e)}`; + }); + }, + {}, + ], + 287: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (0, g.default)((0, r.default)(A)); + }); + var g = i(A("../u8a/toHex")), + r = i(A("./toU8a")); + }, + { + "../u8a/toHex": 297, + "./toU8a": 288, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 288: [ + function (A, e, t) { + "use strict"; + let i; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return A ? i.encode(A) : new Uint8Array(); + }); + try { + i = new TextEncoder(); + } catch (A) { + i = { + encode: function (A) { + const e = new Uint8Array(A.length); + for (let t = 0; t < A.length; t++) e[t] = A.charCodeAt(t); + return e; + }, + }; + } + }, + {}, + ], + 289: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return A ? A.charAt(0).toUpperCase() + A.slice(1) : ""; + }); + }, + {}, + ], + 290: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (...A) { + let e = 0, + t = 0; + const i = new Array(A.length); + for (let t = 0; t < A.length; t++) + (i[t] = (0, g.default)(A[t])), (e += i[t].length); + const r = new Uint8Array(e); + for (let A = 0; A < i.length; A++) + r.set(i[A], t), (t += i[A].length); + return r; + }); + var g = i(A("./toU8a")); + }, + { "./toU8a": 299, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 291: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e) { + return (function (A, e) { + if (A.length !== e.length) return !1; + for (let t = 0; t < A.length; t++) if (A[t] !== e[t]) return !1; + return !0; + })((0, g.default)(A), (0, g.default)(e)); + }); + var g = i(A("./toU8a")); + }, + { "./toU8a": 299, "@babel/runtime/helpers/interopRequireDefault": 200 }, + ], + 292: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = -1, t = !1) { + const i = Math.ceil(e / 8); + if (-1 === e || A.length === i) return A; + if (A.length > i) return A.subarray(0, i); + const g = new Uint8Array(i); + t ? g.set(A, 0) : g.set(A, i - A.length); + return g; + }); + }, + {}, + ], + 293: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + Object.defineProperty(t, "u8aConcat", { + enumerable: !0, + get: function () { + return g.default; + }, + }), + Object.defineProperty(t, "u8aEq", { + enumerable: !0, + get: function () { + return r.default; + }, + }), + Object.defineProperty(t, "u8aFixLength", { + enumerable: !0, + get: function () { + return n.default; + }, + }), + Object.defineProperty(t, "u8aSorted", { + enumerable: !0, + get: function () { + return B.default; + }, + }), + Object.defineProperty(t, "u8aToBn", { + enumerable: !0, + get: function () { + return I.default; + }, + }), + Object.defineProperty(t, "u8aToBuffer", { + enumerable: !0, + get: function () { + return o.default; + }, + }), + Object.defineProperty(t, "u8aToHex", { + enumerable: !0, + get: function () { + return a.default; + }, + }), + Object.defineProperty(t, "u8aToString", { + enumerable: !0, + get: function () { + return Q.default; + }, + }), + Object.defineProperty(t, "u8aToU8a", { + enumerable: !0, + get: function () { + return C.default; + }, + }); + var g = i(A("./concat")), + r = i(A("./eq")), + n = i(A("./fixLength")), + B = i(A("./sorted")), + I = i(A("./toBn")), + o = i(A("./toBuffer")), + a = i(A("./toHex")), + Q = i(A("./toString")), + C = i(A("./toU8a")); + }, + { + "./concat": 290, + "./eq": 291, + "./fixLength": 292, + "./sorted": 294, + "./toBn": 295, + "./toBuffer": 296, + "./toHex": 297, + "./toString": 298, + "./toU8a": 299, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 294: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return A.sort((A, e) => { + let t = 0; + for (;;) { + if ((0, g.default)(A[t]) && (0, g.default)(e[t])) return 0; + if ((0, g.default)(A[t])) return -1; + if ((0, g.default)(e[t])) return 1; + const i = A[t] - e[t]; + if (0 !== i) return i; + t++; + } + }); + }); + var g = i(A("../is/undefined")); + }, + { + "../is/undefined": 267, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 295: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A, e = { isLe: !0, isNegative: !1 }) { + return (0, g.default)((0, r.default)(A), e); + }); + var g = i(A("../hex/toBn")), + r = i(A("./toHex")); + }, + { + "../hex/toBn": 242, + "./toHex": 297, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 296: [ + function (A, e, t) { + (function (A) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (e) { + return e ? A.from(e) : A.from([]); + }); + }.call(this, A("buffer").Buffer)); + }, + { buffer: 64 }, + ], + 297: [ + function (A, e, t) { + "use strict"; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function A(e, t = -1, g = !0) { + const r = g ? "0x" : ""; + if (!(null === e || void 0 === e ? void 0 : e.length)) return r; + const n = Math.ceil(t / 8); + if (n > 0 && e.length > n) { + const t = Math.ceil(n / 2); + return `${A(e.subarray(0, t), -1, g)}…${A( + e.subarray(e.length - t), + -1, + !1 + )}`; + } + const B = new Array(e.length); + for (let A = 0; A < e.length; A++) B[A] = i[e[A]]; + return r + B.join(""); + }); + const i = new Array(256); + for (let A = 0; A < 256; ++A) i[A] = A.toString(16).padStart(2, "0"); + }, + {}, + ], + 298: [ + function (A, e, t) { + "use strict"; + let i; + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + return (null === A || void 0 === A ? void 0 : A.length) + ? i.decode(A) + : ""; + }); + try { + i = new TextDecoder("utf-8"); + } catch (A) { + i = { + decode: function (A) { + return A.reduce((A, e) => A + String.fromCharCode(e), ""); + }, + }; + } + }, + {}, + ], + 299: [ + function (A, e, t) { + "use strict"; + var i = A("@babel/runtime/helpers/interopRequireDefault"); + Object.defineProperty(t, "__esModule", { value: !0 }), + (t.default = function (A) { + if (!A) return new Uint8Array(); + if ((0, g.default)(A)) return (0, B.default)(A); + if ((0, n.default)(A)) + return (0, r.default)(A) ? (0, I.default)(A) : (0, o.default)(A); + return Array.isArray(A) ? Uint8Array.from(A) : A; + }); + var g = i(A("../is/buffer")), + r = i(A("../is/hex")), + n = i(A("../is/string")), + B = i(A("../buffer/toU8a")), + I = i(A("../hex/toU8a")), + o = i(A("../string/toU8a")); + }, + { + "../buffer/toU8a": 221, + "../hex/toU8a": 245, + "../is/buffer": 250, + "../is/hex": 254, + "../is/string": 263, + "../string/toU8a": 288, + "@babel/runtime/helpers/interopRequireDefault": 200, + }, + ], + 300: [ + function (A, e, t) { + const { assert: i } = A("@polkadot/util"); + e.exports = function (A) { + const e = + (e) => + (...t) => + i(A.isReady(), "@polkadot/wasm-crypto has not been initialized"), + e(...t); + return { + bip39Generate: e(A.ext_bip39_generate), + bip39ToEntropy: e(A.ext_bip39_to_entropy), + bip39ToMiniSecret: e(A.ext_bip39_to_mini_secret), + bip39ToSeed: e(A.ext_bip39_to_seed), + bip39Validate: e(A.ext_bip39_validate), + ed25519KeypairFromSeed: e(A.ext_ed_from_seed), + ed25519Sign: e(A.ext_ed_sign), + ed25519Verify: e(A.ext_ed_verify), + sr25519DeriveKeypairHard: e(A.ext_sr_derive_keypair_hard), + sr25519DeriveKeypairSoft: e(A.ext_sr_derive_keypair_soft), + sr25519DerivePublicSoft: e(A.ext_sr_derive_public_soft), + sr25519KeypairFromSeed: e(A.ext_sr_from_seed), + sr25519Sign: e(A.ext_sr_sign), + sr25519Verify: e(A.ext_sr_verify), + blake2b: e(A.ext_blake2b), + keccak256: e(A.ext_keccak256), + pbkdf2: e(A.ext_pbkdf2), + sha512: e(A.ext_sha512), + twox: e(A.ext_twox), + isReady: A.isReady, + waitReady: A.waitReady, + }; + }; + }, + { "@polkadot/util": 246 }, + ], + 301: [ + function (A, e, t) { + const i = A("./wasm"); + e.exports = A("./exports")(i); + }, + { "./exports": 300, "./wasm": 303 }, + ], + 302: [ + function (A, e, t) { + e.exports = { + name: "@polkadot/wasm-crypto", + version: "1.2.1", + author: "Jaco Greeff ", + files: [ + "crypto-polyfill.js", + "exports.js", + "index.d.ts", + "index.js", + "wasm.d.ts", + "wasm.js", + "wasm_asm.js", + "wasm_asm_stub.js", + "wasm_promise.js", + "wasm_wasm.js", + ], + "react-native": { "./wasm_asm_stub.js": "./wasm_asm.js" }, + main: "index.js", + types: "index.d.ts", + devDependencies: { "@polkadot/dev": "^0.50.8" }, + peerDependencies: { "@polkadot/util": "*" }, + }; + }, + {}, + ], + 303: [ + function (A, e, t) { + let i; + const g = { crypto: A("crypto") }; + let r = null; + function n() { + return ( + (null !== r && r.buffer === i.memory.buffer) || + (r = new Uint8Array(i.memory.buffer)), + r + ); + } + let B = 0; + function I(A) { + const e = i.__wbindgen_malloc(1 * A.length); + return n().set(A, e / 1), (B = A.length), e; + } + function o(A, e) { + return n().subarray(A / 1, A / 1 + e); + } + let a = null; + function Q() { + return null === a && (a = i.__wbindgen_global_argument_ptr()), a; + } + let C = null; + function s() { + return ( + (null !== C && C.buffer === i.memory.buffer) || + (C = new Uint32Array(i.memory.buffer)), + C + ); + } + (e.exports.ext_sr_derive_keypair_hard = function (A, e) { + const t = I(A), + g = B, + r = I(e), + n = B, + a = Q(); + try { + i.ext_sr_derive_keypair_hard(a, t, g, r, n); + const A = s(), + e = A[a / 4], + B = A[a / 4 + 1], + I = o(e, B).slice(); + return i.__wbindgen_free(e, 1 * B), I; + } finally { + i.__wbindgen_free(t, 1 * g), i.__wbindgen_free(r, 1 * n); + } + }), + (e.exports.ext_sr_derive_keypair_soft = function (A, e) { + const t = I(A), + g = B, + r = I(e), + n = B, + a = Q(); + try { + i.ext_sr_derive_keypair_soft(a, t, g, r, n); + const A = s(), + e = A[a / 4], + B = A[a / 4 + 1], + I = o(e, B).slice(); + return i.__wbindgen_free(e, 1 * B), I; + } finally { + i.__wbindgen_free(t, 1 * g), i.__wbindgen_free(r, 1 * n); + } + }), + (e.exports.ext_sr_derive_public_soft = function (A, e) { + const t = I(A), + g = B, + r = I(e), + n = B, + a = Q(); + try { + i.ext_sr_derive_public_soft(a, t, g, r, n); + const A = s(), + e = A[a / 4], + B = A[a / 4 + 1], + I = o(e, B).slice(); + return i.__wbindgen_free(e, 1 * B), I; + } finally { + i.__wbindgen_free(t, 1 * g), i.__wbindgen_free(r, 1 * n); + } + }), + (e.exports.ext_sr_from_seed = function (A) { + const e = I(A), + t = B, + g = Q(); + try { + i.ext_sr_from_seed(g, e, t); + const A = s(), + r = A[g / 4], + n = A[g / 4 + 1], + B = o(r, n).slice(); + return i.__wbindgen_free(r, 1 * n), B; + } finally { + i.__wbindgen_free(e, 1 * t); + } + }), + (e.exports.ext_sr_sign = function (A, e, t) { + const g = I(A), + r = B, + n = I(e), + a = B, + C = I(t), + c = B, + h = Q(); + try { + i.ext_sr_sign(h, g, r, n, a, C, c); + const A = s(), + e = A[h / 4], + t = A[h / 4 + 1], + B = o(e, t).slice(); + return i.__wbindgen_free(e, 1 * t), B; + } finally { + i.__wbindgen_free(g, 1 * r), + i.__wbindgen_free(n, 1 * a), + i.__wbindgen_free(C, 1 * c); + } + }), + (e.exports.ext_sr_verify = function (A, e, t) { + const g = I(A), + r = B, + n = I(e), + o = B, + a = I(t), + Q = B; + try { + return 0 !== i.ext_sr_verify(g, r, n, o, a, Q); + } finally { + i.__wbindgen_free(g, 1 * r), + i.__wbindgen_free(n, 1 * o), + i.__wbindgen_free(a, 1 * Q); + } + }), + (e.exports.ext_blake2b = function (A, e, t) { + const g = I(A), + r = B, + n = I(e), + a = B, + C = Q(); + try { + i.ext_blake2b(C, g, r, n, a, t); + const A = s(), + e = A[C / 4], + B = A[C / 4 + 1], + I = o(e, B).slice(); + return i.__wbindgen_free(e, 1 * B), I; + } finally { + i.__wbindgen_free(g, 1 * r), i.__wbindgen_free(n, 1 * a); + } + }), + (e.exports.ext_keccak256 = function (A) { + const e = I(A), + t = B, + g = Q(); + try { + i.ext_keccak256(g, e, t); + const A = s(), + r = A[g / 4], + n = A[g / 4 + 1], + B = o(r, n).slice(); + return i.__wbindgen_free(r, 1 * n), B; + } finally { + i.__wbindgen_free(e, 1 * t); + } + }), + (e.exports.ext_pbkdf2 = function (A, e, t) { + const g = I(A), + r = B, + n = I(e), + a = B, + C = Q(); + try { + i.ext_pbkdf2(C, g, r, n, a, t); + const A = s(), + e = A[C / 4], + B = A[C / 4 + 1], + I = o(e, B).slice(); + return i.__wbindgen_free(e, 1 * B), I; + } finally { + i.__wbindgen_free(g, 1 * r), i.__wbindgen_free(n, 1 * a); + } + }), + (e.exports.ext_sha512 = function (A) { + const e = I(A), + t = B, + g = Q(); + try { + i.ext_sha512(g, e, t); + const A = s(), + r = A[g / 4], + n = A[g / 4 + 1], + B = o(r, n).slice(); + return i.__wbindgen_free(r, 1 * n), B; + } finally { + i.__wbindgen_free(e, 1 * t); + } + }), + (e.exports.ext_twox = function (A, e) { + const t = I(A), + g = B, + r = Q(); + try { + i.ext_twox(r, t, g, e); + const A = s(), + n = A[r / 4], + B = A[r / 4 + 1], + I = o(n, B).slice(); + return i.__wbindgen_free(n, 1 * B), I; + } finally { + i.__wbindgen_free(t, 1 * g); + } + }); + const { u8aToString: c } = A("@polkadot/util"); + function h(A, e) { + return c(n().subarray(A, A + e)); + } + e.exports.ext_bip39_generate = function (A) { + const e = Q(); + i.ext_bip39_generate(e, A); + const t = s(), + g = t[e / 4], + r = t[e / 4 + 1], + n = h(g, r).slice(); + return i.__wbindgen_free(g, 1 * r), n; + }; + const { stringToU8a: f } = A("@polkadot/util"); + let E; + (E = + "function" == typeof stringToU8aInto + ? function (A) { + let e = A.length, + t = i.__wbindgen_malloc(e), + g = 0; + for (;;) { + const r = n().subarray(t + g, t + e), + { read: B, written: I } = stringToU8aInto(A, r); + if (((g += I), 0 === (A = A.substring(B)).length)) break; + (t = i.__wbindgen_realloc(t, e, 2 * e)), (e *= 2); + } + return (B = g), t; + } + : function (A) { + const e = f(A), + t = i.__wbindgen_malloc(e.length); + return n().set(e, t), (B = e.length), t; + }), + (e.exports.ext_bip39_to_entropy = function (A) { + const e = E(A), + t = B, + g = Q(); + try { + i.ext_bip39_to_entropy(g, e, t); + const A = s(), + r = A[g / 4], + n = A[g / 4 + 1], + B = o(r, n).slice(); + return i.__wbindgen_free(r, 1 * n), B; + } finally { + i.__wbindgen_free(e, 1 * t); + } + }), + (e.exports.ext_bip39_to_mini_secret = function (A, e) { + const t = E(A), + g = B, + r = E(e), + n = B, + I = Q(); + try { + i.ext_bip39_to_mini_secret(I, t, g, r, n); + const A = s(), + e = A[I / 4], + B = A[I / 4 + 1], + a = o(e, B).slice(); + return i.__wbindgen_free(e, 1 * B), a; + } finally { + i.__wbindgen_free(t, 1 * g), i.__wbindgen_free(r, 1 * n); + } + }), + (e.exports.ext_bip39_to_seed = function (A, e) { + const t = E(A), + g = B, + r = E(e), + n = B, + I = Q(); + try { + i.ext_bip39_to_seed(I, t, g, r, n); + const A = s(), + e = A[I / 4], + B = A[I / 4 + 1], + a = o(e, B).slice(); + return i.__wbindgen_free(e, 1 * B), a; + } finally { + i.__wbindgen_free(t, 1 * g), i.__wbindgen_free(r, 1 * n); + } + }), + (e.exports.ext_bip39_validate = function (A) { + const e = E(A), + t = B; + try { + return 0 !== i.ext_bip39_validate(e, t); + } finally { + i.__wbindgen_free(e, 1 * t); + } + }), + (e.exports.ext_ed_from_seed = function (A) { + const e = I(A), + t = B, + g = Q(); + try { + i.ext_ed_from_seed(g, e, t); + const A = s(), + r = A[g / 4], + n = A[g / 4 + 1], + B = o(r, n).slice(); + return i.__wbindgen_free(r, 1 * n), B; + } finally { + i.__wbindgen_free(e, 1 * t); + } + }), + (e.exports.ext_ed_sign = function (A, e, t) { + const g = I(A), + r = B, + n = I(e), + a = B, + C = I(t), + c = B, + h = Q(); + try { + i.ext_ed_sign(h, g, r, n, a, C, c); + const A = s(), + e = A[h / 4], + t = A[h / 4 + 1], + B = o(e, t).slice(); + return i.__wbindgen_free(e, 1 * t), B; + } finally { + i.__wbindgen_free(g, 1 * r), + i.__wbindgen_free(n, 1 * a), + i.__wbindgen_free(C, 1 * c); + } + }), + (e.exports.ext_ed_verify = function (A, e, t) { + const g = I(A), + r = B, + n = I(e), + o = B, + a = I(t), + Q = B; + try { + return 0 !== i.ext_ed_verify(g, r, n, o, a, Q); + } finally { + i.__wbindgen_free(g, 1 * r), + i.__wbindgen_free(n, 1 * o), + i.__wbindgen_free(a, 1 * Q); + } + }); + const u = new Array(32); + u.fill(void 0), u.push(void 0, null, !0, !1); + let d = u.length; + function l(A) { + d === u.length && u.push(u.length + 1); + const e = d; + return (d = u[e]), (u[e] = A), e; + } + function w(A) { + return u[A]; + } + (e.exports.__wbg_new_3a746f2619705add = function (A, e) { + let t = h(A, e); + return l(new Function(t)); + }), + (e.exports.__wbg_call_f54d3a6dadb199ca = function (A, e) { + return l(w(A).call(w(e))); + }), + (e.exports.__wbg_self_ac379e780a0d8b94 = function (A) { + return l(w(A).self); + }), + (e.exports.__wbg_crypto_1e4302b85d4f64a2 = function (A) { + return l(w(A).crypto); + }), + (e.exports.__wbg_getRandomValues_1b4ba144162a5c9e = function (A) { + return l(w(A).getRandomValues); + }), + (e.exports.__wbg_getRandomValues_1ef11e888e5228e9 = function ( + A, + e, + t + ) { + let i = o(e, t); + w(A).getRandomValues(i); + }), + (e.exports.__wbg_require_6461b1e9a0d7c34a = function (A, e) { + let t = h(A, e); + return l(g[t]); + }), + (e.exports.__wbg_randomFillSync_1b52c8482374c55b = function ( + A, + e, + t + ) { + let i = o(e, t); + w(A).randomFillSync(i); + }), + (e.exports.__wbindgen_is_undefined = function (A) { + return void 0 === w(A) ? 1 : 0; + }), + (e.exports.__wbindgen_jsval_eq = function (A, e) { + return w(A) === w(e) ? 1 : 0; + }), + (e.exports.__wbindgen_object_drop_ref = function (A) { + var e; + (e = A) < 36 || ((u[e] = d), (d = e)); + }), + (e.exports.abort = function () { + throw new Error("abort"); + }); + const p = A("./wasm_promise")().catch(() => null); + (e.exports.isReady = function () { + return !!i; + }), + (e.exports.waitReady = function () { + return p.then(() => !!i); + }), + p.then((A) => { + i = A; + }); + }, + { "./wasm_promise": 305, "@polkadot/util": 246, crypto: 73 }, + ], + 304: [ + function (A, e, t) { + e.exports = {}; + }, + {}, + ], + 305: [ + function (A, e, t) { + const i = A("./package.json"), + g = A("./wasm_asm_stub"), + r = A("./wasm_wasm"), + n = A("./wasm"); + e.exports = async function () { + try { + const { instance: A } = await WebAssembly.instantiate(r, { + "./wasm": n, + }); + return A.exports; + } catch (A) { + return g && g.ext_blake2b + ? g + : (console.error( + `ERROR: Unable to initialize ${i.name} ${i.version}` + ), + console.error(A), + null); + } + }; + }, + { + "./package.json": 302, + "./wasm": 303, + "./wasm_asm_stub": 304, + "./wasm_wasm": 306, + }, + ], + 306: [ + function (A, e, t) { + (function (A) { + e.exports = A.from( + "AGFzbQEAAAABywEdYAJ/fwBgA39/fwBgAn9/AX9gAX8AYAN/f38Bf2AEf39/fwBgAX8Bf2AFf39/f38AYAABf2AHf39/f39/fwBgAX8BfmAGf39/f39/AGAEf39/fwF/YAAAYAZ/f39/f38Bf2AFf39/f38Bf2ACf34AYAJ/fwF+YAF+AX5gCH9/f39/f39/AGADf39+AGAFf35/fn8AYAN/fn4AYAh/fn5+fn5+fgBgCn9+fn5+fn5+fn4AYAJ/fgF/YAN/fn8Bf2ACfn8Bf2ACfn4BfgKvAwsGLi93YXNtGl9fd2JpbmRnZW5fb2JqZWN0X2Ryb3BfcmVmAAMGLi93YXNtF19fd2JpbmRnZW5faXNfdW5kZWZpbmVkAAYGLi93YXNtE19fd2JpbmRnZW5fanN2YWxfZXEAAgYuL3dhc20aX193YmdfbmV3XzNhNzQ2ZjI2MTk3MDVhZGQAAgYuL3dhc20bX193YmdfY2FsbF9mNTRkM2E2ZGFkYjE5OWNhAAIGLi93YXNtG19fd2JnX3NlbGZfYWMzNzllNzgwYTBkOGI5NAAGBi4vd2FzbR1fX3diZ19jcnlwdG9fMWU0MzAyYjg1ZDRmNjRhMgAGBi4vd2FzbSZfX3diZ19nZXRSYW5kb21WYWx1ZXNfMWI0YmExNDQxNjJhNWM5ZQAGBi4vd2FzbR5fX3diZ19yZXF1aXJlXzY0NjFiMWU5YTBkN2MzNGEAAgYuL3dhc20mX193YmdfZ2V0UmFuZG9tVmFsdWVzXzFlZjExZTg4OGU1MjI4ZTkAAQYuL3dhc20lX193YmdfcmFuZG9tRmlsbFN5bmNfMWI1MmM4NDgyMzc0YzU1YgABA/UF8wUQAAEBAAAAAQEAAAEBAgEHCwAOAQcHAAMOAQABAwQFAQEOAAQBBwMGBAAPAwkFBQUFAAEDAAsCAAABDQQAAAMJBAkAAAICCg8FCQMDAQMBAQABAQEHAAEAAAIFAAEBAQcGAAMABQAAAgEIBQEbAgEFAAAFAQAGAwIBAQAAAAIABRoBAQEABgABAQMCAAMCAQEIBQIFAwEBAQABAAAFAAABAAEFBQUFBQUFAAMBAAcAAwQHBQIEBQAABAgAAgAAAQIHAAAEAAUBAAABBAITAAMDAAMCAQEREQUHBwYDAQEFAQMDBQEAAgIJAwECAgYBAQMBAQIFAwYFAwAAGQAHAQAAAwUCAAEABwEAAAIABQIHAAADAxYDAwIDAgEFAwMHFAAAAwEQBQgGAQMDAAAHCQkAABgAAAsLAQEDBgMDAQEHBwcHBwAAAgADBQAABgYDAwUBAQEBAQEPAAEBAAACAgABAQAAAAwCAAABAQICAgcAAwwCAAcAAAAAAAABDQACAQAVAgABAAgDAgECBgAAAwAAAAEAAQABAAADAAIBAAMFBQEDAwEAAAMDBgQLAAUMAAsAAQAAAAEAAQQABgECAwMDBwYBAQsDDQcHBwEAAggAAQAABAIDAwAAAAAABQUDAwADAQAACAACBAwBAQECAQABAAEAAwMDBQYHAwEGAAEGAAAFBQMIBQICAAUGFwMDAwIIBQUFAAEAAQwBCgIBAAAAAAEBAAEAAAAAAQMAAAABAQIBAAYFAAQGAAEABQYICAADAAAAAAMAAwAAAAYCAAYCAQQDAAAAAAICBQICAAMAAAAGAgIDAQMGAwMDAwAAAAAAAQADEhIDABwDCAICBAIJAQMDAwICAgMCDAUGAwMAAwAODgUCBgIDAwIDAQAAAAABAgIBAgICAAYGBgEDAwAAAAEGAAwDAg0CBAIAAgABAgICAQICAAEGAwMCAgACAgICAgACBAIGAAAACAgIAwIDDQMDAw0CBgIGCgoICgoKCgIDAAQHAXABwgHCAQUDAQATBgkBfwFBgIDAAAsH6AMYBm1lbW9yeQIAHl9fd2JpbmRnZW5fZ2xvYmFsX2FyZ3VtZW50X3B0cgD2BRpleHRfc3JfZGVyaXZlX2tleXBhaXJfaGFyZADJAhpleHRfc3JfZGVyaXZlX2tleXBhaXJfc29mdADKAhlleHRfc3JfZGVyaXZlX3B1YmxpY19zb2Z0AMsCEGV4dF9zcl9mcm9tX3NlZWQA3AILZXh0X3NyX3NpZ24AuAINZXh0X3NyX3ZlcmlmeQCcBQtleHRfYmxha2UyYgC/Ag1leHRfa2VjY2FrMjU2AN0CCmV4dF9wYmtkZjIAwAIKZXh0X3NoYTUxMgDeAghleHRfdHdveADTAhJleHRfYmlwMzlfZ2VuZXJhdGUA7AIUZXh0X2JpcDM5X3RvX2VudHJvcHkA3wIYZXh0X2JpcDM5X3RvX21pbmlfc2VjcmV0AMwCEWV4dF9iaXAzOV90b19zZWVkAM0CEmV4dF9iaXAzOV92YWxpZGF0ZQDgBRBleHRfZWRfZnJvbV9zZWVkAOACC2V4dF9lZF9zaWduALkCDWV4dF9lZF92ZXJpZnkAnQURX193YmluZGdlbl9tYWxsb2MAggQSX193YmluZGdlbl9yZWFsbG9jANwED19fd2JpbmRnZW5fZnJlZQCZBQmDAwEAQQELwQH8BXj8BeED/AXiA60F+gHWAfwF4wP8BdcD/AXkA/wFpQLyBfMF/AX8BYEC8AXxBfwFxwX8BcUF/AXKBfwFkgTnApEElQKSBJIE/AWWA/cE/AX0BZIE/AXKBfwFkgT8BcsF/AWoBeMF8QX1BWS+AfwFlgHOBPwFkwLNBLEDNs4FzwX8BfwFkgT8BZcD+gT8BfQFwwX8BfIE8gT8BdMF0wX8BasFqwXsBeUFmAHtBeYF7gXVBe4F1QXcAecF/AWaBJIE/AWaA/sE/AX0Ba0FkAX8BdYF/AX8BdgF/AWPBdAD4wX3BfEF0AXXBaEC2QWRBe4F2gWSBPwFmwP9BPwF9AX8BdEC1ATSBNsFhQXpBaYE6AX6Ar8BwwPfBfwF/AXGAZIE/QX8BcMBQfUCkQT4BYcF9gSUA4YF3wPcBfUE4wX6BfEFmwWvBbAF3QSFAagB+QWkA4IF9AXwAvwFwwHBBfYCiQWxBaMCUPsFoQX8BfgFRpUB/ALEBd4F9wKYAgr46grzBZouAgZ/Kn4gAEGQAWoiAiAAKQM4IiMgACkDMCIkIABBuAFqIgMpAwAiKyAAQZgBaiIEKQMAIi98fCIffCAfQvnC+JuRo7Pw2wCFQiCJIh9C8e30+KWn/aelf3wiJSArhUIoiSIcfCImIB+FQjCJIg0gJXwiGyAchUIBiSIdIAApA2AiHyAAKQMoIiUgACkDICIcIABBsAFqIgUpAwAiLCACKQMAIip8fCIofCABICiFQuv6htq/tfbBH4VCIIkiJ0Kr8NP0r+68tzx8IiAgLIVCKIkiHnwiCnx8IiEgACkDaCIBfCAdICEgACkDGCIoIAApAxAiKSAAQagBaiICKQMAIi0gAEGIAWoiBikDACIwfHwiInwgIkKf2PnZwpHagpt/hUIgiSIiQrvOqqbY0Ouzu398Ig4gLYVCKIkiCHwiDyAihUIwiSIJhUIgiSITIAApAwgiISAAKQMAIiIgAEGgAWoiBykDACIuIAApA4ABIjF8fCIMfCAAKQPAASAMhULRhZrv+s+Uh9EAhUIgiSIMQoiS853/zPmE6gB8IgsgLoVCKIkiEXwiFCAMhUIwiSIMIAt8Igt8IhWFQiiJIhB8IhIgACkDSCIdfCAeIAogJ4VCMIkiCiAgfCIWhUIBiSIeIAApA1AiJyAPfHwiDyAAKQNYIiB8IB4gGyAMIA+FQiCJIg98IhuFQiiJIh58IgwgD4VCMIkiDyAbfCIXIB6FQgGJIhh8IhkgACkDeCIbfCAYIBkgGyALIBGFQgGJIgsgJiAAKQNwIh58fCImfCAKICaFQiCJIiYgCSAOfCIKfCIOIAuFQiiJIgl8IgsgJoVCMIkiEYVCIIkiGSAIIAqFQgGJIgogACkDQCImIBR8fCIIIB18IAogCCANhUIgiSINIBZ8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIWhUIoiSIYfCIaICB8IBIgE4VCMIkiEyAVfCIVIBCFQgGJIhAgASALfHwiCyAkfCALIA2FQiCJIg0gF3wiCyAQhUIoiSIQfCISIA2FQjCJIg0gC3wiCyAQhUIBiSIQfCIXICN8IBAgFyAIIAqFQgGJIgogDCAcfHwiCCAmfCAKIAggE4VCIIkiCCAOIBF8Ig58IhOFQiiJIgp8IgwgCIVCMIkiCIVCIIkiESAJIA6FQgGJIg4gFCAefHwiCSAnfCAOIAkgD4VCIIkiDyAVfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiFYVCKIkiEHwiFyAlfCAYIBYgGSAahUIwiSIZfCIWhUIBiSIYIAwgInx8IgwgKXwgDCAPhUIgiSIPIAt8IgwgGIVCKIkiC3wiGCAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiApfCALIBogCSAOhUIBiSIOIBIgJXx8IgkgKHwgDiAJIBmFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhkgCCAKhUIBiSIKIBQgIXx8IgggH3wgCiAIIA2FQiCJIg0gFnwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhaFQiiJIgt8IhogI3wgECARIBeFQjCJIhEgFXwiFYVCAYkiECASIBt8fCISIAF8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhcgIXwgECAXIAggCoVCAYkiCiAYIB98fCIIICJ8IAogCCARhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIXIAkgDoVCAYkiDiAUICB8fCIJICZ8IA4gCSAPhUIgiSIPIBV8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIVhUIoiSIQfCIYIAF8IAsgFiAZIBqFQjCJIhZ8IhmFQgGJIgsgESAofHwiESAkfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaIB98IAsgGiAJIA6FQgGJIg4gEiAdfHwiCSAcfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAnfHwiCCAefCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAcfCAQIBUgFyAYhUIwiSIVfCIXhUIBiSIQIBIgIHx8IhIgHnwgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCAifCAQIBggCCAKhUIBiSIKIBEgKHx8IgggIXwgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgI3x8IgkgHXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggKXwgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARICV8fCIRICd8IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogHHwgCyAaIAkgDoVCAYkiDiASIBt8fCIJICZ8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUICl8fCIIICR8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaICR8IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAnfHwiEiAbfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYICZ8IBAgGCAIIAqFQgGJIgogESAlfHwiCCAjfCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gFCAdfHwiCSAifCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAifCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgIHx8IhEgH3wgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAgfCALIBogCSAOhUIBiSIOIBIgKHx8IgkgAXwgDiAJIBaFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhYgCCAKhUIBiSIKIBQgHnx8IgggIXwgCiAIIA2FQiCJIg0gGXwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhmFQiiJIgt8IhogG3wgECAVIBiFQjCJIhUgF3wiF4VCAYkiECASICZ8fCISICh8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhggHnwgECAYIAggCoVCAYkiCiARICR8fCIIICd8IAogCCAVhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIVIAkgDoVCAYkiDiAUICl8fCIJIB98IA4gCSAPhUIgiSIPIBd8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIXhUIoiSIQfCIYIB58IAsgFiAahUIwiSIWIBl8IhmFQgGJIgsgESAjfHwiESAlfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaIAF8IAsgGiAJIA6FQgGJIg4gEiAhfHwiCSAdfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAcfHwiCCABfCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAdfCAQIBUgGIVCMIkiFSAXfCIXhUIBiSIQIBIgHHx8IhIgJ3wgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCApfCAQIBggCCAKhUIBiSIKIBEgIXx8IgggG3wgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgH3x8IgkgJXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggH3wgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARICR8fCIRICh8IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogIXwgCyAaIAkgDoVCAYkiDiASICZ8fCIJICB8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUICJ8fCIIICN8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaICZ8IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAofHwiEiAdfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYICR8IBAgGCAIIAqFQgGJIgogESAjfHwiCCAefCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gASAUfHwiCSAgfCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAgfCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgG3x8IhEgHHwgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAofCALIBogCSAOhUIBiSIOIBIgKXx8IgkgJ3wgDiAJIBaFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhYgCCAKhUIBiSIKIBQgJXx8IgggInwgCiAIIA2FQiCJIg0gGXwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhmFQiiJIgt8IhogIXwgECAVIBiFQjCJIhUgF3wiF4VCAYkiECASICJ8fCISICZ8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhggHHwgECAYIAggCoVCAYkiCiARIB58fCIIIB18IAogCCAVhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIVIAkgDoVCAYkiDiAUICR8fCIJIBt8IA4gCSAPhUIgiSIPIBd8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIXhUIoiSIQfCIYICN8IAsgFiAahUIwiSIWIBl8IhmFQgGJIgsgASARfHwiESAjfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaICR8IAsgGiAJIA6FQgGJIg4gEiAnfHwiCSAlfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAffHwiCCApfCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAofCAQIBUgGIVCMIkiFSAXfCIXhUIBiSIQIBIgIXx8IhIgJXwgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCAffCAQIBggCCAKhUIBiSIKIBEgJnx8IgggHHwgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgJ3x8IgkgKXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggHHwgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARIB18fCIRIB58IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogJXwgCyAaIAkgDoVCAYkiDiABIBJ8fCIJICJ8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUIBt8fCIIICB8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaIB98IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAkfHwiEiAjfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYIAF8IBAgGCAIIAqFQgGJIgogESApfHwiCCAofCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gFCAifHwiCSAhfCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAdfCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgJ3x8IhEgIHwgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAbfCALIBogGyAJIA6FQgGJIg4gEiAefHwiCXwgDiAJIBaFQiCJIhsgCCATfCIIfCIJhUIoiSIOfCITIBuFQjCJIhuFQiCJIhIgHSAIIAqFQgGJIgogFCAmfHwiCHwgCiAIIA2FQiCJIh0gGXwiDYVCKIkiCnwiCCAdhUIwiSIdIA18Ig18IhSFQiiJIgt8IhYgIHwgJCAQIBUgGIVCMIkiICAXfCIVhUIBiSIQIAEgE3x8IgF8IAEgHYVCIIkiASAMfCIkIBCFQiiJIh18IhMgAYVCMIkiASAkfCIkIB2FQgGJIh18IgwgI3wgHSAMIAogDYVCAYkiIyARIBx8fCIcICZ8ICMgHCAghUIgiSIcIAkgG3wiIHwiG4VCKIkiI3wiJiAchUIwiSIchUIgiSINICcgDiAghUIBiSIgIAggHnx8Ih58ICAgDyAehUIgiSInIBV8Ih6FQiiJIiB8IgogJ4VCMIkiJyAefCIefCIOhUIoiSIdfCIIICqFIB8gIyAbIBx8IhyFQgGJIiMgCiAhfHwiIXwgIyABICGFQiCJIgEgEiAWhUIwiSIfIBR8IiF8IhuFQiiJIiN8IiogAYVCMIkiASAbfCIbhTcDACAEICkgCyAhhUIBiSIhICIgJnx8IiJ8ICEgJCAiICeFQiCJIil8IiSFQiiJIiF8IiIgKYVCMIkiKSAkfCIkIC8gKCAeICCFQgGJIicgEyAlfHwiJXwgHCAfICWFQiCJIh98IiUgJ4VCKIkiHHwiKIWFNwMAIAYgJSAfICiFQjCJIh98IiUgIiAwhYU3AwAgACAIIA2FQjCJIiggDnwiIiAqIDGFhTcDgAEgAiAoIC2FIBsgI4VCAYmFNwMAIAMgASArhSAdICKFQgGJhTcDACAFIB8gLIUgISAkhUIBiYU3AwAgByApIC6FIBwgJYVCAYmFNwMAC6g+Ah5/AX4jAEGQAWsiBSQAIAUgAUHAABDyAyEBQQAhBQNAIAVBwABHBEAgASAFaiIGIAYoAgAiBkEYdCAGQQh0QYCA/AdxciAGQQh2QYD+A3EgBkEYdnJyNgIAIAVBBGohBQwBCwsgACgCACEFIAAoAgQhBiAAKAIQIQsgACgCFCEMIAApAgghICABKAIMIRIgASgCCCETIAEoAgQhFCABKAIAIQ0gASAAKQIYNwNoIAEgIDcDYCABIAw2AnwgASALNgJ4IAEgBjYCdCABIAU2AnAgASANQZjfqJQEaiIPNgKMASABIBRBkYndiQdqIhA2AogBIAEgE0HP94Oue2oiETYChAEgASASQaW3181+aiIYNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIRUgASgCVCEWIAEoAlghFyABKAJcIRkgASAMNgJsIAEgCzYCaCABIAY2AmQgASAFNgJgIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIBE2AowBIAEgGDYCiAEgASAPNgKEASABIBA2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhBSABKAJUIQYgASgCWCELIAEoAlwhDCABKAIcIQ8gASgCGCEQIAEoAhQhESABKAIQIRggASAZNgJsIAEgFzYCaCABIBY2AmQgASAVNgJgIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIBhB24TbygNqIhU2AowBIAEgEUHxo8TPBWoiFjYCiAEgASAQQaSF/pF5aiIXNgKEASABIA9B1b3x2HpqIhk2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhGiABKAJUIQIgASgCWCEDIAEoAlwhBCABIAw2AmwgASALNgJoIAEgBjYCZCABIAU2AmAgASAENgJ8IAEgAzYCeCABIAI2AnQgASAaNgJwIAEgFzYCjAEgASAZNgKIASABIBU2AoQBIAEgFjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEFIAEoAlQhBiABKAJYIQsgASgCXCEMIAEoAiwhFSABKAIoIRYgASgCJCEXIAEoAiAhGSABIAQ2AmwgASADNgJoIAEgAjYCZCABIBo2AmAgASAMNgJ8IAEgCzYCeCABIAY2AnQgASAFNgJwIAEgGUGY1Z7AfWoiBzYCjAEgASAXQYG2jZQBaiIINgKIASABIBZBvovGoQJqIgk2AoQBIAEgFUHD+7GoBWoiCjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEaIAEoAlQhAiABKAJYIQMgASgCXCEEIAEgDDYCbCABIAs2AmggASAGNgJkIAEgBTYCYCABIAQ2AnwgASADNgJ4IAEgAjYCdCABIBo2AnAgASAJNgKMASABIAo2AogBIAEgBzYChAEgASAINgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQcgASgCVCEIIAEoAlghCSABKAJcIQogASgCPCEFIAEoAjghBiABKAI0IQsgASgCMCEMIAEgBDYCbCABIAM2AmggASACNgJkIAEgGjYCYCABIAo2AnwgASAJNgJ4IAEgCDYCdCABIAc2AnAgASAMQfS6+ZUHaiIONgKMASABIAtB/uP6hnhqIh02AogBIAEgBkGnjfDeeWoiGzYChAEgASAFQfTi74x8aiIcNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIRogASgCVCECIAEoAlghAyABKAJcIQQgASAKNgJsIAEgCTYCaCABIAg2AmQgASAHNgJgIAEgBDYCfCABIAM2AnggASACNgJ0IAEgGjYCcCABIBs2AowBIAEgHDYCiAEgASAONgKEASABIB02AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhByABKAJUIQggASgCWCEJIAEoAlwhCiABIA02AnwgASAUNgJ4IAEgEzYCdCABIBI2AnAgASAYNgKMASABIBE2AogBIAEgEDYChAEgASAPNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIBcgASgCbGo2AlwgASAWIAEoAmhqNgJYIAEgFSABKAJkajYCVCABIAwgASgCYGo2AlAgASAMNgKMASABIAs2AogBIAEgBjYChAEgASAFNgKAASABQUBrIAFB0ABqIAFBgAFqEPQBIAEgBDYCbCABIAM2AmggASACNgJkIAEgGjYCYCABIAo2AnwgASAJNgJ4IAEgCDYCdCABIAc2AnAgASABKAJMIhpBwdPtpH5qIgI2AowBIAEgASgCSEGGj/n9fmoiAzYCiAEgASABKAJEQca7hv4AaiIENgKEASABIAEoAkBBzMOyoAJqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhEiABKAJUIRMgASgCWCEUIAEoAlwhDSABIAo2AmwgASAJNgJoIAEgCDYCZCABIAc2AmAgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIAEgBDYCjAEgASAONgKIASABIAI2AoQBIAEgAzYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGDYCfCABIBE2AnggASAQNgJ0IAEgDzYCcCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgCyABKAJsajYCXCABIAYgASgCaGo2AlggASAFIAEoAmRqNgJUIAEgGiABKAJgajYCUCABQYgBaiIaIAEpA0g3AwAgASABKQNANwOAASABQfAAaiABQdAAaiABQYABahD0ASABKAJwIQ8gASgCdCEQIAEoAnghESABKAJ8IRggASANNgJsIAEgFDYCaCABIBM2AmQgASASNgJgIAEgBzYCfCABIAQ2AnggASADNgJ0IAEgAjYCcCABIBhB79ik7wJqIgg2AowBIAEgEUGqidLTBGoiCTYCiAEgASAQQdzTwuUFaiIKNgKEASABIA9B2pHmtwdqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhEiABKAJUIRMgASgCWCEUIAEoAlwhDSABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIAEgCjYCjAEgASAONgKIASABIAg2AoQBIAEgCTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgASgCbCABKAJIajYCXCABIAEoAmggASgCRGo2AlggASABKAJkIAEoAkBqNgJUIAEgGCABKAJgajYCUCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhFSABKAJ0IRYgASgCeCEXIAEoAnwhGSABIA02AmwgASAUNgJoIAEgEzYCZCABIBI2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgGUHSovnBeWoiCDYCjAEgASAXQe2Mx8F6aiIJNgKIASABIBZByM+MgHtqIgo2AoQBIAEgFUHH/+X6e2oiDjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCESIAEoAlQhEyABKAJYIRQgASgCXCENIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA02AnwgASAUNgJ4IAEgEzYCdCABIBI2AnAgASAKNgKMASABIA42AogBIAEgCDYChAEgASAJNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASAMNgJ8IAEgCzYCeCABIAY2AnQgASAFNgJwIBogASkDSDcDACABIAEpA0A3A4ABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgESABKAJsajYCXCABIBAgASgCaGo2AlggASAPIAEoAmRqNgJUIAEgGSABKAJgajYCUCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhBSABKAJ0IQYgASgCeCELIAEoAnwhDCABIA02AmwgASAUNgJoIAEgEzYCZCABIBI2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDEHzl4C3fGoiEjYCjAEgASALQceinq19aiITNgKIASABIAZB0capNmoiFDYChAEgASAFQefSpKEBaiINNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQggASgCVCEJIAEoAlghCiABKAJcIQ4gASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgDjYCfCABIAo2AnggASAJNgJ0IAEgCDYCcCABIBQ2AowBIAEgDTYCiAEgASASNgKEASABIBM2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhAiABKAJUIQMgASgCWCEEIAEoAlwhByABQfgAaiIdIAEpA0g3AwAgASABKQNANwNwIAEgGDYCjAEgASARNgKIASABIBA2AoQBIAEgDzYCgAEgAUHgAGogAUHwAGogAUGAAWoQ/AEgASAXIAEoAmxqNgJcIAEgFiABKAJoajYCWCABIBUgASgCZGo2AlQgASAMIAEoAmBqNgJQIAEgDDYCjAEgASALNgKIASABIAY2AoQBIAEgBTYCgAEgAUHwAGogAUHQAGogAUGAAWoQ9AEgASgCcCESIAEoAnQhEyABKAJ4IRQgASgCfCENIAEgDjYCbCABIAo2AmggASAJNgJkIAEgCDYCYCABIAc2AnwgASAENgJ4IAEgAzYCdCABIAI2AnAgASANQYWV3L0CaiIbNgKMASABIBRBuMLs8AJqIhw2AogBIAEgE0H827HpBGoiHjYChAEgASASQZOa4JkFaiIfNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQggASgCVCEJIAEoAlghCiABKAJcIQ4gASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgDjYCfCABIAo2AnggASAJNgJ0IAEgCDYCcCABIB42AowBIAEgHzYCiAEgASAbNgKEASABIBw2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhAiABKAJUIQMgASgCWCEEIAEoAlwhByABIBg2AnwgASARNgJ4IAEgEDYCdCABIA82AnAgASAZNgKMASABIBc2AogBIAEgFjYChAEgASAVNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIAsgASgCbGo2AlwgASAGIAEoAmhqNgJYIAEgBSABKAJkajYCVCABIA0gASgCYGo2AlAgASANNgKMASABIBQ2AogBIAEgEzYChAEgASASNgKAASABQUBrIAFB0ABqIAFBgAFqEPQBIAEgDjYCbCABIAo2AmggASAJNgJkIAEgCDYCYCABIAc2AnwgASAENgJ4IAEgAzYCdCABIAI2AnAgASABKAJMIg9B1OapqAZqIhA2AowBIAEgASgCSCIbQbuVqLMHaiIRNgKIASABIAEoAkQiHEGukouOeGoiGDYChAEgASABKAJAIh5BhdnIk3lqIh82AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhCCABKAJUIQkgASgCWCEKIAEoAlwhDiABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASAONgJ8IAEgCjYCeCABIAk2AnQgASAINgJwIAEgGDYCjAEgASAfNgKIASABIBA2AoQBIAEgETYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgFCABKAJsajYCXCABIBMgASgCaGo2AlggASASIAEoAmRqNgJUIAEgDyABKAJgajYCUCAaIAEpA0g3AwAgASABKQNANwOAASABQfAAaiABQdAAaiABQYABahD0ASABKAJwIQ8gASgCdCEQIAEoAnghESABKAJ8IRggASAONgJsIAEgCjYCaCABIAk2AmQgASAINgJgIAEgBzYCfCABIAQ2AnggASADNgJ0IAEgAjYCcCABIBhBodH/lXpqIgg2AowBIAEgEUHLzOnAemoiCTYCiAEgASAQQfCWrpJ8aiIKNgKEASABIA9Bo6Oxu3xqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhFSABKAJUIRYgASgCWCEXIAEoAlwhGSABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASAZNgJ8IAEgFzYCeCABIBY2AnQgASAVNgJwIAEgCjYCjAEgASAONgKIASABIAg2AoQBIAEgCTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIA02AowBIAEgFDYCiAEgASATNgKEASABIBI2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgGyABKAJsajYCXCABIBwgASgCaGo2AlggASAeIAEoAmRqNgJUIAEgGCABKAJgajYCUCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhBSABKAJ0IQYgASgCeCELIAEoAnwhDCABIBk2AmwgASAXNgJoIAEgFjYCZCABIBU2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDEGZ0MuMfWoiFTYCjAEgASALQaSM5LR9aiIWNgKIASABIAZBheu4oH9qIhc2AoQBIAEgBUHwwKqDAWoiGTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAXNgKMASABIBk2AogBIAEgFTYChAEgASAWNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIBogASkDSDcDACABIAEpA0A3A4ABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgESABKAJsajYCXCABIBAgASgCaGo2AlggASAPIAEoAmRqNgJUIAEgDCABKAJgajYCUCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhFSABKAJ0IRYgASgCeCEXIAEoAnwhGSABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgGUGWgpPNAWoiEjYCjAEgASAXQYjY3fEBaiITNgKIASABIBZBzO6hugJqIhQ2AoQBIAEgFUG1+cKlA2oiDTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAUNgKMASABIA02AogBIAEgEjYChAEgASATNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgHSABKQNINwMAIAEgASkDQDcDcCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgCyABKAJsajYCXCABIAYgASgCaGo2AlggASAFIAEoAmRqNgJUIAEgGSABKAJgajYCUCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhEiABKAJ0IRMgASgCeCEUIAEoAnwhDSABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDUGzmfDIA2oiHTYCjAEgASAUQcrU4vYEaiIbNgKIASABIBNBz5Tz3AVqIhw2AoQBIAEgEkHz37nBBmoiHjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAcNgKMASABIB42AogBIAEgHTYChAEgASAbNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASAYNgJ8IAEgETYCeCABIBA2AnQgASAPNgJwIAEgDDYCjAEgASALNgKIASABIAY2AoQBIAEgBTYCgAEgAUHgAGogAUHwAGogAUGAAWoQ/AEgASAXIAEoAmxqNgJcIAEgFiABKAJoajYCWCABIBUgASgCZGo2AlQgASANIAEoAmBqNgJQIAEgDTYCjAEgASAUNgKIASABIBM2AoQBIAEgEjYCgAEgAUFAayABQdAAaiABQYABahD0ASABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgASgCTCIIQe6FvqQHaiINNgKMASABIAEoAkhB78aVxQdqIgk2AogBIAEgASgCREGU8KGmeGoiCjYChAEgASABKAJAQYiEnOZ4aiIONgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQ8gASgCVCEQIAEoAlghESABKAJcIRggASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgGDYCfCABIBE2AnggASAQNgJ0IAEgDzYCcCABIAo2AowBIAEgDjYCiAEgASANNgKEASABIAk2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhDSABKAJUIQIgASgCWCEDIAEoAlwhBCABIAw2AnwgASALNgJ4IAEgBjYCdCABIAU2AnAgASAZNgKMASABIBc2AogBIAEgFjYChAEgASAVNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIBQgASgCbGo2AlwgASATIAEoAmhqNgJYIAEgEiABKAJkajYCVCABIAggASgCYGo2AlAgGiABKQNINwMAIAEgASkDQDcDgAEgAUHwAGogAUHQAGogAUGAAWoQ9AEgASgCcCEFIAEoAnQhBiABKAJ4IQsgASgCfCEMIAEgGDYCbCABIBE2AmggASAQNgJkIAEgDzYCYCABIAQ2AnwgASADNgJ4IAEgAjYCdCABIA02AnAgASAMQfr/+4V5aiIPNgKMASABIAtB69nBonpqIhA2AogBIAEgBkH3x+b3e2oiETYChAEgASAFQfLxxbN8aiIYNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQUgASgCVCEGIAEoAlghCyABKAJcIQwgASAENgJsIAEgAzYCaCABIAI2AmQgASANNgJgIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIBE2AowBIAEgGDYCiAEgASAPNgKEASABIBA2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlwhDyABKAJYIRAgASgCVCERIAAgACgCACABKAJQajYCACAAIBEgACgCBGo2AgQgACAFIAAoAghqNgIIIAAgBiAAKAIMajYCDCAAIBAgACgCEGo2AhAgACAPIAAoAhRqNgIUIAAgCyAAKAIYajYCGCAAIAwgACgCHGo2AhwgAUGQAWokAAvWIgIBfx5+IwBB0AprIgMkACADQfAGaiACKQMAIgUgASkDACIEEJ4CIANB4AZqIAMpA/AGIgxCm/zRkrG0xwJ+Qv////////8HgyIJQu2n1+el45gBEJ4CIANBgAdqIAIpAwgiBiAEEJ4CIANBwAdqIAEpAwgiByAFEJ4CIANB0AZqIAlCgcu1zvfF+gYQngIgA0HABmogAykDwAciECADKQOAB3wiESADKQPQBnwiDiAMIAMpA+AGIgh8IgxCNIggDCAIVK0gA0HoBmopAwAgA0H4BmopAwB8fCIUQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GACGogByAGEJ4CIANBkAdqIAIpAxAiCCAEEJ4CIANB0AdqIAEpAxAiDSAFEJ4CIANBkAZqIAlC+b3TABCeAiADQbAGaiAMQoHLtc73xfoGEJ4CIANBgAZqIAMpA5AHIhcgAykDgAh8IhIgAykD0Ad8IgogAykDkAZ8Ig8gAykDsAZ8IhMgAykDwAYiFSALfCIWQjSIIBYgFVStIANByAZqKQMAIAsgDlStIA4gEVStIANB2AZqKQMAIBEgEFStIANByAdqKQMAIANBiAdqKQMAfHx8fCAUQjSIfHx8fCIYQgyGhHwiEEKb/NGSsbTHAn5C/////////weDIhFC7afX56XjmAEQngIgA0HACGogCCAHEJ4CIANBkAhqIA0gBhCeAiADQaAHaiACKQMYIg4gBBCeAiADQeAHaiABKQMYIgsgBRCeAiADQaAGaiAMQvm90wAQngIgA0HwBWogEUKBy7XO98X6BhCeAiADQeAFaiADKQOQCCIeIAMpA8AIfCIUIAMpA6AHfCIVIAMpA+AHfCIWIAMpA6AGfCIZIAMpA/AFfCIaIAMpA4AGIhsgEHwiHEI0iCAcIBtUrSADQYgGaikDACAQIBNUrSATIA9UrSADQbgGaikDACAPIApUrSADQZgGaikDACAKIBJUrSADQdgHaikDACASIBdUrSADQZgHaikDACADQYgIaikDAHx8fHx8fHx8IBhCNIh8fHx8Ih9CDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiEkLtp9fnpeOYARCeAiADQfAIaiANIAgQngIgA0HQCGogDiAHEJ4CIANBoAhqIAsgBhCeAiADQbAHaiACKQMgIgogBBCeAiADQfAHaiABKQMgIgQgBRCeAiADQbAFaiARQvm90wAQngIgA0HQBWogEkKBy7XO98X6BhCeAiADQaAFaiADKQPQCCIgIAMpA/AIfCITIAlCLIZ8IhAgAykDoAh8IhcgAykDsAd8IhggAykD8Ad8IhsgAykDsAV8IhwgAykD0AV8Ih0gAykD4AUiBSAPfCIhQjSIICEgBVStIANB6AVqKQMAIA8gGlStIBogGVStIANB+AVqKQMAIBkgFlStIANBqAZqKQMAIBYgFVStIANB6AdqKQMAIBUgFFStIANBqAdqKQMAIBQgHlStIANBmAhqKQMAIANByAhqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIUQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GgCWogDiANEJ4CIANBgAlqIAsgCBCeAiADQeAIaiAKIAcQngIgA0GwCGogBCAGEJ4CIANBwAVqIBJC+b3TABCeAiADQZAFaiAFQoHLtc73xfoGEJ4CIANBwAlqIAsgDhCeAiADQbAJaiAKIA0QngIgA0GQCWogBCAIEJ4CIANBgAVqIAVC+b3TABCeAiADQeAJaiAKIAsQngIgA0HQCWogBCAOEJ4CIANB8AlqIAQgChCeAiADIAMpA4AJIhUgAykDoAl8IgQgAykD4Ah8IgYgAykDsAh8IgcgDEIshnwiCCADKQPABXwiDSADKQOQBXwiDiADKQOgBSILIA98IgpCNIggCiALVK0gA0GoBWopAwAgDyAdVK0gHSAcVK0gA0HYBWopAwAgHCAbVK0gA0G4BWopAwAgGyAYVK0gA0H4B2opAwAgGCAXVK0gA0G4B2opAwAgFyAQVK0gA0GoCGopAwAgECATVK0gEyAgVK0gA0HYCGopAwAgA0H4CGopAwB8fCAJQhSIfHx8fHx8fHx8fHx8IBRCNIh8fHx8IhBCDIaEfCIJQv////////8HgzcDqAogAyADKQOwCSIUIAMpA8AJfCILIAMpA5AJfCIKIBFCLIZ8Ig8gAykDgAV8IhMgCSAOVK0gDiANVK0gA0GYBWopAwAgDSAIVK0gA0HIBWopAwAgCCAHVK0gByAGVK0gA0G4CGopAwAgBiAEVK0gA0HoCGopAwAgBCAVVK0gA0GICWopAwAgA0GoCWopAwB8fHx8fHwgDEIUiHx8fHx8fCAQQjSIfHwiB0IMhiAJQjSIhHwiBEL/////////B4M3A7AKIAMgAykD0AkiDCADKQPgCXwiCSASQiyGfCIGIAQgE1StIBMgD1StIANBiAVqKQMAIA8gClStIAogC1StIANBmAlqKQMAIAsgFFStIANBuAlqKQMAIANByAlqKQMAfHx8fCARQhSIfHx8fCAHQjSIfHwiCEIMhiAEQjSIhHwiBEL/////////B4M3A7gKIAMgBUIshiINIAMpA/AJfCIHIAQgBlStIAYgCVStIAkgDFStIANB2AlqKQMAIANB6AlqKQMAfHwgEkIUiHx8IAhCNIh8fCIJQgyGIARCNIiEfCIEQv////////8HgzcDwAogAyAEIAdUrSAHIA1UrSADQfgJaikDACAFQhSIfHwgCUI0iHx8QgyGIARCNIiENwPICiADQYAKaiADQagKakGAvMQAEKABIANBsAJqIAMpA4AKIgVCu6LLyt7M9AQQngIgA0HgAWogAykDsAIiBkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgA0GgAmogBUKfzfqt8fjYBhCeAiADQYADaiADKQOICiIJQruiy8rezPQEEJ4CIANB0AFqIARCgcu1zvfF+gYQngIgA0GwAWogAykDgAMiCiADKQOgAnwiDCADKQPQAXwiCCAGIAMpA+ABIgd8IgZCNIggBiAHVK0gA0HoAWopAwAgA0G4AmopAwB8fCIPQgyGhHwiDUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GQAmogBUKE7KHb3MzvAhCeAiADQfACaiAJQp/N+q3x+NgGEJ4CIANB0ANqIAMpA5AKIgdCu6LLyt7M9AQQngIgA0HAAWogBEL5vdMAEJ4CIANBoAFqIAZCgcu1zvfF+gYQngIgA0GAAWogAykD8AIiFSADKQOQAnwiESADKQPQA3wiDiADKQPAAXwiCyADKQOgAXwiEiADKQOwASITIA18IhBCNIggECATVK0gA0G4AWopAwAgDSAIVK0gCCAMVK0gA0HYAWopAwAgDCAKVK0gA0GIA2opAwAgA0GoAmopAwB8fHx8IA9CNIh8fHx8IhZCDIaEfCINQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYACaiAFQv/C9LnsnfcBEJ4CIANB4AJqIAlChOyh29zM7wIQngIgA0HAA2ogB0Kfzfqt8fjYBhCeAiADQaAEaiADKQOYCiIIQruiy8rezPQEEJ4CIANBkAFqIAZC+b3TABCeAiADQfAAaiAMQoHLtc73xfoGEJ4CIANB0ABqIAMpA+ACIhcgAykDgAJ8IgogAykDwAN8Ig8gAykDoAR8IhMgAykDkAF8IhAgAykDcHwiFCADKQOAASIZIA18IhpCNIggGiAZVK0gA0GIAWopAwAgDSASVK0gEiALVK0gA0GoAWopAwAgCyAOVK0gA0HIAWopAwAgDiARVK0gA0HYA2opAwAgESAVVK0gA0H4AmopAwAgA0GYAmopAwB8fHx8fHx8fCAWQjSIfHx8fCIYQgyGhHwiEUKb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0HwAWogBUKa4fDbkagCEJ4CIANB0AJqIAlC/8L0ueyd9wEQngIgA0GwA2ogB0KE7KHb3MzvAhCeAiADQZAEaiAIQp/N+q3x+NgGEJ4CIANB8ARqIAMpA6AKIgVCu6LLyt7M9AQQngIgA0HgAGogDEL5vdMAEJ4CIANBQGsgDUKBy7XO98X6BhCeAiADQSBqIAMpA9ACIhsgAykD8AF8Ig4gAykDsAN8IgsgAykDkAR8IhIgAykD8AR8IhUgBEIshnwiFiADKQNgfCIZIAMpA0B8IhogAykDUCIcIBF8Ih1CNIggHSAcVK0gA0HYAGopAwAgESAUVK0gFCAQVK0gA0H4AGopAwAgECATVK0gA0GYAWopAwAgEyAPVK0gA0GoBGopAwAgDyAKVK0gA0HIA2opAwAgCiAXVK0gA0HoAmopAwAgA0GIAmopAwB8fHx8fHx8fHx8IBhCNIh8fHx8IhBCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiEULtp9fnpeOYARCeAiADQcACaiAJQprh8NuRqAIQngIgA0GgA2ogB0L/wvS57J33ARCeAiADQYAEaiAIQoTsodvczO8CEJ4CIANB4ARqIAVCn836rfH42AYQngIgA0EwaiANQvm90wAQngIgA0EQaiARQoHLtc73xfoGEJ4CIANBkANqIAdCmuHw25GoAhCeAiADQfADaiAIQv/C9LnsnfcBEJ4CIANB0ARqIAVChOyh29zM7wIQngIgAyARQvm90wAQngIgA0HgA2ogCEKa4fDbkagCEJ4CIANBwARqIAVC/8L0ueyd9wEQngIgA0GwBGogBUKa4fDbkagCEJ4CIAMgAykDoAMiFCADKQPAAnwiBSADKQOABHwiCSADKQPgBHwiByAGQiyGfCIIIAMpAzB8Ig8gAykDEHwiEyADKQMgIhcgCnwiGEI0iCAYIBdUrSADQShqKQMAIAogGlStIBogGVStIANByABqKQMAIBkgFlStIANB6ABqKQMAIBYgFVStIBUgElStIANB+ARqKQMAIBIgC1StIANBmARqKQMAIAsgDlStIANBuANqKQMAIA4gG1StIANB2AJqKQMAIANB+AFqKQMAfHx8fHx8fHwgBEIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBEL/////////B4M3A6gKIAMgAykD8AMiFSADKQOQA3wiDiADKQPQBHwiCyAMQiyGfCISIAMpAwB8IgogBCATVK0gEyAPVK0gA0EYaikDACAPIAhUrSADQThqKQMAIAggB1StIAcgCVStIANB6ARqKQMAIAkgBVStIANBiARqKQMAIAUgFFStIANBqANqKQMAIANByAJqKQMAfHx8fHx8IAZCFIh8fHx8fHwgEEI0iHx8IgZCDIYgBEI0iIR8IgVC/////////weDNwOwCiADIAMpA8AEIgcgAykD4AN8IgQgDUIshnwiCSAFIApUrSAKIBJUrSADQQhqKQMAIBIgC1StIAsgDlStIANB2ARqKQMAIA4gFVStIANB+ANqKQMAIANBmANqKQMAfHx8fCAMQhSIfHx8fCAGQjSIfHwiDEIMhiAFQjSIhHwiBUL/////////B4M3A7gKIAMgEUIshiIIIAMpA7AEfCIGIAUgCVStIAkgBFStIAQgB1StIANByARqKQMAIANB6ANqKQMAfHwgDUIUiHx8IAxCNIh8fCIEQgyGIAVCNIiEfCIFQv////////8HgzcDwAogAyAFIAZUrSAGIAhUrSADQbgEaikDACARQhSIfHwgBEI0iHx8QgyGIAVCNIiENwPICiAAIANBqApqQYC8xAAQoAEgA0HQCmokAAvWIgIBfx5+IwBB0AprIgMkACADQfAGaiACKQMAIgUgASkDACIEEJ4CIANB4AZqIAMpA/AGIgxCm/zRkrG0xwJ+Qv////////8HgyIJQu2n1+el45gBEJ4CIANBgAdqIAIpAwgiBiAEEJ4CIANBwAdqIAEpAwgiByAFEJ4CIANB0AZqIAlCgcu1zvfF+gYQngIgA0HABmogAykDwAciECADKQOAB3wiESADKQPQBnwiDiAMIAMpA+AGIgh8IgxCNIggDCAIVK0gA0HoBmopAwAgA0H4BmopAwB8fCIUQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GACGogByAGEJ4CIANBkAdqIAIpAxAiCCAEEJ4CIANB0AdqIAEpAxAiDSAFEJ4CIANBkAZqIAlC+b3TABCeAiADQbAGaiAMQoHLtc73xfoGEJ4CIANBgAZqIAMpA5AHIhcgAykDgAh8IhIgAykD0Ad8IgogAykDkAZ8Ig8gAykDsAZ8IhMgAykDwAYiFSALfCIWQjSIIBYgFVStIANByAZqKQMAIAsgDlStIA4gEVStIANB2AZqKQMAIBEgEFStIANByAdqKQMAIANBiAdqKQMAfHx8fCAUQjSIfHx8fCIYQgyGhHwiEEKb/NGSsbTHAn5C/////////weDIhFC7afX56XjmAEQngIgA0HACGogCCAHEJ4CIANBkAhqIA0gBhCeAiADQaAHaiACKQMYIg4gBBCeAiADQeAHaiABKQMYIgsgBRCeAiADQaAGaiAMQvm90wAQngIgA0HwBWogEUKBy7XO98X6BhCeAiADQeAFaiADKQOQCCIeIAMpA8AIfCIUIAMpA6AHfCIVIAMpA+AHfCIWIAMpA6AGfCIZIAMpA/AFfCIaIAMpA4AGIhsgEHwiHEI0iCAcIBtUrSADQYgGaikDACAQIBNUrSATIA9UrSADQbgGaikDACAPIApUrSADQZgGaikDACAKIBJUrSADQdgHaikDACASIBdUrSADQZgHaikDACADQYgIaikDAHx8fHx8fHx8IBhCNIh8fHx8Ih9CDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiEkLtp9fnpeOYARCeAiADQfAIaiANIAgQngIgA0HQCGogDiAHEJ4CIANBoAhqIAsgBhCeAiADQbAHaiACKQMgIgogBBCeAiADQfAHaiABKQMgIgQgBRCeAiADQbAFaiARQvm90wAQngIgA0HQBWogEkKBy7XO98X6BhCeAiADQaAFaiADKQPQCCIgIAMpA/AIfCITIAlCLIZ8IhAgAykDoAh8IhcgAykDsAd8IhggAykD8Ad8IhsgAykDsAV8IhwgAykD0AV8Ih0gAykD4AUiBSAPfCIhQjSIICEgBVStIANB6AVqKQMAIA8gGlStIBogGVStIANB+AVqKQMAIBkgFlStIANBqAZqKQMAIBYgFVStIANB6AdqKQMAIBUgFFStIANBqAdqKQMAIBQgHlStIANBmAhqKQMAIANByAhqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIUQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GgCWogDiANEJ4CIANBgAlqIAsgCBCeAiADQeAIaiAKIAcQngIgA0GwCGogBCAGEJ4CIANBwAVqIBJC+b3TABCeAiADQZAFaiAFQoHLtc73xfoGEJ4CIANBwAlqIAsgDhCeAiADQbAJaiAKIA0QngIgA0GQCWogBCAIEJ4CIANBgAVqIAVC+b3TABCeAiADQeAJaiAKIAsQngIgA0HQCWogBCAOEJ4CIANB8AlqIAQgChCeAiADIAMpA4AJIhUgAykDoAl8IgQgAykD4Ah8IgYgAykDsAh8IgcgDEIshnwiCCADKQPABXwiDSADKQOQBXwiDiADKQOgBSILIA98IgpCNIggCiALVK0gA0GoBWopAwAgDyAdVK0gHSAcVK0gA0HYBWopAwAgHCAbVK0gA0G4BWopAwAgGyAYVK0gA0H4B2opAwAgGCAXVK0gA0G4B2opAwAgFyAQVK0gA0GoCGopAwAgECATVK0gEyAgVK0gA0HYCGopAwAgA0H4CGopAwB8fCAJQhSIfHx8fHx8fHx8fHx8IBRCNIh8fHx8IhBCDIaEfCIJQv////////8HgzcDqAogAyADKQOwCSIUIAMpA8AJfCILIAMpA5AJfCIKIBFCLIZ8Ig8gAykDgAV8IhMgCSAOVK0gDiANVK0gA0GYBWopAwAgDSAIVK0gA0HIBWopAwAgCCAHVK0gByAGVK0gA0G4CGopAwAgBiAEVK0gA0HoCGopAwAgBCAVVK0gA0GICWopAwAgA0GoCWopAwB8fHx8fHwgDEIUiHx8fHx8fCAQQjSIfHwiB0IMhiAJQjSIhHwiBEL/////////B4M3A7AKIAMgAykD0AkiDCADKQPgCXwiCSASQiyGfCIGIAQgE1StIBMgD1StIANBiAVqKQMAIA8gClStIAogC1StIANBmAlqKQMAIAsgFFStIANBuAlqKQMAIANByAlqKQMAfHx8fCARQhSIfHx8fCAHQjSIfHwiCEIMhiAEQjSIhHwiBEL/////////B4M3A7gKIAMgBUIshiINIAMpA/AJfCIHIAQgBlStIAYgCVStIAkgDFStIANB2AlqKQMAIANB6AlqKQMAfHwgEkIUiHx8IAhCNIh8fCIJQgyGIARCNIiEfCIEQv////////8HgzcDwAogAyAEIAdUrSAHIA1UrSADQfgJaikDACAFQhSIfHwgCUI0iHx8QgyGIARCNIiENwPICiADQYAKaiADQagKakHY7cgAEKEBIANBsAJqIAMpA4AKIgVCu6LLyt7M9AQQngIgA0HgAWogAykDsAIiBkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgA0GgAmogBUKfzfqt8fjYBhCeAiADQYADaiADKQOICiIJQruiy8rezPQEEJ4CIANB0AFqIARCgcu1zvfF+gYQngIgA0GwAWogAykDgAMiCiADKQOgAnwiDCADKQPQAXwiCCAGIAMpA+ABIgd8IgZCNIggBiAHVK0gA0HoAWopAwAgA0G4AmopAwB8fCIPQgyGhHwiDUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GQAmogBUKE7KHb3MzvAhCeAiADQfACaiAJQp/N+q3x+NgGEJ4CIANB0ANqIAMpA5AKIgdCu6LLyt7M9AQQngIgA0HAAWogBEL5vdMAEJ4CIANBoAFqIAZCgcu1zvfF+gYQngIgA0GAAWogAykD8AIiFSADKQOQAnwiESADKQPQA3wiDiADKQPAAXwiCyADKQOgAXwiEiADKQOwASITIA18IhBCNIggECATVK0gA0G4AWopAwAgDSAIVK0gCCAMVK0gA0HYAWopAwAgDCAKVK0gA0GIA2opAwAgA0GoAmopAwB8fHx8IA9CNIh8fHx8IhZCDIaEfCINQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYACaiAFQv/C9LnsnfcBEJ4CIANB4AJqIAlChOyh29zM7wIQngIgA0HAA2ogB0Kfzfqt8fjYBhCeAiADQaAEaiADKQOYCiIIQruiy8rezPQEEJ4CIANBkAFqIAZC+b3TABCeAiADQfAAaiAMQoHLtc73xfoGEJ4CIANB0ABqIAMpA+ACIhcgAykDgAJ8IgogAykDwAN8Ig8gAykDoAR8IhMgAykDkAF8IhAgAykDcHwiFCADKQOAASIZIA18IhpCNIggGiAZVK0gA0GIAWopAwAgDSASVK0gEiALVK0gA0GoAWopAwAgCyAOVK0gA0HIAWopAwAgDiARVK0gA0HYA2opAwAgESAVVK0gA0H4AmopAwAgA0GYAmopAwB8fHx8fHx8fCAWQjSIfHx8fCIYQgyGhHwiEUKb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0HwAWogBUKa4fDbkagCEJ4CIANB0AJqIAlC/8L0ueyd9wEQngIgA0GwA2ogB0KE7KHb3MzvAhCeAiADQZAEaiAIQp/N+q3x+NgGEJ4CIANB8ARqIAMpA6AKIgVCu6LLyt7M9AQQngIgA0HgAGogDEL5vdMAEJ4CIANBQGsgDUKBy7XO98X6BhCeAiADQSBqIAMpA9ACIhsgAykD8AF8Ig4gAykDsAN8IgsgAykDkAR8IhIgAykD8AR8IhUgBEIshnwiFiADKQNgfCIZIAMpA0B8IhogAykDUCIcIBF8Ih1CNIggHSAcVK0gA0HYAGopAwAgESAUVK0gFCAQVK0gA0H4AGopAwAgECATVK0gA0GYAWopAwAgEyAPVK0gA0GoBGopAwAgDyAKVK0gA0HIA2opAwAgCiAXVK0gA0HoAmopAwAgA0GIAmopAwB8fHx8fHx8fHx8IBhCNIh8fHx8IhBCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiEULtp9fnpeOYARCeAiADQcACaiAJQprh8NuRqAIQngIgA0GgA2ogB0L/wvS57J33ARCeAiADQYAEaiAIQoTsodvczO8CEJ4CIANB4ARqIAVCn836rfH42AYQngIgA0EwaiANQvm90wAQngIgA0EQaiARQoHLtc73xfoGEJ4CIANBkANqIAdCmuHw25GoAhCeAiADQfADaiAIQv/C9LnsnfcBEJ4CIANB0ARqIAVChOyh29zM7wIQngIgAyARQvm90wAQngIgA0HgA2ogCEKa4fDbkagCEJ4CIANBwARqIAVC/8L0ueyd9wEQngIgA0GwBGogBUKa4fDbkagCEJ4CIAMgAykDoAMiFCADKQPAAnwiBSADKQOABHwiCSADKQPgBHwiByAGQiyGfCIIIAMpAzB8Ig8gAykDEHwiEyADKQMgIhcgCnwiGEI0iCAYIBdUrSADQShqKQMAIAogGlStIBogGVStIANByABqKQMAIBkgFlStIANB6ABqKQMAIBYgFVStIBUgElStIANB+ARqKQMAIBIgC1StIANBmARqKQMAIAsgDlStIANBuANqKQMAIA4gG1StIANB2AJqKQMAIANB+AFqKQMAfHx8fHx8fHwgBEIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBEL/////////B4M3A6gKIAMgAykD8AMiFSADKQOQA3wiDiADKQPQBHwiCyAMQiyGfCISIAMpAwB8IgogBCATVK0gEyAPVK0gA0EYaikDACAPIAhUrSADQThqKQMAIAggB1StIAcgCVStIANB6ARqKQMAIAkgBVStIANBiARqKQMAIAUgFFStIANBqANqKQMAIANByAJqKQMAfHx8fHx8IAZCFIh8fHx8fHwgEEI0iHx8IgZCDIYgBEI0iIR8IgVC/////////weDNwOwCiADIAMpA8AEIgcgAykD4AN8IgQgDUIshnwiCSAFIApUrSAKIBJUrSADQQhqKQMAIBIgC1StIAsgDlStIANB2ARqKQMAIA4gFVStIANB+ANqKQMAIANBmANqKQMAfHx8fCAMQhSIfHx8fCAGQjSIfHwiDEIMhiAFQjSIhHwiBUL/////////B4M3A7gKIAMgEUIshiIIIAMpA7AEfCIGIAUgCVStIAkgBFStIAQgB1StIANByARqKQMAIANB6ANqKQMAfHwgDUIUiHx8IAxCNIh8fCIEQgyGIAVCNIiEfCIFQv////////8HgzcDwAogAyAFIAZUrSAGIAhUrSADQbgEaikDACARQhSIfHwgBEI0iHx8QgyGIAVCNIiENwPICiAAIANBqApqQdjtyAAQoQEgA0HQCmokAAucIgEVfyMAQbDAAGsiAiQAIAJBIGogAUEYaikAADcDAEEQIQQgAkEYaiIDIAFBEGopAAA3AwAgAkEQaiIKIAFBCGoiDykAADcDACACIAEpAAA3AwggAkHIAGpBAEHgHxDBBCACQTBqIA8pAAA3AwAgAkFAayAKKQMANwMAIAIgASkAADcDKCACIAIpAwg3AzggAxCpASACQdgAaiADEKkBA0AgBUGACEYEQCACQShqIAJBqAhqQcAAEPIDGkEAIQVBkAIhBANAIAVBwB9GBEACQCACQaggaiACQShqQYAgEPIDGkEAIQUgAkEANgKoQCACQagwaiEBQcAAIRUDQCAVBEAgBUEPcQ0CIAVB/wNxIgNBAWohBCAFQRBqQf8DcSEWIAVB8ANqQf8DcSIKQQRqIQ8gCkEGaiEJIApBDWohBwJ/IAVBgARPBEAgASADQQJ0aiIFIAUoAgAgASAJQQJ0aiIMKAIAQQh3aiABIAdBAnRqIg0oAgBBCncgASAEQQJ0aiIJKAIAIgdBF3dzaiIRNgIAIAJBqCBqIANBgARyIgRBAnRqIAJBqCBqIAEgD0ECdGooAgAiA0EOdkH8B3FBgAhyaigCACACQaggaiADQf8BcUECdGooAgBqIBFzIg82AgAgCSAHIApBAnQgAWoiA0EcaiIOKAIAQQh3aiADQThqIhEoAgBBCncgBUEIaiIJKAIAIgdBF3dzaiIUNgIAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQCAEQQFqIgpBgAhJBEAgAkGoIGogCkECdGogAkGoIGogA0EUaigCACIKQf8BcUECdGooAgAgAkGoIGogCkEOdkH8B3FBgAhyaigCAGogFHMiCjYCACAJIANBIGoiBigCAEEIdyAHaiADQTxqIhQoAgBBCncgBUEMaiIHKAIAIgtBF3dzaiIINgIAIARBAmoiCUH/B0sNASACQaggaiAJQQJ0aiACQaggaiAMKAIAIglB/wFxQQJ0aigCACACQaggaiAJQQ52QfwHcUGACHJqKAIAaiAIcyIJNgIAIAcgCyADQSRqIggoAgBBCHdqIAVBEGoiDCgCACILQRd3IA9BCndzaiISNgIAIARBA2oiB0H/B0sNAiACQaggaiAHQQJ0aiACQaggaiAOKAIAIgdB/wFxQQJ0aigCACACQaggaiAHQQ52QfwHcUGACHJqKAIAaiAScyIHNgIAIAwgCyADQShqIhIoAgBBCHdqIAVBFGoiDigCACILQRd3IApBCndzaiIQNgIAIARBBGoiDEH/B0sNAyACQaggaiAMQQJ0aiACQaggaiAGKAIAIgxB/wFxQQJ0aigCACACQaggaiAMQQ52QfwHcUGACHJqKAIAaiAQcyIMNgIAIA4gA0EsaiIGKAIAQQh3IAtqIAVBGGoiCygCACIQQRd3IAlBCndzaiITNgIAIARBBWoiDkH/B0sNBCACQaggaiAOQQJ0aiACQaggaiAIKAIAIg5B/wFxQQJ0aigCACACQaggaiAOQQ52QfwHcUGACHJqKAIAaiATcyIONgIAIAsgA0EwaiILKAIAQQh3IBBqIAVBHGoiCCgCACIQQRd3IAdBCndzaiITNgIAIARBBmoiA0H/B0sNBSACQaggaiADQQJ0aiACQaggaiASKAIAIgNB/wFxQQJ0aigCACACQaggaiADQQ52QfwHcUGACHJqKAIAaiATcyISNgIAIAggDSgCAEEIdyAQaiAFQSBqIggoAgAiEEEXdyAMQQp3c2oiEzYCACAEQQdqIgNB/wdLDQYgAkGoIGogA0ECdGogAkGoIGogBigCACIDQf8BcUECdGooAgAgAkGoIGogA0EOdkH8B3FBgAhyaigCAGogE3MiBjYCACAIIBEoAgBBCHcgEGogBUEkaiIIKAIAIhBBF3cgDkEKd3NqIhM2AgAgBEEIaiIDQf8HSw0HIAJBqCBqIANBAnRqIAJBqCBqIAsoAgAiA0H/AXFBAnRqKAIAIAJBqCBqIANBDnZB/AdxQYAIcmooAgBqIBNzIgs2AgAgCCAUKAIAQQh3IBBqIAVBKGoiCCgCACIQQRd3IBJBCndzaiISNgIAIARBCWoiA0H/B0sNCCACQaggaiADQQJ0aiACQaggaiANKAIAIgNB/wFxQQJ0aigCACACQaggaiADQQ52QfwHcUGACHJqKAIAaiAScyINNgIAIAggECAPQQh3aiAFQSxqIggoAgAiEkEXdyAGQQp3c2oiBjYCACAEQQpqIgNB/wdLDQkgAkGoIGogA0ECdGogAkGoIGogESgCACIDQf8BcUECdGooAgAgAkGoIGogA0EOdkH8B3FBgAhyaigCAGogBnMiETYCACAIIBIgCkEId2ogBUEwaiIGKAIAIghBF3cgC0EKd3NqIgs2AgAgBEELaiIDQf8HSw0KIAJBqCBqIANBAnRqIAJBqCBqIBQoAgAiA0H/AXFBAnRqKAIAIAJBqCBqIANBDnZB/AdxQYAIcmooAgBqIAtzIhQ2AgAgBiAIIAlBCHdqIAVBNGoiBigCACILQRd3IA1BCndzaiINNgIAIARBDGoiA0H/B0sNCyACQaggaiADQQJ0aiACQaggaiAPQf8BcUECdGooAgAgAkGoIGogD0EOdkH8B3FBgAhyaigCAGogDXMiDzYCACAGIAsgB0EId2ogBUE4aiINKAIAIgZBF3cgEUEKd3NqIhE2AgAgBEENaiIDQf8HSw0MIAJBqCBqIANBAnRqIAJBqCBqIApB/wFxQQJ0aigCACACQaggaiAKQQ52QfwHcUGACHJqKAIAaiARczYCACANIAYgDEEId2ogBUE8aiIDKAIAIgpBF3cgFEEKd3NqIg02AgAgBEEOaiIFQf8HSw0NIAJBqCBqIAVBAnRqIAJBqCBqIAlB/wFxQQJ0aigCACACQaggaiAJQQ52QfwHcUGACHJqKAIAaiANczYCACADIAogDkEId2ogASAWQQJ0aigCAEEXdyAPQQp3c2oiBTYCACAEQQ9qIgRB/wdLDQ4gAkGoIGogB0EOdkH8B3FBgAhyaiEDIAJBqCBqIAdB/wFxQQJ0agwQC0HY/skAIApBgAgQ5AIAC0Ho/skAIAlBgAgQ5AIAC0H4/skAIAdBgAgQ5AIAC0GI/8kAIAxBgAgQ5AIAC0GY/8kAIA5BgAgQ5AIAC0Go/8kAIANBgAgQ5AIAC0G4/8kAIANBgAgQ5AIAC0HI/8kAIANBgAgQ5AIAC0HY/8kAIANBgAgQ5AIAC0Ho/8kAIANBgAgQ5AIAC0H4/8kAIANBgAgQ5AIAC0GIgMoAIANBgAgQ5AIAC0GYgMoAIANBgAgQ5AIAC0GogMoAIAVBgAgQ5AIAC0G4gMoAIARBgAgQ5AIACyACQaggaiADQQJ0aiIFIAUoAgAgAkGoIGogCUECdGoiDigCAEEYd2ogAkGoIGogB0ECdGoiDSgCAEEWdyACQaggaiAEQQJ0aiIJKAIAIgdBCXdzaiIENgIAIAUgBCABIAJBqCBqIA9BAnRqKAIAIg9BDnZB/AdxQYAIcmooAgAgASAPQf8BcUECdGooAgBqcyIPNgIAIAkgByACQaggaiAKQQJ0aiIEQRxqIgYoAgBBGHdqIARBOGoiESgCAEEWdyAFQQhqIgcoAgAiFEEJd3NqIgo2AgAgCSAKIAEgBEEUaigCACIJQQ52QfwHcUGACHJqKAIAIAEgCUH/AXFBAnRqKAIAanMiCjYCACAHIBQgBEEgaiILKAIAQRh3aiAEQTxqIhQoAgBBFncgBUEMaiIMKAIAIghBCXdzaiIJNgIAIAcgCSABIA4oAgAiB0EOdkH8B3FBgAhyaigCACABIAdB/wFxQQJ0aigCAGpzIgk2AgAgDCAIIARBJGoiEigCAEEYd2ogBUEQaiIOKAIAIghBCXcgD0EWd3NqIgc2AgAgDCAHIAEgBigCACIMQQ52QfwHcUGACHJqKAIAIAEgDEH/AXFBAnRqKAIAanMiBzYCACAOIAggBEEoaiIQKAIAQRh3aiAFQRRqIgwoAgAiBkEJdyAKQRZ3c2oiCDYCACAOIAEgCygCACIOQQ52QfwHcUGACHJqKAIAIAEgDkH/AXFBAnRqKAIAaiAIcyIONgIAIAwgBiAEQSxqIgsoAgBBGHdqIAVBGGoiBigCACIIQQl3IAlBFndzaiITNgIAIAwgASASKAIAIgxBDnZB/AdxQYAIcmooAgAgASAMQf8BcUECdGooAgBqIBNzIgw2AgAgBiAIIARBMGoiEigCAEEYd2ogBUEcaiIEKAIAIghBCXcgB0EWd3NqIhM2AgAgBiABIBAoAgAiBkEOdkH8B3FBgAhyaigCACABIAZB/wFxQQJ0aigCAGogE3MiEDYCACAEIAggDSgCAEEYd2ogBUEgaiIGKAIAIghBCXcgDkEWd3NqIhM2AgAgBCABIAsoAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogE3MiCzYCACAGIAggESgCAEEYd2ogBUEkaiIEKAIAIghBCXcgDEEWd3NqIhM2AgAgBiABIBIoAgAiBkEOdkH8B3FBgAhyaigCACABIAZB/wFxQQJ0aigCAGogE3MiEjYCACAEIAggFCgCAEEYd2ogBUEoaiIGKAIAIghBCXcgEEEWd3NqIhA2AgAgBCABIA0oAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogEHMiEDYCACAGIAggD0EYd2ogBUEsaiIEKAIAIg1BCXcgC0EWd3NqIgs2AgAgBiABIBEoAgAiEUEOdkH8B3FBgAhyaigCACABIBFB/wFxQQJ0aigCAGogC3MiETYCACAEIA0gCkEYd2ogBUEwaiINKAIAIgZBCXcgEkEWd3NqIgs2AgAgBCABIBQoAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogC3MiFDYCACANIAYgCUEYd2ogBUE0aiIEKAIAIgZBCXcgEEEWd3NqIgs2AgAgDSABIA9BDnZB/AdxQYAIcmooAgAgASAPQf8BcUECdGooAgBqIAtzIg82AgAgBCAGIAdBGHdqIAVBOGoiBSgCACINQQl3IBFBFndzaiIRNgIAIAQgASAKQQ52QfwHcUGACHJqKAIAIAEgCkH/AXFBAnRqKAIAaiARczYCACAFIA0gDkEYd2ogAkGoIGogA0EPaiIEQQJ0aiIDKAIAIgpBCXcgFEEWd3NqIg02AgAgBSABIAlBDnZB/AdxQYAIcmooAgAgASAJQf8BcUECdGooAgBqIA1zNgIAIAMgCiAMQRh3aiACQaggaiAWQQJ0aigCAEEJdyAPQRZ3c2oiBTYCACABIAdB/wFxQQJ0aiEDIAEgB0EOdkH8B3FBgAhyagshCiACQaggaiAEQQJ0aiAKKAIAIAMoAgBqIAVzNgIAIAIgAigCqEBBEGoiBTYCqEAgFUF/aiEVDAELCyACQQA2AqhAIAAgAkGoIGpBhCAQ8gMaIAJBsMAAaiQADwsFIAJBKGogBWoiAUFAayAEIAEoAgAgAUEkaigCAGogAUE4aigCACIDQQ93IANBDXdzIANBCnZzaiABQQRqKAIAIgFBGXcgAUEOd3MgAUEDdnNqajYCACAEQQFqIQQgBUEEaiEFDAELC0G0/ckAQSxByP7JABDOAwAFIAJBKGogBWoiAUFAayAEIAEoAgAgAUEkaigCAGogAUE4aigCACIDQQ93IANBDXdzIANBCnZzaiABQQRqKAIAIgFBGXcgAUEOd3MgAUEDdnNqajYCACAFQQRqIQUgBEEBaiEEDAELAAsAC5grAgJ/IH4jAEGAD2siAiQAIAJBgA5qIAFBgAEQ8gMaQQAhAQNAIAFBgAFHBEAgAkGADmogAWoiAyADKQMAIhtCOIYgG0IohkKAgICAgIDA/wCDhCAbQhiGQoCAgICA4D+DIBtCCIZCgICAgPAfg4SEIBtCCIhCgICA+A+DIBtCGIhCgID8B4OEIBtCKIhCgP4DgyAbQjiIhISENwMAIAFBCGohAQwBCwsgAkHwDWogACkDACIbIAApAyAiHCAAKQMIIh4gACkDKCIfIAApAxAiICAAKQMwIiEgACkDGCIiIAApAzgiIyACKQOADiISQqLcormN84vFwgB8ELwCIAJB4A1qIAIpA/ANIg8gAikD+A0iECAbIBwgHiAfICAgISACKQOIDiIHQs3LvZ+SktGb8QB8ELwCIAJB0A1qIAIpA+ANIgkgAikD6A0iDCAPIBAgGyAcIB4gHyACKQOQDiIXQq/2tOL++b7gtX98ELwCIAJBwA1qIAIpA9ANIgsgAikD2A0iEyAJIAwgDyAQIBsgHCACKQOYDiIIQry3p4zY9PbaaXwQvAIgAkGwDWogAikDwA0iDSACKQPIDSIRIAsgEyAJIAwgDyAQIAIpA6AOIhhCuOqimr/LsKs5fBC8AiACQaANaiACKQOwDSIPIAIpA7gNIhAgDSARIAsgEyAJIAwgAikDqA4iCkKZoJewm77E+NkAfBC8AiACQZANaiACKQOgDSIJIAIpA6gNIgwgDyAQIA0gESALIBMgAikDsA4iFEKbn+X4ytTgn5J/fBC8AiACQYANaiACKQOQDSILIAIpA5gNIhMgCSAMIA8gECANIBEgAikDuA4iHUKYgrbT3dqXjqt/fBC8AiACQfAMaiACKQOADSINIAIpA4gNIhEgCyATIAkgDCAPIBAgAikDwA4iGkLChIyYitPqg1h8ELwCIAJB4AxqIAIpA/AMIg8gAikD+AwiECANIBEgCyATIAkgDCACKQPIDiIWQr7fwauU4NbBEnwQvAIgAkHQDGogAikD4AwiCSACKQPoDCIMIA8gECANIBEgCyATIAIpA9AOIhNCjOWS9+S34ZgkfBC8AiACQcAMaiACKQPQDCILIAIpA9gMIgQgCSAMIA8gECANIBEgAikD2A4iFULi6f6vvbifhtUAfBC8AiACQbAMaiACKQPADCINIAIpA8gMIhEgCyAEIAkgDCAPIBAgAikD4A4iGULvku6Tz66X3/IAfBC8AiACQaAMaiACKQOwDCIFIAIpA7gMIgYgDSARIAsgBCAJIAwgAikD6A4iDkKxrdrY47+s74B/fBC8AiACQZAMaiACKQOgDCIJIAIpA6gMIgwgBSAGIA0gESALIAQgAikD8A4iD0K1pJyu8tSB7pt/fBC8AiACQYAMaiACKQOQDCILIAIpA5gMIgQgCSAMIAUgBiANIBEgAikD+A4iEUKUzaT7zK78zUF8ELwCIAJB8AtqIAcgEiAXIBMgFiARIA8QlgQgAkHgC2ogCCAXIBggGSAVIAIpA/ALIhcgAikD+AsiEBCWBCACQdALaiACKQOADCINIAIpA4gMIhIgCyAEIAkgDCAFIAYgEELSlcX3mbjazWR8ELwCIAJBwAtqIAIpA9ALIgUgAikD2AsiBiANIBIgCyAEIAkgDCAXQuPLvMLj8JHfb3wQvAIgAkGwC2ogAikDwAsiByACKQPICyIIIAUgBiANIBIgCyAEIAIpA+gLIglCtauz3Oi45+APfBC8AiACQaALaiACKQOwCyILIAIpA7gLIgQgByAIIAUgBiANIBIgAikD4AsiEkLluLK9x7mohiR8ELwCIAJBkAtqIAogGCAUIA8gDiASIAkQlgQgAkGAC2ogHSAUIBogECARIAIpA5ALIhggAikDmAsiDBCWBCACQfAKaiACKQOgCyINIAIpA6gLIhQgCyAEIAcgCCAFIAYgDEL1hKzJ9Y3L9C18ELwCIAJB4ApqIAIpA/AKIgUgAikD+AoiBiANIBQgCyAEIAcgCCAYQoPJm/WmlaG6ygB8ELwCIAJB0ApqIAIpA+AKIgcgAikD6AoiCCAFIAYgDSAUIAsgBCACKQOICyILQtT3h+rLu6rY3AB8ELwCIAJBwApqIAIpA9AKIgQgAikD2AoiCiAHIAggBSAGIA0gFCACKQOACyIUQrWnxZiom+L89gB8ELwCIAJBsApqIBYgGiATIAkgFyAUIAsQlgQgAkGgCmogFSATIBkgDCASIAIpA7AKIhogAikDuAoiExCWBCACQZAKaiACKQPACiIWIAIpA8gKIhUgBCAKIAcgCCAFIAYgE0Krv5vzrqqUn5h/fBC8AiACQYAKaiACKQOQCiIFIAIpA5gKIgYgFiAVIAQgCiAHIAggGkKQ5NDt0s3xmKh/fBC8AiACQfAJaiACKQOACiIHIAIpA4gKIgggBSAGIBYgFSAEIAogAikDqAoiDUK/wuzHifnJgbB/fBC8AiACQeAJaiACKQPwCSIEIAIpA/gJIgogByAIIAUgBiAWIBUgAikDoAoiFkLknbz3+/jfrL9/fBC8AiACQdAJaiAOIBkgDyALIBggFiANEJYEIAJBwAlqIBEgDyAQIBMgFCACKQPQCSIZIAIpA9gJIg8QlgQgAkGwCWogAikD4AkiFSACKQPoCSIOIAQgCiAHIAggBSAGIA9Cwp+i7bP+gvBGfBC8AiACQaAJaiACKQOwCSIFIAIpA7gJIgYgFSAOIAQgCiAHIAggGUKlzqqY+ajk01V8ELwCIAJBkAlqIAIpA6AJIgcgAikDqAkiCCAFIAYgFSAOIAQgCiACKQPICSIRQu+EjoCe6pjlBnwQvAIgAkGACWogAikDkAkiBCACKQOYCSIKIAcgCCAFIAYgFSAOIAIpA8AJIhVC8Ny50PCsypQUfBC8AiACQfAIaiAXIBAgCSANIBogFSAREJYEIAJB4AhqIBIgCSAMIA8gFiACKQPwCCIXIAIpA/gIIhAQlgQgAkHQCGogAikDgAkiEiACKQOICSIOIAQgCiAHIAggBSAGIBBC/N/IttTQwtsnfBC8AiACQcAIaiACKQPQCCIFIAIpA9gIIgYgEiAOIAQgCiAHIAggF0KmkpvhhafIjS58ELwCIAJBsAhqIAIpA8AIIgcgAikDyAgiCCAFIAYgEiAOIAQgCiACKQPoCCIJQu3VkNbFv5uWzQB8ELwCIAJBoAhqIAIpA7AIIgQgAikDuAgiCiAHIAggBSAGIBIgDiACKQPgCCISQt/n1uy5ooOc0wB8ELwCIAJBkAhqIBggDCALIBEgGSASIAkQlgQgAkGACGogFCALIBMgECAVIAIpA5AIIhggAikDmAgiDBCWBCACQfAHaiACKQOgCCIUIAIpA6gIIg4gBCAKIAcgCCAFIAYgDELex73dyOqcheUAfBC8AiACQeAHaiACKQPwByIFIAIpA/gHIgYgFCAOIAQgCiAHIAggGEKo5d7js9eCtfYAfBC8AiACQdAHaiACKQPgByIHIAIpA+gHIgggBSAGIBQgDiAEIAogAikDiAgiC0Lm3ba/5KWy4YF/fBC8AiACQcAHaiACKQPQByIEIAIpA9gHIgogByAIIAUgBiAUIA4gAikDgAgiFEK76oik0ZCLuZJ/fBC8AiACQbAHaiAaIBMgDSAJIBcgFCALEJYEIAJBoAdqIBYgDSAPIAwgEiACKQOwByIaIAIpA7gHIhMQlgQgAkGQB2ogAikDwAciFiACKQPIByIOIAQgCiAHIAggBSAGIBNC5IbE55SU+t+if3wQvAIgAkGAB2ogAikDkAciBSACKQOYByIGIBYgDiAEIAogByAIIBpCgeCI4rvJmY2of3wQvAIgAkHwBmogAikDgAciByACKQOIByIIIAUgBiAWIA4gBCAKIAIpA6gHIg1Cka/ih43u4qVCfBC8AiACQeAGaiACKQPwBiIEIAIpA/gGIgogByAIIAUgBiAWIA4gAikDoAciFkKw/NKysLSUtkd8ELwCIAJB0AZqIBkgDyARIAsgGCAWIA0QlgQgAkHABmogFSARIBAgEyAUIAIpA9AGIhkgAikD2AYiDxCWBCACQbAGaiACKQPgBiIVIAIpA+gGIg4gBCAKIAcgCCAFIAYgD0KYpL23nYO6yVF8ELwCIAJBoAZqIAIpA7AGIgUgAikDuAYiBiAVIA4gBCAKIAcgCCAZQpDSlqvFxMHMVnwQvAIgAkGQBmogAikDoAYiByACKQOoBiIIIAUgBiAVIA4gBCAKIAIpA8gGIhFCqsDEu9WwjYd0fBC8AiACQYAGaiACKQOQBiIEIAIpA5gGIgogByAIIAUgBiAVIA4gAikDwAYiFUK4o++Vg46otRB8ELwCIAJB8AVqIBcgECAJIA0gGiAVIBEQlgQgAkHgBWogEiAJIAwgDyAWIAIpA/AFIhcgAikD+AUiEBCWBCACQdAFaiACKQOABiISIAIpA4gGIg4gBCAKIAcgCCAFIAYgEELIocvG66Kw0hl8ELwCIAJBwAVqIAIpA9AFIgUgAikD2AUiBiASIA4gBCAKIAcgCCAXQtPWhoqFgdubHnwQvAIgAkGwBWogAikDwAUiByACKQPIBSIIIAUgBiASIA4gBCAKIAIpA+gFIglCmde7/M3pnaQnfBC8AiACQaAFaiACKQOwBSIEIAIpA7gFIgogByAIIAUgBiASIA4gAikD4AUiEkKoke2M3pav2DR8ELwCIAJBkAVqIBggDCALIBEgGSASIAkQlgQgAkGABWogFCALIBMgECAVIAIpA5AFIhggAikDmAUiDBCWBCACQfAEaiACKQOgBSIUIAIpA6gFIg4gBCAKIAcgCCAFIAYgDELjtKWuvJaDjjl8ELwCIAJB4ARqIAIpA/AEIgUgAikD+AQiBiAUIA4gBCAKIAcgCCAYQsuVhpquyarszgB8ELwCIAJB0ARqIAIpA+AEIgcgAikD6AQiCCAFIAYgFCAOIAQgCiACKQOIBSILQvPGj7v3ybLO2wB8ELwCIAJBwARqIAIpA9AEIgQgAikD2AQiCiAHIAggBSAGIBQgDiACKQOABSIUQqPxyrW9/puX6AB8ELwCIAJBsARqIBogEyANIAkgFyAUIAsQlgQgAkGgBGogFiANIA8gDCASIAIpA7AEIhogAikDuAQiExCWBCACQZAEaiACKQPABCIWIAIpA8gEIg4gBCAKIAcgCCAFIAYgE0L85b7v5d3gx/QAfBC8AiACQYAEaiACKQOQBCIFIAIpA5gEIgYgFiAOIAQgCiAHIAggGkLg3tyY9O3Y0vgAfBC8AiACQfADaiACKQOABCIHIAIpA4gEIgggBSAGIBYgDiAEIAogAikDqAQiDULy1sKPyoKe5IR/fBC8AiACQeADaiACKQPwAyIEIAIpA/gDIgogByAIIAUgBiAWIA4gAikDoAQiFkLs85DTgcHA44x/fBC8AiACQdADaiAZIA8gESALIBggFiANEJYEIAJBwANqIBUgESAQIBMgFCACKQPQAyIZIAIpA9gDIg8QlgQgAkGwA2ogAikD4AMiFSACKQPoAyIOIAQgCiAHIAggBSAGIA9CqLyMm6L/v9+Qf3wQvAIgAkGgA2ogAikDsAMiBSACKQO4AyIGIBUgDiAEIAogByAIIBlC6fuK9L2dm6ikf3wQvAIgAkGQA2ogAikDoAMiByACKQOoAyIIIAUgBiAVIA4gBCAKIAIpA8gDIhFClfKZlvv+6Py+f3wQvAIgAkGAA2ogAikDkAMiBCACKQOYAyIKIAcgCCAFIAYgFSAOIAIpA8ADIhVCq6bJm66e3rhGfBC8AiACQfACaiAXIBAgCSANIBogFSAREJYEIAJB4AJqIBIgCSAMIA8gFiACKQPwAiIOIAIpA/gCIhAQlgQgAkHQAmogAikDgAMiCSACKQOIAyIXIAQgCiAHIAggBSAGIBBCnMOZ0e7Zz5NKfBC8AiACQcACaiACKQPQAiIFIAIpA9gCIgYgCSAXIAQgCiAHIAggDkKHhIOO8piuw1F8ELwCIAJBsAJqIAIpA8ACIhIgAikDyAIiByAFIAYgCSAXIAQgCiACKQPoAiIKQp7Wg+/sup/tanwQvAIgAkGgAmogAikDsAIiBCACKQO4AiIIIBIgByAFIAYgCSAXIAIpA+ACIh1C+KK78/7v0751fBC8AiACQZACaiAYIAwgCyARIBkgHSAKEJYEIAJBgAJqIBQgCyATIBAgFSACKQOQAiIYIAIpA5gCIhQQlgQgAkHwAWogAikDoAIiCSACKQOoAiIMIAQgCCASIAcgBSAGIBRCut/dkKf1mfgGfBC8AiACQeABaiACKQPwASILIAIpA/gBIgUgCSAMIAQgCCASIAcgGEKmsaKW2rjfsQp8ELwCIAJB0AFqIAIpA+ABIgYgAikD6AEiFyALIAUgCSAMIAQgCCACKQOIAiIHQq6b5PfLgOafEXwQvAIgAkHAAWogAikD0AEiBCACKQPYASISIAYgFyALIAUgCSAMIAIpA4ACIghCm47xmNHmwrgbfBC8AiACQbABaiAaIBMgDSAKIA4gCCAHEJYEIAJBoAFqIBYgDSAPIBQgHSACKQOwASINIAIpA7gBIhQQlgQgAkGQAWogAikDwAEiCSACKQPIASIMIAQgEiAGIBcgCyAFIBRChPuRmNL+3e0ofBC8AiACQYABaiACKQOQASILIAIpA5gBIhMgCSAMIAQgEiAGIBcgDUKTyZyGtO+q5TJ8ELwCIAJB8ABqIAIpA4ABIg0gAikDiAEiBSALIBMgCSAMIAQgEiACKQOoASIXQrz9pq6hwa/PPHwQvAIgAkHgAGogAikDcCIEIAIpA3giBiANIAUgCyATIAkgDCACKQOgASIJQsyawODJ+NmOwwB8ELwCIAJB0ABqIBkgDyARIAcgGCAJIBcQlgQgAkFAayAVIBEgECAUIAggAikDUCIRIAIpA1giCRCWBCACQTBqIAIpA2AiDyACKQNoIhAgBCAGIA0gBSALIBMgCUK2hfnZ7Jf14swAfBC8AiACQSBqIAIpAzAiCSACKQM4IgwgDyAQIAQgBiANIAUgEUKq/JXjz7PKv9kAfBC8AiACQRBqIAIpAyAiCyACKQMoIhMgCSAMIA8gECAEIAYgAikDSELs9dvWs/Xb5d8AfBC8AiACIAIpAxAiDSACKQMYIhEgCyATIAkgDCAPIBAgAikDQEKXsJ3SxLGGouwAfBC8AiACKQMAIQ8gAikDCCEQIAAgDCAjfDcDOCAAIBMgIXw3AzAgACARIB98NwMoIAAgCSAifDcDGCAAIAsgIHw3AxAgACANIB58NwMIIAAgECAcfDcDICAAIA8gG3w3AwAgAkGAD2okAAulGQERfyAAKAKAICICQQ9xRQRAIABBgBBqIQQgAkH/A3EiCEEBaiEOIAJBEGpB/wNxIRIgAkHwA2pB/wNxIgNBBGohCSADQQZqIQsgA0ENaiEMAn8gAkGABHEEQCAEIAhBAnRqIgIgAigCACAEIAtBAnRqIgsoAgBBCHdqIAQgDEECdGoiCigCAEEKdyAEIA5BAnRqIggoAgBBF3dzaiIONgIAIAEgDiAAIAQgCUECdGooAgAiCUEOdkH8B3FBgAhyaigCACAAIAlB/wFxQQJ0aigCAGpzNgIAIAggCCgCACADQQJ0IARqIgNBHGoiDCgCAEEId2ogA0E4aiIPKAIAQQp3IAJBCGoiDigCAEEXd3NqIgk2AgAgASAJIAAgA0EUaigCACIFQQ52QfwHcUGACHJqKAIAIAAgBUH/AXFBAnRqKAIAanM2AgQgDiAOKAIAIANBIGoiBSgCAEEId2ogA0E8aiIRKAIAQQp3IAJBDGoiCSgCAEEXd3NqIgc2AgAgASAAIAsoAgAiC0EOdkH8B3FBgAhyaigCACAAIAtB/wFxQQJ0aigCAGogB3M2AgggCSAJKAIAIANBJGoiBygCAEEId2ogAigCAEEKdyACQRBqIgsoAgBBF3dzaiIGNgIAIAEgACAMKAIAIgxBDnZB/AdxQYAIcmooAgAgACAMQf8BcUECdGooAgBqIAZzNgIMIAsgCygCACADQShqIgYoAgBBCHdqIAgoAgBBCncgAkEUaiIMKAIAQRd3c2oiDTYCACABIAAgBSgCACIFQQ52QfwHcUGACHJqKAIAIAAgBUH/AXFBAnRqKAIAaiANczYCECAMIAwoAgAgA0EsaiINKAIAQQh3aiAOKAIAQQp3IAJBGGoiBSgCAEEXd3NqIhA2AgAgASAAIAcoAgAiB0EOdkH8B3FBgAhyaigCACAAIAdB/wFxQQJ0aigCAGogEHM2AhQgBSAFKAIAIANBMGoiECgCAEEId2ogCSgCAEEKdyACQRxqIgMoAgBBF3dzaiIHNgIAIAEgByAAIAYoAgAiBkEOdkH8B3FBgAhyaigCACAAIAZB/wFxQQJ0aigCAGpzNgIYIAMgAygCACAKKAIAQQh3aiALKAIAQQp3IAJBIGoiBygCAEEXd3NqIgY2AgAgASAGIAAgDSgCACINQQ52QfwHcUGACHJqKAIAIAAgDUH/AXFBAnRqKAIAanM2AhwgByAHKAIAIA8oAgBBCHdqIAwoAgBBCncgAkEkaiIGKAIAQRd3c2oiDTYCACABIA0gACAQKAIAIhBBDnZB/AdxQYAIcmooAgAgACAQQf8BcUECdGooAgBqczYCICAGIAYoAgAgESgCAEEId2ogBSgCAEEKdyACQShqIgUoAgBBF3dzaiINNgIAIAEgACAKKAIAIgpBDnZB/AdxQYAIcmooAgAgACAKQf8BcUECdGooAgBqIA1zNgIkIAUgBSgCACACKAIAQQh3aiADKAIAQQp3IAJBLGoiAygCAEEXd3NqIgo2AgAgASAKIAAgDygCACIPQQ52QfwHcUGACHJqKAIAIAAgD0H/AXFBAnRqKAIAanM2AiggAyADKAIAIAgoAgBBCHdqIAcoAgBBCncgAkEwaiIHKAIAQRd3c2oiCjYCACABIAogACARKAIAIg9BDnZB/AdxQYAIcmooAgAgACAPQf8BcUECdGooAgBqczYCLCAHIAcoAgAgDigCAEEId2ogBigCAEEKdyACQTRqIgYoAgBBF3dzaiIKNgIAIAEgCiAAIAIoAgAiD0EOdkH8B3FBgAhyaigCACAAIA9B/wFxQQJ0aigCAGpzNgIwIAYgBigCACAJKAIAQQh3aiAFKAIAQQp3IAJBOGoiBSgCAEEXd3NqIgY2AgAgASAAIAgoAgAiCEEOdkH8B3FBgAhyaigCACAAIAhB/wFxQQJ0aigCAGogBnM2AjQgBSAFKAIAIAsoAgBBCHdqIAMoAgBBCncgAkE8aiICKAIAQRd3c2oiAzYCACABIAMgACAOKAIAIghBDnZB/AdxQYAIcmooAgAgACAIQf8BcUECdGooAgBqczYCOCACIAIoAgAgDCgCAEEId2ogBygCAEEKdyAEIBJBAnRqKAIAQRd3c2oiAjYCACAAIAkoAgAiBEH/AXFBAnRqIQMgACAEQQ52QfwHcUGACHJqDAELIAAgCEECdGoiAiACKAIAIAAgC0ECdGoiCygCAEEYd2ogACAMQQJ0aiIKKAIAQRZ3IAAgDkECdGoiCCgCAEEJd3NqIg42AgAgASAOIAQgACAJQQJ0aigCACIJQQ52QfwHcUGACHJqKAIAIAQgCUH/AXFBAnRqKAIAanM2AgAgCCAIKAIAIANBAnQgAGoiA0EcaiIMKAIAQRh3aiADQThqIg8oAgBBFncgAkEIaiIOKAIAQQl3c2oiCTYCACABIAkgBCADQRRqKAIAIgVBDnZB/AdxQYAIcmooAgAgBCAFQf8BcUECdGooAgBqczYCBCAOIA4oAgAgA0EgaiIFKAIAQRh3aiADQTxqIhEoAgBBFncgAkEMaiIJKAIAQQl3c2oiBzYCACABIAQgCygCACILQQ52QfwHcUGACHJqKAIAIAQgC0H/AXFBAnRqKAIAaiAHczYCCCAJIAkoAgAgA0EkaiIHKAIAQRh3aiACKAIAQRZ3IAJBEGoiCygCAEEJd3NqIgY2AgAgASAEIAwoAgAiDEEOdkH8B3FBgAhyaigCACAEIAxB/wFxQQJ0aigCAGogBnM2AgwgCyALKAIAIANBKGoiBigCAEEYd2ogCCgCAEEWdyACQRRqIgwoAgBBCXdzaiINNgIAIAEgBCAFKAIAIgVBDnZB/AdxQYAIcmooAgAgBCAFQf8BcUECdGooAgBqIA1zNgIQIAwgDCgCACADQSxqIg0oAgBBGHdqIA4oAgBBFncgAkEYaiIFKAIAQQl3c2oiEDYCACABIAQgBygCACIHQQ52QfwHcUGACHJqKAIAIAQgB0H/AXFBAnRqKAIAaiAQczYCFCAFIAUoAgAgA0EwaiIQKAIAQRh3aiAJKAIAQRZ3IAJBHGoiAygCAEEJd3NqIgc2AgAgASAHIAQgBigCACIGQQ52QfwHcUGACHJqKAIAIAQgBkH/AXFBAnRqKAIAanM2AhggAyADKAIAIAooAgBBGHdqIAsoAgBBFncgAkEgaiIHKAIAQQl3c2oiBjYCACABIAYgBCANKAIAIg1BDnZB/AdxQYAIcmooAgAgBCANQf8BcUECdGooAgBqczYCHCAHIAcoAgAgDygCAEEYd2ogDCgCAEEWdyACQSRqIgYoAgBBCXdzaiINNgIAIAEgDSAEIBAoAgAiEEEOdkH8B3FBgAhyaigCACAEIBBB/wFxQQJ0aigCAGpzNgIgIAYgBigCACARKAIAQRh3aiAFKAIAQRZ3IAJBKGoiBSgCAEEJd3NqIg02AgAgASAEIAooAgAiCkEOdkH8B3FBgAhyaigCACAEIApB/wFxQQJ0aigCAGogDXM2AiQgBSAFKAIAIAIoAgBBGHdqIAMoAgBBFncgAkEsaiIDKAIAQQl3c2oiCjYCACABIAogBCAPKAIAIg9BDnZB/AdxQYAIcmooAgAgBCAPQf8BcUECdGooAgBqczYCKCADIAMoAgAgCCgCAEEYd2ogBygCAEEWdyACQTBqIgcoAgBBCXdzaiIKNgIAIAEgCiAEIBEoAgAiD0EOdkH8B3FBgAhyaigCACAEIA9B/wFxQQJ0aigCAGpzNgIsIAcgBygCACAOKAIAQRh3aiAGKAIAQRZ3IAJBNGoiBigCAEEJd3NqIgo2AgAgASAKIAQgAigCACIPQQ52QfwHcUGACHJqKAIAIAQgD0H/AXFBAnRqKAIAanM2AjAgBiAGKAIAIAkoAgBBGHdqIAUoAgBBFncgAkE4aiIFKAIAQQl3c2oiBjYCACABIAQgCCgCACIIQQ52QfwHcUGACHJqKAIAIAQgCEH/AXFBAnRqKAIAaiAGczYCNCAFIAUoAgAgCygCAEEYd2ogAygCAEEWdyACQTxqIgIoAgBBCXdzaiIDNgIAIAEgAyAEIA4oAgAiCEEOdkH8B3FBgAhyaigCACAEIAhB/wFxQQJ0aigCAGpzNgI4IAIgAigCACAMKAIAQRh3aiAHKAIAQRZ3IAAgEkECdGooAgBBCXdzaiICNgIAIAQgCSgCACIIQf8BcUECdGohAyAEIAhBDnZB/AdxQYAIcmoLIQQgASAEKAIAIAMoAgBqIAJzNgI8IAAgACgCgCBBEGo2AoAgDwtBtP3JAEEsQbj+yQAQzgMAC7MSAgF/Gn4jAEGABmsiAyQAIANBsAVqIAEQhgEgA0HYBWogAhCGASADQYgFaiADQbAFaiADQdgFahCPAiADQbgCaiADKQOIBSIEQu3Nh7nWl9IHEJ4CIANB6AFqIAMpA7gCIgVCm/zRkrG0xwJ+Qv////////8HgyIGQu2n1+el45gBEJ4CIANBqAJqIARC2sif49rW7gEQngIgA0GIA2ogAykDkAUiCULtzYe51pfSBxCeAiADQdgBaiAGQoHLtc73xfoGEJ4CIANBuAFqIAMpA4gDIgogAykDqAJ8Ig0gAykD2AF8IgcgBSADKQPoASIIfCIFQjSIIAUgCFStIANB8AFqKQMAIANBwAJqKQMAfHwiEkIMhoR8IgtCm/zRkrG0xwJ+Qv////////8HgyIFQu2n1+el45gBEJ4CIANBmAJqIARCm8rX2f7//wcQngIgA0H4AmogCULayJ/j2tbuARCeAiADQdgDaiADKQOYBSIIQu3Nh7nWl9IHEJ4CIANByAFqIAZC+b3TABCeAiADQagBaiAFQoHLtc73xfoGEJ4CIANBiAFqIAMpA/gCIhQgAykDmAJ8IgwgAykD2AN8Ig4gAykDyAF8Ig8gAykDqAF8IhAgAykDuAEiEyALfCIRQjSIIBEgE1StIANBwAFqKQMAIAsgB1StIAcgDVStIANB4AFqKQMAIA0gClStIANBkANqKQMAIANBsAJqKQMAfHx8fCASQjSIfHx8fCIVQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0GIAmogBEL/////////BxCeAiADQegCaiAJQpvK19n+//8HEJ4CIANByANqIAhC2sif49rW7gEQngIgA0GoBGogAykDoAUiB0LtzYe51pfSBxCeAiADQZgBaiAFQvm90wAQngIgA0H4AGogDUKBy7XO98X6BhCeAiADQdgAaiADKQPoAiIZIAMpA4gCfCIKIAMpA8gDfCISIAMpA6gEfCITIAMpA5gBfCIRIAMpA3h8IhYgAykDiAEiFyALfCIYQjSIIBggF1StIANBkAFqKQMAIAsgEFStIBAgD1StIANBsAFqKQMAIA8gDlStIANB0AFqKQMAIA4gDFStIANB4ANqKQMAIAwgFFStIANBgANqKQMAIANBoAJqKQMAfHx8fHx8fHwgFUI0iHx8fHwiGkIMhoR8IgxCm/zRkrG0xwJ+Qv////////8HgyILQu2n1+el45gBEJ4CIANB+AFqIARC////////AxCeAiADQdgCaiAJQv////////8HEJ4CIANBuANqIAhCm8rX2f7//wcQngIgA0GYBGogB0LayJ/j2tbuARCeAiADQfgEaiADKQOoBSIEQu3Nh7nWl9IHEJ4CIANB6ABqIA1C+b3TABCeAiADQcgAaiALQoHLtc73xfoGEJ4CIANBKGogAykD2AIiGyADKQP4AXwiDiADKQO4A3wiDyADKQOYBHwiECADKQP4BHwiFCAGQiyGfCIVIAMpA2h8IhcgAykDSHwiGCADKQNYIhwgDHwiHUI0iCAdIBxUrSADQeAAaikDACAMIBZUrSAWIBFUrSADQYABaikDACARIBNUrSADQaABaikDACATIBJUrSADQbAEaikDACASIApUrSADQdADaikDACAKIBlUrSADQfACaikDACADQZACaikDAHx8fHx8fHx8fHwgGkI0iHx8fHwiEUIMhoR8IgpCm/zRkrG0xwJ+Qv////////8HgyIMQu2n1+el45gBEJ4CIANByAJqIAlC////////AxCeAiADQagDaiAIQv////////8HEJ4CIANBiARqIAdCm8rX2f7//wcQngIgA0HoBGogBELayJ/j2tbuARCeAiADQThqIAtC+b3TABCeAiADQRhqIAxCgcu1zvfF+gYQngIgA0GYA2ogCEL///////8DEJ4CIANB+ANqIAdC/////////wcQngIgA0HYBGogBEKbytfZ/v//BxCeAiADQQhqIAxC+b3TABCeAiADQegDaiAHQv///////wMQngIgA0HIBGogBEL/////////BxCeAiADQbgEaiAEQv///////wMQngIgAyADKQOoAyIWIAMpA8gCfCIEIAMpA4gEfCIJIAMpA+gEfCIIIAVCLIZ8IgcgAykDOHwiEiADKQMYfCITIAMpAygiGSAKfCIaQjSIIBogGVStIANBMGopAwAgCiAYVK0gGCAXVK0gA0HQAGopAwAgFyAVVK0gA0HwAGopAwAgFSAUVK0gFCAQVK0gA0GABWopAwAgECAPVK0gA0GgBGopAwAgDyAOVK0gA0HAA2opAwAgDiAbVK0gA0HgAmopAwAgA0GAAmopAwB8fHx8fHx8fCAGQhSIfHx8fHx8IBFCNIh8fHx8IhFCDIaEfCIGQv////////8HgzcD2AUgAyADKQP4AyIUIAMpA5gDfCIOIAMpA9gEfCIPIA1CLIZ8IhAgAykDCHwiCiAGIBNUrSATIBJUrSADQSBqKQMAIBIgB1StIANBQGspAwAgByAIVK0gCCAJVK0gA0HwBGopAwAgCSAEVK0gA0GQBGopAwAgBCAWVK0gA0GwA2opAwAgA0HQAmopAwB8fHx8fHwgBUIUiHx8fHx8fCARQjSIfHwiBUIMhiAGQjSIhHwiBEL/////////B4M3A+AFIAMgAykDyAQiCCADKQPoA3wiBiALQiyGfCIJIAQgClStIAogEFStIANBEGopAwAgECAPVK0gDyAOVK0gA0HgBGopAwAgDiAUVK0gA0GABGopAwAgA0GgA2opAwB8fHx8IA1CFIh8fHx8IAVCNIh8fCINQgyGIARCNIiEfCIEQv////////8HgzcD6AUgAyAMQiyGIgcgAykDuAR8IgUgBCAJVK0gCSAGVK0gBiAIVK0gA0HQBGopAwAgA0HwA2opAwB8fCALQhSIfHwgDUI0iHx8IgZCDIYgBEI0iIR8IgRC/////////weDNwPwBSADIAQgBVStIAUgB1StIANBwARqKQMAIAxCFIh8fCAGQjSIfHxCDIYgBEI0iIQ3A/gFIANBsAVqIANB2AVqQaC9xAAQoAEgACADQbAFahBxIANBgAZqJAALsxICAX8afiMAQYAGayIDJAAgA0GwBWogARCHASADQdgFaiACEIcBIANBiAVqIANBsAVqIANB2AVqEJICIANBuAJqIAMpA4gFIgRC7c2HudaX0gcQngIgA0HoAWogAykDuAIiBUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GoAmogBELayJ/j2tbuARCeAiADQYgDaiADKQOQBSIJQu3Nh7nWl9IHEJ4CIANB2AFqIAZCgcu1zvfF+gYQngIgA0G4AWogAykDiAMiCiADKQOoAnwiDSADKQPYAXwiByAFIAMpA+gBIgh8IgVCNIggBSAIVK0gA0HwAWopAwAgA0HAAmopAwB8fCISQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GYAmogBEKbytfZ/v//BxCeAiADQfgCaiAJQtrIn+Pa1u4BEJ4CIANB2ANqIAMpA5gFIghC7c2HudaX0gcQngIgA0HIAWogBkL5vdMAEJ4CIANBqAFqIAVCgcu1zvfF+gYQngIgA0GIAWogAykD+AIiFCADKQOYAnwiDCADKQPYA3wiDiADKQPIAXwiDyADKQOoAXwiECADKQO4ASITIAt8IhFCNIggESATVK0gA0HAAWopAwAgCyAHVK0gByANVK0gA0HgAWopAwAgDSAKVK0gA0GQA2opAwAgA0GwAmopAwB8fHx8IBJCNIh8fHx8IhVCDIaEfCILQpv80ZKxtMcCfkL/////////B4MiDULtp9fnpeOYARCeAiADQYgCaiAEQv////////8HEJ4CIANB6AJqIAlCm8rX2f7//wcQngIgA0HIA2ogCELayJ/j2tbuARCeAiADQagEaiADKQOgBSIHQu3Nh7nWl9IHEJ4CIANBmAFqIAVC+b3TABCeAiADQfgAaiANQoHLtc73xfoGEJ4CIANB2ABqIAMpA+gCIhkgAykDiAJ8IgogAykDyAN8IhIgAykDqAR8IhMgAykDmAF8IhEgAykDeHwiFiADKQOIASIXIAt8IhhCNIggGCAXVK0gA0GQAWopAwAgCyAQVK0gECAPVK0gA0GwAWopAwAgDyAOVK0gA0HQAWopAwAgDiAMVK0gA0HgA2opAwAgDCAUVK0gA0GAA2opAwAgA0GgAmopAwB8fHx8fHx8fCAVQjSIfHx8fCIaQgyGhHwiDEKb/NGSsbTHAn5C/////////weDIgtC7afX56XjmAEQngIgA0H4AWogBEL///////8DEJ4CIANB2AJqIAlC/////////wcQngIgA0G4A2ogCEKbytfZ/v//BxCeAiADQZgEaiAHQtrIn+Pa1u4BEJ4CIANB+ARqIAMpA6gFIgRC7c2HudaX0gcQngIgA0HoAGogDUL5vdMAEJ4CIANByABqIAtCgcu1zvfF+gYQngIgA0EoaiADKQPYAiIbIAMpA/gBfCIOIAMpA7gDfCIPIAMpA5gEfCIQIAMpA/gEfCIUIAZCLIZ8IhUgAykDaHwiFyADKQNIfCIYIAMpA1giHCAMfCIdQjSIIB0gHFStIANB4ABqKQMAIAwgFlStIBYgEVStIANBgAFqKQMAIBEgE1StIANBoAFqKQMAIBMgElStIANBsARqKQMAIBIgClStIANB0ANqKQMAIAogGVStIANB8AJqKQMAIANBkAJqKQMAfHx8fHx8fHx8fCAaQjSIfHx8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0HIAmogCUL///////8DEJ4CIANBqANqIAhC/////////wcQngIgA0GIBGogB0KbytfZ/v//BxCeAiADQegEaiAEQtrIn+Pa1u4BEJ4CIANBOGogC0L5vdMAEJ4CIANBGGogDEKBy7XO98X6BhCeAiADQZgDaiAIQv///////wMQngIgA0H4A2ogB0L/////////BxCeAiADQdgEaiAEQpvK19n+//8HEJ4CIANBCGogDEL5vdMAEJ4CIANB6ANqIAdC////////AxCeAiADQcgEaiAEQv////////8HEJ4CIANBuARqIARC////////AxCeAiADIAMpA6gDIhYgAykDyAJ8IgQgAykDiAR8IgkgAykD6AR8IgggBUIshnwiByADKQM4fCISIAMpAxh8IhMgAykDKCIZIAp8IhpCNIggGiAZVK0gA0EwaikDACAKIBhUrSAYIBdUrSADQdAAaikDACAXIBVUrSADQfAAaikDACAVIBRUrSAUIBBUrSADQYAFaikDACAQIA9UrSADQaAEaikDACAPIA5UrSADQcADaikDACAOIBtUrSADQeACaikDACADQYACaikDAHx8fHx8fHx8IAZCFIh8fHx8fHwgEUI0iHx8fHwiEUIMhoR8IgZC/////////weDNwPYBSADIAMpA/gDIhQgAykDmAN8Ig4gAykD2AR8Ig8gDUIshnwiECADKQMIfCIKIAYgE1StIBMgElStIANBIGopAwAgEiAHVK0gA0FAaykDACAHIAhUrSAIIAlUrSADQfAEaikDACAJIARUrSADQZAEaikDACAEIBZUrSADQbADaikDACADQdACaikDAHx8fHx8fCAFQhSIfHx8fHx8IBFCNIh8fCIFQgyGIAZCNIiEfCIEQv////////8HgzcD4AUgAyADKQPIBCIIIAMpA+gDfCIGIAtCLIZ8IgkgBCAKVK0gCiAQVK0gA0EQaikDACAQIA9UrSAPIA5UrSADQeAEaikDACAOIBRUrSADQYAEaikDACADQaADaikDAHx8fHwgDUIUiHx8fHwgBUI0iHx8Ig1CDIYgBEI0iIR8IgRC/////////weDNwPoBSADIAxCLIYiByADKQO4BHwiBSAEIAlUrSAJIAZUrSAGIAhUrSADQdAEaikDACADQfADaikDAHx8IAtCFIh8fCANQjSIfHwiBkIMhiAEQjSIhHwiBEL/////////B4M3A/AFIAMgBCAFVK0gBSAHVK0gA0HABGopAwAgDEIUiHx8IAZCNIh8fEIMhiAEQjSIhDcD+AUgA0GwBWogA0HYBWpB+O7IABChASAAIANBsAVqEHEgA0GABmokAAuTEgIBfxp+IwBBgAZrIgIkACACQYgFaiABEIYBIAJB+AFqIAIpA4gFIgNC7c2HudaX0gcQngIgAkHoAWogAikD+AEiBEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgAkGIAmogA0LayJ/j2tbuARCeAiACQcgCaiACKQOQBSIIQu3Nh7nWl9IHEJ4CIAJB2AFqIAVCgcu1zvfF+gYQngIgAkHIAWogAikDyAIiCSACKQOIAnwiDCACKQPYAXwiBiAEIAIpA+gBIgd8IgRCNIggBCAHVK0gAkHwAWopAwAgAkGAAmopAwB8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgAkGYAmogA0KbytfZ/v//BxCeAiACQdgCaiAIQtrIn+Pa1u4BEJ4CIAJBmANqIAIpA5gFIgdC7c2HudaX0gcQngIgAkGYAWogBUL5vdMAEJ4CIAJBuAFqIARCgcu1zvfF+gYQngIgAkGIAWogAikD2AIiEyACKQOYAnwiCyACKQOYA3wiDSACKQOYAXwiDiACKQO4AXwiDyACKQPIASISIAp8IhBCNIggECASVK0gAkHQAWopAwAgCiAGVK0gBiAMVK0gAkHgAWopAwAgDCAJVK0gAkHQAmopAwAgAkGQAmopAwB8fHx8IBFCNIh8fHx8IhRCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiACQagCaiADQv////////8HEJ4CIAJB6AJqIAhCm8rX2f7//wcQngIgAkGoA2ogB0LayJ/j2tbuARCeAiACQegDaiACKQOgBSIGQu3Nh7nWl9IHEJ4CIAJBqAFqIARC+b3TABCeAiACQfgAaiAMQoHLtc73xfoGEJ4CIAJB6ABqIAIpA+gCIhggAikDqAJ8IgkgAikDqAN8IhEgAikD6AN8IhIgAikDqAF8IhAgAikDeHwiFSACKQOIASIWIAp8IhdCNIggFyAWVK0gAkGQAWopAwAgCiAPVK0gDyAOVK0gAkHAAWopAwAgDiANVK0gAkGgAWopAwAgDSALVK0gAkGgA2opAwAgCyATVK0gAkHgAmopAwAgAkGgAmopAwB8fHx8fHx8fCAUQjSIfHx8fCIZQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgpC7afX56XjmAEQngIgAkG4AmogA0L///////8DEJ4CIAJB+AJqIAhC/////////wcQngIgAkG4A2ogB0KbytfZ/v//BxCeAiACQfgDaiAGQtrIn+Pa1u4BEJ4CIAJBuARqIAIpA6gFIgNC7c2HudaX0gcQngIgAkE4aiAMQvm90wAQngIgAkHYAGogCkKBy7XO98X6BhCeAiACQShqIAIpA/gCIhogAikDuAJ8Ig0gAikDuAN8Ig4gAikD+AN8Ig8gAikDuAR8IhMgBUIshnwiFCACKQM4fCIWIAIpA1h8IhcgAikDaCIbIAt8IhxCNIggHCAbVK0gAkHwAGopAwAgCyAVVK0gFSAQVK0gAkGAAWopAwAgECASVK0gAkGwAWopAwAgEiARVK0gAkHwA2opAwAgESAJVK0gAkGwA2opAwAgCSAYVK0gAkHwAmopAwAgAkGwAmopAwB8fHx8fHx8fHx8IBlCNIh8fHx8IhBCDIaEfCIJQpv80ZKxtMcCfkL/////////B4MiC0Ltp9fnpeOYARCeAiACQYgDaiAIQv///////wMQngIgAkHIA2ogB0L/////////BxCeAiACQYgEaiAGQpvK19n+//8HEJ4CIAJByARqIANC2sif49rW7gEQngIgAkHIAGogCkL5vdMAEJ4CIAJBGGogC0KBy7XO98X6BhCeAiACQdgDaiAHQv///////wMQngIgAkGYBGogBkL/////////BxCeAiACQdgEaiADQpvK19n+//8HEJ4CIAJBCGogC0L5vdMAEJ4CIAJBqARqIAZC////////AxCeAiACQegEaiADQv////////8HEJ4CIAJB+ARqIANC////////AxCeAiACIAIpA8gDIhUgAikDiAN8IgMgAikDiAR8IgggAikDyAR8IgcgBEIshnwiBiACKQNIfCIRIAIpAxh8IhIgAikDKCIYIAl8IhlCNIggGSAYVK0gAkEwaikDACAJIBdUrSAXIBZUrSACQeAAaikDACAWIBRUrSACQUBrKQMAIBQgE1StIBMgD1StIAJBwARqKQMAIA8gDlStIAJBgARqKQMAIA4gDVStIAJBwANqKQMAIA0gGlStIAJBgANqKQMAIAJBwAJqKQMAfHx8fHx8fHwgBUIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBUL/////////B4M3A9gFIAIgAikDmAQiEyACKQPYA3wiDSACKQPYBHwiDiAMQiyGfCIPIAIpAwh8IgkgBSASVK0gEiARVK0gAkEgaikDACARIAZUrSACQdAAaikDACAGIAdUrSAHIAhUrSACQdAEaikDACAIIANUrSACQZAEaikDACADIBVUrSACQdADaikDACACQZADaikDAHx8fHx8fCAEQhSIfHx8fHx8IBBCNIh8fCIEQgyGIAVCNIiEfCIDQv////////8HgzcD4AUgAiACKQPoBCIHIAIpA6gEfCIFIApCLIZ8IgggAyAJVK0gCSAPVK0gAkEQaikDACAPIA5UrSAOIA1UrSACQeAEaikDACANIBNUrSACQaAEaikDACACQeADaikDAHx8fHwgDEIUiHx8fHwgBEI0iHx8IgxCDIYgA0I0iIR8IgNC/////////weDNwPoBSACIAtCLIYiBiACKQP4BHwiBCADIAhUrSAIIAVUrSAFIAdUrSACQfAEaikDACACQbAEaikDAHx8IApCFIh8fCAMQjSIfHwiBUIMhiADQjSIhHwiA0L/////////B4M3A/AFIAIgAyAEVK0gBCAGVK0gAkGABWopAwAgC0IUiHx8IAVCNIh8fEIMhiADQjSIhDcD+AUgAkGwBWogAkHYBWpBoL3EABCgASAAIAJBsAVqEHEgAkGABmokAAuTEgIBfxp+IwBBgAZrIgIkACACQYgFaiABEIcBIAJB+AFqIAIpA4gFIgNC7c2HudaX0gcQngIgAkHoAWogAikD+AEiBEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgAkGIAmogA0LayJ/j2tbuARCeAiACQcgCaiACKQOQBSIIQu3Nh7nWl9IHEJ4CIAJB2AFqIAVCgcu1zvfF+gYQngIgAkHIAWogAikDyAIiCSACKQOIAnwiDCACKQPYAXwiBiAEIAIpA+gBIgd8IgRCNIggBCAHVK0gAkHwAWopAwAgAkGAAmopAwB8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgAkGYAmogA0KbytfZ/v//BxCeAiACQdgCaiAIQtrIn+Pa1u4BEJ4CIAJBmANqIAIpA5gFIgdC7c2HudaX0gcQngIgAkGYAWogBUL5vdMAEJ4CIAJBuAFqIARCgcu1zvfF+gYQngIgAkGIAWogAikD2AIiEyACKQOYAnwiCyACKQOYA3wiDSACKQOYAXwiDiACKQO4AXwiDyACKQPIASISIAp8IhBCNIggECASVK0gAkHQAWopAwAgCiAGVK0gBiAMVK0gAkHgAWopAwAgDCAJVK0gAkHQAmopAwAgAkGQAmopAwB8fHx8IBFCNIh8fHx8IhRCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiACQagCaiADQv////////8HEJ4CIAJB6AJqIAhCm8rX2f7//wcQngIgAkGoA2ogB0LayJ/j2tbuARCeAiACQegDaiACKQOgBSIGQu3Nh7nWl9IHEJ4CIAJBqAFqIARC+b3TABCeAiACQfgAaiAMQoHLtc73xfoGEJ4CIAJB6ABqIAIpA+gCIhggAikDqAJ8IgkgAikDqAN8IhEgAikD6AN8IhIgAikDqAF8IhAgAikDeHwiFSACKQOIASIWIAp8IhdCNIggFyAWVK0gAkGQAWopAwAgCiAPVK0gDyAOVK0gAkHAAWopAwAgDiANVK0gAkGgAWopAwAgDSALVK0gAkGgA2opAwAgCyATVK0gAkHgAmopAwAgAkGgAmopAwB8fHx8fHx8fCAUQjSIfHx8fCIZQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgpC7afX56XjmAEQngIgAkG4AmogA0L///////8DEJ4CIAJB+AJqIAhC/////////wcQngIgAkG4A2ogB0KbytfZ/v//BxCeAiACQfgDaiAGQtrIn+Pa1u4BEJ4CIAJBuARqIAIpA6gFIgNC7c2HudaX0gcQngIgAkE4aiAMQvm90wAQngIgAkHYAGogCkKBy7XO98X6BhCeAiACQShqIAIpA/gCIhogAikDuAJ8Ig0gAikDuAN8Ig4gAikD+AN8Ig8gAikDuAR8IhMgBUIshnwiFCACKQM4fCIWIAIpA1h8IhcgAikDaCIbIAt8IhxCNIggHCAbVK0gAkHwAGopAwAgCyAVVK0gFSAQVK0gAkGAAWopAwAgECASVK0gAkGwAWopAwAgEiARVK0gAkHwA2opAwAgESAJVK0gAkGwA2opAwAgCSAYVK0gAkHwAmopAwAgAkGwAmopAwB8fHx8fHx8fHx8IBlCNIh8fHx8IhBCDIaEfCIJQpv80ZKxtMcCfkL/////////B4MiC0Ltp9fnpeOYARCeAiACQYgDaiAIQv///////wMQngIgAkHIA2ogB0L/////////BxCeAiACQYgEaiAGQpvK19n+//8HEJ4CIAJByARqIANC2sif49rW7gEQngIgAkHIAGogCkL5vdMAEJ4CIAJBGGogC0KBy7XO98X6BhCeAiACQdgDaiAHQv///////wMQngIgAkGYBGogBkL/////////BxCeAiACQdgEaiADQpvK19n+//8HEJ4CIAJBCGogC0L5vdMAEJ4CIAJBqARqIAZC////////AxCeAiACQegEaiADQv////////8HEJ4CIAJB+ARqIANC////////AxCeAiACIAIpA8gDIhUgAikDiAN8IgMgAikDiAR8IgggAikDyAR8IgcgBEIshnwiBiACKQNIfCIRIAIpAxh8IhIgAikDKCIYIAl8IhlCNIggGSAYVK0gAkEwaikDACAJIBdUrSAXIBZUrSACQeAAaikDACAWIBRUrSACQUBrKQMAIBQgE1StIBMgD1StIAJBwARqKQMAIA8gDlStIAJBgARqKQMAIA4gDVStIAJBwANqKQMAIA0gGlStIAJBgANqKQMAIAJBwAJqKQMAfHx8fHx8fHwgBUIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBUL/////////B4M3A9gFIAIgAikDmAQiEyACKQPYA3wiDSACKQPYBHwiDiAMQiyGfCIPIAIpAwh8IgkgBSASVK0gEiARVK0gAkEgaikDACARIAZUrSACQdAAaikDACAGIAdUrSAHIAhUrSACQdAEaikDACAIIANUrSACQZAEaikDACADIBVUrSACQdADaikDACACQZADaikDAHx8fHx8fCAEQhSIfHx8fHx8IBBCNIh8fCIEQgyGIAVCNIiEfCIDQv////////8HgzcD4AUgAiACKQPoBCIHIAIpA6gEfCIFIApCLIZ8IgggAyAJVK0gCSAPVK0gAkEQaikDACAPIA5UrSAOIA1UrSACQeAEaikDACANIBNUrSACQaAEaikDACACQeADaikDAHx8fHwgDEIUiHx8fHwgBEI0iHx8IgxCDIYgA0I0iIR8IgNC/////////weDNwPoBSACIAtCLIYiBiACKQP4BHwiBCADIAhUrSAIIAVUrSAFIAdUrSACQfAEaikDACACQbAEaikDAHx8IApCFIh8fCAMQjSIfHwiBUIMhiADQjSIhHwiA0L/////////B4M3A/AFIAIgAyAEVK0gBCAGVK0gAkGABWopAwAgC0IUiHx8IAVCNIh8fEIMhiADQjSIhDcD+AUgAkGwBWogAkHYBWpB+O7IABChASAAIAJBsAVqEHEgAkGABmokAAvkEAIBfx5+IwBBsAVrIgMkACADQfgBaiACKQMAIgkgASkDACIEEJ4CIANB6AFqIAMpA/gBIgxCm/zRkrG0xwJ+Qv////////8HgyIFQu2n1+el45gBEJ4CIANBiAJqIAIpAwgiDSAEEJ4CIANByAJqIAEpAwgiBiAJEJ4CIANB2AFqIAVCgcu1zvfF+gYQngIgA0HIAWogAykDyAIiDyADKQOIAnwiEyADKQPYAXwiDiAMIAMpA+gBIgp8IgxCNIggDCAKVK0gA0HwAWopAwAgA0GAAmopAwB8fCIRQgyGhHwiB0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GIA2ogBiANEJ4CIANBmAJqIAIpAxAiCiAEEJ4CIANB2AJqIAEpAxAiECAJEJ4CIANBmAFqIAVC+b3TABCeAiADQbgBaiAMQoHLtc73xfoGEJ4CIANBiAFqIAMpA5gCIhYgAykDiAN8IhQgAykD2AJ8IgggAykDmAF8IgsgAykDuAF8IhIgAykDyAEiFSAHfCIXQjSIIBcgFVStIANB0AFqKQMAIAcgDlStIA4gE1StIANB4AFqKQMAIBMgD1StIANB0AJqKQMAIANBkAJqKQMAfHx8fCARQjSIfHx8fCIYQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIhNC7afX56XjmAEQngIgA0HIA2ogCiAGEJ4CIANBmANqIBAgDRCeAiADQagCaiACKQMYIg4gBBCeAiADQegCaiABKQMYIgcgCRCeAiADQagBaiAMQvm90wAQngIgA0H4AGogE0KBy7XO98X6BhCeAiADQegAaiADKQOYAyIeIAMpA8gDfCIRIAMpA6gCfCIVIAMpA+gCfCIXIAMpA6gBfCIbIAMpA3h8IhwgAykDiAEiGSAPfCIaQjSIIBogGVStIANBkAFqKQMAIA8gElStIBIgC1StIANBwAFqKQMAIAsgCFStIANBoAFqKQMAIAggFFStIANB4AJqKQMAIBQgFlStIANBoAJqKQMAIANBkANqKQMAfHx8fHx8fHwgGEI0iHx8fHwiH0IMhoR8IgtCm/zRkrG0xwJ+Qv////////8HgyIUQu2n1+el45gBEJ4CIANB+ANqIBAgChCeAiADQdgDaiAOIAYQngIgA0GoA2ogByANEJ4CIANBuAJqIAIpAyAiCCAEEJ4CIANB+AJqIAEpAyAiBCAJEJ4CIANBOGogE0L5vdMAEJ4CIANB2ABqIBRCgcu1zvfF+gYQngIgA0EoaiADKQPYAyIgIAMpA/gDfCISIAVCLIZ8Ig8gAykDqAN8IhYgAykDuAJ8IhggAykD+AJ8IhkgAykDOHwiGiADKQNYfCIdIAMpA2giCSALfCIhQjSIICEgCVStIANB8ABqKQMAIAsgHFStIBwgG1StIANBgAFqKQMAIBsgF1StIANBsAFqKQMAIBcgFVStIANB8AJqKQMAIBUgEVStIANBsAJqKQMAIBEgHlStIANBoANqKQMAIANB0ANqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIRQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIglC7afX56XjmAEQngIgA0GoBGogDiAQEJ4CIANBiARqIAcgChCeAiADQegDaiAIIAYQngIgA0G4A2ogBCANEJ4CIANByABqIBRC+b3TABCeAiADQRhqIAlCgcu1zvfF+gYQngIgA0HIBGogByAOEJ4CIANBuARqIAggEBCeAiADQZgEaiAEIAoQngIgA0EIaiAJQvm90wAQngIgA0HoBGogCCAHEJ4CIANB2ARqIAQgDhCeAiADQfgEaiAEIAgQngIgAyADKQOIBCIVIAMpA6gEfCIEIAMpA+gDfCINIAMpA7gDfCIGIAxCLIZ8IgogAykDSHwiECADKQMYfCIOIAMpAygiByALfCIIQjSIIAggB1StIANBMGopAwAgCyAdVK0gHSAaVK0gA0HgAGopAwAgGiAZVK0gA0FAaykDACAZIBhUrSADQYADaikDACAYIBZUrSADQcACaikDACAWIA9UrSADQbADaikDACAPIBJUrSASICBUrSADQeADaikDACADQYAEaikDAHx8IAVCFIh8fHx8fHx8fHx8fHwgEUI0iHx8fHwiD0IMhoR8IgVC/////////weDNwOIBSADIAMpA7gEIhEgAykDyAR8IgcgAykDmAR8IgggE0IshnwiCyADKQMIfCISIAUgDlStIA4gEFStIANBIGopAwAgECAKVK0gA0HQAGopAwAgCiAGVK0gBiANVK0gA0HAA2opAwAgDSAEVK0gA0HwA2opAwAgBCAVVK0gA0GQBGopAwAgA0GwBGopAwB8fHx8fHwgDEIUiHx8fHx8fCAPQjSIfHwiBkIMhiAFQjSIhHwiBEL/////////B4M3A5AFIAMgAykD2AQiDCADKQPoBHwiBSAUQiyGfCINIAQgElStIBIgC1StIANBEGopAwAgCyAIVK0gCCAHVK0gA0GgBGopAwAgByARVK0gA0HABGopAwAgA0HQBGopAwB8fHx8IBNCFIh8fHx8IAZCNIh8fCIKQgyGIARCNIiEfCIEQv////////8HgzcDmAUgAyAJQiyGIhAgAykD+AR8IgYgBCANVK0gDSAFVK0gBSAMVK0gA0HgBGopAwAgA0HwBGopAwB8fCAUQhSIfHwgCkI0iHx8IgVCDIYgBEI0iIR8IgRC/////////weDNwOgBSADIAQgBlStIAYgEFStIANBgAVqKQMAIAlCFIh8fCAFQjSIfHxCDIYgBEI0iIQ3A6gFIAAgA0GIBWpBgLzEABCgASADQbAFaiQAC+QQAgF/Hn4jAEGwBWsiAyQAIANB+AFqIAIpAwAiCSABKQMAIgQQngIgA0HoAWogAykD+AEiDEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GIAmogAikDCCINIAQQngIgA0HIAmogASkDCCIGIAkQngIgA0HYAWogBUKBy7XO98X6BhCeAiADQcgBaiADKQPIAiIPIAMpA4gCfCITIAMpA9gBfCIOIAwgAykD6AEiCnwiDEI0iCAMIApUrSADQfABaikDACADQYACaikDAHx8IhFCDIaEfCIHQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYgDaiAGIA0QngIgA0GYAmogAikDECIKIAQQngIgA0HYAmogASkDECIQIAkQngIgA0GYAWogBUL5vdMAEJ4CIANBuAFqIAxCgcu1zvfF+gYQngIgA0GIAWogAykDmAIiFiADKQOIA3wiFCADKQPYAnwiCCADKQOYAXwiCyADKQO4AXwiEiADKQPIASIVIAd8IhdCNIggFyAVVK0gA0HQAWopAwAgByAOVK0gDiATVK0gA0HgAWopAwAgEyAPVK0gA0HQAmopAwAgA0GQAmopAwB8fHx8IBFCNIh8fHx8IhhCDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiE0Ltp9fnpeOYARCeAiADQcgDaiAKIAYQngIgA0GYA2ogECANEJ4CIANBqAJqIAIpAxgiDiAEEJ4CIANB6AJqIAEpAxgiByAJEJ4CIANBqAFqIAxC+b3TABCeAiADQfgAaiATQoHLtc73xfoGEJ4CIANB6ABqIAMpA5gDIh4gAykDyAN8IhEgAykDqAJ8IhUgAykD6AJ8IhcgAykDqAF8IhsgAykDeHwiHCADKQOIASIZIA98IhpCNIggGiAZVK0gA0GQAWopAwAgDyASVK0gEiALVK0gA0HAAWopAwAgCyAIVK0gA0GgAWopAwAgCCAUVK0gA0HgAmopAwAgFCAWVK0gA0GgAmopAwAgA0GQA2opAwB8fHx8fHx8fCAYQjSIfHx8fCIfQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIhRC7afX56XjmAEQngIgA0H4A2ogECAKEJ4CIANB2ANqIA4gBhCeAiADQagDaiAHIA0QngIgA0G4AmogAikDICIIIAQQngIgA0H4AmogASkDICIEIAkQngIgA0E4aiATQvm90wAQngIgA0HYAGogFEKBy7XO98X6BhCeAiADQShqIAMpA9gDIiAgAykD+AN8IhIgBUIshnwiDyADKQOoA3wiFiADKQO4AnwiGCADKQP4AnwiGSADKQM4fCIaIAMpA1h8Ih0gAykDaCIJIAt8IiFCNIggISAJVK0gA0HwAGopAwAgCyAcVK0gHCAbVK0gA0GAAWopAwAgGyAXVK0gA0GwAWopAwAgFyAVVK0gA0HwAmopAwAgFSARVK0gA0GwAmopAwAgESAeVK0gA0GgA2opAwAgA0HQA2opAwB8fHx8fHx8fHx8IB9CNIh8fHx8IhFCDIaEfCILQpv80ZKxtMcCfkL/////////B4MiCULtp9fnpeOYARCeAiADQagEaiAOIBAQngIgA0GIBGogByAKEJ4CIANB6ANqIAggBhCeAiADQbgDaiAEIA0QngIgA0HIAGogFEL5vdMAEJ4CIANBGGogCUKBy7XO98X6BhCeAiADQcgEaiAHIA4QngIgA0G4BGogCCAQEJ4CIANBmARqIAQgChCeAiADQQhqIAlC+b3TABCeAiADQegEaiAIIAcQngIgA0HYBGogBCAOEJ4CIANB+ARqIAQgCBCeAiADIAMpA4gEIhUgAykDqAR8IgQgAykD6AN8Ig0gAykDuAN8IgYgDEIshnwiCiADKQNIfCIQIAMpAxh8Ig4gAykDKCIHIAt8IghCNIggCCAHVK0gA0EwaikDACALIB1UrSAdIBpUrSADQeAAaikDACAaIBlUrSADQUBrKQMAIBkgGFStIANBgANqKQMAIBggFlStIANBwAJqKQMAIBYgD1StIANBsANqKQMAIA8gElStIBIgIFStIANB4ANqKQMAIANBgARqKQMAfHwgBUIUiHx8fHx8fHx8fHx8fCARQjSIfHx8fCIPQgyGhHwiBUL/////////B4M3A4gFIAMgAykDuAQiESADKQPIBHwiByADKQOYBHwiCCATQiyGfCILIAMpAwh8IhIgBSAOVK0gDiAQVK0gA0EgaikDACAQIApUrSADQdAAaikDACAKIAZUrSAGIA1UrSADQcADaikDACANIARUrSADQfADaikDACAEIBVUrSADQZAEaikDACADQbAEaikDAHx8fHx8fCAMQhSIfHx8fHx8IA9CNIh8fCIGQgyGIAVCNIiEfCIEQv////////8HgzcDkAUgAyADKQPYBCIMIAMpA+gEfCIFIBRCLIZ8Ig0gBCASVK0gEiALVK0gA0EQaikDACALIAhUrSAIIAdUrSADQaAEaikDACAHIBFUrSADQcAEaikDACADQdAEaikDAHx8fHwgE0IUiHx8fHwgBkI0iHx8IgpCDIYgBEI0iIR8IgRC/////////weDNwOYBSADIAlCLIYiECADKQP4BHwiBiAEIA1UrSANIAVUrSAFIAxUrSADQeAEaikDACADQfAEaikDAHx8IBRCFIh8fCAKQjSIfHwiBUIMhiAEQjSIhHwiBEL/////////B4M3A6AFIAMgBCAGVK0gBiAQVK0gA0GABWopAwAgCUIUiHx8IAVCNIh8fEIMhiAEQjSIhDcDqAUgACADQYgFakHY7cgAEKEBIANBsAVqJAALphIBDH8jAEGAAmsiAiQAAn8gAC0AHARAIABBDGooAgAhCCACQfABakEEciENIAAoAhghCyAAKAIIIQkDQAJAAkAgByALRg0AIAdBAWohCiAJIQUgCCEGAkADQCACIAU2AvABIAIgBSAGajYC9AEgAkHwAWoQkAEiA0GAgMQARg0BIANBUGpBCkkEQCACIAUgBkEBEP4BIAIoAgQhBiACKAIAIQUMAQsLIAJB6AFqIAkgCCAIIAZrENoCIAJB8AFqIAIoAugBIAIoAuwBELYBIAItAPABQQFHBEAgAkHgAWogBSAGIAIoAvQBIgMQ/gEgAigC5AEhCCACKALgASEJIAJB2AFqIAUgBiADENoCIAIoAtwBIQMgAigC2AEhBCABELMFRSAKIAtHcg0DIAQgA0HoABDdA0UNAyACQdABaiAEIANBARD+ASACIAIoAtABIgU2AvABIAIgBSACKALUAWo2AvQBA0AgAkHwAWoQkAEiBUGAgMQARg0DAkAgBUFQaiIGQQpJDQAgBUGff2pBGk8EQCAFQb9/akEaTw0GIAVBSWohBgwBCyAFQal/aiEGCyAGQRBJDQALDAMLIAIgAi0A8QE6AP8BQaOXygBBKyACQf8BakHQl8oAQeCYygAQqAIAC0H4lsoAQStB0JjKABDOAwALIAEgACgCECAAQRRqKAIAEIgFIAJBgAJqJAAPCwJAIAcEQCABQfCYygBBAhCIBQ0BCyAEIANB8pjKAEECEPsCBEAgAkHIAWogBCADQQEQ/gEgAigCyAEhBCACKALMASEDCwNAIANFBEAgCiEHDAMLIAQgA0EuEN0DRQRAIAQgA0EkEN0DRQRAIAIgBDYC9AEgAkEANgLwASACIAMgBGoiBjYC+AEgBCEFA0ACQCANEJABIgxBgIDEAEYEQCADIQcMAQsgAiACKALwASIHIAYgBWtqIAIoAvQBIgVqIAIoAvgBIgZrNgLwASAMQSRGDQAgDEEuRw0BCwsgAkHAAWogBCADIAcQ2gIgASACKALAASACKALEARCIBQ0DIAJBuAFqIAQgAyAHEP4BIAIoArwBIQMgAigCuAEhBAwCCwJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAIAQgA0H1mMoAQQQQ+wJFBEAgBCADQfqYygBBBBD7Ag0BIAQgA0H/mMoAQQQQ+wINAiAEIANBhJnKAEEEEPsCDQMgBCADQYmZygBBBBD7Ag0EIAQgA0GOmcoAQQQQ+wINBSAEIANBk5nKAEEEEPsCDQYgBCADQZiZygBBAxD7Ag0HIAQgA0GcmcoAQQUQ+wINCCAEIANBopnKAEEFEPsCDQkgBCADQaiZygBBBRD7Ag0KIAQgA0GumcoAQQUQ+wINCyAEIANBtJnKAEEFEPsCDQwgBCADQbqZygBBBRD7Ag0NIAQgA0HAmcoAQQUQ+wINDiAEIANBxpnKAEEFEPsCDQ8gBCADQcyZygBBBRD7Ag0QIAQgA0HSmcoAQQUQ+wINESAEIANB2JnKAEEFEPsCDRIgBCADQd6ZygBBBRD7Ag0TIAohByABIAQgAxCIBUUNFwwWC0EBIAFB+ZjKAEEBEIgFDRgaIAJBGGogBCADQQQQ/gEgAigCHCEDIAIoAhghBAwUC0EBIAFB/pjKAEEBEIgFDRcaIAJBIGogBCADQQQQ/gEgAigCJCEDIAIoAiAhBAwTC0EBIAFBg5nKAEEBEIgFDRYaIAJBKGogBCADQQQQ/gEgAigCLCEDIAIoAighBAwSC0EBIAFBiJnKAEEBEIgFDRUaIAJBMGogBCADQQQQ/gEgAigCNCEDIAIoAjAhBAwRC0EBIAFBjZnKAEEBEIgFDRQaIAJBOGogBCADQQQQ/gEgAigCPCEDIAIoAjghBAwQC0EBIAFBkpnKAEEBEIgFDRMaIAJBQGsgBCADQQQQ/gEgAigCRCEDIAIoAkAhBAwPC0EBIAFBl5nKAEEBEIgFDRIaIAJByABqIAQgA0EEEP4BIAIoAkwhAyACKAJIIQQMDgtBASABQZuZygBBARCIBQ0RGiACQdAAaiAEIANBAxD+ASACKAJUIQMgAigCUCEEDA0LQQEgAUGhmcoAQQEQiAUNEBogAkHYAGogBCADQQUQ/gEgAigCXCEDIAIoAlghBAwMC0EBIAFBp5nKAEEBEIgFDQ8aIAJB4ABqIAQgA0EFEP4BIAIoAmQhAyACKAJgIQQMCwtBASABQa2ZygBBARCIBQ0OGiACQegAaiAEIANBBRD+ASACKAJsIQMgAigCaCEEDAoLQQEgAUGzmcoAQQEQiAUNDRogAkHwAGogBCADQQUQ/gEgAigCdCEDIAIoAnAhBAwJC0EBIAFBuZnKAEEBEIgFDQwaIAJB+ABqIAQgA0EFEP4BIAIoAnwhAyACKAJ4IQQMCAtBASABQb+ZygBBARCIBQ0LGiACQYABaiAEIANBBRD+ASACKAKEASEDIAIoAoABIQQMBwtBASABQcWZygBBARCIBQ0KGiACQYgBaiAEIANBBRD+ASACKAKMASEDIAIoAogBIQQMBgtBASABQcuZygBBARCIBQ0JGiACQZABaiAEIANBBRD+ASACKAKUASEDIAIoApABIQQMBQtBASABQdGZygBBARCIBQ0IGiACQZgBaiAEIANBBRD+ASACKAKcASEDIAIoApgBIQQMBAtBASABQdeZygBBARCIBQ0HGiACQaABaiAEIANBBRD+ASACKAKkASEDIAIoAqABIQQMAwtBASABQd2ZygBBARCIBQ0GGiACQagBaiAEIANBBRD+ASACKAKsASEDIAIoAqgBIQQMAgtBASABQeOZygBBARCIBQ0FGiACQbABaiAEIANBBRD+ASACKAK0ASEDIAIoArABIQQMAQsgAkEQaiAEIANBARD+ASACIAIoAhAiBzYC8AEgAiAHIAIoAhRqNgL0AQJAIAJB8AFqEJABQS5HBEBBASEFIAFB9JjKAEEBEIgFDQMMAQtBAiEFIAFB8JjKAEECEIgFDQILIAJBCGogBCADIAUQ/gEgAigCDCEDIAIoAgghBAwACwALC0EBDAELIAEgACgCACAAKAIEEIgFCyACQYACaiQAC9wOAgt/AX4jAEGQAWsiAyQAIANB0ABqIAEgAkHgl8oAQQYQIAJAIAMoAlBBAUcEQCADQdwAai0AACEGIANBhAFqKAIAIQggAygCVCEHIAMoAoABIQkCQANAAkAgA0EwaiAJIAggBxD+ASADIAMoAjAiBTYCOCADIAUgAygCNGo2AjwgBiIFRSEGIANBOGoQkAEhBCAFDQAgBEGAgMQARg0CAn9BASAEQYABSQ0AGkECIARBgBBJDQAaQQNBBCAEQYCABEkbCyAHaiEHDAELCyADQcgAaiAHNgIAIAMgBzYCVCADIAY6AFwgAyAHNgJEIANBATYCQAwCCyADIAc2AlQgAyAGOgBcIANBADYCQAwBCyADQdgAaiEFIANBjAFqKAIAIQYgA0GEAWooAgAhBCADKAKIASEIIAMoAoABIQcgA0H0AGooAgBBf0YEQCADQUBrIAUgByAEIAggBkEBEFQMAQsgA0FAayAFIAcgBCAIIAZBABBUCwJAIAMoAkBBAUcNACADQShqIAEgAiADKAJEIgZBBmoQ/gEgAyADKAIoIgUgAygCLGo2AlQgAyAFNgJQA0AgA0HQAGoQkAEiBUGAgMQARwRAIAVBwABGIAVBv39qQQZJciAFQVBqQQpJcg0BDAILCyADQSBqIAEgAiAGENoCIAMoAiQhAiADKAIgIQELIANB0ABqIAEgAkHml8oAQQIQIAJAIAMoAlBBAUcEQCADQYQBaigCACELIANB2ABqKAIAIQcgA0HdAGotAAAhBiADKAKAASEMAkADQCADIAYiBUUiBjoAXSADQRhqIAwgCyAHENoCQYCAxAAhBAJAIAMoAhwiCUUNACAJIAMoAhgiCGoiCUF/aiIKLQAAIgRBGHRBGHUiDUEATg0AIA1BP3ECf0EAIAggCkYNABogCUF+aiIKLQAAIgRBwAFxQYABRwRAIARBH3EMAQsgBEE/cQJ/QQAgCCAKRg0AGiAJQX1qIgotAAAiBEHAAXFBgAFHBEAgBEEPcQwBCyAIIApGBH9BAAUgCUF8ai0AAEEHcUEGdAsgBEE/cXILQQZ0cgtBBnRyIQQLIAVFBEAgBEGAgMQARg0CIAMgBwJ/QQEgBEGAAUkNABpBAiAEQYAQSQ0AGkEDQQQgBEGAgARJGwtrIgc2AlgMAQsLIANByABqIAc2AgAgAyAHNgJEIANBATYCQAwCCyADQQA2AkAMAQsgA0HYAGohBSADQYwBaigCACEGIANBhAFqKAIAIQQgAygCiAEhCCADKAKAASEHIANB9ABqKAIAQX9GBEAgA0FAayAFIAcgBCAIIAZBARBMDAELIANBQGsgBSAHIAQgCCAGQQAQTAsgAwJ/AkACQAJAIAMoAkBBAUYEQCADKAJEIgZBAWoiBSAGSSACIAVGckUEQCACIAVNDQMgASAFaiwAAEG/f0wNAwsgAyABIAJqNgJUIAMgASAFaiIMNgJQIAIgBWshCgNAIANB0ABqEJABIgZBgIDEAEYEQCAFIQIMAwsgBkFfakEPSSAGQVBqQQpJciAGQd///wBxQb9/akEaSSAGQUZqQQdJcnIgBkGlf2pBBkkgBkGFf2pBBElycg0ACwtB5pfKACEMQQAhCgsCQCACQQRLBEAgASACQeiXygBBAxD7AkUNASABIAIQ3gNFDQEgAyABIAJBAyACQX9qEMsBQQEhBCADKAIEIQUgAygCAAwEC0EAIQQgAiEFIAEgAkEERw0DGgsgASACQeuXygBBAhD7AkUNASABIAIQ3gNFDQEgA0EIaiABIAJBAiACQX9qEMsBQQEhBCADKAIMIQUgAygCCAwCCyABIAJBACAFECkAC0EAIQQCQCACQQVNDQAgASACQe2XygBBBBD7AkUNACACIQUgASABIAIQ3gNFDQEaIANBEGogASACQQQgAkF/ahDLAUEBIQQgAygCFCEFIAMoAhAMAQsgAiEFIAELIgs2AlAgAyAFIAtqIgY2AlQgA0HQAGoQxQMhCEEAIQ0CQCAERQRAQQAhCQwBC0EAIQkgCA0AIANBgYDEADYCWCADIAY2AlQgAyALNgJQQQEhBANAIARBAXFFDQFBACEEAkACQAJAA0AgBCEIIAMoAlgiBEGBgMQARgRAIAMgA0HQAGoQkAEiBDYCWAtBASEGIARBgIDEAEYNASAEQVBqIgRBCUsNASADQdAAahDsBBogCK1CCn4iDkIgiKcEQEEAIQYMAwsgDqciBiAEaiIEIAZPDQALQQAhBgsgCEUNAQsgAyAINgJEIAhBf2ohBCADIANB0ABqNgJAQQAhBwNAIANBQGsQgAFBgIDEAEcEQCAHQQFqIQcgAyAENgJEIARBf2oiBEF/Rw0BCwsgCSAHIAhGIgRqIQkgBCAGcSEEDAELCyADQdAAahDsBEGAgMQARiENCyAAIA06ABwgACAMNgIQIAAgCzYCCCAAIAI2AgQgACABNgIAIAAgCTYCGCAAQRRqIAo2AgAgAEEMaiAFNgIAIANBkAFqJAALiA8BCX8jAEGQEWsiBSQAIAUgBDYCvAEgBSADNgK4ASAFQbABaiAFQbgBakEHEKYFIAVBtAtqQQE2AgAgBUIBNwKkCyAFQcD6wQA2AqALIAUgBSkDsAE3A/AGIAUgBUHwBmo2ArALIAVBwAFqIAVBoAtqEGYgBUGgC2ogASACEKwBIAVB0AFqIAVBoAtqQcj6wQAQ6wIgBUHoAWpBAEHAABDBBBogBUGoAWogBUHQAWoQsAQgBSgCqAEhASAFKAKsASECIAVBoAFqIAVBwAFqEJsFIAUoAqQBIQsgBSgCoAEhDCAFQagCahCyAyAFQdAPahDaASAFQfAGahCyAyAFQaALaiAFQagCakHYARDyAxogBUHQDmogBUHQD2pBgAEQ8gMhAyAFQfgMaiAFQfAGakHYARDyAyAFQdAPahDZASAFQZgBaiADEKoFAkACQAJAAkACQCAFKAKcASACSQRAIAVBqAJqELIDIAVBqAJqIAEgAhDRBSAFQfAGaiAFQagCakHYARDyAxogBUHQEGogBUHwBmoQ7gMgBUGAAWogBUHQEGoQqQUgBSgChAEhASAFQfgAaiADEKoFIAVB8ABqQQAgBSgCfCICIAEgASACSxsQpgUgBSAFKQNwNwPwBgNAIAVB6ABqIAVB8AZqELkDIAUoAmhFDQYgBSgCbCEBIAVB4ABqIAVB0BBqEKkFIAEgBSgCZCICTw0CIAUoAmAgAWotAAAhAiAFQdgAaiADEKoFIAEgBSgCXCIGTw0DIAUoAlggAWoiBiAGLQAAIAJzOgAAIAVB0ABqIAVB0BBqEKkFIAEgBSgCVCICTw0EIAUoAlAgAWotAAAhAiAFQcgAaiAFQdAPahCqBSABIAUoAkwiBk8NBSAFKAJIIAFqIgEgAS0AACACczoAAAwACwALIAVB8AZqIAEgASACahCLBSAFQagCaiAFQfAGahD5BCAFKAKwAiEBIAUoAqwCIQYgBSgCqAIhAgJAA0AgAiAGRg0GIAItAAAhCCAFQZABaiADEKoFIAEgBSgClAEiB0kEQCAFKAKQASABaiIHIActAAAgCHM6AAAgAi0AACEIIAVBiAFqIAVB0A9qEKoFIAEgBSgCjAEiB08NAiACQQFqIQIgBSgCiAEgAWoiByAHLQAAIAhzOgAAIAFBAWohAQwBCwtBwPjBACABIAcQ5AIAC0HQ+MEAIAEgBxDkAgALQeD4wQAgASACEOQCAAtB8PjBACABIAYQ5AIAC0GA+cEAIAEgAhDkAgALQZD5wQAgASAGEOQCAAsgBUGgC2ogAxCxBCAFQdAPahCxBCAFQagCaiAFQaALakGwBBDyAxogBULAgICAgAg3AvQGIAUgBUHoAWo2AvAGIAVBoAtqIAVB8AZqEOsEIAVB2AZqIAVBoAtqEPgEIAVBqAtqIQcgBUHYD2ohCCAFKALkBiEEIAUoAuAGIQogBSgC3AYhBiAFKALYBiECA0ACQCAGRSACRXJFBEAgBEEBaiEEIAYgCiAGIAYgCksbIgFrIQYgBUFAayACIAEgAmoiAxCmBSAFKAJEIQkgBSgCQCEBA0AgASAJRgRAIAVB8AZqIAVBqAJqEIIDIAVB8AZqIAwgCxDRBSAFIARBCHRBgID8B3EgBEEYdHIgBEEIdkGA/gNxIARBGHZycjYC6AYgBUHwBmogBUHoBmpBBBDRBSAFQaALaiAFQfAGakGwBBDyAxogBUHQD2ogBUGgC2oQvgIgBUGgC2ogBUHQD2oQuQUgBUE4aiAFQaALahCpBSAFQTBqIAUoAjgiASABIAUoAjxqEKYFIAVB0BBqIAIgAyAFKAIwIAUoAjQQywMgBUHgD2oiDSAFQeAQaikDADcDACAIIAVB2BBqKQMANwMAIAUgBSkD0BA3A9APA0AgBSgC4A8iASAFKALkD08EQCAFQdAQaiAFQaALakHAABDyAxogBUEoakEBQYAQEKYFIAUgBSkDKDcD6AYDQCAFQSBqIAVB6AZqELkDIAUoAiBFDQYgBUHwBmogBUGoAmoQggMgBUEYaiAFQdAQahCpBSAFQfAGaiAFKAIYIAUoAhwQ0QUgBUGgC2ogBUHwBmpBsAQQ8gMaIAVB0A9qIAVBoAtqEL4CIAVBoAtqIAVB0A9qELkFIAVB0BBqIAVBoAtqQcAAEPIDGiAFQRBqIAVB0BBqEKkFIAVBCGogBSgCECIBIAEgBSgCFGoQpgUgBUHQD2ogAiADIAUoAgggBSgCDBDLAyAFQbALaiANKQMANwMAIAcgCCkDADcDACAFIAUpA9APNwOgCwNAIAUoArALIgEgBSgCtAtPBEAMAgUgBSABQQFqNgKwCyAFQaALaiABEMwFIQkgByABEMwFIQEgCSAJLQAAIAEtAABzOgAADAELAAsACwAFIAUgAUEBajYC4A8gBUHQD2ogARDMBSEJIAggARDMBSEBIAkgCS0AACABLQAAczoAAAwBCwALAAUgAUEAOgAAIAFBAWohAQwBCwALAAsgACAFQegBakEgEJwDIAVB0AFqEKMFIAVBwAFqEIEFIAVBkBFqJAAPCyADIQIMAAsAC60NAQl/IwBBwBBrIgYkACAGQZgBakEAQcAAEMEEGiAGQdgBahCyAyAGQYAPahDaASAGQaAGahCyAyAGQdAKaiAGQdgBakHYARDyAxogBkGADmogBkGAD2pBgAEQ8gMhCSAGQagMaiAGQaAGakHYARDyAyAGQYAPahDZASAGQZABaiAJEKoFAkACQAJAAkACQCAGKAKUASACSQRAIAZB2AFqELIDIAZB2AFqIAEgAhDRBSAGQaAGaiAGQdgBakHYARDyAxogBkGAEGogBkGgBmoQ7gMgBkH4AGogBkGAEGoQqQUgBigCfCEBIAZB8ABqIAkQqgUgBkHoAGpBACAGKAJ0IgIgASABIAJLGxCmBSAGIAYpA2g3A6AGA0AgBkHgAGogBkGgBmoQuQMgBigCYEUNBiAGKAJkIQEgBkHYAGogBkGAEGoQqQUgASAGKAJcIgJPDQIgBigCWCABai0AACECIAZB0ABqIAkQqgUgASAGKAJUIgdPDQMgBigCUCABaiIHIActAAAgAnM6AAAgBkHIAGogBkGAEGoQqQUgASAGKAJMIgJPDQQgBigCSCABai0AACECIAZBQGsgBkGAD2oQqgUgASAGKAJEIgdPDQUgBigCQCABaiIBIAEtAAAgAnM6AAAMAAsACyAGQaAGaiABIAEgAmoQiwUgBkHYAWogBkGgBmoQ+QQgBigC4AEhAiAGKALcASEHIAYoAtgBIQECQANAIAEgB0YNBiABLQAAIQsgBkGIAWogCRCqBSACIAYoAowBIghJBEAgBigCiAEgAmoiCCAILQAAIAtzOgAAIAEtAAAhCyAGQYABaiAGQYAPahCqBSACIAYoAoQBIghPDQIgAUEBaiEBIAYoAoABIAJqIgggCC0AACALczoAACACQQFqIQIMAQsLQfyEwAAgAiAIEOQCAAtBjIXAACACIAgQ5AIAC0GchcAAIAEgAhDkAgALQayFwAAgASAHEOQCAAtBvIXAACABIAIQ5AIAC0HMhcAAIAEgBxDkAgALIAZB0ApqIAkQsQQgBkGAD2oQsQQgBkHYAWogBkHQCmpBsAQQ8gMaIAZCwICAgIAINwKkBiAGIAZBmAFqNgKgBiAGQdAKaiAGQaAGahDrBCAGQYgGaiAGQdAKahD4BCAGQdgKaiEIIAZBiA9qIQsgBigClAYhCiAGKAKQBiENIAYoAowGIQcgBigCiAYhAQNAAkAgB0UgAUVyRQRAIApBAWohCiAHIA0gByAHIA1LGyICayEHIAZBOGogASABIAJqIgkQpgUgBigCPCEMIAYoAjghAgNAIAIgDEYEQCAGQaAGaiAGQdgBahCCAyAGQaAGaiADIAQQ0QUgBiAKQQh0QYCA/AdxIApBGHRyIApBCHZBgP4DcSAKQRh2cnI2ApgGIAZBoAZqIAZBmAZqQQQQ0QUgBkHQCmogBkGgBmpBsAQQ8gMaIAZBgA9qIAZB0ApqEL4CIAZB0ApqIAZBgA9qELkFIAZBMGogBkHQCmoQqQUgBkEoaiAGKAIwIgIgAiAGKAI0ahCmBSAGQYAQaiABIAkgBigCKCAGKAIsEMsDIAZBkA9qIg4gBkGQEGopAwA3AwAgCyAGQYgQaikDADcDACAGIAYpA4AQNwOADwNAIAYoApAPIgIgBigClA9PBEAgBkGAEGogBkHQCmpBwAAQ8gMaIAZBIGpBASAFEKYFIAYgBikDIDcDmAYDQCAGQRhqIAZBmAZqELkDIAYoAhhFDQYgBkGgBmogBkHYAWoQggMgBkEQaiAGQYAQahCpBSAGQaAGaiAGKAIQIAYoAhQQ0QUgBkHQCmogBkGgBmpBsAQQ8gMaIAZBgA9qIAZB0ApqEL4CIAZB0ApqIAZBgA9qELkFIAZBgBBqIAZB0ApqQcAAEPIDGiAGQQhqIAZBgBBqEKkFIAYgBigCCCICIAIgBigCDGoQpgUgBkGAD2ogASAJIAYoAgAgBigCBBDLAyAGQeAKaiAOKQMANwMAIAggCykDADcDACAGIAYpA4APNwPQCgNAIAYoAuAKIgIgBigC5ApPBEAMAgUgBiACQQFqNgLgCiAGQdAKaiACEMwFIQwgCCACEMwFIQIgDCAMLQAAIAItAABzOgAADAELAAsACwAFIAYgAkEBajYCkA8gBkGAD2ogAhDMBSEMIAsgAhDMBSECIAwgDC0AACACLQAAczoAAAwBCwALAAUgAkEAOgAAIAJBAWohAgwBCwALAAsgACAGQZgBakHAABCcAyAGQcAQaiQADwsgCSEBDAALAAvHCwINfwJ+IwBBMGsiBiQAAkACQAJAAkAgAUEdai0AACIEIAFBHmotAAAiC0sgBEEDRnIgC0EDRnINACABQQhqIQwgAUEdaiEJAkACQAJAAkADQAJAAkACQAJAAkACQAJAIARBAWsOAwIDAAELQbCdygBBKEHoocoAELwEAAsgDC0AACIHQQZGBEBBASEEIAlBAToAAAwECwJAAn8CQAJAAkACQAJAQQAgDCAHQQZGGyIDLQAAIghBAWsOBQADAgEDBAsgAygCCCADKAIQIgRBAWpBACAEG2pBCGoMBAsgAygCCCADKAIQIgRBAWpBACAEG2pBAmoMAwsgAygCCEEEagwCCyABQR1qQQE6AAAMAgsgAygCCEEEagtBASEEIAlBAToAAEUNBAsgASgCBCEFIAEoAgAhCUECIQQCQAJAAkACQAJAAkAgCEEBaw4FAQIEAwUACyADKAIIQQRqIQQMBAsgAygCCCADKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAygCCCADKAIQIgRBAWpBACAEG2pBAmohBAwBCyADKAIIQQRqIQQLIAUgBEkNBEECIQICQAJAAkACQAJAAkAgCEEBaw4FAQIEAwUACyADKAIIQQRqIQIMBAsgAygCCCADKAIQIgJBAWpBACACG2pBCGohAgwDC0EGIQIMAgsgAygCCCADKAIQIgJBAWpBACACG2pBAmohAgwBCyADKAIIQQRqIQILIAUgAkkNBiABIAUgAms2AgQgASACIAlqNgIAIAZBJ2oiAiABQRhqKAAANgAAIAZBIGoiAyABQRFqKQAANwMAIAZBD2oiBSACKAAANgAAIAZBCGoiAiADKQMANwMAIAYgAUEJaikAACIPNwMAIABBDGogBzoAACAAQQhqIAQ2AgAgACAJNgIEIABBADYCACAAIA83AA0gAEEVaiACKQMANwAAIABBHGogBSgAADYAAAwNCyAJQQI6AAACQAJAIAEtABxFBEAgAS0ACCIEQQZHDQJBAiEEIAEoAgQiAkUNBSABKAIAIgMtAAAhBSADQQFqIgggAyACGyIHIAIgA2oiA0YgBUEuR3INASAHLQAAQS9HDQUMDgsgASgCBCIERQ0IIABBATYCACABIARBf2o2AgQgASABKAIAQQFqNgIADA4LIAMgB0cNAyAFQS5GDQwMAwsgBEEDakEHcSICQQZJDQEMCgsgASgCBCIDBEAgASgCACEHQQAhCEEAIQUCQANAIAMgBUYEQCADIQIMAgsgBSAHaiAFQQFqIQUtAAAiCkEvRw0AC0EBIQggAyAKQS9GQQFqQQFxIAVqQX9qIgJJDQgLIAIgCGohCEEEIQUCQCACQQJLDQACQAJAAkAgAkEBaw4CAAECCyAHQdChygBHBEAgBy0AAEEuRw0DC0ECQQVBAiABLQAIIgVBA0kgBUEGRhsiBUEBcRtBBSAFQQJHGyEFDAILIAdB46HKAEcEQCAHLwAAQa7cAEcNAgtBAyEFDAELQQUhBQsgBkEQaiAGQShqIgooAgAiDTYCACAGQQhqIAZBIGoiDikCACIPNwMAIAYgBikCGCIQNwMAIAogDTYCACAOIA83AwAgBiAQNwMYIAMgCEkNCCABIAMgCGs2AgQgASAHIAhqNgIAIAVBBUYNAiAAIAc2AgQgACAFNgIAIABBCGogAjYCACAAQQxqIAYpAxg3AgAgAEEUaiAGQSBqKQMANwIAIABBHGogBkEoaigCADYCAAwMCyABQR1qQQM6AAAMCAtBAiEEQTkgAnZBAXFFDQgLIAQiAiALSw0GIAJBA0cNAQwGCwsgBCAFEOUCAAsgAiAFEOYCAAtBAUEAEOYCAAsgCkEvRkEBakEBcSAFakF/aiADEOUCAAsgCCADEOYCAAsgAEEFNgIADAILIABBATYCAAwBCyABIAg2AgAgAEECNgIAIAEgAkF/ajYCBAsgBkEwaiQAC9ELAgR/An4jAEGQCGsiBiQAAn8CfwJAIAFBwABGBEAgBkHYBWpCADcDACAGQdAFakIANwMAIAZByAVqQgA3AwAgBkIANwPABSAGQegCakIANwMAIAZB4AJqIgdCADcDACAGQdgCaiIIQgA3AwAgBkIANwPQAiAGQcAFakEgIABBIBCuASAGQdACakEgIABBIGpBIBCuASAGQb8EaiIAIAZB5wJqKQAANwAAIAZBuARqIgEgBykDADcDACAGQbAEaiIHIAgpAwA3AwAgBiAGKQPQAjcDqAQgBi0A7wIiCEEQSQ0BIAZBxwJqIAApAAA3AAAgBkHAAmogASkDADcDACAGQbgCaiAHKQMANwMAIAYgBikDqAQ3A7ACIAYgCDoAzwIgBkHoAGogBkGwAmoQzQEgBi0AaEEBRgRAIAZBrgJqIAYtAGs6AAAgBiAGLwBpOwGsAiAGIAZB/ABqKQIANwOIBCAGIAZBgQFqKQAANwCNBCAGQfQAaigCACEBIAZB+ABqKAIAIQAgBigCbCEHIAZB8ABqKAIADAMLIAZB4ABqIAZBkARqKQIANwMAIAYgBikCiAQ3A1gLQQAMAgsgBkH/AGogACkAADcAACAGQfgAaiABKQMANwMAIAZB8ABqIAcpAwA3AwAgBiAGKQOoBDcDaCAGIAg6AIcBIAZB2AZqIAZB6ABqELsDIAZBrgJqIAYtANoGOgAAIAYgBi8B2AY7AawCIAYgBikA6wY3A4gEIAYgBkHwBmopAAA3AI0EIAYoANsGIQcgBigA4wYhASAGKADnBiEAIAYoAN8GCyEIIAZBqgJqIgkgBkGuAmotAAA6AAAgBiAGLwGsAjsBqAIgBiAGKQOIBDcDSCAGIAYpAI0ENwBNIAYgBi8BwAU7AQggBiAGLQDCBToACiAGKQDDBSEKIAYpAMsFIQsgBiAGQdgFaikAADcAbSAGIAYpANMFNwNoIAZB9wBqIAktAAA6AAAgBiAGLwGoAjsAdSAGQeAAaiIJIAZB8ABqKQMANwMAIAYgBikDaDcDWCAGIAs3ABMgBiAKNwALIAZBI2ogCSkDADcAACAGIAYpA1g3ABsgBkE3aiAANgAAIAZBM2ogATYAACAGQS9qIAg2AAAgBkEraiAHNgAAIAZBQGsgBikATTcAACAGQTtqIAYpA0g3AAACQCAFQSBGBEAgBkHIAmoiAEIANwMAIAZBwAJqIgFCADcDACAGQbgCaiIFQgA3AwAgBkIANwOwAiAGQbACakEgIARBIBCuASAGQaAEaiAAKQMANwMAIAZBmARqIgAgASkDADcDACAGQZAEaiAFKQMANwMAIAYgBikDsAI3A4gEIAZB6ABqIAZBiARqEGwgBikDaEIBUQ0BIAZB6AZqIgAgBkHgAmoiASkCADcDACAGQeAGaiAGQdgCaiICKQIANwMAIAYgBikC0AI3A9gGIAZBwAVqIAZB2AZqQZQBEPIDGiAGQfgAaiAGKQLABTcDACAGQYABaiAGQcgFaikCADcDACAGQYgBaiAGQdAFaikCADcDACAGQQA2AmggBkHYBmogBkHoAGpBKBDyAxogAiAGQfAGaikDADcDACABIAZB+AZqKQMANwMAIAYgACkDADcD0AILQdD8wQBBH0Hw/MEAELQEAAsgBkH4AGooAgAhASAGKQNwIQogBkHYBmogBkH8AGpBlAEQ8gMaIAZBwAVqIAZB2AZqQZQBEPIDGiAGQagEaiAGQcAFakGUARDyAxogBkHYBmogBkGoBGpBlAEQ8gMaIAZBhAhqIAZBoARqKQMANwIAIAZB/AdqIAApAwA3AgAgBkH0B2ogBkGQBGopAwA3AgAgBiAGKQOIBDcC7AcgBkHQAmogBkHYBmpBtAEQ8gMaIAYgATYCcCAGIAo3A2ggBkH0AGogBkHQAmpBtAEQ8gMaIAZB2AZqIAZB6ABqIAIgAyAGQQhqELwBIAYoAtgGQQVGCyAGQZAIaiQAC6AJAgF/D34jAEGQA2siAyQAIANBEGogASkDACIEIAIpAwgiBhCeAiADQaABaiABKQMgIgcgAikDECILQhN+IhAQngIgA0HgAWogASkDGCIIIAIpAxgiDUITfiIOEJ4CIANBoAJqIAEpAxAiBSACKQMgIg9CE34iDBCeAiADQdAAaiABKQMIIgkgAikDACIKEJ4CIAMgCiAEEJ4CIANBkAFqIAcgBkITfhCeAiADQdABaiAIIBAQngIgA0GQAmogBSAOEJ4CIANB0AJqIAkgDBCeAiADQSBqIAQgCxCeAiADQbABaiAHIA4QngIgA0HwAWogCCAMEJ4CIANB4ABqIAUgChCeAiADQeACaiAJIAYQngIgA0EwaiAEIA0QngIgA0HAAWogByAMEJ4CIANB8ABqIAggChCeAiADQbACaiAFIAYQngIgA0HwAmogCSALEJ4CIANBQGsgBCAPEJ4CIANBgAFqIAcgChCeAiADQYACaiAIIAYQngIgA0HAAmogBSALEJ4CIANBgANqIAkgDRCeAiAAIAMpA7ABIg8gAykDIHwiBCADKQPwAXwiBiADKQNgfCIHIAMpA+ACfCIIIAMpA6ABIhEgAykDEHwiBSADKQPgAXwiCSADKQOgAnwiCiADKQNQfCILIAMpA5ABIhIgAykDAHwiDCADKQPQAXwiDSADKQOQAnwiDiADKQPQAnwiEEIziCAQIA5UrSADQdgCaikDACAOIA1UrSADQZgCaikDACANIAxUrSADQdgBaikDACAMIBJUrSADQZgBaikDACADQQhqKQMAfHx8fHx8fHxCDYaEfCIMQjOIIAwgC1StIAsgClStIANB2ABqKQMAIAogCVStIANBqAJqKQMAIAkgBVStIANB6AFqKQMAIAUgEVStIANBqAFqKQMAIANBGGopAwB8fHx8fHx8fHxCDYaEfCIFQv////////8DgzcDECAAIAMpA8ABIg4gAykDMHwiCSADKQNwfCIKIAMpA7ACfCILIAMpA/ACfCINIAUgCFStIAggB1StIANB6AJqKQMAIAcgBlStIANB6ABqKQMAIAYgBFStIANB+AFqKQMAIAQgD1StIANBuAFqKQMAIANBKGopAwB8fHx8fHx8fHxCDYYgBUIziIR8IgRC/////////wODNwMYIAAgAykDgAEiDyADKQNAfCIGIAMpA4ACfCIHIAMpA8ACfCIIIAMpA4ADfCIFIAQgDVStIA0gC1StIANB+AJqKQMAIAsgClStIANBuAJqKQMAIAogCVStIANB+ABqKQMAIAkgDlStIANByAFqKQMAIANBOGopAwB8fHx8fHx8fHxCDYYgBEIziIR8IgRC/////////wODNwMgIAAgBCAFVK0gBSAIVK0gA0GIA2opAwAgCCAHVK0gA0HIAmopAwAgByAGVK0gA0GIAmopAwAgBiAPVK0gA0GIAWopAwAgA0HIAGopAwB8fHx8fHx8fHxCDYYgBEIziIRCE34gEEL/////////A4N8IgRC/////////wODNwMAIAAgDEL/////////A4MgBEIziHw3AwggA0GQA2okAAugCwEJfyMAQYAQayIFJAAgBUGYAWpBwAAQtQIgBUGQAWogBUGYAWoQmwUgBSgClAEhCyAFKAKQASEJIAVBqAFqELIDIAVBwA5qENoBIAVB4AVqELIDIAVBkApqIAVBqAFqQdgBEPIDGiAFQcANaiAFQcAOakGAARDyAyEHIAVB6AtqIAVB4AVqQdgBEPIDIAVBwA5qENkBIAVBiAFqIAcQqgUCQAJAAkACQAJAIAUoAowBIAJJBEAgBUGoAWoQsgMgBUGoAWogASACENEFIAVB4AVqIAVBqAFqQdgBEPIDGiAFQcAPaiAFQeAFahDuAyAFQfAAaiAFQcAPahCpBSAFKAJ0IQEgBUHoAGogBxCqBSAFQeAAakEAIAUoAmwiAiABIAEgAksbEKYFIAUgBSkDYDcD4AUDQCAFQdgAaiAFQeAFahC5AyAFKAJYRQ0GIAUoAlwhASAFQdAAaiAFQcAPahCpBSABIAUoAlQiAk8NAiAFKAJQIAFqLQAAIQIgBUHIAGogBxCqBSABIAUoAkwiBk8NAyAFKAJIIAFqIgYgBi0AACACczoAACAFQUBrIAVBwA9qEKkFIAEgBSgCRCICTw0EIAUoAkAgAWotAAAhAiAFQThqIAVBwA5qEKoFIAEgBSgCPCIGTw0FIAUoAjggAWoiASABLQAAIAJzOgAADAALAAsCQANAIAIgBkYNBiABIAZqIgotAAAhCCAFQYABaiAHEKoFIAYgBSgChAEiDUkEQCAFKAKAASAGaiINIA0tAAAgCHM6AAAgCi0AACEKIAVB+ABqIAVBwA5qEKoFIAYgBSgCfCIITw0CIAUoAnggBmoiCCAILQAAIApzOgAAIAZBAWohBgwBCwtB3PLIACAGIA0Q5AIAC0Hs8sgAIAYgCBDkAgALQfzyyAAgASACEOQCAAtBjPPIACABIAYQ5AIAC0Gc88gAIAEgAhDkAgALQazzyAAgASAGEOQCAAsgBUGQCmogBxCxBCAFQcAOahCxBCAFQagBaiAFQZAKakGwBBDyAxpBACECA0ACQCALRSAJRXJFBEAgAkEBaiECIAsgC0HAACALQcAASRsiBmshCyAGIAlqIQEgCSEHA0AgBgRAIAdBADoAACAGQX9qIQYgB0EBaiEHDAEFAkAgBUHgBWogBUGoAWoQhAMgBUHgBWogAyAEENEFIAUgAkEIdEGAgPwHcSACQRh0ciACQQh2QYD+A3EgAkEYdnJyNgLYBSAFQeAFaiAFQdgFakEEENEFIAVBkApqIAVB4AVqQbAEEPIDGiAFQcAOaiAFQZAKahCAAyAFQZAKaiAFQcAOakHAABDyAxogBUEwaiAFQZAKahCpBSAFQShqIAUoAjAiByAHIAUoAjRqEKYFIAUoAiwgBSgCKCIMayIGIAEgCWsiByAHIAZLGyEKQQAhBgNAIAYgCk8NASAGIAlqIgggCC0AACAGIAxqLQAAczoAACAGQQFqIQYMAAsACwsLIAVBwA9qIAVBkApqQcAAEPIDGiAFQSBqQQFBgBAQpgUgBSAFKQMgNwPYBQNAIAVBGGogBUHYBWoQuQMgBSgCGEUNAiAFQeAFaiAFQagBahCEAyAFQRBqIAVBwA9qEKkFIAVB4AVqIAUoAhAgBSgCFBDRBSAFQZAKaiAFQeAFakGwBBDyAxogBUHADmogBUGQCmoQgAMgBUHAD2ogBUHADmpBwAAQ8gMaIAVBCGogBUHAD2oQqQUgBSAFKAIIIgYgBiAFKAIMahCmBSAFKAIEIAUoAgAiDGsiBiAHIAcgBksbIQpBACEGA0AgBiAKTw0BIAYgCWoiCCAILQAAIAYgDGotAABzOgAAIAZBAWohBgwACwALAAsgACAFKQOYATcCACAAQQhqIAVBoAFqKAIANgIAIAVBgBBqJAAPCyABIQkMAAsAC/QJAgp/AX4CQAJAAkACfwJAAkACQCAEQQFNBEAgBCENIAQhCCAEQQFrDQIMAQtBASEFQQEhBkEBIQ0DQCAGIQkCQCAHIApqIgggBEkEQCADIAVqLQAAIgYgAyAIai0AACIFTwRAIAUgBkcEQEEBIQ0gCUEBaiEGQQAhByAJIQoMAwtBACAHQQFqIgYgBiANRiIFGyEHIAZBACAFGyAJaiEGDAILIAcgCWpBAWoiBiAKayENQQAhBwwBC0GgsMoAIAggBBDkAgALIAYgB2oiBSAESQ0AC0EBIQVBASEGQQAhB0EBIQgDQCAGIQkCQCAHIAtqIgwgBEkEQCADIAVqLQAAIgYgAyAMai0AACIFTQRAIAUgBkcEQEEBIQggCUEBaiEGQQAhByAJIQsMAwtBACAHQQFqIgYgBiAIRiIFGyEHIAZBACAFGyAJaiEGDAILIAcgCWpBAWoiBiALayEIQQAhBwwBC0GgsMoAIAwgBBDkAgALIAYgB2oiBSAESQ0ACwsCQAJAIAogCyAKIAtLIgUbIgsgBE0EQCANIAggBRsiBiALaiIFIAZJDQEgBSAESw0CIAZFDQQgAyADIAZqIAsQtANFDQQgCyAEIAtrIgUgCyAFSxsgBCEGIAMhBwNAQgEgBzEAAEI/g4YgD4QhDyAHQQFqIQcgBkF/aiIGDQALQQFqIQZBfyEIIAshBUF/DAULIAsgBBDlAgALIAYgBRDmAgALIAUgBBDlAgALIAAgAzYCOCAAIAE2AjAgAEIANwMAIABBPGpBADYCACAAQTRqIAI2AgAgAEEMakGBAjsBACAAQQhqIAI2AgAPC0EBIQpBACEHQQEhBUEAIQ0DQCAFIgkgB2oiDCAESQRAIAQgB2sgCUF/c2oiCCAETw0FIAdBf3MgBGogDWsiBSAETw0EAkACQCADIAhqLQAAIgggAyAFai0AACIFTwRAIAUgCEYNASAJQQFqIQVBACEHQQEhCiAJIQ0MAgsgDEEBaiIFIA1rIQpBACEHDAELQQAgB0EBaiIIIAggCkYiBRshByAIQQAgBRsgCWohBQsgBiAKRw0BCwtBASEKQQAhB0EBIQVBACEIAkACQAJAAkADQCAFIgkgB2oiDiAESQRAIAQgB2sgCUF/c2oiDCAETw0CIAdBf3MgBGogCGsiBSAETw0DAkACQCADIAxqLQAAIgwgAyAFai0AACIFTQRAIAUgDEYNASAJQQFqIQVBACEHQQEhCiAJIQgMAgsgDkEBaiIFIAhrIQpBACEHDAELQQAgB0EBaiIMIAogDEYiBRshByAMQQAgBRsgCWohBQsgBiAKRw0BCwsgBiAESw0FIAQgDSAIIA0gCEsbayEFIAYNAkEAIQZBACEIDAMLQbCwygAgDCAEEOQCAAtBwLDKACAFIAQQ5AIAC0EAIQhBACEHA0BCASADIAdqMQAAQj+DhiAPhCEPIAYgB0EBaiIHRw0ACwsgBAshCSAAIAM2AjggACABNgIwIABBATYCACAAQTxqIAQ2AgAgAEE0aiACNgIAIABBKGogCTYCACAAQSRqIAg2AgAgAEEgaiACNgIAIABBHGpBADYCACAAQRhqIAY2AgAgAEEUaiAFNgIAIABBEGogCzYCACAAQQhqIA83AgAPCyAGIAQQ5QIAC0HAsMoAIAUgBBDkAgALQbCwygAgCCAEEOQCAAuUCAEJfwJAAkACQAJAAkACQCABKAIEIgIEQCABKAIAIQcCQAJAAkACQAJAAkADQAJ/IANBAWoiBiADIAdqIgotAAAiCEEYdEEYdSIJQX9KDQAaAkACQAJAIAhBsrHKAGotAABBfmoiBUECTQRAIAVBAWsOAgIDAQsgAiADSQ0JIAIgA00NCiAAIAM2AgQgACAHNgIAIAEgAiAGazYCBCABIAYgB2o2AgAMDwsgA0ECaiAGIAdqIgVBACACIAZLGyIEQcWqygAgBBstAABBwAFxQYABRg0CGiACIANJDQggAiADTQ0JDA0LIAYgB2oiBUEAIAIgBksbIgRBxarKACAEGy0AACEEAkACQCAIQaB+aiIIQQ1LDQACQAJAIAhBAWsODQICAgICAgICAgICAgEACyAEQeABcUGgAUYNAgwJCyAEQRh0QRh1QX9KIARBoAFPcg0IDAELIAlBH2pB/wFxQQtNBEAgBEEYdEEYdUF/SiAEQcABT3INCAwBCyAJQf4BcUHuAUcgBEG/AUtyIARBGHRBGHVBf0pyDQcLIANBA2ogByADQQJqIgVqIgZBACACIAVLGyIEQcWqygAgBBstAABBwAFxQYABRg0BGiACIANJDQcgA0F9Sw0KIAIgBUkNCwwOCyAGIAdqIgVBACACIAZLGyIEQcWqygAgBBstAAAhBAJAAkAgCEGQfmoiCEEESw0AAkACQCAIQQFrDgQCAgIBAAsgBEHwAGpB/wFxQTBJDQIMBwsgBEEYdEEYdUF/SiAEQZABT3INBgwBCyAEQb8BSyAJQQ9qQf8BcUECS3IgBEEYdEEYdUF/SnINBQsgByADQQJqIgVqIgZBACACIAVLGyIEQcWqygAgBBstAABBwAFxQYABRw0CIAcgA0EDaiIFaiIGQQAgAiAFSxsiBEHFqsoAIAQbLQAAQcABcUGAAUcNAyADQQRqCyIDIAJJDQALIAFBADYCBCABQcSqygA2AgAgACACNgIEIAAgBzYCACAAQQxqQQA2AgAgAEEIakHEqsoANgIADwsgAiADSQ0DIANBfUsNBiACIAVJDQcMCgsgAiADSQ0CIANBfEsNBSACIAVJDQYgASAGNgIAIAAgAzYCBCAAIAc2AgAgASACIAVrNgIEIABBDGpBAzYCAAwKCyACIANJDQEgAiADTQ0CDAYLIAIgA0kNACACIANNDQEMBQsgAyACEOUCAAsgBiACEOUCAAsgAEEANgIADwsgAyAFEOYCAAsgBSACEOUCAAsgASAFNgIAIAAgAzYCBCAAIAc2AgAgASACIAZrNgIECyAAQQxqQQE2AgAMAQsgASAGNgIAIAAgAzYCBCAAIAc2AgAgASACIAVrNgIEIABBDGpBAjYCAAsgAEEIaiAKNgIAC6MJAgR/LH4jAEHwB2siAiQAIAJByAdqQQBBKBDBBBoDQCABQcAHRgRAAkAgACkDwAEhEyAAKQOYASEFIAApA3AhDSAAKQNIIRQgACkDICEGIAApA7gBIQcgACkDkAEhCiAAKQNoIQggACkDQCEJIAApAxghCyAAKQOwASEVIAApA4gBIRYgACkDYCEXIAApAzghGCAAKQMQIQ4gACkDqAEhGSAAKQOAASEaIAApA1ghGyAAKQMwIRwgACkDCCEdIAApA6ABIQwgACkDeCEeIAApA1AhHyAAKQMoISAgACkDACEhQQAhAUGI98MAIQQDQCABQcAHRg0BIAJBCGogAWoiA0EIaiAOIBiFIBeFIBaFIBWFIg8gBiAUhSANhSAFhSAThSIQQgGJhSIiIAmFQjeJIiM3AwAgA0EQaiANIAkgC4UgCIUgCoUgB4UiESAgICGFIB+FIB6FIAyFIhJCAYmFIgmFQieJIiQ3AwAgA0EgaiAPQgGJIBKFIg8gGYVCAokiEjcDACADQRhqIBAgHCAdhSAbhSAahSAZhSINQgGJhSIQIB6FQimJIiU3AwAgAyAOIBFCAYkgDYUiEYVCPokiJjcDACAPIByFIAkgE4UhDiAjICZCf4WDIBKFIRMgIyAlICRCf4WDhSEZIA8gG4VCCokiJyAHICKFQjiJIiggESAWhUIPiSIpQn+Fg4UhFiAGIAmFQhuJIiogJyAQICCFQiSJIitCf4WDhSEeIAwgEIVCEokiDCARIBiFQgaJIiwgDyAdhUIBiSItQn+Fg4UhDSAFIAmFQgiJIi4gCCAihUIZiSIvQn+FgyAshSEbIBEgFYVCPYkiBSAJIBSFQhSJIgYgCyAihUIciSIHQn+Fg4UhFCAPIBqFQi2JIgggByAFQn+Fg4UhCSAQIB+FQgOJIgsgBSAIQn+Fg4UhGCAIIAtCf4WDIAaFIRwgByALIAZCf4WDhSEgIAogIoVCFYkiBSAQICGFIgYgDkIOiSIHQn+Fg4UhCyARIBeFQiuJIgogByAFQn+Fg4UhDkIsiSIIIAUgCkJ/hYOFIR0gBCkDACAGIAogCEJ/hYOFhSEhIARBCGohBCABQShqIQEgKCArICpCf4WDhSEFIAggBkJ/hYMgB4UhBiAlICYgEkJ/hYOFIQcgKiAoQn+FgyAphSEKIC0gDEJ/hYMgLoUhCCASICVCf4WDICSFIRUgLyAMIC5Cf4WDhSEXICsgKSAnQn+Fg4UhGiAkICNCf4WDICaFIQwgLyAsQn+FgyAthSEfDAALAAsFIAJBCGogAWogAkHIB2pBKBDyAxogAUEoaiEBDAELCyAAIAw3A6ABIAAgHjcDeCAAIB83A1AgACAgNwMoIAAgITcDACAAIBk3A6gBIAAgGjcDgAEgACAbNwNYIAAgHDcDMCAAIB03AwggACAVNwOwASAAIBY3A4gBIAAgFzcDYCAAIBg3AzggACAONwMQIAAgBzcDuAEgACAKNwOQASAAIAg3A2ggACAJNwNAIAAgCzcDGCAAIBM3A8ABIAAgBTcDmAEgACANNwNwIAAgFDcDSCAAIAY3AyAgAkHwB2okAAukCwICfwF+IwBB0AFrIgYkACAGQTRqIAJBJBDyAxogBkEyaiACQSdqLQAAOgAAIAYgAi8AJTsBMCACLQAkIQIgAygCACEHIAMpAgQhCCAGIAE2AlggACgCACEDAn8CQCABRQRAIAMtABBFDQELIAMoAgAhAQJAAkAgACgCBARAIAZBnAFqQQA2AgAgBkH8jsoANgKYASAGQgE3AowBIAZB8I/KADYCiAEgASAGQYgBahDoAg0CIAAoAgAiAS0AEEEBRw0BIAEoAgAgBkEoakGAkMoAELIFIAZBnAFqQQI2AgAgBkGUAWpBATYCACAGQQc2AmQgBkH4j8oANgJgIAZByI/KADYCkAEgBkEBNgKMASAGQfiPygA2AogBIAYgBikDKDcDaCAGIAZB4ABqNgKYASAGQYgBahDoAkUNAQwCCyAGQSBqIANBBGpBywAQpgUgBkGcAWpBATYCACAGQZQBakEBNgIAIAZBkI/KADYCkAEgBkECNgKMASAGQYCPygA2AogBIAYgBikDIDcDYCAGIAZB4ABqNgKYASABIAZBiAFqEOgCDQEgACgCACIBLQAQQQFHDQAgASgCACAGQRhqQcSPygAQsgUgBkGcAWpBAjYCACAGQZQBakEBNgIAIAZBiAE2AmQgBkHIj8oANgKQASAGQQI2AowBIAZBtI/KADYCiAEgBiAGKQMYNwNoIAYgBkHYAGo2AmAgBiAGQeAAajYCmAEgBkGIAWoQ6AINAQsgBkHgAGogBkE0akEkEPIDGiAGQd4AaiAGQTJqLQAAOgAAIAYgBi8BMDsBXCAAKAIAIQECQAJAIAJBA0YNACABLQAQIgNBAUsNACADQQFrBEAgBkGIAWogBkHgAGpBJBDyAxogBkGtAWogBi8BXDsAACAGQawBaiACOgAAIAZBrwFqIAZB3gBqLQAAOgAAIAEoAgAgBkHEAWpBATYCACAGQbwBakEBNgIAIAZBhJDKADYCuAEgBkEBNgK0ASAGQfiPygA2ArABIAZBiQE2AswBIAYgBkHIAWo2AsABIAYgBkGIAWo2AsgBIAZBsAFqEOgCRQ0CDAMLIAZBiAFqIAZB4ABqQSQQ8gMaIAZBrQFqIAYvAVw7AAAgBkGsAWogAjoAACAGQa8BaiAGQd4Aai0AADoAACABKAIAIAZBxAFqQQE2AgAgBkIBNwK0ASAGQfiPygA2ArABIAZBiQE2AswBIAYgBkHIAWo2AsABIAYgBkGIAWo2AsgBIAZBsAFqEOgCRQ0BDAILIAEoAgAgBkGcAWpBADYCACAGQfyOygA2ApgBIAZCATcCjAEgBkGwkMoANgKIASAGQYgBahDoAg0BCyAAKAIAKAIAQbiQygBBARCIBQ0AIAdBAkYgBEEBR3INASAGIAU2ArABAkAgACgCACIBLQAQQQFGBH8gASgCACAGQRBqQcSPygAQsgUgBkGcAWpBAjYCACAGQZQBakEBNgIAIAZBBzYCZCAGQfiPygA2AmAgBkHIj8oANgKQASAGQQE2AowBIAZB+I/KADYCiAEgBiAGKQMQNwNoIAYgBkHgAGo2ApgBIAZBiAFqEOgCDQEgACgCAAUgAQsoAgAgBkGcAWpBADYCACAGQfyOygA2ApgBIAZCATcCjAEgBkHMkMoANgKIASAGQYgBahDoAg0AIAAoAgAiAUEMaigCACECIAEoAgggBkGQAWogCDcDACAGIAc2AowBIAYgASgCACIBNgKIASABIAZBiAFqQQRyIAIoAgwRBAANACAAKAIAKAIAIAZBCGogBkGwAWpBywAQpgUgBkGcAWpBATYCACAGQgI3AowBIAZB2JDKADYCiAEgBiAGKQMINwNgIAYgBkHgAGo2ApgBIAZBiAFqEOgCRQ0CCwtBAQwBCyAAIAAoAgRBAWo2AgRBAAsgBkHQAWokAAv6CQELfyMAQYACayIDJAAQyQQhCyADQRhqEKgDIANBgAFqIAEgAkGI8sgAQQEQICADQQE7AcgBIAMgAjYCxAEgA0EANgLAASADQTBqIANBgAFqQdAAEPIDGiADQYABaiADQTBqQdAAEPIDGiADQYgBaiEMAkACQAJAAkACQANAIAMtAMkBDQEgAygCsAEhBiADQfABaiALAn8CfwJAAkAgAygCgAFBAUcEQCAGIAMoArQBIgdqIQEgAy0AjAEhBCADKAKEASECA0AgAyAHNgLkASADIAY2AuABIAMgAjYC6AEgAyAHNgLsASACRSACIAdGckUEQCAHIAJNDQkgAiAGaiwAAEG/f0wNCQsgBCEJAn8gAiAHRwRAIAIgBmoiCCwAACIFQX9KBEAgBUH/AXEMAgsCfyABIAhBAWpGBEAgASEEQQAMAQsgCEECaiEEIAgtAAFBP3ELIg0gBUEfcSIKQQZ0ciAFQf8BcSIIQd8BTQ0BGgJ/IAEgBEYEQCABIQVBAAwBCyAEQQFqIQUgBC0AAEE/cQsgDUEGdHIiBCAKQQx0ciAIQfABSQ0BGiABIAVGBH9BAAUgBS0AAEE/cQsgCkESdEGAgPAAcSAEQQZ0cnIMAQtBgIDEAAshBSAJRSEEIAkNAyAFQYCAxABHBEACf0EBIAVBgAFJDQAaQQIgBUGAEEkNABpBA0EEIAVBgIAESRsLIAJqIQIMAQsLIAMgAjYChAEgAyAEOgCMASADQQA2AtABDAELIANB0AFqIAwgBiADKAK0ASADKAK4ASADKAK8ASADKAKkAUF/RhBKIAMoAtABQQFGBEAgAygC2AEhAiADKALUAQwDCyADLQDJAQ0FCwJAIAMtAMgBBEAgAygCxAEhAiADKALAASEBDAELIAMoAsQBIgIgAygCwAEiAUYNBQsgA0EBOgDJASACIAFrIQIgAygCsAEgAWoMAgsgAyACNgKEASADIAQ6AIwBIAMgAjYC2AEgAyACNgLUASADQQE2AtABIAILIAMoAsABIQQgAyACNgLAASAEayECIAQgBmoLIAIQfSADLwHwAUEBRwRAIANBGGogAy8B8gEQzgIMAQsLIAAgAykC9AE3AgQgAEEBNgIADAILIANBgAFqIAMoAhggA0EoaiICKAIAQQN0akELbhDvASADKAKEASEEIAMoAoABQQFHDQIgACAENgIEIABBATYCACAAQQhqIANBiAFqKAIANgIADAELIAMgA0HsAWo2AvgBIAMgA0HoAWo2AvQBIAMgA0HgAWo2AvABIANB8AFqEO8EAAsgA0EgahCBBQwBCyADQYABaiIBKAIABEAgAUEEahD6AQsgA0GQAWogAigCADYCACADQYgBaiADQSBqKQMANwMAIAMgAykDGDcDgAEgA0EwaiADQYABahDtAyADQRBqIANBMGoQmwUgAygCFCIBIARBC3YiAksEQCADKAIQIAJqLQAAIANBMGogAhCLBCADQQhqIANBMGoQmwVBACAEa0EHcSIBdkH/AXEgAygCCCADKAIMENoEQf8BcSABdkH/AXFHBEAgA0EANgKAASADIANBgAFqEMEDIAAgAykDADcCBCAAQQE2AgAgA0EwahCBBQwCCyAAIAMpAzA3AgQgAEEANgIAIABBDGogA0E4aigCADYCAAwBC0H48cgAIAIgARDkAgALIANBgAJqJAALigkBCX8jAEHQAGsiAyQAIAFBBGooAgAhBSABKAIAIQIgAS0ACCIGQQZHBEAgA0E3aiABQRhqKAAANgAAIANBMGogAUERaikAADcDACADIAFBCWopAAA3AygLIANBEWogAykDKDcAACADQRlqIANBMGopAwA3AAAgA0EgaiADQTdqKAAANgAAIAMgBjoAECADIAU2AgwgAyACNgIIIAMgAS0AHiIJOgAmIAMgAS0AHSIEOgAlIAMgAS0AHEEARzoAJAJAAkAgBUUgBEH/AXFBAkdyDQACQAJAIAZBAk0EQANAQQAhB0EAIQECQANAIAEgBUYEQCAFIQYMAgsgASACaiABQQFqIQEtAAAiCEEvRw0AC0EBIQcgBSAIQS9GQQFqQQFxIAFqQX9qIgZJDQYLIAYNBCAFIAYgB2oiAUkNAiADIAUgAWsiBTYCDCADIAEgAmoiAjYCCCAFDQAMAwsACwNAQQAhB0EAIQECQAJAA0AgASAFRgRAIAUhBgwCCyABIAJqIAFBAWohAS0AACIIQS9HDQALQQEhByAFIAhBL0ZBAWpBAXEgAWpBf2oiBkkNAQsgBkEBSw0EIAZBAWsgAkHQocoARnJFBEAgAi0AAEEuRw0FCyAFIAYgB2oiAUkNAiADIAUgAWsiBTYCDCADIAEgAmoiAjYCCCAFRQ0DDAELCwwDCyABIAUQ5gIAC0EAIQULAkAgCUECRw0AIANBEGohBwJAA0ACQEEAIQFBACEGAkBBAEEBQX8gBEH/AXEiCBsgCEEBRhtBAWpBAUsiBA0AIAQgAy0AJCIBcg0AIAMtABAiAkF7akH/AXFBAUsNAEEAIQQgAkEGRiICRQRAQQIhBAJAAkACQAJAAkACQEEAIAcgAhsiAi0AAEEBaw4FAQIEAwUACyACKAIIQQRqIQQMBAsgAigCCCACKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAigCCCACKAIQIgRBAWpBACAEG2pBAmohBAwBCyACKAIIQQRqIQQLIAUgBEkNAgsgBCAFRiIJDQAgAygCCCIGIARqIgIgAkEBaiAJGyAFIAZqRiIJIAItAAAiCkEuRnEhBiAJIApBLkdyDQAgAiAEIAVHai0AAEEvRiEGC0EAIQQCQCAIDQAgAy0AEEEGRiICDQBBAiEEAkACQAJAAkACQEEAIAcgAhsiAi0AAEEBaw4FAQIEAwUACyACKAIIQQRqIQQMBAsgAigCCCACKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAigCCCACKAIQIgRBAWpBACAEG2pBAmohBAwBCyACKAIIQQRqIQQLAkAgBSABIAZqIARqSwRAIANBKGogA0EIahAtIAMoAgwhASADKAIsQQVGDQEgASEFCyADKAIIIQIMBAsgASADKAIoIgZrIQUgASAGSQ0CIAMgBTYCDCADLQAlIQQMAQsLIAQgBRDmAgALIAUgARDlAgALIAAgBTYCBCAAIAI2AgAgA0HQAGokAA8LIAhBL0ZBAWpBAXEgAWpBf2ogBRDlAgAL2AkCBX8BfiMAQbAKayIDJAACQAJAIAJBwABGBEAgA0EYaiABQcAAEKIEQSAhAgJ/IAMoAhxBIEcEQEGgucYAIQRBCSEFQQIhBkEBDAELIAMoAhghAiADQfgEaiIEQgA3AwAgA0HwBGpCADcDACADQegEakIANwMAIANCADcD4AQgA0EQaiACQSAQogQgA0HgBGpBICADKAIQIAMoAhQQsAEgA0H2AWogAy0A4gQ6AAAgAyADLwHgBDsB9AEgAyADKQDzBDcDqAMgAyAEKQAANwCtAyADKADjBCEGIAMoAOcEIQQgAygA6wQhBSADKADvBCECQQALIQcgA0GICWogAjYCACADQYQJaiAFNgIAIANBgAlqIAQ2AgAgA0GMCWogAykDqAM3AgAgA0GUCWogA0GwA2opAwA3AgAgA0GcCWogA0G4A2opAwA3AgAgAyAHOgD4CCADIAMvAfQBOwD5CCADIAY2AvwIIAMgA0H2AWotAAA6APsIIAdFDQEgAEEEaiADQfgIakEEckEoEPIDGiAAQQE2AgAMAgsgAEKBgICAIDcDACAAQQxqQoeAgICACDcCACAAQQhqQZC5xgA2AgAMAQsgA0E4aiIEIANB+AhqQQFyIgJBGGopAAA3AwAgA0EwaiACQRBqKQAANwMAIANBKGogAkEIaikAADcDACADIAIpAAA3AyAgA0H4BGoiAkIANwMAIANB8ARqIgVCADcDACADQegEaiIGQgA3AwAgA0IANwPgBCADQQhqIAFBIGpBIBCiBCADQeAEakEgIAMoAgggAygCDBCwASADQZgFaiIBIAIpAwA3AwAgA0GQBWogBSkDADcDACADQYgFaiAGKQMANwMAIAMgAykD4AQ3A4AFIANB+AhqIANBgAVqEGwgAykD+AhCAVEEQCADQYgJaigCACECIAMpA4AJIQggA0HIB2ogA0GMCWpBlAEQ8gMaIANBtAZqIANByAdqQZQBEPIDGiADQaAFaiADQbQGakGUARDyAxogA0H4CGogA0GgBWpBlAEQ8gMaIANBpApqIAEpAwA3AgAgA0GcCmogA0GQBWopAwA3AgAgA0GUCmogA0GIBWopAwA3AgAgAyADKQOABTcCjAogA0GoA2ogA0H4CGpBtAEQ8gMaIANB9AFqIANBqANqQbQBEPIDGiADQUBrIANB9AFqQbQBEPIDGiAAQRBqIAI2AgAgAEEIaiAINwMAIABBFGogA0FAa0G0ARDyAxogAEEANgIAIABB4AFqIAQpAwA3AAAgAEHYAWogA0EwaikDADcAACAAQdABaiADQShqKQMANwAAIABByAFqIAMpAyA3AAAMAQsgA0HYB2ogA0HwCGopAgA3AwAgA0HQB2ogA0HoCGopAgA3AwAgAyADKQLgCDcDyAcgA0G0BmogA0HIB2pBlAEQ8gMaIANBsANqIANBvAZqKQIANwMAIANBuANqIANBxAZqKQIANwMAIAMgAykCtAY3A6gDIANB9AFqIANBqANqQbQBEPIDGiAAQQxqQomAgICABDcCACAAQQhqQZe5xgA2AgAgAEEUaiADKQL0ATcCACAAQRxqIANB/AFqKQIANwIAIABBJGogA0GEAmopAgA3AgAgAEIBNwMAIANBIGoQswILIANBsApqJAALlQgCAX8tfiAAKQPAASEOIAApA5gBIQIgACkDcCEPIAApA0ghECAAKQMgIQMgACkDuAEhBCAAKQOQASEHIAApA2ghBSAAKQNAIQogACkDGCEIIAApA7ABIREgACkDiAEhEiAAKQNgIRMgACkDOCEUIAApAxAhBiAAKQOoASEVIAApA4ABIRYgACkDWCEXIAApAzAhGCAAKQMIIRkgACkDoAEhCSAAKQN4IRogACkDUCEbIAApAyghHCAAKQMAIR1BwH4hAQNAIAEEQCAcIB2FIBuFIBqFIAmFIgsgBiAUhSAThSAShSARhSIMQgGJhSIeIBiFIA4gCCAKhSAFhSAHhSAEhSINIAtCAYmFIguFIS4gFSAehUICiSIgIAogAyAQhSAPhSAChSAOhSIfQgGJIAyFIgyFQjeJIiEgBiAYIBmFIBeFIBaFIBWFIgogDUIBiYUiDYVCPokiIkJ/hYOFIQ4gISAfIApCAYmFIgYgGoVCKYkiHyALIA+FQieJIiNCf4WDhSEVIBcgHoVCCokiJCAEIAyFQjiJIiUgDSAShUIPiSImQn+Fg4UhEiADIAuFQhuJIicgJCAGIByFQiSJIihCf4WDhSEaIAYgCYVCEokiCSANIBSFQgaJIikgGSAehUIBiSIqQn+Fg4UhDyACIAuFQgiJIisgBSAMhUIZiSIsQn+FgyAphSEXIA0gEYVCPYkiAiALIBCFQhSJIgMgCCAMhUIciSIEQn+Fg4UhECAWIB6FQi2JIgUgBCACQn+Fg4UhCiAGIBuFQgOJIgggAiAFQn+Fg4UhFCAFIAhCf4WDIAOFIRggBCAIIANCf4WDhSEcIAcgDIVCFYkiAiAGIB2FIgMgLkIOiSIEQn+Fg4UhCCANIBOFQiuJIgcgBCACQn+Fg4UhBkIsiSIFIAIgB0J/hYOFIRkgAUHYw8QAaikDACADIAcgBUJ/hYOFhSEdIAFBCGohASAlICggJ0J/hYOFIQIgBSADQn+FgyAEhSEDIB8gIiAgQn+Fg4UhBCAnICVCf4WDICaFIQcgKiAJQn+FgyArhSEFICAgH0J/hYMgI4UhESAsIAkgK0J/hYOFIRMgKCAmICRCf4WDhSEWICMgIUJ/hYMgIoUhCSAsIClCf4WDICqFIRsMAQUgACAJNwOgASAAIBo3A3ggACAbNwNQIAAgHDcDKCAAIB03AwAgACAVNwOoASAAIBY3A4ABIAAgFzcDWCAAIBg3AzAgACAZNwMIIAAgETcDsAEgACASNwOIASAAIBM3A2AgACAUNwM4IAAgBjcDECAAIAQ3A7gBIAAgBzcDkAEgACAFNwNoIAAgCjcDQCAAIAg3AxggACAONwPAASAAIAI3A5gBIAAgDzcDcCAAIBA3A0ggACADNwMgCwsLyAgBDX8jAEEwayIEJABBASEOAkACQCACKAIYQSIgAkEcaigCACgCEBECAA0AAkAgAUUNACAAIAFqIQwgACEIAkACQANAIAghDyAIQQFqIQkCQAJ/IAgsAAAiBUF/TARAAn8gCSAMRgRAQQAhBiAMDAELIAgtAAFBP3EhBiAIQQJqIgkLIQggBiAFQR9xIg1BBnRyIAVB/wFxIgdB3wFNDQEaAn8gCCAMRgRAIAwhBUEADAELIAhBAWoiCSEFIAgtAABBP3ELIAZBBnRyIgYgDUEMdHIgB0HwAUkNARoCfyAFIAxGBEBBACELIAkMAQsgBS0AAEE/cSELIAVBAWoLIQggDUESdEGAgPAAcSAGQQZ0ciALciILQYCAxABHDQIMBQsgBUH/AXELIQsgCSEICyAEIAsQfwJAAkACQAJAIAQoAgAiCUEBaw4DAgEAAQsgBCgCCCAELQAMakEBRg0BCyAEIAE2AhQgBCAANgIQIAQgAzYCGCAEIAo2AhwgCiADSQ0DIANFIAEgA0ZyRQRAIAMgAU8NBCAAIANqLAAAQb9/TA0ECyAKRSABIApGckUEQCAKIAFPDQQgACAKaiwAAEG/f0wNBAsgAigCGCAAIANqIAogA2sgAigCHCgCDBEEAA0BIAQtAAwhByAEKAIIIQUCQCAEKAIEIgZBgIDEAEYEQANAIAkhA0EBIQlB3AAhBgJAAkAgA0ECaw4CAQAECyAHQf8BcSEDQQMhCUEEIQcCQAJAAkACQCADQQFrDgUDAgEABAcLQQMhB0H1ACEGDAMLQQIhB0H7ACEGDAILQQJBASAFGyEHQYCAxAAgBUECdEEccXZBD3FBMHIhBiAFQX9qQQAgBRshBQwBC0EAIQdB/QAhBgsgAigCGCAGIAIoAhwoAhARAgBFDQAMBAsACwNAIAkhDUEBIQlB3AAhAwJAAkACQAJAIA1BAWsOAwEDAAULIAdB/wFxIQ1BAyEJQQQhBwJAAkACQCANQQFrDgUCAQAEBQcLQQIhB0H7ACEDDAQLIAYgBUECdEEccXZBD3EiA0EwciADQdcAaiADQQpJGyEDQQJBASAFGyEHIAVBf2pBACAFGyEFDAMLQQAhB0H9ACEDDAILQQAhCSAGIQMMAQtBAyEHQfUAIQMLIAIoAhggAyACKAIcKAIQEQIARQ0ACwwCCwJ/QQEgC0GAAUkNABpBAiALQYAQSQ0AGkEDQQQgC0GAgARJGwsgCmohAwsgCiAPayAIaiEKIAggDEcNAQwDCwsMAwsgBCAEQRxqNgIoIAQgBEEYajYCJCAEIARBEGo2AiAgBEEgahDvBAALIANFIAEgA0ZyDQAgAyABTw0CIAAgA2osAABBv39MDQILIAIoAhggACADaiABIANrIAIoAhwoAgwRBAANACACKAIYQSIgAigCHCgCEBECACEOCyAEQTBqJAAgDg8LIAAgASADIAEQKQALuAgBBn8jAEHwAGsiBCQAIAQgAzYCDCAEIAI2AghBASEHIAEhBgJAIAFBgQJJDQBBACABayEIQYACIQUDQAJAIAUgAU8NACAAIAVqLAAAQb9/TA0AQQAhByAFIQYMAgsgBUF/aiEGQQAhByAFQQFGDQEgBSAIaiAGIQVBAUcNAAsLIAQgBjYCFCAEIAA2AhAgBEEAQQUgBxs2AhwgBEHEqsoAQbKzygAgBxs2AhgCQAJAAkAgAiABSyIFIAMgAUtyRQRAIAIgA0sNAQJAIAJFIAEgAkZyRQRAIAEgAk0NASAAIAJqLAAAQUBIDQELIAMhAgsgBCACNgIgIAJFIAEgAkZyDQIgAUEBaiEDA0AgAiABSQRAIAAgAmosAABBQE4NBAsgAkF/aiEFIAJBAUYNBCACIANGIAUhAkUNAAsMAwsgBCACIAMgBRs2AiggBEHEAGpBAzYCACAEQdwAakG0ATYCACAEQdQAakG0ATYCACAEQgM3AjQgBEHYs8oANgIwIARBywA2AkwgBCAEQcgAajYCQCAEIARBGGo2AlggBCAEQRBqNgJQIAQgBEEoajYCSCAEQTBqQfCzygAQvQQACyAEQeQAakG0ATYCACAEQdwAakG0ATYCACAEQdQAakHLADYCACAEQcQAakEENgIAIARCBDcCNCAEQaS0ygA2AjAgBEHLADYCTCAEIARByABqNgJAIAQgBEEYajYCYCAEIARBEGo2AlggBCAEQQxqNgJQIAQgBEEIajYCSCAEQTBqQcS0ygAQvQQACyACIQULAkAgASAFRg0AQQEhBgJAAkACQCAAIAVqIgMsAAAiAkF/TARAQQAhByAAIAFqIgAhASAAIANBAWpHBEAgAy0AAUE/cSEHIANBAmohAQsgAkEfcSEDIAJB/wFxQd8BSw0BIAcgA0EGdHIhAQwCCyAEIAJB/wFxNgIkIARBKGohAgwCC0EAIQggACIGIAFHBH8gAUEBaiEGIAEtAABBP3EFIAgLIAdBBnRyIQEgAkH/AXFB8AFJBEAgASADQQx0ciEBDAELQQAhAiAAIAZHBH8gBi0AAEE/cQUgAgsgA0ESdEGAgPAAcSABQQZ0cnIiAUGAgMQARg0CCyAEIAE2AiRBASEGIARBKGohAiABQYABSQ0AQQIhBiABQYAQSQ0AQQNBBCABQYCABEkbIQYLIAQgBTYCKCAEIAUgBmo2AiwgBEHEAGpBBTYCACAEQewAakG0ATYCACAEQeQAakG0ATYCACAEQdwAakG1ATYCACAEQdQAakG2ATYCACAEQgU3AjQgBEGYtcoANgIwIAQgAjYCWCAEQcsANgJMIAQgBEHIAGo2AkAgBCAEQRhqNgJoIAQgBEEQajYCYCAEIARBJGo2AlAgBCAEQSBqNgJIIARBMGpBwLXKABC9BAALQemqygBBK0HUtMoAEM4DAAvpBgIBfxR+IwBB8AFrIgMkACABKQMgIQUgASkDGCEGIAEpAxAhBCABKQMIIQcgASkDACEIA0AgA0HwAGogCCAHEJ4CIANBMGogBCAFQhN+IgoQngIgA0HgAWogBkITfiIJIAYQngIgA0FAayAJIAQQngIgA0GAAWogByAKEJ4CIANBIGogCCAEEJ4CIANB0AFqIAkgBRCeAiADQRBqIAcgBBCeAiADQaABaiAIIAYQngIgA0HAAWogCiAFEJ4CIANB0ABqIAcgBhCeAiADQZABaiAIIAUQngIgA0GwAWogCCAIEJ4CIANB4ABqIAcgBxCeAiADIAQgBBCeAiADKQOQASIOIAMpA1B8IgRCAYYiDyADKQMAfCIHIAMpA6ABIhAgAykDEHwiCEIBhiIRIAMpA8ABfCIFIAMpAyAiEiADKQPQAXwiBkIBhiITIAMpA2B8IgogAykDcCIUIAMpAzB8IglCAYYiFSADKQPgAXwiDCADKQOAASIWIAMpA0B8IgtCAYYiFyADKQOwAXwiDUIziCANIBdUrSADQbgBaikDACALIBZUrSADQYgBaikDACADQcgAaikDAHx8QgGGIAtCP4iEfHxCDYaEfCILQjOIIAsgDFStIAwgFVStIANB6AFqKQMAIAkgFFStIANB+ABqKQMAIANBOGopAwB8fEIBhiAJQj+IhHx8fEINhoR8IglCM4ggCSAKVK0gCiATVK0gA0HoAGopAwAgBiASVK0gA0EoaikDACADQdgBaikDAHx8QgGGIAZCP4iEfHx8Qg2GhHwiBkIziCAGIAVUrSAFIBFUrSADQcgBaikDACAIIBBUrSADQagBaikDACADQRhqKQMAfHxCAYYgCEI/iIR8fHxCDYaEfCIFQjOIIAUgB1StIAcgD1StIANBCGopAwAgBCAOVK0gA0GYAWopAwAgA0HYAGopAwB8fEIBhiAEQj+IhHx8fEINhoRCE34gDUL/////////A4N8IgRC/////////wODIQggC0L/////////A4MgBEIziHwhByAFQv////////8DgyEFIAZC/////////wODIQYgCUL/////////A4MhBCACQX9qIgINAAsgACAFNwMgIAAgBjcDGCAAIAQ3AxAgACAHNwMIIAAgCDcDACADQfABaiQAC5AIAQl/IwBBwAZrIgMkAAJAAkAgAkHgAEYEQEHAACECIANBCGogAUHgAEHAABCeBAJ/IAMoAgxBwABHBEBBAyEEQdH+wQAhBUEJIQZB2v7BACEIQckAIQlBAQwBCyADKAIIIQIgA0H4BWoiBEIANwMAIANB8AVqIgVCADcDACADQegFaiIGQgA3AwAgA0IANwPgBSADQeAFakEgIAJBIBCtASADQeAFahDIAyADQbACaiAEKQMANwMAIANBqAJqIAUpAwA3AwAgA0GgAmogBikDADcDACADIAMpA+AFNwOYAiADQYAGaiADQZgCahC7AyADQbgGaiIHQgA3AwAgA0GwBmoiCkIANwMAIANBqAZqIgtCADcDACADQgA3A6AGIANBoAZqQSAgAkEgakEgEK0BIANB1gBqIAMtAIIGOgAAIANB0gBqIAMtAIYGOgAAIANB3ABqIANBnwZqLQAAOgAAIAMgAy8BgAY7AVQgAyADLwGEBjsBUCADIAMoAJsGNgJYIAMtAIMGIQQgAygAhwYhBSADKACLBiEGIAMoAI8GIQggAygAkwYhCSADKACXBiECIANB9QBqIAcpAwA3AAAgA0HtAGogCikDADcAACADQeUAaiALKQMANwAAIAMgAykDoAY3AF0gA0GYAmogA0HYAGpBJRDyAxpBAAshByADQfgDaiACNgIAIANB9ANqIAk2AgAgA0HwA2ogCDYCACADQewDaiAGNgIAIANB6ANqIAU2AgAgAyAHOgDgAyADIAMvAVQ7AOEDIAMgBDoA5AMgAyADLwFQOwDlAyADIANB1gBqLQAAOgDjAyADIANB0gBqLQAAOgDnAyADQfwDaiADQZgCakEoEPIDGiADQeADakEEciECIAdFDQEgAEEBNgIAIAAgAikCADcCBCAAQRRqIAJBEGopAgA3AgAgAEEMaiACQQhqKQIANwIAIANB4ANqIgAtAABFBEAgAEEBahCfAQsMAgsgAEEDOgAEIABBATYCACAAQRRqQqSAgICADDcCACAAQRBqQYrwwwA2AgAgAEEMakEHNgIAIABBCGpBg/DDADYCAAwBCyADQRBqIANB4ANqQQFyQcAAEPIDGiADIAFB4ABBwAAQnQQgA0HgA2ogAygCACADKAIEEGkgAygC4AMgA0GYAmogAkHEARDyAxpBAUcEQCADQdgAaiADQZwCakHAARDyAxogA0HgA2ogA0HYAGpBwAEQ8gMaIANBoAVqIANBEGpBwAAQ8gMaIABBCGogA0HgA2pBgAIQ8gMaIABBADYCAAwBCyAAIAMpApgCNwIEIABBATYCACAAQRRqIANBqAJqKQIANwIAIABBDGogA0GgAmopAgA3AgAgA0EQahCfAQsgA0HABmokAAvoBwIJfwR+IwBBsARrIgYkAAJAIAFBwABHDQAgBkHoA2pCADcDACAGQeADakIANwMAIAZB2ANqQgA3AwAgBkIANwPQAyAGQSBqIgFCADcDACAGQRhqIgdCADcDACAGQRBqIghCADcDACAGQgA3AwggBkHQA2pBICAAQSAQrgEgBkEIakEgIABBIGpBIBCuASAGLAAnIgBBf0oNACAGIABB/wBxOgAnIAZB4ABqIAEpAwA3AwAgBkHYAGogBykDADcDACAGQdAAaiAIKQMANwMAIAYgBikDCDcDSCAGQYgCaiAGQcgAahDMAUEBIQECfyAGLQCIAkEBRwRAIAZBpwRqIAZB1wBqKQAANwAAIAZBoARqIAZB0ABqKQAANwMAIAYgBikASDcDmARBAgwBCyAGQaAEaiAGQZUCaikAADcDACAGQacEaiAGQZwCaikAADcAACAGQZQEaiAGQagCai0AADoAACAGIAYpAI0CNwOYBCAGIAZBpAJqKAIANgKQBCAGLwCJAiAGLQCLAkEQdHIhDUEAIQEgBi0AjAILIQAgBkGABGoiByAGQaAEaiIIKQMANwMAIAZBhwRqIgkgBkGnBGoiCykAADcAACAGQfQDaiIKIAZBlARqIgwtAAA6AAAgBiAGKQOYBDcD+AMgBiAGKAKQBDYC8AMgAQRAIAZBkQJqIAcpAwA3AAAgBkGYAmogCSkAADcAACAGIAA6AIgCIAYgBikD+AM3AIkCIAZByABqIAZBiAJqEKoEIAZBAmogBi0ASzoAACAGIAYvAEk7AQAMAQsgCyAJKQAANwAAIAggBykDADcDACAMIAotAAA6AAAgBkEGaiIBIAYtANIDOgAAIAYgBikD+AM3A5gEIAYgBigC8AM2ApAEIAYgBi8B0AM7AQQgBi0A0wMhByAGQQJqIgkgBi0A1gM6AAAgBiAGLwHUAzsBACAGQe8DajEAACEPIAYpANcDIRAgBikA3wMhESAGKADnAyEKIAY1AOsDIRIgBkEraiAAOgAAIAYgBzoACyAGIAEtAAA6AAogBiAGLwEEOwEIIAYgEiAPQiCGhCANrUIohoQ3ACMgBiAKNgAfIAYgETcAFyAGIBA3AA8gBiAGLwEAOwEMIAYgCS0AADoADiAGQSxqIAYpA5gENwIAIAZBNGogCCkDADcCACAGQTtqIAspAAA3AAAgBkHHAGogDC0AADoAACAGQcMAaiAGKAKQBDYAACAGQYgCaiAEIAUQXiAGQcgAaiAGQYgCakGYhMAAEMcCIAZBiAJqIAZByABqIAIgAyAGQQhqEOQBIAYtAIgCQQdGIQ4LIAZBsARqJAAgDgvUBgENfyMAQSBrIgokAAJAAkACQEEAQQFBfyABLQAdIggbIAhBAUYbQQFqQQFLIgINACACIAEtABwiBnINACABLQAIIgNBe2pB/wFxQQFLDQAgASgCBCEHQQAhAiADQQZGIgNFBEBBAiECAkACQAJAAkACQAJAQQAgAUEIaiADGyIDLQAAQQFrDgUBAgQDBQALIAMoAghBBGohAgwECyADKAIIIAMoAhAiAkEBakEAIAIbakEIaiECDAMLQQYhAgwCCyADKAIIIAMoAhAiAkEBakEAIAIbakECaiECDAELIAMoAghBBGohAgsgByACSQ0CCyACIAdGIgkNACABKAIAIgQgAmoiAyADQQFqIAkbIAQgB2pGIgkgAy0AACILQS5GcSEEIAkgC0EuR3INACADIAIgB0dqLQAAQS9GIQQLAkAgCA0AIAEtAAhBBkYiAg0AQQIhBQJAAkACQAJAAkBBACABQQhqIAIbIgItAABBAWsOBQECBAMFAAsgAigCCEEEaiEFDAQLIAIoAgggAigCECICQQFqQQAgAhtqQQhqIQUMAwtBBiEFDAILIAIoAgggAigCECICQQFqQQAgAhtqQQJqIQUMAQsgAigCCEEEaiEFCyABKAIEIgMgBCAGaiAFaiIHSQ0BIAEoAgAiCCAHaiECIAMgCGoiCUF/aiELIAUgBmogBGoiDCADayENQQAhBEEAIQYCQANAIAYgDUYNASAGIAtqIAZBf2oiBSEGLQAAQS9HDQALQQEhBCADIAkgDGogAmsiAiAFakEBaiIHSQ0CIAIgCGogBWpBAWohAgsgBCADIAdrIgZqIQVBBCEEAkAgBkECSw0AAkACQAJAIAZBAWsOAgABAgsgAkHQocoARwRAIAItAABBLkcNAwtBAkEFQQIgAS0ACCIBQQNJIAFBBkYbIgFBAXEbQQUgAUECRxshBAwCCyACQeOhygBHBEAgAi8AAEGu3ABHDQILQQMhBAwBC0EFIQQLIAAgBDYCBCAAIAU2AgAgAEEMaiAGNgIAIABBCGogAjYCACAAQRBqIAopAgw3AgAgAEEYaiAKQRRqKQIANwIAIABBIGogCkEcaigCADYCACAKQSBqJAAPCyACIAcQ5gIACyAHIAMQ5gIAC8QGAQt/IABBEGooAgAhAwJAAkACQAJAIABBCGooAgAiDUEBRwRAIANBAUYNASAAKAIYIAEgAiAAQRxqKAIAKAIMEQQAIQMMAwsgA0EBRw0BCwJAIAJFBEBBACECDAELIAEgAmohCCAAQRRqKAIAQQFqIQsgASIDIQkDQCADQQFqIQUCQAJ/IAMsAAAiBEF/TARAAn8gBSAIRgRAQQAhCiAIDAELIAMtAAFBP3EhCiADQQJqIgULIQcgCiAEQR9xIgxBBnRyIARB/wFxIgNB3wFNDQEaAn8gByAIRgRAQQAhBCAIDAELIActAABBP3EhBCAHQQFqIgULIQcgBCAKQQZ0ciIEIAxBDHRyIANB8AFJDQEaAn8gByAIRgRAIAUhA0EADAELIAdBAWohAyAHLQAAQT9xCyAMQRJ0QYCA8ABxIARBBnRyciIEQYCAxABHDQIMBAsgBEH/AXELIQQgBSEDCyALQX9qIgsEQCAGIAlrIANqIQYgAyEJIAMgCEcNAQwCCwsgBEGAgMQARg0AAkAgBkUgAiAGRnJFBEBBACEDIAYgAk8NASABIAZqLAAAQUBIDQELIAEhAwsgBiACIAMbIQIgAyABIAMbIQELIA1BAUYNAAwCC0EAIQUgAgRAIAIhBCABIQMDQCAFIAMtAABBwAFxQYABRmohBSADQQFqIQMgBEF/aiIEDQALCyACIAVrIAAoAgwiCU8NAUEAIQZBACEFIAIEQCACIQQgASEDA0AgBSADLQAAQcABcUGAAUZqIQUgA0EBaiEDIARBf2oiBA0ACwsgBSACayAJaiIDIQQCQAJAAkBBACAALQAgIgUgBUEDRhtBAWsOAwEAAQILIANBAXYhBiADQQFqQQF2IQQMAQtBACEEIAMhBgsgBkEBaiEDAkADQCADQX9qIgNFDQEgACgCGCAAKAIEIAAoAhwoAhARAgBFDQALQQEPCyAAKAIEIQVBASEDIAAoAhggASACIAAoAhwoAgwRBAANACAEQQFqIQMgACgCHCEBIAAoAhghAANAIANBf2oiA0UEQEEADwsgACAFIAEoAhARAgBFDQALQQEPCyADDwsgACgCGCABIAIgAEEcaigCACgCDBEEAAvDBwIGfwJ+AkACQAJAAkAgAkUNAEEAIAFrQQAgAUEDcRshCCACQXlqQQAgAkEHSxshBwNAAkAgASAEai0AACIFQRh0QRh1IgZBf0wEQEKAgICAgCAhCiAFQbKxygBqLQAAQX5qIgNBAksEQEKAgICAECEJDAcLAkACQAJAAkACQCADQQFrDgIBAgALIARBAWoiAyACSQ0CQgAhCQwJC0IAIQkgBEEBaiIDIAJPDQggASADai0AACEDAkACQCAFQaB+aiIFQQ1LDQACQAJAIAVBAWsODQICAgICAgICAgICAgEACyADQeABcUGgAUYNAkKAgICAECEJDAwLIANBGHRBGHVBf0oEQEKAgICAECEJDAwLIANBoAFJDQFCgICAgBAhCQwLCyAGQR9qQf8BcUELTQRAIANBGHRBGHVBf0oEQEKAgICAECEJDAwLIANBwAFJDQFCgICAgBAhCQwLCyADQb8BSwRAQoCAgIAQIQkMCwsgBkH+AXFB7gFHBEBCgICAgBAhCQwLCyADQRh0QRh1QX9MDQBCgICAgBAhCQwKC0IAIQogBEECaiIDIAJPDQkgASADai0AAEHAAXFBgAFGDQIMBwtCACEJIARBAWoiAyACTw0HIAEgA2otAAAhAwJAAkAgBUGQfmoiBUEESw0AAkACQCAFQQFrDgQCAgIBAAsgA0HwAGpB/wFxQTBJDQJCgICAgBAhCQwLCyADQRh0QRh1QX9KBEBCgICAgBAhCQwLCyADQZABSQ0BQoCAgIAQIQkMCgsgA0G/AUsEQEKAgICAECEJDAoLIAZBD2pB/wFxQQJLBEBCgICAgBAhCQwKCyADQRh0QRh1QX9MDQBCgICAgBAhCQwJCyAEQQJqIgMgAk8NByABIANqLQAAQcABcUGAAUcNBkIAIQogBEEDaiIDIAJPDQggASADai0AAEHAAXFBgAFGDQFCgICAgIDgACEKQoCAgIAQIQkMCAtCgICAgBAhCSABIANqLQAAQcABcUGAAUcNBwsgA0EBaiEEDAELIAggBGtBA3FFBEACQCAEIAdPDQADQCABIARqIgNBBGooAgAgAygCAHJBgIGChHhxDQEgBEEIaiIEIAdJDQALCyAEIAJPDQEDQCABIARqLAAAQQBIDQIgAiAEQQFqIgRHDQALDAMLIARBAWohBAsgBCACSQ0ACwsgACABNgIEIABBCGogAjYCACAAQQA2AgAPC0KAgICAgMAAIQpCgICAgBAhCQwBC0IAIQoLIAAgCSAErYQgCoQ3AgQgAEEBNgIAC9cGAQx/IwBBwAFrIgUkAAJ/IAIEQEEBIAEtAABBL0YNARoLQQALIQYgBSAFKABgNgIIIAUgBUHjAGooAAA2AAsCfyAEBEBBASADLQAAQS9GDQEaC0EACyEHIAVBKWogBSgAYDYAACAFQSxqIAVB4wBqKAAANgAAIAVBBjoAKCAFIAQ2AiQgBSADNgIgIAVBgAQ7AD0gBSAHOgA8IAVBhAFqIQwgBUHgAGpBBHIhDSAFQckAaiEDIAVBgAFqIQRBAiEIQQYhBwJ/AkADQCAHQQZHBEAgBUHvAGogBUEXaigAADYAACAFQegAaiAFQRBqKQIANwMAIAUgBSkCCDcDYAsgAyAFKQNgNwAAIANBCGoiDiAFQegAaikDADcAACADQQ9qIg8gBUHvAGooAAA2AAAgBSAHOgBIIAUgAjYCRCAFIAE2AkAgBSAIOgBeIAUgCzoAXSAFIAZBAEc6AFwgBUHgAGogBUFAaxAcIAVBoAFqIAVBIGoQHCAEQRhqIAVBuAFqKQMANwIAIARBEGogBUGwAWopAwA3AgAgBEEIaiAFQagBaikDADcCACAEIAUpA6ABNwIAIAUoAoABIQkCQCAFKAJgIgpBBUYEQCAJQQVHDQMMAQsgCUEFRg0AIAkgCkcNAgJAIApBBEsNAAJAAkAgCkEBaw4EAgICAAELIAUoAmgiASAFKAKIAUcNBCAFKAJkIgIgBSgChAEiBkYNASACIAYgARC0Aw0EDAELIA0gDBBPRQ0DCyAFQRBqIA4pAAA3AwAgBUEXaiAPKAAANgAAIAUgAykAADcDCCAFKAJAIQEgBSgCRCECIAUtAEghByAFLQBcIQYgBS0AXSELIAUtAF4hCCAFLQBfIRAMAQsLIAVBrwFqIgQgBUEXaigAADYAACAFQagBaiIDIAVBEGopAwA3AwAgBSAFKQMINwOgASAGQQJGDQAgBUHpAGogBSkDoAE3AAAgBUHxAGogAykDADcAACAFQfgAaiAEKAAANgAAIAUgBzoAaCAFIAI2AmQgBSABNgJgIAUgEDoAfyAFIAg6AH4gBSALOgB9IAUgBjoAfCAFIAVB4ABqECUgBSgCBCEEIAUoAgAMAQtBAAshASAAIAQ2AgQgACABNgIAIAVBwAFqJAALogYCC38BfiMAQeACayIBJAAgABDEAiIGKAIkIQIgAUIANwMQIAZBJGohCSABQRhqIQcgAUEcaiELA0ACQCACRQRAIAZBIGoQ0AQgASgCFCEDIAECfyABKAIQIgRBCE0EQCABKAIcDAELIAEoAhwLIgA2AsACIAEgBDYC0AIgASgCGCEIIAFB0AFqIAFBIGpB2AAQ8gMaQQAhAiABQcACaiABQdACaiAEQQhLIgcbQQA2AgAgASgC0AIhBiABKALAAiEFIAFB+ABqIAFB0AFqQdgAEPIDGiABQdwBaiAFNgIAIAFB2AFqIgUgCDYCACABIAM2AtQBIAEgBjYC0AEgAUHgAWogAUH4AGpB2AAQ8gMaIAEgACAEIAcbIgM2ArwCIAFBADYCuAIMAQsgAigCGCEEIAAgAigCFEcEQCACQRhqIQkgAiEIIAQhAgwCCyAJIAQ2AgAgAiAGKAIoRgRAIAYgCDYCKAsgAkEANgIcIAFB0AFqIAIQmQMCQAJ/IAEoAhAiA0EISyIFRQRAQQghAiADDAELIAMhAiABKAIcCyIKIAJHDQACfyAFRQRAQQghAiADDAELIAMhAiABKAIcCyEFIAIgBUcNACABQQhqIAVBAWoiAiAFTyACEMIDIAFBEGogASgCDEF/IAEoAggbEKUBIAEoAhAhAwsCfyADQQhNBEAgByECIAFBEGoMAQsgASgCGCECIAsLIApBAWo2AgAgAiAKQQxsaiICIAEpA9ABNwIAIAJBCGogAUHYAWooAgA2AgAgBCECDAELCwNAAkAgAiADRgRAIAFBAjoA2AIMAQsgASACQQFqNgK4AiABQdgCaiIAAn8gBSABKALQAUEITQ0AGiABKALYAQsgAkEMbGoiAkEIaigCACIENgIAIAEgAikCADcD0AIgBEH/AXFBAkYNACABQcgCaiAAKAIAIgI2AgAgASABKQPQAiIMNwPAAiAAIAI2AgAgASAMNwPQAiABQdACahDzBCABKAK8AiEDIAEoArgCIQIMAQsLIAFB0AJqEP8DIAFB0AFqEMUCIAFB0AFqEJ0CIAFB4AJqJAALlQYBB38CQAJAAkACQAJAAkACQAJAAkAgAEGAgARPBEAgAEGAgAhJDQEgAEHii3RqQeKNLEkgAEGfqHRqQZ8YSXIgAEH+//8AcUGe8ApGIABB3uJ0akEOSXJyIABBqbJ1akEpSSAAQcuRdWpBC0lycg0IIABBkPxHakGP/AtLDwsgAEGA/gNxQQh2IQZBgLbKACEBIABB/wFxIQcDQCABQQJqIQUgAiABLQABIgRqIQMgBiABLQAAIgFHBEAgASAGSw0IIAMhAiAFIgFB0rbKAEcNAQwICyADIAJJDQIgA0GlAksNAyACQdK2ygBqIQECQANAIARFDQEgBEF/aiEEIAEtAAAgAUEBaiEBIAdHDQALQQAhBAwJCyADIQIgBSIBQdK2ygBHDQALDAYLIABBgP4DcUEIdiEGQbG7ygAhASAAQf8BcSEHA0AgAUECaiEFIAIgAS0AASIEaiEDIAYgAS0AACIBRwRAIAEgBksNBiADIQIgBSIBQfe7ygBHDQEMBgsgAyACSQ0DIANBpgFLDQQgAkH3u8oAaiEBAkADQCAERQ0BIARBf2ohBCABLQAAIAFBAWohASAHRw0AC0EAIQQMCAsgAyECIAUiAUH3u8oARw0ACwwECyACIAMQ5gIACyADQaUCEOUCAAsgAiADEOYCAAsgA0GmARDlAgALIABB//8DcSEAQZ29ygAhAUEBIQQDQAJAAn8gAUEBaiIDIAEtAAAiAkEYdEEYdSIFQQBODQAaIANBtcDKAEYNASABLQABIAVB/wBxQQh0ciECIAFBAmoLIQEgACACayIAQQBIDQMgBEEBcyEEIAFBtcDKAEcNAQwDCwtB6arKAEErQfC1ygAQzgMACyAAQf//A3EhAEH3uMoAIQFBASEEA0ACfyABQQFqIgMgAS0AACICQRh0QRh1IgVBAE4NABogA0Gxu8oARg0DIAEtAAEgBUH/AHFBCHRyIQIgAUECagshASAAIAJrIgBBAEgNASAEQQFzIQQgAUGxu8oARw0ACwsgBEEBcQ8LQemqygBBK0HwtcoAEM4DAAuhBgEKfyMAQTBrIgMkACADQSRqIAE2AgAgA0EDOgAoIANCgICAgIAENwMIIAMgADYCICADQQA2AhggA0EANgIQAkACQAJAIAIoAggiBQRAIAIoAgAhByACKAIEIgkgAkEMaigCACIEIAQgCUsbIgtFDQEgAkEUaigCACEIIAIoAhAhCkEBIQQgACAHKAIAIAcoAgQgASgCDBEEAA0DIAdBDGohAkEBIQYCQAJAA0AgAyAFQQRqKAIANgIMIAMgBUEcai0AADoAKCADIAVBCGooAgA2AgggBUEYaigCACEEQQAhAUEAIQACQAJAAkAgBUEUaigCAEEBaw4CAAIBCyAEIAhPDQMgBEEDdCAKaiIMKAIEQbcBRw0BIAwoAgAoAgAhBAtBASEACyADIAQ2AhQgAyAANgIQIAVBEGooAgAhBAJAAkACQCAFQQxqKAIAQQFrDgIAAgELIAQgCE8NBCAEQQN0IApqIgAoAgRBtwFHDQEgACgCACgCACEEC0EBIQELIAMgBDYCHCADIAE2AhggBSgCACIAIAhJBEAgCiAAQQN0aiIAKAIAIANBCGogACgCBBECAA0GIAYgC08NBSACQXxqIQAgAigCACEBIAJBCGohAiAFQSBqIQVBASEEIAZBAWohBiADKAIgIAAoAgAgASADKAIkKAIMEQQARQ0BDAcLC0G0rsoAIAAgCBDkAgALQcSuygAgBCAIEOQCAAtBxK7KACAEIAgQ5AIACyACKAIAIQcgAigCBCIJIAJBFGooAgAiBCAEIAlLGyIIRQ0AIAIoAhAhBUEBIQQgACAHKAIAIAcoAgQgASgCDBEEAA0CIAdBDGohAkEBIQYDQCAFKAIAIANBCGogBUEEaigCABECAA0CIAYgCE8NASACQXxqIQAgAigCACEBIAJBCGohAiAFQQhqIQUgBkEBaiEGIAMoAiAgACgCACABIAMoAiQoAgwRBABFDQALDAILIAkgBksEQEEBIQQgAygCICAHIAZBA3RqIgAoAgAgACgCBCADKAIkKAIMEQQADQILQQAhBAwBC0EBIQQLIANBMGokACAEC/sFAgh/AX4jAEHQAGsiAiQAIAIgATYCLCAAKAIEIQEgAkEBOgA8IAJBAzYCOCACIAFBAWo2AjQgAkEANgIwQQEhAQNAAkAgAUH/AXFFBEAgAkEYaiACQTBqIAIoAjgQ8AQgAgJ/IAIoAhhBAUcEQEEAIQMgAigCNAwBCyACKAIcIgFBAWogAigCNCIDIAEgA0kiAxsLNgIwDAELIAJBADoAPCACQSBqIAJBMGoQ+QIgAigCJCEBIAIoAiAhAwsgAwRAIAAoAgAgAWoiASABKAIAIgFBB3ZBf3NBgYKECHEgAUH//v37B3JqNgIAIAItADwhAQwBBSAAKAIAIQECQCAAKAIEQQFqIgNBBE8EQCABIANqIAEoAAA2AAAMAQsgAUEEaiABIAMQrQIgACgCBCIBIAAoAgBqQQFqQYABQQMgAWsQwQQaCyACQRBqQQAgACgCBEEBahCmBSACIAIpAxA3AzADQCACQQhqIAJBMGoQ+QIgAigCCEUEQCAAIAAoAgQiAUEITwR/IAFBAWpBA3ZBB2wFIAELIAAoAgxrNgIQIAJB0ABqJAAPCyACKAIMIgEgACgCAGotAABBgAFHDQACQANAIAAgACgCCCABQQxsaiIDEKUEIgoQhQIhBCABIAAoAgQiBSAKpyIGcSIHayAEIAdrcyAFcUEESQ0BIAAoAgAiByAEaiIILQAAIAggBkEZdiIGOgAAIAcgBSAEQXxqcWpBBGogBjoAAEH/AUcEQCAAKAIIIARBDGxqIgQpAgAhCiAEIAMpAgA3AgAgBEEIaiIEKAIAIQUgBCADQQhqIgQoAgA2AgAgAyAKNwIAIAQgBTYCAAwBCwsgACgCACIFIAFqQf8BOgAAIAUgACgCBCABQXxqcWpBBGpB/wE6AAAgA0EIaigCACEBIAAoAgggBEEMbGoiBCADKQIANwIAIARBCGogATYCAAwBCyAAKAIAIgMgAWogBkEZdiIEOgAAIAMgBSABQXxqcWpBBGogBDoAAAwACwALAAsAC9AFAQd/QStBgIDEACAAKAIAIglBAXEiBRshCiAEIAVqIQgCQCAJQQRxRQRAQQAhAQwBCyACBEAgAiEGIAEhBQNAIAcgBS0AAEHAAXFBgAFGaiEHIAVBAWohBSAGQX9qIgYNAAsLIAIgCGogB2shCAtBASEFAkAgACgCCEEBRwRAIAAgCiABIAIQuAMNASAAKAIYIAMgBCAAQRxqKAIAKAIMEQQAIQUMAQsgAEEMaigCACIGIAhNBEAgACAKIAEgAhC4Aw0BIAAoAhggAyAEIABBHGooAgAoAgwRBAAPCwJAIAlBCHFFBEBBACEFIAYgCGsiBiEIAkACQAJAQQEgAC0AICIHIAdBA0YbQQFrDgMBAAECCyAGQQF2IQUgBkEBakEBdiEIDAELQQAhCCAGIQULIAVBAWohBQNAIAVBf2oiBUUNAiAAKAIYIAAoAgQgACgCHCgCEBECAEUNAAtBAQ8LIAAoAgQhCSAAQTA2AgQgAC0AICELIABBAToAICAAIAogASACELgDDQFBACEFIAYgCGsiASECAkACQAJAQQEgAC0AICIGIAZBA0YbQQFrDgMBAAECCyABQQF2IQUgAUEBakEBdiECDAELQQAhAiABIQULIAVBAWohBQJAA0AgBUF/aiIFRQ0BIAAoAhggACgCBCAAKAIcKAIQEQIARQ0AC0EBDwsgACgCBCEBQQEhBSAAKAIYIAMgBCAAKAIcKAIMEQQADQEgAkEBaiEHIAAoAhwhAiAAKAIYIQMDQCAHQX9qIgcEQCADIAEgAigCEBECAEUNAQwDCwsgACALOgAgIAAgCTYCBEEADwsgACgCBCEGQQEhBSAAIAogASACELgDDQAgACgCGCADIAQgACgCHCgCDBEEAA0AIAhBAWohByAAKAIcIQEgACgCGCEAA0AgB0F/aiIHRQRAQQAPCyAAIAYgASgCEBECAEUNAAsLIAULuQUCE38CfiMAQUBqIgEkABDIBCIEKAIAIQcgAUEoaiAEKAIIIgQQtgMgByAEQQN0aiEQQQAhBANAIAcgEEcEQCAHKAIAIQogASAHKAIEIgw2AhQgASAKNgIQQQAhCCABQQA2AjwgAUEQaiABQTxqEKcFIAEoAjwiDUEZdiILQQh0IAtyIglBEHQgCXIhESAEQQFqIQkgB0EIaiEHIAEoAiwiDiANcSEDIAEoAjAhEiABKAIoIRMCQAJAA0AgAyATaigAACIPIBFzIgZBf3MgBkH//ft3anFBgIGChHhxIQIgCEEEaiIIIANqIA5xIQYDQCABQQhqIAIQzAQgASgCCEUEQCAGIQMgDyAPQQF0cUGAgYKEeHFFDQIMAwsgAkF/aiACcSECIAogDCASIAEoAgwgA2ogDnFBDGxqIgUoAgAgBSgCBBC/BUUNAAsLIAUNAQsgASABQShqNgI8IAEoAjhFBEAgAUEoaiABQTxqEIQCCyABKAIsIgggDXEhA0EEIQIgASgCKCEFA0AgASAFIAMiBmooAABBgIGChHhxEMwEIAIgA2ogCHEhAyACQQRqIQIgASgCAEEBRw0ACyAFIAEoAgQgBmogCHEiAmosAABBAE4EQCAFKAIAQYCBgoR4cRDSBSECCyABIAEoAjggASgCKCIDIAJqIgYtAABBAXFrNgI4IAEoAjAhBSAGIAs6AAAgAyABKAIsIAJBfGpxakEEaiALOgAAIAJBDGwgBWoiAyAEOwEIIAMgDDYCBCADIAo2AgAgASABKAI0QQFqNgI0IAkhBAwCCyAFIAQ7AQggCSEEDAELCyABQSBqIAFBOGooAgAiBDYCACABQRhqIAFBMGopAwAiFDcDACABIAEpAygiFTcDECAAQRBqIAQ2AgAgAEEIaiAUNwIAIAAgFTcCACABQUBrJAAL8AUCA38CfiMAQfAEayIHJAAgBEHAAEcEQCAHQZgDakLJgICAgAg3AwAgB0GUA2pBqoHAADYCACAHQZADakEJNgIAIAdBAzoAiAMgByAHLwDEATsAiQMgB0GhgcAANgKMAyAHIAdBxgFqLQAAOgCLA0HzgcAAQSsgB0GIA2pBoILAAEHsg8AAEKgCAAsgB0HoBGoiBEIANwMAIAdB4ARqIghCADcDACAHQdgEaiIJQgA3AwAgB0IANwPQBCAHQdAEakEgIANBIBCuASAHQdAEahDIAyAHQaADaiAEKQMANwMAIAdBmANqIAgpAwA3AwAgB0GQA2ogCSkDADcDACAHIAcpA9AENwOIAyAHIAdBiANqELsDIAdB2ABqIgRCADcDACAHQdAAaiIIQgA3AwAgB0HIAGoiCUIANwMAIAdCADcDQCAHQUBrQSAgA0EgakEgEK4BIAdBxgFqIgMgBy0ABjoAACAHQcwBaiAHQR9qLQAAOgAAIAdB1QFqIAkpAwA3AAAgB0HdAWogCCkDADcAACAHQeUBaiAEKQMANwAAIAcgBy8BADsBgAEgByAHLQACOgCCASAHIAcvAQQ7AcQBIAcgBygAGzYCyAEgByAHKQNANwDNASAHKQAHIQogBykADyELIAcoABchBCAHLQADIQggB0GIA2ogB0HIAWpBJRDyAxogByAIOgCDASAHIAQ2AJcBIAcgCzcAjwEgByAKNwCHASAHIAcvAcQBOwGEASAHIAMtAAA6AIYBIAdBmwFqIAdBiANqQSUQ8gMaIAdBiANqIAEgAhBeIAdByAFqIAdBiANqQYiEwAAQxwIgB0FAayAHQYABaiAFIAYgB0HIAWoQ4wEgB0GIA2pBAEHAABDBBBogB0GIA2pBICAHQUBrQSAQrgEgB0GoA2pBICAHQeAAakEgEK4BIAcgBy0AxwNBgAFyOgDHAyAAIAcgB0GIA2pBwAAQ8gMiAEHAABCcAyAAQYABahCfASAAQfAEaiQAC7IFARB/IwBBgAJrIgQkACAEQfgAaiIFIANBGGopAAA3AwAgBEHwAGoiBiADQRBqKQAANwMAIARB6ABqIgcgA0EIaikAADcDACAEIAMpAAA3A2AgBEHAAWogASACIARB4ABqEO0BIARBGGoiAyAEQdgBaikDADcDACAEQRBqIgggBEHQAWopAwA3AwAgBEEIaiIJIARByAFqKQMANwMAIAQgBCkDwAE3AwAgBEE4aiIKIARB+AFqIgspAwA3AwAgBEEwaiIMIARB8AFqIg0pAwA3AwAgBEEoaiIOIARB6AFqIg8pAwA3AwAgBCAEKQPgATcDICAEQdgAaiIQQgA3AwAgBEHQAGoiEUIANwMAIARByABqIhJCADcDACAEQgA3A0AgBEHAAWpBAEHAABDBBBogBEHgAGogAUHAAWoQ1gMgBEHAAWpBICAEQeAAakEgEK4BIARB4AFqQSAgAUHgAWoiE0EgEK4BIARB4ABqIARBwAFqQcAAEPIDGiAEQawBakHAADYCACAEQSA2AqQBIAQgEzYCoAEgBCAEQeAAajYCqAEgAkHmhsAAQQogBEFAa0EgIARBoAFqQQIQigUgBEG4AWogAUHYAWopAAA3AwAgBEGwAWogAUHQAWopAAA3AwAgBEGoAWogAUHIAWopAAA3AwAgBCABKQDAATcDoAEgBSADKQMANwMAIAYgCCkDADcDACAHIAkpAwA3AwAgBCAEKQMANwNgIARBwAFqIARBoAFqIARB4ABqEBIgDyASKQMANwMAIA0gESkDADcDACALIBApAwA3AwAgBCAEKQNANwPgASAAIARBwAFqQcAAEPIDIgBB2ABqIAopAwA3AAAgAEHQAGogDCkDADcAACAAQcgAaiAOKQMANwAAIAAgBCkDIDcAQCACELcFIARBgAJqJAALpQUBBH8jAEGAFGsiBCQAIARBCGogAUEFEGcgBEGIAmogA0EIEGdBgAIhBUH/ASEGQf8BIQcDQAJAIAchAyAGIgFBf0YNACAEQQhqIAFqLQAABEAgASEDDAELIAFBf2ohBiABIQcgBUF/aiIFIQMgBEGIAmogAWotAABFDQELCyAEQYgEaiACEMcBIARBiA5qQQBBKBDBBBogBEG4DmpCADcDACAEQcAOakIANwMAIARByA5qQgA3AwAgBEHQDmpCADcDACAEQeAOakIANwMAIARB6A5qQgA3AwAgBEHwDmpCADcDACAEQfgOakIANwMAIARCATcDsA4gBEIBNwPYDgNAIARBgA9qIARBiA5qEKMBAkAgBEGAD2oCfyAEQQhqIANqLAAAIgFBAU4EQCAEQcARaiAEQYAPahCDAiAEQeASaiAEQYgEaiABEPgDIARBoBBqIARBwBFqIARB4BJqEJIBIARBoBBqDAELIAFBf0oNASAEQcARaiAEQYAPahCDAiAEQeASaiAEQYgEakEAIAFrQRh0QRh1EPgDIARBoBBqIARBwBFqIARB4BJqEJMBIARBoBBqC0GgARDyAxoLAkAgBEGAD2oCfyAEQYgCaiADaiwAACIBQQFOBEAgBEHgEmogBEGAD2oQgwIgBEGgEGogARD5AyAEQcARaiAEQeASaiAEQaAQahCZASAEQcARagwBCyABQX9KDQEgBEHgEmogBEGAD2oQgwIgBEGgEGpBACABa0EYdEEYdRD5AyAEQcARaiAEQeASaiAEQaAQahCaASAEQcARagtBoAEQ8gMaCyAEQeASaiAEQYAPahDyAiAEQYgOaiAEQeASakH4ABDyAxogAwRAIANBf2ohAwwBCwsgACAEQYgOahCWAiAEQYAUaiQAC6UFAQR/IwBBgBRrIgQkACAEQQhqIAFBBRBnIARBiAJqIANBCBBnQYACIQVB/wEhBkH/ASEHA0ACQCAHIQMgBiIBQX9GDQAgBEEIaiABai0AAARAIAEhAwwBCyABQX9qIQYgASEHIAVBf2oiBSEDIARBiAJqIAFqLQAARQ0BCwsgBEGIBGogAhDIASAEQYgOakEAQSgQwQQaIARBuA5qQgA3AwAgBEHADmpCADcDACAEQcgOakIANwMAIARB0A5qQgA3AwAgBEHgDmpCADcDACAEQegOakIANwMAIARB8A5qQgA3AwAgBEH4DmpCADcDACAEQgE3A7AOIARCATcD2A4DQCAEQYAPaiAEQYgOahCjAQJAIARBgA9qAn8gBEEIaiADaiwAACIBQQFOBEAgBEHAEWogBEGAD2oQgwIgBEHgEmogBEGIBGogARD6AyAEQaAQaiAEQcARaiAEQeASahCSASAEQaAQagwBCyABQX9KDQEgBEHAEWogBEGAD2oQgwIgBEHgEmogBEGIBGpBACABa0EYdEEYdRD6AyAEQaAQaiAEQcARaiAEQeASahCTASAEQaAQagtBoAEQ8gMaCwJAIARBgA9qAn8gBEGIAmogA2osAAAiAUEBTgRAIARB4BJqIARBgA9qEIMCIARBoBBqIAEQ+wMgBEHAEWogBEHgEmogBEGgEGoQmQEgBEHAEWoMAQsgAUF/Sg0BIARB4BJqIARBgA9qEIMCIARBoBBqQQAgAWtBGHRBGHUQ+wMgBEHAEWogBEHgEmogBEGgEGoQmgEgBEHAEWoLQaABEPIDGgsgBEHgEmogBEGAD2oQ8gIgBEGIDmogBEHgEmpB+AAQ8gMaIAMEQCADQX9qIQMMAQsLIAAgBEGIDmoQlgIgBEGAFGokAAv/BAEFfyMAQYABayIEJAAgBEEFOgAYAkACQAJAAkACQCABKAIAIgVBAUYgBUF+akECS3JFBEAgBEEgaiACIAMQYSAEKAIgQQFHDQEgBEHgAGogBEEYaiIDKAIAIgI2AgAgBEHYAGogBEEQaiIFKQMANwMAIAQgBCkDCDcDUCAEQfgAaiAEQTRqKAIANgIAIARB8ABqIARBLGopAgA3AwAgBCAEKQIkNwNoIARBQGsiBiAEQegAaiAEQdAAaiACQf8BcUEFRiIHGyICQQhqKQIANwMAIARByABqIgggAkEQaigCADYCACAEIAIpAgA3AzggBEHQAGogBEHoAGogBxsQmAUgBSAGKQMANwMAIAMgCCgCADYCACAEIAQpAzg3AwgMBAsgBEEgaiABIAIgAxCnASAELQAwQQVHDQEgAEEFOgAQIARBIGoQmAUMAgsgBEEoaigCACECIAQoAiQhAyABKAIAIgVBAUdBACAFQX5qQQNJG0UEQCABEIwFCyABIAI2AgQgASADNgIAIABBBToAEAwBCyAEQQhqEJgFIARBGGogBEEwaigCADYCACAEQRBqIARBKGopAwA3AwAgBCAEKQMgNwMIDAELIARBCGoQmAUMAQsgASgCACIBQX5qIQIgAUECRyACQQJLckUEQEGh+ckAQShBzPnJABC5BAALIAFBA0ZBACACQQJNG0UEQCAELQAYQQVHBEAgBEEwaiAEQRhqKAIANgIAIARBKGogBEEQaikDADcDACAEIAQpAwg3AyAgACAEQSBqEM8CDAILIABB6/jJAEEcEPwEIARBCGoQmAUMAQtBofnJAEEoQcz5yQAQuQQACyAEQYABaiQAC5sFAQF/IwBB8AZrIgIkACACQQhqIAEQmgIgAkEwaiACQQhqEEMCQAJAAkAgAkEwaiABEIwDQf8BcUUgAkEIahDCBEH/AXFBAUZyRQRAIAJB4ABqQgA3AwAgAkHoAGpCADcDACACQfAAakIANwMAIAJCADcDWCACQgE3A1AgAkH4AGogAkEIahDIBSACQaABaiACQdAAaiACQfgAahDfASACQcgBaiACQdAAaiACQfgAahDVAyACQfABaiACQcgBahDIBSACQbAEakGAucQAENkDIAJB0AVqIAJBoAFqEMgFIAJBiARqIAJBsARqIAJB0AVqEB4gAkGYAmogAkGIBGogAkHwAWoQ3wEgAkGwBGogAkGYAmogAkHwAWoQHiACQdAFaiACQbAEahCwAyACLQDQBSACQcACaiACQdgFakEoEPIDGiACQegCaiACQcACaiACQcgBahAeIAJB0AVqIAJB6AJqIAJBmAJqEB4gAkGQA2ogAkHAAmogAkHQBWoQHiACQdAFaiACQQhqIAJBCGoQ1QMgAkG4A2ogAkHQBWogAkHoAmoQHiACQbgDaiACQbgDahDCBBCrBCACQeADaiACQaABaiACQZADahAeIAJBiARqIAJBuANqIAJB4ANqEB5FDQIgAkGIBGoQwgRB/wFxQQFHDQEMAgsgAEIANwMADAILIAJB4ANqEJUDQf8BcUEBRg0AIAJB0AVqIAJBuANqQSgQ8gMaIAJB+AVqIAJB4ANqQSgQ8gMaIAJBoAZqIAJB0ABqQSgQ8gMaIAJByAZqIAJBiARqQSgQ8gMaIAJBsARqIAJB0AVqQaABEPIDGiAAQQhqIAJBsARqQaABEPIDGiAAQgE3AwAMAQsgAEIANwMACyACQfAGaiQAC5UGAgZ/BH4jAEHgAGsiAyQAIABBMGohBgJAIABB0ABqKAIAIgRFBEAgAiEEDAELIANBKGogASACIAJBICAEayIEIAQgAksbIgUQngQgAygCLCEHIAMoAighCCADQSBqIAUgAiABIAIQ1AMgAygCJCEEIAMoAiAhASADQRhqIAAoAlBBICAGQSAQ1AMgA0EQaiADKAIYIAMoAhwgBRCeBCADKAIQIAMoAhQgCCAHELIBIAAgACgCUCAFaiIFNgJQIAVBIEcNACADQQhqIAYQnwQgAyADKQMINwMwIABBKGopAwAhCSAAQSBqKQMAIQogAEEYaikDACELIAApAxAhDANAIANBOGogA0EwahCQAiADKQM4QgFRBEAgAykDWELP1tO+0ser2UJ+IAl8Qh+JQoeVr6+Ytt6bnn9+IQkgAykDUELP1tO+0ser2UJ+IAp8Qh+JQoeVr6+Ytt6bnn9+IQogAykDSELP1tO+0ser2UJ+IAt8Qh+JQoeVr6+Ytt6bnn9+IQsgAykDQELP1tO+0ser2UJ+IAx8Qh+JQoeVr6+Ytt6bnn9+IQwMAQsLIABBADYCUCAAIAk3AyggACAKNwMgIAAgCzcDGCAAIAw3AxALIAQEQCADIAQ2AjQgAyABNgIwIABBKGopAwAhCSAAQSBqKQMAIQogAEEYaikDACELIAApAxAhDANAIANBOGogA0EwahCQAiADKQM4QgFRBEAgAykDWELP1tO+0ser2UJ+IAl8Qh+JQoeVr6+Ytt6bnn9+IQkgAykDUELP1tO+0ser2UJ+IAp8Qh+JQoeVr6+Ytt6bnn9+IQogAykDSELP1tO+0ser2UJ+IAt8Qh+JQoeVr6+Ytt6bnn9+IQsgAykDQELP1tO+0ser2UJ+IAx8Qh+JQoeVr6+Ytt6bnn9+IQwMAQsLIAAgCTcDKCAAIAo3AyAgACALNwMYIAAgDDcDECADKAIwIQQgAyAGQSAgAygCNCIBEJ4EIAMoAgAgAygCBCAEIAEQsgEgACABNgJQCyAAIAApAwAgAq18NwMAIANB4ABqJAALsQMBBX8jAEEQayICJAAgAkECciEEQeT5ygAoAgAhAQJAAkADQAJAAkAgAUEDSw0AAkACQCABQQFrDgMAAgUBC0G4o8oAQSpB5KPKABC8BAALQeT5ygBB5PnKACgCACIBQQIgARs2AgAgAQ0CDAELIAFBA3FBAkcNAwJAAkADQEH4+coAKAIAQQFHBEBB+PnKAEIBNwIAQYD6ygBBADYCAAsgASEDEJsBIQVB5PnKACAEQeT5ygAoAgAiASABIANGGzYCACACQQA6AAggAiAFNgIAIAIgA0F8cTYCBAJAIAEgA0YEQCACLQAIRQ0BDAMLAkAgAigCACIDRQ0AIAMgAygCACIDQX9qNgIAIANBAUcNACACENICCyABQQNxQQJGDQEMAwsLA0AQRSACLQAIRQ0ACwsgAigCACIBRQ0AIAEgASgCACIBQX9qNgIAIAFBAUcNACACENICQeT5ygAoAgAhAQwCC0Hk+coAKAIAIQEMAQsLIAJB5PnKADYCACAAQQBBnIzKACgCABEAACACQQM2AgQgAhBVCyACQRBqJAAPC0HvosoAQTlBqKPKABC8BAALtgMBA38jAEHQBGsiAiQAIAJBIGoQsgMgAkEgaiABEMYFIAJBuAJqIAJBIGpB2AEQ8gMaIAJB+AFqIAJBuAJqEO4DIAJBqARqIgFCADcDACACQaAEaiIDQgA3AwAgAkGYBGoiBEIANwMAIAJCADcDkAQgAkEYaiACQfgBahCpBSACQRBqQQBBICACKAIYIAIoAhwQ1AMgAkGQBGpBICACKAIQIAIoAhQQrQEgAiACLQCQBEH4AXE6AJAEIAIgAi0ArwRBP3FBwAByOgCvBCACQZAEahDIAyACQdACaiABKQMANwMAIAJByAJqIAMpAwA3AwAgAkHAAmogBCkDADcDACACIAIpA5AENwO4AiAAIAJBuAJqELsDIAJByARqIgFCADcDACACQcAEaiIDQgA3AwAgAkG4BGoiBEIANwMAIAJCADcDsAQgAkEIaiACQfgBahCpBSACQSBBwAAgAigCCCACKAIMENQDIAJBsARqQSAgAigCACACKAIEEK0BIABBOGogASkDADcAACAAQTBqIAMpAwA3AAAgAEEoaiAEKQMANwAAIAAgAikDsAQ3ACAgAkHQBGokAAuUBQIGfwF+IwBB4ABrIggkACAIQQI6ACAgCEEIakGU7ckAELcEAn8gCCgCCARAIAhBOGoQSSAIQRBqEJcEIAhBEGogCEE4akEoEPIDGiAIQRBqIAgtACBBAkcNARpB6OzJAEErQYDuyQAQzgMACyAIKAIMCyEGIAEQxAIhBwJ/AkACQCACQezqyQAoAgARBgAEQCAFKQMAIQwgBkEANgIYIAYgDDwAJCAGQQA2AiAgBiABNgIUIAZBAToAECAHKAIoQRhqIAdBJGogBygCJBsgBjYCACAHIAY2AiggB0EgahDQBCADQYDryQAoAgARAwAgBSkDAEIBUQ0BIAYQ5gEMAgsgB0EgahDQBEEBDAILIAYgBSkDCCAFQRBqKAIAEIsBDQACQANAAkAQkAMhASAGKAIUIgtBufPd8XlsQQAgASgCCGtBH3F2IgkgASgCBCICTw0AIAEoAgAiCiAJQfAAbGpBIGoiAhDxBCABQaDYygAoAgBGBEAgBigCFCALRg0DCyACENAEDAELC0HA7skAIAkgAhDkAgALAkAgBCALAn8CQCAGELMDBEAgCiAJQfAAbGoiAUEkaiEDIAEoAiQhBUEAIQcDQCADIQEgByECIAUiB0UNBCAHQRhqIQMgBygCGCEFIAYgB0cNAAsgASAFNgIAIAYgCiAJQfAAbGoiASgCKEYEQCABQShqIAI2AgAMAgsDQCAFRQ0CIAsgBSgCFEcEQCAFKAIYIQUMAQsLQQAMAgsgCiAJQfAAbGpBIGoQ0AQMAwtBAQsiB0GU68kAKAIAEQEACyAKIAlB8ABsakEgahDQBEECDAELIAYoAhwhB0EACyEBIAhBEGoQlwQgACAHNgIEIAAgATYCACAIQeAAaiQAC8oEAQV/IwBBEGsiBCQAIAAoAgAhAAJAAkACQAJAAkACQCABQYABTwRAIARBADYCDCABQYAQSQ0BIARBDGohBSABQYCABEkEQCAEIAFBP3FBgAFyOgAOIAQgAUEGdkE/cUGAAXI6AA0gBCABQQx2QQ9xQeABcjoADEEDIQEMBAsgBCABQT9xQYABcjoADyAEIAFBEnZB8AFyOgAMIAQgAUEGdkE/cUGAAXI6AA4gBCABQQx2QT9xQYABcjoADUEEIQEMAwsgACgCCCICIABBBGooAgBHBEAgACgCACEDDAILIAJBAWoiAyACSQ0DIAJBAXQiBSADIAUgA0sbIgVBAEgNAwJ/IAJFBEAgBUEBEKQFDAELIAAoAgAgAkEBIAUQlAULIgMEQCAAIAM2AgAgAEEEaiAFNgIAIAAoAgghAgwCCyAFQQEQ3QUACyAEIAFBP3FBgAFyOgANIAQgAUEGdkEfcUHAAXI6AAwgBEEMaiEFQQIhAQwBCyACIANqIAE6AAAgACAAKAIIQQFqNgIIDAMLIABBBGooAgAiAyAAQQhqKAIAIgJrIAFPBEAgACgCACEDDAILIAEgAmoiBiACSQ0AIANBAXQiAiAGIAIgBksbIgJBAEgNAAJ/IANFBEAgAkEBEKQFDAELIAAoAgAgA0EBIAIQlAULIgMEQCAAIAM2AgAgAEEEaiACNgIAIABBCGooAgAhAgwCCyACQQEQ3QUACxDCBQALIABBCGogASACajYCACACIANqIAUgARDyAxoLIARBEGokAEEAC8EEAQV/IwBBEGsiBCQAAkACQAJAAkACQAJAIAFBgAFPBEAgBEEANgIMIAFBgBBJDQEgBEEMaiEFIAFBgIAESQRAIAQgAUE/cUGAAXI6AA4gBCABQQZ2QT9xQYABcjoADSAEIAFBDHZBD3FB4AFyOgAMQQMhAQwECyAEIAFBP3FBgAFyOgAPIAQgAUESdkHwAXI6AAwgBCABQQZ2QT9xQYABcjoADiAEIAFBDHZBP3FBgAFyOgANQQQhAQwDCyAAKAIIIgIgAEEEaigCAEcEQCAAKAIAIQMMAgsgAkEBaiIDIAJJDQMgAkEBdCIFIAMgBSADSxsiBUEASA0DAn8gAkUEQCAFQQEQpAUMAQsgACgCACACQQEgBRCUBQsiAwRAIAAgAzYCACAAQQRqIAU2AgAgACgCCCECDAILIAVBARDdBQALIAQgAUE/cUGAAXI6AA0gBCABQQZ2QR9xQcABcjoADCAEQQxqIQVBAiEBDAELIAIgA2ogAToAACAAIAAoAghBAWo2AggMAwsgAEEEaigCACIDIABBCGooAgAiAmsgAU8EQCAAKAIAIQMMAgsgASACaiIGIAJJDQAgA0EBdCICIAYgAiAGSxsiAkEASA0AAn8gA0UEQCACQQEQpAUMAQsgACgCACADQQEgAhCUBQsiAwRAIAAgAzYCACAAQQRqIAI2AgAgAEEIaigCACECDAILIAJBARDdBQALEMIFAAsgAEEIaiABIAJqNgIAIAIgA2ogBSABEPIDGgsgBEEQaiQAC8gEAQZ+IAAgASkDICIDQjOIQhN+IAEpAwAiAkL/////////A4N8IgRCE3xCM4ggASkDCCIFQv////////8DgyACQjOIfCICfEIziCABKQMQIgZC/////////wODIAVCM4h8IgV8QjOIIAEpAxgiB0L/////////A4MgBkIziHwiBnxCM4ggA0L/////////A4MgB0IziHwiB3xCM4hCE34gBHwiAzwAACAAIANCKIg8AAUgACADQiCIPAAEIAAgA0IYiDwAAyAAIANCEIg8AAIgACADQgiIPAABIAAgA0IziCACfCIEQiWIPAALIAAgBEIdiDwACiAAIARCFYg8AAkgACAEQg2IPAAIIAAgBEIFiDwAByAAIARCM4ggBXwiAkIqiDwAEiAAIAJCIog8ABEgACACQhqIPAAQIAAgAkISiDwADyAAIAJCCog8AA4gACACQgKIPAANIAAgA0IwiEIHgyAEQv////////8DgyIEQgOGhDwABiAAIAJCM4ggBnwiA0IniDwAGCAAIANCH4g8ABcgACADQheIPAAWIAAgA0IPiDwAFSAAIANCB4g8ABQgACACQv////////8DgyIFQgaGIARCLYiEPAAMIAAgA0IziCAHfCICQiSIPAAeIAAgAkIciDwAHSAAIAJCFIg8ABwgACACQgyIPAAbIAAgAkIEiDwAGiAAIANC/////////wODIgNCAYYgBUIyiIQ8ABMgACACQv////////8DgyICQiyIPAAfIAAgAkIEhiADQi+IhDwAGQuvBAEBfyMAQfAAayIDJAAgAyABOgALAkACQAJAIAJFBEAgAyABQQhxIgI6AAwgAg0CIAAgAToAygEgAC0AyQEhAiAAIAAtAMgBQQFqOgDJASADIAE6AFkgAyACOgBYIAAgA0HYAGpBAhDBAiADLQALQSRxRQ0BIAAtAMgBRQ0BIAAQnAIMAQsgAC0AygEgAUH/AXFHDQILIANB8ABqJAAPCyADQcwAakEhNgIAIANBxABqQSI2AgAgA0E0akEDNgIAIAMgA0EMajYCVCADQbD2wwA2AhAgA0HsAGpBADYCACADQgM3AiQgA0GI9cMANgIgIANBIjYCPCADQYDzwwA2AmggA0IBNwJcIANB8PbDADYCWCADIANBOGo2AjAgAyADQdgAajYCSCADIANBEGo2AkAgAyADQdQAajYCOCADQSBqQfj2wwAQvQQACyADQcwAakEhNgIAIANBxABqQSI2AgAgAyAAQcoBaiIANgIMIAMgA0ELajYCVCADQewAakECNgIAIANB5ABqQQI2AgAgA0EcakEjNgIAIANBIjYCPCADQeD1wwA2AmAgA0ECNgJcIANB0PXDADYCWCADQSM2AhQgAyAANgIQIAMgA0HYAGo2AkggAyADQdQAajYCQCADIANBDGo2AjggAyADQRBqNgJoIAMgA0ELajYCGCADQTRqQQM2AgAgA0IDNwIkIANBiPXDADYCICADIANBOGo2AjAgA0EgakGg9sMAEL0EAAvxBAEGfyMAQeAAayIAJABB+PnKACgCAEEBRwRAQfj5ygBCATcCAEGA+soAQQA2AgALEJsBIgFBACABKAIYIgIgAkECRiICGzYCGCAAIAE2AggCQCACDQACQAJAAkAgACgCCCIBQRxqIgQoAgAiAi0AAEUEQCACQQE6AABBACECAkBBiPrKACgCAEEBRgRAQYz6ygAoAgAhAgwBC0GI+soAQgE3AwALQYz6ygAgAjYCACABLQAgDQEgASABKAIYIgNBASADGzYCGCADRQRAIAAoAghBJGogBCgCABCoBEEAEMAFAAsgA0ECRw0CIAAoAggiBSgCGCEDIAVBADYCGCAAIAM2AgwgA0ECRw0DAkAgAg0AQYj6ygAoAgBBAUcEQEGI+soAQgE3AwAMAQtBjPrKACgCAEUNACABQQE6ACALIAQoAgBBADoAAAwEC0Hop8oAQSBBpKjKABC8BAALIAAgBDYCSCAAIAJBAEc6AExB9JzKAEErIABByABqQaCdygBB4J7KABCoAgALQfCeygBBF0GIn8oAELwEAAsgAEE8akEhNgIAIABBNGpBkgE2AgAgAEEkakEDNgIAIAAgAEEMajYCQCAAQZifygA2AkQgAEHcAGpBADYCACAAQgM3AhQgAEGAnMoANgIQIABBkgE2AiwgAEHsm8oANgJYIABCATcCTCAAQbyfygA2AkggACAAQShqNgIgIAAgAEHIAGo2AjggACAAQcQAajYCMCAAIABBQGs2AiggAEEQakHEn8oAEKkEAAsgACgCCCIBIAEoAgAiAUF/ajYCACABQQFGBEAgAEEIahDSAgsgAEHgAGokAAuFBAEHfyMAQTBrIgMkAAJ/QQAgAkUNABogA0EoaiEIAkACQAJAAkADQCAAKAIILQAABEAgACgCAEGcrMoAQQQgACgCBCgCDBEEAA0FCyADQQo2AiggA0KKgICAEDcDICADIAI2AhwgA0EANgIYIAMgAjYCFCADIAE2AhAgA0EIakEKIAEgAhBlAn8CQAJAIAMoAghBAUYEQCADKAIMIQQDQCADIAQgAygCGGpBAWoiBDYCGAJAIAQgAygCJCIFSQRAIAMoAhQhBwwBCyADKAIUIgcgBEkNACAFQQVPDQcgBCAFayIGIAMoAhBqIgkgCEYNBCAJIAggBRC0A0UNBAsgAygCHCIGIARJIAcgBklyDQIgAyADIAVqQSdqLQAAIAMoAhAgBGogBiAEaxBlIAMoAgQhBCADKAIAQQFGDQALCyADIAMoAhw2AhgLIAAoAghBADoAACACDAELIAAoAghBAToAACAGQQFqCyEEIAAoAgQhBSAAKAIAIARFIAIgBEZyIgZFBEAgAiAETQ0DIAEgBGosAABBv39MDQMLIAEgBCAFKAIMEQQADQQgBkUEQCACIARNDQQgASAEaiwAAEG/f0wNBAsgASAEaiEBIAIgBGsiAg0AC0EADAQLIAVBBBDlAgALIAEgAkEAIAQQKQALIAEgAiAEIAIQKQALQQELIANBMGokAAvsAwEKfwNAAkBBACEIIAEtAB0NACABKAIIIQoCfwJAA0AgASgCGCICIAEoAhQiBEYNASABIARBAWoiAzYCFAJAAkAgBCwAACIFQX9MBEACfyACIANGBEBBACEGIAIMAQsgASAEQQJqIgM2AhQgBC0AAUE/cSEGIAMLIQcgBUEfcSEJIAVB/wFxIgtB3wFLDQEgBiAJQQZ0ciECDAILIAVB/wFxIQIMAQsCfyACIAdGBEBBACEHIAIMAQsgASAHQQFqIgM2AhQgBy0AAEE/cSEHIAMLIQUgByAGQQZ0ciEGIAtB8AFJBEAgBiAJQQx0ciECDAELIAIgBUYEf0EABSABIAVBAWoiAzYCFCAFLQAAQT9xCyAJQRJ0QYCA8ABxIAZBBnRyciICQYCAxABGDQILIAEgASgCECIFIAMgBGtqIgQ2AhAgAkF3aiIDQRdNQQBBASADdEGfgIAEcRtFBEAgAkGAAUkNASACEPcBRQ0BCwsgASgCACEDIAEgBDYCACADIApqIQggBSADawwBCyABLQAdDQECQCABLQAcBEAgASgCBCEDIAEoAgAhAgwBCyABKAIEIgMgASgCACICRg0CCyABQQE6AB0gASgCCCACaiEIIAMgAmsLIgRFDQELCyAAIAQ2AgQgACAINgIAC4wEAQJ/IwBBwARrIgIkACACQQhqIAFBKBDyAxogAkEwaiABQShqQSgQ8gMaIAJBmARqIAFB0ABqIgMgAkEwahDVAyACQdABaiADIAJBMGoQ3wEgAkHYAGogAkGYBGogAkHQAWoQHiACQYABaiACQQhqIAJBMGoQHiACQZgEaiACQYABahDIBSACQfADaiACQdgAaiACQZgEahAeIAJB0AFqIAJB8ANqELADIAJBqAFqIAJB2AFqQSgQ8gMaIAJBgAJqIAJBqAFqIAJB2ABqEB4gAkGoAmogAkGoAWogAkGAAWoQHiACQdABaiACQagCaiABQfgAaiIBEB4gAkHQAmogAkGAAmogAkHQAWoQHiACQfgCaiACQagCakEoEPIDGiACQaADaiACQQhqQai5xAAQHiACQcgDaiACQTBqQai5xAAQHiACQfADaiACQYACakHQucQAEB4gAkHQAWogASACQdACahAeIAJBCGogAkHIA2ogAkHQAWoQwgQiARCIAiACQTBqIAJBoANqIAEQiAIgAkH4AmogAkHwA2ogARCIAiACQdABaiACQQhqIAJB0AJqEB4gAkEwaiACQdABahDCBBCrBCACQdABaiADIAJBMGoQ3wEgAkGYBGogAkH4AmogAkHQAWoQHiACQZgEaiACQZgEahDCBBCrBCAAIAJBmARqEEMgAkHABGokAAu5BAELfyMAQRBrIggkAEGc2MoAQZzYygAoAgBBAWoiBjYCAAJAQaDYygAoAgBFBEAgBkEAEJ0BIQFBoNjKAEGg2MoAKAIAIgIgASACGzYCACACRQ0BIAggATYCDCAIQQxqEP4DCyAGQQNsIQQDQEGg2MoAKAIAIgMoAgQiAiAETw0BIAJB8ABsIQEgAygCACECA0AgAQRAIAJBIGoQ8QQgAUGQf2ohASACQfAAaiECDAEFIANBoNjKACgCAEcEQCADKAIEQfAAbCEBIAMoAgAhAgNAIAFFDQQgAkEgahDQBCABQZB/aiEBIAJB8ABqIQIMAAsACyAGIAMQnQEhBSADKAIAIgEgAygCBEHwAGxqIQkCQAJAA0AgASAJRwRAIAFB8ABqIQIgASgCJCEBA0AgAUUEQCACIQEMAwsgASgCFEG5893xeWxBACAFKAIIa0EfcXYiByAFKAIEIgRPDQMgASgCGCAHQfAAbCILIAUoAgBqIgYoAigiBEEYaiAGQSRqIAQbIAE2AgAgByAFKAIEIgRPDQQgBSgCACALaiABNgIoIAFBADYCGCEBDAALAAsLQaDYygAgBTYCACADKAIEQfAAbCEBIAMoAgAhAgNAIAFFDQYgAkEgahDQBCABQZB/aiEBIAJB8ABqIQIMAAsAC0GQ7skAIAcgBBDkAgALQaDuyQAgByAEEOQCAAsACwALAAsgABDoAyAAQSRqQQA6AAAgAEEcakIANwIAIABCADcCFCAIQRBqJAALhgQBBn8jAEEgayIIJAAgASgCFCEHA0ACQCAFIAdqIgdBf2oiCSADTwRAIAEgAzYCFEEAIQcMAQsCQCABKQMAQgEgAiAJajEAAEI/g4aDUA0AIAEoAgghByAIQRhqIAYEfyAHBSAHIAEoAhwiCSAHIAlLGwsgBRCmBSAIKAIcIQogCCgCGCEHAkACQANAAkAgByAKSQRAIAdBAWoiCSAHTw0BCyAIQRBqQQAgASgCHCAGGyABKAIIEKYFIAhBCGogCCgCECAIKAIUEKYFIAEoAhQhCiAIKAIMIQcgCCgCCCEJAkACQANAIAkgB08EQCABIAUgCmoiAjYCFCAGRQRAIAFBADYCHAsgACAKNgIEIABBCGogAjYCAEEBIQcMCQsgB0F/aiIHIAVPDQEgByAKaiILIANPDQIgBCAHai0AACACIAtqLQAARg0ACyABIAEoAhAiCSAKaiIHNgIUIAYNCCABIAUgCWs2AhwMCAtBkPHIACAHIAUQ5AIAC0Gg8cgAIAsgAxDkAgALIAcgBU8NASABKAIUIAdqIgwgA08NAiAEIAdqIAkhBy0AACACIAxqLQAARg0ACyAMIAEoAghrQQFqIQcMAgtB8PDIACAHIAUQ5AIAC0GA8cgAIAwgAxDkAgALIAEgBzYCFCAGDQEgAUEANgIcDAELCyAAIAc2AgAgCEEgaiQAC/MDAgd/An4jAEHgAGsiAyQAIAMgAjYCDCADQTBqIAEQWyADIAMpATI3AyAgAyADQThqIgIpAQA3ASYCfwJAIAMtADBBAUcEQCADQcQAaigCACEEIANBGGogA0EqaigBACIFNgIAIAMgAykBIiIKNwMQIAAoAgwhASACIAU2AgAgAyAKNwMwIAMgBCABazYCQCADIAE2AjwgACgCACICIAAoAgRqQQFqIQggAigCAEF/c0GAgYKEeHEhASAAKAIIIQQMAQsgAy0AMUEARwwBCwNAIAMgARDMBCADKAIAQQFGBEAgA0EwaiAEIAMoAgRBDGxqIgUQpQQiChCFAiIGIAMoAjAiB2ogCqdBGXYiCToAACAHIAMoAjQgBkF8anFqQQRqIAk6AAAgBUEIaigCACEHIAMoAjggBkEMbGoiBiAFKQIANwIAIAZBCGogBzYCACABQX9qIAFxIQEMAQsgAkEEaiICIAhJBEAgBEEwaiEEIAIoAgBBf3NBgIGChHhxIQEMAQsLIAApAgAhCiAAIAMpAzA3AgAgA0E4aiIBKQMAIQsgASAAQQhqIgEpAgA3AwAgASALNwIAIANBQGsiASgCACECIAEgAEEQaiIAKAIANgIAIAAgAjYCACADIAo3AzAgA0EwahDYAkECCyADQeAAaiQAC+UDAgx/AX4gAiAFayEPQQAgBWshECABKAIQIQ0gASgCDCEKIAEpAwAhEyABKAIYIQgCQAJAA0AgCCAFayIJIANPBEBBACEHIAFBADYCGAwDC0IBIAIgCWoxAABCP4OGIBODUARAIAEgCTYCGCAJIQggBg0BIAEgBTYCIAwBCyAKIQcgCCAPaiEOIAYEfyAHBSABKAIgIgcgCiAKIAdLGwtBf2ohBwJAA0AgB0F/RgRAIAUgASgCICAGGyELIAggEGohDCAKIQcCQAJAA0AgByALTwRAIAEgCTYCGCAGRQRAIAEgBTYCIAsgACAJNgIEIABBCGogCDYCAEEBIQcMCQsgByAFTw0BIAcgDGogA08NAiAHIA5qIREgBCAHaiAHQQFqIQctAAAgES0AAEYNAAsgASAIIA1rIgg2AhggBg0FIAEgDTYCIAwFC0HYlsoAIAcgBRDkAgALQeiWygAgCCAFayAHaiADEOQCAAsgByAFTw0BIAcgCWogA08NAyAHIA5qIQsgBCAHaiAHQX9qIQctAAAgCy0AAEYNAAsgASAIIAprIAdqQQFqIgg2AhggBg0BIAEgBTYCIAwBCwtBuJbKACAHIAUQ5AIAC0HIlsoAIAggBWsgB2ogAxDkAgALIAAgBzYCAAuWBAIGfwR+IwBBwAFrIgIkACACQQhqQQBBwAAQwQQaA0ACQCADQQhHBEAgA0EBaiEHIAJBCGogA0EDdGohBUEAIQMgBiEEA0AgA0HAAEYNAiAEQcAARwRAIAUgBSkDACABIARqMQAAIANBOHGthoQ3AwAgA0EIaiEDIARBAWohBAwBCwtBnLvEACAEQcAAEOQCAAsgAiACKQMIIghC/////////weDNwNIIAIgAikDQCILQhSINwOQASACIAIpAygiCUIEiEL/////////B4M3A3AgAiACKQMQIgpCDIZCgOD//////weDIAhCNIiENwNQIAIgAikDGCIIQhiGQoCAgPj///8HgyAKQiiIhDcDWCACIAIpAyAiCkIkhkKAgICAgP7/B4MgCEIciIQ3A2AgAiAJQjCGQoCAgICAgMAHgyAKQhCIhDcDaCACIAIpAzAiCEIIhkKA/v//////B4MgCUI4iIQ3A3ggAiACKQM4IglCFIZCgIDA/////weDIAhCLIiENwOAASACIAtCIIZCgICAgPD//weDIAlCIIiENwOIASACQZgBaiACQcgAakGwu8QAEBYgAkHIAGogAkGYAWpBKBDyAxogAkGYAWogAkHwAGpB2LvEABAWIAJB8ABqIAJBmAFqQSgQ8gMaIAAgAkHwAGogAkHIAGoQjwIgAkHAAWokAA8LIAZBCGohBiAHIQMMAAsAC5YEAgZ/BH4jAEHAAWsiAiQAIAJBCGpBAEHAABDBBBoDQAJAIANBCEcEQCADQQFqIQcgAkEIaiADQQN0aiEFQQAhAyAGIQQDQCADQcAARg0CIARBwABHBEAgBSAFKQMAIAEgBGoxAAAgA0E4ca2GhDcDACADQQhqIQMgBEEBaiEEDAELC0H07MgAIARBwAAQ5AIACyACIAIpAwgiCEL/////////B4M3A0ggAiACKQNAIgtCFIg3A5ABIAIgAikDKCIJQgSIQv////////8HgzcDcCACIAIpAxAiCkIMhkKA4P//////B4MgCEI0iIQ3A1AgAiACKQMYIghCGIZCgICA+P///weDIApCKIiENwNYIAIgAikDICIKQiSGQoCAgICA/v8HgyAIQhyIhDcDYCACIAlCMIZCgICAgICAwAeDIApCEIiENwNoIAIgAikDMCIIQgiGQoD+//////8HgyAJQjiIhDcDeCACIAIpAzgiCUIUhkKAgMD/////B4MgCEIsiIQ3A4ABIAIgC0IghkKAgICA8P//B4MgCUIgiIQ3A4gBIAJBmAFqIAJByABqQYjtyAAQFyACQcgAaiACQZgBakEoEPIDGiACQZgBaiACQfAAakGw7cgAEBcgAkHwAGogAkGYAWpBKBDyAxogACACQfAAaiACQcgAahCSAiACQcABaiQADwsgBkEIaiEGIAchAwwACwALmwMBA38CQAJAAkACQAJAIAAtAAgiAiABLQAIRw0AAkACQAJAAkACQAJAIAJBAWsOBQEKAgMKAAsgAEEQaigCACICIAFBEGooAgBHDQUMCAsgAEEQaigCACICIAFBEGooAgBHDQYgAEEMaigCACIDIAFBDGooAgAiBEYNAiADIAQgAhC0A0UNAgwGCyAAQRBqKAIAIgIgAUEQaigCAEcNAwwGCyAAQRBqKAIAIgIgAUEQaigCAEcNAyAAQQxqKAIAIgMgAUEMaigCACIERg0BIAMgBCACELQDRQ0BDAMLIABBGGooAgAiAiABQRhqKAIARw0DQQEhAyAAQRRqKAIAIgAgAUEUaigCACIBRg0BIAAgASACELQDDQMMAQsgAEEYaigCACICIAFBGGooAgBHDQFBASEDIABBFGooAgAiACABQRRqKAIAIgFGDQAgACABIAIQtAMNAQsgAw8LQQAPC0EADwsgAEEMaigCACIAIAFBDGooAgAiAUYEQEEBDwsgACABIAIQtANFDwsgAEEJai0AACABQQlqLQAARgvxAwEHfyMAQRBrIgYkAEEBIQgCQCABKAIYQScgAUEcaigCACgCEBECAA0AIAYgACgCABB/IAZBDGotAAAhAyAGQQhqKAIAIQQgBigCACEAAkAgBigCBCIFQYCAxABGBEADQCAAIQJB3AAhBUEBIQACQAJAIAJBAmsOAgEABAsgA0H/AXEhAkEEIQNBAyEAAkACQAJAAkAgAkEBaw4FAwIBAAQHC0H1ACEFQQMhAwwDC0ECIQNB+wAhBQwCC0ECQQEgBBshA0GAgMQAIARBAnRBHHF2QQ9xQTByIQUgBEF/akEAIAQbIQQMAQtBACEDQf0AIQULIAEoAhggBSABKAIcKAIQEQIARQ0ADAMLAAsDQCAAIQdB3AAhAkEBIQACQAJAAkACQCAHQQFrDgMBAwAFCyADQf8BcSEHQQQhA0EDIQACQAJAAkAgB0EBaw4FAgEABAUHC0ECIQNB+wAhAgwECyAFIARBAnRBHHF2QQ9xIgJBMHIgAkHXAGogAkEKSRshAkECQQEgBBshAyAEQX9qQQAgBBshBAwDC0EAIQNB/QAhAgwCC0EAIQAgBSECDAELQfUAIQJBAyEDCyABKAIYIAIgASgCHCgCEBECAEUNAAsMAQsgASgCGEEnIAEoAhwoAhARAgAhCAsgBkEQaiQAIAgLhQUCAn8FfiMAQTBrIgEkAAJ+IAApAwAiA0IfWARAIAApAwhCxc/ZsvHluuonfAwBCyAAQRhqKQMAIgRCB4kgACkDECIFQgGJfCAAQSBqKQMAIgZCDIl8IABBKGopAwAiB0ISiXwgBULP1tO+0ser2UJ+Qh+JQoeVr6+Ytt6bnn9+hUKHla+vmLbem55/fkLj3MqV/M7y9YV/fCAEQs/W077Sx6vZQn5CH4lCh5Wvr5i23puef36FQoeVr6+Ytt6bnn9+QuPcypX8zvL1hX98IAZCz9bTvtLHq9lCfkIfiUKHla+vmLbem55/foVCh5Wvr5i23puef35C49zKlfzO8vWFf3wgB0LP1tO+0ser2UJ+Qh+JQoeVr6+Ytt6bnn9+hUKHla+vmLbem55/fkLj3MqV/M7y9YV/fAshBCABQRhqIABBMGoQnwQgASABKQMYNwMgIAMgBHwhAwN+IAFBCGogAUEgahC9AyABKQMIpwR+IAEpAxBCz9bTvtLHq9lCfkIfiUKHla+vmLbem55/fiADhUIbiUKHla+vmLbem55/fkLj3MqV/M7y9YV/fCEDDAEFIAEgASkDIDcDKAN+IAEgAUEoahC+AyABKAIABH4gASgCBK1Ch5Wvr5i23puef34gA4VCF4lCz9bTvtLHq9lCfkL5893xmfaZqxZ8IQMMAQUgASgCKCECIAEoAiwhAANAIAAEQCAAQX9qIQAgAjEAAELFz9my8eW66id+IAOFQguJQoeVr6+Ytt6bnn9+IQMgAkEBaiECDAELCyABQTBqJAAgA0IhiCADhULP1tO+0ser2UJ+IgNCHYggA4VC+fPd8Zn2masWfiIDQiCIIAOFCwsLCwuxAwEHfyABQX9qIQggAEECdCEHQQAgAWshCSACKAIAIQUCQAJAA0AgBUUNAiAFIQEDQAJAIAEoAggiBUEBcUUEQAJAIAEoAgBBfHEiCiABQQhqIgZrIAdPBEAgBiADIAAgBCgCEBECAEECdGpBCGogCiAHayAJcSIFTQ0BIAYgCHFFDQMgBigCACEFCyACIAU2AgAMBAsgBUEANgIAIAVBeGoiBUIANwIAIAUgASgCAEF8cTYCACABKAIAIgJBfHEiAEUgAkECcXJFBEAgACAAKAIEQQNxIAVyNgIECyAFIAUoAgRBA3EgAXI2AgQgASABKAIIQX5xNgIIIAEgASgCACIAQQNxIAVyIgI2AgAgAEECcUUNBCABIAJBfXE2AgAgBSAFKAIAQQJyNgIADAQLIAEgBUF+cTYCCAJ/QQAgASgCBEF8cSIFRQ0AGkEAIAUgBS0AAEEBcRsLIQUgARCfAiABLQAAQQJxBEAgBSAFKAIAQQJyNgIACyACIAU2AgAgBSEBDAELCwsgAiABKAIIQXxxNgIAIAEhBQsgBSAFKAIAQQFyNgIAIAVBCGohCwsgCwulAwECfyMAQcACayIEJAAgAhClBSACQdHwwwBBByADQaABahCeBSAEQSA2AkQgBCABQSBqNgJAIAQgAiAEQUBrEPQDIARBQGsgBEGo/8EAEMkFIARBIGogBEFAaxBIIAJB3/DDAEEGIARBIGoQngUgBEHgAWogAkHl8MMAQQYQkAQgBEFAayAEQeABaiABELwDIARBgAJqIARBQGsgBBASIARBoAJqEMsEIARByABqIgEgBEGoAmopAwA3AwAgBEHQAGoiAyAEQbACaikDADcDACAEQdgAaiIFIARBuAJqKQMANwMAIARBCGogASkDADcDACAEQRBqIAMpAwA3AwAgBEEYaiAFKQMANwMAIAQgBCkDoAI3A0AgBCAEKQNANwMAIABBGGogBEE4aikDADcAACAAQRBqIARBMGopAwA3AAAgAEEIaiAEQShqKQMANwAAIAAgBCkDIDcAACAAIAQpA4ACNwAgIABBKGogBEGIAmopAwA3AAAgAEEwaiAEQZACaikDADcAACAAQThqIARBmAJqKQMANwAAIAIQtwUgBEHAAmokAAuyAwIKfwF+QQAgASgCCCIKayENIAUgASgCECIOayEPIAEpAwAhESABKAIUIQgCQANAIAUgCGoiC0F/aiIHIANPBEAgASADNgIUQQAhBwwCC0IBIAIgB2oxAABCP4OGIBGDUARAIAEgCzYCFCALIQggBg0BIAFBADYCHAwBCyAKIQcgBkUEQCAKIAEoAhwiByAKIAdLGyEHCyACIAhqIRACQANAIAcgBU8EQEEAIAEoAhwgBhshCSAKIQcCQAJAA0AgCSAHTwRAIAEgCzYCFCAGRQRAIAFBADYCHAsgACAINgIEIABBCGogCzYCAEEBIQcMCAsgB0F/aiIHIAVPDQEgByAIaiIMIANPDQIgBCAHai0AACACIAxqLQAARg0ACyABIAggDmoiCDYCFCAGDQUgASAPNgIcDAULQZiWygAgByAFEOQCAAtBqJbKACAMIAMQ5AIACyAHIAhqIgkgA08NASAHIBBqIQwgBCAHaiAHQQFqIQctAAAgDC0AAEYNAAsgASAIIA1qIAdqIgg2AhQgBg0BIAFBADYCHAwBCwtBiJbKACAJIAMQ5AIACyAAIAc2AgAL8AMBBH8jAEFAaiIBJAAgACgCACIDKAIAIQIgAyAAKAIENgIAIAEgAkEDcSIANgIMIABBAkYEQAJAAkACQCACQXxxIgAEQANAIAAoAgQgACgCACECIABBADYCACACRQ0CIABBAToACCACKAIYIQAgAkECNgIYIAEgAjYCKAJAAkAgAEECTQRAIABBAWsNAgwBC0HsoMoAQRxBiKHKABC8BAALIAEoAigiAkEcaiIAKAIAIgQtAAANBCAEQQE6AABBjPrKAAJ/QYj6ygAoAgBBAUYEQEGM+soAKAIADAELQYj6ygBCATcDAEEACyIENgIAIAItACANBSAAKAIAQQA6AAALIAEoAigiACAAKAIAIgBBf2o2AgAgAEEBRgRAIAFBKGoQ0gILIgANAAsLIAFBQGskAA8LQZicygBBK0GEpMoAEM4DAAtB6KfKAEEgQaSoygAQvAQACyABIAA2AhAgASAEQQBHOgAUQfScygBBKyABQRBqQaCdygBBmKHKABCoAgALIAFBNGpBkgE2AgAgAUEkakECNgIAIAFCAzcCFCABQdSbygA2AhAgAUGSATYCLCABIAFBDGo2AjggAUGYn8oANgI8IAEgAUEoajYCICABIAFBPGo2AjAgASABQThqNgIoIAFBEGpB9KPKABCpBAALmAMCBX8BfiMAQdAAayIBJAAgACgCACECA0BBACEFA0ACQAJAAkACQAJAIAJBAXEEQCACQXxxIgMgBUEJS3INASAFQQFqIgVBBEkNAgwDCyAAIAJBAXIgACgCACIDIAIgA0YbNgIAIAIgA0cgAyECDQUgAUHQAGokAA8LIAFBAjoAICABQdTwyQAQtwQCfyABKAIABEAgAUEwahCXBSABQRBqEOgEIAFBKGogAUHIAGopAwA3AwAgAUEgaiABQUBrKQMAIgY3AwAgAUEYaiABQThqKQMANwMAIAEgASkDMDcDECABQRBqIAanQf8BcUECRw0BGkGo8MkAQStBvPHJABDOAwALIAEoAgQLIgRBAToAECADRQ0CIAQgAzYCHCAEQgA3AhQMAwsgAUEIakEAQQEgBUEfcXQQpgULIAAoAgAhAgwCCyAEQQA2AhggBCAENgIUCyAAIAJBA3EgBHIgACgCACIDIAIgA0YbNgIAIAIgA0YEQCAEEOYBIAFBEGoQ6AQMAgUgAUEQahDoBCADIQIMAQsACwALAAuFAwEFfyMAQUBqIgMkACADIAA2AhAgACgCACEAA0ACQCAAQQFxDQACQCAAQQJxIgZBAXZFBEACQAJAAkACQCAAQQRxBEAgAEEIcQ0DIAVBCUsNAiAFQQFqIgVBBEkNAQwGCyADKAIQIgQgAEF5cUEEciAEKAIAIgQgACAERhs2AgAgACAERyAEIQANByABIAZBAXYgAigCDBEAACADKAIQIgAoAgAgAEEBNgIAQQhxDQMMBgsgA0EIakEAQQEgBUEfcXQQpgUMBAsgAygCECIEIABBCHIgBCgCACIEIAAgBEYbNgIAIAAgBEcgBCEADQULIAMoAhAhACADIANBEGo2AhQgA0EBOgAaIANBAToAGyADIANBFGo2AhwgAyADQRpqNgIgIAMgA0EbajYCJCADQgA3AyhBACEFIAMgACADQRxqIANBIGogA0EkaiADQShqEEAMAgsgAygCEBAxDAILQZzryQBBKkGg7MkAELkEAAsgAygCECgCACEADAELCyADQUBrJAALwwMBA38jAEEwayIBJAAgAUHIgMoAQQsQAyICNgIUIAFBIDYCGCABIAJBIBAEIgI2AgggAUEYahCNBSABQRRqEI0FIAFBIDYCGCABQQhqIAFBGGoQrAUhAyABQRhqEI0FAkAgAwRAIAEgAjYCDCABIAIQBTYCFCABQSA2AhggAUEUaiABQRhqEKwFIQMgAUEYahCNBSABQRRqEI0FAkACQCADBEAgASACEAYiAjYCECABQRBqEL0FDQEgASACNgIUIAEgAhAHNgIYIAFBGGoQvQUgAUEYahCNBQ0CIABCgICAgBA3AgAgAEEIaiACNgIADAQLIABBCGpB9IHKAEEGEAg2AgAgAEIANwIADAMLIAFBGGpB+oHKAEEYEPwEIABBATYCACAAQRRqIAFBKGooAgA2AgAgAEEMaiABQSBqKQMANwIAIAAgASkDGDcCBCABQRBqEI0FDAILIAFBGGpBkoLKAEEjEPwEIABBATYCACAAQRRqIAFBKGooAgA2AgAgAEEMaiABQSBqKQMANwIAIAAgASkDGDcCBCABQRRqEI0FDAELQdOAygBBLkHkgcoAELkEAAsgAUEMahCNBSABQTBqJAALrQMBAn8jAEHwAmsiAyQAIANBoAJqIAIQyAUgA0EIaiADQaACaiACEB4gA0GgAmogA0EIahDIBSADQTBqIANBoAJqIAIQHiADQYABaiABIANBCGoQHiADQdABaiABIANBMGoQHiADQaACaiADQdABahBjIANB+AFqIANBoAJqQSgQ8gMaIANBoAJqIANB+AFqQQIQKiADQagBaiADQdABaiADQaACahAeIANB2ABqIANBgAFqIANBqAFqEB4gA0GgAmogA0HYAGoQyAUgA0HQAWogAiADQaACahAeIANB0AFqIAEQ9wMhBCADQaACaiABENkDIANB0AFqIANBoAJqEPcDIQIgA0GgAmogARDZAyADQfgBaiADQaACakG4+sMAEB4gA0HQAWogA0H4AWoQ9wMhASADQfgBakG4+sMAIANB2ABqEB4gA0HYAGogA0H4AWogASACchCWBRCIAiADQdgAahDCBCEBIANBoAJqIANB2ABqENkDIANB2ABqIANBoAJqIAEQiAIgACACIARyEJYFOgAAIABBCGogA0HYAGpBKBDyAxogA0HwAmokAAutAwECfyMAQfACayIDJAAgA0GgAmogAhDIBSADQQhqIANBoAJqIAIQHiADQaACaiADQQhqEMgFIANBMGogA0GgAmogAhAeIANBgAFqIAEgA0EIahAeIANB0AFqIAEgA0EwahAeIANBoAJqIANB0AFqEGMgA0H4AWogA0GgAmpBKBDyAxogA0GgAmogA0H4AWpBAhAqIANBqAFqIANB0AFqIANBoAJqEB4gA0HYAGogA0GAAWogA0GoAWoQHiADQaACaiADQdgAahDIBSADQdABaiACIANBoAJqEB4gA0HQAWogARD3AyEEIANBoAJqIAEQ2QMgA0HQAWogA0GgAmoQ9wMhAiADQaACaiABENkDIANB+AFqIANBoAJqQeCsyAAQHiADQdABaiADQfgBahD3AyEBIANB+AFqQeCsyAAgA0HYAGoQHiADQdgAaiADQfgBaiABIAJyEJYFEIgCIANB2ABqEMIEIQEgA0GgAmogA0HYAGoQ2QMgA0HYAGogA0GgAmogARCIAiAAIAIgBHIQlgU6AAAgAEEIaiADQdgAakEoEPIDGiADQfACaiQAC/ACAgZ/AX4jAEEQayIDJAAgA0EBOgAOIAACfwJAAkACQAJAAn8CQCABBEAgAUEISQ0BIAFB/////wFxIAFHDQMgAUEDdEEHbgwCCyAAQRBqQgA3AgAgAEEIakKAgICAwAA3AgAgAEEEakGU9cgANgIAQQAMBgsgAUEBagshASADQQE6AA9BfyABQX9qZ3YiAUEIaiICIAFBBWoiBkkNASABQQFqIgWtQgx+IghCIIinDQEgAkF8cSICIAinaiIEIAJJDQEgBEEEEKQFIgcNAiAEQQQQ3QUACyADQQ5qEP4EDAILIANBD2oQ/gQMAQsgAiAHQf8BIAYQwQQiBGohAiAFQQRJBEAgBCAFakGAAUEDIAFrEMEEGgsgAEEUaiABIAVBA3ZBB2wgAUEISRs2AgAgAEEQakEANgIAIABBDGogAjYCACAAQQhqIAE2AgAgAEEEaiAENgIAQQAMAQsgAEEAOgABQQELOgAAIANBEGokAAuZAwECfyMAQaAFayIDJAAgA0EIaiACEMEBQQAhAiADQcgAakEAQSgQwQQaIANB+ABqQgA3AwAgA0GAAWpCADcDACADQYgBakIANwMAIANBkAFqQgA3AwAgA0IBNwNwIANCATcDmAEgA0GgAWpBAEHIABDBBBoDQCACIgRBP00EQCAEQQFqIQIgBEEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgA0GIA2ogA0HIAGoQxQEgA0HIAGogA0GIA2pBoAEQ8gMaQQAhAgNAIAIiBEE/TQRAIARBAWoiAkEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgACADQcgAakGgARDyAxogA0GgBWokAAuZAwECfyMAQaAFayIDJAAgA0EIaiACEMIBQQAhAiADQcgAakEAQSgQwQQaIANB+ABqQgA3AwAgA0GAAWpCADcDACADQYgBakIANwMAIANBkAFqQgA3AwAgA0IBNwNwIANCATcDmAEgA0GgAWpBAEHIABDBBBoDQCACIgRBP00EQCAEQQFqIQIgBEEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgA0GIA2ogA0HIAGoQxQEgA0HIAGogA0GIA2pBoAEQ8gMaQQAhAgNAIAIiBEE/TQRAIARBAWoiAkEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgACADQcgAakGgARDyAxogA0GgBWokAAudAwEDfyMAQbADayIDJAAgAAJ/AkAgAkEgRwRAIANB3AFqQtKAgICABDcCACADQdgBakHPgMAANgIAIANB1AFqQQk2AgAgA0HQAWpBxoDAADYCACADQQM6AMwBIANBATYCyAEgAyADQcgBakEEckHEARDyAxoMAQsgA0GoA2oiAkIANwMAIANBoANqIgRCADcDACADQZgDaiIFQgA3AwAgA0IANwOQAyADQZADakEgIAFBIBCuASADQRhqIAIpAwA3AwAgA0EQaiAEKQMANwMAIANBCGogBSkDADcDACADIAMpA5ADNwMAIANByAFqIAMQiQEgAygCyAEgAyADQcgBakEEckHEARDyAyECQQFGDQAgAEEIaiACQQRqQcABEPIDGkEADAELIANB2AFqIANBEGopAgA3AwAgA0HQAWogA0EIaikCADcDACADIAMpAgA3A8gBIANBkANqIANByAFqEKoEIABBFGogA0GgA2opAwA3AgAgAEEMaiADQZgDaikDADcCACAAIAMpA5ADNwIEQQELNgIAIANBsANqJAALkAMBAX8jAEHABGsiBSQAIAUgAzYCDCAFIAI2AgggBUEQahCyAyAFQRBqIAFBIGoQxgUgBUEQaiAFQQhqEK4EIAVB6AJqIAVBEGpB2AEQ8gMaIAVBiAJqIAVB6AJqEOICIAVB6AJqIAVBiAJqQZDJxAAQzQUgBUHoAWogBUHoAmoQ2AEgBUHoAmoQsgMgBUEQaiAFQegCakHYARDyAxogBUEQaiAFQegBahDGBSAFQRBqIARBoAFqEMYFIAVBEGogBUEIahCuBCAFQegCaiAFQRBqQdgBEPIDGiAFQcgCaiAFQegCahDiAiAFQegCaiAFQcgCaiABEMADIAVBqAJqIAVB6AJqIAVBiAJqEBMgAEEYaiAFQYACaikDADcAACAAQRBqIAVB+AFqKQMANwAAIABBCGogBUHwAWopAwA3AAAgACAFKQPoATcAACAAIAUpAKgCNwAgIABBKGogBUGwAmopAAA3AAAgAEEwaiAFQbgCaikAADcAACAAQThqIAVBwAJqKQAANwAAIAVBwARqJAALlgMBB38jAEGABWsiAiQAIAJBEGoQsgMgAkHoAWpBAEHAABDBBBogAkHAAmoiA0IANwMAIAJBuAJqIgRCADcDACACQbACaiIFQgA3AwAgAkIANwOoAiACQeACaiIGQgA3AwAgAkHYAmoiB0IANwMAIAJB0AJqIghCADcDACACQgA3A8gCIAJBEGogARDGBSACQagDaiACQRBqQdgBEPIDGiACQegCaiACQagDahChBCACQQhqIAJB6AJqEKkFIAJB6AFqQcAAIAIoAgggAigCDBCwASACQagCakEgIAJB6AFqQSAQsAEgAkHIAmpBICACQYgCakEgELABIAIgAi0AqAJB+AFxOgCoAiACIAItAMcCQT9xQcAAcjoAxwIgAkHAA2ogAykDADcDACACQbgDaiAEKQMANwMAIAJBsANqIAUpAwA3AwAgAiACKQOoAjcDqAMgACACQagDahC7AyAAQThqIAYpAwA3AAAgAEEwaiAHKQMANwAAIABBKGogCCkDADcAACAAIAIpA8gCNwAgIAJBgAVqJAAL9AIBBH8jAEHQAGsiAyQAIANBCGoQrAIgA0EoaiIGIANBHGooAgA2AgAgAyADQRRqKQIANwMgIANBEGooAgAhBCADKAIMIQUCQAJAIAMoAghBAUcEQCADIAQ2AgQgAyAFNgIAIANBIGogAyABIAIQpwEgAy0AMEEFRw0BIANBIGoQmAUgACADKQMANwIEIABBADYCAAwCCyADQRhqIAYoAgA2AgAgAyAENgIMIAMgBTYCCCADIAMpAyA3AxAgA0E4aiADQQhqELgEIABBFGogA0HIAGooAgA2AgAgAEEMaiADQUBrKQMANwIAIAAgAykDODcCBCAAQQE2AgAMAQsgA0EYaiADQTBqKAIANgIAIANBEGogA0EoaikDADcDACADIAMpAyA3AwggA0E4aiADQQhqELgEIABBFGogA0HIAGooAgA2AgAgAEEMaiADQUBrKQMANwIAIAAgAykDODcCBCAAQQE2AgAgAxCMBQsgA0HQAGokAAuRAgECfyMAQeAAayICJAAgAkEgNgIQIAJBIDYCFCACQQQ2AkggAkEgNgJEIAIgATYCQCACQSBqIAAgAEEgaiACQUBrEOYDIAJB2ABqIAJBOGooAgA2AgAgAkHQAGogAkEwaikDADcDACACQcgAaiIBIAJBKGopAwA3AwAgAiACKQMgNwNAAkADQCACKAJUIgAgAigCWEkEQCACIABBAWo2AlQgAigCQCEDIAJBCGogASAAEM0DIAIoAgxBA00NAiACKAIIIAMgAEECdGooAgAiAEEYdCAAQQh0QYCA/AdxciAAQQh2QYD+A3EgAEEYdnJyNgAADAELCyACQeAAaiQADwtByOXJAEEgQdTkyQAQtAQAC4sDAQF/IwBBgAZrIgIkACACQQhqIAEQyAUgAkHYBWogAkEIahDIBSACQTBqIAJB2AVqEMgFIAJB2ABqIAEgAkEwahAeIAJBgAFqIAJBCGogAkHYAGoQHiACQagBaiACQYABahDIBSACQdABaiACQdgAaiACQagBahAeIAJB+AFqIAJB0AFqQQUQKiACQaACaiACQfgBaiACQdABahAeIAJByAJqIAJBoAJqQQoQKiACQfACaiACQcgCaiACQaACahAeIAJBmANqIAJB8AJqQRQQKiACQcADaiACQZgDaiACQfACahAeIAJB6ANqIAJBwANqQQoQKiACQZAEaiACQegDaiACQaACahAeIAJBuARqIAJBkARqQTIQKiACQeAEaiACQbgEaiACQZAEahAeIAJBiAVqIAJB4ARqQeQAECogAkGwBWogAkGIBWogAkHgBGoQHiACQdgFaiACQbAFakEyECogACACQdgFaiACQZAEahAeIABBKGogAkGAAWpBKBDyAxogAkGABmokAAu2AwEBfyMAQdAAayICJAACfwJAAkACQAJAAkAgACgCAEEBaw4EAgMEAAELIAIgAEEEajYCICACIABBCGo2AiQgAkEYaiACQSBqQcEAEKYFIAJBzABqQcIANgIAIAJBPGpBAjYCACACQgI3AiwgAkHE3skANgIoIAIgAikDGDcDQCACIAJBJGo2AkggAiACQUBrNgI4IAEgAkEoahDoAgwECyACQTxqQQA2AgAgAkG838kANgI4IAJCATcCLCACQczfyQA2AiggASACQShqEOgCDAMLIAJBPGpBADYCACACQbzfyQA2AjggAkIBNwIsIAJBtN/JADYCKCABIAJBKGoQ6AIMAgsgAiAAQQRqNgIkIAJBCGogAkEkakHBABCmBSACQTxqQQE2AgAgAkIBNwIsIAJBlN/JADYCKCACIAIpAwg3A0AgAiACQUBrNgI4IAEgAkEoahDoAgwBCyACIABBBGo2AiQgAkEQaiACQSRqQcEAEKYFIAJBPGpBATYCACACQgE3AiwgAkH43skANgIoIAIgAikDEDcDQCACIAJBQGs2AjggASACQShqEOgCCyACQdAAaiQAC+cCAQZ/AkACQCACQQNxIgRFDQBBBCAEayIERQ0AIAMgBCAEIANLGyEFQQAhBCABQf8BcSEIA0AgBCAFRg0BIAIgBGogBEEBaiEELQAAIgYgCEcNAAtBASEDIAYgAUH/AXFGQQFqQQFxIARqQX9qIQQMAQsgAUH/AXEhCAJAAkAgA0EISQ0AIAUgA0F4aiIGSw0AIAhBgYKECGwhBANAIAIgBWoiB0EEaigCACAEcyIJQX9zIAlB//37d2pxIAcoAgAgBHMiB0F/cyAHQf/9+3dqcXJBgIGChHhxRQRAIAVBCGoiBSAGTQ0BCwsgBSADSw0BCyACIAVqIQIgAyAFayEGQQAhA0EAIQQCQANAIAQgBkYNASACIARqIARBAWohBC0AACIHIAhHDQALQQEhAyAHIAFB/wFxRkEBakEBcSAEakF/aiEECyAEIAVqIQQMAQsgBSADEOYCAAsgACAENgIEIAAgAzYCAAv8AgEGfyMAQTBrIgIkACABKAIAIQYgASgCBCIHQQN0IgUEQCAGQQRqIQMDQCADKAIAIARqIQQgA0EIaiEDIAVBeGoiBQ0ACwsCQAJAAkACQAJAIAFBFGooAgBFBEAgBCEDDAELIAdFBEBBlKnKAEEAQQAQ5AIACwJAIARBD00EQCAGQQRqKAIARQ0BCyAEIARqIgMgBE8NAQtBASEFQQAhAyACQQhqIQQMAQsgA0F/TA0BIAJBCGohBCADRQRAQQEhBUEAIQMMAQsgA0EBEKQFIgVFDQILIAJBADYCECACIAM2AgwgAiAFNgIIIAIgAkEIajYCFCACQShqIAFBEGopAgA3AwAgAkEgaiABQQhqKQIANwMAIAIgASkCADcDGCACQRRqQbSoygAgAkEYahAzDQIgACAEKQIANwIAIABBCGogBEEIaigCADYCACACQTBqJAAPCxDrBQALIANBARDdBQALQbSpygBBMyACQRhqQaSpygBB/KnKABCoAgAL1AICBn8EfiMAQbACayIDJAAgA0EIakEAQYACEMEEGiADQZACaiABQQhqKQAANwMAIANBmAJqIAFBEGopAAA3AwAgA0GgAmogAUEYaikAADcDACADQgA3A6gCIAMgASkAADcDiAJBwAAgAmshB0IBIAJBP3GthiIJQgGIIQogCUJ/fCELIAmnIQhBACEBA0BBACABayEEA0AgAUGAAkkEQCABQQZ2IQUCfiABQT9xIgYgB0kEQCADQYgCaiAFQQN0aikDACAGrYgMAQsgA0GIAmogBUEDdGoiBUEIaikDACAEQT9xrYYgBSkDACAGrYiECyALgyAMfCIJQgGDUARAIARBf2ohBCABQQFqIQEMAgUgA0EIaiABaiAJp0EAIAggCSAKVBtrOgAAIAIgBGshASAJIAparSEMDAMLAAsLCyAAIANBCGpBgAIQ8gMaIANBsAJqJAALnQMBBX8jAEGQAmsiAyQAIANByIbAAEEUEPUDIANB3IbAAEEKQayDwABBABDSAyACLQAABEAgA0GIAmogAkEZaikAADcDACADQYACaiACQRFqKQAANwMAIANB+AFqIAJBCWopAAA3AwAgAyACKQABNwPwASADQfCGwABBCiADQfABakEgENIDCyADQfABaiABENYDIANBnYfAAEEKIANB8AFqQSAQ0gMgA0HoAWoiAUIANwMAIANB4AFqIgJCADcDACADQdgBaiIEQgA3AwAgA0IANwPQASADQaeHwABBCSADQdABakEgENMDIANBiAJqIgVCADcDACADQYACaiIGQgA3AwAgA0H4AWoiB0IANwMAIANCADcD8AEgA0GPh8AAQQ4gA0HwAWpBIBDTAyAAQRhqIAEpAwA3AAAgAEEQaiACKQMANwAAIABBCGogBCkDADcAACAAIAMpA9ABNwAAIAAgAykD8AE3ACAgAEEoaiAHKQMANwAAIABBMGogBikDADcAACAAQThqIAUpAwA3AAAgAxC3BSADQZACaiQAC/oCAQN/IwBBwANrIgMkACAAAn8CQCACQSBHBEAgA0HsAWpC0oCAgIAENwIAIANB6AFqQbHvwwA2AgAgA0HkAWpBCTYCACADQeABakGo78MANgIAIANBAzoA3AEgA0EBNgLYASADQRBqIANB2AFqQQRyQcQBEPIDGgwBCyADQbgDaiICQgA3AwAgA0GwA2oiBEIANwMAIANBqANqIgVCADcDACADQgA3A6ADIANBCGogAUEgQSAQngQgA0GgA2pBICADKAIIIAMoAgwQrQEgA0EoaiACKQMANwMAIANBIGogBCkDADcDACADQRhqIAUpAwA3AwAgAyADKQOgAzcDECADQdgBaiADQRBqEIkBIAMoAtgBIANBEGogA0HYAWpBBHJBxAEQ8gMaQQFGDQAgAEEIaiADQRRqQcABEPIDGkEADAELIAAgAykCEDcCBCAAQRRqIANBIGopAgA3AgAgAEEMaiADQRhqKQIANwIAQQELNgIAIANBwANqJAALlwMCBH8CfiMAQUBqIgUkAEEBIQcCQCAALQAEDQAgAC0ABSEIIAAoAgAiBi0AAEEEcUUEQCAGKAIYQaWsygBBp6zKACAIG0ECQQMgCBsgBkEcaigCACgCDBEEAA0BIAAoAgAiBigCGCABIAIgBkEcaigCACgCDBEEAA0BIAAoAgAiASgCGEGcq8oAQQIgAUEcaigCACgCDBEEAA0BIAMgACgCACAEKAIMEQIAIQcMAQsgCEUEQCAGKAIYQaCsygBBAyAGQRxqKAIAKAIMEQQADQEgACgCACEGCyAFQQE6ABcgBUE0akGErMoANgIAIAUgBikCGDcDCCAFIAVBF2o2AhAgBikCCCEJIAYpAhAhCiAFIAYtACA6ADggBSAKNwMoIAUgCTcDICAFIAYpAgA3AxggBSAFQQhqNgIwIAVBCGogASACEEYNACAFQQhqQZyrygBBAhBGDQAgAyAFQRhqIAQoAgwRAgANACAFKAIwQaOsygBBAiAFKAI0KAIMEQQAIQcLIABBAToABSAAIAc6AAQgBUFAayQAC7YDAgR/AX4jAEEwayIBJAACQAJAAkACQAJ/QQAgACgCACICRQ0AGiABIAApAgQ3AiQgASACNgIgIAFBEGogAUEgahD5BCABQQhqQQAgASgCECIAIAEoAhgQZSABKAIIDQEgAUEoaiABQRhqKAIANgIAIAEgASkDEDcDICABIAFBIGoQbiABKAIEIQMgASgCAAshBEGQ+soALQAADQFBkPrKAEEBOgAAAkBBmPvKACkDACIFQn9SBEBBmPvKACAFQgF8NwMAIAVCAFINAUGYnMoAQStBnKDKABDOAwALQdSfygBBN0GMoMoAELwEAAtBkPrKAEEAOgAAQQFBARCkBSICRQ0CIAJBADoAAEEwQQgQpAUiAEUNAyAAQgE3AiQgAEEANgIYIAAgAzYCFCAAIAQ2AhAgACAFNwMIIABCgYCAgBA3AwAgACACrTcCHCABQTBqJAAgAA8LIAEoAgwhAiABQShqIAEpAhQ3AwAgASAANgIkIAEgAjYCIEGsoMoAQS8gAUEgakHUnMoAQdygygAQqAIAC0Hop8oAQSBBpKjKABC8BAALQQFBARDdBQALQTBBCBDdBQAL9AIBAn8jAEHgA2siAiQAIAIgARCbAiACQThqQgA3AwAgAkFAa0IANwMAIAJByABqQgA3AwAgAkIANwMwIAJCATcDKCACQdAAaiACEMgFIAJB+ABqIAJB0ABqIAJBKGoQ3wEgAkHwAWogAkHQAGpBgOvIABAeIAJBoAFqIAJB8AFqIAJBKGoQ1QMgAkHwAWogAkH4AGogAkGgAWoQWiACLQDwASEDIAJByAFqIAJB+AFqQSgQ8gMaIAAgA0EBRgR+IAEtAB9BB3YQlgUhASACQfABaiACQcgBahDZAyACQcgBaiACQfABaiABEIgCIAJB8AFqIAJByAFqQSgQ8gMaIAJBkANqIAJBKBDyAxogAkG4A2ogAkHIAWogAhAeIAJBmAJqIAJBkANqQSgQ8gMaIAJBwAJqIAJBKGpBKBDyAxogAkHoAmogAkG4A2pBKBDyAxogAEEIaiACQfABakGgARDyAxpCAQVCAAs3AwAgAkHgA2okAAuWAwIEfwF+IwBBIGsiASQAIAEgAEHMAGo2AhggAEEMaiEDIAApAwAhBSAAKAIIIQIgASABQRhqNgIcAkACQAJAIAJBwABGBEAgAUEcaiADELoFQQAhAiAAQQA2AggMAQsgAkE/Sw0BCyACIABBDGoiBGpBgAE6AAAgACAAKAIIQQFqIgI2AgggAUEQaiAEQcAAIAIQnQQgASgCEEEAIAEoAhQQwQQaQcAAIAAoAghrQQdNBEAgAUEcaiADELoFIAFBCGpBACAAKAIIIARBwAAQ1AMgASgCCEEAIAEoAgwQwQQaCyABIARBwABBOBCdBCABKAIEQQdNDQEgASgCACAFQiiGQoCAgICAgMD/AIMgBUI4hoQgBUIYhkKAgICAgOA/gyAFQgiGQoCAgIDwH4OEhCAFQgiIQoCAgPgPgyAFQhiIQoCA/AeDhCAFQiiIQoD+A4MgBUI4iISEhDcAACABQRxqIAMQugUgAEEANgIIIAFBIGokAA8LQaTkyQAgAkHAABDkAgALQejlyQBBIEHU5MkAELQEAAvwAgEEfwJAAkACQCABQQRqKAIAIgIgASgCCCIDRgRAIANBAWoiAiADSSACQQBIcg0BAn8gA0UEQCACQQEQpAUMAQsgASgCACADQQEgAhCUBQsiBEUNAiABIAQ2AgAgAUEEaiACNgIACyACIANHBEAgA0EBaiEEIAEoAgAhBQwDCyADQQFqIgQgA0kNACADQQF0IgIgBCACIARLGyICQQBIDQACfyADRQRAIAJBARCkBQwBCyABKAIAIANBASACEJQFCyIFBEAgASAFNgIAIAFBBGogAjYCAAwDCyACQQEQ3QUACxDCBQALIAJBARDdBQALIAMgBWpBADoAACABIAQ2AggCQAJAAkAgAiAERg0AIAIgBEkNASAERQRAIAJFBEBBASEFDAILIAUgAkEBELYFQQEhBQwBCyAFIAJBASAEEJQFIgVFDQILIAAgBDYCBCAAIAU2AgAPC0GInsoAQSRB+J3KABDOAwALIARBARDdBQAL3gIBA38jAEGAA2siBCQAIARB2ABqIANBGGopAAA3AwAgBEHQAGogA0EQaikAADcDACAEQcgAaiADQQhqKQAANwMAIAQgAykAADcDQCAEQeABaiABIAIgBEFAaxDtASAEQRhqIARB+AFqKQMANwMAIARBEGogBEHwAWopAwA3AwAgBEEIaiAEQegBaikDADcDACAEIAQpA+ABNwMAIARBOGoiAyAEQZgCaikDADcDACAEQTBqIgUgBEGQAmopAwA3AwAgBEEoaiIGIARBiAJqKQMANwMAIAQgBCkDgAI3AyAgBEHgAWogBEGwh8AAEMkFIARBQGsgASAEQeABahCIBCAEQeABaiAEQUBrQaABEPIDGiAAIARB4AFqEOEEIABB2AFqIAMpAwA3AAAgAEHQAWogBSkDADcAACAAQcgBaiAGKQMANwAAIAAgBCkDIDcAwAEgAhC3BSAEQYADaiQAC+UBAQR/IwBB4ABrIgIkACACQcAANgIQIAJBwAA2AhQgAkHAADYCRCACIAE2AkAgAkEINgJIIAJBIGogACAAQUBrIAJBQGsQ5wMgAkHQAGogAkEwaikDADcDACACQdgAaiACQThqKAIAIgM2AgAgAkHIAGoiBCACQShqKQMANwMAIAIgAikDIDcDQCACKAJUIgFBA3QhAANAIAEgA0kEQCACIAFBAWoiBTYCVCACQQhqIAQgARDNAyACKAIIIAIoAgwgAigCQCAAaikDABCpAiAAQQhqIQAgBSEBDAELCyACQeAAaiQAC+ACAQR+IAAgASkDICICPAAaIAAgASkDECIDPAANIAAgASkDACIEPAAAIAAgAkIoiDwAHyAAIAJCIIg8AB4gACACQhiIPAAdIAAgAkIQiDwAHCAAIAJCCIg8ABsgACABKQMYIgJCLIg8ABkgACACQiSIPAAYIAAgAkIciDwAFyAAIAJCFIg8ABYgACACQgyIPAAVIAAgAkIEiDwAFCAAIANCKIg8ABIgACADQiCIPAARIAAgA0IYiDwAECAAIANCEIg8AA8gACADQgiIPAAOIAAgASkDCCIFQiyIPAAMIAAgBUIkiDwACyAAIAVCHIg8AAogACAFQhSIPAAJIAAgBUIMiDwACCAAIAVCBIg8AAcgACAEQiiIPAAFIAAgBEIgiDwABCAAIARCGIg8AAMgACAEQhCIPAACIAAgBEIIiDwAASAAIAJCBIYgA0IwiIQ8ABMgACAFQgSGIARCMIiEPAAGC40DAQF/IwBBEGsiAiQAAn8CQAJAAkACQAJAAkAgACgCAEEBaw4EAgMEAAELIAIgAUGpucYAQRAQvwQgAiAAQQRqNgIMIAJBubnGAEEGIAJBDGpBwLnGABBqIAIgAEEMajYCDCACQdC5xgBBCCACQQxqQdi5xgAQaiACIABBEGo2AgwgAkHoucYAQQYgAkEMakHAucYAEGogAiAAQRhqNgIMIAJB7rnGAEEIIAJBDGpB2LnGABBqIAIgAEEcajYCDCACQfa5xgBBBiACQQxqQcC5xgAQaiACIABBJGo2AgwgAkH8ucYAQQggAkEMakHYucYAEGogAhCxAgwFCyACIAFBurrGAEEXEJwEDAMLIAIgAUGpusYAQREQnAQMAgsgAiABQY+6xgBBEBC/BCACIABBBGo2AgwgAkGfusYAQQQgAkEMakHAucYAEGogAiAAQQxqNgIMIAJBo7rGAEEGIAJBDGpB2LnGABBqIAIQsQIMAgsgAiABQYS6xgBBCxCcBAsgAhCAAgsgAkEQaiQAC9kCAgR/An4jAEEwayIDJAAgACkDwAEiB6dB/wBxIQRBACAHUEUgBBtFBEAgA0EoaiABIAIgAkGAASAEayIFIAUgAksbEJ4EIAMoAighBiADQSBqIAEgAiADKAIsIgUQnQQgAygCJCECIAMoAiAhASADQRhqIAAgBBDEBCADKAIYIAMoAhwgBiAFEOQEIAAgACkDwAEiByAFrXwiCCAHWq0gCBCDBTcDwAELA0AgAkH/AE0EQCACBEAgAEIAEAsgAEGAASABIAIQ5AQgACAAKQPAASIHIAKtfCIIIAdarSAIEIMFNwPAAQsgA0EwaiQABSAAQgAQCyADQRBqIAEgAkGAARCeBCADKAIQIQUgA0EIaiABIAIgAygCFCIEEJ0EIAMoAgwhAiADKAIIIQEgAEGAASAFIAQQ5AQgACAAKQPAASIHIAStfCIIIAdarSAIEIMFNwPAAQwBCwsL1QICBn8DfiMAQYDCAGsiASQAIAFBCGoQ3AEgAUH4IGogAUEIakHoIBDyAxogAUIBNwPwIANAIABBIGoiA0HwIE0EQCAAQajYygBqIgIpAwAhBiACIAFB8CBqIABqIgApAwA3AwAgACAGNwMAIAJBCGoiBCkDACEGIAQgAEEIaiIEKQMANwMAIAJBEGoiBSkDACEHIAUgAEEQaiIFKQMANwMAIAJBGGoiAikDACEIIAIgAEEYaiIAKQMANwMAIAAgCDcDACAFIAc3AwAgBCAGNwMAIAMhAAwBCwsgAUHQwQBqIgApAwAhBiAAQYj5ygApAwA3AwBBiPnKACAGNwMAQZD5ygAoAgAhAEGQ+coAIAFB2MEAaikDADcDAAJAIAEpA/AgUCAAQSRJcg0AIAEoAtRBIgNBAUYgA0F+akECS3JFDQAgABAACyABQYDCAGokAEGw2MoAC4wCAgJ/AX4jAEEwayIEJAACQCABKAIEIAJrIANPDQAgBEEgaiABIAIgAxCvAkEBIQUgBCgCJCECIAQoAiBBAUYEQCAEIAIgBEEoaigCABCmBSAAIAQpAwA3AgQMAQsCQAJAAkAgAq1C8AB+IgZCIIinRQRAIAanIgNBAEgNAQJ/IAEoAgQiBUUEQCADQQgQpAUMAQsgASgCACAFQfAAbEEIIAMQlAULIgUEQCABIAI2AgQgASAFNgIAQQAhBQwFCwwCCyAEQQhqIARBABCmBSAAIAQpAwg3AgQMAgsgBEEQaiAEQQAQpgUgACAEKQMQNwIEDAELIANBCBDdBQALCyAAIAU2AgAgBEEwaiQAC4kCAQN/IwBBMGsiAyQAAkAgASgCBCACa0EBTw0AIANBIGogASACQQEQrwJBASEEIAMoAiQhAiADKAIgQQFGBEAgAyACIANBKGooAgAQpgUgACADKQMANwIEDAELAkACQAJAIAIgAkH/////AXFGBEAgAkEDdCIFQQBIDQECfyABKAIEIgRFBEAgBUEEEKQFDAELIAEoAgAgBEEDdEEEIAUQlAULIgQEQCABIAI2AgQgASAENgIAQQAhBAwFCwwCCyADQQhqIANBABCmBSAAIAMpAwg3AgQMAgsgA0EQaiADQQAQpgUgACADKQMQNwIEDAELIAVBBBDdBQALCyAAIAQ2AgAgA0EwaiQAC74CAgV/AX4jAEEwayIEJABBJyECAkAgAEKQzgBUBEAgACEHDAELA0AgBEEJaiACaiIDQXxqIAAgAEKQzgCAIgdCkM4Afn2nIgVB//8DcUHkAG4iBkEBdEG5rMoAai8AADsAACADQX5qIAUgBkHkAGxrQf//A3FBAXRBuazKAGovAAA7AAAgAkF8aiECIABC/8HXL1YgByEADQALCyAHpyIDQeMASgRAIAJBfmoiAiAEQQlqaiAHpyIDIANB//8DcUHkAG4iA0HkAGxrQf//A3FBAXRBuazKAGovAAA7AAALAkAgA0EKTgRAIAJBfmoiAiAEQQlqaiADQQF0QbmsygBqLwAAOwAADAELIAJBf2oiAiAEQQlqaiADQTBqOgAACyABQcSqygBBACAEQQlqIAJqQScgAmsQNSAEQTBqJAALgQMBAX8jAEEQayICJAACfwJAAkACQAJAAkACQAJAAkAgAC0AAEEBaw4GAgMEBQYAAQsgAiABQYbxwwBBERC/BCACIABBAWo2AgwgAkGX8cMAQQsgAkEMakGk8cMAEGogAiAAQQJqNgIMIAJBtPHDAEEJIAJBDGpBwPHDABBqDAYLIAIgAUHg8sMAQQ0QnAQgAhCAAgwGCyACIAFByfLDAEEXEJwEIAIQgAIMBQsgAiABQbjywwBBERCcBCACEIACDAQLIAIgAUHu8cMAQRAQvwQgAiAAQQRqNgIMIAJB/vHDAEEEIAJBDGpBhPLDABBqIAIgAEEMajYCDCACQZTywwBBCyACQQxqQYTywwAQaiACIABBFGo2AgwgAkGf8sMAQQYgAkEMakGo8sMAEGoMAgsgAiABQdvxwwBBExCcBCACEIACDAILIAIgAUHQ8cMAQQsQvwQgAiAAQQFqNgIMIAJBl/HDAEELIAJBDGpBpPHDABBqCyACELECCyACQRBqJAALqAIBAn8jAEHQAGsiAyQAIANBMGogASACEC8Cf0ECIAMoAjBBAUYNABpBAiADKAI0IgRFDQAaIANBMGogBCADQThqKAIAENsCQQIgAy0ATCIEQQJGDQAaIANBKGogA0HIAGooAgA2AgAgA0EgaiADQUBrKQMANwMAIANBGGogA0E4aikDADcDACADQQ5qIANBzwBqLQAAOgAAIAMgAykDMDcDECADIAMvAE07AQwgBAshBCAAIAI2AgQgACABNgIAIAAgAykDEDcCCCAAQSRqIAQ6AAAgAEElaiADLwEMOwAAIABBEGogA0EYaikDADcCACAAQRhqIANBIGopAwA3AgAgAEEgaiADQShqKAIANgIAIABBJ2ogA0EOai0AADoAACADQdAAaiQAC+0BAQJ/IwBBIGsiBCQAIAACf0EAIAEoAgQiBSACayADTw0AGgJAAkAgAiADaiIDIAJPBEAgBUEBdCICIAMgAiADSxshAwwBCyAAIAM2AgQMAQsgBEKBgICAEDcDGCAEQQhqIARBGGogAxD0AiAEKAIIIQICQCAEKAIMIgUEQCACQQBIDQICfyABKAIEIgBFBEAgAiAFEKQFDAELIAEoAgAgAEEBIAIQlAULIgAEQCABIAM2AgQgASAANgIAQQAMBAsMAQsgACACNgIEDAELIAIgBRDdBQALIABBCGpBADYCAEEBCzYCACAEQSBqJAAL3wIBB38jAEEwayICJAACQAJAIAAtANEBRQRAIABBAToA0QEgAC0A0AEhAyAAKALMASEEIAJBKGogAEHIASAAKALIARCdBCACQSBqIAIoAiggAigCLEEBEJ4EIAIoAiRFDQEgAigCICIFIAUtAAAgA3M6AAAgAkEYaiAAQcgBIARBf2oQnQQgAkEQaiACKAIYIAIoAhxBARCeBCACKAIURQ0CIAIoAhAiAyADLQAAQYABczoAACAAELgFCyAAKALMASAAKALIASIFayEDQSAhBANAIAJBCGogAUEgIAYQnQQgAigCDCEHIAIoAgghCCAEIANPBEAgACAIIAcgBSADEP4CIAAQJyAEIANrIQQgAyAGaiEGIAAoAswBIQNBACEFDAELCyAAIAggByAFIAQQ/gIgACAEIAVqNgLIASACQTBqJAAPC0HMwcQAQQBBABDkAgALQdzBxABBAEEAEOQCAAuoAgEEfyMAQeAgayICJAAgAkEYaiIDQgA3AwAgAkEQaiIEQgA3AwAgAkEIaiIFQgA3AwAgAkIANwMAIAJBIGogASACQSAQOyAAAn8gAi0AMEEFRgRAIAJBIGoQygMgAkHYIGogAykDADcDACACQdAgaiAEKQMANwMAIAJByCBqIAUpAwA3AwAgAiACKQMANwPAICACQThqIAJBwCBqEA8gAEEEaiACQThqQYQgEPIDGkEADAELIAJByABqIAJBMGooAgA2AgAgAkFAayACQShqKQMANwMAIAIgAikDIDcDOCACQcAgaiACQThqELgEIABBFGogAkHQIGooAgA2AgAgAEEMaiACQcggaikDADcCACAAIAIpA8AgNwIEQQELNgIAIAJB4CBqJAALsAIBC38jAEEgayIEJAAgBEEANgIQIAIgAyAEQRBqEMkBIAQoAhAiBUEZdiIGQQh0IAZyIgZBEHQgBnIhCyABKAIEIgggBXEhBSABKAIIIQkgASgCACEMIAACfwJAA0AgBSAMaigAACIKIAtzIgFBf3MgAUH//ft3anFBgIGChHhxIQEgDUEEaiINIAVqIAhxIQYDQCABRQRAIAYhBSAKIApBAXRxQYCBgoR4cUUNAgwDCyABENIFIQcgAUF/aiABcSEBIAIgAyAJIAUgB2ogCHEiDkEMbGoiBygCACAHKAIEEL8FRQ0ACwsgB0UNACAAIAkgDkEMbGovAQg7AQJBAAwBCyAEQQE2AhAgBEEIaiAEQRBqEMEDIABBBGogBCkDCDcCAEEBCzsBACAEQSBqJAALygICBH8CfiMAQTBrIgMkACAAIAApAwgiByACrUIDhnwiCDcDCCAIIAdUBEAgACAAKQMAQgF8NwMACyADIABBEGo2AhggACgCUCEEIAMgA0EYajYCHAJAIARFDQBBgAEgBGsiBCACSw0AIANBIGogASACIAQQtwMgA0EsaigCACECIAMoAighASADKAIkIQQgAygCICEFIANBEGogAEHUAGoiBkGAASAAKAJQEJ0EIAMoAhAgAygCFCAFIAQQsQEgAEEANgJQIANBHGogBhC7BQsDQCACQYABTwRAIANBIGogASACQYABELcDIAMoAiwhAiADKAIoIQEgA0EcaiADKAIgELsFDAELCyADQQhqIAAoAlAiBCACIARqIABB1ABqQYABENQDIAMoAgggAygCDCABIAIQsQEgACAAKAJQIAJqNgJQIANBMGokAAvcAgIDfwF+QQIhAwJAAkACQCABQXdqIgRBHksEQCABQdwARw0BDAILQfQAIQICQAJAIARBAWsOHgECAgACAgICAgICAgICAgICAgICAgICAgMCAgICAwQLQfIAIQIMAwtB7gAhAgwCCyABQQp2IQICQAJAAkACQCABQYDYB08EQEEeIQMgAkGAB0cNBAwBCyACQb7BygBqLQAAIgNBHksNAQsgAUEGdkEPcSADQQR0ckG5wsoAai0AACICQYsBTw0BQQMhAyACQQN0QbDGygBqKQMAQgEgAUE/ca2Gg1ANAiABQQFyZ0ECdkEHc61CgICAgNAAhCEFDAMLQdDAygAgA0EfEOQCAAtB4MDKACACQYsBEOQCAAsgARAyBEBBASEDDAELIAFBAXJnQQJ2QQdzrUKAgICA0ACEIQVBAyEDCyABIQILIAAgAjYCBCAAIAM2AgAgAEEIaiAFNwIAC5oCAQZ/IAAoAgAiAygCCCEAIANBgYDEADYCCCAAQYGAxABGBH8gAygCACIBIAMoAgQiAEYEQEGAgMQADwsgAyABQQFqIgI2AgAgASwAACIEQX9KBEAgBEH/AXEPCwJ/IAAgAkYEQCAAIQJBAAwBCyADIAFBAmoiAjYCACABLQABQT9xCyEGIARBH3EhBSAEQf8BcUHfAU0EQCAGIAVBBnRyDwsCfyAAIAJGBEAgACEBQQAMAQsgAyACQQFqIgE2AgAgAi0AAEE/cQsgBkEGdHIhAiAEQf8BcUHwAUkEQCACIAVBDHRyDwsgACABRgR/QQAFIAMgAUEBajYCACABLQAAQT9xCyAFQRJ0QYCA8ABxIAJBBnRycgUgAAsL0AICBH8CfiMAQTBrIgEkACABIABBEGo2AiggAEHUAGohBCAAKQMAIQUgACkDCCEGIAAoAlAhAiABIAFBKGo2AiwCQAJAIAJBgAFGBEAgAUEsaiAEELsFQQAhAiAAQQA2AlAMAQsgAkH/AEsNAQsgAiAAQdQAaiIDakGAAToAACAAIAAoAlBBAWoiAjYCUCABQSBqIANBgAEgAhCdBCABKAIgQQAgASgCJBDBBBpBgAEgACgCUGtBD00EQCABQSxqIAQQuwUgAUEYaiADQYABIAAoAlAQngQgASgCGEEAIAEoAhwQwQQaCyABQRBqQfAAQfgAIANBgAEQ1AMgASgCECABKAIUIAUQqQIgAUEIaiADQYABQfgAEJ0EIAEoAgggASgCDCAGEKkCIAFBLGogBBC7BSAAQQA2AlAgAUEwaiQADwtB5ObJACACQYABEOQCAAuiAgEDfyMAQYABayIEJAACQAJAAn8CQCABKAIAIgNBEHFFBEAgACgCACECIANBIHENASACrSABEHcMAgsgACgCACECQQAhAANAIAAgBGpB/wBqIAJBD3EiA0EwciADQdcAaiADQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPDQIgAUG1rMoAQQIgACAEakGAAWpBACAAaxA1DAELQQAhAANAIAAgBGpB/wBqIAJBD3EiA0EwciADQTdqIANBCkkbOgAAIABBf2ohACACQQR2IgINAAsgAEGAAWoiAkGBAU8NAiABQbWsygBBAiAAIARqQYABakEAIABrEDULIARBgAFqJAAPCyACQYABEOYCAAsgAkGAARDmAgAL3AIBAX8jAEHAA2siAyQAIAJBIEcEQCADQQhqQomAgICABDcDACADQRBqIAMpAoACNwMAIANBGGogA0GIAmopAgA3AwAgA0EgaiADQZACaikCADcDACADQej6wQA2AgQgA0ECNgIAQfH6wQBBKyADQZz7wQBBwPzBABCoAgALIANBGGoiAkIANwMAIANBEGpCADcDACADQQhqQgA3AwAgA0IANwMAIANBICABQSAQrgEgAyACKQAANwCFAiADIAMpABM3A4ACIANB+AFqIAMpAIUCNwAAIAMgAy0AAjoA4gEgAyADLwEAOwHgASADIAMpAAs3AOsBIAMgAykAAzcA4wEgAyADKQOAAjcA8wEgA0GAAmogA0HgAWoQ0gEgAyADQaADakEgIAFBIBCHAiADQeABahCzAiADQYACaiADEL8DIAAgA0GAAmoQnwMgA0HAAWoQswIgA0HAA2okAAugAgIBfwF+IwBB8ABrIgMkACADIAI2AhQgAyABNgIQIANBIGoiAUIANwMAIANCADcDGCADQShqIANBEGogA0EYakEQEDsCfyADLQA4QQVGBEAgA0EoahDKAyADQeAAaiABKQMANwMAIAMgAykDGDcDWCADIANB2ABqEPADIAMpAwAhBCAAQRBqIAMpAwg3AwAgAEEIaiAENwMAQQAMAQsgA0HoAGogA0E4aigCADYCACADQeAAaiADQTBqKQMANwMAIAMgAykDKDcDWCADQUBrIANB2ABqELgEIABBFGogA0HQAGooAgA2AgAgAEEMaiADQcgAaikDADcCACAAIAMpA0A3AgRBAQshASADQRBqEJgEIAAgATYCACADQfAAaiQAC7oCAQV/IwBBQGoiAiQAIAEoAgQiA0UEQCABQQRqIQMgASgCACEEIAJBADYCICACQgE3AxggAiACQRhqNgIkIAJBOGogBEEQaikCADcDACACQTBqIARBCGopAgA3AwAgAiAEKQIANwMoIAJBJGpB5JnKACACQShqEDMaIAJBEGoiBCACKAIgNgIAIAIgAikDGDcDCAJAIAEoAgQiBUUNACABQQhqKAIAIgZFDQAgBSAGQQEQtgULIAMgAikDCDcCACADQQhqIAQoAgA2AgAgAygCACEDCyABQQE2AgQgAUEMaigCACEEIAFBCGoiASgCACEFIAFCADcCAEEMQQQQpAUiAUUEQEEMQQQQ3QUACyABIAQ2AgggASAFNgIEIAEgAzYCACAAQcClygA2AgQgACABNgIAIAJBQGskAAu4AgIGfwJ+IwBBIGsiAiQAIAJBGGpCADcDACACQRBqQgA3AwAgAkEIakIANwMAIAJCADcDAANAAkAgA0EERwRAIANBAWohByACIANBA3RqIQVBACEDIAYhBANAIANBwABGDQIgBEEgRwRAIAUgBSkDACABIARqMQAAIANBOHGthoQ3AwAgA0EIaiEDIARBAWohBAwBCwtBjLvEACAEQSAQ5AIACyAAIAIpAxgiCEIQiDcDICAAIAIpAwAiCUL/////////B4M3AwAgACAIQiSGQoCAgICA/v8HgyACKQMQIghCHIiENwMYIAAgCEIYhkKAgID4////B4MgAikDCCIIQiiIhDcDECAAIAhCDIZCgOD//////weDIAlCNIiENwMIIAJBIGokAA8LIAZBCGohBiAHIQMMAAsAC7gCAgZ/An4jAEEgayICJAAgAkEYakIANwMAIAJBEGpCADcDACACQQhqQgA3AwAgAkIANwMAA0ACQCADQQRHBEAgA0EBaiEHIAIgA0EDdGohBUEAIQMgBiEEA0AgA0HAAEYNAiAEQSBHBEAgBSAFKQMAIAEgBGoxAAAgA0E4ca2GhDcDACADQQhqIQMgBEEBaiEEDAELC0Hk7MgAIARBIBDkAgALIAAgAikDGCIIQhCINwMgIAAgAikDACIJQv////////8HgzcDACAAIAhCJIZCgICAgID+/weDIAIpAxAiCEIciIQ3AxggACAIQhiGQoCAgPj///8HgyACKQMIIghCKIiENwMQIAAgCEIMhkKA4P//////B4MgCUI0iIQ3AwggAkEgaiQADwsgBkEIaiEGIAchAwwACwALugIBBH8jAEHQAGsiAiQAAn8gARCzBSIERQRAIAIgACAAKAIMEIUEIAIoAgQhAyACKAIADAELIAAoAgghA0EBIQUgACgCAAshACACQQhqELUBIAJBIGogAkEQaikDADcDACACIAQ6ACggAiACKQMINwMYIAJBPGpB/JHKADYCACACIAU6AEAgAkEANgI0IAIgATYCMCACIAJBGGo2AjgCfyACQTBqKAIAQemOygBBERCIBQR/QQEFQQALRQRAIANBGGwhAQNAQQAgAUUNAhogAkEANgJMIAIgAkEwajYCSCACQcgAaiAAEMoBRQRAIAIoAkgiAyADKAIEQQFqNgIEIAFBaGohASAAQRhqIQAMAQsLIAIoAkgiACAAKAIEQQFqNgIEQQEMAQtBAQsgAkEYahD6AiACQdAAaiQAC6oCAQJ/IwBBkARrIgIkACACIAEQPCAAAn8gAikDAEIBUgRAIAJB9wJqIAJB1AFqIgEpAAA3AAAgAkHwAmogAkHNAWoiAykAADcDACACIAIpAMUBNwPoAiACQcUBaiACQegCakGjARDyAxogAEEBOgAEIAAgAikAxQE3AAUgAEENaiADKQAANwAAIABBFGogASkAADcAAEEBDAELIAJB6AJqQQNyIAJBCGpBoAEQ8gMaIAJBxQFqIAJB6AJqQaMBEPIDGiACIAJByAFqQaABEPIDIgNBuAFqIAFBGGopAAA3AwAgA0GwAWogAUEQaikAADcDACADQagBaiABQQhqKQAANwMAIAMgASkAADcDoAEgAEEIaiADQcABEPIDGkEACzYCACACQZAEaiQAC7YCAQF/IwBBoARrIgQkACAEQaACaiACQdABEPIDGiAEQRhqIANBGGopAAA3AwAgBEEQaiADQRBqKQAANwMAIARBCGogA0EIaikAADcDACAEIAMpAAA3AwAgBEHgAGogASAEQaACaiAEEDggBCAEQeAAakHAABDyAyIBQdgAaiICIAFBuAFqKQMANwMAIAFB0ABqIgMgAUGwAWopAwA3AwAgAUHIAGoiBCABQagBaikDADcDACABIAEpA6ABNwNAIAFB4ABqIAEQ4AQgAUGgAmogAUHgAGpBwAEQ8gMaIAFB4ANqIAFBwAAQ8gMaIAAgAUGgAmpBgAIQ8gMiAEGYAmogAikDADcAACAAQZACaiADKQMANwAAIABBiAJqIAQpAwA3AAAgACABKQNANwCAAiABQaAEaiQAC/ABAgV/AX4jAEHQAGsiAyQAIANBMGogABDRBCADQSBqIANBMGpBlPXJABCFAyADIAMtACQiBzoALCADIAMoAiAiBTYCKCAAQQhqIQZBASEEAkAgAC0AEARAEO8FIAMoAhghAAJAQX8gAykDECIIIAFSIAggAVYbIgQEfyAEBSAAIAJLDQEgACACRwtBAUYNAgtBACEECyADIAc6ACwgAyAFNgIoIANBKGoQ0gQgA0HQAGokACAEDwsgAyABIAIgCCAAEIsDIAMpAwAaIAMoAggaIAYgBSgCABCoBCAGKAIAGkGLp8oAQR1B2KfKABC8BAAL1wIBAX8jAEGAA2siAyQAIAJBIEcEQCADQfAAakK5gICAgAQ3AwAgA0HsAGpBjYDAADYCACADQegAakENNgIAIANBAzoAYCADIAMvAAA7AGEgA0GAgMAANgJkIAMgA0ECai0AADoAY0HzgcAAQSsgA0HgAGpBoILAAEHcg8AAEKgCAAsgA0H4AGpCADcDACADQfAAakIANwMAIANB6ABqQgA3AwAgA0IANwNgIANB4ABqQSAgAUEgEK4BIANBAmogAy0AZiIBOgAAIANB/wJqIANB/wBqMQAAPAAAIAMgAygCYDYC4AIgAyADLwFkOwHkAiADIAE6AOYCIAMgAykAdzcA9wIgAyADKQBnNwDnAiADIAMpAG83AO8CIANB4ABqIANB4AJqEN8EIAMgA0HgAGoQkQEgACADQeAAEJwDIANB4ABqEKIFIANB4AJqEPMBIANBgANqJAALrgIBBH8jAEEwayIDJAAgACAAKQMAIAKtQgOGfDcDACADIABBzABqNgIYIAAoAgghBCADIANBGGo2AhwCQCAERQ0AQcAAIARrIgQgAksNACADQSBqIAEgAiAEELcDIANBLGooAgAhAiADKAIoIQEgAygCJCEEIAMoAiAhBSADQRBqIABBDGoiBkHAACAAKAIIEJ0EIAMoAhAgAygCFCAFIAQQsQEgAEEANgIIIANBHGogBhC6BQsDQCACQcAATwRAIANBIGogASACQcAAELcDIAMoAiwhAiADKAIoIQEgA0EcaiADKAIgELoFDAELCyADQQhqIAAoAggiBCACIARqIABBDGpBwAAQ1AMgAygCCCADKAIMIAEgAhCxASAAIAAoAgggAmo2AgggA0EwaiQAC8MCAgN/An4jAEFAaiIDJAAgAAJ/QQEgAC0ACA0AGiAAKAIEIQUgACgCACIELQAAQQRxRQRAQQEgBCgCGEGlrMoAQa+sygAgBRtBAkEBIAUbIARBHGooAgAoAgwRBAANARogASAAKAIAIAIoAgwRAgAMAQsgBUUEQEEBIAQoAhhBrazKAEECIARBHGooAgAoAgwRBAANARogACgCACEECyADQQE6ABcgA0E0akGErMoANgIAIAMgBCkCGDcDCCADIANBF2o2AhAgBCkCCCEGIAQpAhAhByADIAQtACA6ADggAyAHNwMoIAMgBjcDICADIAQpAgA3AxggAyADQQhqNgIwQQEgASADQRhqIAIoAgwRAgANABogAygCMEGjrMoAQQIgAygCNCgCDBEEAAs6AAggACAAKAIEQQFqNgIEIANBQGskAAvCAgIDfwJ+IwBBQGoiAiQAAn9BASAALQAEDQAaIAAtAAUhBCAAKAIAIgMtAABBBHFFBEAgASAEBH9BASADKAIYQaWsygBBAiADQRxqKAIAKAIMEQQADQIaIAAoAgAFIAMLQYiaygAoAgARAgAMAQsgBEUEQEEBIAMoAhhBsqzKAEEBIANBHGooAgAoAgwRBAANARogACgCACEDCyACQQE6ABcgAkE0akGErMoANgIAIAIgAykCGDcDCCACIAJBF2o2AhAgAykCCCEFIAMpAhAhBiACIAMtACA6ADggAiAGNwMoIAIgBTcDICACIAMpAgA3AxggAiACQQhqNgIwQQEgASACQRhqQYiaygAoAgARAgANABogAigCMEGjrMoAQQIgAigCNCgCDBEEAAshASAAQQE6AAUgACABOgAEIAJBQGskAAv2AQEGfyAAKAIAIgEgACgCBCIDRgRAQYCAxAAPCyAAIAFBAWoiAjYCACABLAAAIgRBf0oEQCAEQf8BcQ8LAn8gAiADRgRAIAMhAkEADAELIAAgAUECaiICNgIAIAEtAAFBP3ELIQYgBEEfcSEFIARB/wFxQd8BTQRAIAYgBUEGdHIPCwJ/IAIgA0YEQCADIQFBAAwBCyAAIAJBAWoiATYCACACLQAAQT9xCyAGQQZ0ciECIARB/wFxQfABSQRAIAIgBUEMdHIPCyABIANGBH9BAAUgACABQQFqNgIAIAEtAABBP3ELIAVBEnRBgIDwAHEgAkEGdHJyC6ECAQN/IwBBoAJrIgIkACACQSBqQQBB4AAQwQQaIAJBGGogAkEgakHgAEHAABCeBCACKAIcIQMgAigCGCACQcABakEAQcAAEMEEGiACQYACaiABQcABahDWAyACQYACahDJAyACQRBqIAJBwAFqQcAAQSAQngQgAigCECACKAIUIAJBgAJqQSAQrQEgAkEIaiACQcABakHAAEEgEJ0EIAIoAgggAigCDCABQeABakEgEK0BIAJBgAFqIAJBwAFqQcAAEPIDGiADIAJBgAFqQcAAEK0BIAIgAkEgakHgAEHAABCdBCACKAIEIQMgAigCACACQcABaiABQaABahDWAyADIAJBwAFqQSAQrQEgACACQSBqQeAAEPIDGiACQaACaiQAC5ACAQJ/IwBBkANrIgMkACADIAFBKGoiBCABENUDIANBKGogBCABEN8BIANB0ABqIAMgAhAeIANB+ABqIANBKGogAkEoahAeIANBoAFqIAFB+ABqIAJB+ABqEB4gA0HIAWogAUHQAGogAkHQAGoQHiADQfABaiADQcgBaiADQcgBahDVAyAAIANB0ABqIANB+ABqEN8BIANBmAJqIANB0ABqIANB+ABqENUDIANBwAJqIANB8AFqIANBoAFqENUDIANB6AJqIANB8AFqIANBoAFqEN8BIABBKGogA0GYAmpBKBDyAxogAEHQAGogA0HAAmpBKBDyAxogAEH4AGogA0HoAmpBKBDyAxogA0GQA2okAAuQAgECfyMAQZADayIDJAAgAyABQShqIgQgARDVAyADQShqIAQgARDfASADQdAAaiADIAJBKGoQHiADQfgAaiADQShqIAIQHiADQaABaiABQfgAaiACQfgAahAeIANByAFqIAFB0ABqIAJB0ABqEB4gA0HwAWogA0HIAWogA0HIAWoQ1QMgACADQdAAaiADQfgAahDfASADQZgCaiADQdAAaiADQfgAahDVAyADQcACaiADQfABaiADQaABahDfASADQegCaiADQfABaiADQaABahDVAyAAQShqIANBmAJqQSgQ8gMaIABB0ABqIANBwAJqQSgQ8gMaIABB+ABqIANB6AJqQSgQ8gMaIANBkANqJAALkQIBBX8jAEEQayIEJAAgACgCACEBAkADQCABIgJBBEkgAkECcXINASAAIAJBAnIgACgCACIBIAEgAkYbNgIAIAEgAkcNAAsDQCACQXxxIgUhAQNAIAEoAhQiA0UEQCABKAIcIgMgATYCGCADIQEMAQsLIAUgAzYCFAJAAkAgAkEBcUUEQCACIQEgAygCGCICRQ0BIAUgAjYCFCAAIAAoAgBBfXE2AgAMAgsgACACQX1xIAAoAgAiASABIAJGIgMbNgIAIAEhAiADRQ0CDAMLA0AgACABQQFxIAAoAgAiAiABIAJGIgEbNgIAIAENASACIQEgAkEESQ0ACwwBCwsgBCADEJkDIAQQ8wQLIARBEGokAAv/AQECfyMAQRBrIgIkACACQQA2AgwCfwJAAkAgAUGAAU8EQCABQYAQSQ0BIAJBDGohAyABQYCABE8NAiACIAFBP3FBgAFyOgAOIAIgAUEGdkE/cUGAAXI6AA0gAiABQQx2QQ9xQeABcjoADEEDDAMLIAIgAToADCACQQxqIQNBAQwCCyACIAFBP3FBgAFyOgANIAIgAUEGdkEfcUHAAXI6AAwgAkEMaiEDQQIMAQsgAiABQT9xQYABcjoADyACIAFBEnZB8AFyOgAMIAIgAUEGdkE/cUGAAXI6AA4gAiABQQx2QT9xQYABcjoADUEECyEBIAAgAyABEEYgAkEQaiQAC/0BAgR/AX4jAEEwayIBJAAgACgCACIAKAIAIQIgAEEANgIAIAAoAgQgASACKAIAKAIYEQMAKAIAIQAgAUEoaiIEIAFBEGooAgA2AgAgAUEgaiIFIAFBCGopAwA3AwAgASABKQMANwMYIABBBGohAgJAIAAoAgRFDQAgAEEIaigCACIARQ0AAn8CQCAAQQhqIgMgAEEFakkNACAAQQFqrUIMfiIGQiCIpw0AIANBfHEiAyAGp2oiACADSQ0AQQQMAQtBAAshAyACKAIAIAAgAxC2BQsgAiABKQMYNwIAIAJBEGogBCgCADYCACACQQhqIAUpAwA3AgAgAUEwaiQAC4oCAQJ/IwBBIGsiASQAAkACQAJAAkBB3PnKACgCACICQQFNBEACQAJAIAJBAWsEQCABQRBqEOoFIAEoAhBFDQEgASABQRBqNgIAIAEQoAUEQCABQRBqEJIFDAMLIAFBEGoQhgRFDQEMBQsgAEEANgIADAYLIAEQ6gUgASgCAEUNAiABIAE2AhwgAUEcahCgBSABEJIFIAFBEGoQkgVFDQQLQdz5ygBBAjYCAAsgAUEQahCEBCABEKICIAAgASkDEDcCACAAQQhqIAEpAwA3AgAgAEEQaiABQQhqKQMANwIADAMLIAEQkgULIAFBEGoQkgULIABBADYCAEHc+coAQQE2AgALIAFBIGokAAuYAgEBfyMAQdAAayICJAACfyAAKAIIRQRAIAIgAC0AEBChAyACQSRqQegANgIAIAJBxABqQQI2AgAgAkHoADYCHCACIAA2AhggAkIDNwI0IAJBvITKADYCMCACIAIpAwA3A0ggAiACQcgAajYCICACIAJBGGo2AkAgASACQTBqEOgCDAELIAIgAEEIajYCFCACQQhqIAAtABAQoQMgAkHEAGpB6QA2AgAgAkE8akHoADYCACACQSxqQQM2AgAgAkHoADYCNCACIAA2AjAgAkIDNwIcIAJB4ITKADYCGCACIAIpAwg3A0ggAiACQRRqNgJAIAIgAkHIAGo2AjggAiACQTBqNgIoIAEgAkEYahDoAgsgAkHQAGokAAuAAgECfyMAQfACayIDJAAgA0EIaiABQShqIgQgARDVAyADQTBqIAQgARDfASADQdgAaiADQQhqIAIQHiADQYABaiADQTBqIAJBKGoQHiADQagBaiABQfgAaiACQdAAahAeIANB0AFqIAFB0ABqIgEgARDVAyAAIANB2ABqIANBgAFqEN8BIANB+AFqIANB2ABqIANBgAFqENUDIANBoAJqIANB0AFqIANBqAFqENUDIANByAJqIANB0AFqIANBqAFqEN8BIABBKGogA0H4AWpBKBDyAxogAEHQAGogA0GgAmpBKBDyAxogAEH4AGogA0HIAmpBKBDyAxogA0HwAmokAAuAAgECfyMAQfACayIDJAAgA0EIaiABQShqIgQgARDVAyADQTBqIAQgARDfASADQdgAaiADQQhqIAJBKGoQHiADQYABaiADQTBqIAIQHiADQagBaiABQfgAaiACQdAAahAeIANB0AFqIAFB0ABqIgEgARDVAyAAIANB2ABqIANBgAFqEN8BIANB+AFqIANB2ABqIANBgAFqENUDIANBoAJqIANB0AFqIANBqAFqEN8BIANByAJqIANB0AFqIANBqAFqENUDIABBKGogA0H4AWpBKBDyAxogAEHQAGogA0GgAmpBKBDyAxogAEH4AGogA0HIAmpBKBDyAxogA0HwAmokAAulAgEDfyMAQSBrIgEkAAJAAkBB/PnKACgCACIAQQFqQQBKBEBB/PnKACAANgIAQYD6ygAoAgAiAkUEQCABQQA2AgggAUEIahBrIQJB/PnKACgCAA0DQfz5ygBBfzYCAAJAQYD6ygAoAgAiAEUNACAAIAAoAgAiAEF/ajYCACAAQQFHDQBBgPrKABDSAgtBgPrKACACNgIAQfz5ygBB/PnKACgCAEEBaiIANgIACyAADQJB/PnKAEF/NgIAIAIgAigCACIAQQFqNgIAIABBf0wNAUH8+coAQfz5ygAoAgBBAWo2AgAgAUEgaiQAIAIPC0HwmsoAQRggAUEYakHknMoAQYibygAQqAIACwALQYyaygBBECABQRhqQcScygBB4JrKABCoAgAL3gEBCH8gACABKAIMIAMoAgwgAigCCCIEQRp3IARBFXdzIARBB3dzamogASgCCCIGIAIoAgwiB3MgBHEgBnNqIgogASgCBGoiBTYCDCAAIAogASgCACIIIAIoAgAiAXEgAigCBCIJIAFxIgtzIAggCXFzIAFBHncgAUETd3MgAUEKd3NqaiICNgIEIAAgCCAGIAMoAghqIAcgBSAEIAdzcXNqIAVBGncgBUEVd3MgBUEHd3NqIgNqNgIIIAAgAkEedyACQRN3cyACQQp3cyACIAEgCXNxIAtzaiADajYCAAuHAgEEfyMAQbABayICJABBASEDIAJBEGoQmAMgAkHYAGogAkEoaikDADcDACACQdAAaiACQSBqKQMANwMAIAJByABqIAJBGGopAwA3AwAgAiACKQMQNwNAIAJBADYCaCACQgA3A2AgAkEwaiACQUBrIABBA2wiAEECTwRAQX8gAEF/amd2QQFqIQMLIAMQ2wQgAkEwaiIEIgAoAggiBSAAKAIERwRAIAAgBRC2AgsgAkEIaiAEKQIANwIAIAIoAgwhBCACKAIIIQVBEEEEEKQFIgBFBEBBEEEEEN0FAAsgACABNgIMIAAgBTYCACAAIAQ2AgQgAEEfIANnazYCCCACQbABaiQAIAALpwEBAX8gAAJ/QQAgASgCBCIEIAJrIANPDQAaAkACQCACIANqIgMgAk8EQCAEQQF0IgIgAyACIANLGyECDAELIAAgAzYCBAwBCwJAIAJBAE4EQAJ/IARFBEAgAkEBEKQFDAELIAEoAgAgBEEBIAIQlAULIgAEQCABIAI2AgQgASAANgIAQQAMBAsMAQsMAQsgAkEBEN0FAAsgAEEIakEANgIAQQELNgIAC/QBAQd/IwBBQGoiASQAIAFBIGoQywQgAUEIaiICIAFBKGoiBSkDADcDACABQRBqIgMgAUEwaiIGKQMANwMAIAFBGGoiBCABQThqIgcpAwA3AwAgASABKQMgNwMAIAAgASkDADcAACAAQQhqIAIpAwA3AAAgAEEQaiADKQMANwAAIABBGGogBCkDADcAACABQSBqEMsEIAIgBSkAADcDACADIAYpAAA3AwAgBCAHKQAANwMAIAEgASkAIDcDACAAIAEpAwA3ACAgAEEoaiACKQMANwAAIABBMGogAykDADcAACAAQThqIAQpAwA3AAAgAUFAayQAC/MBAgJ/BH4jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAAkBCACEFQgAgBkIBg30hBkEAIQMDQCADQQVGDQEgBEEIaiADEOIEKQMAIQdBgLzEACADEOIEKQMAIQggBEEIaiADEOMEIAcgBUI0iHwgBiAIg3wiBUL/////////B4M3AwAgA0EBaiEDDAALAAsFIAEgAxDiBCkDACEFIAIgAxDiBCkDACEHIARBCGogAxDjBCAFIAZ9IAd9IgVC/////////weDNwMAIAVCP4ghBiADQQFqIQMMAQsLIAAgBEEIakEoEPIDGiAEQTBqJAAL8wECAn8EfiMAQTBrIgQkACAEQQhqQQBBKBDBBBoDQCADQQVGBEACQEIAIQVCACAGQgGDfSEGQQAhAwNAIANBBUYNASAEQQhqIAMQ5QQpAwAhB0HY7cgAIAMQ5QQpAwAhCCAEQQhqIAMQ5gQgByAFQjSIfCAGIAiDfCIFQv////////8HgzcDACADQQFqIQMMAAsACwUgASADEOUEKQMAIQUgAiADEOUEKQMAIQcgBEEIaiADEOYEIAUgBn0gB30iBUL/////////B4M3AwAgBUI/iCEGIANBAWohAwwBCwsgACAEQQhqQSgQ8gMaIARBMGokAAvrAQIHfwR+IwBBIGsiByQAA0AgA0EgaiIEIAJLBEAgAyACSQRAIAcgACADaiIAIAIgA2siBBDyAyECIAAgASADaiIAIAQQ8gMaIAAgAiAEEPIDGgsgB0EgaiQABSAAIANqIgUpAAAhCiAFIAEgA2oiBikAADcAACAFQRhqIgMpAAAhCyADIAZBGGoiCCkAADcAACAFQRBqIgMpAAAhDCADIAZBEGoiCSkAADcAACAFQQhqIgMpAAAhDSADIAZBCGoiAykAADcAACADIA03AAAgCSAMNwAAIAggCzcAACAGIAo3AAAgBCEDDAELCwvtAQECfyMAQfACayICJAAgAkEIaiABEMgFIAJBMGogAUEoaiIDEMgFIAJB2ABqIAFB0ABqEPECIAJBgAFqIAEgAxDVAyACQagBaiACQYABahDIBSACQdABaiACQTBqIAJBCGoQ1QMgAkH4AWogAkEwaiACQQhqEN8BIAAgAkGoAWogAkHQAWoQ3wEgAkGgAmogAkH4AWpBKBDyAxogAkHIAmogAkHYAGogAkH4AWoQ3wEgAEEoaiACQdABakEoEPIDGiAAQdAAaiACQaACakEoEPIDGiAAQfgAaiACQcgCakEoEPIDGiACQfACaiQAC+kBAQN/IwBBgAJrIgMkACADQRhqQgA3AwAgA0EgakIANwMAIANBKGpCADcDACADQgA3AxAgA0IBNwMIIANCATcDMCADQThqQQBByAAQwQQaIAJBGHRBH3UiBCACaiAEcyEFQQEhAgNAIAJBCUYEQCAEQQFxEJYFIQEgA0GIAWogA0EIahCHAyADQQhqIANBiAFqIAEQrAQgACADQQhqQfgAEPIDGiADQYACaiQABSADIAU6AIcBIAMgAjoAiAEgA0EIaiABIANBhwFqIANBiAFqENcEEKwEIAFB+ABqIQEgAkEBaiECDAELCwviAQEGfyMAQRBrIgQkAEEIIQUCfyAAKAIAIgJBCE0EQCAAQQhqIQMgAgwBCyAAQQhqKAIAIQMgAiEFIABBDGooAgALIgYgAU0EQAJAAkAgAUEISwRAIAEgBUYNASAEQQhqIAEQqgIgBCgCCCADIAZBDGwQ8gMhByAAQQxqIAY2AgAgAEEIaiAHNgIAIABBATYCBCAAIAE2AgAgAkEJTw0BDAILIAJBCUkNASAAQQA2AgQgAEEIaiADIAZBDGwQ8gMaCyADIAUQtgQLIARBEGokAA8LQczxyQBBIEGM8skAELkEAAvfAQECfyMAQeAAayICJAAgAkEQaiABQQt2EIEDIAJBKGoiASACQRhqKAIANgIAIAIgAikDEDcDICACEMgENgIwIAJBCGogAkEgahCbBSACIAIoAgggAigCDBDaBDoANyACIAJBIGoQmwUgAkHMAGpBADoAACACQcQAaiACKAIAIgMgAigCBGo2AgAgAkEANgJQIAJByABqIAJBN2o2AgAgAkIANwM4IAIgAzYCQCACIAJBMGo2AlggACACQThqEM8BIABBFGogASgCADYCACAAIAIpAyA3AgwgAkHgAGokAAvoAQEDfyMAQSBrIgQkAAJAIANFBEAgAEEFOgAQDAELIARCADcDCCAEQQhqIgUoAgAEQCAFQQRqENADCyAEIAIgA0EAEMYEQYCABEF/IAEoAgBBAUYbIQUgBCgCACECIAQoAgQhAwNAIANBACACG0UEQCAAQQU6ABAMAgsgBEEIaiABIAIgBSADIAMgBUsbIgYQjAQgBC0AGEEFRgRAIAMgBmshAyACIAZqIQIgBEEIahCYBQwBCwsgACAEKQMINwIAIABBEGogBEEYaigCADYCACAAQQhqIARBEGopAwA3AgALIARBIGokAAvjAQEEfyMAQUBqIgIkACABQQRqIQQgASgCBEUEQCABKAIAIQMgAkEANgIgIAJCATcDGCACIAJBGGo2AiQgAkE4aiADQRBqKQIANwMAIAJBMGogA0EIaikCADcDACACIAMpAgA3AyggAkEkakHkmcoAIAJBKGoQMxogAkEQaiIDIAIoAiA2AgAgAiACKQMYNwMIAkAgASgCBCIFRQ0AIAFBCGooAgAiAUUNACAFIAFBARC2BQsgBCACKQMINwIAIARBCGogAygCADYCAAsgAEHApcoANgIEIAAgBDYCACACQUBrJAALLgEBfyMAQeAAayICJAAgAkEENgIIIAJBBDYCDCAAIAFBEBDyAxogAkHgAGokAAvTAQAgAAJ/AkACQCABQYABTwRAIAFBgBBJDQEgAUGAgARPDQIgAiABQT9xQYABcjoAAiACIAFBBnZBP3FBgAFyOgABIAIgAUEMdkEPcUHgAXI6AABBAwwDCyACIAE6AABBAQwCCyACIAFBP3FBgAFyOgABIAIgAUEGdkEfcUHAAXI6AABBAgwBCyACIAFBP3FBgAFyOgADIAIgAUESdkHwAXI6AAAgAiABQQZ2QT9xQYABcjoAAiACIAFBDHZBP3FBgAFyOgABQQQLNgIEIAAgAjYCAAvrAQIDfwF+QTggASgCGCIDayEEA0ACQAJAAn8gA0ELTwRAIAEgA0F1ajYCGCABIAEpAwAiBUILhjcDACAFQjWIpyEBQQEMAQsCQAJAAkACQCABLQAUQQFrDgICAQALIAEoAggiAiABKAIMRw0EIAFBAjoAFAsgASgCECECIAFBADYCECACDQQMAQsgASgCCCICIAEoAgxHDQILQQALIQIgACABOwECIAAgAjsBAA8LIAEgAkEBajYCCAsgAjEAACEFIAEgA0EIaiIDNgIYIAEgASkDACAFIARBP3GthoQ3AwAgBEF4aiEEDAALAAvLAQECfyMAQTBrIgMkACADQRBqIAEgAhCgAyADQQhqIANBEGoQmwUgA0EgaiADKAIIIAMoAgwQJEEBIQEgA0EoaigCACECIAMoAiQhBAJAIAMoAiBBAUcEQCADQSxqKAIAIQEgACADKQMQNwIEIABBGGogATYCACAAQRRqIAI2AgAgAEEQaiAENgIAIABBDGogA0EYaigCADYCAEEAIQEMAQsgAyAEIAIQpgUgACADKQMANwIEIANBEGoQgQULIAAgATYCACADQTBqJAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBJDYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQYT5wwA2AhAgBEEkNgIsIARB2PnDADYCWCAEQgE3AkwgBEHQ+cMANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBpPrDABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBJTYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQYi/xAA2AhAgBEElNgIsIARB3L/EADYCWCAEQgE3AkwgBEHUv8QANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBqMDEABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBKzYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQeDHxAA2AhAgBEErNgIsIARBtMjEADYCWCAEQgE3AkwgBEGsyMQANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBgMnEABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBLzYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQayryAA2AhAgBEEvNgIsIARBgKzIADYCWCAEQgE3AkwgBEH4q8gANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBzKzIABC9BAAL4QEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBxQA2AgAgBEEkakEDNgIAIAQgBEEIajYCQCAEIARBDGo2AkQgBEHcAGpBADYCACAEQgM3AhQgBEGY4skANgIQIARBxQA2AiwgBEHs4skANgJYIARCATcCTCAEQeTiyQA2AkggBCAEQShqNgIgIAQgBEHIAGo2AjggBCAEQcQAajYCMCAEIARBQGs2AiggBEEQakG448kAEL0EAAvhAQEBfyMAQeAAayIEJAAgBCABNgIIIAQgAzYCDCABIANGBEAgACACIAEQ8gMaIARB4ABqJAAPCyAEQTxqQSE2AgAgBEE0akHiADYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQZj6yQA2AhAgBEHiADYCLCAEQez6yQA2AlggBEIBNwJMIARB5PrJADYCSCAEIARBKGo2AiAgBCAEQcgAajYCOCAEIARBxABqNgIwIAQgBEFAazYCKCAEQRBqQbj7yQAQvQQAC+EBAQF/IwBB4ABrIgQkACAEIAE2AgggBCADNgIMIAEgA0YEQCAAIAIgARDyAxogBEHgAGokAA8LIARBPGpBITYCACAEQTRqQfwANgIAIARBJGpBAzYCACAEIARBCGo2AkAgBCAEQQxqNgJEIARB3ABqQQA2AgAgBEIDNwIUIARBvIrKADYCECAEQfwANgIsIARBkIvKADYCWCAEQgE3AkwgBEGIi8oANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpB3IvKABC9BAAL0wEBBX8jAEFAaiICJAAgAkEIaiABEEcCQCACKAIIIgQEQCACKAIMIQUgAhC0AiACKAIEIQYgAigCACIDIAU2AgQgAyAENgIAIAJBATYCGCACIAY2AhQgAiADNgIQIAJBOGogAUEYaikCADcDACACQTBqIAFBEGopAgA3AwAgAkEoaiABQQhqKQIANwMAIAIgASkCADcDICACQRBqIAJBIGoQjwMgAEEIaiACKAIYNgIAIAAgAikDEDcCAAwBCyAAQQA2AgggAEIENwIACyACQUBrJAAL/gEBA38jAEEQayICJAACQAJAQSNBARCkBSIBBEAgAUEfakGHp8oAKAAANgAAIAFBGGpBgKfKACkAADcAACABQRBqQfimygApAAA3AAAgAUEIakHwpsoAKQAANwAAIAFB6KbKACkAADcAAEEMQQQQpAUiA0UNASADQqOAgICwBDcCBCADIAE2AgBBDEEEEKQFIgFFDQIgAUEQOgAIIAFBqKHKADYCBCABIAM2AgAgASACLwANOwAJIAFBC2ogAkEPai0AADoAACAAQQhqIAE2AgAgAEKBgICAIDcCACACQRBqJAAPC0EjQQEQ3QUAC0EMQQQQ3QUAC0EMQQQQ3QUAC7wBAgN/AX4CQCACRQRAIABBADoAAQwBCwJAAkAgAS0AAEErRgRAIAJBf2oiAkUNASABQQFqIQELAkACQANAIAJFDQIgAS0AAEFQaiIEQQlLDQEgA61CCn4iBkIgiKcNBCABQQFqIQEgAkF/aiECIAQgBqciBWoiAyAFTw0ACwwDCyAAQQE6AAEMAwsgAEEEaiADNgIAIABBADoAAA8LIABBADoAASAAQQE6AAAPCyAAQQI6AAELIABBAToAAAvhAQEBfyMAQcABayICJAAgASABLQAAQfgBcToAACABIAEtAB9BP3FBwAByOgAfIAJBGGogAUEYaikAADcDACACQRBqIAFBEGopAAA3AwAgAkEIaiABQQhqKQAANwMAIAIgASkAADcDACACQaABaiACELsDIAIgAkGgAWpB8LrGABDNBSACQaABaiACENgBIAAgAkGgARDyAyIAQbgBaiACQbgBaikDADcAACAAQbABaiACQbABaikDADcAACAAQagBaiACQagBaikDADcAACAAIAIpA6ABNwCgASACQcABaiQAC+EBAQF/IwBBsAVrIgUkACAFQagDaiABIAIQKyAFQagBaiAFQagDakGcg8AAEMgCIAVBCGogAyAEEKQCIAVBwQNqIAVBIGopAwA3AAAgBUG5A2ogBUEYaikDADcAACAFQbEDaiAFQRBqKQMANwAAIAVBAToAqAMgBSAFKQMINwCpAyAFQegAaiAFQegCaiAFQagDahBoIAVBqANqIAVB6ABqEN8EIAVBCGogBUGoA2oQkQEgACAFQQhqQeAAEJwDIAVBqANqEKIFIAVB6ABqEPMBIAVBqAFqEKIFIAVBsAVqJAAL4QEBAn8jAEHQAGsiAiQAIAEoAsABQf8AcSIDBEAgAkEIaiABIAMQxAQgAigCCEEAIAIoAgwQwQQaCyABQn8QCyACQShqIAFBmAFqKQMANwMAIAJBIGogAUGQAWopAwA3AwAgAkEYaiABQYgBaikDADcDACACQThqIAFBqAFqKQMANwMAIAJBQGsgAUGwAWopAwA3AwAgAkHIAGogAUG4AWopAwA3AwAgAiABKQOAATcDECACIAFBoAFqKQMANwMwIAEoAsgBIQEgACACQRBqQcAAEPIDIAE2AkAgAkHQAGokAAvLAQEDfyMAQSBrIgEkACAAKAIIQRhsIQIgACgCAEEMaiEAA0ACQAJAIAIEQCAAKAIARQ0BDAILIAFBIGokAA8LIAFBADYCCCABQgQ3AwACQCAAQXRqKAIAQQFGBEAgAEF4aigCABCOBAwBCyAAQXhqEI4ECyABQRhqIgMgAUEIaigCADYCACABIAEpAwA3AxAgACgCAARAIAAQowMgABD0BAsgACABKQMQNwIAIABBCGogAygCADYCAAsgAkFoaiECIABBGGohAAwACwAL3AEBBH8jAEEgayIDJAACQAJAIAEEQCADIAE2AgwgAyAANgIIIANBEGogA0EIahAhIAMoAhAiAARAA0AgAygCHCEFIAMoAhQiBiABRg0DQQEhBCACKAIYIAAgBiACKAIcKAIMEQQADQQgBQRAIAIoAhhB/f8DIAIoAhwoAhARAgANBQsgA0EQaiADQQhqECEgAygCECIADQALC0EAIQQMAgsgAkHEqsoAQQAQLiEEDAELIAVFBEAgAiAAIAEQLiEEDAELQdCwygBBI0GMscoAEM4DAAsgA0EgaiQAIAQL0QEBAX8jAEGgBWsiBSQAIAUgAzYCDCAFIAI2AgggBUEQahCyAyAFQagDaiABQaABEPIDGiAFQYgCaiAFQagDahDiBSAFQRBqIAQQxgUgBUEQaiABQaABahDGBSAFQRBqIAVBCGoQrgQgBUGoA2ogBUEQakHYARDyAxogBUHoAWogBUGoA2oQ4gIgBUGoA2ogBUHoAWogBUGIAmogBEEgahA6IAVBgAVqIAVBqANqENgBIABBBUEDIAVBgAVqQSAgBEEgEKMEGzYCACAFQaAFaiQAC58CAQF/IwBB0AFrIgQkACABQX9qQT9LIANBwQBPckUEQCAEQQBBgAEQwQQiBEG4AWpC+cL4m5Gjs/DbADcDACAEQbABakLr+obav7X2wR83AwAgBEGoAWpCn9j52cKR2oKbfzcDACAEQaABakLRhZrv+s+Uh9EANwMAIARBmAFqQvHt9Pilp/2npX83AwAgBEGQAWpCq/DT9K/uvLc8NwMAIARBiAFqQrvOqqbY0Ouzu383AwAgBEIANwPAASAEIAE2AsgBIAQgAa0gA61CCIaFQoiS95X/zPmE6gCFNwOAASADBEAgBEGAASACIAMQ5AQgBEKAATcDwAELIAAgBEHQARDyAxogBEHQAWokAA8LQezExABBMUH8xcQAEK0EAAvsAQEBfyMAQRBrIgIkAAJAAkACQAJAAkACQCAAKAIAQQFrDgQCAwQAAQsgAiABQdTfyQBBFBCcBCACIABBBGo2AgwgAiACQQxqQejfyQAQjgEgAiAAQQhqNgIMIAIgAkEMakH438kAEI4BDAQLIAIgAUGy4MkAQQ8QnAQMAwsgAiABQafgyQBBCxCcBAwCCyACIAFBmeDJAEEOEJwEIAIgAEEEajYCDCACIAJBDGpB6N/JABCOAQwBCyACIAFBiODJAEEREJwEIAIgAEEEajYCDCACIAJBDGpB6N/JABCOAQsgAhCAAiACQRBqJAALuQEBAX8jAEFAaiIDJAAgA0E4aiACQQhqKAIANgIAIAMgAikCADcDMCADQSBqIANBMGoQogMCQAJAIAAtABANACAAKAIADQAgA0EYaiADKAIgIAMoAiggAEEEahCNBCADKAIYIgBFDQAgA0EQaiAAIAMoAhwQpgUgAyADKQMQNwMwDAELIANBCGogAygCICADKAIoEKYFIAMgAykDCDcDMAsgA0EwaiABEPEDIANBIGoQgQUgA0FAayQAC4UCAQJ/IwBBIGsiBCQAQQEhBQJAAkACQEGI+soAKAIAQQFHBEBBiPrKAEKBgICAEDcDAAwBC0GM+soAQYz6ygAoAgBBAWoiBTYCACAFQQJLDQELIAQgAzYCHCAEIAI2AhggBEHsm8oANgIUIARB7JvKADYCEEHs+coAKAIAIgJBf0wNAEHs+coAIAJBAWoiAjYCAEHs+coAQfT5ygAoAgAiAwR/QfD5ygAoAgAgBEEIaiAAIAEoAhARAAAgBCAEKQMINwMQIARBEGogAygCDBEAAEHs+coAKAIABSACC0F/ajYCACAFQQFNDQELAAsjAEEQayICJAAgAiABNgIMIAIgADYCCAALwwEBA38jAEFAaiICJAAgAkEAQcAAEMEEIgQhAgNAIANBIEYEQAJAQQAhAwNAIANBP0YNASADIARqIgEgAS0AACICIAJBCGoiAkHwAXFrOgAAIAFBAWoiASABLQAAIAJBGHRBGHVBBHZqOgAAIANBAWohAwwACwALBSACIAEgAxDtBC0AAEEPcToAACACQQFqIAEgAxDtBC0AAEEEdjoAACACQQJqIQIgA0EBaiEDDAELCyAAIARBwAAQ8gMaIARBQGskAAvDAQEDfyMAQUBqIgIkACACQQBBwAAQwQQiBCECA0AgA0EgRgRAAkBBACEDA0AgA0E/Rg0BIAMgBGoiASABLQAAIgIgAkEIaiICQfABcWs6AAAgAUEBaiIBIAEtAAAgAkEYdEEYdUEEdmo6AAAgA0EBaiEDDAALAAsFIAIgASADEO4ELQAAQQ9xOgAAIAJBAWogASADEO4ELQAAQQR2OgAAIAJBAmohAiADQQFqIQMMAQsLIAAgBEHAABDyAxogBEFAayQAC78BAQN/AkAgACgCACIAQQRqKAIAIgQgAEEIaigCACIDayACTwRAIAAoAgAhBAwBCwJAIAIgA2oiBSADSQ0AIARBAXQiAyAFIAMgBUsbIgNBAEgNAAJ/IARFBEAgA0EBEKQFDAELIAAoAgAgBEEBIAMQlAULIgQEQCAAIAQ2AgAgAEEEaiADNgIAIABBCGooAgAhAwwCCyADQQEQ3QUACxDCBQALIABBCGogAiADajYCACADIARqIAEgAhDyAxpBAAu8AQIEfwF+IwBB4ABrIgAkACAAEJcFIABB2ABqIgEgAEEYaikDADcDACAAQdAAaiICIABBEGopAwA3AwAgAEHIAGoiAyAAQQhqKQMANwMAIAAgACkDADcDQEHw+soAIABBQGtBIBCiASAAQThqIAEpAwA3AwAgAEEwaiACKQMAIgQ3AwAgAEEoaiADKQMANwMAIAAgACkDQDcDICAEp0H/AXFBAkcEQCAAQSBqEIQFCyAAQeAAaiQAQfD6ygALuQEBAX8jAEHAA2siAiQAIAJBqAFqIAFBKBDyAxogAkHQAWogAUEoakEoEPIDGiACQfgBaiABQdAAakEoEPIDGkEDIQEDQCABBEAgAkGgAmogAkGoAWoQowEgAkEIaiACQaACakGgARDyAxogAkGgAmogAkEIahDyAiACQagBaiACQaACakH4ABDyAxogAUF/aiEBDAEFIAJBoAJqIAJBqAFqEKMBIAAgAkGgAmoQgwIgAkHAA2okAAsLC9EBAQJ/IwBBEGsiAiQAIAEoAhhB/cDKAEENIAFBHGooAgAoAgwRBAAhAyACQQA6AAUgAiADOgAEIAIgATYCACACIAA2AgwgAkHwwMoAQQQgAkEMakGMwcoAEGogAi0ABCEBIAItAAUEQCACAn9BASABQf8BcQ0AGiACKAIAIgBBHGooAgAoAgwhASAAKAIYIQMgAC0AAEEEcUUEQCADQausygBBAiABEQQADAELIANBqqzKAEEBIAERBAALIgE6AAQLIAJBEGokACABQf8BcUEARwvEAQECfyMAQYAPayICJAAgAkHgDWogARCJAgNAIANBgApGBEACQCACQYAKaiABENUCQQAhAwNAIANB4AhGDQEgAkHgDWogAkGACmogAiADaiIBEJIBIAJBwAxqIAJB4A1qEIMCIAJBoAtqIAJBwAxqEIkCIAFBoAFqIAJBoAtqQaABEPIDGiADQaABaiEDDAALAAsFIAIgA2ogAkHgDWpBoAEQ8gMaIANBoAFqIQMMAQsLIAAgAkGAChDyAxogAkGAD2okAAvEAQECfyMAQYAPayICJAAgAkHgDWogARCKAgNAIANBgApGBEACQCACQYAKaiABENUCQQAhAwNAIANB4AhGDQEgAkHgDWogAkGACmogAiADaiIBEJIBIAJBwAxqIAJB4A1qEIMCIAJBoAtqIAJBwAxqEIoCIAFBoAFqIAJBoAtqQaABEPIDGiADQaABaiEDDAALAAsFIAIgA2ogAkHgDWpBoAEQ8gMaIANBoAFqIQMMAQsLIAAgAkGAChDyAxogAkGAD2okAAvDAQEDfyMAQRBrIgMkACACKAIAIQQDQCABQQNNBEAgAUEBSwRAIAAvAAAhBSADQQhqIAAgAUECEMYEIARBBXcgBXNBufPd8XlsIQQgAygCDCEBIAMoAgghAAsgAiABBH8gAC0AACAEQQV3c0G5893xeWwFIAQLQQV3Qf8Bc0G5893xeWw2AgAgA0EQaiQABSAAKAAAIQUgAyAAIAFBBBDGBCAEQQV3IAVzQbnz3fF5bCEEIAMoAgQhASADKAIAIQAMAQsLC7MBAQV/IwBBQGoiBCQAIAEoAgwiA0H8kcoAIAMbIQIgAUEUaigCAEEAIAMbIgVBKGwhAwJAA0ACQCADQQAgAhtFBEBBACECIAUNAyABKAIEIQIgASgCACEBIARBAzoALCAEQQI2AjAgACACQQAgAUEBRhsgBEEIaiAEQTBqQQBBACICECMNAQwDCyAAIAEgAhDVASADQVhqIQMgAkEoaiECRQ0BCwtBASECCyAEQUBrJAAgAgu3AQEBfyMAQSBrIgUkACAFIAI2AgQgBSABNgIAIAUgAzYCCCAFIAQ2AgwCQCAEIANJDQAgA0UgAiADRnJFBEAgAiADTQ0BIAEgA2osAABBv39MDQELIARFIAIgBEZyRQRAIAIgBE0NASABIARqLAAAQb9/TA0BCyAAIAQgA2s2AgQgACABIANqNgIAIAVBIGokAA8LIAUgBUEMajYCGCAFIAVBCGo2AhQgBSAFNgIQIAVBEGoQ7wQAC7wBAQR/IwBBIGsiAiQAAkAgASwAHyIDQQBOBEAgAkEXaiABQRdqKQAANwAAIAJBEGoiBCABQRBqKQAANwMAIAJBCGoiBSABQQhqKQAANwMAIAIgASkAADcDACACIANB/wBxOgAfIAAgAhDWBAR/IAAgAikDADcAASAAQRlqIAJBGGopAwA3AAAgAEERaiAEKQMANwAAIABBCWogBSkDADcAAEEBBUEACzoAAAwBCyAAQQA6AAALIAJBIGokAAu8AQEEfyMAQSBrIgIkAAJAIAEsAB8iA0EATgRAIAJBF2ogAUEXaikAADcAACACQRBqIgQgAUEQaikAADcDACACQQhqIgUgAUEIaikAADcDACACIAEpAAA3AwAgAiADQf8AcToAHyAAIAIQ2QQEfyAAIAIpAwA3AAEgAEEZaiACQRhqKQMANwAAIABBEWogBCkDADcAACAAQQlqIAUpAwA3AABBAQVBAAs6AAAMAQsgAEEAOgAACyACQSBqJAALxQEBAn8jAEEgayIDJAACfwNAAkAgAUUNACADQQhqIAAgARAvAkACQCADKAIIQQFGBEAgAyADKQIMNwMYQZCSygBBAyACEN8FDQEgAyADQRhqIgRBBWotAAA2AgQgAyAELQAENgIAIAMoAgBFDQMgASADQRhqKAIAIAMoAgRqIgRPDQIgBCABEOYCAAtBACADKAIMIANBEGooAgAgAhDfBUUNBBoLQQEMAwsgACAEaiEAIAEgBGshAQwBCwtBAAsgA0EgaiQAC7sBAQN/IwBBIGsiAiQAIAJBCGogARCNAwJAIAIoAggiA0UEQCAAQQA2AgggAEIBNwIADAELIAIoAgwhBCACQRBqIAEQ0wEgAkEQaiACKAIQQQtsEP0DIAJBEGogAyAEEK4FA0AgAiABEI0DIAIoAgAiAwRAIAIoAgQhBCACQRBqQYjyyABBARCuBSACQRBqIAMgBBCuBQwBCwsgACACKQMQNwIAIABBCGogAkEYaigCADYCAAsgAkEgaiQAC7YBAQF/IAAoAgAiBEEANgIAIARBeGoiACAAKAIAQX5xNgIAAkAgAiADKAIUEQYARQ0AAkAgBEF8aigCAEF8cSICBEAgAi0AAEEBcUUNAQsgACgCACIDQXxxIgJFIANBAnFyDQEgAi0AAEEBcQ0BIAQgAigCCEF8cTYCACACIABBAXI2AggPCyAAEJ8CIAAtAABBAnEEQCACIAIoAgBBAnI2AgALDwsgBCABKAIANgIAIAEgADYCAAu3AQEEfyMAQZACayIDJAAgA0EANgIAIANBiAFqIAMQxAMgAygCjAEgAygCiAEiBmsiBSACIAFrIgIgAiAFSxshBSADKAKQASECA0AgBCAFTwRAIAMoAgAiAUGAAUkEQCABENkCAAsFIAQgBmogASAEai0AADoAACACIAIoAgBBAWo2AgAgBEEBaiEEDAELCyADQYgBaiADQYQBEPIDGiAAIANBiAFqQQRyQYABEPIDGiADQZACaiQAC8MBAQF/IwBB4ARrIgIkACACQRBqELIDIAJB6AFqQQBBwAAQwQQaIAJBwAJqQgA3AwAgAkG4AmpCADcDACACQbACakIANwMAIAJCADcDqAIgAkEQaiABEMYFIAJBiANqIAJBEGpB2AEQ8gMaIAJByAJqIAJBiANqEKEEIAJBCGogAkHIAmoQqQUgAkHoAWpBwAAgAigCCCACKAIMELABIAJBqAJqQSAgAkHoAWpBIBCwASAAIAJBqAJqELcBIAJB4ARqJAALpQEBAn8gAAJ/AkACfwJAAkAgAUEUai0AAEEBaw4CAQADCyABQRBqKAIAQQBHDAELIAFBDGooAgAgASgCCGsLQQN0QQtuIgIhAUEBDAELQX8gAUEMaigCACABKAIIayICIAFBEGooAgBBAEdqIgEgASACSSIDG0EDdEELbiECQQAgAw0AGiABQQN0QQtuIQFBAQs2AgQgACACNgIAIABBCGogATYCAAvFAQEGfyMAQYABayIEJAAgACAAKAIIIAEQqwMgACgCACEDIAAoAgghBSAEQQhqQQEgARCmBSAFQfAAbCADaiEGIAQoAgwhByAEKAIIIQMDQAJAIAMgB0kEQCADQQFqIgggA08NAQsgACABBH8gBiACQfAAEK0CIAVBAWoFIAULNgIIIARBgAFqJAAPCyAEQRBqIgMQmAMgA0EANgIoIANCADcDICAFQQFqIQUgBiAEQRBqQfAAEPIDQfAAaiEGIAghAwwACwALpgEBBX8jAEFAaiIDJAAgASgCBCEGIAEoAgAhByADQQhqIAIQ6gRBACEBQQIhBSADIAIoAhQiBAR/IAMgBCACQRxqKAIAEMYDIAMoAgAiBAR/IANBOGogAygCBDYCACADIAQ2AjRBAAUgBQsFIAULNgIwIAAgBkEAIAdBAUYbIANBCGogA0EwaiACKAIgIAJBJGooAgAQIwRAQQEhAQsgA0FAayQAIAELvgEBAn8jAEHQAGsiAiQAIAIgACgCACIDNgIUAn8gAygCAARAIAJBCGogABDKBCACQTxqQfgANgIAIAJBLGpBAjYCACACQfkANgI0IAJCAjcCHCACQbiGygA2AhggAiACKQMINwNIIAIgAkHIAGo2AkQgAiACQRRqNgI4IAIgAkHEAGo2AjAgAiACQTBqNgIoIAEgAkEYahDoAgwBCyACIAAQygQgAigCACABIAIoAgQoAjARAgALIAJB0ABqJAALzAEBAX8jAEGABWsiCCQAIAggBzYCDCAIQRBqIABByAEQ8gMiByAALQDKAToAygEgByAALwHIATsByAEgBkEDdCEGA0AgBgRAIAhBsANqIAhBEGpB0AEQ8gMaIAhBEGogCEGwA2ogASACIAUoAgAgBSgCBBC6AyAGQXhqIQYgBUEIaiEFDAEFIAhBsANqIAhBEGpB0AEQ8gMaIAhB4AFqIAhBsANqIAhBDGoQ5wEgCEHgAWogAyAEEPYDIAhB4AFqELcFIAhBgAVqJAALCwunAQEBfyMAQaABayICJAAgAkEIaiABQdAAahD/AiACQTBqIAEgAkEIahAeIAJB2ABqIAFBKGogAkEIahAeIAJBgAFqIAJB2ABqEEMgAEEXaiACQZcBaikAADcAACAAQRBqIAJBkAFqKQAANwAAIABBCGogAkGIAWopAAA3AAAgACACKQCAATcAACAAIAItAJ8BIAJBMGoQwgRBB3RzOgAfIAJBoAFqJAALvAEBA38jAEGgAmsiASQAIAFBADYCACABQZgBaiABEMQDIAEoAqABIQIgAUGYAWogASgCmAEgASgCnAEQiwUgAUGIAWogAUGYAWoQ+QQgAUGgAWogAUGQAWooAgA2AgAgASABKQOIATcDmAEDQCABQZgBahCJBCIDBEAgA0HcADoAACACIAIoAgBBAWo2AgAMAQUgAUGYAWogAUGEARDyAxogACABQZgBakEEckGAARDyAxogAUGgAmokAAsLC7sBAQN/IwBBoAJrIgEkACABQQA2AgAgAUGYAWogARDEAyABKAKgASECIAFBmAFqIAEoApgBIAEoApwBEIsFIAFBiAFqIAFBmAFqEPkEIAFBoAFqIAFBkAFqKAIANgIAIAEgASkDiAE3A5gBA0AgAUGYAWoQiQQiAwRAIANBNjoAACACIAIoAgBBAWo2AgAMAQUgAUGYAWogAUGEARDyAxogACABQZgBakEEckGAARDyAxogAUGgAmokAAsLC6gBAgR/AX4jAEEgayICJAAgAkEIaiAAEJQCAkAgAi0AGCIDQQVHBEAgAkEUaigCACEEQsAAIQYgAigCECEFIANBAkcEQCAAKQMAIgZCCIcgBiADGyEGCyAFRQ0BIAUgBCgCABEDACAEKAIEIgNFDQEgBSADIAQoAggQtgUMAQsgAEEANgKcICAAKQMAIQYLIAAgBkJAfDcDCCAAQRBqIAEQESACQSBqJAALqwEBAn8jAEGgwABrIgEkACABQQQ2AgggAUGYIGogAUEIahB8IAFBmCBqQQRyIQIgASgCmCBBAUYEQCABQSBqIAJBEGooAgA2AgAgAUEYaiACQQhqKQIANwMAIAEgAikCADcDECABQRBqEK0DAAsgAUEQaiACQYQgEPIDGiABQZggaiABQRBqQYQgEPIDGiAAIAFBmCBqIAEoAgggASgCDBCXAiABQaDAAGokAAu9AQECfyMAQRBrIgIkACABQQEgARshAQJAIABFDQAgAEEDakECdiEAAkAgAUEESw0AIABBf2oiA0H/AUsNACACQZjQygA2AgQgAiADQQJ0QZzQygBqIgMoAgA2AgwgACABIAJBDGogAkEEakGU/sEAEOECIQEgAyACKAIMNgIADAELIAJBmNDKACgCADYCCCAAIAEgAkEIakH8/cEAQfz9wQAQ4QIhAUGY0MoAIAIoAgg2AgALIAJBEGokACABC7gBAQF/IwBBEGsiAyQAAkAgAEUNACADIAA2AgQgAUUNAAJAIAJBBEsNACABQQNqQQJ2QX9qIgBB/wFLDQAgA0GY0MoANgIIIAMgAEECdEGc0MoAaiIAKAIANgIMIANBBGogA0EMaiADQQhqQZT+wQAQ0AEgACADKAIMNgIADAELIANBmNDKACgCADYCDCADQQRqIANBDGpB/P3BAEH8/cEAENABQZjQygAgAygCDDYCAAsgA0EQaiQAC+MBAQJ+IAAgASkDICACKQMgfULw////////P3wiBEL/////////A4MgASkDGCACKQMYfULw////////P3wiA0IziHw3AyAgACADQv////////8DgyABKQMQIAIpAxB9QvD///////8/fCIDQjOIfDcDGCAAIANC/////////wODIAEpAwggAikDCH1C8P///////z98IgNCM4h8NwMQIAAgA0L/////////A4MgASkDACACKQMAfULQ/f//////P3wiA0IziHw3AwggACAEQjOIQhN+IANC/////////wODfDcDAAvDAQACQAJAAkACQAJAAkACQAJAIAFBAU0EQCABQQFrDQEMAgsgAUEDSQ0CIAFBA0YNAyABQQVJDQQgAUEFRg0FIAFBB0kNBiABQQdGDQcgACkAAA8LQdT7wwBBAEEAEOQCAAtB5PvDAEEBQQEQ5AIAC0H0+8MAQQIgARDkAgALQYT8wwBBA0EDEOQCAAtBlPzDAEEEIAEQ5AIAC0Gk/MMAQQVBBRDkAgALQbT8wwBBBiABEOQCAAtBxPzDAEEHQQcQ5AIAC8MBAAJAAkACQAJAAkACQAJAAkAgAUEBTQRAIAFBAWsNAQwCCyABQQNJDQIgAUEDRg0DIAFBBUkNBCABQQVGDQUgAUEHSQ0GIAFBB0YNByAAKQAADwtB/K3IAEEAQQAQ5AIAC0GMrsgAQQFBARDkAgALQZyuyABBAiABEOQCAAtBrK7IAEEDQQMQ5AIAC0G8rsgAQQQgARDkAgALQcyuyABBBUEFEOQCAAtB3K7IAEEGIAEQ5AIAC0HsrsgAQQdBBxDkAgALrAEBAX8jAEHQAGsiBCQAIAQgAzYCHCAEIAI2AhggBEEQaiAEQRhqQQcQpgUgBEHEAGpBATYCACAEQgE3AjQgBEGc3ckANgIwIAQgBCkDEDcDSCAEIARByABqNgJAIARBIGogBEEwahBmIARBCGogARCbBSAEKAIMIQEgBCgCCCECIAQgBEEgahCbBSAAIAIgASAEKAIAIAQoAgQQHyAEQSBqEIEFIARB0ABqJAALwwEBAX8jAEHwBGsiBSQAIAVBoANqQa7wwwBBDhD1AyAFQaADakG88MMAQQBB/IPAAEEJENIDIAVB0AFqIAVBoANqQdABEPIDGiAFQaADaiAFQdABakHIARDyAxogBSAFLQCaAzoA6gQgBSAFLwGYAzsB6AQgBUGgA2pBvPDDAEEKIAIgAxDSAyAFIAVBoANqQdABEPIDIgJB0AFqELcFIAJBoANqIAJB0AEQ8gMaIAAgASACQaADaiAEEFMgAkHwBGokAAvEAQEBfyMAQfAEayIFJAAgBUGgA2pBrvDDAEEOEPUDIAVBoANqQbzwwwBBAEH8g8AAQQkQ0gMgBUHQAWogBUGgA2pB0AEQ8gMaIAVBoANqIAVB0AFqQcgBEPIDGiAFIAUtAJoDOgDqBCAFIAUvAZgDOwHoBCAFQaADakG88MMAQQogAiADENIDIAUgBUGgA2pB0AEQ8gMiAkHQAWoQtwUgAkGgA2ogAkHQARDyAxogACABIAJBoANqIAQQjAIgAkHwBGokAAupAQECfyMAQSBrIgEkAAJAAn9BACAAKAIARQ0AGiABQQhqIAAQ0wQgASgCCEEBRg0BIAEgASgCDCICNgIYIAEgAUEQai0AADoAHCACLQAFRQRAIABBCGoQugEgAkEBOgAFCyABQRhqENIEIABBCGoLIAFBIGokAA8LIAEgASgCDDYCGCABIAFBEGotAAA6ABxBvIfKAEErIAFBGGpB6IfKAEHciMoAEKgCAAunAQEEfyMAQTBrIgEkACABQSBqIAAQ0QQgAUEQaiABQSBqQfT0yQAQhQMgASABLQAUIgI6ABwgASABKAIQIgM2AhggAEEIaiEEA0AgAC0AEARAIAFBIGogBCADIAJBAEcQgQQgAUEIaiABQSBqQYT1yQAQhQMgAS0ADEEBcSECIAEoAgghAwwBBSABIAI6ABwgASADNgIYIAFBGGoQ0gQgAUEwaiQACwsLngEBBH8jAEFAaiIDJAAgA0E4aiIEQgA3AwAgA0EwaiIFQgA3AwAgA0EoaiIGQgA3AwAgA0IANwMgIAIgA0EgakEgELwFIANBGGogBCkDADcDACADQRBqIAUpAwA3AwAgA0EIaiAGKQMANwMAIAMgAykDIDcDACABQaz+wQBBA0EAEJUFIAEgA0EgEMICIAAgAUHQARDyAxogA0FAayQAC5gBAQR/IwBBEGsiBSQAIABByABqIQYCQANAIAMgAkkEQCAAKAJAIgRBEE8EQCAGIAAQ3AMgAEEANgJAQQAhBAsgAyACSw0CIAVBCGogACAEQQJ0akEQIARrIAEgA2ogAiADaxCDBCAFKAIMIQQgACAAKAJAIAUoAghqNgJAIAMgBGohAwwBCwsgBUEQaiQADwsgAyACEOYCAAuZAQIBfwJ+IwBBgAFrIgQkACAEQRBqEI4FIARBCGpBACADEKYFIAQ1AgwhBiAENQIIIQUDQCAFIAZaBEAgACAEKQMQNwIAIABBCGogBEEYaigCADYCACAEQYABaiQABSAEQShqIAUQrgIgBEEoaiABIAIQPSAEIARBKGoQUTcDICAEQRBqIARBIGpBCBCuBSAFQgF8IQUMAQsLC58BAQZ/IAAtANEBBEAgAEEAOgDRASAAELgFCyAAKALMASAAKALIASIGayEDIAIhBAJAA0AgBSACTQRAIAIgBWshByABIAVqIQggBCADSQ0CIAAgCCAHIAYgAxCRAiAAECcgBCADayEEIAMgBWohBSAAKALMASEDQQAhBgwBCwsgBSACEOYCAAsgACAIIAcgBiAEEJECIAAgBCAGajYCyAELvQEBAX8jAEGgA2siASQAIAFB4gFqQQBBtgEQwQQaIAFB3gFqQY7zwwAoAAA2AQAgAUGE88MALwAAOwHUASABQYDzwwAoAAA2AtABIAFBhvPDACkAADcB1gEgAUHQAWoQIiABQQhqIAFB0AFqQcgBEPIDGiABQdABaiABQQhqQcgBEPIDGiABQQA6AJoDIAFBADsBmAMgAUHQAWpB7fLDAEELQQAQlQUgACABQdABakHQARDyAxogAUGgA2okAAuYAQEDfyMAQdAAayIBJAAgAUEANgIAIAFBBHIhAwNAIAJBIEYEQCABQShqIAFBJBDyAxogAEEYaiABQcQAaikCADcAACAAQRBqIAFBPGopAgA3AAAgAEEIaiABQTRqKQIANwAAIAAgASkCLDcAACABQdAAaiQABSACIANqQQA6AAAgASABKAIAQQFqNgIAIAJBAWohAgwBCwsLrwEBAn8jAEEgayIEJAAgAkHwhsAAQQogA0EgENIDIAJB+obAAEEKIAEQ4QUQngUgACACQYSHwABBCxCQBCAEQRhqIgFCADcDACAEQRBqIgNCADcDACAEQQhqIgVCADcDACAEQgA3AwAgAkGPh8AAQQ4gBEEgENMDIABBOGogASkDADcAACAAQTBqIAMpAwA3AAAgAEEoaiAFKQMANwAAIAAgBCkDADcAICAEQSBqJAALiQEBAX8jAEEgayIDJAAgA0EIaiABIAIQhAFBASEBAkAgAygCCEEBRgRAIAAgAykCDDcCBCAAQRRqIANBHGooAgA2AgAgAEEMaiADQRRqKQIANwIADAELIABBEGogA0EYaikDADcDACAAQQhqIANBEGopAwA3AwBBACEBCyAAIAE2AgAgA0EgaiQAC6EBAQJ/IwBBIGsiAiQAIAACfwJAIAACfyABQXFqIgNBCUsEQEGEgAIgAUEMRg0BGgwCCwJAAkACQAJAIANBAWsOCQUFAAUFAQUFAgMLQYaAAwwDC0GHwAMMAgtBiIAEDAELQYXAAgs2AgRBAAwBCyACQQM2AhAgAiABrTcCFCACQQhqIAJBEGoQwQMgACACKQMINwIEQQELNgIAIAJBIGokAAuHAQEDfyMAQYABayIDJAAgAC0AACECQQAhAANAIAAgA2pB/wBqIAJBD3EiBEEwciAEQdcAaiAEQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPBEAgAkGAARDmAgALIAFBtazKAEECIAAgA2pBgAFqQQAgAGsQNSADQYABaiQAC4YBAQN/IwBBgAFrIgMkACAALQAAIQJBACEAA0AgACADakH/AGogAkEPcSIEQTByIARBN2ogBEEKSRs6AAAgAEF/aiEAIAJBBHYiAg0ACyAAQYABaiICQYEBTwRAIAJBgAEQ5gIACyABQbWsygBBAiAAIANqQYABakEAIABrEDUgA0GAAWokAAuLAQEBfyMAQaADayIHJAAgB0GAAWogASACIAMgBBCHAiAHQUBrIAdBgAFqIAUgBhCUBCAHQeACakEAQcAAEMEEGiAHQeACakEgIAdBQGtBIBCuASAHQYADakEgIAdB4ABqQSAQrgEgACAHIAdB4AJqQcAAEPIDIgAQnwMgAEHAAmoQswIgAEGgA2okAAuKAQEEfyMAQUBqIgEkACABEMsEIAFBKGoiAiABQQhqKQMANwMAIAFBMGoiAyABQRBqKQMANwMAIAFBOGoiBCABQRhqKQMANwMAIAEgASkDADcDICAAIAEpAyA3AAAgAEEIaiACKQMANwAAIABBEGogAykDADcAACAAQRhqIAQpAwA3AAAgAUFAayQAC4IBAQF/IAAgASgCDCACKAIEIgNBD3cgA0ENd3MgA0EKdnNqIgM2AgwgACABKAIIIAIoAgAiAkEPdyACQQ13cyACQQp2c2oiAjYCCCAAIAEoAgQgA0EPdyADQQ13cyADQQp2c2o2AgQgACABKAIAIAJBD3cgAkENd3MgAkEKdnNqNgIAC4cBAQN/IwBBgAFrIgMkACAAKAIAIQJBACEAA0AgACADakH/AGogAkEPcSIEQTByIARB1wBqIARBCkkbOgAAIABBf2ohACACQQR2IgINAAsgAEGAAWoiAkGBAU8EQCACQYABEOYCAAsgAUG1rMoAQQIgACADakGAAWpBACAAaxA1IANBgAFqJAALhgEBA38jAEGAAWsiAyQAIAAoAgAhAkEAIQADQCAAIANqQf8AaiACQQ9xIgRBMHIgBEE3aiAEQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPBEAgAkGAARDmAgALIAFBtazKAEECIAAgA2pBgAFqQQAgAGsQNSADQYABaiQAC5IBAQJ/IABBCnYhAgJAAkACQCAAQYDIAE8EQEECIQEgAkEMRg0BQQAPCyACQYjPygBqLQAAIgFBBEsNAQsgAEEGdkEPcSABQQR0ckGRz8oAai0AACIBQQVLDQEgAUEDdEHoz8oAaikDAEIBIABBP3GthoNCAFIPC0HQwMoAIAFBBRDkAgALQeDAygAgAUEGEOQCAAuUAQEBfyMAQcADayIDJAAgA0HIhsAAQRQQ9QMgA0HchsAAQQpBrIPAAEEAENIDIANB0AFqIANB0AEQ8gMaIANBuANqIAJBGGopAAA3AwAgA0GwA2ogAkEQaikAADcDACADQagDaiACQQhqKQAANwMAIAMgAikAADcDoAMgACABIANB0AFqIANBoANqEG8gA0HAA2okAAuVAQEBfyMAQcADayIDJAAgA0HIhsAAQRQQ9QMgA0HchsAAQQpBrIPAAEEAENIDIANB0AFqIANB0AEQ8gMaIANBuANqIAJBGGopAAA3AwAgA0GwA2ogAkEQaikAADcDACADQagDaiACQQhqKQAANwMAIAMgAikAADcDoAMgACABIANB0AFqIANBoANqEIoBIANBwANqJAALhAEBA38gACgCBCECIAAoAgAiASgCAARAIAEoAgBBAUEBELYFIAFBCGoiAxDGAiADEOkDCyABIAIoAggiA0EXakEAIANrcWogAigCABEDACAAKAIEIgEoAgQgASgCCCIBQQQgAUEESxsiAWpBF2pBACABa3EiAgRAIAAoAgAgAiABELYFCwudAQEBfyAAQQdBABBEAkACQANAIAJFDQIgAC0AyAEiA0HHAU0EQCABIAAgA2otAAA6AAAgAC0AyAEiA0HHAUsNAiAAIANqQQA6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0Gs9MMAIANByAEQ5AIAC0G89MMAIANByAEQ5AIACwt/AQJ/IAAgASgCDCABKAIIIgNBGXcgA0EDdnMgA0EOd3NqNgIMIAAgAyABKAIEIgRBGXcgBEEDdnMgBEEOd3NqNgIIIAAgBCABKAIAIgFBGXcgAUEDdnMgAUEOd3NqNgIEIAAgASACKAIMIgBBGXcgAEEDdnMgAEEOd3NqNgIAC5cBAQZ/IwBBEGsiAiQAIAFBDGooAgAhBCABKAIAIQUgASgCCCEGIAEQswUhByABKAIAIQMCQCAHRQ0AIAEgA0EIciIDNgIAIAEoAghBAUYNACABQoGAgICgATcCCAsgASADQQRyNgIAIAIgACgCADYCDCACQQxqIAEQ9QEgASAENgIMIAEgBjYCCCABIAU2AgAgAkEQaiQAC4wBAQF/IwBBIGsiBCQAIAQgAjYCBCAEIAE2AgAgBCADNgIIIAQgAjYCDAJAIANFIAIgA0ZyDQAgAiADSwRAIAEgA2osAABBv39KDQELIAQgBEEMajYCGCAEIARBCGo2AhQgBCAENgIQIARBEGoQ7wQACyAAIAIgA2s2AgQgACABIANqNgIAIARBIGokAAuuAQECfyMAQSBrIgEkAAJAIAACf0ECENgDDQAaAn9BAUG8jsoAKAIAEQgAIgJFDQAaIAJBAToAAEEACxCZBBDRAyABQQhqQeD5ygAoAgAQ1QQgASgCCEEBRg0BIAEoAgwhAiABQRBqLQAACzoABCAAIAI2AgAgAUEgaiQADwsgASABKAIMNgIYIAEgAUEQai0AADoAHEGnjcoAQSsgAUEYakHUjcoAQcCOygAQqAIAC5IBAQJ/IAAtAAghASAAKAIEIgIEQCAAAn9BASABQf8BcQ0AGgJAIAJBAUcNACAALQAJRQ0AIAAoAgAiAS0AAEEEcQ0AQQEgASgCGEGwrMoAQQEgAUEcaigCACgCDBEEAA0BGgsgACgCACIAKAIYQbGsygBBASAAQRxqKAIAKAIMEQQACyIBOgAICyABQf8BcUEARwuMAQEBfyMAQRBrIgMkACADIAEoAgAiBCgCADYCDCACQQJqIgEgAWwiAUGAECABQYAQSxsiAkEEIANBDGpB5P3BAEHk/cEAEOECIQEgBCADKAIMNgIAIAEEfyABQgA3AgQgASABIAJBAnRqQQJyNgIAQQAFQQELIQIgACABNgIEIAAgAjYCACADQRBqJAALxQEBAn4gAELw////////PyAAKQMgfSICQv////////8Dg0Lw////////PyAAKQMYfSIBQjOIfDcDICAAIAFC/////////wODQvD///////8/IAApAxB9IgFCM4h8NwMYIAAgAUL/////////A4NC8P///////z8gACkDCH0iAUIziHw3AxAgACABQv////////8Dg0LQ/f//////PyAAKQMAfSIBQjOIfDcDCCAAIAJCM4hCE34gAUL/////////A4N8NwMAC4QBAQR/IwBBgAFrIgIkACAAIAEgAUH4AGoiAxAeIAJBCGogAUEoaiIEIAFB0ABqIgUQHiACQTBqIAUgAxAeIAJB2ABqIAEgBBAeIABBKGogAkEIakEoEPIDGiAAQdAAaiACQTBqQSgQ8gMaIABB+ABqIAJB2ABqQSgQ8gMaIAJBgAFqJAALdwEDfyMAQRBrIgMkACADQQE6AA8CfyAAKAIMIgJBAWoiBCACSQRAIANBD2oQ/gRBAAwBCyAEIAAoAgQiAkEITwR/IAJBAWpBA3ZBB2wFIAILQQF2TwRAIAAgBCABEEtB/wFxDAELIAAgARA0QQALGiADQRBqJAALjAEBBX8jAEEQayIDJAAgACgCACEEIAGnIQIgACgCBCEFQQAhAANAIANBCGogBCACIAVxIgZqKAAAQYCBgoR4cRDMBCAAQQRqIgAgBmohAiADKAIIQQFHDQALIAQgAygCDCAGaiAFcSICaiwAAEEATgRAIAQoAgBBgIGChHhxENIFIQILIANBEGokACACC4wBAQN/IwBBIGsiAiQAIAJBGGoiAyABQRBqKAIANgIAIAJBEGoiBCABQQhqKQIANwMAIAIgASkCADcDCEEUQQQQpAUiAUUEQEEUQQQQ3QUACyABIAIpAwg3AgAgAUEQaiADKAIANgIAIAFBCGogBCkDADcCACAAQYyGygA2AgQgACABNgIAIAJBIGokAAuCAQEBfyMAQYACayIFJAAgBUEIahCOBSAFQQhqIAMgBBCuBSAFQQhqIAEgAhCuBSAFIAVBCGoQmwUgBUEYaiAFKAIAIAUoAgQQJiAFKAIYQQFGBEBBiPzBAEEZQbD8wQAQtAQACyAAIAVBIGpB4AEQ8gMaIAVBCGoQgQUgBUGAAmokAAuGAQECfiAAQgAgAq1C/wGDfSIEIAApAwAiAyABKQMAhYMgA4U3AwAgACAAKQMIIgMgASkDCIUgBIMgA4U3AwggACAAKQMQIgMgASkDEIUgBIMgA4U3AxAgACAAKQMYIgMgASkDGIUgBIMgA4U3AxggACAEIAApAyAiAyABKQMghYMgA4U3AyALhwEBAn8jAEGAAWsiAiQAIAAgAUEoaiIDIAEQ1QMgAkEIaiADIAEQ3wEgAkEwaiABQdAAakEoEPIDGiACQdgAaiABQfgAakHYuMQAEB4gAEEoaiACQQhqQSgQ8gMaIABB0ABqIAJBMGpBKBDyAxogAEH4AGogAkHYAGpBKBDyAxogAkGAAWokAAuHAQECfyMAQYABayICJAAgACABQShqIgMgARDVAyACQQhqIAMgARDfASACQTBqIAFB0ABqQSgQ8gMaIAJB2ABqIAFB+ABqQajryAAQHiAAQShqIAJBCGpBKBDyAxogAEHQAGogAkEwakEoEPIDGiAAQfgAaiACQdgAakEoEPIDGiACQYABaiQAC44BAgF/AX4jAEFAaiIBJAAgAUEIakEENgIAIAFBEGogASgCCCABKAIMEO4BIAEoAhBBAUYEQCABQThqIAFBJGooAgA2AgAgAUEwaiABQRxqKQIANwMAIAEgASkCFDcDKCABQShqEKwDAAsgAUEYaikDACECIAAgAUEgaikDADcDCCAAIAI3AwAgAUFAayQAC5MBAQF/IwBB4AJrIgQkACACEKUFIAJB0fDDAEEHIAFBoAFqEJ4FIAJB3/DDAEEGIAMQngUgBCACQeXwwwBBBhCQBCAEQcABaiABEOIFIARBIGogBCAEQcABaiADQSBqEDkgBEHAAWogBEEgahBIIABBB0EAIARBwAFqQSAgA0EgEL8FGzoAACACELcFIARB4AJqJAALnQEBAX8jAEEQayICJAACQAJAAkACQCAAKAIAIgBBhIACRwRAIABBhcACRg0BIABBhoADRg0CIABBh8ADRg0DIAIgAUHB4MkAQQcQnAQMBAsgAiABQd3gyQBBBxCcBAwDCyACIAFB1uDJAEEHEJwEDAILIAIgAUHP4MkAQQcQnAQMAQsgAiABQcjgyQBBBxCcBAsgAhCAAiACQRBqJAALgAEBAX8jAEGAAWsiAiQAIAAgARDZAyACQQhqIAFBKGpBKBDyAxogAkEwaiABQdAAakEoEPIDGiACQdgAaiABQfgAahDZAyAAQShqIAJBCGpBKBDyAxogAEHQAGogAkEwakEoEPIDGiAAQfgAaiACQdgAakEoEPIDGiACQYABaiQAC4MBAgJ/A34jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAIAAgBEEIakGAvMQAEKABIARBMGokAAUgASADEOIEKQMAIQUgAiADEOIEKQMAIQYgBEEIaiADEOMEIAYgBSAHQjSIfHwiB0L/////////B4M3AwAgA0EBaiEDDAELCwt8AgJ/A34gACABKAIEIgNBIE8EfiAAIAEoAgAiAikAADcDCCACQRhqKQAAIQQgAkEQaikAACEFIAJBCGopAAAhBiABIANBYGo2AgQgASACQSBqNgIAIABBEGogBjcDACAAQRhqIAU3AwAgAEEgaiAENwMAQgEFQgALNwMAC4gBAQF/IwBBEGsiBSQAIAVBCGogAEHIASADEJ0EIAUgBSgCCCAFKAIMIAQQngQgBSgCBCIEIAJNBEAgBSgCACECA0AgBARAIAIgAi0AACABLQAAczoAACAEQX9qIQQgAkEBaiECIAFBAWohAQwBCwsgBUEQaiQADwtBuMDEAEEoQbzBxAAQzgMAC4MBAgJ/A34jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAIAAgBEEIakHY7cgAEKEBIARBMGokAAUgASADEOUEKQMAIQUgAiADEOUEKQMAIQYgBEEIaiADEOYEIAYgBSAHQjSIfHwiB0L/////////B4M3AwAgA0EBaiEDDAELCwubAQEDfyMAQSBrIgEkACAAKAIAIgAoAgAhAiAAQQA2AgAgACgCBCABIAIoAgAoAhARAwAoAgAhAiABQRhqIgMgAUEIaigCADYCACABIAEpAwA3AxAgAkEEaiEAIAIoAgQEQCAAIgIoAgQiBARAIAIoAgAgBEEDdEEEELYFCwsgACABKQMQNwIAIABBCGogAygCADYCACABQSBqJAALhgEBAn8jAEGQIGsiAiQAIAJBCGogAUGUIGoQfCACQQhqQQRyIQMCQCACKAIIQQFGBEAgACADKQIANwIAIABBEGogA0EQaigCADYCACAAQQhqIANBCGopAgA3AgAMAQsgASABKQMANwMIIAFBEGogA0GEIBDyAxogAEEFOgAQCyACQZAgaiQAC3kBAn8jAEGAAWsiAyQAIAAtAAAhAkEAIQADQCAAIANqQf8AaiACQQFxQTByOgAAIABBf2ohACACQQF2IgINAAsgAEGAAWoiAkGBAU8EQCACQYABEOYCAAsgAUG3rMoAQQIgACADakGAAWpBACAAaxA1IANBgAFqJAALfQEDfyMAQYABayICJAAgACABIAFB0ABqIgMQHiACQQhqIAFBKGoiBCADEB4gAkEwaiADEMgFIAJB2ABqIAEgBBAeIABBKGogAkEIakEoEPIDGiAAQdAAaiACQTBqQSgQ8gMaIABB+ABqIAJB2ABqQSgQ8gMaIAJBgAFqJAALgQEBAX8jAEHwIGsiBCQAIARBCGpBAEHAABDBBBogBEHYAGpCgICAEDcDACAEQRA2AkggBEKAgIAQNwNQIARB4ABqIAFBhCAQ8gMaIARB7CBqQQA2AgAgBEHoIGogAzYCACAEQeQgaiACNgIAIAAgBEEIakHoIBDyAxogBEHwIGokAAupAQACQAJAAkACQAJAIAAoAgAtAABBAWsOBAIDBAABCyABKAIYQfnAygBBBCABQRxqKAIAKAIMEQQADwsgASgCGEH0wMoAQQUgAUEcaigCACgCDBEEAA8LIAEoAhhBrcHKAEEMIAFBHGooAgAoAgwRBAAPCyABKAIYQaXBygBBCCABQRxqKAIAKAIMEQQADwsgASgCGEGcwcoAQQkgAUEcaigCACgCDBEEAAt+AQF/IwBBQGoiBSQAIAVBIGogASACEKwBIAVBCGogBUEgakHY+sEAEOsCIAVBIGogBUEIaiADIAQQ4gEgBSAFQSBqEM8EIAUoAgQiAUEfTQRAQSAgARDlAgALIAAgBSgCAEEgEJwDIAVBCGoQowUgBUEgahCBBSAFQUBrJAALngEBBX4gAUEgEOABIQIgAUEGakEaEOABIQMgAUEMakEUEOABIQQgAUETakENEOABIQUgAUEYakEIEOABIQYgACAEQgaIQv////////8DgzcDECAAIANCA4hC/////////wODNwMIIAAgAkL/////////A4M3AwAgACAFQgGIQv////////8DgzcDGCAAIAZCDIhC/////////wODNwMgC54BAQV+IAFBIBDhASECIAFBBmpBGhDhASEDIAFBDGpBFBDhASEEIAFBE2pBDRDhASEFIAFBGGpBCBDhASEGIAAgBEIGiEL/////////A4M3AxAgACADQgOIQv////////8DgzcDCCAAIAJC/////////wODNwMAIAAgBUIBiEL/////////A4M3AxggACAGQgyIQv////////8DgzcDIAuMAQEBfwJAIAAtAMgBIgFBxwFNBEAgACABaiIBIAEtAAAgAC0AyQFzOgAAIAAtAMgBQQFqQf8BcSIBQccBSw0BIAAgAWoiASABLQAAQQRzOgAAIAAgAC0ApwFBgAFzOgCnASAAECIgAEEAOwHIAQ8LQezzwwAgAUHIARDkAgALQfzzwwAgAUHIARDkAgALegEDfyMAQRBrIgIkAAJAIAAoAgAiAUEITQRAIAFBDGwhASAAQQhqIQADQCABRQ0CIAFBdGohASAAELUEIABBDGohAAwACwALIABBCGooAgAhAyACIABBDGooAgA2AgggAiABNgIEIAIgAzYCACACENQFCyACQRBqJAALbwEDfiAAIAJCIIgiAyABQiCIIgR+QgB8QgB8IAJC/////w+DIgIgAUL/////D4MiAX4iBUIgiCACIAR+fCICQiCIfCABIAN+IAJC/////w+DfCIBQiCIfDcDCCAAIAVC/////w+DIAFCIIaENwMAC3MBAn8gACgCACICQXxxIgFFIAJBAnFyRQRAIAEgASgCBEEDcSAAKAIEQXxxcjYCBAsgACAAKAIEIgJBfHEiAQR/IAEgASgCAEEDcSAAKAIAQXxxcjYCACAAKAIEBSACC0EDcTYCBCAAIAAoAgBBA3E2AgALfQEEfyMAQSBrIgEkACAAQgA3AAAgAEEYaiICQgA3AAAgAEEQaiIDQgA3AAAgAEEIaiIEQgA3AAAgARDLBCACIAFBGGopAwA3AAAgAyABQRBqKQMANwAAIAQgAUEIaikDADcAACAAIAEpAwA3AAAgAEEgahCzAiABQSBqJAALgQEBAX8jAEEQayICJAAgAiABQa2FygBBBRC/BCACIABBEGo2AgwgAkGyhcoAQQQgAkEMakG4hcoAEGogAiAANgIMIAJByIXKAEEDIAJBDGpBzIXKABBqIAIgAEEIajYCDCACQdyFygBBBSACQQxqQeSFygAQaiACELECIAJBEGokAAt7AQF/IwBBMGsiASQAIAFBigE2AgQgAUEANgIQIAFCBDcDCCABQQA2AhggASABQRhqNgIoIAEgAUEEajYCJCABIAFBCGo2AiAQhgMgAEEIaiABKAIQNgIAIAAgASkDCDcCACAAIAEoAhxBACABKAIYGzYCDCABQTBqJAALdgEDfyMAQSBrIgIkAAJAIAAgARCCAUUEQCABQRxqKAIAIQMgASgCGCACQRxqQQA2AgAgAkHEqsoANgIYIAJCATcCDCACQciqygA2AgggAyACQQhqEDNFDQELIAJBIGokAEEBDwsgAEEEaiABEIIBIAJBIGokAAt7AQR/IwBBIGsiAyQAIANBGGoiBEIANwMAIANBEGoiBUIANwMAIANBCGoiBkIANwMAIANCADcDACADQSAgASACEK4BIABBGGogBCkDADcAACAAQRBqIAUpAwA3AAAgAEEIaiAGKQMANwAAIAAgAykDADcAACADQSBqJAALcQACfyACQQJ0IgEgA0EDdEGAgAFqIgIgASACSxtBh4AEaiIBQRB2QAAiAkF/RgRAQQAhA0EBDAELIAJBEHQiA0IANwMAIANBADYCCCADIAMgAUGAgHxxakECcjYCAEEACyEBIAAgAzYCBCAAIAE2AgALcgEDfyMAQZABayIBJAAgAUEANgIAIAFBBHIhAwNAIAJBwABGBEAgAUHIAGogAUHEABDyAxogACABQcgAakEEckHAABDyAxogAUGQAWokAAUgAiADakEAOgAAIAEgASgCAEEBajYCACACQQFqIQIMAQsLC3IBA38jAEGQAmsiASQAIAFBADYCACABQQRyIQMDQCACQYABRgRAIAFBiAFqIAFBhAEQ8gMaIAAgAUGIAWpBBHJBgAEQ8gMaIAFBkAJqJAAFIAIgA2pBADoAACABIAEoAgBBAWo2AgAgAkEBaiECDAELCwuAAQEBfyMAQUBqIgUkACAFIAE2AgwgBSAANgIIIAUgAzYCFCAFIAI2AhAgBUEsakECNgIAIAVBPGpBuAE2AgAgBUICNwIcIAVBoKvKADYCGCAFQbQBNgI0IAUgBUEwajYCKCAFIAVBEGo2AjggBSAFQQhqNgIwIAVBGGogBBC9BAALfQAgAUEITwRAIAAgAkIohkKAgICAgIDA/wCDIAJCOIaEIAJCGIZCgICAgIDgP4MgAkIIhkKAgICA8B+DhIQgAkIIiEKAgID4D4MgAkIYiEKAgPwHg4QgAkIoiEKA/gODIAJCOIiEhIQ3AAAPC0GI6MkAQSBBlOfJABC0BAALYAICfwF+AkACQCABrUIMfiIEQiCIp0UEQCAEpyICQX9MDQECQCACRQRAQQQhAwwBCyACQQQQpAUiA0UNAwsgACABNgIEIAAgAzYCAA8LEOsFAAsQ6wUACyACQQQQ3QUAC2ECAn8BfgJAAkAgAa1C8AB+IgRCIIinRQRAIASnIgJBf0wNAQJAIAJFBEBBCCEDDAELIAJBCBCkBSIDRQ0DCyAAIAE2AgQgACADNgIADwsQ6wUACxDrBQALIAJBCBDdBQALbgECfyMAQSBrIgEkACABQQhqEFhBASECAkAgASgCCEEBRgRAIAAgASkCDDcCBCAAQRRqIAFBHGooAgA2AgAgAEEMaiABQRRqKQIANwIADAELIAAgASkCDDcCBEEAIQILIAAgAjYCACABQSBqJAALZwACQCABIABPBEAgAkUNAQNAIAAgAS0AADoAACABQQFqIQEgAEEBaiEAIAJBf2oiAg0ACwwBCyACRQ0AIAFBf2ohASAAQX9qIQADQCAAIAJqIAEgAmotAAA6AAAgAkF/aiICDQALCwuJAQEBfyMAQTBrIgIkACACQQhqEMsEIABBKGogAUL56tDQ58mh5OEAfDcDACAAQSBqIAE3AwAgAEEYaiABQs/W077Sx6vZQnw3AwAgACABQtbrgu7q/Yn14AB8NwMQIAAgATcDCCAAQgA3AwAgAkEANgIoIABBMGogAkEIakEoEPIDGiACQTBqJAALagEBfyMAQRBrIgQkACAAAn8gAiADaiIDIAJPBEAgASgCBEEBdCIBIAMgASADSxshAkEADAELIARBCGogA0EAEKYFIAQoAgghAiAAQQhqIAQoAgw2AgBBAQs2AgAgACACNgIEIARBEGokAAt6AQF/IwBBgAFrIgAkACAAQQhqEEkgAEHYAGogAEEIakEoEPIDGkHI+soAIABB2ABqQSgQogEgAEEwaiAAQdgAakEoEPIDGiAALQBAQQJHBEBBnNjKAEGc2MoAKAIAQX9qNgIAIABBMGoQhAULIABBgAFqJABByPrKAAt0AQJ/IAAtAAQhASAALQAFBEAgAAJ/QQEgAUH/AXENABogACgCACIAQRxqKAIAKAIMIQEgACgCGCECIAAtAABBBHFFBEAgAkGrrMoAQQIgAREEAAwBCyACQaqsygBBASABEQQACyIBOgAECyABQf8BcUEARwuWAQECfyMAQdADayIDJAAgA0EAQcwBEMEEIgRBADoA0QEgBEEBOgDQASAEQYgBNgLMASADQfABakIANwMAIANB6AFqQgA3AwAgA0HgAWpCADcDACADQgA3A9gBIAMgASACEOoBIANB+AFqIANB2AEQ8gMaIANB+AFqIANB2AFqEJMEIAAgA0HYAWpBIBCcAyADQdADaiQAC3UBBH8jAEEgayIBJAAgAEIANwAAIABBGGoiAkIANwAAIABBEGoiA0IANwAAIABBCGoiBEIANwAAIAEQywQgAiABQRhqKQAANwAAIAMgAUEQaikAADcAACAEIAFBCGopAAA3AAAgACABKQAANwAAIAFBIGokAAsnAQF/QQhBBBCkBSIBBEAgAEEBNgIEIAAgATYCAA8LQQhBBBDdBQALNwIBfwF+IwBBIGsiAiQAIAJBCGogAUEBEIkDIAIpAwghAyAAIAE2AgggACADNwIAIAJBIGokAAuRAQECfwJAAkACQCAAKAIEIgIgAU8EQCABBEAgASACRg0EIAAoAgAgAkHwAGxBCCABQfAAbCICEJQFIgMNAiACQQgQ3QUACyAAIgEoAgQiAgRAIAEoAgAgAkHwAGxBCBC2BQsgAEEINgIAQQAhAQwCC0HQ7skAQSRBlO/JABDOAwALIAAgAzYCAAsgACABNgIECwt3AQF/IwBBgAVrIgUkACAFQeAAaiABIAIQKyAFQYADaiAFQeAAakG8g8AAEMgCIAUgAyAEEKQCIAVB4ABqIAVBgANqIAUQ+QEgBSAFQeAAahCRASAAIAVB4AAQnAMgBUHgAGoQogUgBUGAA2oQogUgBUGABWokAAtfAQF/IwBBMGsiByQAIAdBEGogASACIAMgBCAFIAYQNyAHQShqIAdBGGooAgA2AgAgByAHKQMQNwMgIAdBADYCLCAHQQhqIAdBIGoQrwMgACAHKQMINwIAIAdBMGokAAtgAQF/IwBBMGsiByQAIAdBEGogASACIAMgBCAFIAYQ8gEgB0EoaiAHQRhqKAIANgIAIAcgBykDEDcDICAHQQA2AiwgB0EIaiAHQSBqEK8DIAAgBykDCDcCACAHQTBqJAALdgEBfyMAQdAAayICJAAgAhCXASACQSBqIAFBCGooAgA2AgAgAiABKQIANwMYIAJBKGogAkEkEPIDGkEkQQQQpAUiAUUEQEEkQQQQ3QUACyABIAJBKGpBJBDyAyEBIABBvPPIADYCBCAAIAE2AgAgAkHQAGokAAtzAQV/IwBBEGsiAiQAA0ACQCACQQhqIAEQRyACKAIIIgRFDQAgAigCDCEFIAAoAggiAyAAKAIERgRAIAAgACgCCBCnAwsgACgCACADQQN0aiIGIAU2AgQgBiAENgIAIAAgA0EBajYCCAwBCwsgAkEQaiQAC1cAIAAgAkIyiSACQi6JhSACQheJhSAIfCAEIAaFIAKDIAaFfCAJfCICIAd8NwMIIAAgAyAFhSABgyADIAWDhSABQiSJIAFCHomFIAFCGYmFfCACfDcDAAtmAQF/IAEoAgAiASgCaCICIAEoAmxHBEAgASACQQFqNgJoIAACfyABQQhqIAEoAgBBCE0NABogAUEIaigCAAsgAkEMbGoiASkCADcCACAAQQhqIAFBCGooAgA2AgAPCyAAQQI6AAgLcwEBfyMAQbAEayICJAAgAiABQdgBahDpAiACQdgCaiABQdgBEPIDGiACQdgBaiACQdgCahDuAyACIAJB2AFqELIEIAJB2AJqIAJB2AEQ8gMaIAJBmAJqIAJB2AJqEO4DIAAgAkGYAmoQuQUgAkGwBGokAAteAQF/IwBBMGsiBiQAIAZBEGogASACIAMgBCAFELUDIAZBKGogBkEYaigCADYCACAGIAYpAxA3AyAgBkEANgIsIAZBCGogBkEgahCvAyAAIAYpAwg3AgAgBkEwaiQAC10BAX8jAEEwayIGJAAgBkEQaiABIAIgAyAEIAUQGyAGQShqIAZBGGooAgA2AgAgBiAGKQMQNwMgIAZBADYCLCAGQQhqIAZBIGoQrwMgACAGKQMINwIAIAZBMGokAAt0AQF/AkADQCACRQ0BIAAtAMgBIgNBxwFNBEAgACADaiIDIAMtAAAgAS0AAHM6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0GM9MMAIANByAEQ5AIACwt0AQF/IABBBkEAEEQCQANAIAJFDQEgAC0AyAEiA0HHAU0EQCAAIANqIAEtAAA6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0Gc9MMAIANByAEQ5AIACwt1AQF/IwBBQGoiASQAIAEQpgIgAEEANgIIIABCADcDACAAQQxqIAFBwAAQ8gMaIABB5ABqQcDoyQApAgA3AgAgAEHcAGpBuOjJACkCADcCACAAQdQAakGw6MkAKQIANwIAIABBqOjJACkCADcCTCABQUBrJAALdAEEfyAAQbnz3fF5bCEDAkADQCADQQAQkAMiACgCCGtBH3F2IgEgACgCBCICTw0BIAAoAgAiAiABQfAAbGpBIGoiBBDxBCAAQaDYygAoAgBHBEAgBBDQBAwBCwsgAiABQfAAbGoPC0Gw7skAIAEgAhDkAgALcAEBfyMAQTBrIgEkACABIAA2AgwDQCABQSBqIAFBDGoQvQIgAS0AKEECRgRAIAFBIGoiAC0ACEECRwRAIAAQtQQLIAFBMGokAAUgAUEYaiABQShqKAIANgIAIAEgASkDIDcDECABQRBqELUEDAELCwtlAQN/IwBBEGsiASQAIAFBCGogABCbBSABKAIMQRhsIQIgASgCCCIDQQxqIQADQCACBEAgAygCDARAIAAQowMgABD0BAsgA0EYaiEDIAJBaGohAiAAQRhqIQAMAQsLIAFBEGokAAtuAQF/IwBBIGsiAyQAIAEoAgBBAUYEQCADQRhqIAFBFGopAgA3AwAgA0EQaiABQQxqKQIANwMAIAMgASkCBDcDCEHzgcAAQSsgA0EIakGggsAAIAIQqAIACyAAIAFBCGpBwAEQ8gMaIANBIGokAAtuAQF/IwBBIGsiAyQAIAEoAgBBAUYEQCADQRhqIAFBFGopAgA3AwAgA0EQaiABQQxqKQIANwMAIAMgASkCBDcDCEHzgcAAQSsgA0EIakGggsAAIAIQqAIACyAAIAFBCGpBgAIQ8gMaIANBIGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBC4ASAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBC3AiAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBD4AiAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtbAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBAaIAVBKGogBUEYaigCADYCACAFIAUpAxA3AyAgBUEANgIsIAVBCGogBUEgahCvAyAAIAUpAwg3AgAgBUEwaiQAC1wBAX8jAEEwayIFJAAgBUEQaiABIAIgAyAEEJkCIAVBKGogBUEYaigCADYCACAFIAUpAxA3AyAgBUEANgIsIAVBCGogBUEgahCvAyAAIAUpAwg3AgAgBUEwaiQAC2YBAn8gACAAKAIEIAFBFXQgACgCACIBQR9xdnIiAjYCBCAAQQhqIQMgAUELaiEBA0AgACABNgIAIAFBB0sEQCADIAJBGHYQigQgACAAKAIEQQh0IgI2AgQgACgCAEF4aiEBDAELCwtqAQF/IwBBIGsiAiQAIAJBGGogAUEQaigCADYCACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAIgAkEIahCKAyAAIAIpAwA3AgggAEEaNgIEIABBh/nJADYCACAAQQA6ABAgAkEgaiQAC4gBAQF/IwBBEGsiAiQAAkACQAJAAkACQAJAIAAtAABBAWsOBAIDBAABCyACIAFB+ITKAEEPEJwEDAQLIAIgAUGihcoAQQsQnAQMAwsgAiABQZiFygBBChCcBAwCCyACIAFBj4XKAEEJEJwEDAELIAIgAUGHhcoAQQgQnAQLIAIQgAIgAkEQaiQAC3MBAX8jAEEQayIBJAAgACgCACIALQAAIQIgAEEAOgAAAkAgAkEBcQRAIAFBCGoQkQNBCEEEEKQFIgBFDQEgACABKQMINwIAQeD5ygAgADYCACABQRBqJAAPC0H8jMoAQStB7IzKABDOAwALQQhBBBDdBQALcAECfwJAIAAoAgAiAUEQaigCACICRQ0AIAJBADoAACABQRRqKAIAIgJFDQAgASgCECACQQEQtgULIAFBHGooAgBBAUEBELYFIAAoAgAiASABKAIEIgFBf2o2AgQgAUEBRgRAIAAoAgBBMEEIELYFCwtaAQF/IwBBMGsiBCQAIARBEGogASACIAMQ6QEgBEEoaiAEQRhqKAIANgIAIAQgBCkDEDcDICAEQQA2AiwgBEEIaiAEQSBqEK8DIAAgBCkDCDcCACAEQTBqJAALcAEBfwJAAkACQCAAKAIEIgIgAU8EQCABBEAgASACRg0EIAAoAgAgAkEBIAEQlAUiAg0CIAFBARDdBQALIAAQgQUgAEEBNgIAQQAhAQwCC0GQ/cEAQSRB1P3BABDOAwALIAAgAjYCAAsgACABNgIECwtfAQF/IwBBoAJrIgIkACACQagBaiABQSgQ8gMaIAJB0AFqIAFBKGpBKBDyAxogAkH4AWogAUHQAGpBKBDyAxogAkEIaiACQagBahCjASAAIAJBCGoQgwIgAkGgAmokAAt4AQF/IwBBIGsiASQAIAFBrPrKADYCDEGs+soAKAIAQQFHBEAgASAANgIQIAEgAUEMajYCFCABIAFBEGo2AhxBrPrKACABQRxqQZj1yAAQVwsgASgCDBDHBCIARQRAQcD1yABBK0HI9sgAEM4DAAsgAUEgaiQAIAALeAEBfyMAQSBrIgEkACABQZj6ygA2AgxBmPrKACgCAEEBRwRAIAEgADYCECABIAFBDGo2AhQgASABQRBqNgIcQZj6ygAgAUEcakGs9cgAEFcLIAEoAgwQxwQiAEUEQEHA9cgAQStByPbIABDOAwALIAFBIGokACAAC1wCAn8BfiAAKAIEIgEEQAJ/AkAgAUEIaiICIAFBBWpJDQAgAUEBaq1CDH4iA0IgiKcNACACQXxxIgIgA6dqIgEgAkkNAEEEDAELQQALIQIgACgCACABIAIQtgULC3MBAX8jAEEwayIBJAAgAUGAATYCBCABIAA2AgAgAUEcakECNgIAIAFBLGpBywA2AgAgAUICNwIMIAFB5OnJADYCCCABQcsANgIkIAEgAUEgajYCGCABIAFBBGo2AiggASABNgIgIAFBCGpB0OrJABC9BAALcgEBfyMAQRBrIgQkACAEIAI2AgQgBCABNgIAIAQgAzYCDAJAIANFIAIgA0ZyDQAgAiADSwRAIAEgA2osAABBv39KDQELIAQoAgAgBCgCBEEAIARBDGooAgAQKQALIAAgAzYCBCAAIAE2AgAgBEEQaiQAC2sBAX8jAEEgayIDJAAgAyABIAIQGQJAIAMtABxFBEAgAEECOgAcDAELIAAgAykDADcCACAAQRhqIANBGGopAwA3AgAgAEEQaiADQRBqKQMANwIAIABBCGogA0EIaikDADcCAAsgA0EgaiQAC1gBAX8jAEEwayIDJAAgA0EQaiABIAIQjAEgA0EoaiADQRhqKAIANgIAIAMgAykDEDcDICADQQA2AiwgA0EIaiADQSBqEK8DIAAgAykDCDcCACADQTBqJAALWAEBfyMAQTBrIgMkACADQRBqIAEgAhCyAiADQShqIANBGGooAgA2AgAgAyADKQMQNwMgIANBADYCLCADQQhqIANBIGoQrwMgACADKQMINwIAIANBMGokAAtYAQF/IwBBMGsiAyQAIANBEGogASACEOoCIANBKGogA0EYaigCADYCACADIAMpAxA3AyAgA0EANgIsIANBCGogA0EgahCvAyAAIAMpAwg3AgAgA0EwaiQAC1gBAX8jAEEwayIDJAAgA0EQaiABIAIQngMgA0EoaiADQRhqKAIANgIAIAMgAykDEDcDICADQQA2AiwgA0EIaiADQSBqEK8DIAAgAykDCDcCACADQTBqJAALWAEBfyMAQTBrIgMkACADQRBqIAEgAhCDASADQShqIANBGGooAgA2AgAgAyADKQMQNwMgIANBADYCLCADQQhqIANBIGoQrwMgACADKQMINwIAIANBMGokAAtrAQJ/IwBBEGsiBiQAAkAgACABIAIgAyAEEFIiBQ0AIAZBCGogAyAAIAEgBCgCDBEFAEEAIQUgBigCCA0AIAYoAgwiBSACKAIANgIIIAIgBTYCACAAIAEgAiADIAQQUiEFCyAGQRBqJAAgBQtsAQF/IwBB4AJrIgIkACACQQhqQQBBwAAQwQQaIAJBiAFqIAFB2AEQ8gMaIAJByABqIAJBiAFqEKEEIAIgAkHIAGoQqQUgAkEIakHAACACKAIAIAIoAgQQsAEgACACQQhqEMUEIAJB4AJqJAALagEBfyMAQRBrIgMkACADIAEgAhAkIANBCGooAgAhASADKAIEIQIgAygCAEEBRwRAIAMgA0EMaigCADYCCCADIAE2AgQgAyACNgIAIAMQgQVBACECCyAAIAE2AgQgACACNgIAIANBEGokAAtvAQF/IwBBMGsiAyQAIAMgAjYCBCADIAE2AgAgA0EcakECNgIAIANBLGpBywA2AgAgA0ICNwIMIANB9KvKADYCCCADQcsANgIkIAMgA0EgajYCGCADIAM2AiggAyADQQRqNgIgIANBCGogABC9BAALcgEBfyMAQTBrIgIkACACIAE2AgQgAiAANgIAIAJBHGpBAjYCACACQSxqQcsANgIAIAJCAjcCDCACQaCvygA2AgggAkHLADYCJCACIAJBIGo2AhggAiACQQRqNgIoIAIgAjYCICACQQhqQbCvygAQvQQAC3IBAX8jAEEwayICJAAgAiABNgIEIAIgADYCACACQRxqQQI2AgAgAkEsakHLADYCACACQgI3AgwgAkHkr8oANgIIIAJBywA2AiQgAiACQSBqNgIYIAIgAkEEajYCKCACIAI2AiAgAkEIakH0r8oAEL0EAAtWAQJ/IwBBIGsiAiQAIAFBHGooAgAhAyABKAIYIAJBGGogAEEQaikCADcDACACQRBqIABBCGopAgA3AwAgAiAAKQIANwMIIAMgAkEIahAzIAJBIGokAAtWAQJ/IwBBIGsiAiQAIABBHGooAgAhAyAAKAIYIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAMgAkEIahAzIAJBIGokAAttAgJ/An4jAEGAAWsiAiQAIAEpAwAhBCABKQMIIQUgAiABQdQAahDkBSAAIAU3AwggACAENwMAIAEoAlAhAyAAQRBqIAFBEGpBwAAQ8gMaIAAgAzYCUCAAQdQAaiACQYABEPIDGiACQYABaiQAC2gBAX8jAEGABGsiAyQAIANBEGoQsgMgA0EQaiABIAIQ0QUgA0GoAmogA0EQakHYARDyAxogA0HoAWogA0GoAmoQoQQgA0EIaiADQegBahCpBSAAIAMoAgggAygCDBCcAyADQYAEaiQAC2oBAX8jAEEQayIDJAAgASgCAEEBRgRAIAMgASkCBDcDCEGw98EAQSsgA0EIakHc98EAIAIQqAIACyAAIAEpAgQ3AgAgAEEQaiABQRRqKQIANwIAIABBCGogAUEMaikCADcCACADQRBqJAALVgEBfyMAQTBrIgIkACACQRBqIAEQnQMgAkEoaiACQRhqKAIANgIAIAIgAikDEDcDICACQQA2AiwgAkEIaiACQSBqEK8DIAAgAikDCDcCACACQTBqJAALbQICfwJ+IwBBgAFrIgIkACABKQMAIQQgASkDCCEFIAIgAUHUAGoQswQgACAFNwMIIAAgBDcDACABKAJQIQMgAEEQaiABQRBqQcAAEPIDGiAAIAM2AlAgAEHUAGogAkGAARDyAxogAkGAAWokAAthAQF/IwBBIGsiAiQAIAEQbSACEOwBIAFBzABqIAIQYiAAQRhqIAJBGGopAwA3AAAgAEEQaiACQRBqKQMANwAAIABBCGogAkEIaikDADcAACAAIAIpAwA3AAAgAkEgaiQAC14BAX8jAEEgayIEJAAgBCADNgIUIAQgAjYCEAJ/IAEgA08EQCAEQQhqIAEgA2sgASAAIAEQ1AMgBCAEKQMINwMYQQEgBEEQaiAEQRhqEJMFDQEaC0EACyAEQSBqJAALXAECfyMAQRBrIgIkACAAKAIAIgAoAgghAyAAKAIAIQAgAiABEMAEIAMEQANAIAIgADYCDCACIAJBDGoQjwEgAEEBaiEAIANBf2oiAw0ACwsgAhC+BCACQRBqJAALWgECfyMAQTBrIgIkACACQQhqIAFBARAqQQAhAQNAIAFBKEYEQCAAIAJBCGpBKBDyAxogAkEwaiQABSACQQhqIAFqIgMgAykDAEIBhjcDACABQQhqIQEMAQsLC14BAn8jAEHQAGsiAiQAIAAgASABQfgAaiIDEB4gAiABQShqIAFB0ABqIgEQHiACQShqIAEgAxAeIABBKGogAkEoEPIDGiAAQdAAaiACQShqQSgQ8gMaIAJB0ABqJAALZQEBfyMAQZABayIDJAAgA0EIaiACEKsCIANBADYCGCADIAMpAwg3AxAgA0EgaiABQfAAEPIDGiADQRBqIAIgA0EgahDUASAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBkAFqJAALXQICfwF+AkAgASgCACIEIAEoAgQiAWpBf2pBACABa3EiAyAETwRAIAOtIAKtfiIFQiCIpw0BIAAgAzYCCCAAIAE2AgQgACAFPgIADwsgAEEANgIEDwsgAEEANgIEC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpB5JnKACACQQhqEDMgAkEgaiQAC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpBtKjKACACQQhqEDMgAkEgaiQAC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpBhK7KACACQQhqEDMgAkEgaiQAC2cBAX8jAEHAA2siBSQAIAUgASACEF4gBUHgAWogBUHMg8AAEMcCIAVBoANqIAMgBBCkAiAFIAVB4AFqIAVBoANqEPgBIAVBoANqIAUQ4QUQ1gMgACAFQaADakEgEJwDIAVBwANqJAALXQEDfyMAQRBrIgIkAAJAIAEoAgAgASgCBE8NACACQQhqIAFBARDwBCACKAIIQQFHDQAgASgCACEDIAEgAigCDDYCAEEBIQQLIAAgAzYCBCAAIAQ2AgAgAkEQaiQAC2cBA38gAEEEaiEBIAAoAgBFBEAgARCBBQ8LIAEtAABBAk8EQCAAQQhqKAIAIgEoAgAgASgCBCgCABEDACABKAIEIgIoAgQiAwRAIAEoAgAgAyACKAIIELYFCyAAKAIIQQxBBBC2BQsLWwEBfyMAQSBrIgQkACAEIAM2AhQgBCACNgIQAn8gASADTwRAIARBCGpBACADIAAgARDUAyAEIAQpAwg3AxhBASAEQRBqIARBGGoQkwUNARoLQQALIARBIGokAAtWAQF/IwBBIGsiAiQAIAIgADYCBCACQRhqIAFBEGopAgA3AwAgAkEQaiABQQhqKQIANwMAIAIgASkCADcDCCACQQRqQYSuygAgAkEIahAzIAJBIGokAAtTAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqEIcEIAIoAgghASAAIAIoAgw2AgQgACABNgIAIAJBIGokAAtkAQF/IwBBIGsiBSQAIAVBGGogAEHIASADEJ0EIAVBEGogBSgCGCAFKAIcIAQQngQgBSgCFCEAIAUoAhAhAyAFQQhqIAEgAiAEEJ4EIAUoAgggBSgCDCADIAAQrgEgBUEgaiQAC1kBAX8jAEGgAWsiAiQAIAJB0ABqIAEQYyACIAJB0ABqQSgQ8gMiAUEoaiABQfgAakEoEPIDGiABQdAAaiABQQUQKiAAIAFB0ABqIAFBKGoQHiABQaABaiQAC2QBAX8jAEHwA2siAiQAIAIgAUHYAWoQ7QIgAkGYAmogAUHYARDyAxogAkHYAWogAkGYAmoQ7gMgAiACQdgBahCyBCACQZgCaiACQdgBEPIDGiAAIAJBmAJqEO4DIAJB8ANqJAALXAEBfyMAQSBrIgIkACACEO8DNgIMIAJBEGogARC1AiACIAJBEGoQmwUgAkEMaiACKAIAIAIoAgQQvAUgAEEIaiACQRhqKAIANgIAIAAgAikDEDcCACACQSBqJAALXwEBfyMAQeACayICJAAgACABEOkCIAJBCGogAUGwA2oQ5AUgAkGIAWogAUHYAWoQ6QIgAEGwA2ogAkEIakGAARDyAxogAEHYAWogAkGIAWpB2AEQ8gMaIAJB4AJqJAALYgEBfyMAQSBrIgIkACACIAEQSCAAIAFBoAEQ8gMiAEG4AWogAkEYaikDADcAACAAQbABaiACQRBqKQMANwAAIABBqAFqIAJBCGopAwA3AAAgACACKQMANwCgASACQSBqJAALXwEBfyMAQeACayICJAAgACABEO0CIAJBCGogAUGwA2oQswQgAkGIAWogAUHYAWoQ7QIgAEGwA2ogAkEIakGAARDyAxogAEHYAWogAkGIAWpB2AEQ8gMaIAJB4AJqJAALZAEBfyMAQRBrIgMkACABKAIAQQFGBEAgAyABKAIENgIIIAMgAUEIai0AADoADEGp88kAQSsgA0EIakHU88kAIAIQqAIACyAAIAEoAgQ2AgAgACABQQhqLQAAOgAEIANBEGokAAtqAQN/IwBBEGsiACQAIAAQ/wEgACAALQAEIgE6AAwgACAAKAIAIgI2AgggAEEIahCaBQJAAkAgAUECSw0AAkAgAUEBaw4CAQIACxCbBEUNACACQQE6AAQLIAIoAgBBADoAAAsgAEEQaiQAC1kBAX8jAEHQAGsiAiQAIAAgAUEoakEoEPIDIQAgAiABQSgQ8gMiAkEoaiABQdAAahDZAyAAQShqIAJBKBDyAxogAEHQAGogAkEoakEoEPIDGiACQdAAaiQAC00BA39BASEDA38gAkEgRgR/IAMQlgUFIAEgAmotAAAgACACai0AAHMiBEEAIARrckF/c0GAAXFBB3YQlgUgA3EhAyACQQFqIQIMAQsLC2oBAX8CQCABQX9KBEACQCABRQRAQQEhAgwBCwJ/IAJFBEAgAUEBEKQFDAELIAEiAkEBEN0BIgMEQCADQQAgAhDBBBoLIAMLIgJFDQILIAAgATYCBCAAIAI2AgAPCxDrBQALIAFBARDdBQALUgEBfyMAQSBrIgIkACACQRhqIAFBEGooAgA2AgAgAkEQaiABQQhqKQIANwMAIAIgASkCADcDCCACIAJBCGoQhgIgACACKQMANwIAIAJBIGokAAtbAAJAIAEgA30iAyABVg0AAkAgAiAETwRAIAMhAQwBCyADQn98IgEgA1YNASACQYCU69wDaiECCyAAIAE3AwAgACACIARrNgIIDwtBlKTKAEEjQcykygAQjgMAC0wBA39BASEDA0AgAkEgRwRAIAEgAmotAAAgACACai0AAHMiBEEAIARrckF/c0GAAXFBB3YQlgUgA3EhAyACQQFqIQIMAQsLIAMQlgULVwECfyMAQRBrIgIkACACQQhqIAEQqwECf0EAIAIvAQhFDQAaIAIgAUEgaiACLwEKEKQEIAIoAgQhAyACKAIACyEBIAAgAzYCBCAAIAE2AgAgAkEQaiQAC10BAX8jAEEwayIDJAAgAyABNgIMIAMgADYCCCADQSRqQQE2AgAgA0IBNwIUIANBlKvKADYCECADQbQBNgIsIAMgA0EoajYCICADIANBCGo2AiggA0EQaiACEL0EAAtVAQF/IwBBIGsiAiQAIAJBGGogAUEYaikCADcDACACQRBqIAFBEGopAgA3AwAgAkEIaiABQQhqKQIANwMAIAIgASkCADcDACAAIAIQuwIgAkEgaiQAC2ABA38jAEEQayIBJAACQEGg2MoAKAIAIgANAEEDQQAQnQEhAkGg2MoAQaDYygAoAgAiACACIAAbNgIAIABFBEAgAiEADAELIAEgAjYCDCABQQxqEP4DCyABQRBqJAAgAAtYAQJ/IwBBEGsiASQAQQFBARCkBSICRQRAQQFBARDdBQALIAJBADoAACAAQQA6AAQgACACNgIAIAAgAS8ADTsABSAAQQdqIAFBD2otAAA6AAAgAUEQaiQAC1gBAX8jAEEQayICJAACQCAAKAIABEAgAiABQfSFygBBBBCcBCACIAA2AgwgAiACQQxqQfiFygAQjgEMAQsgAiABQYiGygBBBBCcBAsgAhCAAiACQRBqJAALVwEBfwJAIAJBf0oEQAJAIAJFBEBBASEDDAELIAJBARCkBSIDRQ0CCyADIAEgAhDyAyEBIAAgAjYCCCAAIAI2AgQgACABNgIADwsQ6wUACyACQQEQ3QUAC1YBAX8jAEEQayICJAAgAiABQfSlygBBCBCcBCACIAA2AgwgAiACQQxqQayeygAQjgEgAiAAQQRqNgIMIAIgAkEMakH8pcoAEI4BIAIQgAIgAkEQaiQAC0wBAX8jAEFAaiIBJAAgAUEYakIANwMAIAFBEGpCADcDACABQQhqQgA3AwAgAUIANwMAIAFBIGogABBDIAFBIGogARCIAyABQUBrJAALVgECfyABKAIAIQIgAUEANgIAAkAgAgRAIAEoAgQhA0EIQQQQpAUiAUUNASABIAM2AgQgASACNgIAIABBvMbEADYCBCAAIAE2AgAPCwALQQhBBBDdBQALVgECfyABKAIAIQIgAUEANgIAAkAgAgRAIAEoAgQhA0EIQQQQpAUiAUUNASABIAM2AgQgASACNgIAIABBnOnJADYCBCAAIAE2AgAPCwALQQhBBBDdBQALVQICfwJ+IwBBIGsiASQAEO8FIAEpAxAhAyABKAIYIQIgARCLAiABKQMAIQQgAEEYaiABKQMINwMAIAAgBDcDECAAIAI2AgggACADNwMAIAFBIGokAAtVAQJ/IwBBIGsiAiQAIAJBEGogARDRBCACQQhqIAJBEGpBtPXJABCFAyACKAIIIQMgAEEIaiACLQAMQQFxOgAAIAAgAzYCBCAAIAE2AgAgAkEgaiQAC1YBAn8gASgCACECIAFBADYCAAJAIAIEQCABKAIEIQNBCEEEEKQFIgFFDQEgASADNgIEIAEgAjYCACAAQcyCygA2AgQgACABNgIADwsAC0EIQQQQ3QUAC1YBAn8gASgCACECIAFBADYCAAJAIAIEQCABKAIEIQNBCEEEEKQFIgFFDQEgASADNgIEIAEgAjYCACAAQYCMygA2AgQgACABNgIADwsAC0EIQQQQ3QUAC1QBAX8jAEEgayIDJAAgA0EIaiACQQAQiQMgA0EANgIYIAMgAykDCDcDECADQRBqIAEgAhCuBSAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBIGokAAtbAQF/IwBBIGsiAiQAIAIgARDvASACKAIAQQFGBEAgAiACKQIENwMYQbD3wQBBKyACQRhqQdz3wQBBiPrBABCoAgALIAIgAigCBBCmASAAIAIQ5wQgAkEgaiQAC1MBAX8jAEFAaiIDJAAgA0EgaiABIAIQrAEgA0EIaiADQSBqQaj6wQAQ6wIgAyADQQhqELAEIAAgAygCACADKAIEEJwDIANBCGoQowUgA0FAayQAC1YBAX8jAEEgayICJAAgAkEIakHAAEEAEIkDIAJBADYCGCACIAIpAwg3AxAgAkEQaiABQcAAEK4FIABBCGogAigCGDYCACAAIAIpAxA3AgAgAkEgaiQAC1cBAX8jAEEgayIDJAAgA0EIaiACQQAQiQMgA0EANgIYIAMgAykDCDcDECADQRBqIAEgASACahCgBCAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBIGokAAtxAQJ/QRchAkGghMoAIQMCQAJAAkACQAJAIAFB/wFxQQFrDgQBAgMABAtB3ILKAEEoQeCDygAQuQQAC0ESIQJBjoTKACEDDAILQREhAkH9g8oAIQMMAQtBDSECQfCDygAhAwsgACACNgIEIAAgAzYCAAtZAQF/IwBBEGsiAiQAAkAgASgCAA0AIAIgASgCBCABQQhqKAIAEC8gAigCAA0AIAAgAigCBCACQQhqKAIAEJMDIAJBEGokAA8LQeiQygBBKEHskcoAELoEAAtKAQF/IAAoAghBKGwhASAAKAIAIQADQCABBEAgACgCAARAIAAQgQULIAAoAhQEQCAAQRRqEIEFCyAAQShqIQAgAUFYaiEBDAELCwtWAQJ/IAEoAgAhAiABQQA2AgACQCACBEAgASgCBCEDQQhBBBCkBSIBRQ0BIAEgAzYCBCABIAI2AgAgAEHkpcoANgIEIAAgATYCAA8LAAtBCEEEEN0FAAtgAQF/IwBBEGsiAiQAAkACQAJAAkAgAC0AAEEBaw4CAgABCyACIAFB6/DDAEELEJwEDAILIAIgAUH88MMAQQoQnAQMAQsgAiABQfbwwwBBBhCcBAsgAhCAAiACQRBqJAALTQEBfyMAQRBrIgMkACADIAAgASACEJ4BAkAgAygCAEEBRgRAIANBCGooAgBFDQFBzMbEAEEoQZTHxAAQzgMACyADQRBqJAAPCxDCBQALSgEBfyMAQRBrIgIkACACIAAgARB2AkAgAigCAEEBRgRAIAJBCGooAgBFDQFBpN3JAEEoQezdyQAQzgMACyACQRBqJAAPCxDCBQALQQIBfwF+IwBBEGsiASQAIAFBCGpBIUEAEIkDIAEpAwghAiAAQRBqQQA2AgAgAEIANwIAIAAgAjcCCCABQRBqJAALUQEBfyADEMwDIQQgACACNgIEIAAgATYCACAAQQA2AhQgACADKQIANwIIIABBEGogA0EIaigCADYCACAAIAQgAiABa0EDdiIAIAAgBEsbNgIYC1EBAX8gAxDMAyEEIAAgAjYCBCAAIAE2AgAgAEEANgIUIAAgAykCADcCCCAAQRBqIANBCGooAgA2AgAgACAEIAIgAWtBAnYiACAAIARLGzYCGAtMAQF/IwBBEGsiAyQAIAMgACABIAIQdQJAIAMoAgBBAUYEQCADQQhqKAIARQ0BQaTvyQBBKEGU78kAEM4DAAsgA0EQaiQADwsQwgUAC1cBAX8jAEEwayIBJAAgAUEIaiAAQdcAEKYFIAFBJGpBATYCACABQgE3AhQgAUHw78kANgIQIAEgASkDCDcDKCABIAFBKGo2AiAgAUEQakGY8MkAEKkEAAtXAQF/IwBBMGsiASQAIAFBCGogAEHXABCmBSABQSRqQQE2AgAgAUIBNwIUIAFB7PXJADYCECABIAEpAwg3AyggASABQShqNgIgIAFBEGpB0PbJABCpBAALTAEBfyMAQRBrIgMkACADIAAgASACEHoCQCADKAIAQQFGBEAgA0EIaigCAEUNAUGqicoAQShB8InKABDOAwALIANBEGokAA8LEMIFAAtFAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqEP0CIAAgAikDCDcCACACQSBqJAALSwEBfyMAQTBrIgIkACACQRhqQgA3AwAgAkEgakIANwMAIAJBKGpCADcDACACQgA3AxAgAkIBNwMIIAAgAkEIaiABEFkgAkEwaiQAC18BAX8jAEEgayIBJAAgAUEYakGU3ckANgIAIAFBFGpB2PbIADYCACABQQxqQrzmADcCACABQQE7ARwgAUHY9sgANgIIIAFCgICAgMDnDDcDACAAIAEQtAEgAUEgaiQAC1MBAX8jAEGAAWsiASQAIAEQpwIgAEIANwMAIABBADYCUCAAQQhqQgA3AwAgAEHUAGogAUGAARDyAxogAEEQakHI6MkAQcAAEPIDGiABQYABaiQAC04BAX8jAEEgayIBJAAgAUEQaiAAENEEIAEgAUEQakHk9MkAEIUDIAEgAS0ABDoADCABIAEoAgA2AgggAC0AECABQQhqENIEIAFBIGokAAtDAQN/AkAgAkUNAANAIAAtAAAiAyABLQAAIgRGBEAgAEEBaiEAIAFBAWohASACQX9qIgINAQwCCwsgAyAEayEFCyAFC0sBAX8jAEHQAGsiBiQAIAZBCGogBSADIAQgASACEM8DIAYoAkgiAUHBAE8EQCABQcAAEOUCAAsgACAGQQhqIAEQnAMgBkHQAGokAAtHAQF/IwBBIGsiAiQAIAJBCGogARBbIAAgAikCDDcCACAAQQhqIAJBFGopAgA3AgAgAEEQaiACQRxqKAIANgIAIAJBIGokAAtPAgF/An4jAEEQayIEJAAgBEEIakEAIAMgASACENQDIAQpAwghBSAEIAMgAiABIAIQ1AMgBCkDACEGIAAgBTcCACAAIAY3AgggBEEQaiQAC0oAAn8gAUGAgMQARwRAQQEgACgCGCABIABBHGooAgAoAhARAgANARoLIAJFBEBBAA8LIAAoAhggAiADIABBHGooAgAoAgwRBAALC0IBBH8CQCABKAIAIgIgASgCBE8NACACQQFqIgMgAkkNACABKAIAIQQgASADNgIAQQEhBQsgACAENgIEIAAgBTYCAAtIAQF/IwBBEGsiBiQAIAYgBTYCDCABIAIgA0EAEJUFIAEgBkEMakEEQQEQlQUgASAEIAUQwgIgACABQdABEPIDGiAGQRBqJAALSgAgACABKQAANwAAIABBF2ogAUEXaikAADcAACAAQRBqIAFBEGopAAA3AAAgAEEIaiABQQhqKQAANwAAIAAgAS0AH0H/AHE6AB8LRgEBfyMAQYABayIDJAAgA0EwaiABEIYBIANB2ABqIAIQhgEgA0EIaiADQTBqIANB2ABqEA0gACADQQhqEHEgA0GAAWokAAtKAgJ/An4CfkIAIAEoAgQiAkEISQ0AGiABKAIAIgMpAAAhBCABIAJBeGo2AgQgASADQQhqNgIAQgELIQUgACAENwMIIAAgBTcDAAtIAQN/An9BACABKAIEIgJBBEkNABogASgCACIDKAAAIQQgASACQXxqNgIEIAEgA0EEajYCAEEBCyEBIAAgBDYCBCAAIAE2AgALSgEBfyMAQUBqIgIkACACQQBBwAAQwQQiAkEgIAFBwAFqQSAQsAEgAkEgakEgIAFBoAFqQSAQsAEgACACQcAAEPIDGiACQUBrJAALRgEBfyMAQYABayIDJAAgA0EwaiABEIcBIANB2ABqIAIQhwEgA0EIaiADQTBqIANB2ABqEA4gACADQQhqEHEgA0GAAWokAAtFAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqELoCIAAgAikDCDcCACACQSBqJAALNQAgAQR/QX8gAkF/amd2QQAgAkECTxsiAUEBaiICIAFPBUEACyEBIAAgAjYCBCAAIAE2AgALRgEBfyMAQRBrIgMkACADQQxqIAJBCGooAgA2AgAgAyACKQIANwIEIAMgATYCACAAIAEgA0EEchC/ASAAEPoCIANBEGokAAtHAQN/IwBBEGsiAiQAIAJBCGogAUEEahCqBSACKAIMIQQgAigCCCEDIAAgATYCCCAAIAM2AgAgACADIARqNgIEIAJBEGokAAtCAQR/IAAoAgQgACgCACIBayECA0AgAkUEQEEADwsgACABQQFqIgM2AgAgAkF/aiECIAEsAAAgAyEBQX9KDQALQQELRgEBfyMAQRBrIgMkACADIAEgAhAvIAMoAgQhASADKAIAIQIgACADQQhqKAIANgIEIABBACABIAJBAUYbNgIAIANBEGokAAtDAQF/IwBBEGsiAiQAIAIgACABEOMCIAIgAigCBDYCDCACIAIoAgAiADYCCCAABEAgAkEIahD6AQsgAkEQaiQAIABFCzoBA39BHyEBA0AgAUF/RwRAIAAgAWoiAiADIAItAAAiAkEDdnI6AAAgAUF/aiEBIAJBBXQhAwwBCwsLNgEDfwNAIAFBIEcEQCAAIAFqIgIgAyACLQAAIgJBA3RyOgAAIAFBAWohASACQQV2IQMMAQsLC0YBAn8CQCAALQAQQQVGDQAgACgCCCIBRQ0AIAEgACgCDCgCABEDACAAKAIMIgEoAgQiAkUNACAAKAIIIAIgASgCCBC2BQsLQQAgAEEANgIQIAAgAzYCCCAAIAI2AgQgACABNgIAIABBDGogBDYCACAAIAQgA2siACACIAFrIgEgASAASxs2AhQLQAECfyAAKAIEIgFFBEBBAA8LIAAoAggiAARAIAEgAG4iAiABIAAgAmxrQQBHag8LQcDhyQBBGUGs4ckAEM4DAAs/AQF/IAAgASgCCCIDIAJsIgIgASgCAGo2AgAgACABKAIEIgAgACACIANqIgEgASAASxsgASACSRsgAms2AgQLSAEBfyMAQSBrIgMkACADQRRqQQA2AgAgA0HEqsoANgIQIANCATcCBCADIAE2AhwgAyAANgIYIAMgA0EYajYCACADIAIQvQQAC0MBAX8jAEGgA2siBiQAIAYgASACIAMQvQEgBiAEIAUQcyAGQdABaiAGQdABEPIDGiAAIAZB0AFqENgEIAZBoANqJAALQQECfwJAIAAoAggiAUUNACABIABBDGoiASgCACgCABEDACABKAIAIgEoAgQiAkUNACAAKAIIIAIgASgCCBC2BQsLOgEBfyMAQRBrIgAkAEHk+coAKAIAQQNHBEAgAEEBOgALIAAgAEELajYCDCAAQQxqED4LIABBEGokAAtFAQF/IwBBEGsiBSQAIAUgBDYCDCAAIAEgAkEAEJUFIAAgBUEMakEEQQEQlQUgAEECQQAQRCAAIAMgBBDBAiAFQRBqJAALPQEBfyMAQRBrIgUkACAFIAQ2AgwgACABIAJBABCVBSAAIAVBDGpBBEEBEJUFIAAgAyAEEPsBIAVBEGokAAs4AAJAIAIgAU8EQCAEIAJPDQEgAiAEEOUCAAsgASACEOYCAAsgACACIAFrNgIEIAAgASADajYCAAs4AQF/IwBBMGsiAyQAIANBCGogAUEoEPIDGiADQQhqIAIQ5QMgACADQQhqQSgQ8gMaIANBMGokAAs8ACAAIAEpAAA3AAAgAEEYaiABQRhqKQAANwAAIABBEGogAUEQaikAADcAACAAQQhqIAFBCGopAAA3AAALPQEBfyMAQRBrIgIkACACIAFB0brGAEEOEJwEIAIgADYCDCACIAJBDGpB4LrGABCOASACEIACIAJBEGokAAtFAQJ/IwBBEGsiASQAQbyOygAoAgARCAAiAEUEQEGIk8oAQcYAIAFBCGpBqJTKAEGYlMoAEKgCAAsgAC0AACABQRBqJAALNgEBfyMAQTBrIgIkACACQQhqIAFBKBDyAxogAkEIahCCAiAAIAJBCGpBKBDyAxogAkEwaiQACz4BAX8jAEHgAWsiAyQAIAMQwwIgAyABIAIQjQEgA0HwAGogA0HwABDyAxogACADQfAAahDuAiADQeABaiQACzsBAn8jAEEQayICJAAgAkEIaiABEKoFIAIoAgwhASAAIAIoAggiAzYCACAAIAEgA2o2AgQgAkEQaiQACzkBAX4CQCAAKQMIIgJCAVMNACAAKAKcIEEASA0AIAAgAkJAfDcDCCAAQRBqIAEQEQ8LIAAgARDbAQs4AQF/IwBBEGsiAyQAIANBADYCDCADIAIgA0EMahCqASAAIAEgAygCACADKAIEEPsCIANBEGokAAs5AQF/IwBBEGsiAiQAIAJBADYCDCACQcUAIAJBDGoQqgEgACABIAIoAgAgAigCBBDvAiACQRBqJAALSAACQCAALQAEDQBBiPrKACgCAEEBRwRAQYj6ygBCATcDAAwBC0GM+soAKAIARQ0AIAAoAgBBAToABAsgACgCACgCAEEAOgAAC2MBA38jAEEQayIBJAAgACgCDCICRQRAQZicygBBK0GMpcoAEM4DAAsgACgCCCIDRQRAQZicygBBK0GcpcoAEM4DAAsgAUEANgIEIAEgAzYCACABQaylygAgACgCCCACEMABAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQbCCwABBLkH8gsAAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQdyFwABBLkGohsAAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQaD5wQBBLkHs+cEAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQaz7wQBBLkH4+8EAEM4DAAswAQJ/A0AgAkEoRwRAIAAgAmoiAyADKQMAIAEgAmopAwB8NwMAIAJBCGohAgwBCwsLOQEBfyMAQRBrIgQkACAEQQhqIANBCGooAgA2AgAgBCADKQIANwMAIAAgASACIAQQqgMgBEEQaiQACzkBAX8jAEEQayIEJAAgBEEIaiADQQhqKAIANgIAIAQgAykCADcDACAAIAEgAiAEEKkDIARBEGokAAs+AQF/IwBBEGsiASQAIAEQkQMgAUEIakIBNwIAIABBADoAECAAIAEpAwA3AgAgACABKQMINwIIIAFBEGokAAtOAQN/IwBBEGsiASQAIAFBCGoiAiAAKAIEIgNBGGw2AgAgAiADQQBHQQJ0NgIEIAEoAgwiAgRAIAAoAgAgASgCCCACELYFCyABQRBqJAALMwECfxCbBCECAn9BACABLQAERQ0AGkEBCyEDIAAgATYCBCAAIAM2AgAgAEEIaiACOgAACzoBAX8gABCaBSAALQAEIgFBAkcEQAJAIAENACAAKAIAEJsERQ0AQQE6AAQLIAAoAgAoAgBBADoAAAsLOQEBfyMAQRBrIgMkACADIAI2AgwgAyABNgIIIAAgA0EIaigCADYCACAAIAMoAgw2AgQgA0EQaiQACzQAIAEoAgAEQCABQQhqIAFBB2otAAAQigQLIAAgASkCCDcCACAAQQhqIAFBEGooAgA2AgALMgEBfyMAQUBqIgIkACABEIEBIAIQpgIgAUEQaiACEHAgACACQcAAEPIDGiACQUBrJAALQgECfyMAQRBrIgAkAEHE9ckAKAIAEQgAIgFFBEBB4PbJAEHGACAAQQhqQYD4yQBB8PfJABCoAgALIABBEGokACABCzYBAn4gASkAACEDIAAgAUEIaikAAEIBhCICNwMIIAAgAiADfEKt/tXk1IX9qNgAfiACfDcDAAs1AQF/IwBBEGsiAiQAIAJBCGogACgCACAAKAIEEKYFIAIoAgggAigCDCABELsBIAJBEGokAAszAQF/IAIEQCAAIQMDQCADIAEtAAA6AAAgA0EBaiEDIAFBAWohASACQX9qIgINAAsLIAALLQEBfyADIAIQ3QEiBARAIAQgACADIAEgASADSxsQ8gMaIAAgASACEN4BCyAECzoBAX8jAEFAaiIDJAAgAUHY8MMAQQcgA0EAQcAAEMEEIgFBwAAgAkEBEIoFIAAgARDDBCABQUBrJAALNgEBfyMAQdABayIDJAAgAxDrASADQfjywwBBByABIAIQ0gMgACADQdABEPIDGiADQdABaiQACzIBAX8jAEEQayIDJAAgAyACNgIMIAAgA0EMakEEQQAQlQUgACABIAIQ+wEgA0EQaiQACy0BAX8jAEFAaiICJAAgAiAAEEMgAkEgaiABEEMgAiACQSBqEIgDIAJBQGskAAszAQF/IAJBAXYhAyACQQ9NBEAgACABIANBoAFsakGgARDyAxoPC0GsvsQAIANBCBDkAgALOAEBfyABQQF2IQIgAUH/AE0EQCAAIAJB+ABsQdj8wwBqQfgAEPIDGg8LQby+xAAgAkHAABDkAgALMwEBfyACQQF2IQMgAkEPTQRAIAAgASADQaABbGpBoAEQ8gMaDwtBhPDIACADQQgQ5AIACzgBAX8gAUEBdiECIAFB/wBNBEAgACACQfgAbEGAr8gAakH4ABDyAxoPC0GU8MgAIAJBwAAQ5AIACzgBAX8gASgCCCIDIAJB//8DcSICTQRAQbj0yAAgAiADEOQCAAsgACABKAIAIAJBA3RqKQIANwIACzcCAX8BfiMAQRBrIgIkACACQQhqIAFBABCJAyACKQMIIQMgAEEANgIIIAAgAzcCACACQRBqJAALMgECfyAAKAIAIgEoAgRB8ABsIgIEfyABKAIAIAJBCBC2BSAAKAIABSABC0EQQQQQtgULNQEBfyAALQAIIgFBAkcEQAJAIAENACAAKAIEEJsERQ0AQQE6AAQLIAAoAgQoAgBBADoAAAsLMgEBfyAAKAIIQQxsIQEgACgCACEAA0AgAQRAIAFBdGohASAAELUEIABBDGohAAwBCwsLNgEBfyABIAIoAgAiBBCoBCABKAIAEMAFIABBCGogAzoAACAAIAI2AgQgACACLQAEQQBHNgIACysAAkAgAEF8Sw0AIABFBEBBBA8LIAAgAEF9SUECdBCkBSIARQ0AIAAPCwALLwAgAyABIAQgAkECdCIBIAEgBEsbIgEQ8gMaIAAgATYCBCAAIAFBA2pBAnY2AgALNQEBf0EBQQEQpAUiAUUEQEEBQQEQ3QUACyABQQA6AAAgAEEAOgAFIABBADoABCAAIAE2AgALMwEBfyABKAIIIgMgAkkEQCACIAMQ5gIACyAAIAMgAms2AgQgACABKAIAIAJBGGxqNgIACzAAIAAoAghBAUYEfyAAKAIAIgBBgonKAEYEQEEBDwsgAEGCicoAQQEQtANFBUEACwtJAQN/IwBBEGsiAiQAIAEiAygCCCIEIAEoAgRHBEAgAyAEENQCCyACQQhqIAEoAgAgASgCBBDsAyAAIAIpAwg3AgAgAkEQaiQACzUBAX8jAEHAAmsiAyQAIANBoAFqIAIQiQIgAyABIANBoAFqEJIBIAAgAxCDAiADQcACaiQACzABAX8gACgCACIBIAAoAgRHBEAgACABQQFqNgIAIAAgACgCCEEBajYCCCABDwtBAAs0ACAAKAIIIAAoAgRGBEAgAEEBEL4FCyAAKAIAIAAoAghqIAE6AAAgACAAKAIIQQFqNgIICzABAX8jAEEQayICJAAgACgCCCABTwRAIAJBCGogABCbBSAAIAE2AggLIAJBEGokAAs4AQF/IAFBBGohBAJAIAEoAgBBAUYEQCAEKAIAIAIgAxAJDAELIAQoAgAgAiADEAoLIABBBToAEAszAQF/IwBBEGsiBCQAIARBCGogASACIAMoAgAgAygCCBAwIAAgBCkDCDcCACAEQRBqJAALMwAjAEEQayIAJAAgABD/ASAAIAAtAAQ6AAwgACAAKAIANgIIIABBCGoQ6wMgAEEQaiQACzoBAX9BvI7KACgCABEIACIARQRAQQEPCyAALQAABEAgAEEAOgAAQQAPC0G4lMoAQRxBrJXKABC6BAALMwEBfyMAQUBqIgQkACABIAIgAyAEQQBBwAAQwQQiAUHAABDTAyAAIAEQwwQgAUFAayQACzQAIAAoAgAhACABELQFRQRAIAEQtQVFBEAgADEAACABEHcPCyAAIAEQ8QEPCyAAIAEQ8AELMgAgACgCACEAIAEQtAVFBEAgARC1BUUEQCAAIAEQwwUPCyAAIAEQ9gEPCyAAIAEQ9QELLQEBfyMAQeABayICJAAgAkEIaiAAQdgBEPIDGiACQQhqIAEQeyACQeABaiQACy8BAX8jAEFAaiIEJAAgBCABQcABahBgIAAgBCACIAMgARBfIAQQoAIgBEFAayQACyYAAn9BAyAAKAIAIgBBAXENABpBAiAAQQRxDQAaIABBAXZBAXELCy4AIAAgBxD/BCACIAV8fCABEIAFfDcDCCAAIAYQ/wQgASAEfHwgAxCABXw3AwALLAAgAC0AEEECRwRAQZzYygBBnNjKACgCAEF/ajYCACAAKAIAQQFBARC2BQsLLgEBfwJAIAAoAgAiAUEBR0EAIAFBfmpBA0kbDQAgACgCBCIAQSRJDQAgABAACws0AQF/IwBBEGsiASQAIAAEQEGIk8oAQcYAIAFBCGpBqJTKAEGYlMoAEKgCAAsgAUEQaiQACysAIwBBEGsiACQAIABBCGogAUG8nsoAQQsQvwQgAEEIahCxAiAAQRBqJAALOgEBfwJAQYj6ygAoAgBBAUYEQEGM+soAKAIAIQAMAQtBiPrKAEIBNwMAC0GM+soAIAA2AgAgAEEARws0ACAAIAEoAhggAiADIAFBHGooAgAoAgwRBAA6AAggACABNgIAIAAgA0U6AAkgAEEANgIECy4BAX8jAEEQayIEJAAgBEEIaiADIAIgASACENQDIAAgBCkDCDcCACAEQRBqJAALLgEBfyMAQRBrIgQkACAEQQhqQQAgAyABIAIQ1AMgACAEKQMINwIAIARBEGokAAsvAQF/IwBBEGsiAiQAIAJBCGogAUEgIAEoAiAQngQgACACKQMINwIAIAJBEGokAAs1AQF/IAAgACgCCCACIAFrIgIQpgMgACAAKAIIIgMgAmo2AgggAyAAKAIAaiACIAEgAhCvAQsuAQF/IwBB4AFrIgIkACACQQhqIAFB2AEQ8gMaIAAgAkEIahDuAyACQeABaiQACyoBAX8jAEEQayIDJAAgA0EIaiABIAIQrwQgACADKQMINwIAIANBEGokAAskAAJAIAEgA0YEfyAAIAJHDQFBAQVBAAsPCyAAIAIgARC0A0ULMAEBfyMAQRBrIgMkACADQQhqIAEoAgAoAgAgAhD8AyAAIAMpAwg3AgAgA0EQaiQACywCAX8BfiMAQRBrIgEkACABQQA2AgwgACABQQxqEKcFIAE1AgwgAUEQaiQACykAIABBJGotAABBAkYEQCAAKAIAIAAoAgQgARDOAQ8LIABBCGogARAYCzABAX8gACACIAFrIgIQvgUgACAAKAIIIgMgAmo2AgggAyAAKAIAaiACIAEgAhCzAQswACAAIAAoAgQiACABIAAbNgIEIABFIAAgAUZyRQRAQfihygBBNkHIosoAELwEAAsLNQEBfyMAQRBrIgIkACACIAE2AgwgAiAANgIIIAJB7JvKADYCBCACQeybygA2AgAgAhDgAwALLAAgACABKQIANwIAIABBEGogAUEQaikCADcCACAAQQhqIAFBCGopAgA3AgALKgEBfyMAQTBrIgIkACACQQhqIAAQ2QMgACACQQhqIAEQiAIgAkEwaiQACysAIAAgASACEIgCIABBKGogAUEoaiACEIgCIABB0ABqIAFB0ABqIAIQiAILLQEBfyMAQRBrIgMkACADIAE2AgwgAyAANgIIIANBCGpBqMbEAEEAIAIQwAEACywBAX8jAEEQayICJAAgAkEIaiABENAFIAAgAigCCCACKAIMEH4gAkEQaiQACyEAIAJBIE8EQCAAQSA2AgQgACABNgIADwtBICACEOUCAAsrAQF/IwBBEGsiAiQAIAJBCGogAUEMahCbBSAAIAIpAwg3AgAgAkEQaiQACywBAX8jAEEQayICJAAgAkEIaiABEKoFIAAgAigCCCACKAIMEH4gAkEQaiQACywBAX8jAEEQayICJAAgAkEIaiABEKkFIAAgAigCCCACKAIMEH4gAkEQaiQACy0BAX8jAEEQayICJAAgAkEIaiABENsDIAAgAigCCCACKAIMENEBIAJBEGokAAstAQF/IwBBEGsiAyQAIAMgATYCDCADIAA2AgggA0EIakGI6ckAQQAgAhDAAQALLgEBfwJAIABBCGotAAANACAAKAIEEJsERQ0AQQE6AAQLIAAoAgQoAgBBADoAAAsuAQF/IwBBEGsiAiQAIAJBADYCCCACIAE2AgQgAiAANgIAIAIQ1AUgAkEQaiQACygBAX8Cf0EAIAEoAgARCAAiAQ0AGkEBCyECIAAgATYCBCAAIAI2AgALLAAgACABKQIANwIAIABBEGogAUEQaigCADYCACAAQQhqIAFBCGopAgA3AgALLQEBfyMAQRBrIgMkACADIAE2AgwgAyAANgIIIANBCGpBuILKAEEAIAIQwAEACy0BAX8jAEEQayIDJAAgAyABNgIMIAMgADYCCCADQQhqQeyLygBBACACEMABAAsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQ/QEgAkEQaiQACy0BAX8jAEEQayIDJAAgAyABNgIMIAMgADYCCCADQQhqQdClygBBACACEMABAAs1AQF/IwBBEGsiAiQAIAIgATYCDCACIAA2AgggAkGwq8oANgIEIAJBxKrKADYCACACEOADAAsyAQF/QQEhASAALQAEBH8gAQUgACgCACIAKAIYQbSsygBBASAAQRxqKAIAKAIMEQQACwswACABKAIYIAIgAyABQRxqKAIAKAIMEQQAIQIgAEEAOgAFIAAgAjoABCAAIAE2AgALNQEBfyABKAIYQbOsygBBASABQRxqKAIAKAIMEQQAIQIgAEEAOgAFIAAgAjoABCAAIAE2AgALKQEBfyACBEAgACEDA0AgAyABOgAAIANBAWohAyACQX9qIgINAAsLIAALJQEBfyMAQSBrIgEkACABIAAQQyABLQAAQQFxEJYFIAFBIGokAAsmAQF/IwBBMGsiAiQAIAJBCGogARBNIAAgAkEIahBxIAJBMGokAAspACACQYEBTwRAIAJBgAEQ5gIACyAAQYABIAJrNgIEIAAgASACajYCAAsmAQF/IwBBMGsiAiQAIAJBCGogARBOIAAgAkEIahBxIAJBMGokAAsmACACIANJBEAgAyACEOYCAAsgACACIANrNgIEIAAgASADajYCAAshACAAEJUEQf8BcUEDRgR/IABBBGpBACAAKAIEGwVBAAsLJgECfyMAQRBrIgAkACAAQZj6ygA2AgwgAEEMahDXAiAAQRBqJAALJgECfyMAQRBrIgAkACAAQaz6ygA2AgwgAEEMahDWAiAAQRBqJAALKwEBfyAAIAEoAgQiAjYCBCAAIAEoAgAgAigCCCIAQRdqQQAgAGtxajYCAAsnACAAQgA3AAAgAEEYakIANwAAIABBEGpCADcAACAAQQhqQgA3AAALJQEBfyABBH8gARDSBSECQQEFQQALIQEgACACNgIEIAAgATYCAAsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQkwIgAkEQaiQACygBAX8jAEEQayICJAAgAiAAKAIANgIMIAJBDGogARCWASACQRBqJAALKAEBfyMAQRBrIgIkACACQQhqIAEQmwUgACACKQMINwIAIAJBEGokAAsnAQF/IAAgACgCACIBQX9qNgIAIAFBAnEgAUEESXJFBEAgABCUAQsLLwEBfyABKAIAIgItAAAEQEGc8skAQSBBgPPJABC5BAALIAJBAToAACAAIAEQ6QQLKwEBfwJAIAAtAAQNACAAKAIAEJsERQ0AQQE6AAQLIAAoAgAoAgBBADoAAAsvAQF/IAEoAgAiAi0AAARAQciGygBBIEGsh8oAELoEAAsgAkEBOgAAIAAgARDqAwsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQ0QIgAkEQaiQACy8BAX8gASgCACICLQAABEBBk5LKAEEgQfiSygAQugQACyACQQE6AAAgACABEOkECyEBAX8jAEEgayIBJAAgASAAEBQgACABEJ8FIAFBIGokAAsiACABLQAAIAAtAABzIgBBACAAa3JBf3NBgAFxQQd2EJYFCycBAX8jAEHQAWsiAiQAIAAgAiABQdABEPIDIgAQuQEgAEHQAWokAAshAQF/IwBBIGsiASQAIAEgABAVIAAgARCfBSABQSBqJAALIgEBfyMAQSBrIgIkACACIAAgARDaAyACLQAAIAJBIGokAAspAQF/IwBB8ABrIgMkACAAIAMgAUHwABDyAyIAIAIQ8wIgAEHwAGokAAsgAAJAIAFBfEsNACAAIAFBBCACEJQFIgBFDQAgAA8LAAsnAQF/AkAgACgCBCIBRQ0AIABBCGooAgAiAEUNACABIABBARC2BQsLNgEBfyMAQUBqIgIkACAAIAIgAUHAABDyAyIBIgIQ4AQgAEHAAWogAkHAABDyAxogAUFAayQACyEBAX8jAEFAaiICJAAgAiABED8gACACEN4EIAJBQGskAAspAQF/IwBBoAFrIgIkACACIAFBqP/BABDJBSAAIAIQ4QQgAkGgAWokAAsnAQF/IwBBoAFrIgIkACAAIAIgAUGgARDyAyIAEIMDIABBoAFqJAALIAAgAUEETQRAIAAgAUEDdGoPC0HsusQAIAFBBRDkAgALIAAgAUEETQRAIAAgAUEDdGoPC0H8usQAIAFBBRDkAgALJQAgAyABTQRAIAAgAiADEPIDGg8LQdjDxABBKUHcxMQAEK0EAAsgACABQQRNBEAgACABQQN0ag8LQcTsyAAgAUEFEOQCAAsgACABQQRNBEAgACABQQN0ag8LQdTsyAAgAUEFEOQCAAskACAAIAEpAgA3AgAgAEEIaiABQQhqKAIANgIAIAFBDGoQgQULGQAgAC0AEEECRwRAIAAoAgBBAUEBELYFCwsnAQF/EJsEIQIgACABNgIEIABBCGogAjoAACAAIAEtAARBAEc2AgALJQEBfyABKAIAIgJFBEAgAEEDOgAkDwsgACACIAFBCGooAgAQeQsjACAAQQA2AgwgACABKQIANwIAIABBCGogAUEIaigCADYCAAsoAQF/IAAoAgghASAAQYGAxAA2AgggAUGBgMQARgR/IAAQkAEFIAELCx0AIAFBH00EQCAAIAFqDwtBjL3EACABQSAQ5AIACx0AIAFBH00EQCAAIAFqDwtB5O7IACABQSAQ5AIACyYBAX8gACgCACIBKAIAIAEoAgQgACgCBCgCACAAKAIIKAIAECkACx0AIAAgASgCACIBIAJqIgI2AgQgACACIAFPNgIACx4BAX8gACAAKAIAIgFBASABGzYCACABBEAgABBWCwseAQF/IAAoAgAiACgCACAAQQA2AgAoAgAoAgBBDEYLFAAgACgCAEEAOgAQIABBBGoQ0gQLHQEBfyAAKAIEIgEEQCAAKAIAIAFBKGxBBBC2BQsLHQEBfyAAQQRqKAIAIgEEQCAAKAIAIAFBARC2BQsLHQEBfyAAQQhqKAIAIgEEQCAAKAIEIAFBARC2BQsLHQAgASgCAEUEQAALIABBvMbEADYCBCAAIAE2AgALHAAgACABKQIANwIAIABBCGogAUEIaikCADcCAAscACAAIAEpAgA3AgAgAEEIaiABQQhqKAIANgIACx0AIAEoAgBFBEAACyAAQZzpyQA2AgQgACABNgIACx0AIAEoAgBFBEAACyAAQcyCygA2AgQgACABNgIACx4AIABBADYCCCAAIAI2AgQgACABNgIAIABBADoAEAsdACABKAIARQRAAAsgAEGAjMoANgIEIAAgATYCAAsdACAALQAAQQFGBEBByPTIAEEcQYT1yAAQzgMACwsTACAAQgaIIABCA4mFIABCLYmFCxMAIABCB4ggAEI4iYUgAEI/iYULGgEBfyAAKAIEIgEEQCAAKAIAIAFBARC2BQsLHQAgASgCAEUEQAALIABB5KXKADYCBCAAIAE2AgALGwAgAKdFBEBBjMbEAEEZQfzFxAAQjgMACyABCw4AIAAoAgBBAUEBELYFCx8AQZD7ygAtAABBAkYEQEGQ+8oAQQA6AAALQZD7ygALHAAgASgCGEHQqsoAQQsgAUEcaigCACgCDBEEAAscACABKAIYQduqygBBDiABQRxqKAIAKAIMEQQACxkAIAAoAhggASACIABBHGooAgAoAgwRBAALHAAgASgCGEG5wcoAQQUgAUEcaigCACgCDBEEAAsWACAAIAEgAiADIAQgBSAGEO8DENcBCxcAIABBADYCCCAAIAI2AgQgACABNgIACxMAIAAoAgQiAEEkTwRAIAAQAAsLEwAgACgCACIAQSRPBEAgABAACwsXACAAQQA2AgggAEEANgIEIABBATYCAAsZACAAKAIAIgAoAgAgASAAKAIEKAIkEQIACxkAIAAoAgAiACgCACABIAAoAgQoAiARAgALGQAgACgCACIAKAIAIAEgACgCBCgCMBECAAsPACAAKAIABEAgABCBBQsLGQAgACgCACAAKAIEIAEoAgAgASgCBBCjBAsNACAAIAEgAiADEPMDCxMAIABBEiADEEQgACABIAIQwQILFQEBfyMAQRBrIgEgADoADyABLQAPCxUAIAAQ6AMgAEEANgIcIABCADcCFAsSACAALQAQQQVHBEAgABDQAwsLEAAgAQRAIAAgAUEEELYFCwsTACAALQAEQQJHBEAQjwQQmQQLCxYAIAAgASgCCDYCBCAAIAEoAgA2AgALEAAgACABIAIgAyAEIAUQLAsQACAAIAEgAiADIAQgBRAdCw8AIAAgASACIANBIBDSAwsQACAAIAEQjANB/wFxQQFGCw0AIAAoAgAQhgRBAXMLFAAgACgCACABIAAoAgQoAgwRAgALFAAgAEHAAWoQnwEgAEHAAWoQnwELDwAgABCBBSAAQQxqEIEFCwkAIAAgARDdAQsVACAAQa/+wQBBCkHG8MMAQQsQ0gMLEAAgACACNgIEIAAgATYCAAsRACAAKAIAIAAoAgQgARDJAQsTACAAQRc2AgQgAEH83ckANgIACxEAIABBwAA2AgQgACABNgIACxEAIABBgAE2AgQgACABNgIACxwAIAAoAgBBADoAAEGw7MkAQShB2OzJABC5BAALDwAgACgCACABKAIAEAJFCxEAIAAoAgAgACgCBCABEN8FCw4AIAAgASABIAJqEKcECxEAIAAoAgAgACgCCCABEN8FCxAAIAAoAgAgACgCCCABECgLEAAgASAAKAIAIAAoAgQQLgsRACAAQbcBNgIEIAAgATYCAAsNACAALQAAQQRxQQJ2Cw0AIAAtAABBEHFBBHYLDQAgAC0AAEEgcUEFdgsLACAAIAEgAhDeAQsNACAAQQBByAEQwQQaCw4AIAAQJyAAQQA2AsgBCw0AIAAgAUHAABDyAxoLDgAgACgCACgCACABEAwLDgAgACgCACgCACABEBALDgAgACgCACABIAIQ6AELDAAgACgCABABQQFGCw4AIAAgACgCCCABEK4DCw0AIAAgASACIAMQowQLEgBBi6fKAEEdQcinygAQvAQACw0AIAAoAgAgARBCQQALEgBBo6rKAEERQbSqygAQzgMACwsAIAA1AgAgARB3Cw0AIAAoAgAgASACEEYLKQACfyAAKAIALQAARQRAIAFB2K7KAEEFEC4MAQsgAUHUrsoAQQQQLgsLCgAgACABQSAQfgsMACAAKAIAIAEQpQMLCgAgACABQQEQKgsKACAAIAIgARBcCxUAIAAoAgAiACgCACAAKAIEIAEQKAsLACAAKAIAIAEQcgsKACAAKAIAIAFqCwoAIAAgAiABEF0LDAAgACgCACABEMMFCwwAIAAoAgAgARCNAgsMACAAIAEpAgA3AgALCgAgACABIAIQfgsIACAAaEEDdgsMACAAKAIAQQA6AAALIgEBfyAAEIAEIAAoAgQiAQRAIAAoAgAgAUEMbEEEELYFCwsNAEGQ88kAQRkgARAoCwwAIAAoAgAgARDQAgsMACAAIAEpAgg3AgALDAAgACgCACABEJIDCxwAAn9BACAAKAIAEOUBIgBFDQAaIAAgARCIAQsLDQBBkYnKAEEZIAEQKAsNAEHQjsoAQRkgARAoCw0AQdykygBBGSABECgLGgAgACABQej5ygAoAgAiAEGTASAAGxEAAAALDAAgACgCACABEJUBCwoAIAIgACABEC4LCQAgACABEMcDCwgAIABBoAFqCwkAIAAgARCOAgsJACAAQQA2AgALCQAgACABELMECxkAQdj6ygAtAABBAkYEfxCwAgVByPrKAAsLGQBBgPvKAC0AAEECRgR/EMQBBUHw+soACwscAAJ/QajYygApAwBCAVIEQBB0DAELQbDYygALCwcAIAAQogILCQAgACABELsECwkAIABBADYCAAsGABDCBQALBgAgABBJCwcAIAAQlwULBwAgABDSBAsSAEGMpsoAQS5B2KbKABC8BAALBAAgAQsEAEEACwUAQYAECwQAQQELDABC5K7ChZebpYgRCwwAQrOPmIHv8ID7VwsHAEGY+coACw0AQp2ezqyTrKLEgH8LDQBCxfbN6sGgwvaHfwsNAELl0Iz4nPvoupx/CwwAQpv/8avd9Y2acQsDAAALAwABCwMAAQsLos4KLABBgIDAAAuTvARNaW5pU2VjcmV0S2V5QW5hbG9nb3VzIHRvIGVkMjU1MTkgc2VjcmV0IGtleSBhcyAzMiBieXRlcywgc2VlIFJGQzgwMzIuUHVibGljS2V5QSBSaXN0cmV0dG8gU2Nobm9yciBwdWJsaWMga2V5IHJlcHJlc2VudGVkIGFzIGEgMzItYnl0ZSBSaXN0cmV0dG8gY29tcHJlc3NlZCBwb2ludFNlY3JldEtleUFuIGVkMjU1MTktbGlrZSBleHBhbmRlZCBzZWNyZXQga2V5IGFzIDY0IGJ5dGVzLCBhcyBzcGVjaWZpZWQgaW4gUkZDODAzMi5jYWxsZWQgYFJlc3VsdDo6dW53cmFwKClgIG9uIGFuIGBFcnJgIHZhbHVlAAABAAAAGAAAAAQAAAACAAAAYXNzZXJ0aW9uIGZhaWxlZDogc2VsZi5uZXh0IDwgR0xPQkFMX1NUQUNLX0NBUDw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPl4BEAAeAAAAAgAAAAIAAABzcmMvc3IyNTUxOS5ycwAAjAEQAA4AAAAkAAAABQAAAAMAAAAEAAAABAAAAAQAAACMARAADgAAADUAAAAFAAAAjAEQAA4AAABEAAAABQAAAIwBEAAOAAAAUwAAAAUAAACMARAADgAAAHMAAAAFAAAAc3Vic3RyYXRlAAAAjAEQAA4AAAB1AAAALQAAAIwBEAAOAAAAggAAABoAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvaG1hYy0wLjcuMC9zcmMvbGliLnJzAAAoAhAAUgAAAHYAAAARAAAAKAIQAFIAAAB3AAAAEQAAACgCEABSAAAAgQAAACgAAAAoAhAAUgAAAIEAAAARAAAAKAIQAFIAAACCAAAAHgAAACgCEABSAAAAggAAABEAAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLm5leHQgPCBHTE9CQUxfU1RBQ0tfQ0FQPDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+CgMQAB4AAAACAAAAAgAAAAUAAAAEAAAABAAAAAYAAABTY2hub3JyUmlzdHJldHRvSERLRHNpZ24tYnl0ZXNIREtELW5vbmNlY2hhaW4tY29kZXB1YmxpYy1rZXlIREtELXNjYWxhckhES0QtY2hhaW5jb2Rlc2VjcmV0LWtleUhES0QtaGFyZHI7jPXGkwwA9iXDgXHfCAC2TD4LC/UIADFMpIWTMgUASz2j0/l8CAA+kUDXBTkAAKJz1hcougAAfOb0Jyg+AgA0GsLg0jMBAIGPKfnSTwQAaKp6hwUSAQB51ZNYlXkEAKBnmzBmDQUA7uW+DS3UAgDG8Im2F/EGANdxPJP85wwAQ7K2/kHPAgB2Gn0KHFgHAPAyTVMtFwcA0of6Y8CQBQCo1bRCYKUBAFPRnhXMiQEABK48qt64BQDYtRFP8KoCAJKcZlpZuwYAX3qbpbOoAgB/CO9Zs6sDAK8F28So9QQABULQB6i5BQBQ6hNbrwEHADCX7kyosAUA5FVxyRAdBgAQagnInAUEAE8BqI1gegwADqi54WShBwBl0vyk6B8BAMyqTze4vAcAT03v9FovBQAQjfmYQDEFAL1VdViRqwIAidjQDT+TBgCVQky7hkMEAIxQYjFtywMAxqJyuGhjAgCbK/FqgqIFAJ8J/I65UQMADgWnpL+PBgAbl52VSSoEAP2eRhrlkwMAWB4yEOmABgC/GGgFCgUGAL8yVR/MKgYAJfrJzEGBAgCD5nH0YU0CAFpEx/QzeQIACf92xOn7AwBCSy6Ya68AAOV4ulESrQAAiHzu7a4VBwBTNfbL0PkHACC7pQhEvAIAQlSg3et4CAAiQTUSsf8KACyG9Y3udQsAH24Uz1yUCgC61kekw4IBAPLvNuVkKQIAUwBUH4KSAQBcjnie8fkCALWxPuenVAEAhYIqgfHbAwCXlz+6F/oAACA4nLSc9gYAjYWzDVpNAwC7s5bmqzoEADFxFXfr7gQAQQfxFRkgAQBWnGzanGYJAGw02zLAXgQAwyxqu1ceBQCkjH17tgYAADMp50T6hAAAim9d5U4VAQCQcy6EXUIEABfkGsRkiwMAcUvqAmcyBAC1MGA3NGgAAIDD+RIF7wAAhCVR8qnxAADW8KmRjgsBAL+jTpTQXAoAYk0auHNWBwDUwNEluVAJABNBKdk4PwkAyIOSpr5hBACxITKqmiwHAE33dER3ZwIAhYCy6bBkAADJJzv1TvADADHl0tXt1gEAorO4AchtAwAwXpPUp+AAAH0NzM633gEALN0gTqlTAAD5oMax+6kHAHw+3QRmWQ8ANYsFDlH8DgAMzLKNDGcDAC8zzpnYlwIAzhsGdl6RCADZNJLz7V0HAFQ8H6s2HAAA2vVY7o/wAAA31qATluEAAOAgE0oCqQMAGpGiydn1AQD4/PqUeREHAMWN4sqo2AIAhwwJsrFKBwDE7MLFB2kCAB2cL2MO3QQA2aUiJtHOCgDZQkdh6Y0JANO122+pnAcA7gCa1DfdBgBeUapJVGMDAKtdR9B44QMAEpehEkcLBQCt9A+GwtwCADE98NZ2DQMAx+QGIRdEBACILe2vURIAAFpP7Zv8NAUANFLPOVrYBQBk6BJxaQwBAPLHWIOgKgYAlOFICERvBAAr9ahxt0cEAB3TaTK6dwMAgFD1uvk7CADeX759J8QDAJJM1K81owUAPnWZQBbBAAAj5G8AhwQHAG/WvsphXgIABGZYzCjhAwDix48ui5YFAM9hvdWjSQAA5vYeW1AWAQBuWDSG12YFAL0vWsaFQg0AH3T4zGJeBQBEkLFhuWsMADggcQU0FQkAOnk0X7pPCQA0CMGcn6QHAMYiingTtQIAWznybkv/BQC/B/ZajuwCAMPspbx1OQMA1PeFaRZGBwCa5woAOZkAAHr5ZHlMhAUAPVv54Rc2AQDFP6jOKUgBAKXscU4vCwcAPGT8jhQoBwB2W5kDPnUIAGZnq7Jfvw0A1jVFvMNfCADCld2XhHsDAOj/tNZJFQYAONGxLaIXAgCesC4Gz7kAAFj35XGc/QIA3d6vUq6zAACX5Blmp50BAI5V0lQG+gYA1EFe0hmCBwBRxnV0dnMDAJBlJBTLlQgAZ6ymKtgCCABQSLyD8UIMAEMGChxPRgYABwlzBVm/BgDZrdFA/ZkCAPflBJre8gUAWRzMuu7ABwAKKfixocwEAI+xw1bq+wEAiltB4fF4BwD0we90WPcGAH8CGUBpigIATdxrqTcrBQA1pmfPISUAANFeL3cgZwQAItZZ88AyBgBS4qMrCbICAIAmEXwlYg4A1XyfPXUBCACUUp0KC+4HACfKTOv7gQMAnWM+Oh+EBwBfRMMw6nYGAIIT56cA+gMANNs9li0jAQCNBwvnklYDAB96dxTKRwIA0Pzoa1XbBgCOBPriXysBAJIeb60mfAsA5HsicQlqBABMmy0NL3IEADrgTiBG3AMAbHkgPOn3BgBN4/yWxPsAAD6ufWu+dQUACebOhRWjBAD/MDkC6TcAABL7lm+3SQcABa6mrgT2AgDrI5OT3DcGAEeNBJut/QMA91oE1LCoAAACHvAQ7PwAAEVOJMSd0gIAvkfBG3uSBgA5CKw0hTAIAEA/A2Q2hQQAq/5mkXcTBABEHv5JplgFAInM7641RgQAuvKHSEP/AQBELQ4igfkAAFE8GKcakAQA8PgajFS3AQAWgTZTjIQHAOk9OOdkGwAAj3xYsPsJAQDRJreHuBsEAJuRZnxZTAsAww+ZtlChBwB0IpKd6ysFABqGZHHtDgcAqcZw4HGoCAC+RkN0RH0AAB2oZKW2ggIAayN1+IDtBABQDEUdvvsGANv8Eoxy6wQAiYm8S5m1AQBgBkyoe0sHALiuzfF4VgcADPHWsAYyAgBdaPIAc+4DABh1HoRHeQoAfujaiHMsCwDoG5fTrRQEAPEOL4NQGAgAiPssanzUBwC31n2e5FUCALqe1WMhjAMARVgAKh+GAwDJrstMHuECABJ5KXYVOAEA4NbwjhTQAgD7h+eNKlIDANL5dF4F7gIAEwgx9jhABgCeTNNYz0gBAFp15Jp9LwcASvwPaR5xDwAVDVs1ooINALO2hejP3AgA6erUuv54CgAn8DR59pIEANQoVYHQ3gcAEmYaUWGEBQBEFd5QLuoFANvV66Ev/wMAZjmTjB9oAgA1FpMhBYQDAFKGMErxdAYAkEipiJy9AwDG6S/QTRAEAKVqCdsGTgkAI7DmiZwhCQDaoobUq3gKAB+VYJKyQAoAye9IWlsWCAAqQiQRXr8CAFauVmcUcwYAMOiHmtlKAQD9gLBlyuoBAPX6CrBjyAIAdmqEoHSkAAAyHpjvpZkAAOa/SzyuqAIALIMUrzRcBADs/5t9tpEFAF21GJ9xswkANtODjDFUBwCXl5G3F3wKAGCbCISwRQkAAANn+LSJBAD6m7SAHA0HACVGkX1+1QMAReVlIXLAAwBP4Bk4ueUFAPeofOwC3gMA75LrOi0QAgBGOgzVIowGAE6JhZOoLgQAjPNVv55fBwDLlqS7X58EABtXnB6MYgUAqyLoCLGYBQAaNimuj10FACh7qdHIrQgAdIYobBpqCADUz1uKEJoEABJmfY6MFwYAdQNxczTwAQCYYEphSToHAKa/3IZKYAUAtmQXfNTRAABRLmoxCBwAAEVQyUXbswIADDCNgU9jAQB04p/oiQkCABvs6oWLJwwAzeJ7ZVnvCABvh1hp0S8PAC8LJgWy6QoAWHAPlbkwDwB/zC06/XcHADJJEvuplAUA8BXKgI4fAABpMuw80RQHAGfK0NE+QAAAUsVOhzUtAwApufGNBPMBACObFzvXAAMAC32j5XvmBgADgzBUdL0FACp55xUhkwwAtzC5u7lXBAAmMhmLXY8GAFbUHo9OFgQAfwYjsX27BQDCTLIoldECAPMvMLhmrAQAUa392cgBBwAnN1tcs8EGAAo4B4CnMwEAvmLKxmf0AQAswV0qI8QCAIewE8AdVQcAzTuwEQxpAAAOj9Wm3EAHADxDeARXjAIAY6RzKFDYAQCc1N5+HmQHAHH1TNXt7AEAsMJWUj/AAgBOzs9SB+4AAOn7FoHdYAYA6/8PE2dRBQBclYW4gsYBAOpjqV/SYQEAfaRTe3UYBwAhLw+L4RkGAATsweTf+wUAkrseyJjXBQBr2duLRpkGADUZqWrmPQ0AGptZGvhFCACSQSG9qPcLABkzEqRNHQcAosTmxOGTCgDP/tr0Ri8HAKP33vqPlAIABLzz/c0eAQAl7f6P6cIDAAU5R5ohJQUA4RJRkksTBgDtBrQrlLsGAOLdwEXEcAAAo9fEItgRBAAy8EfEBbYFADnw5/DG/gkAfEcsabzOAwBeqRlqmHcIAA6Ld6Gq6gYAq8VM7y/xCgCJfMQgWYAFACyX+XFHkgEAQMCf372LAwCBspIAAPcBAOuK6tx2SgIAQMfA37IiBQBI4YA0GegHALlBQ6DZPwMAvCCKZ2PIAwBDilGyB+YFAAHPlqUcQwwABBSAfNoVCAC0EI9vmzwIABZAkyJpNAgAVuQ5MfMBCgAYGN9sjx0DABZLFEts+AEAnT7XuHWYAwCzp//Z8PsCAN3Mtsp6BgUAUZ0DCGt/AgCq3wCAL4AEACXFYqCSlgAAF1gHkeq6AQBgJIaoy5cDAOd5E8j7wwUAAi9eJbwbBABQhplW96MOAEF84NR/KQkAGx4sArRxBwCyWVnwkzABABjGLi81vQEAhuqIm3h1AAC5SOoXER0GAOZmBzKdMwIApy86UYbZBQAPG+GZOj8GAG2y1s8OigIAj43hNWg7BQBxmSGJoTEDAJxydZ06LwkAycRT6QANCQCJL28R3wMGAIjg4HbCPQMAmmT/GZasCQDGgE/7RW8GAKL+ue44zAMAH9twcmQHAQDIDXTq8RAHAN87uMZnEQMAaBBLUkI4AwBF/jCd030HANCgQSFDiQEAJcK4Tv6IAACL8EFjQxIGACUmLRrjSQMAbLGmf3oTCADbfneSroEOAFDc+MW/IgIAkI0XoypSCQCNiU6H20EFADMbhPuALQYAl/on8G4+AADoM5aePKAHAO/lCSO+bgQAOElhaVMvAACHBaKt5VYDAAL5a5/IGwEA28gZZHQ2AABDUlAP518EAH4UlcggSQoAXUyUYewHCQAewBfgUicHAHrpot23IgkAoVfb9hlmCQCMCwyWpnUAAEkb5MXh3QYAQaNtUT8uBACe56j9A2oBADkOOmLRKAQA/QijAURKBwAJgVW51G4AAGeIoPbxRgcAISNvXG9jBADTC9aSFdgBANXFhXuftg0A61BWFy16CQCdwb9tPswEAA6+czgdPgcA+Aob1falCwBfrA2mVocGACbsint1XQUAvYBf9D04AwCmlp+MP3gGAM2eeKc0AgIAUrJ4cbYNAgDaDizaozoHANNwHMBFkAcAWRAlFXuzAQD+z1MjaM0HAOD0rGhgzQUAzHR6/JoHCwCzZAtll4AFAJlOnKyrfwQAzbKyUwLvCwC2+ofYW6QBAHzBbQdIVwYAqBGqAIC5BQB0CQjJ7KEEAMC9Y4iMgwIAMFBGSs+wAwAtevWuuCIAAK0l6XcGrQIAekXXZ0EJBACCamCKyx0CALoxd776AA0AUDMRw1PMBwCBDQj+Zc8HAKEbAWbZxQMA9sb220DYBQDIn52MRgQAAIxreVSF2gUAJQCVcL64AwAJpqYtidUGADFKGQg9vAAAi+GfMA04BgAN7rgsPNcEALbAuq2CuAYAvkzd3atuAwAZrDJiJ6QDALh+RNtywQgAfqe3BcX4AwAQP3/5V6gGADrgf1bA/AwAGU6Cngx3CAD6hHCKLEMCAGipqDz3ewQAZygmdpFjAQDOEIBP3+gFAN4W6nwX/wEA/bW1RZrZAQDsmSRPZyMFABMmGCb6+AAAmIwEmHOPBQAAFdRPJp8DAM57Cf6rSgsAMjolA/w7DADyt5H+x5sCABZKhORhpwgAXsNyEmJcDgCc4ufbFzQFAPWUc4JzRQUA3VD2pu5lBQBJx410UCAEAImIRnMtcQEA3ZMxzviJAwDlfBe4JNQCAM1ANA36cwAAl57UDAI5AQDOGasAmC8CAJn9bprdnwoAPygoqZTGBwA6S+TuzfcGAMNcsgcyWgUAjFk4TRoXDADL+J4+ijYCAAus4giqVAQAAKePP5KQBAAvWKSeqnIDAGJH1mxBPwEAjEzJmapYBwBE/wAXAPYFAL0BjEhOaQcA1u5I6f3VAAC9dKVPIQgFAMMD0FO7FQoAwqgseZ4XCQChQMhq6aABALY6u+KTIwoAyoZMinWnCwBL/tY+FWkCAECY+K4jKgcAnGmZUr5SAAAWIxPv5aUDALr6xg6WLwIAdlCuk/YRAQCQypSqv+MDAIe4dpR5RQQAeUhGEglKAgB/3vgV/dkFAAtS1+4qTQQA5KfC0mUIBQBA6jhSW3AKAJY7XbJwbAwAuH6kfxi8CwB/cmNt0wgEAGJgpvb4+gUAa96oLYm7AgDm4sfw1GkHAPv4FFnzMgMADMKG6hUBBwCorSTaiG0BAN8qZiIGmAEAnVoZvOsBBQD7Bukc2FAEAD90rhyW2AQADrp9jMO9BgBjtOGntNMHAPOt4t5LhAgAqmOWJ63LBAB1UiCmobYDAM9t0JEn6AIAhzypynI9AgD0qmirt/AFAEVjutQl3gIAzR/XoCSQAQAaEF8RZV8BAAiXFGeQ6QQAr6XL0dgZAQAHIP7O+9cHAJSQwvPFXQwArnm1IFJFCwCJBh5jwXAIACCbDmPAawoAjM1tGc35BAABKGsmah4HAF3f4nOumgAAo7EZstgNBAAN3hdF+0YFAHV76DVUlwUAaDd7atiXAgAyY0wvWoMEAGBBQ18wcAAArlZOAd2DAQCgh0MI3cwHAIDMYGcYhAQAYTNTZVZDBwABuDZjaC8IADBD9kZUIg0ACxlIqDxZCwAXBCZtLEIGAJS7F0iQEgIA9VS43hmjBQB92mDg1KkHAAwd1g69KAQAp5qEXpoYAwBCslkfu6wGAAxjU0fv9gcAqS0qKUbzAQDWoo0wmHMCAFMkcApMDgkAM9d7o6/aBABhiT7ca58MAOXa7Nz//gEAw5JUlMJyBQAT1F5DKI0DAFgomRlPBgQAzUP1vg9oBwA8jdWD3aoBAMPo63pZaQIAvjDN1kXHBwDveN9Vd3wCAKN/kzNodwEAVRhEFlFABQC8BYxJhfkHAFBjvw9SFQ4Aadp0v+m5CABoESAIg/4MAELeJ2H3cwkAsGnNUyYPCwAX4QufiM4BAAkHUZRqbwMAtBYAckjyBwCRz+HRHoIBAB+jcMQubAcAhQzBqjjJAABBcXntZBsEAG1eGMGxvgEABw9gkFTtAQBHlhU/J/ECAMALp1XXiwgACOZciDqeBADWWhuIhWUJAF1P02h1wgMAX9x+mcGKAwARHuCKfPwBAOfoc1VNCQIA0kn1uzzKBQBDQcXsIPkEALaFrXLl2QUAO7FRpxe1BgDMgLFw088AABr00SV5NwUAoghgVlZOAwCe/svZ/C0CAI7gOxC0WQQA3SotP0uaBQDrjrvINNcHAAlKWb48OQIA3kyCd5j+CADZDA3D4NIDALtxZmiX9QMAmTm2fliqAAAZxpK1x+MAAIxEBWyRsgYAO5G6CtE0AwDbz4G1zUUAADaPOlXg4wUAsv8eBLMLBQAA/wfzA8MEAO1E2Q1YAwQAP2WSffeNDADpSbPjn4oDAOGvCoWJ6ggAaXCrUbEWDACFjLIX1jsCAGFafecu5wYA3k0X/3KpAQAPxnNjY+IDAKuyeI8b1gAAsDbB6e/XAADVCmSJHKsBAJcf9K6CXwUADe0X81dpBAB+J3SvopEBAOgORk9DKw4A+9P6wMaUAgAPTHuTaIMGAFuHECn4yQUARQXg2+c3CgAxFDzFS/cGAMLZu10OxAEAl1yunPvIBgDat+FcXIQEAMy1UOTg4gcAMLQBZ+11BQAmAKJ/4dMEAFNCjIj8kQcAwYoHmbrxAgAVEZtp+hoHAMNQO0ccPAIASB3iHWfnAwDooUdV+iYDANmvX8JNDg0AiI/H+zEHCAAdtlM5m28GALnMPCj0VQUA52AZ+2fdBwDU/q+hB0cBABwrnC4UIQAAgBj4SBjHAACGPCPY2UsEADBY/o5X6AYAtUFwbVsEBAAVfjTz1sQEAF0Zj5j83QQA4WWjPhf2BACIRa752kUOADpi22M31AcA+YgKUPmLCwDJH33Bz+wHAB6DggcoygQA1texfTO4BwD7lTjvbREFAEd+qtr9kwEAb4foNzzJAgD6g8UoGkMDAHnYi9pJkAQAHMF6QKi0BADU8OuZ+6YGAMYj5La1IgkA1d3x31AeCgC/dU4ydj0HAI5BlVRIiAUAXiz0qf02AQDrVQhWu8EGAEitE34SHwcA7FqQBLPGBQDHm4iOa3UDAIkxSpF2XwcA0b0Fo7HfBAApH4EF/7MDAC7ZPChi7QYA4VLsQxVdBgCNvhA1GCIAAGx6MEMBcQIAq/OLtI/YAwB6j8FO60kKAF4p/10RNgkAA9QfRHw4CQAULa1eOGYHAF4JBotPGQAAYjuC9niEAAAIc9OJhgEGAAa4F85xoAYA+IqXh9HDAwC6doLI4a8HAGityIHyHQUAXSSkvQZJBgDt8aomGxcDANFHirLYtw0AwDSeFO7CAgBT/Jpi9XYHAKlJ/FDq9AEAJEQzphTFBgCoTFaXkDEHACU1I7xOhAEA4e79Q0UdAgDSG/+qJ60BAAjPc0j9IQIAQWMVOk8gAgBkpGVAQTcFAIPP7TsMPAQAIKZucH5VBQAkuW9Zqo0EAICXTMhdHQYAnsJAMOh9BADnB2Wy3okJAJlH3Prm1AQAp+igf4OMDQDHnKVcZo4CANkNlBXHZQEAlRyhOl94AABphOPXmHsFAIStzG/ddgYAWJD8loVoAQCfYQPUam8GAO9yd6hZ1wQApL5zYW6FBwBXaiw/98QBAIQ0fPxucAYAbTbsOXiYBgAmf8+VH3MAALzkvI51rgsA9dq3rVkEBwC7oF8wvU8CAM+hdcyYCgQAM3UKIuGMBwCXweEQeiEGAGS/0YCslQcAsyu0kUnbAQByQ5lbYGkEAFiaXHHjMQYAj3LP78/pBwAhzkgoFv4FAPWxfF0thQEAD+Vcvg8NBgB1e+NG4qEFAJDV/wXuGg0A2Xc2BEy0CgAalpThTyEBAMvpqTmu4QAA9/kmtchDBQAd6WeASRkBABfJb0SdeAQAjrdOB6uHBABD44xeO9MBAEYb659BPgEApOZdVh9yAgCau/LuUgwGABFtrnzCxQsABG6VkZRqCwClHRPJuiQJAFwrIN73tgsAZZuNJHcNBwDxi/07vIkFAGtBo2o++QYASK7B1qPABABqWAsmh1UFAPzMEsPJCwEAW6DCPkvoAgBRFTzwop0GAHumYUYXOgIAOPKJorwJAgBvlzq9VTcGALes8ZcYEAcAuAd7tyzYCwD0aXc9CIQGAAfOLUcoKw0AUXxzUTd2AgBTCNEqPqAHAKs2rcbcEwIA1r3VQOKmAQDf/vj8T8IHABa8SBzM2AAAqRm0btMCBABSoBSM9s4HADnRwlsl8QAAahgx1OdzAwAWrafYLQwHAAB+7bh9lgQAOlIv0O5aCQC7lNCRlRQGAAZwwQTycgYAU2qBE4YrCwAO7G+fUJQBAKysMcrYKAUA+rm4c22CBwCz+eCZy0oCAEg5Nsb64AIAZM1I5L73BwA8D9oQD+EEAOkgq7lskwMA0GzqT/ygBwCkNccVkhcEACHNayi5Mw4AlJzburPKDgD5vd9+OE4HANkPisUTQwkAGyRiVqgfCwAq7dzX55QAAI4RjnP6aAAAK+5fCmQbBADUGfCdcLsGAJnNMEo0AAcA9CI2LkJsAgDwtQVqBvMAAKaABI9E4gQAlfDb4M1EAgBSmSoxsksCAFhc+PUqDAgAPojyTJ9gCAASyqG1bugGANHM76JEiw4AtP6fr9LRCADDZ94yF+0AADUWKWnDCAMAUNLySPM+AwC7oaFeRwQAAIjhcejj/gAA3x5iMqGKAgA7Na9MJCsEAIrgwkwGawYA070MAiC7BgAxhXF5zWoBAK22h3jFxgkAKlnXH/KrDQB5hlMS1AsFAFExJ3ELgAsAYIGxNO1kAQA9HZstr3IHAFtOi0SG1AYAqBiN3VjOAgCLPFBnn4QBAAKTa+/gIwEAmuYvGUzZBgAPaaIiUkcFALO4hp14kwYA3Gn7vcP1AQA/B2H8oI0HAIE6DGjxgAcAU9T8PF2jCgD33cfN5QUIACOseICI7gYAOGsxS6pUCABqxivlKF0BAH7LUQMeDgMAjB+xdC8KAwAD3tcMEp0DALFWsu5d0gIAuHwmGY1GAAD5+7Wp3IwDAOKhLFywuwEAM5WOdRWwAwDat2oKYTQBABX10XfnZQoApDkeTPXxCABFJlKVG/ACAG3endvY/QQAzJe6jIdUBgD+sPaNx44DACJqo76uPAEAal9O5cbrBQC4Dj2QBCgDAA2yotsvEAIAoeZcBQXkBgDTMqU1SgIFAJ3y2lSQ9gEA1Yt6DR1dAQDLnrJdcq0AAIVvBZsMvAcA2P/6v/4cBQBJ9U3pu0oMACAx49e77AcAmSMw9XX2BABXJE6DsWcCAIi7eMMZrgYAEtXZXntFBwD7BT14DSgDAAMat//8rgQAHhcVBDY2BQBleAcJMzECALyvNENEUQIA6FY3hcOwAgCGKiq3y7wAAJYS/lBMXg0ADMPvE91fCADt5YDDxsAJAKdi++Md4QMA8wiR1o9nBgDIqbHqL5YGAAujuY+irAYAmJ8byrdtBQDdGHBJWJ8DAGudtQpPAgQAwmNoYzH6BgCwQn6m5QoBADHaH/C7egIAvE/muaeAAwDU6gghLtQCAIB1Uw8NewkALYTJwGNiCQCjOUV+gqsEADrXQ9sNNwYAI7R5Or8gDACb0t+UFRMFAP5SjeknpgMAYVaFQUAVAQCEg5/QdZEBAC2Ni2CydgYARytbHGW6AAAnEHBjI4YFANvGGcLWxAAA3liG/z3wAADPwKn/0kUHAFdO0yFX3wYABgx6di/zBAAgbsfqq9UJAOPhBOHpHAwA28FUvhVuCAC9yMkrHloCAOo3sPPIBAEAmGypb1cFBABvh+OIaugCAM9guc4jrgEASpkyGYddAgBuC1Y71rkGAHLUyBQo3wIA7aQK4r77AADseBKG7Y0FAJXJwraoWwMAv4Uxi6XeCQC9uyPNVbQEAPiDSMAZ7AUA1TG1lqaLCABcxWbykzcHAAI7yamIuQAA2yUjow6bAABefMFxrnwDAF9Ihd45/wIAesXvw+4+BQD9LgLpn/oCAFSBEyzHmQYA+B+9HnUqBwDPR0k7YyABAPcPEklHMQUAV9DA982vBQDtjXgb56kHAIgMO49w7wUAk7M8vjN0CABCAGGReJgEAHIBXX+dnQcAxJ47AZPCAwDKyjlfuMIAAFlNm6kwXQMA9JfpXMBEAQDvfzSKC5YEAPd0XfER2gEArf7AGaxPBQBtr+ftc9gCAG75XU7hAgoAS7U+vALqAgBkNYiydYgDAN3pOlGMKQkA/xWgGDZUCAAJNDdDZDECAK8iO1CV3gUA3+LqGyCZBgB6c/9JWNsDAPoHR2Vz5wIAwSNMl/S9AgC9YdLIubMEACi8qbLoagIAUVwWEIIGAwB50GIzRLEEALicUhzpVAQAz3K/xphMCgCZ2MOUZUgIADv616MTrgcAZq+OQThwCQB6H262x7cEAJjZ74WhvgQA+FUQcbz6BAA4/jZ4n/sBAKYtdUb0ggUA5EwyINN7AQDGmHgRiRQFAAtBoJJNaAEAp8V4D9nkBgAo2rzEocIAADJpvWlIgQQAuF2kkcO3BwBBtjWsFnMFAGoJ6R3jQQYATTEKs6mmDQBHBB9v0McFAEk6C/hw2wcAeJrIPkrLBgB9OYGt6DsEAGRvHL1YxQcAPUaW0yQVBAAdGp5Ea1gBAIrtSpB+8QIAjjwdhtLhBwC6r6BcSkAAAL5vQSobngwAVmwxC2ocDQDbG9eepXUNAB3sHxoCTAcAjn9uUSeVCwDWQ6cKB0AHAIMR3ctkawEAQ+sye0s/AgCzNYKlqxkDANmt3L+VYwQAnJpdGi3bBwAvQoULIJoHABbdcaq/VQMAqnhf6ncLAAAtgp6ieWUHAN80tFITtQQAZyYc0HsyCQCgyGA71zQEALpDlKja4AsAdqKyS1EsCAAXKsBJfo4GALbobzSVVwQARjWPbDCJAAD2iC9rn9gGAFvgyU04OgQARbbxi9rVAwAJbWqp1t4HAE0v7k9JwwYA1GuLnJgsAABIFZYgCRYBALpNmzYWVggARm+shqvsDACxANeFAMYLAOn8DeE+IQgAbR5J1zf2CgCqz9opaRYFAIn2MWuCkAEAfUppZ1X1BAAi5bH39AUHAJhWvCXhUQMAvnv2GkabBACWOixxFVkHAA0MWO9nmgYA/M9w7zhNBQDifG7QgvEHAA91IY5ySwUAKAEbl5CaBgCjY6nyQBoNAL6mEqzpCwkAxEEyBMxKDADsaAGrZI4EAE9vqLi9ogIAKWktazs0BwCj6YyqBNgBAOlDw8hKfQYAd1d6T7trBQCPI3xiMJICAPvXLBIarQUAZONQbqXeAADXKjHI0VYFAA7oG7FWZwgAPbB7fhRiDADfvz50GWUKALQqaFn8ggcAx8iM46uXCACCOY0M40AHAP2CRn+0wgcAHNzHuJHNBQCD5fmQp38HACTY0cbGRgcApC2lfofJAQCJYaiDe7MCAKUNMUmvMwcA+wQcFoFeAgDovjRK4XcFACvXTb2+zgYAnzJC5MFACwA+qdH/RyMDAOC7LCWJSgEACbCPSzAFBwAKO6dhrGgCABy+vjTyBgIA6OvLpwO0BQA1QZ/wYKEHAHj9lu6nDwYAxm4pTTUdBQDHFjum9csHABQMz7ML9QIAWsbKhbP+AQA1FsrgmBMCAO5Vt7T5qggA8kSutZFrAgDIsXqNgN4GALAwVWdppwYA95hOKPu7CQDzMys4igUFAD6RFhipdQEA6Ipruc32BADSgdrJR3MBACNa2dk+qgUAYWXZx+l3BwCszAbwWI4CAEmsLLu7QQUA7EyZgjLmAwCV6OUUfqAEAJukd8TNWAsAgOQC/ojMCwBq4/S3qiEHAFOZRsmMQAgA+UrYrvcKBQCZ+Q2YyxIEANwp7tiN5wUAXVeM9t9xAQBJ7/bSXQECABPTkcO68AMA5Vv2FQHeBwDJTTYhLCQEAJhgpmRbtwYAhcACATwDAAC9rmsxGpIBAIvB89marQoA6pozOBbsBQA7qFllO3AFABLWBU2f+gsAKwbK3kmwBwD8cLjffi8CACixd9buaQUAr6Ww3DcJAwAb6nicA1gHADonHvSNRQYAg0RENXrjAwCZe9K3/WEGAOQh1h12FwMAiWECMDwyBwBQKbzMPQkGAEsDhGC+7gYAe40K9wHPBgAKZ8ZUGrQIANpVu5lLyAYAR7aYDBjjBgBtcOCFhZoDAP5jJud8FgMAl0Lb7BQ9BgC4cPncIb4EAHqChKAefQUAcbAooee2AgDPXXURdbIFAGUFk8KEhQAAWUFv2nuMBgB72d2Z6WMDALOuS+LcSAAA4wXslVe3AgDJbdrFpL8LAB03nmXIqgkAmm+8efkxCgDEH+41wUMAANXyGZkcoQIAzbpdwkwzBgDaALQX2pUCAKCThrfpjgQAxvMqzEveAQCG66MRxB8GAMAuwZrRPgUA4AS4xtsJAgCSh7Cpv3kAADJC1aKA7QkAeF4qx/4OBwAtgirUUSEEAOgx1rbrtQkABUdZsU/vCQD0DTDaUToAAHIcViu1ZwQAkOUQApLVBACFlniedsoAABdIaH/HOAAA7HsWW+ZeBgCpULgZ2lIAAClkZWWGQAAATJpvWTmrBwC/oKSS7nUFAO7XpApFvAYAqAs7d6b0DABHvA4LGyQGABWTHU+cDQwA9ILj56EACgDPLxiKkIAAAJi6txMpUwAAw4XDeM/cAwCpq17dAoAGAD/NEnFOPQQAxTr56me5BQAxCljKrGADAGLyxtVfxgEAq+zCFX8cBwDkUSal7FAAAOpo5mB2OQwA9PKSVqfCBwDvZmx+nrILAJnavFimKwcAGhP6CRwVBgCcDD9F3hoDAGh4cwfu3wMAEdSn9+wRBgD2ZL1sfmMCAI/FIWzusAQAll3w/Q1cBQBeR8+dVgUEALuYdCdcXAAAicNd2YiFAQDwAKhP8v4BAHNrlzD1rwoAWYTASFrYCADfQjaW65YHACa2xFDuCwYAQINs/gWACgCWMaca+1MGAPoGg+z6BwYAVFI+yF7oBAD9hAWQVp8AAIb8kpLURAUAiIZSNJ+6BwBdLbQPooQCAP5vcNksZQMAs+bdrXv9BgAW8zApRy4HABR2KtM19gsA/QDerOzLCAA1qepBEUEDAJTL80IeHAIABv4A8Of+CQBPCIGXjCAFANIk3KFoZAEAqEDFCni/BwABU9fOfqYBADpzwujSqQUA5ffbA9oFAwDKrreZhiIBAMlrk7IjKgEA6eZqpb2hAgBA4B4FlA8AAECXrwe7kwcA/frU7LbnCQBC+2AVeywIALZfzDRnKQoAP90l/X97DACyMNPDI2sFAKbRYOMIdgMALnLI8+AKAQA3thi22YYAAKu+6Md5fQAAEt0IvJz7AwD/cFPYPVwHAKwZKP4GfwQA7RWSqwbbBQBk6jUKUsMBAEbAayFAbwgAtNkPm1eiCwCL7H5AJhwHAAtPtUraKgcAEm22w1CHCwBKo8u8plMCABpwMwQHJwQADof5WI4LAgDMANthyDcDAO7QdVfQwwEAGuUilEDxBgAlLc6+a4UHABwDL6eAMwEAuvOngBA+BAAEM30sHmIAAPPw27CWFwYA9dYynC88DwC9flPRjqoGAPQ4GMmSTgcAAhDKieXYBQCNg1mCzGAAAPOVW/PTOAAAI6lDwnhgBQCyGySTMt4CADq9l2B9AAAAS6lCCJUdBwAX2MflEWsEAA1Py76LRwUAXRwKSwXDBwDLwYN3PVgBAMconcwERwMAAPKxmOXeAwCebXSYHG4BAN+vlXALBQQAVTzoZICVBADheqJd76IGAJ2dLuCsigIA6PBl6VkkAAAzCRXTZLgHANge6PKlUgIADehmUCaUAAClYY2RD6YAAN4P8/dLRAAABjztqQ3EAQA7hL1wwXkAAFbQ1cBQzQ4AuXnnamC3BQCh3WsivQ8HAPkfOVMeZgUAuBdzDYx2BgD/b/pk5OwGAKBgpLxAzAMADI37CqnjBgAoEqG8GoAFAJ+sNF7A3gYAs8FV8eUlBgCWMnJvL/MEAM7vBQGYrAUANu5eFmF6AQDV3E3hRRQFAEKkviurRwEAJjEl8kDyCQCITjGe3sMIAF6k/KSlHgoA/OSGAJkuCQBRSRQ7SysAAOpqlneJaAUA/Z85bheOAQCLk7ReXOQCACk5HvOGMQEALrvff7OWBAAhPl+dQ8IDAE1qfv5gbgEAHWKbiO/XBADp0wU/LnsHAJGw3RKcYwgAsnrNkAQYDgB7RpeCkfMDAKyBF75oRQcAleBSURl6CADexC6cxakHAC1leZ7w6QcAhi3yIuSjBgCLbIM7jq4CADKtx195OwYAyF+eOAKPBgAGdYe88VkAAOwMQQ6ZBAUA4q7+0NebAADwMtCD/ugDACnR7+iNTAgADSHmBnzGCQBpFH+PN4MBAInSrs5SQwYAWGKaiWAtCgCUonAFuRUDAPElqQjhDAYACclTEvbvBgCwcC0O7wMAAMT6l7ejWwcAltHNcMDbAQBHTFOxj20BACr6g4FJAAUAdd4jxFkvBwB5d7gHTZAAALlA+UhmLQIAhj6HoaWXCQC7VBrE5AcKAM/WSzsLNgUAcq/rrAokBgCckbrd1B8GAJlWtZHp2AcAbMc8RzEbBgDWMeYxlgMHAN3B+0MhPgQAoJWiW5x0BAAGX0v6RnkDAPFRWqvFJAcA89OdeDNWBgBA2zjy2msFAJ87ncFs0wgAYSLXcETsBgCuqRhwPYUGAOvIwk0+qgMA5eEHFaM6CADrMzX147kCAMUGqCfXrQIAoxXOyFVpBQAOKQoHT4wBAEE32IZK0gEAH87U/0h2BACdnoORlQoGAKsXgfPVJAQADsESacQsBAC0rskdJjsEAFETlWyLPQkAKWOPfgHABADE+VOeVT4FAOpuiEYBsgwAPykkXk0rCAC7ebuIGR4DAKu8s0YvuAcAQXuCzqj3AAAwcRcWWOEFAHay9VwFJgMA8o3RKMtVAQCUFqGcDcMAABkxqycOCQIAtkl6TmIIAgDT5ZqAbHoCAEFpPcQKJwQApVlW2UztAgD5KHWzDVwPADOSLP28zAIAwtgDNlAhCgCIsQ0fzesGAHQRfUvrTAcAXE/faGHVBwCK0W8Xeb8AAAr2TxdnywIA0OELOfnNBgA9K36cUY4AAIEIpdLDUwIAPTOOREEbAgAPiXNL37EHAIz1+AcYIgYA5Ys6gZL6AwByVY3DmNoGAI9GVFXZHggALTVdJJiGBgAkorKz4PICAJIcLKJqxQAAeLLxOez9BQAG8cf1CskEAMWPZfLOHwYAehgYKoVdAQB2+5q123ACAKuSzwsS2wcAh0BxXaLnAADw2nPE9GwEAC2BSfGnbgQAJ4QKaSUHDwD6efDpOqcIACrGYUSS3QIAzNhQrloGCQD55cSe7SUFAExoYAbSIgAAaHs5cCuXBwBl+dNYOaAHALVO0byHkwIAVw0g3yVFBACFQ+lM+dcCALfscMEADQYA8NjzAwWLAwDO8WSOGZoGAO3Kxdw0RAkAH3xmn5DHCgB1tR+dgxoGAHa7ygA48gwAfia9lyZbAgC8eBrZ4LICAAzyzBIKmQMAIiYf4cJBAQAgM6X6zt8AADpJkmqeNgcAZGiYE/s/BwCsE/e4KygDAO+X8njtnAQA7x1mJ3BpBgDkVNuDBkIBANBazMFvuwYAnWaR1cgyDQAybKhNea8JANIkbdjp4AgABx0WtIMeAwCX0Z0kHr0AAI9WIBjLCwAA1DCIcbHqAgDml2mB/ZYDAIpQv75jCwYATysGnhLHAAD9EltBJuUBAD2SJ/2gYQQAt6Vw9q2LAQBQ1WLr8VwFAD+M9X3jtQ4ADcaGOfO8CwDm6lyDuE8MAKNxjsHemQgAnyumum+lCQBYPcJlEBABAA+LM5ASqgUAIXQunn4VAwCJ1BcgceoAAIlwRVamaQYA7MmdXFBrBgCHUuOG73QHAF6VwETZ0QQAICvXOUwuBQBYnHk2SDwBAIDQi11q+wQAm1gISeOKDQASr3uXTZUDANxBdFnqEwQAW47ch9wLBQC54bNaRl0CAEco7Cf++AAABk/w2+bWAgB2Mhv8jAMDAHtjOsmAbwYAEeHfboM3BQANLHs1Ar4CAPjUyFju3AYAkmEdWDLXAgD9JUdEVt0BAIfIuggA5gcAUhh8OFw9CgCnM/XxXZ4HAM/wxfH55goALzr2UKSjCwB9EmIz+H8EAPSxgq85jgAAq33yLjKIBACkoaI4N5cBAPcZIpFF5gAAJ0Y52DEvBwDxAKKU0nsAAMZ04gC+ZQYAiza28eg9BACaOjnZyBgDAIXTHaspngYArGvHs4UGAwBZSPI3z2UFAPn+jsIqew0AT1kyHKQJDQAZ/v8qA10EAE7ebJvkLwEA8XwyvGMWAgDd8WlMXooBANWhecbHJAIA6SX5ptxuAAC4d+Zjg4wGAM/75CX6DAYATkAJdsHEAQARijIC/1sAAOQSxQ3doAkAD81fv5QICQA2nD8BSSkFAMc1R7oP9QkAGeDefCd2BQAL4MojcBMCAMYm65k1WgEAPCtRIXJoAADpJAg6y1MCAKSiP8y4gAcAXzBPI7yKAwDeA8G7gKIHAP5daTaomAMAGopSQa/QAwAbJyaHQf8FAC2VthPoRwsAujwcwmRoBwCodM3bSeAJAJt0kw/WtAUADArKuE2dCgCd24kXDAgGADGnHu98vgQAgICddg30AgADpkRMfV8DAJZawj2gBgEA0FMzM68KBQA1uzxhmrUEAHaa4cDfIwIAZMWyKx59BwDLUhClOKsEAInA3V/v0QcA2dq56+q+BwD7rKAL01gIAI+uteqSzQUA0k6waxwECwCT1WhnJSsEAE97QlmE6AIAAQdjdjgrAADl6gXUeEgDAIoI3BrdnAIASOFW2fnyAgD+wWWt5rMGAF2et3IJsAUAr11MI409BQBJQIHWuwQBAFDxf9Zfmg0AKjXQ6pipCwCZr6RfyYMIAG4mAfzb+g4AcbAPovIECgBn7fFoMf0AAD5KeOcNuwEAdwSyeMtLAwCCIS5uoqQAAKeScMWMvgUAebDrMD07BAACGcalrFcDAFUk1sVwtQUAxxgenrIPAwCRJ3yxD1cCAEckuAtVqQYAJSMaCvIRBQDumyPXJJMKAMMWdcM8NAsAF+Ad+cVBCgB1FbYsfzYCAN+HTcCawwYAveXXi5XUBgAyFYpj9GYFADAwpV623AMAqmzeQCkXAAAbRWcuWwQGALP8PkYHbAUAkW7+a4tyAADf/NXtIIQAALsQ9AROwwgAaqDQwO1EAwBtTdiGVOQOAPRjOMsuTgwAtx0yT2VNCABK+mKDqyAHAL/ZzUdDnAIAY4RfrZjnAAD+C8uL8f4EAHbB+z6l2QAA1bW93RbBBQDPq6W7tNEGAHpTpUiK0gQAmQsEW45rBQCRiWHypKcEAEsqN6+RsgsAl0T+KDAOBgAJak/KeyYKAEKyQsLuGQcADj4iFGOpBACVX7FfAhgHAJT+cYNrjQYAfNn3SESAAwCAQnj+ZiQEADHdzcRQGwEA1v+kCEQnAADdNNuugtMHAF04zsnPCgQAHlukmbsoBgC85tzkvPQEAG8LncRuYQIAHOZihF35CQDFWZGbPq0JAPhNoHWkmwcAlRVW7iwEAwCEJSTiWs4HAOPUU7Fe0gIAyamb0POoAwCO6wQNafMAAMBxS9HNPwcAQaybRHlwBgBPSCFGnLcFAI1rFfJpEAYArxA7VybrAADOqclA54kDABWsDlf2eAUANzmcM/JEBgAsbJW3R24GANBVH/4ySAsAYmJdXkJcCgDOudw0rrMEAJ+sFRppfAQADEBdbuAYAwCxPvjZIsQDAKZllDdFFQYAbt7X8aYGBgDnB2HEwPEEANjl+9yxKQIAJxN7CsasAwCEVJEImlMGAAZKuxTU2wQAuNvxSQiTDwDvymakxSkDAJvrT1QkyAYAmwHvIFP2CABz99LDdB8CADq9CI24JAAAUUEFz3jmBgB8dC4nMTYEANFcrEpeHAEAxuD9yrHRBgCQOjBqx2IEAJv/PGlOygMA/YZX1CyVAwAww957vMoEAInSeD+PeAcAEfizCSiUDQCbwvh3MpcFAGf+xTv5EAgAsaxlgUnuBwAuCpwIJJYGAHME58hfBwAAEyMdq4Q+AQA7lfbtC8ECAMghAz+5OQYAw6ERkeMIBQB6L5EOEpACAEOurGT0ywEAV2FX6XNTAQBgW8iT9O0AAABBdoTSxAcA7KwGv/7+BwAAQYJ6+5oDAGX950eOtAkA+R1NxQBMCABoWptZWIEEANnVQbx1/QEAPF2pH/zZAgARug7yJ9oHANQZMC65AwQA+FxGi4EvAgC4Cf8dkEIDAM2Dxl1ZHwMAgtZfdFd6AwAXJqsSu1UDABhzjFrH2gEAYDRC1Xm2CwANQLa3/LgGAJ1fvoM3xwYAKgWOr45RBwD0u5N0zGQGAON0GHaUPQMAE/aWF54XAAB9huI1BYkBAOyCIRO4+QAAMmx/G8RZAACRFFMGh54HAIK1PGRHxwYA5JTUCgziAgB1sbtxOHwEALBmUMhQXQYAfB82U3QWBgASs4uBo2sIACF1qpvyrwYASI3OAuqPAABIT+xxl1MEACjKrYsxuQcAxRbgrxkPBwAjjWCxe+4EAGlkV7iJCwAA0OreaHbdBQBJcKQLbQkEABSRIZdZJwYAruZnitqbAgBd93SagnMEAMkCOa06UwkAeuQRa+DdCQB2C5PRvoQHAGfIuZIKyAkATE7UtGjGBgAYxHlGddoCAFoQvjFMFgMAX++YK6wfAQBWknevGloDADyDxISGBwIADIJ4eiHPAABp59LnJFAGACqo3e+1OwIAxtMyttSfAQCk+FRgGkEHALR1sRg95QIA80ogVHI+CwDExKHV17wLAA5d9irCxwQAw1gkh5rsAQBtyJ25Mp0FAKypIl4HrAYAcTMRIJILAwBuljim2X8CABO4T1c2wQcAm1CiANSkBgAcl1YQeUEAAFwHbobVVQYA+E3m8yswAgDWfFyK2K0DAEYwOVnUmAoAt5A9y/4LAwDW+D3quNkDAHkVUZYOkAMAakAaE6EbBgDy3DW2cFcBAHGV94PNngUAvX8LHEbbAgBfNIGpQjoHAHnIzJ+SSQIAKZCVFvGgAAB6NLHXT5cFAK3tCBzM4AEAEx+t+L1zBgCOvcsQA2IFANaF4nf0tQYAyGwy7JHtDAD8owN1U9YOANSIOXbTJgYAzlg2b4TsBwBD1jRJQ5MBAFGqXkSi1AAA4G/ninDQBwDhx8O2R5gDANnZpKJ2dgMAxy6iHT+PBgBrc6I5gO0GAHU8TOB+YgIA0edHppDqBgC5mTNyr9oGAI+Oray/BAMAB4sQfZECBQAP3aZsF0MIAIMdLI8V1QUAO+tYnkS1CgBHvj3rYnUCAOcLF7TXkQIA4ajfZ8rRBQCimPJhgKgCAH1icZ5OMAEA/pzcatIUAAATb6EbafEHAKxu8CgY5wUA/P/wB+1JAwDdwtfijUYEALsHY/jG2AoAcgmFoWsoDgDTRISw3OkFALJiM1RqqQkARjLmJ2TaDQCeRhmUXjUDADeK6rh7hAEAcZvPiGX+AQAia9vSybEGAEu0/8bnzAYAyiKs3ojGBABSA//DdfcGALsZ5D5gZQUARhzGVkRUBgDyef6rKY8FAPbNDnG/ZAoAaoknhcUIBwCUM8Xm6iwMAGkr6CEbOAQAtIVBcpOvBgBoPueNq88GACG91M7v5gMAvg1QCWYFAADfha0keBsHAEF/SpxidwUAiKjGCUUCAABEZi6xamkCANiAS3+izAAAnhEb8cHHAADsyrBb8gEHABPBvnzZ9gAAo5N8+5fODAAaKBFagzkJAFWR2nqQKAcAVQkFvKUgBwDtbGHk+LAAAHW4D7XE0wEAmAHcc5byAgD6D4PxsPQFAEDc+yvJ4AIANVqAm0MJBwCHgX9VSOwGACw6oRtNigAArvkLijR2AADvRLHLuekAANu+sV3VmwYAvTH3R07hBgCsDidHXqMJAI3feFQibwYA08+RQdRmCwCtIFf7j9QCAHffoSF/ewUARQa6/w5VBQAxqZhAauwFADfzs04QIQIAFIy88kMXBADHc4etsJYHAJtou1zunwIANIcXXGYiAQCTxWtOehYEANuPzvhlJgYAV5jFGhCdCgD7n6W7O9kEABc/N5d4ewkA7LcMNzNLCwAAJ/Z2KJ0DAIdsHc3OAQAAdXZ0ERrwBwCQgaGlDTUCAFIl4reLkwcAzNaBhu6RBQC4eeq0sJ0DAEIIOA8iAgIArOBCunbyAgDm3+LGbxcBAKUOd0mJ4gAAcnsUiJ5VBQAw72NuHl4LAG7/p5oQWwMAkCZP5aP2CQCbYZxb0GwHAJUWkLBUlgYAJ3+3EDelBwB1gdKnHpoHANV3xqTDjwAA6jQH05nBBAAUzJrLIsYGABYCA1UKZgUA+xGfGfFoAACQaxHQ+vIEACW2O7cd2QwAxBKBU4JfDQDdFZgnWtgGAPmczbC3QAcATpTylRlFCwBUTq6UQbIGAJeI7f0KIwIAcVB9YRI0AgCbljUP09UDAO9ySUpIRQQAfH3qn9D8AgAq0p5rEpYCALIFKgFxoQQAI1VNx5LbAQCJQmDKiQsBAFvwRVq+QQkApq7si7OtBQC78kHbRv0LADjOtbuI1A4A0/CeHS19CQCcKBiXSUcBAKvH5GeKpAAA469LVLwPAwCK5V8xAccAAHV7V42HCwIAaj4/BxivAgD+JA1C6joDAJT/9IsAmAIAHpbbcZFTAwBcxjz2FCIHALYpO/S5twUAs6PuMepJCQAIFlgTd74EAJheOWB52AoAU6FVyEryCQCTpgdTQH8DAJy28mzm5QIAU5yuZkLYBQC5U+h96+QFABwXWIz0/QUAqgWVjjIIBgCaxB2EgiECAAcjHYmW7AMAAy7y/2PzAgA5ruI5pwsAACa7iOr1JgQAyHV/55IwAwDnGdhAOaUBABOGgU8uEwkAjFF93pciBwDWkIdc3pgGACXrW1S4aAIA3/6Wi2TSBgB8sB2tiHkEANd65qODMgAAObkMvscdBAAECRBmbLEBAG3GyyBMogAAgYbk7+miBABxYoSWEl4AAFBFLCTIuwcAtzU7EAaaDQAyIPNKfiMHAHpTsxpCJgcAjCU4XfKMBwBaSZwts+4CAFCXL3clngcAI787g0fXBgBJ19UW2M0GAJg2wckAnAMAaJ1IMY5rBgC14hB+hXMFAHIUqhboOwEA+Eut02QZBAD/s3YgtQYAAC0IzrkWfgsAuD6FVy+ICQDEH9CsntIHABXntVlq5woA9qlhlS7eBwAceJWd4c8AADxFHGLMEgMAfAfa5qxFAQC46ZzvK5EAAHa8QzR+1QQAy16ltvTUAADOO3O7sOsHAEkFIAVqugcAaSDi5O32BAACpvEKqbIGAArYslsk8wsA/G7zIPflCABswGDPzLkLACV58yPjhAgAwXaCLIFlBACXHuaa/PQDACQt+usHvAMAoNRctUS3AwDzIVeyUyUHANMSnU6P/QUA2WIQKrK+AwCoyYI7BqcGAO2XwV2jpQAA7z2lBgzIAwAWy7HCMlsAAIKB1XospAwA/p55fmbIBQChUMh0Xi4IAJmGTmHb8AMAMGeFpHEXCwD9qE3SzF4AABh58P27gAUAajyHhjXnBwA++Xff7UwHAHG0N2pVtQMAgtRN4STFAABWxpZ0RYMCAEXNts9rrQAAFCSw6NF1AwAzpyedB/wEAA3FhgxEiwwAhTvKnJI5CQAu30zk8vgIALGmexEyhA4AO64rDBdBAgB/L7+JsDgBADnqNP1boAQA9V6STJEDAgA8TuD/f0kHAJiv7HxWJAEAtHPECoarAQD/p4Z8IsAFAHdEwr8SGwcAdTCoc6UGAABwyGYpYfgDAACNBDb6/AgAgrO7M3FuBgB2VqSoQksGAM+Fmk9u6gwAoHjo7ldvCgDeDSp4yQwCALOqcDBOXQYANndUMY68BwCYLUOxv54AADaXZ3eqBAUAse+HVtUsAwCVYS9ej0QEAEUDRp2RaAUAJxqt4MI0AACj29lDGQQEAMqqbKJDdwEAZMn5VpGMBADQmh6NJ+8HAAG9p47lDAgADIApFJMtCQCWzOtDuu4AAHj4lVPdhAMActI1GjPfAQAO90r97AcCAENolx0KQgEAT1k305l3BgAYYI9URxYAAEXxeFXOfwUAcSoUDCIJAACaNRQj+bQBALFmmKQwMAcAeSYL6StECgDOfZTY03sHACggVcFV+wkAoflWHRn/BQBRCRWJnRAEAMtHLS29JQIA6jvngMB8BQDLH3J1ENcGADLxp3K1OQIAaJAtrDPUBgAzcKQw+SsHAK0OovSsTwYAKkC5ovdlAwDzWKcmxSAAAHbMQvBZ7wkAJd12ScKxAwByYrFcZh0LAFbFcORWhgoAK2Cl4M9SDAC829ie+DQAAPOOjZSPOwcAq8oj08GGBwBRbiap1DsEABNTYcSsKgAA33d4ZKD3AADU8JMPzOEEAJAR7yZH7AcA+BL1i9W9AwC4BLPXt88EABLviZfCmQYAULwh4+o7BgA1u61AwyULAPUr5KHhYgUA0zTEy9SxBQD+dZu4bD0EAFYOkFuNMwMAUxpTfTKNAwCfG9VhXLIBAHWQsyJGSwEAJp8KzBUmAwDftpy5EXcFADg86RScpgUAmcWkgInoBgCShSVxj/kCAO6mVE9ErgoAwcX7ejkVBgD7+PODdw0OALmGxF9nqgoAE3aeLgbYCQBWng+1TKcEAJIBZMLRMQUA0n9snT3AAADBEGYVzXwFAGqAnSSupgMAWnyQqYXaAgCvTOwhN7IGAKI6aKTT0gQA7/0Oh8b5BwAl74rOuJgCAN5lIQrqcgoAbtA+73mBBgAerP7AueIMALpjGwsp7gsAfDqAcWK6BgCyDPfvU3kCAFLFDq4iTwUAJCcuqT2fAgAYvSIMykICAM7VBISKSwMANTNpg7XsBgBNuN+/duwDAE+gVs+VyAIAUk3VSVE1BgDhZdS9Yh0HAPVe97HatQUApbm+DNbiCQBW/l0XwicFAB/1jyuKng0AsWISYjPDAQCA33jTKMwDAKaMlvRBIQcADW3ba2kHBAD7/C+ycdIFAHIxfzFfTQcAgcrZZ1TlBwAN9YYxZaUGAPEt5uyIsQYAcUmENm3GBACdflTEvK4EAP21VHOejQAAaMFtC3VrAgDJrAEeiGIBAKUBHfNtlgcAHZrcnb1zCQDJAW0nGwcAAF4CjpHYsAAA6+Kep+5bBwC4TQmEKckDANujlb+P2AUA33JY/h4PAABqJRgjh9oFAGBZY4HrnAUAZMeTdvOMAQDqGTvRHG4AAFMDW55irwsA5OiIoPEECgAtqO6c/A4JAEqjLzyGiQ0ANtiooabzBwAjbxZvUa0AABrIV231YwIAyjhGOCI0AQBQCq/xHzMBABZuUgMGCAMAC4A9XTlEBgD83r49ILkCAFWjVuaMsQQALBi8ZjQ/AAAT5dLeDw0DAD1HuGgelwwAlfN5l8wsBQDIVYKuBOkLADiT80au7AQAWBw1hFBhDACzMxLyGk0BAAucs4kZ3gEAnm9v3GkmBQDHP4yyNDQEAJnAAkIhqQAALqC5rsAZAACS15VpwKIBAEQcV7HLZAYAsoD6Ngf/BgClXInSoLwDAL8BzJ62jggAjPMtkci0DQAN8sKLf+oFAK+vyhblIAkAJ984QIvqBACkYl08vDEAAB4ITA/+2QcALPJnFNU+BAAJ0R4MzOYBAPHo2u0dYwUAAtLK8QpGBQBdZdCdkbQAAEzBGH1pxAcApKK7kMgxAgDKQgWT4EwCAIUL8/1VoQcA+YfU5cbGCQBZ3EsT4UsKADFvMnBZQAkA8yRzipJJBQAGwQb99ZAAAP1DHgKxqwYAoBHX+rwyAgA3fwQ8waUDAG2gKDxOHQQALhruY6cyBgBNXr3/S/oGAJJHuqY1/QUA6J3pHV61BwDPDexttpEEAKFk2tCOSggAvW4JRfzsDQCxiLST7u0NAI68URrBswUAGHALi2vPBACnMurHPbEFAB4Tc9vCjwEA41ePH2XjBwBlqV8FVlYCAO6FDI0zjwAAvXMamSGoAwBwWI9B5jsAAPCerI7B3QEAwo2ZnuBMBQB4sC6o1DAFAIu/mmxFcwkArA0QFSCJBwDL/pVA4T4DAGQJetaVrQYA+8sAfj7bCAAlSPnhMDYEAAlAa2qV0QQA4LX4Lf4TAgDmkRGk41wAAHcB8VOnXgYAY2MJ4j78BgCsZ225NuwHALFYB2rsEAUACSEC34ftAAAaHpLBTioAAEx5z/FiYQgAuF7+yt0kCwAXMkbg1RgIAI1CkpCL5wcAZ8DetRJtCwCiuCQ7miUGAJwLF/S1iAEA613h3sCBBgBFdPNl5t8EAIAnEcVD0QMAV0UVeZEnBQBNQkEHj58DAD2SV7NuXgQAb3TbXpssBACCuoV4Ue8CAFEvWzD7vwYA3RLXshKxBQDi5E+XdFcDAKPjlnr4SggAn7MLKWh5BQDcrliMTpcHAMaINAh+dQcAi7znKsYBBgB0q+zCcFMEADoUq4+38QIAAeEgCkO4AgDj/ogdnqQBAJZNzke7iwMAN9SEuufwAQCqwl3jQ9wHABiXPidcKggATouy38krCwAZ29X49I0EAI8CbJeHTAUAUC3YgftEAADD2X2IZWYGALKwagp2KQYAbD4kx+aBBAB3/EZw45cAAMxYZwFy7wcA2eMHqcUYBwA7OGuMybkDANzMXiXtBgAAWZoiOGWXBgANw/kjmPcHALqH9WjwHwQAU80bGQrACQAkniCcb7UHAL6qzF8eeAsAbMAxBJtKBgDoE7WjOdIEAGYQG/UjlwIAw9kEz/RCBgB6m6BaCdoEAE14PTfgpAAAGSl9W6HWAwDWpUZQpxoEANrTwh51kQYAxCFnqzg2AgCD4azQp3EAADFE4SBSNQQAgTkoKjbhAABUljXYfHUKAI8NsXrN6QoAdBd2z5vGBwALuofIqi0HAGDaXaz0twAApJgELNq9AwBgARiqZ04HAKduFMe8wwIAXynoBOvXAAD+oG8e6qUEAGBsQ1xjXgQAi9HUqPSOAgDKKjKnqfUGAKtE2aPr1AkA5NzzFQ8QCAAkeDYOcBoGACM9q5IikgUA0+gOaLkqCADFxkEvDAABAHRxc9+fIQAA530Sf3IUAwAeuCN9J+UHAHoULhrilAQAmg3l3YWKBAD0PUk098EBAIlohmTbewQA7I6PBH2aBQBrpL5s17UGACIleB4XQQEAH3zaJm2ABgC5mscbHfMDAGhRn0UgnwgA0j3AabhvAQCU2QzsbFUHAApRtwOa6wUAccuR3dEKBQBHirSAV6oBAHdSaD8zrgAAYgm2M5cZBgARZSZ8FZsGAMrxk/hARwYAhPb7CKQ6AAAN97g4HvgDABHIF181fwsAWoE0U+h6CACO5NLdq+MHAOVFH77qHgYA7c00LT6tCAD+r9l+zA8BAPJv6bCMJAQA4nJRERwxBAAlab8c1MkEAFBPEPwQBQUAnSRuM8UPBADhLfs5ZjgDAHh70XH4uwcABIB+a3lfBwChD79YwScBAHS5Ua7EjwoA09vSv4luCgDOZXagIuEMAMIFNCCxygcAfRadR4LtBACieZguQnwBAMP+yEZZigIAdyuRLrM6BQCl4J+gTbQHAPR+0IfvVAMAddnFYCK1AwDcHxc2aJ0HALvUQPGU2QcAVBhWBMS2AQCSUyAt2QIDAGTx4OS2bwQAt2VSrZc0BQD8hhOg2+sJADtqswwvMAgAbELr9cXtCAA9KKS8osEDAAIvu8cwNAIAwou1G+qjAQBhXN5jVyYHAMrxdjtdDgEAZ47aU9a/AwCKKsg+lYQFAHtwp48oXgUAgR2Tw185BQDLYRPFRlsEANHjf4rdTQ0A0hnGQczOCgCQTaxiZToMANi9p6yl7wwAISHzrsDBDQChf08xvyoAACgVip7RkQMAx1+JE/qiBgCRperdjp0AALfcNvp7FwIAj9t5+rwbAADhZjbrS9gDAAQigR2SDAIAzjI7PYTdAgCr2IeTYa4EAIP7W5hEfgkAIcwmxjJODQAXgfMvQZYIAGkkGtZBsg4AQrrlq4VWBwAuo0RTqvYDALsRD2iDlgYAqiP2gTVMAACly3VYrwEHAPN7sZENoAEAsvJh6zMJBgDSTSrpPxkFAD70UKWV2QMAPYg6uW9VAwAOO2KbUjUBAOuDLuK8FgcAuD64MAE9AwCsr9C6KpUIAIkb0072CQMACllRoC6XDQAY1dGt19sAAB4j4iP4GQEA4n1ebtZRBAA4+HCZwwAFAKNcpoFbmwcAEXiP3CCsBAD6AfWpiZUCAEpratIQ2AQAWbKWDeDtBQDzBVnJ6fcEAOuZUjU9RAgAOO5afX2bCwDrNC+aUZIGAHjPJElA5A4ASRRK7C6UCQAuMIFXvEsHAEzsgbs1MQcAPEhhG2fvBwAp18wURiYHADjmkq2TGQMAkkkjrhlTBAC1T9JHnSECAPZssIhE8AQAEkpynqo6BQCc7xRTpqACACd5HDzNGg4A5XmHt0aLBQDyer6smjYLANN0MHSwCQUAod62OdxVCADCJ/n3f5MHALalxhT6wgAAfNBt271WBQAI0XnBrPYGAMJHhiFuzwQAtluNwnwiAQAjdvW/6Y4HADqJHySyjAIAcmc8HlRbAgCiCnEHoyEBAMmDdMc+cQkAyvrVcgX3BgCB/yJO814KAIcRFE+UTQ0A0s6mlLsnBQCXSgOfXl0DAJu8hZcGJgEA8E+Fx05HBQDKSKMCo5YCAA6kx3b8MwMALkhbmSqZBQDHKgAHx40HAEEX0JRjkwUAF+8aKKT7BAB6CrJpkLgGAGTbx7WM+goAD6gqmOYYDwAaGhr4lZ4LAPpsZPOU5wUAOXaKMD1HCAANInBiQaACACXQaYskXwcAJ2plFrzLAQAoZ+LW/7kFAD6nOhDCOwIABZ5YAyZ5BgBdWZKY20gCAAgtrTylBgAAc7r3UAENAgBD4P079wIBAJocUbXg2gwAVdTg/38lBQCAIevRCEENAPmumw/MlggA6aRdcr32AwDGRVd/q7kAAGMd0vjwygUAK+oIpL7eBwAWbYmT254AAMClXtKXZQMArFhgEHuNBQBp7gvS+M0DAF4BZbdMCgAAyXx8MzJoAwANpp3B7LcHAIj6fKdRSgYAtQ3KcPScCgDYmAhuC7YEAMfm/90EXQUAXL9hxu07CAANaVxpPDcCABjPDVLIwAQAuZR0S6+EAwAlIqKOSqsEAEMXYNdaIwQA9XWJBw3LAABLDFM+MZICAAmlJJG7jQMA8RFaZdBQAwAG3wwrzucAAOZwS9nf/gYA1L9Flz84CgAAw8Qnrr4EAD8/akGkWgcAzq44YSUVDgCjhYzEOmQEAJK4NSeMhwYAd9j0IzWlAwCd7ovtBKUDAEb72KXgZgYADctwSE72AwBXZW2xSBUGAPOWNXdhogcAOl0nX01yBwBNUQ2BvPAHAI0TcnOtnQwAdBDT5d5FBwDi239epbEHAKFuF4+YugUAWuzdB6nTCQBvE/QmpGsAACC3Bgb8ygMA2pw1ovAYBQCn7G/k5foFAO2Oz9v40QAA3IHQPjGTBgBCF5Bmo7AFAH7KpCyHDAQAAZ4AlIDxBgC/MUq0EQAAAFynCmppHwYAykKtVwqLCwDI/Qa3muUJAMy/btQIEwgAUCgtipg9BgAMbMY/bKAHAPtHusG6yQEAjgN1xTU5AgATnMVxvfADADXoFtlIrAMALiO9r1MHAgACYNAeux8HADqvpEeunAMAwtk0C3wzAACKNrJSrT8DAOjPIsTQyAQApXFZJ7RgBwA9rRy8ldoLAHVzW/9R8QgAppDLXDXMAwAWHuTFxkkGAICq5u5nBgYAkOErGJ0XBAB5aX5W2VMGAG0lmkIPbAEAMZE+kEOUBgA23fnGSm8BAFOS4hJJ6gIAXdJoPmS0AgDnuib06jEGAOgNcKO5dQEA+0iqAF98BwAXA8qFd5ELAJiTx7KpWggA92X2x/IxBACf/mbaEAQBAH3WtNyCTQIALXUXDv7mAwCPsMse3toEAJHqsUiWWQUAGXuPhURjAgDAWilKPfQFANSsUlynQgIAEA0igESTBQBTEvkVR7AHAMa65sSAwgYAbnZhs6OtCwBOO1wS5S8EACKsSk3YEQkA3XylzwqNBABDrvasKL0FAH2QVo+rbwEA8tUYErGsBwDbtCMg4B8EAGUvXL83mwUAcearfeQmBwDB9kbnRewCAIZGx1MOWAYAdD9nBKHtBQDTNhMZNGIBAECG8x/WnAkAqBu0xMZgCABuNqcM91wHAB4BbPGoGAEAuQOiB1eiBAD2fyb23pkEADx3CIGFbgcAKcvdxcqTBgD0nwrQEQMAAAVdzf79zQIAau32U4pmBwBWJRQuugMDAAkJwYQFiAMAHSYKACD+BADkSNKWGHIFADva0KGRUA0ACgXBx7/2BAC+qS7NTk4OAG++i/KxfggAAkv8WpM8CACuGxj9F1UGAG2Bdix35QMAiolAlhgZAACZdN6EKu0BAMFjT9fteAUAPQwrScZ2AgAuk79A/JsAAAszH/HoiAUAbsJNaW7RAwCMKJC1KuwDALjRMq4JOgEA5LRauB7oCwAerjykrHoIAHNjUtcFLwYAuq3GZr/hCAC5e9jke9IAADS0XSMnbAUANy2mDm4uBwA56G7QTGcFAPwAoiVc3QIAfogseenVAwBVvKtNchkDAAAIaHh8uQIA3eY03d+vBwCIrjWLVDAHADTj1qFLCQMACzDjpybhBgDF+/yuwIkIAIJlgx+h7goAg4d9J6KFBQDuuKjLo1EFAIbY4itCtgMAvImWQeEwBgBVqacHO2UEANsRtEM0BAMAYonUM4JfAgAx9K8Ej70GABJjmv0H+QQAm9I3x9MPBAD5DpV4YmUHAIrPhuqjcwgALZz7q+LgBgDuM+o4Kg4GABj+8ykkCwsAPmFLSL+LCgDAyB/VWc8DABhH3tagoAcAS7dvPjpcBQDVT4hfE1MDAIQbjAoW9AMAfGwTb1wvAQBM3jei2/4AAESrv868eQcACWlNP6muAwCPGFiznOcBAG6B4PXYUwkA/C7buzOFCAAwlBKWlxQJAEKGFjZuegkAHp3TUqt4DADx4/fuwzYEACYAH8LT/wcAqS0K8nvnAwDecoT8vxgEALOjs1F5XQYAWdFSktOkBgDU7ABZ45AHAIZ3l78lBwMAU6A1FlwKAQASohGkh20BAHAFTtXi1QQAdF8/s9flAgC/fog/3qULALY5Yb0k7wYApqV3tZD5CQAVYgZCWn4FAHc2mESLoQEAj28e3lLmAwDr2C7gK1MGADhfFsiHjwIA1vfoG61OBABm9DFPnXUFAEN59EmBNwAAKU8r4zufBgDWNBX+glgEAORvPJQpmQQAFVtUcnA0DADE59fOayILAN6J7UwTOggAXkDOQ/jcBwDWg3l1XTQBAM3MNEL1IgIAtNuKPUp4AQDMK4zuvm4DAG9ij1v+iAYAwDJHSkjWAACSLVPGSrkHAA+FVIcbdwUAyGEU39mNBABxMueHlnMGAMAaDMidzAUAzdSGFGeDBgBzgV4aX28HAErf+fXT1Q4A5tdojwvaBwCmdVY4FCAAAO8dPbVfFQYAfJKJLqN+AwAuqPVoplkAANzUoasVYQQAdtq1w1MZBwCBetMzImQGAL2xdoBlyQIA/xAw5oGlBQB0NuiH+KUFALlDpqDTKAYA0pMMZNgcCAArD9fKsLcIAL1EgalNhgsAG10trjc+BAARPaFwzwEDAOyRGLqhpgIA4Do/+5HyAgBS6kuBexoCANFEbmWbZgMAM+Gm7QY/BgAPB1gnNDMCAHXAnEXgmAAAG3xsrV7fBABe/dRsHqIGANCymWYSKQkA5z1gohHuCAAgTMf1wgoGAAhoGSoZmwUA6AFwsHFTDABf5kYwChcGADiepEYaQAUAqMRhVd0KAgBGnt7ttKsHAF8ZGp+/hgUAC3n4Xo0IAwDbtPwmIYwDAMPjSeG6hQYAMOmkAda8AABSDnkD++oAAB2udQ9egAgAJwqGWcxkDADuC7C35UgKAHSP73WW2QUANVRMNONKBAAvBEg3wVUFAMAyQnVB0AQAB2mGMLQhBQA5nPtAjjADACygdcasCQMA7kOlu7mJAgCeUyguWasDADrYzauCTQYAJ+NywY7HAwBG+bchUi0GACl69zom1AUAsK6JIt0/CgDruX73ZNwHACxAOIPSGwgAITk4pSlPCQBtk9AYnCkEAEmKQYNBkQUA1a4hxxgqBQBtl4K6UbECAFTHS97vwAUA9deyJdx+AQDuGwimNnMDAMPlh4gxtQcA4VsaSW2fBADgvsdlI+cFAD6zCC8GOQsAsc9X5vO7BABnWW7193oOAI7Wnn/W2wwAM7dcVSALBwB/IXFFB/wDAOtqK5vSoAMAneXdzHhkAAD63RsFTV4FAE57xAQRfwcATCwRVcUTAQDKt/kDUVMHAAghmh3tQAEAr8I7MyIlAABkoPSYQ+MAACgZSz4JCwMAEgPIfn7OCQCDj/e9deUMADjtCxl6Hw4AeKNs7a34BgDovc4+2SIFAM/24EXwJAAAoc8mNLZtAQDYD9MfOrkBAGKjaFNA5QUAmrK3/T0SAABoPFJWQzQEAF/uIXlSmgcAfoE+y/xLBwA9jexy3oAHAHIn9ADz6gcA40w1iFFFDQCryz1KytwEAMvrv9AU0wsAVyvTavzeAQC855oIRYUCAFzBoOmP4wEAezfi4EYgAQCFqApWHHIGACgZZ78o6wAAp5VR7xq+AwDrtb1iL/IGAEkwUrholwMAvf37yJQzBADSjb8B0mcEAJbnela99AYAg7cXk8haBgAyif0gO30IABVpMgjyAAgAg6NbWpzvCgCtT+90mpEGAL9SFGHUngUA7wnqBOyRBgCE6QAny8sDADy69cRDHAcAzXSe+vZtBQDfVs/klZwHAOIJxjtkvgcAeOjZKsFJAQBfDDnKWKcFAIHcYR2LkQgAm9EMJlDTCADYtDdOq6IHANcUVHPqHwIAnWN/AjinCACVJEbZECcHAFZ0AKqvWgIAG6PqKB/SAgDQXwDqcXYBALc+SySu2wIAzOH/Vy9KBwABcwhzMLwBADScAfRX7AcAJKUfLghOAwBqEjWmjGkCAA7ZPV4vcAUAx8VwSpocAwAk/HiqpTYJAAB7nzsvmQkAoq/EsATAAwB4urAyiDEFAOx88Z9L8gYAx2DgMH+kAADQyA1UhIMFAK6cxNxD+wEAK7j0BqxGAQBVc57YALUEABKKchweNQMA4y+TaZ8LAQD90RzQP7QGAPMOdj5YQg8AtxYyV8E9BwBKcdf9SK4EAAPhE4pf+AQADf/WsiA0BwBExZdGS10HAPT49//hGwEA4fdXaOEZAQDV9Vw0FIoDAC+1BXGNpgUABh6Fnsv2BADllRhHxHgCAORkPc7N7wcATEtcRW1PBgBLo/4yVtsDAMIlmIKxkAkAyCUyUdPnCACtq7fjK8EJAKWcHnh3hwUA8l1J6peRDQDY2V33K+4GAI2+NOssxwYAx140zMl5BgCkmGj5jYkHAHWd9K0hQwAArlrl5BlgAQCcIF3yxU8HAA3tnZNqVgQAt+AW52NgBgBwTR/cr14EANqxzM8kRgYAwbZygKtXCgAJb2clBxIIAO2OTtAYoAwAbNWl7jz3CwAr10WAhQEEADAtyuDlWQQA6oswGbeIBAC1MhsNSm8FAC02gLzupQUAxo1OCtG/BwD0Nmc2mcgHAAFc+eq7XgUAij+QYLBtBAAhZhKJWGACAC/ldsY8jgkAj6mV2XlgCgCxCHkhfEoIAFll5gN23AEARCQLod/eCAAE/2CDpgQHAD6L3jzMzgMA/2QPR9UcAgCJOZWNwasGABXm5MLQSgUAKlIruNVnAwDHfT249NMAAI3F20x/BgMAN3lp2lIEAgCpd6oryy4GAHQotq82KAcAQLKUIDyvAAB6NX8phcIIAOLWgFYtzAcAY1YH1RMZBgA9KxVhUnkFAL08+rrboQcA1YglxTGtBQBcaGRBOl8EAG2WmpGf5QIA2jEyGjYtBgC4AU4AhFIGAGAd6TtTVgYAn6gAbAGuBgAFHBMqvN0DABS7lieiVwoAdD5E+2DzBgDq6iBy5IAGABgM8aXy/AoAH4ONs3/uBQBLxV7O+Q8EAFuzYeKFcQUAqXAOVFTiAwD44wNAgbUBAEvASjFoiQcAjmpEQcv9BQBxKv8maSgFAPazluIx8gAAk0bIV6OEBgCgvMkzBh0GAN9z/Pi8KAsAs5X/Bt60CwCkEbonpAoLAJtt2r8x7gUAZ4DfwjqyBQBmJdv/NUkEAG5sF20BLwEArvUWD7D7BAAqQJmNt/oDAO16hP1l6QYAe1KA7lO5AgBas7HNW18FAGY8oj8LOgQACoKLOAduBwBd2Z27m5sHAGFzn46ufQkAMtoCYfcZBwCLyoAqfBENADUJXbZmGgwAyqxgFIG6CQDCJjFqQFUDAHZ9chgZDQUADo5JC+rlBgDyFDIGtqMAANKfjBVfBgUAVJlCDPtpAQAQ7uzZ7ZoFAAIYhesWmQMAOMVcVRd5BQBPiuU5H5gDAMtv5m2l3wUACFkHCYgFCACTSoXL2NMGAOOxcOn0sgUAwcvtUkQPCwCTCiNZdYoDAB+ji94cLAUAPVp01PKkAgCKotRCnX4AAM1acIPAjQMAQJd1xYInBQCtkNmXMz8FABVN6Mc5qQMA4Dl+IsQ0AgDyk6Wh2TIGAJSEDO0R/QkA4Fcn7bMhCADFwY/lHT4HAKsWRsgQ0QUAZK8o36elCwCmywe4FWsDANf+Gp6K9wMAH49gLJylAAC3gcuO3SsFANR+hEhPsgAAx+obUb7UAgCbW57ZpL0GAAFOkZZpfgEAgM9/zvCxBwCBVEd0z08DAIWqz3irHQMAt1RebiHjBACJtnM5gkkKAISI5IRJWAoANvtCMJoRCADKZ5d4TOAHADK4zygbZwEAN8Xhon7lBwBBQUTvqvsBAKbfZMG90wMAfRfC6JzYAgD0LBi6Es0GAJd2msGKCgIA2XLMsvo5BQAg3h6PCGwFAO+O8ySsXwsAAquXYVzXBwCnL6TCSz4LAESBtBDNxwkAjzVI6rc4CAAXbqgQET0FAG1GX7ZuQQYAIM5fI6YcBAASu5mK/MMFAAiRucZ0lgAA+G8xmSH4BgDp86nxVF0AAEonvdDFvAMArdXSuISyBQCeliUQ4+UGAA9iBmMO+wQAYOZHl/UwCQAZ1OyPhkEIAMU7koxeEAMAOBg91IoFCwD7k+WH9WIEAC02zqdL2QMAt2cmtfkwAwAK8OBIWtQFAI2aeBRRjwAA0GN25f0PBABHBsLURRQHAHwPF2g+ZQIA1l7F495MBgA9/k76SWUCAG5mP69JhQYAaLvUQSmeAAA8/10fMegCANL7H/meQg4A4iwT/g2hAwDW+WseRloFAIMusPTujgcAzxaMZE/TAQAyUboq6n8AAB5Axh1ukgEAoM4X6opOBwAPvD/4Q8cAAFVUv8QDywcAmH6RqYuKBgDlYdgBHfoBAKuU39EArAwAGie9ASG6AwCvxLmIiVcPAH2f9Im/8ggAn+mO0c4/BwAymFl9lFUAAJAZpCr+RgMAWxl5gEwWAAAnunv7zJkHAFynxjtWcwcAs5wTYwjpAQDWoNkHtPgEAGlPksokjgUAVmTnu0aiBwBkuAG3JvQBAD8loZHINQYAL96O0+tqAgAFrt36yG0GAIY3oEF9HAoAffqzsWu3CAABHJFBTCYBAPm9hEX0AgcA3o7GH1E8BAD5Ne06LEgAABvTcVKv4QQAm5OSf/nBAAAXwW2ViHoBAMed+V4A7gYAzDGycpGqBAAqd+th3bYHAMfSAav5qwgA5QpjhwKIAwDb7VsEyi4LAM8yXzZDfw0A9b9Ztqk/BQCSPfNQ6MEFAPX2uZoR7AEA6WPmbW/xBwDG3hbL1qcHANLx6rzpAwcAVVSIlOnIBACCrZzatcwEAHXpEMZrWQMAXp/bDQyoBwBhTFw+2ZgDAPLj59JgfAcAcDh2URAGBACq0uzgxHsGALlzEx+UuwIAMCwAycmZBgDzSOIzZ9EDAInjS+G34gAASnj22g0sBABQeMYf6okFAJHx3bUJOwUAzPFGWSOnBgBgvi+7nLkGAGJcSNal0wYAwCPpZpSDBADd/MYwrxwFALRUrBia+QoAbu5hlqOYCwDizUAeM4QDAKYZ3sQVzQQAjp8YnOIqCQAK4HR2QqcDAMF0fk8vFAYAFTqMMZPMBADnHiusG9UGAD84kqJKUAUAzwENH8vABgAz1fWeRocBAL9HN4g4cQIA6JA65Sr1AgC6jpX+FP0FAI7Lk79e/goAh+fLitomAgChfvuigwgBAETPQnhwlAgAXHJg+XPdBwAsq0Uo3y0EALt2Mv1PIQYARlIaGI0LAAAg63nVpmgCAEeG5Sb/kwAAKZgFaP4kBQAhtnzkdVsGABnM1aWwXgEAWp2SswlSAABHa8jLm/UCAO7CkbZg1QkAB87j/Lr1BwBsgBQWVs0MAIexcGGLWAwAgRDQ41WqCgBfExeZQn0EAHDweqDP6gMARG60RqveAQDfbKQ7P6UHABrl4kKLRQUAT0QHDOaSAQCqHaJDiK4FADgVC5Eh1wYAfkGmlRoyAwBop6gEkD4BAGyHOxnJAAYAZXcNihscCgChjrN/knkLABrg23l2DQcA6Y2JQGD0DQDbzi+DRYgFAHNuDH/NNQEAW+Po3/s/BQBb5QZeGS8CAM5Lgeg3OQcAjfR7KRZxAwAglwYNnloEAOxEpxr3WgIAo6uKy/AaBABeHYlOis8CAKJr0Bd+SAUAlmUtAyqHCwDfSJPAKF4GAMJAzrJrewoAaR2J8vemBwBnDxEHh/0DALItqRaHbwIAJzB1G6rNAQBhJrVYvgQFAFKC5dabBAIASe+aao39AQChbyG3Z8sHAIK5w1P/egYAKJbaEKYOAgBZVPytGgEGAH34ywLI0AYAe0xV7b9BCQBiQu9nttsGANx+hSYxjwUAQJN3i+GcDgA8+JXPbZIHAOwrDhIlLgQAFfrxbek9BgDM+fNQa/AEAC+2sMFc/AYAy3mYsihVBwA9WhLSj5oHALhqdEuNfAIADCECP4n4AAAQV66zllUBAMokUX4WMQcAP+G76Dh7CQBVkC+UW9ULAD6RvpUUnAgAbPsaJE6qAwCieZE/0jkHAMToudv6MgYASAz+K1LIBwCpWu+DCe0GAPS1h3Yj0gAA9QUzKr84AQCYZdgkXfQBAP5gIa1LJwUAKtFYHQS2AQB6aOSmyi8DAN/MhydzpAcAQAZ/fEIeCQBjjF84WTYIAPprdtnq9AUAACZsM/ZGBwD1mn3FjW4FAHhPvhe+swUASy/4jJK/AwARbwpgVS4FANbr75x+YgQAHJdsq0XzAgDp52NuKFMGAK0jirdhEAUAAUW1rJlJAQBm7QdwkbQHAMqiU90oGwwAheqHX+h7AwBBXqjS40sHAKZsyfqHvgkAzAj+IDbQCQBksISrXPsFALCFgnc+UQIAQ+AlMThXBAA9Im61o70GAE+Ebze6IgEAVOW0os0yAgBA+A+jK0IAAPVDe2bnUQcAPl/aVRcmBgCOtlK/cCwAAOFyjUW/Mg0Am7WW55YPDACinW+d9y4CAHfKvmerAQUAQ+s/fmmwBgC7LwtdS+wHAFBUWRDpAAIAXnEFcQVCBwBgD1MicPACAO8JpPA0YwIAwKNi30rwAADZtou07eAFAAPA+6RKwwcAJKxcTk7XBwCyQTT0N8wBAKauzsnxVgYA7FqtrBwDBwBXbHHQjDABAEIZlHMTHAwAlfFy90ajCwBPMsdcWlYHABFKJNWgHAAAE4dBZ7AWAQCu7VWMfaUAAAM4EJyAxgYAyGra4hJRBQBauj0KPTYGAAz0povJGQMAx26jA0voAgB87/a5EVkAANzqLlHzrAkAaCppOZhjCgAGBYM0omkGANQDBgySiwYAsmQcne9VDQC7Dt/1g5kDACaYlYkl6gEA1s0Dh2POBgAFhYl4FjEGAHCims/OswYACL1zO7pwBwDUhuH3dRQBALwrickbJQAAWsz/m6tOAgAXOBPe9HUGAAqz2jvZ9gcAJdS/pazzAQBglxwcUvoCAM35J86AIQYA0yyIC0UPDgD8ghdrA1IEAMWBdrCVLQAAsgWS+RyQBQC07F5uaJACAEwWcN+ZPQEAysDlIcNeAwApQPQ34zoBAKctP4GOAAQAOgyOLydABgDaXuXpbcABAKppbf9AKwUA+n83CYgbCwArTNFcYjYFANEXLiWvFgUAK9Pn+JaABwDixD6j1noHACHTEdzFFwcA5COYVRShBACx4qFQzgYDANvC/qE4zwQA51z6DWWqAgAVlPGoFkkFAHgS52/JDQAAuD7mhCdfBQCRYKLTynMDAJq73Yn7qAYAN37Z1TWMBwCyLO90Nm4GAI/dU6xHQwMAKhGl7UcVCgB89cmCTWMEAFLWpmiSJAQA9y9/aG0zBgCg2SZOT/4EAEFUlD0PBAAA04ZZ/TnpBQDfmwFHISoBALKc0OdmxAQA3QPSlVv6BgBUojSjUDUGADZ7VHJFWAIAdxMcgVhcBwAbF8w3xtMMAOI0fXQwPQMA16f6upKaCwA3z2m17dYHAKAs3KWUAQYAphBedFmvBQB1SAA+9agHAHivfSym7gMATieT5hPHBACks256G+0GABWOfWnOKgYAdbAqKbhmAgCcXGagNoQGAGkQIOgX0wYAyqMsXYGQCACgmRTr8T8IABjjUPBgOQoAEBbJaTY3DQAnPy8g6DUCAIAXti6fTAQAA3AdW5AwBgDR6nTSyPwEAHiraH9uewEAV1IOmqsUAACli39WOZkAAII8Qip7tAQALcR65deIBgCHj2daS8sBANQHoKJiqgwAbS32OA4eBgCCR8yPiC8IAP8b8oMrVgcA9i7Y0g/cCgBs/Eo5a8AEAMw29ksbkwQAeCMy0GArBwAli4HGJ1ECAEPnjae8MAMATnQZEYT/BgAFk+ToYMUCAHql5e9PJQcA36dgxeJ6BgDxabPhG8MDAHJCy/mTvAgALBhz2/n4AwDE4brqNbIKABlVKYe/3QIA1eeXEOwcBADuipQITYYEAB72jUM30gUAZ3AfYIWyAgBT1+a6vF0CAC0mNBG2MAMAioBtotcZBgDyvq3Cs8MDAFJ/7J58hwYAbbbh67m+AwCH8pHNRGsCAIMDc2KT8gcANpxFUXn9BwDnSS1RTFAHAF/FO37thwgAJcdJAbHeBwB1dDiPR0gAAD6KZ9mXkwYA83bJVoF8BgBsIolVTesCAArBweYJxwIAeu5mh2qvAgBs2aF5qooAALAvm9WSLwQAB5wAQCx1AQDOYv/paI4AAPnyuArVCQ0A5OV7JKu4CQCF5LLmstkNADgTmkel+gwAcI9zvRPLBACtMMFLClAFAJWGk3qhJwEAbeM0+iYqAAAozB4u0YQFAKPrfvjz8QIASrYV5XWMBADwHgdSaVsHAAZUlkJt1AUAn5+YBmF0BwDiCjw1HpoBAL29ltXNcgkAgxaI3x1zCAAUgU/WJgQJANmjqdhPGgcAaiaQOb02BwDDBfq6YHUEAKMvzKvcGAQAgobPzpFZAwBgjEupcUMCAMMgHLFGFQQAtLM0k1AtAwCqcK4sEGwBAEX0G9UNcgEAIZivL2auBQD6hytaKRIEALPqk+JhUg0Ay2WbdSZkCABHahGuZQIEALzlugQjwAYArZXRuAt2CADp1n71iJsBADmjBBm/zQQALE9OzUkrBADZCRl3LhoHANJSuz4VTgEAioHmzRcaBgAniBA0rT0FALZVXMUyKwMAo0eTXxb5AgCsM7zpS7MGAMDycWVlaQwAPkJvzmGqCACgJxvXQPkLAGnRc53xhQkA3OZie5wbCACywHg6ZC8HAHueT8BF3gMAXPowjdYGBwAkL44+9pYGAC2S8BgsAQIAKZ3IWuVVAwABcewUtOgDAJAMUnywnQMA4e93mx70BgC65IS39YoAAEsszInSFAsATbzx4lA0CgDzki85k80IAHxrlGoMNwkAl/1aHTxCBgAzJR+I3JkEAAbFdmTyTgMAlxR00gfRBACz/W69xEYDAKFjEdd5KwMAarP87dn4BQCQOb/c6OYBAArzijRPlwcAfJzxTnLmBgDiE7zvpYAEAAwizkLkTAkAyxYlp4CJCQB2ZrgN+HIIAG1S2h8zAwcAyJF21DFLCgBxIGIBC+cBAGqh+LVj8QEAF9QaNK9qBQD3MNg1lpgHAHvLAHaiegQAw/gVwO0eBABKhe8njc8HAPmTRljjiQIApwmzV3hKAADaTdGFtUUFAOEhs+PQ5AQAQKzS4x9FBwCNqe549mYGAK3+Z4aFOAgAjEzmwy3SBAAPOtSgXicHAPfM130TgQYAOJq3upznAQBqpolEISoCAKUrM5wv9gAAOV871ollBACWP+x5+eoHAKi5chXo6wQASmlhXX8bAgBxY6MB+sABAD1qk4wOKwgAIM22WDu4BgCAJufT2H4DAGIqn9s3oAgAu9KxGVQADAD/PZQitgQGAFgadPaZyAEA+zLy4hkCBgDL+aeSrl8DAMqx8xQ2+gAA8IK+ub3+AwAAFJKVSOcFAAYngjjqUwUAjMjPJHyhBQAK9K4YovsBAJQBez4EVwYA5+nvVRvBBQD7dKDGe3MHAMxV4xzk6ggAdfc/0TXFBgA+9cj6SJQEAGo16MZ0TwMAotsHBnitAAC2PrZ+OiEHAIaMqqzjkgMArzWKPuk0BQCXyQL9EIsAAAUeuKzCagIAeTvOmIydAACsUE3+F14CAKch8Xb1fwcAK3L8sPnlDADHKA2blG8EACbvF13mzQwAl5b4KKi7BgB29gQe15sAAEWh8kHIWgIAcTiCrH6kAQAaWGzDqKgBAPupQhR1VQIAATn+kGa8AQBavFovExQDACjVMlGDEQYAV4q0jkvyBQC39vcE1VkFAP1m0vbnkQgAiHMD72BgAwCGEh3siIcJAK+ORxxEhwIAvVQzauojAQDVVOuzeIMDAO6Uj6eq1AQATad16AKgBAB8sWcThQsBAOMHWC2xGgAAli3jQZAYBQAxAgkrBlsAAI+352YXyQAA7DihVQ+qAACKkSwelqMEAB4/I/NE1gcAZMACnp/GCQCXaCbl5WoDAHmL09rBjwgAQL3Z6s6KBgCgu+b44DsEADtOYfzfjwYA4Dtbqx3pBADwLyHJ1LEDANuxP85rzQIAEMLX8w7JBAAWh4Gg9ZYEALg5woz4nAcA2/hsMJzLAgCPUFsNdpUFAJAnAv3rywIABRHsKoK4CADLvCbSz9EMAL1xSfqyFQUAFUX1XSzLAgCXY6oE4b8BACVsmf+UFAEAAFg+YlFCBgC+RODFn9QAACnL7UP6CQcAyir9Y4xdAgBh/d8pzcUEAAWvSOvALgMAfLf5kZOPAQCBDM+eAg8HALmwEF6qrwoATCVVg+AdBgCNwuN9WOsIANS7fZ+78AQAvXQqWspOBAAzPu0uswcDAMLoPLCKdAYAvBC4mg18BQCM6SSiZCwEABTDptjVtwAAQ9WVezJIBAC6pOOBZhQAAAxOw60UhwMAMI4pDm/yBADexxJFInICAPx1qUKKuwsA7hdrtNXyBgDlcDEiqbYHAOa34z9xUwgAwWt//TWXAQAuNMVJr5IEAFcDWt9cNgIAYLv/pzghAwD+RkbR96ECAMxEivFdGwEAZkLIQtCQAwB13I8q4+8BADgSrudekgYAMujQgZKvBAD4HRkR+f4AAGNhbGxlZCBgUmVzdWx0Ojp1bndyYXAoKWAgb24gYW4gYEVycmAgdmFsdWUACAAAAAgAAAAEAAAACQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9obWFjLTAuNy4wL3NyYy9saWIucnMAAOx7EABSAAAAdgAAABEAAADsexAAUgAAAHcAAAARAAAA7HsQAFIAAACBAAAAKAAAAOx7EABSAAAAgQAAABEAAADsexAAUgAAAIIAAAAeAAAA7HsQAFIAAACCAAAAEQAAAGFzc2VydGlvbiBmYWlsZWQ6IHNlbGYubmV4dCA8IEdMT0JBTF9TVEFDS19DQVA8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz7OfBAAHgAAAAIAAAACAAAAc3JjL2JpcDM5LnJz/HwQAAwAAAASAAAAEwAAAAoAAAAEAAAABAAAAAsAAAD8fBAADAAAAB0AAAAFAAAAbW5lbW9uaWM4fRAACAAAAPx8EAAMAAAAKwAAABQAAAD8fBAADAAAADoAAAAUAAAAU2VjcmV0S2V5Y2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQwAAAAoAAAABAAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLm5leHQgPCBHTE9CQUxfU1RBQ0tfQ0FQPDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+2n0QAB4AAAACAAAAAgAAAFByb3ZpZGVkIHBhaXIgaXMgaW52YWxpZC5zcmMvZWQyNTUxOS5ycwAhfhAADgAAAAwAAAATAAAAIX4QAA4AAAAcAAAAEgAAAFByb3ZpZGVkIHB1YmxpYyBrZXkgaXMgaW52YWxpZC4AIX4QAA4AAAAmAAAAEwAAAA4AAAAEAAAABAAAAA8AAABUcmllZCB0byBzaHJpbmsgdG8gYSBsYXJnZXIgY2FwYWNpdHk8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AALR+EAAeAAAAAgAAAAIAAAAQAAAAAAAAAAEAAAARAAAAEgAAABMAAAAUAAAAAAAAAAEAAAARAAAAEgAAABMAAAAVAAAABAAAAAQAAAAWAAAAFwAAABgAAABybmdwcm90by1uYW1lRXhwYW5kU2VjcmV0S2V5c21pbmlza25vU2VjcmV0S2V5QW4gZWQyNTUxOS1saWtlIGV4cGFuZGVkIHNlY3JldCBrZXkgYXMgNjQgYnl0ZXMsIGFzIHNwZWNpZmllZCBpbiBSRkM4MDMyLgAAAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYA13E8k/znDABDsrb+Qc8CAHYafQocWAcA8DJNUy0XBwDSh/pjwJAFAKjVtEJgpQEAU9GeFcyJAQAErjyq3rgFANi1EU/wqgIAkpxmWlm7BgBfepuls6gCAH8I71mzqwMArwXbxKj1BAAFQtAHqLkFAFDqE1uvAQcAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAnwn8jrlRAwAOBaekv48GABuXnZVJKgQA/Z5GGuWTAwBYHjIQ6YAGAL8YaAUKBQYAvzJVH8wqBgAl+snMQYECAIPmcfRhTQIAWkTH9DN5AgAJ/3bE6fsDAEJLLphrrwAA5Xi6URKtAACIfO7trhUHAFM19svQ+QcAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAMXEVd+vuBABBB/EVGSABAFacbNqcZgkAbDTbMsBeBADDLGq7Vx4FAKSMfXu2BgAAMynnRPqEAACKb13lThUBAJBzLoRdQgQAF+QaxGSLAwBxS+oCZzIEALUwYDc0aAAAgMP5EgXvAACEJVHyqfEAANbwqZGOCwEAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAfD7dBGZZDwA1iwUOUfwOAAzMso0MZwMALzPOmdiXAgDOGwZ2XpEIANk0kvPtXQcAVDwfqzYcAADa9Vjuj/AAADfWoBOW4QAA4CATSgKpAwAakaLJ2fUBAPj8+pR5EQcAxY3iyqjYAgCHDAmysUoHAMTswsUHaQIAHZwvYw7dBADZpSIm0c4KANlCR2HpjQkA07Xbb6mcBwDuAJrUN90GAF5RqklUYwMAq11H0HjhAwASl6ESRwsFAK30D4bC3AIAMT3w1nYNAwDH5AYhF0QEAIgt7a9REgAAWk/tm/w0BQA0Us85WtgFAGToEnFpDAEA8sdYg6AqBgCU4UgIRG8EACv1qHG3RwQAHdNpMrp3AwCAUPW6+TsIAN5fvn0nxAMAkkzUrzWjBQA+dZlAFsEAACPkbwCHBAcAb9a+ymFeAgAEZljMKOEDAOLHjy6LlgUAz2G91aNJAADm9h5bUBYBAG5YNIbXZgUAvS9axoVCDQAfdPjMYl4FAESQsWG5awwAOCBxBTQVCQA6eTRfuk8JADQIwZyfpAcAxiKKeBO1AgBbOfJuS/8FAL8H9lqO7AIAw+ylvHU5AwDU94VpFkYHAJrnCgA5mQAAevlkeUyEBQA9W/nhFzYBAMU/qM4pSAEApexxTi8LBwA8ZPyOFCgHAHZbmQM+dQgAZmersl+/DQDWNUW8w18IAMKV3ZeEewMA6P+01kkVBgA40bEtohcCAJ6wLgbPuQAAWPflcZz9AgDd3q9SrrMAAJfkGWannQEAjlXSVAb6BgDUQV7SGYIHAFHGdXR2cwMAkGUkFMuVCABnrKYq2AIIAFBIvIPxQgwAQwYKHE9GBgAHCXMFWb8GANmt0UD9mQIA9+UEmt7yBQBZHMy67sAHAAop+LGhzAQAj7HDVur7AQCKW0Hh8XgHAPTB73RY9wYAfwIZQGmKAgBN3GupNysFADWmZ88hJQAA0V4vdyBnBAAi1lnzwDIGAFLioysJsgIAgCYRfCViDgDVfJ89dQEIAJRSnQoL7gcAJ8pM6/uBAwCdYz46H4QHAF9EwzDqdgYAghPnpwD6AwA02z2WLSMBAI0HC+eSVgMAH3p3FMpHAgDQ/OhrVdsGAI4E+uJfKwEAkh5vrSZ8CwDkeyJxCWoEAEybLQ0vcgQAOuBOIEbcAwBseSA86fcGAE3j/JbE+wAAPq59a751BQAJ5s6FFaMEAP8wOQLpNwAAEvuWb7dJBwAFrqauBPYCAOsjk5PcNwYAR40Em639AwD3WgTUsKgAAAIe8BDs/AAARU4kxJ3SAgC+R8Ebe5IGADkIrDSFMAgAQD8DZDaFBACr/maRdxMEAEQe/kmmWAUAiczvrjVGBAC68odIQ/8BAEQtDiKB+QAAUTwYpxqQBADw+BqMVLcBABaBNlOMhAcA6T0452QbAACPfFiw+wkBANEmt4e4GwQAm5FmfFlMCwDDD5m2UKEHAHQikp3rKwUAGoZkce0OBwCpxnDgcagIAL5GQ3REfQAAHahkpbaCAgBrI3X4gO0EAFAMRR2++wYA2/wSjHLrBACJibxLmbUBAGAGTKh7SwcAuK7N8XhWBwAM8dawBjICAF1o8gBz7gMAGHUehEd5CgB+6NqIcywLAOgbl9OtFAQA8Q4vg1AYCACI+yxqfNQHALfWfZ7kVQIAup7VYyGMAwBFWAAqH4YDAMmuy0we4QIAEnkpdhU4AQDg1vCOFNACAPuH540qUgMA0vl0XgXuAgATCDH2OEAGAJ5M01jPSAEAWnXkmn0vBwBK/A9pHnEPABUNWzWigg0As7aF6M/cCADp6tS6/ngKACfwNHn2kgQA1ChVgdDeBwASZhpRYYQFAEQV3lAu6gUA29XroS//AwBmOZOMH2gCADUWkyEFhAMAUoYwSvF0BgCQSKmInL0DAMbpL9BNEAQApWoJ2wZOCQAjsOaJnCEJANqihtSreAoAH5VgkrJACgDJ70haWxYIACpCJBFevwIAVq5WZxRzBgAw6Iea2UoBAP2AsGXK6gEA9foKsGPIAgB2aoSgdKQAADIemO+lmQAA5r9LPK6oAgAsgxSvNFwEAOz/m322kQUAXbUYn3GzCQA204OMMVQHAJeXkbcXfAoAYJsIhLBFCQAAA2f4tIkEAPqbtIAcDQcAJUaRfX7VAwBF5WUhcsADAE/gGTi55QUA96h87ALeAwDvkus6LRACAEY6DNUijAYATomFk6guBACM81W/nl8HAMuWpLtfnwQAG1ecHoxiBQCrIugIsZgFABo2Ka6PXQUAKHup0citCAB0hihsGmoIANTPW4oQmgQAEmZ9jowXBgB1A3FzNPABAJhgSmFJOgcApr/chkpgBQC2ZBd81NEAAFEuajEIHAAARVDJRduzAgAMMI2BT2MBAHTin+iJCQIAG+zqhYsnDADN4ntlWe8IAG+HWGnRLw8ALwsmBbLpCgBYcA+VuTAPAH/MLTr9dwcAMkkS+6mUBQDwFcqAjh8AAGky7DzRFAcAZ8rQ0T5AAABSxU6HNS0DACm58Y0E8wEAI5sXO9cAAwALfaPle+YGAAODMFR0vQUAKnnnFSGTDAC3MLm7uVcEACYyGYtdjwYAVtQej04WBAB/BiOxfbsFAMJMsiiV0QIA8y8wuGasBABRrf3ZyAEHACc3W1yzwQYACjgHgKczAQC+YsrGZ/QBACzBXSojxAIAh7ATwB1VBwDNO7ARDGkAAA6P1abcQAcAPEN4BFeMAgBjpHMoUNgBAJzU3n4eZAcAcfVM1e3sAQCwwlZSP8ACAE7Oz1IH7gAA6fsWgd1gBgDr/w8TZ1EFAFyVhbiCxgEA6mOpX9JhAQB9pFN7dRgHACEvD4vhGQYABOzB5N/7BQCSux7ImNcFAGvZ24tGmQYANRmpauY9DQAam1ka+EUIAJJBIb2o9wsAGTMSpE0dBwCixObE4ZMKAM/+2vRGLwcAo/fe+o+UAgAEvPP9zR4BACXt/o/pwgMABTlHmiElBQDhElGSSxMGAO0GtCuUuwYA4t3ARcRwAACj18Qi2BEEADLwR8QFtgUAOfDn8Mb+CQB8RyxpvM4DAF6pGWqYdwgADot3oarqBgCrxUzvL/EKAIl8xCBZgAUALJf5cUeSAQBAwJ/fvYsDAIGykgAA9wEA64rq3HZKAgBAx8DfsiIFAEjhgDQZ6AcAuUFDoNk/AwC8IIpnY8gDAEOKUbIH5gUAAc+WpRxDDAAEFIB82hUIALQQj2+bPAgAFkCTImk0CABW5Dkx8wEKABgY32yPHQMAFksUS2z4AQCdPte4dZgDALOn/9nw+wIA3cy2ynoGBQBRnQMIa38CAKrfAIAvgAQAJcVioJKWAAAXWAeR6roBAGAkhqjLlwMA53kTyPvDBQACL14lvBsEAFCGmVb3ow4AQXzg1H8pCQAbHiwCtHEHALJZWfCTMAEAGMYuLzW9AQCG6oibeHUAALlI6hcRHQYA5mYHMp0zAgCnLzpRhtkFAA8b4Zk6PwYAbbLWzw6KAgCPjeE1aDsFAHGZIYmhMQMAnHJ1nTovCQDJxFPpAA0JAIkvbxHfAwYAiODgdsI9AwCaZP8ZlqwJAMaAT/tFbwYAov657jjMAwAf23ByZAcBAMgNdOrxEAcA3zu4xmcRAwBoEEtSQjgDAEX+MJ3TfQcA0KBBIUOJAQAlwrhO/ogAAIvwQWNDEgYAJSYtGuNJAwBssaZ/ehMIANt+d5KugQ4AUNz4xb8iAgCQjRejKlIJAI2JTofbQQUAMxuE+4AtBgCX+ifwbj4AAOgzlp48oAcA7+UJI75uBAA4SWFpUy8AAIcFoq3lVgMAAvlrn8gbAQDbyBlkdDYAAENSUA/nXwQAfhSVyCBJCgBdTJRh7AcJAB7AF+BSJwcAeumi3bciCQChV9v2GWYJAIwLDJamdQAASRvkxeHdBgBBo21RPy4EAJ7nqP0DagEAOQ46YtEoBAD9CKMBREoHAAmBVbnUbgAAZ4ig9vFGBwAhI29cb2MEANML1pIV2AEA1cWFe5+2DQDrUFYXLXoJAJ3Bv20+zAQADr5zOB0+BwD4ChvV9qULAF+sDaZWhwYAJuyKe3VdBQC9gF/0PTgDAKaWn4w/eAYAzZ54pzQCAgBSsnhxtg0CANoOLNqjOgcA03AcwEWQBwBZECUVe7MBAP7PUyNozQcA4PSsaGDNBQDMdHr8mgcLALNkC2WXgAUAmU6crKt/BADNsrJTAu8LALb6h9hbpAEAfMFtB0hXBgCoEaoAgLkFAHQJCMnsoQQAwL1jiIyDAgAwUEZKz7ADAC169a64IgAArSXpdwatAgB6RddnQQkEAIJqYIrLHQIAujF3vvoADQBQMxHDU8wHAIENCP5lzwcAoRsBZtnFAwD2xvbbQNgFAMifnYxGBAAAjGt5VIXaBQAlAJVwvrgDAAmmpi2J1QYAMUoZCD28AACL4Z8wDTgGAA3uuCw81wQAtsC6rYK4BgC+TN3dq24DABmsMmInpAMAuH5E23LBCAB+p7cFxfgDABA/f/lXqAYAOuB/VsD8DAAZToKeDHcIAPqEcIosQwIAaKmoPPd7BABnKCZ2kWMBAM4QgE/f6AUA3hbqfBf/AQD9tbVFmtkBAOyZJE9nIwUAEyYYJvr4AACYjASYc48FAAAV1E8mnwMAznsJ/qtKCwAyOiUD/DsMAPK3kf7HmwIAFkqE5GGnCABew3ISYlwOAJzi59sXNAUA9ZRzgnNFBQDdUPam7mUFAEnHjXRQIAQAiYhGcy1xAQDdkzHO+IkDAOV8F7gk1AIAzUA0DfpzAACXntQMAjkBAM4ZqwCYLwIAmf1umt2fCgA/KCiplMYHADpL5O7N9wYAw1yyBzJaBQCMWThNGhcMAMv4nj6KNgIAC6ziCKpUBAAAp48/kpAEAC9YpJ6qcgMAYkfWbEE/AQCMTMmZqlgHAET/ABcA9gUAvQGMSE5pBwDW7kjp/dUAAL10pU8hCAUAwwPQU7sVCgDCqCx5nhcJAKFAyGrpoAEAtjq74pMjCgDKhkyKdacLAEv+1j4VaQIAQJj4riMqBwCcaZlSvlIAABYjE+/lpQMAuvrGDpYvAgB2UK6T9hEBAJDKlKq/4wMAh7h2lHlFBAB5SEYSCUoCAH/e+BX92QUAC1LX7ipNBADkp8LSZQgFAEDqOFJbcAoAljtdsnBsDAC4fqR/GLwLAH9yY23TCAQAYmCm9vj6BQBr3qgtibsCAObix/DUaQcA+/gUWfMyAwAMwobqFQEHAKitJNqIbQEA3ypmIgaYAQCdWhm86wEFAPsG6RzYUAQAP3SuHJbYBAAOun2Mw70GAGO04ae00wcA863i3kuECACqY5YnrcsEAHVSIKahtgMAz23QkSfoAgCHPKnKcj0CAPSqaKu38AUARWO61CXeAgDNH9egJJABABoQXxFlXwEACJcUZ5DpBACvpcvR2BkBAAcg/s771wcAlJDC88VdDACuebUgUkULAIkGHmPBcAgAIJsOY8BrCgCMzW0ZzfkEAAEoayZqHgcAXd/ic66aAACjsRmy2A0EAA3eF0X7RgUAdXvoNVSXBQBoN3tq2JcCADJjTC9agwQAYEFDXzBwAACuVk4B3YMBAKCHQwjdzAcAgMxgZxiEBABhM1NlVkMHAAG4NmNoLwgAMEP2RlQiDQALGUioPFkLABcEJm0sQgYAlLsXSJASAgD1VLjeGaMFAH3aYODUqQcADB3WDr0oBACnmoRemhgDAEKyWR+7rAYADGNTR+/2BwCpLSopRvMBANaijTCYcwIAUyRwCkwOCQAz13ujr9oEAGGJPtxrnwwA5drs3P/+AQDDklSUwnIFABPUXkMojQMAWCiZGU8GBADNQ/W+D2gHADyN1YPdqgEAw+jrellpAgC+MM3WRccHAO9431V3fAIAo3+TM2h3AQBVGEQWUUAFALwFjEmF+QcAUGO/D1IVDgBp2nS/6bkIAGgRIAiD/gwAQt4nYfdzCQCwac1TJg8LABfhC5+IzgEACQdRlGpvAwC0FgBySPIHAJHP4dEeggEAH6NwxC5sBwCFDMGqOMkAAEFxee1kGwQAbV4YwbG+AQAHD2CQVO0BAEeWFT8n8QIAwAunVdeLCAAI5lyIOp4EANZaG4iFZQkAXU/TaHXCAwBf3H6ZwYoDABEe4Ip8/AEA5+hzVU0JAgDSSfW7PMoFAENBxewg+QQAtoWtcuXZBQA7sVGnF7UGAMyAsXDTzwAAGvTRJXk3BQCiCGBWVk4DAJ7+y9n8LQIAjuA7ELRZBADdKi0/S5oFAOuOu8g01wcACUpZvjw5AgDeTIJ3mP4IANkMDcPg0gMAu3FmaJf1AwCZObZ+WKoAABnGkrXH4wAAjEQFbJGyBgA7kboK0TQDANvPgbXNRQAANo86VeDjBQCy/x4EswsFAAD/B/MDwwQA7UTZDVgDBAA/ZZJ9940MAOlJs+OfigMA4a8KhYnqCABpcKtRsRYMAIWMshfWOwIAYVp95y7nBgDeTRf/cqkBAA/Gc2Nj4gMAq7J4jxvWAACwNsHp79cAANUKZIkcqwEAlx/0roJfBQAN7RfzV2kEAH4ndK+ikQEA6A5GT0MrDgD70/rAxpQCAA9Me5NogwYAW4cQKfjJBQBFBeDb5zcKADEUPMVL9wYAwtm7XQ7EAQCXXK6c+8gGANq34VxchAQAzLVQ5ODiBwAwtAFn7XUFACYAon/h0wQAU0KMiPyRBwDBigeZuvECABURm2n6GgcAw1A7Rxw8AgBIHeIdZ+cDAOihR1X6JgMA2a9fwk0ODQCIj8f7MQcIAB22UzmbbwYAucw8KPRVBQDnYBn7Z90HANT+r6EHRwEAHCucLhQhAACAGPhIGMcAAIY8I9jZSwQAMFj+jlfoBgC1QXBtWwQEABV+NPPWxAQAXRmPmPzdBADhZaM+F/YEAIhFrvnaRQ4AOmLbYzfUBwD5iApQ+YsLAMkffcHP7AcAHoOCByjKBADW17F9M7gHAPuVOO9tEQUAR36q2v2TAQBvh+g3PMkCAPqDxSgaQwMAediL2kmQBAAcwXpAqLQEANTw65n7pgYAxiPktrUiCQDV3fHfUB4KAL91TjJ2PQcAjkGVVEiIBQBeLPSp/TYBAOtVCFa7wQYASK0TfhIfBwDsWpAEs8YFAMebiI5rdQMAiTFKkXZfBwDRvQWjsd8EACkfgQX/swMALtk8KGLtBgDhUuxDFV0GAI2+EDUYIgAAbHowQwFxAgCr84u0j9gDAHqPwU7rSQoAXin/XRE2CQAD1B9EfDgJABQtrV44ZgcAXgkGi08ZAABiO4L2eIQAAAhz04mGAQYABrgXznGgBgD4ipeH0cMDALp2gsjhrwcAaK3IgfIdBQBdJKS9BkkGAO3xqiYbFwMA0UeKsti3DQDANJ4U7sICAFP8mmL1dgcAqUn8UOr0AQAkRDOmFMUGAKhMVpeQMQcAJTUjvE6EAQDh7v1DRR0CANIb/6onrQEACM9zSP0hAgBBYxU6TyACAGSkZUBBNwUAg8/tOww8BAAgpm5wflUFACS5b1mqjQQAgJdMyF0dBgCewkAw6H0EAOcHZbLeiQkAmUfc+ubUBACn6KB/g4wNAMecpVxmjgIA2Q2UFcdlAQCVHKE6X3gAAGmE49eYewUAhK3Mb912BgBYkPyWhWgBAJ9hA9RqbwYA73J3qFnXBACkvnNhboUHAFdqLD/3xAEAhDR8/G5wBgBtNuw5eJgGACZ/z5UfcwAAvOS8jnWuCwD12retWQQHALugXzC9TwIAz6F1zJgKBAAzdQoi4YwHAJfB4RB6IQYAZL/RgKyVBwCzK7SRSdsBAHJDmVtgaQQAWJpcceMxBgCPcs/vz+kHACHOSCgW/gUA9bF8XS2FAQAP5Vy+Dw0GAHV740bioQUAkNX/Be4aDQDZdzYETLQKABqWlOFPIQEAy+mpOa7hAAD3+Sa1yEMFAB3pZ4BJGQEAF8lvRJ14BACOt04Hq4cEAEPjjF470wEARhvrn0E+AQCk5l1WH3ICAJq78u5SDAYAEW2ufMLFCwAEbpWRlGoLAKUdE8m6JAkAXCsg3ve2CwBlm40kdw0HAPGL/Tu8iQUAa0Gjaj75BgBIrsHWo8AEAGpYCyaHVQUA/MwSw8kLAQBboMI+S+gCAFEVPPCinQYAe6ZhRhc6AgA48omivAkCAG+XOr1VNwYAt6zxlxgQBwC4B3u3LNgLAPRpdz0IhAYAB84tRygrDQBRfHNRN3YCAFMI0So+oAcAqzatxtwTAgDWvdVA4qYBAN/++PxPwgcAFrxIHMzYAACpGbRu0wIEAFKgFIz2zgcAOdHCWyXxAABqGDHU53MDABatp9gtDAcAAH7tuH2WBAA6Ui/Q7loJALuU0JGVFAYABnDBBPJyBgBTaoEThisLAA7sb59QlAEArKwxytgoBQD6ubhzbYIHALP54JnLSgIASDk2xvrgAgBkzUjkvvcHADwP2hAP4QQA6SCruWyTAwDQbOpP/KAHAKQ1xxWSFwQAIc1rKLkzDgCUnNu6s8oOAPm93344TgcA2Q+KxRNDCQAbJGJWqB8LACrt3NfnlAAAjhGOc/poAAAr7l8KZBsEANQZ8J1wuwYAmc0wSjQABwD0IjYuQmwCAPC1BWoG8wAApoAEj0TiBACV8NvgzUQCAFKZKjGySwIAWFz49SoMCAA+iPJMn2AIABLKobVu6AYA0czvokSLDgC0/p+v0tEIAMNn3jIX7QAANRYpacMIAwBQ0vJI8z4DALuhoV5HBAAAiOFx6OP+AADfHmIyoYoCADs1r0wkKwQAiuDCTAZrBgDTvQwCILsGADGFcXnNagEArbaHeMXGCQAqWdcf8qsNAHmGUxLUCwUAUTEncQuACwBggbE07WQBAD0dmy2vcgcAW06LRIbUBgCoGI3dWM4CAIs8UGefhAEAApNr7+AjAQCa5i8ZTNkGAA9poiJSRwUAs7iGnXiTBgDcafu9w/UBAD8HYfygjQcAgToMaPGABwBT1Pw8XaMKAPfdx83lBQgAI6x4gIjuBgA4azFLqlQIAGrGK+UoXQEAfstRAx4OAwCMH7F0LwoDAAPe1wwSnQMAsVay7l3SAgC4fCYZjUYAAPn7tancjAMA4qEsXLC7AQAzlY51FbADANq3agphNAEAFfXRd+dlCgCkOR5M9fEIAEUmUpUb8AIAbd6d29j9BADMl7qMh1QGAP6w9o3HjgMAImqjvq48AQBqX07lxusFALgOPZAEKAMADbKi2y8QAgCh5lwFBeQGANMypTVKAgUAnfLaVJD2AQDVi3oNHV0BAMuesl1yrQAAhW8Fmwy8BwDY//q//hwFAEn1Tem7SgwAIDHj17vsBwCZIzD1dfYEAFckToOxZwIAiLt4wxmuBgAS1dlee0UHAPsFPXgNKAMAAxq3//yuBAAeFxUENjYFAGV4BwkzMQIAvK80Q0RRAgDoVjeFw7ACAIYqKrfLvAAAlhL+UExeDQAMw+8T3V8IAO3lgMPGwAkAp2L74x3hAwDzCJHWj2cGAMipseovlgYAC6O5j6KsBgCYnxvKt20FAN0YcElYnwMAa521Ck8CBADCY2hjMfoGALBCfqblCgEAMdof8Lt6AgC8T+a5p4ADANTqCCEu1AIAgHVTDw17CQAthMnAY2IJAKM5RX6CqwQAOtdD2w03BgAjtHk6vyAMAJvS35QVEwUA/lKN6SemAwBhVoVBQBUBAISDn9B1kQEALY2LYLJ2BgBHK1scZboAACcQcGMjhgUA28YZwtbEAADeWIb/PfAAAM/Aqf/SRQcAV07TIVffBgAGDHp2L/MEACBux+qr1QkA4+EE4ekcDADbwVS+FW4IAL3IySseWgIA6jew88gEAQCYbKlvVwUEAG+H44hq6AIAz2C5ziOuAQBKmTIZh10CAG4LVjvWuQYActTIFCjfAgDtpArivvsAAOx4EobtjQUAlcnCtqhbAwC/hTGLpd4JAL27I81VtAQA+INIwBnsBQDVMbWWposIAFzFZvKTNwcAAjvJqYi5AADbJSOjDpsAAF58wXGufAMAX0iF3jn/AgB6xe/D7j4FAP0uAumf+gIAVIETLMeZBgD4H70edSoHAM9HSTtjIAEA9w8SSUcxBQBX0MD3za8FAO2NeBvnqQcAiAw7j3DvBQCTszy+M3QIAEIAYZF4mAQAcgFdf52dBwDEnjsBk8IDAMrKOV+4wgAAWU2bqTBdAwD0l+lcwEQBAO9/NIoLlgQA93Rd8RHaAQCt/sAZrE8FAG2v5+1z2AIAbvldTuECCgBLtT68AuoCAGQ1iLJ1iAMA3ek6UYwpCQD/FaAYNlQIAAk0N0NkMQIAryI7UJXeBQDf4uobIJkGAHpz/0lY2wMA+gdHZXPnAgDBI0yX9L0CAL1h0si5swQAKLypsuhqAgBRXBYQggYDAHnQYjNEsQQAuJxSHOlUBADPcr/GmEwKAJnYw5RlSAgAO/rXoxOuBwBmr45BOHAJAHofbrbHtwQAmNnvhaG+BAD4VRBxvPoEADj+Nnif+wEApi11RvSCBQDkTDIg03sBAMaYeBGJFAUAC0Ggkk1oAQCnxXgP2eQGACjavMShwgAAMmm9aUiBBAC4XaSRw7cHAEG2NawWcwUAagnpHeNBBgBNMQqzqaYNAEcEH2/QxwUASToL+HDbBwB4msg+SssGAH05ga3oOwQAZG8cvVjFBwA9RpbTJBUEAB0ankRrWAEAiu1KkH7xAgCOPB2G0uEHALqvoFxKQAAAvm9BKhueDABWbDELahwNANsb156ldQ0AHewfGgJMBwCOf25RJ5ULANZDpwoHQAcAgxHdy2RrAQBD6zJ7Sz8CALM1gqWrGQMA2a3cv5VjBACcml0aLdsHAC9ChQsgmgcAFt1xqr9VAwCqeF/qdwsAAC2CnqJ5ZQcA3zS0UhO1BABnJhzQezIJAKDIYDvXNAQAukOUqNrgCwB2orJLUSwIABcqwEl+jgYAtuhvNJVXBABGNY9sMIkAAPaIL2uf2AYAW+DJTTg6BABFtvGL2tUDAAltaqnW3gcATS/uT0nDBgDUa4ucmCwAAEgVliAJFgEAuk2bNhZWCABGb6yGq+wMALEA14UAxgsA6fwN4T4hCABtHknXN/YKAKrP2ilpFgUAifYxa4KQAQB9SmlnVfUEACLlsff0BQcAmFa8JeFRAwC+e/YaRpsEAJY6LHEVWQcADQxY72eaBgD8z3DvOE0FAOJ8btCC8QcAD3UhjnJLBQAoARuXkJoGAKNjqfJAGg0AvqYSrOkLCQDEQTIEzEoMAOxoAatkjgQAT2+ouL2iAgApaS1rOzQHAKPpjKoE2AEA6UPDyEp9BgB3V3pPu2sFAI8jfGIwkgIA+9csEhqtBQBk41Bupd4AANcqMcjRVgUADugbsVZnCAA9sHt+FGIMAN+/PnQZZQoAtCpoWfyCBwDHyIzjq5cIAII5jQzjQAcA/YJGf7TCBwAc3Me4kc0FAIPl+ZCnfwcAJNjRxsZGBwCkLaV+h8kBAIlhqIN7swIApQ0xSa8zBwD7BBwWgV4CAOi+NErhdwUAK9dNvb7OBgCfMkLkwUALAD6p0f9HIwMA4LssJYlKAQAJsI9LMAUHAAo7p2GsaAIAHL6+NPIGAgDo68unA7QFADVBn/BgoQcAeP2W7qcPBgDGbilNNR0FAMcWO6b1ywcAFAzPswv1AgBaxsqFs/4BADUWyuCYEwIA7lW3tPmqCADyRK61kWsCAMixeo2A3gYAsDBVZ2mnBgD3mE4o+7sJAPMzKziKBQUAPpEWGKl1AQDoimu5zfYEANKB2slHcwEAI1rZ2T6qBQBhZdnH6XcHAKzMBvBYjgIASawsu7tBBQDsTJmCMuYDAJXo5RR+oAQAm6R3xM1YCwCA5AL+iMwLAGrj9LeqIQcAU5lGyYxACAD5Stiu9woFAJn5DZjLEgQA3Cnu2I3nBQBdV4z233EBAEnv9tJdAQIAE9ORw7rwAwDlW/YVAd4HAMlNNiEsJAQAmGCmZFu3BgCFwAIBPAMAAL2uazEakgEAi8Hz2ZqtCgDqmjM4FuwFADuoWWU7cAUAEtYFTZ/6CwArBsreSbAHAPxwuN9+LwIAKLF31u5pBQCvpbDcNwkDABvqeJwDWAcAOice9I1FBgCDREQ1euMDAJl70rf9YQYA5CHWHXYXAwCJYQIwPDIHAFApvMw9CQYASwOEYL7uBgB7jQr3Ac8GAApnxlQatAgA2lW7mUvIBgBHtpgMGOMGAG1w4IWFmgMA/mMm53wWAwCXQtvsFD0GALhw+dwhvgQAeoKEoB59BQBxsCih57YCAM9ddRF1sgUAZQWTwoSFAABZQW/ae4wGAHvZ3ZnpYwMAs65L4txIAADjBeyVV7cCAMlt2sWkvwsAHTeeZciqCQCab7x5+TEKAMQf7jXBQwAA1fIZmRyhAgDNul3CTDMGANoAtBfalQIAoJOGt+mOBADG8yrMS94BAIbroxHEHwYAwC7BmtE+BQDgBLjG2wkCAJKHsKm/eQAAMkLVooDtCQB4XirH/g4HAC2CKtRRIQQA6DHWtuu1CQAFR1mxT+8JAPQNMNpROgAAchxWK7VnBACQ5RACktUEAIWWeJ52ygAAF0hof8c4AADsexZb5l4GAKlQuBnaUgAAKWRlZYZAAABMmm9ZOasHAL+gpJLudQUA7tekCkW8BgCoCzt3pvQMAEe8DgsbJAYAFZMdT5wNDAD0guPnoQAKAM8vGIqQgAAAmLq3EylTAADDhcN4z9wDAKmrXt0CgAYAP80ScU49BADFOvnqZ7kFADEKWMqsYAMAYvLG1V/GAQCr7MIVfxwHAORRJqXsUAAA6mjmYHY5DAD08pJWp8IHAO9mbH6esgsAmdq8WKYrBwAaE/oJHBUGAJwMP0XeGgMAaHhzB+7fAwAR1Kf37BEGAPZkvWx+YwIAj8UhbO6wBACWXfD9DVwFAF5Hz51WBQQAu5h0J1xcAACJw13ZiIUBAPAAqE/y/gEAc2uXMPWvCgBZhMBIWtgIAN9CNpbrlgcAJrbEUO4LBgBAg2z+BYAKAJYxpxr7UwYA+gaD7PoHBgBUUj7IXugEAP2EBZBWnwAAhvySktREBQCIhlI0n7oHAF0ttA+ihAIA/m9w2SxlAwCz5t2te/0GABbzMClHLgcAFHYq0zX2CwD9AN6s7MsIADWp6kERQQMAlMvzQh4cAgAG/gDw5/4JAE8IgZeMIAUA0iTcoWhkAQCoQMUKeL8HAAFT185+pgEAOnPC6NKpBQDl99sD2gUDAMqut5mGIgEAyWuTsiMqAQDp5mqlvaECAEDgHgWUDwAAQJevB7uTBwD9+tTstucJAEL7YBV7LAgAtl/MNGcpCgA/3SX9f3sMALIw08MjawUAptFg4wh2AwAucsjz4AoBADe2GLbZhgAAq77ox3l9AAAS3Qi8nPsDAP9wU9g9XAcArBko/gZ/BADtFZKrBtsFAGTqNQpSwwEARsBrIUBvCAC02Q+bV6ILAIvsfkAmHAcAC0+1StoqBwASbbbDUIcLAEqjy7ymUwIAGnAzBAcnBAAOh/lYjgsCAMwA22HINwMA7tB1V9DDAQAa5SKUQPEGACUtzr5rhQcAHAMvp4AzAQC686eAED4EAAQzfSweYgAA8/DbsJYXBgD11jKcLzwPAL1+U9GOqgYA9DgYyZJOBwACEMqJ5dgFAI2DWYLMYAAA85Vb89M4AAAjqUPCeGAFALIbJJMy3gIAOr2XYH0AAABLqUIIlR0HABfYx+URawQADU/LvotHBQBdHApLBcMHAMvBg3c9WAEAxyidzARHAwAA8rGY5d4DAJ5tdJgcbgEA36+VcAsFBABVPOhkgJUEAOF6ol3vogYAnZ0u4KyKAgDo8GXpWSQAADMJFdNkuAcA2B7o8qVSAgAN6GZQJpQAAKVhjZEPpgAA3g/z90tEAAAGPO2pDcQBADuEvXDBeQAAVtDVwFDNDgC5eedqYLcFAKHdayK9DwcA+R85Ux5mBQC4F3MNjHYGAP9v+mTk7AYAoGCkvEDMAwAMjfsKqeMGACgSobwagAUAn6w0XsDeBgCzwVXx5SUGAJYycm8v8wQAzu8FAZisBQA27l4WYXoBANXcTeFFFAUAQqS+K6tHAQAmMSXyQPIJAIhOMZ7ewwgAXqT8pKUeCgD85IYAmS4JAFFJFDtLKwAA6mqWd4loBQD9nzluF44BAIuTtF5c5AIAKTke84YxAQAuu99/s5YEACE+X51DwgMATWp+/mBuAQAdYpuI79cEAOnTBT8uewcAkbDdEpxjCACyes2QBBgOAHtGl4KR8wMArIEXvmhFBwCV4FJRGXoIAN7ELpzFqQcALWV5nvDpBwCGLfIi5KMGAItsgzuOrgIAMq3HX3k7BgDIX544Ao8GAAZ1h7zxWQAA7AxBDpkEBQDirv7Q15sAAPAy0IP+6AMAKdHv6I1MCAANIeYGfMYJAGkUf483gwEAidKuzlJDBgBYYpqJYC0KAJSicAW5FQMA8SWpCOEMBgAJyVMS9u8GALBwLQ7vAwAAxPqXt6NbBwCW0c1wwNsBAEdMU7GPbQEAKvqDgUkABQB13iPEWS8HAHl3uAdNkAAAuUD5SGYtAgCGPoehpZcJALtUGsTkBwoAz9ZLOws2BQByr+usCiQGAJyRut3UHwYAmVa1kenYBwBsxzxHMRsGANYx5jGWAwcA3cH7QyE+BACglaJbnHQEAAZfS/pGeQMA8VFaq8UkBwDz0514M1YGAEDbOPLaawUAnzudwWzTCABhItdwROwGAK6pGHA9hQYA68jCTT6qAwDl4QcVozoIAOszNfXjuQIAxQaoJ9etAgCjFc7IVWkFAA4pCgdPjAEAQTfYhkrSAQAfztT/SHYEAJ2eg5GVCgYAqxeB89UkBAAOwRJpxCwEALSuyR0mOwQAUROVbIs9CQApY49+AcAEAMT5U55VPgUA6m6IRgGyDAA/KSReTSsIALt5u4gZHgMAq7yzRi+4BwBBe4LOqPcAADBxFxZY4QUAdrL1XAUmAwDyjdEoy1UBAJQWoZwNwwAAGTGrJw4JAgC2SXpOYggCANPlmoBsegIAQWk9xAonBAClWVbZTO0CAPkodbMNXA8AM5Is/bzMAgDC2AM2UCEKAIixDR/N6wYAdBF9S+tMBwBcT99oYdUHAIrRbxd5vwAACvZPF2fLAgDQ4Qs5+c0GAD0rfpxRjgAAgQil0sNTAgA9M45EQRsCAA+Jc0vfsQcAjPX4BxgiBgDlizqBkvoDAHJVjcOY2gYAj0ZUVdkeCAAtNV0kmIYGACSisrPg8gIAkhwsomrFAAB4svE57P0FAAbxx/UKyQQAxY9l8s4fBgB6GBgqhV0BAHb7mrXbcAIAq5LPCxLbBwCHQHFdoucAAPDac8T0bAQALYFJ8aduBAAnhAppJQcPAPp58Ok6pwgAKsZhRJLdAgDM2FCuWgYJAPnlxJ7tJQUATGhgBtIiAABoezlwK5cHAGX501g5oAcAtU7RvIeTAgBXDSDfJUUEAIVD6Uz51wIAt+xwwQANBgDw2PMDBYsDAM7xZI4ZmgYA7crF3DRECQAffGafkMcKAHW1H52DGgYAdrvKADjyDAB+Jr2XJlsCALx4GtngsgIADPLMEgqZAwAiJh/hwkEBACAzpfrO3wAAOkmSap42BwBkaJgT+z8HAKwT97grKAMA75fyeO2cBADvHWYncGkGAORU24MGQgEA0FrMwW+7BgCdZpHVyDINADJsqE15rwkA0iRt2OngCAAHHRa0gx4DAJfRnSQevQAAj1YgGMsLAADUMIhxseoCAOaXaYH9lgMAilC/vmMLBgBPKwaeEscAAP0SW0Em5QEAPZIn/aBhBAC3pXD2rYsBAFDVYuvxXAUAP4z1feO1DgANxoY587wLAObqXIO4TwwAo3GOwd6ZCACfK6a6b6UJAFg9wmUQEAEAD4szkBKqBQAhdC6efhUDAInUFyBx6gAAiXBFVqZpBgDsyZ1cUGsGAIdS44bvdAcAXpXARNnRBAAgK9c5TC4FAFiceTZIPAEAgNCLXWr7BACbWAhJ44oNABKve5dNlQMA3EF0WeoTBABbjtyH3AsFALnhs1pGXQIARyjsJ/74AAAGT/Db5tYCAHYyG/yMAwMAe2M6yYBvBgAR4d9ugzcFAA0sezUCvgIA+NTIWO7cBgCSYR1YMtcCAP0lR0RW3QEAh8i6CADmBwBSGHw4XD0KAKcz9fFdngcAz/DF8fnmCgAvOvZQpKMLAH0SYjP4fwQA9LGCrzmOAACrffIuMogEAKShojg3lwEA9xkikUXmAAAnRjnYMS8HAPEAopTSewAAxnTiAL5lBgCLNrbx6D0EAJo6OdnIGAMAhdMdqymeBgCsa8ezhQYDAFlI8jfPZQUA+f6Owip7DQBPWTIcpAkNABn+/yoDXQQATt5sm+QvAQDxfDK8YxYCAN3xaUxeigEA1aF5xsckAgDpJfmm3G4AALh35mODjAYAz/vkJfoMBgBOQAl2wcQBABGKMgL/WwAA5BLFDd2gCQAPzV+/lAgJADacPwFJKQUAxzVHug/1CQAZ4N58J3YFAAvgyiNwEwIAxibrmTVaAQA8K1EhcmgAAOkkCDrLUwIApKI/zLiABwBfME8jvIoDAN4DwbuAogcA/l1pNqiYAwAailJBr9ADABsnJodB/wUALZW2E+hHCwC6PBzCZGgHAKh0zdtJ4AkAm3STD9a0BQAMCsq4TZ0KAJ3biRcMCAYAMace73y+BACAgJ12DfQCAAOmREx9XwMAllrCPaAGAQDQUzMzrwoFADW7PGGatQQAdprhwN8jAgBkxbIrHn0HAMtSEKU4qwQAicDdX+/RBwDZ2rnr6r4HAPusoAvTWAgAj6616pLNBQDSTrBrHAQLAJPVaGclKwQAT3tCWYToAgABB2N2OCsAAOXqBdR4SAMAigjcGt2cAgBI4VbZ+fICAP7BZa3mswYAXZ63cgmwBQCvXUwjjT0FAElAgda7BAEAUPF/1l+aDQAqNdDqmKkLAJmvpF/JgwgAbiYB/Nv6DgBxsA+i8gQKAGft8Wgx/QAAPkp45w27AQB3BLJ4y0sDAIIhLm6ipAAAp5JwxYy+BQB5sOswPTsEAAIZxqWsVwMAVSTWxXC1BQDHGB6esg8DAJEnfLEPVwIARyS4C1WpBgAlIxoK8hEFAO6bI9ckkwoAwxZ1wzw0CwAX4B35xUEKAHUVtix/NgIA34dNwJrDBgC95deLldQGADIVimP0ZgUAMDClXrbcAwCqbN5AKRcAABtFZy5bBAYAs/w+RgdsBQCRbv5ri3IAAN/81e0ghAAAuxD0BE7DCABqoNDA7UQDAG1N2IZU5A4A9GM4yy5ODAC3HTJPZU0IAEr6YoOrIAcAv9nNR0OcAgBjhF+tmOcAAP4Ly4vx/gQAdsH7PqXZAADVtb3dFsEFAM+rpbu00QYAelOlSIrSBACZCwRbjmsFAJGJYfKkpwQASyo3r5GyCwCXRP4oMA4GAAlqT8p7JgoAQrJCwu4ZBwAOPiIUY6kEAJVfsV8CGAcAlP5xg2uNBgB82fdIRIADAIBCeP5mJAQAMd3NxFAbAQDW/6QIRCcAAN00266C0wcAXTjOyc8KBAAeW6SZuygGALzm3OS89AQAbwudxG5hAgAc5mKEXfkJAMVZkZs+rQkA+E2gdaSbBwCVFVbuLAQDAIQlJOJazgcA49RTsV7SAgDJqZvQ86gDAI7rBA1p8wAAwHFL0c0/BwBBrJtEeXAGAE9IIUactwUAjWsV8mkQBgCvEDtXJusAAM6pyUDniQMAFawOV/Z4BQA3OZwz8kQGACxslbdHbgYA0FUf/jJICwBiYl1eQlwKAM653DSuswQAn6wVGml8BAAMQF1u4BgDALE++NkixAMApmWUN0UVBgBu3tfxpgYGAOcHYcTA8QQA2OX73LEpAgAnE3sKxqwDAIRUkQiaUwYABkq7FNTbBAC42/FJCJMPAO/KZqTFKQMAm+tPVCTIBgCbAe8gU/YIAHP30sN0HwIAOr0IjbgkAABRQQXPeOYGAHx0LicxNgQA0VysSl4cAQDG4P3KsdEGAJA6MGrHYgQAm/88aU7KAwD9hlfULJUDADDD3nu8ygQAidJ4P494BwAR+LMJKJQNAJvC+HcylwUAZ/7FO/kQCACxrGWBSe4HAC4KnAgklgYAcwTnyF8HAAATIx2rhD4BADuV9u0LwQIAyCEDP7k5BgDDoRGR4wgFAHovkQ4SkAIAQ66sZPTLAQBXYVfpc1MBAGBbyJP07QAAAEF2hNLEBwDsrAa//v4HAABBgnr7mgMAZf3nR460CQD5HU3FAEwIAGham1lYgQQA2dVBvHX9AQA8Xakf/NkCABG6DvIn2gcA1BkwLrkDBAD4XEaLgS8CALgJ/x2QQgMAzYPGXVkfAwCC1l90V3oDABcmqxK7VQMAGHOMWsfaAQBgNELVebYLAA1Atrf8uAYAnV++gzfHBgAqBY6vjlEHAPS7k3TMZAYA43QYdpQ9AwAT9pYXnhcAAH2G4jUFiQEA7IIhE7j5AAAybH8bxFkAAJEUUwaHngcAgrU8ZEfHBgDklNQKDOICAHWxu3E4fAQAsGZQyFBdBgB8HzZTdBYGABKzi4GjawgAIXWqm/KvBgBIjc4C6o8AAEhP7HGXUwQAKMqtizG5BwDFFuCvGQ8HACONYLF77gQAaWRXuIkLAADQ6t5odt0FAElwpAttCQQAFJEhl1knBgCu5meK2psCAF33dJqCcwQAyQI5rTpTCQB65BFr4N0JAHYLk9G+hAcAZ8i5kgrICQBMTtS0aMYGABjEeUZ12gIAWhC+MUwWAwBf75grrB8BAFaSd68aWgMAPIPEhIYHAgAMgnh6Ic8AAGnn0uckUAYAKqjd77U7AgDG0zK21J8BAKT4VGAaQQcAtHWxGD3lAgDzSiBUcj4LAMTEodXXvAsADl32KsLHBADDWCSHmuwBAG3InbkynQUArKkiXgesBgBxMxEgkgsDAG6WOKbZfwIAE7hPVzbBBwCbUKIA1KQGAByXVhB5QQAAXAduhtVVBgD4TebzKzACANZ8XIrYrQMARjA5WdSYCgC3kD3L/gsDANb4Peq42QMAeRVRlg6QAwBqQBoToRsGAPLcNbZwVwEAcZX3g82eBQC9fwscRtsCAF80galCOgcAecjMn5JJAgApkJUW8aAAAHo0sddPlwUAre0IHMzgAQATH634vXMGAI69yxADYgUA1oXid/S1BgDIbDLske0MAPyjA3VT1g4A1Ig5dtMmBgDOWDZvhOwHAEPWNElDkwEAUapeRKLUAADgb+eKcNAHAOHHw7ZHmAMA2dmkonZ2AwDHLqIdP48GAGtzojmA7QYAdTxM4H5iAgDR50emkOoGALmZM3Kv2gYAj46trL8EAwAHixB9kQIFAA/dpmwXQwgAgx0sjxXVBQA761ieRLUKAEe+PetidQIA5wsXtNeRAgDhqN9nytEFAKKY8mGAqAIAfWJxnk4wAQD+nNxq0hQAABNvoRtp8QcArG7wKBjnBQD8//AH7UkDAN3C1+KNRgQAuwdj+MbYCgByCYWhaygOANNEhLDc6QUAsmIzVGqpCQBGMuYnZNoNAJ5GGZReNQMAN4rquHuEAQBxm8+IZf4BACJr29LJsQYAS7T/xufMBgDKIqzeiMYEAFID/8N19wYAuxnkPmBlBQBGHMZWRFQGAPJ5/qspjwUA9s0Ocb9kCgBqiSeFxQgHAJQzxebqLAwAaSvoIRs4BAC0hUFyk68GAGg+542rzwYAIb3Uzu/mAwC+DVAJZgUAAN+FrSR4GwcAQX9KnGJ3BQCIqMYJRQIAAERmLrFqaQIA2IBLf6LMAACeERvxwccAAOzKsFvyAQcAE8G+fNn2AACjk3z7l84MABooEVqDOQkAVZHaepAoBwBVCQW8pSAHAO1sYeT4sAAAdbgPtcTTAQCYAdxzlvICAPoPg/Gw9AUAQNz7K8ngAgA1WoCbQwkHAIeBf1VI7AYALDqhG02KAACu+QuKNHYAAO9Escu56QAA276xXdWbBgC9MfdHTuEGAKwOJ0deowkAjd94VCJvBgDTz5FB1GYLAK0gV/uP1AIAd9+hIX97BQBFBrr/DlUFADGpmEBq7AUAN/OzThAhAgAUjLzyQxcEAMdzh62wlgcAm2i7XO6fAgA0hxdcZiIBAJPFa056FgQA24/O+GUmBgBXmMUaEJ0KAPufpbs72QQAFz83l3h7CQDstww3M0sLAAAn9nYonQMAh2wdzc4BAAB1dnQRGvAHAJCBoaUNNQIAUiXit4uTBwDM1oGG7pEFALh56rSwnQMAQgg4DyICAgCs4EK6dvICAObf4sZvFwEApQ53SYniAAByexSInlUFADDvY24eXgsAbv+nmhBbAwCQJk/lo/YJAJthnFvQbAcAlRaQsFSWBgAnf7cQN6UHAHWB0qcemgcA1XfGpMOPAADqNAfTmcEEABTMmssixgYAFgIDVQpmBQD7EZ8Z8WgAAJBrEdD68gQAJbY7tx3ZDADEEoFTgl8NAN0VmCda2AYA+ZzNsLdABwBOlPKVGUULAFROrpRBsgYAl4jt/QojAgBxUH1hEjQCAJuWNQ/T1QMA73JJSkhFBAB8feqf0PwCACrSnmsSlgIAsgUqAXGhBAAjVU3HktsBAIlCYMqJCwEAW/BFWr5BCQCmruyLs60FALvyQdtG/QsAOM61u4jUDgDT8J4dLX0JAJwoGJdJRwEAq8fkZ4qkAADjr0tUvA8DAIrlXzEBxwAAdXtXjYcLAgBqPj8HGK8CAP4kDULqOgMAlP/0iwCYAgAelttxkVMDAFzGPPYUIgcAtik79Lm3BQCzo+4x6kkJAAgWWBN3vgQAmF45YHnYCgBToVXISvIJAJOmB1NAfwMAnLbybOblAgBTnK5mQtgFALlT6H3r5AUAHBdYjPT9BQCqBZWOMggGAJrEHYSCIQIAByMdiZbsAwADLvL/Y/MCADmu4jmnCwAAJruI6vUmBADIdX/nkjADAOcZ2EA5pQEAE4aBTy4TCQCMUX3elyIHANaQh1zemAYAJetbVLhoAgDf/paLZNIGAHywHa2IeQQA13rmo4MyAAA5uQy+xx0EAAQJEGZssQEAbcbLIEyiAACBhuTv6aIEAHFihJYSXgAAUEUsJMi7BwC3NTsQBpoNADIg80p+IwcAelOzGkImBwCMJThd8owHAFpJnC2z7gIAUJcvdyWeBwAjvzuDR9cGAEnX1RbYzQYAmDbByQCcAwBonUgxjmsGALXiEH6FcwUAchSqFug7AQD4S63TZBkEAP+zdiC1BgAALQjOuRZ+CwC4PoVXL4gJAMQf0Kye0gcAFee1WWrnCgD2qWGVLt4HABx4lZ3hzwAAPEUcYswSAwB8B9rmrEUBALjpnO8rkQAAdrxDNH7VBADLXqW29NQAAM47c7uw6wcASQUgBWq6BwBpIOLk7fYEAAKm8QqpsgYACtiyWyTzCwD8bvMg9+UIAGzAYM/MuQsAJXnzI+OECADBdoIsgWUEAJce5pr89AMAJC366we8AwCg1Fy1RLcDAPMhV7JTJQcA0xKdTo/9BQDZYhAqsr4DAKjJgjsGpwYA7ZfBXaOlAADvPaUGDMgDABbLscIyWwAAgoHVeiykDAD+nnl+ZsgFAKFQyHReLggAmYZOYdvwAwAwZ4WkcRcLAP2oTdLMXgAAGHnw/buABQBqPIeGNecHAD75d9/tTAcAcbQ3alW1AwCC1E3hJMUAAFbGlnRFgwIARc22z2utAAAUJLDo0XUDADOnJ50H/AQADcWGDESLDACFO8qckjkJAC7fTOTy+AgAsaZ7ETKEDgA7risMF0ECAH8vv4mwOAEAOeo0/VugBAD1XpJMkQMCADxO4P9/SQcAmK/sfFYkAQC0c8QKhqsBAP+nhnwiwAUAd0TCvxIbBwB1MKhzpQYAAHDIZilh+AMAAI0ENvr8CACCs7szcW4GAHZWpKhCSwYAz4WaT27qDACgeOjuV28KAN4NKnjJDAIAs6pwME5dBgA2d1QxjrwHAJgtQ7G/ngAANpdnd6oEBQCx74dW1SwDAJVhL16PRAQARQNGnZFoBQAnGq3gwjQAAKPb2UMZBAQAyqpsokN3AQBkyflWkYwEANCaHo0n7wcAAb2njuUMCAAMgCkUky0JAJbM60O67gAAePiVU92EAwBy0jUaM98BAA73Sv3sBwIAQ2iXHQpCAQBPWTfTmXcGABhgj1RHFgAARfF4Vc5/BQBxKhQMIgkAAJo1FCP5tAEAsWaYpDAwBwB5JgvpK0QKAM59lNjTewcAKCBVwVX7CQCh+VYdGf8FAFEJFYmdEAQAy0ctLb0lAgDqO+eAwHwFAMsfcnUQ1wYAMvGncrU5AgBokC2sM9QGADNwpDD5KwcArQ6i9KxPBgAqQLmi92UDAPNYpybFIAAAdsxC8FnvCQAl3XZJwrEDAHJisVxmHQsAVsVw5FaGCgArYKXgz1IMALzb2J74NAAA846NlI87BwCryiPTwYYHAFFuJqnUOwQAE1NhxKwqAADfd3hkoPcAANTwkw/M4QQAkBHvJkfsBwD4EvWL1b0DALgEs9e3zwQAEu+Jl8KZBgBQvCHj6jsGADW7rUDDJQsA9SvkoeFiBQDTNMTL1LEFAP51m7hsPQQAVg6QW40zAwBTGlN9Mo0DAJ8b1WFcsgEAdZCzIkZLAQAmnwrMFSYDAN+2nLkRdwUAODzpFJymBQCZxaSAiegGAJKFJXGP+QIA7qZUT0SuCgDBxft6ORUGAPv484N3DQ4AuYbEX2eqCgATdp4uBtgJAFaeD7VMpwQAkgFkwtExBQDSf2ydPcAAAMEQZhXNfAUAaoCdJK6mAwBafJCphdoCAK9M7CE3sgYAojpopNPSBADv/Q6HxvkHACXvis64mAIA3mUhCupyCgBu0D7veYEGAB6s/sC54gwAumMbCynuCwB8OoBxYroGALIM9+9TeQIAUsUOriJPBQAkJy6pPZ8CABi9IgzKQgIAztUEhIpLAwA1M2mDtewGAE2437927AMAT6BWz5XIAgBSTdVJUTUGAOFl1L1iHQcA9V73sdq1BQClub4M1uIJAFb+XRfCJwUAH/WPK4qeDQCxYhJiM8MBAIDfeNMozAMApoyW9EEhBwANbdtraQcEAPv8L7Jx0gUAcjF/MV9NBwCBytlnVOUHAA31hjFlpQYA8S3m7IixBgBxSYQ2bcYEAJ1+VMS8rgQA/bVUc56NAABowW0LdWsCAMmsAR6IYgEApQEd822WBwAdmtydvXMJAMkBbScbBwAAXgKOkdiwAADr4p6n7lsHALhNCYQpyQMA26OVv4/YBQDfclj+Hg8AAGolGCOH2gUAYFljgeucBQBkx5N284wBAOoZO9EcbgAAUwNbnmKvCwDk6Iig8QQKAC2o7pz8DgkASqMvPIaJDQA22KihpvMHACNvFm9RrQAAGshXbfVjAgDKOEY4IjQBAFAKr/EfMwEAFm5SAwYIAwALgD1dOUQGAPzevj0guQIAVaNW5oyxBAAsGLxmND8AABPl0t4PDQMAPUe4aB6XDACV83mXzCwFAMhVgq4E6QsAOJPzRq7sBABYHDWEUGEMALMzEvIaTQEAC5yziRneAQCeb2/caSYFAMc/jLI0NAQAmcACQiGpAAAuoLmuwBkAAJLXlWnAogEARBxXsctkBgCygPo2B/8GAKVcidKgvAMAvwHMnraOCACM8y2RyLQNAA3ywot/6gUAr6/KFuUgCQAn3zhAi+oEAKRiXTy8MQAAHghMD/7ZBwAs8mcU1T4EAAnRHgzM5gEA8eja7R1jBQAC0srxCkYFAF1l0J2RtAAATMEYfWnEBwCkoruQyDECAMpCBZPgTAIAhQvz/VWhBwD5h9TlxsYJAFncSxPhSwoAMW8ycFlACQDzJHOKkkkFAAbBBv31kAAA/UMeArGrBgCgEdf6vDICADd/BDzBpQMAbaAoPE4dBAAuGu5jpzIGAE1evf9L+gYAkke6pjX9BQDonekdXrUHAM8N7G22kQQAoWTa0I5KCAC9bglF/OwNALGItJPu7Q0AjrxRGsGzBQAYcAuLa88EAKcy6sc9sQUAHhNz28KPAQDjV48fZeMHAGWpXwVWVgIA7oUMjTOPAAC9cxqZIagDAHBYj0HmOwAA8J6sjsHdAQDCjZme4EwFAHiwLqjUMAUAi7+abEVzCQCsDRAVIIkHAMv+lUDhPgMAZAl61pWtBgD7ywB+PtsIACVI+eEwNgQACUBrapXRBADgtfgt/hMCAOaREaTjXAAAdwHxU6deBgBjYwniPvwGAKxnbbk27AcAsVgHauwQBQAJIQLfh+0AABoeksFOKgAATHnP8WJhCAC4Xv7K3SQLABcyRuDVGAgAjUKSkIvnBwBnwN61Em0LAKK4JDuaJQYAnAsX9LWIAQDrXeHewIEGAEV082Xm3wQAgCcRxUPRAwBXRRV5kScFAE1CQQePnwMAPZJXs25eBABvdNtemywEAIK6hXhR7wIAUS9bMPu/BgDdEteyErEFAOLkT5d0VwMAo+OWevhKCACfswspaHkFANyuWIxOlwcAxog0CH51BwCLvOcqxgEGAHSr7MJwUwQAOhSrj7fxAgAB4SAKQ7gCAOP+iB2epAEAlk3OR7uLAwA31IS65/ABAKrCXeND3AcAGJc+J1wqCABOi7LfySsLABnb1fj0jQQAjwJsl4dMBQBQLdiB+0QAAMPZfYhlZgYAsrBqCnYpBgBsPiTH5oEEAHf8RnDjlwAAzFhnAXLvBwDZ4wepxRgHADs4a4zJuQMA3MxeJe0GAABZmiI4ZZcGAA3D+SOY9wcAuof1aPAfBABTzRsZCsAJACSeIJxvtQcAvqrMXx54CwBswDEEm0oGAOgTtaM50gQAZhAb9SOXAgDD2QTP9EIGAHqboFoJ2gQATXg9N+CkAAAZKX1bodYDANalRlCnGgQA2tPCHnWRBgDEIWerODYCAIPhrNCncQAAMUThIFI1BACBOSgqNuEAAFSWNdh8dQoAjw2xes3pCgB0F3bPm8YHAAu6h8iqLQcAYNpdrPS3AACkmAQs2r0DAGABGKpnTgcAp24Ux7zDAgBfKegE69cAAP6gbx7qpQQAYGxDXGNeBACL0dSo9I4CAMoqMqep9QYAq0TZo+vUCQDk3PMVDxAIACR4Ng5wGgYAIz2rkiKSBQDT6A5ouSoIAMXGQS8MAAEAdHFz358hAADnfRJ/chQDAB64I30n5QcAehQuGuKUBACaDeXdhYoEAPQ9STT3wQEAiWiGZNt7BADsjo8EfZoFAGukvmzXtQYAIiV4HhdBAQAffNombYAGALmaxxsd8wMAaFGfRSCfCADSPcBpuG8BAJTZDOxsVQcAClG3A5rrBQBxy5Hd0QoFAEeKtIBXqgEAd1JoPzOuAABiCbYzlxkGABFlJnwVmwYAyvGT+EBHBgCE9vsIpDoAAA33uDge+AMAEcgXXzV/CwBagTRT6HoIAI7k0t2r4wcA5UUfvuoeBgDtzTQtPq0IAP6v2X7MDwEA8m/psIwkBADiclERHDEEACVpvxzUyQQAUE8Q/BAFBQCdJG4zxQ8EAOEt+zlmOAMAeHvRcfi7BwAEgH5reV8HAKEPv1jBJwEAdLlRrsSPCgDT29K/iW4KAM5ldqAi4QwAwgU0ILHKBwB9Fp1Hgu0EAKJ5mC5CfAEAw/7IRlmKAgB3K5EuszoFAKXgn6BNtAcA9H7Qh+9UAwB12cVgIrUDANwfFzZonQcAu9RA8ZTZBwBUGFYExLYBAJJTIC3ZAgMAZPHg5LZvBAC3ZVKtlzQFAPyGE6Db6wkAO2qzDC8wCABsQuv1xe0IAD0opLyiwQMAAi+7xzA0AgDCi7Ub6qMBAGFc3mNXJgcAyvF2O10OAQBnjtpT1r8DAIoqyD6VhAUAe3CnjyheBQCBHZPDXzkFAMthE8VGWwQA0eN/it1NDQDSGcZBzM4KAJBNrGJlOgwA2L2nrKXvDAAhIfOuwMENAKF/TzG/KgAAKBWKntGRAwDHX4kT+qIGAJGl6t2OnQAAt9w2+nsXAgCP23n6vBsAAOFmNutL2AMABCKBHZIMAgDOMjs9hN0CAKvYh5NhrgQAg/tbmER+CQAhzCbGMk4NABeB8y9BlggAaSQa1kGyDgBCuuWrhVYHAC6jRFOq9gMAuxEPaIOWBgCqI/aBNUwAAKXLdVivAQcA83uxkQ2gAQCy8mHrMwkGANJNKuk/GQUAPvRQpZXZAwA9iDq5b1UDAA47YptSNQEA64Mu4rwWBwC4PrgwAT0DAKyv0LoqlQgAiRvTTvYJAwAKWVGgLpcNABjV0a3X2wAAHiPiI/gZAQDifV5u1lEEADj4cJnDAAUAo1ymgVubBwAReI/cIKwEAPoB9amJlQIASmtq0hDYBABZspYN4O0FAPMFWcnp9wQA65lSNT1ECAA47lp9fZsLAOs0L5pRkgYAeM8kSUDkDgBJFErsLpQJAC4wgVe8SwcATOyBuzUxBwA8SGEbZ+8HACnXzBRGJgcAOOaSrZMZAwCSSSOuGVMEALVP0kedIQIA9mywiETwBAASSnKeqjoFAJzvFFOmoAIAJ3kcPM0aDgDleYe3RosFAPJ6vqyaNgsA03QwdLAJBQCh3rY53FUIAMIn+fd/kwcAtqXGFPrCAAB80G3bvVYFAAjRecGs9gYAwkeGIW7PBAC2W43CfCIBACN29b/pjgcAOokfJLKMAgByZzweVFsCAKIKcQejIQEAyYN0xz5xCQDK+tVyBfcGAIH/Ik7zXgoAhxEUT5RNDQDSzqaUuycFAJdKA59eXQMAm7yFlwYmAQDwT4XHTkcFAMpIowKjlgIADqTHdvwzAwAuSFuZKpkFAMcqAAfHjQcAQRfQlGOTBQAX7xoopPsEAHoKsmmQuAYAZNvHtYz6CgAPqCqY5hgPABoaGviVngsA+mxk85TnBQA5doowPUcIAA0icGJBoAIAJdBpiyRfBwAnamUWvMsBAChn4tb/uQUAPqc6EMI7AgAFnlgDJnkGAF1ZkpjbSAIACC2tPKUGAABzuvdQAQ0CAEPg/Tv3AgEAmhxRteDaDABV1OD/fyUFAIAh69EIQQ0A+a6bD8yWCADppF1yvfYDAMZFV3+ruQAAYx3S+PDKBQAr6gikvt4HABZtiZPbngAAwKVe0pdlAwCsWGAQe40FAGnuC9L4zQMAXgFlt0wKAADJfHwzMmgDAA2mncHstwcAiPp8p1FKBgC1Dcpw9JwKANiYCG4LtgQAx+b/3QRdBQBcv2HG7TsIAA1pXGk8NwIAGM8NUsjABAC5lHRLr4QDACUioo5KqwQAQxdg11ojBAD1dYkHDcsAAEsMUz4xkgIACaUkkbuNAwDxEVpl0FADAAbfDCvO5wAA5nBL2d/+BgDUv0WXPzgKAADDxCeuvgQAPz9qQaRaBwDOrjhhJRUOAKOFjMQ6ZAQAkrg1J4yHBgB32PQjNaUDAJ3ui+0EpQMARvvYpeBmBgANy3BITvYDAFdlbbFIFQYA85Y1d2GiBwA6XSdfTXIHAE1RDYG88AcAjRNyc62dDAB0ENPl3kUHAOLbf16lsQcAoW4Xj5i6BQBa7N0HqdMJAG8T9CakawAAILcGBvzKAwDanDWi8BgFAKfsb+Tl+gUA7Y7P2/jRAADcgdA+MZMGAEIXkGajsAUAfsqkLIcMBAABngCUgPEGAL8xSrQRAAAAXKcKamkfBgDKQq1XCosLAMj9Brea5QkAzL9u1AgTCABQKC2KmD0GAAxsxj9soAcA+0e6wbrJAQCOA3XFNTkCABOcxXG98AMANegW2UisAwAuI72vUwcCAAJg0B67HwcAOq+kR66cAwDC2TQLfDMAAIo2slKtPwMA6M8ixNDIBAClcVkntGAHAD2tHLyV2gsAdXNb/1HxCACmkMtcNcwDABYe5MXGSQYAgKrm7mcGBgCQ4SsYnRcEAHlpflbZUwYAbSWaQg9sAQAxkT6QQ5QGADbd+cZKbwEAU5LiEknqAgBd0mg+ZLQCAOe6JvTqMQYA6A1wo7l1AQD7SKoAX3wHABcDyoV3kQsAmJPHsqlaCAD3ZfbH8jEEAJ/+ZtoQBAEAfda03IJNAgAtdRcO/uYDAI+wyx7e2gQAkeqxSJZZBQAZe4+FRGMCAMBaKUo99AUA1KxSXKdCAgAQDSKARJMFAFMS+RVHsAcAxrrmxIDCBgBudmGzo60LAE47XBLlLwQAIqxKTdgRCQDdfKXPCo0EAEOu9qwovQUAfZBWj6tvAQDy1RgSsawHANu0IyDgHwQAZS9cvzebBQBx5qt95CYHAMH2RudF7AIAhkbHUw5YBgB0P2cEoe0FANM2Exk0YgEAQIbzH9acCQCoG7TExmAIAG42pwz3XAcAHgFs8agYAQC5A6IHV6IEAPZ/JvbemQQAPHcIgYVuBwApy93FypMGAPSfCtARAwAABV3N/v3NAgBq7fZTimYHAFYlFC66AwMACQnBhAWIAwAdJgoAIP4EAORI0pYYcgUAO9rQoZFQDQAKBcHHv/YEAL6pLs1OTg4Ab76L8rF+CAACS/xakzwIAK4bGP0XVQYAbYF2LHflAwCKiUCWGBkAAJl03oQq7QEAwWNP1+14BQA9DCtJxnYCAC6Tv0D8mwAACzMf8eiIBQBuwk1pbtEDAIwokLUq7AMAuNEyrgk6AQDktFq4HugLAB6uPKSseggAc2NS1wUvBgC6rcZmv+EIALl72OR70gAANLRdIydsBQA3LaYObi4HADnobtBMZwUA/ACiJVzdAgB+iCx56dUDAFW8q01yGQMAAAhoeHy5AgDd5jTd368HAIiuNYtUMAcANOPWoUsJAwALMOOnJuEGAMX7/K7AiQgAgmWDH6HuCgCDh30nooUFAO64qMujUQUAhtjiK0K2AwC8iZZB4TAGAFWppwc7ZQQA2xG0QzQEAwBiidQzgl8CADH0rwSPvQYAEmOa/Qf5BACb0jfH0w8EAPkOlXhiZQcAis+G6qNzCAAtnPur4uAGAO4z6jgqDgYAGP7zKSQLCwA+YUtIv4sKAMDIH9VZzwMAGEfe1qCgBwBLt28+OlwFANVPiF8TUwMAhBuMChb0AwB8bBNvXC8BAEzeN6Lb/gAARKu/zrx5BwAJaU0/qa4DAI8YWLOc5wEAboHg9dhTCQD8Ltu7M4UIADCUEpaXFAkAQoYWNm56CQAendNSq3gMAPHj9+7DNgQAJgAfwtP/BwCpLQrye+cDAN5yhPy/GAQAs6OzUXldBgBZ0VKS06QGANTsAFnjkAcAhneXvyUHAwBToDUWXAoBABKiEaSHbQEAcAVO1eLVBAB0Xz+z1+UCAL9+iD/epQsAtjlhvSTvBgCmpXe1kPkJABViBkJafgUAdzaYRIuhAQCPbx7eUuYDAOvYLuArUwYAOF8WyIePAgDW9+gbrU4EAGb0MU+ddQUAQ3n0SYE3AAApTyvjO58GANY0Ff6CWAQA5G88lCmZBAAVW1RycDQMAMTn185rIgsA3ontTBM6CABeQM5D+NwHANaDeXVdNAEAzcw0QvUiAgC024o9SngBAMwrjO6+bgMAb2KPW/6IBgDAMkdKSNYAAJItU8ZKuQcAD4VUhxt3BQDIYRTf2Y0EAHEy54eWcwYAwBoMyJ3MBQDN1IYUZ4MGAHOBXhpfbwcASt/59dPVDgDm12iPC9oHAKZ1VjgUIAAA7x09tV8VBgB8kokuo34DAC6o9WimWQAA3NShqxVhBAB22rXDUxkHAIF60zMiZAYAvbF2gGXJAgD/EDDmgaUFAHQ26If4pQUAuUOmoNMoBgDSkwxk2BwIACsP18qwtwgAvUSBqU2GCwAbXS2uNz4EABE9oXDPAQMA7JEYuqGmAgDgOj/7kfICAFLqS4F7GgIA0URuZZtmAwAz4abtBj8GAA8HWCc0MwIAdcCcReCYAAAbfGytXt8EAF791GweogYA0LKZZhIpCQDnPWCiEe4IACBMx/XCCgYACGgZKhmbBQDoAXCwcVMMAF/mRjAKFwYAOJ6kRhpABQCoxGFV3QoCAEae3u20qwcAXxkan7+GBQALefhejQgDANu0/CYhjAMAw+NJ4bqFBgAw6aQB1rwAAFIOeQP76gAAHa51D16ACAAnCoZZzGQMAO4LsLflSAoAdI/vdZbZBQA1VEw040oEAC8ESDfBVQUAwDJCdUHQBAAHaYYwtCEFADmc+0COMAMALKB1xqwJAwDuQ6W7uYkCAJ5TKC5ZqwMAOtjNq4JNBgAn43LBjscDAEb5tyFSLQYAKXr3OibUBQCwroki3T8KAOu5fvdk3AcALEA4g9IbCAAhOTilKU8JAG2T0BicKQQASYpBg0GRBQDVriHHGCoFAG2XgrpRsQIAVMdL3u/ABQD117Il3H4BAO4bCKY2cwMAw+WHiDG1BwDhWxpJbZ8EAOC+x2Uj5wUAPrMILwY5CwCxz1fm87sEAGdZbvX3eg4Ajtaef9bbDAAzt1xVIAsHAH8hcUUH/AMA62orm9KgAwCd5d3MeGQAAPrdGwVNXgUATnvEBBF/BwBMLBFVxRMBAMq3+QNRUwcACCGaHe1AAQCvwjszIiUAAGSg9JhD4wAAKBlLPgkLAwASA8h+fs4JAIOP97115QwAOO0LGXofDgB4o2ztrfgGAOi9zj7ZIgUAz/bgRfAkAAChzyY0tm0BANgP0x86uQEAYqNoU0DlBQCasrf9PRIAAGg8UlZDNAQAX+4heVKaBwB+gT7L/EsHAD2N7HLegAcAcif0APPqBwDjTDWIUUUNAKvLPUrK3AQAy+u/0BTTCwBXK9Nq/N4BALznmghFhQIAXMGg6Y/jAQB7N+LgRiABAIWoClYccgYAKBlnvyjrAACnlVHvGr4DAOu1vWIv8gYASTBSuGiXAwC9/fvIlDMEANKNvwHSZwQAlud6Vr30BgCDtxeTyFoGADKJ/SA7fQgAFWkyCPIACACDo1tanO8KAK1P73SakQYAv1IUYdSeBQDvCeoE7JEGAITpACfLywMAPLr1xEMcBwDNdJ769m0FAN9Wz+SVnAcA4gnGO2S+BwB46NkqwUkBAF8MOcpYpwUAgdxhHYuRCACb0QwmUNMIANi0N06rogcA1xRUc+ofAgCdY38COKcIAJUkRtkQJwcAVnQAqq9aAgAbo+ooH9ICANBfAOpxdgEAtz5LJK7bAgDM4f9XL0oHAAFzCHMwvAEANJwB9FfsBwAkpR8uCE4DAGoSNaaMaQIADtk9Xi9wBQDHxXBKmhwDACT8eKqlNgkAAHufOy+ZCQCir8SwBMADAHi6sDKIMQUA7Hzxn0vyBgDHYOAwf6QAANDIDVSEgwUArpzE3EP7AQAruPQGrEYBAFVzntgAtQQAEopyHB41AwDjL5NpnwsBAP3RHNA/tAYA8w52PlhCDwC3FjJXwT0HAEpx1/1IrgQAA+ETil/4BAAN/9ayIDQHAETFl0ZLXQcA9Pj3/+EbAQDh91do4RkBANX1XDQUigMAL7UFcY2mBQAGHoWey/YEAOWVGEfEeAIA5GQ9zs3vBwBMS1xFbU8GAEuj/jJW2wMAwiWYgrGQCQDIJTJR0+cIAK2rt+MrwQkApZweeHeHBQDyXUnql5ENANjZXfcr7gYAjb406yzHBgDHXjTMyXkGAKSYaPmNiQcAdZ30rSFDAACuWuXkGWABAJwgXfLFTwcADe2dk2pWBAC34BbnY2AGAHBNH9yvXgQA2rHMzyRGBgDBtnKAq1cKAAlvZyUHEggA7Y5O0BigDABs1aXuPPcLACvXRYCFAQQAMC3K4OVZBADqizAZt4gEALUyGw1KbwUALTaAvO6lBQDGjU4K0b8HAPQ2ZzaZyAcAAVz56rteBQCKP5BgsG0EACFmEolYYAIAL+V2xjyOCQCPqZXZeWAKALEIeSF8SggAWWXmA3bcAQBEJAuh394IAAT/YIOmBAcAPovePMzOAwD/ZA9H1RwCAIk5lY3BqwYAFebkwtBKBQAqUiu41WcDAMd9Pbj00wAAjcXbTH8GAwA3eWnaUgQCAKl3qivLLgYAdCi2rzYoBwBAspQgPK8AAHo1fymFwggA4taAVi3MBwBjVgfVExkGAD0rFWFSeQUAvTz6utuhBwDViCXFMa0FAFxoZEE6XwQAbZaakZ/lAgDaMTIaNi0GALgBTgCEUgYAYB3pO1NWBgCfqABsAa4GAAUcEyq83QMAFLuWJ6JXCgB0PkT7YPMGAOrqIHLkgAYAGAzxpfL8CgAfg42zf+4FAEvFXs75DwQAW7Nh4oVxBQCpcA5UVOIDAPjjA0CBtQEAS8BKMWiJBwCOakRBy/0FAHEq/yZpKAUA9rOW4jHyAACTRshXo4QGAKC8yTMGHQYA33P8+LwoCwCzlf8G3rQLAKQRuiekCgsAm23avzHuBQBngN/COrIFAGYl2/81SQQAbmwXbQEvAQCu9RYPsPsEACpAmY23+gMA7XqE/WXpBgB7UoDuU7kCAFqzsc1bXwUAZjyiPws6BAAKgos4B24HAF3ZnbubmwcAYXOfjq59CQAy2gJh9xkHAIvKgCp8EQ0ANQldtmYaDADKrGAUgboJAMImMWpAVQMAdn1yGBkNBQAOjkkL6uUGAPIUMga2owAA0p+MFV8GBQBUmUIM+2kBABDu7NntmgUAAhiF6xaZAwA4xVxVF3kFAE+K5TkfmAMAy2/mbaXfBQAIWQcJiAUIAJNKhcvY0wYA47Fw6fSyBQDBy+1SRA8LAJMKI1l1igMAH6OL3hwsBQA9WnTU8qQCAIqi1EKdfgAAzVpwg8CNAwBAl3XFgicFAK2Q2ZczPwUAFU3oxzmpAwDgOX4ixDQCAPKTpaHZMgYAlIQM7RH9CQDgVyftsyEIAMXBj+UdPgcAqxZGyBDRBQBkryjfp6ULAKbLB7gVawMA1/4anor3AwAfj2AsnKUAALeBy47dKwUA1H6ESE+yAADH6htRvtQCAJtbntmkvQYAAU6Rlml+AQCAz3/O8LEHAIFUR3TPTwMAharPeKsdAwC3VF5uIeMEAIm2czmCSQoAhIjkhElYCgA2+0IwmhEIAMpnl3hM4AcAMrjPKBtnAQA3xeGifuUHAEFBRO+q+wEApt9kwb3TAwB9F8LonNgCAPQsGLoSzQYAl3aawYoKAgDZcsyy+jkFACDeHo8IbAUA747zJKxfCwACq5dhXNcHAKcvpMJLPgsARIG0EM3HCQCPNUjqtzgIABduqBARPQUAbUZftm5BBgAgzl8jphwEABK7mYr8wwUACJG5xnSWAAD4bzGZIfgGAOnzqfFUXQAASie90MW8AwCt1dK4hLIFAJ6WJRDj5QYAD2IGYw77BABg5keX9TAJABnU7I+GQQgAxTuSjF4QAwA4GD3UigULAPuT5Yf1YgQALTbOp0vZAwC3Zya1+TADAArw4Eha1AUAjZp4FFGPAADQY3bl/Q8EAEcGwtRFFAcAfA8XaD5lAgDWXsXj3kwGAD3+TvpJZQIAbmY/r0mFBgBou9RBKZ4AADz/XR8x6AIA0vsf+Z5CDgDiLBP+DaEDANb5ax5GWgUAgy6w9O6OBwDPFoxkT9MBADJRuirqfwAAHkDGHW6SAQCgzhfqik4HAA+8P/hDxwAAVVS/xAPLBwCYfpGpi4oGAOVh2AEd+gEAq5Tf0QCsDAAaJ70BIboDAK/EuYiJVw8AfZ/0ib/yCACf6Y7Rzj8HADKYWX2UVQAAkBmkKv5GAwBbGXmATBYAACe6e/vMmQcAXKfGO1ZzBwCznBNjCOkBANag2Qe0+AQAaU+SyiSOBQBWZOe7RqIHAGS4Abcm9AEAPyWhkcg1BgAv3o7T62oCAAWu3frIbQYAhjegQX0cCgB9+rOxa7cIAAEckUFMJgEA+b2ERfQCBwDejsYfUTwEAPk17TosSAAAG9NxUq/hBACbk5J/+cEAABfBbZWIegEAx535XgDuBgDMMbJykaoEACp362HdtgcAx9IBq/mrCADlCmOHAogDANvtWwTKLgsAzzJfNkN/DQD1v1m2qT8FAJI981DowQUA9fa5mhHsAQDpY+Ztb/EHAMbeFsvWpwcA0vHqvOkDBwBVVIiU6cgEAIKtnNq1zAQAdekQxmtZAwBen9sNDKgHAGFMXD7ZmAMA8uPn0mB8BwBwOHZREAYEAKrS7ODEewYAuXMTH5S7AgAwLADJyZkGAPNI4jNn0QMAieNL4bfiAABKePbaDSwEAFB4xh/qiQUAkfHdtQk7BQDM8UZZI6cGAGC+L7ucuQYAYlxI1qXTBgDAI+lmlIMEAN38xjCvHAUAtFSsGJr5CgBu7mGWo5gLAOLNQB4zhAMAphnexBXNBACOnxic4ioJAArgdHZCpwMAwXR+Ty8UBgAVOowxk8wEAOceK6wb1QYAPziSokpQBQDPAQ0fy8AGADPV9Z5GhwEAv0c3iDhxAgDokDrlKvUCALqOlf4U/QUAjsuTv17+CgCH58uK2iYCAKF++6KDCAEARM9CeHCUCABccmD5c90HACyrRSjfLQQAu3Yy/U8hBgBGUhoYjQsAACDredWmaAIAR4blJv+TAAApmAVo/iQFACG2fOR1WwYAGczVpbBeAQBanZKzCVIAAEdryMub9QIA7sKRtmDVCQAHzuP8uvUHAGyAFBZWzQwAh7FwYYtYDACBENDjVaoKAF8TF5lCfQQAcPB6oM/qAwBEbrRGq94BAN9spDs/pQcAGuXiQotFBQBPRAcM5pIBAKodokOIrgUAOBULkSHXBgB+QaaVGjIDAGinqASQPgEAbIc7GckABgBldw2KGxwKAKGOs3+SeQsAGuDbeXYNBwDpjYlAYPQNANvOL4NFiAUAc24Mf801AQBb4+jf+z8FAFvlBl4ZLwIAzkuB6Dc5BwCN9HspFnEDACCXBg2eWgQA7ESnGvdaAgCjq4rL8BoEAF4diU6KzwIAomvQF35IBQCWZS0DKocLAN9Ik8AoXgYAwkDOsmt7CgBpHYny96YHAGcPEQeH/QMAsi2pFodvAgAnMHUbqs0BAGEmtVi+BAUAUoLl1psEAgBJ75pqjf0BAKFvIbdnywcAgrnDU/96BgAoltoQpg4CAFlU/K0aAQYAffjLAsjQBgB7TFXtv0EJAGJC72e22wYA3H6FJjGPBQBAk3eL4ZwOADz4lc9tkgcA7CsOEiUuBAAV+vFt6T0GAMz581Br8AQAL7awwVz8BgDLeZiyKFUHAD1aEtKPmgcAuGp0S418AgAMIQI/ifgAABBXrrOWVQEAyiRRfhYxBwA/4bvoOHsJAFWQL5Rb1QsAPpG+lRScCABs+xokTqoDAKJ5kT/SOQcAxOi52/oyBgBIDP4rUsgHAKla74MJ7QYA9LWHdiPSAAD1BTMqvzgBAJhl2CRd9AEA/mAhrUsnBQAq0VgdBLYBAHpo5KbKLwMA38yHJ3OkBwBABn98Qh4JAGOMXzhZNggA+mt22er0BQAAJmwz9kYHAPWafcWNbgUAeE++F76zBQBLL/iMkr8DABFvCmBVLgUA1uvvnH5iBAAcl2yrRfMCAOnnY24oUwYArSOKt2EQBQABRbWsmUkBAGbtB3CRtAcAyqJT3SgbDACF6odf6HsDAEFeqNLjSwcApmzJ+oe+CQDMCP4gNtAJAGSwhKtc+wUAsIWCdz5RAgBD4CUxOFcEAD0ibrWjvQYAT4RvN7oiAQBU5bSizTICAED4D6MrQgAA9UN7ZudRBwA+X9pVFyYGAI62Ur9wLAAA4XKNRb8yDQCbtZbnlg8MAKKdb533LgIAd8q+Z6sBBQBD6z9+abAGALsvC11L7AcAUFRZEOkAAgBecQVxBUIHAGAPUyJw8AIA7wmk8DRjAgDAo2LfSvAAANm2i7Tt4AUAA8D7pErDBwAkrFxOTtcHALJBNPQ3zAEApq7OyfFWBgDsWq2sHAMHAFdscdCMMAEAQhmUcxMcDACV8XL3RqMLAE8yx1xaVgcAEUok1aAcAAATh0FnsBYBAK7tVYx9pQAAAzgQnIDGBgDIatriElEFAFq6PQo9NgYADPSmi8kZAwDHbqMDS+gCAHzv9rkRWQAA3OouUfOsCQBoKmk5mGMKAAYFgzSiaQYA1AMGDJKLBgCyZByd71UNALsO3/WDmQMAJpiViSXqAQDWzQOHY84GAAWFiXgWMQYAcKKaz86zBgAIvXM7unAHANSG4fd1FAEAvCuJyRslAABazP+bq04CABc4E970dQYACrPaO9n2BwAl1L+lrPMBAGCXHBxS+gIAzfknzoAhBgDTLIgLRQ8OAPyCF2sDUgQAxYF2sJUtAACyBZL5HJAFALTsXm5okAIATBZw35k9AQDKwOUhw14DAClA9DfjOgEApy0/gY4ABAA6DI4vJ0AGANpe5eltwAEAqmlt/0ArBQD6fzcJiBsLACtM0VxiNgUA0RcuJa8WBQAr0+f4loAHAOLEPqPWegcAIdMR3MUXBwDkI5hVFKEEALHioVDOBgMA28L+oTjPBADnXPoNZaoCABWU8agWSQUAeBLnb8kNAAC4PuaEJ18FAJFgotPKcwMAmrvdifuoBgA3ftnVNYwHALIs73Q2bgYAj91TrEdDAwAqEaXtRxUKAHz1yYJNYwQAUtamaJIkBAD3L39obTMGAKDZJk5P/gQAQVSUPQ8EAADThln9OekFAN+bAUchKgEAspzQ52bEBADdA9KVW/oGAFSiNKNQNQYANntUckVYAgB3ExyBWFwHABsXzDfG0wwA4jR9dDA9AwDXp/q6kpoLADfPabXt1gcAoCzcpZQBBgCmEF50Wa8FAHVIAD71qAcAeK99LKbuAwBOJ5PmE8cEAKSzbnob7QYAFY59ac4qBgB1sCopuGYCAJxcZqA2hAYAaRAg6BfTBgDKoyxdgZAIAKCZFOvxPwgAGONQ8GA5CgAQFslpNjcNACc/LyDoNQIAgBe2Lp9MBAADcB1bkDAGANHqdNLI/AQAeKtof257AQBXUg6aqxQAAKWLf1Y5mQAAgjxCKnu0BAAtxHrl14gGAIePZ1pLywEA1AegomKqDABtLfY4Dh4GAIJHzI+ILwgA/xvygytWBwD2LtjSD9wKAGz8SjlrwAQAzDb2SxuTBAB4IzLQYCsHACWLgcYnUQIAQ+eNp7wwAwBOdBkRhP8GAAWT5OhgxQIAeqXl708lBwDfp2DF4noGAPFps+EbwwMAckLL+ZO8CAAsGHPb+fgDAMThuuo1sgoAGVUph7/dAgDV55cQ7BwEAO6KlAhNhgQAHvaNQzfSBQBncB9ghbICAFPX5rq8XQIALSY0EbYwAwCKgG2i1xkGAPK+rcKzwwMAUn/snnyHBgBttuHrub4DAIfykc1EawIAgwNzYpPyBwA2nEVRef0HAOdJLVFMUAcAX8U7fu2HCAAlx0kBsd4HAHV0OI9HSAAAPopn2ZeTBgDzdslWgXwGAGwiiVVN6wIACsHB5gnHAgB67maHaq8CAGzZoXmqigAAsC+b1ZIvBAAHnABALHUBAM5i/+lojgAA+fK4CtUJDQDk5Xskq7gJAIXksuay2Q0AOBOaR6X6DABwj3O9E8sEAK0wwUsKUAUAlYaTeqEnAQBt4zT6JioAACjMHi7RhAUAo+t++PPxAgBKthXldYwEAPAeB1JpWwcABlSWQm3UBQCfn5gGYXQHAOIKPDUemgEAvb2W1c1yCQCDFojfHXMIABSBT9YmBAkA2aOp2E8aBwBqJpA5vTYHAMMF+rpgdQQAoy/Mq9wYBACChs/OkVkDAGCMS6lxQwIAwyAcsUYVBAC0szSTUC0DAKpwriwQbAEARfQb1Q1yAQAhmK8vZq4FAPqHK1opEgQAs+qT4mFSDQDLZZt1JmQIAEdqEa5lAgQAvOW6BCPABgCtldG4C3YIAOnWfvWImwEAOaMEGb/NBAAsT07NSSsEANkJGXcuGgcA0lK7PhVOAQCKgebNFxoGACeIEDStPQUAtlVcxTIrAwCjR5NfFvkCAKwzvOlLswYAwPJxZWVpDAA+Qm/OYaoIAKAnG9dA+QsAadFznfGFCQDc5mJ7nBsIALLAeDpkLwcAe55PwEXeAwBc+jCN1gYHACQvjj72lgYALZLwGCwBAgApncha5VUDAAFx7BS06AMAkAxSfLCdAwDh73ebHvQGALrkhLf1igAASyzMidIUCwBNvPHiUDQKAPOSLzmTzQgAfGuUagw3CQCX/VodPEIGADMlH4jcmQQABsV2ZPJOAwCXFHTSB9EEALP9br3ERgMAoWMR13krAwBqs/zt2fgFAJA5v9zo5gEACvOKNE+XBwB8nPFOcuYGAOITvO+lgAQADCLOQuRMCQDLFiWngIkJAHZmuA34cggAbVLaHzMDBwDIkXbUMUsKAHEgYgEL5wEAaqH4tWPxAQAX1Bo0r2oFAPcw2DWWmAcAe8sAdqJ6BADD+BXA7R4EAEqF7yeNzwcA+ZNGWOOJAgCnCbNXeEoAANpN0YW1RQUA4SGz49DkBABArNLjH0UHAI2p7nj2ZgYArf5nhoU4CACMTObDLdIEAA861KBeJwcA98zXfROBBgA4mre6nOcBAGqmiUQhKgIApSsznC/2AAA5XzvWiWUEAJY/7Hn56gcAqLlyFejrBABKaWFdfxsCAHFjowH6wAEAPWqTjA4rCAAgzbZYO7gGAIAm59PYfgMAYiqf2zegCAC70rEZVAAMAP89lCK2BAYAWBp09pnIAQD7MvLiGQIGAMv5p5KuXwMAyrHzFDb6AADwgr65vf4DAAAUkpVI5wUABieCOOpTBQCMyM8kfKEFAAr0rhii+wEAlAF7PgRXBgDn6e9VG8EFAPt0oMZ7cwcAzFXjHOTqCAB19z/RNcUGAD71yPpIlAQAajXoxnRPAwCi2wcGeK0AALY+tn46IQcAhoyqrOOSAwCvNYo+6TQFAJfJAv0QiwAABR64rMJqAgB5O86YjJ0AAKxQTf4XXgIApyHxdvV/BwArcvyw+eUMAMcoDZuUbwQAJu8XXebNDACXlvgoqLsGAHb2BB7XmwAARaHyQchaAgBxOIKsfqQBABpYbMOoqAEA+6lCFHVVAgABOf6QZrwBAFq8Wi8TFAMAKNUyUYMRBgBXirSOS/IFALf29wTVWQUA/WbS9ueRCACIcwPvYGADAIYSHeyIhwkAr45HHESHAgC9VDNq6iMBANVU67N4gwMA7pSPp6rUBABNp3XoAqAEAHyxZxOFCwEA4wdYLbEaAACWLeNBkBgFADECCSsGWwAAj7fnZhfJAADsOKFVD6oAAIqRLB6WowQAHj8j80TWBwBkwAKen8YJAJdoJuXlagMAeYvT2sGPCABAvdnqzooGAKC75vjgOwQAO05h/N+PBgDgO1urHekEAPAvIcnUsQMA27E/zmvNAgAQwtfzDskEABaHgaD1lgQAuDnCjPicBwDb+GwwnMsCAI9QWw12lQUAkCcC/evLAgAFEewqgrgIAMu8JtLP0QwAvXFJ+rIVBQAVRfVdLMsCAJdjqgThvwEAJWyZ/5QUAQAAWD5iUUIGAL5E4MWf1AAAKcvtQ/oJBwDKKv1jjF0CAGH93ynNxQQABa9I68AuAwB8t/mRk48BAIEMz54CDwcAubAQXqqvCgBMJVWD4B0GAI3C431Y6wgA1Lt9n7vwBAC9dCpayk4EADM+7S6zBwMAwug8sIp0BgC8ELiaDXwFAIzpJKJkLAQAFMOm2NW3AABD1ZV7MkgEALqk44FmFAAADE7DrRSHAwAwjikOb/IEAN7HEkUicgIA/HWpQoq7CwDuF2u01fIGAOVwMSKptgcA5rfjP3FTCADBa3/9NZcBAC40xUmvkgQAVwNa31w2AgBgu/+nOCEDAP5GRtH3oQIAzESK8V0bAQBmQshC0JADAHXcjyrj7wEAOBKu516SBgAy6NCBkq8EAPgdGRH5/gAAUHVibGljS2V5QSBSaXN0cmV0dG8gU2Nobm9yciBwdWJsaWMga2V5IHJlcHJlc2VudGVkIGFzIGEgMzItYnl0ZSBSaXN0cmV0dG8gY29tcHJlc3NlZCBwb2ludEtleXBhaXJBIDk2IGJ5dGVzIFJpc3RyZXR0byBTY2hub3JyIGtleXBhaXJTaWduaW5nQ29udGV4dHNpZ24tYnl0ZXNTY2hub3JyLXNpZ3NpZ246cGtzaWduaW5nc2lnbjpSc2lnbjpjQ29zaWduYXR1cmVSZXZlYWxDb21taXRtZW50TXVTaWdJbmNvbnNpc3RlbnRtdXNpZ19zdGFnZQAAGQAAAAQAAAAEAAAAGgAAAGR1cGxpY2F0ZQAAABsAAAAEAAAABAAAABwAAABNdVNpZ0Fic2VudE5vdE1hcmtlZFNjaG5vcnJrZWxCeXRlc0xlbmd0aEVycm9ybmFtZQAAHQAAAAQAAAAEAAAAHgAAAGRlc2NyaXB0aW9ubGVuZ3RoAAAAHwAAAAQAAAAEAAAAIAAAAFNjYWxhckZvcm1hdEVycm9yUG9pbnREZWNvbXByZXNzaW9uRXJyb3JFcXVhdGlvbkZhbHNlTWVybGluIHYxLjBkb20tc2VwAAGoAQABYFNUUk9CRXYxLjAuMi9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9tZXJsaW4tMS4yLjAvc3JjL3N0cm9iZS5ycwAAAJL5EABXAAAAYwAAAAkAAACS+RAAVwAAAGQAAAAJAAAAkvkQAFcAAABtAAAADQAAAJL5EABXAAAAdwAAAA0AAACS+RAAVwAAAIEAAAAVAAAAkvkQAFcAAACCAAAADQAAAGFzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6IEz6EAAtAAAAefoQAAwAAACF+hAAAwAAAFlvdSB0cmllZCB0byBjb250aW51ZSBvcCAgYnV0IGNoYW5nZWQgZmxhZ3MgdG8gAKD6EAAZAAAAufoQABYAAAAAAAAAIAAAAAQAAAACAAAAAAAAAAIAAAAAAAAAAwAAAAEAAAAgAAAABAAAAAIAAAAAAAAAAgAAAAAAAAADAAAAkvkQAFcAAACNAAAADQAAAABZb3UgdXNlZCB0aGUgVCBmbGFnLCB3aGljaCB0aGlzIGltcGxlbWVudGF0aW9uIGRvZXNuJ3Qgc3VwcG9ydAAx+xAAPgAAAJL5EABXAAAAlgAAAAkAAAABAAAAAAAAAIKAAAAAAAAAioAAAAAAAIAAgACAAAAAgIuAAAAAAAAAAQAAgAAAAACBgACAAAAAgAmAAAAAAACAigAAAAAAAACIAAAAAAAAAAmAAIAAAAAACgAAgAAAAACLgACAAAAAAIsAAAAAAACAiYAAAAAAAIADgAAAAAAAgAKAAAAAAACAgAAAAAAAAIAKgAAAAAAAAAoAAIAAAACAgYAAgAAAAICAgAAAAAAAgAEAAIAAAAAACIAAgAAAAIBhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgOiBI/BAALQAAAHX8EAAMAAAAgfwQAAMAAABkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNsaWNlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhznPwQADQAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9tYWNyb3MvbW9kLnJzAAAA2PwQAEkAAAASAAAADQAAAAAAAACwoA5KJxsGAJ0Yj/yl1QAAYAy9nF7vBwCeTICmlYUHAB38BEgyuAIAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL2JhY2tlbmQvc2VyaWFsL3U2NC9maWVsZC5ycwBg/RAAcwAAAEQBAAARAAAAYP0QAHMAAABFAQAAEQAAAGD9EABzAAAARgEAABEAAABg/RAAcwAAAEcBAAARAAAAYP0QAHMAAABIAQAAEQAAAGD9EABzAAAASQEAABEAAABg/RAAcwAAAEoBAAARAAAAYP0QAHMAAABLAQAAEQAAAAAAAAByO4z1xpMMAPYlw4Fx3wgAtkw+Cwv1CAAxTKSFkzIFAEs9o9P5fAgAPpFA1wU5AACic9YXKLoAAHzm9CcoPgIANBrC4NIzAQCBjyn50k8EAGiqeocFEgEAedWTWJV5BACgZ5swZg0FAO7lvg0t1AIAxvCJthfxBgAwl+5MqLAFAORVcckQHQYAEGoJyJwFBABPAaiNYHoMAA6oueFkoQcAZdL8pOgfAQDMqk83uLwHAE9N7/RaLwUAEI35mEAxBQC9VXVYkasCAInY0A0/kwYAlUJMu4ZDBACMUGIxbcsDAMaicrhoYwIAmyvxaoKiBQAgu6UIRLwCAEJUoN3reAgAIkE1ErH/CgAshvWN7nULAB9uFM9clAoAutZHpMOCAQDy7zblZCkCAFMAVB+CkgEAXI54nvH5AgC1sT7np1QBAIWCKoHx2wMAl5c/uhf6AAAgOJy0nPYGAI2Fsw1aTQMAu7OW5qs6BAC/o06U0FwKAGJNGrhzVgcA1MDRJblQCQATQSnZOD8JAMiDkqa+YQQAsSEyqposBwBN93REd2cCAIWAsumwZAAAySc79U7wAwAx5dLV7dYBAKKzuAHIbQMAMF6T1KfgAAB9DczOt94BACzdIE6pUwAA+aDGsfupBwAcY6imimcGAGWz2Ig36gUAeUKZ1tYbCgDi5BlZ56wHANetONOeSwsAZICdA34hBgBtfjMIpN4GAAaCYhLBegUAcwTjZctHBgDJrR+lBZwEABuvRZC/6AQA1uBFOuMUBQAP/otbPFMHAMkUfntVgwUACLAhIBc8BwDeKoCKhAAPAPblxAVG4AkA+meXG9DABQCLOEKfiNcHANhGJa5aJwQASEOGSQJbBwArJnAQ4S4FAM1a+1SuNwIAtao60NG/AwBcnQKYtYoBAOmJYP3FLAMABZuUXFAmBADSegyIGGoEANrMiBgipAQA31MrUmXcAwBtfwCiIsIIAO1325u3VgsAzRL+HugeBAB9CQe9qSAJAG407H79NAIAk79/MjsBBwANau3tbjMBAK/zu6JltQIAVRlZic5TAgACdtGCeCYAAHijLnMZoQAAbCqOuvE7BgCa35DMlJ8GAEj8m3fRMQQAl6Dab7qXBACg6s8TA8wGAJmkjYQTowkACSMZQlPLBwBg/d7elpUDAN4Sf5EiHgYAC8+MRobNAwCBwBoiU4UEAG4KTktGyQYAAwQYhLpfBwAFjSHUXDsEABa10JsvdgIAs8vd++fGAQC94qzDCVkHAMk+LZcBIQQATa4QEtYRBQBunQ6V73YGAFjyieAauAkAghiVIkk8BgA3MptN1fEKAITbTZIl0w4Ah94gREiGAwACgbZdstYCAMBzKJa0UAYAlBMn/RwIBACCJP7mfxoHAFTIyKW4ggEAjm1A5cs/BwBR9M8wNN4FAEGMrGe5VAUA7lllS2x0BAArmsZtPHsHAG76wj7x7QQAyOp711roDADZe46yotsHAOlP4x2lyQUARxF0ZMhGBQCQJgmZ36EDALvW9MmMygEAAzvNyX9rAwBe25c0ZhkCAGcO8XnP8QAAon4rCss8BABqd//fiVAAAIiL0+GE3QEAIgjGA0WABAC0f6Ms0J4MAIN4lbXCdAQAg2aBjji4BQDka7dUxLYMAAVlUYo5Uw0AddE2OtIhAABtR8ZzM/0EACrQ7h4pDgIAEHIuzy4vBgDkjYWY4HEHAN8eRXjS9QIAQnOZM7EwBwB1aesgVJYGAM8Wpb+jCAMAWv9oHe2lBQCDDhX+KhINADECu2bJrwQAaII8g3jEAQCPFPzDOXgJAPiLfYnLSgQAWXNSWMXgBQBc169zWzkDAHC55KSvcgAAbQ+eMhQiBgD9/jUBthkAAINLE14UaAAAzMOCCYbkAQCZ1xNf+2gAAH5URDcoyQcA0mren8RQAQAlEUcJlfIDAM8xyrTuKQcAvL91tSKcBgAS4rxXCJEMAJi7daC1sg4AaKjcnDyGAQAJF1opDncDABP9IDda2AAABqtxH//gBQBf4JF3bYoHAHa5oEdLcAcAF6sa6YKuAgDNBphC1gsFAOrYjxVVgAYAVa3E/8clBwCymc/RFWcCAIicpkFUIAoAU0vNfUJIBADFvYrokdEJAB7Ld5LMlAcAwJjQHPcrAAAw0mzMq50EALIF+TNlCgQApLgurO9zBQBfhV9iVM0EAFNQrMImxAYAXglLzl6mBQC2a/KGQMQAAIV4GWiVQgcAyPy2V4MABwDuPnc4J2cIAHBhn3m/UgcAIzPj2qa0BgDc0eqWRrUHANAahen3bggANEpYgrufAwADeiWPVnoEAJGtHgmITQEAJM6xGFsUAgBtnWajkjoBAOV9V8AcdwMAUpmLuwbKAwCQA9XFgQsAAOyABzQSNQQAr6L43ZbCAwATpxTZ+RUFANVVIv+RMQcA772kwlxPDQDOixH8V90DAMeQNDmdqQcAQSUfuy5NAwCd/yO3FegAAENU4ha0hgIA6L7ROP69AAB3dADHkqgAAOijvTYk7QIA6pHyAP0qAAAho96Bc74AAJOxstRS6QMALzAoLXaGAgASW+M8CTYIAM7pUnVNtgsAX4QL/uAeBwDlaclgBp0GANmpRqAdLwsAvfUuziuOBQCKb4z36IwGALJhkuMm7gYAnc8LpQo9AwAXbz0qb2gHAGp8WW2mEgUAUXWlcJpgAABMRjyKwCYAAOE57sgfUwQA0pqKXzBhBQC+rpLsjZcMAACifK6taQgAVA8pI+keCQBrkY2JQZYGANQ1PsWuCggA1cCw5yjMAgDkbIrrYHsHAKZ3woUpBAQA69NGe2U2BgB8xfKuoTAAAKrSOgBz9wEAdg/BLGQFAACm/Cz4SDsAAClD7hA8QAIAZUDCwekLAgCmc5Yk2IcDACp8ktyovg0A7w5l1Y69BQDhQM0/Du8IAKvwYTOrUAcAYF4C4krkAAAcBCeXe/kFAOzswHI0aAUAfM6xLoiIAQB+BkXFZJcGADcQ+KKDMgIA0SN++a93BABou7yNlbgAANat6JdbIAAAdXD7s5ZPBQBmkmYpBPIFAPVBSa6vjwgAh3brxINdCQBFQcqeN88JAHS7Upz+1wsAzR6xFsavBQDvIo/sSp8DAC7ZJRaeswMAc4hQ1Fv4BQBd6Ps5aI4HAGuFuDf3LQMABk7xQoNgAAB1QdeJeJYDAFCl+wcZIQEAiAA1jyYPBwBHX4Cxg0UGANAsg68bLAoAFtfUG8AyCQCOW6fD9OwEAIitz0XTwAcAVfPccCARBABk5CKc/9wHACUz4GDaSgUAmnbvjtlcAgCMmwNs5QQEAIozeIxLHwcAIyu8FvwsBgCq2YAS9XwBAFqpIF6uuwMA7KpiR3UNAgBFtzvHb8MHANFLc5fHpgQADpWziiTvCADHPqXJVDEOAO08b+TxuAoAQ/W5NbH+BACuk62S0TsGAPfNEqYuTgQAq4MVmfRwBgC0kIfaiosDAF35Ud+cSgAAuJbV+2PZBQBK5axomy0CAJnFNoiOqQQAoesss65JAAAxefx1C30IAEl1uuRMbwEASb4/wOSsBQCcFSrBDn4KAGYPUxfulQcAfv7cYzx9BgDuGsit8BIBAGVxgkzwPQUA8DC0M1v+AgBijQxeZhwFAIG97FIKWwIAqeT8lQbcBQB9BHXFKLkDAOWGJlHzOwIAVNxJvxnNBgCGw69lIWEGAP8DYqMaFwEAqqggqC5kCgAPPzF7u/MJAOMpdDob4AUAo5wXUpBhBwDQr/CTZcEAACh0XHnEZQIAQlRdUUAcAwAuC7Q9D1IHAKFXk9PjCwUAtqeU0jOrAwCz7Vm6ecQEAG8yTRgNwwQAPO/MyZIQBwC8HQV0rNgDAK3QQ/W2CgkAj9oPrPPQDQDj5XMlHe8FAHoTt1s6FwwAjJFkAz9SAAB7imNt9YcGABPQipKWBwIAM0+lBYTTBQBXAj2wFeoAAIoh+fAxbgUA+ALhiF9jBQC4pWnZxcsCAHo0i8n7MwUA46QUVlb8BQCOmJB35uECABJJ5JqL4wkAU1YHtPtIBgByzUDY8Y0KAGXUCXRMIQMA5XptxA1XBgBt4pEbn4oBAKtCPxi2NgQAmIFPqqxQBQBUxBTEEScGAHAXZQZ0ggEAZcKG8kTRBACBku7wiHQBAAx2XNtsngEAuOxzQKm+BQD40kPzY84IAI02Hn2o4AkA6Z4BvO1FCADQ0CjtmpcOABpPlIUHrQQA5JvIEgm/BQCDjPPKrS8GACzOs5bBXgIAewFP/1V2BwBhjxRczaoDAAGDMcM0OwYAsdAELebgAAABZ3IzonYGAGmXLQSangIAKJAdy/CvAwDyNMX0C0MGAERyUOTDZAIAcJKjGZ9MBwBHvJn3hD8HAJm9Mvf5zAoAXkAgOuvHBQD4MNmqtf0FAEeMO+ZXpwQAViSXkpSOAgDSTG/o5xABAOT1A9ae2AAA+IoBBBYeBQAYIkrc7rgAANCEk4upGwUAk5YLflVcAACwDsKJsLsGAO6eC/tB3wYAb+GH7YcQDQAwp59c2wIJAGAYhPD+iQIAb37JHzHOAQAf27U/PwIGAJj86HWXtAcARVC/rXCtAwCY/njBVOEGAL+a1v42YwEA7PkpuWbwBACTW2ye/+kEALqyS7yJjAEAypUqZL+vBgC5qBP5cFANALsrrJ5hZQcAWXT0JVKrCwBHW6sU7WwHAAG47TwJLAkAwdL1YgzeAAC1T3PPAZYEAPbwY4LDtQYABm219T5iBAADlRuFS9sAAA8ZuAiTfwQAgh9iXCMUBAB2Whr0Xx8DAG25qnNncwYANWaceag6AwCebBX8iPUIAGjwpE1BYwMA6oq22WopBwBDrhYTcdMEAFiNHAzNEgoA8lwIvR71BwDh9eNn+iwBAGrU4/EMgAEAqPBfYTdDBQAhjp7yxjMCAIHHGH8Q1QQAXhql009KBgA3u0gEzfQEAB4VQ4XTcQYAFBmReHfbAQC2GnDdaUcJAGa2tPE5gwIAe+OKSyGrBAD+sKDvCl8KANEXoKgsrgcAb8JrfDlSAwC+eyKgeooBAItf6sGM5gUAXx16Oj7+BgAqbtJ62RoDAGK5IAntFwAA/bZTO+OHAQBjFHqQKVgFAJKn4EjyQQYAImY6xR/tAQAtLQkcpkIGAH/REec3GQsAIUHN7UvcDADePYsMn1YKAKF6pWTWAwUAbvKJTY7pAQCX/vwWrhAFAHwLznIRFwIAgja/7ZFRBQDAi/I2K7EFADcVqZBbOQMAQ1m+/Ob5BgAP6ubqLzoCAAYfAZWMcQQAH5peaAZpAwAdeNhPPL4EAImK/GpxQgoAdjy/5PRsCQBeMveT9dIJAFuABM/cVQMASJ5puNgNAQBjjY/rOkYHADPAkW6FYAcAVeCOACvPAABLRwgnEbEFANt1PMtNmAUAd/nPyv7qBAB72X5YBmYBAFvEWpzYsgcA5Foie1iEBQDDfqZmD8EFAAqJ+DJymQUAha0TLobICgC/6f+nRSoGACqYS7onXggAplcv8WOjAwByxn2Fd2YDAEXXUN1uAQYAVAQMpO13BwARfbiPkdgDAE2GWh59pgYA4McQQsUbBgC2upY/q6AFAHVHiLA17QIApWRNQvP4BwCvhkiyB0gCAGNPvF+I2AsAsyNVPpUVAQA90hip1zIJAA4xoMtV5wcA0U55JDYpBgDaYdEeHu0AAMNvuA/zjgAAZwv/flViAwA1MpwFp8oAACMwGnZSTwQAXxPN3tIEAQBqOJlmZZEHAH4GeiNxGAEAs3DuKmxTBADDucwh8+8LAJsR9yqkjAYA/eJoLlqMBQCH9i8w7tkDAEmkXA9doQYA+redWQKjAQAD3ET4Bf4GAJzTujUGxAEAfyn8Df84AgBHukGA37sHANWovwnx4QUAwRGeOEQ8BwCrk3BjIV4CABvNnJd9vQUAzTVAbSBcBQAldt6QrfoHAERhHDmGwgMARp8ILmcpBQAQru3MhxIOAHDuIjlrzQUANz1EuFmBAwAqLp/s2VoFAG3PCvB7egQABmAKzixcBwDpdM2L/HgCAMfrM9aUqQQAB9739EbPBQBJRISvUDQDAHBPGPopFAIAiKuRUmFoBABv60zVUTgIAIflbK2/WQUAp4i0r+SJAwCMqZBW+kICAIk4NS8+UgUA0u+lVJwJAQA07vLzCh4EABoU1z/vUwcAicdZDO7pBgBOiaVm2zYGAN7U0HtuUwIAX1M8frRsBQCWhD3UMCEHAFk+0XpEzAcAsFlV9owoBQAJiNnwKbYKAPEhzuGqfAoA68fy7+suCQCjxCf3L+kIACNFX8hwLAkAmyiXCsXIBQBS9kclUF0HAK76Y6Uk2gUAB2N56zYKAwBkqVW1AT8GAH92OOWlvQUASI0ZLGH6AABMpoBFzVQDAOq0z0meqgQAYqsWVBY3BACGrf3d+7EFADq88c6WXAcA/ga2fnQDBgDMjAy8tdsIAHG58YXpbwQAmkvmNigKAAAmLE6nkh4CAJPaQNWRzQcAo6eRMkIeAQDdwnLcRuoDAKff4oiFAQUA/lPd66A/AADQ55yV03ECAOxLLwc1pwQAMvR9yrCIAADAbP7+VA4HAAyCsqMcdQIAde46fI/WBAD6EYdP/UkMAO31CnBVxwMAnapUfDNFBADIpPltyM8HADpC22FtRgQASuvQx/a8AQDhEGFUsNUHAJYFx9eWOgcAE28+YF9hBwD546teA4cAAGo0IwuyVgUAdzpLVlyuAQA4WQIDTK0BAEGbcEuNjwIAm+9PkIoXCgAD4HOAojELAJGNGUGmAQoAW41wPobmAACxv1S2FJkAALeWJ0F20QEAD3Q+mAfDAwDxioEez9kFACtZoeI7HQIAe+uDGFdMBQCqbq8sMQkBAG6epLwqkwUA4B82DAqqAwCT9t8I5V8MAIKycfDBbAUASkAfE5XeCQCt7nSTI6ABACCLcA8Z5gMALu9J4SFuBADPIC3OAEoAAASDM8LM4gEAT646VdiUAAAaDSOfMO4GAHe4Z6wyrgAAKSdB2I/qAQCKiOi1JqEDANh7ErqwpQMAHU82mN5MBgDnT2y2grkOAF4IueDDGAIAbNDiPuxUDgDCqzyRlgMIAAJCFMxnlwkAUGQfB+TWBwDh5D7qw/cBANrj9M0+pQAAANJ+ecIYBABTtOWAGsQCAEvFnY7gDwYAt6AJw/GyBgC8u8sROykDAO2nWIZX9AEAHMh3e7yTAwACjM1oqGcLACY22a0ZRwcATxRa0UoXDAAj+1z2PUsDANPDmlm16w4AVUc/t0WGAwA3XWFzB7EBANRyfeoFAwcA4p2K3PsxBwBOytC7zsAHAL1ZYDDaxQQAU0i/zO+sBACvt5lsWrIGAGdoAjMYRgYAlKl2Ea3OBwAi5k3GCB4LAEIMKpJxrw8A66wcIUjABgATDlubbm4FANDkTzcWuAcAg0dWaNtMBgDfZliCzToAAB3KTEyPuwQAkfDJ5b+oAgDXFMTXcy4DAMw/EQTBGwcAUgprThnxAQD08XBRkH4BAOs6zpPHsQAA8JbO42r1BgCmtPaG4aMCAO+oJq9kHgwAfZkF/to0CQAyx+25onQIAKqS/Ja8vAoAc5IejO2WAACnq8vawmgAAK1NfpvcywMAatGbxs2LBgCzr/6pJ/8GACljH2E+9wEAgS3IORDVAADFzsDXsLgBANI6AnCoZgQAhOJtW1orBwDDN6MoRiwJAI3nYPRnbAQAXnJo3uWQDABBjAHSNYQGAOf9pnpaSAMAIOdo7XSXBgAmfpXifSkDACZ043cARQYArpy1KP6zAAC3lw0WoRoGAI4SVX97igQApuSyxbC6BgAtL90wIYIDALR49rlZoQAAje4DBc7GAgAHm0Z25hcHACnRYzwEPAQAszPQDClKBAAB3FRwh9MJADiDN7XC+AgAiShjnLHfAgCwUZ5IJYUDADNbemlI2gMATbZyd/LUAwBJJtnReucAAHVc2/IdMAIA48U7owEVAgCCA3U/tXYCAFx3AXC8+gYAjSXHVB7MBACc4Tpr2OELABIXpxcwjwIAnnoM5E/QCAD+z+EiwzsHAC2jNyJPKQcAjmNDdWbABAB/fh/JiQwHAH2Y0JvtpgIAoFPX5HpyAQAUdc798y4GAP0+ffcXgAAAy21IPg3HAwB2R3t6lwkEAKcb59ReUgEAZlbRh4ySAQApcghm1UcIAEbJGOuyVgEAi6a2bKQ4BwA6MNSqK0oFAJ9J1MEOrgQAMCF+tVqVBABho76eyLIHAP6tv2Wy9AIAhHY6AiEYAwCPRXQXtH0HAKd9vqKbywYAerC6D5wBAwB2rBkS/0IHAMlL0l9XhwMAMdphNBt/AQCGKGwDPWsJADNB85x83AkAdB3rAuwFCQDJc6zj1SYJADxEP8SCigcAUs4DNJsZBADJsRzibE8DAISNstSc2gUAor0Wu2gTAwCprROaudkDAMR1JnASgQMArcDpKI1oBQDnRL//sRIHAHut05wiyAEAu4G9CJK0AABvBw0K+1AFAH/A2h3TLQ4AtCOrI2ACDAA2zMmxYCQKAFAt2mQK5AsAQXIoLbPcAgC3JpiwkrgGAF307DlgowUAeX4J1sOQAgAoHy577lcBAJ9wyp0upQUA/rKX/+d4AwBCi5RU/rgEAHh7160PWgcA+1VcEXeiBQBCTIXlIdkIAGdPNsb7DQcA7PGcuLlICAAmKLex8bkOANItiZHh9AgAzACDMhUwAgBiVfj0sPoHAB37IcPjtgEArL4WnCd3BwDfF6sCm2gEAO0yQewSHAUAd7i3ViQbAwCB0YdTHsIFAC/KSXrDEwMA3Z68LkOyAwDc2MeBl4kIAN8ChTHnDQkAZ62QvhjbCAAbsRUR2mAIAIwyMBP9YQsAWS6Mt8LMBgB3t5IvOAYHANxkN/RYAgcA9gSa/8bcBQDbsiofXMUGAIaZFWWBDAMARZroofguAgDkXOISEegDAGoLtKxYQwIALHuSWoTNAwDMURks1wYNAF2i/gUfvQwAzKjv1zluCAAjUVi1qlYJAH4kx4qZXwwAsNNv360VBwCi49brGs8HAKnIAXEbOQAAaas1q4doBQCR2qDoIWEDAM0+XcUoBwMAgfRmKs2IAQANhVs7M1EBALlqYaP/jQEA1WbwbAg7AgB81b20gGAGAKwxRpfGMAkAj/L15vCyBACAmiJ/ogoDAPEUkKFfbAkAXhkF6hhRAwBtuCAt+EYAAEVRx8o8SgMAloTCGXU6BQDoxohTux4AADv1cuduQQUA6KESnXO5AADjPyZDHFgCAKvhlP5XKAAAc4SB8U6GBAAduNALOqgFAKEZhYYjdwsArTsZ0vtUCACBTZ83cygJALv2164DbAoAs5pjlzLDBwAC33EaDWQFAB4f0TzwiAUAHcQlYC62BwC6TcPAracCAM59HFgvegYAw7ItNQUJBAAleurwkCYGANw9pWxIqgMAHZ6VaVGLBwAtzGlXWsgEACt/ZbrpSgcAVPqb26AaBgAqC8XlDtoIANG8JALsVwwADRhd31SCAQAfoow6nf8AAFQY1H3EOQIApBqVq5OEAwAeN5C8FCMAAIqQJo/+rgAAPW9ap2q/AwDM7lroOxMCAHWbvMXdJAUA8Pw0xXKVBwCXlXTgAEMLAIaGmIAMcgwAl9x8kSYjAgDLVftJCg4FABl/bgsMiQcAby1bozyyBQBzJDeYJVcHADYo7BKoWwYABsSbGYKfBwAOtpiN3w0HAMRd1/23QAEAkn7TAl8LAwAOzI4WEtICAPYYcawVVQAAp4keaWlXBACtQ6Zb3D0GACFnbSM3PQMA+3MhQnaeCQAqCDrXRTwOAMYFa3AP7AIA2y1bNAXjAwCcanNdgL0GADCnHvWFVwUA7veuEQHBBgDBAS8jdAsBANhZj2CUFgIAh5+Pocf3AwC4NyXCUTgBABU3WyjIUwMA9KMlnfrWBQDKpqOy/loMAIS1zAG+8wAAtLOZtnJ+CgAL+2UmA44LAJ18iEH6dA0Au2xu5IVBBwDbSMpH5CUAADCnqRiZ9AUA+vv6vzy9BAD2dfcE50UGAPoeid7aKQUAJRn73EWiBQDP6TxEVDgFABTBrBp5mQQAq8pNVw5CBwAJSyOUP24GAAcfgkNo0wQAh+0hl1IRBwBJ2JmlojoIANs8nPpgugoAPFE0oDihBgDsvnM63+gFAICYP5iSGwUAxoAcV5TpAQAbWCtj9E4EAMlk0yEcSQYAerRESaSMBQDuaBddchwAAODsiHqr5wEAX0vEmUgFBwBZ8bImlJsGAHrdKnZQUAMAUoADwETPAwB3eUDHjHMGAP9txZ1tQAIAo3hZE8pNAwC9bhU7KKgBACnAAWCi5wUAuzygY8Y5BwD/tuLONiAFALCgDkonGwYAnRiP/KXVAABgDL2cXu8HAJ5MgKaVhQcAHfwESDK4AgDqQF2Aqv0AADnTVy5I6wIAWLx0AmEHAAD/yD1hC1EGAP/6XJDIhgcAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL2JhY2tlbmQvc2VyaWFsL3U2NC9zY2FsYXIucnP4HBEAdAAAACEAAAAKAAAA+BwRAHQAAAAnAAAADgAAAPgcEQB0AAAAPAAAAB4AAAD4HBEAdAAAAFIAAAAeAAAAAAAAAO3mIWe9SA8AWuRnrLW6AwAb5TXr//8PAP///////w8A//////8PAAA70VLpZdIJAJ+mvhXHYw0ABHZoy2W+BQB/IT3H7twDAJowfBtBCQAA7dP1XBpjAgCBZc15L+oNAPneFABBpbzEAAuOARAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTEuMi4zL3NyYy9zY2FsYXIucnMAAAAoHhEAYQAAABUBAAAKAAAAAAAAAO3T9VwaYwIAgWXNeS/qDQD53hQAQcW9xAALprAEEAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL3dpbmRvdy5ycwAAAMgeEQBhAAAAhQAAAAkAAADIHhEAYQAAALAAAAAJAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogTB8RAC0AAAB5HxEADAAAAIUfEQADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc6AfEQA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAANwfEQBJAAAAEgAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBkc3QubGVuKCkgPD0gc3JjLmxlbigpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL3Rpbnkta2VjY2FrLTIuMC4xL3NyYy9saWIucnMAAABgIBEAWQAAAFIBAAANAAAAYCARAFkAAABhAQAAKAAAAGAgEQBZAAAAYgEAACoAAAByYXRlIGNhbm5vdCBiZSBlcXVhbCAwAABgIBEAWQAAAIgBAAAJAAAAAAAAAAEAAAAAAAAAgoAAAAAAAACKgAAAAAAAgACAAIAAAACAi4AAAAAAAAABAACAAAAAAIGAAIAAAACACYAAAAAAAICKAAAAAAAAAIgAAAAAAAAACYAAgAAAAAAKAACAAAAAAIuAAIAAAAAAiwAAAAAAAICJgAAAAAAAgAOAAAAAAACAAoAAAAAAAICAAAAAAAAAgAqAAAAAAAAACgAAgAAAAICBgACAAAAAgICAAAAAAACAAQAAgAAAAAAIgACAAAAAgGFzc2VydGlvbiBmYWlsZWQ6IHNyYy5sZW4oKSA8PSBzZWxmLmxlbigpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JsYWtlMi1yZmMtMC4yLjE4L3NyYy9ieXRlcy5ycwEiEQBbAAAAIwAAAAkAAABhc3NlcnRpb24gZmFpbGVkOiBubiA+PSAxICYmIG5uIDw9IDY0ICYmIGtrIDw9IDY0L2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JsYWtlMi1yZmMtMC4yLjE4L3NyYy9ibGFrZTJiLnJzAACdIhEAXQAAACUAAAABAAAAaGFzaCBkYXRhIGxlbmd0aCBvdmVyZmxvdwAAACYAAAAIAAAABAAAACcAAAAoAAAAKQAAAAgAAAAEAAAAKgAAAGludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGU8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAHQjEQAeAAAAAgAAAAIAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgOiCkIxEALQAAANEjEQAMAAAA3SMRAAMAAABkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNsaWNlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhz+CMRADQAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9tYWNyb3MvbW9kLnJzAAAANCQRAEkAAAASAAAADQAAAHI7jPXGkwwA9iXDgXHfCAC2TD4LC/UIADFMpIWTMgUASz2j0/l8CAA+kUDXBTkAAKJz1hcougAAfOb0Jyg+AgA0GsLg0jMBAIGPKfnSTwQAaKp6hwUSAQB51ZNYlXkEAKBnmzBmDQUA7uW+DS3UAgDG8Im2F/EGANdxPJP85wwAQ7K2/kHPAgB2Gn0KHFgHAPAyTVMtFwcA0of6Y8CQBQCo1bRCYKUBAFPRnhXMiQEABK48qt64BQDYtRFP8KoCAJKcZlpZuwYAX3qbpbOoAgB/CO9Zs6sDAK8F28So9QQABULQB6i5BQBQ6hNbrwEHADCX7kyosAUA5FVxyRAdBgAQagnInAUEAE8BqI1gegwADqi54WShBwBl0vyk6B8BAMyqTze4vAcAT03v9FovBQAQjfmYQDEFAL1VdViRqwIAidjQDT+TBgCVQky7hkMEAIxQYjFtywMAxqJyuGhjAgCbK/FqgqIFAJ8J/I65UQMADgWnpL+PBgAbl52VSSoEAP2eRhrlkwMAWB4yEOmABgC/GGgFCgUGAL8yVR/MKgYAJfrJzEGBAgCD5nH0YU0CAFpEx/QzeQIACf92xOn7AwBCSy6Ya68AAOV4ulESrQAAiHzu7a4VBwBTNfbL0PkHACC7pQhEvAIAQlSg3et4CAAiQTUSsf8KACyG9Y3udQsAH24Uz1yUCgC61kekw4IBAPLvNuVkKQIAUwBUH4KSAQBcjnie8fkCALWxPuenVAEAhYIqgfHbAwCXlz+6F/oAACA4nLSc9gYAjYWzDVpNAwC7s5bmqzoEADFxFXfr7gQAQQfxFRkgAQBWnGzanGYJAGw02zLAXgQAwyxqu1ceBQCkjH17tgYAADMp50T6hAAAim9d5U4VAQCQcy6EXUIEABfkGsRkiwMAcUvqAmcyBAC1MGA3NGgAAIDD+RIF7wAAhCVR8qnxAADW8KmRjgsBAL+jTpTQXAoAYk0auHNWBwDUwNEluVAJABNBKdk4PwkAyIOSpr5hBACxITKqmiwHAE33dER3ZwIAhYCy6bBkAADJJzv1TvADADHl0tXt1gEAorO4AchtAwAwXpPUp+AAAH0NzM633gEALN0gTqlTAAD5oMax+6kHAHw+3QRmWQ8ANYsFDlH8DgAMzLKNDGcDAC8zzpnYlwIAzhsGdl6RCADZNJLz7V0HAFQ8H6s2HAAA2vVY7o/wAAA31qATluEAAOAgE0oCqQMAGpGiydn1AQD4/PqUeREHAMWN4sqo2AIAhwwJsrFKBwDE7MLFB2kCAB2cL2MO3QQA2aUiJtHOCgDZQkdh6Y0JANO122+pnAcA7gCa1DfdBgBeUapJVGMDAKtdR9B44QMAEpehEkcLBQCt9A+GwtwCADE98NZ2DQMAx+QGIRdEBACILe2vURIAAFpP7Zv8NAUANFLPOVrYBQBk6BJxaQwBAPLHWIOgKgYAlOFICERvBAAr9ahxt0cEAB3TaTK6dwMAgFD1uvk7CADeX759J8QDAJJM1K81owUAPnWZQBbBAAAj5G8AhwQHAG/WvsphXgIABGZYzCjhAwDix48ui5YFAM9hvdWjSQAA5vYeW1AWAQBuWDSG12YFAL0vWsaFQg0AH3T4zGJeBQBEkLFhuWsMADggcQU0FQkAOnk0X7pPCQA0CMGcn6QHAMYiingTtQIAWznybkv/BQC/B/ZajuwCAMPspbx1OQMA1PeFaRZGBwCa5woAOZkAAHr5ZHlMhAUAPVv54Rc2AQDFP6jOKUgBAKXscU4vCwcAPGT8jhQoBwB2W5kDPnUIAGZnq7Jfvw0A1jVFvMNfCADCld2XhHsDAOj/tNZJFQYAONGxLaIXAgCesC4Gz7kAAFj35XGc/QIA3d6vUq6zAACX5Blmp50BAI5V0lQG+gYA1EFe0hmCBwBRxnV0dnMDAJBlJBTLlQgAZ6ymKtgCCABQSLyD8UIMAEMGChxPRgYABwlzBVm/BgDZrdFA/ZkCAPflBJre8gUAWRzMuu7ABwAKKfixocwEAI+xw1bq+wEAiltB4fF4BwD0we90WPcGAH8CGUBpigIATdxrqTcrBQA1pmfPISUAANFeL3cgZwQAItZZ88AyBgBS4qMrCbICAIAmEXwlYg4A1XyfPXUBCACUUp0KC+4HACfKTOv7gQMAnWM+Oh+EBwBfRMMw6nYGAIIT56cA+gMANNs9li0jAQCNBwvnklYDAB96dxTKRwIA0Pzoa1XbBgCOBPriXysBAJIeb60mfAsA5HsicQlqBABMmy0NL3IEADrgTiBG3AMAbHkgPOn3BgBN4/yWxPsAAD6ufWu+dQUACebOhRWjBAD/MDkC6TcAABL7lm+3SQcABa6mrgT2AgDrI5OT3DcGAEeNBJut/QMA91oE1LCoAAACHvAQ7PwAAEVOJMSd0gIAvkfBG3uSBgA5CKw0hTAIAEA/A2Q2hQQAq/5mkXcTBABEHv5JplgFAInM7641RgQAuvKHSEP/AQBELQ4igfkAAFE8GKcakAQA8PgajFS3AQAWgTZTjIQHAOk9OOdkGwAAj3xYsPsJAQDRJreHuBsEAJuRZnxZTAsAww+ZtlChBwB0IpKd6ysFABqGZHHtDgcAqcZw4HGoCAC+RkN0RH0AAB2oZKW2ggIAayN1+IDtBABQDEUdvvsGANv8Eoxy6wQAiYm8S5m1AQBgBkyoe0sHALiuzfF4VgcADPHWsAYyAgBdaPIAc+4DABh1HoRHeQoAfujaiHMsCwDoG5fTrRQEAPEOL4NQGAgAiPssanzUBwC31n2e5FUCALqe1WMhjAMARVgAKh+GAwDJrstMHuECABJ5KXYVOAEA4NbwjhTQAgD7h+eNKlIDANL5dF4F7gIAEwgx9jhABgCeTNNYz0gBAFp15Jp9LwcASvwPaR5xDwAVDVs1ooINALO2hejP3AgA6erUuv54CgAn8DR59pIEANQoVYHQ3gcAEmYaUWGEBQBEFd5QLuoFANvV66Ev/wMAZjmTjB9oAgA1FpMhBYQDAFKGMErxdAYAkEipiJy9AwDG6S/QTRAEAKVqCdsGTgkAI7DmiZwhCQDaoobUq3gKAB+VYJKyQAoAye9IWlsWCAAqQiQRXr8CAFauVmcUcwYAMOiHmtlKAQD9gLBlyuoBAPX6CrBjyAIAdmqEoHSkAAAyHpjvpZkAAOa/SzyuqAIALIMUrzRcBADs/5t9tpEFAF21GJ9xswkANtODjDFUBwCXl5G3F3wKAGCbCISwRQkAAANn+LSJBAD6m7SAHA0HACVGkX1+1QMAReVlIXLAAwBP4Bk4ueUFAPeofOwC3gMA75LrOi0QAgBGOgzVIowGAE6JhZOoLgQAjPNVv55fBwDLlqS7X58EABtXnB6MYgUAqyLoCLGYBQAaNimuj10FACh7qdHIrQgAdIYobBpqCADUz1uKEJoEABJmfY6MFwYAdQNxczTwAQCYYEphSToHAKa/3IZKYAUAtmQXfNTRAABRLmoxCBwAAEVQyUXbswIADDCNgU9jAQB04p/oiQkCABvs6oWLJwwAzeJ7ZVnvCABvh1hp0S8PAC8LJgWy6QoAWHAPlbkwDwB/zC06/XcHADJJEvuplAUA8BXKgI4fAABpMuw80RQHAGfK0NE+QAAAUsVOhzUtAwApufGNBPMBACObFzvXAAMAC32j5XvmBgADgzBUdL0FACp55xUhkwwAtzC5u7lXBAAmMhmLXY8GAFbUHo9OFgQAfwYjsX27BQDCTLIoldECAPMvMLhmrAQAUa392cgBBwAnN1tcs8EGAAo4B4CnMwEAvmLKxmf0AQAswV0qI8QCAIewE8AdVQcAzTuwEQxpAAAOj9Wm3EAHADxDeARXjAIAY6RzKFDYAQCc1N5+HmQHAHH1TNXt7AEAsMJWUj/AAgBOzs9SB+4AAOn7FoHdYAYA6/8PE2dRBQBclYW4gsYBAOpjqV/SYQEAfaRTe3UYBwAhLw+L4RkGAATsweTf+wUAkrseyJjXBQBr2duLRpkGADUZqWrmPQ0AGptZGvhFCACSQSG9qPcLABkzEqRNHQcAosTmxOGTCgDP/tr0Ri8HAKP33vqPlAIABLzz/c0eAQAl7f6P6cIDAAU5R5ohJQUA4RJRkksTBgDtBrQrlLsGAOLdwEXEcAAAo9fEItgRBAAy8EfEBbYFADnw5/DG/gkAfEcsabzOAwBeqRlqmHcIAA6Ld6Gq6gYAq8VM7y/xCgCJfMQgWYAFACyX+XFHkgEAQMCf372LAwCBspIAAPcBAOuK6tx2SgIAQMfA37IiBQBI4YA0GegHALlBQ6DZPwMAvCCKZ2PIAwBDilGyB+YFAAHPlqUcQwwABBSAfNoVCAC0EI9vmzwIABZAkyJpNAgAVuQ5MfMBCgAYGN9sjx0DABZLFEts+AEAnT7XuHWYAwCzp//Z8PsCAN3Mtsp6BgUAUZ0DCGt/AgCq3wCAL4AEACXFYqCSlgAAF1gHkeq6AQBgJIaoy5cDAOd5E8j7wwUAAi9eJbwbBABQhplW96MOAEF84NR/KQkAGx4sArRxBwCyWVnwkzABABjGLi81vQEAhuqIm3h1AAC5SOoXER0GAOZmBzKdMwIApy86UYbZBQAPG+GZOj8GAG2y1s8OigIAj43hNWg7BQBxmSGJoTEDAJxydZ06LwkAycRT6QANCQCJL28R3wMGAIjg4HbCPQMAmmT/GZasCQDGgE/7RW8GAKL+ue44zAMAH9twcmQHAQDIDXTq8RAHAN87uMZnEQMAaBBLUkI4AwBF/jCd030HANCgQSFDiQEAJcK4Tv6IAACL8EFjQxIGACUmLRrjSQMAbLGmf3oTCADbfneSroEOAFDc+MW/IgIAkI0XoypSCQCNiU6H20EFADMbhPuALQYAl/on8G4+AADoM5aePKAHAO/lCSO+bgQAOElhaVMvAACHBaKt5VYDAAL5a5/IGwEA28gZZHQ2AABDUlAP518EAH4UlcggSQoAXUyUYewHCQAewBfgUicHAHrpot23IgkAoVfb9hlmCQCMCwyWpnUAAEkb5MXh3QYAQaNtUT8uBACe56j9A2oBADkOOmLRKAQA/QijAURKBwAJgVW51G4AAGeIoPbxRgcAISNvXG9jBADTC9aSFdgBANXFhXuftg0A61BWFy16CQCdwb9tPswEAA6+czgdPgcA+Aob1falCwBfrA2mVocGACbsint1XQUAvYBf9D04AwCmlp+MP3gGAM2eeKc0AgIAUrJ4cbYNAgDaDizaozoHANNwHMBFkAcAWRAlFXuzAQD+z1MjaM0HAOD0rGhgzQUAzHR6/JoHCwCzZAtll4AFAJlOnKyrfwQAzbKyUwLvCwC2+ofYW6QBAHzBbQdIVwYAqBGqAIC5BQB0CQjJ7KEEAMC9Y4iMgwIAMFBGSs+wAwAtevWuuCIAAK0l6XcGrQIAekXXZ0EJBACCamCKyx0CALoxd776AA0AUDMRw1PMBwCBDQj+Zc8HAKEbAWbZxQMA9sb220DYBQDIn52MRgQAAIxreVSF2gUAJQCVcL64AwAJpqYtidUGADFKGQg9vAAAi+GfMA04BgAN7rgsPNcEALbAuq2CuAYAvkzd3atuAwAZrDJiJ6QDALh+RNtywQgAfqe3BcX4AwAQP3/5V6gGADrgf1bA/AwAGU6Cngx3CAD6hHCKLEMCAGipqDz3ewQAZygmdpFjAQDOEIBP3+gFAN4W6nwX/wEA/bW1RZrZAQDsmSRPZyMFABMmGCb6+AAAmIwEmHOPBQAAFdRPJp8DAM57Cf6rSgsAMjolA/w7DADyt5H+x5sCABZKhORhpwgAXsNyEmJcDgCc4ufbFzQFAPWUc4JzRQUA3VD2pu5lBQBJx410UCAEAImIRnMtcQEA3ZMxzviJAwDlfBe4JNQCAM1ANA36cwAAl57UDAI5AQDOGasAmC8CAJn9bprdnwoAPygoqZTGBwA6S+TuzfcGAMNcsgcyWgUAjFk4TRoXDADL+J4+ijYCAAus4giqVAQAAKePP5KQBAAvWKSeqnIDAGJH1mxBPwEAjEzJmapYBwBE/wAXAPYFAL0BjEhOaQcA1u5I6f3VAAC9dKVPIQgFAMMD0FO7FQoAwqgseZ4XCQChQMhq6aABALY6u+KTIwoAyoZMinWnCwBL/tY+FWkCAECY+K4jKgcAnGmZUr5SAAAWIxPv5aUDALr6xg6WLwIAdlCuk/YRAQCQypSqv+MDAIe4dpR5RQQAeUhGEglKAgB/3vgV/dkFAAtS1+4qTQQA5KfC0mUIBQBA6jhSW3AKAJY7XbJwbAwAuH6kfxi8CwB/cmNt0wgEAGJgpvb4+gUAa96oLYm7AgDm4sfw1GkHAPv4FFnzMgMADMKG6hUBBwCorSTaiG0BAN8qZiIGmAEAnVoZvOsBBQD7Bukc2FAEAD90rhyW2AQADrp9jMO9BgBjtOGntNMHAPOt4t5LhAgAqmOWJ63LBAB1UiCmobYDAM9t0JEn6AIAhzypynI9AgD0qmirt/AFAEVjutQl3gIAzR/XoCSQAQAaEF8RZV8BAAiXFGeQ6QQAr6XL0dgZAQAHIP7O+9cHAJSQwvPFXQwArnm1IFJFCwCJBh5jwXAIACCbDmPAawoAjM1tGc35BAABKGsmah4HAF3f4nOumgAAo7EZstgNBAAN3hdF+0YFAHV76DVUlwUAaDd7atiXAgAyY0wvWoMEAGBBQ18wcAAArlZOAd2DAQCgh0MI3cwHAIDMYGcYhAQAYTNTZVZDBwABuDZjaC8IADBD9kZUIg0ACxlIqDxZCwAXBCZtLEIGAJS7F0iQEgIA9VS43hmjBQB92mDg1KkHAAwd1g69KAQAp5qEXpoYAwBCslkfu6wGAAxjU0fv9gcAqS0qKUbzAQDWoo0wmHMCAFMkcApMDgkAM9d7o6/aBABhiT7ca58MAOXa7Nz//gEAw5JUlMJyBQAT1F5DKI0DAFgomRlPBgQAzUP1vg9oBwA8jdWD3aoBAMPo63pZaQIAvjDN1kXHBwDveN9Vd3wCAKN/kzNodwEAVRhEFlFABQC8BYxJhfkHAFBjvw9SFQ4Aadp0v+m5CABoESAIg/4MAELeJ2H3cwkAsGnNUyYPCwAX4QufiM4BAAkHUZRqbwMAtBYAckjyBwCRz+HRHoIBAB+jcMQubAcAhQzBqjjJAABBcXntZBsEAG1eGMGxvgEABw9gkFTtAQBHlhU/J/ECAMALp1XXiwgACOZciDqeBADWWhuIhWUJAF1P02h1wgMAX9x+mcGKAwARHuCKfPwBAOfoc1VNCQIA0kn1uzzKBQBDQcXsIPkEALaFrXLl2QUAO7FRpxe1BgDMgLFw088AABr00SV5NwUAoghgVlZOAwCe/svZ/C0CAI7gOxC0WQQA3SotP0uaBQDrjrvINNcHAAlKWb48OQIA3kyCd5j+CADZDA3D4NIDALtxZmiX9QMAmTm2fliqAAAZxpK1x+MAAIxEBWyRsgYAO5G6CtE0AwDbz4G1zUUAADaPOlXg4wUAsv8eBLMLBQAA/wfzA8MEAO1E2Q1YAwQAP2WSffeNDADpSbPjn4oDAOGvCoWJ6ggAaXCrUbEWDACFjLIX1jsCAGFafecu5wYA3k0X/3KpAQAPxnNjY+IDAKuyeI8b1gAAsDbB6e/XAADVCmSJHKsBAJcf9K6CXwUADe0X81dpBAB+J3SvopEBAOgORk9DKw4A+9P6wMaUAgAPTHuTaIMGAFuHECn4yQUARQXg2+c3CgAxFDzFS/cGAMLZu10OxAEAl1yunPvIBgDat+FcXIQEAMy1UOTg4gcAMLQBZ+11BQAmAKJ/4dMEAFNCjIj8kQcAwYoHmbrxAgAVEZtp+hoHAMNQO0ccPAIASB3iHWfnAwDooUdV+iYDANmvX8JNDg0AiI/H+zEHCAAdtlM5m28GALnMPCj0VQUA52AZ+2fdBwDU/q+hB0cBABwrnC4UIQAAgBj4SBjHAACGPCPY2UsEADBY/o5X6AYAtUFwbVsEBAAVfjTz1sQEAF0Zj5j83QQA4WWjPhf2BACIRa752kUOADpi22M31AcA+YgKUPmLCwDJH33Bz+wHAB6DggcoygQA1texfTO4BwD7lTjvbREFAEd+qtr9kwEAb4foNzzJAgD6g8UoGkMDAHnYi9pJkAQAHMF6QKi0BADU8OuZ+6YGAMYj5La1IgkA1d3x31AeCgC/dU4ydj0HAI5BlVRIiAUAXiz0qf02AQDrVQhWu8EGAEitE34SHwcA7FqQBLPGBQDHm4iOa3UDAIkxSpF2XwcA0b0Fo7HfBAApH4EF/7MDAC7ZPChi7QYA4VLsQxVdBgCNvhA1GCIAAGx6MEMBcQIAq/OLtI/YAwB6j8FO60kKAF4p/10RNgkAA9QfRHw4CQAULa1eOGYHAF4JBotPGQAAYjuC9niEAAAIc9OJhgEGAAa4F85xoAYA+IqXh9HDAwC6doLI4a8HAGityIHyHQUAXSSkvQZJBgDt8aomGxcDANFHirLYtw0AwDSeFO7CAgBT/Jpi9XYHAKlJ/FDq9AEAJEQzphTFBgCoTFaXkDEHACU1I7xOhAEA4e79Q0UdAgDSG/+qJ60BAAjPc0j9IQIAQWMVOk8gAgBkpGVAQTcFAIPP7TsMPAQAIKZucH5VBQAkuW9Zqo0EAICXTMhdHQYAnsJAMOh9BADnB2Wy3okJAJlH3Prm1AQAp+igf4OMDQDHnKVcZo4CANkNlBXHZQEAlRyhOl94AABphOPXmHsFAIStzG/ddgYAWJD8loVoAQCfYQPUam8GAO9yd6hZ1wQApL5zYW6FBwBXaiw/98QBAIQ0fPxucAYAbTbsOXiYBgAmf8+VH3MAALzkvI51rgsA9dq3rVkEBwC7oF8wvU8CAM+hdcyYCgQAM3UKIuGMBwCXweEQeiEGAGS/0YCslQcAsyu0kUnbAQByQ5lbYGkEAFiaXHHjMQYAj3LP78/pBwAhzkgoFv4FAPWxfF0thQEAD+Vcvg8NBgB1e+NG4qEFAJDV/wXuGg0A2Xc2BEy0CgAalpThTyEBAMvpqTmu4QAA9/kmtchDBQAd6WeASRkBABfJb0SdeAQAjrdOB6uHBABD44xeO9MBAEYb659BPgEApOZdVh9yAgCau/LuUgwGABFtrnzCxQsABG6VkZRqCwClHRPJuiQJAFwrIN73tgsAZZuNJHcNBwDxi/07vIkFAGtBo2o++QYASK7B1qPABABqWAsmh1UFAPzMEsPJCwEAW6DCPkvoAgBRFTzwop0GAHumYUYXOgIAOPKJorwJAgBvlzq9VTcGALes8ZcYEAcAuAd7tyzYCwD0aXc9CIQGAAfOLUcoKw0AUXxzUTd2AgBTCNEqPqAHAKs2rcbcEwIA1r3VQOKmAQDf/vj8T8IHABa8SBzM2AAAqRm0btMCBABSoBSM9s4HADnRwlsl8QAAahgx1OdzAwAWrafYLQwHAAB+7bh9lgQAOlIv0O5aCQC7lNCRlRQGAAZwwQTycgYAU2qBE4YrCwAO7G+fUJQBAKysMcrYKAUA+rm4c22CBwCz+eCZy0oCAEg5Nsb64AIAZM1I5L73BwA8D9oQD+EEAOkgq7lskwMA0GzqT/ygBwCkNccVkhcEACHNayi5Mw4AlJzburPKDgD5vd9+OE4HANkPisUTQwkAGyRiVqgfCwAq7dzX55QAAI4RjnP6aAAAK+5fCmQbBADUGfCdcLsGAJnNMEo0AAcA9CI2LkJsAgDwtQVqBvMAAKaABI9E4gQAlfDb4M1EAgBSmSoxsksCAFhc+PUqDAgAPojyTJ9gCAASyqG1bugGANHM76JEiw4AtP6fr9LRCADDZ94yF+0AADUWKWnDCAMAUNLySPM+AwC7oaFeRwQAAIjhcejj/gAA3x5iMqGKAgA7Na9MJCsEAIrgwkwGawYA070MAiC7BgAxhXF5zWoBAK22h3jFxgkAKlnXH/KrDQB5hlMS1AsFAFExJ3ELgAsAYIGxNO1kAQA9HZstr3IHAFtOi0SG1AYAqBiN3VjOAgCLPFBnn4QBAAKTa+/gIwEAmuYvGUzZBgAPaaIiUkcFALO4hp14kwYA3Gn7vcP1AQA/B2H8oI0HAIE6DGjxgAcAU9T8PF2jCgD33cfN5QUIACOseICI7gYAOGsxS6pUCABqxivlKF0BAH7LUQMeDgMAjB+xdC8KAwAD3tcMEp0DALFWsu5d0gIAuHwmGY1GAAD5+7Wp3IwDAOKhLFywuwEAM5WOdRWwAwDat2oKYTQBABX10XfnZQoApDkeTPXxCABFJlKVG/ACAG3endvY/QQAzJe6jIdUBgD+sPaNx44DACJqo76uPAEAal9O5cbrBQC4Dj2QBCgDAA2yotsvEAIAoeZcBQXkBgDTMqU1SgIFAJ3y2lSQ9gEA1Yt6DR1dAQDLnrJdcq0AAIVvBZsMvAcA2P/6v/4cBQBJ9U3pu0oMACAx49e77AcAmSMw9XX2BABXJE6DsWcCAIi7eMMZrgYAEtXZXntFBwD7BT14DSgDAAMat//8rgQAHhcVBDY2BQBleAcJMzECALyvNENEUQIA6FY3hcOwAgCGKiq3y7wAAJYS/lBMXg0ADMPvE91fCADt5YDDxsAJAKdi++Md4QMA8wiR1o9nBgDIqbHqL5YGAAujuY+irAYAmJ8byrdtBQDdGHBJWJ8DAGudtQpPAgQAwmNoYzH6BgCwQn6m5QoBADHaH/C7egIAvE/muaeAAwDU6gghLtQCAIB1Uw8NewkALYTJwGNiCQCjOUV+gqsEADrXQ9sNNwYAI7R5Or8gDACb0t+UFRMFAP5SjeknpgMAYVaFQUAVAQCEg5/QdZEBAC2Ni2CydgYARytbHGW6AAAnEHBjI4YFANvGGcLWxAAA3liG/z3wAADPwKn/0kUHAFdO0yFX3wYABgx6di/zBAAgbsfqq9UJAOPhBOHpHAwA28FUvhVuCAC9yMkrHloCAOo3sPPIBAEAmGypb1cFBABvh+OIaugCAM9guc4jrgEASpkyGYddAgBuC1Y71rkGAHLUyBQo3wIA7aQK4r77AADseBKG7Y0FAJXJwraoWwMAv4Uxi6XeCQC9uyPNVbQEAPiDSMAZ7AUA1TG1lqaLCABcxWbykzcHAAI7yamIuQAA2yUjow6bAABefMFxrnwDAF9Ihd45/wIAesXvw+4+BQD9LgLpn/oCAFSBEyzHmQYA+B+9HnUqBwDPR0k7YyABAPcPEklHMQUAV9DA982vBQDtjXgb56kHAIgMO49w7wUAk7M8vjN0CABCAGGReJgEAHIBXX+dnQcAxJ47AZPCAwDKyjlfuMIAAFlNm6kwXQMA9JfpXMBEAQDvfzSKC5YEAPd0XfER2gEArf7AGaxPBQBtr+ftc9gCAG75XU7hAgoAS7U+vALqAgBkNYiydYgDAN3pOlGMKQkA/xWgGDZUCAAJNDdDZDECAK8iO1CV3gUA3+LqGyCZBgB6c/9JWNsDAPoHR2Vz5wIAwSNMl/S9AgC9YdLIubMEACi8qbLoagIAUVwWEIIGAwB50GIzRLEEALicUhzpVAQAz3K/xphMCgCZ2MOUZUgIADv616MTrgcAZq+OQThwCQB6H262x7cEAJjZ74WhvgQA+FUQcbz6BAA4/jZ4n/sBAKYtdUb0ggUA5EwyINN7AQDGmHgRiRQFAAtBoJJNaAEAp8V4D9nkBgAo2rzEocIAADJpvWlIgQQAuF2kkcO3BwBBtjWsFnMFAGoJ6R3jQQYATTEKs6mmDQBHBB9v0McFAEk6C/hw2wcAeJrIPkrLBgB9OYGt6DsEAGRvHL1YxQcAPUaW0yQVBAAdGp5Ea1gBAIrtSpB+8QIAjjwdhtLhBwC6r6BcSkAAAL5vQSobngwAVmwxC2ocDQDbG9eepXUNAB3sHxoCTAcAjn9uUSeVCwDWQ6cKB0AHAIMR3ctkawEAQ+sye0s/AgCzNYKlqxkDANmt3L+VYwQAnJpdGi3bBwAvQoULIJoHABbdcaq/VQMAqnhf6ncLAAAtgp6ieWUHAN80tFITtQQAZyYc0HsyCQCgyGA71zQEALpDlKja4AsAdqKyS1EsCAAXKsBJfo4GALbobzSVVwQARjWPbDCJAAD2iC9rn9gGAFvgyU04OgQARbbxi9rVAwAJbWqp1t4HAE0v7k9JwwYA1GuLnJgsAABIFZYgCRYBALpNmzYWVggARm+shqvsDACxANeFAMYLAOn8DeE+IQgAbR5J1zf2CgCqz9opaRYFAIn2MWuCkAEAfUppZ1X1BAAi5bH39AUHAJhWvCXhUQMAvnv2GkabBACWOixxFVkHAA0MWO9nmgYA/M9w7zhNBQDifG7QgvEHAA91IY5ySwUAKAEbl5CaBgCjY6nyQBoNAL6mEqzpCwkAxEEyBMxKDADsaAGrZI4EAE9vqLi9ogIAKWktazs0BwCj6YyqBNgBAOlDw8hKfQYAd1d6T7trBQCPI3xiMJICAPvXLBIarQUAZONQbqXeAADXKjHI0VYFAA7oG7FWZwgAPbB7fhRiDADfvz50GWUKALQqaFn8ggcAx8iM46uXCACCOY0M40AHAP2CRn+0wgcAHNzHuJHNBQCD5fmQp38HACTY0cbGRgcApC2lfofJAQCJYaiDe7MCAKUNMUmvMwcA+wQcFoFeAgDovjRK4XcFACvXTb2+zgYAnzJC5MFACwA+qdH/RyMDAOC7LCWJSgEACbCPSzAFBwAKO6dhrGgCABy+vjTyBgIA6OvLpwO0BQA1QZ/wYKEHAHj9lu6nDwYAxm4pTTUdBQDHFjum9csHABQMz7ML9QIAWsbKhbP+AQA1FsrgmBMCAO5Vt7T5qggA8kSutZFrAgDIsXqNgN4GALAwVWdppwYA95hOKPu7CQDzMys4igUFAD6RFhipdQEA6Ipruc32BADSgdrJR3MBACNa2dk+qgUAYWXZx+l3BwCszAbwWI4CAEmsLLu7QQUA7EyZgjLmAwCV6OUUfqAEAJukd8TNWAsAgOQC/ojMCwBq4/S3qiEHAFOZRsmMQAgA+UrYrvcKBQCZ+Q2YyxIEANwp7tiN5wUAXVeM9t9xAQBJ7/bSXQECABPTkcO68AMA5Vv2FQHeBwDJTTYhLCQEAJhgpmRbtwYAhcACATwDAAC9rmsxGpIBAIvB89marQoA6pozOBbsBQA7qFllO3AFABLWBU2f+gsAKwbK3kmwBwD8cLjffi8CACixd9buaQUAr6Ww3DcJAwAb6nicA1gHADonHvSNRQYAg0RENXrjAwCZe9K3/WEGAOQh1h12FwMAiWECMDwyBwBQKbzMPQkGAEsDhGC+7gYAe40K9wHPBgAKZ8ZUGrQIANpVu5lLyAYAR7aYDBjjBgBtcOCFhZoDAP5jJud8FgMAl0Lb7BQ9BgC4cPncIb4EAHqChKAefQUAcbAooee2AgDPXXURdbIFAGUFk8KEhQAAWUFv2nuMBgB72d2Z6WMDALOuS+LcSAAA4wXslVe3AgDJbdrFpL8LAB03nmXIqgkAmm+8efkxCgDEH+41wUMAANXyGZkcoQIAzbpdwkwzBgDaALQX2pUCAKCThrfpjgQAxvMqzEveAQCG66MRxB8GAMAuwZrRPgUA4AS4xtsJAgCSh7Cpv3kAADJC1aKA7QkAeF4qx/4OBwAtgirUUSEEAOgx1rbrtQkABUdZsU/vCQD0DTDaUToAAHIcViu1ZwQAkOUQApLVBACFlniedsoAABdIaH/HOAAA7HsWW+ZeBgCpULgZ2lIAAClkZWWGQAAATJpvWTmrBwC/oKSS7nUFAO7XpApFvAYAqAs7d6b0DABHvA4LGyQGABWTHU+cDQwA9ILj56EACgDPLxiKkIAAAJi6txMpUwAAw4XDeM/cAwCpq17dAoAGAD/NEnFOPQQAxTr56me5BQAxCljKrGADAGLyxtVfxgEAq+zCFX8cBwDkUSal7FAAAOpo5mB2OQwA9PKSVqfCBwDvZmx+nrILAJnavFimKwcAGhP6CRwVBgCcDD9F3hoDAGh4cwfu3wMAEdSn9+wRBgD2ZL1sfmMCAI/FIWzusAQAll3w/Q1cBQBeR8+dVgUEALuYdCdcXAAAicNd2YiFAQDwAKhP8v4BAHNrlzD1rwoAWYTASFrYCADfQjaW65YHACa2xFDuCwYAQINs/gWACgCWMaca+1MGAPoGg+z6BwYAVFI+yF7oBAD9hAWQVp8AAIb8kpLURAUAiIZSNJ+6BwBdLbQPooQCAP5vcNksZQMAs+bdrXv9BgAW8zApRy4HABR2KtM19gsA/QDerOzLCAA1qepBEUEDAJTL80IeHAIABv4A8Of+CQBPCIGXjCAFANIk3KFoZAEAqEDFCni/BwABU9fOfqYBADpzwujSqQUA5ffbA9oFAwDKrreZhiIBAMlrk7IjKgEA6eZqpb2hAgBA4B4FlA8AAECXrwe7kwcA/frU7LbnCQBC+2AVeywIALZfzDRnKQoAP90l/X97DACyMNPDI2sFAKbRYOMIdgMALnLI8+AKAQA3thi22YYAAKu+6Md5fQAAEt0IvJz7AwD/cFPYPVwHAKwZKP4GfwQA7RWSqwbbBQBk6jUKUsMBAEbAayFAbwgAtNkPm1eiCwCL7H5AJhwHAAtPtUraKgcAEm22w1CHCwBKo8u8plMCABpwMwQHJwQADof5WI4LAgDMANthyDcDAO7QdVfQwwEAGuUilEDxBgAlLc6+a4UHABwDL6eAMwEAuvOngBA+BAAEM30sHmIAAPPw27CWFwYA9dYynC88DwC9flPRjqoGAPQ4GMmSTgcAAhDKieXYBQCNg1mCzGAAAPOVW/PTOAAAI6lDwnhgBQCyGySTMt4CADq9l2B9AAAAS6lCCJUdBwAX2MflEWsEAA1Py76LRwUAXRwKSwXDBwDLwYN3PVgBAMconcwERwMAAPKxmOXeAwCebXSYHG4BAN+vlXALBQQAVTzoZICVBADheqJd76IGAJ2dLuCsigIA6PBl6VkkAAAzCRXTZLgHANge6PKlUgIADehmUCaUAAClYY2RD6YAAN4P8/dLRAAABjztqQ3EAQA7hL1wwXkAAFbQ1cBQzQ4AuXnnamC3BQCh3WsivQ8HAPkfOVMeZgUAuBdzDYx2BgD/b/pk5OwGAKBgpLxAzAMADI37CqnjBgAoEqG8GoAFAJ+sNF7A3gYAs8FV8eUlBgCWMnJvL/MEAM7vBQGYrAUANu5eFmF6AQDV3E3hRRQFAEKkviurRwEAJjEl8kDyCQCITjGe3sMIAF6k/KSlHgoA/OSGAJkuCQBRSRQ7SysAAOpqlneJaAUA/Z85bheOAQCLk7ReXOQCACk5HvOGMQEALrvff7OWBAAhPl+dQ8IDAE1qfv5gbgEAHWKbiO/XBADp0wU/LnsHAJGw3RKcYwgAsnrNkAQYDgB7RpeCkfMDAKyBF75oRQcAleBSURl6CADexC6cxakHAC1leZ7w6QcAhi3yIuSjBgCLbIM7jq4CADKtx195OwYAyF+eOAKPBgAGdYe88VkAAOwMQQ6ZBAUA4q7+0NebAADwMtCD/ugDACnR7+iNTAgADSHmBnzGCQBpFH+PN4MBAInSrs5SQwYAWGKaiWAtCgCUonAFuRUDAPElqQjhDAYACclTEvbvBgCwcC0O7wMAAMT6l7ejWwcAltHNcMDbAQBHTFOxj20BACr6g4FJAAUAdd4jxFkvBwB5d7gHTZAAALlA+UhmLQIAhj6HoaWXCQC7VBrE5AcKAM/WSzsLNgUAcq/rrAokBgCckbrd1B8GAJlWtZHp2AcAbMc8RzEbBgDWMeYxlgMHAN3B+0MhPgQAoJWiW5x0BAAGX0v6RnkDAPFRWqvFJAcA89OdeDNWBgBA2zjy2msFAJ87ncFs0wgAYSLXcETsBgCuqRhwPYUGAOvIwk0+qgMA5eEHFaM6CADrMzX147kCAMUGqCfXrQIAoxXOyFVpBQAOKQoHT4wBAEE32IZK0gEAH87U/0h2BACdnoORlQoGAKsXgfPVJAQADsESacQsBAC0rskdJjsEAFETlWyLPQkAKWOPfgHABADE+VOeVT4FAOpuiEYBsgwAPykkXk0rCAC7ebuIGR4DAKu8s0YvuAcAQXuCzqj3AAAwcRcWWOEFAHay9VwFJgMA8o3RKMtVAQCUFqGcDcMAABkxqycOCQIAtkl6TmIIAgDT5ZqAbHoCAEFpPcQKJwQApVlW2UztAgD5KHWzDVwPADOSLP28zAIAwtgDNlAhCgCIsQ0fzesGAHQRfUvrTAcAXE/faGHVBwCK0W8Xeb8AAAr2TxdnywIA0OELOfnNBgA9K36cUY4AAIEIpdLDUwIAPTOOREEbAgAPiXNL37EHAIz1+AcYIgYA5Ys6gZL6AwByVY3DmNoGAI9GVFXZHggALTVdJJiGBgAkorKz4PICAJIcLKJqxQAAeLLxOez9BQAG8cf1CskEAMWPZfLOHwYAehgYKoVdAQB2+5q123ACAKuSzwsS2wcAh0BxXaLnAADw2nPE9GwEAC2BSfGnbgQAJ4QKaSUHDwD6efDpOqcIACrGYUSS3QIAzNhQrloGCQD55cSe7SUFAExoYAbSIgAAaHs5cCuXBwBl+dNYOaAHALVO0byHkwIAVw0g3yVFBACFQ+lM+dcCALfscMEADQYA8NjzAwWLAwDO8WSOGZoGAO3Kxdw0RAkAH3xmn5DHCgB1tR+dgxoGAHa7ygA48gwAfia9lyZbAgC8eBrZ4LICAAzyzBIKmQMAIiYf4cJBAQAgM6X6zt8AADpJkmqeNgcAZGiYE/s/BwCsE/e4KygDAO+X8njtnAQA7x1mJ3BpBgDkVNuDBkIBANBazMFvuwYAnWaR1cgyDQAybKhNea8JANIkbdjp4AgABx0WtIMeAwCX0Z0kHr0AAI9WIBjLCwAA1DCIcbHqAgDml2mB/ZYDAIpQv75jCwYATysGnhLHAAD9EltBJuUBAD2SJ/2gYQQAt6Vw9q2LAQBQ1WLr8VwFAD+M9X3jtQ4ADcaGOfO8CwDm6lyDuE8MAKNxjsHemQgAnyumum+lCQBYPcJlEBABAA+LM5ASqgUAIXQunn4VAwCJ1BcgceoAAIlwRVamaQYA7MmdXFBrBgCHUuOG73QHAF6VwETZ0QQAICvXOUwuBQBYnHk2SDwBAIDQi11q+wQAm1gISeOKDQASr3uXTZUDANxBdFnqEwQAW47ch9wLBQC54bNaRl0CAEco7Cf++AAABk/w2+bWAgB2Mhv8jAMDAHtjOsmAbwYAEeHfboM3BQANLHs1Ar4CAPjUyFju3AYAkmEdWDLXAgD9JUdEVt0BAIfIuggA5gcAUhh8OFw9CgCnM/XxXZ4HAM/wxfH55goALzr2UKSjCwB9EmIz+H8EAPSxgq85jgAAq33yLjKIBACkoaI4N5cBAPcZIpFF5gAAJ0Y52DEvBwDxAKKU0nsAAMZ04gC+ZQYAiza28eg9BACaOjnZyBgDAIXTHaspngYArGvHs4UGAwBZSPI3z2UFAPn+jsIqew0AT1kyHKQJDQAZ/v8qA10EAE7ebJvkLwEA8XwyvGMWAgDd8WlMXooBANWhecbHJAIA6SX5ptxuAAC4d+Zjg4wGAM/75CX6DAYATkAJdsHEAQARijIC/1sAAOQSxQ3doAkAD81fv5QICQA2nD8BSSkFAMc1R7oP9QkAGeDefCd2BQAL4MojcBMCAMYm65k1WgEAPCtRIXJoAADpJAg6y1MCAKSiP8y4gAcAXzBPI7yKAwDeA8G7gKIHAP5daTaomAMAGopSQa/QAwAbJyaHQf8FAC2VthPoRwsAujwcwmRoBwCodM3bSeAJAJt0kw/WtAUADArKuE2dCgCd24kXDAgGADGnHu98vgQAgICddg30AgADpkRMfV8DAJZawj2gBgEA0FMzM68KBQA1uzxhmrUEAHaa4cDfIwIAZMWyKx59BwDLUhClOKsEAInA3V/v0QcA2dq56+q+BwD7rKAL01gIAI+uteqSzQUA0k6waxwECwCT1WhnJSsEAE97QlmE6AIAAQdjdjgrAADl6gXUeEgDAIoI3BrdnAIASOFW2fnyAgD+wWWt5rMGAF2et3IJsAUAr11MI409BQBJQIHWuwQBAFDxf9Zfmg0AKjXQ6pipCwCZr6RfyYMIAG4mAfzb+g4AcbAPovIECgBn7fFoMf0AAD5KeOcNuwEAdwSyeMtLAwCCIS5uoqQAAKeScMWMvgUAebDrMD07BAACGcalrFcDAFUk1sVwtQUAxxgenrIPAwCRJ3yxD1cCAEckuAtVqQYAJSMaCvIRBQDumyPXJJMKAMMWdcM8NAsAF+Ad+cVBCgB1FbYsfzYCAN+HTcCawwYAveXXi5XUBgAyFYpj9GYFADAwpV623AMAqmzeQCkXAAAbRWcuWwQGALP8PkYHbAUAkW7+a4tyAADf/NXtIIQAALsQ9AROwwgAaqDQwO1EAwBtTdiGVOQOAPRjOMsuTgwAtx0yT2VNCABK+mKDqyAHAL/ZzUdDnAIAY4RfrZjnAAD+C8uL8f4EAHbB+z6l2QAA1bW93RbBBQDPq6W7tNEGAHpTpUiK0gQAmQsEW45rBQCRiWHypKcEAEsqN6+RsgsAl0T+KDAOBgAJak/KeyYKAEKyQsLuGQcADj4iFGOpBACVX7FfAhgHAJT+cYNrjQYAfNn3SESAAwCAQnj+ZiQEADHdzcRQGwEA1v+kCEQnAADdNNuugtMHAF04zsnPCgQAHlukmbsoBgC85tzkvPQEAG8LncRuYQIAHOZihF35CQDFWZGbPq0JAPhNoHWkmwcAlRVW7iwEAwCEJSTiWs4HAOPUU7Fe0gIAyamb0POoAwCO6wQNafMAAMBxS9HNPwcAQaybRHlwBgBPSCFGnLcFAI1rFfJpEAYArxA7VybrAADOqclA54kDABWsDlf2eAUANzmcM/JEBgAsbJW3R24GANBVH/4ySAsAYmJdXkJcCgDOudw0rrMEAJ+sFRppfAQADEBdbuAYAwCxPvjZIsQDAKZllDdFFQYAbt7X8aYGBgDnB2HEwPEEANjl+9yxKQIAJxN7CsasAwCEVJEImlMGAAZKuxTU2wQAuNvxSQiTDwDvymakxSkDAJvrT1QkyAYAmwHvIFP2CABz99LDdB8CADq9CI24JAAAUUEFz3jmBgB8dC4nMTYEANFcrEpeHAEAxuD9yrHRBgCQOjBqx2IEAJv/PGlOygMA/YZX1CyVAwAww957vMoEAInSeD+PeAcAEfizCSiUDQCbwvh3MpcFAGf+xTv5EAgAsaxlgUnuBwAuCpwIJJYGAHME58hfBwAAEyMdq4Q+AQA7lfbtC8ECAMghAz+5OQYAw6ERkeMIBQB6L5EOEpACAEOurGT0ywEAV2FX6XNTAQBgW8iT9O0AAABBdoTSxAcA7KwGv/7+BwAAQYJ6+5oDAGX950eOtAkA+R1NxQBMCABoWptZWIEEANnVQbx1/QEAPF2pH/zZAgARug7yJ9oHANQZMC65AwQA+FxGi4EvAgC4Cf8dkEIDAM2Dxl1ZHwMAgtZfdFd6AwAXJqsSu1UDABhzjFrH2gEAYDRC1Xm2CwANQLa3/LgGAJ1fvoM3xwYAKgWOr45RBwD0u5N0zGQGAON0GHaUPQMAE/aWF54XAAB9huI1BYkBAOyCIRO4+QAAMmx/G8RZAACRFFMGh54HAIK1PGRHxwYA5JTUCgziAgB1sbtxOHwEALBmUMhQXQYAfB82U3QWBgASs4uBo2sIACF1qpvyrwYASI3OAuqPAABIT+xxl1MEACjKrYsxuQcAxRbgrxkPBwAjjWCxe+4EAGlkV7iJCwAA0OreaHbdBQBJcKQLbQkEABSRIZdZJwYAruZnitqbAgBd93SagnMEAMkCOa06UwkAeuQRa+DdCQB2C5PRvoQHAGfIuZIKyAkATE7UtGjGBgAYxHlGddoCAFoQvjFMFgMAX++YK6wfAQBWknevGloDADyDxISGBwIADIJ4eiHPAABp59LnJFAGACqo3e+1OwIAxtMyttSfAQCk+FRgGkEHALR1sRg95QIA80ogVHI+CwDExKHV17wLAA5d9irCxwQAw1gkh5rsAQBtyJ25Mp0FAKypIl4HrAYAcTMRIJILAwBuljim2X8CABO4T1c2wQcAm1CiANSkBgAcl1YQeUEAAFwHbobVVQYA+E3m8yswAgDWfFyK2K0DAEYwOVnUmAoAt5A9y/4LAwDW+D3quNkDAHkVUZYOkAMAakAaE6EbBgDy3DW2cFcBAHGV94PNngUAvX8LHEbbAgBfNIGpQjoHAHnIzJ+SSQIAKZCVFvGgAAB6NLHXT5cFAK3tCBzM4AEAEx+t+L1zBgCOvcsQA2IFANaF4nf0tQYAyGwy7JHtDAD8owN1U9YOANSIOXbTJgYAzlg2b4TsBwBD1jRJQ5MBAFGqXkSi1AAA4G/ninDQBwDhx8O2R5gDANnZpKJ2dgMAxy6iHT+PBgBrc6I5gO0GAHU8TOB+YgIA0edHppDqBgC5mTNyr9oGAI+Oray/BAMAB4sQfZECBQAP3aZsF0MIAIMdLI8V1QUAO+tYnkS1CgBHvj3rYnUCAOcLF7TXkQIA4ajfZ8rRBQCimPJhgKgCAH1icZ5OMAEA/pzcatIUAAATb6EbafEHAKxu8CgY5wUA/P/wB+1JAwDdwtfijUYEALsHY/jG2AoAcgmFoWsoDgDTRISw3OkFALJiM1RqqQkARjLmJ2TaDQCeRhmUXjUDADeK6rh7hAEAcZvPiGX+AQAia9vSybEGAEu0/8bnzAYAyiKs3ojGBABSA//DdfcGALsZ5D5gZQUARhzGVkRUBgDyef6rKY8FAPbNDnG/ZAoAaoknhcUIBwCUM8Xm6iwMAGkr6CEbOAQAtIVBcpOvBgBoPueNq88GACG91M7v5gMAvg1QCWYFAADfha0keBsHAEF/SpxidwUAiKjGCUUCAABEZi6xamkCANiAS3+izAAAnhEb8cHHAADsyrBb8gEHABPBvnzZ9gAAo5N8+5fODAAaKBFagzkJAFWR2nqQKAcAVQkFvKUgBwDtbGHk+LAAAHW4D7XE0wEAmAHcc5byAgD6D4PxsPQFAEDc+yvJ4AIANVqAm0MJBwCHgX9VSOwGACw6oRtNigAArvkLijR2AADvRLHLuekAANu+sV3VmwYAvTH3R07hBgCsDidHXqMJAI3feFQibwYA08+RQdRmCwCtIFf7j9QCAHffoSF/ewUARQa6/w5VBQAxqZhAauwFADfzs04QIQIAFIy88kMXBADHc4etsJYHAJtou1zunwIANIcXXGYiAQCTxWtOehYEANuPzvhlJgYAV5jFGhCdCgD7n6W7O9kEABc/N5d4ewkA7LcMNzNLCwAAJ/Z2KJ0DAIdsHc3OAQAAdXZ0ERrwBwCQgaGlDTUCAFIl4reLkwcAzNaBhu6RBQC4eeq0sJ0DAEIIOA8iAgIArOBCunbyAgDm3+LGbxcBAKUOd0mJ4gAAcnsUiJ5VBQAw72NuHl4LAG7/p5oQWwMAkCZP5aP2CQCbYZxb0GwHAJUWkLBUlgYAJ3+3EDelBwB1gdKnHpoHANV3xqTDjwAA6jQH05nBBAAUzJrLIsYGABYCA1UKZgUA+xGfGfFoAACQaxHQ+vIEACW2O7cd2QwAxBKBU4JfDQDdFZgnWtgGAPmczbC3QAcATpTylRlFCwBUTq6UQbIGAJeI7f0KIwIAcVB9YRI0AgCbljUP09UDAO9ySUpIRQQAfH3qn9D8AgAq0p5rEpYCALIFKgFxoQQAI1VNx5LbAQCJQmDKiQsBAFvwRVq+QQkApq7si7OtBQC78kHbRv0LADjOtbuI1A4A0/CeHS19CQCcKBiXSUcBAKvH5GeKpAAA469LVLwPAwCK5V8xAccAAHV7V42HCwIAaj4/BxivAgD+JA1C6joDAJT/9IsAmAIAHpbbcZFTAwBcxjz2FCIHALYpO/S5twUAs6PuMepJCQAIFlgTd74EAJheOWB52AoAU6FVyEryCQCTpgdTQH8DAJy28mzm5QIAU5yuZkLYBQC5U+h96+QFABwXWIz0/QUAqgWVjjIIBgCaxB2EgiECAAcjHYmW7AMAAy7y/2PzAgA5ruI5pwsAACa7iOr1JgQAyHV/55IwAwDnGdhAOaUBABOGgU8uEwkAjFF93pciBwDWkIdc3pgGACXrW1S4aAIA3/6Wi2TSBgB8sB2tiHkEANd65qODMgAAObkMvscdBAAECRBmbLEBAG3GyyBMogAAgYbk7+miBABxYoSWEl4AAFBFLCTIuwcAtzU7EAaaDQAyIPNKfiMHAHpTsxpCJgcAjCU4XfKMBwBaSZwts+4CAFCXL3clngcAI787g0fXBgBJ19UW2M0GAJg2wckAnAMAaJ1IMY5rBgC14hB+hXMFAHIUqhboOwEA+Eut02QZBAD/s3YgtQYAAC0IzrkWfgsAuD6FVy+ICQDEH9CsntIHABXntVlq5woA9qlhlS7eBwAceJWd4c8AADxFHGLMEgMAfAfa5qxFAQC46ZzvK5EAAHa8QzR+1QQAy16ltvTUAADOO3O7sOsHAEkFIAVqugcAaSDi5O32BAACpvEKqbIGAArYslsk8wsA/G7zIPflCABswGDPzLkLACV58yPjhAgAwXaCLIFlBACXHuaa/PQDACQt+usHvAMAoNRctUS3AwDzIVeyUyUHANMSnU6P/QUA2WIQKrK+AwCoyYI7BqcGAO2XwV2jpQAA7z2lBgzIAwAWy7HCMlsAAIKB1XospAwA/p55fmbIBQChUMh0Xi4IAJmGTmHb8AMAMGeFpHEXCwD9qE3SzF4AABh58P27gAUAajyHhjXnBwA++Xff7UwHAHG0N2pVtQMAgtRN4STFAABWxpZ0RYMCAEXNts9rrQAAFCSw6NF1AwAzpyedB/wEAA3FhgxEiwwAhTvKnJI5CQAu30zk8vgIALGmexEyhA4AO64rDBdBAgB/L7+JsDgBADnqNP1boAQA9V6STJEDAgA8TuD/f0kHAJiv7HxWJAEAtHPECoarAQD/p4Z8IsAFAHdEwr8SGwcAdTCoc6UGAABwyGYpYfgDAACNBDb6/AgAgrO7M3FuBgB2VqSoQksGAM+Fmk9u6gwAoHjo7ldvCgDeDSp4yQwCALOqcDBOXQYANndUMY68BwCYLUOxv54AADaXZ3eqBAUAse+HVtUsAwCVYS9ej0QEAEUDRp2RaAUAJxqt4MI0AACj29lDGQQEAMqqbKJDdwEAZMn5VpGMBADQmh6NJ+8HAAG9p47lDAgADIApFJMtCQCWzOtDuu4AAHj4lVPdhAMActI1GjPfAQAO90r97AcCAENolx0KQgEAT1k305l3BgAYYI9URxYAAEXxeFXOfwUAcSoUDCIJAACaNRQj+bQBALFmmKQwMAcAeSYL6StECgDOfZTY03sHACggVcFV+wkAoflWHRn/BQBRCRWJnRAEAMtHLS29JQIA6jvngMB8BQDLH3J1ENcGADLxp3K1OQIAaJAtrDPUBgAzcKQw+SsHAK0OovSsTwYAKkC5ovdlAwDzWKcmxSAAAHbMQvBZ7wkAJd12ScKxAwByYrFcZh0LAFbFcORWhgoAK2Cl4M9SDAC829ie+DQAAPOOjZSPOwcAq8oj08GGBwBRbiap1DsEABNTYcSsKgAA33d4ZKD3AADU8JMPzOEEAJAR7yZH7AcA+BL1i9W9AwC4BLPXt88EABLviZfCmQYAULwh4+o7BgA1u61AwyULAPUr5KHhYgUA0zTEy9SxBQD+dZu4bD0EAFYOkFuNMwMAUxpTfTKNAwCfG9VhXLIBAHWQsyJGSwEAJp8KzBUmAwDftpy5EXcFADg86RScpgUAmcWkgInoBgCShSVxj/kCAO6mVE9ErgoAwcX7ejkVBgD7+PODdw0OALmGxF9nqgoAE3aeLgbYCQBWng+1TKcEAJIBZMLRMQUA0n9snT3AAADBEGYVzXwFAGqAnSSupgMAWnyQqYXaAgCvTOwhN7IGAKI6aKTT0gQA7/0Oh8b5BwAl74rOuJgCAN5lIQrqcgoAbtA+73mBBgAerP7AueIMALpjGwsp7gsAfDqAcWK6BgCyDPfvU3kCAFLFDq4iTwUAJCcuqT2fAgAYvSIMykICAM7VBISKSwMANTNpg7XsBgBNuN+/duwDAE+gVs+VyAIAUk3VSVE1BgDhZdS9Yh0HAPVe97HatQUApbm+DNbiCQBW/l0XwicFAB/1jyuKng0AsWISYjPDAQCA33jTKMwDAKaMlvRBIQcADW3ba2kHBAD7/C+ycdIFAHIxfzFfTQcAgcrZZ1TlBwAN9YYxZaUGAPEt5uyIsQYAcUmENm3GBACdflTEvK4EAP21VHOejQAAaMFtC3VrAgDJrAEeiGIBAKUBHfNtlgcAHZrcnb1zCQDJAW0nGwcAAF4CjpHYsAAA6+Kep+5bBwC4TQmEKckDANujlb+P2AUA33JY/h4PAABqJRgjh9oFAGBZY4HrnAUAZMeTdvOMAQDqGTvRHG4AAFMDW55irwsA5OiIoPEECgAtqO6c/A4JAEqjLzyGiQ0ANtiooabzBwAjbxZvUa0AABrIV231YwIAyjhGOCI0AQBQCq/xHzMBABZuUgMGCAMAC4A9XTlEBgD83r49ILkCAFWjVuaMsQQALBi8ZjQ/AAAT5dLeDw0DAD1HuGgelwwAlfN5l8wsBQDIVYKuBOkLADiT80au7AQAWBw1hFBhDACzMxLyGk0BAAucs4kZ3gEAnm9v3GkmBQDHP4yyNDQEAJnAAkIhqQAALqC5rsAZAACS15VpwKIBAEQcV7HLZAYAsoD6Ngf/BgClXInSoLwDAL8BzJ62jggAjPMtkci0DQAN8sKLf+oFAK+vyhblIAkAJ984QIvqBACkYl08vDEAAB4ITA/+2QcALPJnFNU+BAAJ0R4MzOYBAPHo2u0dYwUAAtLK8QpGBQBdZdCdkbQAAEzBGH1pxAcApKK7kMgxAgDKQgWT4EwCAIUL8/1VoQcA+YfU5cbGCQBZ3EsT4UsKADFvMnBZQAkA8yRzipJJBQAGwQb99ZAAAP1DHgKxqwYAoBHX+rwyAgA3fwQ8waUDAG2gKDxOHQQALhruY6cyBgBNXr3/S/oGAJJHuqY1/QUA6J3pHV61BwDPDexttpEEAKFk2tCOSggAvW4JRfzsDQCxiLST7u0NAI68URrBswUAGHALi2vPBACnMurHPbEFAB4Tc9vCjwEA41ePH2XjBwBlqV8FVlYCAO6FDI0zjwAAvXMamSGoAwBwWI9B5jsAAPCerI7B3QEAwo2ZnuBMBQB4sC6o1DAFAIu/mmxFcwkArA0QFSCJBwDL/pVA4T4DAGQJetaVrQYA+8sAfj7bCAAlSPnhMDYEAAlAa2qV0QQA4LX4Lf4TAgDmkRGk41wAAHcB8VOnXgYAY2MJ4j78BgCsZ225NuwHALFYB2rsEAUACSEC34ftAAAaHpLBTioAAEx5z/FiYQgAuF7+yt0kCwAXMkbg1RgIAI1CkpCL5wcAZ8DetRJtCwCiuCQ7miUGAJwLF/S1iAEA613h3sCBBgBFdPNl5t8EAIAnEcVD0QMAV0UVeZEnBQBNQkEHj58DAD2SV7NuXgQAb3TbXpssBACCuoV4Ue8CAFEvWzD7vwYA3RLXshKxBQDi5E+XdFcDAKPjlnr4SggAn7MLKWh5BQDcrliMTpcHAMaINAh+dQcAi7znKsYBBgB0q+zCcFMEADoUq4+38QIAAeEgCkO4AgDj/ogdnqQBAJZNzke7iwMAN9SEuufwAQCqwl3jQ9wHABiXPidcKggATouy38krCwAZ29X49I0EAI8CbJeHTAUAUC3YgftEAADD2X2IZWYGALKwagp2KQYAbD4kx+aBBAB3/EZw45cAAMxYZwFy7wcA2eMHqcUYBwA7OGuMybkDANzMXiXtBgAAWZoiOGWXBgANw/kjmPcHALqH9WjwHwQAU80bGQrACQAkniCcb7UHAL6qzF8eeAsAbMAxBJtKBgDoE7WjOdIEAGYQG/UjlwIAw9kEz/RCBgB6m6BaCdoEAE14PTfgpAAAGSl9W6HWAwDWpUZQpxoEANrTwh51kQYAxCFnqzg2AgCD4azQp3EAADFE4SBSNQQAgTkoKjbhAABUljXYfHUKAI8NsXrN6QoAdBd2z5vGBwALuofIqi0HAGDaXaz0twAApJgELNq9AwBgARiqZ04HAKduFMe8wwIAXynoBOvXAAD+oG8e6qUEAGBsQ1xjXgQAi9HUqPSOAgDKKjKnqfUGAKtE2aPr1AkA5NzzFQ8QCAAkeDYOcBoGACM9q5IikgUA0+gOaLkqCADFxkEvDAABAHRxc9+fIQAA530Sf3IUAwAeuCN9J+UHAHoULhrilAQAmg3l3YWKBAD0PUk098EBAIlohmTbewQA7I6PBH2aBQBrpL5s17UGACIleB4XQQEAH3zaJm2ABgC5mscbHfMDAGhRn0UgnwgA0j3AabhvAQCU2QzsbFUHAApRtwOa6wUAccuR3dEKBQBHirSAV6oBAHdSaD8zrgAAYgm2M5cZBgARZSZ8FZsGAMrxk/hARwYAhPb7CKQ6AAAN97g4HvgDABHIF181fwsAWoE0U+h6CACO5NLdq+MHAOVFH77qHgYA7c00LT6tCAD+r9l+zA8BAPJv6bCMJAQA4nJRERwxBAAlab8c1MkEAFBPEPwQBQUAnSRuM8UPBADhLfs5ZjgDAHh70XH4uwcABIB+a3lfBwChD79YwScBAHS5Ua7EjwoA09vSv4luCgDOZXagIuEMAMIFNCCxygcAfRadR4LtBACieZguQnwBAMP+yEZZigIAdyuRLrM6BQCl4J+gTbQHAPR+0IfvVAMAddnFYCK1AwDcHxc2aJ0HALvUQPGU2QcAVBhWBMS2AQCSUyAt2QIDAGTx4OS2bwQAt2VSrZc0BQD8hhOg2+sJADtqswwvMAgAbELr9cXtCAA9KKS8osEDAAIvu8cwNAIAwou1G+qjAQBhXN5jVyYHAMrxdjtdDgEAZ47aU9a/AwCKKsg+lYQFAHtwp48oXgUAgR2Tw185BQDLYRPFRlsEANHjf4rdTQ0A0hnGQczOCgCQTaxiZToMANi9p6yl7wwAISHzrsDBDQChf08xvyoAACgVip7RkQMAx1+JE/qiBgCRperdjp0AALfcNvp7FwIAj9t5+rwbAADhZjbrS9gDAAQigR2SDAIAzjI7PYTdAgCr2IeTYa4EAIP7W5hEfgkAIcwmxjJODQAXgfMvQZYIAGkkGtZBsg4AQrrlq4VWBwAuo0RTqvYDALsRD2iDlgYAqiP2gTVMAACly3VYrwEHAPN7sZENoAEAsvJh6zMJBgDSTSrpPxkFAD70UKWV2QMAPYg6uW9VAwAOO2KbUjUBAOuDLuK8FgcAuD64MAE9AwCsr9C6KpUIAIkb0072CQMACllRoC6XDQAY1dGt19sAAB4j4iP4GQEA4n1ebtZRBAA4+HCZwwAFAKNcpoFbmwcAEXiP3CCsBAD6AfWpiZUCAEpratIQ2AQAWbKWDeDtBQDzBVnJ6fcEAOuZUjU9RAgAOO5afX2bCwDrNC+aUZIGAHjPJElA5A4ASRRK7C6UCQAuMIFXvEsHAEzsgbs1MQcAPEhhG2fvBwAp18wURiYHADjmkq2TGQMAkkkjrhlTBAC1T9JHnSECAPZssIhE8AQAEkpynqo6BQCc7xRTpqACACd5HDzNGg4A5XmHt0aLBQDyer6smjYLANN0MHSwCQUAod62OdxVCADCJ/n3f5MHALalxhT6wgAAfNBt271WBQAI0XnBrPYGAMJHhiFuzwQAtluNwnwiAQAjdvW/6Y4HADqJHySyjAIAcmc8HlRbAgCiCnEHoyEBAMmDdMc+cQkAyvrVcgX3BgCB/yJO814KAIcRFE+UTQ0A0s6mlLsnBQCXSgOfXl0DAJu8hZcGJgEA8E+Fx05HBQDKSKMCo5YCAA6kx3b8MwMALkhbmSqZBQDHKgAHx40HAEEX0JRjkwUAF+8aKKT7BAB6CrJpkLgGAGTbx7WM+goAD6gqmOYYDwAaGhr4lZ4LAPpsZPOU5wUAOXaKMD1HCAANInBiQaACACXQaYskXwcAJ2plFrzLAQAoZ+LW/7kFAD6nOhDCOwIABZ5YAyZ5BgBdWZKY20gCAAgtrTylBgAAc7r3UAENAgBD4P079wIBAJocUbXg2gwAVdTg/38lBQCAIevRCEENAPmumw/MlggA6aRdcr32AwDGRVd/q7kAAGMd0vjwygUAK+oIpL7eBwAWbYmT254AAMClXtKXZQMArFhgEHuNBQBp7gvS+M0DAF4BZbdMCgAAyXx8MzJoAwANpp3B7LcHAIj6fKdRSgYAtQ3KcPScCgDYmAhuC7YEAMfm/90EXQUAXL9hxu07CAANaVxpPDcCABjPDVLIwAQAuZR0S6+EAwAlIqKOSqsEAEMXYNdaIwQA9XWJBw3LAABLDFM+MZICAAmlJJG7jQMA8RFaZdBQAwAG3wwrzucAAOZwS9nf/gYA1L9Flz84CgAAw8Qnrr4EAD8/akGkWgcAzq44YSUVDgCjhYzEOmQEAJK4NSeMhwYAd9j0IzWlAwCd7ovtBKUDAEb72KXgZgYADctwSE72AwBXZW2xSBUGAPOWNXdhogcAOl0nX01yBwBNUQ2BvPAHAI0TcnOtnQwAdBDT5d5FBwDi239epbEHAKFuF4+YugUAWuzdB6nTCQBvE/QmpGsAACC3Bgb8ygMA2pw1ovAYBQCn7G/k5foFAO2Oz9v40QAA3IHQPjGTBgBCF5Bmo7AFAH7KpCyHDAQAAZ4AlIDxBgC/MUq0EQAAAFynCmppHwYAykKtVwqLCwDI/Qa3muUJAMy/btQIEwgAUCgtipg9BgAMbMY/bKAHAPtHusG6yQEAjgN1xTU5AgATnMVxvfADADXoFtlIrAMALiO9r1MHAgACYNAeux8HADqvpEeunAMAwtk0C3wzAACKNrJSrT8DAOjPIsTQyAQApXFZJ7RgBwA9rRy8ldoLAHVzW/9R8QgAppDLXDXMAwAWHuTFxkkGAICq5u5nBgYAkOErGJ0XBAB5aX5W2VMGAG0lmkIPbAEAMZE+kEOUBgA23fnGSm8BAFOS4hJJ6gIAXdJoPmS0AgDnuib06jEGAOgNcKO5dQEA+0iqAF98BwAXA8qFd5ELAJiTx7KpWggA92X2x/IxBACf/mbaEAQBAH3WtNyCTQIALXUXDv7mAwCPsMse3toEAJHqsUiWWQUAGXuPhURjAgDAWilKPfQFANSsUlynQgIAEA0igESTBQBTEvkVR7AHAMa65sSAwgYAbnZhs6OtCwBOO1wS5S8EACKsSk3YEQkA3XylzwqNBABDrvasKL0FAH2QVo+rbwEA8tUYErGsBwDbtCMg4B8EAGUvXL83mwUAcearfeQmBwDB9kbnRewCAIZGx1MOWAYAdD9nBKHtBQDTNhMZNGIBAECG8x/WnAkAqBu0xMZgCABuNqcM91wHAB4BbPGoGAEAuQOiB1eiBAD2fyb23pkEADx3CIGFbgcAKcvdxcqTBgD0nwrQEQMAAAVdzf79zQIAau32U4pmBwBWJRQuugMDAAkJwYQFiAMAHSYKACD+BADkSNKWGHIFADva0KGRUA0ACgXBx7/2BAC+qS7NTk4OAG++i/KxfggAAkv8WpM8CACuGxj9F1UGAG2Bdix35QMAiolAlhgZAACZdN6EKu0BAMFjT9fteAUAPQwrScZ2AgAuk79A/JsAAAszH/HoiAUAbsJNaW7RAwCMKJC1KuwDALjRMq4JOgEA5LRauB7oCwAerjykrHoIAHNjUtcFLwYAuq3GZr/hCAC5e9jke9IAADS0XSMnbAUANy2mDm4uBwA56G7QTGcFAPwAoiVc3QIAfogseenVAwBVvKtNchkDAAAIaHh8uQIA3eY03d+vBwCIrjWLVDAHADTj1qFLCQMACzDjpybhBgDF+/yuwIkIAIJlgx+h7goAg4d9J6KFBQDuuKjLo1EFAIbY4itCtgMAvImWQeEwBgBVqacHO2UEANsRtEM0BAMAYonUM4JfAgAx9K8Ej70GABJjmv0H+QQAm9I3x9MPBAD5DpV4YmUHAIrPhuqjcwgALZz7q+LgBgDuM+o4Kg4GABj+8ykkCwsAPmFLSL+LCgDAyB/VWc8DABhH3tagoAcAS7dvPjpcBQDVT4hfE1MDAIQbjAoW9AMAfGwTb1wvAQBM3jei2/4AAESrv868eQcACWlNP6muAwCPGFiznOcBAG6B4PXYUwkA/C7buzOFCAAwlBKWlxQJAEKGFjZuegkAHp3TUqt4DADx4/fuwzYEACYAH8LT/wcAqS0K8nvnAwDecoT8vxgEALOjs1F5XQYAWdFSktOkBgDU7ABZ45AHAIZ3l78lBwMAU6A1FlwKAQASohGkh20BAHAFTtXi1QQAdF8/s9flAgC/fog/3qULALY5Yb0k7wYApqV3tZD5CQAVYgZCWn4FAHc2mESLoQEAj28e3lLmAwDr2C7gK1MGADhfFsiHjwIA1vfoG61OBABm9DFPnXUFAEN59EmBNwAAKU8r4zufBgDWNBX+glgEAORvPJQpmQQAFVtUcnA0DADE59fOayILAN6J7UwTOggAXkDOQ/jcBwDWg3l1XTQBAM3MNEL1IgIAtNuKPUp4AQDMK4zuvm4DAG9ij1v+iAYAwDJHSkjWAACSLVPGSrkHAA+FVIcbdwUAyGEU39mNBABxMueHlnMGAMAaDMidzAUAzdSGFGeDBgBzgV4aX28HAErf+fXT1Q4A5tdojwvaBwCmdVY4FCAAAO8dPbVfFQYAfJKJLqN+AwAuqPVoplkAANzUoasVYQQAdtq1w1MZBwCBetMzImQGAL2xdoBlyQIA/xAw5oGlBQB0NuiH+KUFALlDpqDTKAYA0pMMZNgcCAArD9fKsLcIAL1EgalNhgsAG10trjc+BAARPaFwzwEDAOyRGLqhpgIA4Do/+5HyAgBS6kuBexoCANFEbmWbZgMAM+Gm7QY/BgAPB1gnNDMCAHXAnEXgmAAAG3xsrV7fBABe/dRsHqIGANCymWYSKQkA5z1gohHuCAAgTMf1wgoGAAhoGSoZmwUA6AFwsHFTDABf5kYwChcGADiepEYaQAUAqMRhVd0KAgBGnt7ttKsHAF8ZGp+/hgUAC3n4Xo0IAwDbtPwmIYwDAMPjSeG6hQYAMOmkAda8AABSDnkD++oAAB2udQ9egAgAJwqGWcxkDADuC7C35UgKAHSP73WW2QUANVRMNONKBAAvBEg3wVUFAMAyQnVB0AQAB2mGMLQhBQA5nPtAjjADACygdcasCQMA7kOlu7mJAgCeUyguWasDADrYzauCTQYAJ+NywY7HAwBG+bchUi0GACl69zom1AUAsK6JIt0/CgDruX73ZNwHACxAOIPSGwgAITk4pSlPCQBtk9AYnCkEAEmKQYNBkQUA1a4hxxgqBQBtl4K6UbECAFTHS97vwAUA9deyJdx+AQDuGwimNnMDAMPlh4gxtQcA4VsaSW2fBADgvsdlI+cFAD6zCC8GOQsAsc9X5vO7BABnWW7193oOAI7Wnn/W2wwAM7dcVSALBwB/IXFFB/wDAOtqK5vSoAMAneXdzHhkAAD63RsFTV4FAE57xAQRfwcATCwRVcUTAQDKt/kDUVMHAAghmh3tQAEAr8I7MyIlAABkoPSYQ+MAACgZSz4JCwMAEgPIfn7OCQCDj/e9deUMADjtCxl6Hw4AeKNs7a34BgDovc4+2SIFAM/24EXwJAAAoc8mNLZtAQDYD9MfOrkBAGKjaFNA5QUAmrK3/T0SAABoPFJWQzQEAF/uIXlSmgcAfoE+y/xLBwA9jexy3oAHAHIn9ADz6gcA40w1iFFFDQCryz1KytwEAMvrv9AU0wsAVyvTavzeAQC855oIRYUCAFzBoOmP4wEAezfi4EYgAQCFqApWHHIGACgZZ78o6wAAp5VR7xq+AwDrtb1iL/IGAEkwUrholwMAvf37yJQzBADSjb8B0mcEAJbnela99AYAg7cXk8haBgAyif0gO30IABVpMgjyAAgAg6NbWpzvCgCtT+90mpEGAL9SFGHUngUA7wnqBOyRBgCE6QAny8sDADy69cRDHAcAzXSe+vZtBQDfVs/klZwHAOIJxjtkvgcAeOjZKsFJAQBfDDnKWKcFAIHcYR2LkQgAm9EMJlDTCADYtDdOq6IHANcUVHPqHwIAnWN/AjinCACVJEbZECcHAFZ0AKqvWgIAG6PqKB/SAgDQXwDqcXYBALc+SySu2wIAzOH/Vy9KBwABcwhzMLwBADScAfRX7AcAJKUfLghOAwBqEjWmjGkCAA7ZPV4vcAUAx8VwSpocAwAk/HiqpTYJAAB7nzsvmQkAoq/EsATAAwB4urAyiDEFAOx88Z9L8gYAx2DgMH+kAADQyA1UhIMFAK6cxNxD+wEAK7j0BqxGAQBVc57YALUEABKKchweNQMA4y+TaZ8LAQD90RzQP7QGAPMOdj5YQg8AtxYyV8E9BwBKcdf9SK4EAAPhE4pf+AQADf/WsiA0BwBExZdGS10HAPT49//hGwEA4fdXaOEZAQDV9Vw0FIoDAC+1BXGNpgUABh6Fnsv2BADllRhHxHgCAORkPc7N7wcATEtcRW1PBgBLo/4yVtsDAMIlmIKxkAkAyCUyUdPnCACtq7fjK8EJAKWcHnh3hwUA8l1J6peRDQDY2V33K+4GAI2+NOssxwYAx140zMl5BgCkmGj5jYkHAHWd9K0hQwAArlrl5BlgAQCcIF3yxU8HAA3tnZNqVgQAt+AW52NgBgBwTR/cr14EANqxzM8kRgYAwbZygKtXCgAJb2clBxIIAO2OTtAYoAwAbNWl7jz3CwAr10WAhQEEADAtyuDlWQQA6oswGbeIBAC1MhsNSm8FAC02gLzupQUAxo1OCtG/BwD0Nmc2mcgHAAFc+eq7XgUAij+QYLBtBAAhZhKJWGACAC/ldsY8jgkAj6mV2XlgCgCxCHkhfEoIAFll5gN23AEARCQLod/eCAAE/2CDpgQHAD6L3jzMzgMA/2QPR9UcAgCJOZWNwasGABXm5MLQSgUAKlIruNVnAwDHfT249NMAAI3F20x/BgMAN3lp2lIEAgCpd6oryy4GAHQotq82KAcAQLKUIDyvAAB6NX8phcIIAOLWgFYtzAcAY1YH1RMZBgA9KxVhUnkFAL08+rrboQcA1YglxTGtBQBcaGRBOl8EAG2WmpGf5QIA2jEyGjYtBgC4AU4AhFIGAGAd6TtTVgYAn6gAbAGuBgAFHBMqvN0DABS7lieiVwoAdD5E+2DzBgDq6iBy5IAGABgM8aXy/AoAH4ONs3/uBQBLxV7O+Q8EAFuzYeKFcQUAqXAOVFTiAwD44wNAgbUBAEvASjFoiQcAjmpEQcv9BQBxKv8maSgFAPazluIx8gAAk0bIV6OEBgCgvMkzBh0GAN9z/Pi8KAsAs5X/Bt60CwCkEbonpAoLAJtt2r8x7gUAZ4DfwjqyBQBmJdv/NUkEAG5sF20BLwEArvUWD7D7BAAqQJmNt/oDAO16hP1l6QYAe1KA7lO5AgBas7HNW18FAGY8oj8LOgQACoKLOAduBwBd2Z27m5sHAGFzn46ufQkAMtoCYfcZBwCLyoAqfBENADUJXbZmGgwAyqxgFIG6CQDCJjFqQFUDAHZ9chgZDQUADo5JC+rlBgDyFDIGtqMAANKfjBVfBgUAVJlCDPtpAQAQ7uzZ7ZoFAAIYhesWmQMAOMVcVRd5BQBPiuU5H5gDAMtv5m2l3wUACFkHCYgFCACTSoXL2NMGAOOxcOn0sgUAwcvtUkQPCwCTCiNZdYoDAB+ji94cLAUAPVp01PKkAgCKotRCnX4AAM1acIPAjQMAQJd1xYInBQCtkNmXMz8FABVN6Mc5qQMA4Dl+IsQ0AgDyk6Wh2TIGAJSEDO0R/QkA4Fcn7bMhCADFwY/lHT4HAKsWRsgQ0QUAZK8o36elCwCmywe4FWsDANf+Gp6K9wMAH49gLJylAAC3gcuO3SsFANR+hEhPsgAAx+obUb7UAgCbW57ZpL0GAAFOkZZpfgEAgM9/zvCxBwCBVEd0z08DAIWqz3irHQMAt1RebiHjBACJtnM5gkkKAISI5IRJWAoANvtCMJoRCADKZ5d4TOAHADK4zygbZwEAN8Xhon7lBwBBQUTvqvsBAKbfZMG90wMAfRfC6JzYAgD0LBi6Es0GAJd2msGKCgIA2XLMsvo5BQAg3h6PCGwFAO+O8ySsXwsAAquXYVzXBwCnL6TCSz4LAESBtBDNxwkAjzVI6rc4CAAXbqgQET0FAG1GX7ZuQQYAIM5fI6YcBAASu5mK/MMFAAiRucZ0lgAA+G8xmSH4BgDp86nxVF0AAEonvdDFvAMArdXSuISyBQCeliUQ4+UGAA9iBmMO+wQAYOZHl/UwCQAZ1OyPhkEIAMU7koxeEAMAOBg91IoFCwD7k+WH9WIEAC02zqdL2QMAt2cmtfkwAwAK8OBIWtQFAI2aeBRRjwAA0GN25f0PBABHBsLURRQHAHwPF2g+ZQIA1l7F495MBgA9/k76SWUCAG5mP69JhQYAaLvUQSmeAAA8/10fMegCANL7H/meQg4A4iwT/g2hAwDW+WseRloFAIMusPTujgcAzxaMZE/TAQAyUboq6n8AAB5Axh1ukgEAoM4X6opOBwAPvD/4Q8cAAFVUv8QDywcAmH6RqYuKBgDlYdgBHfoBAKuU39EArAwAGie9ASG6AwCvxLmIiVcPAH2f9Im/8ggAn+mO0c4/BwAymFl9lFUAAJAZpCr+RgMAWxl5gEwWAAAnunv7zJkHAFynxjtWcwcAs5wTYwjpAQDWoNkHtPgEAGlPksokjgUAVmTnu0aiBwBkuAG3JvQBAD8loZHINQYAL96O0+tqAgAFrt36yG0GAIY3oEF9HAoAffqzsWu3CAABHJFBTCYBAPm9hEX0AgcA3o7GH1E8BAD5Ne06LEgAABvTcVKv4QQAm5OSf/nBAAAXwW2ViHoBAMed+V4A7gYAzDGycpGqBAAqd+th3bYHAMfSAav5qwgA5QpjhwKIAwDb7VsEyi4LAM8yXzZDfw0A9b9Ztqk/BQCSPfNQ6MEFAPX2uZoR7AEA6WPmbW/xBwDG3hbL1qcHANLx6rzpAwcAVVSIlOnIBACCrZzatcwEAHXpEMZrWQMAXp/bDQyoBwBhTFw+2ZgDAPLj59JgfAcAcDh2URAGBACq0uzgxHsGALlzEx+UuwIAMCwAycmZBgDzSOIzZ9EDAInjS+G34gAASnj22g0sBABQeMYf6okFAJHx3bUJOwUAzPFGWSOnBgBgvi+7nLkGAGJcSNal0wYAwCPpZpSDBADd/MYwrxwFALRUrBia+QoAbu5hlqOYCwDizUAeM4QDAKYZ3sQVzQQAjp8YnOIqCQAK4HR2QqcDAMF0fk8vFAYAFTqMMZPMBADnHiusG9UGAD84kqJKUAUAzwENH8vABgAz1fWeRocBAL9HN4g4cQIA6JA65Sr1AgC6jpX+FP0FAI7Lk79e/goAh+fLitomAgChfvuigwgBAETPQnhwlAgAXHJg+XPdBwAsq0Uo3y0EALt2Mv1PIQYARlIaGI0LAAAg63nVpmgCAEeG5Sb/kwAAKZgFaP4kBQAhtnzkdVsGABnM1aWwXgEAWp2SswlSAABHa8jLm/UCAO7CkbZg1QkAB87j/Lr1BwBsgBQWVs0MAIexcGGLWAwAgRDQ41WqCgBfExeZQn0EAHDweqDP6gMARG60RqveAQDfbKQ7P6UHABrl4kKLRQUAT0QHDOaSAQCqHaJDiK4FADgVC5Eh1wYAfkGmlRoyAwBop6gEkD4BAGyHOxnJAAYAZXcNihscCgChjrN/knkLABrg23l2DQcA6Y2JQGD0DQDbzi+DRYgFAHNuDH/NNQEAW+Po3/s/BQBb5QZeGS8CAM5Lgeg3OQcAjfR7KRZxAwAglwYNnloEAOxEpxr3WgIAo6uKy/AaBABeHYlOis8CAKJr0Bd+SAUAlmUtAyqHCwDfSJPAKF4GAMJAzrJrewoAaR2J8vemBwBnDxEHh/0DALItqRaHbwIAJzB1G6rNAQBhJrVYvgQFAFKC5dabBAIASe+aao39AQChbyG3Z8sHAIK5w1P/egYAKJbaEKYOAgBZVPytGgEGAH34ywLI0AYAe0xV7b9BCQBiQu9nttsGANx+hSYxjwUAQJN3i+GcDgA8+JXPbZIHAOwrDhIlLgQAFfrxbek9BgDM+fNQa/AEAC+2sMFc/AYAy3mYsihVBwA9WhLSj5oHALhqdEuNfAIADCECP4n4AAAQV66zllUBAMokUX4WMQcAP+G76Dh7CQBVkC+UW9ULAD6RvpUUnAgAbPsaJE6qAwCieZE/0jkHAMToudv6MgYASAz+K1LIBwCpWu+DCe0GAPS1h3Yj0gAA9QUzKr84AQCYZdgkXfQBAP5gIa1LJwUAKtFYHQS2AQB6aOSmyi8DAN/MhydzpAcAQAZ/fEIeCQBjjF84WTYIAPprdtnq9AUAACZsM/ZGBwD1mn3FjW4FAHhPvhe+swUASy/4jJK/AwARbwpgVS4FANbr75x+YgQAHJdsq0XzAgDp52NuKFMGAK0jirdhEAUAAUW1rJlJAQBm7QdwkbQHAMqiU90oGwwAheqHX+h7AwBBXqjS40sHAKZsyfqHvgkAzAj+IDbQCQBksISrXPsFALCFgnc+UQIAQ+AlMThXBAA9Im61o70GAE+Ebze6IgEAVOW0os0yAgBA+A+jK0IAAPVDe2bnUQcAPl/aVRcmBgCOtlK/cCwAAOFyjUW/Mg0Am7WW55YPDACinW+d9y4CAHfKvmerAQUAQ+s/fmmwBgC7LwtdS+wHAFBUWRDpAAIAXnEFcQVCBwBgD1MicPACAO8JpPA0YwIAwKNi30rwAADZtou07eAFAAPA+6RKwwcAJKxcTk7XBwCyQTT0N8wBAKauzsnxVgYA7FqtrBwDBwBXbHHQjDABAEIZlHMTHAwAlfFy90ajCwBPMsdcWlYHABFKJNWgHAAAE4dBZ7AWAQCu7VWMfaUAAAM4EJyAxgYAyGra4hJRBQBauj0KPTYGAAz0povJGQMAx26jA0voAgB87/a5EVkAANzqLlHzrAkAaCppOZhjCgAGBYM0omkGANQDBgySiwYAsmQcne9VDQC7Dt/1g5kDACaYlYkl6gEA1s0Dh2POBgAFhYl4FjEGAHCims/OswYACL1zO7pwBwDUhuH3dRQBALwrickbJQAAWsz/m6tOAgAXOBPe9HUGAAqz2jvZ9gcAJdS/pazzAQBglxwcUvoCAM35J86AIQYA0yyIC0UPDgD8ghdrA1IEAMWBdrCVLQAAsgWS+RyQBQC07F5uaJACAEwWcN+ZPQEAysDlIcNeAwApQPQ34zoBAKctP4GOAAQAOgyOLydABgDaXuXpbcABAKppbf9AKwUA+n83CYgbCwArTNFcYjYFANEXLiWvFgUAK9Pn+JaABwDixD6j1noHACHTEdzFFwcA5COYVRShBACx4qFQzgYDANvC/qE4zwQA51z6DWWqAgAVlPGoFkkFAHgS52/JDQAAuD7mhCdfBQCRYKLTynMDAJq73Yn7qAYAN37Z1TWMBwCyLO90Nm4GAI/dU6xHQwMAKhGl7UcVCgB89cmCTWMEAFLWpmiSJAQA9y9/aG0zBgCg2SZOT/4EAEFUlD0PBAAA04ZZ/TnpBQDfmwFHISoBALKc0OdmxAQA3QPSlVv6BgBUojSjUDUGADZ7VHJFWAIAdxMcgVhcBwAbF8w3xtMMAOI0fXQwPQMA16f6upKaCwA3z2m17dYHAKAs3KWUAQYAphBedFmvBQB1SAA+9agHAHivfSym7gMATieT5hPHBACks256G+0GABWOfWnOKgYAdbAqKbhmAgCcXGagNoQGAGkQIOgX0wYAyqMsXYGQCACgmRTr8T8IABjjUPBgOQoAEBbJaTY3DQAnPy8g6DUCAIAXti6fTAQAA3AdW5AwBgDR6nTSyPwEAHiraH9uewEAV1IOmqsUAACli39WOZkAAII8Qip7tAQALcR65deIBgCHj2daS8sBANQHoKJiqgwAbS32OA4eBgCCR8yPiC8IAP8b8oMrVgcA9i7Y0g/cCgBs/Eo5a8AEAMw29ksbkwQAeCMy0GArBwAli4HGJ1ECAEPnjae8MAMATnQZEYT/BgAFk+ToYMUCAHql5e9PJQcA36dgxeJ6BgDxabPhG8MDAHJCy/mTvAgALBhz2/n4AwDE4brqNbIKABlVKYe/3QIA1eeXEOwcBADuipQITYYEAB72jUM30gUAZ3AfYIWyAgBT1+a6vF0CAC0mNBG2MAMAioBtotcZBgDyvq3Cs8MDAFJ/7J58hwYAbbbh67m+AwCH8pHNRGsCAIMDc2KT8gcANpxFUXn9BwDnSS1RTFAHAF/FO37thwgAJcdJAbHeBwB1dDiPR0gAAD6KZ9mXkwYA83bJVoF8BgBsIolVTesCAArBweYJxwIAeu5mh2qvAgBs2aF5qooAALAvm9WSLwQAB5wAQCx1AQDOYv/paI4AAPnyuArVCQ0A5OV7JKu4CQCF5LLmstkNADgTmkel+gwAcI9zvRPLBACtMMFLClAFAJWGk3qhJwEAbeM0+iYqAAAozB4u0YQFAKPrfvjz8QIASrYV5XWMBADwHgdSaVsHAAZUlkJt1AUAn5+YBmF0BwDiCjw1HpoBAL29ltXNcgkAgxaI3x1zCAAUgU/WJgQJANmjqdhPGgcAaiaQOb02BwDDBfq6YHUEAKMvzKvcGAQAgobPzpFZAwBgjEupcUMCAMMgHLFGFQQAtLM0k1AtAwCqcK4sEGwBAEX0G9UNcgEAIZivL2auBQD6hytaKRIEALPqk+JhUg0Ay2WbdSZkCABHahGuZQIEALzlugQjwAYArZXRuAt2CADp1n71iJsBADmjBBm/zQQALE9OzUkrBADZCRl3LhoHANJSuz4VTgEAioHmzRcaBgAniBA0rT0FALZVXMUyKwMAo0eTXxb5AgCsM7zpS7MGAMDycWVlaQwAPkJvzmGqCACgJxvXQPkLAGnRc53xhQkA3OZie5wbCACywHg6ZC8HAHueT8BF3gMAXPowjdYGBwAkL44+9pYGAC2S8BgsAQIAKZ3IWuVVAwABcewUtOgDAJAMUnywnQMA4e93mx70BgC65IS39YoAAEsszInSFAsATbzx4lA0CgDzki85k80IAHxrlGoMNwkAl/1aHTxCBgAzJR+I3JkEAAbFdmTyTgMAlxR00gfRBACz/W69xEYDAKFjEdd5KwMAarP87dn4BQCQOb/c6OYBAArzijRPlwcAfJzxTnLmBgDiE7zvpYAEAAwizkLkTAkAyxYlp4CJCQB2ZrgN+HIIAG1S2h8zAwcAyJF21DFLCgBxIGIBC+cBAGqh+LVj8QEAF9QaNK9qBQD3MNg1lpgHAHvLAHaiegQAw/gVwO0eBABKhe8njc8HAPmTRljjiQIApwmzV3hKAADaTdGFtUUFAOEhs+PQ5AQAQKzS4x9FBwCNqe549mYGAK3+Z4aFOAgAjEzmwy3SBAAPOtSgXicHAPfM130TgQYAOJq3upznAQBqpolEISoCAKUrM5wv9gAAOV871ollBACWP+x5+eoHAKi5chXo6wQASmlhXX8bAgBxY6MB+sABAD1qk4wOKwgAIM22WDu4BgCAJufT2H4DAGIqn9s3oAgAu9KxGVQADAD/PZQitgQGAFgadPaZyAEA+zLy4hkCBgDL+aeSrl8DAMqx8xQ2+gAA8IK+ub3+AwAAFJKVSOcFAAYngjjqUwUAjMjPJHyhBQAK9K4YovsBAJQBez4EVwYA5+nvVRvBBQD7dKDGe3MHAMxV4xzk6ggAdfc/0TXFBgA+9cj6SJQEAGo16MZ0TwMAotsHBnitAAC2PrZ+OiEHAIaMqqzjkgMArzWKPuk0BQCXyQL9EIsAAAUeuKzCagIAeTvOmIydAACsUE3+F14CAKch8Xb1fwcAK3L8sPnlDADHKA2blG8EACbvF13mzQwAl5b4KKi7BgB29gQe15sAAEWh8kHIWgIAcTiCrH6kAQAaWGzDqKgBAPupQhR1VQIAATn+kGa8AQBavFovExQDACjVMlGDEQYAV4q0jkvyBQC39vcE1VkFAP1m0vbnkQgAiHMD72BgAwCGEh3siIcJAK+ORxxEhwIAvVQzauojAQDVVOuzeIMDAO6Uj6eq1AQATad16AKgBAB8sWcThQsBAOMHWC2xGgAAli3jQZAYBQAxAgkrBlsAAI+352YXyQAA7DihVQ+qAACKkSwelqMEAB4/I/NE1gcAZMACnp/GCQCXaCbl5WoDAHmL09rBjwgAQL3Z6s6KBgCgu+b44DsEADtOYfzfjwYA4Dtbqx3pBADwLyHJ1LEDANuxP85rzQIAEMLX8w7JBAAWh4Gg9ZYEALg5woz4nAcA2/hsMJzLAgCPUFsNdpUFAJAnAv3rywIABRHsKoK4CADLvCbSz9EMAL1xSfqyFQUAFUX1XSzLAgCXY6oE4b8BACVsmf+UFAEAAFg+YlFCBgC+RODFn9QAACnL7UP6CQcAyir9Y4xdAgBh/d8pzcUEAAWvSOvALgMAfLf5kZOPAQCBDM+eAg8HALmwEF6qrwoATCVVg+AdBgCNwuN9WOsIANS7fZ+78AQAvXQqWspOBAAzPu0uswcDAMLoPLCKdAYAvBC4mg18BQCM6SSiZCwEABTDptjVtwAAQ9WVezJIBAC6pOOBZhQAAAxOw60UhwMAMI4pDm/yBADexxJFInICAPx1qUKKuwsA7hdrtNXyBgDlcDEiqbYHAOa34z9xUwgAwWt//TWXAQAuNMVJr5IEAFcDWt9cNgIAYLv/pzghAwD+RkbR96ECAMxEivFdGwEAZkLIQtCQAwB13I8q4+8BADgSrudekgYAMujQgZKvBAD4HRkR+f4AAEtleXBhaXJQdWJsaWNLZXlTZWNyZXRLZXlBcnJheUxlbmd0aEVycm9ybmFtZV9hACwAAAAEAAAABAAAAC0AAABsZW5ndGhfYS4AAAAEAAAABAAAAC8AAABuYW1lX2JsZW5ndGhfYm5hbWVfY2xlbmd0aF9jVmVyaWZ5RXJyb3JCeXRlc0xlbmd0aEVycm9ybmFtZWxlbmd0aFNjYWxhckZvcm1hdEVycm9yUG9pbnREZWNvbXByZXNzaW9uRXJyb3JTaWduYXR1cmVFcnJvcgAwAAAABAAAAAQAAAAxAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYA13E8k/znDABDsrb+Qc8CAHYafQocWAcA8DJNUy0XBwDSh/pjwJAFAKjVtEJgpQEAU9GeFcyJAQAErjyq3rgFANi1EU/wqgIAkpxmWlm7BgBfepuls6gCAH8I71mzqwMArwXbxKj1BAAFQtAHqLkFAFDqE1uvAQcAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAnwn8jrlRAwAOBaekv48GABuXnZVJKgQA/Z5GGuWTAwBYHjIQ6YAGAL8YaAUKBQYAvzJVH8wqBgAl+snMQYECAIPmcfRhTQIAWkTH9DN5AgAJ/3bE6fsDAEJLLphrrwAA5Xi6URKtAACIfO7trhUHAFM19svQ+QcAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAMXEVd+vuBABBB/EVGSABAFacbNqcZgkAbDTbMsBeBADDLGq7Vx4FAKSMfXu2BgAAMynnRPqEAACKb13lThUBAJBzLoRdQgQAF+QaxGSLAwBxS+oCZzIEALUwYDc0aAAAgMP5EgXvAACEJVHyqfEAANbwqZGOCwEAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAfD7dBGZZDwA1iwUOUfwOAAzMso0MZwMALzPOmdiXAgDOGwZ2XpEIANk0kvPtXQcAVDwfqzYcAADa9Vjuj/AAADfWoBOW4QAA4CATSgKpAwAakaLJ2fUBAPj8+pR5EQcAxY3iyqjYAgCHDAmysUoHAMTswsUHaQIAHZwvYw7dBADZpSIm0c4KANlCR2HpjQkA07Xbb6mcBwDuAJrUN90GAF5RqklUYwMAq11H0HjhAwASl6ESRwsFAK30D4bC3AIAMT3w1nYNAwDH5AYhF0QEAIgt7a9REgAAWk/tm/w0BQA0Us85WtgFAGToEnFpDAEA8sdYg6AqBgCU4UgIRG8EACv1qHG3RwQAHdNpMrp3AwCAUPW6+TsIAN5fvn0nxAMAkkzUrzWjBQA+dZlAFsEAACPkbwCHBAcAb9a+ymFeAgAEZljMKOEDAOLHjy6LlgUAz2G91aNJAADm9h5bUBYBAG5YNIbXZgUAvS9axoVCDQAfdPjMYl4FAESQsWG5awwAOCBxBTQVCQA6eTRfuk8JADQIwZyfpAcAxiKKeBO1AgBbOfJuS/8FAL8H9lqO7AIAw+ylvHU5AwDU94VpFkYHAJrnCgA5mQAAevlkeUyEBQA9W/nhFzYBAMU/qM4pSAEApexxTi8LBwA8ZPyOFCgHAHZbmQM+dQgAZmersl+/DQDWNUW8w18IAMKV3ZeEewMA6P+01kkVBgA40bEtohcCAJ6wLgbPuQAAWPflcZz9AgDd3q9SrrMAAJfkGWannQEAjlXSVAb6BgDUQV7SGYIHAFHGdXR2cwMAkGUkFMuVCABnrKYq2AIIAFBIvIPxQgwAQwYKHE9GBgAHCXMFWb8GANmt0UD9mQIA9+UEmt7yBQBZHMy67sAHAAop+LGhzAQAj7HDVur7AQCKW0Hh8XgHAPTB73RY9wYAfwIZQGmKAgBN3GupNysFADWmZ88hJQAA0V4vdyBnBAAi1lnzwDIGAFLioysJsgIAgCYRfCViDgDVfJ89dQEIAJRSnQoL7gcAJ8pM6/uBAwCdYz46H4QHAF9EwzDqdgYAghPnpwD6AwA02z2WLSMBAI0HC+eSVgMAH3p3FMpHAgDQ/OhrVdsGAI4E+uJfKwEAkh5vrSZ8CwDkeyJxCWoEAEybLQ0vcgQAOuBOIEbcAwBseSA86fcGAE3j/JbE+wAAPq59a751BQAJ5s6FFaMEAP8wOQLpNwAAEvuWb7dJBwAFrqauBPYCAOsjk5PcNwYAR40Em639AwD3WgTUsKgAAAIe8BDs/AAARU4kxJ3SAgC+R8Ebe5IGADkIrDSFMAgAQD8DZDaFBACr/maRdxMEAEQe/kmmWAUAiczvrjVGBAC68odIQ/8BAEQtDiKB+QAAUTwYpxqQBADw+BqMVLcBABaBNlOMhAcA6T0452QbAACPfFiw+wkBANEmt4e4GwQAm5FmfFlMCwDDD5m2UKEHAHQikp3rKwUAGoZkce0OBwCpxnDgcagIAL5GQ3REfQAAHahkpbaCAgBrI3X4gO0EAFAMRR2++wYA2/wSjHLrBACJibxLmbUBAGAGTKh7SwcAuK7N8XhWBwAM8dawBjICAF1o8gBz7gMAGHUehEd5CgB+6NqIcywLAOgbl9OtFAQA8Q4vg1AYCACI+yxqfNQHALfWfZ7kVQIAup7VYyGMAwBFWAAqH4YDAMmuy0we4QIAEnkpdhU4AQDg1vCOFNACAPuH540qUgMA0vl0XgXuAgATCDH2OEAGAJ5M01jPSAEAWnXkmn0vBwBK/A9pHnEPABUNWzWigg0As7aF6M/cCADp6tS6/ngKACfwNHn2kgQA1ChVgdDeBwASZhpRYYQFAEQV3lAu6gUA29XroS//AwBmOZOMH2gCADUWkyEFhAMAUoYwSvF0BgCQSKmInL0DAMbpL9BNEAQApWoJ2wZOCQAjsOaJnCEJANqihtSreAoAH5VgkrJACgDJ70haWxYIACpCJBFevwIAVq5WZxRzBgAw6Iea2UoBAP2AsGXK6gEA9foKsGPIAgB2aoSgdKQAADIemO+lmQAA5r9LPK6oAgAsgxSvNFwEAOz/m322kQUAXbUYn3GzCQA204OMMVQHAJeXkbcXfAoAYJsIhLBFCQAAA2f4tIkEAPqbtIAcDQcAJUaRfX7VAwBF5WUhcsADAE/gGTi55QUA96h87ALeAwDvkus6LRACAEY6DNUijAYATomFk6guBACM81W/nl8HAMuWpLtfnwQAG1ecHoxiBQCrIugIsZgFABo2Ka6PXQUAKHup0citCAB0hihsGmoIANTPW4oQmgQAEmZ9jowXBgB1A3FzNPABAJhgSmFJOgcApr/chkpgBQC2ZBd81NEAAFEuajEIHAAARVDJRduzAgAMMI2BT2MBAHTin+iJCQIAG+zqhYsnDADN4ntlWe8IAG+HWGnRLw8ALwsmBbLpCgBYcA+VuTAPAH/MLTr9dwcAMkkS+6mUBQDwFcqAjh8AAGky7DzRFAcAZ8rQ0T5AAABSxU6HNS0DACm58Y0E8wEAI5sXO9cAAwALfaPle+YGAAODMFR0vQUAKnnnFSGTDAC3MLm7uVcEACYyGYtdjwYAVtQej04WBAB/BiOxfbsFAMJMsiiV0QIA8y8wuGasBABRrf3ZyAEHACc3W1yzwQYACjgHgKczAQC+YsrGZ/QBACzBXSojxAIAh7ATwB1VBwDNO7ARDGkAAA6P1abcQAcAPEN4BFeMAgBjpHMoUNgBAJzU3n4eZAcAcfVM1e3sAQCwwlZSP8ACAE7Oz1IH7gAA6fsWgd1gBgDr/w8TZ1EFAFyVhbiCxgEA6mOpX9JhAQB9pFN7dRgHACEvD4vhGQYABOzB5N/7BQCSux7ImNcFAGvZ24tGmQYANRmpauY9DQAam1ka+EUIAJJBIb2o9wsAGTMSpE0dBwCixObE4ZMKAM/+2vRGLwcAo/fe+o+UAgAEvPP9zR4BACXt/o/pwgMABTlHmiElBQDhElGSSxMGAO0GtCuUuwYA4t3ARcRwAACj18Qi2BEEADLwR8QFtgUAOfDn8Mb+CQB8RyxpvM4DAF6pGWqYdwgADot3oarqBgCrxUzvL/EKAIl8xCBZgAUALJf5cUeSAQBAwJ/fvYsDAIGykgAA9wEA64rq3HZKAgBAx8DfsiIFAEjhgDQZ6AcAuUFDoNk/AwC8IIpnY8gDAEOKUbIH5gUAAc+WpRxDDAAEFIB82hUIALQQj2+bPAgAFkCTImk0CABW5Dkx8wEKABgY32yPHQMAFksUS2z4AQCdPte4dZgDALOn/9nw+wIA3cy2ynoGBQBRnQMIa38CAKrfAIAvgAQAJcVioJKWAAAXWAeR6roBAGAkhqjLlwMA53kTyPvDBQACL14lvBsEAFCGmVb3ow4AQXzg1H8pCQAbHiwCtHEHALJZWfCTMAEAGMYuLzW9AQCG6oibeHUAALlI6hcRHQYA5mYHMp0zAgCnLzpRhtkFAA8b4Zk6PwYAbbLWzw6KAgCPjeE1aDsFAHGZIYmhMQMAnHJ1nTovCQDJxFPpAA0JAIkvbxHfAwYAiODgdsI9AwCaZP8ZlqwJAMaAT/tFbwYAov657jjMAwAf23ByZAcBAMgNdOrxEAcA3zu4xmcRAwBoEEtSQjgDAEX+MJ3TfQcA0KBBIUOJAQAlwrhO/ogAAIvwQWNDEgYAJSYtGuNJAwBssaZ/ehMIANt+d5KugQ4AUNz4xb8iAgCQjRejKlIJAI2JTofbQQUAMxuE+4AtBgCX+ifwbj4AAOgzlp48oAcA7+UJI75uBAA4SWFpUy8AAIcFoq3lVgMAAvlrn8gbAQDbyBlkdDYAAENSUA/nXwQAfhSVyCBJCgBdTJRh7AcJAB7AF+BSJwcAeumi3bciCQChV9v2GWYJAIwLDJamdQAASRvkxeHdBgBBo21RPy4EAJ7nqP0DagEAOQ46YtEoBAD9CKMBREoHAAmBVbnUbgAAZ4ig9vFGBwAhI29cb2MEANML1pIV2AEA1cWFe5+2DQDrUFYXLXoJAJ3Bv20+zAQADr5zOB0+BwD4ChvV9qULAF+sDaZWhwYAJuyKe3VdBQC9gF/0PTgDAKaWn4w/eAYAzZ54pzQCAgBSsnhxtg0CANoOLNqjOgcA03AcwEWQBwBZECUVe7MBAP7PUyNozQcA4PSsaGDNBQDMdHr8mgcLALNkC2WXgAUAmU6crKt/BADNsrJTAu8LALb6h9hbpAEAfMFtB0hXBgCoEaoAgLkFAHQJCMnsoQQAwL1jiIyDAgAwUEZKz7ADAC169a64IgAArSXpdwatAgB6RddnQQkEAIJqYIrLHQIAujF3vvoADQBQMxHDU8wHAIENCP5lzwcAoRsBZtnFAwD2xvbbQNgFAMifnYxGBAAAjGt5VIXaBQAlAJVwvrgDAAmmpi2J1QYAMUoZCD28AACL4Z8wDTgGAA3uuCw81wQAtsC6rYK4BgC+TN3dq24DABmsMmInpAMAuH5E23LBCAB+p7cFxfgDABA/f/lXqAYAOuB/VsD8DAAZToKeDHcIAPqEcIosQwIAaKmoPPd7BABnKCZ2kWMBAM4QgE/f6AUA3hbqfBf/AQD9tbVFmtkBAOyZJE9nIwUAEyYYJvr4AACYjASYc48FAAAV1E8mnwMAznsJ/qtKCwAyOiUD/DsMAPK3kf7HmwIAFkqE5GGnCABew3ISYlwOAJzi59sXNAUA9ZRzgnNFBQDdUPam7mUFAEnHjXRQIAQAiYhGcy1xAQDdkzHO+IkDAOV8F7gk1AIAzUA0DfpzAACXntQMAjkBAM4ZqwCYLwIAmf1umt2fCgA/KCiplMYHADpL5O7N9wYAw1yyBzJaBQCMWThNGhcMAMv4nj6KNgIAC6ziCKpUBAAAp48/kpAEAC9YpJ6qcgMAYkfWbEE/AQCMTMmZqlgHAET/ABcA9gUAvQGMSE5pBwDW7kjp/dUAAL10pU8hCAUAwwPQU7sVCgDCqCx5nhcJAKFAyGrpoAEAtjq74pMjCgDKhkyKdacLAEv+1j4VaQIAQJj4riMqBwCcaZlSvlIAABYjE+/lpQMAuvrGDpYvAgB2UK6T9hEBAJDKlKq/4wMAh7h2lHlFBAB5SEYSCUoCAH/e+BX92QUAC1LX7ipNBADkp8LSZQgFAEDqOFJbcAoAljtdsnBsDAC4fqR/GLwLAH9yY23TCAQAYmCm9vj6BQBr3qgtibsCAObix/DUaQcA+/gUWfMyAwAMwobqFQEHAKitJNqIbQEA3ypmIgaYAQCdWhm86wEFAPsG6RzYUAQAP3SuHJbYBAAOun2Mw70GAGO04ae00wcA863i3kuECACqY5YnrcsEAHVSIKahtgMAz23QkSfoAgCHPKnKcj0CAPSqaKu38AUARWO61CXeAgDNH9egJJABABoQXxFlXwEACJcUZ5DpBACvpcvR2BkBAAcg/s771wcAlJDC88VdDACuebUgUkULAIkGHmPBcAgAIJsOY8BrCgCMzW0ZzfkEAAEoayZqHgcAXd/ic66aAACjsRmy2A0EAA3eF0X7RgUAdXvoNVSXBQBoN3tq2JcCADJjTC9agwQAYEFDXzBwAACuVk4B3YMBAKCHQwjdzAcAgMxgZxiEBABhM1NlVkMHAAG4NmNoLwgAMEP2RlQiDQALGUioPFkLABcEJm0sQgYAlLsXSJASAgD1VLjeGaMFAH3aYODUqQcADB3WDr0oBACnmoRemhgDAEKyWR+7rAYADGNTR+/2BwCpLSopRvMBANaijTCYcwIAUyRwCkwOCQAz13ujr9oEAGGJPtxrnwwA5drs3P/+AQDDklSUwnIFABPUXkMojQMAWCiZGU8GBADNQ/W+D2gHADyN1YPdqgEAw+jrellpAgC+MM3WRccHAO9431V3fAIAo3+TM2h3AQBVGEQWUUAFALwFjEmF+QcAUGO/D1IVDgBp2nS/6bkIAGgRIAiD/gwAQt4nYfdzCQCwac1TJg8LABfhC5+IzgEACQdRlGpvAwC0FgBySPIHAJHP4dEeggEAH6NwxC5sBwCFDMGqOMkAAEFxee1kGwQAbV4YwbG+AQAHD2CQVO0BAEeWFT8n8QIAwAunVdeLCAAI5lyIOp4EANZaG4iFZQkAXU/TaHXCAwBf3H6ZwYoDABEe4Ip8/AEA5+hzVU0JAgDSSfW7PMoFAENBxewg+QQAtoWtcuXZBQA7sVGnF7UGAMyAsXDTzwAAGvTRJXk3BQCiCGBWVk4DAJ7+y9n8LQIAjuA7ELRZBADdKi0/S5oFAOuOu8g01wcACUpZvjw5AgDeTIJ3mP4IANkMDcPg0gMAu3FmaJf1AwCZObZ+WKoAABnGkrXH4wAAjEQFbJGyBgA7kboK0TQDANvPgbXNRQAANo86VeDjBQCy/x4EswsFAAD/B/MDwwQA7UTZDVgDBAA/ZZJ9940MAOlJs+OfigMA4a8KhYnqCABpcKtRsRYMAIWMshfWOwIAYVp95y7nBgDeTRf/cqkBAA/Gc2Nj4gMAq7J4jxvWAACwNsHp79cAANUKZIkcqwEAlx/0roJfBQAN7RfzV2kEAH4ndK+ikQEA6A5GT0MrDgD70/rAxpQCAA9Me5NogwYAW4cQKfjJBQBFBeDb5zcKADEUPMVL9wYAwtm7XQ7EAQCXXK6c+8gGANq34VxchAQAzLVQ5ODiBwAwtAFn7XUFACYAon/h0wQAU0KMiPyRBwDBigeZuvECABURm2n6GgcAw1A7Rxw8AgBIHeIdZ+cDAOihR1X6JgMA2a9fwk0ODQCIj8f7MQcIAB22UzmbbwYAucw8KPRVBQDnYBn7Z90HANT+r6EHRwEAHCucLhQhAACAGPhIGMcAAIY8I9jZSwQAMFj+jlfoBgC1QXBtWwQEABV+NPPWxAQAXRmPmPzdBADhZaM+F/YEAIhFrvnaRQ4AOmLbYzfUBwD5iApQ+YsLAMkffcHP7AcAHoOCByjKBADW17F9M7gHAPuVOO9tEQUAR36q2v2TAQBvh+g3PMkCAPqDxSgaQwMAediL2kmQBAAcwXpAqLQEANTw65n7pgYAxiPktrUiCQDV3fHfUB4KAL91TjJ2PQcAjkGVVEiIBQBeLPSp/TYBAOtVCFa7wQYASK0TfhIfBwDsWpAEs8YFAMebiI5rdQMAiTFKkXZfBwDRvQWjsd8EACkfgQX/swMALtk8KGLtBgDhUuxDFV0GAI2+EDUYIgAAbHowQwFxAgCr84u0j9gDAHqPwU7rSQoAXin/XRE2CQAD1B9EfDgJABQtrV44ZgcAXgkGi08ZAABiO4L2eIQAAAhz04mGAQYABrgXznGgBgD4ipeH0cMDALp2gsjhrwcAaK3IgfIdBQBdJKS9BkkGAO3xqiYbFwMA0UeKsti3DQDANJ4U7sICAFP8mmL1dgcAqUn8UOr0AQAkRDOmFMUGAKhMVpeQMQcAJTUjvE6EAQDh7v1DRR0CANIb/6onrQEACM9zSP0hAgBBYxU6TyACAGSkZUBBNwUAg8/tOww8BAAgpm5wflUFACS5b1mqjQQAgJdMyF0dBgCewkAw6H0EAOcHZbLeiQkAmUfc+ubUBACn6KB/g4wNAMecpVxmjgIA2Q2UFcdlAQCVHKE6X3gAAGmE49eYewUAhK3Mb912BgBYkPyWhWgBAJ9hA9RqbwYA73J3qFnXBACkvnNhboUHAFdqLD/3xAEAhDR8/G5wBgBtNuw5eJgGACZ/z5UfcwAAvOS8jnWuCwD12retWQQHALugXzC9TwIAz6F1zJgKBAAzdQoi4YwHAJfB4RB6IQYAZL/RgKyVBwCzK7SRSdsBAHJDmVtgaQQAWJpcceMxBgCPcs/vz+kHACHOSCgW/gUA9bF8XS2FAQAP5Vy+Dw0GAHV740bioQUAkNX/Be4aDQDZdzYETLQKABqWlOFPIQEAy+mpOa7hAAD3+Sa1yEMFAB3pZ4BJGQEAF8lvRJ14BACOt04Hq4cEAEPjjF470wEARhvrn0E+AQCk5l1WH3ICAJq78u5SDAYAEW2ufMLFCwAEbpWRlGoLAKUdE8m6JAkAXCsg3ve2CwBlm40kdw0HAPGL/Tu8iQUAa0Gjaj75BgBIrsHWo8AEAGpYCyaHVQUA/MwSw8kLAQBboMI+S+gCAFEVPPCinQYAe6ZhRhc6AgA48omivAkCAG+XOr1VNwYAt6zxlxgQBwC4B3u3LNgLAPRpdz0IhAYAB84tRygrDQBRfHNRN3YCAFMI0So+oAcAqzatxtwTAgDWvdVA4qYBAN/++PxPwgcAFrxIHMzYAACpGbRu0wIEAFKgFIz2zgcAOdHCWyXxAABqGDHU53MDABatp9gtDAcAAH7tuH2WBAA6Ui/Q7loJALuU0JGVFAYABnDBBPJyBgBTaoEThisLAA7sb59QlAEArKwxytgoBQD6ubhzbYIHALP54JnLSgIASDk2xvrgAgBkzUjkvvcHADwP2hAP4QQA6SCruWyTAwDQbOpP/KAHAKQ1xxWSFwQAIc1rKLkzDgCUnNu6s8oOAPm93344TgcA2Q+KxRNDCQAbJGJWqB8LACrt3NfnlAAAjhGOc/poAAAr7l8KZBsEANQZ8J1wuwYAmc0wSjQABwD0IjYuQmwCAPC1BWoG8wAApoAEj0TiBACV8NvgzUQCAFKZKjGySwIAWFz49SoMCAA+iPJMn2AIABLKobVu6AYA0czvokSLDgC0/p+v0tEIAMNn3jIX7QAANRYpacMIAwBQ0vJI8z4DALuhoV5HBAAAiOFx6OP+AADfHmIyoYoCADs1r0wkKwQAiuDCTAZrBgDTvQwCILsGADGFcXnNagEArbaHeMXGCQAqWdcf8qsNAHmGUxLUCwUAUTEncQuACwBggbE07WQBAD0dmy2vcgcAW06LRIbUBgCoGI3dWM4CAIs8UGefhAEAApNr7+AjAQCa5i8ZTNkGAA9poiJSRwUAs7iGnXiTBgDcafu9w/UBAD8HYfygjQcAgToMaPGABwBT1Pw8XaMKAPfdx83lBQgAI6x4gIjuBgA4azFLqlQIAGrGK+UoXQEAfstRAx4OAwCMH7F0LwoDAAPe1wwSnQMAsVay7l3SAgC4fCYZjUYAAPn7tancjAMA4qEsXLC7AQAzlY51FbADANq3agphNAEAFfXRd+dlCgCkOR5M9fEIAEUmUpUb8AIAbd6d29j9BADMl7qMh1QGAP6w9o3HjgMAImqjvq48AQBqX07lxusFALgOPZAEKAMADbKi2y8QAgCh5lwFBeQGANMypTVKAgUAnfLaVJD2AQDVi3oNHV0BAMuesl1yrQAAhW8Fmwy8BwDY//q//hwFAEn1Tem7SgwAIDHj17vsBwCZIzD1dfYEAFckToOxZwIAiLt4wxmuBgAS1dlee0UHAPsFPXgNKAMAAxq3//yuBAAeFxUENjYFAGV4BwkzMQIAvK80Q0RRAgDoVjeFw7ACAIYqKrfLvAAAlhL+UExeDQAMw+8T3V8IAO3lgMPGwAkAp2L74x3hAwDzCJHWj2cGAMipseovlgYAC6O5j6KsBgCYnxvKt20FAN0YcElYnwMAa521Ck8CBADCY2hjMfoGALBCfqblCgEAMdof8Lt6AgC8T+a5p4ADANTqCCEu1AIAgHVTDw17CQAthMnAY2IJAKM5RX6CqwQAOtdD2w03BgAjtHk6vyAMAJvS35QVEwUA/lKN6SemAwBhVoVBQBUBAISDn9B1kQEALY2LYLJ2BgBHK1scZboAACcQcGMjhgUA28YZwtbEAADeWIb/PfAAAM/Aqf/SRQcAV07TIVffBgAGDHp2L/MEACBux+qr1QkA4+EE4ekcDADbwVS+FW4IAL3IySseWgIA6jew88gEAQCYbKlvVwUEAG+H44hq6AIAz2C5ziOuAQBKmTIZh10CAG4LVjvWuQYActTIFCjfAgDtpArivvsAAOx4EobtjQUAlcnCtqhbAwC/hTGLpd4JAL27I81VtAQA+INIwBnsBQDVMbWWposIAFzFZvKTNwcAAjvJqYi5AADbJSOjDpsAAF58wXGufAMAX0iF3jn/AgB6xe/D7j4FAP0uAumf+gIAVIETLMeZBgD4H70edSoHAM9HSTtjIAEA9w8SSUcxBQBX0MD3za8FAO2NeBvnqQcAiAw7j3DvBQCTszy+M3QIAEIAYZF4mAQAcgFdf52dBwDEnjsBk8IDAMrKOV+4wgAAWU2bqTBdAwD0l+lcwEQBAO9/NIoLlgQA93Rd8RHaAQCt/sAZrE8FAG2v5+1z2AIAbvldTuECCgBLtT68AuoCAGQ1iLJ1iAMA3ek6UYwpCQD/FaAYNlQIAAk0N0NkMQIAryI7UJXeBQDf4uobIJkGAHpz/0lY2wMA+gdHZXPnAgDBI0yX9L0CAL1h0si5swQAKLypsuhqAgBRXBYQggYDAHnQYjNEsQQAuJxSHOlUBADPcr/GmEwKAJnYw5RlSAgAO/rXoxOuBwBmr45BOHAJAHofbrbHtwQAmNnvhaG+BAD4VRBxvPoEADj+Nnif+wEApi11RvSCBQDkTDIg03sBAMaYeBGJFAUAC0Ggkk1oAQCnxXgP2eQGACjavMShwgAAMmm9aUiBBAC4XaSRw7cHAEG2NawWcwUAagnpHeNBBgBNMQqzqaYNAEcEH2/QxwUASToL+HDbBwB4msg+SssGAH05ga3oOwQAZG8cvVjFBwA9RpbTJBUEAB0ankRrWAEAiu1KkH7xAgCOPB2G0uEHALqvoFxKQAAAvm9BKhueDABWbDELahwNANsb156ldQ0AHewfGgJMBwCOf25RJ5ULANZDpwoHQAcAgxHdy2RrAQBD6zJ7Sz8CALM1gqWrGQMA2a3cv5VjBACcml0aLdsHAC9ChQsgmgcAFt1xqr9VAwCqeF/qdwsAAC2CnqJ5ZQcA3zS0UhO1BABnJhzQezIJAKDIYDvXNAQAukOUqNrgCwB2orJLUSwIABcqwEl+jgYAtuhvNJVXBABGNY9sMIkAAPaIL2uf2AYAW+DJTTg6BABFtvGL2tUDAAltaqnW3gcATS/uT0nDBgDUa4ucmCwAAEgVliAJFgEAuk2bNhZWCABGb6yGq+wMALEA14UAxgsA6fwN4T4hCABtHknXN/YKAKrP2ilpFgUAifYxa4KQAQB9SmlnVfUEACLlsff0BQcAmFa8JeFRAwC+e/YaRpsEAJY6LHEVWQcADQxY72eaBgD8z3DvOE0FAOJ8btCC8QcAD3UhjnJLBQAoARuXkJoGAKNjqfJAGg0AvqYSrOkLCQDEQTIEzEoMAOxoAatkjgQAT2+ouL2iAgApaS1rOzQHAKPpjKoE2AEA6UPDyEp9BgB3V3pPu2sFAI8jfGIwkgIA+9csEhqtBQBk41Bupd4AANcqMcjRVgUADugbsVZnCAA9sHt+FGIMAN+/PnQZZQoAtCpoWfyCBwDHyIzjq5cIAII5jQzjQAcA/YJGf7TCBwAc3Me4kc0FAIPl+ZCnfwcAJNjRxsZGBwCkLaV+h8kBAIlhqIN7swIApQ0xSa8zBwD7BBwWgV4CAOi+NErhdwUAK9dNvb7OBgCfMkLkwUALAD6p0f9HIwMA4LssJYlKAQAJsI9LMAUHAAo7p2GsaAIAHL6+NPIGAgDo68unA7QFADVBn/BgoQcAeP2W7qcPBgDGbilNNR0FAMcWO6b1ywcAFAzPswv1AgBaxsqFs/4BADUWyuCYEwIA7lW3tPmqCADyRK61kWsCAMixeo2A3gYAsDBVZ2mnBgD3mE4o+7sJAPMzKziKBQUAPpEWGKl1AQDoimu5zfYEANKB2slHcwEAI1rZ2T6qBQBhZdnH6XcHAKzMBvBYjgIASawsu7tBBQDsTJmCMuYDAJXo5RR+oAQAm6R3xM1YCwCA5AL+iMwLAGrj9LeqIQcAU5lGyYxACAD5Stiu9woFAJn5DZjLEgQA3Cnu2I3nBQBdV4z233EBAEnv9tJdAQIAE9ORw7rwAwDlW/YVAd4HAMlNNiEsJAQAmGCmZFu3BgCFwAIBPAMAAL2uazEakgEAi8Hz2ZqtCgDqmjM4FuwFADuoWWU7cAUAEtYFTZ/6CwArBsreSbAHAPxwuN9+LwIAKLF31u5pBQCvpbDcNwkDABvqeJwDWAcAOice9I1FBgCDREQ1euMDAJl70rf9YQYA5CHWHXYXAwCJYQIwPDIHAFApvMw9CQYASwOEYL7uBgB7jQr3Ac8GAApnxlQatAgA2lW7mUvIBgBHtpgMGOMGAG1w4IWFmgMA/mMm53wWAwCXQtvsFD0GALhw+dwhvgQAeoKEoB59BQBxsCih57YCAM9ddRF1sgUAZQWTwoSFAABZQW/ae4wGAHvZ3ZnpYwMAs65L4txIAADjBeyVV7cCAMlt2sWkvwsAHTeeZciqCQCab7x5+TEKAMQf7jXBQwAA1fIZmRyhAgDNul3CTDMGANoAtBfalQIAoJOGt+mOBADG8yrMS94BAIbroxHEHwYAwC7BmtE+BQDgBLjG2wkCAJKHsKm/eQAAMkLVooDtCQB4XirH/g4HAC2CKtRRIQQA6DHWtuu1CQAFR1mxT+8JAPQNMNpROgAAchxWK7VnBACQ5RACktUEAIWWeJ52ygAAF0hof8c4AADsexZb5l4GAKlQuBnaUgAAKWRlZYZAAABMmm9ZOasHAL+gpJLudQUA7tekCkW8BgCoCzt3pvQMAEe8DgsbJAYAFZMdT5wNDAD0guPnoQAKAM8vGIqQgAAAmLq3EylTAADDhcN4z9wDAKmrXt0CgAYAP80ScU49BADFOvnqZ7kFADEKWMqsYAMAYvLG1V/GAQCr7MIVfxwHAORRJqXsUAAA6mjmYHY5DAD08pJWp8IHAO9mbH6esgsAmdq8WKYrBwAaE/oJHBUGAJwMP0XeGgMAaHhzB+7fAwAR1Kf37BEGAPZkvWx+YwIAj8UhbO6wBACWXfD9DVwFAF5Hz51WBQQAu5h0J1xcAACJw13ZiIUBAPAAqE/y/gEAc2uXMPWvCgBZhMBIWtgIAN9CNpbrlgcAJrbEUO4LBgBAg2z+BYAKAJYxpxr7UwYA+gaD7PoHBgBUUj7IXugEAP2EBZBWnwAAhvySktREBQCIhlI0n7oHAF0ttA+ihAIA/m9w2SxlAwCz5t2te/0GABbzMClHLgcAFHYq0zX2CwD9AN6s7MsIADWp6kERQQMAlMvzQh4cAgAG/gDw5/4JAE8IgZeMIAUA0iTcoWhkAQCoQMUKeL8HAAFT185+pgEAOnPC6NKpBQDl99sD2gUDAMqut5mGIgEAyWuTsiMqAQDp5mqlvaECAEDgHgWUDwAAQJevB7uTBwD9+tTstucJAEL7YBV7LAgAtl/MNGcpCgA/3SX9f3sMALIw08MjawUAptFg4wh2AwAucsjz4AoBADe2GLbZhgAAq77ox3l9AAAS3Qi8nPsDAP9wU9g9XAcArBko/gZ/BADtFZKrBtsFAGTqNQpSwwEARsBrIUBvCAC02Q+bV6ILAIvsfkAmHAcAC0+1StoqBwASbbbDUIcLAEqjy7ymUwIAGnAzBAcnBAAOh/lYjgsCAMwA22HINwMA7tB1V9DDAQAa5SKUQPEGACUtzr5rhQcAHAMvp4AzAQC686eAED4EAAQzfSweYgAA8/DbsJYXBgD11jKcLzwPAL1+U9GOqgYA9DgYyZJOBwACEMqJ5dgFAI2DWYLMYAAA85Vb89M4AAAjqUPCeGAFALIbJJMy3gIAOr2XYH0AAABLqUIIlR0HABfYx+URawQADU/LvotHBQBdHApLBcMHAMvBg3c9WAEAxyidzARHAwAA8rGY5d4DAJ5tdJgcbgEA36+VcAsFBABVPOhkgJUEAOF6ol3vogYAnZ0u4KyKAgDo8GXpWSQAADMJFdNkuAcA2B7o8qVSAgAN6GZQJpQAAKVhjZEPpgAA3g/z90tEAAAGPO2pDcQBADuEvXDBeQAAVtDVwFDNDgC5eedqYLcFAKHdayK9DwcA+R85Ux5mBQC4F3MNjHYGAP9v+mTk7AYAoGCkvEDMAwAMjfsKqeMGACgSobwagAUAn6w0XsDeBgCzwVXx5SUGAJYycm8v8wQAzu8FAZisBQA27l4WYXoBANXcTeFFFAUAQqS+K6tHAQAmMSXyQPIJAIhOMZ7ewwgAXqT8pKUeCgD85IYAmS4JAFFJFDtLKwAA6mqWd4loBQD9nzluF44BAIuTtF5c5AIAKTke84YxAQAuu99/s5YEACE+X51DwgMATWp+/mBuAQAdYpuI79cEAOnTBT8uewcAkbDdEpxjCACyes2QBBgOAHtGl4KR8wMArIEXvmhFBwCV4FJRGXoIAN7ELpzFqQcALWV5nvDpBwCGLfIi5KMGAItsgzuOrgIAMq3HX3k7BgDIX544Ao8GAAZ1h7zxWQAA7AxBDpkEBQDirv7Q15sAAPAy0IP+6AMAKdHv6I1MCAANIeYGfMYJAGkUf483gwEAidKuzlJDBgBYYpqJYC0KAJSicAW5FQMA8SWpCOEMBgAJyVMS9u8GALBwLQ7vAwAAxPqXt6NbBwCW0c1wwNsBAEdMU7GPbQEAKvqDgUkABQB13iPEWS8HAHl3uAdNkAAAuUD5SGYtAgCGPoehpZcJALtUGsTkBwoAz9ZLOws2BQByr+usCiQGAJyRut3UHwYAmVa1kenYBwBsxzxHMRsGANYx5jGWAwcA3cH7QyE+BACglaJbnHQEAAZfS/pGeQMA8VFaq8UkBwDz0514M1YGAEDbOPLaawUAnzudwWzTCABhItdwROwGAK6pGHA9hQYA68jCTT6qAwDl4QcVozoIAOszNfXjuQIAxQaoJ9etAgCjFc7IVWkFAA4pCgdPjAEAQTfYhkrSAQAfztT/SHYEAJ2eg5GVCgYAqxeB89UkBAAOwRJpxCwEALSuyR0mOwQAUROVbIs9CQApY49+AcAEAMT5U55VPgUA6m6IRgGyDAA/KSReTSsIALt5u4gZHgMAq7yzRi+4BwBBe4LOqPcAADBxFxZY4QUAdrL1XAUmAwDyjdEoy1UBAJQWoZwNwwAAGTGrJw4JAgC2SXpOYggCANPlmoBsegIAQWk9xAonBAClWVbZTO0CAPkodbMNXA8AM5Is/bzMAgDC2AM2UCEKAIixDR/N6wYAdBF9S+tMBwBcT99oYdUHAIrRbxd5vwAACvZPF2fLAgDQ4Qs5+c0GAD0rfpxRjgAAgQil0sNTAgA9M45EQRsCAA+Jc0vfsQcAjPX4BxgiBgDlizqBkvoDAHJVjcOY2gYAj0ZUVdkeCAAtNV0kmIYGACSisrPg8gIAkhwsomrFAAB4svE57P0FAAbxx/UKyQQAxY9l8s4fBgB6GBgqhV0BAHb7mrXbcAIAq5LPCxLbBwCHQHFdoucAAPDac8T0bAQALYFJ8aduBAAnhAppJQcPAPp58Ok6pwgAKsZhRJLdAgDM2FCuWgYJAPnlxJ7tJQUATGhgBtIiAABoezlwK5cHAGX501g5oAcAtU7RvIeTAgBXDSDfJUUEAIVD6Uz51wIAt+xwwQANBgDw2PMDBYsDAM7xZI4ZmgYA7crF3DRECQAffGafkMcKAHW1H52DGgYAdrvKADjyDAB+Jr2XJlsCALx4GtngsgIADPLMEgqZAwAiJh/hwkEBACAzpfrO3wAAOkmSap42BwBkaJgT+z8HAKwT97grKAMA75fyeO2cBADvHWYncGkGAORU24MGQgEA0FrMwW+7BgCdZpHVyDINADJsqE15rwkA0iRt2OngCAAHHRa0gx4DAJfRnSQevQAAj1YgGMsLAADUMIhxseoCAOaXaYH9lgMAilC/vmMLBgBPKwaeEscAAP0SW0Em5QEAPZIn/aBhBAC3pXD2rYsBAFDVYuvxXAUAP4z1feO1DgANxoY587wLAObqXIO4TwwAo3GOwd6ZCACfK6a6b6UJAFg9wmUQEAEAD4szkBKqBQAhdC6efhUDAInUFyBx6gAAiXBFVqZpBgDsyZ1cUGsGAIdS44bvdAcAXpXARNnRBAAgK9c5TC4FAFiceTZIPAEAgNCLXWr7BACbWAhJ44oNABKve5dNlQMA3EF0WeoTBABbjtyH3AsFALnhs1pGXQIARyjsJ/74AAAGT/Db5tYCAHYyG/yMAwMAe2M6yYBvBgAR4d9ugzcFAA0sezUCvgIA+NTIWO7cBgCSYR1YMtcCAP0lR0RW3QEAh8i6CADmBwBSGHw4XD0KAKcz9fFdngcAz/DF8fnmCgAvOvZQpKMLAH0SYjP4fwQA9LGCrzmOAACrffIuMogEAKShojg3lwEA9xkikUXmAAAnRjnYMS8HAPEAopTSewAAxnTiAL5lBgCLNrbx6D0EAJo6OdnIGAMAhdMdqymeBgCsa8ezhQYDAFlI8jfPZQUA+f6Owip7DQBPWTIcpAkNABn+/yoDXQQATt5sm+QvAQDxfDK8YxYCAN3xaUxeigEA1aF5xsckAgDpJfmm3G4AALh35mODjAYAz/vkJfoMBgBOQAl2wcQBABGKMgL/WwAA5BLFDd2gCQAPzV+/lAgJADacPwFJKQUAxzVHug/1CQAZ4N58J3YFAAvgyiNwEwIAxibrmTVaAQA8K1EhcmgAAOkkCDrLUwIApKI/zLiABwBfME8jvIoDAN4DwbuAogcA/l1pNqiYAwAailJBr9ADABsnJodB/wUALZW2E+hHCwC6PBzCZGgHAKh0zdtJ4AkAm3STD9a0BQAMCsq4TZ0KAJ3biRcMCAYAMace73y+BACAgJ12DfQCAAOmREx9XwMAllrCPaAGAQDQUzMzrwoFADW7PGGatQQAdprhwN8jAgBkxbIrHn0HAMtSEKU4qwQAicDdX+/RBwDZ2rnr6r4HAPusoAvTWAgAj6616pLNBQDSTrBrHAQLAJPVaGclKwQAT3tCWYToAgABB2N2OCsAAOXqBdR4SAMAigjcGt2cAgBI4VbZ+fICAP7BZa3mswYAXZ63cgmwBQCvXUwjjT0FAElAgda7BAEAUPF/1l+aDQAqNdDqmKkLAJmvpF/JgwgAbiYB/Nv6DgBxsA+i8gQKAGft8Wgx/QAAPkp45w27AQB3BLJ4y0sDAIIhLm6ipAAAp5JwxYy+BQB5sOswPTsEAAIZxqWsVwMAVSTWxXC1BQDHGB6esg8DAJEnfLEPVwIARyS4C1WpBgAlIxoK8hEFAO6bI9ckkwoAwxZ1wzw0CwAX4B35xUEKAHUVtix/NgIA34dNwJrDBgC95deLldQGADIVimP0ZgUAMDClXrbcAwCqbN5AKRcAABtFZy5bBAYAs/w+RgdsBQCRbv5ri3IAAN/81e0ghAAAuxD0BE7DCABqoNDA7UQDAG1N2IZU5A4A9GM4yy5ODAC3HTJPZU0IAEr6YoOrIAcAv9nNR0OcAgBjhF+tmOcAAP4Ly4vx/gQAdsH7PqXZAADVtb3dFsEFAM+rpbu00QYAelOlSIrSBACZCwRbjmsFAJGJYfKkpwQASyo3r5GyCwCXRP4oMA4GAAlqT8p7JgoAQrJCwu4ZBwAOPiIUY6kEAJVfsV8CGAcAlP5xg2uNBgB82fdIRIADAIBCeP5mJAQAMd3NxFAbAQDW/6QIRCcAAN00266C0wcAXTjOyc8KBAAeW6SZuygGALzm3OS89AQAbwudxG5hAgAc5mKEXfkJAMVZkZs+rQkA+E2gdaSbBwCVFVbuLAQDAIQlJOJazgcA49RTsV7SAgDJqZvQ86gDAI7rBA1p8wAAwHFL0c0/BwBBrJtEeXAGAE9IIUactwUAjWsV8mkQBgCvEDtXJusAAM6pyUDniQMAFawOV/Z4BQA3OZwz8kQGACxslbdHbgYA0FUf/jJICwBiYl1eQlwKAM653DSuswQAn6wVGml8BAAMQF1u4BgDALE++NkixAMApmWUN0UVBgBu3tfxpgYGAOcHYcTA8QQA2OX73LEpAgAnE3sKxqwDAIRUkQiaUwYABkq7FNTbBAC42/FJCJMPAO/KZqTFKQMAm+tPVCTIBgCbAe8gU/YIAHP30sN0HwIAOr0IjbgkAABRQQXPeOYGAHx0LicxNgQA0VysSl4cAQDG4P3KsdEGAJA6MGrHYgQAm/88aU7KAwD9hlfULJUDADDD3nu8ygQAidJ4P494BwAR+LMJKJQNAJvC+HcylwUAZ/7FO/kQCACxrGWBSe4HAC4KnAgklgYAcwTnyF8HAAATIx2rhD4BADuV9u0LwQIAyCEDP7k5BgDDoRGR4wgFAHovkQ4SkAIAQ66sZPTLAQBXYVfpc1MBAGBbyJP07QAAAEF2hNLEBwDsrAa//v4HAABBgnr7mgMAZf3nR460CQD5HU3FAEwIAGham1lYgQQA2dVBvHX9AQA8Xakf/NkCABG6DvIn2gcA1BkwLrkDBAD4XEaLgS8CALgJ/x2QQgMAzYPGXVkfAwCC1l90V3oDABcmqxK7VQMAGHOMWsfaAQBgNELVebYLAA1Atrf8uAYAnV++gzfHBgAqBY6vjlEHAPS7k3TMZAYA43QYdpQ9AwAT9pYXnhcAAH2G4jUFiQEA7IIhE7j5AAAybH8bxFkAAJEUUwaHngcAgrU8ZEfHBgDklNQKDOICAHWxu3E4fAQAsGZQyFBdBgB8HzZTdBYGABKzi4GjawgAIXWqm/KvBgBIjc4C6o8AAEhP7HGXUwQAKMqtizG5BwDFFuCvGQ8HACONYLF77gQAaWRXuIkLAADQ6t5odt0FAElwpAttCQQAFJEhl1knBgCu5meK2psCAF33dJqCcwQAyQI5rTpTCQB65BFr4N0JAHYLk9G+hAcAZ8i5kgrICQBMTtS0aMYGABjEeUZ12gIAWhC+MUwWAwBf75grrB8BAFaSd68aWgMAPIPEhIYHAgAMgnh6Ic8AAGnn0uckUAYAKqjd77U7AgDG0zK21J8BAKT4VGAaQQcAtHWxGD3lAgDzSiBUcj4LAMTEodXXvAsADl32KsLHBADDWCSHmuwBAG3InbkynQUArKkiXgesBgBxMxEgkgsDAG6WOKbZfwIAE7hPVzbBBwCbUKIA1KQGAByXVhB5QQAAXAduhtVVBgD4TebzKzACANZ8XIrYrQMARjA5WdSYCgC3kD3L/gsDANb4Peq42QMAeRVRlg6QAwBqQBoToRsGAPLcNbZwVwEAcZX3g82eBQC9fwscRtsCAF80galCOgcAecjMn5JJAgApkJUW8aAAAHo0sddPlwUAre0IHMzgAQATH634vXMGAI69yxADYgUA1oXid/S1BgDIbDLske0MAPyjA3VT1g4A1Ig5dtMmBgDOWDZvhOwHAEPWNElDkwEAUapeRKLUAADgb+eKcNAHAOHHw7ZHmAMA2dmkonZ2AwDHLqIdP48GAGtzojmA7QYAdTxM4H5iAgDR50emkOoGALmZM3Kv2gYAj46trL8EAwAHixB9kQIFAA/dpmwXQwgAgx0sjxXVBQA761ieRLUKAEe+PetidQIA5wsXtNeRAgDhqN9nytEFAKKY8mGAqAIAfWJxnk4wAQD+nNxq0hQAABNvoRtp8QcArG7wKBjnBQD8//AH7UkDAN3C1+KNRgQAuwdj+MbYCgByCYWhaygOANNEhLDc6QUAsmIzVGqpCQBGMuYnZNoNAJ5GGZReNQMAN4rquHuEAQBxm8+IZf4BACJr29LJsQYAS7T/xufMBgDKIqzeiMYEAFID/8N19wYAuxnkPmBlBQBGHMZWRFQGAPJ5/qspjwUA9s0Ocb9kCgBqiSeFxQgHAJQzxebqLAwAaSvoIRs4BAC0hUFyk68GAGg+542rzwYAIb3Uzu/mAwC+DVAJZgUAAN+FrSR4GwcAQX9KnGJ3BQCIqMYJRQIAAERmLrFqaQIA2IBLf6LMAACeERvxwccAAOzKsFvyAQcAE8G+fNn2AACjk3z7l84MABooEVqDOQkAVZHaepAoBwBVCQW8pSAHAO1sYeT4sAAAdbgPtcTTAQCYAdxzlvICAPoPg/Gw9AUAQNz7K8ngAgA1WoCbQwkHAIeBf1VI7AYALDqhG02KAACu+QuKNHYAAO9Escu56QAA276xXdWbBgC9MfdHTuEGAKwOJ0deowkAjd94VCJvBgDTz5FB1GYLAK0gV/uP1AIAd9+hIX97BQBFBrr/DlUFADGpmEBq7AUAN/OzThAhAgAUjLzyQxcEAMdzh62wlgcAm2i7XO6fAgA0hxdcZiIBAJPFa056FgQA24/O+GUmBgBXmMUaEJ0KAPufpbs72QQAFz83l3h7CQDstww3M0sLAAAn9nYonQMAh2wdzc4BAAB1dnQRGvAHAJCBoaUNNQIAUiXit4uTBwDM1oGG7pEFALh56rSwnQMAQgg4DyICAgCs4EK6dvICAObf4sZvFwEApQ53SYniAAByexSInlUFADDvY24eXgsAbv+nmhBbAwCQJk/lo/YJAJthnFvQbAcAlRaQsFSWBgAnf7cQN6UHAHWB0qcemgcA1XfGpMOPAADqNAfTmcEEABTMmssixgYAFgIDVQpmBQD7EZ8Z8WgAAJBrEdD68gQAJbY7tx3ZDADEEoFTgl8NAN0VmCda2AYA+ZzNsLdABwBOlPKVGUULAFROrpRBsgYAl4jt/QojAgBxUH1hEjQCAJuWNQ/T1QMA73JJSkhFBAB8feqf0PwCACrSnmsSlgIAsgUqAXGhBAAjVU3HktsBAIlCYMqJCwEAW/BFWr5BCQCmruyLs60FALvyQdtG/QsAOM61u4jUDgDT8J4dLX0JAJwoGJdJRwEAq8fkZ4qkAADjr0tUvA8DAIrlXzEBxwAAdXtXjYcLAgBqPj8HGK8CAP4kDULqOgMAlP/0iwCYAgAelttxkVMDAFzGPPYUIgcAtik79Lm3BQCzo+4x6kkJAAgWWBN3vgQAmF45YHnYCgBToVXISvIJAJOmB1NAfwMAnLbybOblAgBTnK5mQtgFALlT6H3r5AUAHBdYjPT9BQCqBZWOMggGAJrEHYSCIQIAByMdiZbsAwADLvL/Y/MCADmu4jmnCwAAJruI6vUmBADIdX/nkjADAOcZ2EA5pQEAE4aBTy4TCQCMUX3elyIHANaQh1zemAYAJetbVLhoAgDf/paLZNIGAHywHa2IeQQA13rmo4MyAAA5uQy+xx0EAAQJEGZssQEAbcbLIEyiAACBhuTv6aIEAHFihJYSXgAAUEUsJMi7BwC3NTsQBpoNADIg80p+IwcAelOzGkImBwCMJThd8owHAFpJnC2z7gIAUJcvdyWeBwAjvzuDR9cGAEnX1RbYzQYAmDbByQCcAwBonUgxjmsGALXiEH6FcwUAchSqFug7AQD4S63TZBkEAP+zdiC1BgAALQjOuRZ+CwC4PoVXL4gJAMQf0Kye0gcAFee1WWrnCgD2qWGVLt4HABx4lZ3hzwAAPEUcYswSAwB8B9rmrEUBALjpnO8rkQAAdrxDNH7VBADLXqW29NQAAM47c7uw6wcASQUgBWq6BwBpIOLk7fYEAAKm8QqpsgYACtiyWyTzCwD8bvMg9+UIAGzAYM/MuQsAJXnzI+OECADBdoIsgWUEAJce5pr89AMAJC366we8AwCg1Fy1RLcDAPMhV7JTJQcA0xKdTo/9BQDZYhAqsr4DAKjJgjsGpwYA7ZfBXaOlAADvPaUGDMgDABbLscIyWwAAgoHVeiykDAD+nnl+ZsgFAKFQyHReLggAmYZOYdvwAwAwZ4WkcRcLAP2oTdLMXgAAGHnw/buABQBqPIeGNecHAD75d9/tTAcAcbQ3alW1AwCC1E3hJMUAAFbGlnRFgwIARc22z2utAAAUJLDo0XUDADOnJ50H/AQADcWGDESLDACFO8qckjkJAC7fTOTy+AgAsaZ7ETKEDgA7risMF0ECAH8vv4mwOAEAOeo0/VugBAD1XpJMkQMCADxO4P9/SQcAmK/sfFYkAQC0c8QKhqsBAP+nhnwiwAUAd0TCvxIbBwB1MKhzpQYAAHDIZilh+AMAAI0ENvr8CACCs7szcW4GAHZWpKhCSwYAz4WaT27qDACgeOjuV28KAN4NKnjJDAIAs6pwME5dBgA2d1QxjrwHAJgtQ7G/ngAANpdnd6oEBQCx74dW1SwDAJVhL16PRAQARQNGnZFoBQAnGq3gwjQAAKPb2UMZBAQAyqpsokN3AQBkyflWkYwEANCaHo0n7wcAAb2njuUMCAAMgCkUky0JAJbM60O67gAAePiVU92EAwBy0jUaM98BAA73Sv3sBwIAQ2iXHQpCAQBPWTfTmXcGABhgj1RHFgAARfF4Vc5/BQBxKhQMIgkAAJo1FCP5tAEAsWaYpDAwBwB5JgvpK0QKAM59lNjTewcAKCBVwVX7CQCh+VYdGf8FAFEJFYmdEAQAy0ctLb0lAgDqO+eAwHwFAMsfcnUQ1wYAMvGncrU5AgBokC2sM9QGADNwpDD5KwcArQ6i9KxPBgAqQLmi92UDAPNYpybFIAAAdsxC8FnvCQAl3XZJwrEDAHJisVxmHQsAVsVw5FaGCgArYKXgz1IMALzb2J74NAAA846NlI87BwCryiPTwYYHAFFuJqnUOwQAE1NhxKwqAADfd3hkoPcAANTwkw/M4QQAkBHvJkfsBwD4EvWL1b0DALgEs9e3zwQAEu+Jl8KZBgBQvCHj6jsGADW7rUDDJQsA9SvkoeFiBQDTNMTL1LEFAP51m7hsPQQAVg6QW40zAwBTGlN9Mo0DAJ8b1WFcsgEAdZCzIkZLAQAmnwrMFSYDAN+2nLkRdwUAODzpFJymBQCZxaSAiegGAJKFJXGP+QIA7qZUT0SuCgDBxft6ORUGAPv484N3DQ4AuYbEX2eqCgATdp4uBtgJAFaeD7VMpwQAkgFkwtExBQDSf2ydPcAAAMEQZhXNfAUAaoCdJK6mAwBafJCphdoCAK9M7CE3sgYAojpopNPSBADv/Q6HxvkHACXvis64mAIA3mUhCupyCgBu0D7veYEGAB6s/sC54gwAumMbCynuCwB8OoBxYroGALIM9+9TeQIAUsUOriJPBQAkJy6pPZ8CABi9IgzKQgIAztUEhIpLAwA1M2mDtewGAE2437927AMAT6BWz5XIAgBSTdVJUTUGAOFl1L1iHQcA9V73sdq1BQClub4M1uIJAFb+XRfCJwUAH/WPK4qeDQCxYhJiM8MBAIDfeNMozAMApoyW9EEhBwANbdtraQcEAPv8L7Jx0gUAcjF/MV9NBwCBytlnVOUHAA31hjFlpQYA8S3m7IixBgBxSYQ2bcYEAJ1+VMS8rgQA/bVUc56NAABowW0LdWsCAMmsAR6IYgEApQEd822WBwAdmtydvXMJAMkBbScbBwAAXgKOkdiwAADr4p6n7lsHALhNCYQpyQMA26OVv4/YBQDfclj+Hg8AAGolGCOH2gUAYFljgeucBQBkx5N284wBAOoZO9EcbgAAUwNbnmKvCwDk6Iig8QQKAC2o7pz8DgkASqMvPIaJDQA22KihpvMHACNvFm9RrQAAGshXbfVjAgDKOEY4IjQBAFAKr/EfMwEAFm5SAwYIAwALgD1dOUQGAPzevj0guQIAVaNW5oyxBAAsGLxmND8AABPl0t4PDQMAPUe4aB6XDACV83mXzCwFAMhVgq4E6QsAOJPzRq7sBABYHDWEUGEMALMzEvIaTQEAC5yziRneAQCeb2/caSYFAMc/jLI0NAQAmcACQiGpAAAuoLmuwBkAAJLXlWnAogEARBxXsctkBgCygPo2B/8GAKVcidKgvAMAvwHMnraOCACM8y2RyLQNAA3ywot/6gUAr6/KFuUgCQAn3zhAi+oEAKRiXTy8MQAAHghMD/7ZBwAs8mcU1T4EAAnRHgzM5gEA8eja7R1jBQAC0srxCkYFAF1l0J2RtAAATMEYfWnEBwCkoruQyDECAMpCBZPgTAIAhQvz/VWhBwD5h9TlxsYJAFncSxPhSwoAMW8ycFlACQDzJHOKkkkFAAbBBv31kAAA/UMeArGrBgCgEdf6vDICADd/BDzBpQMAbaAoPE4dBAAuGu5jpzIGAE1evf9L+gYAkke6pjX9BQDonekdXrUHAM8N7G22kQQAoWTa0I5KCAC9bglF/OwNALGItJPu7Q0AjrxRGsGzBQAYcAuLa88EAKcy6sc9sQUAHhNz28KPAQDjV48fZeMHAGWpXwVWVgIA7oUMjTOPAAC9cxqZIagDAHBYj0HmOwAA8J6sjsHdAQDCjZme4EwFAHiwLqjUMAUAi7+abEVzCQCsDRAVIIkHAMv+lUDhPgMAZAl61pWtBgD7ywB+PtsIACVI+eEwNgQACUBrapXRBADgtfgt/hMCAOaREaTjXAAAdwHxU6deBgBjYwniPvwGAKxnbbk27AcAsVgHauwQBQAJIQLfh+0AABoeksFOKgAATHnP8WJhCAC4Xv7K3SQLABcyRuDVGAgAjUKSkIvnBwBnwN61Em0LAKK4JDuaJQYAnAsX9LWIAQDrXeHewIEGAEV082Xm3wQAgCcRxUPRAwBXRRV5kScFAE1CQQePnwMAPZJXs25eBABvdNtemywEAIK6hXhR7wIAUS9bMPu/BgDdEteyErEFAOLkT5d0VwMAo+OWevhKCACfswspaHkFANyuWIxOlwcAxog0CH51BwCLvOcqxgEGAHSr7MJwUwQAOhSrj7fxAgAB4SAKQ7gCAOP+iB2epAEAlk3OR7uLAwA31IS65/ABAKrCXeND3AcAGJc+J1wqCABOi7LfySsLABnb1fj0jQQAjwJsl4dMBQBQLdiB+0QAAMPZfYhlZgYAsrBqCnYpBgBsPiTH5oEEAHf8RnDjlwAAzFhnAXLvBwDZ4wepxRgHADs4a4zJuQMA3MxeJe0GAABZmiI4ZZcGAA3D+SOY9wcAuof1aPAfBABTzRsZCsAJACSeIJxvtQcAvqrMXx54CwBswDEEm0oGAOgTtaM50gQAZhAb9SOXAgDD2QTP9EIGAHqboFoJ2gQATXg9N+CkAAAZKX1bodYDANalRlCnGgQA2tPCHnWRBgDEIWerODYCAIPhrNCncQAAMUThIFI1BACBOSgqNuEAAFSWNdh8dQoAjw2xes3pCgB0F3bPm8YHAAu6h8iqLQcAYNpdrPS3AACkmAQs2r0DAGABGKpnTgcAp24Ux7zDAgBfKegE69cAAP6gbx7qpQQAYGxDXGNeBACL0dSo9I4CAMoqMqep9QYAq0TZo+vUCQDk3PMVDxAIACR4Ng5wGgYAIz2rkiKSBQDT6A5ouSoIAMXGQS8MAAEAdHFz358hAADnfRJ/chQDAB64I30n5QcAehQuGuKUBACaDeXdhYoEAPQ9STT3wQEAiWiGZNt7BADsjo8EfZoFAGukvmzXtQYAIiV4HhdBAQAffNombYAGALmaxxsd8wMAaFGfRSCfCADSPcBpuG8BAJTZDOxsVQcAClG3A5rrBQBxy5Hd0QoFAEeKtIBXqgEAd1JoPzOuAABiCbYzlxkGABFlJnwVmwYAyvGT+EBHBgCE9vsIpDoAAA33uDge+AMAEcgXXzV/CwBagTRT6HoIAI7k0t2r4wcA5UUfvuoeBgDtzTQtPq0IAP6v2X7MDwEA8m/psIwkBADiclERHDEEACVpvxzUyQQAUE8Q/BAFBQCdJG4zxQ8EAOEt+zlmOAMAeHvRcfi7BwAEgH5reV8HAKEPv1jBJwEAdLlRrsSPCgDT29K/iW4KAM5ldqAi4QwAwgU0ILHKBwB9Fp1Hgu0EAKJ5mC5CfAEAw/7IRlmKAgB3K5EuszoFAKXgn6BNtAcA9H7Qh+9UAwB12cVgIrUDANwfFzZonQcAu9RA8ZTZBwBUGFYExLYBAJJTIC3ZAgMAZPHg5LZvBAC3ZVKtlzQFAPyGE6Db6wkAO2qzDC8wCABsQuv1xe0IAD0opLyiwQMAAi+7xzA0AgDCi7Ub6qMBAGFc3mNXJgcAyvF2O10OAQBnjtpT1r8DAIoqyD6VhAUAe3CnjyheBQCBHZPDXzkFAMthE8VGWwQA0eN/it1NDQDSGcZBzM4KAJBNrGJlOgwA2L2nrKXvDAAhIfOuwMENAKF/TzG/KgAAKBWKntGRAwDHX4kT+qIGAJGl6t2OnQAAt9w2+nsXAgCP23n6vBsAAOFmNutL2AMABCKBHZIMAgDOMjs9hN0CAKvYh5NhrgQAg/tbmER+CQAhzCbGMk4NABeB8y9BlggAaSQa1kGyDgBCuuWrhVYHAC6jRFOq9gMAuxEPaIOWBgCqI/aBNUwAAKXLdVivAQcA83uxkQ2gAQCy8mHrMwkGANJNKuk/GQUAPvRQpZXZAwA9iDq5b1UDAA47YptSNQEA64Mu4rwWBwC4PrgwAT0DAKyv0LoqlQgAiRvTTvYJAwAKWVGgLpcNABjV0a3X2wAAHiPiI/gZAQDifV5u1lEEADj4cJnDAAUAo1ymgVubBwAReI/cIKwEAPoB9amJlQIASmtq0hDYBABZspYN4O0FAPMFWcnp9wQA65lSNT1ECAA47lp9fZsLAOs0L5pRkgYAeM8kSUDkDgBJFErsLpQJAC4wgVe8SwcATOyBuzUxBwA8SGEbZ+8HACnXzBRGJgcAOOaSrZMZAwCSSSOuGVMEALVP0kedIQIA9mywiETwBAASSnKeqjoFAJzvFFOmoAIAJ3kcPM0aDgDleYe3RosFAPJ6vqyaNgsA03QwdLAJBQCh3rY53FUIAMIn+fd/kwcAtqXGFPrCAAB80G3bvVYFAAjRecGs9gYAwkeGIW7PBAC2W43CfCIBACN29b/pjgcAOokfJLKMAgByZzweVFsCAKIKcQejIQEAyYN0xz5xCQDK+tVyBfcGAIH/Ik7zXgoAhxEUT5RNDQDSzqaUuycFAJdKA59eXQMAm7yFlwYmAQDwT4XHTkcFAMpIowKjlgIADqTHdvwzAwAuSFuZKpkFAMcqAAfHjQcAQRfQlGOTBQAX7xoopPsEAHoKsmmQuAYAZNvHtYz6CgAPqCqY5hgPABoaGviVngsA+mxk85TnBQA5doowPUcIAA0icGJBoAIAJdBpiyRfBwAnamUWvMsBAChn4tb/uQUAPqc6EMI7AgAFnlgDJnkGAF1ZkpjbSAIACC2tPKUGAABzuvdQAQ0CAEPg/Tv3AgEAmhxRteDaDABV1OD/fyUFAIAh69EIQQ0A+a6bD8yWCADppF1yvfYDAMZFV3+ruQAAYx3S+PDKBQAr6gikvt4HABZtiZPbngAAwKVe0pdlAwCsWGAQe40FAGnuC9L4zQMAXgFlt0wKAADJfHwzMmgDAA2mncHstwcAiPp8p1FKBgC1Dcpw9JwKANiYCG4LtgQAx+b/3QRdBQBcv2HG7TsIAA1pXGk8NwIAGM8NUsjABAC5lHRLr4QDACUioo5KqwQAQxdg11ojBAD1dYkHDcsAAEsMUz4xkgIACaUkkbuNAwDxEVpl0FADAAbfDCvO5wAA5nBL2d/+BgDUv0WXPzgKAADDxCeuvgQAPz9qQaRaBwDOrjhhJRUOAKOFjMQ6ZAQAkrg1J4yHBgB32PQjNaUDAJ3ui+0EpQMARvvYpeBmBgANy3BITvYDAFdlbbFIFQYA85Y1d2GiBwA6XSdfTXIHAE1RDYG88AcAjRNyc62dDAB0ENPl3kUHAOLbf16lsQcAoW4Xj5i6BQBa7N0HqdMJAG8T9CakawAAILcGBvzKAwDanDWi8BgFAKfsb+Tl+gUA7Y7P2/jRAADcgdA+MZMGAEIXkGajsAUAfsqkLIcMBAABngCUgPEGAL8xSrQRAAAAXKcKamkfBgDKQq1XCosLAMj9Brea5QkAzL9u1AgTCABQKC2KmD0GAAxsxj9soAcA+0e6wbrJAQCOA3XFNTkCABOcxXG98AMANegW2UisAwAuI72vUwcCAAJg0B67HwcAOq+kR66cAwDC2TQLfDMAAIo2slKtPwMA6M8ixNDIBAClcVkntGAHAD2tHLyV2gsAdXNb/1HxCACmkMtcNcwDABYe5MXGSQYAgKrm7mcGBgCQ4SsYnRcEAHlpflbZUwYAbSWaQg9sAQAxkT6QQ5QGADbd+cZKbwEAU5LiEknqAgBd0mg+ZLQCAOe6JvTqMQYA6A1wo7l1AQD7SKoAX3wHABcDyoV3kQsAmJPHsqlaCAD3ZfbH8jEEAJ/+ZtoQBAEAfda03IJNAgAtdRcO/uYDAI+wyx7e2gQAkeqxSJZZBQAZe4+FRGMCAMBaKUo99AUA1KxSXKdCAgAQDSKARJMFAFMS+RVHsAcAxrrmxIDCBgBudmGzo60LAE47XBLlLwQAIqxKTdgRCQDdfKXPCo0EAEOu9qwovQUAfZBWj6tvAQDy1RgSsawHANu0IyDgHwQAZS9cvzebBQBx5qt95CYHAMH2RudF7AIAhkbHUw5YBgB0P2cEoe0FANM2Exk0YgEAQIbzH9acCQCoG7TExmAIAG42pwz3XAcAHgFs8agYAQC5A6IHV6IEAPZ/JvbemQQAPHcIgYVuBwApy93FypMGAPSfCtARAwAABV3N/v3NAgBq7fZTimYHAFYlFC66AwMACQnBhAWIAwAdJgoAIP4EAORI0pYYcgUAO9rQoZFQDQAKBcHHv/YEAL6pLs1OTg4Ab76L8rF+CAACS/xakzwIAK4bGP0XVQYAbYF2LHflAwCKiUCWGBkAAJl03oQq7QEAwWNP1+14BQA9DCtJxnYCAC6Tv0D8mwAACzMf8eiIBQBuwk1pbtEDAIwokLUq7AMAuNEyrgk6AQDktFq4HugLAB6uPKSseggAc2NS1wUvBgC6rcZmv+EIALl72OR70gAANLRdIydsBQA3LaYObi4HADnobtBMZwUA/ACiJVzdAgB+iCx56dUDAFW8q01yGQMAAAhoeHy5AgDd5jTd368HAIiuNYtUMAcANOPWoUsJAwALMOOnJuEGAMX7/K7AiQgAgmWDH6HuCgCDh30nooUFAO64qMujUQUAhtjiK0K2AwC8iZZB4TAGAFWppwc7ZQQA2xG0QzQEAwBiidQzgl8CADH0rwSPvQYAEmOa/Qf5BACb0jfH0w8EAPkOlXhiZQcAis+G6qNzCAAtnPur4uAGAO4z6jgqDgYAGP7zKSQLCwA+YUtIv4sKAMDIH9VZzwMAGEfe1qCgBwBLt28+OlwFANVPiF8TUwMAhBuMChb0AwB8bBNvXC8BAEzeN6Lb/gAARKu/zrx5BwAJaU0/qa4DAI8YWLOc5wEAboHg9dhTCQD8Ltu7M4UIADCUEpaXFAkAQoYWNm56CQAendNSq3gMAPHj9+7DNgQAJgAfwtP/BwCpLQrye+cDAN5yhPy/GAQAs6OzUXldBgBZ0VKS06QGANTsAFnjkAcAhneXvyUHAwBToDUWXAoBABKiEaSHbQEAcAVO1eLVBAB0Xz+z1+UCAL9+iD/epQsAtjlhvSTvBgCmpXe1kPkJABViBkJafgUAdzaYRIuhAQCPbx7eUuYDAOvYLuArUwYAOF8WyIePAgDW9+gbrU4EAGb0MU+ddQUAQ3n0SYE3AAApTyvjO58GANY0Ff6CWAQA5G88lCmZBAAVW1RycDQMAMTn185rIgsA3ontTBM6CABeQM5D+NwHANaDeXVdNAEAzcw0QvUiAgC024o9SngBAMwrjO6+bgMAb2KPW/6IBgDAMkdKSNYAAJItU8ZKuQcAD4VUhxt3BQDIYRTf2Y0EAHEy54eWcwYAwBoMyJ3MBQDN1IYUZ4MGAHOBXhpfbwcASt/59dPVDgDm12iPC9oHAKZ1VjgUIAAA7x09tV8VBgB8kokuo34DAC6o9WimWQAA3NShqxVhBAB22rXDUxkHAIF60zMiZAYAvbF2gGXJAgD/EDDmgaUFAHQ26If4pQUAuUOmoNMoBgDSkwxk2BwIACsP18qwtwgAvUSBqU2GCwAbXS2uNz4EABE9oXDPAQMA7JEYuqGmAgDgOj/7kfICAFLqS4F7GgIA0URuZZtmAwAz4abtBj8GAA8HWCc0MwIAdcCcReCYAAAbfGytXt8EAF791GweogYA0LKZZhIpCQDnPWCiEe4IACBMx/XCCgYACGgZKhmbBQDoAXCwcVMMAF/mRjAKFwYAOJ6kRhpABQCoxGFV3QoCAEae3u20qwcAXxkan7+GBQALefhejQgDANu0/CYhjAMAw+NJ4bqFBgAw6aQB1rwAAFIOeQP76gAAHa51D16ACAAnCoZZzGQMAO4LsLflSAoAdI/vdZbZBQA1VEw040oEAC8ESDfBVQUAwDJCdUHQBAAHaYYwtCEFADmc+0COMAMALKB1xqwJAwDuQ6W7uYkCAJ5TKC5ZqwMAOtjNq4JNBgAn43LBjscDAEb5tyFSLQYAKXr3OibUBQCwroki3T8KAOu5fvdk3AcALEA4g9IbCAAhOTilKU8JAG2T0BicKQQASYpBg0GRBQDVriHHGCoFAG2XgrpRsQIAVMdL3u/ABQD117Il3H4BAO4bCKY2cwMAw+WHiDG1BwDhWxpJbZ8EAOC+x2Uj5wUAPrMILwY5CwCxz1fm87sEAGdZbvX3eg4Ajtaef9bbDAAzt1xVIAsHAH8hcUUH/AMA62orm9KgAwCd5d3MeGQAAPrdGwVNXgUATnvEBBF/BwBMLBFVxRMBAMq3+QNRUwcACCGaHe1AAQCvwjszIiUAAGSg9JhD4wAAKBlLPgkLAwASA8h+fs4JAIOP97115QwAOO0LGXofDgB4o2ztrfgGAOi9zj7ZIgUAz/bgRfAkAAChzyY0tm0BANgP0x86uQEAYqNoU0DlBQCasrf9PRIAAGg8UlZDNAQAX+4heVKaBwB+gT7L/EsHAD2N7HLegAcAcif0APPqBwDjTDWIUUUNAKvLPUrK3AQAy+u/0BTTCwBXK9Nq/N4BALznmghFhQIAXMGg6Y/jAQB7N+LgRiABAIWoClYccgYAKBlnvyjrAACnlVHvGr4DAOu1vWIv8gYASTBSuGiXAwC9/fvIlDMEANKNvwHSZwQAlud6Vr30BgCDtxeTyFoGADKJ/SA7fQgAFWkyCPIACACDo1tanO8KAK1P73SakQYAv1IUYdSeBQDvCeoE7JEGAITpACfLywMAPLr1xEMcBwDNdJ769m0FAN9Wz+SVnAcA4gnGO2S+BwB46NkqwUkBAF8MOcpYpwUAgdxhHYuRCACb0QwmUNMIANi0N06rogcA1xRUc+ofAgCdY38COKcIAJUkRtkQJwcAVnQAqq9aAgAbo+ooH9ICANBfAOpxdgEAtz5LJK7bAgDM4f9XL0oHAAFzCHMwvAEANJwB9FfsBwAkpR8uCE4DAGoSNaaMaQIADtk9Xi9wBQDHxXBKmhwDACT8eKqlNgkAAHufOy+ZCQCir8SwBMADAHi6sDKIMQUA7Hzxn0vyBgDHYOAwf6QAANDIDVSEgwUArpzE3EP7AQAruPQGrEYBAFVzntgAtQQAEopyHB41AwDjL5NpnwsBAP3RHNA/tAYA8w52PlhCDwC3FjJXwT0HAEpx1/1IrgQAA+ETil/4BAAN/9ayIDQHAETFl0ZLXQcA9Pj3/+EbAQDh91do4RkBANX1XDQUigMAL7UFcY2mBQAGHoWey/YEAOWVGEfEeAIA5GQ9zs3vBwBMS1xFbU8GAEuj/jJW2wMAwiWYgrGQCQDIJTJR0+cIAK2rt+MrwQkApZweeHeHBQDyXUnql5ENANjZXfcr7gYAjb406yzHBgDHXjTMyXkGAKSYaPmNiQcAdZ30rSFDAACuWuXkGWABAJwgXfLFTwcADe2dk2pWBAC34BbnY2AGAHBNH9yvXgQA2rHMzyRGBgDBtnKAq1cKAAlvZyUHEggA7Y5O0BigDABs1aXuPPcLACvXRYCFAQQAMC3K4OVZBADqizAZt4gEALUyGw1KbwUALTaAvO6lBQDGjU4K0b8HAPQ2ZzaZyAcAAVz56rteBQCKP5BgsG0EACFmEolYYAIAL+V2xjyOCQCPqZXZeWAKALEIeSF8SggAWWXmA3bcAQBEJAuh394IAAT/YIOmBAcAPovePMzOAwD/ZA9H1RwCAIk5lY3BqwYAFebkwtBKBQAqUiu41WcDAMd9Pbj00wAAjcXbTH8GAwA3eWnaUgQCAKl3qivLLgYAdCi2rzYoBwBAspQgPK8AAHo1fymFwggA4taAVi3MBwBjVgfVExkGAD0rFWFSeQUAvTz6utuhBwDViCXFMa0FAFxoZEE6XwQAbZaakZ/lAgDaMTIaNi0GALgBTgCEUgYAYB3pO1NWBgCfqABsAa4GAAUcEyq83QMAFLuWJ6JXCgB0PkT7YPMGAOrqIHLkgAYAGAzxpfL8CgAfg42zf+4FAEvFXs75DwQAW7Nh4oVxBQCpcA5UVOIDAPjjA0CBtQEAS8BKMWiJBwCOakRBy/0FAHEq/yZpKAUA9rOW4jHyAACTRshXo4QGAKC8yTMGHQYA33P8+LwoCwCzlf8G3rQLAKQRuiekCgsAm23avzHuBQBngN/COrIFAGYl2/81SQQAbmwXbQEvAQCu9RYPsPsEACpAmY23+gMA7XqE/WXpBgB7UoDuU7kCAFqzsc1bXwUAZjyiPws6BAAKgos4B24HAF3ZnbubmwcAYXOfjq59CQAy2gJh9xkHAIvKgCp8EQ0ANQldtmYaDADKrGAUgboJAMImMWpAVQMAdn1yGBkNBQAOjkkL6uUGAPIUMga2owAA0p+MFV8GBQBUmUIM+2kBABDu7NntmgUAAhiF6xaZAwA4xVxVF3kFAE+K5TkfmAMAy2/mbaXfBQAIWQcJiAUIAJNKhcvY0wYA47Fw6fSyBQDBy+1SRA8LAJMKI1l1igMAH6OL3hwsBQA9WnTU8qQCAIqi1EKdfgAAzVpwg8CNAwBAl3XFgicFAK2Q2ZczPwUAFU3oxzmpAwDgOX4ixDQCAPKTpaHZMgYAlIQM7RH9CQDgVyftsyEIAMXBj+UdPgcAqxZGyBDRBQBkryjfp6ULAKbLB7gVawMA1/4anor3AwAfj2AsnKUAALeBy47dKwUA1H6ESE+yAADH6htRvtQCAJtbntmkvQYAAU6Rlml+AQCAz3/O8LEHAIFUR3TPTwMAharPeKsdAwC3VF5uIeMEAIm2czmCSQoAhIjkhElYCgA2+0IwmhEIAMpnl3hM4AcAMrjPKBtnAQA3xeGifuUHAEFBRO+q+wEApt9kwb3TAwB9F8LonNgCAPQsGLoSzQYAl3aawYoKAgDZcsyy+jkFACDeHo8IbAUA747zJKxfCwACq5dhXNcHAKcvpMJLPgsARIG0EM3HCQCPNUjqtzgIABduqBARPQUAbUZftm5BBgAgzl8jphwEABK7mYr8wwUACJG5xnSWAAD4bzGZIfgGAOnzqfFUXQAASie90MW8AwCt1dK4hLIFAJ6WJRDj5QYAD2IGYw77BABg5keX9TAJABnU7I+GQQgAxTuSjF4QAwA4GD3UigULAPuT5Yf1YgQALTbOp0vZAwC3Zya1+TADAArw4Eha1AUAjZp4FFGPAADQY3bl/Q8EAEcGwtRFFAcAfA8XaD5lAgDWXsXj3kwGAD3+TvpJZQIAbmY/r0mFBgBou9RBKZ4AADz/XR8x6AIA0vsf+Z5CDgDiLBP+DaEDANb5ax5GWgUAgy6w9O6OBwDPFoxkT9MBADJRuirqfwAAHkDGHW6SAQCgzhfqik4HAA+8P/hDxwAAVVS/xAPLBwCYfpGpi4oGAOVh2AEd+gEAq5Tf0QCsDAAaJ70BIboDAK/EuYiJVw8AfZ/0ib/yCACf6Y7Rzj8HADKYWX2UVQAAkBmkKv5GAwBbGXmATBYAACe6e/vMmQcAXKfGO1ZzBwCznBNjCOkBANag2Qe0+AQAaU+SyiSOBQBWZOe7RqIHAGS4Abcm9AEAPyWhkcg1BgAv3o7T62oCAAWu3frIbQYAhjegQX0cCgB9+rOxa7cIAAEckUFMJgEA+b2ERfQCBwDejsYfUTwEAPk17TosSAAAG9NxUq/hBACbk5J/+cEAABfBbZWIegEAx535XgDuBgDMMbJykaoEACp362HdtgcAx9IBq/mrCADlCmOHAogDANvtWwTKLgsAzzJfNkN/DQD1v1m2qT8FAJI981DowQUA9fa5mhHsAQDpY+Ztb/EHAMbeFsvWpwcA0vHqvOkDBwBVVIiU6cgEAIKtnNq1zAQAdekQxmtZAwBen9sNDKgHAGFMXD7ZmAMA8uPn0mB8BwBwOHZREAYEAKrS7ODEewYAuXMTH5S7AgAwLADJyZkGAPNI4jNn0QMAieNL4bfiAABKePbaDSwEAFB4xh/qiQUAkfHdtQk7BQDM8UZZI6cGAGC+L7ucuQYAYlxI1qXTBgDAI+lmlIMEAN38xjCvHAUAtFSsGJr5CgBu7mGWo5gLAOLNQB4zhAMAphnexBXNBACOnxic4ioJAArgdHZCpwMAwXR+Ty8UBgAVOowxk8wEAOceK6wb1QYAPziSokpQBQDPAQ0fy8AGADPV9Z5GhwEAv0c3iDhxAgDokDrlKvUCALqOlf4U/QUAjsuTv17+CgCH58uK2iYCAKF++6KDCAEARM9CeHCUCABccmD5c90HACyrRSjfLQQAu3Yy/U8hBgBGUhoYjQsAACDredWmaAIAR4blJv+TAAApmAVo/iQFACG2fOR1WwYAGczVpbBeAQBanZKzCVIAAEdryMub9QIA7sKRtmDVCQAHzuP8uvUHAGyAFBZWzQwAh7FwYYtYDACBENDjVaoKAF8TF5lCfQQAcPB6oM/qAwBEbrRGq94BAN9spDs/pQcAGuXiQotFBQBPRAcM5pIBAKodokOIrgUAOBULkSHXBgB+QaaVGjIDAGinqASQPgEAbIc7GckABgBldw2KGxwKAKGOs3+SeQsAGuDbeXYNBwDpjYlAYPQNANvOL4NFiAUAc24Mf801AQBb4+jf+z8FAFvlBl4ZLwIAzkuB6Dc5BwCN9HspFnEDACCXBg2eWgQA7ESnGvdaAgCjq4rL8BoEAF4diU6KzwIAomvQF35IBQCWZS0DKocLAN9Ik8AoXgYAwkDOsmt7CgBpHYny96YHAGcPEQeH/QMAsi2pFodvAgAnMHUbqs0BAGEmtVi+BAUAUoLl1psEAgBJ75pqjf0BAKFvIbdnywcAgrnDU/96BgAoltoQpg4CAFlU/K0aAQYAffjLAsjQBgB7TFXtv0EJAGJC72e22wYA3H6FJjGPBQBAk3eL4ZwOADz4lc9tkgcA7CsOEiUuBAAV+vFt6T0GAMz581Br8AQAL7awwVz8BgDLeZiyKFUHAD1aEtKPmgcAuGp0S418AgAMIQI/ifgAABBXrrOWVQEAyiRRfhYxBwA/4bvoOHsJAFWQL5Rb1QsAPpG+lRScCABs+xokTqoDAKJ5kT/SOQcAxOi52/oyBgBIDP4rUsgHAKla74MJ7QYA9LWHdiPSAAD1BTMqvzgBAJhl2CRd9AEA/mAhrUsnBQAq0VgdBLYBAHpo5KbKLwMA38yHJ3OkBwBABn98Qh4JAGOMXzhZNggA+mt22er0BQAAJmwz9kYHAPWafcWNbgUAeE++F76zBQBLL/iMkr8DABFvCmBVLgUA1uvvnH5iBAAcl2yrRfMCAOnnY24oUwYArSOKt2EQBQABRbWsmUkBAGbtB3CRtAcAyqJT3SgbDACF6odf6HsDAEFeqNLjSwcApmzJ+oe+CQDMCP4gNtAJAGSwhKtc+wUAsIWCdz5RAgBD4CUxOFcEAD0ibrWjvQYAT4RvN7oiAQBU5bSizTICAED4D6MrQgAA9UN7ZudRBwA+X9pVFyYGAI62Ur9wLAAA4XKNRb8yDQCbtZbnlg8MAKKdb533LgIAd8q+Z6sBBQBD6z9+abAGALsvC11L7AcAUFRZEOkAAgBecQVxBUIHAGAPUyJw8AIA7wmk8DRjAgDAo2LfSvAAANm2i7Tt4AUAA8D7pErDBwAkrFxOTtcHALJBNPQ3zAEApq7OyfFWBgDsWq2sHAMHAFdscdCMMAEAQhmUcxMcDACV8XL3RqMLAE8yx1xaVgcAEUok1aAcAAATh0FnsBYBAK7tVYx9pQAAAzgQnIDGBgDIatriElEFAFq6PQo9NgYADPSmi8kZAwDHbqMDS+gCAHzv9rkRWQAA3OouUfOsCQBoKmk5mGMKAAYFgzSiaQYA1AMGDJKLBgCyZByd71UNALsO3/WDmQMAJpiViSXqAQDWzQOHY84GAAWFiXgWMQYAcKKaz86zBgAIvXM7unAHANSG4fd1FAEAvCuJyRslAABazP+bq04CABc4E970dQYACrPaO9n2BwAl1L+lrPMBAGCXHBxS+gIAzfknzoAhBgDTLIgLRQ8OAPyCF2sDUgQAxYF2sJUtAACyBZL5HJAFALTsXm5okAIATBZw35k9AQDKwOUhw14DAClA9DfjOgEApy0/gY4ABAA6DI4vJ0AGANpe5eltwAEAqmlt/0ArBQD6fzcJiBsLACtM0VxiNgUA0RcuJa8WBQAr0+f4loAHAOLEPqPWegcAIdMR3MUXBwDkI5hVFKEEALHioVDOBgMA28L+oTjPBADnXPoNZaoCABWU8agWSQUAeBLnb8kNAAC4PuaEJ18FAJFgotPKcwMAmrvdifuoBgA3ftnVNYwHALIs73Q2bgYAj91TrEdDAwAqEaXtRxUKAHz1yYJNYwQAUtamaJIkBAD3L39obTMGAKDZJk5P/gQAQVSUPQ8EAADThln9OekFAN+bAUchKgEAspzQ52bEBADdA9KVW/oGAFSiNKNQNQYANntUckVYAgB3ExyBWFwHABsXzDfG0wwA4jR9dDA9AwDXp/q6kpoLADfPabXt1gcAoCzcpZQBBgCmEF50Wa8FAHVIAD71qAcAeK99LKbuAwBOJ5PmE8cEAKSzbnob7QYAFY59ac4qBgB1sCopuGYCAJxcZqA2hAYAaRAg6BfTBgDKoyxdgZAIAKCZFOvxPwgAGONQ8GA5CgAQFslpNjcNACc/LyDoNQIAgBe2Lp9MBAADcB1bkDAGANHqdNLI/AQAeKtof257AQBXUg6aqxQAAKWLf1Y5mQAAgjxCKnu0BAAtxHrl14gGAIePZ1pLywEA1AegomKqDABtLfY4Dh4GAIJHzI+ILwgA/xvygytWBwD2LtjSD9wKAGz8SjlrwAQAzDb2SxuTBAB4IzLQYCsHACWLgcYnUQIAQ+eNp7wwAwBOdBkRhP8GAAWT5OhgxQIAeqXl708lBwDfp2DF4noGAPFps+EbwwMAckLL+ZO8CAAsGHPb+fgDAMThuuo1sgoAGVUph7/dAgDV55cQ7BwEAO6KlAhNhgQAHvaNQzfSBQBncB9ghbICAFPX5rq8XQIALSY0EbYwAwCKgG2i1xkGAPK+rcKzwwMAUn/snnyHBgBttuHrub4DAIfykc1EawIAgwNzYpPyBwA2nEVRef0HAOdJLVFMUAcAX8U7fu2HCAAlx0kBsd4HAHV0OI9HSAAAPopn2ZeTBgDzdslWgXwGAGwiiVVN6wIACsHB5gnHAgB67maHaq8CAGzZoXmqigAAsC+b1ZIvBAAHnABALHUBAM5i/+lojgAA+fK4CtUJDQDk5Xskq7gJAIXksuay2Q0AOBOaR6X6DABwj3O9E8sEAK0wwUsKUAUAlYaTeqEnAQBt4zT6JioAACjMHi7RhAUAo+t++PPxAgBKthXldYwEAPAeB1JpWwcABlSWQm3UBQCfn5gGYXQHAOIKPDUemgEAvb2W1c1yCQCDFojfHXMIABSBT9YmBAkA2aOp2E8aBwBqJpA5vTYHAMMF+rpgdQQAoy/Mq9wYBACChs/OkVkDAGCMS6lxQwIAwyAcsUYVBAC0szSTUC0DAKpwriwQbAEARfQb1Q1yAQAhmK8vZq4FAPqHK1opEgQAs+qT4mFSDQDLZZt1JmQIAEdqEa5lAgQAvOW6BCPABgCtldG4C3YIAOnWfvWImwEAOaMEGb/NBAAsT07NSSsEANkJGXcuGgcA0lK7PhVOAQCKgebNFxoGACeIEDStPQUAtlVcxTIrAwCjR5NfFvkCAKwzvOlLswYAwPJxZWVpDAA+Qm/OYaoIAKAnG9dA+QsAadFznfGFCQDc5mJ7nBsIALLAeDpkLwcAe55PwEXeAwBc+jCN1gYHACQvjj72lgYALZLwGCwBAgApncha5VUDAAFx7BS06AMAkAxSfLCdAwDh73ebHvQGALrkhLf1igAASyzMidIUCwBNvPHiUDQKAPOSLzmTzQgAfGuUagw3CQCX/VodPEIGADMlH4jcmQQABsV2ZPJOAwCXFHTSB9EEALP9br3ERgMAoWMR13krAwBqs/zt2fgFAJA5v9zo5gEACvOKNE+XBwB8nPFOcuYGAOITvO+lgAQADCLOQuRMCQDLFiWngIkJAHZmuA34cggAbVLaHzMDBwDIkXbUMUsKAHEgYgEL5wEAaqH4tWPxAQAX1Bo0r2oFAPcw2DWWmAcAe8sAdqJ6BADD+BXA7R4EAEqF7yeNzwcA+ZNGWOOJAgCnCbNXeEoAANpN0YW1RQUA4SGz49DkBABArNLjH0UHAI2p7nj2ZgYArf5nhoU4CACMTObDLdIEAA861KBeJwcA98zXfROBBgA4mre6nOcBAGqmiUQhKgIApSsznC/2AAA5XzvWiWUEAJY/7Hn56gcAqLlyFejrBABKaWFdfxsCAHFjowH6wAEAPWqTjA4rCAAgzbZYO7gGAIAm59PYfgMAYiqf2zegCAC70rEZVAAMAP89lCK2BAYAWBp09pnIAQD7MvLiGQIGAMv5p5KuXwMAyrHzFDb6AADwgr65vf4DAAAUkpVI5wUABieCOOpTBQCMyM8kfKEFAAr0rhii+wEAlAF7PgRXBgDn6e9VG8EFAPt0oMZ7cwcAzFXjHOTqCAB19z/RNcUGAD71yPpIlAQAajXoxnRPAwCi2wcGeK0AALY+tn46IQcAhoyqrOOSAwCvNYo+6TQFAJfJAv0QiwAABR64rMJqAgB5O86YjJ0AAKxQTf4XXgIApyHxdvV/BwArcvyw+eUMAMcoDZuUbwQAJu8XXebNDACXlvgoqLsGAHb2BB7XmwAARaHyQchaAgBxOIKsfqQBABpYbMOoqAEA+6lCFHVVAgABOf6QZrwBAFq8Wi8TFAMAKNUyUYMRBgBXirSOS/IFALf29wTVWQUA/WbS9ueRCACIcwPvYGADAIYSHeyIhwkAr45HHESHAgC9VDNq6iMBANVU67N4gwMA7pSPp6rUBABNp3XoAqAEAHyxZxOFCwEA4wdYLbEaAACWLeNBkBgFADECCSsGWwAAj7fnZhfJAADsOKFVD6oAAIqRLB6WowQAHj8j80TWBwBkwAKen8YJAJdoJuXlagMAeYvT2sGPCABAvdnqzooGAKC75vjgOwQAO05h/N+PBgDgO1urHekEAPAvIcnUsQMA27E/zmvNAgAQwtfzDskEABaHgaD1lgQAuDnCjPicBwDb+GwwnMsCAI9QWw12lQUAkCcC/evLAgAFEewqgrgIAMu8JtLP0QwAvXFJ+rIVBQAVRfVdLMsCAJdjqgThvwEAJWyZ/5QUAQAAWD5iUUIGAL5E4MWf1AAAKcvtQ/oJBwDKKv1jjF0CAGH93ynNxQQABa9I68AuAwB8t/mRk48BAIEMz54CDwcAubAQXqqvCgBMJVWD4B0GAI3C431Y6wgA1Lt9n7vwBAC9dCpayk4EADM+7S6zBwMAwug8sIp0BgC8ELiaDXwFAIzpJKJkLAQAFMOm2NW3AABD1ZV7MkgEALqk44FmFAAADE7DrRSHAwAwjikOb/IEAN7HEkUicgIA/HWpQoq7CwDuF2u01fIGAOVwMSKptgcA5rfjP3FTCADBa3/9NZcBAC40xUmvkgQAVwNa31w2AgBgu/+nOCEDAP5GRtH3oQIAzESK8V0bAQBmQshC0JADAHXcjyrj7wEAOBKu516SBgAy6NCBkq8EAPgdGRH5/gAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogcBUSAC0AAACdFRIADAAAAKkVEgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc8QVEgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAAAWEgBJAAAAEgAAAA0AAAAAAAAAsKAOSicbBgCdGI/8pdUAAGAMvZxe7wcAnkyAppWFBwAd/ARIMrgCAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTIuMC4wL3NyYy9iYWNrZW5kL3NlcmlhbC91NjQvZmllbGQucnMAiBYSAHMAAABMAQAAEQAAAIgWEgBzAAAATQEAABEAAACIFhIAcwAAAE4BAAARAAAAiBYSAHMAAABPAQAAEQAAAIgWEgBzAAAAUAEAABEAAACIFhIAcwAAAFEBAAARAAAAiBYSAHMAAABSAQAAEQAAAIgWEgBzAAAAUwEAABEAAAAAAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAHGOopopnBgBls9iIN+oFAHlCmdbWGwoA4uQZWeesBwDXrTjTnksLAGSAnQN+IQYAbX4zCKTeBgAGgmISwXoFAHME42XLRwYAya0fpQWcBAAbr0WQv+gEANbgRTrjFAUAD/6LWzxTBwDJFH57VYMFAAiwISAXPAcA3iqAioQADwD25cQFRuAJAPpnlxvQwAUAizhCn4jXBwDYRiWuWicEAEhDhkkCWwcAKyZwEOEuBQDNWvtUrjcCALWqOtDRvwMAXJ0CmLWKAQDpiWD9xSwDAAWblFxQJgQA0noMiBhqBADazIgYIqQEAN9TK1Jl3AMAbX8AoiLCCADtd9ubt1YLAM0S/h7oHgQAfQkHvakgCQBuNOx+/TQCAJO/fzI7AQcADWrt7W4zAQCv87uiZbUCAFUZWYnOUwIAAnbRgngmAAB4oy5zGaEAAGwqjrrxOwYAmt+QzJSfBgBI/Jt30TEEAJeg2m+6lwQAoOrPEwPMBgCZpI2EE6MJAAkjGUJTywcAYP3e3paVAwDeEn+RIh4GAAvPjEaGzQMAgcAaIlOFBABuCk5LRskGAAMEGIS6XwcABY0h1Fw7BAAWtdCbL3YCALPL3fvnxgEAveKswwlZBwDJPi2XASEEAE2uEBLWEQUAbp0Ole92BgBY8ongGrgJAIIYlSJJPAYANzKbTdXxCgCE202SJdMOAIfeIERIhgMAAoG2XbLWAgDAcyiWtFAGAJQTJ/0cCAQAgiT+5n8aBwBUyMiluIIBAI5tQOXLPwcAUfTPMDTeBQBBjKxnuVQFAO5ZZUtsdAQAK5rGbTx7BwBu+sI+8e0EAMjqe9da6AwA2XuOsqLbBwDpT+MdpckFAEcRdGTIRgUAkCYJmd+hAwC71vTJjMoBAAM7zcl/awMAXtuXNGYZAgBnDvF5z/EAAKJ+KwrLPAQAanf/34lQAACIi9PhhN0BACIIxgNFgAQAtH+jLNCeDACDeJW1wnQEAINmgY44uAUA5Gu3VMS2DAAFZVGKOVMNAHXRNjrSIQAAbUfGczP9BAAq0O4eKQ4CABByLs8uLwYA5I2FmOBxBwDfHkV40vUCAEJzmTOxMAcAdWnrIFSWBgDPFqW/owgDAFr/aB3tpQUAgw4V/ioSDQAxArtmya8EAGiCPIN4xAEAjxT8wzl4CQD4i32Jy0oEAFlzUljF4AUAXNevc1s5AwBwueSkr3IAAG0PnjIUIgYA/f41AbYZAACDSxNeFGgAAMzDggmG5AEAmdcTX/toAAB+VEQ3KMkHANJq3p/EUAEAJRFHCZXyAwDPMcq07ikHALy/dbUinAYAEuK8VwiRDACYu3WgtbIOAGio3Jw8hgEACRdaKQ53AwAT/SA3WtgAAAarcR//4AUAX+CRd22KBwB2uaBHS3AHABerGumCrgIAzQaYQtYLBQDq2I8VVYAGAFWtxP/HJQcAspnP0RVnAgCInKZBVCAKAFNLzX1CSAQAxb2K6JHRCQAey3eSzJQHAMCY0Bz3KwAAMNJszKudBACyBfkzZQoEAKS4LqzvcwUAX4VfYlTNBABTUKzCJsQGAF4JS85epgUAtmvyhkDEAACFeBlolUIHAMj8tleDAAcA7j53OCdnCABwYZ95v1IHACMz49qmtAYA3NHqlka1BwDQGoXp924IADRKWIK7nwMAA3olj1Z6BACRrR4JiE0BACTOsRhbFAIAbZ1mo5I6AQDlfVfAHHcDAFKZi7sGygMAkAPVxYELAADsgAc0EjUEAK+i+N2WwgMAE6cU2fkVBQDVVSL/kTEHAO+9pMJcTw0AzosR/FfdAwDHkDQ5nakHAEElH7suTQMAnf8jtxXoAABDVOIWtIYCAOi+0Tj+vQAAd3QAx5KoAADoo702JO0CAOqR8gD9KgAAIaPegXO+AACTsbLUUukDAC8wKC12hgIAElvjPAk2CADO6VJ1TbYLAF+EC/7gHgcA5WnJYAadBgDZqUagHS8LAL31Ls4rjgUAim+M9+iMBgCyYZLjJu4GAJ3PC6UKPQMAF289Km9oBwBqfFltphIFAFF1pXCaYAAATEY8isAmAADhOe7IH1MEANKail8wYQUAvq6S7I2XDAAAonyurWkIAFQPKSPpHgkAa5GNiUGWBgDUNT7FrgoIANXAsOcozAIA5GyK62B7BwCmd8KFKQQEAOvTRntlNgYAfMXyrqEwAACq0joAc/cBAHYPwSxkBQAApvws+Eg7AAApQ+4QPEACAGVAwsHpCwIApnOWJNiHAwAqfJLcqL4NAO8OZdWOvQUA4UDNPw7vCACr8GEzq1AHAGBeAuJK5AAAHAQnl3v5BQDs7MByNGgFAHzOsS6IiAEAfgZFxWSXBgA3EPiigzICANEjfvmvdwQAaLu8jZW4AADWreiXWyAAAHVw+7OWTwUAZpJmKQTyBQD1QUmur48IAId268SDXQkARUHKnjfPCQB0u1Kc/tcLAM0esRbGrwUA7yKP7EqfAwAu2SUWnrMDAHOIUNRb+AUAXej7OWiOBwBrhbg39y0DAAZO8UKDYAAAdUHXiXiWAwBQpfsHGSEBAIgANY8mDwcAR1+AsYNFBgDQLIOvGywKABbX1BvAMgkAjlunw/TsBACIrc9F08AHAFXz3HAgEQQAZOQinP/cBwAlM+Bg2koFAJp2747ZXAIAjJsDbOUEBACKM3iMSx8HACMrvBb8LAYAqtmAEvV8AQBaqSBerrsDAOyqYkd1DQIARbc7x2/DBwDRS3OXx6YEAA6Vs4ok7wgAxz6lyVQxDgDtPG/k8bgKAEP1uTWx/gQArpOtktE7BgD3zRKmLk4EAKuDFZn0cAYAtJCH2oqLAwBd+VHfnEoAALiW1ftj2QUASuWsaJstAgCZxTaIjqkEAKHrLLOuSQAAMXn8dQt9CABJdbrkTG8BAEm+P8DkrAUAnBUqwQ5+CgBmD1MX7pUHAH7+3GM8fQYA7hrIrfASAQBlcYJM8D0FAPAwtDNb/gIAYo0MXmYcBQCBvexSClsCAKnk/JUG3AUAfQR1xSi5AwDlhiZR8zsCAFTcSb8ZzQYAhsOvZSFhBgD/A2KjGhcBAKqoIKguZAoADz8xe7vzCQDjKXQ6G+AFAKOcF1KQYQcA0K/wk2XBAAAodFx5xGUCAEJUXVFAHAMALgu0PQ9SBwChV5PT4wsFALanlNIzqwMAs+1ZunnEBABvMk0YDcMEADzvzMmSEAcAvB0FdKzYAwCt0EP1tgoJAI/aD6zz0A0A4+VzJR3vBQB6E7dbOhcMAIyRZAM/UgAAe4pjbfWHBgAT0IqSlgcCADNPpQWE0wUAVwI9sBXqAACKIfnwMW4FAPgC4YhfYwUAuKVp2cXLAgB6NIvJ+zMFAOOkFFZW/AUAjpiQd+bhAgASSeSai+MJAFNWB7T7SAYAcs1A2PGNCgBl1Al0TCEDAOV6bcQNVwYAbeKRG5+KAQCrQj8YtjYEAJiBT6qsUAUAVMQUxBEnBgBwF2UGdIIBAGXChvJE0QQAgZLu8Ih0AQAMdlzbbJ4BALjsc0CpvgUA+NJD82POCACNNh59qOAJAOmeAbztRQgA0NAo7ZqXDgAaT5SFB60EAOSbyBIJvwUAg4zzyq0vBgAszrOWwV4CAHsBT/9VdgcAYY8UXM2qAwABgzHDNDsGALHQBC3m4AAAAWdyM6J2BgBply0Emp4CACiQHcvwrwMA8jTF9AtDBgBEclDkw2QCAHCSoxmfTAcAR7yZ94Q/BwCZvTL3+cwKAF5AIDrrxwUA+DDZqrX9BQBHjDvmV6cEAFYkl5KUjgIA0kxv6OcQAQDk9QPWntgAAPiKAQQWHgUAGCJK3O64AADQhJOLqRsFAJOWC35VXAAAsA7CibC7BgDungv7Qd8GAG/hh+2HEA0AMKefXNsCCQBgGITw/okCAG9+yR8xzgEAH9u1Pz8CBgCY/Oh1l7QHAEVQv61wrQMAmP54wVThBgC/mtb+NmMBAOz5Kblm8AQAk1tsnv/pBAC6sku8iYwBAMqVKmS/rwYAuagT+XBQDQC7K6yeYWUHAFl09CVSqwsAR1urFO1sBwABuO08CSwJAMHS9WIM3gAAtU9zzwGWBAD28GOCw7UGAAZttfU+YgQAA5UbhUvbAAAPGbgIk38EAIIfYlwjFAQAdloa9F8fAwBtuapzZ3MGADVmnHmoOgMAnmwV/Ij1CABo8KRNQWMDAOqKttlqKQcAQ64WE3HTBABYjRwMzRIKAPJcCL0e9QcA4fXjZ/osAQBq1OPxDIABAKjwX2E3QwUAIY6e8sYzAgCBxxh/ENUEAF4apdNPSgYAN7tIBM30BAAeFUOF03EGABQZkXh32wEAthpw3WlHCQBmtrTxOYMCAHvjikshqwQA/rCg7wpfCgDRF6CoLK4HAG/Ca3w5UgMAvnsioHqKAQCLX+rBjOYFAF8dejo+/gYAKm7SetkaAwBiuSAJ7RcAAP22UzvjhwEAYxR6kClYBQCSp+BI8kEGACJmOsUf7QEALS0JHKZCBgB/0RHnNxkLACFBze1L3AwA3j2LDJ9WCgCheqVk1gMFAG7yiU2O6QEAl/78Fq4QBQB8C85yERcCAII2v+2RUQUAwIvyNiuxBQA3FamQWzkDAENZvvzm+QYAD+rm6i86AgAGHwGVjHEEAB+aXmgGaQMAHXjYTzy+BACJivxqcUIKAHY8v+T0bAkAXjL3k/XSCQBbgATP3FUDAEieabjYDQEAY42P6zpGBwAzwJFuhWAHAFXgjgArzwAAS0cIJxGxBQDbdTzLTZgFAHf5z8r+6gQAe9l+WAZmAQBbxFqc2LIHAORaIntYhAUAw36mZg/BBQAKifgycpkFAIWtEy6GyAoAv+n/p0UqBgAqmEu6J14IAKZXL/FjowMAcsZ9hXdmAwBF11DdbgEGAFQEDKTtdwcAEX24j5HYAwBNhloefaYGAODHEELFGwYAtrqWP6ugBQB1R4iwNe0CAKVkTULz+AcAr4ZIsgdIAgBjT7xfiNgLALMjVT6VFQEAPdIYqdcyCQAOMaDLVecHANFOeSQ2KQYA2mHRHh7tAADDb7gP844AAGcL/35VYgMANTKcBafKAAAjMBp2Uk8EAF8Tzd7SBAEAajiZZmWRBwB+BnojcRgBALNw7ipsUwQAw7nMIfPvCwCbEfcqpIwGAP3iaC5ajAUAh/YvMO7ZAwBJpFwPXaEGAPq3nVkCowEAA9xE+AX+BgCc07o1BsQBAH8p/A3/OAIAR7pBgN+7BwDVqL8J8eEFAMERnjhEPAcAq5NwYyFeAgAbzZyXfb0FAM01QG0gXAUAJXbekK36BwBEYRw5hsIDAEafCC5nKQUAEK7tzIcSDgBw7iI5a80FADc9RLhZgQMAKi6f7NlaBQBtzwrwe3oEAAZgCs4sXAcA6XTNi/x4AgDH6zPWlKkEAAfe9/RGzwUASUSEr1A0AwBwTxj6KRQCAIirkVJhaAQAb+tM1VE4CACH5Wytv1kFAKeItK/kiQMAjKmQVvpCAgCJODUvPlIFANLvpVScCQEANO7y8woeBAAaFNc/71MHAInHWQzu6QYATomlZts2BgDe1NB7blMCAF9TPH60bAUAloQ91DAhBwBZPtF6RMwHALBZVfaMKAUACYjZ8Cm2CgDxIc7hqnwKAOvH8u/rLgkAo8Qn9y/pCAAjRV/IcCwJAJsolwrFyAUAUvZHJVBdBwCu+mOlJNoFAAdjees2CgMAZKlVtQE/BgB/djjlpb0FAEiNGSxh+gAATKaARc1UAwDqtM9JnqoEAGKrFlQWNwQAhq393fuxBQA6vPHOllwHAP4Gtn50AwYAzIwMvLXbCABxufGF6W8EAJpL5jYoCgAAJixOp5IeAgCT2kDVkc0HAKOnkTJCHgEA3cJy3EbqAwCn3+KIhQEFAP5T3eugPwAA0OecldNxAgDsSy8HNacEADL0fcqwiAAAwGz+/lQOBwAMgrKjHHUCAHXuOnyP1gQA+hGHT/1JDADt9QpwVccDAJ2qVHwzRQQAyKT5bcjPBwA6QtthbUYEAErr0Mf2vAEA4RBhVLDVBwCWBcfXljoHABNvPmBfYQcA+eOrXgOHAABqNCMLslYFAHc6S1ZcrgEAOFkCA0ytAQBBm3BLjY8CAJvvT5CKFwoAA+BzgKIxCwCRjRlBpgEKAFuNcD6G5gAAsb9UthSZAAC3lidBdtEBAA90PpgHwwMA8YqBHs/ZBQArWaHiOx0CAHvrgxhXTAUAqm6vLDEJAQBunqS8KpMFAOAfNgwKqgMAk/bfCOVfDACCsnHwwWwFAEpAHxOV3gkAre50kyOgAQAgi3APGeYDAC7vSeEhbgQAzyAtzgBKAAAEgzPCzOIBAE+uOlXYlAAAGg0jnzDuBgB3uGesMq4AACknQdiP6gEAiojotSahAwDYexK6sKUDAB1PNpjeTAYA509stoK5DgBeCLngwxgCAGzQ4j7sVA4Awqs8kZYDCAACQhTMZ5cJAFBkHwfk1gcA4eQ+6sP3AQDa4/TNPqUAAADSfnnCGAQAU7TlgBrEAgBLxZ2O4A8GALegCcPxsgYAvLvLETspAwDtp1iGV/QBABzId3u8kwMAAozNaKhnCwAmNtmtGUcHAE8UWtFKFwwAI/tc9j1LAwDTw5pZtesOAFVHP7dFhgMAN11hcwexAQDUcn3qBQMHAOKditz7MQcATsrQu87ABwC9WWAw2sUEAFNIv8zvrAQAr7eZbFqyBgBnaAIzGEYGAJSpdhGtzgcAIuZNxggeCwBCDCqSca8PAOusHCFIwAYAEw5bm25uBQDQ5E83FrgHAINHVmjbTAYA32ZYgs06AAAdykxMj7sEAJHwyeW/qAIA1xTE13MuAwDMPxEEwRsHAFIKa04Z8QEA9PFwUZB+AQDrOs6Tx7EAAPCWzuNq9QYAprT2huGjAgDvqCavZB4MAH2ZBf7aNAkAMsftuaJ0CACqkvyWvLwKAHOSHoztlgAAp6vL2sJoAACtTX6b3MsDAGrRm8bNiwYAs6/+qSf/BgApYx9hPvcBAIEtyDkQ1QAAxc7A17C4AQDSOgJwqGYEAITibVtaKwcAwzejKEYsCQCN52D0Z2wEAF5yaN7lkAwAQYwB0jWEBgDn/aZ6WkgDACDnaO10lwYAJn6V4n0pAwAmdON3AEUGAK6ctSj+swAAt5cNFqEaBgCOElV/e4oEAKbkssWwugYALS/dMCGCAwC0ePa5WaEAAI3uAwXOxgIAB5tGduYXBwAp0WM8BDwEALMz0AwpSgQAAdxUcIfTCQA4gze1wvgIAIkoY5yx3wIAsFGeSCWFAwAzW3ppSNoDAE22cnfy1AMASSbZ0XrnAAB1XNvyHTACAOPFO6MBFQIAggN1P7V2AgBcdwFwvPoGAI0lx1QezAQAnOE6a9jhCwASF6cXMI8CAJ56DORP0AgA/s/hIsM7BwAtozciTykHAI5jQ3VmwAQAf34fyYkMBwB9mNCb7aYCAKBT1+R6cgEAFHXO/fMuBgD9Pn33F4AAAMttSD4NxwMAdkd7epcJBACnG+fUXlIBAGZW0YeMkgEAKXIIZtVHCABGyRjrslYBAIumtmykOAcAOjDUqitKBQCfSdTBDq4EADAhfrValQQAYaO+nsiyBwD+rb9lsvQCAIR2OgIhGAMAj0V0F7R9BwCnfb6im8sGAHqwug+cAQMAdqwZEv9CBwDJS9JfV4cDADHaYTQbfwEAhihsAz1rCQAzQfOcfNwJAHQd6wLsBQkAyXOs49UmCQA8RD/EgooHAFLOAzSbGQQAybEc4mxPAwCEjbLUnNoFAKK9FrtoEwMAqa0TmrnZAwDEdSZwEoEDAK3A6SiNaAUA50S//7ESBwB7rdOcIsgBALuBvQiStAAAbwcNCvtQBQB/wNod0y0OALQjqyNgAgwANszJsWAkCgBQLdpkCuQLAEFyKC2z3AIAtyaYsJK4BgBd9Ow5YKMFAHl+CdbDkAIAKB8ue+5XAQCfcMqdLqUFAP6yl//neAMAQouUVP64BAB4e9etD1oHAPtVXBF3ogUAQkyF5SHZCABnTzbG+w0HAOzxnLi5SAgAJii3sfG5DgDSLYmR4fQIAMwAgzIVMAIAYlX49LD6BwAd+yHD47YBAKy+FpwndwcA3xerAptoBADtMkHsEhwFAHe4t1YkGwMAgdGHUx7CBQAvykl6wxMDAN2evC5DsgMA3NjHgZeJCADfAoUx5w0JAGetkL4Y2wgAG7EVEdpgCACMMjAT/WELAFkujLfCzAYAd7eSLzgGBwDcZDf0WAIHAPYEmv/G3AUA27IqH1zFBgCGmRVlgQwDAEWa6KH4LgIA5FziEhHoAwBqC7SsWEMCACx7klqEzQMAzFEZLNcGDQBdov4FH70MAMyo79c5bggAI1FYtapWCQB+JMeKmV8MALDTb9+tFQcAouPW6xrPBwCpyAFxGzkAAGmrNauHaAUAkdqg6CFhAwDNPl3FKAcDAIH0ZirNiAEADYVbOzNRAQC5amGj/40BANVm8GwIOwIAfNW9tIBgBgCsMUaXxjAJAI/y9ebwsgQAgJoif6IKAwDxFJChX2wJAF4ZBeoYUQMAbbggLfhGAABFUcfKPEoDAJaEwhl1OgUA6MaIU7seAAA79XLnbkEFAOihEp1zuQAA4z8mQxxYAgCr4ZT+VygAAHOEgfFOhgQAHbjQCzqoBQChGYWGI3cLAK07GdL7VAgAgU2fN3MoCQC79teuA2wKALOaY5cywwcAAt9xGg1kBQAeH9E88IgFAB3EJWAutgcAuk3DwK2nAgDOfRxYL3oGAMOyLTUFCQQAJXrq8JAmBgDcPaVsSKoDAB2elWlRiwcALcxpV1rIBAArf2W66UoHAFT6m9ugGgYAKgvF5Q7aCADRvCQC7FcMAA0YXd9UggEAH6KMOp3/AABUGNR9xDkCAKQalauThAMAHjeQvBQjAACKkCaP/q4AAD1vWqdqvwMAzO5a6DsTAgB1m7zF3SQFAPD8NMVylQcAl5V04ABDCwCGhpiADHIMAJfcfJEmIwIAy1X7SQoOBQAZf24LDIkHAG8tW6M8sgUAcyQ3mCVXBwA2KOwSqFsGAAbEmxmCnwcADraYjd8NBwDEXdf9t0ABAJJ+0wJfCwMADsyOFhLSAgD2GHGsFVUAAKeJHmlpVwQArUOmW9w9BgAhZ20jNz0DAPtzIUJ2ngkAKgg610U8DgDGBWtwD+wCANstWzQF4wMAnGpzXYC9BgAwpx71hVcFAO73rhEBwQYAwQEvI3QLAQDYWY9glBYCAIefj6HH9wMAuDclwlE4AQAVN1soyFMDAPSjJZ361gUAyqajsv5aDACEtcwBvvMAALSzmbZyfgoAC/tlJgOOCwCdfIhB+nQNALtsbuSFQQcA20jKR+QlAAAwp6kYmfQFAPr7+r88vQQA9nX3BOdFBgD6Hone2ikFACUZ+9xFogUAz+k8RFQ4BQAUwawaeZkEAKvKTVcOQgcACUsjlD9uBgAHH4JDaNMEAIftIZdSEQcASdiZpaI6CADbPJz6YLoKADxRNKA4oQYA7L5zOt/oBQCAmD+YkhsFAMaAHFeU6QEAG1grY/ROBADJZNMhHEkGAHq0REmkjAUA7mgXXXIcAADg7Ih6q+cBAF9LxJlIBQcAo3hZE8pNAwC9bhU7KKgBACnAAWCi5wUAuzygY8Y5BwD/tuLONiAFAFnxsiaUmwYAet0qdlBQAwBSgAPARM8DAHd5QMeMcwYA/23FnW1AAgAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvY3VydmUyNTUxOS1kYWxlay0yLjAuMC9zcmMvYmFja2VuZC9zZXJpYWwvdTY0L3NjYWxhci5yc9A1EgB0AAAAKQAAAAoAAADQNRIAdAAAAC8AAAAOAAAA0DUSAHQAAABEAAAAHgAAANA1EgB0AAAAWgAAAB4AAAAAAAAA7eYhZ71IDwBa5GestboDABvlNev//w8A////////DwD//////w8AADvRUull0gkAn6a+FcdjDQAEdmjLZb4FAH8hPcfu3AMAmjB8G0EJAADt0/VcGmMCAIFlzXkv6g0A+d4UAEH97cgAC44BEAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMi4wLjAvc3JjL3NjYWxhci5ycwAAAAA3EgBhAAAAFwEAAAoAAAAAAAAA7dP1XBpjAgCBZc15L+oNAPneFABBne/IAAu0BBAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTIuMC4wL3NyYy93aW5kb3cucnMAAACgNxIAYQAAAH8AAAAJAAAAoDcSAGEAAACqAAAACQAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL3N0ci9wYXR0ZXJuLnJzAAAkOBIASgAAAIIEAAAUAAAAJDgSAEoAAACCBAAAIQAAACQ4EgBKAAAAjgQAABQAAAAkOBIASgAAAI4EAAAhAAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvc2xpY2UvbW9kLnJzsDgSAEgAAAAmCwAACgAAACAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvaG1hYy0wLjcuMC9zcmMvbGliLnJzAAk5EgBSAAAAdgAAABEAAAAJORIAUgAAAHcAAAARAAAACTkSAFIAAACBAAAAKAAAAAk5EgBSAAAAgQAAABEAAAAJORIAUgAAAIIAAAAeAAAACTkSAFIAAACCAAAAEQAAADIAAAAMAAAABAAAADMAAAA0AAAANQBB5PPIAAu5mwE2AAAANwAAADgAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9zbGljZS9tb2QucnPwORIASAAAACYLAAAKAAAASGFzaCB0YWJsZSBjYXBhY2l0eSBvdmVyZmxvdzw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAZDoSAB4AAAACAAAAAgAAAP////85AAAABAAAAAQAAAA6AAAAOwAAADwAAAAEAAAABAAAAD0AAAA+AAAAY2FsbGVkIGBPcHRpb246OnVud3JhcCgpYCBvbiBhIGBOb25lYCB2YWx1ZS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9vbmNlX2NlbGwtMC4xLjgvc3JjL2ltcF9wbC5ycwAAAOs6EgBaAAAAhwAAAAkAAABhYmFuZG9uCmFiaWxpdHkKYWJsZQphYm91dAphYm92ZQphYnNlbnQKYWJzb3JiCmFic3RyYWN0CmFic3VyZAphYnVzZQphY2Nlc3MKYWNjaWRlbnQKYWNjb3VudAphY2N1c2UKYWNoaWV2ZQphY2lkCmFjb3VzdGljCmFjcXVpcmUKYWNyb3NzCmFjdAphY3Rpb24KYWN0b3IKYWN0cmVzcwphY3R1YWwKYWRhcHQKYWRkCmFkZGljdAphZGRyZXNzCmFkanVzdAphZG1pdAphZHVsdAphZHZhbmNlCmFkdmljZQphZXJvYmljCmFmZmFpcgphZmZvcmQKYWZyYWlkCmFnYWluCmFnZQphZ2VudAphZ3JlZQphaGVhZAphaW0KYWlyCmFpcnBvcnQKYWlzbGUKYWxhcm0KYWxidW0KYWxjb2hvbAphbGVydAphbGllbgphbGwKYWxsZXkKYWxsb3cKYWxtb3N0CmFsb25lCmFscGhhCmFscmVhZHkKYWxzbwphbHRlcgphbHdheXMKYW1hdGV1cgphbWF6aW5nCmFtb25nCmFtb3VudAphbXVzZWQKYW5hbHlzdAphbmNob3IKYW5jaWVudAphbmdlcgphbmdsZQphbmdyeQphbmltYWwKYW5rbGUKYW5ub3VuY2UKYW5udWFsCmFub3RoZXIKYW5zd2VyCmFudGVubmEKYW50aXF1ZQphbnhpZXR5CmFueQphcGFydAphcG9sb2d5CmFwcGVhcgphcHBsZQphcHByb3ZlCmFwcmlsCmFyY2gKYXJjdGljCmFyZWEKYXJlbmEKYXJndWUKYXJtCmFybWVkCmFybW9yCmFybXkKYXJvdW5kCmFycmFuZ2UKYXJyZXN0CmFycml2ZQphcnJvdwphcnQKYXJ0ZWZhY3QKYXJ0aXN0CmFydHdvcmsKYXNrCmFzcGVjdAphc3NhdWx0CmFzc2V0CmFzc2lzdAphc3N1bWUKYXN0aG1hCmF0aGxldGUKYXRvbQphdHRhY2sKYXR0ZW5kCmF0dGl0dWRlCmF0dHJhY3QKYXVjdGlvbgphdWRpdAphdWd1c3QKYXVudAphdXRob3IKYXV0bwphdXR1bW4KYXZlcmFnZQphdm9jYWRvCmF2b2lkCmF3YWtlCmF3YXJlCmF3YXkKYXdlc29tZQphd2Z1bAphd2t3YXJkCmF4aXMKYmFieQpiYWNoZWxvcgpiYWNvbgpiYWRnZQpiYWcKYmFsYW5jZQpiYWxjb255CmJhbGwKYmFtYm9vCmJhbmFuYQpiYW5uZXIKYmFyCmJhcmVseQpiYXJnYWluCmJhcnJlbApiYXNlCmJhc2ljCmJhc2tldApiYXR0bGUKYmVhY2gKYmVhbgpiZWF1dHkKYmVjYXVzZQpiZWNvbWUKYmVlZgpiZWZvcmUKYmVnaW4KYmVoYXZlCmJlaGluZApiZWxpZXZlCmJlbG93CmJlbHQKYmVuY2gKYmVuZWZpdApiZXN0CmJldHJheQpiZXR0ZXIKYmV0d2VlbgpiZXlvbmQKYmljeWNsZQpiaWQKYmlrZQpiaW5kCmJpb2xvZ3kKYmlyZApiaXJ0aApiaXR0ZXIKYmxhY2sKYmxhZGUKYmxhbWUKYmxhbmtldApibGFzdApibGVhawpibGVzcwpibGluZApibG9vZApibG9zc29tCmJsb3VzZQpibHVlCmJsdXIKYmx1c2gKYm9hcmQKYm9hdApib2R5CmJvaWwKYm9tYgpib25lCmJvbnVzCmJvb2sKYm9vc3QKYm9yZGVyCmJvcmluZwpib3Jyb3cKYm9zcwpib3R0b20KYm91bmNlCmJveApib3kKYnJhY2tldApicmFpbgpicmFuZApicmFzcwpicmF2ZQpicmVhZApicmVlemUKYnJpY2sKYnJpZGdlCmJyaWVmCmJyaWdodApicmluZwpicmlzawpicm9jY29saQpicm9rZW4KYnJvbnplCmJyb29tCmJyb3RoZXIKYnJvd24KYnJ1c2gKYnViYmxlCmJ1ZGR5CmJ1ZGdldApidWZmYWxvCmJ1aWxkCmJ1bGIKYnVsawpidWxsZXQKYnVuZGxlCmJ1bmtlcgpidXJkZW4KYnVyZ2VyCmJ1cnN0CmJ1cwpidXNpbmVzcwpidXN5CmJ1dHRlcgpidXllcgpidXp6CmNhYmJhZ2UKY2FiaW4KY2FibGUKY2FjdHVzCmNhZ2UKY2FrZQpjYWxsCmNhbG0KY2FtZXJhCmNhbXAKY2FuCmNhbmFsCmNhbmNlbApjYW5keQpjYW5ub24KY2Fub2UKY2FudmFzCmNhbnlvbgpjYXBhYmxlCmNhcGl0YWwKY2FwdGFpbgpjYXIKY2FyYm9uCmNhcmQKY2FyZ28KY2FycGV0CmNhcnJ5CmNhcnQKY2FzZQpjYXNoCmNhc2lubwpjYXN0bGUKY2FzdWFsCmNhdApjYXRhbG9nCmNhdGNoCmNhdGVnb3J5CmNhdHRsZQpjYXVnaHQKY2F1c2UKY2F1dGlvbgpjYXZlCmNlaWxpbmcKY2VsZXJ5CmNlbWVudApjZW5zdXMKY2VudHVyeQpjZXJlYWwKY2VydGFpbgpjaGFpcgpjaGFsawpjaGFtcGlvbgpjaGFuZ2UKY2hhb3MKY2hhcHRlcgpjaGFyZ2UKY2hhc2UKY2hhdApjaGVhcApjaGVjawpjaGVlc2UKY2hlZgpjaGVycnkKY2hlc3QKY2hpY2tlbgpjaGllZgpjaGlsZApjaGltbmV5CmNob2ljZQpjaG9vc2UKY2hyb25pYwpjaHVja2xlCmNodW5rCmNodXJuCmNpZ2FyCmNpbm5hbW9uCmNpcmNsZQpjaXRpemVuCmNpdHkKY2l2aWwKY2xhaW0KY2xhcApjbGFyaWZ5CmNsYXcKY2xheQpjbGVhbgpjbGVyawpjbGV2ZXIKY2xpY2sKY2xpZW50CmNsaWZmCmNsaW1iCmNsaW5pYwpjbGlwCmNsb2NrCmNsb2cKY2xvc2UKY2xvdGgKY2xvdWQKY2xvd24KY2x1YgpjbHVtcApjbHVzdGVyCmNsdXRjaApjb2FjaApjb2FzdApjb2NvbnV0CmNvZGUKY29mZmVlCmNvaWwKY29pbgpjb2xsZWN0CmNvbG9yCmNvbHVtbgpjb21iaW5lCmNvbWUKY29tZm9ydApjb21pYwpjb21tb24KY29tcGFueQpjb25jZXJ0CmNvbmR1Y3QKY29uZmlybQpjb25ncmVzcwpjb25uZWN0CmNvbnNpZGVyCmNvbnRyb2wKY29udmluY2UKY29vawpjb29sCmNvcHBlcgpjb3B5CmNvcmFsCmNvcmUKY29ybgpjb3JyZWN0CmNvc3QKY290dG9uCmNvdWNoCmNvdW50cnkKY291cGxlCmNvdXJzZQpjb3VzaW4KY292ZXIKY295b3RlCmNyYWNrCmNyYWRsZQpjcmFmdApjcmFtCmNyYW5lCmNyYXNoCmNyYXRlcgpjcmF3bApjcmF6eQpjcmVhbQpjcmVkaXQKY3JlZWsKY3Jldwpjcmlja2V0CmNyaW1lCmNyaXNwCmNyaXRpYwpjcm9wCmNyb3NzCmNyb3VjaApjcm93ZApjcnVjaWFsCmNydWVsCmNydWlzZQpjcnVtYmxlCmNydW5jaApjcnVzaApjcnkKY3J5c3RhbApjdWJlCmN1bHR1cmUKY3VwCmN1cGJvYXJkCmN1cmlvdXMKY3VycmVudApjdXJ0YWluCmN1cnZlCmN1c2hpb24KY3VzdG9tCmN1dGUKY3ljbGUKZGFkCmRhbWFnZQpkYW1wCmRhbmNlCmRhbmdlcgpkYXJpbmcKZGFzaApkYXVnaHRlcgpkYXduCmRheQpkZWFsCmRlYmF0ZQpkZWJyaXMKZGVjYWRlCmRlY2VtYmVyCmRlY2lkZQpkZWNsaW5lCmRlY29yYXRlCmRlY3JlYXNlCmRlZXIKZGVmZW5zZQpkZWZpbmUKZGVmeQpkZWdyZWUKZGVsYXkKZGVsaXZlcgpkZW1hbmQKZGVtaXNlCmRlbmlhbApkZW50aXN0CmRlbnkKZGVwYXJ0CmRlcGVuZApkZXBvc2l0CmRlcHRoCmRlcHV0eQpkZXJpdmUKZGVzY3JpYmUKZGVzZXJ0CmRlc2lnbgpkZXNrCmRlc3BhaXIKZGVzdHJveQpkZXRhaWwKZGV0ZWN0CmRldmVsb3AKZGV2aWNlCmRldm90ZQpkaWFncmFtCmRpYWwKZGlhbW9uZApkaWFyeQpkaWNlCmRpZXNlbApkaWV0CmRpZmZlcgpkaWdpdGFsCmRpZ25pdHkKZGlsZW1tYQpkaW5uZXIKZGlub3NhdXIKZGlyZWN0CmRpcnQKZGlzYWdyZWUKZGlzY292ZXIKZGlzZWFzZQpkaXNoCmRpc21pc3MKZGlzb3JkZXIKZGlzcGxheQpkaXN0YW5jZQpkaXZlcnQKZGl2aWRlCmRpdm9yY2UKZGl6enkKZG9jdG9yCmRvY3VtZW50CmRvZwpkb2xsCmRvbHBoaW4KZG9tYWluCmRvbmF0ZQpkb25rZXkKZG9ub3IKZG9vcgpkb3NlCmRvdWJsZQpkb3ZlCmRyYWZ0CmRyYWdvbgpkcmFtYQpkcmFzdGljCmRyYXcKZHJlYW0KZHJlc3MKZHJpZnQKZHJpbGwKZHJpbmsKZHJpcApkcml2ZQpkcm9wCmRydW0KZHJ5CmR1Y2sKZHVtYgpkdW5lCmR1cmluZwpkdXN0CmR1dGNoCmR1dHkKZHdhcmYKZHluYW1pYwplYWdlcgplYWdsZQplYXJseQplYXJuCmVhcnRoCmVhc2lseQplYXN0CmVhc3kKZWNobwplY29sb2d5CmVjb25vbXkKZWRnZQplZGl0CmVkdWNhdGUKZWZmb3J0CmVnZwplaWdodAplaXRoZXIKZWxib3cKZWxkZXIKZWxlY3RyaWMKZWxlZ2FudAplbGVtZW50CmVsZXBoYW50CmVsZXZhdG9yCmVsaXRlCmVsc2UKZW1iYXJrCmVtYm9keQplbWJyYWNlCmVtZXJnZQplbW90aW9uCmVtcGxveQplbXBvd2VyCmVtcHR5CmVuYWJsZQplbmFjdAplbmQKZW5kbGVzcwplbmRvcnNlCmVuZW15CmVuZXJneQplbmZvcmNlCmVuZ2FnZQplbmdpbmUKZW5oYW5jZQplbmpveQplbmxpc3QKZW5vdWdoCmVucmljaAplbnJvbGwKZW5zdXJlCmVudGVyCmVudGlyZQplbnRyeQplbnZlbG9wZQplcGlzb2RlCmVxdWFsCmVxdWlwCmVyYQplcmFzZQplcm9kZQplcm9zaW9uCmVycm9yCmVydXB0CmVzY2FwZQplc3NheQplc3NlbmNlCmVzdGF0ZQpldGVybmFsCmV0aGljcwpldmlkZW5jZQpldmlsCmV2b2tlCmV2b2x2ZQpleGFjdApleGFtcGxlCmV4Y2VzcwpleGNoYW5nZQpleGNpdGUKZXhjbHVkZQpleGN1c2UKZXhlY3V0ZQpleGVyY2lzZQpleGhhdXN0CmV4aGliaXQKZXhpbGUKZXhpc3QKZXhpdApleG90aWMKZXhwYW5kCmV4cGVjdApleHBpcmUKZXhwbGFpbgpleHBvc2UKZXhwcmVzcwpleHRlbmQKZXh0cmEKZXllCmV5ZWJyb3cKZmFicmljCmZhY2UKZmFjdWx0eQpmYWRlCmZhaW50CmZhaXRoCmZhbGwKZmFsc2UKZmFtZQpmYW1pbHkKZmFtb3VzCmZhbgpmYW5jeQpmYW50YXN5CmZhcm0KZmFzaGlvbgpmYXQKZmF0YWwKZmF0aGVyCmZhdGlndWUKZmF1bHQKZmF2b3JpdGUKZmVhdHVyZQpmZWJydWFyeQpmZWRlcmFsCmZlZQpmZWVkCmZlZWwKZmVtYWxlCmZlbmNlCmZlc3RpdmFsCmZldGNoCmZldmVyCmZldwpmaWJlcgpmaWN0aW9uCmZpZWxkCmZpZ3VyZQpmaWxlCmZpbG0KZmlsdGVyCmZpbmFsCmZpbmQKZmluZQpmaW5nZXIKZmluaXNoCmZpcmUKZmlybQpmaXJzdApmaXNjYWwKZmlzaApmaXQKZml0bmVzcwpmaXgKZmxhZwpmbGFtZQpmbGFzaApmbGF0CmZsYXZvcgpmbGVlCmZsaWdodApmbGlwCmZsb2F0CmZsb2NrCmZsb29yCmZsb3dlcgpmbHVpZApmbHVzaApmbHkKZm9hbQpmb2N1cwpmb2cKZm9pbApmb2xkCmZvbGxvdwpmb29kCmZvb3QKZm9yY2UKZm9yZXN0CmZvcmdldApmb3JrCmZvcnR1bmUKZm9ydW0KZm9yd2FyZApmb3NzaWwKZm9zdGVyCmZvdW5kCmZveApmcmFnaWxlCmZyYW1lCmZyZXF1ZW50CmZyZXNoCmZyaWVuZApmcmluZ2UKZnJvZwpmcm9udApmcm9zdApmcm93bgpmcm96ZW4KZnJ1aXQKZnVlbApmdW4KZnVubnkKZnVybmFjZQpmdXJ5CmZ1dHVyZQpnYWRnZXQKZ2FpbgpnYWxheHkKZ2FsbGVyeQpnYW1lCmdhcApnYXJhZ2UKZ2FyYmFnZQpnYXJkZW4KZ2FybGljCmdhcm1lbnQKZ2FzCmdhc3AKZ2F0ZQpnYXRoZXIKZ2F1Z2UKZ2F6ZQpnZW5lcmFsCmdlbml1cwpnZW5yZQpnZW50bGUKZ2VudWluZQpnZXN0dXJlCmdob3N0CmdpYW50CmdpZnQKZ2lnZ2xlCmdpbmdlcgpnaXJhZmZlCmdpcmwKZ2l2ZQpnbGFkCmdsYW5jZQpnbGFyZQpnbGFzcwpnbGlkZQpnbGltcHNlCmdsb2JlCmdsb29tCmdsb3J5Cmdsb3ZlCmdsb3cKZ2x1ZQpnb2F0CmdvZGRlc3MKZ29sZApnb29kCmdvb3NlCmdvcmlsbGEKZ29zcGVsCmdvc3NpcApnb3Zlcm4KZ293bgpncmFiCmdyYWNlCmdyYWluCmdyYW50CmdyYXBlCmdyYXNzCmdyYXZpdHkKZ3JlYXQKZ3JlZW4KZ3JpZApncmllZgpncml0Cmdyb2NlcnkKZ3JvdXAKZ3JvdwpncnVudApndWFyZApndWVzcwpndWlkZQpndWlsdApndWl0YXIKZ3VuCmd5bQpoYWJpdApoYWlyCmhhbGYKaGFtbWVyCmhhbXN0ZXIKaGFuZApoYXBweQpoYXJib3IKaGFyZApoYXJzaApoYXJ2ZXN0CmhhdApoYXZlCmhhd2sKaGF6YXJkCmhlYWQKaGVhbHRoCmhlYXJ0CmhlYXZ5CmhlZGdlaG9nCmhlaWdodApoZWxsbwpoZWxtZXQKaGVscApoZW4KaGVybwpoaWRkZW4KaGlnaApoaWxsCmhpbnQKaGlwCmhpcmUKaGlzdG9yeQpob2JieQpob2NrZXkKaG9sZApob2xlCmhvbGlkYXkKaG9sbG93CmhvbWUKaG9uZXkKaG9vZApob3BlCmhvcm4KaG9ycm9yCmhvcnNlCmhvc3BpdGFsCmhvc3QKaG90ZWwKaG91cgpob3ZlcgpodWIKaHVnZQpodW1hbgpodW1ibGUKaHVtb3IKaHVuZHJlZApodW5ncnkKaHVudApodXJkbGUKaHVycnkKaHVydApodXNiYW5kCmh5YnJpZAppY2UKaWNvbgppZGVhCmlkZW50aWZ5CmlkbGUKaWdub3JlCmlsbAppbGxlZ2FsCmlsbG5lc3MKaW1hZ2UKaW1pdGF0ZQppbW1lbnNlCmltbXVuZQppbXBhY3QKaW1wb3NlCmltcHJvdmUKaW1wdWxzZQppbmNoCmluY2x1ZGUKaW5jb21lCmluY3JlYXNlCmluZGV4CmluZGljYXRlCmluZG9vcgppbmR1c3RyeQppbmZhbnQKaW5mbGljdAppbmZvcm0KaW5oYWxlCmluaGVyaXQKaW5pdGlhbAppbmplY3QKaW5qdXJ5CmlubWF0ZQppbm5lcgppbm5vY2VudAppbnB1dAppbnF1aXJ5Cmluc2FuZQppbnNlY3QKaW5zaWRlCmluc3BpcmUKaW5zdGFsbAppbnRhY3QKaW50ZXJlc3QKaW50bwppbnZlc3QKaW52aXRlCmludm9sdmUKaXJvbgppc2xhbmQKaXNvbGF0ZQppc3N1ZQppdGVtCml2b3J5CmphY2tldApqYWd1YXIKamFyCmphenoKamVhbG91cwpqZWFucwpqZWxseQpqZXdlbApqb2IKam9pbgpqb2tlCmpvdXJuZXkKam95Cmp1ZGdlCmp1aWNlCmp1bXAKanVuZ2xlCmp1bmlvcgpqdW5rCmp1c3QKa2FuZ2Fyb28Ka2VlbgprZWVwCmtldGNodXAKa2V5CmtpY2sKa2lkCmtpZG5leQpraW5kCmtpbmdkb20Ka2lzcwpraXQKa2l0Y2hlbgpraXRlCmtpdHRlbgpraXdpCmtuZWUKa25pZmUKa25vY2sKa25vdwpsYWIKbGFiZWwKbGFib3IKbGFkZGVyCmxhZHkKbGFrZQpsYW1wCmxhbmd1YWdlCmxhcHRvcApsYXJnZQpsYXRlcgpsYXRpbgpsYXVnaApsYXVuZHJ5CmxhdmEKbGF3Cmxhd24KbGF3c3VpdApsYXllcgpsYXp5CmxlYWRlcgpsZWFmCmxlYXJuCmxlYXZlCmxlY3R1cmUKbGVmdApsZWcKbGVnYWwKbGVnZW5kCmxlaXN1cmUKbGVtb24KbGVuZApsZW5ndGgKbGVucwpsZW9wYXJkCmxlc3NvbgpsZXR0ZXIKbGV2ZWwKbGlhcgpsaWJlcnR5CmxpYnJhcnkKbGljZW5zZQpsaWZlCmxpZnQKbGlnaHQKbGlrZQpsaW1iCmxpbWl0CmxpbmsKbGlvbgpsaXF1aWQKbGlzdApsaXR0bGUKbGl2ZQpsaXphcmQKbG9hZApsb2FuCmxvYnN0ZXIKbG9jYWwKbG9jawpsb2dpYwpsb25lbHkKbG9uZwpsb29wCmxvdHRlcnkKbG91ZApsb3VuZ2UKbG92ZQpsb3lhbApsdWNreQpsdWdnYWdlCmx1bWJlcgpsdW5hcgpsdW5jaApsdXh1cnkKbHlyaWNzCm1hY2hpbmUKbWFkCm1hZ2ljCm1hZ25ldAptYWlkCm1haWwKbWFpbgptYWpvcgptYWtlCm1hbW1hbAptYW4KbWFuYWdlCm1hbmRhdGUKbWFuZ28KbWFuc2lvbgptYW51YWwKbWFwbGUKbWFyYmxlCm1hcmNoCm1hcmdpbgptYXJpbmUKbWFya2V0Cm1hcnJpYWdlCm1hc2sKbWFzcwptYXN0ZXIKbWF0Y2gKbWF0ZXJpYWwKbWF0aAptYXRyaXgKbWF0dGVyCm1heGltdW0KbWF6ZQptZWFkb3cKbWVhbgptZWFzdXJlCm1lYXQKbWVjaGFuaWMKbWVkYWwKbWVkaWEKbWVsb2R5Cm1lbHQKbWVtYmVyCm1lbW9yeQptZW50aW9uCm1lbnUKbWVyY3kKbWVyZ2UKbWVyaXQKbWVycnkKbWVzaAptZXNzYWdlCm1ldGFsCm1ldGhvZAptaWRkbGUKbWlkbmlnaHQKbWlsawptaWxsaW9uCm1pbWljCm1pbmQKbWluaW11bQptaW5vcgptaW51dGUKbWlyYWNsZQptaXJyb3IKbWlzZXJ5Cm1pc3MKbWlzdGFrZQptaXgKbWl4ZWQKbWl4dHVyZQptb2JpbGUKbW9kZWwKbW9kaWZ5Cm1vbQptb21lbnQKbW9uaXRvcgptb25rZXkKbW9uc3Rlcgptb250aAptb29uCm1vcmFsCm1vcmUKbW9ybmluZwptb3NxdWl0bwptb3RoZXIKbW90aW9uCm1vdG9yCm1vdW50YWluCm1vdXNlCm1vdmUKbW92aWUKbXVjaAptdWZmaW4KbXVsZQptdWx0aXBseQptdXNjbGUKbXVzZXVtCm11c2hyb29tCm11c2ljCm11c3QKbXV0dWFsCm15c2VsZgpteXN0ZXJ5Cm15dGgKbmFpdmUKbmFtZQpuYXBraW4KbmFycm93Cm5hc3R5Cm5hdGlvbgpuYXR1cmUKbmVhcgpuZWNrCm5lZWQKbmVnYXRpdmUKbmVnbGVjdApuZWl0aGVyCm5lcGhldwpuZXJ2ZQpuZXN0Cm5ldApuZXR3b3JrCm5ldXRyYWwKbmV2ZXIKbmV3cwpuZXh0Cm5pY2UKbmlnaHQKbm9ibGUKbm9pc2UKbm9taW5lZQpub29kbGUKbm9ybWFsCm5vcnRoCm5vc2UKbm90YWJsZQpub3RlCm5vdGhpbmcKbm90aWNlCm5vdmVsCm5vdwpudWNsZWFyCm51bWJlcgpudXJzZQpudXQKb2FrCm9iZXkKb2JqZWN0Cm9ibGlnZQpvYnNjdXJlCm9ic2VydmUKb2J0YWluCm9idmlvdXMKb2NjdXIKb2NlYW4Kb2N0b2JlcgpvZG9yCm9mZgpvZmZlcgpvZmZpY2UKb2Z0ZW4Kb2lsCm9rYXkKb2xkCm9saXZlCm9seW1waWMKb21pdApvbmNlCm9uZQpvbmlvbgpvbmxpbmUKb25seQpvcGVuCm9wZXJhCm9waW5pb24Kb3Bwb3NlCm9wdGlvbgpvcmFuZ2UKb3JiaXQKb3JjaGFyZApvcmRlcgpvcmRpbmFyeQpvcmdhbgpvcmllbnQKb3JpZ2luYWwKb3JwaGFuCm9zdHJpY2gKb3RoZXIKb3V0ZG9vcgpvdXRlcgpvdXRwdXQKb3V0c2lkZQpvdmFsCm92ZW4Kb3Zlcgpvd24Kb3duZXIKb3h5Z2VuCm95c3Rlcgpvem9uZQpwYWN0CnBhZGRsZQpwYWdlCnBhaXIKcGFsYWNlCnBhbG0KcGFuZGEKcGFuZWwKcGFuaWMKcGFudGhlcgpwYXBlcgpwYXJhZGUKcGFyZW50CnBhcmsKcGFycm90CnBhcnR5CnBhc3MKcGF0Y2gKcGF0aApwYXRpZW50CnBhdHJvbApwYXR0ZXJuCnBhdXNlCnBhdmUKcGF5bWVudApwZWFjZQpwZWFudXQKcGVhcgpwZWFzYW50CnBlbGljYW4KcGVuCnBlbmFsdHkKcGVuY2lsCnBlb3BsZQpwZXBwZXIKcGVyZmVjdApwZXJtaXQKcGVyc29uCnBldApwaG9uZQpwaG90bwpwaHJhc2UKcGh5c2ljYWwKcGlhbm8KcGljbmljCnBpY3R1cmUKcGllY2UKcGlnCnBpZ2VvbgpwaWxsCnBpbG90CnBpbmsKcGlvbmVlcgpwaXBlCnBpc3RvbApwaXRjaApwaXp6YQpwbGFjZQpwbGFuZXQKcGxhc3RpYwpwbGF0ZQpwbGF5CnBsZWFzZQpwbGVkZ2UKcGx1Y2sKcGx1ZwpwbHVuZ2UKcG9lbQpwb2V0CnBvaW50CnBvbGFyCnBvbGUKcG9saWNlCnBvbmQKcG9ueQpwb29sCnBvcHVsYXIKcG9ydGlvbgpwb3NpdGlvbgpwb3NzaWJsZQpwb3N0CnBvdGF0bwpwb3R0ZXJ5CnBvdmVydHkKcG93ZGVyCnBvd2VyCnByYWN0aWNlCnByYWlzZQpwcmVkaWN0CnByZWZlcgpwcmVwYXJlCnByZXNlbnQKcHJldHR5CnByZXZlbnQKcHJpY2UKcHJpZGUKcHJpbWFyeQpwcmludApwcmlvcml0eQpwcmlzb24KcHJpdmF0ZQpwcml6ZQpwcm9ibGVtCnByb2Nlc3MKcHJvZHVjZQpwcm9maXQKcHJvZ3JhbQpwcm9qZWN0CnByb21vdGUKcHJvb2YKcHJvcGVydHkKcHJvc3Blcgpwcm90ZWN0CnByb3VkCnByb3ZpZGUKcHVibGljCnB1ZGRpbmcKcHVsbApwdWxwCnB1bHNlCnB1bXBraW4KcHVuY2gKcHVwaWwKcHVwcHkKcHVyY2hhc2UKcHVyaXR5CnB1cnBvc2UKcHVyc2UKcHVzaApwdXQKcHV6emxlCnB5cmFtaWQKcXVhbGl0eQpxdWFudHVtCnF1YXJ0ZXIKcXVlc3Rpb24KcXVpY2sKcXVpdApxdWl6CnF1b3RlCnJhYmJpdApyYWNjb29uCnJhY2UKcmFjawpyYWRhcgpyYWRpbwpyYWlsCnJhaW4KcmFpc2UKcmFsbHkKcmFtcApyYW5jaApyYW5kb20KcmFuZ2UKcmFwaWQKcmFyZQpyYXRlCnJhdGhlcgpyYXZlbgpyYXcKcmF6b3IKcmVhZHkKcmVhbApyZWFzb24KcmViZWwKcmVidWlsZApyZWNhbGwKcmVjZWl2ZQpyZWNpcGUKcmVjb3JkCnJlY3ljbGUKcmVkdWNlCnJlZmxlY3QKcmVmb3JtCnJlZnVzZQpyZWdpb24KcmVncmV0CnJlZ3VsYXIKcmVqZWN0CnJlbGF4CnJlbGVhc2UKcmVsaWVmCnJlbHkKcmVtYWluCnJlbWVtYmVyCnJlbWluZApyZW1vdmUKcmVuZGVyCnJlbmV3CnJlbnQKcmVvcGVuCnJlcGFpcgpyZXBlYXQKcmVwbGFjZQpyZXBvcnQKcmVxdWlyZQpyZXNjdWUKcmVzZW1ibGUKcmVzaXN0CnJlc291cmNlCnJlc3BvbnNlCnJlc3VsdApyZXRpcmUKcmV0cmVhdApyZXR1cm4KcmV1bmlvbgpyZXZlYWwKcmV2aWV3CnJld2FyZApyaHl0aG0KcmliCnJpYmJvbgpyaWNlCnJpY2gKcmlkZQpyaWRnZQpyaWZsZQpyaWdodApyaWdpZApyaW5nCnJpb3QKcmlwcGxlCnJpc2sKcml0dWFsCnJpdmFsCnJpdmVyCnJvYWQKcm9hc3QKcm9ib3QKcm9idXN0CnJvY2tldApyb21hbmNlCnJvb2YKcm9va2llCnJvb20Kcm9zZQpyb3RhdGUKcm91Z2gKcm91bmQKcm91dGUKcm95YWwKcnViYmVyCnJ1ZGUKcnVnCnJ1bGUKcnVuCnJ1bndheQpydXJhbApzYWQKc2FkZGxlCnNhZG5lc3MKc2FmZQpzYWlsCnNhbGFkCnNhbG1vbgpzYWxvbgpzYWx0CnNhbHV0ZQpzYW1lCnNhbXBsZQpzYW5kCnNhdGlzZnkKc2F0b3NoaQpzYXVjZQpzYXVzYWdlCnNhdmUKc2F5CnNjYWxlCnNjYW4Kc2NhcmUKc2NhdHRlcgpzY2VuZQpzY2hlbWUKc2Nob29sCnNjaWVuY2UKc2Npc3NvcnMKc2NvcnBpb24Kc2NvdXQKc2NyYXAKc2NyZWVuCnNjcmlwdApzY3J1YgpzZWEKc2VhcmNoCnNlYXNvbgpzZWF0CnNlY29uZApzZWNyZXQKc2VjdGlvbgpzZWN1cml0eQpzZWVkCnNlZWsKc2VnbWVudApzZWxlY3QKc2VsbApzZW1pbmFyCnNlbmlvcgpzZW5zZQpzZW50ZW5jZQpzZXJpZXMKc2VydmljZQpzZXNzaW9uCnNldHRsZQpzZXR1cApzZXZlbgpzaGFkb3cKc2hhZnQKc2hhbGxvdwpzaGFyZQpzaGVkCnNoZWxsCnNoZXJpZmYKc2hpZWxkCnNoaWZ0CnNoaW5lCnNoaXAKc2hpdmVyCnNob2NrCnNob2UKc2hvb3QKc2hvcApzaG9ydApzaG91bGRlcgpzaG92ZQpzaHJpbXAKc2hydWcKc2h1ZmZsZQpzaHkKc2libGluZwpzaWNrCnNpZGUKc2llZ2UKc2lnaHQKc2lnbgpzaWxlbnQKc2lsawpzaWxseQpzaWx2ZXIKc2ltaWxhcgpzaW1wbGUKc2luY2UKc2luZwpzaXJlbgpzaXN0ZXIKc2l0dWF0ZQpzaXgKc2l6ZQpza2F0ZQpza2V0Y2gKc2tpCnNraWxsCnNraW4Kc2tpcnQKc2t1bGwKc2xhYgpzbGFtCnNsZWVwCnNsZW5kZXIKc2xpY2UKc2xpZGUKc2xpZ2h0CnNsaW0Kc2xvZ2FuCnNsb3QKc2xvdwpzbHVzaApzbWFsbApzbWFydApzbWlsZQpzbW9rZQpzbW9vdGgKc25hY2sKc25ha2UKc25hcApzbmlmZgpzbm93CnNvYXAKc29jY2VyCnNvY2lhbApzb2NrCnNvZGEKc29mdApzb2xhcgpzb2xkaWVyCnNvbGlkCnNvbHV0aW9uCnNvbHZlCnNvbWVvbmUKc29uZwpzb29uCnNvcnJ5CnNvcnQKc291bApzb3VuZApzb3VwCnNvdXJjZQpzb3V0aApzcGFjZQpzcGFyZQpzcGF0aWFsCnNwYXduCnNwZWFrCnNwZWNpYWwKc3BlZWQKc3BlbGwKc3BlbmQKc3BoZXJlCnNwaWNlCnNwaWRlcgpzcGlrZQpzcGluCnNwaXJpdApzcGxpdApzcG9pbApzcG9uc29yCnNwb29uCnNwb3J0CnNwb3QKc3ByYXkKc3ByZWFkCnNwcmluZwpzcHkKc3F1YXJlCnNxdWVlemUKc3F1aXJyZWwKc3RhYmxlCnN0YWRpdW0Kc3RhZmYKc3RhZ2UKc3RhaXJzCnN0YW1wCnN0YW5kCnN0YXJ0CnN0YXRlCnN0YXkKc3RlYWsKc3RlZWwKc3RlbQpzdGVwCnN0ZXJlbwpzdGljawpzdGlsbApzdGluZwpzdG9jawpzdG9tYWNoCnN0b25lCnN0b29sCnN0b3J5CnN0b3ZlCnN0cmF0ZWd5CnN0cmVldApzdHJpa2UKc3Ryb25nCnN0cnVnZ2xlCnN0dWRlbnQKc3R1ZmYKc3R1bWJsZQpzdHlsZQpzdWJqZWN0CnN1Ym1pdApzdWJ3YXkKc3VjY2VzcwpzdWNoCnN1ZGRlbgpzdWZmZXIKc3VnYXIKc3VnZ2VzdApzdWl0CnN1bW1lcgpzdW4Kc3VubnkKc3Vuc2V0CnN1cGVyCnN1cHBseQpzdXByZW1lCnN1cmUKc3VyZmFjZQpzdXJnZQpzdXJwcmlzZQpzdXJyb3VuZApzdXJ2ZXkKc3VzcGVjdApzdXN0YWluCnN3YWxsb3cKc3dhbXAKc3dhcApzd2FybQpzd2Vhcgpzd2VldApzd2lmdApzd2ltCnN3aW5nCnN3aXRjaApzd29yZApzeW1ib2wKc3ltcHRvbQpzeXJ1cApzeXN0ZW0KdGFibGUKdGFja2xlCnRhZwp0YWlsCnRhbGVudAp0YWxrCnRhbmsKdGFwZQp0YXJnZXQKdGFzawp0YXN0ZQp0YXR0b28KdGF4aQp0ZWFjaAp0ZWFtCnRlbGwKdGVuCnRlbmFudAp0ZW5uaXMKdGVudAp0ZXJtCnRlc3QKdGV4dAp0aGFuawp0aGF0CnRoZW1lCnRoZW4KdGhlb3J5CnRoZXJlCnRoZXkKdGhpbmcKdGhpcwp0aG91Z2h0CnRocmVlCnRocml2ZQp0aHJvdwp0aHVtYgp0aHVuZGVyCnRpY2tldAp0aWRlCnRpZ2VyCnRpbHQKdGltYmVyCnRpbWUKdGlueQp0aXAKdGlyZWQKdGlzc3VlCnRpdGxlCnRvYXN0CnRvYmFjY28KdG9kYXkKdG9kZGxlcgp0b2UKdG9nZXRoZXIKdG9pbGV0CnRva2VuCnRvbWF0bwp0b21vcnJvdwp0b25lCnRvbmd1ZQp0b25pZ2h0CnRvb2wKdG9vdGgKdG9wCnRvcGljCnRvcHBsZQp0b3JjaAp0b3JuYWRvCnRvcnRvaXNlCnRvc3MKdG90YWwKdG91cmlzdAp0b3dhcmQKdG93ZXIKdG93bgp0b3kKdHJhY2sKdHJhZGUKdHJhZmZpYwp0cmFnaWMKdHJhaW4KdHJhbnNmZXIKdHJhcAp0cmFzaAp0cmF2ZWwKdHJheQp0cmVhdAp0cmVlCnRyZW5kCnRyaWFsCnRyaWJlCnRyaWNrCnRyaWdnZXIKdHJpbQp0cmlwCnRyb3BoeQp0cm91YmxlCnRydWNrCnRydWUKdHJ1bHkKdHJ1bXBldAp0cnVzdAp0cnV0aAp0cnkKdHViZQp0dWl0aW9uCnR1bWJsZQp0dW5hCnR1bm5lbAp0dXJrZXkKdHVybgp0dXJ0bGUKdHdlbHZlCnR3ZW50eQp0d2ljZQp0d2luCnR3aXN0CnR3bwp0eXBlCnR5cGljYWwKdWdseQp1bWJyZWxsYQp1bmFibGUKdW5hd2FyZQp1bmNsZQp1bmNvdmVyCnVuZGVyCnVuZG8KdW5mYWlyCnVuZm9sZAp1bmhhcHB5CnVuaWZvcm0KdW5pcXVlCnVuaXQKdW5pdmVyc2UKdW5rbm93bgp1bmxvY2sKdW50aWwKdW51c3VhbAp1bnZlaWwKdXBkYXRlCnVwZ3JhZGUKdXBob2xkCnVwb24KdXBwZXIKdXBzZXQKdXJiYW4KdXJnZQp1c2FnZQp1c2UKdXNlZAp1c2VmdWwKdXNlbGVzcwp1c3VhbAp1dGlsaXR5CnZhY2FudAp2YWN1dW0KdmFndWUKdmFsaWQKdmFsbGV5CnZhbHZlCnZhbgp2YW5pc2gKdmFwb3IKdmFyaW91cwp2YXN0CnZhdWx0CnZlaGljbGUKdmVsdmV0CnZlbmRvcgp2ZW50dXJlCnZlbnVlCnZlcmIKdmVyaWZ5CnZlcnNpb24KdmVyeQp2ZXNzZWwKdmV0ZXJhbgp2aWFibGUKdmlicmFudAp2aWNpb3VzCnZpY3RvcnkKdmlkZW8Kdmlldwp2aWxsYWdlCnZpbnRhZ2UKdmlvbGluCnZpcnR1YWwKdmlydXMKdmlzYQp2aXNpdAp2aXN1YWwKdml0YWwKdml2aWQKdm9jYWwKdm9pY2UKdm9pZAp2b2xjYW5vCnZvbHVtZQp2b3RlCnZveWFnZQp3YWdlCndhZ29uCndhaXQKd2Fsawp3YWxsCndhbG51dAp3YW50CndhcmZhcmUKd2FybQp3YXJyaW9yCndhc2gKd2FzcAp3YXN0ZQp3YXRlcgp3YXZlCndheQp3ZWFsdGgKd2VhcG9uCndlYXIKd2Vhc2VsCndlYXRoZXIKd2ViCndlZGRpbmcKd2Vla2VuZAp3ZWlyZAp3ZWxjb21lCndlc3QKd2V0CndoYWxlCndoYXQKd2hlYXQKd2hlZWwKd2hlbgp3aGVyZQp3aGlwCndoaXNwZXIKd2lkZQp3aWR0aAp3aWZlCndpbGQKd2lsbAp3aW4Kd2luZG93CndpbmUKd2luZwp3aW5rCndpbm5lcgp3aW50ZXIKd2lyZQp3aXNkb20Kd2lzZQp3aXNoCndpdG5lc3MKd29sZgp3b21hbgp3b25kZXIKd29vZAp3b29sCndvcmQKd29yawp3b3JsZAp3b3JyeQp3b3J0aAp3cmFwCndyZWNrCndyZXN0bGUKd3Jpc3QKd3JpdGUKd3JvbmcKeWFyZAp5ZWFyCnllbGxvdwp5b3UKeW91bmcKeW91dGgKemVicmEKemVybwp6b25lCnpvbwptbmVtb25pY5RuEgAIAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZTw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAzG4SAB4AAAACAAAAAgAAAGJpcDM5OjplcnJvcjo6RXJyb3JLaW5kaW52YWxpZCBlbnRyb3B5IGxlbmd0aCBiaXRzIGZvciBtbmVtb25pYyB0eXBlIAAAABNvEgAXAAAAKm8SABcAAABpbnZhbGlkIG51bWJlciBvZiB3b3JkcyBpbiBwaHJhc2U6IABUbxIAIwAAAGludmFsaWQga2V5c2l6ZTogAAAAgG8SABEAAABpbnZhbGlkIHdvcmQgaW4gcGhyYXNlAACcbxIAFgAAAGludmFsaWQgY2hlY2tzdW28bxIAEAAAAEludmFsaWRFbnRyb3B5TGVuZ3RoQwAAAAQAAAAEAAAAIAAAAEQAAAAEAAAABAAAAEIAAABJbnZhbGlkV29yZExlbmd0aEludmFsaWRLZXlzaXplSW52YWxpZFdvcmRJbnZhbGlkQ2hlY2tzdW1Xb3JkczI0V29yZHMyMVdvcmRzMThXb3JkczE1V29yZHMxMi9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL3NsaWNlL21vZC5yc2RwEgBIAAAAQxIAABUAAAAAAAAAYXR0ZW1wdCB0byBkaXZpZGUgYnkgemVyb2Fzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6IAAAANlwEgAtAAAABnESAAwAAAAScRIAAwAAAGRlc3RpbmF0aW9uIGFuZCBzb3VyY2Ugc2xpY2VzIGhhdmUgZGlmZmVyZW50IGxlbmd0aHMwcRIANAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL21hY3Jvcy9tb2QucnMAAABscRIASQAAABIAAAANAAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2Jsb2NrLWJ1ZmZlci0wLjcuMC9zcmMvbGliLnJzAADIcRIAWgAAAF0AAAAJAAAAPDo6c3RkOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAAA0chIAHQAAAAIAAAAEAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYAAAZHISAC0AAACRchIADAAAAJ1yEgABAAAANHISAB0AAAAFAAAABgAAAGFzc2VydGlvbiBmYWlsZWQ6IDQgPD0gYnVmLmxlbigpYXNzZXJ0aW9uIGZhaWxlZDogOCA8PSBidWYubGVuKCkvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvYmxvY2stYnVmZmVyLTAuNy4wL3NyYy9saWIucnMAAAhzEgBaAAAAXQAAAAkAAAA8OjpzdGQ6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAAHRzEgAdAAAAAgAAAAQAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgAACkcxIALQAAANFzEgAMAAAA3XMSAAEAAAB0cxIAHQAAAAUAAAAGAAAAYXNzZXJ0aW9uIGZhaWxlZDogOCA8PSBidWYubGVuKCln5glqha5nu3Lzbjw69U+lf1IOUYxoBZur2YMfGc3gWwjJvPNn5glqO6fKhIWuZ7sr+JT+cvNuPPE2HV869U+l0YLmrX9SDlEfbD4rjGgFm2u9Qfur2YMfeSF+ExnN4FtGAAAACAAAAAQAAABHAAAASAAAAEkAAAAIAAAABAAAAEoAAABHZW5lcmljQXJyYXk6OmZyb21faXRlciByZWNlaXZlZCAgZWxlbWVudHMgYnV0IGV4cGVjdGVkIKx0EgAhAAAAzXQSABcAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvZ2VuZXJpYy1hcnJheS0wLjEyLjAvc3JjL2xpYi5yc/R0EgBcAAAAQAEAAAUAAABMAAAABAAAAAQAAABNAAAATgAAAE8AAAAEAAAABAAAAFAAAABRAAAAUgAAAAQAAAAEAAAAUwAAAFQAAABPbmNlIGluc3RhbmNlIGhhcyBwcmV2aW91c2x5IGJlZW4gcG9pc29uZWQvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcGFya2luZ19sb3QtMC43LjEvc3JjL29uY2UucnPGdRIAWgAAAPIAAAARAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZcZ1EgBaAAAAHgEAACgAAABjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlAFYAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcGFya2luZ19sb3RfY29yZS0wLjQuMC9zcmMvcGFya2luZ19sb3QucnMAAJh2EgBmAAAAugAAAAUAAACYdhIAZgAAABcBAAAQAAAAmHYSAGYAAAAeAQAADQAAAJh2EgBmAAAAQAEAABMAAACYdhIAZgAAAFkBAAATAAAAVHJpZWQgdG8gc2hyaW5rIHRvIGEgbGFyZ2VyIGNhcGFjaXR5PDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+AAB0dxIAHgAAAAIAAAACAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZUZyb21FbnRyb3B5Ojpmcm9tX2VudHJvcHkoKSBmYWlsZWQ6IMx3EgAkAAAAPDo6c3RkOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAAD4dxIAHQAAAAUAAAAGAAAAY2FsbGVkIGBPcHRpb246OnVud3JhcCgpYCBvbiBhIGBOb25lYCB2YWx1ZQBZAAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL3BhcmtpbmdfbG90X2NvcmUtMC40LjAvc3JjL3dvcmRfbG9jay5yc1h4EgBkAAAASQAAAAUAAABhc3NlcnRpb24gZmFpbGVkOiBuZXdfY2FwID49IGxlbjw6OnN0ZDo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+AAAA7HgSAB0AAAACAAAABAAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4L3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC9tYWNyb3MucnM8eRIARAAAAA0AAAAXAAAAUG9pc29uRXJyb3IgeyBpbm5lcjogLi4gfWNhbGxlZCBgUmVzdWx0Ojp1bndyYXAoKWAgb24gYW4gYEVycmAgdmFsdWVaAAAACAAAAAQAAABbAAAAXAAAAAwAAAAEAAAAXQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9wYXJraW5nX2xvdF9jb3JlLTAuNC4wL3NyYy90aHJlYWRfcGFya2VyL2dlbmVyaWMucnP0eRIAcAAAACcAAAAVAAAA9HkSAHAAAAAuAAAAGAAAAPR5EgBwAAAAMAAAABQAAAD0eRIAcAAAADgAAAAYAAAA9HkSAHAAAAA+AAAAIQAAAPR5EgBwAAAASgAAABUAAABfAAAAY291bGQgbm90IGluaXRpYWxpemUgdGhyZWFkX3JuZzogAAAAyHoSACEAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcmFuZC0wLjYuNS9zcmMvcm5ncy90aHJlYWQucnMAAPR6EgBaAAAAUAAAABEAAABjYW5ub3QgYWNjZXNzIGEgVGhyZWFkIExvY2FsIFN0b3JhZ2UgdmFsdWUgZHVyaW5nIG9yIGFmdGVyIGRlc3RydWN0aW9uL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC90aHJlYWQvbG9jYWwucnOmexIASgAAAO8AAAAJAAAAYAAAAAAAAAABAAAAYQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kLTAuNi41L3NyYy9ybmdzL2VudHJvcHkucnNObyBlbnRyb3B5IHNvdXJjZXMgYXZhaWxhYmxlQWxsIGVudHJvcHkgc291cmNlcyBmYWlsZWRpbnRlcm5hbCBlcnJvcjogZW50ZXJlZCB1bnJlYWNoYWJsZSBjb2RlAAAAEHwSAFsAAAC6AAAACQAAAGFzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6INx8EgAtAAAACX0SAAwAAAAVfRIAAwAAAGRlc3RpbmF0aW9uIGFuZCBzb3VyY2Ugc2xpY2VzIGhhdmUgZGlmZmVyZW50IGxlbmd0aHMwfRIANAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL21hY3Jvcy9tb2QucnMAAABsfRIASQAAABIAAAANAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogyH0SAC0AAAD1fRIADAAAAAF+EgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Rocxx+EgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAFh+EgBJAAAAEgAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLmNvdW50ZXIxMDI0ICUgMTYgPT0gMC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kX2hjLTAuMS4wL3NyYy9oYzEyOC5ycwDgfhIAVwAAAH0AAAAJAAAA4H4SAFcAAADhAAAACQAAAOB+EgBXAAAA/AAAAA0AAADgfhIAVwAAAP0AAAANAAAA4H4SAFcAAAD+AAAADQAAAOB+EgBXAAAA/wAAAA0AAADgfhIAVwAAAAABAAANAAAA4H4SAFcAAAABAQAADQAAAOB+EgBXAAAAAgEAAA0AAADgfhIAVwAAAAMBAAANAAAA4H4SAFcAAAAEAQAADQAAAOB+EgBXAAAABQEAAA0AAADgfhIAVwAAAAYBAAANAAAA4H4SAFcAAAAHAQAADQAAAOB+EgBXAAAACAEAAA0AAADgfhIAVwAAAAkBAAANAAAA4H4SAFcAAAAKAQAADQAAAHJldHVybiB0aGlzYXNzZXJ0aW9uIGZhaWxlZDogdGhpcyAhPSBKc1ZhbHVlOjp1bmRlZmluZWQoKS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kX29zLTAuMS4zL3NyYy93YXNtMzJfYmluZGdlbi5ycwAAAIGAEgBgAAAAIQAAAAkAAABjcnlwdG9zZWxmLmNyeXB0byBpcyB1bmRlZmluZWRjcnlwdG8uZ2V0UmFuZG9tVmFsdWVzIGlzIHVuZGVmaW5lZAAAAGMAAAAIAAAABAAAAGQAAABlAAAAZgAAAAgAAAAEAAAAZwAAAGludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGUvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcmFuZF9jb3JlLTAuNC4yL3NyYy9lcnJvci5ycwAAAISBEgBZAAAASgAAACsAAABub3QgcmVhZHkgeWV0dHJhbnNpZW50IGZhaWx1cmV1bmV4cGVjdGVkIGZhaWx1cmVwZXJtYW5lbnRseSB1bmF2YWlsYWJsZSAoKQAAN4ISAAAAAAA3ghIAAgAAADmCEgABAAAAKTsgY2F1c2U6IAAAN4ISAAAAAAA3ghIAAgAAAFSCEgAKAAAAX19Ob25leGhhdXN0aXZlTm90UmVhZHlUcmFuc2llbnRVbmV4cGVjdGVkVW5hdmFpbGFibGVFcnJvcmtpbmQAAGoAAAAEAAAABAAAAGsAAABtc2cAbAAAAAQAAAAEAAAAHgAAAGNhdXNlAAAAbQAAAAQAAAAEAAAAbgAAAFNvbWVvAAAABAAAAAQAAABwAAAATm9uZXEAAAAUAAAABAAAAHIAAABzAAAAdAAAAHUAAAB2AAAAVwAAAHcAAAAKCgAANIMSAAAAAAA0gxIAAgAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4L3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC9tYWNyb3MucnNogxIARAAAAA0AAAAXAAAAY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQB6AAAACAAAAAQAAAB7AAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2ZhaWx1cmUtMC4xLjUvc3JjL2JhY2t0cmFjZS9pbnRlcm5hbC5yc/iDEgBkAAAAOgAAABwAAABSVVNUX0ZBSUxVUkVfQkFDS1RSQUNFMFJVU1RfQkFDS1RSQUNFUG9pc29uRXJyb3IgeyBpbm5lcjogLi4gfWludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGU8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz7ShBIAHgAAAAIAAAACAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogAIUSAC0AAAAthRIADAAAADmFEgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc1SFEgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAJCFEgBJAAAAEgAAAA0AAAB9AAAACAAAAAQAAAB+AAAAfwAAAIAAAAAIAAAABAAAAIEAAACCAAAABAAAAAQAAACDAAAAhAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJzdGQvc3luYy9vbmNlLnJzACSGEgBHAAAACAEAACkAAABjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQAAhQAAAAgAAAAEAAAAhgAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9iYWNrdHJhY2UtMC4zLjM4L3NyYy9saWIucnOHAAAA5IYSAFgAAACUAAAAHAAAAFBvaXNvbkVycm9yIHsgaW5uZXI6IC4uIH1zdGFjayBiYWNrdHJhY2U6CgAAOiAAAHyHEgAAAAAAfIcSAAIAAAAAAAAAIAAAAAAAAAACAEGoj8oAC4ojBAAAAAMAAAAgLSAAfIcSAAAAAACwhxIAAwAAAAoAAAAAAAAAIAAAAAAAAAACAAAAAAAAAAEAAAABAAAAAwAAACAgICAgIAAA6IcSAAYAAAB8hxIAAAAAAA0AAAAAAAAAIAAAAAQAAAACAAAAAAAAAAIAAAAAAAAAAwAAADx1bmtub3duPgAAACSIEgAJAAAACiAgICAgICAgICAgICBhdCAAAAA5iBIAEAAAADoAAABUiBIAAQAAADiIEgABAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9iYWNrdHJhY2UtMC4zLjM4L3NyYy90eXBlcy5ycwAAkIgSAFoAAABKAAAACQAAAIsAAAAUAAAABAAAAIwAAACNAAAA77+9Y2Fubm90IHJlY3Vyc2l2ZWx5IGFjcXVpcmUgbXV0ZXgvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGlic3RkL21hY3Jvcy5ycwAziRIARAAAAA0AAAAXAAAAY2Fubm90IGFjY2VzcyBhIFRocmVhZCBMb2NhbCBTdG9yYWdlIHZhbHVlIGR1cmluZyBvciBhZnRlciBkZXN0cnVjdGlvbi9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJzdGQvdGhyZWFkL2xvY2FsLnJzzokSAEoAAADvAAAACQAAAI8AAAAAAAAAAQAAAGEAAABhc3NlcnRpb24gZmFpbGVkOiBzbG90LmdldCgpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JhY2t0cmFjZS0wLjMuMzgvc3JjL2xpYi5yc1SKEgBYAAAAhAAAABUAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9zdHIvcGF0dGVybi5ycwAAvIoSAEoAAACCBAAAIQAAALyKEgBKAAAAjgQAABQAAAC8ihIASgAAAI4EAAAhAAAAvIoSAEoAAADZBAAAFAAAALyKEgBKAAAA2QQAACEAAAC8ihIASgAAAOUEAAAUAAAAvIoSAEoAAADlBAAAIQAAAGNhbGxlZCBgT3B0aW9uOjp1bndyYXAoKWAgb24gYSBgTm9uZWAgdmFsdWVjYWxsZWQgYFJlc3VsdDo6dW53cmFwKClgIG9uIGFuIGBFcnJgIHZhbHVlAACQAAAAAQAAAAEAAACRAAAALmxsdm0uRS5fWk5aTl9fWk4vaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcnVzdGMtZGVtYW5nbGUtMC4xLjEzL3NyYy9saWIucnMAAPGLEgBdAAAAAgEAABMAAADxixIAXQAAAAUBAAAcAAAAOjpfJC4kU1AkQCRCUCQqJFJGJCYkTFQkPCRHVCQ+JExQJCgkUlAkKSRDJCwkdTdlJH4kdTIwJCAkdTI3JCckdTNkJD0kdTViJFskdTVkJF0kdTdiJHskdTdkJH0kdTNiJDskdTJiJCskdTIxJCEkdTIyJCKUAAAABAAAAAQAAACVAAAAlgAAAJcAAACUAAAABAAAAAQAAACYAAAAYWxyZWFkeSBib3Jyb3dlZC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL2NlbGwucnMAHI0SAEMAAABuAwAACQAAAGFscmVhZHkgbXV0YWJseSBib3Jyb3dlZByNEgBDAAAAHgMAAAkAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgAACYjRIALQAAAMWNEgAMAAAA0Y0SAAEAAACUAAAAAAAAAAEAAACZAAAAYDogAJiNEgAtAAAAxY0SAAwAAAD8jRIAAwAAAGNhbGxlZCBgT3B0aW9uOjp1bndyYXAoKWAgb24gYSBgTm9uZWAgdmFsdWUAlAAAAAAAAAABAAAAmgAAAJsAAAAQAAAABAAAAJwAAACUAAAAAAAAAAEAAACdAAAAY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQCeAAAACAAAAAQAAACfAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZTw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAA2I4SAB4AAAACAAAAAgAAAFRyaWVkIHRvIHNocmluayB0byBhIGxhcmdlciBjYXBhY2l0eZQAAAAEAAAABAAAAJIAAABBY2Nlc3NFcnJvcnNyYy9saWJzdGQvdGhyZWFkL21vZC5ycwBHjxIAGAAAAIYDAAARAAAAaW5jb25zaXN0ZW50IHBhcmsgc3RhdGUAR48SABgAAACUAwAAEwAAAAIAAABwYXJrIHN0YXRlIGNoYW5nZWQgdW5leHBlY3RlZGx5AJyPEgAfAAAAR48SABgAAACRAwAADQAAAGZhaWxlZCB0byBnZW5lcmF0ZSB1bmlxdWUgdGhyZWFkIElEOiBiaXRzcGFjZSBleGhhdXN0ZWQAR48SABgAAAAqBAAAEQAAAEePEgAYAAAAMAQAABYAAAB0aHJlYWQgbmFtZSBtYXkgbm90IGNvbnRhaW4gaW50ZXJpb3IgbnVsbCBieXRlcwBHjxIAGAAAAHMEAAAaAAAAaW5jb25zaXN0ZW50IHN0YXRlIGluIHVucGFya0ePEgAYAAAAqwQAABIAAABHjxIAGAAAALkEAAAOAAAAoAAAAAwAAAAEAAAAoQAAAKIAAACjAAAApAAAAKEAAAClAAAApgAAAC5zcmMvbGlic3RkL3BhdGgucnMuLgAAANGQEgASAAAAiwMAACAAAABhdHRlbXB0ZWQgdG8gdXNlIGEgY29uZGl0aW9uIHZhcmlhYmxlIHdpdGggdHdvIG11dGV4ZXNzcmMvbGlic3RkL3N5bmMvY29uZHZhci5ycy6REgAaAAAAPwIAABIAAABzcmMvbGlic3RkL3N5bmMvb25jZS5yc2Fzc2VydGlvbiBmYWlsZWQ6IHN0YXRlX2FuZF9xdWV1ZSAmIFNUQVRFX01BU0sgPT0gUlVOTklOR1iREgAXAAAApwEAABUAAABPbmNlIGluc3RhbmNlIGhhcyBwcmV2aW91c2x5IGJlZW4gcG9pc29uZWQAAFiREgAXAAAAiwEAABUAAABYkRIAFwAAAOgBAAAJAAAAWJESABcAAAD0AQAAHgAAAHN1cHBsaWVkIGluc3RhbnQgaXMgbGF0ZXIgdGhhbiBzZWxmc3JjL2xpYnN0ZC90aW1lLnJzAAAAN5ISABIAAAAHAQAACQAAAFBvaXNvbkVycm9yIHsgaW5uZXI6IC4uIH1zcmMvbGlic3RkL3Bhbmlja2luZy5yc3WSEgAXAAAAeAEAAA8AAAB1khIAFwAAAHkBAAAPAAAApwAAABAAAAAEAAAAqAAAAKkAAACgAAAADAAAAAQAAACqAAAAlAAAAAgAAAAEAAAAqwAAAKwAAACUAAAACAAAAAQAAACtAAAATnVsRXJyb3KUAAAABAAAAAQAAACuAAAAdGltZSBub3QgaW1wbGVtZW50ZWQgb24gd2FzbTMyLXVua25vd24tdW5rbm93bnNyYy9saWJzdGQvc3lzL3dhc20vdGltZS5ycwAAADqTEgAbAAAADQAAAAkAAABvcGVyYXRpb24gbm90IHN1cHBvcnRlZCBvbiB3YXNtIHlldGNhbid0IGJsb2NrIHdpdGggd2ViIGFzc2VtYmx5c3JjL2xpYnN0ZC9zeXMvd2FzbS9jb25kdmFyLnJzAACokxIAHgAAABUAAAAJAAAAqJMSAB4AAAAZAAAACQAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4c3JjL2xpYnN0ZC9zeXMvd2FzbS9tdXRleC5ycwiUEgAcAAAAFQAAAAkAAACvAAAABAAAAAQAAACwAAAAsQAAALIAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9mbXQvbW9kLnJzAABMlBIARgAAAFgBAAATAAAArwAAAAAAAAABAAAAswAAAGEgZm9ybWF0dGluZyB0cmFpdCBpbXBsZW1lbnRhdGlvbiByZXR1cm5lZCBhbiBlcnJvcnNyYy9saWJhbGxvYy9mbXQucnMAAOeUEgATAAAAOwIAAAUAAABzcmMvbGliYWxsb2MvcmF3X3ZlYy5yc2NhcGFjaXR5IG92ZXJmbG93DJUSABcAAADrAgAABQAAAGAALi5GlRIAAgAAAEJvcnJvd0Vycm9yQm9ycm93TXV0RXJyb3JjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlRJUSAAAAAAA6IAAARJUSAAAAAACclRIAAgAAALkAAAAAAAAAAQAAALoAAABpbmRleCBvdXQgb2YgYm91bmRzOiB0aGUgbGVuIGlzICBidXQgdGhlIGluZGV4IGlzIAAAwJUSACAAAADglRIAEgAAALkAAAAMAAAABAAAALsAAAC8AAAAvQAAACAgICAgewosCiwgIHsgfSB9KAooLCkKW10weDBiMDAwMTAyMDMwNDA1MDYwNzA4MDkxMDExMTIxMzE0MTUxNjE3MTgxOTIwMjEyMjIzMjQyNTI2MjcyODI5MzAzMTMyMzMzNDM1MzYzNzM4Mzk0MDQxNDI0MzQ0NDU0NjQ3NDg0OTUwNTE1MjUzNTQ1NTU2NTc1ODU5NjA2MTYyNjM2NDY1NjY2NzY4Njk3MDcxNzI3Mzc0NzU3Njc3Nzg3OTgwODE4MjgzODQ4NTg2ODc4ODg5OTA5MTkyOTM5NDk1OTY5Nzk4OTkAAAC5AAAABAAAAAQAAAC+AAAAvwAAAMAAAABzcmMvbGliY29yZS9mbXQvbW9kLnJzAAAclxIAFgAAADwEAAARAAAAHJcSABYAAABGBAAAJAAAAHRydWVmYWxzZXNyYy9saWJjb3JlL3NsaWNlL21vZC5yc2luZGV4ICBvdXQgb2YgcmFuZ2UgZm9yIHNsaWNlIG9mIGxlbmd0aCAAAAB1lxIABgAAAHuXEgAiAAAAXZcSABgAAACxCgAABQAAAHNsaWNlIGluZGV4IHN0YXJ0cyBhdCAgYnV0IGVuZHMgYXQgAMCXEgAWAAAA1pcSAA0AAABdlxIAGAAAALcKAAAFAAAAc3JjL2xpYmNvcmUvc3RyL3BhdHRlcm4ucnMAAASYEgAaAAAAEAUAABUAAAAEmBIAGgAAAD4FAAAVAAAABJgSABoAAAA/BQAAFQAAAGFzc2VydGlvbiBmYWlsZWQ6IGJyb2tlbi5pc19lbXB0eSgpc3JjL2xpYmNvcmUvc3RyL2xvc3N5LnJzAHOYEgAYAAAAnQAAABEAAABzcmMvbGliY29yZS9zdHIvbW9kLnJzAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAQfSyygALMwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDAwMDAwMDAwMEBAQEBABBsrPKAAuZDlsuLi5dYnl0ZSBpbmRleCAgaXMgb3V0IG9mIGJvdW5kcyBvZiBgt5kSAAsAAADCmRIAFgAAAESVEgABAAAAnJgSABYAAACSCAAACQAAAGJlZ2luIDw9IGVuZCAoIDw9ICkgd2hlbiBzbGljaW5nIGAAAACaEgAOAAAADpoSAAQAAAASmhIAEAAAAESVEgABAAAAnJgSABYAAACWCAAABQAAAJyYEgAWAAAApwgAAA4AAAAgaXMgbm90IGEgY2hhciBib3VuZGFyeTsgaXQgaXMgaW5zaWRlICAoYnl0ZXMgKSBvZiBgt5kSAAsAAABkmhIAJgAAAIqaEgAIAAAAkpoSAAYAAABElRIAAQAAAJyYEgAWAAAAqQgAAAUAAABzcmMvbGliY29yZS91bmljb2RlL3ByaW50YWJsZS5yc9CaEgAgAAAAGgAAACgAAAAAAQMFBQYGAwcGCAgJEQocCxkMFA0SDg0PBBADEhITCRYBFwUYAhkDGgccAh0BHxYgAysELAItCy4BMAMxAjIBpwKpAqoEqwj6AvsF/QT+A/8JrXh5i42iMFdYi4yQHB3dDg9LTPv8Li8/XF1fteKEjY6RkqmxurvFxsnK3uTl/wAEERIpMTQ3Ojs9SUpdhI6SqbG0urvGys7P5OUABA0OERIpMTQ6O0VGSUpeZGWEkZudyc7PDREpRUlXZGWNkam0urvFyd/k5fAEDRFFSWRlgIGEsry+v9XX8PGDhYukpr6/xcfOz9rbSJi9zcbOz0lOT1dZXl+Jjo+xtre/wcbH1xEWF1tc9vf+/4ANbXHe3w4PH25vHB1ffX6ur7u8+hYXHh9GR05PWFpcXn5/tcXU1dzw8fVyc490dZaXL18mLi+nr7e/x8/X35pAl5gwjx/Awc7/Tk9aWwcIDxAnL+7vbm83PT9CRZCR/v9TZ3XIydDR2Nnn/v8AIF8igt8EgkQIGwQGEYGsDoCrNR4VgOADGQgBBC8ENAQHAwEHBgcRClAPEgdVCAIEHAoJAwgDBwMCAwMDDAQFAwsGAQ4VBToDEQcGBRAHVwcCBxUNUARDAy0DAQQRBg8MOgQdJV8gbQRqJYDIBYKwAxoGgv0DWQcVCxcJFAwUDGoGCgYaBlkHKwVGCiwEDAQBAzELLAQaBgsDgKwGCgYfQUwELQN0CDwDDwM8BzgIKwWC/xEYCC8RLQMgECEPgIwEgpcZCxWIlAUvBTsHAg4YCYCwMHQMgNYaDAWA/wWAtgUkDJvGCtIwEISNAzcJgVwUgLgIgMcwNQQKBjgIRggMBnQLHgNaBFkJgIMYHAoWCUgIgIoGq6QMFwQxoQSB2iYHDAUFgKURgW0QeCgqBkwEgI0EgL4DGwMPDQAGAQEDAQQCCAgJAgoFCwIQAREEEgUTERQCFQIXAhkEHAUdCCQBagNrArwC0QLUDNUJ1gLXAtoB4AXhAugC7iDwBPkG+gIMJzs+Tk+Pnp6fBgcJNj0+VvPQ0QQUGDY3Vle9Nc7P4BKHiY6eBA0OERIpMTQ6RUZJSk5PZGVaXLa3GxyoqdjZCTeQkagHCjs+ZmmPkm9f7u9aYpqbJyhVnaCho6SnqK26vMQGCwwVHTo/RVGmp8zNoAcZGiIlPj/FxgQgIyUmKDM4OkhKTFBTVVZYWlxeYGNlZmtzeH1/iqSqr7DA0Axyo6TLzG5vXiJ7BQMELQNlBAEvLoCCHQMxDxwEJAkeBSsFRAQOKoCqBiQEJAQoCDQLAYCQgTcJFgoIgJg5A2MICTAWBSEDGwUBQDgESwUvBAoHCQdAICcEDAk2AzoFGgcEDAdQSTczDTMHLggKgSYfgIEoCCqAhhcJTgQeD0MOGQcKBkcJJwl1Cz9BKgY7BQoGUQYBBRADBYCLYCBICAqApl4iRQsKBg0TOQcKNiwEEIDAPGRTDAGAoEUbSAhTHTmBB0YKHQNHSTcDDggKBjkHCoE2GYDHMg2Dm2Z1C4DEiryEL4/RgkehuYI5ByoEAmAmCkYKKAUTgrBbZUsEOQcRQAQcl/gIgvOlDYEfMQMRBAiBjIkEawUNAwkHEJNggPYKcwhuF0aAmhQMVwkZgIeBRwOFQg8VhVArgNUtAxoEAoFwOgUBhQCA1ylMBAoEAoMRREw9gMI8BgEEVQUbNAKBDiwEZAxWCg0DXQM9OR0NLAQJBwIOBoCag9YKDQMLBXQMWQcMFAwEOAgKBigIHlJ3AzEDgKYMFAQDBQMNBoVqc3JjL2xpYmNvcmUvdW5pY29kZS9tb2QucnMANaASABoAAAA4AAAADwAAADWgEgAaAAAAOQAAABAAAABraW5kRW1wdHlaZXJvUGFyc2VJbnRFcnJvcgAAuQAAAAQAAAAEAAAAwQAAAFVuZGVyZmxvd092ZXJmbG93SW52YWxpZERpZ2l0RXJyb3IEDxUbGQMSFxEAAA4WAEHnwcoACwIGEwBB/MHKAAsKAgcKAAgMHRwYGgBBmMLKAAsCBQEAQa3CygALDBAAAAAACwAJABQADQBB1sLKAAsCDxIAQeXCygALAR8AQfXCygALBElGZh0AQYXDygALAoo+AEGUw8oACwJLUwBBosPKAAsDZyNCAEGxw8oACwc9AAAAAAAjAEHBw8oACwR1AAAtAEHRw8oACwOCTjwAQeDDygALE2MAAAAlAFoAAAAAAAAAgTYAAAMAQf3DygALAS8AQYbEygALCRAAAAAAABMACABBnMTKAAsFQwByAIkAQavEygALEQcAAAB9BRg/ADeHCUBkAAAhAEHJxMoACwQKAABBAEHZxMoAC0MMADAAXAAAABl3cQBgRzVELgAAdDkRZSxRXn9QAAAANDEAAABTAAAAAAAAOgAAAAA4GgCIXytraV1PXYSAKmgUOwAXAEGpxcoACwhVAABXAAAAgwBBucXKAAsTWQAAAAAAACZuGxYAAAAAAG1KHABB1sXKAAtLJAAAfABSAHsGFQAAAABIAAAAAH4odidsKQAiWw5hDVZwYgSFIHgCAAB6HnkBVAAzAAAAhnNYAE1FbwtqAAAybEwAAImKAACKioo+AEG4xsoAC5wCAQAAAAAAAAANAAAAAAAAABwAAAAAAAAAQAAAAAAAAAC2AAAAAAAAAL8AAAAAAAAA+AMAAAAAAADwBwAAAAAAAP8HAAAAAAAAABAAAAAAAAAAHgAAAAAAAAA4AAAAAAAAAD8AAAAAAACAfwAAAAAAAACAAAAAAAAAwP8BAAAAAACA/wMAAAAAAACABwAAAAAAAAB/AAAAAAABIIAAAAAAAAAAowAAAAAAAPx/AwAAAAAAAAAGAAAAAAAA/wcAAAAAAACACQAAAAAAAAAOAAAAAIAAfg4AAAAAZCAAIAAAAABA/g8gAAAAAAEAADAAAAAAAAAAQAAAAABcAABAAAAAAAAAAGAAAAAAAIRcgAAAAAAAAADAAAAAAAAAAOAAQdzIygALtQYBAAAAAADwDAEAAABEMGAADAAAAME9YAAMAAAAHiCAAAwAAAAeIMAADAAAAP4h/gAMAAAAAAAAACAAAAAAAAAAYAAAAEQIAABgAAAAAAAAAPAAAABgAAAAAAIAAH////nbBwAAAAAAgPgHAAAAAADgvA8AAAAAAAAgIQAAAwAAADw7AADnDwAAADwAAAAAwJ+fPQAAAADA++8+AAAAAAAAwD8AAAAAAAAA8AAAAAAAAAD8AAAQAAD4/v8AAP//AAD//wAA////////AAAA+P//AAABAAAAAADA/wEAAAD/////AQAAAAAAAAADAAAAAAAAgAMAAAAAAECjAwAAAAAAAAAIAAAADAAAAAwABAAAAAD4DwAAAAAAAAAYAAAAHAAAABwAAAAAwwEAHgAAAAAAAAAfAAEAgADAHx8ABwAAAIDvHwD//////x8gAIY5AgAAACMAAgAAAAAwQAAAAAAAAH5mAAAA/P///G0AAAAAAAAAfwAAAAAAACi/AAAAAAAA8M8AAAAAAwAAoAIAAPf//SEQAwMAAAAAAHgGAAAAAACA/wYAAAAAAADABwAAAAAAAPIHAAAAAIcBBA4GAAAAAAAAEAgQAAAAAAAQBwAAAAAAABQPAAAAAADwFwAAAAAAAPIf3+D//v///x8AAAAAAAAAIAAAAAAA+A8gBwAAAAAAyDMAAAAAAACwPwAAAAAAgPc/BAAAAAAAAEAeIIAADAAAQAAAAAAAgNNAAgAAAAAAAFADAAAAAAAAWAAAAAAA4P1m/gcAAAAA+HkDAAAAAADAfwAAAAAAAP5/AAAAAAAA/38AAAAAAAAAgH8AAAAAAACAMAAAAP//A4Bu8AAAAAAAhwIAAAAAAACQAABAf+Uf+J8AAAAAAAD5pQAAAAAAAPinAAAAAACAPLAAAAAAAAB+tAAAAAAAAH+/AAD+/////78RAAAAAAAAwAAAAAAAAJ3BAgAAAAAAANAAAAAAoMMH+P///////3/4//////////u+IQAADAAA/AAAAAAAAAD/AgAAAAAAAP8AAAIAAAD//wAA+P/7////AAAAAP///////////////wMAAAAAAQAABABBq8/KAAsHAQAAAAAAAQBBwc/KAAsDBAADAEHRz8oACwIFAgBB8M/KAAsBAQBB+8/KAAsbgAAAAAAgAAAAAQAAAAA+AAABAAAA/wcAAACDAEGo+soACwE/AEHE+soACwFAAEHY+soACwECAEGA+8oACwECAEGQ+8oACwkCAAAAAAAAAAEAggEJcHJvZHVjZXJzAghsYW5ndWFnZQEEUnVzdAAMcHJvY2Vzc2VkLWJ5AwVydXN0YyUxLjQzLjAtbmlnaHRseSAoMGViODc4ZDJhIDIwMjAtMDItMjgpBndhbHJ1cwUwLjUuMAx3YXNtLWJpbmRnZW4SMC4yLjM5IChlMDc1ZDA0OTIp", + "base64" + ); + }.call(this, A("buffer").Buffer)); + }, + { buffer: 64 }, + ], + 307: [ + function (A, e, t) { + "use strict"; + const i = + (A, e) => + (...t) => { + return `[${A(...t) + e}m`; + }, + g = + (A, e) => + (...t) => { + const i = A(...t); + return `[${38 + e};5;${i}m`; + }, + r = + (A, e) => + (...t) => { + const i = A(...t); + return `[${38 + e};2;${i[0]};${i[1]};${i[2]}m`; + }, + n = (A) => A, + B = (A, e, t) => [A, e, t], + I = (A, e, t) => { + Object.defineProperty(A, e, { + get: () => { + const i = t(); + return ( + Object.defineProperty(A, e, { + value: i, + enumerable: !0, + configurable: !0, + }), + i + ); + }, + enumerable: !0, + configurable: !0, + }); + }; + let o; + const a = (e, t, i, g) => { + void 0 === o && (o = A("color-convert")); + const r = g ? 10 : 0, + n = {}; + for (const [A, g] of Object.entries(o)) { + const B = "ansi16" === A ? "ansi" : A; + A === t + ? (n[B] = e(i, r)) + : "object" == typeof g && (n[B] = e(g[t], r)); + } + return n; + }; + Object.defineProperty(e, "exports", { + enumerable: !0, + get: function () { + const A = new Map(), + e = { + modifier: { + reset: [0, 0], + bold: [1, 22], + dim: [2, 22], + italic: [3, 23], + underline: [4, 24], + inverse: [7, 27], + hidden: [8, 28], + strikethrough: [9, 29], + }, + color: { + black: [30, 39], + red: [31, 39], + green: [32, 39], + yellow: [33, 39], + blue: [34, 39], + magenta: [35, 39], + cyan: [36, 39], + white: [37, 39], + blackBright: [90, 39], + redBright: [91, 39], + greenBright: [92, 39], + yellowBright: [93, 39], + blueBright: [94, 39], + magentaBright: [95, 39], + cyanBright: [96, 39], + whiteBright: [97, 39], + }, + bgColor: { + bgBlack: [40, 49], + bgRed: [41, 49], + bgGreen: [42, 49], + bgYellow: [43, 49], + bgBlue: [44, 49], + bgMagenta: [45, 49], + bgCyan: [46, 49], + bgWhite: [47, 49], + bgBlackBright: [100, 49], + bgRedBright: [101, 49], + bgGreenBright: [102, 49], + bgYellowBright: [103, 49], + bgBlueBright: [104, 49], + bgMagentaBright: [105, 49], + bgCyanBright: [106, 49], + bgWhiteBright: [107, 49], + }, + }; + (e.color.gray = e.color.blackBright), + (e.bgColor.bgGray = e.bgColor.bgBlackBright), + (e.color.grey = e.color.blackBright), + (e.bgColor.bgGrey = e.bgColor.bgBlackBright); + for (const [t, i] of Object.entries(e)) { + for (const [t, g] of Object.entries(i)) + (e[t] = { open: `[${g[0]}m`, close: `[${g[1]}m` }), + (i[t] = e[t]), + A.set(g[0], g[1]); + Object.defineProperty(e, t, { value: i, enumerable: !1 }); + } + return ( + Object.defineProperty(e, "codes", { value: A, enumerable: !1 }), + (e.color.close = ""), + (e.bgColor.close = ""), + I(e.color, "ansi", () => a(i, "ansi16", n, !1)), + I(e.color, "ansi256", () => a(g, "ansi256", n, !1)), + I(e.color, "ansi16m", () => a(r, "rgb", B, !1)), + I(e.bgColor, "ansi", () => a(i, "ansi16", n, !0)), + I(e.bgColor, "ansi256", () => a(g, "ansi256", n, !0)), + I(e.bgColor, "ansi16m", () => a(r, "rgb", B, !0)), + e + ); + }, + }); + }, + { "color-convert": 309 }, + ], + 308: [ + function (A, e, t) { + const i = A("color-name"), + g = {}; + for (const A of Object.keys(i)) g[i[A]] = A; + const r = { + rgb: { channels: 3, labels: "rgb" }, + hsl: { channels: 3, labels: "hsl" }, + hsv: { channels: 3, labels: "hsv" }, + hwb: { channels: 3, labels: "hwb" }, + cmyk: { channels: 4, labels: "cmyk" }, + xyz: { channels: 3, labels: "xyz" }, + lab: { channels: 3, labels: "lab" }, + lch: { channels: 3, labels: "lch" }, + hex: { channels: 1, labels: ["hex"] }, + keyword: { channels: 1, labels: ["keyword"] }, + ansi16: { channels: 1, labels: ["ansi16"] }, + ansi256: { channels: 1, labels: ["ansi256"] }, + hcg: { channels: 3, labels: ["h", "c", "g"] }, + apple: { channels: 3, labels: ["r16", "g16", "b16"] }, + gray: { channels: 1, labels: ["gray"] }, + }; + e.exports = r; + for (const A of Object.keys(r)) { + if (!("channels" in r[A])) + throw new Error("missing channels property: " + A); + if (!("labels" in r[A])) + throw new Error("missing channel labels property: " + A); + if (r[A].labels.length !== r[A].channels) + throw new Error("channel and label counts mismatch: " + A); + const { channels: e, labels: t } = r[A]; + delete r[A].channels, + delete r[A].labels, + Object.defineProperty(r[A], "channels", { value: e }), + Object.defineProperty(r[A], "labels", { value: t }); + } + (r.rgb.hsl = function (A) { + const e = A[0] / 255, + t = A[1] / 255, + i = A[2] / 255, + g = Math.min(e, t, i), + r = Math.max(e, t, i), + n = r - g; + let B, I; + r === g + ? (B = 0) + : e === r + ? (B = (t - i) / n) + : t === r + ? (B = 2 + (i - e) / n) + : i === r && (B = 4 + (e - t) / n), + (B = Math.min(60 * B, 360)) < 0 && (B += 360); + const o = (g + r) / 2; + return [ + B, + 100 * (I = r === g ? 0 : o <= 0.5 ? n / (r + g) : n / (2 - r - g)), + 100 * o, + ]; + }), + (r.rgb.hsv = function (A) { + let e, t, i, g, r; + const n = A[0] / 255, + B = A[1] / 255, + I = A[2] / 255, + o = Math.max(n, B, I), + a = o - Math.min(n, B, I), + Q = function (A) { + return (o - A) / 6 / a + 0.5; + }; + return ( + 0 === a + ? ((g = 0), (r = 0)) + : ((r = a / o), + (e = Q(n)), + (t = Q(B)), + (i = Q(I)), + n === o + ? (g = i - t) + : B === o + ? (g = 1 / 3 + e - i) + : I === o && (g = 2 / 3 + t - e), + g < 0 ? (g += 1) : g > 1 && (g -= 1)), + [360 * g, 100 * r, 100 * o] + ); + }), + (r.rgb.hwb = function (A) { + const e = A[0], + t = A[1]; + let i = A[2]; + return [ + r.rgb.hsl(A)[0], + 100 * ((1 / 255) * Math.min(e, Math.min(t, i))), + 100 * (i = 1 - (1 / 255) * Math.max(e, Math.max(t, i))), + ]; + }), + (r.rgb.cmyk = function (A) { + const e = A[0] / 255, + t = A[1] / 255, + i = A[2] / 255, + g = Math.min(1 - e, 1 - t, 1 - i); + return [ + 100 * ((1 - e - g) / (1 - g) || 0), + 100 * ((1 - t - g) / (1 - g) || 0), + 100 * ((1 - i - g) / (1 - g) || 0), + 100 * g, + ]; + }), + (r.rgb.keyword = function (A) { + const e = g[A]; + if (e) return e; + let t, + r = 1 / 0; + for (const e of Object.keys(i)) { + const g = i[e], + I = + ((B = g), + ((n = A)[0] - B[0]) ** 2 + + (n[1] - B[1]) ** 2 + + (n[2] - B[2]) ** 2); + I < r && ((r = I), (t = e)); + } + var n, B; + return t; + }), + (r.keyword.rgb = function (A) { + return i[A]; + }), + (r.rgb.xyz = function (A) { + let e = A[0] / 255, + t = A[1] / 255, + i = A[2] / 255; + return [ + 100 * + (0.4124 * + (e = e > 0.04045 ? ((e + 0.055) / 1.055) ** 2.4 : e / 12.92) + + 0.3576 * + (t = + t > 0.04045 ? ((t + 0.055) / 1.055) ** 2.4 : t / 12.92) + + 0.1805 * + (i = + i > 0.04045 ? ((i + 0.055) / 1.055) ** 2.4 : i / 12.92)), + 100 * (0.2126 * e + 0.7152 * t + 0.0722 * i), + 100 * (0.0193 * e + 0.1192 * t + 0.9505 * i), + ]; + }), + (r.rgb.lab = function (A) { + const e = r.rgb.xyz(A); + let t = e[0], + i = e[1], + g = e[2]; + return ( + (i /= 100), + (g /= 108.883), + (t = + (t /= 95.047) > 0.008856 ? t ** (1 / 3) : 7.787 * t + 16 / 116), + [ + 116 * (i = i > 0.008856 ? i ** (1 / 3) : 7.787 * i + 16 / 116) - + 16, + 500 * (t - i), + 200 * + (i - + (g = g > 0.008856 ? g ** (1 / 3) : 7.787 * g + 16 / 116)), + ] + ); + }), + (r.hsl.rgb = function (A) { + const e = A[0] / 360, + t = A[1] / 100, + i = A[2] / 100; + let g, r, n; + if (0 === t) return [(n = 255 * i), n, n]; + const B = 2 * i - (g = i < 0.5 ? i * (1 + t) : i + t - i * t), + I = [0, 0, 0]; + for (let A = 0; A < 3; A++) + (r = e + (1 / 3) * -(A - 1)) < 0 && r++, + r > 1 && r--, + (n = + 6 * r < 1 + ? B + 6 * (g - B) * r + : 2 * r < 1 + ? g + : 3 * r < 2 + ? B + (g - B) * (2 / 3 - r) * 6 + : B), + (I[A] = 255 * n); + return I; + }), + (r.hsl.hsv = function (A) { + const e = A[0]; + let t = A[1] / 100, + i = A[2] / 100, + g = t; + const r = Math.max(i, 0.01); + return ( + (t *= (i *= 2) <= 1 ? i : 2 - i), + (g *= r <= 1 ? r : 2 - r), + [ + e, + 100 * (0 === i ? (2 * g) / (r + g) : (2 * t) / (i + t)), + 100 * ((i + t) / 2), + ] + ); + }), + (r.hsv.rgb = function (A) { + const e = A[0] / 60, + t = A[1] / 100; + let i = A[2] / 100; + const g = Math.floor(e) % 6, + r = e - Math.floor(e), + n = 255 * i * (1 - t), + B = 255 * i * (1 - t * r), + I = 255 * i * (1 - t * (1 - r)); + switch (((i *= 255), g)) { + case 0: + return [i, I, n]; + case 1: + return [B, i, n]; + case 2: + return [n, i, I]; + case 3: + return [n, B, i]; + case 4: + return [I, n, i]; + case 5: + return [i, n, B]; + } + }), + (r.hsv.hsl = function (A) { + const e = A[0], + t = A[1] / 100, + i = A[2] / 100, + g = Math.max(i, 0.01); + let r, n; + n = (2 - t) * i; + const B = (2 - t) * g; + return ( + (r = t * g), + [e, 100 * (r = (r /= B <= 1 ? B : 2 - B) || 0), 100 * (n /= 2)] + ); + }), + (r.hwb.rgb = function (A) { + const e = A[0] / 360; + let t = A[1] / 100, + i = A[2] / 100; + const g = t + i; + let r; + g > 1 && ((t /= g), (i /= g)); + const n = Math.floor(6 * e), + B = 1 - i; + (r = 6 * e - n), 0 != (1 & n) && (r = 1 - r); + const I = t + r * (B - t); + let o, a, Q; + switch (n) { + default: + case 6: + case 0: + (o = B), (a = I), (Q = t); + break; + case 1: + (o = I), (a = B), (Q = t); + break; + case 2: + (o = t), (a = B), (Q = I); + break; + case 3: + (o = t), (a = I), (Q = B); + break; + case 4: + (o = I), (a = t), (Q = B); + break; + case 5: + (o = B), (a = t), (Q = I); + } + return [255 * o, 255 * a, 255 * Q]; + }), + (r.cmyk.rgb = function (A) { + const e = A[0] / 100, + t = A[1] / 100, + i = A[2] / 100, + g = A[3] / 100; + return [ + 255 * (1 - Math.min(1, e * (1 - g) + g)), + 255 * (1 - Math.min(1, t * (1 - g) + g)), + 255 * (1 - Math.min(1, i * (1 - g) + g)), + ]; + }), + (r.xyz.rgb = function (A) { + const e = A[0] / 100, + t = A[1] / 100, + i = A[2] / 100; + let g, r, n; + return ( + (r = -0.9689 * e + 1.8758 * t + 0.0415 * i), + (n = 0.0557 * e + -0.204 * t + 1.057 * i), + (g = + (g = 3.2406 * e + -1.5372 * t + -0.4986 * i) > 0.0031308 + ? 1.055 * g ** (1 / 2.4) - 0.055 + : 12.92 * g), + (r = r > 0.0031308 ? 1.055 * r ** (1 / 2.4) - 0.055 : 12.92 * r), + (n = n > 0.0031308 ? 1.055 * n ** (1 / 2.4) - 0.055 : 12.92 * n), + [ + 255 * (g = Math.min(Math.max(0, g), 1)), + 255 * (r = Math.min(Math.max(0, r), 1)), + 255 * (n = Math.min(Math.max(0, n), 1)), + ] + ); + }), + (r.xyz.lab = function (A) { + let e = A[0], + t = A[1], + i = A[2]; + return ( + (t /= 100), + (i /= 108.883), + (e = + (e /= 95.047) > 0.008856 ? e ** (1 / 3) : 7.787 * e + 16 / 116), + [ + 116 * (t = t > 0.008856 ? t ** (1 / 3) : 7.787 * t + 16 / 116) - + 16, + 500 * (e - t), + 200 * + (t - + (i = i > 0.008856 ? i ** (1 / 3) : 7.787 * i + 16 / 116)), + ] + ); + }), + (r.lab.xyz = function (A) { + const e = A[0], + t = A[1], + i = A[2]; + let g, r, n; + const B = (r = (e + 16) / 116) ** 3, + I = (g = t / 500 + r) ** 3, + o = (n = r - i / 200) ** 3; + return ( + (r = B > 0.008856 ? B : (r - 16 / 116) / 7.787), + (g = I > 0.008856 ? I : (g - 16 / 116) / 7.787), + (n = o > 0.008856 ? o : (n - 16 / 116) / 7.787), + [(g *= 95.047), (r *= 100), (n *= 108.883)] + ); + }), + (r.lab.lch = function (A) { + const e = A[0], + t = A[1], + i = A[2]; + let g; + return ( + (g = (360 * Math.atan2(i, t)) / 2 / Math.PI) < 0 && (g += 360), + [e, Math.sqrt(t * t + i * i), g] + ); + }), + (r.lch.lab = function (A) { + const e = A[0], + t = A[1], + i = (A[2] / 360) * 2 * Math.PI; + return [e, t * Math.cos(i), t * Math.sin(i)]; + }), + (r.rgb.ansi16 = function (A, e = null) { + const [t, i, g] = A; + let n = null === e ? r.rgb.hsv(A)[2] : e; + if (0 === (n = Math.round(n / 50))) return 30; + let B = + 30 + + ((Math.round(g / 255) << 2) | + (Math.round(i / 255) << 1) | + Math.round(t / 255)); + return 2 === n && (B += 60), B; + }), + (r.hsv.ansi16 = function (A) { + return r.rgb.ansi16(r.hsv.rgb(A), A[2]); + }), + (r.rgb.ansi256 = function (A) { + const e = A[0], + t = A[1], + i = A[2]; + return e === t && t === i + ? e < 8 + ? 16 + : e > 248 + ? 231 + : Math.round(((e - 8) / 247) * 24) + 232 + : 16 + + 36 * Math.round((e / 255) * 5) + + 6 * Math.round((t / 255) * 5) + + Math.round((i / 255) * 5); + }), + (r.ansi16.rgb = function (A) { + let e = A % 10; + if (0 === e || 7 === e) + return A > 50 && (e += 3.5), [(e = (e / 10.5) * 255), e, e]; + const t = 0.5 * (1 + ~~(A > 50)); + return [ + (1 & e) * t * 255, + ((e >> 1) & 1) * t * 255, + ((e >> 2) & 1) * t * 255, + ]; + }), + (r.ansi256.rgb = function (A) { + if (A >= 232) { + const e = 10 * (A - 232) + 8; + return [e, e, e]; + } + let e; + return ( + (A -= 16), + [ + (Math.floor(A / 36) / 5) * 255, + (Math.floor((e = A % 36) / 6) / 5) * 255, + ((e % 6) / 5) * 255, + ] + ); + }), + (r.rgb.hex = function (A) { + const e = ( + ((255 & Math.round(A[0])) << 16) + + ((255 & Math.round(A[1])) << 8) + + (255 & Math.round(A[2])) + ) + .toString(16) + .toUpperCase(); + return "000000".substring(e.length) + e; + }), + (r.hex.rgb = function (A) { + const e = A.toString(16).match(/[a-f0-9]{6}|[a-f0-9]{3}/i); + if (!e) return [0, 0, 0]; + let t = e[0]; + 3 === e[0].length && + (t = t + .split("") + .map((A) => A + A) + .join("")); + const i = parseInt(t, 16); + return [(i >> 16) & 255, (i >> 8) & 255, 255 & i]; + }), + (r.rgb.hcg = function (A) { + const e = A[0] / 255, + t = A[1] / 255, + i = A[2] / 255, + g = Math.max(Math.max(e, t), i), + r = Math.min(Math.min(e, t), i), + n = g - r; + let B, I; + return ( + (B = n < 1 ? r / (1 - n) : 0), + (I = + n <= 0 + ? 0 + : g === e + ? ((t - i) / n) % 6 + : g === t + ? 2 + (i - e) / n + : 4 + (e - t) / n), + (I /= 6), + [360 * (I %= 1), 100 * n, 100 * B] + ); + }), + (r.hsl.hcg = function (A) { + const e = A[1] / 100, + t = A[2] / 100, + i = t < 0.5 ? 2 * e * t : 2 * e * (1 - t); + let g = 0; + return ( + i < 1 && (g = (t - 0.5 * i) / (1 - i)), [A[0], 100 * i, 100 * g] + ); + }), + (r.hsv.hcg = function (A) { + const e = A[1] / 100, + t = A[2] / 100, + i = e * t; + let g = 0; + return i < 1 && (g = (t - i) / (1 - i)), [A[0], 100 * i, 100 * g]; + }), + (r.hcg.rgb = function (A) { + const e = A[0] / 360, + t = A[1] / 100, + i = A[2] / 100; + if (0 === t) return [255 * i, 255 * i, 255 * i]; + const g = [0, 0, 0], + r = (e % 1) * 6, + n = r % 1, + B = 1 - n; + let I = 0; + switch (Math.floor(r)) { + case 0: + (g[0] = 1), (g[1] = n), (g[2] = 0); + break; + case 1: + (g[0] = B), (g[1] = 1), (g[2] = 0); + break; + case 2: + (g[0] = 0), (g[1] = 1), (g[2] = n); + break; + case 3: + (g[0] = 0), (g[1] = B), (g[2] = 1); + break; + case 4: + (g[0] = n), (g[1] = 0), (g[2] = 1); + break; + default: + (g[0] = 1), (g[1] = 0), (g[2] = B); + } + return ( + (I = (1 - t) * i), + [255 * (t * g[0] + I), 255 * (t * g[1] + I), 255 * (t * g[2] + I)] + ); + }), + (r.hcg.hsv = function (A) { + const e = A[1] / 100, + t = e + (A[2] / 100) * (1 - e); + let i = 0; + return t > 0 && (i = e / t), [A[0], 100 * i, 100 * t]; + }), + (r.hcg.hsl = function (A) { + const e = A[1] / 100, + t = (A[2] / 100) * (1 - e) + 0.5 * e; + let i = 0; + return ( + t > 0 && t < 0.5 + ? (i = e / (2 * t)) + : t >= 0.5 && t < 1 && (i = e / (2 * (1 - t))), + [A[0], 100 * i, 100 * t] + ); + }), + (r.hcg.hwb = function (A) { + const e = A[1] / 100, + t = e + (A[2] / 100) * (1 - e); + return [A[0], 100 * (t - e), 100 * (1 - t)]; + }), + (r.hwb.hcg = function (A) { + const e = A[1] / 100, + t = 1 - A[2] / 100, + i = t - e; + let g = 0; + return i < 1 && (g = (t - i) / (1 - i)), [A[0], 100 * i, 100 * g]; + }), + (r.apple.rgb = function (A) { + return [ + (A[0] / 65535) * 255, + (A[1] / 65535) * 255, + (A[2] / 65535) * 255, + ]; + }), + (r.rgb.apple = function (A) { + return [ + (A[0] / 255) * 65535, + (A[1] / 255) * 65535, + (A[2] / 255) * 65535, + ]; + }), + (r.gray.rgb = function (A) { + return [(A[0] / 100) * 255, (A[0] / 100) * 255, (A[0] / 100) * 255]; + }), + (r.gray.hsl = function (A) { + return [0, 0, A[0]]; + }), + (r.gray.hsv = r.gray.hsl), + (r.gray.hwb = function (A) { + return [0, 100, A[0]]; + }), + (r.gray.cmyk = function (A) { + return [0, 0, 0, A[0]]; + }), + (r.gray.lab = function (A) { + return [A[0], 0, 0]; + }), + (r.gray.hex = function (A) { + const e = 255 & Math.round((A[0] / 100) * 255), + t = ((e << 16) + (e << 8) + e).toString(16).toUpperCase(); + return "000000".substring(t.length) + t; + }), + (r.rgb.gray = function (A) { + return [((A[0] + A[1] + A[2]) / 3 / 255) * 100]; + }); + }, + { "color-name": 319 }, + ], + 309: [ + function (A, e, t) { + const i = A("./conversions"), + g = A("./route"), + r = {}; + Object.keys(i).forEach((A) => { + (r[A] = {}), + Object.defineProperty(r[A], "channels", { value: i[A].channels }), + Object.defineProperty(r[A], "labels", { value: i[A].labels }); + const e = g(A); + Object.keys(e).forEach((t) => { + const i = e[t]; + (r[A][t] = (function (A) { + const e = function (...e) { + const t = e[0]; + if (void 0 === t || null === t) return t; + t.length > 1 && (e = t); + const i = A(e); + if ("object" == typeof i) + for (let A = i.length, e = 0; e < A; e++) + i[e] = Math.round(i[e]); + return i; + }; + return "conversion" in A && (e.conversion = A.conversion), e; + })(i)), + (r[A][t].raw = (function (A) { + const e = function (...e) { + const t = e[0]; + return void 0 === t || null === t + ? t + : (t.length > 1 && (e = t), A(e)); + }; + return "conversion" in A && (e.conversion = A.conversion), e; + })(i)); + }); + }), + (e.exports = r); + }, + { "./conversions": 308, "./route": 310 }, + ], + 310: [ + function (A, e, t) { + const i = A("./conversions"); + function g(A) { + const e = (function () { + const A = {}, + e = Object.keys(i); + for (let t = e.length, i = 0; i < t; i++) + A[e[i]] = { distance: -1, parent: null }; + return A; + })(), + t = [A]; + for (e[A].distance = 0; t.length; ) { + const A = t.pop(), + g = Object.keys(i[A]); + for (let i = g.length, r = 0; r < i; r++) { + const i = g[r], + n = e[i]; + -1 === n.distance && + ((n.distance = e[A].distance + 1), + (n.parent = A), + t.unshift(i)); + } + } + return e; + } + function r(A, e) { + return function (t) { + return e(A(t)); + }; + } + function n(A, e) { + const t = [e[A].parent, A]; + let g = i[e[A].parent][A], + n = e[A].parent; + for (; e[n].parent; ) + t.unshift(e[n].parent), + (g = r(i[e[n].parent][n], g)), + (n = e[n].parent); + return (g.conversion = t), g; + } + e.exports = function (A) { + const e = g(A), + t = {}, + i = Object.keys(e); + for (let A = i.length, g = 0; g < A; g++) { + const A = i[g]; + null !== e[A].parent && (t[A] = n(A, e)); + } + return t; + }; + }, + { "./conversions": 308 }, + ], + 311: [ + function (A, e, t) { + "use strict"; + var i = A("safe-buffer").Buffer; + e.exports = function (A) { + if (A.length >= 255) throw new TypeError("Alphabet too long"); + for (var e = new Uint8Array(256), t = 0; t < e.length; t++) + e[t] = 255; + for (var g = 0; g < A.length; g++) { + var r = A.charAt(g), + n = r.charCodeAt(0); + if (255 !== e[n]) throw new TypeError(r + " is ambiguous"); + e[n] = g; + } + var B = A.length, + I = A.charAt(0), + o = Math.log(B) / Math.log(256), + a = Math.log(256) / Math.log(B); + function Q(A) { + if ("string" != typeof A) throw new TypeError("Expected String"); + if (0 === A.length) return i.alloc(0); + var t = 0; + if (" " !== A[t]) { + for (var g = 0, r = 0; A[t] === I; ) g++, t++; + for ( + var n = ((A.length - t) * o + 1) >>> 0, a = new Uint8Array(n); + A[t]; + + ) { + var Q = e[A.charCodeAt(t)]; + if (255 === Q) return; + for ( + var C = 0, s = n - 1; + (0 !== Q || C < r) && -1 !== s; + s--, C++ + ) + (Q += (B * a[s]) >>> 0), + (a[s] = Q % 256 >>> 0), + (Q = (Q / 256) >>> 0); + if (0 !== Q) throw new Error("Non-zero carry"); + (r = C), t++; + } + if (" " !== A[t]) { + for (var c = n - r; c !== n && 0 === a[c]; ) c++; + var h = i.allocUnsafe(g + (n - c)); + h.fill(0, 0, g); + for (var f = g; c !== n; ) h[f++] = a[c++]; + return h; + } + } + } + return { + encode: function (e) { + if ( + ((Array.isArray(e) || e instanceof Uint8Array) && + (e = i.from(e)), + !i.isBuffer(e)) + ) + throw new TypeError("Expected Buffer"); + if (0 === e.length) return ""; + for ( + var t = 0, g = 0, r = 0, n = e.length; + r !== n && 0 === e[r]; + + ) + r++, t++; + for ( + var o = ((n - r) * a + 1) >>> 0, Q = new Uint8Array(o); + r !== n; + + ) { + for ( + var C = e[r], s = 0, c = o - 1; + (0 !== C || s < g) && -1 !== c; + c--, s++ + ) + (C += (256 * Q[c]) >>> 0), + (Q[c] = C % B >>> 0), + (C = (C / B) >>> 0); + if (0 !== C) throw new Error("Non-zero carry"); + (g = s), r++; + } + for (var h = o - g; h !== o && 0 === Q[h]; ) h++; + for (var f = I.repeat(t); h < o; ++h) f += A.charAt(Q[h]); + return f; + }, + decodeUnsafe: Q, + decode: function (A) { + var e = Q(A); + if (e) return e; + throw new Error("Non-base" + B + " character"); + }, + }; + }; + }, + { "safe-buffer": 321 }, + ], + 312: [ + function (A, e, t) { + var i = A("./util"); + function g(A, e, t) { + var i = A[e] + A[t], + g = A[e + 1] + A[t + 1]; + i >= 4294967296 && g++, (A[e] = i), (A[e + 1] = g); + } + function r(A, e, t, i) { + var g = A[e] + t; + t < 0 && (g += 4294967296); + var r = A[e + 1] + i; + g >= 4294967296 && r++, (A[e] = g), (A[e + 1] = r); + } + function n(A, e) { + return A[e] ^ (A[e + 1] << 8) ^ (A[e + 2] << 16) ^ (A[e + 3] << 24); + } + function B(A, e, t, i, n, B) { + var I = Q[n], + o = Q[n + 1], + C = Q[B], + s = Q[B + 1]; + g(a, A, e), r(a, A, I, o); + var c = a[i] ^ a[A], + h = a[i + 1] ^ a[A + 1]; + (a[i] = h), + (a[i + 1] = c), + g(a, t, i), + (c = a[e] ^ a[t]), + (h = a[e + 1] ^ a[t + 1]), + (a[e] = (c >>> 24) ^ (h << 8)), + (a[e + 1] = (h >>> 24) ^ (c << 8)), + g(a, A, e), + r(a, A, C, s), + (c = a[i] ^ a[A]), + (h = a[i + 1] ^ a[A + 1]), + (a[i] = (c >>> 16) ^ (h << 16)), + (a[i + 1] = (h >>> 16) ^ (c << 16)), + g(a, t, i), + (c = a[e] ^ a[t]), + (h = a[e + 1] ^ a[t + 1]), + (a[e] = (h >>> 31) ^ (c << 1)), + (a[e + 1] = (c >>> 31) ^ (h << 1)); + } + var I = new Uint32Array([ + 4089235720, 1779033703, 2227873595, 3144134277, 4271175723, + 1013904242, 1595750129, 2773480762, 2917565137, 1359893119, + 725511199, 2600822924, 4215389547, 528734635, 327033209, 1541459225, + ]), + o = new Uint8Array( + [ + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 14, 10, 4, + 8, 9, 15, 13, 6, 1, 12, 0, 2, 11, 7, 5, 3, 11, 8, 12, 0, 5, 2, 15, + 13, 10, 14, 3, 6, 7, 1, 9, 4, 7, 9, 3, 1, 13, 12, 11, 14, 2, 6, 5, + 10, 4, 0, 15, 8, 9, 0, 5, 7, 2, 4, 10, 15, 14, 1, 11, 12, 6, 8, 3, + 13, 2, 12, 6, 10, 0, 11, 8, 3, 4, 13, 7, 5, 15, 14, 1, 9, 12, 5, + 1, 15, 14, 13, 4, 10, 0, 7, 6, 3, 9, 2, 8, 11, 13, 11, 7, 14, 12, + 1, 3, 9, 5, 0, 15, 4, 8, 6, 2, 10, 6, 15, 14, 9, 11, 3, 0, 8, 12, + 2, 13, 7, 1, 4, 10, 5, 10, 2, 8, 4, 7, 6, 1, 5, 15, 11, 9, 14, 3, + 12, 13, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, + 14, 10, 4, 8, 9, 15, 13, 6, 1, 12, 0, 2, 11, 7, 5, 3, + ].map(function (A) { + return 2 * A; + }) + ), + a = new Uint32Array(32), + Q = new Uint32Array(32); + function C(A, e) { + var t = 0; + for (t = 0; t < 16; t++) (a[t] = A.h[t]), (a[t + 16] = I[t]); + for ( + a[24] = a[24] ^ A.t, + a[25] = a[25] ^ (A.t / 4294967296), + e && ((a[28] = ~a[28]), (a[29] = ~a[29])), + t = 0; + t < 32; + t++ + ) + Q[t] = n(A.b, 4 * t); + for (t = 0; t < 12; t++) + B(0, 8, 16, 24, o[16 * t + 0], o[16 * t + 1]), + B(2, 10, 18, 26, o[16 * t + 2], o[16 * t + 3]), + B(4, 12, 20, 28, o[16 * t + 4], o[16 * t + 5]), + B(6, 14, 22, 30, o[16 * t + 6], o[16 * t + 7]), + B(0, 10, 20, 30, o[16 * t + 8], o[16 * t + 9]), + B(2, 12, 22, 24, o[16 * t + 10], o[16 * t + 11]), + B(4, 14, 16, 26, o[16 * t + 12], o[16 * t + 13]), + B(6, 8, 18, 28, o[16 * t + 14], o[16 * t + 15]); + for (t = 0; t < 16; t++) A.h[t] = A.h[t] ^ a[t] ^ a[t + 16]; + } + function s(A, e) { + if (0 === A || A > 64) + throw new Error("Illegal output length, expected 0 < length <= 64"); + if (e && e.length > 64) + throw new Error( + "Illegal key, expected Uint8Array with 0 < length <= 64" + ); + for ( + var t = { + b: new Uint8Array(128), + h: new Uint32Array(16), + t: 0, + c: 0, + outlen: A, + }, + i = 0; + i < 16; + i++ + ) + t.h[i] = I[i]; + var g = e ? e.length : 0; + return ( + (t.h[0] ^= 16842752 ^ (g << 8) ^ A), e && (c(t, e), (t.c = 128)), t + ); + } + function c(A, e) { + for (var t = 0; t < e.length; t++) + 128 === A.c && ((A.t += A.c), C(A, !1), (A.c = 0)), + (A.b[A.c++] = e[t]); + } + function h(A) { + for (A.t += A.c; A.c < 128; ) A.b[A.c++] = 0; + C(A, !0); + for (var e = new Uint8Array(A.outlen), t = 0; t < A.outlen; t++) + e[t] = A.h[t >> 2] >> (8 * (3 & t)); + return e; + } + function f(A, e, t) { + (t = t || 64), (A = i.normalizeInput(A)); + var g = s(t, e); + return c(g, A), h(g); + } + e.exports = { + blake2b: f, + blake2bHex: function (A, e, t) { + var g = f(A, e, t); + return i.toHex(g); + }, + blake2bInit: s, + blake2bUpdate: c, + blake2bFinal: h, + }; + }, + { "./util": 315 }, + ], + 313: [ + function (A, e, t) { + var i = A("./util"); + function g(A, e) { + return A[e] ^ (A[e + 1] << 8) ^ (A[e + 2] << 16) ^ (A[e + 3] << 24); + } + function r(A, e, t, i, g, r) { + (o[A] = o[A] + o[e] + g), + (o[i] = n(o[i] ^ o[A], 16)), + (o[t] = o[t] + o[i]), + (o[e] = n(o[e] ^ o[t], 12)), + (o[A] = o[A] + o[e] + r), + (o[i] = n(o[i] ^ o[A], 8)), + (o[t] = o[t] + o[i]), + (o[e] = n(o[e] ^ o[t], 7)); + } + function n(A, e) { + return (A >>> e) ^ (A << (32 - e)); + } + var B = new Uint32Array([ + 1779033703, 3144134277, 1013904242, 2773480762, 1359893119, + 2600822924, 528734635, 1541459225, + ]), + I = new Uint8Array([ + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 14, 10, 4, 8, + 9, 15, 13, 6, 1, 12, 0, 2, 11, 7, 5, 3, 11, 8, 12, 0, 5, 2, 15, 13, + 10, 14, 3, 6, 7, 1, 9, 4, 7, 9, 3, 1, 13, 12, 11, 14, 2, 6, 5, 10, + 4, 0, 15, 8, 9, 0, 5, 7, 2, 4, 10, 15, 14, 1, 11, 12, 6, 8, 3, 13, + 2, 12, 6, 10, 0, 11, 8, 3, 4, 13, 7, 5, 15, 14, 1, 9, 12, 5, 1, 15, + 14, 13, 4, 10, 0, 7, 6, 3, 9, 2, 8, 11, 13, 11, 7, 14, 12, 1, 3, 9, + 5, 0, 15, 4, 8, 6, 2, 10, 6, 15, 14, 9, 11, 3, 0, 8, 12, 2, 13, 7, + 1, 4, 10, 5, 10, 2, 8, 4, 7, 6, 1, 5, 15, 11, 9, 14, 3, 12, 13, 0, + ]), + o = new Uint32Array(16), + a = new Uint32Array(16); + function Q(A, e) { + var t = 0; + for (t = 0; t < 8; t++) (o[t] = A.h[t]), (o[t + 8] = B[t]); + for ( + o[12] ^= A.t, + o[13] ^= A.t / 4294967296, + e && (o[14] = ~o[14]), + t = 0; + t < 16; + t++ + ) + a[t] = g(A.b, 4 * t); + for (t = 0; t < 10; t++) + r(0, 4, 8, 12, a[I[16 * t + 0]], a[I[16 * t + 1]]), + r(1, 5, 9, 13, a[I[16 * t + 2]], a[I[16 * t + 3]]), + r(2, 6, 10, 14, a[I[16 * t + 4]], a[I[16 * t + 5]]), + r(3, 7, 11, 15, a[I[16 * t + 6]], a[I[16 * t + 7]]), + r(0, 5, 10, 15, a[I[16 * t + 8]], a[I[16 * t + 9]]), + r(1, 6, 11, 12, a[I[16 * t + 10]], a[I[16 * t + 11]]), + r(2, 7, 8, 13, a[I[16 * t + 12]], a[I[16 * t + 13]]), + r(3, 4, 9, 14, a[I[16 * t + 14]], a[I[16 * t + 15]]); + for (t = 0; t < 8; t++) A.h[t] ^= o[t] ^ o[t + 8]; + } + function C(A, e) { + if (!(A > 0 && A <= 32)) + throw new Error("Incorrect output length, should be in [1, 32]"); + var t = e ? e.length : 0; + if (e && !(t > 0 && t <= 32)) + throw new Error("Incorrect key length, should be in [1, 32]"); + var i = { + h: new Uint32Array(B), + b: new Uint32Array(64), + c: 0, + t: 0, + outlen: A, + }; + return ( + (i.h[0] ^= 16842752 ^ (t << 8) ^ A), + t > 0 && (s(i, e), (i.c = 64)), + i + ); + } + function s(A, e) { + for (var t = 0; t < e.length; t++) + 64 === A.c && ((A.t += A.c), Q(A, !1), (A.c = 0)), + (A.b[A.c++] = e[t]); + } + function c(A) { + for (A.t += A.c; A.c < 64; ) A.b[A.c++] = 0; + Q(A, !0); + for (var e = new Uint8Array(A.outlen), t = 0; t < A.outlen; t++) + e[t] = (A.h[t >> 2] >> (8 * (3 & t))) & 255; + return e; + } + function h(A, e, t) { + (t = t || 32), (A = i.normalizeInput(A)); + var g = C(t, e); + return s(g, A), c(g); + } + e.exports = { + blake2s: h, + blake2sHex: function (A, e, t) { + var g = h(A, e, t); + return i.toHex(g); + }, + blake2sInit: C, + blake2sUpdate: s, + blake2sFinal: c, + }; + }, + { "./util": 315 }, + ], + 314: [ + function (A, e, t) { + var i = A("./blake2b"), + g = A("./blake2s"); + e.exports = { + blake2b: i.blake2b, + blake2bHex: i.blake2bHex, + blake2bInit: i.blake2bInit, + blake2bUpdate: i.blake2bUpdate, + blake2bFinal: i.blake2bFinal, + blake2s: g.blake2s, + blake2sHex: g.blake2sHex, + blake2sInit: g.blake2sInit, + blake2sUpdate: g.blake2sUpdate, + blake2sFinal: g.blake2sFinal, + }; + }, + { "./blake2b": 312, "./blake2s": 313 }, + ], + 315: [ + function (A, e, t) { + (function (A) { + var t = "Input must be an string, Buffer or Uint8Array"; + function i(A) { + return (4294967296 + A).toString(16).substring(1); + } + e.exports = { + normalizeInput: function (e) { + var i; + if (e instanceof Uint8Array) i = e; + else if (e instanceof A) i = new Uint8Array(e); + else { + if ("string" != typeof e) throw new Error(t); + i = new Uint8Array(A.from(e, "utf8")); + } + return i; + }, + toHex: function (A) { + return Array.prototype.map + .call(A, function (A) { + return (A < 16 ? "0" : "") + A.toString(16); + }) + .join(""); + }, + debugPrint: function (A, e, t) { + for (var g = "\n" + A + " = ", r = 0; r < e.length; r += 2) { + if (32 === t) + (g += i(e[r]).toUpperCase()), + (g += " "), + (g += i(e[r + 1]).toUpperCase()); + else { + if (64 !== t) throw new Error("Invalid size " + t); + (g += i(e[r + 1]).toUpperCase()), + (g += i(e[r]).toUpperCase()); + } + r % 6 == 4 + ? (g += "\n" + new Array(A.length + 4).join(" ")) + : r < e.length - 2 && (g += " "); + } + console.log(g); + }, + testSpeed: function (A, e, t) { + for ( + var i = new Date().getTime(), g = new Uint8Array(e), r = 0; + r < e; + r++ + ) + g[r] = r % 256; + var n = new Date().getTime(); + for ( + console.log("Generated random input in " + (n - i) + "ms"), + i = n, + r = 0; + r < t; + r++ + ) { + var B = A(g), + I = new Date().getTime(), + o = I - i; + (i = I), + console.log( + "Hashed in " + o + "ms: " + B.substring(0, 20) + "..." + ), + console.log( + Math.round((e / (1 << 20) / (o / 1e3)) * 100) / 100 + + " MB PER SECOND" + ); + } + }, + }; + }.call(this, A("buffer").Buffer)); + }, + { buffer: 64 }, + ], + 316: [ + function (A, e, t) { + !(function (e, t) { + "use strict"; + function i(A, e) { + if (!A) throw new Error(e || "Assertion failed"); + } + function g(A, e) { + A.super_ = e; + var t = function () {}; + (t.prototype = e.prototype), + (A.prototype = new t()), + (A.prototype.constructor = A); + } + function r(A, e, t) { + if (r.isBN(A)) return A; + (this.negative = 0), + (this.words = null), + (this.length = 0), + (this.red = null), + null !== A && + (("le" !== e && "be" !== e) || ((t = e), (e = 10)), + this._init(A || 0, e || 10, t || "be")); + } + var n; + "object" == typeof e ? (e.exports = r) : (t.BN = r), + (r.BN = r), + (r.wordSize = 26); + try { + n = A("buffer").Buffer; + } catch (A) {} + function B(A, e, t) { + for ( + var g = 0, r = Math.min(A.length, t), n = 0, B = e; + B < r; + B++ + ) { + var I, + o = A.charCodeAt(B) - 48; + (g <<= 4), + (g |= I = + o >= 49 && o <= 54 + ? o - 49 + 10 + : o >= 17 && o <= 22 + ? o - 17 + 10 + : o), + (n |= I); + } + return i(!(240 & n), "Invalid character in " + A), g; + } + function I(A, e, t, g) { + for ( + var r = 0, n = 0, B = Math.min(A.length, t), I = e; + I < B; + I++ + ) { + var o = A.charCodeAt(I) - 48; + (r *= g), + (n = o >= 49 ? o - 49 + 10 : o >= 17 ? o - 17 + 10 : o), + i(o >= 0 && n < g, "Invalid character"), + (r += n); + } + return r; + } + function o(A, e) { + (A.words = e.words), + (A.length = e.length), + (A.negative = e.negative), + (A.red = e.red); + } + function a() { + return (this.red ? ""; + } + (r.isBN = function (A) { + return ( + A instanceof r || + (null !== A && + "object" == typeof A && + A.constructor.wordSize === r.wordSize && + Array.isArray(A.words)) + ); + }), + (r.max = function (A, e) { + return A.cmp(e) > 0 ? A : e; + }), + (r.min = function (A, e) { + return A.cmp(e) < 0 ? A : e; + }), + (r.prototype._init = function (A, e, t) { + if ("number" == typeof A) return this._initNumber(A, e, t); + if ("object" == typeof A) return this._initArray(A, e, t); + "hex" === e && (e = 16), i(e === (0 | e) && e >= 2 && e <= 36); + var g = 0; + "-" === (A = A.toString().replace(/\s+/g, ""))[0] && g++, + 16 === e ? this._parseHex(A, g) : this._parseBase(A, e, g), + "-" === A[0] && (this.negative = 1), + this._strip(), + "le" === t && this._initArray(this.toArray(), e, t); + }), + (r.prototype._initNumber = function (A, e, t) { + A < 0 && ((this.negative = 1), (A = -A)), + A < 67108864 + ? ((this.words = [67108863 & A]), (this.length = 1)) + : A < 4503599627370496 + ? ((this.words = [67108863 & A, (A / 67108864) & 67108863]), + (this.length = 2)) + : (i(A < 9007199254740992), + (this.words = [67108863 & A, (A / 67108864) & 67108863, 1]), + (this.length = 3)), + "le" === t && this._initArray(this.toArray(), e, t); + }), + (r.prototype._initArray = function (A, e, t) { + if ((i("number" == typeof A.length), A.length <= 0)) + return (this.words = [0]), (this.length = 1), this; + (this.length = Math.ceil(A.length / 3)), + (this.words = new Array(this.length)); + for (var g = 0; g < this.length; g++) this.words[g] = 0; + var r, + n, + B = 0; + if ("be" === t) + for (g = A.length - 1, r = 0; g >= 0; g -= 3) + (n = A[g] | (A[g - 1] << 8) | (A[g - 2] << 16)), + (this.words[r] |= (n << B) & 67108863), + (this.words[r + 1] = (n >>> (26 - B)) & 67108863), + (B += 24) >= 26 && ((B -= 26), r++); + else if ("le" === t) + for (g = 0, r = 0; g < A.length; g += 3) + (n = A[g] | (A[g + 1] << 8) | (A[g + 2] << 16)), + (this.words[r] |= (n << B) & 67108863), + (this.words[r + 1] = (n >>> (26 - B)) & 67108863), + (B += 24) >= 26 && ((B -= 26), r++); + return this._strip(); + }), + (r.prototype._parseHex = function (A, e) { + (this.length = Math.ceil((A.length - e) / 6)), + (this.words = new Array(this.length)); + for (var t = 0; t < this.length; t++) this.words[t] = 0; + var i, + g, + r = 0; + for (t = A.length - 6, i = 0; t >= e; t -= 6) + (g = B(A, t, t + 6)), + (this.words[i] |= (g << r) & 67108863), + (this.words[i + 1] |= (g >>> (26 - r)) & 4194303), + (r += 24) >= 26 && ((r -= 26), i++); + t + 6 !== e && + ((g = B(A, e, t + 6)), + (this.words[i] |= (g << r) & 67108863), + (this.words[i + 1] |= (g >>> (26 - r)) & 4194303)), + this._strip(); + }), + (r.prototype._parseBase = function (A, e, t) { + (this.words = [0]), (this.length = 1); + for (var i = 0, g = 1; g <= 67108863; g *= e) i++; + i--, (g = (g / e) | 0); + for ( + var r = A.length - t, + n = r % i, + B = Math.min(r, r - n) + t, + o = 0, + a = t; + a < B; + a += i + ) + (o = I(A, a, a + i, e)), + this.imuln(g), + this.words[0] + o < 67108864 + ? (this.words[0] += o) + : this._iaddn(o); + if (0 !== n) { + var Q = 1; + for (o = I(A, a, A.length, e), a = 0; a < n; a++) Q *= e; + this.imuln(Q), + this.words[0] + o < 67108864 + ? (this.words[0] += o) + : this._iaddn(o); + } + }), + (r.prototype.copy = function (A) { + A.words = new Array(this.length); + for (var e = 0; e < this.length; e++) A.words[e] = this.words[e]; + (A.length = this.length), + (A.negative = this.negative), + (A.red = this.red); + }), + (r.prototype._move = function (A) { + o(A, this); + }), + (r.prototype.clone = function () { + var A = new r(null); + return this.copy(A), A; + }), + (r.prototype._expand = function (A) { + for (; this.length < A; ) this.words[this.length++] = 0; + return this; + }), + (r.prototype._strip = function () { + for (; this.length > 1 && 0 === this.words[this.length - 1]; ) + this.length--; + return this._normSign(); + }), + (r.prototype._normSign = function () { + return ( + 1 === this.length && 0 === this.words[0] && (this.negative = 0), + this + ); + }), + "undefined" != typeof Symbol && "function" == typeof Symbol.for + ? (r.prototype[Symbol.for("nodejs.util.inspect.custom")] = a) + : (r.prototype.inspect = a); + var Q = [ + "", + "0", + "00", + "000", + "0000", + "00000", + "000000", + "0000000", + "00000000", + "000000000", + "0000000000", + "00000000000", + "000000000000", + "0000000000000", + "00000000000000", + "000000000000000", + "0000000000000000", + "00000000000000000", + "000000000000000000", + "0000000000000000000", + "00000000000000000000", + "000000000000000000000", + "0000000000000000000000", + "00000000000000000000000", + "000000000000000000000000", + "0000000000000000000000000", + ], + C = [ + 0, 0, 25, 16, 12, 11, 10, 9, 8, 8, 7, 7, 7, 7, 6, 6, 6, 6, 6, 6, + 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, + ], + s = [ + 0, 0, 33554432, 43046721, 16777216, 48828125, 60466176, 40353607, + 16777216, 43046721, 1e7, 19487171, 35831808, 62748517, 7529536, + 11390625, 16777216, 24137569, 34012224, 47045881, 64e6, 4084101, + 5153632, 6436343, 7962624, 9765625, 11881376, 14348907, 17210368, + 20511149, 243e5, 28629151, 33554432, 39135393, 45435424, 52521875, + 60466176, + ]; + (r.prototype.toString = function (A, e) { + var t; + if (((A = A || 10), (e = 0 | e || 1), 16 === A || "hex" === A)) { + t = ""; + for (var g = 0, r = 0, n = 0; n < this.length; n++) { + var B = this.words[n], + I = (16777215 & ((B << g) | r)).toString(16); + (t = + 0 !== (r = (B >>> (24 - g)) & 16777215) || + n !== this.length - 1 + ? Q[6 - I.length] + I + t + : I + t), + (g += 2) >= 26 && ((g -= 26), n--); + } + for (0 !== r && (t = r.toString(16) + t); t.length % e != 0; ) + t = "0" + t; + return 0 !== this.negative && (t = "-" + t), t; + } + if (A === (0 | A) && A >= 2 && A <= 36) { + var o = C[A], + a = s[A]; + t = ""; + var c = this.clone(); + for (c.negative = 0; !c.isZero(); ) { + var h = c.modrn(a).toString(A); + t = (c = c.idivn(a)).isZero() ? h + t : Q[o - h.length] + h + t; + } + for (this.isZero() && (t = "0" + t); t.length % e != 0; ) + t = "0" + t; + return 0 !== this.negative && (t = "-" + t), t; + } + i(!1, "Base should be between 2 and 36"); + }), + (r.prototype.toNumber = function () { + var A = this.words[0]; + return ( + 2 === this.length + ? (A += 67108864 * this.words[1]) + : 3 === this.length && 1 === this.words[2] + ? (A += 4503599627370496 + 67108864 * this.words[1]) + : this.length > 2 && + i(!1, "Number can only safely store up to 53 bits"), + 0 !== this.negative ? -A : A + ); + }), + (r.prototype.toJSON = function () { + return this.toString(16, 2); + }), + n && + (r.prototype.toBuffer = function (A, e) { + return this.toArrayLike(n, A, e); + }), + (r.prototype.toArray = function (A, e) { + return this.toArrayLike(Array, A, e); + }); + function c(A, e, t) { + t.negative = e.negative ^ A.negative; + var i = (A.length + e.length) | 0; + (t.length = i), (i = (i - 1) | 0); + var g = 0 | A.words[0], + r = 0 | e.words[0], + n = g * r, + B = 67108863 & n, + I = (n / 67108864) | 0; + t.words[0] = B; + for (var o = 1; o < i; o++) { + for ( + var a = I >>> 26, + Q = 67108863 & I, + C = Math.min(o, e.length - 1), + s = Math.max(0, o - A.length + 1); + s <= C; + s++ + ) { + var c = (o - s) | 0; + (a += + ((n = (g = 0 | A.words[c]) * (r = 0 | e.words[s]) + Q) / + 67108864) | + 0), + (Q = 67108863 & n); + } + (t.words[o] = 0 | Q), (I = 0 | a); + } + return 0 !== I ? (t.words[o] = 0 | I) : t.length--, t._strip(); + } + (r.prototype.toArrayLike = function (A, e, t) { + this._strip(); + var g = this.byteLength(), + r = t || Math.max(1, g); + i(g <= r, "byte array longer than desired length"), + i(r > 0, "Requested array length <= 0"); + var n = (function (A, e) { + return A.allocUnsafe ? A.allocUnsafe(e) : new A(e); + })(A, r); + return this["_toArrayLike" + ("le" === e ? "LE" : "BE")](n, g), n; + }), + (r.prototype._toArrayLikeLE = function (A, e) { + for (var t = 0, i = 0, g = 0, r = 0; g < this.length; g++) { + var n = (this.words[g] << r) | i; + (A[t++] = 255 & n), + t < A.length && (A[t++] = (n >> 8) & 255), + t < A.length && (A[t++] = (n >> 16) & 255), + 6 === r + ? (t < A.length && (A[t++] = (n >> 24) & 255), + (i = 0), + (r = 0)) + : ((i = n >>> 24), (r += 2)); + } + if (t < A.length) for (A[t++] = i; t < A.length; ) A[t++] = 0; + }), + (r.prototype._toArrayLikeBE = function (A, e) { + for ( + var t = A.length - 1, i = 0, g = 0, r = 0; + g < this.length; + g++ + ) { + var n = (this.words[g] << r) | i; + (A[t--] = 255 & n), + t >= 0 && (A[t--] = (n >> 8) & 255), + t >= 0 && (A[t--] = (n >> 16) & 255), + 6 === r + ? (t >= 0 && (A[t--] = (n >> 24) & 255), (i = 0), (r = 0)) + : ((i = n >>> 24), (r += 2)); + } + if (t >= 0) for (A[t--] = i; t >= 0; ) A[t--] = 0; + }), + Math.clz32 + ? (r.prototype._countBits = function (A) { + return 32 - Math.clz32(A); + }) + : (r.prototype._countBits = function (A) { + var e = A, + t = 0; + return ( + e >= 4096 && ((t += 13), (e >>>= 13)), + e >= 64 && ((t += 7), (e >>>= 7)), + e >= 8 && ((t += 4), (e >>>= 4)), + e >= 2 && ((t += 2), (e >>>= 2)), + t + e + ); + }), + (r.prototype._zeroBits = function (A) { + if (0 === A) return 26; + var e = A, + t = 0; + return ( + 0 == (8191 & e) && ((t += 13), (e >>>= 13)), + 0 == (127 & e) && ((t += 7), (e >>>= 7)), + 0 == (15 & e) && ((t += 4), (e >>>= 4)), + 0 == (3 & e) && ((t += 2), (e >>>= 2)), + 0 == (1 & e) && t++, + t + ); + }), + (r.prototype.bitLength = function () { + var A = this.words[this.length - 1], + e = this._countBits(A); + return 26 * (this.length - 1) + e; + }), + (r.prototype.zeroBits = function () { + if (this.isZero()) return 0; + for (var A = 0, e = 0; e < this.length; e++) { + var t = this._zeroBits(this.words[e]); + if (((A += t), 26 !== t)) break; + } + return A; + }), + (r.prototype.byteLength = function () { + return Math.ceil(this.bitLength() / 8); + }), + (r.prototype.toTwos = function (A) { + return 0 !== this.negative + ? this.abs().inotn(A).iaddn(1) + : this.clone(); + }), + (r.prototype.fromTwos = function (A) { + return this.testn(A - 1) + ? this.notn(A).iaddn(1).ineg() + : this.clone(); + }), + (r.prototype.isNeg = function () { + return 0 !== this.negative; + }), + (r.prototype.neg = function () { + return this.clone().ineg(); + }), + (r.prototype.ineg = function () { + return this.isZero() || (this.negative ^= 1), this; + }), + (r.prototype.iuor = function (A) { + for (; this.length < A.length; ) this.words[this.length++] = 0; + for (var e = 0; e < A.length; e++) + this.words[e] = this.words[e] | A.words[e]; + return this._strip(); + }), + (r.prototype.ior = function (A) { + return i(0 == (this.negative | A.negative)), this.iuor(A); + }), + (r.prototype.or = function (A) { + return this.length > A.length + ? this.clone().ior(A) + : A.clone().ior(this); + }), + (r.prototype.uor = function (A) { + return this.length > A.length + ? this.clone().iuor(A) + : A.clone().iuor(this); + }), + (r.prototype.iuand = function (A) { + var e; + e = this.length > A.length ? A : this; + for (var t = 0; t < e.length; t++) + this.words[t] = this.words[t] & A.words[t]; + return (this.length = e.length), this._strip(); + }), + (r.prototype.iand = function (A) { + return i(0 == (this.negative | A.negative)), this.iuand(A); + }), + (r.prototype.and = function (A) { + return this.length > A.length + ? this.clone().iand(A) + : A.clone().iand(this); + }), + (r.prototype.uand = function (A) { + return this.length > A.length + ? this.clone().iuand(A) + : A.clone().iuand(this); + }), + (r.prototype.iuxor = function (A) { + var e, t; + this.length > A.length + ? ((e = this), (t = A)) + : ((e = A), (t = this)); + for (var i = 0; i < t.length; i++) + this.words[i] = e.words[i] ^ t.words[i]; + if (this !== e) + for (; i < e.length; i++) this.words[i] = e.words[i]; + return (this.length = e.length), this._strip(); + }), + (r.prototype.ixor = function (A) { + return i(0 == (this.negative | A.negative)), this.iuxor(A); + }), + (r.prototype.xor = function (A) { + return this.length > A.length + ? this.clone().ixor(A) + : A.clone().ixor(this); + }), + (r.prototype.uxor = function (A) { + return this.length > A.length + ? this.clone().iuxor(A) + : A.clone().iuxor(this); + }), + (r.prototype.inotn = function (A) { + i("number" == typeof A && A >= 0); + var e = 0 | Math.ceil(A / 26), + t = A % 26; + this._expand(e), t > 0 && e--; + for (var g = 0; g < e; g++) + this.words[g] = 67108863 & ~this.words[g]; + return ( + t > 0 && + (this.words[g] = ~this.words[g] & (67108863 >> (26 - t))), + this._strip() + ); + }), + (r.prototype.notn = function (A) { + return this.clone().inotn(A); + }), + (r.prototype.setn = function (A, e) { + i("number" == typeof A && A >= 0); + var t = (A / 26) | 0, + g = A % 26; + return ( + this._expand(t + 1), + (this.words[t] = e + ? this.words[t] | (1 << g) + : this.words[t] & ~(1 << g)), + this._strip() + ); + }), + (r.prototype.iadd = function (A) { + var e, t, i; + if (0 !== this.negative && 0 === A.negative) + return ( + (this.negative = 0), + (e = this.isub(A)), + (this.negative ^= 1), + this._normSign() + ); + if (0 === this.negative && 0 !== A.negative) + return ( + (A.negative = 0), + (e = this.isub(A)), + (A.negative = 1), + e._normSign() + ); + this.length > A.length + ? ((t = this), (i = A)) + : ((t = A), (i = this)); + for (var g = 0, r = 0; r < i.length; r++) + (e = (0 | t.words[r]) + (0 | i.words[r]) + g), + (this.words[r] = 67108863 & e), + (g = e >>> 26); + for (; 0 !== g && r < t.length; r++) + (e = (0 | t.words[r]) + g), + (this.words[r] = 67108863 & e), + (g = e >>> 26); + if (((this.length = t.length), 0 !== g)) + (this.words[this.length] = g), this.length++; + else if (t !== this) + for (; r < t.length; r++) this.words[r] = t.words[r]; + return this; + }), + (r.prototype.add = function (A) { + var e; + return 0 !== A.negative && 0 === this.negative + ? ((A.negative = 0), (e = this.sub(A)), (A.negative ^= 1), e) + : 0 === A.negative && 0 !== this.negative + ? ((this.negative = 0), + (e = A.sub(this)), + (this.negative = 1), + e) + : this.length > A.length + ? this.clone().iadd(A) + : A.clone().iadd(this); + }), + (r.prototype.isub = function (A) { + if (0 !== A.negative) { + A.negative = 0; + var e = this.iadd(A); + return (A.negative = 1), e._normSign(); + } + if (0 !== this.negative) + return ( + (this.negative = 0), + this.iadd(A), + (this.negative = 1), + this._normSign() + ); + var t, + i, + g = this.cmp(A); + if (0 === g) + return ( + (this.negative = 0), + (this.length = 1), + (this.words[0] = 0), + this + ); + g > 0 ? ((t = this), (i = A)) : ((t = A), (i = this)); + for (var r = 0, n = 0; n < i.length; n++) + (r = (e = (0 | t.words[n]) - (0 | i.words[n]) + r) >> 26), + (this.words[n] = 67108863 & e); + for (; 0 !== r && n < t.length; n++) + (r = (e = (0 | t.words[n]) + r) >> 26), + (this.words[n] = 67108863 & e); + if (0 === r && n < t.length && t !== this) + for (; n < t.length; n++) this.words[n] = t.words[n]; + return ( + (this.length = Math.max(this.length, n)), + t !== this && (this.negative = 1), + this._strip() + ); + }), + (r.prototype.sub = function (A) { + return this.clone().isub(A); + }); + var h = function (A, e, t) { + var i, + g, + r, + n = A.words, + B = e.words, + I = t.words, + o = 0, + a = 0 | n[0], + Q = 8191 & a, + C = a >>> 13, + s = 0 | n[1], + c = 8191 & s, + h = s >>> 13, + f = 0 | n[2], + E = 8191 & f, + u = f >>> 13, + d = 0 | n[3], + l = 8191 & d, + w = d >>> 13, + p = 0 | n[4], + D = 8191 & p, + b = p >>> 13, + y = 0 | n[5], + M = 8191 & y, + m = y >>> 13, + G = 0 | n[6], + k = 8191 & G, + F = G >>> 13, + N = 0 | n[7], + S = 8191 & N, + Y = N >>> 13, + v = 0 | n[8], + K = 8191 & v, + U = v >>> 13, + J = 0 | n[9], + H = 8191 & J, + R = J >>> 13, + q = 0 | B[0], + L = 8191 & q, + x = q >>> 13, + Z = 0 | B[1], + j = 8191 & Z, + W = Z >>> 13, + O = 0 | B[2], + P = 8191 & O, + V = O >>> 13, + X = 0 | B[3], + z = 8191 & X, + T = X >>> 13, + _ = 0 | B[4], + $ = 8191 & _, + AA = _ >>> 13, + eA = 0 | B[5], + tA = 8191 & eA, + iA = eA >>> 13, + gA = 0 | B[6], + rA = 8191 & gA, + nA = gA >>> 13, + BA = 0 | B[7], + IA = 8191 & BA, + oA = BA >>> 13, + aA = 0 | B[8], + QA = 8191 & aA, + CA = aA >>> 13, + sA = 0 | B[9], + cA = 8191 & sA, + hA = sA >>> 13; + (t.negative = A.negative ^ e.negative), (t.length = 19); + var fA = + (((o + (i = Math.imul(Q, L))) | 0) + + ((8191 & (g = ((g = Math.imul(Q, x)) + Math.imul(C, L)) | 0)) << + 13)) | + 0; + (o = + ((((r = Math.imul(C, x)) + (g >>> 13)) | 0) + (fA >>> 26)) | 0), + (fA &= 67108863), + (i = Math.imul(c, L)), + (g = ((g = Math.imul(c, x)) + Math.imul(h, L)) | 0), + (r = Math.imul(h, x)); + var EA = + (((o + (i = (i + Math.imul(Q, j)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, W)) | 0) + Math.imul(C, j)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, W)) | 0) + (g >>> 13)) | 0) + + (EA >>> 26)) | + 0), + (EA &= 67108863), + (i = Math.imul(E, L)), + (g = ((g = Math.imul(E, x)) + Math.imul(u, L)) | 0), + (r = Math.imul(u, x)), + (i = (i + Math.imul(c, j)) | 0), + (g = ((g = (g + Math.imul(c, W)) | 0) + Math.imul(h, j)) | 0), + (r = (r + Math.imul(h, W)) | 0); + var uA = + (((o + (i = (i + Math.imul(Q, P)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, V)) | 0) + Math.imul(C, P)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, V)) | 0) + (g >>> 13)) | 0) + + (uA >>> 26)) | + 0), + (uA &= 67108863), + (i = Math.imul(l, L)), + (g = ((g = Math.imul(l, x)) + Math.imul(w, L)) | 0), + (r = Math.imul(w, x)), + (i = (i + Math.imul(E, j)) | 0), + (g = ((g = (g + Math.imul(E, W)) | 0) + Math.imul(u, j)) | 0), + (r = (r + Math.imul(u, W)) | 0), + (i = (i + Math.imul(c, P)) | 0), + (g = ((g = (g + Math.imul(c, V)) | 0) + Math.imul(h, P)) | 0), + (r = (r + Math.imul(h, V)) | 0); + var dA = + (((o + (i = (i + Math.imul(Q, z)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, T)) | 0) + Math.imul(C, z)) | 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, T)) | 0) + (g >>> 13)) | 0) + + (dA >>> 26)) | + 0), + (dA &= 67108863), + (i = Math.imul(D, L)), + (g = ((g = Math.imul(D, x)) + Math.imul(b, L)) | 0), + (r = Math.imul(b, x)), + (i = (i + Math.imul(l, j)) | 0), + (g = ((g = (g + Math.imul(l, W)) | 0) + Math.imul(w, j)) | 0), + (r = (r + Math.imul(w, W)) | 0), + (i = (i + Math.imul(E, P)) | 0), + (g = ((g = (g + Math.imul(E, V)) | 0) + Math.imul(u, P)) | 0), + (r = (r + Math.imul(u, V)) | 0), + (i = (i + Math.imul(c, z)) | 0), + (g = ((g = (g + Math.imul(c, T)) | 0) + Math.imul(h, z)) | 0), + (r = (r + Math.imul(h, T)) | 0); + var lA = + (((o + (i = (i + Math.imul(Q, $)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, AA)) | 0) + Math.imul(C, $)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, AA)) | 0) + (g >>> 13)) | 0) + + (lA >>> 26)) | + 0), + (lA &= 67108863), + (i = Math.imul(M, L)), + (g = ((g = Math.imul(M, x)) + Math.imul(m, L)) | 0), + (r = Math.imul(m, x)), + (i = (i + Math.imul(D, j)) | 0), + (g = ((g = (g + Math.imul(D, W)) | 0) + Math.imul(b, j)) | 0), + (r = (r + Math.imul(b, W)) | 0), + (i = (i + Math.imul(l, P)) | 0), + (g = ((g = (g + Math.imul(l, V)) | 0) + Math.imul(w, P)) | 0), + (r = (r + Math.imul(w, V)) | 0), + (i = (i + Math.imul(E, z)) | 0), + (g = ((g = (g + Math.imul(E, T)) | 0) + Math.imul(u, z)) | 0), + (r = (r + Math.imul(u, T)) | 0), + (i = (i + Math.imul(c, $)) | 0), + (g = ((g = (g + Math.imul(c, AA)) | 0) + Math.imul(h, $)) | 0), + (r = (r + Math.imul(h, AA)) | 0); + var wA = + (((o + (i = (i + Math.imul(Q, tA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, iA)) | 0) + Math.imul(C, tA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, iA)) | 0) + (g >>> 13)) | 0) + + (wA >>> 26)) | + 0), + (wA &= 67108863), + (i = Math.imul(k, L)), + (g = ((g = Math.imul(k, x)) + Math.imul(F, L)) | 0), + (r = Math.imul(F, x)), + (i = (i + Math.imul(M, j)) | 0), + (g = ((g = (g + Math.imul(M, W)) | 0) + Math.imul(m, j)) | 0), + (r = (r + Math.imul(m, W)) | 0), + (i = (i + Math.imul(D, P)) | 0), + (g = ((g = (g + Math.imul(D, V)) | 0) + Math.imul(b, P)) | 0), + (r = (r + Math.imul(b, V)) | 0), + (i = (i + Math.imul(l, z)) | 0), + (g = ((g = (g + Math.imul(l, T)) | 0) + Math.imul(w, z)) | 0), + (r = (r + Math.imul(w, T)) | 0), + (i = (i + Math.imul(E, $)) | 0), + (g = ((g = (g + Math.imul(E, AA)) | 0) + Math.imul(u, $)) | 0), + (r = (r + Math.imul(u, AA)) | 0), + (i = (i + Math.imul(c, tA)) | 0), + (g = ((g = (g + Math.imul(c, iA)) | 0) + Math.imul(h, tA)) | 0), + (r = (r + Math.imul(h, iA)) | 0); + var pA = + (((o + (i = (i + Math.imul(Q, rA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, nA)) | 0) + Math.imul(C, rA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, nA)) | 0) + (g >>> 13)) | 0) + + (pA >>> 26)) | + 0), + (pA &= 67108863), + (i = Math.imul(S, L)), + (g = ((g = Math.imul(S, x)) + Math.imul(Y, L)) | 0), + (r = Math.imul(Y, x)), + (i = (i + Math.imul(k, j)) | 0), + (g = ((g = (g + Math.imul(k, W)) | 0) + Math.imul(F, j)) | 0), + (r = (r + Math.imul(F, W)) | 0), + (i = (i + Math.imul(M, P)) | 0), + (g = ((g = (g + Math.imul(M, V)) | 0) + Math.imul(m, P)) | 0), + (r = (r + Math.imul(m, V)) | 0), + (i = (i + Math.imul(D, z)) | 0), + (g = ((g = (g + Math.imul(D, T)) | 0) + Math.imul(b, z)) | 0), + (r = (r + Math.imul(b, T)) | 0), + (i = (i + Math.imul(l, $)) | 0), + (g = ((g = (g + Math.imul(l, AA)) | 0) + Math.imul(w, $)) | 0), + (r = (r + Math.imul(w, AA)) | 0), + (i = (i + Math.imul(E, tA)) | 0), + (g = ((g = (g + Math.imul(E, iA)) | 0) + Math.imul(u, tA)) | 0), + (r = (r + Math.imul(u, iA)) | 0), + (i = (i + Math.imul(c, rA)) | 0), + (g = ((g = (g + Math.imul(c, nA)) | 0) + Math.imul(h, rA)) | 0), + (r = (r + Math.imul(h, nA)) | 0); + var DA = + (((o + (i = (i + Math.imul(Q, IA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, oA)) | 0) + Math.imul(C, IA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, oA)) | 0) + (g >>> 13)) | 0) + + (DA >>> 26)) | + 0), + (DA &= 67108863), + (i = Math.imul(K, L)), + (g = ((g = Math.imul(K, x)) + Math.imul(U, L)) | 0), + (r = Math.imul(U, x)), + (i = (i + Math.imul(S, j)) | 0), + (g = ((g = (g + Math.imul(S, W)) | 0) + Math.imul(Y, j)) | 0), + (r = (r + Math.imul(Y, W)) | 0), + (i = (i + Math.imul(k, P)) | 0), + (g = ((g = (g + Math.imul(k, V)) | 0) + Math.imul(F, P)) | 0), + (r = (r + Math.imul(F, V)) | 0), + (i = (i + Math.imul(M, z)) | 0), + (g = ((g = (g + Math.imul(M, T)) | 0) + Math.imul(m, z)) | 0), + (r = (r + Math.imul(m, T)) | 0), + (i = (i + Math.imul(D, $)) | 0), + (g = ((g = (g + Math.imul(D, AA)) | 0) + Math.imul(b, $)) | 0), + (r = (r + Math.imul(b, AA)) | 0), + (i = (i + Math.imul(l, tA)) | 0), + (g = ((g = (g + Math.imul(l, iA)) | 0) + Math.imul(w, tA)) | 0), + (r = (r + Math.imul(w, iA)) | 0), + (i = (i + Math.imul(E, rA)) | 0), + (g = ((g = (g + Math.imul(E, nA)) | 0) + Math.imul(u, rA)) | 0), + (r = (r + Math.imul(u, nA)) | 0), + (i = (i + Math.imul(c, IA)) | 0), + (g = ((g = (g + Math.imul(c, oA)) | 0) + Math.imul(h, IA)) | 0), + (r = (r + Math.imul(h, oA)) | 0); + var bA = + (((o + (i = (i + Math.imul(Q, QA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, CA)) | 0) + Math.imul(C, QA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, CA)) | 0) + (g >>> 13)) | 0) + + (bA >>> 26)) | + 0), + (bA &= 67108863), + (i = Math.imul(H, L)), + (g = ((g = Math.imul(H, x)) + Math.imul(R, L)) | 0), + (r = Math.imul(R, x)), + (i = (i + Math.imul(K, j)) | 0), + (g = ((g = (g + Math.imul(K, W)) | 0) + Math.imul(U, j)) | 0), + (r = (r + Math.imul(U, W)) | 0), + (i = (i + Math.imul(S, P)) | 0), + (g = ((g = (g + Math.imul(S, V)) | 0) + Math.imul(Y, P)) | 0), + (r = (r + Math.imul(Y, V)) | 0), + (i = (i + Math.imul(k, z)) | 0), + (g = ((g = (g + Math.imul(k, T)) | 0) + Math.imul(F, z)) | 0), + (r = (r + Math.imul(F, T)) | 0), + (i = (i + Math.imul(M, $)) | 0), + (g = ((g = (g + Math.imul(M, AA)) | 0) + Math.imul(m, $)) | 0), + (r = (r + Math.imul(m, AA)) | 0), + (i = (i + Math.imul(D, tA)) | 0), + (g = ((g = (g + Math.imul(D, iA)) | 0) + Math.imul(b, tA)) | 0), + (r = (r + Math.imul(b, iA)) | 0), + (i = (i + Math.imul(l, rA)) | 0), + (g = ((g = (g + Math.imul(l, nA)) | 0) + Math.imul(w, rA)) | 0), + (r = (r + Math.imul(w, nA)) | 0), + (i = (i + Math.imul(E, IA)) | 0), + (g = ((g = (g + Math.imul(E, oA)) | 0) + Math.imul(u, IA)) | 0), + (r = (r + Math.imul(u, oA)) | 0), + (i = (i + Math.imul(c, QA)) | 0), + (g = ((g = (g + Math.imul(c, CA)) | 0) + Math.imul(h, QA)) | 0), + (r = (r + Math.imul(h, CA)) | 0); + var yA = + (((o + (i = (i + Math.imul(Q, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(Q, hA)) | 0) + Math.imul(C, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(C, hA)) | 0) + (g >>> 13)) | 0) + + (yA >>> 26)) | + 0), + (yA &= 67108863), + (i = Math.imul(H, j)), + (g = ((g = Math.imul(H, W)) + Math.imul(R, j)) | 0), + (r = Math.imul(R, W)), + (i = (i + Math.imul(K, P)) | 0), + (g = ((g = (g + Math.imul(K, V)) | 0) + Math.imul(U, P)) | 0), + (r = (r + Math.imul(U, V)) | 0), + (i = (i + Math.imul(S, z)) | 0), + (g = ((g = (g + Math.imul(S, T)) | 0) + Math.imul(Y, z)) | 0), + (r = (r + Math.imul(Y, T)) | 0), + (i = (i + Math.imul(k, $)) | 0), + (g = ((g = (g + Math.imul(k, AA)) | 0) + Math.imul(F, $)) | 0), + (r = (r + Math.imul(F, AA)) | 0), + (i = (i + Math.imul(M, tA)) | 0), + (g = ((g = (g + Math.imul(M, iA)) | 0) + Math.imul(m, tA)) | 0), + (r = (r + Math.imul(m, iA)) | 0), + (i = (i + Math.imul(D, rA)) | 0), + (g = ((g = (g + Math.imul(D, nA)) | 0) + Math.imul(b, rA)) | 0), + (r = (r + Math.imul(b, nA)) | 0), + (i = (i + Math.imul(l, IA)) | 0), + (g = ((g = (g + Math.imul(l, oA)) | 0) + Math.imul(w, IA)) | 0), + (r = (r + Math.imul(w, oA)) | 0), + (i = (i + Math.imul(E, QA)) | 0), + (g = ((g = (g + Math.imul(E, CA)) | 0) + Math.imul(u, QA)) | 0), + (r = (r + Math.imul(u, CA)) | 0); + var MA = + (((o + (i = (i + Math.imul(c, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(c, hA)) | 0) + Math.imul(h, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(h, hA)) | 0) + (g >>> 13)) | 0) + + (MA >>> 26)) | + 0), + (MA &= 67108863), + (i = Math.imul(H, P)), + (g = ((g = Math.imul(H, V)) + Math.imul(R, P)) | 0), + (r = Math.imul(R, V)), + (i = (i + Math.imul(K, z)) | 0), + (g = ((g = (g + Math.imul(K, T)) | 0) + Math.imul(U, z)) | 0), + (r = (r + Math.imul(U, T)) | 0), + (i = (i + Math.imul(S, $)) | 0), + (g = ((g = (g + Math.imul(S, AA)) | 0) + Math.imul(Y, $)) | 0), + (r = (r + Math.imul(Y, AA)) | 0), + (i = (i + Math.imul(k, tA)) | 0), + (g = ((g = (g + Math.imul(k, iA)) | 0) + Math.imul(F, tA)) | 0), + (r = (r + Math.imul(F, iA)) | 0), + (i = (i + Math.imul(M, rA)) | 0), + (g = ((g = (g + Math.imul(M, nA)) | 0) + Math.imul(m, rA)) | 0), + (r = (r + Math.imul(m, nA)) | 0), + (i = (i + Math.imul(D, IA)) | 0), + (g = ((g = (g + Math.imul(D, oA)) | 0) + Math.imul(b, IA)) | 0), + (r = (r + Math.imul(b, oA)) | 0), + (i = (i + Math.imul(l, QA)) | 0), + (g = ((g = (g + Math.imul(l, CA)) | 0) + Math.imul(w, QA)) | 0), + (r = (r + Math.imul(w, CA)) | 0); + var mA = + (((o + (i = (i + Math.imul(E, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(E, hA)) | 0) + Math.imul(u, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(u, hA)) | 0) + (g >>> 13)) | 0) + + (mA >>> 26)) | + 0), + (mA &= 67108863), + (i = Math.imul(H, z)), + (g = ((g = Math.imul(H, T)) + Math.imul(R, z)) | 0), + (r = Math.imul(R, T)), + (i = (i + Math.imul(K, $)) | 0), + (g = ((g = (g + Math.imul(K, AA)) | 0) + Math.imul(U, $)) | 0), + (r = (r + Math.imul(U, AA)) | 0), + (i = (i + Math.imul(S, tA)) | 0), + (g = ((g = (g + Math.imul(S, iA)) | 0) + Math.imul(Y, tA)) | 0), + (r = (r + Math.imul(Y, iA)) | 0), + (i = (i + Math.imul(k, rA)) | 0), + (g = ((g = (g + Math.imul(k, nA)) | 0) + Math.imul(F, rA)) | 0), + (r = (r + Math.imul(F, nA)) | 0), + (i = (i + Math.imul(M, IA)) | 0), + (g = ((g = (g + Math.imul(M, oA)) | 0) + Math.imul(m, IA)) | 0), + (r = (r + Math.imul(m, oA)) | 0), + (i = (i + Math.imul(D, QA)) | 0), + (g = ((g = (g + Math.imul(D, CA)) | 0) + Math.imul(b, QA)) | 0), + (r = (r + Math.imul(b, CA)) | 0); + var GA = + (((o + (i = (i + Math.imul(l, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(l, hA)) | 0) + Math.imul(w, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(w, hA)) | 0) + (g >>> 13)) | 0) + + (GA >>> 26)) | + 0), + (GA &= 67108863), + (i = Math.imul(H, $)), + (g = ((g = Math.imul(H, AA)) + Math.imul(R, $)) | 0), + (r = Math.imul(R, AA)), + (i = (i + Math.imul(K, tA)) | 0), + (g = ((g = (g + Math.imul(K, iA)) | 0) + Math.imul(U, tA)) | 0), + (r = (r + Math.imul(U, iA)) | 0), + (i = (i + Math.imul(S, rA)) | 0), + (g = ((g = (g + Math.imul(S, nA)) | 0) + Math.imul(Y, rA)) | 0), + (r = (r + Math.imul(Y, nA)) | 0), + (i = (i + Math.imul(k, IA)) | 0), + (g = ((g = (g + Math.imul(k, oA)) | 0) + Math.imul(F, IA)) | 0), + (r = (r + Math.imul(F, oA)) | 0), + (i = (i + Math.imul(M, QA)) | 0), + (g = ((g = (g + Math.imul(M, CA)) | 0) + Math.imul(m, QA)) | 0), + (r = (r + Math.imul(m, CA)) | 0); + var kA = + (((o + (i = (i + Math.imul(D, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(D, hA)) | 0) + Math.imul(b, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(b, hA)) | 0) + (g >>> 13)) | 0) + + (kA >>> 26)) | + 0), + (kA &= 67108863), + (i = Math.imul(H, tA)), + (g = ((g = Math.imul(H, iA)) + Math.imul(R, tA)) | 0), + (r = Math.imul(R, iA)), + (i = (i + Math.imul(K, rA)) | 0), + (g = ((g = (g + Math.imul(K, nA)) | 0) + Math.imul(U, rA)) | 0), + (r = (r + Math.imul(U, nA)) | 0), + (i = (i + Math.imul(S, IA)) | 0), + (g = ((g = (g + Math.imul(S, oA)) | 0) + Math.imul(Y, IA)) | 0), + (r = (r + Math.imul(Y, oA)) | 0), + (i = (i + Math.imul(k, QA)) | 0), + (g = ((g = (g + Math.imul(k, CA)) | 0) + Math.imul(F, QA)) | 0), + (r = (r + Math.imul(F, CA)) | 0); + var FA = + (((o + (i = (i + Math.imul(M, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(M, hA)) | 0) + Math.imul(m, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(m, hA)) | 0) + (g >>> 13)) | 0) + + (FA >>> 26)) | + 0), + (FA &= 67108863), + (i = Math.imul(H, rA)), + (g = ((g = Math.imul(H, nA)) + Math.imul(R, rA)) | 0), + (r = Math.imul(R, nA)), + (i = (i + Math.imul(K, IA)) | 0), + (g = ((g = (g + Math.imul(K, oA)) | 0) + Math.imul(U, IA)) | 0), + (r = (r + Math.imul(U, oA)) | 0), + (i = (i + Math.imul(S, QA)) | 0), + (g = ((g = (g + Math.imul(S, CA)) | 0) + Math.imul(Y, QA)) | 0), + (r = (r + Math.imul(Y, CA)) | 0); + var NA = + (((o + (i = (i + Math.imul(k, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(k, hA)) | 0) + Math.imul(F, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(F, hA)) | 0) + (g >>> 13)) | 0) + + (NA >>> 26)) | + 0), + (NA &= 67108863), + (i = Math.imul(H, IA)), + (g = ((g = Math.imul(H, oA)) + Math.imul(R, IA)) | 0), + (r = Math.imul(R, oA)), + (i = (i + Math.imul(K, QA)) | 0), + (g = ((g = (g + Math.imul(K, CA)) | 0) + Math.imul(U, QA)) | 0), + (r = (r + Math.imul(U, CA)) | 0); + var SA = + (((o + (i = (i + Math.imul(S, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(S, hA)) | 0) + Math.imul(Y, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(Y, hA)) | 0) + (g >>> 13)) | 0) + + (SA >>> 26)) | + 0), + (SA &= 67108863), + (i = Math.imul(H, QA)), + (g = ((g = Math.imul(H, CA)) + Math.imul(R, QA)) | 0), + (r = Math.imul(R, CA)); + var YA = + (((o + (i = (i + Math.imul(K, cA)) | 0)) | 0) + + ((8191 & + (g = + ((g = (g + Math.imul(K, hA)) | 0) + Math.imul(U, cA)) | + 0)) << + 13)) | + 0; + (o = + ((((r = (r + Math.imul(U, hA)) | 0) + (g >>> 13)) | 0) + + (YA >>> 26)) | + 0), + (YA &= 67108863); + var vA = + (((o + (i = Math.imul(H, cA))) | 0) + + ((8191 & + (g = ((g = Math.imul(H, hA)) + Math.imul(R, cA)) | 0)) << + 13)) | + 0; + return ( + (o = + ((((r = Math.imul(R, hA)) + (g >>> 13)) | 0) + (vA >>> 26)) | + 0), + (vA &= 67108863), + (I[0] = fA), + (I[1] = EA), + (I[2] = uA), + (I[3] = dA), + (I[4] = lA), + (I[5] = wA), + (I[6] = pA), + (I[7] = DA), + (I[8] = bA), + (I[9] = yA), + (I[10] = MA), + (I[11] = mA), + (I[12] = GA), + (I[13] = kA), + (I[14] = FA), + (I[15] = NA), + (I[16] = SA), + (I[17] = YA), + (I[18] = vA), + 0 !== o && ((I[19] = o), t.length++), + t + ); + }; + function f(A, e, t) { + (t.negative = e.negative ^ A.negative), + (t.length = A.length + e.length); + for (var i = 0, g = 0, r = 0; r < t.length - 1; r++) { + var n = g; + g = 0; + for ( + var B = 67108863 & i, + I = Math.min(r, e.length - 1), + o = Math.max(0, r - A.length + 1); + o <= I; + o++ + ) { + var a = r - o, + Q = (0 | A.words[a]) * (0 | e.words[o]), + C = 67108863 & Q; + (B = 67108863 & (C = (C + B) | 0)), + (g += + (n = + ((n = (n + ((Q / 67108864) | 0)) | 0) + (C >>> 26)) | + 0) >>> 26), + (n &= 67108863); + } + (t.words[r] = B), (i = n), (n = g); + } + return 0 !== i ? (t.words[r] = i) : t.length--, t._strip(); + } + function E(A, e, t) { + return f(A, e, t); + } + function u(A, e) { + (this.x = A), (this.y = e); + } + Math.imul || (h = c), + (r.prototype.mulTo = function (A, e) { + var t = this.length + A.length; + return 10 === this.length && 10 === A.length + ? h(this, A, e) + : t < 63 + ? c(this, A, e) + : t < 1024 + ? f(this, A, e) + : E(this, A, e); + }), + (u.prototype.makeRBT = function (A) { + for ( + var e = new Array(A), t = r.prototype._countBits(A) - 1, i = 0; + i < A; + i++ + ) + e[i] = this.revBin(i, t, A); + return e; + }), + (u.prototype.revBin = function (A, e, t) { + if (0 === A || A === t - 1) return A; + for (var i = 0, g = 0; g < e; g++) + (i |= (1 & A) << (e - g - 1)), (A >>= 1); + return i; + }), + (u.prototype.permute = function (A, e, t, i, g, r) { + for (var n = 0; n < r; n++) (i[n] = e[A[n]]), (g[n] = t[A[n]]); + }), + (u.prototype.transform = function (A, e, t, i, g, r) { + this.permute(r, A, e, t, i, g); + for (var n = 1; n < g; n <<= 1) + for ( + var B = n << 1, + I = Math.cos((2 * Math.PI) / B), + o = Math.sin((2 * Math.PI) / B), + a = 0; + a < g; + a += B + ) + for (var Q = I, C = o, s = 0; s < n; s++) { + var c = t[a + s], + h = i[a + s], + f = t[a + s + n], + E = i[a + s + n], + u = Q * f - C * E; + (E = Q * E + C * f), + (f = u), + (t[a + s] = c + f), + (i[a + s] = h + E), + (t[a + s + n] = c - f), + (i[a + s + n] = h - E), + s !== B && + ((u = I * Q - o * C), (C = I * C + o * Q), (Q = u)); + } + }), + (u.prototype.guessLen13b = function (A, e) { + var t = 1 | Math.max(e, A), + i = 1 & t, + g = 0; + for (t = (t / 2) | 0; t; t >>>= 1) g++; + return 1 << (g + 1 + i); + }), + (u.prototype.conjugate = function (A, e, t) { + if (!(t <= 1)) + for (var i = 0; i < t / 2; i++) { + var g = A[i]; + (A[i] = A[t - i - 1]), + (A[t - i - 1] = g), + (g = e[i]), + (e[i] = -e[t - i - 1]), + (e[t - i - 1] = -g); + } + }), + (u.prototype.normalize13b = function (A, e) { + for (var t = 0, i = 0; i < e / 2; i++) { + var g = + 8192 * Math.round(A[2 * i + 1] / e) + + Math.round(A[2 * i] / e) + + t; + (A[i] = 67108863 & g), + (t = g < 67108864 ? 0 : (g / 67108864) | 0); + } + return A; + }), + (u.prototype.convert13b = function (A, e, t, g) { + for (var r = 0, n = 0; n < e; n++) + (r += 0 | A[n]), + (t[2 * n] = 8191 & r), + (r >>>= 13), + (t[2 * n + 1] = 8191 & r), + (r >>>= 13); + for (n = 2 * e; n < g; ++n) t[n] = 0; + i(0 === r), i(0 == (-8192 & r)); + }), + (u.prototype.stub = function (A) { + for (var e = new Array(A), t = 0; t < A; t++) e[t] = 0; + return e; + }), + (u.prototype.mulp = function (A, e, t) { + var i = 2 * this.guessLen13b(A.length, e.length), + g = this.makeRBT(i), + r = this.stub(i), + n = new Array(i), + B = new Array(i), + I = new Array(i), + o = new Array(i), + a = new Array(i), + Q = new Array(i), + C = t.words; + (C.length = i), + this.convert13b(A.words, A.length, n, i), + this.convert13b(e.words, e.length, o, i), + this.transform(n, r, B, I, i, g), + this.transform(o, r, a, Q, i, g); + for (var s = 0; s < i; s++) { + var c = B[s] * a[s] - I[s] * Q[s]; + (I[s] = B[s] * Q[s] + I[s] * a[s]), (B[s] = c); + } + return ( + this.conjugate(B, I, i), + this.transform(B, I, C, r, i, g), + this.conjugate(C, r, i), + this.normalize13b(C, i), + (t.negative = A.negative ^ e.negative), + (t.length = A.length + e.length), + t._strip() + ); + }), + (r.prototype.mul = function (A) { + var e = new r(null); + return ( + (e.words = new Array(this.length + A.length)), this.mulTo(A, e) + ); + }), + (r.prototype.mulf = function (A) { + var e = new r(null); + return ( + (e.words = new Array(this.length + A.length)), E(this, A, e) + ); + }), + (r.prototype.imul = function (A) { + return this.clone().mulTo(A, this); + }), + (r.prototype.imuln = function (A) { + var e = A < 0; + e && (A = -A), i("number" == typeof A), i(A < 67108864); + for (var t = 0, g = 0; g < this.length; g++) { + var r = (0 | this.words[g]) * A, + n = (67108863 & r) + (67108863 & t); + (t >>= 26), + (t += (r / 67108864) | 0), + (t += n >>> 26), + (this.words[g] = 67108863 & n); + } + return ( + 0 !== t && ((this.words[g] = t), this.length++), + e ? this.ineg() : this + ); + }), + (r.prototype.muln = function (A) { + return this.clone().imuln(A); + }), + (r.prototype.sqr = function () { + return this.mul(this); + }), + (r.prototype.isqr = function () { + return this.imul(this.clone()); + }), + (r.prototype.pow = function (A) { + var e = (function (A) { + for ( + var e = new Array(A.bitLength()), t = 0; + t < e.length; + t++ + ) { + var i = (t / 26) | 0, + g = t % 26; + e[t] = (A.words[i] >>> g) & 1; + } + return e; + })(A); + if (0 === e.length) return new r(1); + for ( + var t = this, i = 0; + i < e.length && 0 === e[i]; + i++, t = t.sqr() + ); + if (++i < e.length) + for (var g = t.sqr(); i < e.length; i++, g = g.sqr()) + 0 !== e[i] && (t = t.mul(g)); + return t; + }), + (r.prototype.iushln = function (A) { + i("number" == typeof A && A >= 0); + var e, + t = A % 26, + g = (A - t) / 26, + r = (67108863 >>> (26 - t)) << (26 - t); + if (0 !== t) { + var n = 0; + for (e = 0; e < this.length; e++) { + var B = this.words[e] & r, + I = ((0 | this.words[e]) - B) << t; + (this.words[e] = I | n), (n = B >>> (26 - t)); + } + n && ((this.words[e] = n), this.length++); + } + if (0 !== g) { + for (e = this.length - 1; e >= 0; e--) + this.words[e + g] = this.words[e]; + for (e = 0; e < g; e++) this.words[e] = 0; + this.length += g; + } + return this._strip(); + }), + (r.prototype.ishln = function (A) { + return i(0 === this.negative), this.iushln(A); + }), + (r.prototype.iushrn = function (A, e, t) { + var g; + i("number" == typeof A && A >= 0), + (g = e ? (e - (e % 26)) / 26 : 0); + var r = A % 26, + n = Math.min((A - r) / 26, this.length), + B = 67108863 ^ ((67108863 >>> r) << r), + I = t; + if (((g -= n), (g = Math.max(0, g)), I)) { + for (var o = 0; o < n; o++) I.words[o] = this.words[o]; + I.length = n; + } + if (0 === n); + else if (this.length > n) + for (this.length -= n, o = 0; o < this.length; o++) + this.words[o] = this.words[o + n]; + else (this.words[0] = 0), (this.length = 1); + var a = 0; + for (o = this.length - 1; o >= 0 && (0 !== a || o >= g); o--) { + var Q = 0 | this.words[o]; + (this.words[o] = (a << (26 - r)) | (Q >>> r)), (a = Q & B); + } + return ( + I && 0 !== a && (I.words[I.length++] = a), + 0 === this.length && ((this.words[0] = 0), (this.length = 1)), + this._strip() + ); + }), + (r.prototype.ishrn = function (A, e, t) { + return i(0 === this.negative), this.iushrn(A, e, t); + }), + (r.prototype.shln = function (A) { + return this.clone().ishln(A); + }), + (r.prototype.ushln = function (A) { + return this.clone().iushln(A); + }), + (r.prototype.shrn = function (A) { + return this.clone().ishrn(A); + }), + (r.prototype.ushrn = function (A) { + return this.clone().iushrn(A); + }), + (r.prototype.testn = function (A) { + i("number" == typeof A && A >= 0); + var e = A % 26, + t = (A - e) / 26, + g = 1 << e; + return !(this.length <= t) && !!(this.words[t] & g); + }), + (r.prototype.imaskn = function (A) { + i("number" == typeof A && A >= 0); + var e = A % 26, + t = (A - e) / 26; + if ( + (i( + 0 === this.negative, + "imaskn works only with positive numbers" + ), + this.length <= t) + ) + return this; + if ( + (0 !== e && t++, + (this.length = Math.min(t, this.length)), + 0 !== e) + ) { + var g = 67108863 ^ ((67108863 >>> e) << e); + this.words[this.length - 1] &= g; + } + return this._strip(); + }), + (r.prototype.maskn = function (A) { + return this.clone().imaskn(A); + }), + (r.prototype.iaddn = function (A) { + return ( + i("number" == typeof A), + i(A < 67108864), + A < 0 + ? this.isubn(-A) + : 0 !== this.negative + ? 1 === this.length && (0 | this.words[0]) <= A + ? ((this.words[0] = A - (0 | this.words[0])), + (this.negative = 0), + this) + : ((this.negative = 0), + this.isubn(A), + (this.negative = 1), + this) + : this._iaddn(A) + ); + }), + (r.prototype._iaddn = function (A) { + this.words[0] += A; + for (var e = 0; e < this.length && this.words[e] >= 67108864; e++) + (this.words[e] -= 67108864), + e === this.length - 1 + ? (this.words[e + 1] = 1) + : this.words[e + 1]++; + return (this.length = Math.max(this.length, e + 1)), this; + }), + (r.prototype.isubn = function (A) { + if ((i("number" == typeof A), i(A < 67108864), A < 0)) + return this.iaddn(-A); + if (0 !== this.negative) + return ( + (this.negative = 0), this.iaddn(A), (this.negative = 1), this + ); + if ( + ((this.words[0] -= A), 1 === this.length && this.words[0] < 0) + ) + (this.words[0] = -this.words[0]), (this.negative = 1); + else + for (var e = 0; e < this.length && this.words[e] < 0; e++) + (this.words[e] += 67108864), (this.words[e + 1] -= 1); + return this._strip(); + }), + (r.prototype.addn = function (A) { + return this.clone().iaddn(A); + }), + (r.prototype.subn = function (A) { + return this.clone().isubn(A); + }), + (r.prototype.iabs = function () { + return (this.negative = 0), this; + }), + (r.prototype.abs = function () { + return this.clone().iabs(); + }), + (r.prototype._ishlnsubmul = function (A, e, t) { + var g, + r, + n = A.length + t; + this._expand(n); + var B = 0; + for (g = 0; g < A.length; g++) { + r = (0 | this.words[g + t]) + B; + var I = (0 | A.words[g]) * e; + (B = ((r -= 67108863 & I) >> 26) - ((I / 67108864) | 0)), + (this.words[g + t] = 67108863 & r); + } + for (; g < this.length - t; g++) + (B = (r = (0 | this.words[g + t]) + B) >> 26), + (this.words[g + t] = 67108863 & r); + if (0 === B) return this._strip(); + for (i(-1 === B), B = 0, g = 0; g < this.length; g++) + (B = (r = -(0 | this.words[g]) + B) >> 26), + (this.words[g] = 67108863 & r); + return (this.negative = 1), this._strip(); + }), + (r.prototype._wordDiv = function (A, e) { + var t = (this.length, A.length), + i = this.clone(), + g = A, + n = 0 | g.words[g.length - 1]; + 0 !== (t = 26 - this._countBits(n)) && + ((g = g.ushln(t)), + i.iushln(t), + (n = 0 | g.words[g.length - 1])); + var B, + I = i.length - g.length; + if ("mod" !== e) { + ((B = new r(null)).length = I + 1), + (B.words = new Array(B.length)); + for (var o = 0; o < B.length; o++) B.words[o] = 0; + } + var a = i.clone()._ishlnsubmul(g, 1, I); + 0 === a.negative && ((i = a), B && (B.words[I] = 1)); + for (var Q = I - 1; Q >= 0; Q--) { + var C = + 67108864 * (0 | i.words[g.length + Q]) + + (0 | i.words[g.length + Q - 1]); + for ( + C = Math.min((C / n) | 0, 67108863), i._ishlnsubmul(g, C, Q); + 0 !== i.negative; + + ) + C--, + (i.negative = 0), + i._ishlnsubmul(g, 1, Q), + i.isZero() || (i.negative ^= 1); + B && (B.words[Q] = C); + } + return ( + B && B._strip(), + i._strip(), + "div" !== e && 0 !== t && i.iushrn(t), + { div: B || null, mod: i } + ); + }), + (r.prototype.divmod = function (A, e, t) { + return ( + i(!A.isZero()), + this.isZero() + ? { div: new r(0), mod: new r(0) } + : 0 !== this.negative && 0 === A.negative + ? ((B = this.neg().divmod(A, e)), + "mod" !== e && (g = B.div.neg()), + "div" !== e && + ((n = B.mod.neg()), t && 0 !== n.negative && n.iadd(A)), + { div: g, mod: n }) + : 0 === this.negative && 0 !== A.negative + ? ((B = this.divmod(A.neg(), e)), + "mod" !== e && (g = B.div.neg()), + { div: g, mod: B.mod }) + : 0 != (this.negative & A.negative) + ? ((B = this.neg().divmod(A.neg(), e)), + "div" !== e && + ((n = B.mod.neg()), t && 0 !== n.negative && n.isub(A)), + { div: B.div, mod: n }) + : A.length > this.length || this.cmp(A) < 0 + ? { div: new r(0), mod: this } + : 1 === A.length + ? "div" === e + ? { div: this.divn(A.words[0]), mod: null } + : "mod" === e + ? { div: null, mod: new r(this.modrn(A.words[0])) } + : { + div: this.divn(A.words[0]), + mod: new r(this.modrn(A.words[0])), + } + : this._wordDiv(A, e) + ); + var g, n, B; + }), + (r.prototype.div = function (A) { + return this.divmod(A, "div", !1).div; + }), + (r.prototype.mod = function (A) { + return this.divmod(A, "mod", !1).mod; + }), + (r.prototype.umod = function (A) { + return this.divmod(A, "mod", !0).mod; + }), + (r.prototype.divRound = function (A) { + var e = this.divmod(A); + if (e.mod.isZero()) return e.div; + var t = 0 !== e.div.negative ? e.mod.isub(A) : e.mod, + i = A.ushrn(1), + g = A.andln(1), + r = t.cmp(i); + return r < 0 || (1 === g && 0 === r) + ? e.div + : 0 !== e.div.negative + ? e.div.isubn(1) + : e.div.iaddn(1); + }), + (r.prototype.modrn = function (A) { + var e = A < 0; + e && (A = -A), i(A <= 67108863); + for ( + var t = (1 << 26) % A, g = 0, r = this.length - 1; + r >= 0; + r-- + ) + g = (t * g + (0 | this.words[r])) % A; + return e ? -g : g; + }), + (r.prototype.modn = function (A) { + return this.modrn(A); + }), + (r.prototype.idivn = function (A) { + var e = A < 0; + e && (A = -A), i(A <= 67108863); + for (var t = 0, g = this.length - 1; g >= 0; g--) { + var r = (0 | this.words[g]) + 67108864 * t; + (this.words[g] = (r / A) | 0), (t = r % A); + } + return this._strip(), e ? this.ineg() : this; + }), + (r.prototype.divn = function (A) { + return this.clone().idivn(A); + }), + (r.prototype.egcd = function (A) { + i(0 === A.negative), i(!A.isZero()); + var e = this, + t = A.clone(); + e = 0 !== e.negative ? e.umod(A) : e.clone(); + for ( + var g = new r(1), + n = new r(0), + B = new r(0), + I = new r(1), + o = 0; + e.isEven() && t.isEven(); + + ) + e.iushrn(1), t.iushrn(1), ++o; + for (var a = t.clone(), Q = e.clone(); !e.isZero(); ) { + for ( + var C = 0, s = 1; + 0 == (e.words[0] & s) && C < 26; + ++C, s <<= 1 + ); + if (C > 0) + for (e.iushrn(C); C-- > 0; ) + (g.isOdd() || n.isOdd()) && (g.iadd(a), n.isub(Q)), + g.iushrn(1), + n.iushrn(1); + for ( + var c = 0, h = 1; + 0 == (t.words[0] & h) && c < 26; + ++c, h <<= 1 + ); + if (c > 0) + for (t.iushrn(c); c-- > 0; ) + (B.isOdd() || I.isOdd()) && (B.iadd(a), I.isub(Q)), + B.iushrn(1), + I.iushrn(1); + e.cmp(t) >= 0 + ? (e.isub(t), g.isub(B), n.isub(I)) + : (t.isub(e), B.isub(g), I.isub(n)); + } + return { a: B, b: I, gcd: t.iushln(o) }; + }), + (r.prototype._invmp = function (A) { + i(0 === A.negative), i(!A.isZero()); + var e = this, + t = A.clone(); + e = 0 !== e.negative ? e.umod(A) : e.clone(); + for ( + var g, n = new r(1), B = new r(0), I = t.clone(); + e.cmpn(1) > 0 && t.cmpn(1) > 0; + + ) { + for ( + var o = 0, a = 1; + 0 == (e.words[0] & a) && o < 26; + ++o, a <<= 1 + ); + if (o > 0) + for (e.iushrn(o); o-- > 0; ) + n.isOdd() && n.iadd(I), n.iushrn(1); + for ( + var Q = 0, C = 1; + 0 == (t.words[0] & C) && Q < 26; + ++Q, C <<= 1 + ); + if (Q > 0) + for (t.iushrn(Q); Q-- > 0; ) + B.isOdd() && B.iadd(I), B.iushrn(1); + e.cmp(t) >= 0 ? (e.isub(t), n.isub(B)) : (t.isub(e), B.isub(n)); + } + return (g = 0 === e.cmpn(1) ? n : B).cmpn(0) < 0 && g.iadd(A), g; + }), + (r.prototype.gcd = function (A) { + if (this.isZero()) return A.abs(); + if (A.isZero()) return this.abs(); + var e = this.clone(), + t = A.clone(); + (e.negative = 0), (t.negative = 0); + for (var i = 0; e.isEven() && t.isEven(); i++) + e.iushrn(1), t.iushrn(1); + for (;;) { + for (; e.isEven(); ) e.iushrn(1); + for (; t.isEven(); ) t.iushrn(1); + var g = e.cmp(t); + if (g < 0) { + var r = e; + (e = t), (t = r); + } else if (0 === g || 0 === t.cmpn(1)) break; + e.isub(t); + } + return t.iushln(i); + }), + (r.prototype.invm = function (A) { + return this.egcd(A).a.umod(A); + }), + (r.prototype.isEven = function () { + return 0 == (1 & this.words[0]); + }), + (r.prototype.isOdd = function () { + return 1 == (1 & this.words[0]); + }), + (r.prototype.andln = function (A) { + return this.words[0] & A; + }), + (r.prototype.bincn = function (A) { + i("number" == typeof A); + var e = A % 26, + t = (A - e) / 26, + g = 1 << e; + if (this.length <= t) + return this._expand(t + 1), (this.words[t] |= g), this; + for (var r = g, n = t; 0 !== r && n < this.length; n++) { + var B = 0 | this.words[n]; + (r = (B += r) >>> 26), (B &= 67108863), (this.words[n] = B); + } + return 0 !== r && ((this.words[n] = r), this.length++), this; + }), + (r.prototype.isZero = function () { + return 1 === this.length && 0 === this.words[0]; + }), + (r.prototype.cmpn = function (A) { + var e, + t = A < 0; + if (0 !== this.negative && !t) return -1; + if (0 === this.negative && t) return 1; + if ((this._strip(), this.length > 1)) e = 1; + else { + t && (A = -A), i(A <= 67108863, "Number is too big"); + var g = 0 | this.words[0]; + e = g === A ? 0 : g < A ? -1 : 1; + } + return 0 !== this.negative ? 0 | -e : e; + }), + (r.prototype.cmp = function (A) { + if (0 !== this.negative && 0 === A.negative) return -1; + if (0 === this.negative && 0 !== A.negative) return 1; + var e = this.ucmp(A); + return 0 !== this.negative ? 0 | -e : e; + }), + (r.prototype.ucmp = function (A) { + if (this.length > A.length) return 1; + if (this.length < A.length) return -1; + for (var e = 0, t = this.length - 1; t >= 0; t--) { + var i = 0 | this.words[t], + g = 0 | A.words[t]; + if (i !== g) { + i < g ? (e = -1) : i > g && (e = 1); + break; + } + } + return e; + }), + (r.prototype.gtn = function (A) { + return 1 === this.cmpn(A); + }), + (r.prototype.gt = function (A) { + return 1 === this.cmp(A); + }), + (r.prototype.gten = function (A) { + return this.cmpn(A) >= 0; + }), + (r.prototype.gte = function (A) { + return this.cmp(A) >= 0; + }), + (r.prototype.ltn = function (A) { + return -1 === this.cmpn(A); + }), + (r.prototype.lt = function (A) { + return -1 === this.cmp(A); + }), + (r.prototype.lten = function (A) { + return this.cmpn(A) <= 0; + }), + (r.prototype.lte = function (A) { + return this.cmp(A) <= 0; + }), + (r.prototype.eqn = function (A) { + return 0 === this.cmpn(A); + }), + (r.prototype.eq = function (A) { + return 0 === this.cmp(A); + }), + (r.red = function (A) { + return new y(A); + }), + (r.prototype.toRed = function (A) { + return ( + i(!this.red, "Already a number in reduction context"), + i(0 === this.negative, "red works only with positives"), + A.convertTo(this)._forceRed(A) + ); + }), + (r.prototype.fromRed = function () { + return ( + i( + this.red, + "fromRed works only with numbers in reduction context" + ), + this.red.convertFrom(this) + ); + }), + (r.prototype._forceRed = function (A) { + return (this.red = A), this; + }), + (r.prototype.forceRed = function (A) { + return ( + i(!this.red, "Already a number in reduction context"), + this._forceRed(A) + ); + }), + (r.prototype.redAdd = function (A) { + return ( + i(this.red, "redAdd works only with red numbers"), + this.red.add(this, A) + ); + }), + (r.prototype.redIAdd = function (A) { + return ( + i(this.red, "redIAdd works only with red numbers"), + this.red.iadd(this, A) + ); + }), + (r.prototype.redSub = function (A) { + return ( + i(this.red, "redSub works only with red numbers"), + this.red.sub(this, A) + ); + }), + (r.prototype.redISub = function (A) { + return ( + i(this.red, "redISub works only with red numbers"), + this.red.isub(this, A) + ); + }), + (r.prototype.redShl = function (A) { + return ( + i(this.red, "redShl works only with red numbers"), + this.red.shl(this, A) + ); + }), + (r.prototype.redMul = function (A) { + return ( + i(this.red, "redMul works only with red numbers"), + this.red._verify2(this, A), + this.red.mul(this, A) + ); + }), + (r.prototype.redIMul = function (A) { + return ( + i(this.red, "redMul works only with red numbers"), + this.red._verify2(this, A), + this.red.imul(this, A) + ); + }), + (r.prototype.redSqr = function () { + return ( + i(this.red, "redSqr works only with red numbers"), + this.red._verify1(this), + this.red.sqr(this) + ); + }), + (r.prototype.redISqr = function () { + return ( + i(this.red, "redISqr works only with red numbers"), + this.red._verify1(this), + this.red.isqr(this) + ); + }), + (r.prototype.redSqrt = function () { + return ( + i(this.red, "redSqrt works only with red numbers"), + this.red._verify1(this), + this.red.sqrt(this) + ); + }), + (r.prototype.redInvm = function () { + return ( + i(this.red, "redInvm works only with red numbers"), + this.red._verify1(this), + this.red.invm(this) + ); + }), + (r.prototype.redNeg = function () { + return ( + i(this.red, "redNeg works only with red numbers"), + this.red._verify1(this), + this.red.neg(this) + ); + }), + (r.prototype.redPow = function (A) { + return ( + i(this.red && !A.red, "redPow(normalNum)"), + this.red._verify1(this), + this.red.pow(this, A) + ); + }); + var d = { k256: null, p224: null, p192: null, p25519: null }; + function l(A, e) { + (this.name = A), + (this.p = new r(e, 16)), + (this.n = this.p.bitLength()), + (this.k = new r(1).iushln(this.n).isub(this.p)), + (this.tmp = this._tmp()); + } + function w() { + l.call( + this, + "k256", + "ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f" + ); + } + function p() { + l.call( + this, + "p224", + "ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001" + ); + } + function D() { + l.call( + this, + "p192", + "ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff" + ); + } + function b() { + l.call( + this, + "25519", + "7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed" + ); + } + function y(A) { + if ("string" == typeof A) { + var e = r._prime(A); + (this.m = e.p), (this.prime = e); + } else + i(A.gtn(1), "modulus must be greater than 1"), + (this.m = A), + (this.prime = null); + } + function M(A) { + y.call(this, A), + (this.shift = this.m.bitLength()), + this.shift % 26 != 0 && (this.shift += 26 - (this.shift % 26)), + (this.r = new r(1).iushln(this.shift)), + (this.r2 = this.imod(this.r.sqr())), + (this.rinv = this.r._invmp(this.m)), + (this.minv = this.rinv.mul(this.r).isubn(1).div(this.m)), + (this.minv = this.minv.umod(this.r)), + (this.minv = this.r.sub(this.minv)); + } + (l.prototype._tmp = function () { + var A = new r(null); + return (A.words = new Array(Math.ceil(this.n / 13))), A; + }), + (l.prototype.ireduce = function (A) { + var e, + t = A; + do { + this.split(t, this.tmp), + (e = (t = (t = this.imulK(t)).iadd(this.tmp)).bitLength()); + } while (e > this.n); + var i = e < this.n ? -1 : t.ucmp(this.p); + return ( + 0 === i + ? ((t.words[0] = 0), (t.length = 1)) + : i > 0 + ? t.isub(this.p) + : void 0 !== t.strip + ? t.strip() + : t._strip(), + t + ); + }), + (l.prototype.split = function (A, e) { + A.iushrn(this.n, 0, e); + }), + (l.prototype.imulK = function (A) { + return A.imul(this.k); + }), + g(w, l), + (w.prototype.split = function (A, e) { + for (var t = Math.min(A.length, 9), i = 0; i < t; i++) + e.words[i] = A.words[i]; + if (((e.length = t), A.length <= 9)) + return (A.words[0] = 0), void (A.length = 1); + var g = A.words[9]; + for ( + e.words[e.length++] = 4194303 & g, i = 10; + i < A.length; + i++ + ) { + var r = 0 | A.words[i]; + (A.words[i - 10] = ((4194303 & r) << 4) | (g >>> 22)), (g = r); + } + (g >>>= 22), + (A.words[i - 10] = g), + 0 === g && A.length > 10 ? (A.length -= 10) : (A.length -= 9); + }), + (w.prototype.imulK = function (A) { + (A.words[A.length] = 0), + (A.words[A.length + 1] = 0), + (A.length += 2); + for (var e = 0, t = 0; t < A.length; t++) { + var i = 0 | A.words[t]; + (e += 977 * i), + (A.words[t] = 67108863 & e), + (e = 64 * i + ((e / 67108864) | 0)); + } + return ( + 0 === A.words[A.length - 1] && + (A.length--, 0 === A.words[A.length - 1] && A.length--), + A + ); + }), + g(p, l), + g(D, l), + g(b, l), + (b.prototype.imulK = function (A) { + for (var e = 0, t = 0; t < A.length; t++) { + var i = 19 * (0 | A.words[t]) + e, + g = 67108863 & i; + (i >>>= 26), (A.words[t] = g), (e = i); + } + return 0 !== e && (A.words[A.length++] = e), A; + }), + (r._prime = function (A) { + if (d[A]) return d[A]; + var e; + if ("k256" === A) e = new w(); + else if ("p224" === A) e = new p(); + else if ("p192" === A) e = new D(); + else { + if ("p25519" !== A) throw new Error("Unknown prime " + A); + e = new b(); + } + return (d[A] = e), e; + }), + (y.prototype._verify1 = function (A) { + i(0 === A.negative, "red works only with positives"), + i(A.red, "red works only with red numbers"); + }), + (y.prototype._verify2 = function (A, e) { + i( + 0 == (A.negative | e.negative), + "red works only with positives" + ), + i(A.red && A.red === e.red, "red works only with red numbers"); + }), + (y.prototype.imod = function (A) { + return this.prime + ? this.prime.ireduce(A)._forceRed(this) + : (o(A, A.umod(this.m)._forceRed(this)), A); + }), + (y.prototype.neg = function (A) { + return A.isZero() ? A.clone() : this.m.sub(A)._forceRed(this); + }), + (y.prototype.add = function (A, e) { + this._verify2(A, e); + var t = A.add(e); + return t.cmp(this.m) >= 0 && t.isub(this.m), t._forceRed(this); + }), + (y.prototype.iadd = function (A, e) { + this._verify2(A, e); + var t = A.iadd(e); + return t.cmp(this.m) >= 0 && t.isub(this.m), t; + }), + (y.prototype.sub = function (A, e) { + this._verify2(A, e); + var t = A.sub(e); + return t.cmpn(0) < 0 && t.iadd(this.m), t._forceRed(this); + }), + (y.prototype.isub = function (A, e) { + this._verify2(A, e); + var t = A.isub(e); + return t.cmpn(0) < 0 && t.iadd(this.m), t; + }), + (y.prototype.shl = function (A, e) { + return this._verify1(A), this.imod(A.ushln(e)); + }), + (y.prototype.imul = function (A, e) { + return this._verify2(A, e), this.imod(A.imul(e)); + }), + (y.prototype.mul = function (A, e) { + return this._verify2(A, e), this.imod(A.mul(e)); + }), + (y.prototype.isqr = function (A) { + return this.imul(A, A.clone()); + }), + (y.prototype.sqr = function (A) { + return this.mul(A, A); + }), + (y.prototype.sqrt = function (A) { + if (A.isZero()) return A.clone(); + var e = this.m.andln(3); + if ((i(e % 2 == 1), 3 === e)) { + var t = this.m.add(new r(1)).iushrn(2); + return this.pow(A, t); + } + for ( + var g = this.m.subn(1), n = 0; + !g.isZero() && 0 === g.andln(1); + + ) + n++, g.iushrn(1); + i(!g.isZero()); + var B = new r(1).toRed(this), + I = B.redNeg(), + o = this.m.subn(1).iushrn(1), + a = this.m.bitLength(); + for ( + a = new r(2 * a * a).toRed(this); + 0 !== this.pow(a, o).cmp(I); + + ) + a.redIAdd(I); + for ( + var Q = this.pow(a, g), + C = this.pow(A, g.addn(1).iushrn(1)), + s = this.pow(A, g), + c = n; + 0 !== s.cmp(B); + + ) { + for (var h = s, f = 0; 0 !== h.cmp(B); f++) h = h.redSqr(); + i(f < c); + var E = this.pow(Q, new r(1).iushln(c - f - 1)); + (C = C.redMul(E)), (Q = E.redSqr()), (s = s.redMul(Q)), (c = f); + } + return C; + }), + (y.prototype.invm = function (A) { + var e = A._invmp(this.m); + return 0 !== e.negative + ? ((e.negative = 0), this.imod(e).redNeg()) + : this.imod(e); + }), + (y.prototype.pow = function (A, e) { + if (e.isZero()) return new r(1).toRed(this); + if (0 === e.cmpn(1)) return A.clone(); + var t = new Array(16); + (t[0] = new r(1).toRed(this)), (t[1] = A); + for (var i = 2; i < t.length; i++) t[i] = this.mul(t[i - 1], A); + var g = t[0], + n = 0, + B = 0, + I = e.bitLength() % 26; + for (0 === I && (I = 26), i = e.length - 1; i >= 0; i--) { + for (var o = e.words[i], a = I - 1; a >= 0; a--) { + var Q = (o >> a) & 1; + g !== t[0] && (g = this.sqr(g)), + 0 !== Q || 0 !== n + ? ((n <<= 1), + (n |= Q), + (4 === ++B || (0 === i && 0 === a)) && + ((g = this.mul(g, t[n])), (B = 0), (n = 0))) + : (B = 0); + } + I = 26; + } + return g; + }), + (y.prototype.convertTo = function (A) { + var e = A.umod(this.m); + return e === A ? e.clone() : e; + }), + (y.prototype.convertFrom = function (A) { + var e = A.clone(); + return (e.red = null), e; + }), + (r.mont = function (A) { + return new M(A); + }), + g(M, y), + (M.prototype.convertTo = function (A) { + return this.imod(A.ushln(this.shift)); + }), + (M.prototype.convertFrom = function (A) { + var e = this.imod(A.mul(this.rinv)); + return (e.red = null), e; + }), + (M.prototype.imul = function (A, e) { + if (A.isZero() || e.isZero()) + return (A.words[0] = 0), (A.length = 1), A; + var t = A.imul(e), + i = t + .maskn(this.shift) + .mul(this.minv) + .imaskn(this.shift) + .mul(this.m), + g = t.isub(i).iushrn(this.shift), + r = g; + return ( + g.cmp(this.m) >= 0 + ? (r = g.isub(this.m)) + : g.cmpn(0) < 0 && (r = g.iadd(this.m)), + r._forceRed(this) + ); + }), + (M.prototype.mul = function (A, e) { + if (A.isZero() || e.isZero()) return new r(0)._forceRed(this); + var t = A.mul(e), + i = t + .maskn(this.shift) + .mul(this.minv) + .imaskn(this.shift) + .mul(this.m), + g = t.isub(i).iushrn(this.shift), + n = g; + return ( + g.cmp(this.m) >= 0 + ? (n = g.isub(this.m)) + : g.cmpn(0) < 0 && (n = g.iadd(this.m)), + n._forceRed(this) + ); + }), + (M.prototype.invm = function (A) { + return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this); + }); + })(void 0 === e || e, this); + }, + { buffer: 19 }, + ], + 317: [ + function (A, e, t) { + var i = A("base-x"); + e.exports = i( + "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz" + ); + }, + { "base-x": 311 }, + ], + 318: [ + function (A, e, t) { + "use strict"; + const i = (A, e) => { + if ("string" != typeof A && !Array.isArray(A)) + throw new TypeError("Expected the input to be `string | string[]`"); + e = Object.assign({ pascalCase: !1 }, e); + return 0 === + (A = Array.isArray(A) + ? A.map((A) => A.trim()) + .filter((A) => A.length) + .join("-") + : A.trim()).length + ? "" + : 1 === A.length + ? e.pascalCase + ? A.toUpperCase() + : A.toLowerCase() + : (A !== A.toLowerCase() && + (A = ((A) => { + let e = !1, + t = !1, + i = !1; + for (let g = 0; g < A.length; g++) { + const r = A[g]; + e && /[a-zA-Z]/.test(r) && r.toUpperCase() === r + ? ((A = A.slice(0, g) + "-" + A.slice(g)), + (e = !1), + (i = t), + (t = !0), + g++) + : t && i && /[a-zA-Z]/.test(r) && r.toLowerCase() === r + ? ((A = A.slice(0, g - 1) + "-" + A.slice(g - 1)), + (i = t), + (t = !1), + (e = !0)) + : ((e = r.toLowerCase() === r && r.toUpperCase() !== r), + (i = t), + (t = r.toUpperCase() === r && r.toLowerCase() !== r)); + } + return A; + })(A)), + ((A) => + e.pascalCase ? A.charAt(0).toUpperCase() + A.slice(1) : A)( + (A = A.replace(/^[_.\- ]+/, "") + .toLowerCase() + .replace(/[_.\- ]+(\w|$)/g, (A, e) => e.toUpperCase()) + .replace(/\d+(\w|$)/g, (A) => A.toUpperCase())) + )); + }; + (e.exports = i), (e.exports.default = i); + }, + {}, + ], + 319: [ + function (A, e, t) { + "use strict"; + e.exports = { + aliceblue: [240, 248, 255], + antiquewhite: [250, 235, 215], + aqua: [0, 255, 255], + aquamarine: [127, 255, 212], + azure: [240, 255, 255], + beige: [245, 245, 220], + bisque: [255, 228, 196], + black: [0, 0, 0], + blanchedalmond: [255, 235, 205], + blue: [0, 0, 255], + blueviolet: [138, 43, 226], + brown: [165, 42, 42], + burlywood: [222, 184, 135], + cadetblue: [95, 158, 160], + chartreuse: [127, 255, 0], + chocolate: [210, 105, 30], + coral: [255, 127, 80], + cornflowerblue: [100, 149, 237], + cornsilk: [255, 248, 220], + crimson: [220, 20, 60], + cyan: [0, 255, 255], + darkblue: [0, 0, 139], + darkcyan: [0, 139, 139], + darkgoldenrod: [184, 134, 11], + darkgray: [169, 169, 169], + darkgreen: [0, 100, 0], + darkgrey: [169, 169, 169], + darkkhaki: [189, 183, 107], + darkmagenta: [139, 0, 139], + darkolivegreen: [85, 107, 47], + darkorange: [255, 140, 0], + darkorchid: [153, 50, 204], + darkred: [139, 0, 0], + darksalmon: [233, 150, 122], + darkseagreen: [143, 188, 143], + darkslateblue: [72, 61, 139], + darkslategray: [47, 79, 79], + darkslategrey: [47, 79, 79], + darkturquoise: [0, 206, 209], + darkviolet: [148, 0, 211], + deeppink: [255, 20, 147], + deepskyblue: [0, 191, 255], + dimgray: [105, 105, 105], + dimgrey: [105, 105, 105], + dodgerblue: [30, 144, 255], + firebrick: [178, 34, 34], + floralwhite: [255, 250, 240], + forestgreen: [34, 139, 34], + fuchsia: [255, 0, 255], + gainsboro: [220, 220, 220], + ghostwhite: [248, 248, 255], + gold: [255, 215, 0], + goldenrod: [218, 165, 32], + gray: [128, 128, 128], + green: [0, 128, 0], + greenyellow: [173, 255, 47], + grey: [128, 128, 128], + honeydew: [240, 255, 240], + hotpink: [255, 105, 180], + indianred: [205, 92, 92], + indigo: [75, 0, 130], + ivory: [255, 255, 240], + khaki: [240, 230, 140], + lavender: [230, 230, 250], + lavenderblush: [255, 240, 245], + lawngreen: [124, 252, 0], + lemonchiffon: [255, 250, 205], + lightblue: [173, 216, 230], + lightcoral: [240, 128, 128], + lightcyan: [224, 255, 255], + lightgoldenrodyellow: [250, 250, 210], + lightgray: [211, 211, 211], + lightgreen: [144, 238, 144], + lightgrey: [211, 211, 211], + lightpink: [255, 182, 193], + lightsalmon: [255, 160, 122], + lightseagreen: [32, 178, 170], + lightskyblue: [135, 206, 250], + lightslategray: [119, 136, 153], + lightslategrey: [119, 136, 153], + lightsteelblue: [176, 196, 222], + lightyellow: [255, 255, 224], + lime: [0, 255, 0], + limegreen: [50, 205, 50], + linen: [250, 240, 230], + magenta: [255, 0, 255], + maroon: [128, 0, 0], + mediumaquamarine: [102, 205, 170], + mediumblue: [0, 0, 205], + mediumorchid: [186, 85, 211], + mediumpurple: [147, 112, 219], + mediumseagreen: [60, 179, 113], + mediumslateblue: [123, 104, 238], + mediumspringgreen: [0, 250, 154], + mediumturquoise: [72, 209, 204], + mediumvioletred: [199, 21, 133], + midnightblue: [25, 25, 112], + mintcream: [245, 255, 250], + mistyrose: [255, 228, 225], + moccasin: [255, 228, 181], + navajowhite: [255, 222, 173], + navy: [0, 0, 128], + oldlace: [253, 245, 230], + olive: [128, 128, 0], + olivedrab: [107, 142, 35], + orange: [255, 165, 0], + orangered: [255, 69, 0], + orchid: [218, 112, 214], + palegoldenrod: [238, 232, 170], + palegreen: [152, 251, 152], + paleturquoise: [175, 238, 238], + palevioletred: [219, 112, 147], + papayawhip: [255, 239, 213], + peachpuff: [255, 218, 185], + peru: [205, 133, 63], + pink: [255, 192, 203], + plum: [221, 160, 221], + powderblue: [176, 224, 230], + purple: [128, 0, 128], + rebeccapurple: [102, 51, 153], + red: [255, 0, 0], + rosybrown: [188, 143, 143], + royalblue: [65, 105, 225], + saddlebrown: [139, 69, 19], + salmon: [250, 128, 114], + sandybrown: [244, 164, 96], + seagreen: [46, 139, 87], + seashell: [255, 245, 238], + sienna: [160, 82, 45], + silver: [192, 192, 192], + skyblue: [135, 206, 235], + slateblue: [106, 90, 205], + slategray: [112, 128, 144], + slategrey: [112, 128, 144], + snow: [255, 250, 250], + springgreen: [0, 255, 127], + steelblue: [70, 130, 180], + tan: [210, 180, 140], + teal: [0, 128, 128], + thistle: [216, 191, 216], + tomato: [255, 99, 71], + turquoise: [64, 224, 208], + violet: [238, 130, 238], + wheat: [245, 222, 179], + white: [255, 255, 255], + whitesmoke: [245, 245, 245], + yellow: [255, 255, 0], + yellowgreen: [154, 205, 50], + }; + }, + {}, + ], + 320: [ + function (A, e, t) { + "use strict"; + const i = (A) => + A && A.includeBoundaries + ? "(?:(?<=\\s|^)(?=[a-fA-F\\d:])|(?<=[a-fA-F\\d:])(?=\\s|$))" + : "", + g = + "(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]\\d|\\d)(?:\\.(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]\\d|\\d)){3}", + r = "[a-fA-F\\d]{1,4}", + n = + `\n(\n(?:${r}:){7}(?:${r}|:)| // 1:2:3:4:5:6:7:: 1:2:3:4:5:6:7:8\n(?:${r}:){6}(?:${g}|:${r}|:)| // 1:2:3:4:5:6:: 1:2:3:4:5:6::8 1:2:3:4:5:6::8 1:2:3:4:5:6::1.2.3.4\n(?:${r}:){5}(?::${g}|(:${r}){1,2}|:)| // 1:2:3:4:5:: 1:2:3:4:5::7:8 1:2:3:4:5::8 1:2:3:4:5::7:1.2.3.4\n(?:${r}:){4}(?:(:${r}){0,1}:${g}|(:${r}){1,3}|:)| // 1:2:3:4:: 1:2:3:4::6:7:8 1:2:3:4::8 1:2:3:4::6:7:1.2.3.4\n(?:${r}:){3}(?:(:${r}){0,2}:${g}|(:${r}){1,4}|:)| // 1:2:3:: 1:2:3::5:6:7:8 1:2:3::8 1:2:3::5:6:7:1.2.3.4\n(?:${r}:){2}(?:(:${r}){0,3}:${g}|(:${r}){1,5}|:)| // 1:2:: 1:2::4:5:6:7:8 1:2::8 1:2::4:5:6:7:1.2.3.4\n(?:${r}:){1}(?:(:${r}){0,4}:${g}|(:${r}){1,6}|:)| // 1:: 1::3:4:5:6:7:8 1::8 1::3:4:5:6:7:1.2.3.4\n(?::((?::${r}){0,5}:${g}|(?::${r}){1,7}|:)) // ::2:3:4:5:6:7:8 ::2:3:4:5:6:7:8 ::8 ::1.2.3.4\n)(%[0-9a-zA-Z]{1,})? // %eth0 %1\n` + .replace(/\s*\/\/.*$/gm, "") + .replace(/\n/g, "") + .trim(), + B = (A) => + A && A.exact + ? new RegExp(`(?:^${g}$)|(?:^${n}$)`) + : new RegExp( + `(?:${i(A)}${g}${i(A)})|(?:${i(A)}${n}${i(A)})`, + "g" + ); + (B.v4 = (A) => + A && A.exact + ? new RegExp(`^${g}$`) + : new RegExp(`${i(A)}${g}${i(A)}`, "g")), + (B.v6 = (A) => + A && A.exact + ? new RegExp(`^${n}$`) + : new RegExp(`${i(A)}${n}${i(A)}`, "g")), + (e.exports = B); + }, + {}, + ], + 321: [ + function (A, e, t) { + var i = A("buffer"), + g = i.Buffer; + function r(A, e) { + for (var t in A) e[t] = A[t]; + } + function n(A, e, t) { + return g(A, e, t); + } + g.from && g.alloc && g.allocUnsafe && g.allocUnsafeSlow + ? (e.exports = i) + : (r(i, t), (t.Buffer = n)), + (n.prototype = Object.create(g.prototype)), + r(g, n), + (n.from = function (A, e, t) { + if ("number" == typeof A) + throw new TypeError("Argument must not be a number"); + return g(A, e, t); + }), + (n.alloc = function (A, e, t) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + var i = g(A); + return ( + void 0 !== e + ? "string" == typeof t + ? i.fill(e, t) + : i.fill(e) + : i.fill(0), + i + ); + }), + (n.allocUnsafe = function (A) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + return g(A); + }), + (n.allocUnsafeSlow = function (A) { + if ("number" != typeof A) + throw new TypeError("Argument must be a number"); + return i.SlowBuffer(A); + }); + }, + { buffer: 64 }, + ], + 322: [ + function (A, e, t) { + "use strict"; + e.exports = { stdout: !1, stderr: !1 }; + }, + {}, + ], + 323: [ + function (A, e, t) { + const i = A("@polkadot/util-crypto/address/decode").default, + g = A("@polkadot/util-crypto/address/encode").default; + globalThis.addressChanger = () => { + const A = document.getElementById("input"), + e = document.getElementById("prefix-select"), + t = document.getElementById("output"), + r = e.options[e.selectedIndex].value; + try { + const e = i(A.value), + n = g(e, r); + t.textContent = n.toString(); + } catch (A) { + console.log(A); + } + }; + }, + { + "@polkadot/util-crypto/address/decode": 202, + "@polkadot/util-crypto/address/encode": 204, + }, + ], + }, + {}, + [323] +); diff --git a/website/translated_docs/ar/ambassadors.md b/polkadot-wiki/translated_docs/ar/ambassadors.md similarity index 100% rename from website/translated_docs/ar/ambassadors.md rename to polkadot-wiki/translated_docs/ar/ambassadors.md diff --git a/website/translated_docs/ar/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/ar/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/ar/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/ar/build-build-with-polkadot.md diff --git a/website/translated_docs/ar/build-cumulus.md b/polkadot-wiki/translated_docs/ar/build-cumulus.md similarity index 100% rename from website/translated_docs/ar/build-cumulus.md rename to polkadot-wiki/translated_docs/ar/build-cumulus.md diff --git a/website/translated_docs/ar/build-hackathon.md b/polkadot-wiki/translated_docs/ar/build-hackathon.md similarity index 100% rename from website/translated_docs/ar/build-hackathon.md rename to polkadot-wiki/translated_docs/ar/build-hackathon.md diff --git a/website/translated_docs/ar/build-index.md b/polkadot-wiki/translated_docs/ar/build-index.md similarity index 100% rename from website/translated_docs/ar/build-index.md rename to polkadot-wiki/translated_docs/ar/build-index.md diff --git a/website/translated_docs/ar/build-integration.md b/polkadot-wiki/translated_docs/ar/build-integration.md similarity index 100% rename from website/translated_docs/ar/build-integration.md rename to polkadot-wiki/translated_docs/ar/build-integration.md diff --git a/website/translated_docs/ar/build-node-interaction.md b/polkadot-wiki/translated_docs/ar/build-node-interaction.md similarity index 100% rename from website/translated_docs/ar/build-node-interaction.md rename to polkadot-wiki/translated_docs/ar/build-node-interaction.md diff --git a/website/translated_docs/ar/build-node-management.md b/polkadot-wiki/translated_docs/ar/build-node-management.md similarity index 100% rename from website/translated_docs/ar/build-node-management.md rename to polkadot-wiki/translated_docs/ar/build-node-management.md diff --git a/website/translated_docs/ar/build-oracle.md b/polkadot-wiki/translated_docs/ar/build-oracle.md similarity index 100% rename from website/translated_docs/ar/build-oracle.md rename to polkadot-wiki/translated_docs/ar/build-oracle.md diff --git a/website/translated_docs/ar/build-parachains-rococo.md b/polkadot-wiki/translated_docs/ar/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/ar/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/ar/build-parachains-rococo.md diff --git a/website/translated_docs/ar/build-pdk.md b/polkadot-wiki/translated_docs/ar/build-pdk.md similarity index 100% rename from website/translated_docs/ar/build-pdk.md rename to polkadot-wiki/translated_docs/ar/build-pdk.md diff --git a/polkadot-wiki/translated_docs/ar/build-protocol-info.md b/polkadot-wiki/translated_docs/ar/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ar/build-smart-contracts.md b/polkadot-wiki/translated_docs/ar/build-smart-contracts.md similarity index 100% rename from website/translated_docs/ar/build-smart-contracts.md rename to polkadot-wiki/translated_docs/ar/build-smart-contracts.md diff --git a/website/translated_docs/ar/build-tools-index.md b/polkadot-wiki/translated_docs/ar/build-tools-index.md similarity index 100% rename from website/translated_docs/ar/build-tools-index.md rename to polkadot-wiki/translated_docs/ar/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/ar/build-transaction-construction.md b/polkadot-wiki/translated_docs/ar/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/ar/build-wallets.md b/polkadot-wiki/translated_docs/ar/build-wallets.md similarity index 100% rename from website/translated_docs/ar/build-wallets.md rename to polkadot-wiki/translated_docs/ar/build-wallets.md diff --git a/polkadot-wiki/translated_docs/ar/claims.md b/polkadot-wiki/translated_docs/ar/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ar/community.md b/polkadot-wiki/translated_docs/ar/community.md similarity index 100% rename from website/translated_docs/ar/community.md rename to polkadot-wiki/translated_docs/ar/community.md diff --git a/website/translated_docs/ar/contributing.md b/polkadot-wiki/translated_docs/ar/contributing.md similarity index 100% rename from website/translated_docs/ar/contributing.md rename to polkadot-wiki/translated_docs/ar/contributing.md diff --git a/website/translated_docs/ar/contributors.md b/polkadot-wiki/translated_docs/ar/contributors.md similarity index 100% rename from website/translated_docs/ar/contributors.md rename to polkadot-wiki/translated_docs/ar/contributors.md diff --git a/website/translated_docs/ar/ens.md b/polkadot-wiki/translated_docs/ar/ens.md similarity index 100% rename from website/translated_docs/ar/ens.md rename to polkadot-wiki/translated_docs/ar/ens.md diff --git a/website/translated_docs/ar/faq.md b/polkadot-wiki/translated_docs/ar/faq.md similarity index 100% rename from website/translated_docs/ar/faq.md rename to polkadot-wiki/translated_docs/ar/faq.md diff --git a/polkadot-wiki/translated_docs/ar/getting-started.md b/polkadot-wiki/translated_docs/ar/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ar/glossary.md b/polkadot-wiki/translated_docs/ar/glossary.md similarity index 100% rename from website/translated_docs/ar/glossary.md rename to polkadot-wiki/translated_docs/ar/glossary.md diff --git a/polkadot-wiki/translated_docs/ar/grants.md b/polkadot-wiki/translated_docs/ar/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/ar/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/ar/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ar/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/ar/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/ar/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/ar/kusama-bug-bounty.md diff --git a/website/translated_docs/ar/kusama-claims.md b/polkadot-wiki/translated_docs/ar/kusama-claims.md similarity index 100% rename from website/translated_docs/ar/kusama-claims.md rename to polkadot-wiki/translated_docs/ar/kusama-claims.md diff --git a/website/translated_docs/ar/kusama-coc.md b/polkadot-wiki/translated_docs/ar/kusama-coc.md similarity index 100% rename from website/translated_docs/ar/kusama-coc.md rename to polkadot-wiki/translated_docs/ar/kusama-coc.md diff --git a/website/translated_docs/ar/kusama-community.md b/polkadot-wiki/translated_docs/ar/kusama-community.md similarity index 100% rename from website/translated_docs/ar/kusama-community.md rename to polkadot-wiki/translated_docs/ar/kusama-community.md diff --git a/website/translated_docs/ar/kusama-endpoints.md b/polkadot-wiki/translated_docs/ar/kusama-endpoints.md similarity index 100% rename from website/translated_docs/ar/kusama-endpoints.md rename to polkadot-wiki/translated_docs/ar/kusama-endpoints.md diff --git a/website/translated_docs/ar/kusama-faucet.md b/polkadot-wiki/translated_docs/ar/kusama-faucet.md similarity index 100% rename from website/translated_docs/ar/kusama-faucet.md rename to polkadot-wiki/translated_docs/ar/kusama-faucet.md diff --git a/website/translated_docs/ar/kusama-getting-started.md b/polkadot-wiki/translated_docs/ar/kusama-getting-started.md similarity index 100% rename from website/translated_docs/ar/kusama-getting-started.md rename to polkadot-wiki/translated_docs/ar/kusama-getting-started.md diff --git a/website/translated_docs/ar/kusama-index.md b/polkadot-wiki/translated_docs/ar/kusama-index.md similarity index 100% rename from website/translated_docs/ar/kusama-index.md rename to polkadot-wiki/translated_docs/ar/kusama-index.md diff --git a/polkadot-wiki/translated_docs/ar/kusama-ledger.md b/polkadot-wiki/translated_docs/ar/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/ar/kusama-parameters.md b/polkadot-wiki/translated_docs/ar/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ar/kusama-social-recovery.md b/polkadot-wiki/translated_docs/ar/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/ar/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/ar/kusama-social-recovery.md diff --git a/website/translated_docs/ar/kusama-timeline.md b/polkadot-wiki/translated_docs/ar/kusama-timeline.md similarity index 100% rename from website/translated_docs/ar/kusama-timeline.md rename to polkadot-wiki/translated_docs/ar/kusama-timeline.md diff --git a/website/translated_docs/ar/learn-DOT.md b/polkadot-wiki/translated_docs/ar/learn-DOT.md similarity index 100% rename from website/translated_docs/ar/learn-DOT.md rename to polkadot-wiki/translated_docs/ar/learn-DOT.md diff --git a/website/translated_docs/ar/learn-account-generation.md b/polkadot-wiki/translated_docs/ar/learn-account-generation.md similarity index 100% rename from website/translated_docs/ar/learn-account-generation.md rename to polkadot-wiki/translated_docs/ar/learn-account-generation.md diff --git a/website/translated_docs/ar/learn-account-restore.md b/polkadot-wiki/translated_docs/ar/learn-account-restore.md similarity index 100% rename from website/translated_docs/ar/learn-account-restore.md rename to polkadot-wiki/translated_docs/ar/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/ar/learn-accounts.md b/polkadot-wiki/translated_docs/ar/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ar/learn-architecture.md b/polkadot-wiki/translated_docs/ar/learn-architecture.md similarity index 100% rename from website/translated_docs/ar/learn-architecture.md rename to polkadot-wiki/translated_docs/ar/learn-architecture.md diff --git a/website/translated_docs/ar/learn-auction.md b/polkadot-wiki/translated_docs/ar/learn-auction.md similarity index 100% rename from website/translated_docs/ar/learn-auction.md rename to polkadot-wiki/translated_docs/ar/learn-auction.md diff --git a/polkadot-wiki/translated_docs/ar/learn-availability.md b/polkadot-wiki/translated_docs/ar/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/ar/learn-balance-transfers.md b/polkadot-wiki/translated_docs/ar/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/ar/learn-bridges.md b/polkadot-wiki/translated_docs/ar/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ar/learn-collator.md b/polkadot-wiki/translated_docs/ar/learn-collator.md similarity index 100% rename from website/translated_docs/ar/learn-collator.md rename to polkadot-wiki/translated_docs/ar/learn-collator.md diff --git a/website/translated_docs/ar/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/ar/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/ar/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/ar/learn-comparison-dfinity.md diff --git a/website/translated_docs/ar/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/ar/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/ar/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/ar/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/ar/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/ar/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/ar/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/ar/learn-comparisons-cosmos.md diff --git a/website/translated_docs/ar/learn-comparisons.md b/polkadot-wiki/translated_docs/ar/learn-comparisons.md similarity index 100% rename from website/translated_docs/ar/learn-comparisons.md rename to polkadot-wiki/translated_docs/ar/learn-comparisons.md diff --git a/website/translated_docs/ar/learn-consensus.md b/polkadot-wiki/translated_docs/ar/learn-consensus.md similarity index 100% rename from website/translated_docs/ar/learn-consensus.md rename to polkadot-wiki/translated_docs/ar/learn-consensus.md diff --git a/website/translated_docs/ar/learn-crosschain.md b/polkadot-wiki/translated_docs/ar/learn-crosschain.md similarity index 100% rename from website/translated_docs/ar/learn-crosschain.md rename to polkadot-wiki/translated_docs/ar/learn-crosschain.md diff --git a/website/translated_docs/ar/learn-crowdloans.md b/polkadot-wiki/translated_docs/ar/learn-crowdloans.md similarity index 100% rename from website/translated_docs/ar/learn-crowdloans.md rename to polkadot-wiki/translated_docs/ar/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/ar/learn-cryptography.md b/polkadot-wiki/translated_docs/ar/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/ar/learn-governance.md b/polkadot-wiki/translated_docs/ar/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ar/learn-identity.md b/polkadot-wiki/translated_docs/ar/learn-identity.md similarity index 100% rename from website/translated_docs/ar/learn-identity.md rename to polkadot-wiki/translated_docs/ar/learn-identity.md diff --git a/website/translated_docs/ar/learn-implementations.md b/polkadot-wiki/translated_docs/ar/learn-implementations.md similarity index 100% rename from website/translated_docs/ar/learn-implementations.md rename to polkadot-wiki/translated_docs/ar/learn-implementations.md diff --git a/website/translated_docs/ar/learn-implementers-guide.md b/polkadot-wiki/translated_docs/ar/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/ar/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/ar/learn-implementers-guide.md diff --git a/website/translated_docs/ar/learn-keys.md b/polkadot-wiki/translated_docs/ar/learn-keys.md similarity index 100% rename from website/translated_docs/ar/learn-keys.md rename to polkadot-wiki/translated_docs/ar/learn-keys.md diff --git a/website/translated_docs/ar/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/ar/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/ar/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/ar/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/ar/learn-launch.md b/polkadot-wiki/translated_docs/ar/learn-launch.md similarity index 100% rename from website/translated_docs/ar/learn-launch.md rename to polkadot-wiki/translated_docs/ar/learn-launch.md diff --git a/polkadot-wiki/translated_docs/ar/learn-ledger.md b/polkadot-wiki/translated_docs/ar/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ar/learn-nominator.md b/polkadot-wiki/translated_docs/ar/learn-nominator.md similarity index 100% rename from website/translated_docs/ar/learn-nominator.md rename to polkadot-wiki/translated_docs/ar/learn-nominator.md diff --git a/website/translated_docs/ar/learn-parachains.md b/polkadot-wiki/translated_docs/ar/learn-parachains.md similarity index 100% rename from website/translated_docs/ar/learn-parachains.md rename to polkadot-wiki/translated_docs/ar/learn-parachains.md diff --git a/website/translated_docs/ar/learn-parathreads.md b/polkadot-wiki/translated_docs/ar/learn-parathreads.md similarity index 100% rename from website/translated_docs/ar/learn-parathreads.md rename to polkadot-wiki/translated_docs/ar/learn-parathreads.md diff --git a/website/translated_docs/ar/learn-phragmen.md b/polkadot-wiki/translated_docs/ar/learn-phragmen.md similarity index 100% rename from website/translated_docs/ar/learn-phragmen.md rename to polkadot-wiki/translated_docs/ar/learn-phragmen.md diff --git a/website/translated_docs/ar/learn-polkadot-host.md b/polkadot-wiki/translated_docs/ar/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/ar/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/ar/learn-polkadot-host.md diff --git a/website/translated_docs/ar/learn-proxies.md b/polkadot-wiki/translated_docs/ar/learn-proxies.md similarity index 100% rename from website/translated_docs/ar/learn-proxies.md rename to polkadot-wiki/translated_docs/ar/learn-proxies.md diff --git a/website/translated_docs/ar/learn-randomness.md b/polkadot-wiki/translated_docs/ar/learn-randomness.md similarity index 100% rename from website/translated_docs/ar/learn-randomness.md rename to polkadot-wiki/translated_docs/ar/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/ar/learn-registrar.md b/polkadot-wiki/translated_docs/ar/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ar/learn-scams.md b/polkadot-wiki/translated_docs/ar/learn-scams.md similarity index 100% rename from website/translated_docs/ar/learn-scams.md rename to polkadot-wiki/translated_docs/ar/learn-scams.md diff --git a/website/translated_docs/ar/learn-security.md b/polkadot-wiki/translated_docs/ar/learn-security.md similarity index 100% rename from website/translated_docs/ar/learn-security.md rename to polkadot-wiki/translated_docs/ar/learn-security.md diff --git a/website/translated_docs/ar/learn-simple-payouts.md b/polkadot-wiki/translated_docs/ar/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/ar/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/ar/learn-simple-payouts.md diff --git a/website/translated_docs/ar/learn-spree.md b/polkadot-wiki/translated_docs/ar/learn-spree.md similarity index 100% rename from website/translated_docs/ar/learn-spree.md rename to polkadot-wiki/translated_docs/ar/learn-spree.md diff --git a/polkadot-wiki/translated_docs/ar/learn-staking.md b/polkadot-wiki/translated_docs/ar/learn-staking.md new file mode 100644 index 000000000000..904382eb43af --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-staking.md @@ -0,0 +1,259 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ar/learn-transaction-fees.md b/polkadot-wiki/translated_docs/ar/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/ar/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/ar/learn-transaction-fees.md diff --git a/polkadot-wiki/translated_docs/ar/learn-treasury.md b/polkadot-wiki/translated_docs/ar/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ar/learn-validator.md b/polkadot-wiki/translated_docs/ar/learn-validator.md similarity index 100% rename from website/translated_docs/ar/learn-validator.md rename to polkadot-wiki/translated_docs/ar/learn-validator.md diff --git a/website/translated_docs/ar/learn-wasm.md b/polkadot-wiki/translated_docs/ar/learn-wasm.md similarity index 100% rename from website/translated_docs/ar/learn-wasm.md rename to polkadot-wiki/translated_docs/ar/learn-wasm.md diff --git a/website/translated_docs/ar/maintain-errors.md b/polkadot-wiki/translated_docs/ar/maintain-errors.md similarity index 100% rename from website/translated_docs/ar/maintain-errors.md rename to polkadot-wiki/translated_docs/ar/maintain-errors.md diff --git a/website/translated_docs/ar/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/ar/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-democracy.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/ar/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/ar/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/ar/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/ar/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/ar/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/ar/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ar/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/ar/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ar/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/ar/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/ar/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/ar/maintain-guides-validator-payout.md diff --git a/polkadot-wiki/translated_docs/ar/maintain-index.md b/polkadot-wiki/translated_docs/ar/maintain-index.md new file mode 100644 index 000000000000..acd2a9953a5f --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/maintain-index.md @@ -0,0 +1,43 @@ +--- +id: maintain-index +title: Network Maintainers +sidebar_label: Network Maintainers +slug: / +--- + +Welcome to the network maintainers section of the Polkadot wiki. Here you will find information and guides to set up a node and run the network. + +## Node + +- [Networks Guide](maintain-networks) - A list of the available Polkadot networks that you can connect to with a node. +- [Set up a Full Node](maintain-sync) - Get up and started by syncing a full node for the Kusama network. The steps in the guide will broadly apply also to any Substrate-based network (like Polkadot). +- [Set up WSS using Nginx](maintain-wss) - Set up a Secure WebSockets server for your node's WebSockets connection. + +## Collator + +- [Learn about Collators](learn-collator) - High level overview of collators and related links. + +## Nominator + +- [Learn about Nominators](learn-nominator) - High level overview of nominators and related links. +- [Nomination Guide (Polkadot)](maintain-guides-how-to-nominate-polkadot) - Walkthrough on how to nominate on the Polkadot network. +- [Nomination Guide (Kusama)](maintain-guides-how-to-nominate-kusama) - Walkthrough on how to nominate on the Kusama canary network. +- [How to stop being a Nominator](maintain-guides-how-to-unbond) - Guide on how to stop nominating. + +## Validator + +- [Learn about Validators](learn-validator) - High level overview of validator and related links. +- [Validator Payouts](maintain-guides-validator-payout) - Overview on how validator rewards are calculated and paid. +- [Validation Guide (Polkadot)](maintain-guides-how-to-validate-polkadot) - Walkthrough on how to validate on the Polkadot network. +- [Validation Guide (Kusama)](maintain-guides-how-to-validate-kusama) - Walkthrough on how to validate on the Kusama canary network. +- [Using systemmd for the Validator Node](maintain-guides-how-to-systemd) - Configuring systemmd with the Validator node. +- [Secure Validator](maintain-guides-secure-validator) - Best tips and practices for validating. +- [How to use Polkadot Secure Validator](maintain-guides-how-to-use-polkadot-secure-validator) - Walkthrough on how to set up a validator securely. +- [How to upgrade a Validator Node](maintain-guides-how-to-upgrade) - Guide on upgrading your validator node. +- [How to Chill](maintain-guides-how-to-chill) - Walkthrough on how to chill as a validator. + +## Governance + +- [How to pariticipate in Governance](maintain-guides-democracy) - Walkthrough on how to participate in governance. +- [How to join the Council](maintain-guides-how-to-join-council) - Step by step guide for running for the Council. +- [How to vote for a Councillor](maintain-guides-how-to-vote-councillor) - Step by step guide for voting for your favorite councillors. diff --git a/website/translated_docs/ar/maintain-networks.md b/polkadot-wiki/translated_docs/ar/maintain-networks.md similarity index 100% rename from website/translated_docs/ar/maintain-networks.md rename to polkadot-wiki/translated_docs/ar/maintain-networks.md diff --git a/polkadot-wiki/translated_docs/ar/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/ar/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ar/maintain-sync.md b/polkadot-wiki/translated_docs/ar/maintain-sync.md similarity index 100% rename from website/translated_docs/ar/maintain-sync.md rename to polkadot-wiki/translated_docs/ar/maintain-sync.md diff --git a/website/translated_docs/ar/maintain-wss.md b/polkadot-wiki/translated_docs/ar/maintain-wss.md similarity index 100% rename from website/translated_docs/ar/maintain-wss.md rename to polkadot-wiki/translated_docs/ar/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/ar/redenomination.md b/polkadot-wiki/translated_docs/ar/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ar/research.md b/polkadot-wiki/translated_docs/ar/research.md similarity index 100% rename from website/translated_docs/ar/research.md rename to polkadot-wiki/translated_docs/ar/research.md diff --git a/polkadot-wiki/translated_docs/ar/thousand-validators.md b/polkadot-wiki/translated_docs/ar/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ar/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/de/ambassadors.md b/polkadot-wiki/translated_docs/de/ambassadors.md similarity index 100% rename from website/translated_docs/de/ambassadors.md rename to polkadot-wiki/translated_docs/de/ambassadors.md diff --git a/website/translated_docs/de/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/de/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/de/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/de/build-build-with-polkadot.md diff --git a/website/translated_docs/de/build-cumulus.md b/polkadot-wiki/translated_docs/de/build-cumulus.md similarity index 100% rename from website/translated_docs/de/build-cumulus.md rename to polkadot-wiki/translated_docs/de/build-cumulus.md diff --git a/website/translated_docs/de/build-hackathon.md b/polkadot-wiki/translated_docs/de/build-hackathon.md similarity index 100% rename from website/translated_docs/de/build-hackathon.md rename to polkadot-wiki/translated_docs/de/build-hackathon.md diff --git a/website/translated_docs/de/build-index.md b/polkadot-wiki/translated_docs/de/build-index.md similarity index 100% rename from website/translated_docs/de/build-index.md rename to polkadot-wiki/translated_docs/de/build-index.md diff --git a/website/translated_docs/de/build-integration.md b/polkadot-wiki/translated_docs/de/build-integration.md similarity index 100% rename from website/translated_docs/de/build-integration.md rename to polkadot-wiki/translated_docs/de/build-integration.md diff --git a/website/translated_docs/de/build-node-interaction.md b/polkadot-wiki/translated_docs/de/build-node-interaction.md similarity index 100% rename from website/translated_docs/de/build-node-interaction.md rename to polkadot-wiki/translated_docs/de/build-node-interaction.md diff --git a/website/translated_docs/de/build-node-management.md b/polkadot-wiki/translated_docs/de/build-node-management.md similarity index 100% rename from website/translated_docs/de/build-node-management.md rename to polkadot-wiki/translated_docs/de/build-node-management.md diff --git a/website/translated_docs/de/build-oracle.md b/polkadot-wiki/translated_docs/de/build-oracle.md similarity index 100% rename from website/translated_docs/de/build-oracle.md rename to polkadot-wiki/translated_docs/de/build-oracle.md diff --git a/website/translated_docs/de/build-parachains-rococo.md b/polkadot-wiki/translated_docs/de/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/de/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/de/build-parachains-rococo.md diff --git a/website/translated_docs/de/build-pdk.md b/polkadot-wiki/translated_docs/de/build-pdk.md similarity index 100% rename from website/translated_docs/de/build-pdk.md rename to polkadot-wiki/translated_docs/de/build-pdk.md diff --git a/polkadot-wiki/translated_docs/de/build-protocol-info.md b/polkadot-wiki/translated_docs/de/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/de/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/de/build-smart-contracts.md b/polkadot-wiki/translated_docs/de/build-smart-contracts.md similarity index 100% rename from website/translated_docs/de/build-smart-contracts.md rename to polkadot-wiki/translated_docs/de/build-smart-contracts.md diff --git a/website/translated_docs/de/build-tools-index.md b/polkadot-wiki/translated_docs/de/build-tools-index.md similarity index 100% rename from website/translated_docs/de/build-tools-index.md rename to polkadot-wiki/translated_docs/de/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/de/build-transaction-construction.md b/polkadot-wiki/translated_docs/de/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/de/build-wallets.md b/polkadot-wiki/translated_docs/de/build-wallets.md similarity index 100% rename from website/translated_docs/de/build-wallets.md rename to polkadot-wiki/translated_docs/de/build-wallets.md diff --git a/polkadot-wiki/translated_docs/de/claims.md b/polkadot-wiki/translated_docs/de/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/de/community.md b/polkadot-wiki/translated_docs/de/community.md similarity index 100% rename from website/translated_docs/de/community.md rename to polkadot-wiki/translated_docs/de/community.md diff --git a/website/translated_docs/de/contributing.md b/polkadot-wiki/translated_docs/de/contributing.md similarity index 100% rename from website/translated_docs/de/contributing.md rename to polkadot-wiki/translated_docs/de/contributing.md diff --git a/website/translated_docs/de/contributors.md b/polkadot-wiki/translated_docs/de/contributors.md similarity index 100% rename from website/translated_docs/de/contributors.md rename to polkadot-wiki/translated_docs/de/contributors.md diff --git a/website/translated_docs/de/ens.md b/polkadot-wiki/translated_docs/de/ens.md similarity index 100% rename from website/translated_docs/de/ens.md rename to polkadot-wiki/translated_docs/de/ens.md diff --git a/website/translated_docs/de/faq.md b/polkadot-wiki/translated_docs/de/faq.md similarity index 100% rename from website/translated_docs/de/faq.md rename to polkadot-wiki/translated_docs/de/faq.md diff --git a/polkadot-wiki/translated_docs/de/getting-started.md b/polkadot-wiki/translated_docs/de/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/de/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/de/glossary.md b/polkadot-wiki/translated_docs/de/glossary.md similarity index 100% rename from website/translated_docs/de/glossary.md rename to polkadot-wiki/translated_docs/de/glossary.md diff --git a/polkadot-wiki/translated_docs/de/grants.md b/polkadot-wiki/translated_docs/de/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/de/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/de/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/de/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/de/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/de/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/de/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/de/kusama-bug-bounty.md diff --git a/website/translated_docs/de/kusama-claims.md b/polkadot-wiki/translated_docs/de/kusama-claims.md similarity index 100% rename from website/translated_docs/de/kusama-claims.md rename to polkadot-wiki/translated_docs/de/kusama-claims.md diff --git a/website/translated_docs/de/kusama-coc.md b/polkadot-wiki/translated_docs/de/kusama-coc.md similarity index 100% rename from website/translated_docs/de/kusama-coc.md rename to polkadot-wiki/translated_docs/de/kusama-coc.md diff --git a/website/translated_docs/de/kusama-community.md b/polkadot-wiki/translated_docs/de/kusama-community.md similarity index 100% rename from website/translated_docs/de/kusama-community.md rename to polkadot-wiki/translated_docs/de/kusama-community.md diff --git a/website/translated_docs/de/kusama-endpoints.md b/polkadot-wiki/translated_docs/de/kusama-endpoints.md similarity index 100% rename from website/translated_docs/de/kusama-endpoints.md rename to polkadot-wiki/translated_docs/de/kusama-endpoints.md diff --git a/website/translated_docs/de/kusama-faucet.md b/polkadot-wiki/translated_docs/de/kusama-faucet.md similarity index 100% rename from website/translated_docs/de/kusama-faucet.md rename to polkadot-wiki/translated_docs/de/kusama-faucet.md diff --git a/website/translated_docs/de/kusama-getting-started.md b/polkadot-wiki/translated_docs/de/kusama-getting-started.md similarity index 100% rename from website/translated_docs/de/kusama-getting-started.md rename to polkadot-wiki/translated_docs/de/kusama-getting-started.md diff --git a/website/translated_docs/de/kusama-index.md b/polkadot-wiki/translated_docs/de/kusama-index.md similarity index 100% rename from website/translated_docs/de/kusama-index.md rename to polkadot-wiki/translated_docs/de/kusama-index.md diff --git a/polkadot-wiki/translated_docs/de/kusama-ledger.md b/polkadot-wiki/translated_docs/de/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/de/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/de/kusama-parameters.md b/polkadot-wiki/translated_docs/de/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/de/kusama-social-recovery.md b/polkadot-wiki/translated_docs/de/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/de/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/de/kusama-social-recovery.md diff --git a/website/translated_docs/de/kusama-timeline.md b/polkadot-wiki/translated_docs/de/kusama-timeline.md similarity index 100% rename from website/translated_docs/de/kusama-timeline.md rename to polkadot-wiki/translated_docs/de/kusama-timeline.md diff --git a/website/translated_docs/de/learn-DOT.md b/polkadot-wiki/translated_docs/de/learn-DOT.md similarity index 100% rename from website/translated_docs/de/learn-DOT.md rename to polkadot-wiki/translated_docs/de/learn-DOT.md diff --git a/website/translated_docs/de/learn-account-generation.md b/polkadot-wiki/translated_docs/de/learn-account-generation.md similarity index 100% rename from website/translated_docs/de/learn-account-generation.md rename to polkadot-wiki/translated_docs/de/learn-account-generation.md diff --git a/website/translated_docs/de/learn-account-restore.md b/polkadot-wiki/translated_docs/de/learn-account-restore.md similarity index 100% rename from website/translated_docs/de/learn-account-restore.md rename to polkadot-wiki/translated_docs/de/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/de/learn-accounts.md b/polkadot-wiki/translated_docs/de/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/de/learn-architecture.md b/polkadot-wiki/translated_docs/de/learn-architecture.md similarity index 100% rename from website/translated_docs/de/learn-architecture.md rename to polkadot-wiki/translated_docs/de/learn-architecture.md diff --git a/website/translated_docs/de/learn-auction.md b/polkadot-wiki/translated_docs/de/learn-auction.md similarity index 100% rename from website/translated_docs/de/learn-auction.md rename to polkadot-wiki/translated_docs/de/learn-auction.md diff --git a/polkadot-wiki/translated_docs/de/learn-availability.md b/polkadot-wiki/translated_docs/de/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/de/learn-balance-transfers.md b/polkadot-wiki/translated_docs/de/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/de/learn-bridges.md b/polkadot-wiki/translated_docs/de/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/de/learn-collator.md b/polkadot-wiki/translated_docs/de/learn-collator.md similarity index 100% rename from website/translated_docs/de/learn-collator.md rename to polkadot-wiki/translated_docs/de/learn-collator.md diff --git a/website/translated_docs/de/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/de/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/de/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/de/learn-comparison-dfinity.md diff --git a/website/translated_docs/de/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/de/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/de/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/de/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/de/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/de/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/de/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/de/learn-comparisons-cosmos.md diff --git a/website/translated_docs/de/learn-comparisons.md b/polkadot-wiki/translated_docs/de/learn-comparisons.md similarity index 100% rename from website/translated_docs/de/learn-comparisons.md rename to polkadot-wiki/translated_docs/de/learn-comparisons.md diff --git a/website/translated_docs/de/learn-consensus.md b/polkadot-wiki/translated_docs/de/learn-consensus.md similarity index 100% rename from website/translated_docs/de/learn-consensus.md rename to polkadot-wiki/translated_docs/de/learn-consensus.md diff --git a/website/translated_docs/de/learn-crosschain.md b/polkadot-wiki/translated_docs/de/learn-crosschain.md similarity index 100% rename from website/translated_docs/de/learn-crosschain.md rename to polkadot-wiki/translated_docs/de/learn-crosschain.md diff --git a/website/translated_docs/de/learn-crowdloans.md b/polkadot-wiki/translated_docs/de/learn-crowdloans.md similarity index 100% rename from website/translated_docs/de/learn-crowdloans.md rename to polkadot-wiki/translated_docs/de/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/de/learn-cryptography.md b/polkadot-wiki/translated_docs/de/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/de/learn-governance.md b/polkadot-wiki/translated_docs/de/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/de/learn-identity.md b/polkadot-wiki/translated_docs/de/learn-identity.md similarity index 100% rename from website/translated_docs/de/learn-identity.md rename to polkadot-wiki/translated_docs/de/learn-identity.md diff --git a/website/translated_docs/de/learn-implementations.md b/polkadot-wiki/translated_docs/de/learn-implementations.md similarity index 100% rename from website/translated_docs/de/learn-implementations.md rename to polkadot-wiki/translated_docs/de/learn-implementations.md diff --git a/website/translated_docs/de/learn-implementers-guide.md b/polkadot-wiki/translated_docs/de/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/de/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/de/learn-implementers-guide.md diff --git a/website/translated_docs/de/learn-keys.md b/polkadot-wiki/translated_docs/de/learn-keys.md similarity index 100% rename from website/translated_docs/de/learn-keys.md rename to polkadot-wiki/translated_docs/de/learn-keys.md diff --git a/website/translated_docs/de/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/de/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/de/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/de/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/de/learn-launch.md b/polkadot-wiki/translated_docs/de/learn-launch.md similarity index 100% rename from website/translated_docs/de/learn-launch.md rename to polkadot-wiki/translated_docs/de/learn-launch.md diff --git a/polkadot-wiki/translated_docs/de/learn-ledger.md b/polkadot-wiki/translated_docs/de/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/de/learn-nominator.md b/polkadot-wiki/translated_docs/de/learn-nominator.md similarity index 100% rename from website/translated_docs/de/learn-nominator.md rename to polkadot-wiki/translated_docs/de/learn-nominator.md diff --git a/website/translated_docs/de/learn-parachains.md b/polkadot-wiki/translated_docs/de/learn-parachains.md similarity index 100% rename from website/translated_docs/de/learn-parachains.md rename to polkadot-wiki/translated_docs/de/learn-parachains.md diff --git a/website/translated_docs/de/learn-parathreads.md b/polkadot-wiki/translated_docs/de/learn-parathreads.md similarity index 100% rename from website/translated_docs/de/learn-parathreads.md rename to polkadot-wiki/translated_docs/de/learn-parathreads.md diff --git a/website/translated_docs/de/learn-phragmen.md b/polkadot-wiki/translated_docs/de/learn-phragmen.md similarity index 100% rename from website/translated_docs/de/learn-phragmen.md rename to polkadot-wiki/translated_docs/de/learn-phragmen.md diff --git a/website/translated_docs/de/learn-polkadot-host.md b/polkadot-wiki/translated_docs/de/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/de/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/de/learn-polkadot-host.md diff --git a/website/translated_docs/de/learn-proxies.md b/polkadot-wiki/translated_docs/de/learn-proxies.md similarity index 100% rename from website/translated_docs/de/learn-proxies.md rename to polkadot-wiki/translated_docs/de/learn-proxies.md diff --git a/website/translated_docs/de/learn-randomness.md b/polkadot-wiki/translated_docs/de/learn-randomness.md similarity index 100% rename from website/translated_docs/de/learn-randomness.md rename to polkadot-wiki/translated_docs/de/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/de/learn-registrar.md b/polkadot-wiki/translated_docs/de/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/de/learn-scams.md b/polkadot-wiki/translated_docs/de/learn-scams.md similarity index 100% rename from website/translated_docs/de/learn-scams.md rename to polkadot-wiki/translated_docs/de/learn-scams.md diff --git a/website/translated_docs/de/learn-security.md b/polkadot-wiki/translated_docs/de/learn-security.md similarity index 100% rename from website/translated_docs/de/learn-security.md rename to polkadot-wiki/translated_docs/de/learn-security.md diff --git a/website/translated_docs/de/learn-simple-payouts.md b/polkadot-wiki/translated_docs/de/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/de/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/de/learn-simple-payouts.md diff --git a/website/translated_docs/de/learn-spree.md b/polkadot-wiki/translated_docs/de/learn-spree.md similarity index 100% rename from website/translated_docs/de/learn-spree.md rename to polkadot-wiki/translated_docs/de/learn-spree.md diff --git a/polkadot-wiki/translated_docs/de/learn-staking.md b/polkadot-wiki/translated_docs/de/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/de/learn-transaction-fees.md b/polkadot-wiki/translated_docs/de/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/de/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/de/learn-transaction-fees.md diff --git a/polkadot-wiki/translated_docs/de/learn-treasury.md b/polkadot-wiki/translated_docs/de/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/de/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/de/learn-validator.md b/polkadot-wiki/translated_docs/de/learn-validator.md similarity index 100% rename from website/translated_docs/de/learn-validator.md rename to polkadot-wiki/translated_docs/de/learn-validator.md diff --git a/website/translated_docs/de/learn-wasm.md b/polkadot-wiki/translated_docs/de/learn-wasm.md similarity index 100% rename from website/translated_docs/de/learn-wasm.md rename to polkadot-wiki/translated_docs/de/learn-wasm.md diff --git a/website/translated_docs/de/maintain-errors.md b/polkadot-wiki/translated_docs/de/maintain-errors.md similarity index 100% rename from website/translated_docs/de/maintain-errors.md rename to polkadot-wiki/translated_docs/de/maintain-errors.md diff --git a/website/translated_docs/de/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/de/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/de/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/de/maintain-guides-democracy.md diff --git a/website/translated_docs/de/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/de/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/de/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/de/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/de/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/de/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/de/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/de/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/de/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/de/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/de/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/de/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/de/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/de/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/de/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/de/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/de/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/de/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/de/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/de/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/de/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/de/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/de/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/de/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/de/maintain-guides-validator-payout.md diff --git a/website/translated_docs/ar/maintain-index.md b/polkadot-wiki/translated_docs/de/maintain-index.md similarity index 100% rename from website/translated_docs/ar/maintain-index.md rename to polkadot-wiki/translated_docs/de/maintain-index.md diff --git a/website/translated_docs/de/maintain-networks.md b/polkadot-wiki/translated_docs/de/maintain-networks.md similarity index 100% rename from website/translated_docs/de/maintain-networks.md rename to polkadot-wiki/translated_docs/de/maintain-networks.md diff --git a/polkadot-wiki/translated_docs/de/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/de/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/de/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/de/maintain-sync.md b/polkadot-wiki/translated_docs/de/maintain-sync.md similarity index 100% rename from website/translated_docs/de/maintain-sync.md rename to polkadot-wiki/translated_docs/de/maintain-sync.md diff --git a/website/translated_docs/de/maintain-wss.md b/polkadot-wiki/translated_docs/de/maintain-wss.md similarity index 100% rename from website/translated_docs/de/maintain-wss.md rename to polkadot-wiki/translated_docs/de/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/de/redenomination.md b/polkadot-wiki/translated_docs/de/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/de/research.md b/polkadot-wiki/translated_docs/de/research.md similarity index 100% rename from website/translated_docs/de/research.md rename to polkadot-wiki/translated_docs/de/research.md diff --git a/polkadot-wiki/translated_docs/de/thousand-validators.md b/polkadot-wiki/translated_docs/de/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/de/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/es-ES/ambassadors.md b/polkadot-wiki/translated_docs/es-ES/ambassadors.md similarity index 100% rename from website/translated_docs/es-ES/ambassadors.md rename to polkadot-wiki/translated_docs/es-ES/ambassadors.md diff --git a/website/translated_docs/es-ES/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/es-ES/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/es-ES/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/es-ES/build-build-with-polkadot.md diff --git a/website/translated_docs/es-ES/build-cumulus.md b/polkadot-wiki/translated_docs/es-ES/build-cumulus.md similarity index 100% rename from website/translated_docs/es-ES/build-cumulus.md rename to polkadot-wiki/translated_docs/es-ES/build-cumulus.md diff --git a/website/translated_docs/es-ES/build-deploy-parachains.md b/polkadot-wiki/translated_docs/es-ES/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/es-ES/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/es-ES/build-deploy-parachains.md diff --git a/website/translated_docs/es-ES/build-dev-roadmap.md b/polkadot-wiki/translated_docs/es-ES/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/es-ES/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/es-ES/build-dev-roadmap.md diff --git a/website/translated_docs/es-ES/build-examples-index.md b/polkadot-wiki/translated_docs/es-ES/build-examples-index.md similarity index 100% rename from website/translated_docs/es-ES/build-examples-index.md rename to polkadot-wiki/translated_docs/es-ES/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/es-ES/build-exchange-integration.md b/polkadot-wiki/translated_docs/es-ES/build-exchange-integration.md new file mode 100644 index 000000000000..dddd3a779fac --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. Tracking the chain head + +Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). + +That will give you a stream of hashes of the most recent finalised headers. + +When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. + +If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. + +## 2. Decoding blocks + +You will need to decode blocks from the basic data into useful fields. + +All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. + +For Genesis Polkadot, the header format is a five-field structure: + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +It also relies on `Extrinsic`. An _extrinsic_ is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. + +The metadata itself is provided encoded in SCALE. Its format is: + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. + +Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various _modules_. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, _extrinsics_), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. Working with SS58 and account addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) _AccountId_. This is simply the public key for the x25519 cryptography used by Substrate. + +However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this _index_ to identify the account. This index is much smaller than the 32-byte _AccountId_, and can usually be encoded in just a couple of bytes. + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: + +`0x00 ` + +**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. + +Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. + +Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. + +### Looking up an index + +Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. + +The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. + +For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. + +This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. + +This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. + +Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. + +## 4. Working with balances + +In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. + +NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. + +The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10\*\*12). For completeness, The exact denominations of the Polkadot currency are: + +| Balance value | Name | +| ------------- | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### Transferring balances + +To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. + +In general, Polkadot's transactions are encoded as _signed_ `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. + +The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. + +NOTE: The nonce retrieved from storage does not take into account _pending_ transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. + +The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. + +The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. + +Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. + +Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +The `function` _in this case_ (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. + +The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. + +### Submitting and checking transactions + +Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. + +This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. + +The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. + +## Conclusion + +This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. + +If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). + +_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/polkadot-wiki/translated_docs/es-ES/build-extrinsic-format.md b/polkadot-wiki/translated_docs/es-ES/build-extrinsic-format.md new file mode 100644 index 000000000000..39a48b855d09 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/build-extrinsic-format.md @@ -0,0 +1,44 @@ +--- +id: build-extrinsic-format +title: Polkadot Extrinsic Format aka Transaction Format +sidebar_label: Polkadot Extrinsic Format aka Transaction Format +--- + +## Old Format + +For reference, the **old** extrinsic format was: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] +``` + +## Current Format + +The Polkadot extrinsic format is: + +``` +[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] +``` + +The _original_ fields refer to the following from the old extrinsic format: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] +``` + +The specific format for the new address type is one of 5 sub-formats, switched on the first byte: + +- `0xff, 32-byte account id` +- `0xfe, 8-byte account index` +- `0xfd, 4-byte account index` +- `0xfc, 2-byte account index` +- `[0xf0...0xfb] (invalid, reserved for future use)` +- `[0x00...0xef] 1-byte account index (less than 0xf0)` + +The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. + +In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). + +## Source + +[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/es-ES/build-hackathon.md b/polkadot-wiki/translated_docs/es-ES/build-hackathon.md similarity index 100% rename from website/translated_docs/es-ES/build-hackathon.md rename to polkadot-wiki/translated_docs/es-ES/build-hackathon.md diff --git a/website/translated_docs/es-ES/build-index.md b/polkadot-wiki/translated_docs/es-ES/build-index.md similarity index 100% rename from website/translated_docs/es-ES/build-index.md rename to polkadot-wiki/translated_docs/es-ES/build-index.md diff --git a/website/translated_docs/es-ES/build-integration.md b/polkadot-wiki/translated_docs/es-ES/build-integration.md similarity index 100% rename from website/translated_docs/es-ES/build-integration.md rename to polkadot-wiki/translated_docs/es-ES/build-integration.md diff --git a/website/translated_docs/es-ES/build-networks.md b/polkadot-wiki/translated_docs/es-ES/build-networks.md similarity index 100% rename from website/translated_docs/es-ES/build-networks.md rename to polkadot-wiki/translated_docs/es-ES/build-networks.md diff --git a/website/translated_docs/es-ES/build-node-interaction.md b/polkadot-wiki/translated_docs/es-ES/build-node-interaction.md similarity index 100% rename from website/translated_docs/es-ES/build-node-interaction.md rename to polkadot-wiki/translated_docs/es-ES/build-node-interaction.md diff --git a/website/translated_docs/es-ES/build-node-management.md b/polkadot-wiki/translated_docs/es-ES/build-node-management.md similarity index 100% rename from website/translated_docs/es-ES/build-node-management.md rename to polkadot-wiki/translated_docs/es-ES/build-node-management.md diff --git a/website/translated_docs/es-ES/build-oracle.md b/polkadot-wiki/translated_docs/es-ES/build-oracle.md similarity index 100% rename from website/translated_docs/es-ES/build-oracle.md rename to polkadot-wiki/translated_docs/es-ES/build-oracle.md diff --git a/website/translated_docs/es-ES/build-parachains-rococo.md b/polkadot-wiki/translated_docs/es-ES/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/es-ES/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/es-ES/build-parachains-rococo.md diff --git a/website/translated_docs/es-ES/build-pdk.md b/polkadot-wiki/translated_docs/es-ES/build-pdk.md similarity index 100% rename from website/translated_docs/es-ES/build-pdk.md rename to polkadot-wiki/translated_docs/es-ES/build-pdk.md diff --git a/polkadot-wiki/translated_docs/es-ES/build-protocol-info.md b/polkadot-wiki/translated_docs/es-ES/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/polkadot-wiki/translated_docs/es-ES/build-rust-style-guide.md b/polkadot-wiki/translated_docs/es-ES/build-rust-style-guide.md new file mode 100644 index 000000000000..678bb58481ae --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/build-rust-style-guide.md @@ -0,0 +1,117 @@ +--- +id: build-rust-style-guide +title: Style Guide for Rust in Polkadot +sidebar_label: Style Guide for Rust in Polkadot +--- + +- Indent using tabs +- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. +- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. +- Never have spaces on a line prior to a non-whitespace character +- Follow-on lines are only ever a single indent from the original line. + +```rust +fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { + let x = some_long_variable_a * some_long_variable_b + - some_long_variable_b / some_long_variable_a + + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); + x > 10 +} +``` + +- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: + +```rust +fn calculate( + some_long_variable_a: f32, + some_long_variable_b: f32, + some_long_variable_c: f32, +) -> f32 { + (-some_long_variable_b + sqrt( + // two parens open, but since we open & close them both on the + // same line, only one indent level is used + some_long_variable_b * some_long_variable_b + - 4 * some_long_variable_a * some_long_variable_c + // both closed here at beginning of line, so back to the original indent + // level + )) / (2 * some_long_variable_a) +} +``` + +- `where` is indented, and its items are indented one further +- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. + +```rust +// OK +fn foo( + really_long_parameter_name_1: SomeLongTypeName, + really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, + shrt_nm_2: u8, +) { + ... +} + +// NOT OK +fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, shrt_nm_2: u8) { + ... +} + +``` + +```rust +{ + // Complex line (not just a function call, also a let statement). Full + // structure. + let (a, b) = bar( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Long, simple function call. + waz( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Short function call. Inline. + baz(a, b); +} +``` + +- Always end last item of a multi-line comma-delimited set with `,` when legal: + +```rust +struct Point { + x: T, + y: T, // <-- Multiline comma-delimited lists end with a trailing , +} + +// Single line comma-delimited items do not have a trailing `,` +enum Meal { Breakfast, Lunch, Dinner }; +``` + +- Avoid trailing `;`s where unneeded. + +```rust +if condition { + return 1 // <-- no ; here +} +``` + +- `match` arms may be either blocks or have a trailing `,` but not both. +- Blocks should not be used unnecessarily. + +```rust +match meal { + Meal::Breakfast => "eggs", + Meal::Lunch => { check_diet(); recipe() }, +// Meal::Dinner => { return Err("Fasting") } // WRONG + Meal::Dinner => return Err("Fasting"), +} +``` diff --git a/website/translated_docs/es-ES/build-smart-contracts.md b/polkadot-wiki/translated_docs/es-ES/build-smart-contracts.md similarity index 100% rename from website/translated_docs/es-ES/build-smart-contracts.md rename to polkadot-wiki/translated_docs/es-ES/build-smart-contracts.md diff --git a/website/translated_docs/es-ES/build-tools-index.md b/polkadot-wiki/translated_docs/es-ES/build-tools-index.md similarity index 100% rename from website/translated_docs/es-ES/build-tools-index.md rename to polkadot-wiki/translated_docs/es-ES/build-tools-index.md diff --git a/website/translated_docs/es-ES/build-tools-subkey.md b/polkadot-wiki/translated_docs/es-ES/build-tools-subkey.md similarity index 100% rename from website/translated_docs/es-ES/build-tools-subkey.md rename to polkadot-wiki/translated_docs/es-ES/build-tools-subkey.md diff --git a/polkadot-wiki/translated_docs/es-ES/build-transaction-construction.md b/polkadot-wiki/translated_docs/es-ES/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/es-ES/build-wallets.md b/polkadot-wiki/translated_docs/es-ES/build-wallets.md similarity index 100% rename from website/translated_docs/es-ES/build-wallets.md rename to polkadot-wiki/translated_docs/es-ES/build-wallets.md diff --git a/polkadot-wiki/translated_docs/es-ES/claims.md b/polkadot-wiki/translated_docs/es-ES/claims.md new file mode 100644 index 000000000000..9cda53b70132 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +Si hiciste una compra de DOTs en una de las ventas previas al lanzamiento, entonces tendrás que solicitar tus tokens DOTs. Para aquellos que hicieron la solicitud previa al lanzamiento enviando una transacción de solicitud al Contrato de Reclamación en Ethereum, aún tendrán que enviar una transacción gratuita de _prueba_ que acepte los términos y condiciones de su asignación. Si no ha hecho una reclamación previa al génesis, entonces la reclamará y certificará en una sola transacción. + +Esta guía le ayudará en los pasos para hacer una reclamación o dar fe de la declaración. + +Si es la primera vez que reclama en Polkadot, por favor, lea más abajo en la sección de [reclamaciones](#making-a-claim). Si ya ha reclamado durante el período de reclamación previo al Génesis, por favor proceda a la sección de [certificar una declaración](#attesting-to-a-statement) en su lugar. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Hacer la reclamación + +Si no hizo la solicitud en el período de reclamación previo a la génesis, entonces puede reclamar sus tokens DOTs después del génesis. No hay límite de tiempo para hacer su reclamación, así que siéntase libre de hacerlo cuando se sienta más cómodo. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### Lo que necesitarás + +- La cuenta Ethereum que contiene los tokens del indicador DOT +- La cartera MyCrypto +- Una cuenta de Polkadot + +Ya deberías tener tu cuenta en Ethereum que tiene los tokens del indicador DOT de Polkadot de la venta anterior. Necesitarás tener acceso a esta cuenta para poder firmar. + +[MyCrypto][] es una cartera versátil que admite una variedad de métodos de almacenamiento para su cuenta de Ethereum. Vaya a su página de descargas y asegúrese de descargar la última versión para su sistema operativo. Esto es importante porque la última versión siempre tendrá los últimos parches de seguridad. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Reclamando tus DOTs con MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Ahora tendrás que proporcionar la dirección de Ethereum que está asociada con los tokens DOTs que reclamarás. Introduce la dirección de Ethereum en la casilla y haz clic en "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +A continuación, tu pantalla debe mostrar la imagen de abajo. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +El siguiente paso es ir a la aplicación MyCrypto y hacer clic en la pestaña "Sign & Verify Message". + +![claim-3](assets/new-claims/claim-3.png) + +Esto te pedirá que selecciones un método para desbloquear tu cartera. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +Cuando hagas clic en "Sign Message" obtendrás una salida JSON como la de abajo: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +Aparecerá un cuadro verde que te indicará la cantidad a reclamar con un botón "Claim" para hacer la solicitud. Haz clic en el botón "Claim" y luego en "Submit (no signature)" para completar la solicitud. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verificando tu reclamación + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +¿Tienes problemas? Consigue ayuda en el [canal de soporte de reclamaciones]() de DOT. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Procesos de reclamaciones de terceros + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Acreditar una declaración + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### Lo que necesitarás + +- Tu cuenta de Polkadot desbloqueada en la IU de Polkadot-JS Apps. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Vaya a Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Haga la declaración + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/es-ES/community.md b/polkadot-wiki/translated_docs/es-ES/community.md similarity index 100% rename from website/translated_docs/es-ES/community.md rename to polkadot-wiki/translated_docs/es-ES/community.md diff --git a/website/translated_docs/es-ES/contributing.md b/polkadot-wiki/translated_docs/es-ES/contributing.md similarity index 100% rename from website/translated_docs/es-ES/contributing.md rename to polkadot-wiki/translated_docs/es-ES/contributing.md diff --git a/website/translated_docs/es-ES/contributors.md b/polkadot-wiki/translated_docs/es-ES/contributors.md similarity index 100% rename from website/translated_docs/es-ES/contributors.md rename to polkadot-wiki/translated_docs/es-ES/contributors.md diff --git a/website/translated_docs/es-ES/ens.md b/polkadot-wiki/translated_docs/es-ES/ens.md similarity index 100% rename from website/translated_docs/es-ES/ens.md rename to polkadot-wiki/translated_docs/es-ES/ens.md diff --git a/website/translated_docs/es-ES/faq.md b/polkadot-wiki/translated_docs/es-ES/faq.md similarity index 100% rename from website/translated_docs/es-ES/faq.md rename to polkadot-wiki/translated_docs/es-ES/faq.md diff --git a/polkadot-wiki/translated_docs/es-ES/getting-started.md b/polkadot-wiki/translated_docs/es-ES/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/es-ES/glossary.md b/polkadot-wiki/translated_docs/es-ES/glossary.md similarity index 100% rename from website/translated_docs/es-ES/glossary.md rename to polkadot-wiki/translated_docs/es-ES/glossary.md diff --git a/polkadot-wiki/translated_docs/es-ES/grants.md b/polkadot-wiki/translated_docs/es-ES/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/es-ES/index.md b/polkadot-wiki/translated_docs/es-ES/index.md similarity index 100% rename from website/translated_docs/es-ES/index.md rename to polkadot-wiki/translated_docs/es-ES/index.md diff --git a/polkadot-wiki/translated_docs/es-ES/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/es-ES/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/es-ES/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/es-ES/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/es-ES/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/es-ES/kusama-bug-bounty.md diff --git a/website/translated_docs/es-ES/kusama-claims.md b/polkadot-wiki/translated_docs/es-ES/kusama-claims.md similarity index 100% rename from website/translated_docs/es-ES/kusama-claims.md rename to polkadot-wiki/translated_docs/es-ES/kusama-claims.md diff --git a/website/translated_docs/es-ES/kusama-coc.md b/polkadot-wiki/translated_docs/es-ES/kusama-coc.md similarity index 100% rename from website/translated_docs/es-ES/kusama-coc.md rename to polkadot-wiki/translated_docs/es-ES/kusama-coc.md diff --git a/website/translated_docs/es-ES/kusama-community.md b/polkadot-wiki/translated_docs/es-ES/kusama-community.md similarity index 100% rename from website/translated_docs/es-ES/kusama-community.md rename to polkadot-wiki/translated_docs/es-ES/kusama-community.md diff --git a/website/translated_docs/es-ES/kusama-endpoints.md b/polkadot-wiki/translated_docs/es-ES/kusama-endpoints.md similarity index 100% rename from website/translated_docs/es-ES/kusama-endpoints.md rename to polkadot-wiki/translated_docs/es-ES/kusama-endpoints.md diff --git a/website/translated_docs/es-ES/kusama-faucet.md b/polkadot-wiki/translated_docs/es-ES/kusama-faucet.md similarity index 100% rename from website/translated_docs/es-ES/kusama-faucet.md rename to polkadot-wiki/translated_docs/es-ES/kusama-faucet.md diff --git a/website/translated_docs/es-ES/kusama-getting-started.md b/polkadot-wiki/translated_docs/es-ES/kusama-getting-started.md similarity index 100% rename from website/translated_docs/es-ES/kusama-getting-started.md rename to polkadot-wiki/translated_docs/es-ES/kusama-getting-started.md diff --git a/website/translated_docs/es-ES/kusama-index.md b/polkadot-wiki/translated_docs/es-ES/kusama-index.md similarity index 100% rename from website/translated_docs/es-ES/kusama-index.md rename to polkadot-wiki/translated_docs/es-ES/kusama-index.md diff --git a/polkadot-wiki/translated_docs/es-ES/kusama-ledger.md b/polkadot-wiki/translated_docs/es-ES/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/es-ES/kusama-parameters.md b/polkadot-wiki/translated_docs/es-ES/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/es-ES/kusama-social-recovery.md b/polkadot-wiki/translated_docs/es-ES/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/es-ES/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/es-ES/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/es-ES/kusama-time-periods.md b/polkadot-wiki/translated_docs/es-ES/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/es-ES/kusama-timeline.md b/polkadot-wiki/translated_docs/es-ES/kusama-timeline.md similarity index 100% rename from website/translated_docs/es-ES/kusama-timeline.md rename to polkadot-wiki/translated_docs/es-ES/kusama-timeline.md diff --git a/website/translated_docs/es-ES/learn-DOT.md b/polkadot-wiki/translated_docs/es-ES/learn-DOT.md similarity index 100% rename from website/translated_docs/es-ES/learn-DOT.md rename to polkadot-wiki/translated_docs/es-ES/learn-DOT.md diff --git a/website/translated_docs/es-ES/learn-PRE.md b/polkadot-wiki/translated_docs/es-ES/learn-PRE.md similarity index 100% rename from website/translated_docs/es-ES/learn-PRE.md rename to polkadot-wiki/translated_docs/es-ES/learn-PRE.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-UI.md b/polkadot-wiki/translated_docs/es-ES/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/es-ES/learn-account-generation.md b/polkadot-wiki/translated_docs/es-ES/learn-account-generation.md similarity index 100% rename from website/translated_docs/es-ES/learn-account-generation.md rename to polkadot-wiki/translated_docs/es-ES/learn-account-generation.md diff --git a/website/translated_docs/es-ES/learn-account-restore.md b/polkadot-wiki/translated_docs/es-ES/learn-account-restore.md similarity index 100% rename from website/translated_docs/es-ES/learn-account-restore.md rename to polkadot-wiki/translated_docs/es-ES/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-accounts.md b/polkadot-wiki/translated_docs/es-ES/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/es-ES/learn-architecture.md b/polkadot-wiki/translated_docs/es-ES/learn-architecture.md similarity index 100% rename from website/translated_docs/es-ES/learn-architecture.md rename to polkadot-wiki/translated_docs/es-ES/learn-architecture.md diff --git a/website/translated_docs/es-ES/learn-auction.md b/polkadot-wiki/translated_docs/es-ES/learn-auction.md similarity index 100% rename from website/translated_docs/es-ES/learn-auction.md rename to polkadot-wiki/translated_docs/es-ES/learn-auction.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-availability.md b/polkadot-wiki/translated_docs/es-ES/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/es-ES/learn-balance-transfers.md b/polkadot-wiki/translated_docs/es-ES/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/es-ES/learn-bridges.md b/polkadot-wiki/translated_docs/es-ES/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/es-ES/learn-collator.md b/polkadot-wiki/translated_docs/es-ES/learn-collator.md similarity index 100% rename from website/translated_docs/es-ES/learn-collator.md rename to polkadot-wiki/translated_docs/es-ES/learn-collator.md diff --git a/website/translated_docs/es-ES/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/es-ES/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/es-ES/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/es-ES/learn-comparison-dfinity.md diff --git a/website/translated_docs/es-ES/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/es-ES/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/es-ES/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/es-ES/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/es-ES/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/es-ES/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/es-ES/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/es-ES/learn-comparisons-cosmos.md diff --git a/website/translated_docs/es-ES/learn-comparisons.md b/polkadot-wiki/translated_docs/es-ES/learn-comparisons.md similarity index 100% rename from website/translated_docs/es-ES/learn-comparisons.md rename to polkadot-wiki/translated_docs/es-ES/learn-comparisons.md diff --git a/website/translated_docs/es-ES/learn-consensus.md b/polkadot-wiki/translated_docs/es-ES/learn-consensus.md similarity index 100% rename from website/translated_docs/es-ES/learn-consensus.md rename to polkadot-wiki/translated_docs/es-ES/learn-consensus.md diff --git a/website/translated_docs/es-ES/learn-crosschain.md b/polkadot-wiki/translated_docs/es-ES/learn-crosschain.md similarity index 100% rename from website/translated_docs/es-ES/learn-crosschain.md rename to polkadot-wiki/translated_docs/es-ES/learn-crosschain.md diff --git a/website/translated_docs/es-ES/learn-crowdloans.md b/polkadot-wiki/translated_docs/es-ES/learn-crowdloans.md similarity index 100% rename from website/translated_docs/es-ES/learn-crowdloans.md rename to polkadot-wiki/translated_docs/es-ES/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-cryptography.md b/polkadot-wiki/translated_docs/es-ES/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/es-ES/learn-faq.md b/polkadot-wiki/translated_docs/es-ES/learn-faq.md similarity index 100% rename from website/translated_docs/es-ES/learn-faq.md rename to polkadot-wiki/translated_docs/es-ES/learn-faq.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-governance.md b/polkadot-wiki/translated_docs/es-ES/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/es-ES/learn-identity.md b/polkadot-wiki/translated_docs/es-ES/learn-identity.md similarity index 100% rename from website/translated_docs/es-ES/learn-identity.md rename to polkadot-wiki/translated_docs/es-ES/learn-identity.md diff --git a/website/translated_docs/es-ES/learn-implementations.md b/polkadot-wiki/translated_docs/es-ES/learn-implementations.md similarity index 100% rename from website/translated_docs/es-ES/learn-implementations.md rename to polkadot-wiki/translated_docs/es-ES/learn-implementations.md diff --git a/website/translated_docs/es-ES/learn-implementers-guide.md b/polkadot-wiki/translated_docs/es-ES/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/es-ES/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/es-ES/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-interchain.md b/polkadot-wiki/translated_docs/es-ES/learn-interchain.md new file mode 100644 index 000000000000..2677ee91d812 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. + +The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. + +## Overview + +- Interchain messages will _not_ go on to the relay chain. +- Interchain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. + +## Example + +A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. + +When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/es-ES/learn-introduction.md b/polkadot-wiki/translated_docs/es-ES/learn-introduction.md similarity index 100% rename from website/translated_docs/es-ES/learn-introduction.md rename to polkadot-wiki/translated_docs/es-ES/learn-introduction.md diff --git a/website/translated_docs/es-ES/learn-keys.md b/polkadot-wiki/translated_docs/es-ES/learn-keys.md similarity index 100% rename from website/translated_docs/es-ES/learn-keys.md rename to polkadot-wiki/translated_docs/es-ES/learn-keys.md diff --git a/website/translated_docs/es-ES/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/es-ES/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/es-ES/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/es-ES/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/es-ES/learn-launch.md b/polkadot-wiki/translated_docs/es-ES/learn-launch.md similarity index 100% rename from website/translated_docs/es-ES/learn-launch.md rename to polkadot-wiki/translated_docs/es-ES/learn-launch.md diff --git a/website/translated_docs/es-ES/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/es-ES/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/es-ES/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/es-ES/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-ledger.md b/polkadot-wiki/translated_docs/es-ES/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/es-ES/learn-nominator.md b/polkadot-wiki/translated_docs/es-ES/learn-nominator.md similarity index 100% rename from website/translated_docs/es-ES/learn-nominator.md rename to polkadot-wiki/translated_docs/es-ES/learn-nominator.md diff --git a/website/translated_docs/es-ES/learn-parachains.md b/polkadot-wiki/translated_docs/es-ES/learn-parachains.md similarity index 100% rename from website/translated_docs/es-ES/learn-parachains.md rename to polkadot-wiki/translated_docs/es-ES/learn-parachains.md diff --git a/website/translated_docs/es-ES/learn-parathreads.md b/polkadot-wiki/translated_docs/es-ES/learn-parathreads.md similarity index 100% rename from website/translated_docs/es-ES/learn-parathreads.md rename to polkadot-wiki/translated_docs/es-ES/learn-parathreads.md diff --git a/website/translated_docs/es-ES/learn-phragmen.md b/polkadot-wiki/translated_docs/es-ES/learn-phragmen.md similarity index 100% rename from website/translated_docs/es-ES/learn-phragmen.md rename to polkadot-wiki/translated_docs/es-ES/learn-phragmen.md diff --git a/website/translated_docs/es-ES/learn-polkadot-host.md b/polkadot-wiki/translated_docs/es-ES/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/es-ES/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/es-ES/learn-polkadot-host.md diff --git a/website/translated_docs/es-ES/learn-proxies.md b/polkadot-wiki/translated_docs/es-ES/learn-proxies.md similarity index 100% rename from website/translated_docs/es-ES/learn-proxies.md rename to polkadot-wiki/translated_docs/es-ES/learn-proxies.md diff --git a/website/translated_docs/es-ES/learn-randomness.md b/polkadot-wiki/translated_docs/es-ES/learn-randomness.md similarity index 100% rename from website/translated_docs/es-ES/learn-randomness.md rename to polkadot-wiki/translated_docs/es-ES/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-registrar.md b/polkadot-wiki/translated_docs/es-ES/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/es-ES/learn-relevant-links.md b/polkadot-wiki/translated_docs/es-ES/learn-relevant-links.md similarity index 100% rename from website/translated_docs/es-ES/learn-relevant-links.md rename to polkadot-wiki/translated_docs/es-ES/learn-relevant-links.md diff --git a/website/translated_docs/es-ES/learn-roadmap.md b/polkadot-wiki/translated_docs/es-ES/learn-roadmap.md similarity index 100% rename from website/translated_docs/es-ES/learn-roadmap.md rename to polkadot-wiki/translated_docs/es-ES/learn-roadmap.md diff --git a/website/translated_docs/es-ES/learn-scams.md b/polkadot-wiki/translated_docs/es-ES/learn-scams.md similarity index 100% rename from website/translated_docs/es-ES/learn-scams.md rename to polkadot-wiki/translated_docs/es-ES/learn-scams.md diff --git a/website/translated_docs/es-ES/learn-security.md b/polkadot-wiki/translated_docs/es-ES/learn-security.md similarity index 100% rename from website/translated_docs/es-ES/learn-security.md rename to polkadot-wiki/translated_docs/es-ES/learn-security.md diff --git a/website/translated_docs/es-ES/learn-simple-payouts.md b/polkadot-wiki/translated_docs/es-ES/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/es-ES/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/es-ES/learn-simple-payouts.md diff --git a/website/translated_docs/es-ES/learn-spree.md b/polkadot-wiki/translated_docs/es-ES/learn-spree.md similarity index 100% rename from website/translated_docs/es-ES/learn-spree.md rename to polkadot-wiki/translated_docs/es-ES/learn-spree.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-staking.md b/polkadot-wiki/translated_docs/es-ES/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/es-ES/learn-transaction-fees.md b/polkadot-wiki/translated_docs/es-ES/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/es-ES/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/es-ES/learn-transaction-fees.md diff --git a/website/translated_docs/es-ES/learn-transactions.md b/polkadot-wiki/translated_docs/es-ES/learn-transactions.md similarity index 100% rename from website/translated_docs/es-ES/learn-transactions.md rename to polkadot-wiki/translated_docs/es-ES/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/es-ES/learn-treasury.md b/polkadot-wiki/translated_docs/es-ES/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/es-ES/learn-validator.md b/polkadot-wiki/translated_docs/es-ES/learn-validator.md similarity index 100% rename from website/translated_docs/es-ES/learn-validator.md rename to polkadot-wiki/translated_docs/es-ES/learn-validator.md diff --git a/website/translated_docs/es-ES/learn-wasm.md b/polkadot-wiki/translated_docs/es-ES/learn-wasm.md similarity index 100% rename from website/translated_docs/es-ES/learn-wasm.md rename to polkadot-wiki/translated_docs/es-ES/learn-wasm.md diff --git a/website/translated_docs/es-ES/maintain-collator.md b/polkadot-wiki/translated_docs/es-ES/maintain-collator.md similarity index 100% rename from website/translated_docs/es-ES/maintain-collator.md rename to polkadot-wiki/translated_docs/es-ES/maintain-collator.md diff --git a/website/translated_docs/es-ES/maintain-errors.md b/polkadot-wiki/translated_docs/es-ES/maintain-errors.md similarity index 100% rename from website/translated_docs/es-ES/maintain-errors.md rename to polkadot-wiki/translated_docs/es-ES/maintain-errors.md diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-governance-index.md b/polkadot-wiki/translated_docs/es-ES/maintain-governance-index.md new file mode 100644 index 000000000000..8812e030de6c --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-governance-index.md @@ -0,0 +1,185 @@ +--- +id: maintain-governance-index +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. + +All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. + +The following steps are the governance procedure in the Polkadot network: + +- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) +- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) +- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) + +To better understand how the council is formed, please read [this section](#council). + +### Proposing Referenda + +- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. + +- **[Council](#council)**: + + Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. + + Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) + +### Voting for a proposal + +To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). + +``` +Example: + +Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes +``` + +According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. + +### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +voters - the total number of voting tokens + +electorate - the total number of DOTs tokens issued in the network +``` + +**Super-Majority Approve** + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ + +**Super-Majority Against** + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ + +**Simple-Majority** + +Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ + +_To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume we only have 1,500 DOTs tokens in total. + +John - 500 DOTs +Peter - 100 DOTs +Lilly - 150 DOTs +JJ - 150 DOTs +Ken - 600 DOTs + +John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +voters = 1050 +electorate = 1500 +``` + +$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ + +$${13.887} < {15.492}$$ + +Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. + +## Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: + +``` +Max votes = tokens * periods +``` + +Based on the current testnet setting, the maximum number of lock periods is set to 6. + +**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** + +## Adaptive Quorum Biasing + +Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. + +Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. + +Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. + +In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +## Council + +Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. + +To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. + +Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. + +Let's take a look at the example below. + +||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. + +### Resources + +- [Governance Description](learn-governance#referenda) +- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) + +## [Usage of DOT](learn-DOT#dots-for-governance) + +## Guides + +### [How to create a proposal]() + +### [How to join the council]() + +### [How to propose a referenda]() diff --git a/website/translated_docs/es-ES/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-democracy.md diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate-polkadot.md diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate.md new file mode 100644 index 000000000000..20b9f634ea64 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-nominate.md @@ -0,0 +1,59 @@ +--- +id: maintain-guides-how-to-nominate +title: How to nominate +sidebar_label: How to nominate +--- + +This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. + +It has been updated for the Alexander testnet and Polkadot release PoC-4. + +## Create `stash` and `controller` accounts + +We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. + +The first step is to create two accounts by going to the _Accounts_ tab on the Polkadot Dashboard and clicking on [_Add account_](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. + +![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) + +Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. + +## Nominating + +It is now time to setup our nominator. We will do the following: + +- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. +- Select the `controller`. This is the account that will decide when to start or stop nominating. + +First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. + +![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. +- **Controller account** - select the `controller` account created earlier. +- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). +- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). + +Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. + +![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) + +## Nominating a validator + +Go to the _Staking Overview_ tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. + +![Validators](assets/guides/how-to-nominate/validators.png) + +Go back to the _Account Actions_ tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). + +![Nominating](assets/guides/how-to-nominate/nominating.jpg) + +**Congratulations!** You are now a nominator. + +If you return to the _Staking Overview_ tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. + +![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) + +## How to stop nominating + +To stop nominating simply return to the _Account Actions_ tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/es-ES/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/es-ES/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/es-ES/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/es-ES/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/es-ES/maintain-guides-validator-payout.md diff --git a/website/translated_docs/de/maintain-index.md b/polkadot-wiki/translated_docs/es-ES/maintain-index.md similarity index 100% rename from website/translated_docs/de/maintain-index.md rename to polkadot-wiki/translated_docs/es-ES/maintain-index.md diff --git a/website/translated_docs/es-ES/maintain-networks.md b/polkadot-wiki/translated_docs/es-ES/maintain-networks.md similarity index 100% rename from website/translated_docs/es-ES/maintain-networks.md rename to polkadot-wiki/translated_docs/es-ES/maintain-networks.md diff --git a/website/translated_docs/es-ES/maintain-node-operator.md b/polkadot-wiki/translated_docs/es-ES/maintain-node-operator.md similarity index 100% rename from website/translated_docs/es-ES/maintain-node-operator.md rename to polkadot-wiki/translated_docs/es-ES/maintain-node-operator.md diff --git a/website/translated_docs/es-ES/maintain-nominator.md b/polkadot-wiki/translated_docs/es-ES/maintain-nominator.md similarity index 100% rename from website/translated_docs/es-ES/maintain-nominator.md rename to polkadot-wiki/translated_docs/es-ES/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/es-ES/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/es-ES/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/es-ES/maintain-sync.md b/polkadot-wiki/translated_docs/es-ES/maintain-sync.md similarity index 100% rename from website/translated_docs/es-ES/maintain-sync.md rename to polkadot-wiki/translated_docs/es-ES/maintain-sync.md diff --git a/website/translated_docs/es-ES/maintain-validator.md b/polkadot-wiki/translated_docs/es-ES/maintain-validator.md similarity index 100% rename from website/translated_docs/es-ES/maintain-validator.md rename to polkadot-wiki/translated_docs/es-ES/maintain-validator.md diff --git a/website/translated_docs/es-ES/maintain-wss.md b/polkadot-wiki/translated_docs/es-ES/maintain-wss.md similarity index 100% rename from website/translated_docs/es-ES/maintain-wss.md rename to polkadot-wiki/translated_docs/es-ES/maintain-wss.md diff --git a/website/translated_docs/es-ES/news.md b/polkadot-wiki/translated_docs/es-ES/news.md similarity index 100% rename from website/translated_docs/es-ES/news.md rename to polkadot-wiki/translated_docs/es-ES/news.md diff --git a/polkadot-wiki/translated_docs/es-ES/redenomination.md b/polkadot-wiki/translated_docs/es-ES/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/es-ES/research.md b/polkadot-wiki/translated_docs/es-ES/research.md similarity index 100% rename from website/translated_docs/es-ES/research.md rename to polkadot-wiki/translated_docs/es-ES/research.md diff --git a/polkadot-wiki/translated_docs/es-ES/thousand-validators.md b/polkadot-wiki/translated_docs/es-ES/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/es-ES/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/fi/ambassadors.md b/polkadot-wiki/translated_docs/fi/ambassadors.md similarity index 100% rename from website/translated_docs/fi/ambassadors.md rename to polkadot-wiki/translated_docs/fi/ambassadors.md diff --git a/website/translated_docs/fi/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/fi/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/fi/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/fi/build-build-with-polkadot.md diff --git a/website/translated_docs/fi/build-cumulus.md b/polkadot-wiki/translated_docs/fi/build-cumulus.md similarity index 100% rename from website/translated_docs/fi/build-cumulus.md rename to polkadot-wiki/translated_docs/fi/build-cumulus.md diff --git a/website/translated_docs/fi/build-deploy-parachains.md b/polkadot-wiki/translated_docs/fi/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/fi/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/fi/build-deploy-parachains.md diff --git a/website/translated_docs/fi/build-dev-roadmap.md b/polkadot-wiki/translated_docs/fi/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/fi/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/fi/build-dev-roadmap.md diff --git a/website/translated_docs/fi/build-examples-index.md b/polkadot-wiki/translated_docs/fi/build-examples-index.md similarity index 100% rename from website/translated_docs/fi/build-examples-index.md rename to polkadot-wiki/translated_docs/fi/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/fi/build-exchange-integration.md b/polkadot-wiki/translated_docs/fi/build-exchange-integration.md new file mode 100644 index 000000000000..dddd3a779fac --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. Tracking the chain head + +Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). + +That will give you a stream of hashes of the most recent finalised headers. + +When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. + +If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. + +## 2. Decoding blocks + +You will need to decode blocks from the basic data into useful fields. + +All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. + +For Genesis Polkadot, the header format is a five-field structure: + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +It also relies on `Extrinsic`. An _extrinsic_ is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. + +The metadata itself is provided encoded in SCALE. Its format is: + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. + +Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various _modules_. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, _extrinsics_), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. Working with SS58 and account addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) _AccountId_. This is simply the public key for the x25519 cryptography used by Substrate. + +However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this _index_ to identify the account. This index is much smaller than the 32-byte _AccountId_, and can usually be encoded in just a couple of bytes. + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: + +`0x00 ` + +**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. + +Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. + +Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. + +### Looking up an index + +Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. + +The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. + +For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. + +This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. + +This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. + +Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. + +## 4. Working with balances + +In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. + +NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. + +The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10\*\*12). For completeness, The exact denominations of the Polkadot currency are: + +| Balance value | Name | +| ------------- | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### Transferring balances + +To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. + +In general, Polkadot's transactions are encoded as _signed_ `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. + +The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. + +NOTE: The nonce retrieved from storage does not take into account _pending_ transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. + +The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. + +The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. + +Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. + +Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +The `function` _in this case_ (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. + +The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. + +### Submitting and checking transactions + +Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. + +This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. + +The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. + +## Conclusion + +This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. + +If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). + +_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/fi/build-hackathon.md b/polkadot-wiki/translated_docs/fi/build-hackathon.md similarity index 100% rename from website/translated_docs/fi/build-hackathon.md rename to polkadot-wiki/translated_docs/fi/build-hackathon.md diff --git a/website/translated_docs/fi/build-index.md b/polkadot-wiki/translated_docs/fi/build-index.md similarity index 100% rename from website/translated_docs/fi/build-index.md rename to polkadot-wiki/translated_docs/fi/build-index.md diff --git a/website/translated_docs/fi/build-integration.md b/polkadot-wiki/translated_docs/fi/build-integration.md similarity index 100% rename from website/translated_docs/fi/build-integration.md rename to polkadot-wiki/translated_docs/fi/build-integration.md diff --git a/website/translated_docs/fi/build-node-interaction.md b/polkadot-wiki/translated_docs/fi/build-node-interaction.md similarity index 100% rename from website/translated_docs/fi/build-node-interaction.md rename to polkadot-wiki/translated_docs/fi/build-node-interaction.md diff --git a/website/translated_docs/fi/build-node-management.md b/polkadot-wiki/translated_docs/fi/build-node-management.md similarity index 100% rename from website/translated_docs/fi/build-node-management.md rename to polkadot-wiki/translated_docs/fi/build-node-management.md diff --git a/website/translated_docs/fi/build-oracle.md b/polkadot-wiki/translated_docs/fi/build-oracle.md similarity index 100% rename from website/translated_docs/fi/build-oracle.md rename to polkadot-wiki/translated_docs/fi/build-oracle.md diff --git a/website/translated_docs/fi/build-parachains-rococo.md b/polkadot-wiki/translated_docs/fi/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/fi/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/fi/build-parachains-rococo.md diff --git a/website/translated_docs/fi/build-pdk.md b/polkadot-wiki/translated_docs/fi/build-pdk.md similarity index 100% rename from website/translated_docs/fi/build-pdk.md rename to polkadot-wiki/translated_docs/fi/build-pdk.md diff --git a/polkadot-wiki/translated_docs/fi/build-protocol-info.md b/polkadot-wiki/translated_docs/fi/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/fi/build-smart-contracts.md b/polkadot-wiki/translated_docs/fi/build-smart-contracts.md similarity index 100% rename from website/translated_docs/fi/build-smart-contracts.md rename to polkadot-wiki/translated_docs/fi/build-smart-contracts.md diff --git a/website/translated_docs/fi/build-tools-index.md b/polkadot-wiki/translated_docs/fi/build-tools-index.md similarity index 100% rename from website/translated_docs/fi/build-tools-index.md rename to polkadot-wiki/translated_docs/fi/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/fi/build-transaction-construction.md b/polkadot-wiki/translated_docs/fi/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/fi/build-wallets.md b/polkadot-wiki/translated_docs/fi/build-wallets.md similarity index 100% rename from website/translated_docs/fi/build-wallets.md rename to polkadot-wiki/translated_docs/fi/build-wallets.md diff --git a/polkadot-wiki/translated_docs/fi/claims.md b/polkadot-wiki/translated_docs/fi/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/fi/community.md b/polkadot-wiki/translated_docs/fi/community.md similarity index 100% rename from website/translated_docs/fi/community.md rename to polkadot-wiki/translated_docs/fi/community.md diff --git a/website/translated_docs/fi/contributing.md b/polkadot-wiki/translated_docs/fi/contributing.md similarity index 100% rename from website/translated_docs/fi/contributing.md rename to polkadot-wiki/translated_docs/fi/contributing.md diff --git a/website/translated_docs/fi/contributors.md b/polkadot-wiki/translated_docs/fi/contributors.md similarity index 100% rename from website/translated_docs/fi/contributors.md rename to polkadot-wiki/translated_docs/fi/contributors.md diff --git a/website/translated_docs/fi/ens.md b/polkadot-wiki/translated_docs/fi/ens.md similarity index 100% rename from website/translated_docs/fi/ens.md rename to polkadot-wiki/translated_docs/fi/ens.md diff --git a/website/translated_docs/fi/faq.md b/polkadot-wiki/translated_docs/fi/faq.md similarity index 100% rename from website/translated_docs/fi/faq.md rename to polkadot-wiki/translated_docs/fi/faq.md diff --git a/polkadot-wiki/translated_docs/fi/getting-started.md b/polkadot-wiki/translated_docs/fi/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/fi/glossary.md b/polkadot-wiki/translated_docs/fi/glossary.md similarity index 100% rename from website/translated_docs/fi/glossary.md rename to polkadot-wiki/translated_docs/fi/glossary.md diff --git a/polkadot-wiki/translated_docs/fi/grants.md b/polkadot-wiki/translated_docs/fi/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/fi/index.md b/polkadot-wiki/translated_docs/fi/index.md similarity index 100% rename from website/translated_docs/fi/index.md rename to polkadot-wiki/translated_docs/fi/index.md diff --git a/polkadot-wiki/translated_docs/fi/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/fi/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/fi/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/fi/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/fi/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/fi/kusama-bug-bounty.md diff --git a/website/translated_docs/fi/kusama-claims.md b/polkadot-wiki/translated_docs/fi/kusama-claims.md similarity index 100% rename from website/translated_docs/fi/kusama-claims.md rename to polkadot-wiki/translated_docs/fi/kusama-claims.md diff --git a/website/translated_docs/fi/kusama-coc.md b/polkadot-wiki/translated_docs/fi/kusama-coc.md similarity index 100% rename from website/translated_docs/fi/kusama-coc.md rename to polkadot-wiki/translated_docs/fi/kusama-coc.md diff --git a/website/translated_docs/fi/kusama-community.md b/polkadot-wiki/translated_docs/fi/kusama-community.md similarity index 100% rename from website/translated_docs/fi/kusama-community.md rename to polkadot-wiki/translated_docs/fi/kusama-community.md diff --git a/website/translated_docs/fi/kusama-endpoints.md b/polkadot-wiki/translated_docs/fi/kusama-endpoints.md similarity index 100% rename from website/translated_docs/fi/kusama-endpoints.md rename to polkadot-wiki/translated_docs/fi/kusama-endpoints.md diff --git a/website/translated_docs/fi/kusama-faucet.md b/polkadot-wiki/translated_docs/fi/kusama-faucet.md similarity index 100% rename from website/translated_docs/fi/kusama-faucet.md rename to polkadot-wiki/translated_docs/fi/kusama-faucet.md diff --git a/website/translated_docs/fi/kusama-getting-started.md b/polkadot-wiki/translated_docs/fi/kusama-getting-started.md similarity index 100% rename from website/translated_docs/fi/kusama-getting-started.md rename to polkadot-wiki/translated_docs/fi/kusama-getting-started.md diff --git a/website/translated_docs/fi/kusama-index.md b/polkadot-wiki/translated_docs/fi/kusama-index.md similarity index 100% rename from website/translated_docs/fi/kusama-index.md rename to polkadot-wiki/translated_docs/fi/kusama-index.md diff --git a/polkadot-wiki/translated_docs/fi/kusama-ledger.md b/polkadot-wiki/translated_docs/fi/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/fi/kusama-parameters.md b/polkadot-wiki/translated_docs/fi/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/fi/kusama-social-recovery.md b/polkadot-wiki/translated_docs/fi/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/fi/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/fi/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/fi/kusama-time-periods.md b/polkadot-wiki/translated_docs/fi/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/fi/kusama-timeline.md b/polkadot-wiki/translated_docs/fi/kusama-timeline.md similarity index 100% rename from website/translated_docs/fi/kusama-timeline.md rename to polkadot-wiki/translated_docs/fi/kusama-timeline.md diff --git a/website/translated_docs/fi/learn-DOT.md b/polkadot-wiki/translated_docs/fi/learn-DOT.md similarity index 100% rename from website/translated_docs/fi/learn-DOT.md rename to polkadot-wiki/translated_docs/fi/learn-DOT.md diff --git a/website/translated_docs/fi/learn-PRE.md b/polkadot-wiki/translated_docs/fi/learn-PRE.md similarity index 100% rename from website/translated_docs/fi/learn-PRE.md rename to polkadot-wiki/translated_docs/fi/learn-PRE.md diff --git a/polkadot-wiki/translated_docs/fi/learn-UI.md b/polkadot-wiki/translated_docs/fi/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/fi/learn-account-generation.md b/polkadot-wiki/translated_docs/fi/learn-account-generation.md similarity index 100% rename from website/translated_docs/fi/learn-account-generation.md rename to polkadot-wiki/translated_docs/fi/learn-account-generation.md diff --git a/website/translated_docs/fi/learn-account-restore.md b/polkadot-wiki/translated_docs/fi/learn-account-restore.md similarity index 100% rename from website/translated_docs/fi/learn-account-restore.md rename to polkadot-wiki/translated_docs/fi/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/fi/learn-accounts.md b/polkadot-wiki/translated_docs/fi/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/fi/learn-architecture.md b/polkadot-wiki/translated_docs/fi/learn-architecture.md similarity index 100% rename from website/translated_docs/fi/learn-architecture.md rename to polkadot-wiki/translated_docs/fi/learn-architecture.md diff --git a/website/translated_docs/fi/learn-auction.md b/polkadot-wiki/translated_docs/fi/learn-auction.md similarity index 100% rename from website/translated_docs/fi/learn-auction.md rename to polkadot-wiki/translated_docs/fi/learn-auction.md diff --git a/polkadot-wiki/translated_docs/fi/learn-availability.md b/polkadot-wiki/translated_docs/fi/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/fi/learn-balance-transfers.md b/polkadot-wiki/translated_docs/fi/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/fi/learn-bridges.md b/polkadot-wiki/translated_docs/fi/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/fi/learn-collator.md b/polkadot-wiki/translated_docs/fi/learn-collator.md similarity index 100% rename from website/translated_docs/fi/learn-collator.md rename to polkadot-wiki/translated_docs/fi/learn-collator.md diff --git a/website/translated_docs/fi/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/fi/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/fi/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/fi/learn-comparison-dfinity.md diff --git a/website/translated_docs/fi/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/fi/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/fi/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/fi/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/fi/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/fi/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/fi/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/fi/learn-comparisons-cosmos.md diff --git a/website/translated_docs/fi/learn-comparisons.md b/polkadot-wiki/translated_docs/fi/learn-comparisons.md similarity index 100% rename from website/translated_docs/fi/learn-comparisons.md rename to polkadot-wiki/translated_docs/fi/learn-comparisons.md diff --git a/website/translated_docs/fi/learn-consensus.md b/polkadot-wiki/translated_docs/fi/learn-consensus.md similarity index 100% rename from website/translated_docs/fi/learn-consensus.md rename to polkadot-wiki/translated_docs/fi/learn-consensus.md diff --git a/website/translated_docs/fi/learn-crosschain.md b/polkadot-wiki/translated_docs/fi/learn-crosschain.md similarity index 100% rename from website/translated_docs/fi/learn-crosschain.md rename to polkadot-wiki/translated_docs/fi/learn-crosschain.md diff --git a/website/translated_docs/fi/learn-crowdloans.md b/polkadot-wiki/translated_docs/fi/learn-crowdloans.md similarity index 100% rename from website/translated_docs/fi/learn-crowdloans.md rename to polkadot-wiki/translated_docs/fi/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/fi/learn-cryptography.md b/polkadot-wiki/translated_docs/fi/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/fi/learn-faq.md b/polkadot-wiki/translated_docs/fi/learn-faq.md similarity index 100% rename from website/translated_docs/fi/learn-faq.md rename to polkadot-wiki/translated_docs/fi/learn-faq.md diff --git a/polkadot-wiki/translated_docs/fi/learn-governance.md b/polkadot-wiki/translated_docs/fi/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/fi/learn-identity.md b/polkadot-wiki/translated_docs/fi/learn-identity.md similarity index 100% rename from website/translated_docs/fi/learn-identity.md rename to polkadot-wiki/translated_docs/fi/learn-identity.md diff --git a/website/translated_docs/fi/learn-implementations.md b/polkadot-wiki/translated_docs/fi/learn-implementations.md similarity index 100% rename from website/translated_docs/fi/learn-implementations.md rename to polkadot-wiki/translated_docs/fi/learn-implementations.md diff --git a/website/translated_docs/fi/learn-implementers-guide.md b/polkadot-wiki/translated_docs/fi/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/fi/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/fi/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/fi/learn-interchain.md b/polkadot-wiki/translated_docs/fi/learn-interchain.md new file mode 100644 index 000000000000..2677ee91d812 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. + +The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. + +## Overview + +- Interchain messages will _not_ go on to the relay chain. +- Interchain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. + +## Example + +A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. + +When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/fi/learn-introduction.md b/polkadot-wiki/translated_docs/fi/learn-introduction.md similarity index 100% rename from website/translated_docs/fi/learn-introduction.md rename to polkadot-wiki/translated_docs/fi/learn-introduction.md diff --git a/website/translated_docs/fi/learn-keys.md b/polkadot-wiki/translated_docs/fi/learn-keys.md similarity index 100% rename from website/translated_docs/fi/learn-keys.md rename to polkadot-wiki/translated_docs/fi/learn-keys.md diff --git a/website/translated_docs/fi/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/fi/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/fi/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/fi/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/fi/learn-launch.md b/polkadot-wiki/translated_docs/fi/learn-launch.md similarity index 100% rename from website/translated_docs/fi/learn-launch.md rename to polkadot-wiki/translated_docs/fi/learn-launch.md diff --git a/website/translated_docs/fi/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/fi/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/fi/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/fi/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/fi/learn-ledger.md b/polkadot-wiki/translated_docs/fi/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/fi/learn-nominator.md b/polkadot-wiki/translated_docs/fi/learn-nominator.md similarity index 100% rename from website/translated_docs/fi/learn-nominator.md rename to polkadot-wiki/translated_docs/fi/learn-nominator.md diff --git a/website/translated_docs/fi/learn-parachains.md b/polkadot-wiki/translated_docs/fi/learn-parachains.md similarity index 100% rename from website/translated_docs/fi/learn-parachains.md rename to polkadot-wiki/translated_docs/fi/learn-parachains.md diff --git a/website/translated_docs/fi/learn-parathreads.md b/polkadot-wiki/translated_docs/fi/learn-parathreads.md similarity index 100% rename from website/translated_docs/fi/learn-parathreads.md rename to polkadot-wiki/translated_docs/fi/learn-parathreads.md diff --git a/website/translated_docs/fi/learn-phragmen.md b/polkadot-wiki/translated_docs/fi/learn-phragmen.md similarity index 100% rename from website/translated_docs/fi/learn-phragmen.md rename to polkadot-wiki/translated_docs/fi/learn-phragmen.md diff --git a/website/translated_docs/fi/learn-polkadot-host.md b/polkadot-wiki/translated_docs/fi/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/fi/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/fi/learn-polkadot-host.md diff --git a/website/translated_docs/fi/learn-proxies.md b/polkadot-wiki/translated_docs/fi/learn-proxies.md similarity index 100% rename from website/translated_docs/fi/learn-proxies.md rename to polkadot-wiki/translated_docs/fi/learn-proxies.md diff --git a/website/translated_docs/fi/learn-randomness.md b/polkadot-wiki/translated_docs/fi/learn-randomness.md similarity index 100% rename from website/translated_docs/fi/learn-randomness.md rename to polkadot-wiki/translated_docs/fi/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/fi/learn-registrar.md b/polkadot-wiki/translated_docs/fi/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/fi/learn-relevant-links.md b/polkadot-wiki/translated_docs/fi/learn-relevant-links.md similarity index 100% rename from website/translated_docs/fi/learn-relevant-links.md rename to polkadot-wiki/translated_docs/fi/learn-relevant-links.md diff --git a/website/translated_docs/fi/learn-roadmap.md b/polkadot-wiki/translated_docs/fi/learn-roadmap.md similarity index 100% rename from website/translated_docs/fi/learn-roadmap.md rename to polkadot-wiki/translated_docs/fi/learn-roadmap.md diff --git a/website/translated_docs/fi/learn-scams.md b/polkadot-wiki/translated_docs/fi/learn-scams.md similarity index 100% rename from website/translated_docs/fi/learn-scams.md rename to polkadot-wiki/translated_docs/fi/learn-scams.md diff --git a/website/translated_docs/fi/learn-security.md b/polkadot-wiki/translated_docs/fi/learn-security.md similarity index 100% rename from website/translated_docs/fi/learn-security.md rename to polkadot-wiki/translated_docs/fi/learn-security.md diff --git a/website/translated_docs/fi/learn-simple-payouts.md b/polkadot-wiki/translated_docs/fi/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/fi/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/fi/learn-simple-payouts.md diff --git a/website/translated_docs/fi/learn-spree.md b/polkadot-wiki/translated_docs/fi/learn-spree.md similarity index 100% rename from website/translated_docs/fi/learn-spree.md rename to polkadot-wiki/translated_docs/fi/learn-spree.md diff --git a/polkadot-wiki/translated_docs/fi/learn-staking.md b/polkadot-wiki/translated_docs/fi/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/fi/learn-transaction-fees.md b/polkadot-wiki/translated_docs/fi/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/fi/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/fi/learn-transaction-fees.md diff --git a/website/translated_docs/fi/learn-transactions.md b/polkadot-wiki/translated_docs/fi/learn-transactions.md similarity index 100% rename from website/translated_docs/fi/learn-transactions.md rename to polkadot-wiki/translated_docs/fi/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/fi/learn-treasury.md b/polkadot-wiki/translated_docs/fi/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/fi/learn-validator.md b/polkadot-wiki/translated_docs/fi/learn-validator.md similarity index 100% rename from website/translated_docs/fi/learn-validator.md rename to polkadot-wiki/translated_docs/fi/learn-validator.md diff --git a/website/translated_docs/fi/learn-wasm.md b/polkadot-wiki/translated_docs/fi/learn-wasm.md similarity index 100% rename from website/translated_docs/fi/learn-wasm.md rename to polkadot-wiki/translated_docs/fi/learn-wasm.md diff --git a/website/translated_docs/fi/maintain-collator.md b/polkadot-wiki/translated_docs/fi/maintain-collator.md similarity index 100% rename from website/translated_docs/fi/maintain-collator.md rename to polkadot-wiki/translated_docs/fi/maintain-collator.md diff --git a/website/translated_docs/fi/maintain-errors.md b/polkadot-wiki/translated_docs/fi/maintain-errors.md similarity index 100% rename from website/translated_docs/fi/maintain-errors.md rename to polkadot-wiki/translated_docs/fi/maintain-errors.md diff --git a/website/translated_docs/fi/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/fi/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-democracy.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/fi/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/fi/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/fi/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/fi/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/fi/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/fi/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/fi/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/fi/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/fi/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/fi/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/fi/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/fi/maintain-guides-validator-payout.md diff --git a/website/translated_docs/es-ES/maintain-index.md b/polkadot-wiki/translated_docs/fi/maintain-index.md similarity index 100% rename from website/translated_docs/es-ES/maintain-index.md rename to polkadot-wiki/translated_docs/fi/maintain-index.md diff --git a/website/translated_docs/fi/maintain-networks.md b/polkadot-wiki/translated_docs/fi/maintain-networks.md similarity index 100% rename from website/translated_docs/fi/maintain-networks.md rename to polkadot-wiki/translated_docs/fi/maintain-networks.md diff --git a/website/translated_docs/fi/maintain-nominator.md b/polkadot-wiki/translated_docs/fi/maintain-nominator.md similarity index 100% rename from website/translated_docs/fi/maintain-nominator.md rename to polkadot-wiki/translated_docs/fi/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/fi/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/fi/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/fi/maintain-sync.md b/polkadot-wiki/translated_docs/fi/maintain-sync.md similarity index 100% rename from website/translated_docs/fi/maintain-sync.md rename to polkadot-wiki/translated_docs/fi/maintain-sync.md diff --git a/website/translated_docs/fi/maintain-validator.md b/polkadot-wiki/translated_docs/fi/maintain-validator.md similarity index 100% rename from website/translated_docs/fi/maintain-validator.md rename to polkadot-wiki/translated_docs/fi/maintain-validator.md diff --git a/website/translated_docs/fi/maintain-wss.md b/polkadot-wiki/translated_docs/fi/maintain-wss.md similarity index 100% rename from website/translated_docs/fi/maintain-wss.md rename to polkadot-wiki/translated_docs/fi/maintain-wss.md diff --git a/website/translated_docs/fi/news.md b/polkadot-wiki/translated_docs/fi/news.md similarity index 100% rename from website/translated_docs/fi/news.md rename to polkadot-wiki/translated_docs/fi/news.md diff --git a/polkadot-wiki/translated_docs/fi/redenomination.md b/polkadot-wiki/translated_docs/fi/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/fi/research.md b/polkadot-wiki/translated_docs/fi/research.md similarity index 100% rename from website/translated_docs/fi/research.md rename to polkadot-wiki/translated_docs/fi/research.md diff --git a/polkadot-wiki/translated_docs/fi/thousand-validators.md b/polkadot-wiki/translated_docs/fi/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/fi/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/fil-PH/ambassadors.md b/polkadot-wiki/translated_docs/fil-PH/ambassadors.md similarity index 100% rename from website/translated_docs/fil-PH/ambassadors.md rename to polkadot-wiki/translated_docs/fil-PH/ambassadors.md diff --git a/website/translated_docs/fil-PH/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/fil-PH/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/fil-PH/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/fil-PH/build-build-with-polkadot.md diff --git a/website/translated_docs/fil-PH/build-cumulus.md b/polkadot-wiki/translated_docs/fil-PH/build-cumulus.md similarity index 100% rename from website/translated_docs/fil-PH/build-cumulus.md rename to polkadot-wiki/translated_docs/fil-PH/build-cumulus.md diff --git a/website/translated_docs/fil-PH/build-hackathon.md b/polkadot-wiki/translated_docs/fil-PH/build-hackathon.md similarity index 100% rename from website/translated_docs/fil-PH/build-hackathon.md rename to polkadot-wiki/translated_docs/fil-PH/build-hackathon.md diff --git a/website/translated_docs/fil-PH/build-index.md b/polkadot-wiki/translated_docs/fil-PH/build-index.md similarity index 100% rename from website/translated_docs/fil-PH/build-index.md rename to polkadot-wiki/translated_docs/fil-PH/build-index.md diff --git a/website/translated_docs/fil-PH/build-integration.md b/polkadot-wiki/translated_docs/fil-PH/build-integration.md similarity index 100% rename from website/translated_docs/fil-PH/build-integration.md rename to polkadot-wiki/translated_docs/fil-PH/build-integration.md diff --git a/website/translated_docs/fil-PH/build-node-interaction.md b/polkadot-wiki/translated_docs/fil-PH/build-node-interaction.md similarity index 100% rename from website/translated_docs/fil-PH/build-node-interaction.md rename to polkadot-wiki/translated_docs/fil-PH/build-node-interaction.md diff --git a/website/translated_docs/fil-PH/build-node-management.md b/polkadot-wiki/translated_docs/fil-PH/build-node-management.md similarity index 100% rename from website/translated_docs/fil-PH/build-node-management.md rename to polkadot-wiki/translated_docs/fil-PH/build-node-management.md diff --git a/website/translated_docs/fil-PH/build-oracle.md b/polkadot-wiki/translated_docs/fil-PH/build-oracle.md similarity index 100% rename from website/translated_docs/fil-PH/build-oracle.md rename to polkadot-wiki/translated_docs/fil-PH/build-oracle.md diff --git a/website/translated_docs/fil-PH/build-parachains-rococo.md b/polkadot-wiki/translated_docs/fil-PH/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/fil-PH/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/fil-PH/build-parachains-rococo.md diff --git a/website/translated_docs/fil-PH/build-pdk.md b/polkadot-wiki/translated_docs/fil-PH/build-pdk.md similarity index 100% rename from website/translated_docs/fil-PH/build-pdk.md rename to polkadot-wiki/translated_docs/fil-PH/build-pdk.md diff --git a/polkadot-wiki/translated_docs/fil-PH/build-protocol-info.md b/polkadot-wiki/translated_docs/fil-PH/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/fil-PH/build-smart-contracts.md b/polkadot-wiki/translated_docs/fil-PH/build-smart-contracts.md similarity index 100% rename from website/translated_docs/fil-PH/build-smart-contracts.md rename to polkadot-wiki/translated_docs/fil-PH/build-smart-contracts.md diff --git a/website/translated_docs/fil-PH/build-tools-index.md b/polkadot-wiki/translated_docs/fil-PH/build-tools-index.md similarity index 100% rename from website/translated_docs/fil-PH/build-tools-index.md rename to polkadot-wiki/translated_docs/fil-PH/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/fil-PH/build-transaction-construction.md b/polkadot-wiki/translated_docs/fil-PH/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/fil-PH/build-wallets.md b/polkadot-wiki/translated_docs/fil-PH/build-wallets.md similarity index 100% rename from website/translated_docs/fil-PH/build-wallets.md rename to polkadot-wiki/translated_docs/fil-PH/build-wallets.md diff --git a/polkadot-wiki/translated_docs/fil-PH/claims.md b/polkadot-wiki/translated_docs/fil-PH/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/fil-PH/community.md b/polkadot-wiki/translated_docs/fil-PH/community.md similarity index 100% rename from website/translated_docs/fil-PH/community.md rename to polkadot-wiki/translated_docs/fil-PH/community.md diff --git a/website/translated_docs/fil-PH/contributing.md b/polkadot-wiki/translated_docs/fil-PH/contributing.md similarity index 100% rename from website/translated_docs/fil-PH/contributing.md rename to polkadot-wiki/translated_docs/fil-PH/contributing.md diff --git a/website/translated_docs/fil-PH/contributors.md b/polkadot-wiki/translated_docs/fil-PH/contributors.md similarity index 100% rename from website/translated_docs/fil-PH/contributors.md rename to polkadot-wiki/translated_docs/fil-PH/contributors.md diff --git a/website/translated_docs/fil-PH/ens.md b/polkadot-wiki/translated_docs/fil-PH/ens.md similarity index 100% rename from website/translated_docs/fil-PH/ens.md rename to polkadot-wiki/translated_docs/fil-PH/ens.md diff --git a/website/translated_docs/fil-PH/faq.md b/polkadot-wiki/translated_docs/fil-PH/faq.md similarity index 100% rename from website/translated_docs/fil-PH/faq.md rename to polkadot-wiki/translated_docs/fil-PH/faq.md diff --git a/polkadot-wiki/translated_docs/fil-PH/getting-started.md b/polkadot-wiki/translated_docs/fil-PH/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/fil-PH/glossary.md b/polkadot-wiki/translated_docs/fil-PH/glossary.md similarity index 100% rename from website/translated_docs/fil-PH/glossary.md rename to polkadot-wiki/translated_docs/fil-PH/glossary.md diff --git a/polkadot-wiki/translated_docs/fil-PH/grants.md b/polkadot-wiki/translated_docs/fil-PH/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/fil-PH/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/fil-PH/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/fil-PH/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/fil-PH/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-bug-bounty.md diff --git a/website/translated_docs/fil-PH/kusama-claims.md b/polkadot-wiki/translated_docs/fil-PH/kusama-claims.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-claims.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-claims.md diff --git a/website/translated_docs/fil-PH/kusama-coc.md b/polkadot-wiki/translated_docs/fil-PH/kusama-coc.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-coc.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-coc.md diff --git a/website/translated_docs/fil-PH/kusama-community.md b/polkadot-wiki/translated_docs/fil-PH/kusama-community.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-community.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-community.md diff --git a/website/translated_docs/fil-PH/kusama-endpoints.md b/polkadot-wiki/translated_docs/fil-PH/kusama-endpoints.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-endpoints.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-endpoints.md diff --git a/website/translated_docs/fil-PH/kusama-faucet.md b/polkadot-wiki/translated_docs/fil-PH/kusama-faucet.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-faucet.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-faucet.md diff --git a/website/translated_docs/fil-PH/kusama-getting-started.md b/polkadot-wiki/translated_docs/fil-PH/kusama-getting-started.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-getting-started.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-getting-started.md diff --git a/website/translated_docs/fil-PH/kusama-index.md b/polkadot-wiki/translated_docs/fil-PH/kusama-index.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-index.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-index.md diff --git a/polkadot-wiki/translated_docs/fil-PH/kusama-ledger.md b/polkadot-wiki/translated_docs/fil-PH/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/fil-PH/kusama-parameters.md b/polkadot-wiki/translated_docs/fil-PH/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/fil-PH/kusama-social-recovery.md b/polkadot-wiki/translated_docs/fil-PH/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-social-recovery.md diff --git a/website/translated_docs/fil-PH/kusama-timeline.md b/polkadot-wiki/translated_docs/fil-PH/kusama-timeline.md similarity index 100% rename from website/translated_docs/fil-PH/kusama-timeline.md rename to polkadot-wiki/translated_docs/fil-PH/kusama-timeline.md diff --git a/website/translated_docs/fil-PH/learn-DOT.md b/polkadot-wiki/translated_docs/fil-PH/learn-DOT.md similarity index 100% rename from website/translated_docs/fil-PH/learn-DOT.md rename to polkadot-wiki/translated_docs/fil-PH/learn-DOT.md diff --git a/website/translated_docs/fil-PH/learn-account-generation.md b/polkadot-wiki/translated_docs/fil-PH/learn-account-generation.md similarity index 100% rename from website/translated_docs/fil-PH/learn-account-generation.md rename to polkadot-wiki/translated_docs/fil-PH/learn-account-generation.md diff --git a/website/translated_docs/fil-PH/learn-account-restore.md b/polkadot-wiki/translated_docs/fil-PH/learn-account-restore.md similarity index 100% rename from website/translated_docs/fil-PH/learn-account-restore.md rename to polkadot-wiki/translated_docs/fil-PH/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-accounts.md b/polkadot-wiki/translated_docs/fil-PH/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/fil-PH/learn-architecture.md b/polkadot-wiki/translated_docs/fil-PH/learn-architecture.md similarity index 100% rename from website/translated_docs/fil-PH/learn-architecture.md rename to polkadot-wiki/translated_docs/fil-PH/learn-architecture.md diff --git a/website/translated_docs/fil-PH/learn-auction.md b/polkadot-wiki/translated_docs/fil-PH/learn-auction.md similarity index 100% rename from website/translated_docs/fil-PH/learn-auction.md rename to polkadot-wiki/translated_docs/fil-PH/learn-auction.md diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-availability.md b/polkadot-wiki/translated_docs/fil-PH/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-balance-transfers.md b/polkadot-wiki/translated_docs/fil-PH/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-bridges.md b/polkadot-wiki/translated_docs/fil-PH/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/fil-PH/learn-collator.md b/polkadot-wiki/translated_docs/fil-PH/learn-collator.md similarity index 100% rename from website/translated_docs/fil-PH/learn-collator.md rename to polkadot-wiki/translated_docs/fil-PH/learn-collator.md diff --git a/website/translated_docs/fil-PH/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/fil-PH/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/fil-PH/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/fil-PH/learn-comparison-dfinity.md diff --git a/website/translated_docs/fil-PH/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/fil-PH/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/fil-PH/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/fil-PH/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/fil-PH/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/fil-PH/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/fil-PH/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/fil-PH/learn-comparisons-cosmos.md diff --git a/website/translated_docs/fil-PH/learn-comparisons.md b/polkadot-wiki/translated_docs/fil-PH/learn-comparisons.md similarity index 100% rename from website/translated_docs/fil-PH/learn-comparisons.md rename to polkadot-wiki/translated_docs/fil-PH/learn-comparisons.md diff --git a/website/translated_docs/fil-PH/learn-consensus.md b/polkadot-wiki/translated_docs/fil-PH/learn-consensus.md similarity index 100% rename from website/translated_docs/fil-PH/learn-consensus.md rename to polkadot-wiki/translated_docs/fil-PH/learn-consensus.md diff --git a/website/translated_docs/fil-PH/learn-crosschain.md b/polkadot-wiki/translated_docs/fil-PH/learn-crosschain.md similarity index 100% rename from website/translated_docs/fil-PH/learn-crosschain.md rename to polkadot-wiki/translated_docs/fil-PH/learn-crosschain.md diff --git a/website/translated_docs/fil-PH/learn-crowdloans.md b/polkadot-wiki/translated_docs/fil-PH/learn-crowdloans.md similarity index 100% rename from website/translated_docs/fil-PH/learn-crowdloans.md rename to polkadot-wiki/translated_docs/fil-PH/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-cryptography.md b/polkadot-wiki/translated_docs/fil-PH/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-governance.md b/polkadot-wiki/translated_docs/fil-PH/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/fil-PH/learn-identity.md b/polkadot-wiki/translated_docs/fil-PH/learn-identity.md similarity index 100% rename from website/translated_docs/fil-PH/learn-identity.md rename to polkadot-wiki/translated_docs/fil-PH/learn-identity.md diff --git a/website/translated_docs/fil-PH/learn-implementations.md b/polkadot-wiki/translated_docs/fil-PH/learn-implementations.md similarity index 100% rename from website/translated_docs/fil-PH/learn-implementations.md rename to polkadot-wiki/translated_docs/fil-PH/learn-implementations.md diff --git a/website/translated_docs/fil-PH/learn-implementers-guide.md b/polkadot-wiki/translated_docs/fil-PH/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/fil-PH/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/fil-PH/learn-implementers-guide.md diff --git a/website/translated_docs/fil-PH/learn-keys.md b/polkadot-wiki/translated_docs/fil-PH/learn-keys.md similarity index 100% rename from website/translated_docs/fil-PH/learn-keys.md rename to polkadot-wiki/translated_docs/fil-PH/learn-keys.md diff --git a/website/translated_docs/fil-PH/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/fil-PH/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/fil-PH/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/fil-PH/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/fil-PH/learn-launch.md b/polkadot-wiki/translated_docs/fil-PH/learn-launch.md similarity index 100% rename from website/translated_docs/fil-PH/learn-launch.md rename to polkadot-wiki/translated_docs/fil-PH/learn-launch.md diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-ledger.md b/polkadot-wiki/translated_docs/fil-PH/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/fil-PH/learn-nominator.md b/polkadot-wiki/translated_docs/fil-PH/learn-nominator.md similarity index 100% rename from website/translated_docs/fil-PH/learn-nominator.md rename to polkadot-wiki/translated_docs/fil-PH/learn-nominator.md diff --git a/website/translated_docs/fil-PH/learn-parachains.md b/polkadot-wiki/translated_docs/fil-PH/learn-parachains.md similarity index 100% rename from website/translated_docs/fil-PH/learn-parachains.md rename to polkadot-wiki/translated_docs/fil-PH/learn-parachains.md diff --git a/website/translated_docs/fil-PH/learn-parathreads.md b/polkadot-wiki/translated_docs/fil-PH/learn-parathreads.md similarity index 100% rename from website/translated_docs/fil-PH/learn-parathreads.md rename to polkadot-wiki/translated_docs/fil-PH/learn-parathreads.md diff --git a/website/translated_docs/fil-PH/learn-phragmen.md b/polkadot-wiki/translated_docs/fil-PH/learn-phragmen.md similarity index 100% rename from website/translated_docs/fil-PH/learn-phragmen.md rename to polkadot-wiki/translated_docs/fil-PH/learn-phragmen.md diff --git a/website/translated_docs/fil-PH/learn-polkadot-host.md b/polkadot-wiki/translated_docs/fil-PH/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/fil-PH/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/fil-PH/learn-polkadot-host.md diff --git a/website/translated_docs/fil-PH/learn-proxies.md b/polkadot-wiki/translated_docs/fil-PH/learn-proxies.md similarity index 100% rename from website/translated_docs/fil-PH/learn-proxies.md rename to polkadot-wiki/translated_docs/fil-PH/learn-proxies.md diff --git a/website/translated_docs/fil-PH/learn-randomness.md b/polkadot-wiki/translated_docs/fil-PH/learn-randomness.md similarity index 100% rename from website/translated_docs/fil-PH/learn-randomness.md rename to polkadot-wiki/translated_docs/fil-PH/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-registrar.md b/polkadot-wiki/translated_docs/fil-PH/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/fil-PH/learn-scams.md b/polkadot-wiki/translated_docs/fil-PH/learn-scams.md similarity index 100% rename from website/translated_docs/fil-PH/learn-scams.md rename to polkadot-wiki/translated_docs/fil-PH/learn-scams.md diff --git a/website/translated_docs/fil-PH/learn-security.md b/polkadot-wiki/translated_docs/fil-PH/learn-security.md similarity index 100% rename from website/translated_docs/fil-PH/learn-security.md rename to polkadot-wiki/translated_docs/fil-PH/learn-security.md diff --git a/website/translated_docs/fil-PH/learn-simple-payouts.md b/polkadot-wiki/translated_docs/fil-PH/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/fil-PH/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/fil-PH/learn-simple-payouts.md diff --git a/website/translated_docs/fil-PH/learn-spree.md b/polkadot-wiki/translated_docs/fil-PH/learn-spree.md similarity index 100% rename from website/translated_docs/fil-PH/learn-spree.md rename to polkadot-wiki/translated_docs/fil-PH/learn-spree.md diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-staking.md b/polkadot-wiki/translated_docs/fil-PH/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/fil-PH/learn-transaction-fees.md b/polkadot-wiki/translated_docs/fil-PH/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/fil-PH/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/fil-PH/learn-transaction-fees.md diff --git a/polkadot-wiki/translated_docs/fil-PH/learn-treasury.md b/polkadot-wiki/translated_docs/fil-PH/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/fil-PH/learn-validator.md b/polkadot-wiki/translated_docs/fil-PH/learn-validator.md similarity index 100% rename from website/translated_docs/fil-PH/learn-validator.md rename to polkadot-wiki/translated_docs/fil-PH/learn-validator.md diff --git a/website/translated_docs/fil-PH/learn-wasm.md b/polkadot-wiki/translated_docs/fil-PH/learn-wasm.md similarity index 100% rename from website/translated_docs/fil-PH/learn-wasm.md rename to polkadot-wiki/translated_docs/fil-PH/learn-wasm.md diff --git a/website/translated_docs/fil-PH/maintain-errors.md b/polkadot-wiki/translated_docs/fil-PH/maintain-errors.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-errors.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-errors.md diff --git a/website/translated_docs/fil-PH/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-democracy.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/fil-PH/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/fil-PH/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/fil-PH/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/fil-PH/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-guides-validator-payout.md diff --git a/website/translated_docs/fi/maintain-index.md b/polkadot-wiki/translated_docs/fil-PH/maintain-index.md similarity index 100% rename from website/translated_docs/fi/maintain-index.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-index.md diff --git a/website/translated_docs/fil-PH/maintain-networks.md b/polkadot-wiki/translated_docs/fil-PH/maintain-networks.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-networks.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-networks.md diff --git a/polkadot-wiki/translated_docs/fil-PH/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/fil-PH/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/fil-PH/maintain-sync.md b/polkadot-wiki/translated_docs/fil-PH/maintain-sync.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-sync.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-sync.md diff --git a/website/translated_docs/fil-PH/maintain-wss.md b/polkadot-wiki/translated_docs/fil-PH/maintain-wss.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-wss.md rename to polkadot-wiki/translated_docs/fil-PH/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/fil-PH/redenomination.md b/polkadot-wiki/translated_docs/fil-PH/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/fil-PH/research.md b/polkadot-wiki/translated_docs/fil-PH/research.md similarity index 100% rename from website/translated_docs/fil-PH/research.md rename to polkadot-wiki/translated_docs/fil-PH/research.md diff --git a/polkadot-wiki/translated_docs/fil-PH/thousand-validators.md b/polkadot-wiki/translated_docs/fil-PH/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/fil-PH/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/fr/ambassadors.md b/polkadot-wiki/translated_docs/fr/ambassadors.md similarity index 100% rename from website/translated_docs/fr/ambassadors.md rename to polkadot-wiki/translated_docs/fr/ambassadors.md diff --git a/website/translated_docs/fr/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/fr/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/fr/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/fr/build-build-with-polkadot.md diff --git a/website/translated_docs/fr/build-cumulus.md b/polkadot-wiki/translated_docs/fr/build-cumulus.md similarity index 100% rename from website/translated_docs/fr/build-cumulus.md rename to polkadot-wiki/translated_docs/fr/build-cumulus.md diff --git a/website/translated_docs/fr/build-hackathon.md b/polkadot-wiki/translated_docs/fr/build-hackathon.md similarity index 100% rename from website/translated_docs/fr/build-hackathon.md rename to polkadot-wiki/translated_docs/fr/build-hackathon.md diff --git a/website/translated_docs/fr/build-index.md b/polkadot-wiki/translated_docs/fr/build-index.md similarity index 100% rename from website/translated_docs/fr/build-index.md rename to polkadot-wiki/translated_docs/fr/build-index.md diff --git a/website/translated_docs/fr/build-integration.md b/polkadot-wiki/translated_docs/fr/build-integration.md similarity index 100% rename from website/translated_docs/fr/build-integration.md rename to polkadot-wiki/translated_docs/fr/build-integration.md diff --git a/website/translated_docs/fr/build-node-interaction.md b/polkadot-wiki/translated_docs/fr/build-node-interaction.md similarity index 100% rename from website/translated_docs/fr/build-node-interaction.md rename to polkadot-wiki/translated_docs/fr/build-node-interaction.md diff --git a/website/translated_docs/fr/build-node-management.md b/polkadot-wiki/translated_docs/fr/build-node-management.md similarity index 100% rename from website/translated_docs/fr/build-node-management.md rename to polkadot-wiki/translated_docs/fr/build-node-management.md diff --git a/website/translated_docs/fr/build-oracle.md b/polkadot-wiki/translated_docs/fr/build-oracle.md similarity index 100% rename from website/translated_docs/fr/build-oracle.md rename to polkadot-wiki/translated_docs/fr/build-oracle.md diff --git a/website/translated_docs/fr/build-parachains-rococo.md b/polkadot-wiki/translated_docs/fr/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/fr/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/fr/build-parachains-rococo.md diff --git a/website/translated_docs/fr/build-pdk.md b/polkadot-wiki/translated_docs/fr/build-pdk.md similarity index 100% rename from website/translated_docs/fr/build-pdk.md rename to polkadot-wiki/translated_docs/fr/build-pdk.md diff --git a/polkadot-wiki/translated_docs/fr/build-protocol-info.md b/polkadot-wiki/translated_docs/fr/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/fr/build-smart-contracts.md b/polkadot-wiki/translated_docs/fr/build-smart-contracts.md similarity index 100% rename from website/translated_docs/fr/build-smart-contracts.md rename to polkadot-wiki/translated_docs/fr/build-smart-contracts.md diff --git a/website/translated_docs/fr/build-tools-index.md b/polkadot-wiki/translated_docs/fr/build-tools-index.md similarity index 100% rename from website/translated_docs/fr/build-tools-index.md rename to polkadot-wiki/translated_docs/fr/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/fr/build-transaction-construction.md b/polkadot-wiki/translated_docs/fr/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/fr/build-wallets.md b/polkadot-wiki/translated_docs/fr/build-wallets.md similarity index 100% rename from website/translated_docs/fr/build-wallets.md rename to polkadot-wiki/translated_docs/fr/build-wallets.md diff --git a/polkadot-wiki/translated_docs/fr/claims.md b/polkadot-wiki/translated_docs/fr/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/fr/community.md b/polkadot-wiki/translated_docs/fr/community.md similarity index 100% rename from website/translated_docs/fr/community.md rename to polkadot-wiki/translated_docs/fr/community.md diff --git a/website/translated_docs/fr/contributing.md b/polkadot-wiki/translated_docs/fr/contributing.md similarity index 100% rename from website/translated_docs/fr/contributing.md rename to polkadot-wiki/translated_docs/fr/contributing.md diff --git a/website/translated_docs/fr/contributors.md b/polkadot-wiki/translated_docs/fr/contributors.md similarity index 100% rename from website/translated_docs/fr/contributors.md rename to polkadot-wiki/translated_docs/fr/contributors.md diff --git a/website/translated_docs/fr/ens.md b/polkadot-wiki/translated_docs/fr/ens.md similarity index 100% rename from website/translated_docs/fr/ens.md rename to polkadot-wiki/translated_docs/fr/ens.md diff --git a/website/translated_docs/fr/faq.md b/polkadot-wiki/translated_docs/fr/faq.md similarity index 100% rename from website/translated_docs/fr/faq.md rename to polkadot-wiki/translated_docs/fr/faq.md diff --git a/polkadot-wiki/translated_docs/fr/getting-started.md b/polkadot-wiki/translated_docs/fr/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/fr/glossary.md b/polkadot-wiki/translated_docs/fr/glossary.md similarity index 100% rename from website/translated_docs/fr/glossary.md rename to polkadot-wiki/translated_docs/fr/glossary.md diff --git a/polkadot-wiki/translated_docs/fr/grants.md b/polkadot-wiki/translated_docs/fr/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/fr/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/fr/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/fr/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/fr/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/fr/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/fr/kusama-bug-bounty.md diff --git a/website/translated_docs/fr/kusama-claims.md b/polkadot-wiki/translated_docs/fr/kusama-claims.md similarity index 100% rename from website/translated_docs/fr/kusama-claims.md rename to polkadot-wiki/translated_docs/fr/kusama-claims.md diff --git a/website/translated_docs/fr/kusama-coc.md b/polkadot-wiki/translated_docs/fr/kusama-coc.md similarity index 100% rename from website/translated_docs/fr/kusama-coc.md rename to polkadot-wiki/translated_docs/fr/kusama-coc.md diff --git a/website/translated_docs/fr/kusama-community.md b/polkadot-wiki/translated_docs/fr/kusama-community.md similarity index 100% rename from website/translated_docs/fr/kusama-community.md rename to polkadot-wiki/translated_docs/fr/kusama-community.md diff --git a/website/translated_docs/fr/kusama-endpoints.md b/polkadot-wiki/translated_docs/fr/kusama-endpoints.md similarity index 100% rename from website/translated_docs/fr/kusama-endpoints.md rename to polkadot-wiki/translated_docs/fr/kusama-endpoints.md diff --git a/website/translated_docs/fr/kusama-faucet.md b/polkadot-wiki/translated_docs/fr/kusama-faucet.md similarity index 100% rename from website/translated_docs/fr/kusama-faucet.md rename to polkadot-wiki/translated_docs/fr/kusama-faucet.md diff --git a/website/translated_docs/fr/kusama-getting-started.md b/polkadot-wiki/translated_docs/fr/kusama-getting-started.md similarity index 100% rename from website/translated_docs/fr/kusama-getting-started.md rename to polkadot-wiki/translated_docs/fr/kusama-getting-started.md diff --git a/website/translated_docs/fr/kusama-index.md b/polkadot-wiki/translated_docs/fr/kusama-index.md similarity index 100% rename from website/translated_docs/fr/kusama-index.md rename to polkadot-wiki/translated_docs/fr/kusama-index.md diff --git a/polkadot-wiki/translated_docs/fr/kusama-ledger.md b/polkadot-wiki/translated_docs/fr/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/fr/kusama-parameters.md b/polkadot-wiki/translated_docs/fr/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/fr/kusama-social-recovery.md b/polkadot-wiki/translated_docs/fr/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/fr/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/fr/kusama-social-recovery.md diff --git a/website/translated_docs/fr/kusama-timeline.md b/polkadot-wiki/translated_docs/fr/kusama-timeline.md similarity index 100% rename from website/translated_docs/fr/kusama-timeline.md rename to polkadot-wiki/translated_docs/fr/kusama-timeline.md diff --git a/website/translated_docs/fr/learn-DOT.md b/polkadot-wiki/translated_docs/fr/learn-DOT.md similarity index 100% rename from website/translated_docs/fr/learn-DOT.md rename to polkadot-wiki/translated_docs/fr/learn-DOT.md diff --git a/website/translated_docs/fr/learn-account-generation.md b/polkadot-wiki/translated_docs/fr/learn-account-generation.md similarity index 100% rename from website/translated_docs/fr/learn-account-generation.md rename to polkadot-wiki/translated_docs/fr/learn-account-generation.md diff --git a/website/translated_docs/fr/learn-account-restore.md b/polkadot-wiki/translated_docs/fr/learn-account-restore.md similarity index 100% rename from website/translated_docs/fr/learn-account-restore.md rename to polkadot-wiki/translated_docs/fr/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/fr/learn-accounts.md b/polkadot-wiki/translated_docs/fr/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/fr/learn-architecture.md b/polkadot-wiki/translated_docs/fr/learn-architecture.md similarity index 100% rename from website/translated_docs/fr/learn-architecture.md rename to polkadot-wiki/translated_docs/fr/learn-architecture.md diff --git a/website/translated_docs/fr/learn-auction.md b/polkadot-wiki/translated_docs/fr/learn-auction.md similarity index 100% rename from website/translated_docs/fr/learn-auction.md rename to polkadot-wiki/translated_docs/fr/learn-auction.md diff --git a/polkadot-wiki/translated_docs/fr/learn-availability.md b/polkadot-wiki/translated_docs/fr/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/fr/learn-balance-transfers.md b/polkadot-wiki/translated_docs/fr/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/fr/learn-bridges.md b/polkadot-wiki/translated_docs/fr/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/fr/learn-collator.md b/polkadot-wiki/translated_docs/fr/learn-collator.md similarity index 100% rename from website/translated_docs/fr/learn-collator.md rename to polkadot-wiki/translated_docs/fr/learn-collator.md diff --git a/website/translated_docs/fr/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/fr/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/fr/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/fr/learn-comparison-dfinity.md diff --git a/website/translated_docs/fr/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/fr/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/fr/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/fr/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/fr/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/fr/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/fr/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/fr/learn-comparisons-cosmos.md diff --git a/website/translated_docs/fr/learn-comparisons.md b/polkadot-wiki/translated_docs/fr/learn-comparisons.md similarity index 100% rename from website/translated_docs/fr/learn-comparisons.md rename to polkadot-wiki/translated_docs/fr/learn-comparisons.md diff --git a/website/translated_docs/fr/learn-consensus.md b/polkadot-wiki/translated_docs/fr/learn-consensus.md similarity index 100% rename from website/translated_docs/fr/learn-consensus.md rename to polkadot-wiki/translated_docs/fr/learn-consensus.md diff --git a/website/translated_docs/fr/learn-crosschain.md b/polkadot-wiki/translated_docs/fr/learn-crosschain.md similarity index 100% rename from website/translated_docs/fr/learn-crosschain.md rename to polkadot-wiki/translated_docs/fr/learn-crosschain.md diff --git a/website/translated_docs/fr/learn-crowdloans.md b/polkadot-wiki/translated_docs/fr/learn-crowdloans.md similarity index 100% rename from website/translated_docs/fr/learn-crowdloans.md rename to polkadot-wiki/translated_docs/fr/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/fr/learn-cryptography.md b/polkadot-wiki/translated_docs/fr/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/fr/learn-governance.md b/polkadot-wiki/translated_docs/fr/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/fr/learn-identity.md b/polkadot-wiki/translated_docs/fr/learn-identity.md similarity index 100% rename from website/translated_docs/fr/learn-identity.md rename to polkadot-wiki/translated_docs/fr/learn-identity.md diff --git a/website/translated_docs/fr/learn-implementations.md b/polkadot-wiki/translated_docs/fr/learn-implementations.md similarity index 100% rename from website/translated_docs/fr/learn-implementations.md rename to polkadot-wiki/translated_docs/fr/learn-implementations.md diff --git a/website/translated_docs/fr/learn-implementers-guide.md b/polkadot-wiki/translated_docs/fr/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/fr/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/fr/learn-implementers-guide.md diff --git a/website/translated_docs/fr/learn-keys.md b/polkadot-wiki/translated_docs/fr/learn-keys.md similarity index 100% rename from website/translated_docs/fr/learn-keys.md rename to polkadot-wiki/translated_docs/fr/learn-keys.md diff --git a/website/translated_docs/fr/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/fr/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/fr/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/fr/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/fr/learn-launch.md b/polkadot-wiki/translated_docs/fr/learn-launch.md similarity index 100% rename from website/translated_docs/fr/learn-launch.md rename to polkadot-wiki/translated_docs/fr/learn-launch.md diff --git a/polkadot-wiki/translated_docs/fr/learn-ledger.md b/polkadot-wiki/translated_docs/fr/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/fr/learn-nominator.md b/polkadot-wiki/translated_docs/fr/learn-nominator.md similarity index 100% rename from website/translated_docs/fr/learn-nominator.md rename to polkadot-wiki/translated_docs/fr/learn-nominator.md diff --git a/website/translated_docs/fr/learn-parachains.md b/polkadot-wiki/translated_docs/fr/learn-parachains.md similarity index 100% rename from website/translated_docs/fr/learn-parachains.md rename to polkadot-wiki/translated_docs/fr/learn-parachains.md diff --git a/website/translated_docs/fr/learn-parathreads.md b/polkadot-wiki/translated_docs/fr/learn-parathreads.md similarity index 100% rename from website/translated_docs/fr/learn-parathreads.md rename to polkadot-wiki/translated_docs/fr/learn-parathreads.md diff --git a/website/translated_docs/fr/learn-phragmen.md b/polkadot-wiki/translated_docs/fr/learn-phragmen.md similarity index 100% rename from website/translated_docs/fr/learn-phragmen.md rename to polkadot-wiki/translated_docs/fr/learn-phragmen.md diff --git a/website/translated_docs/fr/learn-polkadot-host.md b/polkadot-wiki/translated_docs/fr/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/fr/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/fr/learn-polkadot-host.md diff --git a/website/translated_docs/fr/learn-proxies.md b/polkadot-wiki/translated_docs/fr/learn-proxies.md similarity index 100% rename from website/translated_docs/fr/learn-proxies.md rename to polkadot-wiki/translated_docs/fr/learn-proxies.md diff --git a/website/translated_docs/fr/learn-randomness.md b/polkadot-wiki/translated_docs/fr/learn-randomness.md similarity index 100% rename from website/translated_docs/fr/learn-randomness.md rename to polkadot-wiki/translated_docs/fr/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/fr/learn-registrar.md b/polkadot-wiki/translated_docs/fr/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/fr/learn-scams.md b/polkadot-wiki/translated_docs/fr/learn-scams.md similarity index 100% rename from website/translated_docs/fr/learn-scams.md rename to polkadot-wiki/translated_docs/fr/learn-scams.md diff --git a/website/translated_docs/fr/learn-security.md b/polkadot-wiki/translated_docs/fr/learn-security.md similarity index 100% rename from website/translated_docs/fr/learn-security.md rename to polkadot-wiki/translated_docs/fr/learn-security.md diff --git a/website/translated_docs/fr/learn-simple-payouts.md b/polkadot-wiki/translated_docs/fr/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/fr/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/fr/learn-simple-payouts.md diff --git a/website/translated_docs/fr/learn-spree.md b/polkadot-wiki/translated_docs/fr/learn-spree.md similarity index 100% rename from website/translated_docs/fr/learn-spree.md rename to polkadot-wiki/translated_docs/fr/learn-spree.md diff --git a/polkadot-wiki/translated_docs/fr/learn-staking.md b/polkadot-wiki/translated_docs/fr/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/fr/learn-transaction-fees.md b/polkadot-wiki/translated_docs/fr/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/fr/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/fr/learn-transaction-fees.md diff --git a/polkadot-wiki/translated_docs/fr/learn-treasury.md b/polkadot-wiki/translated_docs/fr/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/fr/learn-validator.md b/polkadot-wiki/translated_docs/fr/learn-validator.md similarity index 100% rename from website/translated_docs/fr/learn-validator.md rename to polkadot-wiki/translated_docs/fr/learn-validator.md diff --git a/website/translated_docs/fr/learn-wasm.md b/polkadot-wiki/translated_docs/fr/learn-wasm.md similarity index 100% rename from website/translated_docs/fr/learn-wasm.md rename to polkadot-wiki/translated_docs/fr/learn-wasm.md diff --git a/website/translated_docs/fr/maintain-errors.md b/polkadot-wiki/translated_docs/fr/maintain-errors.md similarity index 100% rename from website/translated_docs/fr/maintain-errors.md rename to polkadot-wiki/translated_docs/fr/maintain-errors.md diff --git a/website/translated_docs/fr/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/fr/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-democracy.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/fr/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/fr/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/fr/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/fr/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/fr/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/fr/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/fr/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/fr/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/fr/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/fr/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/fr/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/fr/maintain-guides-validator-payout.md diff --git a/website/translated_docs/fil-PH/maintain-index.md b/polkadot-wiki/translated_docs/fr/maintain-index.md similarity index 100% rename from website/translated_docs/fil-PH/maintain-index.md rename to polkadot-wiki/translated_docs/fr/maintain-index.md diff --git a/website/translated_docs/fr/maintain-networks.md b/polkadot-wiki/translated_docs/fr/maintain-networks.md similarity index 100% rename from website/translated_docs/fr/maintain-networks.md rename to polkadot-wiki/translated_docs/fr/maintain-networks.md diff --git a/polkadot-wiki/translated_docs/fr/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/fr/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/fr/maintain-sync.md b/polkadot-wiki/translated_docs/fr/maintain-sync.md similarity index 100% rename from website/translated_docs/fr/maintain-sync.md rename to polkadot-wiki/translated_docs/fr/maintain-sync.md diff --git a/website/translated_docs/fr/maintain-wss.md b/polkadot-wiki/translated_docs/fr/maintain-wss.md similarity index 100% rename from website/translated_docs/fr/maintain-wss.md rename to polkadot-wiki/translated_docs/fr/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/fr/redenomination.md b/polkadot-wiki/translated_docs/fr/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/fr/research.md b/polkadot-wiki/translated_docs/fr/research.md similarity index 100% rename from website/translated_docs/fr/research.md rename to polkadot-wiki/translated_docs/fr/research.md diff --git a/polkadot-wiki/translated_docs/fr/thousand-validators.md b/polkadot-wiki/translated_docs/fr/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/fr/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/hi-IN/ambassadors.md b/polkadot-wiki/translated_docs/hi-IN/ambassadors.md similarity index 100% rename from website/translated_docs/hi-IN/ambassadors.md rename to polkadot-wiki/translated_docs/hi-IN/ambassadors.md diff --git a/website/translated_docs/hi-IN/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/hi-IN/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/hi-IN/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/hi-IN/build-build-with-polkadot.md diff --git a/website/translated_docs/hi-IN/build-cumulus.md b/polkadot-wiki/translated_docs/hi-IN/build-cumulus.md similarity index 100% rename from website/translated_docs/hi-IN/build-cumulus.md rename to polkadot-wiki/translated_docs/hi-IN/build-cumulus.md diff --git a/website/translated_docs/hi-IN/build-deploy-parachains.md b/polkadot-wiki/translated_docs/hi-IN/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/hi-IN/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/hi-IN/build-deploy-parachains.md diff --git a/website/translated_docs/hi-IN/build-dev-roadmap.md b/polkadot-wiki/translated_docs/hi-IN/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/hi-IN/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/hi-IN/build-dev-roadmap.md diff --git a/website/translated_docs/hi-IN/build-examples-index.md b/polkadot-wiki/translated_docs/hi-IN/build-examples-index.md similarity index 100% rename from website/translated_docs/hi-IN/build-examples-index.md rename to polkadot-wiki/translated_docs/hi-IN/build-examples-index.md diff --git a/website/translated_docs/hi-IN/build-hackathon.md b/polkadot-wiki/translated_docs/hi-IN/build-hackathon.md similarity index 100% rename from website/translated_docs/hi-IN/build-hackathon.md rename to polkadot-wiki/translated_docs/hi-IN/build-hackathon.md diff --git a/website/translated_docs/hi-IN/build-index.md b/polkadot-wiki/translated_docs/hi-IN/build-index.md similarity index 100% rename from website/translated_docs/hi-IN/build-index.md rename to polkadot-wiki/translated_docs/hi-IN/build-index.md diff --git a/website/translated_docs/hi-IN/build-integration.md b/polkadot-wiki/translated_docs/hi-IN/build-integration.md similarity index 100% rename from website/translated_docs/hi-IN/build-integration.md rename to polkadot-wiki/translated_docs/hi-IN/build-integration.md diff --git a/website/translated_docs/hi-IN/build-node-interaction.md b/polkadot-wiki/translated_docs/hi-IN/build-node-interaction.md similarity index 100% rename from website/translated_docs/hi-IN/build-node-interaction.md rename to polkadot-wiki/translated_docs/hi-IN/build-node-interaction.md diff --git a/website/translated_docs/hi-IN/build-node-management.md b/polkadot-wiki/translated_docs/hi-IN/build-node-management.md similarity index 100% rename from website/translated_docs/hi-IN/build-node-management.md rename to polkadot-wiki/translated_docs/hi-IN/build-node-management.md diff --git a/website/translated_docs/hi-IN/build-oracle.md b/polkadot-wiki/translated_docs/hi-IN/build-oracle.md similarity index 100% rename from website/translated_docs/hi-IN/build-oracle.md rename to polkadot-wiki/translated_docs/hi-IN/build-oracle.md diff --git a/website/translated_docs/hi-IN/build-parachains-rococo.md b/polkadot-wiki/translated_docs/hi-IN/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/hi-IN/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/hi-IN/build-parachains-rococo.md diff --git a/website/translated_docs/hi-IN/build-pdk.md b/polkadot-wiki/translated_docs/hi-IN/build-pdk.md similarity index 100% rename from website/translated_docs/hi-IN/build-pdk.md rename to polkadot-wiki/translated_docs/hi-IN/build-pdk.md diff --git a/polkadot-wiki/translated_docs/hi-IN/build-protocol-info.md b/polkadot-wiki/translated_docs/hi-IN/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/hi-IN/build-smart-contracts.md b/polkadot-wiki/translated_docs/hi-IN/build-smart-contracts.md similarity index 100% rename from website/translated_docs/hi-IN/build-smart-contracts.md rename to polkadot-wiki/translated_docs/hi-IN/build-smart-contracts.md diff --git a/website/translated_docs/hi-IN/build-tools-index.md b/polkadot-wiki/translated_docs/hi-IN/build-tools-index.md similarity index 100% rename from website/translated_docs/hi-IN/build-tools-index.md rename to polkadot-wiki/translated_docs/hi-IN/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/hi-IN/build-transaction-construction.md b/polkadot-wiki/translated_docs/hi-IN/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/hi-IN/build-wallets.md b/polkadot-wiki/translated_docs/hi-IN/build-wallets.md similarity index 100% rename from website/translated_docs/hi-IN/build-wallets.md rename to polkadot-wiki/translated_docs/hi-IN/build-wallets.md diff --git a/polkadot-wiki/translated_docs/hi-IN/claims.md b/polkadot-wiki/translated_docs/hi-IN/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/hi-IN/community.md b/polkadot-wiki/translated_docs/hi-IN/community.md similarity index 100% rename from website/translated_docs/hi-IN/community.md rename to polkadot-wiki/translated_docs/hi-IN/community.md diff --git a/website/translated_docs/hi-IN/contributing.md b/polkadot-wiki/translated_docs/hi-IN/contributing.md similarity index 100% rename from website/translated_docs/hi-IN/contributing.md rename to polkadot-wiki/translated_docs/hi-IN/contributing.md diff --git a/website/translated_docs/hi-IN/contributors.md b/polkadot-wiki/translated_docs/hi-IN/contributors.md similarity index 100% rename from website/translated_docs/hi-IN/contributors.md rename to polkadot-wiki/translated_docs/hi-IN/contributors.md diff --git a/website/translated_docs/hi-IN/ens.md b/polkadot-wiki/translated_docs/hi-IN/ens.md similarity index 100% rename from website/translated_docs/hi-IN/ens.md rename to polkadot-wiki/translated_docs/hi-IN/ens.md diff --git a/website/translated_docs/hi-IN/faq.md b/polkadot-wiki/translated_docs/hi-IN/faq.md similarity index 100% rename from website/translated_docs/hi-IN/faq.md rename to polkadot-wiki/translated_docs/hi-IN/faq.md diff --git a/polkadot-wiki/translated_docs/hi-IN/getting-started.md b/polkadot-wiki/translated_docs/hi-IN/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/hi-IN/glossary.md b/polkadot-wiki/translated_docs/hi-IN/glossary.md similarity index 100% rename from website/translated_docs/hi-IN/glossary.md rename to polkadot-wiki/translated_docs/hi-IN/glossary.md diff --git a/polkadot-wiki/translated_docs/hi-IN/grants.md b/polkadot-wiki/translated_docs/hi-IN/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/hi-IN/index.md b/polkadot-wiki/translated_docs/hi-IN/index.md similarity index 100% rename from website/translated_docs/hi-IN/index.md rename to polkadot-wiki/translated_docs/hi-IN/index.md diff --git a/polkadot-wiki/translated_docs/hi-IN/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/hi-IN/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/hi-IN/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/hi-IN/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-bug-bounty.md diff --git a/website/translated_docs/hi-IN/kusama-claims.md b/polkadot-wiki/translated_docs/hi-IN/kusama-claims.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-claims.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-claims.md diff --git a/website/translated_docs/hi-IN/kusama-coc.md b/polkadot-wiki/translated_docs/hi-IN/kusama-coc.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-coc.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-coc.md diff --git a/website/translated_docs/hi-IN/kusama-community.md b/polkadot-wiki/translated_docs/hi-IN/kusama-community.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-community.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-community.md diff --git a/website/translated_docs/hi-IN/kusama-endpoints.md b/polkadot-wiki/translated_docs/hi-IN/kusama-endpoints.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-endpoints.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-endpoints.md diff --git a/website/translated_docs/hi-IN/kusama-faucet.md b/polkadot-wiki/translated_docs/hi-IN/kusama-faucet.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-faucet.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-faucet.md diff --git a/website/translated_docs/hi-IN/kusama-getting-started.md b/polkadot-wiki/translated_docs/hi-IN/kusama-getting-started.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-getting-started.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-getting-started.md diff --git a/website/translated_docs/hi-IN/kusama-index.md b/polkadot-wiki/translated_docs/hi-IN/kusama-index.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-index.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-index.md diff --git a/polkadot-wiki/translated_docs/hi-IN/kusama-ledger.md b/polkadot-wiki/translated_docs/hi-IN/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/hi-IN/kusama-parameters.md b/polkadot-wiki/translated_docs/hi-IN/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/hi-IN/kusama-social-recovery.md b/polkadot-wiki/translated_docs/hi-IN/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/hi-IN/kusama-time-periods.md b/polkadot-wiki/translated_docs/hi-IN/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/hi-IN/kusama-timeline.md b/polkadot-wiki/translated_docs/hi-IN/kusama-timeline.md similarity index 100% rename from website/translated_docs/hi-IN/kusama-timeline.md rename to polkadot-wiki/translated_docs/hi-IN/kusama-timeline.md diff --git a/website/translated_docs/hi-IN/learn-DOT.md b/polkadot-wiki/translated_docs/hi-IN/learn-DOT.md similarity index 100% rename from website/translated_docs/hi-IN/learn-DOT.md rename to polkadot-wiki/translated_docs/hi-IN/learn-DOT.md diff --git a/website/translated_docs/hi-IN/learn-account-generation.md b/polkadot-wiki/translated_docs/hi-IN/learn-account-generation.md similarity index 100% rename from website/translated_docs/hi-IN/learn-account-generation.md rename to polkadot-wiki/translated_docs/hi-IN/learn-account-generation.md diff --git a/website/translated_docs/hi-IN/learn-account-restore.md b/polkadot-wiki/translated_docs/hi-IN/learn-account-restore.md similarity index 100% rename from website/translated_docs/hi-IN/learn-account-restore.md rename to polkadot-wiki/translated_docs/hi-IN/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-accounts.md b/polkadot-wiki/translated_docs/hi-IN/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/hi-IN/learn-architecture.md b/polkadot-wiki/translated_docs/hi-IN/learn-architecture.md similarity index 100% rename from website/translated_docs/hi-IN/learn-architecture.md rename to polkadot-wiki/translated_docs/hi-IN/learn-architecture.md diff --git a/website/translated_docs/hi-IN/learn-auction.md b/polkadot-wiki/translated_docs/hi-IN/learn-auction.md similarity index 100% rename from website/translated_docs/hi-IN/learn-auction.md rename to polkadot-wiki/translated_docs/hi-IN/learn-auction.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-availability.md b/polkadot-wiki/translated_docs/hi-IN/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-balance-transfers.md b/polkadot-wiki/translated_docs/hi-IN/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-bridges.md b/polkadot-wiki/translated_docs/hi-IN/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/hi-IN/learn-collator.md b/polkadot-wiki/translated_docs/hi-IN/learn-collator.md similarity index 100% rename from website/translated_docs/hi-IN/learn-collator.md rename to polkadot-wiki/translated_docs/hi-IN/learn-collator.md diff --git a/website/translated_docs/hi-IN/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/hi-IN/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/hi-IN/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/hi-IN/learn-comparison-dfinity.md diff --git a/website/translated_docs/hi-IN/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/hi-IN/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/hi-IN/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/hi-IN/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/hi-IN/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/hi-IN/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/hi-IN/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/hi-IN/learn-comparisons-cosmos.md diff --git a/website/translated_docs/hi-IN/learn-comparisons.md b/polkadot-wiki/translated_docs/hi-IN/learn-comparisons.md similarity index 100% rename from website/translated_docs/hi-IN/learn-comparisons.md rename to polkadot-wiki/translated_docs/hi-IN/learn-comparisons.md diff --git a/website/translated_docs/hi-IN/learn-consensus.md b/polkadot-wiki/translated_docs/hi-IN/learn-consensus.md similarity index 100% rename from website/translated_docs/hi-IN/learn-consensus.md rename to polkadot-wiki/translated_docs/hi-IN/learn-consensus.md diff --git a/website/translated_docs/hi-IN/learn-crosschain.md b/polkadot-wiki/translated_docs/hi-IN/learn-crosschain.md similarity index 100% rename from website/translated_docs/hi-IN/learn-crosschain.md rename to polkadot-wiki/translated_docs/hi-IN/learn-crosschain.md diff --git a/website/translated_docs/hi-IN/learn-crowdloans.md b/polkadot-wiki/translated_docs/hi-IN/learn-crowdloans.md similarity index 100% rename from website/translated_docs/hi-IN/learn-crowdloans.md rename to polkadot-wiki/translated_docs/hi-IN/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-cryptography.md b/polkadot-wiki/translated_docs/hi-IN/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/hi-IN/learn-faq.md b/polkadot-wiki/translated_docs/hi-IN/learn-faq.md similarity index 100% rename from website/translated_docs/hi-IN/learn-faq.md rename to polkadot-wiki/translated_docs/hi-IN/learn-faq.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-governance.md b/polkadot-wiki/translated_docs/hi-IN/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/hi-IN/learn-identity.md b/polkadot-wiki/translated_docs/hi-IN/learn-identity.md similarity index 100% rename from website/translated_docs/hi-IN/learn-identity.md rename to polkadot-wiki/translated_docs/hi-IN/learn-identity.md diff --git a/website/translated_docs/hi-IN/learn-implementations.md b/polkadot-wiki/translated_docs/hi-IN/learn-implementations.md similarity index 100% rename from website/translated_docs/hi-IN/learn-implementations.md rename to polkadot-wiki/translated_docs/hi-IN/learn-implementations.md diff --git a/website/translated_docs/hi-IN/learn-implementers-guide.md b/polkadot-wiki/translated_docs/hi-IN/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/hi-IN/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/hi-IN/learn-implementers-guide.md diff --git a/website/translated_docs/hi-IN/learn-introduction.md b/polkadot-wiki/translated_docs/hi-IN/learn-introduction.md similarity index 100% rename from website/translated_docs/hi-IN/learn-introduction.md rename to polkadot-wiki/translated_docs/hi-IN/learn-introduction.md diff --git a/website/translated_docs/hi-IN/learn-keys.md b/polkadot-wiki/translated_docs/hi-IN/learn-keys.md similarity index 100% rename from website/translated_docs/hi-IN/learn-keys.md rename to polkadot-wiki/translated_docs/hi-IN/learn-keys.md diff --git a/website/translated_docs/hi-IN/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/hi-IN/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/hi-IN/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/hi-IN/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/hi-IN/learn-launch.md b/polkadot-wiki/translated_docs/hi-IN/learn-launch.md similarity index 100% rename from website/translated_docs/hi-IN/learn-launch.md rename to polkadot-wiki/translated_docs/hi-IN/learn-launch.md diff --git a/website/translated_docs/hi-IN/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/hi-IN/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/hi-IN/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/hi-IN/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-ledger.md b/polkadot-wiki/translated_docs/hi-IN/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/hi-IN/learn-nominator.md b/polkadot-wiki/translated_docs/hi-IN/learn-nominator.md similarity index 100% rename from website/translated_docs/hi-IN/learn-nominator.md rename to polkadot-wiki/translated_docs/hi-IN/learn-nominator.md diff --git a/website/translated_docs/hi-IN/learn-parachains.md b/polkadot-wiki/translated_docs/hi-IN/learn-parachains.md similarity index 100% rename from website/translated_docs/hi-IN/learn-parachains.md rename to polkadot-wiki/translated_docs/hi-IN/learn-parachains.md diff --git a/website/translated_docs/hi-IN/learn-parathreads.md b/polkadot-wiki/translated_docs/hi-IN/learn-parathreads.md similarity index 100% rename from website/translated_docs/hi-IN/learn-parathreads.md rename to polkadot-wiki/translated_docs/hi-IN/learn-parathreads.md diff --git a/website/translated_docs/hi-IN/learn-phragmen.md b/polkadot-wiki/translated_docs/hi-IN/learn-phragmen.md similarity index 100% rename from website/translated_docs/hi-IN/learn-phragmen.md rename to polkadot-wiki/translated_docs/hi-IN/learn-phragmen.md diff --git a/website/translated_docs/hi-IN/learn-polkadot-host.md b/polkadot-wiki/translated_docs/hi-IN/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/hi-IN/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/hi-IN/learn-polkadot-host.md diff --git a/website/translated_docs/hi-IN/learn-proxies.md b/polkadot-wiki/translated_docs/hi-IN/learn-proxies.md similarity index 100% rename from website/translated_docs/hi-IN/learn-proxies.md rename to polkadot-wiki/translated_docs/hi-IN/learn-proxies.md diff --git a/website/translated_docs/hi-IN/learn-randomness.md b/polkadot-wiki/translated_docs/hi-IN/learn-randomness.md similarity index 100% rename from website/translated_docs/hi-IN/learn-randomness.md rename to polkadot-wiki/translated_docs/hi-IN/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-registrar.md b/polkadot-wiki/translated_docs/hi-IN/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/hi-IN/learn-relevant-links.md b/polkadot-wiki/translated_docs/hi-IN/learn-relevant-links.md similarity index 100% rename from website/translated_docs/hi-IN/learn-relevant-links.md rename to polkadot-wiki/translated_docs/hi-IN/learn-relevant-links.md diff --git a/website/translated_docs/hi-IN/learn-roadmap.md b/polkadot-wiki/translated_docs/hi-IN/learn-roadmap.md similarity index 100% rename from website/translated_docs/hi-IN/learn-roadmap.md rename to polkadot-wiki/translated_docs/hi-IN/learn-roadmap.md diff --git a/website/translated_docs/hi-IN/learn-scams.md b/polkadot-wiki/translated_docs/hi-IN/learn-scams.md similarity index 100% rename from website/translated_docs/hi-IN/learn-scams.md rename to polkadot-wiki/translated_docs/hi-IN/learn-scams.md diff --git a/website/translated_docs/hi-IN/learn-security.md b/polkadot-wiki/translated_docs/hi-IN/learn-security.md similarity index 100% rename from website/translated_docs/hi-IN/learn-security.md rename to polkadot-wiki/translated_docs/hi-IN/learn-security.md diff --git a/website/translated_docs/hi-IN/learn-simple-payouts.md b/polkadot-wiki/translated_docs/hi-IN/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/hi-IN/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/hi-IN/learn-simple-payouts.md diff --git a/website/translated_docs/hi-IN/learn-spree.md b/polkadot-wiki/translated_docs/hi-IN/learn-spree.md similarity index 100% rename from website/translated_docs/hi-IN/learn-spree.md rename to polkadot-wiki/translated_docs/hi-IN/learn-spree.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-staking.md b/polkadot-wiki/translated_docs/hi-IN/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/hi-IN/learn-transaction-fees.md b/polkadot-wiki/translated_docs/hi-IN/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/hi-IN/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/hi-IN/learn-transaction-fees.md diff --git a/website/translated_docs/hi-IN/learn-transactions.md b/polkadot-wiki/translated_docs/hi-IN/learn-transactions.md similarity index 100% rename from website/translated_docs/hi-IN/learn-transactions.md rename to polkadot-wiki/translated_docs/hi-IN/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/hi-IN/learn-treasury.md b/polkadot-wiki/translated_docs/hi-IN/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/hi-IN/learn-validator.md b/polkadot-wiki/translated_docs/hi-IN/learn-validator.md similarity index 100% rename from website/translated_docs/hi-IN/learn-validator.md rename to polkadot-wiki/translated_docs/hi-IN/learn-validator.md diff --git a/website/translated_docs/hi-IN/learn-wasm.md b/polkadot-wiki/translated_docs/hi-IN/learn-wasm.md similarity index 100% rename from website/translated_docs/hi-IN/learn-wasm.md rename to polkadot-wiki/translated_docs/hi-IN/learn-wasm.md diff --git a/website/translated_docs/hi-IN/maintain-collator.md b/polkadot-wiki/translated_docs/hi-IN/maintain-collator.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-collator.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-collator.md diff --git a/website/translated_docs/hi-IN/maintain-errors.md b/polkadot-wiki/translated_docs/hi-IN/maintain-errors.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-errors.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-errors.md diff --git a/website/translated_docs/hi-IN/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-democracy.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/hi-IN/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/hi-IN/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/hi-IN/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/hi-IN/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-guides-validator-payout.md diff --git a/website/translated_docs/fr/maintain-index.md b/polkadot-wiki/translated_docs/hi-IN/maintain-index.md similarity index 100% rename from website/translated_docs/fr/maintain-index.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-index.md diff --git a/website/translated_docs/hi-IN/maintain-networks.md b/polkadot-wiki/translated_docs/hi-IN/maintain-networks.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-networks.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-networks.md diff --git a/website/translated_docs/hi-IN/maintain-nominator.md b/polkadot-wiki/translated_docs/hi-IN/maintain-nominator.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-nominator.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/hi-IN/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/hi-IN/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/hr-HR/maintain-sync.md b/polkadot-wiki/translated_docs/hi-IN/maintain-sync.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-sync.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-sync.md diff --git a/website/translated_docs/hi-IN/maintain-validator.md b/polkadot-wiki/translated_docs/hi-IN/maintain-validator.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-validator.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-validator.md diff --git a/website/translated_docs/hi-IN/maintain-wss.md b/polkadot-wiki/translated_docs/hi-IN/maintain-wss.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-wss.md rename to polkadot-wiki/translated_docs/hi-IN/maintain-wss.md diff --git a/website/translated_docs/hi-IN/news.md b/polkadot-wiki/translated_docs/hi-IN/news.md similarity index 100% rename from website/translated_docs/hi-IN/news.md rename to polkadot-wiki/translated_docs/hi-IN/news.md diff --git a/polkadot-wiki/translated_docs/hi-IN/redenomination.md b/polkadot-wiki/translated_docs/hi-IN/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/hi-IN/research.md b/polkadot-wiki/translated_docs/hi-IN/research.md similarity index 100% rename from website/translated_docs/hi-IN/research.md rename to polkadot-wiki/translated_docs/hi-IN/research.md diff --git a/polkadot-wiki/translated_docs/hi-IN/thousand-validators.md b/polkadot-wiki/translated_docs/hi-IN/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/hi-IN/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/hr-HR/ambassadors.md b/polkadot-wiki/translated_docs/hr-HR/ambassadors.md similarity index 100% rename from website/translated_docs/hr-HR/ambassadors.md rename to polkadot-wiki/translated_docs/hr-HR/ambassadors.md diff --git a/website/translated_docs/hr-HR/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/hr-HR/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/hr-HR/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/hr-HR/build-build-with-polkadot.md diff --git a/website/translated_docs/hr-HR/build-cumulus.md b/polkadot-wiki/translated_docs/hr-HR/build-cumulus.md similarity index 100% rename from website/translated_docs/hr-HR/build-cumulus.md rename to polkadot-wiki/translated_docs/hr-HR/build-cumulus.md diff --git a/website/translated_docs/hr-HR/build-hackathon.md b/polkadot-wiki/translated_docs/hr-HR/build-hackathon.md similarity index 100% rename from website/translated_docs/hr-HR/build-hackathon.md rename to polkadot-wiki/translated_docs/hr-HR/build-hackathon.md diff --git a/website/translated_docs/hr-HR/build-index.md b/polkadot-wiki/translated_docs/hr-HR/build-index.md similarity index 100% rename from website/translated_docs/hr-HR/build-index.md rename to polkadot-wiki/translated_docs/hr-HR/build-index.md diff --git a/website/translated_docs/hr-HR/build-integration.md b/polkadot-wiki/translated_docs/hr-HR/build-integration.md similarity index 100% rename from website/translated_docs/hr-HR/build-integration.md rename to polkadot-wiki/translated_docs/hr-HR/build-integration.md diff --git a/website/translated_docs/hr-HR/build-node-interaction.md b/polkadot-wiki/translated_docs/hr-HR/build-node-interaction.md similarity index 100% rename from website/translated_docs/hr-HR/build-node-interaction.md rename to polkadot-wiki/translated_docs/hr-HR/build-node-interaction.md diff --git a/website/translated_docs/hr-HR/build-node-management.md b/polkadot-wiki/translated_docs/hr-HR/build-node-management.md similarity index 100% rename from website/translated_docs/hr-HR/build-node-management.md rename to polkadot-wiki/translated_docs/hr-HR/build-node-management.md diff --git a/website/translated_docs/hr-HR/build-oracle.md b/polkadot-wiki/translated_docs/hr-HR/build-oracle.md similarity index 100% rename from website/translated_docs/hr-HR/build-oracle.md rename to polkadot-wiki/translated_docs/hr-HR/build-oracle.md diff --git a/website/translated_docs/hr-HR/build-parachains-rococo.md b/polkadot-wiki/translated_docs/hr-HR/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/hr-HR/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/hr-HR/build-parachains-rococo.md diff --git a/website/translated_docs/hr-HR/build-pdk.md b/polkadot-wiki/translated_docs/hr-HR/build-pdk.md similarity index 100% rename from website/translated_docs/hr-HR/build-pdk.md rename to polkadot-wiki/translated_docs/hr-HR/build-pdk.md diff --git a/polkadot-wiki/translated_docs/hr-HR/build-protocol-info.md b/polkadot-wiki/translated_docs/hr-HR/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/hr-HR/build-smart-contracts.md b/polkadot-wiki/translated_docs/hr-HR/build-smart-contracts.md similarity index 100% rename from website/translated_docs/hr-HR/build-smart-contracts.md rename to polkadot-wiki/translated_docs/hr-HR/build-smart-contracts.md diff --git a/website/translated_docs/hr-HR/build-tools-index.md b/polkadot-wiki/translated_docs/hr-HR/build-tools-index.md similarity index 100% rename from website/translated_docs/hr-HR/build-tools-index.md rename to polkadot-wiki/translated_docs/hr-HR/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/hr-HR/build-transaction-construction.md b/polkadot-wiki/translated_docs/hr-HR/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/hr-HR/build-wallets.md b/polkadot-wiki/translated_docs/hr-HR/build-wallets.md similarity index 100% rename from website/translated_docs/hr-HR/build-wallets.md rename to polkadot-wiki/translated_docs/hr-HR/build-wallets.md diff --git a/polkadot-wiki/translated_docs/hr-HR/claims.md b/polkadot-wiki/translated_docs/hr-HR/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/hr-HR/community.md b/polkadot-wiki/translated_docs/hr-HR/community.md similarity index 100% rename from website/translated_docs/hr-HR/community.md rename to polkadot-wiki/translated_docs/hr-HR/community.md diff --git a/website/translated_docs/hr-HR/contributing.md b/polkadot-wiki/translated_docs/hr-HR/contributing.md similarity index 100% rename from website/translated_docs/hr-HR/contributing.md rename to polkadot-wiki/translated_docs/hr-HR/contributing.md diff --git a/website/translated_docs/hr-HR/contributors.md b/polkadot-wiki/translated_docs/hr-HR/contributors.md similarity index 100% rename from website/translated_docs/hr-HR/contributors.md rename to polkadot-wiki/translated_docs/hr-HR/contributors.md diff --git a/website/translated_docs/hr-HR/ens.md b/polkadot-wiki/translated_docs/hr-HR/ens.md similarity index 100% rename from website/translated_docs/hr-HR/ens.md rename to polkadot-wiki/translated_docs/hr-HR/ens.md diff --git a/website/translated_docs/hr-HR/faq.md b/polkadot-wiki/translated_docs/hr-HR/faq.md similarity index 100% rename from website/translated_docs/hr-HR/faq.md rename to polkadot-wiki/translated_docs/hr-HR/faq.md diff --git a/polkadot-wiki/translated_docs/hr-HR/getting-started.md b/polkadot-wiki/translated_docs/hr-HR/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/hr-HR/glossary.md b/polkadot-wiki/translated_docs/hr-HR/glossary.md similarity index 100% rename from website/translated_docs/hr-HR/glossary.md rename to polkadot-wiki/translated_docs/hr-HR/glossary.md diff --git a/polkadot-wiki/translated_docs/hr-HR/grants.md b/polkadot-wiki/translated_docs/hr-HR/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/hr-HR/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/hr-HR/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/hr-HR/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/hr-HR/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-bug-bounty.md diff --git a/website/translated_docs/hr-HR/kusama-claims.md b/polkadot-wiki/translated_docs/hr-HR/kusama-claims.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-claims.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-claims.md diff --git a/website/translated_docs/hr-HR/kusama-coc.md b/polkadot-wiki/translated_docs/hr-HR/kusama-coc.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-coc.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-coc.md diff --git a/website/translated_docs/hr-HR/kusama-community.md b/polkadot-wiki/translated_docs/hr-HR/kusama-community.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-community.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-community.md diff --git a/website/translated_docs/hr-HR/kusama-endpoints.md b/polkadot-wiki/translated_docs/hr-HR/kusama-endpoints.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-endpoints.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-endpoints.md diff --git a/website/translated_docs/hr-HR/kusama-faucet.md b/polkadot-wiki/translated_docs/hr-HR/kusama-faucet.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-faucet.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-faucet.md diff --git a/website/translated_docs/hr-HR/kusama-getting-started.md b/polkadot-wiki/translated_docs/hr-HR/kusama-getting-started.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-getting-started.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-getting-started.md diff --git a/website/translated_docs/hr-HR/kusama-index.md b/polkadot-wiki/translated_docs/hr-HR/kusama-index.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-index.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-index.md diff --git a/polkadot-wiki/translated_docs/hr-HR/kusama-ledger.md b/polkadot-wiki/translated_docs/hr-HR/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/hr-HR/kusama-parameters.md b/polkadot-wiki/translated_docs/hr-HR/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/hr-HR/kusama-social-recovery.md b/polkadot-wiki/translated_docs/hr-HR/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-social-recovery.md diff --git a/website/translated_docs/hr-HR/kusama-timeline.md b/polkadot-wiki/translated_docs/hr-HR/kusama-timeline.md similarity index 100% rename from website/translated_docs/hr-HR/kusama-timeline.md rename to polkadot-wiki/translated_docs/hr-HR/kusama-timeline.md diff --git a/website/translated_docs/hr-HR/learn-DOT.md b/polkadot-wiki/translated_docs/hr-HR/learn-DOT.md similarity index 100% rename from website/translated_docs/hr-HR/learn-DOT.md rename to polkadot-wiki/translated_docs/hr-HR/learn-DOT.md diff --git a/website/translated_docs/hr-HR/learn-account-generation.md b/polkadot-wiki/translated_docs/hr-HR/learn-account-generation.md similarity index 100% rename from website/translated_docs/hr-HR/learn-account-generation.md rename to polkadot-wiki/translated_docs/hr-HR/learn-account-generation.md diff --git a/website/translated_docs/hr-HR/learn-account-restore.md b/polkadot-wiki/translated_docs/hr-HR/learn-account-restore.md similarity index 100% rename from website/translated_docs/hr-HR/learn-account-restore.md rename to polkadot-wiki/translated_docs/hr-HR/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-accounts.md b/polkadot-wiki/translated_docs/hr-HR/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/hr-HR/learn-architecture.md b/polkadot-wiki/translated_docs/hr-HR/learn-architecture.md similarity index 100% rename from website/translated_docs/hr-HR/learn-architecture.md rename to polkadot-wiki/translated_docs/hr-HR/learn-architecture.md diff --git a/website/translated_docs/hr-HR/learn-auction.md b/polkadot-wiki/translated_docs/hr-HR/learn-auction.md similarity index 100% rename from website/translated_docs/hr-HR/learn-auction.md rename to polkadot-wiki/translated_docs/hr-HR/learn-auction.md diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-availability.md b/polkadot-wiki/translated_docs/hr-HR/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-balance-transfers.md b/polkadot-wiki/translated_docs/hr-HR/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-bridges.md b/polkadot-wiki/translated_docs/hr-HR/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/hr-HR/learn-collator.md b/polkadot-wiki/translated_docs/hr-HR/learn-collator.md similarity index 100% rename from website/translated_docs/hr-HR/learn-collator.md rename to polkadot-wiki/translated_docs/hr-HR/learn-collator.md diff --git a/website/translated_docs/hr-HR/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/hr-HR/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/hr-HR/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/hr-HR/learn-comparison-dfinity.md diff --git a/website/translated_docs/hr-HR/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/hr-HR/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/hr-HR/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/hr-HR/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/hr-HR/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/hr-HR/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/hr-HR/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/hr-HR/learn-comparisons-cosmos.md diff --git a/website/translated_docs/hr-HR/learn-comparisons.md b/polkadot-wiki/translated_docs/hr-HR/learn-comparisons.md similarity index 100% rename from website/translated_docs/hr-HR/learn-comparisons.md rename to polkadot-wiki/translated_docs/hr-HR/learn-comparisons.md diff --git a/website/translated_docs/hr-HR/learn-consensus.md b/polkadot-wiki/translated_docs/hr-HR/learn-consensus.md similarity index 100% rename from website/translated_docs/hr-HR/learn-consensus.md rename to polkadot-wiki/translated_docs/hr-HR/learn-consensus.md diff --git a/website/translated_docs/hr-HR/learn-crosschain.md b/polkadot-wiki/translated_docs/hr-HR/learn-crosschain.md similarity index 100% rename from website/translated_docs/hr-HR/learn-crosschain.md rename to polkadot-wiki/translated_docs/hr-HR/learn-crosschain.md diff --git a/website/translated_docs/hr-HR/learn-crowdloans.md b/polkadot-wiki/translated_docs/hr-HR/learn-crowdloans.md similarity index 100% rename from website/translated_docs/hr-HR/learn-crowdloans.md rename to polkadot-wiki/translated_docs/hr-HR/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-cryptography.md b/polkadot-wiki/translated_docs/hr-HR/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-governance.md b/polkadot-wiki/translated_docs/hr-HR/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/hr-HR/learn-identity.md b/polkadot-wiki/translated_docs/hr-HR/learn-identity.md similarity index 100% rename from website/translated_docs/hr-HR/learn-identity.md rename to polkadot-wiki/translated_docs/hr-HR/learn-identity.md diff --git a/website/translated_docs/hr-HR/learn-implementations.md b/polkadot-wiki/translated_docs/hr-HR/learn-implementations.md similarity index 100% rename from website/translated_docs/hr-HR/learn-implementations.md rename to polkadot-wiki/translated_docs/hr-HR/learn-implementations.md diff --git a/website/translated_docs/hr-HR/learn-implementers-guide.md b/polkadot-wiki/translated_docs/hr-HR/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/hr-HR/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/hr-HR/learn-implementers-guide.md diff --git a/website/translated_docs/hr-HR/learn-keys.md b/polkadot-wiki/translated_docs/hr-HR/learn-keys.md similarity index 100% rename from website/translated_docs/hr-HR/learn-keys.md rename to polkadot-wiki/translated_docs/hr-HR/learn-keys.md diff --git a/website/translated_docs/hr-HR/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/hr-HR/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/hr-HR/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/hr-HR/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/hr-HR/learn-launch.md b/polkadot-wiki/translated_docs/hr-HR/learn-launch.md similarity index 100% rename from website/translated_docs/hr-HR/learn-launch.md rename to polkadot-wiki/translated_docs/hr-HR/learn-launch.md diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-ledger.md b/polkadot-wiki/translated_docs/hr-HR/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/hr-HR/learn-nominator.md b/polkadot-wiki/translated_docs/hr-HR/learn-nominator.md similarity index 100% rename from website/translated_docs/hr-HR/learn-nominator.md rename to polkadot-wiki/translated_docs/hr-HR/learn-nominator.md diff --git a/website/translated_docs/hr-HR/learn-parachains.md b/polkadot-wiki/translated_docs/hr-HR/learn-parachains.md similarity index 100% rename from website/translated_docs/hr-HR/learn-parachains.md rename to polkadot-wiki/translated_docs/hr-HR/learn-parachains.md diff --git a/website/translated_docs/hr-HR/learn-parathreads.md b/polkadot-wiki/translated_docs/hr-HR/learn-parathreads.md similarity index 100% rename from website/translated_docs/hr-HR/learn-parathreads.md rename to polkadot-wiki/translated_docs/hr-HR/learn-parathreads.md diff --git a/website/translated_docs/hr-HR/learn-phragmen.md b/polkadot-wiki/translated_docs/hr-HR/learn-phragmen.md similarity index 100% rename from website/translated_docs/hr-HR/learn-phragmen.md rename to polkadot-wiki/translated_docs/hr-HR/learn-phragmen.md diff --git a/website/translated_docs/hr-HR/learn-polkadot-host.md b/polkadot-wiki/translated_docs/hr-HR/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/hr-HR/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/hr-HR/learn-polkadot-host.md diff --git a/website/translated_docs/hr-HR/learn-proxies.md b/polkadot-wiki/translated_docs/hr-HR/learn-proxies.md similarity index 100% rename from website/translated_docs/hr-HR/learn-proxies.md rename to polkadot-wiki/translated_docs/hr-HR/learn-proxies.md diff --git a/website/translated_docs/hr-HR/learn-randomness.md b/polkadot-wiki/translated_docs/hr-HR/learn-randomness.md similarity index 100% rename from website/translated_docs/hr-HR/learn-randomness.md rename to polkadot-wiki/translated_docs/hr-HR/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-registrar.md b/polkadot-wiki/translated_docs/hr-HR/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/hr-HR/learn-scams.md b/polkadot-wiki/translated_docs/hr-HR/learn-scams.md similarity index 100% rename from website/translated_docs/hr-HR/learn-scams.md rename to polkadot-wiki/translated_docs/hr-HR/learn-scams.md diff --git a/website/translated_docs/hr-HR/learn-security.md b/polkadot-wiki/translated_docs/hr-HR/learn-security.md similarity index 100% rename from website/translated_docs/hr-HR/learn-security.md rename to polkadot-wiki/translated_docs/hr-HR/learn-security.md diff --git a/website/translated_docs/hr-HR/learn-simple-payouts.md b/polkadot-wiki/translated_docs/hr-HR/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/hr-HR/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/hr-HR/learn-simple-payouts.md diff --git a/website/translated_docs/hr-HR/learn-spree.md b/polkadot-wiki/translated_docs/hr-HR/learn-spree.md similarity index 100% rename from website/translated_docs/hr-HR/learn-spree.md rename to polkadot-wiki/translated_docs/hr-HR/learn-spree.md diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-staking.md b/polkadot-wiki/translated_docs/hr-HR/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/hr-HR/learn-transaction-fees.md b/polkadot-wiki/translated_docs/hr-HR/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/hr-HR/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/hr-HR/learn-transaction-fees.md diff --git a/polkadot-wiki/translated_docs/hr-HR/learn-treasury.md b/polkadot-wiki/translated_docs/hr-HR/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/hr-HR/learn-validator.md b/polkadot-wiki/translated_docs/hr-HR/learn-validator.md similarity index 100% rename from website/translated_docs/hr-HR/learn-validator.md rename to polkadot-wiki/translated_docs/hr-HR/learn-validator.md diff --git a/website/translated_docs/hr-HR/learn-wasm.md b/polkadot-wiki/translated_docs/hr-HR/learn-wasm.md similarity index 100% rename from website/translated_docs/hr-HR/learn-wasm.md rename to polkadot-wiki/translated_docs/hr-HR/learn-wasm.md diff --git a/website/translated_docs/hr-HR/maintain-errors.md b/polkadot-wiki/translated_docs/hr-HR/maintain-errors.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-errors.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-errors.md diff --git a/website/translated_docs/hr-HR/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-democracy.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/hr-HR/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/hr-HR/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/hr-HR/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/hr-HR/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-guides-validator-payout.md diff --git a/website/translated_docs/hi-IN/maintain-index.md b/polkadot-wiki/translated_docs/hr-HR/maintain-index.md similarity index 100% rename from website/translated_docs/hi-IN/maintain-index.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-index.md diff --git a/website/translated_docs/hr-HR/maintain-networks.md b/polkadot-wiki/translated_docs/hr-HR/maintain-networks.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-networks.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-networks.md diff --git a/polkadot-wiki/translated_docs/hr-HR/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/hr-HR/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/id-ID/maintain-sync.md b/polkadot-wiki/translated_docs/hr-HR/maintain-sync.md similarity index 100% rename from website/translated_docs/id-ID/maintain-sync.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-sync.md diff --git a/website/translated_docs/hr-HR/maintain-wss.md b/polkadot-wiki/translated_docs/hr-HR/maintain-wss.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-wss.md rename to polkadot-wiki/translated_docs/hr-HR/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/hr-HR/redenomination.md b/polkadot-wiki/translated_docs/hr-HR/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/hr-HR/research.md b/polkadot-wiki/translated_docs/hr-HR/research.md similarity index 100% rename from website/translated_docs/hr-HR/research.md rename to polkadot-wiki/translated_docs/hr-HR/research.md diff --git a/polkadot-wiki/translated_docs/hr-HR/thousand-validators.md b/polkadot-wiki/translated_docs/hr-HR/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/hr-HR/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/id-ID/ambassadors.md b/polkadot-wiki/translated_docs/id-ID/ambassadors.md similarity index 100% rename from website/translated_docs/id-ID/ambassadors.md rename to polkadot-wiki/translated_docs/id-ID/ambassadors.md diff --git a/website/translated_docs/id-ID/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/id-ID/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/id-ID/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/id-ID/build-build-with-polkadot.md diff --git a/website/translated_docs/id-ID/build-cumulus.md b/polkadot-wiki/translated_docs/id-ID/build-cumulus.md similarity index 100% rename from website/translated_docs/id-ID/build-cumulus.md rename to polkadot-wiki/translated_docs/id-ID/build-cumulus.md diff --git a/polkadot-wiki/translated_docs/id-ID/build-deploy-parachains.md b/polkadot-wiki/translated_docs/id-ID/build-deploy-parachains.md new file mode 100644 index 000000000000..bd76e206eef9 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/build-deploy-parachains.md @@ -0,0 +1,93 @@ +--- +id: build-deploy-parachains +title: Cara melihat dan menggunakan parachains +sidebar_label: Cara melihat dan menggunakan parachains +--- + +Panduan ini telah diperbarui untuk bekerja dengan testnet Alexander. + +## Cara melihat parachains + +On the [Polkadot UI](https://polkadot.js.org/apps/#/explorer) navigate to the `Chain State` tab. Select the `parachains` module and the `parachains()` then hit the `+` button. It will return an array of the currently active parachains. + +## Cara menyebarkan parachain Adder + +**You will need to have the minimum deposit needed to create a referendum. Currently this minimum is 5 DOT.** + +The `adder` parachain is a simple parachain that will keep a value in storage and add to this value as messages are sent to it. It can be found in the Polkadot repository under the `test-parachains` folder. + +> A slightly out-of-date video version of this guide presented by Adrian Brink is available [here](https://www.youtube.com/watch?v=pDqkzvA4C0E). When the two guides diverge, please refer to this written text as definitive and updated. + +### Membangun kode + +Langkah pertama adalah mengunduh secara lokal kode Polkadot dan beralih ke cabang `v0.4`. + +```bash +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git checkout v0.4 +``` + +Sekarang pastikan Anda telah menginstal Rust. + +```bash +curl https://sh.rustup.rs -sSf | sh +sudo apt install make clang pkg-config libssl-dev +rustup update +``` + +Now navigate to the `test-parachains` folder in the Polkadot code repository and run the build script. + +```bash +cd test-parachains +./build.sh +``` + +This will create the Wasm executable of the simple `adder` parachain contained in this folder. This parachain will simply add messages that are sent to it. The Wasm executable will output into the `parachains/test/res/adder.wasm` path so make sure you are able to find it there. + +You will need to build and run the collator node in order to get the genesis state of this parachain. + +Navigasikan ke direktori `test-parachains / adder / collator` dan jalankan perintah `build` dan `run`. + +```bash +cargo build +cargo run +[ctrl-c] +``` + +Jangan ragu untuk menghentikan node collator segera. Anda akan mendapatkan beberapa output yang terlihat seperti ini: + +``` +Starting adder collator with genesis: +Dec: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 27, 77, 3, 221, 140, 1, 241, 4, 145, 67, +207, 156, 76, 129, 126, 75, 22, 127, 29, 27, 131, 229, 198, 240, 241, 13, 137, 186, 30, 123, 206] +Hex: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000011b4d03dd8c01f1049143cf9c4c817e4b167f1d1b83e5c6f0f10d89ba1e7bce +``` + +The important information is the hex string. This is your genesis state and you will need to save it for the next steps. + +### Menjalankan parachain + +Go to [Polkadot UI](https://polkadot.js.org/apps/#/extrinsics) on the `Extrinsics` tab. Select the account you wish to deploy the parachain from. You will need to create a referendum to deploy the parachain. + +Click on `democracy` -> `propose(proposal,value)` -> `parachains` -> `registerParachain(id,code,initial_head_data)`. + +In the `id` input enter in the id of the parachain. In the case of the simple adder it will be `100`. In the `code` field click on the page button and then upload the `adder.wasm` binary that was compiled from before. In the `initial_head_data` we will copy and paste the hex data that we got from running the collator node. In the `value` field you will need to input the minimum required value for creating a referendum. At the time of writing this is _5 DOT_ on the Alexander testnet. + +![mendaftarkan parachain](assets/parachain/register.png) + +If you navigate to the `Democracy` tab you will be able to see your proposal in the proposals section. + +Once you wait for the proposal to become a referendum you will be able to vote `Nay` or `Aye` on it. Assumably, you will vote Aye as this will be a vote for the deployment of your parachain. + +![referendum parachain](assets/parachain/referendum.png) + +After the voting period of your referendum goes through you will be able to query the state of your parachain. + +You can go to the `Chain State` tab and by querying the `parachains` state you should be able to see some information on your parachain. + +![info parachain](assets/parachain/info.png) + +### Berinteraksi dengan parachain + +_Segera hadir_ diff --git a/website/translated_docs/id-ID/build-dev-roadmap.md b/polkadot-wiki/translated_docs/id-ID/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/id-ID/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/id-ID/build-dev-roadmap.md diff --git a/website/translated_docs/id-ID/build-examples-index.md b/polkadot-wiki/translated_docs/id-ID/build-examples-index.md similarity index 100% rename from website/translated_docs/id-ID/build-examples-index.md rename to polkadot-wiki/translated_docs/id-ID/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/id-ID/build-exchange-integration.md b/polkadot-wiki/translated_docs/id-ID/build-exchange-integration.md new file mode 100644 index 000000000000..dddd3a779fac --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. Tracking the chain head + +Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). + +That will give you a stream of hashes of the most recent finalised headers. + +When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. + +If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. + +## 2. Decoding blocks + +You will need to decode blocks from the basic data into useful fields. + +All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. + +For Genesis Polkadot, the header format is a five-field structure: + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +It also relies on `Extrinsic`. An _extrinsic_ is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. + +The metadata itself is provided encoded in SCALE. Its format is: + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. + +Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various _modules_. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, _extrinsics_), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. Working with SS58 and account addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) _AccountId_. This is simply the public key for the x25519 cryptography used by Substrate. + +However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this _index_ to identify the account. This index is much smaller than the 32-byte _AccountId_, and can usually be encoded in just a couple of bytes. + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: + +`0x00 ` + +**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. + +Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. + +Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. + +### Looking up an index + +Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. + +The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. + +For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. + +This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. + +This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. + +Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. + +## 4. Working with balances + +In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. + +NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. + +The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10\*\*12). For completeness, The exact denominations of the Polkadot currency are: + +| Balance value | Name | +| ------------- | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### Transferring balances + +To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. + +In general, Polkadot's transactions are encoded as _signed_ `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. + +The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. + +NOTE: The nonce retrieved from storage does not take into account _pending_ transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. + +The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. + +The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. + +Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. + +Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +The `function` _in this case_ (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. + +The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. + +### Submitting and checking transactions + +Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. + +This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. + +The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. + +## Conclusion + +This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. + +If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). + +_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/id-ID/build-hackathon.md b/polkadot-wiki/translated_docs/id-ID/build-hackathon.md similarity index 100% rename from website/translated_docs/id-ID/build-hackathon.md rename to polkadot-wiki/translated_docs/id-ID/build-hackathon.md diff --git a/website/translated_docs/id-ID/build-index.md b/polkadot-wiki/translated_docs/id-ID/build-index.md similarity index 100% rename from website/translated_docs/id-ID/build-index.md rename to polkadot-wiki/translated_docs/id-ID/build-index.md diff --git a/website/translated_docs/id-ID/build-integration.md b/polkadot-wiki/translated_docs/id-ID/build-integration.md similarity index 100% rename from website/translated_docs/id-ID/build-integration.md rename to polkadot-wiki/translated_docs/id-ID/build-integration.md diff --git a/website/translated_docs/id-ID/build-node-interaction.md b/polkadot-wiki/translated_docs/id-ID/build-node-interaction.md similarity index 100% rename from website/translated_docs/id-ID/build-node-interaction.md rename to polkadot-wiki/translated_docs/id-ID/build-node-interaction.md diff --git a/website/translated_docs/id-ID/build-node-management.md b/polkadot-wiki/translated_docs/id-ID/build-node-management.md similarity index 100% rename from website/translated_docs/id-ID/build-node-management.md rename to polkadot-wiki/translated_docs/id-ID/build-node-management.md diff --git a/website/translated_docs/id-ID/build-oracle.md b/polkadot-wiki/translated_docs/id-ID/build-oracle.md similarity index 100% rename from website/translated_docs/id-ID/build-oracle.md rename to polkadot-wiki/translated_docs/id-ID/build-oracle.md diff --git a/website/translated_docs/id-ID/build-parachains-rococo.md b/polkadot-wiki/translated_docs/id-ID/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/id-ID/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/id-ID/build-parachains-rococo.md diff --git a/website/translated_docs/id-ID/build-pdk.md b/polkadot-wiki/translated_docs/id-ID/build-pdk.md similarity index 100% rename from website/translated_docs/id-ID/build-pdk.md rename to polkadot-wiki/translated_docs/id-ID/build-pdk.md diff --git a/polkadot-wiki/translated_docs/id-ID/build-protocol-info.md b/polkadot-wiki/translated_docs/id-ID/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/polkadot-wiki/translated_docs/id-ID/build-smart-contracts.md b/polkadot-wiki/translated_docs/id-ID/build-smart-contracts.md new file mode 100644 index 000000000000..59aacad22054 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/build-smart-contracts.md @@ -0,0 +1,57 @@ +--- +id: build-smart-contracts +title: Kontrak pintar +sidebar_label: Kontrak pintar +--- + +The Polkadot Relay Chain will not support smart contracts natively. However, parachains on Polkadot will support smart contracts. There are already announced projects such as [Edgeware](https://edgewa.re), and thanks to the Substrate built-in [contract pallet](https://substrate.dev/rustdocs/latest/pallet_contracts/index.html), it is likely that more parachains will support this feature. + +Additionally, there is the EVM pallet which lets a parachain implement the Ethereum Virtual Machine, thereby supporting almost direct ports of Ethereum contracts. Some of the projects using this approach are [Edgeware](https://edgewa.re), [Moonbeam](https://moonbeam.network/) and [Frontier](https://github.com/paritytech/frontier). + +A video version of the recap of the smart contract situation on Polkadot and Kusama is available [here](https://www.youtube.com/watch?v=fKHkFBXaUxQ). + +## Sumber daya + +Here is the list of current resources available to developers who want to get started writing smart contracts to deploy on parachains based on Substrate. + +- [Edgeware Contracts](https://contracts.edgewa.re) - Edgeware's documentation on Smart Contracts +- [ink!](https://github.com/paritytech/ink) - Parity's ink to write smart contracts. +- [Substrate Contracts Workshop](https://substrate.dev/substrate-contracts-workshop/#/) - Walks you through the basics of writing and deploying an ERC20 token using `ink!`. + +## Contoh + +Collected below are some community examples of smart contracts in `ink!`. Are you working on a smart contract example? Ask us to add it to this page! + +- [ Dimiliki ](https://github.com/JesseAbram/foRust/) - Port kontrak OpenZeppelin `Ownable`. + +## Storage Rent + +Storage rent limits the footprint that a contract can have on the blockchain's storage. + +A contract deployed to the chain produces a code hash from which new instances of the chain can be created, but there is currently no rent applied to the code hash itself. The rent applies only to instances of this contract which have their own _contract accounts_. Deploying a code hash currently has a one-time byte-fee applied to the transaction, but no recurring cost. + +An account of a contract instance is charged proportionally to the amount of storage its account uses. When a contract's balance goes below a defined limit, the contract's account is turned into a "tombstone" (a hash of the contract's current state) and its storage is cleaned up. A tombstone contract can be restored by providing the data that was cleaned up when it became a tombstone as well as any additional funds needed to keep the contract alive. This fee will retroactively apply to missed rent periods. + +Block producers or regular users of the chain can "poke" a smart contract if they think it ran out of funds for rent. This will initiate the cleanup process and the _poker_ will get a finder's fee. + +## What is the difference between developing a smart contract versus a parachain? + +### Lapisan Abstraksi + +When you write a smart contract you are creating the instructions that will be deployed and associated to a specific chain address. + +In comparison, a runtime module is the entire logic of a chain's state transitions (what's called a state transition function). + +Smart contracts must consciously implement upgradeability while parachains will have the ability to swap out their code entirely through a root command or via the governance pallet. + +When you build a smart contract, it will eventually be deployed to a target chain with its own environment. Parachains allow the developer to declare the environment of their own chain, even allowing others to write smart contracts for it. + +### Biaya Gas + +Smart contracts must find a way to limit their own execution, or else full nodes are vulnerable to DOS attacks. An infinite loop in a smart contract, for example, could consume the computational resources of an entire chain, preventing others from using it. The [halting problem](https://en.wikipedia.org/wiki/Halting_problem) shows that with a powerful enough language, it is impossible to know ahead of time whether or not a program will ever cease execution. Some platforms, such as Bitcoin, get around this constraint by providing a very restricted scripting language. Others, such as Ethereum, "charge" the smart contract "gas" for the rights to execute their code. If a smart contract does get into a state where execution will never halt, it eventually runs out of gas, ceases execution, and any state transition that would have been made by the smart contract is rolled back. + +Parachains can implement arbitrarily powerful programming languages and also contain no notion of gas for their own native logic. This means that some functionality is easier to implement for the developer, but it also means there are some constructs, such as a loop without a terminating condition, which should _never_ be implemented. Leaving certain logic, such as complex loops that could possibly run indefinitely, to a non-smart contract layer, or even trying to eliminate it entirely, will often be a wiser choice. + +## Resources + +- [When should I build a Substrate runtime versus a Substrate smart contract](https://stackoverflow.com/a/56041305) - From a technical standpoint answers the question of when a developer might choose to develop a runtime versus a smart contract. diff --git a/website/translated_docs/id-ID/build-tools-index.md b/polkadot-wiki/translated_docs/id-ID/build-tools-index.md similarity index 100% rename from website/translated_docs/id-ID/build-tools-index.md rename to polkadot-wiki/translated_docs/id-ID/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/id-ID/build-transaction-construction.md b/polkadot-wiki/translated_docs/id-ID/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/id-ID/build-wallets.md b/polkadot-wiki/translated_docs/id-ID/build-wallets.md similarity index 100% rename from website/translated_docs/id-ID/build-wallets.md rename to polkadot-wiki/translated_docs/id-ID/build-wallets.md diff --git a/polkadot-wiki/translated_docs/id-ID/claims.md b/polkadot-wiki/translated_docs/id-ID/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/id-ID/community.md b/polkadot-wiki/translated_docs/id-ID/community.md similarity index 100% rename from website/translated_docs/id-ID/community.md rename to polkadot-wiki/translated_docs/id-ID/community.md diff --git a/polkadot-wiki/translated_docs/id-ID/contributing.md b/polkadot-wiki/translated_docs/id-ID/contributing.md new file mode 100644 index 000000000000..f594a03feef7 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/contributing.md @@ -0,0 +1,45 @@ +--- +id: contributing +title: Berkontribusi +sidebar_label: Berkontribusi +--- + +The wiki was started and is maintained by the Web3 Foundation. It is an open source project and aims to be the most extensive resource of knowledge on Polkadot and the Polkadot ecosystem. A large part of the material currently focuses on Polkadot directly but it is not opposed to covering informational material for community projects. Please do not try to pull request any marketing material as this will be rejected. + +Pull requests, discussions, and contributions from the community are encouraged. Active community members who demonstrate a record of good contributions may be given write access to the repository. Otherwise, Web3 Foundation holds the administrative position and final say on the content that is included. Specifically the Technical Education team at the foundation are most directly involved. + +> There is video guide on how to contribute to the wiki [here](https://www.youtube.com/watch?v=6i55KOcy7B0). + +## Bagaimana cara Berkontribusi + +Contributing to the wiki is easy with a GitHub account. Every page is a MarkDown file, which is a [very easy to learn](https://guides.github.com/features/mastering-markdown/) syntax extension to plain text that makes creating links, rendering images, and nice-looking formatting simple. + +Each page has an "Edit" button in the top right corner of the content. By clicking this button you are taken to the GitHub sign in page, where you can either log in or create an account. + +![](assets/edit_button.png) + +Once logged in, you'll be taken to the GitHub text editor in which you can make your edits directly. When you've completed your changes, you can add any specific details on what was changed and commit to a new branch to create a new Pull Request to the repository. From there one of the maintainers will either merge it in or request changes very soon. + +![](assets/contributing.png) ![](assets/creating-pull-request.png) + +Remember that after you click "Propose Changes", you must also click on "Create Pull Request" on the next page. + +![](assets/creating-pull-request-2.png) + +## Aturan + +There are a few basic ground-rules for contributors: + +1. ** Tidak ada `- memaksa` mendorong ** atau memodifikasi riwayat Git dengan cara apa pun. +2. Pull requests are preferred to issues, especially for small changes such as typos. Issues should be used for generic or broad-based changes or missing content. +3. Only use **non-master branches**. +4. **Significant modifications**, even by contributors, ought to be subject to a **pull request** to solicit feedback from other contributors. +5. Pull requests to solicit feedback are _encouraged_ for any other non-trivial contribution but left to the discretion of the contributor. +6. Contributors should attempt to adhere to the prevailing MarkDown style, language, and layout. +7. Correct grammar should be used at all times. Pull requests with typos will not be merged until fixed. +8. Care should be taken to remain as objective and informative as possible. There should be no editorializing, and external bias should not be present. +9. We use a plugin called Prettier to standardize the style across documents. You can run this on your local copy with `npx run prettier --save`, but for simplicity we also have a bot which runs this for us in your PRs. + +## Heritage + +This document was based on the Level contribution guidelines located here: [https://github.com/Level/community/blob/master/CONTRIBUTING.md](https://github.com/Level/community/blob/master/CONTRIBUTING.md) diff --git a/website/translated_docs/id-ID/contributors.md b/polkadot-wiki/translated_docs/id-ID/contributors.md similarity index 100% rename from website/translated_docs/id-ID/contributors.md rename to polkadot-wiki/translated_docs/id-ID/contributors.md diff --git a/website/translated_docs/id-ID/ens.md b/polkadot-wiki/translated_docs/id-ID/ens.md similarity index 100% rename from website/translated_docs/id-ID/ens.md rename to polkadot-wiki/translated_docs/id-ID/ens.md diff --git a/website/translated_docs/id-ID/faq.md b/polkadot-wiki/translated_docs/id-ID/faq.md similarity index 100% rename from website/translated_docs/id-ID/faq.md rename to polkadot-wiki/translated_docs/id-ID/faq.md diff --git a/polkadot-wiki/translated_docs/id-ID/getting-started.md b/polkadot-wiki/translated_docs/id-ID/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/id-ID/glossary.md b/polkadot-wiki/translated_docs/id-ID/glossary.md similarity index 100% rename from website/translated_docs/id-ID/glossary.md rename to polkadot-wiki/translated_docs/id-ID/glossary.md diff --git a/polkadot-wiki/translated_docs/id-ID/grants.md b/polkadot-wiki/translated_docs/id-ID/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/id-ID/index.md b/polkadot-wiki/translated_docs/id-ID/index.md similarity index 100% rename from website/translated_docs/id-ID/index.md rename to polkadot-wiki/translated_docs/id-ID/index.md diff --git a/polkadot-wiki/translated_docs/id-ID/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/id-ID/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/id-ID/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/id-ID/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/id-ID/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/id-ID/kusama-bug-bounty.md diff --git a/website/translated_docs/id-ID/kusama-claims.md b/polkadot-wiki/translated_docs/id-ID/kusama-claims.md similarity index 100% rename from website/translated_docs/id-ID/kusama-claims.md rename to polkadot-wiki/translated_docs/id-ID/kusama-claims.md diff --git a/website/translated_docs/id-ID/kusama-coc.md b/polkadot-wiki/translated_docs/id-ID/kusama-coc.md similarity index 100% rename from website/translated_docs/id-ID/kusama-coc.md rename to polkadot-wiki/translated_docs/id-ID/kusama-coc.md diff --git a/website/translated_docs/id-ID/kusama-community.md b/polkadot-wiki/translated_docs/id-ID/kusama-community.md similarity index 100% rename from website/translated_docs/id-ID/kusama-community.md rename to polkadot-wiki/translated_docs/id-ID/kusama-community.md diff --git a/website/translated_docs/id-ID/kusama-endpoints.md b/polkadot-wiki/translated_docs/id-ID/kusama-endpoints.md similarity index 100% rename from website/translated_docs/id-ID/kusama-endpoints.md rename to polkadot-wiki/translated_docs/id-ID/kusama-endpoints.md diff --git a/website/translated_docs/id-ID/kusama-faucet.md b/polkadot-wiki/translated_docs/id-ID/kusama-faucet.md similarity index 100% rename from website/translated_docs/id-ID/kusama-faucet.md rename to polkadot-wiki/translated_docs/id-ID/kusama-faucet.md diff --git a/website/translated_docs/id-ID/kusama-getting-started.md b/polkadot-wiki/translated_docs/id-ID/kusama-getting-started.md similarity index 100% rename from website/translated_docs/id-ID/kusama-getting-started.md rename to polkadot-wiki/translated_docs/id-ID/kusama-getting-started.md diff --git a/website/translated_docs/id-ID/kusama-index.md b/polkadot-wiki/translated_docs/id-ID/kusama-index.md similarity index 100% rename from website/translated_docs/id-ID/kusama-index.md rename to polkadot-wiki/translated_docs/id-ID/kusama-index.md diff --git a/polkadot-wiki/translated_docs/id-ID/kusama-ledger.md b/polkadot-wiki/translated_docs/id-ID/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/id-ID/kusama-parameters.md b/polkadot-wiki/translated_docs/id-ID/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/id-ID/kusama-social-recovery.md b/polkadot-wiki/translated_docs/id-ID/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/id-ID/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/id-ID/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/id-ID/kusama-time-periods.md b/polkadot-wiki/translated_docs/id-ID/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/id-ID/kusama-timeline.md b/polkadot-wiki/translated_docs/id-ID/kusama-timeline.md similarity index 100% rename from website/translated_docs/id-ID/kusama-timeline.md rename to polkadot-wiki/translated_docs/id-ID/kusama-timeline.md diff --git a/website/translated_docs/id-ID/learn-DOT.md b/polkadot-wiki/translated_docs/id-ID/learn-DOT.md similarity index 100% rename from website/translated_docs/id-ID/learn-DOT.md rename to polkadot-wiki/translated_docs/id-ID/learn-DOT.md diff --git a/website/translated_docs/id-ID/learn-PRE.md b/polkadot-wiki/translated_docs/id-ID/learn-PRE.md similarity index 100% rename from website/translated_docs/id-ID/learn-PRE.md rename to polkadot-wiki/translated_docs/id-ID/learn-PRE.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-UI.md b/polkadot-wiki/translated_docs/id-ID/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/id-ID/learn-account-generation.md b/polkadot-wiki/translated_docs/id-ID/learn-account-generation.md similarity index 100% rename from website/translated_docs/id-ID/learn-account-generation.md rename to polkadot-wiki/translated_docs/id-ID/learn-account-generation.md diff --git a/website/translated_docs/id-ID/learn-account-restore.md b/polkadot-wiki/translated_docs/id-ID/learn-account-restore.md similarity index 100% rename from website/translated_docs/id-ID/learn-account-restore.md rename to polkadot-wiki/translated_docs/id-ID/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-accounts.md b/polkadot-wiki/translated_docs/id-ID/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/id-ID/learn-architecture.md b/polkadot-wiki/translated_docs/id-ID/learn-architecture.md similarity index 100% rename from website/translated_docs/id-ID/learn-architecture.md rename to polkadot-wiki/translated_docs/id-ID/learn-architecture.md diff --git a/website/translated_docs/id-ID/learn-auction.md b/polkadot-wiki/translated_docs/id-ID/learn-auction.md similarity index 100% rename from website/translated_docs/id-ID/learn-auction.md rename to polkadot-wiki/translated_docs/id-ID/learn-auction.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-availability.md b/polkadot-wiki/translated_docs/id-ID/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/id-ID/learn-balance-transfers.md b/polkadot-wiki/translated_docs/id-ID/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/id-ID/learn-bridges.md b/polkadot-wiki/translated_docs/id-ID/learn-bridges.md new file mode 100644 index 000000000000..e8cbbdcb522e --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Jembatan +sidebar_label: Jembatan +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/id-ID/learn-collator.md b/polkadot-wiki/translated_docs/id-ID/learn-collator.md similarity index 100% rename from website/translated_docs/id-ID/learn-collator.md rename to polkadot-wiki/translated_docs/id-ID/learn-collator.md diff --git a/website/translated_docs/id-ID/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/id-ID/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/id-ID/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/id-ID/learn-comparison-dfinity.md diff --git a/website/translated_docs/id-ID/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/id-ID/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/id-ID/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/id-ID/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/id-ID/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/id-ID/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/id-ID/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/id-ID/learn-comparisons-cosmos.md diff --git a/website/translated_docs/id-ID/learn-comparisons.md b/polkadot-wiki/translated_docs/id-ID/learn-comparisons.md similarity index 100% rename from website/translated_docs/id-ID/learn-comparisons.md rename to polkadot-wiki/translated_docs/id-ID/learn-comparisons.md diff --git a/website/translated_docs/id-ID/learn-consensus.md b/polkadot-wiki/translated_docs/id-ID/learn-consensus.md similarity index 100% rename from website/translated_docs/id-ID/learn-consensus.md rename to polkadot-wiki/translated_docs/id-ID/learn-consensus.md diff --git a/website/translated_docs/id-ID/learn-crosschain.md b/polkadot-wiki/translated_docs/id-ID/learn-crosschain.md similarity index 100% rename from website/translated_docs/id-ID/learn-crosschain.md rename to polkadot-wiki/translated_docs/id-ID/learn-crosschain.md diff --git a/website/translated_docs/id-ID/learn-crowdloans.md b/polkadot-wiki/translated_docs/id-ID/learn-crowdloans.md similarity index 100% rename from website/translated_docs/id-ID/learn-crowdloans.md rename to polkadot-wiki/translated_docs/id-ID/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-cryptography.md b/polkadot-wiki/translated_docs/id-ID/learn-cryptography.md new file mode 100644 index 000000000000..fdd7b80073cd --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Penjelasan Kriptografi +sidebar_label: Penjelasan Kriptografi +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Algoritma Hashing + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs dan Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/id-ID/learn-faq.md b/polkadot-wiki/translated_docs/id-ID/learn-faq.md similarity index 100% rename from website/translated_docs/id-ID/learn-faq.md rename to polkadot-wiki/translated_docs/id-ID/learn-faq.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-governance.md b/polkadot-wiki/translated_docs/id-ID/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/id-ID/learn-identity.md b/polkadot-wiki/translated_docs/id-ID/learn-identity.md similarity index 100% rename from website/translated_docs/id-ID/learn-identity.md rename to polkadot-wiki/translated_docs/id-ID/learn-identity.md diff --git a/website/translated_docs/id-ID/learn-implementations.md b/polkadot-wiki/translated_docs/id-ID/learn-implementations.md similarity index 100% rename from website/translated_docs/id-ID/learn-implementations.md rename to polkadot-wiki/translated_docs/id-ID/learn-implementations.md diff --git a/website/translated_docs/id-ID/learn-implementers-guide.md b/polkadot-wiki/translated_docs/id-ID/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/id-ID/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/id-ID/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-interchain.md b/polkadot-wiki/translated_docs/id-ID/learn-interchain.md new file mode 100644 index 000000000000..2677ee91d812 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. + +The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. + +## Overview + +- Interchain messages will _not_ go on to the relay chain. +- Interchain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. + +## Example + +A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. + +When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/id-ID/learn-introduction.md b/polkadot-wiki/translated_docs/id-ID/learn-introduction.md similarity index 100% rename from website/translated_docs/id-ID/learn-introduction.md rename to polkadot-wiki/translated_docs/id-ID/learn-introduction.md diff --git a/website/translated_docs/id-ID/learn-keys.md b/polkadot-wiki/translated_docs/id-ID/learn-keys.md similarity index 100% rename from website/translated_docs/id-ID/learn-keys.md rename to polkadot-wiki/translated_docs/id-ID/learn-keys.md diff --git a/website/translated_docs/id-ID/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/id-ID/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/id-ID/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/id-ID/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/id-ID/learn-launch.md b/polkadot-wiki/translated_docs/id-ID/learn-launch.md similarity index 100% rename from website/translated_docs/id-ID/learn-launch.md rename to polkadot-wiki/translated_docs/id-ID/learn-launch.md diff --git a/website/translated_docs/id-ID/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/id-ID/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/id-ID/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/id-ID/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-ledger.md b/polkadot-wiki/translated_docs/id-ID/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/id-ID/learn-nominator.md b/polkadot-wiki/translated_docs/id-ID/learn-nominator.md similarity index 100% rename from website/translated_docs/id-ID/learn-nominator.md rename to polkadot-wiki/translated_docs/id-ID/learn-nominator.md diff --git a/website/translated_docs/id-ID/learn-parachains.md b/polkadot-wiki/translated_docs/id-ID/learn-parachains.md similarity index 100% rename from website/translated_docs/id-ID/learn-parachains.md rename to polkadot-wiki/translated_docs/id-ID/learn-parachains.md diff --git a/website/translated_docs/id-ID/learn-parathreads.md b/polkadot-wiki/translated_docs/id-ID/learn-parathreads.md similarity index 100% rename from website/translated_docs/id-ID/learn-parathreads.md rename to polkadot-wiki/translated_docs/id-ID/learn-parathreads.md diff --git a/website/translated_docs/id-ID/learn-phragmen.md b/polkadot-wiki/translated_docs/id-ID/learn-phragmen.md similarity index 100% rename from website/translated_docs/id-ID/learn-phragmen.md rename to polkadot-wiki/translated_docs/id-ID/learn-phragmen.md diff --git a/website/translated_docs/id-ID/learn-polkadot-host.md b/polkadot-wiki/translated_docs/id-ID/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/id-ID/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/id-ID/learn-polkadot-host.md diff --git a/website/translated_docs/id-ID/learn-proxies.md b/polkadot-wiki/translated_docs/id-ID/learn-proxies.md similarity index 100% rename from website/translated_docs/id-ID/learn-proxies.md rename to polkadot-wiki/translated_docs/id-ID/learn-proxies.md diff --git a/website/translated_docs/id-ID/learn-randomness.md b/polkadot-wiki/translated_docs/id-ID/learn-randomness.md similarity index 100% rename from website/translated_docs/id-ID/learn-randomness.md rename to polkadot-wiki/translated_docs/id-ID/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-registrar.md b/polkadot-wiki/translated_docs/id-ID/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/id-ID/learn-relevant-links.md b/polkadot-wiki/translated_docs/id-ID/learn-relevant-links.md similarity index 100% rename from website/translated_docs/id-ID/learn-relevant-links.md rename to polkadot-wiki/translated_docs/id-ID/learn-relevant-links.md diff --git a/website/translated_docs/id-ID/learn-roadmap.md b/polkadot-wiki/translated_docs/id-ID/learn-roadmap.md similarity index 100% rename from website/translated_docs/id-ID/learn-roadmap.md rename to polkadot-wiki/translated_docs/id-ID/learn-roadmap.md diff --git a/website/translated_docs/id-ID/learn-scams.md b/polkadot-wiki/translated_docs/id-ID/learn-scams.md similarity index 100% rename from website/translated_docs/id-ID/learn-scams.md rename to polkadot-wiki/translated_docs/id-ID/learn-scams.md diff --git a/website/translated_docs/id-ID/learn-security.md b/polkadot-wiki/translated_docs/id-ID/learn-security.md similarity index 100% rename from website/translated_docs/id-ID/learn-security.md rename to polkadot-wiki/translated_docs/id-ID/learn-security.md diff --git a/website/translated_docs/id-ID/learn-simple-payouts.md b/polkadot-wiki/translated_docs/id-ID/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/id-ID/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/id-ID/learn-simple-payouts.md diff --git a/website/translated_docs/id-ID/learn-spree.md b/polkadot-wiki/translated_docs/id-ID/learn-spree.md similarity index 100% rename from website/translated_docs/id-ID/learn-spree.md rename to polkadot-wiki/translated_docs/id-ID/learn-spree.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-staking.md b/polkadot-wiki/translated_docs/id-ID/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/id-ID/learn-transaction-fees.md b/polkadot-wiki/translated_docs/id-ID/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/id-ID/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/id-ID/learn-transaction-fees.md diff --git a/website/translated_docs/id-ID/learn-transactions.md b/polkadot-wiki/translated_docs/id-ID/learn-transactions.md similarity index 100% rename from website/translated_docs/id-ID/learn-transactions.md rename to polkadot-wiki/translated_docs/id-ID/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/id-ID/learn-treasury.md b/polkadot-wiki/translated_docs/id-ID/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/id-ID/learn-validator.md b/polkadot-wiki/translated_docs/id-ID/learn-validator.md similarity index 100% rename from website/translated_docs/id-ID/learn-validator.md rename to polkadot-wiki/translated_docs/id-ID/learn-validator.md diff --git a/website/translated_docs/id-ID/learn-wasm.md b/polkadot-wiki/translated_docs/id-ID/learn-wasm.md similarity index 100% rename from website/translated_docs/id-ID/learn-wasm.md rename to polkadot-wiki/translated_docs/id-ID/learn-wasm.md diff --git a/website/translated_docs/id-ID/maintain-collator.md b/polkadot-wiki/translated_docs/id-ID/maintain-collator.md similarity index 100% rename from website/translated_docs/id-ID/maintain-collator.md rename to polkadot-wiki/translated_docs/id-ID/maintain-collator.md diff --git a/website/translated_docs/id-ID/maintain-errors.md b/polkadot-wiki/translated_docs/id-ID/maintain-errors.md similarity index 100% rename from website/translated_docs/id-ID/maintain-errors.md rename to polkadot-wiki/translated_docs/id-ID/maintain-errors.md diff --git a/website/translated_docs/id-ID/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-democracy.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/id-ID/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/id-ID/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/id-ID/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/id-ID/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/id-ID/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/id-ID/maintain-guides-validator-payout.md diff --git a/website/translated_docs/id-ID/maintain-index.md b/polkadot-wiki/translated_docs/id-ID/maintain-index.md similarity index 100% rename from website/translated_docs/id-ID/maintain-index.md rename to polkadot-wiki/translated_docs/id-ID/maintain-index.md diff --git a/website/translated_docs/id-ID/maintain-networks.md b/polkadot-wiki/translated_docs/id-ID/maintain-networks.md similarity index 100% rename from website/translated_docs/id-ID/maintain-networks.md rename to polkadot-wiki/translated_docs/id-ID/maintain-networks.md diff --git a/website/translated_docs/id-ID/maintain-nominator.md b/polkadot-wiki/translated_docs/id-ID/maintain-nominator.md similarity index 100% rename from website/translated_docs/id-ID/maintain-nominator.md rename to polkadot-wiki/translated_docs/id-ID/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/id-ID/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/id-ID/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/it/maintain-sync.md b/polkadot-wiki/translated_docs/id-ID/maintain-sync.md similarity index 100% rename from website/translated_docs/it/maintain-sync.md rename to polkadot-wiki/translated_docs/id-ID/maintain-sync.md diff --git a/website/translated_docs/id-ID/maintain-validator.md b/polkadot-wiki/translated_docs/id-ID/maintain-validator.md similarity index 100% rename from website/translated_docs/id-ID/maintain-validator.md rename to polkadot-wiki/translated_docs/id-ID/maintain-validator.md diff --git a/website/translated_docs/id-ID/maintain-wss.md b/polkadot-wiki/translated_docs/id-ID/maintain-wss.md similarity index 100% rename from website/translated_docs/id-ID/maintain-wss.md rename to polkadot-wiki/translated_docs/id-ID/maintain-wss.md diff --git a/website/translated_docs/id-ID/news.md b/polkadot-wiki/translated_docs/id-ID/news.md similarity index 100% rename from website/translated_docs/id-ID/news.md rename to polkadot-wiki/translated_docs/id-ID/news.md diff --git a/polkadot-wiki/translated_docs/id-ID/redenomination.md b/polkadot-wiki/translated_docs/id-ID/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/id-ID/research.md b/polkadot-wiki/translated_docs/id-ID/research.md similarity index 100% rename from website/translated_docs/id-ID/research.md rename to polkadot-wiki/translated_docs/id-ID/research.md diff --git a/polkadot-wiki/translated_docs/id-ID/thousand-validators.md b/polkadot-wiki/translated_docs/id-ID/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/id-ID/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/it/ambassadors.md b/polkadot-wiki/translated_docs/it/ambassadors.md similarity index 100% rename from website/translated_docs/it/ambassadors.md rename to polkadot-wiki/translated_docs/it/ambassadors.md diff --git a/website/translated_docs/it/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/it/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/it/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/it/build-build-with-polkadot.md diff --git a/website/translated_docs/it/build-cumulus.md b/polkadot-wiki/translated_docs/it/build-cumulus.md similarity index 100% rename from website/translated_docs/it/build-cumulus.md rename to polkadot-wiki/translated_docs/it/build-cumulus.md diff --git a/website/translated_docs/it/build-deploy-parachains.md b/polkadot-wiki/translated_docs/it/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/it/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/it/build-deploy-parachains.md diff --git a/website/translated_docs/it/build-examples-index.md b/polkadot-wiki/translated_docs/it/build-examples-index.md similarity index 100% rename from website/translated_docs/it/build-examples-index.md rename to polkadot-wiki/translated_docs/it/build-examples-index.md diff --git a/website/translated_docs/it/build-hackathon.md b/polkadot-wiki/translated_docs/it/build-hackathon.md similarity index 100% rename from website/translated_docs/it/build-hackathon.md rename to polkadot-wiki/translated_docs/it/build-hackathon.md diff --git a/website/translated_docs/it/build-index.md b/polkadot-wiki/translated_docs/it/build-index.md similarity index 100% rename from website/translated_docs/it/build-index.md rename to polkadot-wiki/translated_docs/it/build-index.md diff --git a/website/translated_docs/it/build-integration.md b/polkadot-wiki/translated_docs/it/build-integration.md similarity index 100% rename from website/translated_docs/it/build-integration.md rename to polkadot-wiki/translated_docs/it/build-integration.md diff --git a/website/translated_docs/it/build-node-interaction.md b/polkadot-wiki/translated_docs/it/build-node-interaction.md similarity index 100% rename from website/translated_docs/it/build-node-interaction.md rename to polkadot-wiki/translated_docs/it/build-node-interaction.md diff --git a/website/translated_docs/it/build-node-management.md b/polkadot-wiki/translated_docs/it/build-node-management.md similarity index 100% rename from website/translated_docs/it/build-node-management.md rename to polkadot-wiki/translated_docs/it/build-node-management.md diff --git a/website/translated_docs/it/build-oracle.md b/polkadot-wiki/translated_docs/it/build-oracle.md similarity index 100% rename from website/translated_docs/it/build-oracle.md rename to polkadot-wiki/translated_docs/it/build-oracle.md diff --git a/website/translated_docs/it/build-parachains-rococo.md b/polkadot-wiki/translated_docs/it/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/it/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/it/build-parachains-rococo.md diff --git a/website/translated_docs/it/build-pdk.md b/polkadot-wiki/translated_docs/it/build-pdk.md similarity index 100% rename from website/translated_docs/it/build-pdk.md rename to polkadot-wiki/translated_docs/it/build-pdk.md diff --git a/polkadot-wiki/translated_docs/it/build-protocol-info.md b/polkadot-wiki/translated_docs/it/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/it/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/it/build-smart-contracts.md b/polkadot-wiki/translated_docs/it/build-smart-contracts.md similarity index 100% rename from website/translated_docs/it/build-smart-contracts.md rename to polkadot-wiki/translated_docs/it/build-smart-contracts.md diff --git a/website/translated_docs/it/build-tools-index.md b/polkadot-wiki/translated_docs/it/build-tools-index.md similarity index 100% rename from website/translated_docs/it/build-tools-index.md rename to polkadot-wiki/translated_docs/it/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/it/build-transaction-construction.md b/polkadot-wiki/translated_docs/it/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/it/build-wallets.md b/polkadot-wiki/translated_docs/it/build-wallets.md similarity index 100% rename from website/translated_docs/it/build-wallets.md rename to polkadot-wiki/translated_docs/it/build-wallets.md diff --git a/polkadot-wiki/translated_docs/it/claims.md b/polkadot-wiki/translated_docs/it/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/it/community.md b/polkadot-wiki/translated_docs/it/community.md similarity index 100% rename from website/translated_docs/it/community.md rename to polkadot-wiki/translated_docs/it/community.md diff --git a/website/translated_docs/it/contributing.md b/polkadot-wiki/translated_docs/it/contributing.md similarity index 100% rename from website/translated_docs/it/contributing.md rename to polkadot-wiki/translated_docs/it/contributing.md diff --git a/website/translated_docs/it/contributors.md b/polkadot-wiki/translated_docs/it/contributors.md similarity index 100% rename from website/translated_docs/it/contributors.md rename to polkadot-wiki/translated_docs/it/contributors.md diff --git a/website/translated_docs/it/ens.md b/polkadot-wiki/translated_docs/it/ens.md similarity index 100% rename from website/translated_docs/it/ens.md rename to polkadot-wiki/translated_docs/it/ens.md diff --git a/website/translated_docs/it/faq.md b/polkadot-wiki/translated_docs/it/faq.md similarity index 100% rename from website/translated_docs/it/faq.md rename to polkadot-wiki/translated_docs/it/faq.md diff --git a/polkadot-wiki/translated_docs/it/getting-started.md b/polkadot-wiki/translated_docs/it/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/it/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/it/glossary.md b/polkadot-wiki/translated_docs/it/glossary.md similarity index 100% rename from website/translated_docs/it/glossary.md rename to polkadot-wiki/translated_docs/it/glossary.md diff --git a/polkadot-wiki/translated_docs/it/grants.md b/polkadot-wiki/translated_docs/it/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/it/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/it/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/it/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/it/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/it/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/it/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/it/kusama-bug-bounty.md diff --git a/website/translated_docs/it/kusama-claims.md b/polkadot-wiki/translated_docs/it/kusama-claims.md similarity index 100% rename from website/translated_docs/it/kusama-claims.md rename to polkadot-wiki/translated_docs/it/kusama-claims.md diff --git a/website/translated_docs/it/kusama-coc.md b/polkadot-wiki/translated_docs/it/kusama-coc.md similarity index 100% rename from website/translated_docs/it/kusama-coc.md rename to polkadot-wiki/translated_docs/it/kusama-coc.md diff --git a/website/translated_docs/it/kusama-community.md b/polkadot-wiki/translated_docs/it/kusama-community.md similarity index 100% rename from website/translated_docs/it/kusama-community.md rename to polkadot-wiki/translated_docs/it/kusama-community.md diff --git a/website/translated_docs/it/kusama-endpoints.md b/polkadot-wiki/translated_docs/it/kusama-endpoints.md similarity index 100% rename from website/translated_docs/it/kusama-endpoints.md rename to polkadot-wiki/translated_docs/it/kusama-endpoints.md diff --git a/website/translated_docs/it/kusama-faucet.md b/polkadot-wiki/translated_docs/it/kusama-faucet.md similarity index 100% rename from website/translated_docs/it/kusama-faucet.md rename to polkadot-wiki/translated_docs/it/kusama-faucet.md diff --git a/website/translated_docs/it/kusama-getting-started.md b/polkadot-wiki/translated_docs/it/kusama-getting-started.md similarity index 100% rename from website/translated_docs/it/kusama-getting-started.md rename to polkadot-wiki/translated_docs/it/kusama-getting-started.md diff --git a/website/translated_docs/it/kusama-index.md b/polkadot-wiki/translated_docs/it/kusama-index.md similarity index 100% rename from website/translated_docs/it/kusama-index.md rename to polkadot-wiki/translated_docs/it/kusama-index.md diff --git a/polkadot-wiki/translated_docs/it/kusama-ledger.md b/polkadot-wiki/translated_docs/it/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/it/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/it/kusama-parameters.md b/polkadot-wiki/translated_docs/it/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/it/kusama-social-recovery.md b/polkadot-wiki/translated_docs/it/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/it/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/it/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/it/kusama-time-periods.md b/polkadot-wiki/translated_docs/it/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/it/kusama-timeline.md b/polkadot-wiki/translated_docs/it/kusama-timeline.md similarity index 100% rename from website/translated_docs/it/kusama-timeline.md rename to polkadot-wiki/translated_docs/it/kusama-timeline.md diff --git a/website/translated_docs/it/learn-DOT.md b/polkadot-wiki/translated_docs/it/learn-DOT.md similarity index 100% rename from website/translated_docs/it/learn-DOT.md rename to polkadot-wiki/translated_docs/it/learn-DOT.md diff --git a/website/translated_docs/it/learn-account-generation.md b/polkadot-wiki/translated_docs/it/learn-account-generation.md similarity index 100% rename from website/translated_docs/it/learn-account-generation.md rename to polkadot-wiki/translated_docs/it/learn-account-generation.md diff --git a/website/translated_docs/it/learn-account-restore.md b/polkadot-wiki/translated_docs/it/learn-account-restore.md similarity index 100% rename from website/translated_docs/it/learn-account-restore.md rename to polkadot-wiki/translated_docs/it/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/it/learn-accounts.md b/polkadot-wiki/translated_docs/it/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/it/learn-architecture.md b/polkadot-wiki/translated_docs/it/learn-architecture.md similarity index 100% rename from website/translated_docs/it/learn-architecture.md rename to polkadot-wiki/translated_docs/it/learn-architecture.md diff --git a/website/translated_docs/it/learn-auction.md b/polkadot-wiki/translated_docs/it/learn-auction.md similarity index 100% rename from website/translated_docs/it/learn-auction.md rename to polkadot-wiki/translated_docs/it/learn-auction.md diff --git a/polkadot-wiki/translated_docs/it/learn-availability.md b/polkadot-wiki/translated_docs/it/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/it/learn-balance-transfers.md b/polkadot-wiki/translated_docs/it/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/it/learn-bridges.md b/polkadot-wiki/translated_docs/it/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/it/learn-collator.md b/polkadot-wiki/translated_docs/it/learn-collator.md similarity index 100% rename from website/translated_docs/it/learn-collator.md rename to polkadot-wiki/translated_docs/it/learn-collator.md diff --git a/website/translated_docs/it/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/it/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/it/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/it/learn-comparison-dfinity.md diff --git a/website/translated_docs/it/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/it/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/it/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/it/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/it/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/it/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/it/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/it/learn-comparisons-cosmos.md diff --git a/website/translated_docs/it/learn-comparisons.md b/polkadot-wiki/translated_docs/it/learn-comparisons.md similarity index 100% rename from website/translated_docs/it/learn-comparisons.md rename to polkadot-wiki/translated_docs/it/learn-comparisons.md diff --git a/website/translated_docs/it/learn-consensus.md b/polkadot-wiki/translated_docs/it/learn-consensus.md similarity index 100% rename from website/translated_docs/it/learn-consensus.md rename to polkadot-wiki/translated_docs/it/learn-consensus.md diff --git a/website/translated_docs/it/learn-crosschain.md b/polkadot-wiki/translated_docs/it/learn-crosschain.md similarity index 100% rename from website/translated_docs/it/learn-crosschain.md rename to polkadot-wiki/translated_docs/it/learn-crosschain.md diff --git a/website/translated_docs/it/learn-crowdloans.md b/polkadot-wiki/translated_docs/it/learn-crowdloans.md similarity index 100% rename from website/translated_docs/it/learn-crowdloans.md rename to polkadot-wiki/translated_docs/it/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/it/learn-cryptography.md b/polkadot-wiki/translated_docs/it/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/it/learn-governance.md b/polkadot-wiki/translated_docs/it/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/it/learn-identity.md b/polkadot-wiki/translated_docs/it/learn-identity.md similarity index 100% rename from website/translated_docs/it/learn-identity.md rename to polkadot-wiki/translated_docs/it/learn-identity.md diff --git a/website/translated_docs/it/learn-implementations.md b/polkadot-wiki/translated_docs/it/learn-implementations.md similarity index 100% rename from website/translated_docs/it/learn-implementations.md rename to polkadot-wiki/translated_docs/it/learn-implementations.md diff --git a/website/translated_docs/it/learn-implementers-guide.md b/polkadot-wiki/translated_docs/it/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/it/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/it/learn-implementers-guide.md diff --git a/website/translated_docs/it/learn-keys.md b/polkadot-wiki/translated_docs/it/learn-keys.md similarity index 100% rename from website/translated_docs/it/learn-keys.md rename to polkadot-wiki/translated_docs/it/learn-keys.md diff --git a/website/translated_docs/it/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/it/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/it/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/it/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/it/learn-launch.md b/polkadot-wiki/translated_docs/it/learn-launch.md similarity index 100% rename from website/translated_docs/it/learn-launch.md rename to polkadot-wiki/translated_docs/it/learn-launch.md diff --git a/polkadot-wiki/translated_docs/it/learn-ledger.md b/polkadot-wiki/translated_docs/it/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/it/learn-nominator.md b/polkadot-wiki/translated_docs/it/learn-nominator.md similarity index 100% rename from website/translated_docs/it/learn-nominator.md rename to polkadot-wiki/translated_docs/it/learn-nominator.md diff --git a/website/translated_docs/it/learn-parachains.md b/polkadot-wiki/translated_docs/it/learn-parachains.md similarity index 100% rename from website/translated_docs/it/learn-parachains.md rename to polkadot-wiki/translated_docs/it/learn-parachains.md diff --git a/website/translated_docs/it/learn-parathreads.md b/polkadot-wiki/translated_docs/it/learn-parathreads.md similarity index 100% rename from website/translated_docs/it/learn-parathreads.md rename to polkadot-wiki/translated_docs/it/learn-parathreads.md diff --git a/website/translated_docs/it/learn-phragmen.md b/polkadot-wiki/translated_docs/it/learn-phragmen.md similarity index 100% rename from website/translated_docs/it/learn-phragmen.md rename to polkadot-wiki/translated_docs/it/learn-phragmen.md diff --git a/website/translated_docs/it/learn-polkadot-host.md b/polkadot-wiki/translated_docs/it/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/it/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/it/learn-polkadot-host.md diff --git a/website/translated_docs/it/learn-proxies.md b/polkadot-wiki/translated_docs/it/learn-proxies.md similarity index 100% rename from website/translated_docs/it/learn-proxies.md rename to polkadot-wiki/translated_docs/it/learn-proxies.md diff --git a/website/translated_docs/it/learn-randomness.md b/polkadot-wiki/translated_docs/it/learn-randomness.md similarity index 100% rename from website/translated_docs/it/learn-randomness.md rename to polkadot-wiki/translated_docs/it/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/it/learn-registrar.md b/polkadot-wiki/translated_docs/it/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/it/learn-scams.md b/polkadot-wiki/translated_docs/it/learn-scams.md similarity index 100% rename from website/translated_docs/it/learn-scams.md rename to polkadot-wiki/translated_docs/it/learn-scams.md diff --git a/website/translated_docs/it/learn-security.md b/polkadot-wiki/translated_docs/it/learn-security.md similarity index 100% rename from website/translated_docs/it/learn-security.md rename to polkadot-wiki/translated_docs/it/learn-security.md diff --git a/website/translated_docs/it/learn-simple-payouts.md b/polkadot-wiki/translated_docs/it/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/it/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/it/learn-simple-payouts.md diff --git a/website/translated_docs/it/learn-spree.md b/polkadot-wiki/translated_docs/it/learn-spree.md similarity index 100% rename from website/translated_docs/it/learn-spree.md rename to polkadot-wiki/translated_docs/it/learn-spree.md diff --git a/polkadot-wiki/translated_docs/it/learn-staking.md b/polkadot-wiki/translated_docs/it/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/it/learn-transaction-fees.md b/polkadot-wiki/translated_docs/it/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/it/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/it/learn-transaction-fees.md diff --git a/website/translated_docs/it/learn-transactions.md b/polkadot-wiki/translated_docs/it/learn-transactions.md similarity index 100% rename from website/translated_docs/it/learn-transactions.md rename to polkadot-wiki/translated_docs/it/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/it/learn-treasury.md b/polkadot-wiki/translated_docs/it/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/it/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/it/learn-validator.md b/polkadot-wiki/translated_docs/it/learn-validator.md similarity index 100% rename from website/translated_docs/it/learn-validator.md rename to polkadot-wiki/translated_docs/it/learn-validator.md diff --git a/website/translated_docs/it/learn-wasm.md b/polkadot-wiki/translated_docs/it/learn-wasm.md similarity index 100% rename from website/translated_docs/it/learn-wasm.md rename to polkadot-wiki/translated_docs/it/learn-wasm.md diff --git a/website/translated_docs/it/maintain-collator.md b/polkadot-wiki/translated_docs/it/maintain-collator.md similarity index 100% rename from website/translated_docs/it/maintain-collator.md rename to polkadot-wiki/translated_docs/it/maintain-collator.md diff --git a/website/translated_docs/it/maintain-errors.md b/polkadot-wiki/translated_docs/it/maintain-errors.md similarity index 100% rename from website/translated_docs/it/maintain-errors.md rename to polkadot-wiki/translated_docs/it/maintain-errors.md diff --git a/website/translated_docs/it/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/it/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/it/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/it/maintain-guides-democracy.md diff --git a/website/translated_docs/it/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/it/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/it/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/it/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/it/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/it/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/it/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/it/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/it/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/it/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/it/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/it/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/it/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/it/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/it/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/it/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/it/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/it/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/it/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/it/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/it/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/it/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/it/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/it/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/it/maintain-guides-validator-payout.md diff --git a/website/translated_docs/hr-HR/maintain-index.md b/polkadot-wiki/translated_docs/it/maintain-index.md similarity index 100% rename from website/translated_docs/hr-HR/maintain-index.md rename to polkadot-wiki/translated_docs/it/maintain-index.md diff --git a/website/translated_docs/it/maintain-networks.md b/polkadot-wiki/translated_docs/it/maintain-networks.md similarity index 100% rename from website/translated_docs/it/maintain-networks.md rename to polkadot-wiki/translated_docs/it/maintain-networks.md diff --git a/website/translated_docs/it/maintain-nominator.md b/polkadot-wiki/translated_docs/it/maintain-nominator.md similarity index 100% rename from website/translated_docs/it/maintain-nominator.md rename to polkadot-wiki/translated_docs/it/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/it/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/it/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/it/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ja/maintain-sync.md b/polkadot-wiki/translated_docs/it/maintain-sync.md similarity index 100% rename from website/translated_docs/ja/maintain-sync.md rename to polkadot-wiki/translated_docs/it/maintain-sync.md diff --git a/website/translated_docs/it/maintain-validator.md b/polkadot-wiki/translated_docs/it/maintain-validator.md similarity index 100% rename from website/translated_docs/it/maintain-validator.md rename to polkadot-wiki/translated_docs/it/maintain-validator.md diff --git a/website/translated_docs/it/maintain-wss.md b/polkadot-wiki/translated_docs/it/maintain-wss.md similarity index 100% rename from website/translated_docs/it/maintain-wss.md rename to polkadot-wiki/translated_docs/it/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/it/redenomination.md b/polkadot-wiki/translated_docs/it/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/it/research.md b/polkadot-wiki/translated_docs/it/research.md similarity index 100% rename from website/translated_docs/it/research.md rename to polkadot-wiki/translated_docs/it/research.md diff --git a/polkadot-wiki/translated_docs/it/thousand-validators.md b/polkadot-wiki/translated_docs/it/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/it/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ja/ambassadors.md b/polkadot-wiki/translated_docs/ja/ambassadors.md similarity index 100% rename from website/translated_docs/ja/ambassadors.md rename to polkadot-wiki/translated_docs/ja/ambassadors.md diff --git a/website/translated_docs/ja/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/ja/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/ja/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/ja/build-build-with-polkadot.md diff --git a/website/translated_docs/ja/build-cumulus.md b/polkadot-wiki/translated_docs/ja/build-cumulus.md similarity index 100% rename from website/translated_docs/ja/build-cumulus.md rename to polkadot-wiki/translated_docs/ja/build-cumulus.md diff --git a/website/translated_docs/ja/build-deploy-parachains.md b/polkadot-wiki/translated_docs/ja/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/ja/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/ja/build-deploy-parachains.md diff --git a/website/translated_docs/ja/build-dev-roadmap.md b/polkadot-wiki/translated_docs/ja/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/ja/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/ja/build-dev-roadmap.md diff --git a/website/translated_docs/ja/build-examples-index.md b/polkadot-wiki/translated_docs/ja/build-examples-index.md similarity index 100% rename from website/translated_docs/ja/build-examples-index.md rename to polkadot-wiki/translated_docs/ja/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/ja/build-exchange-integration.md b/polkadot-wiki/translated_docs/ja/build-exchange-integration.md new file mode 100644 index 000000000000..dddd3a779fac --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. Tracking the chain head + +Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). + +That will give you a stream of hashes of the most recent finalised headers. + +When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. + +If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. + +## 2. Decoding blocks + +You will need to decode blocks from the basic data into useful fields. + +All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. + +For Genesis Polkadot, the header format is a five-field structure: + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +It also relies on `Extrinsic`. An _extrinsic_ is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. + +The metadata itself is provided encoded in SCALE. Its format is: + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. + +Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various _modules_. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, _extrinsics_), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. Working with SS58 and account addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) _AccountId_. This is simply the public key for the x25519 cryptography used by Substrate. + +However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this _index_ to identify the account. This index is much smaller than the 32-byte _AccountId_, and can usually be encoded in just a couple of bytes. + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: + +`0x00 ` + +**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. + +Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. + +Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. + +### Looking up an index + +Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. + +The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. + +For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. + +This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. + +This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. + +Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. + +## 4. Working with balances + +In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. + +NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. + +The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10\*\*12). For completeness, The exact denominations of the Polkadot currency are: + +| Balance value | Name | +| ------------- | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### Transferring balances + +To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. + +In general, Polkadot's transactions are encoded as _signed_ `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. + +The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. + +NOTE: The nonce retrieved from storage does not take into account _pending_ transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. + +The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. + +The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. + +Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. + +Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +The `function` _in this case_ (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. + +The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. + +### Submitting and checking transactions + +Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. + +This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. + +The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. + +## Conclusion + +This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. + +If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). + +_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/polkadot-wiki/translated_docs/ja/build-extrinsic-format.md b/polkadot-wiki/translated_docs/ja/build-extrinsic-format.md new file mode 100644 index 000000000000..39a48b855d09 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/build-extrinsic-format.md @@ -0,0 +1,44 @@ +--- +id: build-extrinsic-format +title: Polkadot Extrinsic Format aka Transaction Format +sidebar_label: Polkadot Extrinsic Format aka Transaction Format +--- + +## Old Format + +For reference, the **old** extrinsic format was: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] +``` + +## Current Format + +The Polkadot extrinsic format is: + +``` +[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] +``` + +The _original_ fields refer to the following from the old extrinsic format: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] +``` + +The specific format for the new address type is one of 5 sub-formats, switched on the first byte: + +- `0xff, 32-byte account id` +- `0xfe, 8-byte account index` +- `0xfd, 4-byte account index` +- `0xfc, 2-byte account index` +- `[0xf0...0xfb] (invalid, reserved for future use)` +- `[0x00...0xef] 1-byte account index (less than 0xf0)` + +The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. + +In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). + +## Source + +[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/ja/build-hackathon.md b/polkadot-wiki/translated_docs/ja/build-hackathon.md similarity index 100% rename from website/translated_docs/ja/build-hackathon.md rename to polkadot-wiki/translated_docs/ja/build-hackathon.md diff --git a/website/translated_docs/ja/build-index.md b/polkadot-wiki/translated_docs/ja/build-index.md similarity index 100% rename from website/translated_docs/ja/build-index.md rename to polkadot-wiki/translated_docs/ja/build-index.md diff --git a/website/translated_docs/ja/build-integration.md b/polkadot-wiki/translated_docs/ja/build-integration.md similarity index 100% rename from website/translated_docs/ja/build-integration.md rename to polkadot-wiki/translated_docs/ja/build-integration.md diff --git a/website/translated_docs/ja/build-networks.md b/polkadot-wiki/translated_docs/ja/build-networks.md similarity index 100% rename from website/translated_docs/ja/build-networks.md rename to polkadot-wiki/translated_docs/ja/build-networks.md diff --git a/website/translated_docs/ja/build-node-interaction.md b/polkadot-wiki/translated_docs/ja/build-node-interaction.md similarity index 100% rename from website/translated_docs/ja/build-node-interaction.md rename to polkadot-wiki/translated_docs/ja/build-node-interaction.md diff --git a/website/translated_docs/ja/build-node-management.md b/polkadot-wiki/translated_docs/ja/build-node-management.md similarity index 100% rename from website/translated_docs/ja/build-node-management.md rename to polkadot-wiki/translated_docs/ja/build-node-management.md diff --git a/website/translated_docs/ja/build-oracle.md b/polkadot-wiki/translated_docs/ja/build-oracle.md similarity index 100% rename from website/translated_docs/ja/build-oracle.md rename to polkadot-wiki/translated_docs/ja/build-oracle.md diff --git a/website/translated_docs/ja/build-parachains-rococo.md b/polkadot-wiki/translated_docs/ja/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/ja/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/ja/build-parachains-rococo.md diff --git a/website/translated_docs/ja/build-pdk.md b/polkadot-wiki/translated_docs/ja/build-pdk.md similarity index 100% rename from website/translated_docs/ja/build-pdk.md rename to polkadot-wiki/translated_docs/ja/build-pdk.md diff --git a/polkadot-wiki/translated_docs/ja/build-protocol-info.md b/polkadot-wiki/translated_docs/ja/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/polkadot-wiki/translated_docs/ja/build-rust-style-guide.md b/polkadot-wiki/translated_docs/ja/build-rust-style-guide.md new file mode 100644 index 000000000000..678bb58481ae --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/build-rust-style-guide.md @@ -0,0 +1,117 @@ +--- +id: build-rust-style-guide +title: Style Guide for Rust in Polkadot +sidebar_label: Style Guide for Rust in Polkadot +--- + +- Indent using tabs +- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. +- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. +- Never have spaces on a line prior to a non-whitespace character +- Follow-on lines are only ever a single indent from the original line. + +```rust +fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { + let x = some_long_variable_a * some_long_variable_b + - some_long_variable_b / some_long_variable_a + + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); + x > 10 +} +``` + +- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: + +```rust +fn calculate( + some_long_variable_a: f32, + some_long_variable_b: f32, + some_long_variable_c: f32, +) -> f32 { + (-some_long_variable_b + sqrt( + // two parens open, but since we open & close them both on the + // same line, only one indent level is used + some_long_variable_b * some_long_variable_b + - 4 * some_long_variable_a * some_long_variable_c + // both closed here at beginning of line, so back to the original indent + // level + )) / (2 * some_long_variable_a) +} +``` + +- `where` is indented, and its items are indented one further +- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. + +```rust +// OK +fn foo( + really_long_parameter_name_1: SomeLongTypeName, + really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, + shrt_nm_2: u8, +) { + ... +} + +// NOT OK +fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, shrt_nm_2: u8) { + ... +} + +``` + +```rust +{ + // Complex line (not just a function call, also a let statement). Full + // structure. + let (a, b) = bar( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Long, simple function call. + waz( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Short function call. Inline. + baz(a, b); +} +``` + +- Always end last item of a multi-line comma-delimited set with `,` when legal: + +```rust +struct Point { + x: T, + y: T, // <-- Multiline comma-delimited lists end with a trailing , +} + +// Single line comma-delimited items do not have a trailing `,` +enum Meal { Breakfast, Lunch, Dinner }; +``` + +- Avoid trailing `;`s where unneeded. + +```rust +if condition { + return 1 // <-- no ; here +} +``` + +- `match` arms may be either blocks or have a trailing `,` but not both. +- Blocks should not be used unnecessarily. + +```rust +match meal { + Meal::Breakfast => "eggs", + Meal::Lunch => { check_diet(); recipe() }, +// Meal::Dinner => { return Err("Fasting") } // WRONG + Meal::Dinner => return Err("Fasting"), +} +``` diff --git a/website/translated_docs/ja/build-smart-contracts.md b/polkadot-wiki/translated_docs/ja/build-smart-contracts.md similarity index 100% rename from website/translated_docs/ja/build-smart-contracts.md rename to polkadot-wiki/translated_docs/ja/build-smart-contracts.md diff --git a/website/translated_docs/ja/build-tools-index.md b/polkadot-wiki/translated_docs/ja/build-tools-index.md similarity index 100% rename from website/translated_docs/ja/build-tools-index.md rename to polkadot-wiki/translated_docs/ja/build-tools-index.md diff --git a/website/translated_docs/ja/build-tools-subkey.md b/polkadot-wiki/translated_docs/ja/build-tools-subkey.md similarity index 100% rename from website/translated_docs/ja/build-tools-subkey.md rename to polkadot-wiki/translated_docs/ja/build-tools-subkey.md diff --git a/polkadot-wiki/translated_docs/ja/build-transaction-construction.md b/polkadot-wiki/translated_docs/ja/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/ja/build-wallets.md b/polkadot-wiki/translated_docs/ja/build-wallets.md similarity index 100% rename from website/translated_docs/ja/build-wallets.md rename to polkadot-wiki/translated_docs/ja/build-wallets.md diff --git a/polkadot-wiki/translated_docs/ja/claims.md b/polkadot-wiki/translated_docs/ja/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ja/community.md b/polkadot-wiki/translated_docs/ja/community.md similarity index 100% rename from website/translated_docs/ja/community.md rename to polkadot-wiki/translated_docs/ja/community.md diff --git a/website/translated_docs/ja/contributing.md b/polkadot-wiki/translated_docs/ja/contributing.md similarity index 100% rename from website/translated_docs/ja/contributing.md rename to polkadot-wiki/translated_docs/ja/contributing.md diff --git a/website/translated_docs/ja/contributors.md b/polkadot-wiki/translated_docs/ja/contributors.md similarity index 100% rename from website/translated_docs/ja/contributors.md rename to polkadot-wiki/translated_docs/ja/contributors.md diff --git a/website/translated_docs/ja/ens.md b/polkadot-wiki/translated_docs/ja/ens.md similarity index 100% rename from website/translated_docs/ja/ens.md rename to polkadot-wiki/translated_docs/ja/ens.md diff --git a/website/translated_docs/ja/faq.md b/polkadot-wiki/translated_docs/ja/faq.md similarity index 100% rename from website/translated_docs/ja/faq.md rename to polkadot-wiki/translated_docs/ja/faq.md diff --git a/polkadot-wiki/translated_docs/ja/getting-started.md b/polkadot-wiki/translated_docs/ja/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ja/glossary.md b/polkadot-wiki/translated_docs/ja/glossary.md similarity index 100% rename from website/translated_docs/ja/glossary.md rename to polkadot-wiki/translated_docs/ja/glossary.md diff --git a/polkadot-wiki/translated_docs/ja/grants.md b/polkadot-wiki/translated_docs/ja/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ja/index.md b/polkadot-wiki/translated_docs/ja/index.md similarity index 100% rename from website/translated_docs/ja/index.md rename to polkadot-wiki/translated_docs/ja/index.md diff --git a/polkadot-wiki/translated_docs/ja/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/ja/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ja/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/ja/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/ja/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/ja/kusama-bug-bounty.md diff --git a/website/translated_docs/ja/kusama-claims.md b/polkadot-wiki/translated_docs/ja/kusama-claims.md similarity index 100% rename from website/translated_docs/ja/kusama-claims.md rename to polkadot-wiki/translated_docs/ja/kusama-claims.md diff --git a/website/translated_docs/ja/kusama-coc.md b/polkadot-wiki/translated_docs/ja/kusama-coc.md similarity index 100% rename from website/translated_docs/ja/kusama-coc.md rename to polkadot-wiki/translated_docs/ja/kusama-coc.md diff --git a/website/translated_docs/ja/kusama-community.md b/polkadot-wiki/translated_docs/ja/kusama-community.md similarity index 100% rename from website/translated_docs/ja/kusama-community.md rename to polkadot-wiki/translated_docs/ja/kusama-community.md diff --git a/website/translated_docs/ja/kusama-endpoints.md b/polkadot-wiki/translated_docs/ja/kusama-endpoints.md similarity index 100% rename from website/translated_docs/ja/kusama-endpoints.md rename to polkadot-wiki/translated_docs/ja/kusama-endpoints.md diff --git a/website/translated_docs/ja/kusama-faucet.md b/polkadot-wiki/translated_docs/ja/kusama-faucet.md similarity index 100% rename from website/translated_docs/ja/kusama-faucet.md rename to polkadot-wiki/translated_docs/ja/kusama-faucet.md diff --git a/website/translated_docs/ja/kusama-getting-started.md b/polkadot-wiki/translated_docs/ja/kusama-getting-started.md similarity index 100% rename from website/translated_docs/ja/kusama-getting-started.md rename to polkadot-wiki/translated_docs/ja/kusama-getting-started.md diff --git a/website/translated_docs/ja/kusama-index.md b/polkadot-wiki/translated_docs/ja/kusama-index.md similarity index 100% rename from website/translated_docs/ja/kusama-index.md rename to polkadot-wiki/translated_docs/ja/kusama-index.md diff --git a/polkadot-wiki/translated_docs/ja/kusama-ledger.md b/polkadot-wiki/translated_docs/ja/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/ja/kusama-parameters.md b/polkadot-wiki/translated_docs/ja/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ja/kusama-social-recovery.md b/polkadot-wiki/translated_docs/ja/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/ja/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/ja/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/ja/kusama-time-periods.md b/polkadot-wiki/translated_docs/ja/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ja/kusama-timeline.md b/polkadot-wiki/translated_docs/ja/kusama-timeline.md similarity index 100% rename from website/translated_docs/ja/kusama-timeline.md rename to polkadot-wiki/translated_docs/ja/kusama-timeline.md diff --git a/website/translated_docs/ja/learn-DOT.md b/polkadot-wiki/translated_docs/ja/learn-DOT.md similarity index 100% rename from website/translated_docs/ja/learn-DOT.md rename to polkadot-wiki/translated_docs/ja/learn-DOT.md diff --git a/website/translated_docs/ja/learn-PRE.md b/polkadot-wiki/translated_docs/ja/learn-PRE.md similarity index 100% rename from website/translated_docs/ja/learn-PRE.md rename to polkadot-wiki/translated_docs/ja/learn-PRE.md diff --git a/polkadot-wiki/translated_docs/ja/learn-UI.md b/polkadot-wiki/translated_docs/ja/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/ja/learn-account-generation.md b/polkadot-wiki/translated_docs/ja/learn-account-generation.md similarity index 100% rename from website/translated_docs/ja/learn-account-generation.md rename to polkadot-wiki/translated_docs/ja/learn-account-generation.md diff --git a/website/translated_docs/ja/learn-account-restore.md b/polkadot-wiki/translated_docs/ja/learn-account-restore.md similarity index 100% rename from website/translated_docs/ja/learn-account-restore.md rename to polkadot-wiki/translated_docs/ja/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/ja/learn-accounts.md b/polkadot-wiki/translated_docs/ja/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ja/learn-architecture.md b/polkadot-wiki/translated_docs/ja/learn-architecture.md similarity index 100% rename from website/translated_docs/ja/learn-architecture.md rename to polkadot-wiki/translated_docs/ja/learn-architecture.md diff --git a/website/translated_docs/ja/learn-auction.md b/polkadot-wiki/translated_docs/ja/learn-auction.md similarity index 100% rename from website/translated_docs/ja/learn-auction.md rename to polkadot-wiki/translated_docs/ja/learn-auction.md diff --git a/polkadot-wiki/translated_docs/ja/learn-availability.md b/polkadot-wiki/translated_docs/ja/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/ja/learn-balance-transfers.md b/polkadot-wiki/translated_docs/ja/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/ja/learn-bridges.md b/polkadot-wiki/translated_docs/ja/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ja/learn-collator.md b/polkadot-wiki/translated_docs/ja/learn-collator.md similarity index 100% rename from website/translated_docs/ja/learn-collator.md rename to polkadot-wiki/translated_docs/ja/learn-collator.md diff --git a/website/translated_docs/ja/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/ja/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/ja/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/ja/learn-comparison-dfinity.md diff --git a/website/translated_docs/ja/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/ja/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/ja/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/ja/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/ja/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/ja/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/ja/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/ja/learn-comparisons-cosmos.md diff --git a/website/translated_docs/ja/learn-comparisons.md b/polkadot-wiki/translated_docs/ja/learn-comparisons.md similarity index 100% rename from website/translated_docs/ja/learn-comparisons.md rename to polkadot-wiki/translated_docs/ja/learn-comparisons.md diff --git a/website/translated_docs/ja/learn-consensus.md b/polkadot-wiki/translated_docs/ja/learn-consensus.md similarity index 100% rename from website/translated_docs/ja/learn-consensus.md rename to polkadot-wiki/translated_docs/ja/learn-consensus.md diff --git a/website/translated_docs/ja/learn-crosschain.md b/polkadot-wiki/translated_docs/ja/learn-crosschain.md similarity index 100% rename from website/translated_docs/ja/learn-crosschain.md rename to polkadot-wiki/translated_docs/ja/learn-crosschain.md diff --git a/website/translated_docs/ja/learn-crowdloans.md b/polkadot-wiki/translated_docs/ja/learn-crowdloans.md similarity index 100% rename from website/translated_docs/ja/learn-crowdloans.md rename to polkadot-wiki/translated_docs/ja/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/ja/learn-cryptography.md b/polkadot-wiki/translated_docs/ja/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ja/learn-faq.md b/polkadot-wiki/translated_docs/ja/learn-faq.md similarity index 100% rename from website/translated_docs/ja/learn-faq.md rename to polkadot-wiki/translated_docs/ja/learn-faq.md diff --git a/polkadot-wiki/translated_docs/ja/learn-governance.md b/polkadot-wiki/translated_docs/ja/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ja/learn-identity.md b/polkadot-wiki/translated_docs/ja/learn-identity.md similarity index 100% rename from website/translated_docs/ja/learn-identity.md rename to polkadot-wiki/translated_docs/ja/learn-identity.md diff --git a/website/translated_docs/ja/learn-implementations.md b/polkadot-wiki/translated_docs/ja/learn-implementations.md similarity index 100% rename from website/translated_docs/ja/learn-implementations.md rename to polkadot-wiki/translated_docs/ja/learn-implementations.md diff --git a/website/translated_docs/ja/learn-implementers-guide.md b/polkadot-wiki/translated_docs/ja/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/ja/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/ja/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/ja/learn-interchain.md b/polkadot-wiki/translated_docs/ja/learn-interchain.md new file mode 100644 index 000000000000..2677ee91d812 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. + +The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. + +## Overview + +- Interchain messages will _not_ go on to the relay chain. +- Interchain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. + +## Example + +A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. + +When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/ja/learn-introduction.md b/polkadot-wiki/translated_docs/ja/learn-introduction.md similarity index 100% rename from website/translated_docs/ja/learn-introduction.md rename to polkadot-wiki/translated_docs/ja/learn-introduction.md diff --git a/website/translated_docs/ja/learn-keys.md b/polkadot-wiki/translated_docs/ja/learn-keys.md similarity index 100% rename from website/translated_docs/ja/learn-keys.md rename to polkadot-wiki/translated_docs/ja/learn-keys.md diff --git a/website/translated_docs/ja/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/ja/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/ja/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/ja/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/ja/learn-launch.md b/polkadot-wiki/translated_docs/ja/learn-launch.md similarity index 100% rename from website/translated_docs/ja/learn-launch.md rename to polkadot-wiki/translated_docs/ja/learn-launch.md diff --git a/website/translated_docs/ja/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/ja/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/ja/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/ja/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/ja/learn-ledger.md b/polkadot-wiki/translated_docs/ja/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ja/learn-nominator.md b/polkadot-wiki/translated_docs/ja/learn-nominator.md similarity index 100% rename from website/translated_docs/ja/learn-nominator.md rename to polkadot-wiki/translated_docs/ja/learn-nominator.md diff --git a/website/translated_docs/ja/learn-parachains.md b/polkadot-wiki/translated_docs/ja/learn-parachains.md similarity index 100% rename from website/translated_docs/ja/learn-parachains.md rename to polkadot-wiki/translated_docs/ja/learn-parachains.md diff --git a/website/translated_docs/ja/learn-parathreads.md b/polkadot-wiki/translated_docs/ja/learn-parathreads.md similarity index 100% rename from website/translated_docs/ja/learn-parathreads.md rename to polkadot-wiki/translated_docs/ja/learn-parathreads.md diff --git a/website/translated_docs/ja/learn-phragmen.md b/polkadot-wiki/translated_docs/ja/learn-phragmen.md similarity index 100% rename from website/translated_docs/ja/learn-phragmen.md rename to polkadot-wiki/translated_docs/ja/learn-phragmen.md diff --git a/website/translated_docs/ja/learn-polkadot-host.md b/polkadot-wiki/translated_docs/ja/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/ja/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/ja/learn-polkadot-host.md diff --git a/website/translated_docs/ja/learn-proxies.md b/polkadot-wiki/translated_docs/ja/learn-proxies.md similarity index 100% rename from website/translated_docs/ja/learn-proxies.md rename to polkadot-wiki/translated_docs/ja/learn-proxies.md diff --git a/website/translated_docs/ja/learn-randomness.md b/polkadot-wiki/translated_docs/ja/learn-randomness.md similarity index 100% rename from website/translated_docs/ja/learn-randomness.md rename to polkadot-wiki/translated_docs/ja/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/ja/learn-registrar.md b/polkadot-wiki/translated_docs/ja/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ja/learn-relevant-links.md b/polkadot-wiki/translated_docs/ja/learn-relevant-links.md similarity index 100% rename from website/translated_docs/ja/learn-relevant-links.md rename to polkadot-wiki/translated_docs/ja/learn-relevant-links.md diff --git a/website/translated_docs/ja/learn-roadmap.md b/polkadot-wiki/translated_docs/ja/learn-roadmap.md similarity index 100% rename from website/translated_docs/ja/learn-roadmap.md rename to polkadot-wiki/translated_docs/ja/learn-roadmap.md diff --git a/website/translated_docs/ja/learn-scams.md b/polkadot-wiki/translated_docs/ja/learn-scams.md similarity index 100% rename from website/translated_docs/ja/learn-scams.md rename to polkadot-wiki/translated_docs/ja/learn-scams.md diff --git a/website/translated_docs/ja/learn-security.md b/polkadot-wiki/translated_docs/ja/learn-security.md similarity index 100% rename from website/translated_docs/ja/learn-security.md rename to polkadot-wiki/translated_docs/ja/learn-security.md diff --git a/website/translated_docs/ja/learn-simple-payouts.md b/polkadot-wiki/translated_docs/ja/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/ja/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/ja/learn-simple-payouts.md diff --git a/website/translated_docs/ja/learn-spree.md b/polkadot-wiki/translated_docs/ja/learn-spree.md similarity index 100% rename from website/translated_docs/ja/learn-spree.md rename to polkadot-wiki/translated_docs/ja/learn-spree.md diff --git a/polkadot-wiki/translated_docs/ja/learn-staking.md b/polkadot-wiki/translated_docs/ja/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ja/learn-transaction-fees.md b/polkadot-wiki/translated_docs/ja/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/ja/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/ja/learn-transaction-fees.md diff --git a/website/translated_docs/ja/learn-transactions.md b/polkadot-wiki/translated_docs/ja/learn-transactions.md similarity index 100% rename from website/translated_docs/ja/learn-transactions.md rename to polkadot-wiki/translated_docs/ja/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/ja/learn-treasury.md b/polkadot-wiki/translated_docs/ja/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ja/learn-validator.md b/polkadot-wiki/translated_docs/ja/learn-validator.md similarity index 100% rename from website/translated_docs/ja/learn-validator.md rename to polkadot-wiki/translated_docs/ja/learn-validator.md diff --git a/website/translated_docs/ja/learn-wasm.md b/polkadot-wiki/translated_docs/ja/learn-wasm.md similarity index 100% rename from website/translated_docs/ja/learn-wasm.md rename to polkadot-wiki/translated_docs/ja/learn-wasm.md diff --git a/website/translated_docs/ja/maintain-collator.md b/polkadot-wiki/translated_docs/ja/maintain-collator.md similarity index 100% rename from website/translated_docs/ja/maintain-collator.md rename to polkadot-wiki/translated_docs/ja/maintain-collator.md diff --git a/website/translated_docs/ja/maintain-errors.md b/polkadot-wiki/translated_docs/ja/maintain-errors.md similarity index 100% rename from website/translated_docs/ja/maintain-errors.md rename to polkadot-wiki/translated_docs/ja/maintain-errors.md diff --git a/polkadot-wiki/translated_docs/ja/maintain-governance-index.md b/polkadot-wiki/translated_docs/ja/maintain-governance-index.md new file mode 100644 index 000000000000..8812e030de6c --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-governance-index.md @@ -0,0 +1,185 @@ +--- +id: maintain-governance-index +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. + +All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. + +The following steps are the governance procedure in the Polkadot network: + +- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) +- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) +- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) + +To better understand how the council is formed, please read [this section](#council). + +### Proposing Referenda + +- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. + +- **[Council](#council)**: + + Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. + + Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) + +### Voting for a proposal + +To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). + +``` +Example: + +Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes +``` + +According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. + +### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +voters - the total number of voting tokens + +electorate - the total number of DOTs tokens issued in the network +``` + +**Super-Majority Approve** + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ + +**Super-Majority Against** + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ + +**Simple-Majority** + +Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ + +_To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume we only have 1,500 DOTs tokens in total. + +John - 500 DOTs +Peter - 100 DOTs +Lilly - 150 DOTs +JJ - 150 DOTs +Ken - 600 DOTs + +John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +voters = 1050 +electorate = 1500 +``` + +$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ + +$${13.887} < {15.492}$$ + +Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. + +## Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: + +``` +Max votes = tokens * periods +``` + +Based on the current testnet setting, the maximum number of lock periods is set to 6. + +**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** + +## Adaptive Quorum Biasing + +Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. + +Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. + +Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. + +In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +## Council + +Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. + +To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. + +Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. + +Let's take a look at the example below. + +||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. + +### Resources + +- [Governance Description](learn-governance#referenda) +- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) + +## [Usage of DOT](learn-DOT#dots-for-governance) + +## Guides + +### [How to create a proposal]() + +### [How to join the council]() + +### [How to propose a referenda]() diff --git a/website/translated_docs/ja/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/ja/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-democracy.md diff --git a/website/translated_docs/ja/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-chill.md diff --git a/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-join-council.md new file mode 100644 index 000000000000..7057a0f069f9 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-join-council.md @@ -0,0 +1,43 @@ +--- +id: maintain-guides-how-to-join-council +title: 協議会への参加 +sidebar_label: 協議会への参加 +--- + +協議会は、Polkadot および Kusama のステークホルダーたちを代表するチェーン上のアカウントから選ばれたもので構成されています。協議会にはガバナンスにおける主な役割が主に二つあります。それは、1) 投票を提案すること、2) 危険および悪意のある投票を拒否権を使い否認することです。協議会についてより詳しく知るためには[ガバナンスページ](learn-governance#council)　をご覧下さい。このガイドは協議会に立候補する方法について説明します。 + +## 立候補を表明する + +Submitting your candidacy for the council requires a small bond of DOT / KSM. The bond will be forfeited if your candidacy does not win or become a runner-up and will be kept otherwise. You only receive your bond back, if you manually renounce your candidacy before losing. Runners-up are selected after every round and are reserved members in case one of the winners gets forcefully removed. + +> 現在 Polkadot において協議会に立候補する場合の担保額は 100DOT、Kusama において協議会に立候補する場合の担保額は 0.1666KSM です。 + +協議会に立候補をする前には、選挙が開始され、すぐに投票してもらえるように、前以て出馬することをアナウンスし、サポーターに対し周知活動しておくことが良いでしょう。万が一、誰も投票してくれない場合は自分で自身に対し票をいれることができます。 + +Go to [Polkadot Apps Dashboard](https://polkadot.js.org/apps) and navigate to the "Council" tab. Click the button on the right that says "Submit Candidacy." + +![立候補を表明するボタン](assets/council/polkadotjs_submit_candidancy.png) + +トランザクションを行った後に、「立候補者」の下にあなたのアカウントが表示されます。 + +![立候補者リスト](assets/council/polkadotjs_candidates.png) + +まず、自分自身のアカウントに対して票を入れ、例を作っておくことが良いと考えれらます。 + +## 立候補者に対して投票する + +Next to the button to submit candidacy is another button titled "Vote." You will click this button to make a vote for yourself (optional). + +![UIの投票ボタン](assets/council/polkadotjs_vote_button.png) + +The council uses [Phragmén](learn-phragmen) approval voting, which is also used in the validator elections. This means that you can choose up to 16 distinct candidates to vote for and your stake will equalize between them. For this guide, choose to approve your own candidacy by clicking on the switch next to your account and changing it to say "Aye." + +![UIでの投票ポップアップ](assets/council/polkadotjs_voting.png) + +## 当選 + +If you are one of the lucky ones to win a council election you will see your account move underneath the row "Members". + +![council members list](assets/council/polkadotjs_council_members.png) + +これであなたも協議会に参加し、提案を行うことができます。よりアクティブなディスカッションに参加するには[Kusama ガバナンスチャンネル](https://matrix.to/#/!QXMnIJzxlnVrvRzhUA:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation)まで。 diff --git a/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/ja/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/ja/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate-polkadot.md diff --git a/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate.md new file mode 100644 index 000000000000..20b9f634ea64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-nominate.md @@ -0,0 +1,59 @@ +--- +id: maintain-guides-how-to-nominate +title: How to nominate +sidebar_label: How to nominate +--- + +This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. + +It has been updated for the Alexander testnet and Polkadot release PoC-4. + +## Create `stash` and `controller` accounts + +We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. + +The first step is to create two accounts by going to the _Accounts_ tab on the Polkadot Dashboard and clicking on [_Add account_](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. + +![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) + +Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. + +## Nominating + +It is now time to setup our nominator. We will do the following: + +- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. +- Select the `controller`. This is the account that will decide when to start or stop nominating. + +First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. + +![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. +- **Controller account** - select the `controller` account created earlier. +- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). +- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). + +Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. + +![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) + +## Nominating a validator + +Go to the _Staking Overview_ tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. + +![Validators](assets/guides/how-to-nominate/validators.png) + +Go back to the _Account Actions_ tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). + +![Nominating](assets/guides/how-to-nominate/nominating.jpg) + +**Congratulations!** You are now a nominator. + +If you return to the _Staking Overview_ tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. + +![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) + +## How to stop nominating + +To stop nominating simply return to the _Account Actions_ tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/ja/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/ja/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/ja/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/ja/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/ja/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/ja/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/ja/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/ja/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/ja/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ja/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/ja/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ja/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/ja/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/ja/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/ja/maintain-guides-validator-payout.md diff --git a/website/translated_docs/it/maintain-index.md b/polkadot-wiki/translated_docs/ja/maintain-index.md similarity index 100% rename from website/translated_docs/it/maintain-index.md rename to polkadot-wiki/translated_docs/ja/maintain-index.md diff --git a/website/translated_docs/ja/maintain-networks.md b/polkadot-wiki/translated_docs/ja/maintain-networks.md similarity index 100% rename from website/translated_docs/ja/maintain-networks.md rename to polkadot-wiki/translated_docs/ja/maintain-networks.md diff --git a/website/translated_docs/ja/maintain-node-operator.md b/polkadot-wiki/translated_docs/ja/maintain-node-operator.md similarity index 100% rename from website/translated_docs/ja/maintain-node-operator.md rename to polkadot-wiki/translated_docs/ja/maintain-node-operator.md diff --git a/website/translated_docs/ja/maintain-nominator.md b/polkadot-wiki/translated_docs/ja/maintain-nominator.md similarity index 100% rename from website/translated_docs/ja/maintain-nominator.md rename to polkadot-wiki/translated_docs/ja/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/ja/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/ja/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ko/maintain-sync.md b/polkadot-wiki/translated_docs/ja/maintain-sync.md similarity index 100% rename from website/translated_docs/ko/maintain-sync.md rename to polkadot-wiki/translated_docs/ja/maintain-sync.md diff --git a/website/translated_docs/ja/maintain-validator.md b/polkadot-wiki/translated_docs/ja/maintain-validator.md similarity index 100% rename from website/translated_docs/ja/maintain-validator.md rename to polkadot-wiki/translated_docs/ja/maintain-validator.md diff --git a/website/translated_docs/ja/maintain-wss.md b/polkadot-wiki/translated_docs/ja/maintain-wss.md similarity index 100% rename from website/translated_docs/ja/maintain-wss.md rename to polkadot-wiki/translated_docs/ja/maintain-wss.md diff --git a/website/translated_docs/ja/news.md b/polkadot-wiki/translated_docs/ja/news.md similarity index 100% rename from website/translated_docs/ja/news.md rename to polkadot-wiki/translated_docs/ja/news.md diff --git a/polkadot-wiki/translated_docs/ja/redenomination.md b/polkadot-wiki/translated_docs/ja/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ja/research.md b/polkadot-wiki/translated_docs/ja/research.md similarity index 100% rename from website/translated_docs/ja/research.md rename to polkadot-wiki/translated_docs/ja/research.md diff --git a/polkadot-wiki/translated_docs/ja/thousand-validators.md b/polkadot-wiki/translated_docs/ja/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ja/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ko/ambassadors.md b/polkadot-wiki/translated_docs/ko/ambassadors.md similarity index 100% rename from website/translated_docs/ko/ambassadors.md rename to polkadot-wiki/translated_docs/ko/ambassadors.md diff --git a/website/translated_docs/ko/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/ko/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/ko/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/ko/build-build-with-polkadot.md diff --git a/website/translated_docs/ko/build-cumulus.md b/polkadot-wiki/translated_docs/ko/build-cumulus.md similarity index 100% rename from website/translated_docs/ko/build-cumulus.md rename to polkadot-wiki/translated_docs/ko/build-cumulus.md diff --git a/website/translated_docs/ko/build-deploy-parachains.md b/polkadot-wiki/translated_docs/ko/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/ko/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/ko/build-deploy-parachains.md diff --git a/website/translated_docs/ko/build-dev-roadmap.md b/polkadot-wiki/translated_docs/ko/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/ko/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/ko/build-dev-roadmap.md diff --git a/website/translated_docs/ko/build-examples-index.md b/polkadot-wiki/translated_docs/ko/build-examples-index.md similarity index 100% rename from website/translated_docs/ko/build-examples-index.md rename to polkadot-wiki/translated_docs/ko/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/ko/build-exchange-integration.md b/polkadot-wiki/translated_docs/ko/build-exchange-integration.md new file mode 100644 index 000000000000..dddd3a779fac --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. Tracking the chain head + +Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). + +That will give you a stream of hashes of the most recent finalised headers. + +When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. + +If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. + +## 2. Decoding blocks + +You will need to decode blocks from the basic data into useful fields. + +All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. + +For Genesis Polkadot, the header format is a five-field structure: + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +It also relies on `Extrinsic`. An _extrinsic_ is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. + +The metadata itself is provided encoded in SCALE. Its format is: + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. + +Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various _modules_. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, _extrinsics_), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. Working with SS58 and account addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) _AccountId_. This is simply the public key for the x25519 cryptography used by Substrate. + +However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this _index_ to identify the account. This index is much smaller than the 32-byte _AccountId_, and can usually be encoded in just a couple of bytes. + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: + +`0x00 ` + +**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. + +Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. + +Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. + +### Looking up an index + +Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. + +The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. + +For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. + +This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. + +This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. + +Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. + +## 4. Working with balances + +In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. + +NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. + +The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10\*\*12). For completeness, The exact denominations of the Polkadot currency are: + +| Balance value | Name | +| ------------- | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### Transferring balances + +To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. + +In general, Polkadot's transactions are encoded as _signed_ `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. + +The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. + +NOTE: The nonce retrieved from storage does not take into account _pending_ transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. + +The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. + +The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. + +Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. + +Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +The `function` _in this case_ (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. + +The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. + +### Submitting and checking transactions + +Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. + +This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. + +The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. + +## Conclusion + +This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. + +If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). + +_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/polkadot-wiki/translated_docs/ko/build-extrinsic-format.md b/polkadot-wiki/translated_docs/ko/build-extrinsic-format.md new file mode 100644 index 000000000000..ca6f1cce2226 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/build-extrinsic-format.md @@ -0,0 +1,44 @@ +--- +id: build-extrinsic-format +title: Polkadot Extrinsic Format aka Transaction Format +sidebar_label: Polkadot Extrinsic Format aka Transaction Format +--- + +## 이전 포맷 + +참고로 **예전** 트랜잭션 포맷은 아래와 같습니다.: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length), 첫 세가지 필드에 서명 (account-id, index, call에 서명함 - 역자 주) (64 bytes) ] +``` + +## 현재 포맷 + +폴카닷(Polkadot) 트랜잭션 포맷은 아래와 같습니다.: + +``` +[ address (1/3/5/9/33-bytes, 첫번째 바이트에 따라 다름), index (4-bytes), call (dynamic-length), *오리지널* 필드에 서명함 (64 bytes) ] +``` + +_오리지널_ 필드들은 예전 트랜잭션 포맷에서 다음과 같은 요소들을 참조합니다. + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] +``` + +새 주소 타입을 위한 특정 형식은 아래 5개의 하위 형식 중 하나이며 첫 번째 바이트로 전환됩니다. + +- `0xff, 32-byte account id` +- `0xfe, 8-byte account index` +- `0xfd, 4-byte account index` +- `0xfc, 2-byte account index` +- `[0xf0...0xfb] (유효하지 않음, 나중에 사용하기 위해 남겨놓음)` +- `[0x00...0xef] 1-byte account index (0xf0보다 작음)` + +계정 인덱스 변형들은 상당히 작지만 스테이트에서 조회가 필요합니다. 인덱스가 계정을 변경할 때 트랜잭션 리플레이 어택을 피하기 위해 서명은 첫 번째 필드인 인덱스가 아닌 계정 ID로 서명되므로 이것때문에 인덱스가 다른 ID를 조회하는 데 사용되면 이전의 모든 서명이 무효화됩니다. + +발신자 필드 뿐만 아니라 이전 형식의 AccountId(32-bytes)였던 Call/Propose(PrivCall) 필드에 대한 파라매터는 이제 Address(1/3/5/9/33-bytes)입니다. + +## 출처 + +[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/polkadot-wiki/translated_docs/ko/build-hackathon.md b/polkadot-wiki/translated_docs/ko/build-hackathon.md new file mode 100644 index 000000000000..b575dbc79662 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/build-hackathon.md @@ -0,0 +1,63 @@ +--- +id: build-hackathon +title: Hackathon +sidebar_label: Hackathon +--- + +As one of our objectives in the Web3 Foundation is promoting the [Web3 technology stack](http://wiki.web3.foundation/en/latest/tech_stack/tech_stack_overview/), we would like to support any individual or team who wants to organize a hackathon that gets more developers to understand Polkadot and Substrate in your city or online. + +We are not only providing technical resources for you, but we can have someone from our team give a hands-on workshop/presentation about the technology to help participants get started hacking on it more quickly. + +## Ideas + +- NFT +- Bonded Tokens +- New governance pallets with different styles of voting & democracy +- Upgrade the TCR pallet +- IPFS integration +- 분산화된 신원 인증 솔루션 (Decentralized identity solutions) +- Oracle pallet +- 제네럴 스테이트 체널/플라즈마 체인의 구현 (Implement Generalized State Channel/Plasma Chain) +- DeX (Decentralized Exchange) +- 밸리데이터 퍼포먼스 모니터링 툴 (Tools for monitoring validator performance) +- dApps across different parachains + +## 왜 해커톤을 해야만 할까요? + +- Web3의 비전을 전달하는 것을 사랑하기 때문에 +- 최신 기술을 배우기 위해서 +- 개발자들이 어플리케이션을 만들기 위해 Web3 기술 스택이 알맞다는 것을 믿으니까 +- 사람들과 만나는 것을 좋아하니까 + +## 워크샵과 해커톤은 어떻게 다른가요? + +Hackathon is aimed at participants who want to deliver their prototype and demonstrate their ideas to reality in a short period (few hours - one day). Workshops are more for getting developers familiar with the tooling and understanding more about what are the resources currently available and how they can make use of it. + +## 어떻게 당신의 도시에서 해커톤을 열 수 있나요? + +1. 해커톤 지원서를 제출합니다 (Coming soon.) +2. 리뷰하고 +3. 결정한 뒤 +4. 진행합니다. + +## 어떻게 당신을 도와드릴 수 있을까요? + +- 기술적인 리소스나 자료들을 제공하고. +- 장소를 찾아보고. +- 원활한 해커톤 진행을 할 수 있도록 합니다. + +## Upcoming Hackathons + +- [Hello World! by Polkadot](https://gitcoin.co/hackathon/polkadot/onboard) - A collaborative hackathon celebrating the integration of Polkadot and Kusama into the Gitcoin platform. Has many sets of smaller challenges that will reward in either DOT or KSM. Open from 15 October - 12 November 2020. + +## Past Hackathons + +- [Hackusama](https://hackusama.devpost.com/) - A 7-week online hackathon being launched for developers to "Build a Blockchain" or submit your wildest tools, visualizations, and ideas to the "Open Hack" category. Many high quality submissions were received. + +## 참고 자료들 + +- [Substrate Knowledge Base](https://substrate.dev/docs/en/) + +## Support / Contact + +If you have any questions regarding organizing a hackathon, please free feel to contact us by [email](mailto:events@web3.foundation) or ask us via [Riot](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org) chat. diff --git a/website/translated_docs/ko/build-index.md b/polkadot-wiki/translated_docs/ko/build-index.md similarity index 100% rename from website/translated_docs/ko/build-index.md rename to polkadot-wiki/translated_docs/ko/build-index.md diff --git a/website/translated_docs/ko/build-integration.md b/polkadot-wiki/translated_docs/ko/build-integration.md similarity index 100% rename from website/translated_docs/ko/build-integration.md rename to polkadot-wiki/translated_docs/ko/build-integration.md diff --git a/polkadot-wiki/translated_docs/ko/build-networks.md b/polkadot-wiki/translated_docs/ko/build-networks.md new file mode 100644 index 000000000000..556115afc139 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/build-networks.md @@ -0,0 +1,71 @@ +--- +id: build-networks +title: Networks +sidebar_label: Networks +--- + +다음 커맨드들은 다른 네트워크들 끼리 연결하는데 사용 할 수 있습니다. + +## Development + +다음 명령어로 폴카닷(polkadot)을 설치하고 `polkadot` 바이너리를 `PATH`에 등록하세요. + +```bash +cargo install --git https://github.com/paritytech/polkadot.git polkadot +``` + +다음 명령어를 터미널에 입력해서 단순한 단일 노드 개발 "네트워크"를 작동 시킬 수 있습니다. + +```bash +polkadot --dev +``` + +http://github.com/paritytech/polka-ui나 http://github.com/paritytech/polkadot-ui을 클로닝하거나 만들면서 노닥거릴수 있습니다. 아니면 https://polkadot.js.org/apps을 가리킬 수도 있습니다. + +## Krumme Lanke (베를린 남서쪽에 있는 호수 이름 - 역자 주 ) + +Krumme Lanke는 PoC-2의 개발단계에서 사용했던 테스트넷 네트워크 입니다. 다음 명령어로 Polkadot PoC-2를 설치하고 `polkadot` 바이너리를 `PATH`에 등록하세요. + +글로벌 "Krumme Lanke" 테스트넷에 기본적으로 연결되어서 동작합니다. 명령어는 아래와 같습니다. + +```bash +cargo install --git https://github.com/paritytech/substrate.git --branch v0.2 polkadot +``` + +Alexander 는 PoC-3와 PoC-4 개발단계에서 사용했던 테스트넷 네트워크 입니다. 다음 명령어로 Polkadot PoC-4를 설치하고 `polkadot` 바이너리를 `PATH`에 등록하세요. + +```bash +polkadot +``` + +## Alexander (PoC-4) + +글로벌 "Alexander" 테스트넷에 기본적으로 연결되어서 동작합니다. 명령어는 아래와 같습니다. + +다중 노드 합의 알고리즘 실행을 로컬에서 보고 싶다면 로컬 testnet을 생성 할 수 있습니다. 두 개의 터미널이 열려 있어야합니다. 하나는 다음을 실행하십시오. + +```bash +cargo install --git https://github.com/paritytech/polkadot.git --branch v0.4 polkadot +``` + +다른 터미널에서는 다음 명령어를 실행하세요. + +```bash +polkadot +``` + +## 2개의 노드로 테스트넷 작동시키기 + +`ALICE_BOOTNODE_ID_HERE`를 첫 번째 터미널의 출력에서 노드 ID로 대체했는지 확인하십시오. + +```bash +polkadot --chain=local --validator --key Alice -d /tmp/alice +``` + +and in the other, run: + +```bash +polkadot --chain=local --validator --key Bob -d /tmp/bob --port 30334 --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE' +``` + +Ensure you replace `ALICE_BOOTNODE_ID_HERE` with the node ID from the output of the first terminal. diff --git a/website/translated_docs/ko/build-node-interaction.md b/polkadot-wiki/translated_docs/ko/build-node-interaction.md similarity index 100% rename from website/translated_docs/ko/build-node-interaction.md rename to polkadot-wiki/translated_docs/ko/build-node-interaction.md diff --git a/website/translated_docs/ko/build-node-management.md b/polkadot-wiki/translated_docs/ko/build-node-management.md similarity index 100% rename from website/translated_docs/ko/build-node-management.md rename to polkadot-wiki/translated_docs/ko/build-node-management.md diff --git a/website/translated_docs/ko/build-oracle.md b/polkadot-wiki/translated_docs/ko/build-oracle.md similarity index 100% rename from website/translated_docs/ko/build-oracle.md rename to polkadot-wiki/translated_docs/ko/build-oracle.md diff --git a/website/translated_docs/ko/build-parachains-rococo.md b/polkadot-wiki/translated_docs/ko/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/ko/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/ko/build-parachains-rococo.md diff --git a/website/translated_docs/ko/build-pdk.md b/polkadot-wiki/translated_docs/ko/build-pdk.md similarity index 100% rename from website/translated_docs/ko/build-pdk.md rename to polkadot-wiki/translated_docs/ko/build-pdk.md diff --git a/polkadot-wiki/translated_docs/ko/build-protocol-info.md b/polkadot-wiki/translated_docs/ko/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/polkadot-wiki/translated_docs/ko/build-rust-style-guide.md b/polkadot-wiki/translated_docs/ko/build-rust-style-guide.md new file mode 100644 index 000000000000..678bb58481ae --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/build-rust-style-guide.md @@ -0,0 +1,117 @@ +--- +id: build-rust-style-guide +title: Style Guide for Rust in Polkadot +sidebar_label: Style Guide for Rust in Polkadot +--- + +- Indent using tabs +- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. +- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. +- Never have spaces on a line prior to a non-whitespace character +- Follow-on lines are only ever a single indent from the original line. + +```rust +fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { + let x = some_long_variable_a * some_long_variable_b + - some_long_variable_b / some_long_variable_a + + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); + x > 10 +} +``` + +- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: + +```rust +fn calculate( + some_long_variable_a: f32, + some_long_variable_b: f32, + some_long_variable_c: f32, +) -> f32 { + (-some_long_variable_b + sqrt( + // two parens open, but since we open & close them both on the + // same line, only one indent level is used + some_long_variable_b * some_long_variable_b + - 4 * some_long_variable_a * some_long_variable_c + // both closed here at beginning of line, so back to the original indent + // level + )) / (2 * some_long_variable_a) +} +``` + +- `where` is indented, and its items are indented one further +- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. + +```rust +// OK +fn foo( + really_long_parameter_name_1: SomeLongTypeName, + really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, + shrt_nm_2: u8, +) { + ... +} + +// NOT OK +fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, shrt_nm_2: u8) { + ... +} + +``` + +```rust +{ + // Complex line (not just a function call, also a let statement). Full + // structure. + let (a, b) = bar( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Long, simple function call. + waz( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Short function call. Inline. + baz(a, b); +} +``` + +- Always end last item of a multi-line comma-delimited set with `,` when legal: + +```rust +struct Point { + x: T, + y: T, // <-- Multiline comma-delimited lists end with a trailing , +} + +// Single line comma-delimited items do not have a trailing `,` +enum Meal { Breakfast, Lunch, Dinner }; +``` + +- Avoid trailing `;`s where unneeded. + +```rust +if condition { + return 1 // <-- no ; here +} +``` + +- `match` arms may be either blocks or have a trailing `,` but not both. +- Blocks should not be used unnecessarily. + +```rust +match meal { + Meal::Breakfast => "eggs", + Meal::Lunch => { check_diet(); recipe() }, +// Meal::Dinner => { return Err("Fasting") } // WRONG + Meal::Dinner => return Err("Fasting"), +} +``` diff --git a/website/translated_docs/ko/build-smart-contracts.md b/polkadot-wiki/translated_docs/ko/build-smart-contracts.md similarity index 100% rename from website/translated_docs/ko/build-smart-contracts.md rename to polkadot-wiki/translated_docs/ko/build-smart-contracts.md diff --git a/website/translated_docs/ko/build-tools-index.md b/polkadot-wiki/translated_docs/ko/build-tools-index.md similarity index 100% rename from website/translated_docs/ko/build-tools-index.md rename to polkadot-wiki/translated_docs/ko/build-tools-index.md diff --git a/website/translated_docs/ko/build-tools-subkey.md b/polkadot-wiki/translated_docs/ko/build-tools-subkey.md similarity index 100% rename from website/translated_docs/ko/build-tools-subkey.md rename to polkadot-wiki/translated_docs/ko/build-tools-subkey.md diff --git a/polkadot-wiki/translated_docs/ko/build-transaction-construction.md b/polkadot-wiki/translated_docs/ko/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/ko/build-wallets.md b/polkadot-wiki/translated_docs/ko/build-wallets.md similarity index 100% rename from website/translated_docs/ko/build-wallets.md rename to polkadot-wiki/translated_docs/ko/build-wallets.md diff --git a/polkadot-wiki/translated_docs/ko/claims.md b/polkadot-wiki/translated_docs/ko/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ko/community.md b/polkadot-wiki/translated_docs/ko/community.md similarity index 100% rename from website/translated_docs/ko/community.md rename to polkadot-wiki/translated_docs/ko/community.md diff --git a/website/translated_docs/ko/contributing.md b/polkadot-wiki/translated_docs/ko/contributing.md similarity index 100% rename from website/translated_docs/ko/contributing.md rename to polkadot-wiki/translated_docs/ko/contributing.md diff --git a/website/translated_docs/ko/contributors.md b/polkadot-wiki/translated_docs/ko/contributors.md similarity index 100% rename from website/translated_docs/ko/contributors.md rename to polkadot-wiki/translated_docs/ko/contributors.md diff --git a/website/translated_docs/ko/ens.md b/polkadot-wiki/translated_docs/ko/ens.md similarity index 100% rename from website/translated_docs/ko/ens.md rename to polkadot-wiki/translated_docs/ko/ens.md diff --git a/website/translated_docs/ko/faq.md b/polkadot-wiki/translated_docs/ko/faq.md similarity index 100% rename from website/translated_docs/ko/faq.md rename to polkadot-wiki/translated_docs/ko/faq.md diff --git a/polkadot-wiki/translated_docs/ko/getting-started.md b/polkadot-wiki/translated_docs/ko/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ko/glossary.md b/polkadot-wiki/translated_docs/ko/glossary.md similarity index 100% rename from website/translated_docs/ko/glossary.md rename to polkadot-wiki/translated_docs/ko/glossary.md diff --git a/polkadot-wiki/translated_docs/ko/grants.md b/polkadot-wiki/translated_docs/ko/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ko/index.md b/polkadot-wiki/translated_docs/ko/index.md similarity index 100% rename from website/translated_docs/ko/index.md rename to polkadot-wiki/translated_docs/ko/index.md diff --git a/polkadot-wiki/translated_docs/ko/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/ko/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ko/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/ko/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/ko/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/ko/kusama-bug-bounty.md diff --git a/website/translated_docs/ko/kusama-claims.md b/polkadot-wiki/translated_docs/ko/kusama-claims.md similarity index 100% rename from website/translated_docs/ko/kusama-claims.md rename to polkadot-wiki/translated_docs/ko/kusama-claims.md diff --git a/website/translated_docs/ko/kusama-coc.md b/polkadot-wiki/translated_docs/ko/kusama-coc.md similarity index 100% rename from website/translated_docs/ko/kusama-coc.md rename to polkadot-wiki/translated_docs/ko/kusama-coc.md diff --git a/website/translated_docs/ko/kusama-community.md b/polkadot-wiki/translated_docs/ko/kusama-community.md similarity index 100% rename from website/translated_docs/ko/kusama-community.md rename to polkadot-wiki/translated_docs/ko/kusama-community.md diff --git a/website/translated_docs/ko/kusama-endpoints.md b/polkadot-wiki/translated_docs/ko/kusama-endpoints.md similarity index 100% rename from website/translated_docs/ko/kusama-endpoints.md rename to polkadot-wiki/translated_docs/ko/kusama-endpoints.md diff --git a/website/translated_docs/ko/kusama-faucet.md b/polkadot-wiki/translated_docs/ko/kusama-faucet.md similarity index 100% rename from website/translated_docs/ko/kusama-faucet.md rename to polkadot-wiki/translated_docs/ko/kusama-faucet.md diff --git a/website/translated_docs/ko/kusama-getting-started.md b/polkadot-wiki/translated_docs/ko/kusama-getting-started.md similarity index 100% rename from website/translated_docs/ko/kusama-getting-started.md rename to polkadot-wiki/translated_docs/ko/kusama-getting-started.md diff --git a/website/translated_docs/ko/kusama-index.md b/polkadot-wiki/translated_docs/ko/kusama-index.md similarity index 100% rename from website/translated_docs/ko/kusama-index.md rename to polkadot-wiki/translated_docs/ko/kusama-index.md diff --git a/polkadot-wiki/translated_docs/ko/kusama-ledger.md b/polkadot-wiki/translated_docs/ko/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/ko/kusama-parameters.md b/polkadot-wiki/translated_docs/ko/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ko/kusama-social-recovery.md b/polkadot-wiki/translated_docs/ko/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/ko/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/ko/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/ko/kusama-time-periods.md b/polkadot-wiki/translated_docs/ko/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ko/kusama-timeline.md b/polkadot-wiki/translated_docs/ko/kusama-timeline.md similarity index 100% rename from website/translated_docs/ko/kusama-timeline.md rename to polkadot-wiki/translated_docs/ko/kusama-timeline.md diff --git a/website/translated_docs/ko/learn-DOT.md b/polkadot-wiki/translated_docs/ko/learn-DOT.md similarity index 100% rename from website/translated_docs/ko/learn-DOT.md rename to polkadot-wiki/translated_docs/ko/learn-DOT.md diff --git a/website/translated_docs/ko/learn-PRE.md b/polkadot-wiki/translated_docs/ko/learn-PRE.md similarity index 100% rename from website/translated_docs/ko/learn-PRE.md rename to polkadot-wiki/translated_docs/ko/learn-PRE.md diff --git a/polkadot-wiki/translated_docs/ko/learn-UI.md b/polkadot-wiki/translated_docs/ko/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/ko/learn-account-generation.md b/polkadot-wiki/translated_docs/ko/learn-account-generation.md similarity index 100% rename from website/translated_docs/ko/learn-account-generation.md rename to polkadot-wiki/translated_docs/ko/learn-account-generation.md diff --git a/website/translated_docs/ko/learn-account-restore.md b/polkadot-wiki/translated_docs/ko/learn-account-restore.md similarity index 100% rename from website/translated_docs/ko/learn-account-restore.md rename to polkadot-wiki/translated_docs/ko/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/ko/learn-accounts.md b/polkadot-wiki/translated_docs/ko/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ko/learn-architecture.md b/polkadot-wiki/translated_docs/ko/learn-architecture.md similarity index 100% rename from website/translated_docs/ko/learn-architecture.md rename to polkadot-wiki/translated_docs/ko/learn-architecture.md diff --git a/website/translated_docs/ko/learn-auction.md b/polkadot-wiki/translated_docs/ko/learn-auction.md similarity index 100% rename from website/translated_docs/ko/learn-auction.md rename to polkadot-wiki/translated_docs/ko/learn-auction.md diff --git a/polkadot-wiki/translated_docs/ko/learn-availability.md b/polkadot-wiki/translated_docs/ko/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/ko/learn-balance-transfers.md b/polkadot-wiki/translated_docs/ko/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/ko/learn-bridges.md b/polkadot-wiki/translated_docs/ko/learn-bridges.md new file mode 100644 index 000000000000..ed3cbf926b90 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: 브릿지(Bridges) +sidebar_label: 브릿지(Bridges) +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ko/learn-collator.md b/polkadot-wiki/translated_docs/ko/learn-collator.md similarity index 100% rename from website/translated_docs/ko/learn-collator.md rename to polkadot-wiki/translated_docs/ko/learn-collator.md diff --git a/website/translated_docs/ko/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/ko/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/ko/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/ko/learn-comparison-dfinity.md diff --git a/website/translated_docs/ko/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/ko/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/ko/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/ko/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/ko/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/ko/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/ko/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/ko/learn-comparisons-cosmos.md diff --git a/website/translated_docs/ko/learn-comparisons.md b/polkadot-wiki/translated_docs/ko/learn-comparisons.md similarity index 100% rename from website/translated_docs/ko/learn-comparisons.md rename to polkadot-wiki/translated_docs/ko/learn-comparisons.md diff --git a/website/translated_docs/ko/learn-consensus.md b/polkadot-wiki/translated_docs/ko/learn-consensus.md similarity index 100% rename from website/translated_docs/ko/learn-consensus.md rename to polkadot-wiki/translated_docs/ko/learn-consensus.md diff --git a/website/translated_docs/ko/learn-crosschain.md b/polkadot-wiki/translated_docs/ko/learn-crosschain.md similarity index 100% rename from website/translated_docs/ko/learn-crosschain.md rename to polkadot-wiki/translated_docs/ko/learn-crosschain.md diff --git a/website/translated_docs/ko/learn-crowdloans.md b/polkadot-wiki/translated_docs/ko/learn-crowdloans.md similarity index 100% rename from website/translated_docs/ko/learn-crowdloans.md rename to polkadot-wiki/translated_docs/ko/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/ko/learn-cryptography.md b/polkadot-wiki/translated_docs/ko/learn-cryptography.md new file mode 100644 index 000000000000..893b7f130a6a --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: 암호화체계 부연 설명 +sidebar_label: 암호화체계 부연 설명 +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## 해시함수 알고리듬(Hashing Algorithm) + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## 키쌍과 전자서명(Keypairs and Signing) + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ko/learn-faq.md b/polkadot-wiki/translated_docs/ko/learn-faq.md similarity index 100% rename from website/translated_docs/ko/learn-faq.md rename to polkadot-wiki/translated_docs/ko/learn-faq.md diff --git a/polkadot-wiki/translated_docs/ko/learn-governance.md b/polkadot-wiki/translated_docs/ko/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ko/learn-identity.md b/polkadot-wiki/translated_docs/ko/learn-identity.md similarity index 100% rename from website/translated_docs/ko/learn-identity.md rename to polkadot-wiki/translated_docs/ko/learn-identity.md diff --git a/website/translated_docs/ko/learn-implementations.md b/polkadot-wiki/translated_docs/ko/learn-implementations.md similarity index 100% rename from website/translated_docs/ko/learn-implementations.md rename to polkadot-wiki/translated_docs/ko/learn-implementations.md diff --git a/website/translated_docs/ko/learn-implementers-guide.md b/polkadot-wiki/translated_docs/ko/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/ko/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/ko/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/ko/learn-interchain.md b/polkadot-wiki/translated_docs/ko/learn-interchain.md new file mode 100644 index 000000000000..2677ee91d812 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. + +The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. + +## Overview + +- Interchain messages will _not_ go on to the relay chain. +- Interchain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. + +## Example + +A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. + +When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/ko/learn-introduction.md b/polkadot-wiki/translated_docs/ko/learn-introduction.md similarity index 100% rename from website/translated_docs/ko/learn-introduction.md rename to polkadot-wiki/translated_docs/ko/learn-introduction.md diff --git a/website/translated_docs/ko/learn-keys.md b/polkadot-wiki/translated_docs/ko/learn-keys.md similarity index 100% rename from website/translated_docs/ko/learn-keys.md rename to polkadot-wiki/translated_docs/ko/learn-keys.md diff --git a/website/translated_docs/ko/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/ko/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/ko/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/ko/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/ko/learn-launch.md b/polkadot-wiki/translated_docs/ko/learn-launch.md similarity index 100% rename from website/translated_docs/ko/learn-launch.md rename to polkadot-wiki/translated_docs/ko/learn-launch.md diff --git a/website/translated_docs/ko/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/ko/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/ko/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/ko/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/ko/learn-ledger.md b/polkadot-wiki/translated_docs/ko/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ko/learn-nominator.md b/polkadot-wiki/translated_docs/ko/learn-nominator.md similarity index 100% rename from website/translated_docs/ko/learn-nominator.md rename to polkadot-wiki/translated_docs/ko/learn-nominator.md diff --git a/website/translated_docs/ko/learn-parachains.md b/polkadot-wiki/translated_docs/ko/learn-parachains.md similarity index 100% rename from website/translated_docs/ko/learn-parachains.md rename to polkadot-wiki/translated_docs/ko/learn-parachains.md diff --git a/website/translated_docs/ko/learn-parathreads.md b/polkadot-wiki/translated_docs/ko/learn-parathreads.md similarity index 100% rename from website/translated_docs/ko/learn-parathreads.md rename to polkadot-wiki/translated_docs/ko/learn-parathreads.md diff --git a/website/translated_docs/ko/learn-phragmen.md b/polkadot-wiki/translated_docs/ko/learn-phragmen.md similarity index 100% rename from website/translated_docs/ko/learn-phragmen.md rename to polkadot-wiki/translated_docs/ko/learn-phragmen.md diff --git a/website/translated_docs/ko/learn-polkadot-host.md b/polkadot-wiki/translated_docs/ko/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/ko/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/ko/learn-polkadot-host.md diff --git a/website/translated_docs/ko/learn-proxies.md b/polkadot-wiki/translated_docs/ko/learn-proxies.md similarity index 100% rename from website/translated_docs/ko/learn-proxies.md rename to polkadot-wiki/translated_docs/ko/learn-proxies.md diff --git a/website/translated_docs/ko/learn-randomness.md b/polkadot-wiki/translated_docs/ko/learn-randomness.md similarity index 100% rename from website/translated_docs/ko/learn-randomness.md rename to polkadot-wiki/translated_docs/ko/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/ko/learn-registrar.md b/polkadot-wiki/translated_docs/ko/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ko/learn-relevant-links.md b/polkadot-wiki/translated_docs/ko/learn-relevant-links.md similarity index 100% rename from website/translated_docs/ko/learn-relevant-links.md rename to polkadot-wiki/translated_docs/ko/learn-relevant-links.md diff --git a/website/translated_docs/ko/learn-roadmap.md b/polkadot-wiki/translated_docs/ko/learn-roadmap.md similarity index 100% rename from website/translated_docs/ko/learn-roadmap.md rename to polkadot-wiki/translated_docs/ko/learn-roadmap.md diff --git a/website/translated_docs/ko/learn-scams.md b/polkadot-wiki/translated_docs/ko/learn-scams.md similarity index 100% rename from website/translated_docs/ko/learn-scams.md rename to polkadot-wiki/translated_docs/ko/learn-scams.md diff --git a/website/translated_docs/ko/learn-security.md b/polkadot-wiki/translated_docs/ko/learn-security.md similarity index 100% rename from website/translated_docs/ko/learn-security.md rename to polkadot-wiki/translated_docs/ko/learn-security.md diff --git a/website/translated_docs/ko/learn-simple-payouts.md b/polkadot-wiki/translated_docs/ko/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/ko/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/ko/learn-simple-payouts.md diff --git a/website/translated_docs/ko/learn-spree.md b/polkadot-wiki/translated_docs/ko/learn-spree.md similarity index 100% rename from website/translated_docs/ko/learn-spree.md rename to polkadot-wiki/translated_docs/ko/learn-spree.md diff --git a/polkadot-wiki/translated_docs/ko/learn-staking.md b/polkadot-wiki/translated_docs/ko/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ko/learn-transaction-fees.md b/polkadot-wiki/translated_docs/ko/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/ko/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/ko/learn-transaction-fees.md diff --git a/website/translated_docs/ko/learn-transactions.md b/polkadot-wiki/translated_docs/ko/learn-transactions.md similarity index 100% rename from website/translated_docs/ko/learn-transactions.md rename to polkadot-wiki/translated_docs/ko/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/ko/learn-treasury.md b/polkadot-wiki/translated_docs/ko/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ko/learn-validator.md b/polkadot-wiki/translated_docs/ko/learn-validator.md similarity index 100% rename from website/translated_docs/ko/learn-validator.md rename to polkadot-wiki/translated_docs/ko/learn-validator.md diff --git a/website/translated_docs/ko/learn-wasm.md b/polkadot-wiki/translated_docs/ko/learn-wasm.md similarity index 100% rename from website/translated_docs/ko/learn-wasm.md rename to polkadot-wiki/translated_docs/ko/learn-wasm.md diff --git a/website/translated_docs/ko/maintain-collator.md b/polkadot-wiki/translated_docs/ko/maintain-collator.md similarity index 100% rename from website/translated_docs/ko/maintain-collator.md rename to polkadot-wiki/translated_docs/ko/maintain-collator.md diff --git a/website/translated_docs/ko/maintain-errors.md b/polkadot-wiki/translated_docs/ko/maintain-errors.md similarity index 100% rename from website/translated_docs/ko/maintain-errors.md rename to polkadot-wiki/translated_docs/ko/maintain-errors.md diff --git a/polkadot-wiki/translated_docs/ko/maintain-governance-index.md b/polkadot-wiki/translated_docs/ko/maintain-governance-index.md new file mode 100644 index 000000000000..8812e030de6c --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-governance-index.md @@ -0,0 +1,185 @@ +--- +id: maintain-governance-index +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. + +All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. + +The following steps are the governance procedure in the Polkadot network: + +- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) +- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) +- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) + +To better understand how the council is formed, please read [this section](#council). + +### Proposing Referenda + +- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. + +- **[Council](#council)**: + + Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. + + Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) + +### Voting for a proposal + +To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). + +``` +Example: + +Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes +``` + +According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. + +### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +voters - the total number of voting tokens + +electorate - the total number of DOTs tokens issued in the network +``` + +**Super-Majority Approve** + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ + +**Super-Majority Against** + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ + +**Simple-Majority** + +Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ + +_To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume we only have 1,500 DOTs tokens in total. + +John - 500 DOTs +Peter - 100 DOTs +Lilly - 150 DOTs +JJ - 150 DOTs +Ken - 600 DOTs + +John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +voters = 1050 +electorate = 1500 +``` + +$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ + +$${13.887} < {15.492}$$ + +Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. + +## Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: + +``` +Max votes = tokens * periods +``` + +Based on the current testnet setting, the maximum number of lock periods is set to 6. + +**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** + +## Adaptive Quorum Biasing + +Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. + +Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. + +Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. + +In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +## Council + +Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. + +To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. + +Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. + +Let's take a look at the example below. + +||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. + +### Resources + +- [Governance Description](learn-governance#referenda) +- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) + +## [Usage of DOT](learn-DOT#dots-for-governance) + +## Guides + +### [How to create a proposal]() + +### [How to join the council]() + +### [How to propose a referenda]() diff --git a/website/translated_docs/ko/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/ko/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-democracy.md diff --git a/website/translated_docs/ko/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/ko/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/ko/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/ko/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate-polkadot.md diff --git a/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate.md new file mode 100644 index 000000000000..20b9f634ea64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-nominate.md @@ -0,0 +1,59 @@ +--- +id: maintain-guides-how-to-nominate +title: How to nominate +sidebar_label: How to nominate +--- + +This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. + +It has been updated for the Alexander testnet and Polkadot release PoC-4. + +## Create `stash` and `controller` accounts + +We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. + +The first step is to create two accounts by going to the _Accounts_ tab on the Polkadot Dashboard and clicking on [_Add account_](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. + +![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) + +Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. + +## Nominating + +It is now time to setup our nominator. We will do the following: + +- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. +- Select the `controller`. This is the account that will decide when to start or stop nominating. + +First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. + +![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. +- **Controller account** - select the `controller` account created earlier. +- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). +- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). + +Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. + +![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) + +## Nominating a validator + +Go to the _Staking Overview_ tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. + +![Validators](assets/guides/how-to-nominate/validators.png) + +Go back to the _Account Actions_ tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). + +![Nominating](assets/guides/how-to-nominate/nominating.jpg) + +**Congratulations!** You are now a nominator. + +If you return to the _Staking Overview_ tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. + +![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) + +## How to stop nominating + +To stop nominating simply return to the _Account Actions_ tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/ko/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/ko/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/ko/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/ko/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/ko/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/ko/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/ko/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/ko/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/ko/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ko/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/ko/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ko/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/ko/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/ko/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/ko/maintain-guides-validator-payout.md diff --git a/website/translated_docs/ja/maintain-index.md b/polkadot-wiki/translated_docs/ko/maintain-index.md similarity index 100% rename from website/translated_docs/ja/maintain-index.md rename to polkadot-wiki/translated_docs/ko/maintain-index.md diff --git a/website/translated_docs/ko/maintain-networks.md b/polkadot-wiki/translated_docs/ko/maintain-networks.md similarity index 100% rename from website/translated_docs/ko/maintain-networks.md rename to polkadot-wiki/translated_docs/ko/maintain-networks.md diff --git a/website/translated_docs/ko/maintain-node-operator.md b/polkadot-wiki/translated_docs/ko/maintain-node-operator.md similarity index 100% rename from website/translated_docs/ko/maintain-node-operator.md rename to polkadot-wiki/translated_docs/ko/maintain-node-operator.md diff --git a/website/translated_docs/ko/maintain-nominator.md b/polkadot-wiki/translated_docs/ko/maintain-nominator.md similarity index 100% rename from website/translated_docs/ko/maintain-nominator.md rename to polkadot-wiki/translated_docs/ko/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/ko/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/ko/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ms-MY/maintain-sync.md b/polkadot-wiki/translated_docs/ko/maintain-sync.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-sync.md rename to polkadot-wiki/translated_docs/ko/maintain-sync.md diff --git a/website/translated_docs/ko/maintain-validator.md b/polkadot-wiki/translated_docs/ko/maintain-validator.md similarity index 100% rename from website/translated_docs/ko/maintain-validator.md rename to polkadot-wiki/translated_docs/ko/maintain-validator.md diff --git a/website/translated_docs/ko/maintain-wss.md b/polkadot-wiki/translated_docs/ko/maintain-wss.md similarity index 100% rename from website/translated_docs/ko/maintain-wss.md rename to polkadot-wiki/translated_docs/ko/maintain-wss.md diff --git a/website/translated_docs/ko/news.md b/polkadot-wiki/translated_docs/ko/news.md similarity index 100% rename from website/translated_docs/ko/news.md rename to polkadot-wiki/translated_docs/ko/news.md diff --git a/polkadot-wiki/translated_docs/ko/redenomination.md b/polkadot-wiki/translated_docs/ko/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ko/research.md b/polkadot-wiki/translated_docs/ko/research.md similarity index 100% rename from website/translated_docs/ko/research.md rename to polkadot-wiki/translated_docs/ko/research.md diff --git a/polkadot-wiki/translated_docs/ko/thousand-validators.md b/polkadot-wiki/translated_docs/ko/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ko/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ms-MY/ambassadors.md b/polkadot-wiki/translated_docs/ms-MY/ambassadors.md similarity index 100% rename from website/translated_docs/ms-MY/ambassadors.md rename to polkadot-wiki/translated_docs/ms-MY/ambassadors.md diff --git a/website/translated_docs/ms-MY/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/ms-MY/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/ms-MY/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/ms-MY/build-build-with-polkadot.md diff --git a/website/translated_docs/ms-MY/build-cumulus.md b/polkadot-wiki/translated_docs/ms-MY/build-cumulus.md similarity index 100% rename from website/translated_docs/ms-MY/build-cumulus.md rename to polkadot-wiki/translated_docs/ms-MY/build-cumulus.md diff --git a/website/translated_docs/ms-MY/build-deploy-parachains.md b/polkadot-wiki/translated_docs/ms-MY/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/ms-MY/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/ms-MY/build-deploy-parachains.md diff --git a/website/translated_docs/ms-MY/build-examples-index.md b/polkadot-wiki/translated_docs/ms-MY/build-examples-index.md similarity index 100% rename from website/translated_docs/ms-MY/build-examples-index.md rename to polkadot-wiki/translated_docs/ms-MY/build-examples-index.md diff --git a/website/translated_docs/ms-MY/build-hackathon.md b/polkadot-wiki/translated_docs/ms-MY/build-hackathon.md similarity index 100% rename from website/translated_docs/ms-MY/build-hackathon.md rename to polkadot-wiki/translated_docs/ms-MY/build-hackathon.md diff --git a/website/translated_docs/ms-MY/build-index.md b/polkadot-wiki/translated_docs/ms-MY/build-index.md similarity index 100% rename from website/translated_docs/ms-MY/build-index.md rename to polkadot-wiki/translated_docs/ms-MY/build-index.md diff --git a/website/translated_docs/ms-MY/build-integration.md b/polkadot-wiki/translated_docs/ms-MY/build-integration.md similarity index 100% rename from website/translated_docs/ms-MY/build-integration.md rename to polkadot-wiki/translated_docs/ms-MY/build-integration.md diff --git a/website/translated_docs/ms-MY/build-node-interaction.md b/polkadot-wiki/translated_docs/ms-MY/build-node-interaction.md similarity index 100% rename from website/translated_docs/ms-MY/build-node-interaction.md rename to polkadot-wiki/translated_docs/ms-MY/build-node-interaction.md diff --git a/website/translated_docs/ms-MY/build-node-management.md b/polkadot-wiki/translated_docs/ms-MY/build-node-management.md similarity index 100% rename from website/translated_docs/ms-MY/build-node-management.md rename to polkadot-wiki/translated_docs/ms-MY/build-node-management.md diff --git a/website/translated_docs/ms-MY/build-oracle.md b/polkadot-wiki/translated_docs/ms-MY/build-oracle.md similarity index 100% rename from website/translated_docs/ms-MY/build-oracle.md rename to polkadot-wiki/translated_docs/ms-MY/build-oracle.md diff --git a/website/translated_docs/ms-MY/build-parachains-rococo.md b/polkadot-wiki/translated_docs/ms-MY/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/ms-MY/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/ms-MY/build-parachains-rococo.md diff --git a/website/translated_docs/ms-MY/build-pdk.md b/polkadot-wiki/translated_docs/ms-MY/build-pdk.md similarity index 100% rename from website/translated_docs/ms-MY/build-pdk.md rename to polkadot-wiki/translated_docs/ms-MY/build-pdk.md diff --git a/polkadot-wiki/translated_docs/ms-MY/build-protocol-info.md b/polkadot-wiki/translated_docs/ms-MY/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ms-MY/build-smart-contracts.md b/polkadot-wiki/translated_docs/ms-MY/build-smart-contracts.md similarity index 100% rename from website/translated_docs/ms-MY/build-smart-contracts.md rename to polkadot-wiki/translated_docs/ms-MY/build-smart-contracts.md diff --git a/website/translated_docs/ms-MY/build-tools-index.md b/polkadot-wiki/translated_docs/ms-MY/build-tools-index.md similarity index 100% rename from website/translated_docs/ms-MY/build-tools-index.md rename to polkadot-wiki/translated_docs/ms-MY/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/ms-MY/build-transaction-construction.md b/polkadot-wiki/translated_docs/ms-MY/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/ms-MY/build-wallets.md b/polkadot-wiki/translated_docs/ms-MY/build-wallets.md similarity index 100% rename from website/translated_docs/ms-MY/build-wallets.md rename to polkadot-wiki/translated_docs/ms-MY/build-wallets.md diff --git a/polkadot-wiki/translated_docs/ms-MY/claims.md b/polkadot-wiki/translated_docs/ms-MY/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ms-MY/community.md b/polkadot-wiki/translated_docs/ms-MY/community.md similarity index 100% rename from website/translated_docs/ms-MY/community.md rename to polkadot-wiki/translated_docs/ms-MY/community.md diff --git a/website/translated_docs/ms-MY/contributing.md b/polkadot-wiki/translated_docs/ms-MY/contributing.md similarity index 100% rename from website/translated_docs/ms-MY/contributing.md rename to polkadot-wiki/translated_docs/ms-MY/contributing.md diff --git a/website/translated_docs/ms-MY/contributors.md b/polkadot-wiki/translated_docs/ms-MY/contributors.md similarity index 100% rename from website/translated_docs/ms-MY/contributors.md rename to polkadot-wiki/translated_docs/ms-MY/contributors.md diff --git a/website/translated_docs/ms-MY/ens.md b/polkadot-wiki/translated_docs/ms-MY/ens.md similarity index 100% rename from website/translated_docs/ms-MY/ens.md rename to polkadot-wiki/translated_docs/ms-MY/ens.md diff --git a/website/translated_docs/ms-MY/faq.md b/polkadot-wiki/translated_docs/ms-MY/faq.md similarity index 100% rename from website/translated_docs/ms-MY/faq.md rename to polkadot-wiki/translated_docs/ms-MY/faq.md diff --git a/polkadot-wiki/translated_docs/ms-MY/getting-started.md b/polkadot-wiki/translated_docs/ms-MY/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ms-MY/glossary.md b/polkadot-wiki/translated_docs/ms-MY/glossary.md similarity index 100% rename from website/translated_docs/ms-MY/glossary.md rename to polkadot-wiki/translated_docs/ms-MY/glossary.md diff --git a/polkadot-wiki/translated_docs/ms-MY/grants.md b/polkadot-wiki/translated_docs/ms-MY/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ms-MY/index.md b/polkadot-wiki/translated_docs/ms-MY/index.md similarity index 100% rename from website/translated_docs/ms-MY/index.md rename to polkadot-wiki/translated_docs/ms-MY/index.md diff --git a/polkadot-wiki/translated_docs/ms-MY/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/ms-MY/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ms-MY/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/ms-MY/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-bug-bounty.md diff --git a/website/translated_docs/ms-MY/kusama-claims.md b/polkadot-wiki/translated_docs/ms-MY/kusama-claims.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-claims.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-claims.md diff --git a/website/translated_docs/ms-MY/kusama-coc.md b/polkadot-wiki/translated_docs/ms-MY/kusama-coc.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-coc.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-coc.md diff --git a/website/translated_docs/ms-MY/kusama-community.md b/polkadot-wiki/translated_docs/ms-MY/kusama-community.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-community.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-community.md diff --git a/website/translated_docs/ms-MY/kusama-endpoints.md b/polkadot-wiki/translated_docs/ms-MY/kusama-endpoints.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-endpoints.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-endpoints.md diff --git a/website/translated_docs/ms-MY/kusama-faucet.md b/polkadot-wiki/translated_docs/ms-MY/kusama-faucet.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-faucet.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-faucet.md diff --git a/website/translated_docs/ms-MY/kusama-getting-started.md b/polkadot-wiki/translated_docs/ms-MY/kusama-getting-started.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-getting-started.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-getting-started.md diff --git a/website/translated_docs/ms-MY/kusama-index.md b/polkadot-wiki/translated_docs/ms-MY/kusama-index.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-index.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-index.md diff --git a/polkadot-wiki/translated_docs/ms-MY/kusama-ledger.md b/polkadot-wiki/translated_docs/ms-MY/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/ms-MY/kusama-parameters.md b/polkadot-wiki/translated_docs/ms-MY/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ms-MY/kusama-social-recovery.md b/polkadot-wiki/translated_docs/ms-MY/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/ms-MY/kusama-time-periods.md b/polkadot-wiki/translated_docs/ms-MY/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ms-MY/kusama-timeline.md b/polkadot-wiki/translated_docs/ms-MY/kusama-timeline.md similarity index 100% rename from website/translated_docs/ms-MY/kusama-timeline.md rename to polkadot-wiki/translated_docs/ms-MY/kusama-timeline.md diff --git a/website/translated_docs/ms-MY/learn-DOT.md b/polkadot-wiki/translated_docs/ms-MY/learn-DOT.md similarity index 100% rename from website/translated_docs/ms-MY/learn-DOT.md rename to polkadot-wiki/translated_docs/ms-MY/learn-DOT.md diff --git a/website/translated_docs/ms-MY/learn-account-generation.md b/polkadot-wiki/translated_docs/ms-MY/learn-account-generation.md similarity index 100% rename from website/translated_docs/ms-MY/learn-account-generation.md rename to polkadot-wiki/translated_docs/ms-MY/learn-account-generation.md diff --git a/website/translated_docs/ms-MY/learn-account-restore.md b/polkadot-wiki/translated_docs/ms-MY/learn-account-restore.md similarity index 100% rename from website/translated_docs/ms-MY/learn-account-restore.md rename to polkadot-wiki/translated_docs/ms-MY/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-accounts.md b/polkadot-wiki/translated_docs/ms-MY/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ms-MY/learn-architecture.md b/polkadot-wiki/translated_docs/ms-MY/learn-architecture.md similarity index 100% rename from website/translated_docs/ms-MY/learn-architecture.md rename to polkadot-wiki/translated_docs/ms-MY/learn-architecture.md diff --git a/website/translated_docs/ms-MY/learn-auction.md b/polkadot-wiki/translated_docs/ms-MY/learn-auction.md similarity index 100% rename from website/translated_docs/ms-MY/learn-auction.md rename to polkadot-wiki/translated_docs/ms-MY/learn-auction.md diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-availability.md b/polkadot-wiki/translated_docs/ms-MY/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-balance-transfers.md b/polkadot-wiki/translated_docs/ms-MY/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-bridges.md b/polkadot-wiki/translated_docs/ms-MY/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ms-MY/learn-collator.md b/polkadot-wiki/translated_docs/ms-MY/learn-collator.md similarity index 100% rename from website/translated_docs/ms-MY/learn-collator.md rename to polkadot-wiki/translated_docs/ms-MY/learn-collator.md diff --git a/website/translated_docs/ms-MY/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/ms-MY/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/ms-MY/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/ms-MY/learn-comparison-dfinity.md diff --git a/website/translated_docs/ms-MY/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/ms-MY/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/ms-MY/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/ms-MY/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/ms-MY/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/ms-MY/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/ms-MY/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/ms-MY/learn-comparisons-cosmos.md diff --git a/website/translated_docs/ms-MY/learn-comparisons.md b/polkadot-wiki/translated_docs/ms-MY/learn-comparisons.md similarity index 100% rename from website/translated_docs/ms-MY/learn-comparisons.md rename to polkadot-wiki/translated_docs/ms-MY/learn-comparisons.md diff --git a/website/translated_docs/ms-MY/learn-consensus.md b/polkadot-wiki/translated_docs/ms-MY/learn-consensus.md similarity index 100% rename from website/translated_docs/ms-MY/learn-consensus.md rename to polkadot-wiki/translated_docs/ms-MY/learn-consensus.md diff --git a/website/translated_docs/ms-MY/learn-crosschain.md b/polkadot-wiki/translated_docs/ms-MY/learn-crosschain.md similarity index 100% rename from website/translated_docs/ms-MY/learn-crosschain.md rename to polkadot-wiki/translated_docs/ms-MY/learn-crosschain.md diff --git a/website/translated_docs/ms-MY/learn-crowdloans.md b/polkadot-wiki/translated_docs/ms-MY/learn-crowdloans.md similarity index 100% rename from website/translated_docs/ms-MY/learn-crowdloans.md rename to polkadot-wiki/translated_docs/ms-MY/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-cryptography.md b/polkadot-wiki/translated_docs/ms-MY/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-governance.md b/polkadot-wiki/translated_docs/ms-MY/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ms-MY/learn-identity.md b/polkadot-wiki/translated_docs/ms-MY/learn-identity.md similarity index 100% rename from website/translated_docs/ms-MY/learn-identity.md rename to polkadot-wiki/translated_docs/ms-MY/learn-identity.md diff --git a/website/translated_docs/ms-MY/learn-implementations.md b/polkadot-wiki/translated_docs/ms-MY/learn-implementations.md similarity index 100% rename from website/translated_docs/ms-MY/learn-implementations.md rename to polkadot-wiki/translated_docs/ms-MY/learn-implementations.md diff --git a/website/translated_docs/ms-MY/learn-implementers-guide.md b/polkadot-wiki/translated_docs/ms-MY/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/ms-MY/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/ms-MY/learn-implementers-guide.md diff --git a/website/translated_docs/ms-MY/learn-introduction.md b/polkadot-wiki/translated_docs/ms-MY/learn-introduction.md similarity index 100% rename from website/translated_docs/ms-MY/learn-introduction.md rename to polkadot-wiki/translated_docs/ms-MY/learn-introduction.md diff --git a/website/translated_docs/ms-MY/learn-keys.md b/polkadot-wiki/translated_docs/ms-MY/learn-keys.md similarity index 100% rename from website/translated_docs/ms-MY/learn-keys.md rename to polkadot-wiki/translated_docs/ms-MY/learn-keys.md diff --git a/website/translated_docs/ms-MY/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/ms-MY/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/ms-MY/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/ms-MY/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/ms-MY/learn-launch.md b/polkadot-wiki/translated_docs/ms-MY/learn-launch.md similarity index 100% rename from website/translated_docs/ms-MY/learn-launch.md rename to polkadot-wiki/translated_docs/ms-MY/learn-launch.md diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-ledger.md b/polkadot-wiki/translated_docs/ms-MY/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ms-MY/learn-nominator.md b/polkadot-wiki/translated_docs/ms-MY/learn-nominator.md similarity index 100% rename from website/translated_docs/ms-MY/learn-nominator.md rename to polkadot-wiki/translated_docs/ms-MY/learn-nominator.md diff --git a/website/translated_docs/ms-MY/learn-parachains.md b/polkadot-wiki/translated_docs/ms-MY/learn-parachains.md similarity index 100% rename from website/translated_docs/ms-MY/learn-parachains.md rename to polkadot-wiki/translated_docs/ms-MY/learn-parachains.md diff --git a/website/translated_docs/ms-MY/learn-parathreads.md b/polkadot-wiki/translated_docs/ms-MY/learn-parathreads.md similarity index 100% rename from website/translated_docs/ms-MY/learn-parathreads.md rename to polkadot-wiki/translated_docs/ms-MY/learn-parathreads.md diff --git a/website/translated_docs/ms-MY/learn-phragmen.md b/polkadot-wiki/translated_docs/ms-MY/learn-phragmen.md similarity index 100% rename from website/translated_docs/ms-MY/learn-phragmen.md rename to polkadot-wiki/translated_docs/ms-MY/learn-phragmen.md diff --git a/website/translated_docs/ms-MY/learn-polkadot-host.md b/polkadot-wiki/translated_docs/ms-MY/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/ms-MY/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/ms-MY/learn-polkadot-host.md diff --git a/website/translated_docs/ms-MY/learn-proxies.md b/polkadot-wiki/translated_docs/ms-MY/learn-proxies.md similarity index 100% rename from website/translated_docs/ms-MY/learn-proxies.md rename to polkadot-wiki/translated_docs/ms-MY/learn-proxies.md diff --git a/website/translated_docs/ms-MY/learn-randomness.md b/polkadot-wiki/translated_docs/ms-MY/learn-randomness.md similarity index 100% rename from website/translated_docs/ms-MY/learn-randomness.md rename to polkadot-wiki/translated_docs/ms-MY/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-registrar.md b/polkadot-wiki/translated_docs/ms-MY/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ms-MY/learn-relevant-links.md b/polkadot-wiki/translated_docs/ms-MY/learn-relevant-links.md similarity index 100% rename from website/translated_docs/ms-MY/learn-relevant-links.md rename to polkadot-wiki/translated_docs/ms-MY/learn-relevant-links.md diff --git a/website/translated_docs/ms-MY/learn-roadmap.md b/polkadot-wiki/translated_docs/ms-MY/learn-roadmap.md similarity index 100% rename from website/translated_docs/ms-MY/learn-roadmap.md rename to polkadot-wiki/translated_docs/ms-MY/learn-roadmap.md diff --git a/website/translated_docs/ms-MY/learn-scams.md b/polkadot-wiki/translated_docs/ms-MY/learn-scams.md similarity index 100% rename from website/translated_docs/ms-MY/learn-scams.md rename to polkadot-wiki/translated_docs/ms-MY/learn-scams.md diff --git a/website/translated_docs/ms-MY/learn-security.md b/polkadot-wiki/translated_docs/ms-MY/learn-security.md similarity index 100% rename from website/translated_docs/ms-MY/learn-security.md rename to polkadot-wiki/translated_docs/ms-MY/learn-security.md diff --git a/website/translated_docs/ms-MY/learn-simple-payouts.md b/polkadot-wiki/translated_docs/ms-MY/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/ms-MY/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/ms-MY/learn-simple-payouts.md diff --git a/website/translated_docs/ms-MY/learn-spree.md b/polkadot-wiki/translated_docs/ms-MY/learn-spree.md similarity index 100% rename from website/translated_docs/ms-MY/learn-spree.md rename to polkadot-wiki/translated_docs/ms-MY/learn-spree.md diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-staking.md b/polkadot-wiki/translated_docs/ms-MY/learn-staking.md new file mode 100644 index 000000000000..5bb6dfc0fa74 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on secure validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ms-MY/learn-transaction-fees.md b/polkadot-wiki/translated_docs/ms-MY/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/ms-MY/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/ms-MY/learn-transaction-fees.md diff --git a/website/translated_docs/ms-MY/learn-transactions.md b/polkadot-wiki/translated_docs/ms-MY/learn-transactions.md similarity index 100% rename from website/translated_docs/ms-MY/learn-transactions.md rename to polkadot-wiki/translated_docs/ms-MY/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/ms-MY/learn-treasury.md b/polkadot-wiki/translated_docs/ms-MY/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ms-MY/learn-validator.md b/polkadot-wiki/translated_docs/ms-MY/learn-validator.md similarity index 100% rename from website/translated_docs/ms-MY/learn-validator.md rename to polkadot-wiki/translated_docs/ms-MY/learn-validator.md diff --git a/website/translated_docs/ms-MY/learn-wasm.md b/polkadot-wiki/translated_docs/ms-MY/learn-wasm.md similarity index 100% rename from website/translated_docs/ms-MY/learn-wasm.md rename to polkadot-wiki/translated_docs/ms-MY/learn-wasm.md diff --git a/website/translated_docs/ms-MY/maintain-collator.md b/polkadot-wiki/translated_docs/ms-MY/maintain-collator.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-collator.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-collator.md diff --git a/website/translated_docs/ms-MY/maintain-errors.md b/polkadot-wiki/translated_docs/ms-MY/maintain-errors.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-errors.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-errors.md diff --git a/website/translated_docs/ms-MY/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-democracy.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/ms-MY/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ms-MY/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ms-MY/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/ms-MY/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-guides-validator-payout.md diff --git a/website/translated_docs/ko/maintain-index.md b/polkadot-wiki/translated_docs/ms-MY/maintain-index.md similarity index 100% rename from website/translated_docs/ko/maintain-index.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-index.md diff --git a/website/translated_docs/ms-MY/maintain-networks.md b/polkadot-wiki/translated_docs/ms-MY/maintain-networks.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-networks.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-networks.md diff --git a/website/translated_docs/ms-MY/maintain-nominator.md b/polkadot-wiki/translated_docs/ms-MY/maintain-nominator.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-nominator.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/ms-MY/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/ms-MY/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/pt-BR/maintain-sync.md b/polkadot-wiki/translated_docs/ms-MY/maintain-sync.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-sync.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-sync.md diff --git a/website/translated_docs/ms-MY/maintain-validator.md b/polkadot-wiki/translated_docs/ms-MY/maintain-validator.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-validator.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-validator.md diff --git a/website/translated_docs/ms-MY/maintain-wss.md b/polkadot-wiki/translated_docs/ms-MY/maintain-wss.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-wss.md rename to polkadot-wiki/translated_docs/ms-MY/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/ms-MY/redenomination.md b/polkadot-wiki/translated_docs/ms-MY/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ms-MY/research.md b/polkadot-wiki/translated_docs/ms-MY/research.md similarity index 100% rename from website/translated_docs/ms-MY/research.md rename to polkadot-wiki/translated_docs/ms-MY/research.md diff --git a/polkadot-wiki/translated_docs/ms-MY/thousand-validators.md b/polkadot-wiki/translated_docs/ms-MY/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ms-MY/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/pt-BR/ambassadors.md b/polkadot-wiki/translated_docs/pt-BR/ambassadors.md similarity index 100% rename from website/translated_docs/pt-BR/ambassadors.md rename to polkadot-wiki/translated_docs/pt-BR/ambassadors.md diff --git a/website/translated_docs/pt-BR/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/pt-BR/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/pt-BR/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/pt-BR/build-build-with-polkadot.md diff --git a/website/translated_docs/pt-BR/build-cumulus.md b/polkadot-wiki/translated_docs/pt-BR/build-cumulus.md similarity index 100% rename from website/translated_docs/pt-BR/build-cumulus.md rename to polkadot-wiki/translated_docs/pt-BR/build-cumulus.md diff --git a/website/translated_docs/pt-BR/build-deploy-parachains.md b/polkadot-wiki/translated_docs/pt-BR/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/pt-BR/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/pt-BR/build-deploy-parachains.md diff --git a/website/translated_docs/pt-BR/build-examples-index.md b/polkadot-wiki/translated_docs/pt-BR/build-examples-index.md similarity index 100% rename from website/translated_docs/pt-BR/build-examples-index.md rename to polkadot-wiki/translated_docs/pt-BR/build-examples-index.md diff --git a/website/translated_docs/pt-BR/build-hackathon.md b/polkadot-wiki/translated_docs/pt-BR/build-hackathon.md similarity index 100% rename from website/translated_docs/pt-BR/build-hackathon.md rename to polkadot-wiki/translated_docs/pt-BR/build-hackathon.md diff --git a/website/translated_docs/pt-BR/build-index.md b/polkadot-wiki/translated_docs/pt-BR/build-index.md similarity index 100% rename from website/translated_docs/pt-BR/build-index.md rename to polkadot-wiki/translated_docs/pt-BR/build-index.md diff --git a/website/translated_docs/pt-BR/build-integration.md b/polkadot-wiki/translated_docs/pt-BR/build-integration.md similarity index 100% rename from website/translated_docs/pt-BR/build-integration.md rename to polkadot-wiki/translated_docs/pt-BR/build-integration.md diff --git a/website/translated_docs/pt-BR/build-node-interaction.md b/polkadot-wiki/translated_docs/pt-BR/build-node-interaction.md similarity index 100% rename from website/translated_docs/pt-BR/build-node-interaction.md rename to polkadot-wiki/translated_docs/pt-BR/build-node-interaction.md diff --git a/website/translated_docs/pt-BR/build-node-management.md b/polkadot-wiki/translated_docs/pt-BR/build-node-management.md similarity index 100% rename from website/translated_docs/pt-BR/build-node-management.md rename to polkadot-wiki/translated_docs/pt-BR/build-node-management.md diff --git a/website/translated_docs/pt-BR/build-oracle.md b/polkadot-wiki/translated_docs/pt-BR/build-oracle.md similarity index 100% rename from website/translated_docs/pt-BR/build-oracle.md rename to polkadot-wiki/translated_docs/pt-BR/build-oracle.md diff --git a/website/translated_docs/pt-BR/build-parachains-rococo.md b/polkadot-wiki/translated_docs/pt-BR/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/pt-BR/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/pt-BR/build-parachains-rococo.md diff --git a/website/translated_docs/pt-BR/build-pdk.md b/polkadot-wiki/translated_docs/pt-BR/build-pdk.md similarity index 100% rename from website/translated_docs/pt-BR/build-pdk.md rename to polkadot-wiki/translated_docs/pt-BR/build-pdk.md diff --git a/polkadot-wiki/translated_docs/pt-BR/build-protocol-info.md b/polkadot-wiki/translated_docs/pt-BR/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/pt-BR/build-smart-contracts.md b/polkadot-wiki/translated_docs/pt-BR/build-smart-contracts.md similarity index 100% rename from website/translated_docs/pt-BR/build-smart-contracts.md rename to polkadot-wiki/translated_docs/pt-BR/build-smart-contracts.md diff --git a/website/translated_docs/pt-BR/build-tools-index.md b/polkadot-wiki/translated_docs/pt-BR/build-tools-index.md similarity index 100% rename from website/translated_docs/pt-BR/build-tools-index.md rename to polkadot-wiki/translated_docs/pt-BR/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/pt-BR/build-transaction-construction.md b/polkadot-wiki/translated_docs/pt-BR/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/pt-BR/build-wallets.md b/polkadot-wiki/translated_docs/pt-BR/build-wallets.md similarity index 100% rename from website/translated_docs/pt-BR/build-wallets.md rename to polkadot-wiki/translated_docs/pt-BR/build-wallets.md diff --git a/polkadot-wiki/translated_docs/pt-BR/claims.md b/polkadot-wiki/translated_docs/pt-BR/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/pt-BR/community.md b/polkadot-wiki/translated_docs/pt-BR/community.md similarity index 100% rename from website/translated_docs/pt-BR/community.md rename to polkadot-wiki/translated_docs/pt-BR/community.md diff --git a/website/translated_docs/pt-BR/contributing.md b/polkadot-wiki/translated_docs/pt-BR/contributing.md similarity index 100% rename from website/translated_docs/pt-BR/contributing.md rename to polkadot-wiki/translated_docs/pt-BR/contributing.md diff --git a/website/translated_docs/pt-BR/contributors.md b/polkadot-wiki/translated_docs/pt-BR/contributors.md similarity index 100% rename from website/translated_docs/pt-BR/contributors.md rename to polkadot-wiki/translated_docs/pt-BR/contributors.md diff --git a/website/translated_docs/pt-BR/ens.md b/polkadot-wiki/translated_docs/pt-BR/ens.md similarity index 100% rename from website/translated_docs/pt-BR/ens.md rename to polkadot-wiki/translated_docs/pt-BR/ens.md diff --git a/website/translated_docs/pt-BR/faq.md b/polkadot-wiki/translated_docs/pt-BR/faq.md similarity index 100% rename from website/translated_docs/pt-BR/faq.md rename to polkadot-wiki/translated_docs/pt-BR/faq.md diff --git a/polkadot-wiki/translated_docs/pt-BR/getting-started.md b/polkadot-wiki/translated_docs/pt-BR/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/pt-BR/glossary.md b/polkadot-wiki/translated_docs/pt-BR/glossary.md similarity index 100% rename from website/translated_docs/pt-BR/glossary.md rename to polkadot-wiki/translated_docs/pt-BR/glossary.md diff --git a/polkadot-wiki/translated_docs/pt-BR/grants.md b/polkadot-wiki/translated_docs/pt-BR/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/pt-BR/index.md b/polkadot-wiki/translated_docs/pt-BR/index.md similarity index 100% rename from website/translated_docs/pt-BR/index.md rename to polkadot-wiki/translated_docs/pt-BR/index.md diff --git a/polkadot-wiki/translated_docs/pt-BR/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/pt-BR/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/pt-BR/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/pt-BR/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-bug-bounty.md diff --git a/website/translated_docs/pt-BR/kusama-claims.md b/polkadot-wiki/translated_docs/pt-BR/kusama-claims.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-claims.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-claims.md diff --git a/website/translated_docs/pt-BR/kusama-coc.md b/polkadot-wiki/translated_docs/pt-BR/kusama-coc.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-coc.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-coc.md diff --git a/website/translated_docs/pt-BR/kusama-community.md b/polkadot-wiki/translated_docs/pt-BR/kusama-community.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-community.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-community.md diff --git a/website/translated_docs/pt-BR/kusama-endpoints.md b/polkadot-wiki/translated_docs/pt-BR/kusama-endpoints.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-endpoints.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-endpoints.md diff --git a/website/translated_docs/pt-BR/kusama-faucet.md b/polkadot-wiki/translated_docs/pt-BR/kusama-faucet.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-faucet.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-faucet.md diff --git a/website/translated_docs/pt-BR/kusama-getting-started.md b/polkadot-wiki/translated_docs/pt-BR/kusama-getting-started.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-getting-started.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-getting-started.md diff --git a/website/translated_docs/pt-BR/kusama-index.md b/polkadot-wiki/translated_docs/pt-BR/kusama-index.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-index.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-index.md diff --git a/polkadot-wiki/translated_docs/pt-BR/kusama-ledger.md b/polkadot-wiki/translated_docs/pt-BR/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/pt-BR/kusama-parameters.md b/polkadot-wiki/translated_docs/pt-BR/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/pt-BR/kusama-social-recovery.md b/polkadot-wiki/translated_docs/pt-BR/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/pt-BR/kusama-time-periods.md b/polkadot-wiki/translated_docs/pt-BR/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/pt-BR/kusama-timeline.md b/polkadot-wiki/translated_docs/pt-BR/kusama-timeline.md similarity index 100% rename from website/translated_docs/pt-BR/kusama-timeline.md rename to polkadot-wiki/translated_docs/pt-BR/kusama-timeline.md diff --git a/website/translated_docs/pt-BR/learn-DOT.md b/polkadot-wiki/translated_docs/pt-BR/learn-DOT.md similarity index 100% rename from website/translated_docs/pt-BR/learn-DOT.md rename to polkadot-wiki/translated_docs/pt-BR/learn-DOT.md diff --git a/website/translated_docs/pt-BR/learn-account-generation.md b/polkadot-wiki/translated_docs/pt-BR/learn-account-generation.md similarity index 100% rename from website/translated_docs/pt-BR/learn-account-generation.md rename to polkadot-wiki/translated_docs/pt-BR/learn-account-generation.md diff --git a/website/translated_docs/pt-BR/learn-account-restore.md b/polkadot-wiki/translated_docs/pt-BR/learn-account-restore.md similarity index 100% rename from website/translated_docs/pt-BR/learn-account-restore.md rename to polkadot-wiki/translated_docs/pt-BR/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-accounts.md b/polkadot-wiki/translated_docs/pt-BR/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/pt-BR/learn-architecture.md b/polkadot-wiki/translated_docs/pt-BR/learn-architecture.md similarity index 100% rename from website/translated_docs/pt-BR/learn-architecture.md rename to polkadot-wiki/translated_docs/pt-BR/learn-architecture.md diff --git a/website/translated_docs/pt-BR/learn-auction.md b/polkadot-wiki/translated_docs/pt-BR/learn-auction.md similarity index 100% rename from website/translated_docs/pt-BR/learn-auction.md rename to polkadot-wiki/translated_docs/pt-BR/learn-auction.md diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-availability.md b/polkadot-wiki/translated_docs/pt-BR/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-balance-transfers.md b/polkadot-wiki/translated_docs/pt-BR/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-bridges.md b/polkadot-wiki/translated_docs/pt-BR/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/pt-BR/learn-collator.md b/polkadot-wiki/translated_docs/pt-BR/learn-collator.md similarity index 100% rename from website/translated_docs/pt-BR/learn-collator.md rename to polkadot-wiki/translated_docs/pt-BR/learn-collator.md diff --git a/website/translated_docs/pt-BR/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/pt-BR/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/pt-BR/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/pt-BR/learn-comparison-dfinity.md diff --git a/website/translated_docs/pt-BR/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/pt-BR/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/pt-BR/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/pt-BR/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/pt-BR/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/pt-BR/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/pt-BR/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/pt-BR/learn-comparisons-cosmos.md diff --git a/website/translated_docs/pt-BR/learn-comparisons.md b/polkadot-wiki/translated_docs/pt-BR/learn-comparisons.md similarity index 100% rename from website/translated_docs/pt-BR/learn-comparisons.md rename to polkadot-wiki/translated_docs/pt-BR/learn-comparisons.md diff --git a/website/translated_docs/pt-BR/learn-consensus.md b/polkadot-wiki/translated_docs/pt-BR/learn-consensus.md similarity index 100% rename from website/translated_docs/pt-BR/learn-consensus.md rename to polkadot-wiki/translated_docs/pt-BR/learn-consensus.md diff --git a/website/translated_docs/pt-BR/learn-crosschain.md b/polkadot-wiki/translated_docs/pt-BR/learn-crosschain.md similarity index 100% rename from website/translated_docs/pt-BR/learn-crosschain.md rename to polkadot-wiki/translated_docs/pt-BR/learn-crosschain.md diff --git a/website/translated_docs/pt-BR/learn-crowdloans.md b/polkadot-wiki/translated_docs/pt-BR/learn-crowdloans.md similarity index 100% rename from website/translated_docs/pt-BR/learn-crowdloans.md rename to polkadot-wiki/translated_docs/pt-BR/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-cryptography.md b/polkadot-wiki/translated_docs/pt-BR/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-governance.md b/polkadot-wiki/translated_docs/pt-BR/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/pt-BR/learn-identity.md b/polkadot-wiki/translated_docs/pt-BR/learn-identity.md similarity index 100% rename from website/translated_docs/pt-BR/learn-identity.md rename to polkadot-wiki/translated_docs/pt-BR/learn-identity.md diff --git a/website/translated_docs/pt-BR/learn-implementations.md b/polkadot-wiki/translated_docs/pt-BR/learn-implementations.md similarity index 100% rename from website/translated_docs/pt-BR/learn-implementations.md rename to polkadot-wiki/translated_docs/pt-BR/learn-implementations.md diff --git a/website/translated_docs/pt-BR/learn-implementers-guide.md b/polkadot-wiki/translated_docs/pt-BR/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/pt-BR/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/pt-BR/learn-implementers-guide.md diff --git a/website/translated_docs/pt-BR/learn-introduction.md b/polkadot-wiki/translated_docs/pt-BR/learn-introduction.md similarity index 100% rename from website/translated_docs/pt-BR/learn-introduction.md rename to polkadot-wiki/translated_docs/pt-BR/learn-introduction.md diff --git a/website/translated_docs/pt-BR/learn-keys.md b/polkadot-wiki/translated_docs/pt-BR/learn-keys.md similarity index 100% rename from website/translated_docs/pt-BR/learn-keys.md rename to polkadot-wiki/translated_docs/pt-BR/learn-keys.md diff --git a/website/translated_docs/pt-BR/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/pt-BR/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/pt-BR/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/pt-BR/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/pt-BR/learn-launch.md b/polkadot-wiki/translated_docs/pt-BR/learn-launch.md similarity index 100% rename from website/translated_docs/pt-BR/learn-launch.md rename to polkadot-wiki/translated_docs/pt-BR/learn-launch.md diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-ledger.md b/polkadot-wiki/translated_docs/pt-BR/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/pt-BR/learn-nominator.md b/polkadot-wiki/translated_docs/pt-BR/learn-nominator.md similarity index 100% rename from website/translated_docs/pt-BR/learn-nominator.md rename to polkadot-wiki/translated_docs/pt-BR/learn-nominator.md diff --git a/website/translated_docs/pt-BR/learn-parachains.md b/polkadot-wiki/translated_docs/pt-BR/learn-parachains.md similarity index 100% rename from website/translated_docs/pt-BR/learn-parachains.md rename to polkadot-wiki/translated_docs/pt-BR/learn-parachains.md diff --git a/website/translated_docs/pt-BR/learn-parathreads.md b/polkadot-wiki/translated_docs/pt-BR/learn-parathreads.md similarity index 100% rename from website/translated_docs/pt-BR/learn-parathreads.md rename to polkadot-wiki/translated_docs/pt-BR/learn-parathreads.md diff --git a/website/translated_docs/pt-BR/learn-phragmen.md b/polkadot-wiki/translated_docs/pt-BR/learn-phragmen.md similarity index 100% rename from website/translated_docs/pt-BR/learn-phragmen.md rename to polkadot-wiki/translated_docs/pt-BR/learn-phragmen.md diff --git a/website/translated_docs/pt-BR/learn-polkadot-host.md b/polkadot-wiki/translated_docs/pt-BR/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/pt-BR/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/pt-BR/learn-polkadot-host.md diff --git a/website/translated_docs/pt-BR/learn-proxies.md b/polkadot-wiki/translated_docs/pt-BR/learn-proxies.md similarity index 100% rename from website/translated_docs/pt-BR/learn-proxies.md rename to polkadot-wiki/translated_docs/pt-BR/learn-proxies.md diff --git a/website/translated_docs/pt-BR/learn-randomness.md b/polkadot-wiki/translated_docs/pt-BR/learn-randomness.md similarity index 100% rename from website/translated_docs/pt-BR/learn-randomness.md rename to polkadot-wiki/translated_docs/pt-BR/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-registrar.md b/polkadot-wiki/translated_docs/pt-BR/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/pt-BR/learn-relevant-links.md b/polkadot-wiki/translated_docs/pt-BR/learn-relevant-links.md similarity index 100% rename from website/translated_docs/pt-BR/learn-relevant-links.md rename to polkadot-wiki/translated_docs/pt-BR/learn-relevant-links.md diff --git a/website/translated_docs/pt-BR/learn-roadmap.md b/polkadot-wiki/translated_docs/pt-BR/learn-roadmap.md similarity index 100% rename from website/translated_docs/pt-BR/learn-roadmap.md rename to polkadot-wiki/translated_docs/pt-BR/learn-roadmap.md diff --git a/website/translated_docs/pt-BR/learn-scams.md b/polkadot-wiki/translated_docs/pt-BR/learn-scams.md similarity index 100% rename from website/translated_docs/pt-BR/learn-scams.md rename to polkadot-wiki/translated_docs/pt-BR/learn-scams.md diff --git a/website/translated_docs/pt-BR/learn-security.md b/polkadot-wiki/translated_docs/pt-BR/learn-security.md similarity index 100% rename from website/translated_docs/pt-BR/learn-security.md rename to polkadot-wiki/translated_docs/pt-BR/learn-security.md diff --git a/website/translated_docs/pt-BR/learn-simple-payouts.md b/polkadot-wiki/translated_docs/pt-BR/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/pt-BR/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/pt-BR/learn-simple-payouts.md diff --git a/website/translated_docs/pt-BR/learn-spree.md b/polkadot-wiki/translated_docs/pt-BR/learn-spree.md similarity index 100% rename from website/translated_docs/pt-BR/learn-spree.md rename to polkadot-wiki/translated_docs/pt-BR/learn-spree.md diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-staking.md b/polkadot-wiki/translated_docs/pt-BR/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/pt-BR/learn-transaction-fees.md b/polkadot-wiki/translated_docs/pt-BR/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/pt-BR/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/pt-BR/learn-transaction-fees.md diff --git a/website/translated_docs/pt-BR/learn-transactions.md b/polkadot-wiki/translated_docs/pt-BR/learn-transactions.md similarity index 100% rename from website/translated_docs/pt-BR/learn-transactions.md rename to polkadot-wiki/translated_docs/pt-BR/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/pt-BR/learn-treasury.md b/polkadot-wiki/translated_docs/pt-BR/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/pt-BR/learn-validator.md b/polkadot-wiki/translated_docs/pt-BR/learn-validator.md similarity index 100% rename from website/translated_docs/pt-BR/learn-validator.md rename to polkadot-wiki/translated_docs/pt-BR/learn-validator.md diff --git a/website/translated_docs/pt-BR/learn-wasm.md b/polkadot-wiki/translated_docs/pt-BR/learn-wasm.md similarity index 100% rename from website/translated_docs/pt-BR/learn-wasm.md rename to polkadot-wiki/translated_docs/pt-BR/learn-wasm.md diff --git a/website/translated_docs/pt-BR/maintain-collator.md b/polkadot-wiki/translated_docs/pt-BR/maintain-collator.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-collator.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-collator.md diff --git a/website/translated_docs/pt-BR/maintain-errors.md b/polkadot-wiki/translated_docs/pt-BR/maintain-errors.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-errors.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-errors.md diff --git a/website/translated_docs/pt-BR/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-democracy.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/pt-BR/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/pt-BR/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/pt-BR/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/pt-BR/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-guides-validator-payout.md diff --git a/website/translated_docs/ms-MY/maintain-index.md b/polkadot-wiki/translated_docs/pt-BR/maintain-index.md similarity index 100% rename from website/translated_docs/ms-MY/maintain-index.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-index.md diff --git a/website/translated_docs/pt-BR/maintain-networks.md b/polkadot-wiki/translated_docs/pt-BR/maintain-networks.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-networks.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-networks.md diff --git a/website/translated_docs/pt-BR/maintain-nominator.md b/polkadot-wiki/translated_docs/pt-BR/maintain-nominator.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-nominator.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/pt-BR/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/pt-BR/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ru/maintain-sync.md b/polkadot-wiki/translated_docs/pt-BR/maintain-sync.md similarity index 100% rename from website/translated_docs/ru/maintain-sync.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-sync.md diff --git a/website/translated_docs/pt-BR/maintain-validator.md b/polkadot-wiki/translated_docs/pt-BR/maintain-validator.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-validator.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-validator.md diff --git a/website/translated_docs/pt-BR/maintain-wss.md b/polkadot-wiki/translated_docs/pt-BR/maintain-wss.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-wss.md rename to polkadot-wiki/translated_docs/pt-BR/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/pt-BR/redenomination.md b/polkadot-wiki/translated_docs/pt-BR/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/pt-BR/research.md b/polkadot-wiki/translated_docs/pt-BR/research.md similarity index 100% rename from website/translated_docs/pt-BR/research.md rename to polkadot-wiki/translated_docs/pt-BR/research.md diff --git a/polkadot-wiki/translated_docs/pt-BR/thousand-validators.md b/polkadot-wiki/translated_docs/pt-BR/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-BR/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/pt-PT/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/pt-PT/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/pt-PT/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/pt-PT/build-build-with-polkadot.md diff --git a/website/translated_docs/pt-PT/build-cumulus.md b/polkadot-wiki/translated_docs/pt-PT/build-cumulus.md similarity index 100% rename from website/translated_docs/pt-PT/build-cumulus.md rename to polkadot-wiki/translated_docs/pt-PT/build-cumulus.md diff --git a/website/translated_docs/pt-PT/build-deploy-parachains.md b/polkadot-wiki/translated_docs/pt-PT/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/pt-PT/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/pt-PT/build-deploy-parachains.md diff --git a/website/translated_docs/pt-PT/build-examples-index.md b/polkadot-wiki/translated_docs/pt-PT/build-examples-index.md similarity index 100% rename from website/translated_docs/pt-PT/build-examples-index.md rename to polkadot-wiki/translated_docs/pt-PT/build-examples-index.md diff --git a/website/translated_docs/pt-PT/build-hackathon.md b/polkadot-wiki/translated_docs/pt-PT/build-hackathon.md similarity index 100% rename from website/translated_docs/pt-PT/build-hackathon.md rename to polkadot-wiki/translated_docs/pt-PT/build-hackathon.md diff --git a/website/translated_docs/pt-PT/build-index.md b/polkadot-wiki/translated_docs/pt-PT/build-index.md similarity index 100% rename from website/translated_docs/pt-PT/build-index.md rename to polkadot-wiki/translated_docs/pt-PT/build-index.md diff --git a/website/translated_docs/pt-PT/build-node-interaction.md b/polkadot-wiki/translated_docs/pt-PT/build-node-interaction.md similarity index 100% rename from website/translated_docs/pt-PT/build-node-interaction.md rename to polkadot-wiki/translated_docs/pt-PT/build-node-interaction.md diff --git a/website/translated_docs/pt-PT/build-node-management.md b/polkadot-wiki/translated_docs/pt-PT/build-node-management.md similarity index 100% rename from website/translated_docs/pt-PT/build-node-management.md rename to polkadot-wiki/translated_docs/pt-PT/build-node-management.md diff --git a/website/translated_docs/pt-PT/build-oracle.md b/polkadot-wiki/translated_docs/pt-PT/build-oracle.md similarity index 100% rename from website/translated_docs/pt-PT/build-oracle.md rename to polkadot-wiki/translated_docs/pt-PT/build-oracle.md diff --git a/website/translated_docs/pt-PT/build-pdk.md b/polkadot-wiki/translated_docs/pt-PT/build-pdk.md similarity index 100% rename from website/translated_docs/pt-PT/build-pdk.md rename to polkadot-wiki/translated_docs/pt-PT/build-pdk.md diff --git a/polkadot-wiki/translated_docs/pt-PT/build-protocol-info.md b/polkadot-wiki/translated_docs/pt-PT/build-protocol-info.md new file mode 100644 index 000000000000..107a8e6f4e82 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/build-protocol-info.md @@ -0,0 +1,171 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## DOT Tokens + +- **Token decimals:** See [Redenomination](#redenomination) +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination will take effect 72 hours after transfers are enabled. The projected block numbers and times are: + +| Event | Block Number | Earliest Time | +| :---------------- | :----------: | :--------------: | +| Transfers enabled | 1,205,128 | 18 Aug 13:15 UTC | +| Redenomination | 1,248,328 | 21 Aug 13:15 UTC | + +Block explorers, wallets, and any component that displays DOT balances should use the symbol "DOT (old)" to differentiate DOTs of the original denomination. This change can be made immediately. For a period of time after the redenomination occurs, we recommend that you use the symbol "_New DOT_" to clearly indicate that you have made the change. After sufficient time has elapsed post-redenomination, you should change "_New DOT_" back to "DOT". An example of an explanation would be: + +> “On approximately August 21st at 13:15 UTC (block number 1,248,328), the DOT token will undergo a redenomination. New DOTs will be 100x smaller than DOTs (old). Therefore, your DOT balance will be 100x higher. The percentage of the DOTs you own relative to total supply will be unchanged. See the Polkadot [blog post](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) for more information.” + +If you require assistance with redenomination, please contact redenomination@web3.foundation. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOTs with two locks on it: 150 DOTs for `Transfer` purposes and 100 DOTs for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOTs, but an operation could result in reserving DOTs such that the free balance is below 150, but above 100 DOTs. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/v2.0.0-rc4/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/v2.0.0-rc4/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOTs from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/pt-PT/build-smart-contracts.md b/polkadot-wiki/translated_docs/pt-PT/build-smart-contracts.md similarity index 100% rename from website/translated_docs/pt-PT/build-smart-contracts.md rename to polkadot-wiki/translated_docs/pt-PT/build-smart-contracts.md diff --git a/website/translated_docs/pt-PT/build-tools-index.md b/polkadot-wiki/translated_docs/pt-PT/build-tools-index.md similarity index 100% rename from website/translated_docs/pt-PT/build-tools-index.md rename to polkadot-wiki/translated_docs/pt-PT/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/pt-PT/build-transaction-construction.md b/polkadot-wiki/translated_docs/pt-PT/build-transaction-construction.md new file mode 100644 index 000000000000..656143afd844 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot JS Tools + +[Polkadot JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/polkadot-wiki/translated_docs/pt-PT/build-wallets.md b/polkadot-wiki/translated_docs/pt-PT/build-wallets.md new file mode 100644 index 000000000000..694126c89e72 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/build-wallets.md @@ -0,0 +1,38 @@ +--- +id: build-wallets +title: Polkadot Wallets +sidebar_label: Polkadot Wallets +--- + +## Polkadot Wallets + +The integration of a [wallet](https://wiki.polkadot.network/docs/en/glossary#wallet) with Polkadot allows for simple and easy access to private keys and signing transactions. Below are some wallets that support Polkadot along with their development statuses. Note that inclusion does not necessarily imply endorsement of that wallet. + +## Encryption Enhancement + +Wallets (JSON files) recently generated by the polkadot.js web app (or other applications which use the latest version of the Polkadot JS API) currently cannot be imported (restored) into some wallets, including the polkadot.js extension. This is due to an enhanced encryption method, which is also noticeable in a slight delay when encrypting/decrypting your wallet. The next version of the polkadot.js extension, which will be released soon, will support this new encryption. Other wallet software will also need to update to use the latest version of the Polkadot JS API before they will be able to use these wallets. + +If you are unable to load a JSON file in a wallet, try loading it in the Polkadot-JS web application. + +### Supported Wallets + +| Wallet Name | Development State | Team Name | Description | +| ------------------------------------------------------------------ | ----------------- | ----------- | ----------------------------------- | +| [Signer](https://www.parity.io/signer/) | Live | Parity | IOS and Android | +| [Polkadot-JS](https://polkadot.js.org/apps/#/accounts) | Live | Parity | Browser | +| [Polkadot.JS Plugin](https://github.com/polkadot-js/extension) | Live | Parity | Browser extension | +| [Polkawallet](https://polkawallet.io/) | Live | Polkawallet | IOS and Android | +| [Math Wallet](https://www.mathwallet.org/kusama-wallet/en/) | Live | Math Wallet | Browser extension | +| [Lunie](https://lunie.io/) | Live | Lunie | Browser extension | +| [ImToken](https://token.im/) | Live | ImToken | IOS and Android | +| [TokenPocket](https://www.tokenpocket.pro/) | Live | TokenPocket | IOS and Android | +| [Cobo Wallet](https://cobo.com/) | Building | Cobo | IOS and Android | +| [Polkadot{.js}](https://github.com/EthWorks/extension) | Building | EthWorks | Browser extension | +| [MetaMask](https://metamask.io/index.html) | Building | MetaMask | IOS, Android, and browser extension | +| [Speckle](https://github.com/GetSpeckle/speckle-browser-extension) | Building | Speckle | Browser extension | +| [Enzyme](https://getenzyme.dev/) | Building | BlockXLabs | Browser extension | +| [AirGap](https://airgap.it/) | Building | AirGap | IOS and Android | +| [Ledger App](https://zondax.ch/kusama.html#overview) | Building | Zondax | Hardware | +| [KodaDot](https://kodadot.netlify.app/#/accounts) | Building | Geefu | Browser | +| [Subwallet](https://github.com/yxf/subwallet) | Building | yxf | CLI Wallet | +| [Ownbit](https://ownbit.io/) | Building | Ownbit | IOS and Android | diff --git a/polkadot-wiki/translated_docs/pt-PT/claims.md b/polkadot-wiki/translated_docs/pt-PT/claims.md new file mode 100644 index 000000000000..2215bc87e7d2 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/claims.md @@ -0,0 +1,203 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOTs post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOTs with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOTs. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOTs into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.png) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.png) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.png) + +The hex-encoded string that follows the sentence: "Pay DOTs to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.png) ![claim-8](assets/new-claims/claim-8.png) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.png) + +If this claim succeeded, then you will see a success message and your DOTs will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOTs, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.png) + +Congratulations, you have now completed the process for claiming and signing for your DOTs. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.png) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.png) + +![claim-attest-4](assets/new-claims/new-attest-4.png) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOTs will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.png) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the PolkadotJS apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the PolkadotJS apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.png) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOTs to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the PolkadotJS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +![ps-claim-4](assets/new-claims/ps-claim-4.png) + +You will notice that the digit beside the "Claim Tokens" menu changed to 2. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the PolkadotJS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOTs will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/pt-PT/community.md b/polkadot-wiki/translated_docs/pt-PT/community.md similarity index 100% rename from website/translated_docs/pt-PT/community.md rename to polkadot-wiki/translated_docs/pt-PT/community.md diff --git a/website/translated_docs/pt-PT/contributing.md b/polkadot-wiki/translated_docs/pt-PT/contributing.md similarity index 100% rename from website/translated_docs/pt-PT/contributing.md rename to polkadot-wiki/translated_docs/pt-PT/contributing.md diff --git a/website/translated_docs/pt-PT/faq.md b/polkadot-wiki/translated_docs/pt-PT/faq.md similarity index 100% rename from website/translated_docs/pt-PT/faq.md rename to polkadot-wiki/translated_docs/pt-PT/faq.md diff --git a/website/translated_docs/pt-PT/getting-started.md b/polkadot-wiki/translated_docs/pt-PT/getting-started.md similarity index 100% rename from website/translated_docs/pt-PT/getting-started.md rename to polkadot-wiki/translated_docs/pt-PT/getting-started.md diff --git a/website/translated_docs/pt-PT/glossary.md b/polkadot-wiki/translated_docs/pt-PT/glossary.md similarity index 100% rename from website/translated_docs/pt-PT/glossary.md rename to polkadot-wiki/translated_docs/pt-PT/glossary.md diff --git a/polkadot-wiki/translated_docs/pt-PT/grants.md b/polkadot-wiki/translated_docs/pt-PT/grants.md new file mode 100644 index 000000000000..7be68296fbfe --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/grants.md @@ -0,0 +1,117 @@ +--- + +id: grants title: Web3 Foundation Grantees sidebar_label: Grants + +--- + +This page gives an overview of accepted grants and a link to their GitHub repositories. Keep in mind that not all of the accepted grants have already delivered software. + +--- + +## Table of Contents + +- [Wave 1 - First Quarter 2019](#wave-1) +- [Wave 2 - Second Quarter 2019](#wave-2) +- [Wave 3 - Third Quarter 2019](#wave-3) +- [Wave 4 - Fourth Quarter 2019](#wave-4) +- [Wave 5 - First Quarter 2020](#wave-5) + +## Wave 1 + +- [ChainSafe](https://chainsafe.io/) - Polkadot Host in Go (via an RFP) ([GitHub](https://github.com/ChainSafeSystems/gossamer)) +- [Soramitsu](https://soramitsu.co.jp/) - Polkadot Host in C++ (via an RFP) ([GitHub](https://github.com/soramitsu/kagome)) +- [WEB3SCAN](https://www.web3scan.com/) - Polkascan: Open Source Block Explorer ([GitHub](https://github.com/polkascan)) +- [Polkawallet](https://polkawallet.io/) - Mobile Wallet ([GitHub](https://github.com/polkawallet-io/polkawallet-RN)) +- [Validators](http://validators.com/) - Open Source Scalable Cluster ([GitHub](https://github.com/Validators)) +- [BlockX Labs](http://blockxlabs.com/) - Enzyme Browser extension wallet ([GitHub](https://github.com/blockxlabs/enzyme)) +- [Speckle OS](https://www.speckleos.io/) - Browser extension wallet ([GitHub](https://github.com/SpeckleOS/speckle-browser-extension)) +- [Noise Explorer](https://symbolic.software/) - Rust code generator for formally verified (Noise/ cryptographic) handshakes ([Source Code](https://source.symbolic.software/noiseexplorer/noiseexplorer)) +- [Protos](http://protosmanagement.com/) - Open Source Node Explorer +- [Supercomputing Systems](https://www.scs.ch/) - Substrate Transaction Privacy using Intel SGX ([GitHub](https://github.com/scs/substraTEE)) + +## Wave 2 + +- [Cap9](https://cap9.io/) - A low-level security protocol and framework for smart contracts ([GitHub](https://github.com/Daohub-io/cap9)) +- Substrate Java API - Java version of our JS API ([GitHub](https://github.com/polkadot-java)) +- [Starlog](https://pact.care/) - A metadata chain for IPFS ([GitHub](https://github.com/PACTCare/Starlog)) +- [MixBytes](https://mixbytes.io/) - Benchmarking tool for Substrate and Polkadot ([GitHub](https://github.com/mixbytes/tank)) +- [Gunclear](https://gunclear.io/) - Private secure data storage solution using Plasma Cash in Substrate ([GitHub](https://github.com/GunClear)) +- [ZeroChain](https://layerx.co.jp/) - Zero knowledge transactions in Substrate ([GitHub](https://github.com/LayerXcom/zero-chain)) +- [Robonomics](https://aira.life/en/) - Substrate modules for controlling robots ([GitHub](https://github.com/airalab/substrate-node-robonomics)) +- [Avado](https://ava.do/) - Polkadot node deployment with consumer hardware (GitHub) +- [Stake Technologies](https://stake.co.jp/) - Plasma modules for Substrate ([GitHub](https://github.com/stakedtechnologies/Plasm)) +- [HOPR](https://hopr.network/) - Substrate integration with this P2P messaging protocol ([GitHub](https://github.com/validitylabs/HOPR-PL-Substrate)) +- [Mailchain](https://mailchain.xyz/) - a Multi-Blockchain Messaging Application ([GitHub](https://github.com/mailchain)) +- [Usetech](http://usetech.com/blockchain.html) - Polkadot C++ API ([GitHub](https://github.com/usetech-llc/polkadot_api_cpp)) + +## Wave 3 + +- [Supercomputing systems](http://scs.ch/) - Substrate Rust API client ([GitHub](https://github.com/scs/substrate-api-client)) +- [NGRAVE](https://ngrave.io/) - Substrate Hardware Wallet Integration +- [Caelum Labs](https://caelumlabs.com/) - Decentralised identity modules +- [Runtime Verification](https://runtimeverification.com/) - Build executable K specifications of the SRML ([GitHub](https://github.com/runtimeverification/polkadot-verification)) +- [Attic Lab](https://atticlab.net/) - VS Code and Atom plugins ([GitHub](https://github.com/everstake/VSCode-Atom-Plugin)) +- [Dock](http://dock.io/) - Verifiable Claims +- [Blockdaemon](https://blockdaemon.com/) - Polkadot Package Manager ([GitHub](https://github.com/Blockdaemon/bpm-sdk)) +- [Zondax](http://zondax.ch/) - Ledger app for Polkadot ([GitHub](https://github.com/ZondaX/ledger-polkadot)) +- [Geefu](https://www.geefu.net/) - Vue JS components for Polkadot JS apps ([GitHub](https://github.com/vue-polkadot)) +- [Centrifuge](https://centrifuge.io/) - Substrate Go API client ([GitHub](http://github.com/centrifuge)) +- [Litentry](https://www.litentry.com/) - Identity modules and corresponding UIs ([GitHub](https://github.com/litentry/litentry-runtime)) +- [Subsocial](http://subsocial.network) - Substrate modules with web UI for decentralized social networks and marketplaces ([GitHub](https://github.com/dappforce/dappforce-subsocial)) +- [pLibra ](https://plibra.io/)- Bridge between Polkadot and a Libra chain ([GitHub](https://github.com/libra-china-org)) +- [Wiv ](http://wiv.io/)- Supply chain modules and front-end UI ([GitHub](https://github.com/wivtech)) + +## Wave 4 + +- [Genesis Lab](https://genesislab.net/) - Validator Tracker ([GitHub](https://github.com/genesis-lab-team)) +- [Usetech](http://usetech.com/blockchain.html) - Substrate API in .NET ([GitHub](https://github.com/usetech-llc/polkadot_api_dotnet)) +- [BlockX Labs](http://blockxlabs.com/) - Enzyme Browser extension wallet ([GitHub](https://github.com/blockxlabs/enzyme)) +- [WEB3SCAN](https://www.web3scan.com/) - Python API client ([GitHub](https://github.com/polkascan)) +- [Galactic Council](https://github.com/galacticcouncil) - Polkalert: Validator Monitoring ([GitHub](https://github.com/galacticcouncil/polkalert)) +- [Bandot](http://bandot.io/) - Stablecoin ([GitHub](https://github.com/bandotorg/Bandot)) +- [Laminar One](https://laminar.one/) - LaminarChain: High performance Flow Protocols powering synthetic asset and margin trading ([GitHub](https://github.com/laminar-protocol/laminar-chain)) +- [Stake Technologies](https://stake.co.jp/) - Ink! Playground ([GitHub](https://github.com/staketechnologies/ink-playground)) +- [B-Harvest](https://bharvest.io/) - Node Monitoring Tool ([GitHub](https://github.com/b-harvest)) +- [Simply VC](https://simply-vc.com.mt/) - P.A.N.I.C. Validator alerting solution ([GitHub](https://github.com/SimplyVC/panic_polkadot)) +- [Ethworks](https://ethworks.io/) - Polkadot{.js} extension improvements ([GitHub](https://github.com/ethWorks)) +- [Lyken Software Solutions](https://lyken.rs/) - Investigation of runtime compilation +- [Blockchain IT](https://blockchain-it.hr) - Ink! Remix Plugin ([GitHub](https://github.com/blockchain-it-hr/ink-remix-plugin)) +- [Kadena](https://www.kadena.io/) - Pact feasibility study ([GitHub](https://github.com/kadena-io/)) +- [STAFI Protocol](http://www.stafi.io/) - Stafi is a protocol to provide liquidity for staking assets ([GitHub](https://github.com/stafiprotocol/stafi-node)) +- [Vision Baker](https://playproject.io/) - DatDot - Dat protocol for Polkadot ([GitHub](https://github.com/playproject-io/datdot)) +- [Speckle OS](https://www.speckleos.io/) - Integrating additional features into Speckle OS ([GitHub](https://github.com/SpeckleOS/speckle-browser-extension)) +- [Archipel](https://archipel.id/) - Solution to resolve high availability problem of Validator nodes in PoS ([GitHub](https://github.com/luguslabs/archipel)) +- [Zondax](https://zondax.ch/) - Flexible TrustZone-based HSM stack ([GitHub](https://github.com/ZondaX)) +- [Usetech](http://usetech.com/blockchain.html) - SR25519 library in pure C and C# ([GitHub](https://github.com/usetech-llc/)) +- [Akropolis](https://akropolis.io/) - PolkaHub - Heroku-like infrastructure for node deployment ([GitHub](https://github.com/akropolisio)) +- [Pixura](https://pixura.io/) - Substrate API client in Haskell ([GitHub](https://github.com/Pixura)) +- [HashQuark](https://www.hashquark.io/) - Validator Dashboard ([GitHub](https://github.com/hashquark-research)) +- [Stacktical](https://stacktical.com/) - Performance Management Runtime Modules ([GitHub](https://github.com/Stacktical)) +- [Sean Young](https://www.mess.org/) - Solidity to WASM compiler ([GitHub](https://github.com/hyperledger-labs/solang)) +- [Chain Security](https://chainsecurity.com/) - Tool for validating correctness of Polkadot runtimes ([GitHub](https://github.com/ChainSecurity)) + +## Wave 5 + +- [Bifrost](https://bifrost.codes/) - EOS interoperable bridge ([GitHub](https://github.com/bifrost-codes)) +- [Entropy Labs](https://entropylabs.hk) - A toolkit for building and deploying applications with substrate +- [Papers GmbH](https://airgap.it) - AirGap - Desktop (+mobile) wallet for Polkadot ([GitHub](https://github.com/airgap-it)) +- [Stake Technologies](https://stake.co.jp/) - Plasm Chain + OVM Implementation ([GitHub](https://github.com/stakedtechnologies/)) +- [Usetech](http://usetech.com/blockchain.html) - PostgreSQL Indexer and Consensus Insurer ([GitHub](https://github.com/usetech-llc/)) +- [ACALA PTE. LTD.](https://acala.network/) - A decentralized stablecoin platform +- [ETCDEV](https://emeraldpay.io/) - Polkadot Network Crawler ([GitHub](https://github.com/emeraldpay)) +- [Xaya](https://xaya.io/) - Decentralised Complex Gaming([GitHub](https://github.com/xaya)) +- [Celer](https://www.celer.network/) - Layer 2 Scaling Infrastructure ([GitHub](https://github.com/celer-network)) +- [Cryptoeconomics Lab](https://www.cryptoeconomicslab.com/) - Substrate adapter of Plasma child chain ([GitHub](https://github.com/cryptoeconomicslab)) +- [Centrifuge](https://centrifuge.io/) - Substrate / Ethereum Bridge ([GitHub](https://github.com/centrifuge/)) +- Advanca - Privacy-preserving general-purpose compute/storage layer +- [Nodle](https://nodle.io) - Securely identify, certify and verify IoT devices ([GitHub](http://github.com/NodleCode/)) +- [Figment](https://figment.network/) - DotHub: Information Hub for validators and delegators ([GitHub](https://github.com/figment-networks/dothub)) +- [Lunie](http://lunie.io/) - Web and mobile wallet ([GitHub](https://github.com/luniehq/lunie)) +- [Web3 Gardens](https://web3.garden) - Runtime modules and UI for creating stable, well-governed communities on Substrate ([GitHub](https://github.com/web3garden/sunshine)) +- [Itering](https://itering.com/) - Ruby Substrate API ([GitHub](https://github.com/itering)) +- [WEB3SCAN](https://www.web3scan.com/) - Identity Pallet for Polkascan ([GitHub](https://github.com/polkascan)) +- [Swisscom Blockchain AG](https://www.blockchain.swisscom.com/) - Kubernetes Operator for Sentry nodes or Validators deployment ([GitHub](https://github.com/swisscom-blockchain)) +- [Polkastats](https://polkastats.io/) - Polkadot/Kusama network statistics ([GitHub](https://github.com/Colm3na/polkastats-v3)) +- [Supercomputing Systems](https://www.scs.ch/) - SubstraTEE extension pack ([GitHub](https://github.com/scs/substraTEE)) +- [Encointer](https://encointer.org/) - An Ecological, Egalitarian and Private Cryptocurrency and Self-Sovereign Identity System ([GitHub](https://github.com/encointer)) +- [FlexDapps](https://flexdapps.com/) - Gantree is a full-service node infrastructure toolkit for Substrate-based blockchains ([GitHub](https://github.com/flex-dapps)) diff --git a/website/translated_docs/pt-PT/index.md b/polkadot-wiki/translated_docs/pt-PT/index.md similarity index 100% rename from website/translated_docs/pt-PT/index.md rename to polkadot-wiki/translated_docs/pt-PT/index.md diff --git a/polkadot-wiki/translated_docs/pt-PT/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/pt-PT/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/pt-PT/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/pt-PT/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-bug-bounty.md diff --git a/website/translated_docs/pt-PT/kusama-claims.md b/polkadot-wiki/translated_docs/pt-PT/kusama-claims.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-claims.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-claims.md diff --git a/website/translated_docs/pt-PT/kusama-coc.md b/polkadot-wiki/translated_docs/pt-PT/kusama-coc.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-coc.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-coc.md diff --git a/website/translated_docs/pt-PT/kusama-community.md b/polkadot-wiki/translated_docs/pt-PT/kusama-community.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-community.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-community.md diff --git a/website/translated_docs/pt-PT/kusama-endpoints.md b/polkadot-wiki/translated_docs/pt-PT/kusama-endpoints.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-endpoints.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-endpoints.md diff --git a/website/translated_docs/pt-PT/kusama-faucet.md b/polkadot-wiki/translated_docs/pt-PT/kusama-faucet.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-faucet.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-faucet.md diff --git a/website/translated_docs/pt-PT/kusama-getting-started.md b/polkadot-wiki/translated_docs/pt-PT/kusama-getting-started.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-getting-started.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-getting-started.md diff --git a/website/translated_docs/pt-PT/kusama-index.md b/polkadot-wiki/translated_docs/pt-PT/kusama-index.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-index.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-index.md diff --git a/website/translated_docs/pt-PT/kusama-social-recovery.md b/polkadot-wiki/translated_docs/pt-PT/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/pt-PT/kusama-time-periods.md b/polkadot-wiki/translated_docs/pt-PT/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/pt-PT/kusama-timeline.md b/polkadot-wiki/translated_docs/pt-PT/kusama-timeline.md similarity index 100% rename from website/translated_docs/pt-PT/kusama-timeline.md rename to polkadot-wiki/translated_docs/pt-PT/kusama-timeline.md diff --git a/website/translated_docs/pt-PT/learn-DOT.md b/polkadot-wiki/translated_docs/pt-PT/learn-DOT.md similarity index 100% rename from website/translated_docs/pt-PT/learn-DOT.md rename to polkadot-wiki/translated_docs/pt-PT/learn-DOT.md diff --git a/website/translated_docs/pt-PT/learn-account-generation.md b/polkadot-wiki/translated_docs/pt-PT/learn-account-generation.md similarity index 100% rename from website/translated_docs/pt-PT/learn-account-generation.md rename to polkadot-wiki/translated_docs/pt-PT/learn-account-generation.md diff --git a/website/translated_docs/pt-PT/learn-account-restore.md b/polkadot-wiki/translated_docs/pt-PT/learn-account-restore.md similarity index 100% rename from website/translated_docs/pt-PT/learn-account-restore.md rename to polkadot-wiki/translated_docs/pt-PT/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/pt-PT/learn-accounts.md b/polkadot-wiki/translated_docs/pt-PT/learn-accounts.md new file mode 100644 index 000000000000..990239738f70 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/learn-accounts.md @@ -0,0 +1,171 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are merely different representations of the same public key in a private-public keypair generated by an address generation tool (see next section). This makes the addresses cross-Substrate-chain-compatible as long as you convert the format. + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Kusama address is through the [Polkadot JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [PolkadotJS extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. Creating cold storage is as simple as securely stashing away the seed phrase for your accounts and removing all traces of the accounts from your computer. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/) but it currently only supports Kusama addresses, not Polkadot or generic Substrate. + +Alternatively, you might find some wallets on the [Polkaproject.com page](http://www.polkaproject.com/) but bear in mind that these are **unaudited** and not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +Hardware wallet integration from [Ledger](https://ledger.com) is coming soon. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit - 0.01 KSM / DOT. This deposit is paid by the account sending you tokens. The one "creating" you pays for your creation. + +Going below 0.01 causes an account to be _reaped_. Your account will be wiped from the blockchain's state to conserve space. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama address can have an index. An index is like a short and easy to remember version of an address. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +Because of this unreliability of indices, they **may not be present** in Polkadot mainnet. + +## Identities + +The _Identities_ pallet built into Kusama allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` and the DepositFactor is equal to `deposit(0,32)`. + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/kusama/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot | Kusama | +| ------------- | ------------ | --------------- | +| DepositBase | 200880000000 | 3347999999941.4 | +| DepositFactor | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit 0.20152 DOTs while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. diff --git a/website/translated_docs/pt-PT/learn-architecture.md b/polkadot-wiki/translated_docs/pt-PT/learn-architecture.md similarity index 100% rename from website/translated_docs/pt-PT/learn-architecture.md rename to polkadot-wiki/translated_docs/pt-PT/learn-architecture.md diff --git a/website/translated_docs/pt-PT/learn-auction.md b/polkadot-wiki/translated_docs/pt-PT/learn-auction.md similarity index 100% rename from website/translated_docs/pt-PT/learn-auction.md rename to polkadot-wiki/translated_docs/pt-PT/learn-auction.md diff --git a/polkadot-wiki/translated_docs/pt-PT/learn-availability.md b/polkadot-wiki/translated_docs/pt-PT/learn-availability.md new file mode 100644 index 000000000000..69c8563590cb --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Life of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/pt-PT/learn-bridges.md b/polkadot-wiki/translated_docs/pt-PT/learn-bridges.md new file mode 100644 index 000000000000..c2ec3f78b621 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/learn-bridges.md @@ -0,0 +1,82 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible for external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +# Types of bridges + +There are two types of bridges in the Polkadot ecosystem. + +- _Bridge modules_ - Bridge modules are possibly system-level or community-deployed parachains that serve a distinct purpose as consensus-adaptors to external chains. +- _Bridge contracts_ - Similar to bridge modules, however they exist on specific parachains that support smart contracts. + +## Bridge modules + +Receiving messages on Polkadot from an external, non-parachain blockchain can be built as a parachain module. The parachain module can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +Bridge modules allow for non-parachains to act as a "virtual parachain" and extends the external chain's functionality with the interoperability benefits of Polkadot. + +Bridge modules will be written with particular chains in mind such as Bitcoin or Ethereum. This means that blockchains that are based of these will likely be easily supported as well (e.g. Litecoin and other Bitcoin-forks). + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=3) + +For the standalone chains that will not have a parachain bridging module on Polkadot, it will be necessary to deploy bridge contracts (see below). + +## Bridge contracts + +Those who are already familiar with Ethereum may know of the [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +In the case of Polkadot, it should be possible to have a bridge contract deployed on, say, an EVM-based standalone chain and a contract deployed on a smart contract capable parachain. This would not necessarily be the most efficient method of bridging, but given the generality of a Turing-complete parachain it would be possible to bridge Polkadot and any other smart contract capable blockchain. + +## Bitcoin Bridge + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XClaim](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Ethereum Bridge + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +## Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +## Resources + +### Smart Contract Bridges + +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain). +- [Parity Bridge](https://github.com/paritytech/parity-bridge) +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. + +### Runtime Module Bridges + +- [Bifrost](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [Tendermint Bridge](https://github.com/ChorusOne) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/develop/cxrml/bridge/btc) - ChainX have implemented a BTC to Substrate bridge for their parachain. + +### Design + +- [XClaim](https://eprint.iacr.org/2018/643.pdf) - XClaim design for bridging Proof-of-Work chains in a trustless way. diff --git a/website/translated_docs/pt-PT/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/pt-PT/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/pt-PT/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/pt-PT/learn-comparison-dfinity.md diff --git a/website/translated_docs/pt-PT/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/pt-PT/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/pt-PT/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/pt-PT/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/pt-PT/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/pt-PT/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/pt-PT/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/pt-PT/learn-comparisons-cosmos.md diff --git a/website/translated_docs/pt-PT/learn-comparisons.md b/polkadot-wiki/translated_docs/pt-PT/learn-comparisons.md similarity index 100% rename from website/translated_docs/pt-PT/learn-comparisons.md rename to polkadot-wiki/translated_docs/pt-PT/learn-comparisons.md diff --git a/polkadot-wiki/translated_docs/pt-PT/learn-consensus.md b/polkadot-wiki/translated_docs/pt-PT/learn-consensus.md new file mode 100644 index 000000000000..da86642b7158 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/learn-consensus.md @@ -0,0 +1,124 @@ +--- +id: learn-consensus +title: Polkadot Consensus +sidebar_label: Polkadot Consensus +description: An explanation of the consensus model used in Polkadot and Kusama +--- + +## Why do we need consensus? + +Consensus is a method for coming to agreement over a shared state. In order for the state of the blockchain to continue to build and move forward, all nodes in the network must agree and come to consensus. It is the way that the nodes in a decentralized network are able to stay synced with each other. Without consensus for the decentralized network of nodes in a blockchain, there is no way to ensure that the state one node believes is true will be shared by the other nodes. Consensus aims to provide the _objective_ view of the state amid participants who each have their own _subjective_ views of the network. It is the process by which these nodes communicate and come to agreement, and are able to build new blocks. + +## What are PoW and PoS? + +Proof of Work (PoW) and Proof of Stake (PoS) have been inaccurately used as short hand to refer to consensus mechanisms of blockchains, but that does not capture the full picture. PoW is the method for agreeing on a block author and part of the fuller [Nakamoto consensus](#nakamoto-consensus) that also encompasses a chain selection algorithm (longest chain rule in Bitcoin). Similarly, PoS is a set of rules for selecting the validator set and does not specify a chain selection rule or how a chain might reach finality. PoS algorithms have traditionally been paired with an algorithm for coming to Byzantine agreement between nodes. For example, [Tendermint](learn-comparisons-cosmos) is a practical Byzantine fault tolerant algorithm that uses PoS as its validator set selection method. + +## Why not Proof of Work? + +Although simple and effective in coming to a decentralized consensus on the next block producer, proof of work with Nakamoto consensus consumes an incredible amount of energy, has no economic or provable finality, and has no effective strategy in resisting cartels. + +## Probabilistic vs. provable finality + +A pure Nakamoto consensus blockchain that runs PoW is only able to achieve the notion of _probabilistic finality_ and reach _eventual consensus_. Probabilistic finality means that under some assumptions about the network and participants, if we see a few blocks building on a given block, we can estimate the probability that it is final. Eventual consensus means that at some point in the future, all nodes will agree on the truthfulness of one set of data. This eventual consensus may take a long time and will not be able to be determined how long it will take ahead of time. However, finality gadgets such as GRANDPA or Ethereum's Casper FFG are designed to give stronger and quicker guarantees on the finality of blocks - specifically, that they can never be reverted after some process of Byzantine agreements has taken place. The notion of irreversible consensus is known as _provable finality._ + +In the GRANDPA paper, it is phrased in this way: + +> We say an oracle A in a protocol is _eventually consistent_ if it returns the same value to all participants after some unspecified time. + +## What is GRANDPA/BABE? + +### Hybrid Consensus + +There are two acronyms we use when we talk about the consensus protocol of Polkadot, GRANDPA and BABE. We talk about both of these acronyms because Polkadot uses what is known as _hybrid consensus_. Hybrid consensus splits up the finality gadget from the block production mechanism. + +This is a way of getting the benefits of probabilistic finality (the ability to always produce new blocks) and provable finality (having a universal agreement on the canonical chain with no chance for reversion) in Polkadot. It also avoids the corresponding drawbacks of each mechanism (the chance of unknowingly following the wrong fork in probabilistic finality, and a chance for "stalling" - not being able to produce new blocks - in provable finality). By combining these two mechanisms, Polkadot allows for blocks to be rapidly produced, and the slower finality mechanism to run in a separate process to finalize blocks without risking slower transaction processing or stalling. + +Hybrid consensus has been proposed in the past. Notably, it was proposed (now defunct) as a step in Ethereum's transition to proof of stake in [EIP 1011](http://eips.ethereum.org/EIPS/eip-1011), which specified [Casper FFG](#casper-ffg). + +### BABE + +BABE (Blind Assignment for Blockchain Extension) is the block production mechanism that runs between the validator nodes and determines the authors of new blocks. BABE is comparable as an algorithm to Ouroboros Praos, with some key differences in chain selection rule and slot time adjustments. BABE assigns block production slots to validators according to stake and using the Polkadot [randomness cycle](learn-randomness). + +Validators in Polkadot will participate in a [lottery](learn-randomness) in every slot that will tell them whether or not they are the block producer candidate for that slot. Slots are discrete units of time, nominally 6 seconds in length. Because of this randomness mechanism, multiple validators could be candidates for the same slot. Other times, a slot could be empty, resulting in inconsistent block time. + +#### Multiple Validators per Slot + +When multiple validators are block producer candidates in a given slot, all will produce a block and broadcast it to the network. At that point, it's a race. The validator whose block reaches most of the network first wins. Depending on network topology and latency, both chains will continue to build in some capacity, until finalization kicks in and amputates a fork. See Fork Choice below for how that works. + +#### No Validators in Slot + +When no validators have rolled low enough in the randomness lottery to qualify for block production, a slot can remain seemingly blockless. We avoid this by running a secondary, round-robin style validator selection algorithm in the background. The validators selected to produce blocks through this algorithm always produce blocks, but these _secondary_ blocks are ignored if the same slot also produces a primary block from a [VRF-selected](learn-randomness) validator. Thus, a slot can have either a _primary_ or a _secondary_ block, and no slots are ever skipped. + +For more details on BABE, please see the [working research draft](https://research.web3.foundation/en/latest/polkadot/BABE/Babe.html). + +#### Difference of BABE secondary blocks between Kusama and Polkadot + +Both Kusama and Polkadot uses the BABE block production mechanism outlined above. However, there is a slight difference in the secondary blocks that are produced between the two networks. Polkadot attaches the VRF output to secondary blocks (and therefore every block contributes to the Era randomness), while Kusama keeps the VRF output off the secondary blocks (meaning only the primary blocks contribute to Era randomness). The Polkadot method should give stronger randomness as more inputs are collected during every Era. Eventually, this change should make its way into Kusama too. + +### GRANDPA: Finality gadget + +GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is the finality gadget that is implemented for the Polkadot Relay Chain. + +It works in a partially synchronous network model as long as 2/3 of nodes are honest and can cope with 1/5 Byzantine nodes in an asynchronous setting. + +A notable distinction is that GRANDPA reaches agreements on chains rather than blocks, greatly speeding up the finalization process, even after long-term network partitioning or other networking failures. + +In other words, as soon as more than 2/3 of validators attest to a chain containing a certain block, all blocks leading up to that one are finalized at once. + +#### Protocol + +Please refer to heading 3 in [the paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) for a full description of the protocol. + +#### Implementation + +The [Rust implementation](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs) is part of Substrate Frame. + +For even more detail, see the [GRANDPA research page](https://research.web3.foundation/en/latest/polkadot/GRANDPA.html) on the W3F Research pages. + +### Fork Choice + +Bringing BABE and GRANDPA together, the fork choice of Polkadot becomes clear. BABE must always build on the chain that has been finalized by GRANDPA. When there are forks after the finalized head, BABE provides probabilistic finality by building on the chain with the most primary blocks. + +![Best chain choice](assets/best_chain.png) + +In the above image, the black blocks are finalized. Ones are primary, twos are secondary blocks. Even though the topmost chain is the longest chain on the latest finalized block, it does not qualify because it has fewer primaries at the time of evaluation than the one below it. + +## Comparisons + +### Nakamoto consensus + +Nakamoto consensus consists of the longest chain rule using proof of work as its sybil resistance mechanism and leader election. + +Nakamoto consensus only gives us probabilistic finality. Probabilistic finality states that a block in the past is only as safe as the number of confirmations it has, or the number of blocks that have been built on top of it. As more blocks are built on top of a specific block in a Proof of Work chain, more computational work has been expended behind this particular chain. However, it does not guarantee that the chain containing the block will always remain the agreed-upon chain, since an actor with unlimited resources could potentially build a competing chain and expend enough computational resources to create a chain that did not contain a specific block. In such a situation, the longest chain rule employed in Bitcoin and other proof of work chains would move to this new chain as the canonical one. + +### PBFT / Tendermint + +Please see the [relevant section](learn-comparisons-cosmos#consensus) in the Cosmos comparison article. + + + +### Casper FFG + +The two main differences between GRANDPA and Casper FFG (Friendly Finality Gadget) are: + +- in GRANDPA, different voters can cast votes simultaneously for blocks at different heights +- GRANDPA only depends on finalized blocks to affect the fork-choice rule of the underlying block production mechanism + +### Casper CBC + +_Coming soon!_ + + + +## Resources + +- [GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) - The academic description of the GRANDPA finality gadget. Contains formal proofs of the algorithm. +- [Rust implementation](https://github.com/paritytech/finality-grandpa) - The reference implementation and the accompanying [Substrate pallet](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs). + + diff --git a/website/translated_docs/pt-PT/learn-crosschain.md b/polkadot-wiki/translated_docs/pt-PT/learn-crosschain.md similarity index 100% rename from website/translated_docs/pt-PT/learn-crosschain.md rename to polkadot-wiki/translated_docs/pt-PT/learn-crosschain.md diff --git a/polkadot-wiki/translated_docs/pt-PT/learn-cryptography.md b/polkadot-wiki/translated_docs/pt-PT/learn-cryptography.md new file mode 100644 index 000000000000..907e6cc563cc --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/learn-cryptography.md @@ -0,0 +1,21 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/pt-PT/learn-governance.md b/polkadot-wiki/translated_docs/pt-PT/learn-governance.md new file mode 100644 index 000000000000..9661c5d2cb17 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/learn-governance.md @@ -0,0 +1,262 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +The following steps are the governance procedure in the Polkadot network: + +- [Proposing Referenda](#proposing-a-referendum) +- [Voting for a proposal](#voting-on-a-referendum) +- [Tallying](#tallying) + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is planned to be 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of DOTs for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest amount of bonded support will be selected to be a referendum. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOTs each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries. + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of DOT tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +``` +Example: + +Peter: Votes `No` with 10 DOTs for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOTs for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOTs for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combining both Logan and Kevin vote with more DOTs than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (Does not include conviction) + +electorate - the total number of DOTs tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOTs tokens in total. +- Public proposal + +John - 500 DOTs +Peter - 100 DOTs +Lilly - 150 DOTs +JJ - 150 DOTs +Ken - 600 DOTs + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: + +``` +Max votes = tokens * vote_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the lock period doubles. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +Based on the genesis runtime, the maximum number of lock periods is set to 6 and the lock period is 30 days on Polkadot and eight days on Kusama. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +To represent passive stakeholders, we introduce the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. For Polkadot this number is likely to begin at around six people, and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). In general, it has a fixed number of seats (24 on Polkadot and 17 on Kusama). + +The council is called upon primarily for two tasks of governance: proposing sensible referenda, and cancelling uncontroversially dangerous or malicious referenda. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. In the case that all members vote in favor, the vote is considered unanimous and is treated as uncontroversial. + +A two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +At genesis, there will be 6 to 12 seats in the Council. All stakeholders are free to signal their approval of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referendum. + +To elect a new council member, Polkadot employs the same election scheme as used for choosing the active set of validators, a [Phragmén election](learn-phragmen). The election also chooses a set number of runners up (currently seven in Kusama) that will remain in the queue with their votes intact. + +As opposed to a "first past the post", where voters must decide only on a single candidate chosen from a list, a Phragmén election is a more expressive way to indicate voters' views. Token holders can treat it as Boolean voting to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the council. + +The Technical Committee can, along with the Polkadot Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## [Usage of DOT](learn-DOT#dots-for-governance) + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) diff --git a/website/translated_docs/pt-PT/learn-identity.md b/polkadot-wiki/translated_docs/pt-PT/learn-identity.md similarity index 100% rename from website/translated_docs/pt-PT/learn-identity.md rename to polkadot-wiki/translated_docs/pt-PT/learn-identity.md diff --git a/website/translated_docs/pt-PT/learn-implementations.md b/polkadot-wiki/translated_docs/pt-PT/learn-implementations.md similarity index 100% rename from website/translated_docs/pt-PT/learn-implementations.md rename to polkadot-wiki/translated_docs/pt-PT/learn-implementations.md diff --git a/website/translated_docs/pt-PT/learn-implementers-guide.md b/polkadot-wiki/translated_docs/pt-PT/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/pt-PT/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/pt-PT/learn-implementers-guide.md diff --git a/website/translated_docs/pt-PT/learn-introduction.md b/polkadot-wiki/translated_docs/pt-PT/learn-introduction.md similarity index 100% rename from website/translated_docs/pt-PT/learn-introduction.md rename to polkadot-wiki/translated_docs/pt-PT/learn-introduction.md diff --git a/website/translated_docs/pt-PT/learn-keys.md b/polkadot-wiki/translated_docs/pt-PT/learn-keys.md similarity index 100% rename from website/translated_docs/pt-PT/learn-keys.md rename to polkadot-wiki/translated_docs/pt-PT/learn-keys.md diff --git a/website/translated_docs/pt-PT/learn-launch.md b/polkadot-wiki/translated_docs/pt-PT/learn-launch.md similarity index 100% rename from website/translated_docs/pt-PT/learn-launch.md rename to polkadot-wiki/translated_docs/pt-PT/learn-launch.md diff --git a/website/translated_docs/pt-PT/learn-parachains.md b/polkadot-wiki/translated_docs/pt-PT/learn-parachains.md similarity index 100% rename from website/translated_docs/pt-PT/learn-parachains.md rename to polkadot-wiki/translated_docs/pt-PT/learn-parachains.md diff --git a/website/translated_docs/pt-PT/learn-parathreads.md b/polkadot-wiki/translated_docs/pt-PT/learn-parathreads.md similarity index 100% rename from website/translated_docs/pt-PT/learn-parathreads.md rename to polkadot-wiki/translated_docs/pt-PT/learn-parathreads.md diff --git a/website/translated_docs/pt-PT/learn-phragmen.md b/polkadot-wiki/translated_docs/pt-PT/learn-phragmen.md similarity index 100% rename from website/translated_docs/pt-PT/learn-phragmen.md rename to polkadot-wiki/translated_docs/pt-PT/learn-phragmen.md diff --git a/website/translated_docs/pt-PT/learn-polkadot-host.md b/polkadot-wiki/translated_docs/pt-PT/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/pt-PT/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/pt-PT/learn-polkadot-host.md diff --git a/website/translated_docs/pt-PT/learn-proxies.md b/polkadot-wiki/translated_docs/pt-PT/learn-proxies.md similarity index 100% rename from website/translated_docs/pt-PT/learn-proxies.md rename to polkadot-wiki/translated_docs/pt-PT/learn-proxies.md diff --git a/website/translated_docs/pt-PT/learn-randomness.md b/polkadot-wiki/translated_docs/pt-PT/learn-randomness.md similarity index 100% rename from website/translated_docs/pt-PT/learn-randomness.md rename to polkadot-wiki/translated_docs/pt-PT/learn-randomness.md diff --git a/website/translated_docs/pt-PT/learn-relevant-links.md b/polkadot-wiki/translated_docs/pt-PT/learn-relevant-links.md similarity index 100% rename from website/translated_docs/pt-PT/learn-relevant-links.md rename to polkadot-wiki/translated_docs/pt-PT/learn-relevant-links.md diff --git a/website/translated_docs/pt-PT/learn-roadmap.md b/polkadot-wiki/translated_docs/pt-PT/learn-roadmap.md similarity index 100% rename from website/translated_docs/pt-PT/learn-roadmap.md rename to polkadot-wiki/translated_docs/pt-PT/learn-roadmap.md diff --git a/website/translated_docs/pt-PT/learn-security.md b/polkadot-wiki/translated_docs/pt-PT/learn-security.md similarity index 100% rename from website/translated_docs/pt-PT/learn-security.md rename to polkadot-wiki/translated_docs/pt-PT/learn-security.md diff --git a/website/translated_docs/pt-PT/learn-simple-payouts.md b/polkadot-wiki/translated_docs/pt-PT/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/pt-PT/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/pt-PT/learn-simple-payouts.md diff --git a/website/translated_docs/pt-PT/learn-spree.md b/polkadot-wiki/translated_docs/pt-PT/learn-spree.md similarity index 100% rename from website/translated_docs/pt-PT/learn-spree.md rename to polkadot-wiki/translated_docs/pt-PT/learn-spree.md diff --git a/polkadot-wiki/translated_docs/pt-PT/learn-staking.md b/polkadot-wiki/translated_docs/pt-PT/learn-staking.md new file mode 100644 index 000000000000..34bd0d55f6ff --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/learn-staking.md @@ -0,0 +1,240 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards equally to all validators regardless of stake. In other words, having more stake on a validator does not influence the block rewards they receive. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOTs. You can take a look at the [nominator guide](maintain-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid the **same amount of DOTs** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. Within a validator pool, a (configurable) part of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once as commission fees for validating, and once for nominating itself with stake. + +To estimate the inflation rate and how many DOTs you can get each month as a nominator or validator, you can use this [Excel sheet](https://docs.google.com/spreadsheets/d/1-9Hc3kZ23EhZC3X6feRUKSTv6gj4xR7cvUbJD2zUEZk/edit?usp=sharing) as a reference and play around with it by changing some parameters (e.g. validator pools, total supply, commission fees, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They do NOT charge any commission fees +- Reward amount is 100 DOT tokens +- The least amount of DOTs to be a validator is 350 + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOTs in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOTs), which means that validator pools with more stake get slashed more DOTs. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOTs, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOTs and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOTs. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +### Want to stake DOTs? + +- [Nominator Guide](mirror-maintain-guides-how-to-nominate-kusama) - Become a nominator on the Kusama network. +- [Validator Guide](mirror-maintain-guides-how-to-validate-kusama) - Become a validator on the Kusama network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOTs. Any slashed DOTs will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of validators that you have nominated in the past 84 eras. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOTs. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOTs. The remaining 5 DOTs would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller) or to the stash account (and either increasing the staked value or not increasing the staked value). It is also possible to top-up / withdraw some bonded DOTs without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOTs staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [PolkadotJS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces validator payouts. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators will Polkadot have? + +The plan is to start with somewhere between 50 to 100 open validator positions and open more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to frequent and voluminous peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, has over 300 validator slots. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/pt-PT/learn-transaction-fees.md b/polkadot-wiki/translated_docs/pt-PT/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/pt-PT/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/pt-PT/learn-transaction-fees.md diff --git a/website/translated_docs/pt-PT/learn-transactions.md b/polkadot-wiki/translated_docs/pt-PT/learn-transactions.md similarity index 100% rename from website/translated_docs/pt-PT/learn-transactions.md rename to polkadot-wiki/translated_docs/pt-PT/learn-transactions.md diff --git a/website/translated_docs/pt-PT/learn-treasury.md b/polkadot-wiki/translated_docs/pt-PT/learn-treasury.md similarity index 100% rename from website/translated_docs/pt-PT/learn-treasury.md rename to polkadot-wiki/translated_docs/pt-PT/learn-treasury.md diff --git a/website/translated_docs/pt-PT/learn-wasm.md b/polkadot-wiki/translated_docs/pt-PT/learn-wasm.md similarity index 100% rename from website/translated_docs/pt-PT/learn-wasm.md rename to polkadot-wiki/translated_docs/pt-PT/learn-wasm.md diff --git a/website/translated_docs/pt-PT/maintain-collator.md b/polkadot-wiki/translated_docs/pt-PT/maintain-collator.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-collator.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-collator.md diff --git a/website/translated_docs/pt-PT/maintain-errors.md b/polkadot-wiki/translated_docs/pt-PT/maintain-errors.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-errors.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-errors.md diff --git a/website/translated_docs/pt-PT/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-democracy.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-join-council.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-nominate-alexander.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-nominate-alexander.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-nominate-alexander.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-setup-sentry-node.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-setup-sentry-node.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-setup-sentry-node.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-setup-sentry-node.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..8546cc811426 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,257 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: Validator Guide +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmen's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](maintain-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.3**, but you should review the output from the "git tag" command (`git tag | grep "$v\0\.8"`) to see a list of all the potential 0.8 releases. You should replace `v0.8.8` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag | grep "$v\0\.8" +git checkout v0.8.8 +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `-unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSMs - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn/staking/#reward-distribution). + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSMs staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:v0.7.28 --validator --name "name on telemetry" +``` diff --git a/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..3427da057f92 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,275 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: Validator Guide +--- + +> The following information applies to the Polkadot network, which is currently in the soft launch phase. During soft launch the network starts as a Proof-of-Authority network before transitioning to Proof-of-Stake. You will be able to follow this guide to set up your validator but the first validator election and rewards will not start until later. If you want to set up a validator on Kusama, check out the [Kusama guide](mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOTs do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmen's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](maintain-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOTs that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.3**, but you should review the output from the "git tag" command (`git tag | grep "$v\0\.8"`) to see a list of all the potential 0.8 releases. You should replace `v0.8.8` with the latest build (i.e., the highest number). You can also find the latest Polkadot version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag | grep "$v\0\.8" +git checkout v0.8.8 +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-05-15 +> rustup override set nightly-2020-05-15 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15 +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `-unsafe-pruning --pruning OF BLOCKS>`, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +> **Note:** If you do not already have DOTs, this is as far as you will be able to go until the end of the soft launch period. You can still run a node, but you will need to have a minimal amount of DOTs to continue, as balance transfers are disabled during the soft launch. Please keep in mind that even for those with DOTs, they will only be indicating their _intent_ to validate; they will also not be able to run a validator until the NPoS phase starts. + +## Bond DOTs + +> **Note:** Transfers are disabled during the soft launch phase of Polkadot. This means that if you are setting up a validator during this time you may not be able to make your stash and controller two separate accounts, as is recommended. You must make them the same account, meaning that you will bond the account to itself. However it is highly recommended that you change your controller as soon as possible. + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOTs of the Stash account. These DOTs will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOTs - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOTs in order to start and stop validating. +- **Value bonded** - How much DOts from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOTs in that account. Also note that you can always bond _more_ DOTs later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn/staking/#reward-distribution). + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point, omitting the `--unsafe-rpc-expose` flag as it is no longer needed. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOTs staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/pt-PT/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/pt-PT/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..94fb88f0ee87 --- /dev/null +++ b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-society-kusama.md @@ -0,0 +1,163 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/society/dashboard.jpg) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on PolkadotJS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +`Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. + +`Rotation`: The duration between each time the membership rotates. + +`Challenge`: The time period to randomly select one of the members to defend his membership in the society. + +`Pot`: Resource that is used to support the member of society. + +`Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +`Bidder` - A token holder who intends to join the society by placing a bid. + +`Candidate` - The selected bidders that will be voted on by members of the society. + +`Suspended Candidate` - The candidates that failed to join the society. + +`Member` - Member of the society. + +`Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. + +`Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. + +`Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +**Remember to take a look at the \[rules\]\[kapp rules\] first. And since those rules are not enforced entirely on-chain, it is recommended to join the [public chat room](https://matrix.to/#/!BUmiAAnAYSRGarqwOt:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) to ask any questions if anything is unclear.** + +### 1. Bid Phase + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +![Society Dashboard](assets/society/submit_bid.jpg) + +Anyone who wants to join the society is required to deposit 10 KSM for reserve on Kusama and place the bid amount (1 KSM in this case) that they want to get when joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://polkadot.js.org/apps/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid`. + +> unbid(pos) +> +> pos - The index of the bid. + +If you are not sure what your position is, you can check that by going to the [Society->bids chain state](https://polkadot.js.org/apps/#/chainstate) in the PolkadotJS apps. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +![Society Vote Candidate](assets/society/vote_candidate.jpg) + +> vote(candidate,approve) +> +> candidate - Select the candidate you would like to vote +> +> approve - Yes / No + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> **_NOTE:_** +> +> If the randomly selected member does not vote, it will be treated as a rejection. +> +> For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> **_NOTE:_** +> +> The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is closer to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgment Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +![Society Vote Defender](assets/society/vote_defender.jpg) + +> defenderVote(approve) +> +> approve - Yes / No + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> **_NOTE:_** +> +> Each member can only vouch for one user at a time. +> +> A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society + +[Kappa Sigma Mu Lounge](https://matrix.to/#/!BUmiAAnAYSRGarqwOt:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - A public chat room on Riot to talk about anything about the society. + +[Substrate Society](https://www.shawntabrizi.com/substrate-society/) - It shows the Kusama society information and allowing you to directly place a bid if you have installed the [PolkadotJS extension](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd). diff --git a/website/translated_docs/pt-PT/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/pt-PT/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-guides-validator-payout.md diff --git a/website/translated_docs/pt-PT/maintain-index.md b/polkadot-wiki/translated_docs/pt-PT/maintain-index.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-index.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-index.md diff --git a/website/translated_docs/pt-PT/maintain-networks.md b/polkadot-wiki/translated_docs/pt-PT/maintain-networks.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-networks.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-networks.md diff --git a/website/translated_docs/pt-PT/maintain-nominator.md b/polkadot-wiki/translated_docs/pt-PT/maintain-nominator.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-nominator.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-nominator.md diff --git a/website/translated_docs/pt-PT/maintain-sync.md b/polkadot-wiki/translated_docs/pt-PT/maintain-sync.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-sync.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-sync.md diff --git a/website/translated_docs/pt-PT/maintain-validator.md b/polkadot-wiki/translated_docs/pt-PT/maintain-validator.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-validator.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-validator.md diff --git a/website/translated_docs/pt-PT/maintain-wss.md b/polkadot-wiki/translated_docs/pt-PT/maintain-wss.md similarity index 100% rename from website/translated_docs/pt-PT/maintain-wss.md rename to polkadot-wiki/translated_docs/pt-PT/maintain-wss.md diff --git a/website/translated_docs/pt-PT/research.md b/polkadot-wiki/translated_docs/pt-PT/research.md similarity index 100% rename from website/translated_docs/pt-PT/research.md rename to polkadot-wiki/translated_docs/pt-PT/research.md diff --git a/website/translated_docs/ru/ambassadors.md b/polkadot-wiki/translated_docs/ru/ambassadors.md similarity index 100% rename from website/translated_docs/ru/ambassadors.md rename to polkadot-wiki/translated_docs/ru/ambassadors.md diff --git a/website/translated_docs/ru/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/ru/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/ru/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/ru/build-build-with-polkadot.md diff --git a/website/translated_docs/ru/build-cumulus.md b/polkadot-wiki/translated_docs/ru/build-cumulus.md similarity index 100% rename from website/translated_docs/ru/build-cumulus.md rename to polkadot-wiki/translated_docs/ru/build-cumulus.md diff --git a/website/translated_docs/ru/build-deploy-parachains.md b/polkadot-wiki/translated_docs/ru/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/ru/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/ru/build-deploy-parachains.md diff --git a/website/translated_docs/ru/build-dev-roadmap.md b/polkadot-wiki/translated_docs/ru/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/ru/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/ru/build-dev-roadmap.md diff --git a/website/translated_docs/ru/build-examples-index.md b/polkadot-wiki/translated_docs/ru/build-examples-index.md similarity index 100% rename from website/translated_docs/ru/build-examples-index.md rename to polkadot-wiki/translated_docs/ru/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/ru/build-exchange-integration.md b/polkadot-wiki/translated_docs/ru/build-exchange-integration.md new file mode 100644 index 000000000000..dddd3a779fac --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. Tracking the chain head + +Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). + +That will give you a stream of hashes of the most recent finalised headers. + +When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. + +If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. + +## 2. Decoding blocks + +You will need to decode blocks from the basic data into useful fields. + +All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. + +For Genesis Polkadot, the header format is a five-field structure: + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +It also relies on `Extrinsic`. An _extrinsic_ is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. + +The metadata itself is provided encoded in SCALE. Its format is: + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. + +Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various _modules_. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, _extrinsics_), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. Working with SS58 and account addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) _AccountId_. This is simply the public key for the x25519 cryptography used by Substrate. + +However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this _index_ to identify the account. This index is much smaller than the 32-byte _AccountId_, and can usually be encoded in just a couple of bytes. + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: + +`0x00 ` + +**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. + +Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. + +Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. + +### Looking up an index + +Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. + +The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. + +For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. + +This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. + +This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. + +Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. + +## 4. Working with balances + +In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. + +NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. + +The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10\*\*12). For completeness, The exact denominations of the Polkadot currency are: + +| Balance value | Name | +| ------------- | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### Transferring balances + +To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. + +In general, Polkadot's transactions are encoded as _signed_ `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. + +The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. + +NOTE: The nonce retrieved from storage does not take into account _pending_ transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. + +The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. + +The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. + +Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. + +Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +The `function` _in this case_ (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. + +The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. + +### Submitting and checking transactions + +Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. + +This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. + +The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. + +## Conclusion + +This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. + +If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). + +_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/polkadot-wiki/translated_docs/ru/build-extrinsic-format.md b/polkadot-wiki/translated_docs/ru/build-extrinsic-format.md new file mode 100644 index 000000000000..39a48b855d09 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/build-extrinsic-format.md @@ -0,0 +1,44 @@ +--- +id: build-extrinsic-format +title: Polkadot Extrinsic Format aka Transaction Format +sidebar_label: Polkadot Extrinsic Format aka Transaction Format +--- + +## Old Format + +For reference, the **old** extrinsic format was: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] +``` + +## Current Format + +The Polkadot extrinsic format is: + +``` +[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] +``` + +The _original_ fields refer to the following from the old extrinsic format: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] +``` + +The specific format for the new address type is one of 5 sub-formats, switched on the first byte: + +- `0xff, 32-byte account id` +- `0xfe, 8-byte account index` +- `0xfd, 4-byte account index` +- `0xfc, 2-byte account index` +- `[0xf0...0xfb] (invalid, reserved for future use)` +- `[0x00...0xef] 1-byte account index (less than 0xf0)` + +The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. + +In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). + +## Source + +[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/ru/build-hackathon.md b/polkadot-wiki/translated_docs/ru/build-hackathon.md similarity index 100% rename from website/translated_docs/ru/build-hackathon.md rename to polkadot-wiki/translated_docs/ru/build-hackathon.md diff --git a/website/translated_docs/ru/build-index.md b/polkadot-wiki/translated_docs/ru/build-index.md similarity index 100% rename from website/translated_docs/ru/build-index.md rename to polkadot-wiki/translated_docs/ru/build-index.md diff --git a/website/translated_docs/ru/build-integration.md b/polkadot-wiki/translated_docs/ru/build-integration.md similarity index 100% rename from website/translated_docs/ru/build-integration.md rename to polkadot-wiki/translated_docs/ru/build-integration.md diff --git a/website/translated_docs/ru/build-networks.md b/polkadot-wiki/translated_docs/ru/build-networks.md similarity index 100% rename from website/translated_docs/ru/build-networks.md rename to polkadot-wiki/translated_docs/ru/build-networks.md diff --git a/website/translated_docs/ru/build-node-interaction.md b/polkadot-wiki/translated_docs/ru/build-node-interaction.md similarity index 100% rename from website/translated_docs/ru/build-node-interaction.md rename to polkadot-wiki/translated_docs/ru/build-node-interaction.md diff --git a/website/translated_docs/ru/build-node-management.md b/polkadot-wiki/translated_docs/ru/build-node-management.md similarity index 100% rename from website/translated_docs/ru/build-node-management.md rename to polkadot-wiki/translated_docs/ru/build-node-management.md diff --git a/website/translated_docs/ru/build-oracle.md b/polkadot-wiki/translated_docs/ru/build-oracle.md similarity index 100% rename from website/translated_docs/ru/build-oracle.md rename to polkadot-wiki/translated_docs/ru/build-oracle.md diff --git a/website/translated_docs/ru/build-parachains-rococo.md b/polkadot-wiki/translated_docs/ru/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/ru/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/ru/build-parachains-rococo.md diff --git a/website/translated_docs/ru/build-pdk.md b/polkadot-wiki/translated_docs/ru/build-pdk.md similarity index 100% rename from website/translated_docs/ru/build-pdk.md rename to polkadot-wiki/translated_docs/ru/build-pdk.md diff --git a/polkadot-wiki/translated_docs/ru/build-protocol-info.md b/polkadot-wiki/translated_docs/ru/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/polkadot-wiki/translated_docs/ru/build-rust-style-guide.md b/polkadot-wiki/translated_docs/ru/build-rust-style-guide.md new file mode 100644 index 000000000000..678bb58481ae --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/build-rust-style-guide.md @@ -0,0 +1,117 @@ +--- +id: build-rust-style-guide +title: Style Guide for Rust in Polkadot +sidebar_label: Style Guide for Rust in Polkadot +--- + +- Indent using tabs +- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. +- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. +- Never have spaces on a line prior to a non-whitespace character +- Follow-on lines are only ever a single indent from the original line. + +```rust +fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { + let x = some_long_variable_a * some_long_variable_b + - some_long_variable_b / some_long_variable_a + + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); + x > 10 +} +``` + +- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: + +```rust +fn calculate( + some_long_variable_a: f32, + some_long_variable_b: f32, + some_long_variable_c: f32, +) -> f32 { + (-some_long_variable_b + sqrt( + // two parens open, but since we open & close them both on the + // same line, only one indent level is used + some_long_variable_b * some_long_variable_b + - 4 * some_long_variable_a * some_long_variable_c + // both closed here at beginning of line, so back to the original indent + // level + )) / (2 * some_long_variable_a) +} +``` + +- `where` is indented, and its items are indented one further +- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. + +```rust +// OK +fn foo( + really_long_parameter_name_1: SomeLongTypeName, + really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, + shrt_nm_2: u8, +) { + ... +} + +// NOT OK +fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, shrt_nm_2: u8) { + ... +} + +``` + +```rust +{ + // Complex line (not just a function call, also a let statement). Full + // structure. + let (a, b) = bar( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Long, simple function call. + waz( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Short function call. Inline. + baz(a, b); +} +``` + +- Always end last item of a multi-line comma-delimited set with `,` when legal: + +```rust +struct Point { + x: T, + y: T, // <-- Multiline comma-delimited lists end with a trailing , +} + +// Single line comma-delimited items do not have a trailing `,` +enum Meal { Breakfast, Lunch, Dinner }; +``` + +- Avoid trailing `;`s where unneeded. + +```rust +if condition { + return 1 // <-- no ; here +} +``` + +- `match` arms may be either blocks or have a trailing `,` but not both. +- Blocks should not be used unnecessarily. + +```rust +match meal { + Meal::Breakfast => "eggs", + Meal::Lunch => { check_diet(); recipe() }, +// Meal::Dinner => { return Err("Fasting") } // WRONG + Meal::Dinner => return Err("Fasting"), +} +``` diff --git a/website/translated_docs/ru/build-smart-contracts.md b/polkadot-wiki/translated_docs/ru/build-smart-contracts.md similarity index 100% rename from website/translated_docs/ru/build-smart-contracts.md rename to polkadot-wiki/translated_docs/ru/build-smart-contracts.md diff --git a/website/translated_docs/ru/build-tools-index.md b/polkadot-wiki/translated_docs/ru/build-tools-index.md similarity index 100% rename from website/translated_docs/ru/build-tools-index.md rename to polkadot-wiki/translated_docs/ru/build-tools-index.md diff --git a/website/translated_docs/ru/build-tools-subkey.md b/polkadot-wiki/translated_docs/ru/build-tools-subkey.md similarity index 100% rename from website/translated_docs/ru/build-tools-subkey.md rename to polkadot-wiki/translated_docs/ru/build-tools-subkey.md diff --git a/polkadot-wiki/translated_docs/ru/build-transaction-construction.md b/polkadot-wiki/translated_docs/ru/build-transaction-construction.md new file mode 100644 index 000000000000..156bbbebd565 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Создание и подписание транзакций +sidebar_label: Создание транзакций +--- + +На этой странице будет обсуждаться формат транзакций в Polkadot и способы создания, подписания и трансляции транзакций. Как и на других страницах этого руководства, на этой странице демонстрируются некоторые из доступных инструментов.**При интеграции всегда обращайтесь к документации по каждому инструменту.** + +## Формат транзакции + +У Polkadot есть базовая информация о транзакциях, которая является общей для всех транзакций. + +- Адрес/Address: SS58-кодированный адрес учётной записи отправителя. +- Хеш Блока/Block Hash: Хэш [контрольной точки/checkpoint](build-protocol-info#transaction-mortality) блока. +- Номер Блока/Block Number: номер контрольной точки блока. +- Хеш Генезиса/Genesis Hash: Хэш генезиса цепочки. +- Метаданные/Metadata: метаданные в кодировке SCALE для среды исполнения при отправке. +- Nonce: [nonce](https://ru.wikipedia.org/wiki/Nonce) для этой транзакции.\* +- Версия Spec: Текущая версия spec для среды исполнения. +- Версия транзакции: текущая версия для формата транзакции. +- Подсказка: необязательно, [советы](build-protocol-info#fees) для увеличения приоритета транзакций. +- Период Эы/Era Period: Необязательно, количество блоков после контрольной точки, для которой транзакция является действительной. Если нуль, транзакция [бессмертная](build-protocol-info#transaction-mortality). + +\*Nonce, запрошенный из системного модуля, не учитывает отложенные транзакции. Вы должны отслеживать и увеличивать nonce вручную, если хотите отправить несколько действительных транзакций одновременно. + +Каждая транзакция будет иметь свои собственные (или нет) параметры для добавления. Например, функция `transferKeepAlive` из паллета Балансов будет принимать: + +- `dest`: Адрес назначения +- `#[compact]количество`: Количество токенов (компактная кодировка) + +Как только Вы получите всю необходимую информацию, Вам нужно будет: + +1. Создать неподписанную транзакцию. +1. Создать информационное наполнение (англ. payload) для подписи. +1. Подписать полезную информацию. +1. Сериализовать подписанную полезную информацию в транзакцию. +1. Отправить сериализованную транзакцию. + +Parity предоставляет следующие инструменты для выполнения этих шагов. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +В этом примере будет использована команда `signer submit`, которая создаст и отправит транзакцию. Команда `signer sendOffline` имеет тот же API, но не будет транслировать транзакцию. `submit` и `sendOffline` должны быть подключены к узлу, чтобы получить текущие метаданные и построить действительную транзакцию. Их API имеет формат: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Подписание: + +```bash +yarn run:signer sign --account --seed --type +``` + +Например, давайте отправим 0.5 DOT от `121X5bEgTZcGQx5NZjwuTjqKoiG8B2wEAvrUFjuw24ZGZf2` до `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +Это вернёт полезную информацию для подписи и входные данные, ожидающие подписи. Возьмите эти данные и используйте свою обычную среду для подписи (например, компьютер в режиме Авиа, VM и т. д.). Подпишите данные: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Сохраните выходные данные и принесите их на машину, с которой Вы будете транслировать, введите их в поле подписи `submit` и отправьте транзакцию (или просто верните сериализованную транзакцию, если вы используете `sendOffline`). + +## Tx Оболочка/Tx Wrapper + +Если Вы не хотите использовать CLI для операций подписи, Parity предоставляет SDK с именем [TxWrapper](https://github.com/paritytech/txwrapper) для генерации и подписания транзакций в автономном режиме. Посмотреть на [примеры](https://github.com/paritytech/txwrapper/tree/master/examples) из руководства. + +**Импорт приватного ключа** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Вывод адреса из открытого ключа** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Открытый ключ может быть либо шестнадцатеричной строкой, либо Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Построить транзакцию оффлайн** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // необходимо импортировать из клиентского RPC вызов state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // количество блоков от контрольной точки, в которой транзакция является действительной + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Создать полезную информацию для подписи** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Сериализовать подписанную транзакцию** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Пример кода, замените `signWithAlice` на актуального удаленного подписанта. +// Пример приведен здесь: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Декодировать типы полезной информации** + +Вы можете декодировать полезную информацию для проверки её содержания до отправки. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Декодируем неподписанную tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Декодируем полезную информацию +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Декодируем подписанную tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Проверьте хэш транзакции** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Отправка подписанной полезной информации + +Есть несколько способов отправить подписанную полезную информацию: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) с `author_submitExtrinsic` или `author_submitAndWatchExtrinsic`, последняя из которых подписывается на события, которые будут уведомлять о том, когда транзакция будет проверена и включена в цепочку. + +## Примечания + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/ru/build-wallets.md b/polkadot-wiki/translated_docs/ru/build-wallets.md similarity index 100% rename from website/translated_docs/ru/build-wallets.md rename to polkadot-wiki/translated_docs/ru/build-wallets.md diff --git a/polkadot-wiki/translated_docs/ru/claims.md b/polkadot-wiki/translated_docs/ru/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ru/community.md b/polkadot-wiki/translated_docs/ru/community.md similarity index 100% rename from website/translated_docs/ru/community.md rename to polkadot-wiki/translated_docs/ru/community.md diff --git a/website/translated_docs/ru/contributing.md b/polkadot-wiki/translated_docs/ru/contributing.md similarity index 100% rename from website/translated_docs/ru/contributing.md rename to polkadot-wiki/translated_docs/ru/contributing.md diff --git a/website/translated_docs/ru/contributors.md b/polkadot-wiki/translated_docs/ru/contributors.md similarity index 100% rename from website/translated_docs/ru/contributors.md rename to polkadot-wiki/translated_docs/ru/contributors.md diff --git a/website/translated_docs/ru/ens.md b/polkadot-wiki/translated_docs/ru/ens.md similarity index 100% rename from website/translated_docs/ru/ens.md rename to polkadot-wiki/translated_docs/ru/ens.md diff --git a/website/translated_docs/ru/faq.md b/polkadot-wiki/translated_docs/ru/faq.md similarity index 100% rename from website/translated_docs/ru/faq.md rename to polkadot-wiki/translated_docs/ru/faq.md diff --git a/polkadot-wiki/translated_docs/ru/getting-started.md b/polkadot-wiki/translated_docs/ru/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ru/glossary.md b/polkadot-wiki/translated_docs/ru/glossary.md similarity index 100% rename from website/translated_docs/ru/glossary.md rename to polkadot-wiki/translated_docs/ru/glossary.md diff --git a/polkadot-wiki/translated_docs/ru/grants.md b/polkadot-wiki/translated_docs/ru/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ru/index.md b/polkadot-wiki/translated_docs/ru/index.md similarity index 100% rename from website/translated_docs/ru/index.md rename to polkadot-wiki/translated_docs/ru/index.md diff --git a/polkadot-wiki/translated_docs/ru/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/ru/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..887e262cfc32 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Список вероятных атак +sidebar_label: Шпаргалка враждебности +--- + +Ожидайте, что в Кусаме всё что угодно может сломаться. Чтобы лучше сориентироваться в том, что именно может пойти не так, взгляните на нашу модель угроз. + +| Цель хакера | Гарантия безопасности, которой противостоит взломщик | Стимул взлома | Урон при взломе | Детали взлома | +| ----------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------: | :-----------: | :-------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Двойная трата токенов, заставляя клиентов принимать другую цепочку | Целостность (по всей системе) | Высокий | Высокий | Если злоумышленники смогут провести двойную трату токенов, они смогут получать услуги, не оплачивая их. Это прямой денежный стимул для проведения атаки. | +| Заставить систему чеканить токены на свой счет | Целостность (по всей системе) | Средний | Ниже среднего | Если злоумышленник сможет создавать токены на своём счету "из воздуха" — это будет прямым финансовым вознаграждением за проведение атаки. | +| Валидировать вредные блоки, чтобы реализовать двойную трату токенов | Доступность (в масштабе системы) | Высокий | Средний | Если злоумышленники смогут использовать двойную трату токенов, они смогут получать услуги, не оплачивая их. Это дает им высокий денежный стимул для выполнения нападения. | +| Подорвать механизм консенсуса, чтобы расколоть цепочку | Целостность (по всей системе) | Высокий | Высокий | Если злоумышленник может использовать двойную трату токенов, он способен получать услуги, не оплачивая их. Это дает им высокий денежный стимул для выполнения нападения. Ставки на снижение стоимости криптовалюты или если конкуренты хотят навредить репутации, так что стоимость их блокчейна увеличивается. | +| Фальсифисировать/манипулировать историей блокчейна для аннулирования транзакций (например, результат голосования) | Целостность (по всей системе) | Средний | Выше среднего | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Подорвать блокчейн или механизм консенсуса, чтобы нанести ущерб репутации экосистемы | Наличие (в масштабе системы) | Высокий | Высокий | Делая ставку на снижение стоимости криптовалюты или конкуренты хотят нанести ущерб репутации, так что ценность их блокчейна возрастает | +| Цензура | Наличие (в масштабе системы) | Средний | Высокий | Хакеры способны блокировать нежелательные типы транзакций (например, транзакции отраслевых конкурентов или голосование на референдуме). Это может быть достигнуто путем сговора с другими заинтересованными сторонами или иным способом получения большего числа голосов. | +| Деанонимизировать пользователей | Конфиденциальность (Узел/Нода) | Средний | Средний | Стороны, желающие деанонимизировать пользователей, могут использовать эту информацию для угнетения оппозиции (например, политических активистов). | +| Украсть токен из узла/ноды | Целостность (узел) | Высокий | Высокий | Атакующие, способные украсть токены с узлов могут претендовать на активы, что дает им высокий денежный стимул к совершению нападения. | +| Украсть токен из узла путем утечки учётных данных | Конфиденциальность (Узел/Нода) | Высокий | Высокий | Атакующие, способные украсть токены с узлов могут претендовать на активы, что дает им высокий денежный стимул к совершению нападения. | +| Запретить узлу доступ к сети Polkadot | Доступность (узел) | Низкий | Ниже среднего | Запуск целенаправленной атаки отказа в обслуживании (DDoS) из мести, денежных интересов (в случае конкурирующего обмена монет и т. д.). | +| Обманывать других участников | Целостность (узел) | Средний | Ниже среднего | Злоумышленник может злоупотребить непониманием другими участниками гарантий безопасности Polkadot, чтобы обмануть их. Кроме того, если вознаграждение за вызывающее плохое поведение может быть настроено таким образом, чтобы оно было выше соответствующего наказания, можно настроить набор саморегулируемых узлов для генерации исходного цикла. Другие участники этой атаки не нужны. | +| Обманывать других участников | Целостность (по всей системе) | Высокий | Высокий | Злоумышленник может злоупотреблять ошибками в экономической системе Polkadot, чтобы обмануть других участников. Например, злоумышленник может использовать логическую ошибку, чтобы не платить комиссию за транзакцию. | diff --git a/website/translated_docs/ru/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/ru/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/ru/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/ru/kusama-bug-bounty.md diff --git a/website/translated_docs/ru/kusama-claims.md b/polkadot-wiki/translated_docs/ru/kusama-claims.md similarity index 100% rename from website/translated_docs/ru/kusama-claims.md rename to polkadot-wiki/translated_docs/ru/kusama-claims.md diff --git a/website/translated_docs/ru/kusama-coc.md b/polkadot-wiki/translated_docs/ru/kusama-coc.md similarity index 100% rename from website/translated_docs/ru/kusama-coc.md rename to polkadot-wiki/translated_docs/ru/kusama-coc.md diff --git a/website/translated_docs/ru/kusama-community.md b/polkadot-wiki/translated_docs/ru/kusama-community.md similarity index 100% rename from website/translated_docs/ru/kusama-community.md rename to polkadot-wiki/translated_docs/ru/kusama-community.md diff --git a/website/translated_docs/ru/kusama-endpoints.md b/polkadot-wiki/translated_docs/ru/kusama-endpoints.md similarity index 100% rename from website/translated_docs/ru/kusama-endpoints.md rename to polkadot-wiki/translated_docs/ru/kusama-endpoints.md diff --git a/website/translated_docs/ru/kusama-faucet.md b/polkadot-wiki/translated_docs/ru/kusama-faucet.md similarity index 100% rename from website/translated_docs/ru/kusama-faucet.md rename to polkadot-wiki/translated_docs/ru/kusama-faucet.md diff --git a/website/translated_docs/ru/kusama-getting-started.md b/polkadot-wiki/translated_docs/ru/kusama-getting-started.md similarity index 100% rename from website/translated_docs/ru/kusama-getting-started.md rename to polkadot-wiki/translated_docs/ru/kusama-getting-started.md diff --git a/website/translated_docs/ru/kusama-index.md b/polkadot-wiki/translated_docs/ru/kusama-index.md similarity index 100% rename from website/translated_docs/ru/kusama-index.md rename to polkadot-wiki/translated_docs/ru/kusama-index.md diff --git a/polkadot-wiki/translated_docs/ru/kusama-ledger.md b/polkadot-wiki/translated_docs/ru/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/ru/kusama-parameters.md b/polkadot-wiki/translated_docs/ru/kusama-parameters.md new file mode 100644 index 000000000000..b56360b897b6 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Параматры +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Периоды общих действий и атрибутов + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Эпоха: 1 час (600 слотов x 6 секунд) +- Сессия: 1 час (6 сессий в эре) +- Эра: 6 часов (3600 слотов x 6 секунд) + +| Kusama | Время | Слоты\* | +| ------ | -------- | ------- | +| Slot | 6 секунд | 1 | +| Эпоха | 1 час | 600 | +| Сессия | 1 час | 600 | +| Эра | 6 часов | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Управление + +| Демократия | Время | Слоты | Описание | +| ------------------ | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Период голосования | 7 дней | 100,800 | Как долго общественность может голосовать за референдум. | +| Период запуска | 7 дней | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Период принятия | 8 дней | 115,200 | Время на успешное проведение референдума в сети. | + +| Совет | Время | Слоты | Описание | +| ------------------ | ------ | ------ | ------------------------------------------------------------------------------------ | +| Срок действия | 1 день | 14,400 | Продолжительность срока полномочий члена совета до следующего избирательного раунда. | +| Период голосования | 1 день | 14,400 | Период голосования по предложениям в Совете. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Технический комитет | Время | Слоты | Описание | +| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------- | +| Период ожидания | 7 дней | 604,800 | Время вето от технического комитета длится до того, как предложение будет вновь представлено. | +| Период экстренного голосования | 3 часов | 1,800 | Период голосования после того, как технический комитет ускорит голосование. | + +### Стейкинг, валидация и номинирование + +| Kusama | Время | Слоты | Описание | +| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Срок действия | 6 часов | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Период номинации | 6 часов | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Длительность бондинга | 7 дней | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Длительность отсрочки слэшинга | 7 дней | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Казначейство + +| Казна | Время | Слоты | Описание | +| ----------------------- | ------ | ------ | ------------------------------------------------------------------------- | +| Периоды между расходами | 6 дней | 86,400 | Когда казначейство может потратить средства снова после предидущей траты. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ru/kusama-social-recovery.md b/polkadot-wiki/translated_docs/ru/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/ru/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/ru/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/ru/kusama-time-periods.md b/polkadot-wiki/translated_docs/ru/kusama-time-periods.md new file mode 100644 index 000000000000..04c0a93f0497 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: временные-периоды-kusama +title: Шпаргалка по временным периодам +sidebar_label: Параматры +--- + +### Периоды общих действий и атрибутов + +_ПРИМЕЧАНИЕ: Kusama в 4 раза быстрее Polkadot, кроме времени блока, как и в Polkadot это 6 секунд._ + +- Блок: 6 секунд +- Эпоха: 1 час (600 слотов x 6 секунд) +- Сессия: 1 час (6 сессий в эре) +- Эра: 6 часов (3600 слотов x 6 секунд) + +| Kusama | Время | Слоты\* | +| ------ | -------- | ------- | +| Блок | 6 секунд | 1 | +| Эпоха | 1 час | 600 | +| Сессия | 1 час | 600 | +| Эра | 6 часов | 3,600 | + +\*_В цепочке может быть не более одного блока на слот._ + +### Управление + +| Демократия | Время | Слоты | Описание | +| ------------------ | ------ | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Период голосования | 7 дней | 604,800 | Как долго общественность может голосовать за референдум. | +| Период запуска | 7 дней | 604,800 | Как долго общественность может выбрать, по какому предложению проводить референдум. Каждую неделю будет выбираться наиболее взвешенное предложение для проведения референдума | +| Период принятия | 8 дней | 691,200 | Время на успешное проведение референдума в сети. | + +| Совет | Время | Слоты | Описание | +| ------------------ | ------ | ------ | ------------------------------------------------------------------------------------ | +| Срок действия | 1 день | 14,400 | Продолжительность срока полномочий члена совета до следующего избирательного раунда. | +| Период голосования | 1 день | 14,400 | Период голосования по предложениям в Совете. | + +| Технический комитет | Время | Слоты | Описание | +| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------- | +| Период ожидания | 7 дней | 604,800 | Время вето от технического комитета длится до того, как предложение будет вновь представлено. | +| Период экстренного голосования | 3 часов | 1,800 | Период голосования после того, как технический комитет ускорит голосование. | + +### Стейкинг, валидация и номинирование + +| Kusama | Время | Слоты | Описание | +| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Срок действия | 6 часов | 3,600 | Время, в течение которого валидатор находится в наборе после избрания. Обратите внимание, что эта продолжительность может быть сокращена в том случае, если валидатор плохо себя ведет. | +| Период номинации | 6 часов | 3,600 | Каждые 6 часов новый набор валидаторов выбирается в соответствии с методом Phragmen. | +| Длительность бондинга | 7 дней | 604,800 | Как долго Ваши средства будут не перемещаемыми после отмены бондинга. | +| Длительность отсрочки слэшинга | 7 дней | 604,800 | Предотвращает чрезмерный слешинг и "побег" валидаторов, а так же получают своих номинаторов порезанными без каких-либо последствий для себя | + +### Казначейство + +| Казна | Время | Слоты | Описание | +| ----------------------- | ------ | ------- | ------------------------------------------------------------------------- | +| Периоды между расходами | 6 дней | 518,400 | Когда казначейство может потратить средства снова после предидущей траты. | diff --git a/website/translated_docs/ru/kusama-timeline.md b/polkadot-wiki/translated_docs/ru/kusama-timeline.md similarity index 100% rename from website/translated_docs/ru/kusama-timeline.md rename to polkadot-wiki/translated_docs/ru/kusama-timeline.md diff --git a/website/translated_docs/ru/learn-DOT.md b/polkadot-wiki/translated_docs/ru/learn-DOT.md similarity index 100% rename from website/translated_docs/ru/learn-DOT.md rename to polkadot-wiki/translated_docs/ru/learn-DOT.md diff --git a/website/translated_docs/ru/learn-PRE.md b/polkadot-wiki/translated_docs/ru/learn-PRE.md similarity index 100% rename from website/translated_docs/ru/learn-PRE.md rename to polkadot-wiki/translated_docs/ru/learn-PRE.md diff --git a/polkadot-wiki/translated_docs/ru/learn-UI.md b/polkadot-wiki/translated_docs/ru/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/ru/learn-account-generation.md b/polkadot-wiki/translated_docs/ru/learn-account-generation.md similarity index 100% rename from website/translated_docs/ru/learn-account-generation.md rename to polkadot-wiki/translated_docs/ru/learn-account-generation.md diff --git a/website/translated_docs/ru/learn-account-restore.md b/polkadot-wiki/translated_docs/ru/learn-account-restore.md similarity index 100% rename from website/translated_docs/ru/learn-account-restore.md rename to polkadot-wiki/translated_docs/ru/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/ru/learn-accounts.md b/polkadot-wiki/translated_docs/ru/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ru/learn-architecture.md b/polkadot-wiki/translated_docs/ru/learn-architecture.md similarity index 100% rename from website/translated_docs/ru/learn-architecture.md rename to polkadot-wiki/translated_docs/ru/learn-architecture.md diff --git a/website/translated_docs/ru/learn-auction.md b/polkadot-wiki/translated_docs/ru/learn-auction.md similarity index 100% rename from website/translated_docs/ru/learn-auction.md rename to polkadot-wiki/translated_docs/ru/learn-auction.md diff --git a/polkadot-wiki/translated_docs/ru/learn-availability.md b/polkadot-wiki/translated_docs/ru/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/ru/learn-balance-transfers.md b/polkadot-wiki/translated_docs/ru/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/ru/learn-bridges.md b/polkadot-wiki/translated_docs/ru/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ru/learn-collator.md b/polkadot-wiki/translated_docs/ru/learn-collator.md similarity index 100% rename from website/translated_docs/ru/learn-collator.md rename to polkadot-wiki/translated_docs/ru/learn-collator.md diff --git a/website/translated_docs/ru/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/ru/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/ru/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/ru/learn-comparison-dfinity.md diff --git a/website/translated_docs/ru/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/ru/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/ru/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/ru/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/ru/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/ru/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/ru/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/ru/learn-comparisons-cosmos.md diff --git a/website/translated_docs/ru/learn-comparisons.md b/polkadot-wiki/translated_docs/ru/learn-comparisons.md similarity index 100% rename from website/translated_docs/ru/learn-comparisons.md rename to polkadot-wiki/translated_docs/ru/learn-comparisons.md diff --git a/website/translated_docs/ru/learn-consensus.md b/polkadot-wiki/translated_docs/ru/learn-consensus.md similarity index 100% rename from website/translated_docs/ru/learn-consensus.md rename to polkadot-wiki/translated_docs/ru/learn-consensus.md diff --git a/website/translated_docs/ru/learn-crosschain.md b/polkadot-wiki/translated_docs/ru/learn-crosschain.md similarity index 100% rename from website/translated_docs/ru/learn-crosschain.md rename to polkadot-wiki/translated_docs/ru/learn-crosschain.md diff --git a/website/translated_docs/ru/learn-crowdloans.md b/polkadot-wiki/translated_docs/ru/learn-crowdloans.md similarity index 100% rename from website/translated_docs/ru/learn-crowdloans.md rename to polkadot-wiki/translated_docs/ru/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/ru/learn-cryptography.md b/polkadot-wiki/translated_docs/ru/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ru/learn-faq.md b/polkadot-wiki/translated_docs/ru/learn-faq.md similarity index 100% rename from website/translated_docs/ru/learn-faq.md rename to polkadot-wiki/translated_docs/ru/learn-faq.md diff --git a/polkadot-wiki/translated_docs/ru/learn-governance.md b/polkadot-wiki/translated_docs/ru/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ru/learn-identity.md b/polkadot-wiki/translated_docs/ru/learn-identity.md similarity index 100% rename from website/translated_docs/ru/learn-identity.md rename to polkadot-wiki/translated_docs/ru/learn-identity.md diff --git a/website/translated_docs/ru/learn-implementations.md b/polkadot-wiki/translated_docs/ru/learn-implementations.md similarity index 100% rename from website/translated_docs/ru/learn-implementations.md rename to polkadot-wiki/translated_docs/ru/learn-implementations.md diff --git a/website/translated_docs/ru/learn-implementers-guide.md b/polkadot-wiki/translated_docs/ru/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/ru/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/ru/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/ru/learn-interchain.md b/polkadot-wiki/translated_docs/ru/learn-interchain.md new file mode 100644 index 000000000000..2677ee91d812 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. + +The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. + +## Overview + +- Interchain messages will _not_ go on to the relay chain. +- Interchain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. + +## Example + +A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. + +When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/ru/learn-introduction.md b/polkadot-wiki/translated_docs/ru/learn-introduction.md similarity index 100% rename from website/translated_docs/ru/learn-introduction.md rename to polkadot-wiki/translated_docs/ru/learn-introduction.md diff --git a/website/translated_docs/ru/learn-keys.md b/polkadot-wiki/translated_docs/ru/learn-keys.md similarity index 100% rename from website/translated_docs/ru/learn-keys.md rename to polkadot-wiki/translated_docs/ru/learn-keys.md diff --git a/website/translated_docs/ru/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/ru/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/ru/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/ru/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/ru/learn-launch.md b/polkadot-wiki/translated_docs/ru/learn-launch.md similarity index 100% rename from website/translated_docs/ru/learn-launch.md rename to polkadot-wiki/translated_docs/ru/learn-launch.md diff --git a/website/translated_docs/ru/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/ru/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/ru/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/ru/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/ru/learn-ledger.md b/polkadot-wiki/translated_docs/ru/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ru/learn-nominator.md b/polkadot-wiki/translated_docs/ru/learn-nominator.md similarity index 100% rename from website/translated_docs/ru/learn-nominator.md rename to polkadot-wiki/translated_docs/ru/learn-nominator.md diff --git a/website/translated_docs/ru/learn-parachains.md b/polkadot-wiki/translated_docs/ru/learn-parachains.md similarity index 100% rename from website/translated_docs/ru/learn-parachains.md rename to polkadot-wiki/translated_docs/ru/learn-parachains.md diff --git a/website/translated_docs/ru/learn-parathreads.md b/polkadot-wiki/translated_docs/ru/learn-parathreads.md similarity index 100% rename from website/translated_docs/ru/learn-parathreads.md rename to polkadot-wiki/translated_docs/ru/learn-parathreads.md diff --git a/website/translated_docs/ru/learn-phragmen.md b/polkadot-wiki/translated_docs/ru/learn-phragmen.md similarity index 100% rename from website/translated_docs/ru/learn-phragmen.md rename to polkadot-wiki/translated_docs/ru/learn-phragmen.md diff --git a/website/translated_docs/ru/learn-polkadot-host.md b/polkadot-wiki/translated_docs/ru/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/ru/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/ru/learn-polkadot-host.md diff --git a/website/translated_docs/ru/learn-proxies.md b/polkadot-wiki/translated_docs/ru/learn-proxies.md similarity index 100% rename from website/translated_docs/ru/learn-proxies.md rename to polkadot-wiki/translated_docs/ru/learn-proxies.md diff --git a/website/translated_docs/ru/learn-randomness.md b/polkadot-wiki/translated_docs/ru/learn-randomness.md similarity index 100% rename from website/translated_docs/ru/learn-randomness.md rename to polkadot-wiki/translated_docs/ru/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/ru/learn-registrar.md b/polkadot-wiki/translated_docs/ru/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ru/learn-relevant-links.md b/polkadot-wiki/translated_docs/ru/learn-relevant-links.md similarity index 100% rename from website/translated_docs/ru/learn-relevant-links.md rename to polkadot-wiki/translated_docs/ru/learn-relevant-links.md diff --git a/website/translated_docs/ru/learn-roadmap.md b/polkadot-wiki/translated_docs/ru/learn-roadmap.md similarity index 100% rename from website/translated_docs/ru/learn-roadmap.md rename to polkadot-wiki/translated_docs/ru/learn-roadmap.md diff --git a/website/translated_docs/ru/learn-scams.md b/polkadot-wiki/translated_docs/ru/learn-scams.md similarity index 100% rename from website/translated_docs/ru/learn-scams.md rename to polkadot-wiki/translated_docs/ru/learn-scams.md diff --git a/website/translated_docs/ru/learn-security.md b/polkadot-wiki/translated_docs/ru/learn-security.md similarity index 100% rename from website/translated_docs/ru/learn-security.md rename to polkadot-wiki/translated_docs/ru/learn-security.md diff --git a/website/translated_docs/ru/learn-simple-payouts.md b/polkadot-wiki/translated_docs/ru/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/ru/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/ru/learn-simple-payouts.md diff --git a/website/translated_docs/ru/learn-spree.md b/polkadot-wiki/translated_docs/ru/learn-spree.md similarity index 100% rename from website/translated_docs/ru/learn-spree.md rename to polkadot-wiki/translated_docs/ru/learn-spree.md diff --git a/polkadot-wiki/translated_docs/ru/learn-staking.md b/polkadot-wiki/translated_docs/ru/learn-staking.md new file mode 100644 index 000000000000..5bb6dfc0fa74 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on secure validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ru/learn-transaction-fees.md b/polkadot-wiki/translated_docs/ru/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/ru/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/ru/learn-transaction-fees.md diff --git a/website/translated_docs/ru/learn-transactions.md b/polkadot-wiki/translated_docs/ru/learn-transactions.md similarity index 100% rename from website/translated_docs/ru/learn-transactions.md rename to polkadot-wiki/translated_docs/ru/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/ru/learn-treasury.md b/polkadot-wiki/translated_docs/ru/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ru/learn-validator.md b/polkadot-wiki/translated_docs/ru/learn-validator.md similarity index 100% rename from website/translated_docs/ru/learn-validator.md rename to polkadot-wiki/translated_docs/ru/learn-validator.md diff --git a/website/translated_docs/ru/learn-wasm.md b/polkadot-wiki/translated_docs/ru/learn-wasm.md similarity index 100% rename from website/translated_docs/ru/learn-wasm.md rename to polkadot-wiki/translated_docs/ru/learn-wasm.md diff --git a/website/translated_docs/ru/maintain-collator.md b/polkadot-wiki/translated_docs/ru/maintain-collator.md similarity index 100% rename from website/translated_docs/ru/maintain-collator.md rename to polkadot-wiki/translated_docs/ru/maintain-collator.md diff --git a/website/translated_docs/ru/maintain-errors.md b/polkadot-wiki/translated_docs/ru/maintain-errors.md similarity index 100% rename from website/translated_docs/ru/maintain-errors.md rename to polkadot-wiki/translated_docs/ru/maintain-errors.md diff --git a/polkadot-wiki/translated_docs/ru/maintain-governance-index.md b/polkadot-wiki/translated_docs/ru/maintain-governance-index.md new file mode 100644 index 000000000000..8812e030de6c --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-governance-index.md @@ -0,0 +1,185 @@ +--- +id: maintain-governance-index +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. + +All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. + +The following steps are the governance procedure in the Polkadot network: + +- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) +- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) +- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) + +To better understand how the council is formed, please read [this section](#council). + +### Proposing Referenda + +- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. + +- **[Council](#council)**: + + Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. + + Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) + +### Voting for a proposal + +To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). + +``` +Example: + +Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes +``` + +According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. + +### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +voters - the total number of voting tokens + +electorate - the total number of DOTs tokens issued in the network +``` + +**Super-Majority Approve** + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ + +**Super-Majority Against** + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ + +**Simple-Majority** + +Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ + +_To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume we only have 1,500 DOTs tokens in total. + +John - 500 DOTs +Peter - 100 DOTs +Lilly - 150 DOTs +JJ - 150 DOTs +Ken - 600 DOTs + +John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +voters = 1050 +electorate = 1500 +``` + +$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ + +$${13.887} < {15.492}$$ + +Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. + +## Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: + +``` +Max votes = tokens * periods +``` + +Based on the current testnet setting, the maximum number of lock periods is set to 6. + +**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** + +## Adaptive Quorum Biasing + +Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. + +Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. + +Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. + +In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +## Council + +Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. + +To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. + +Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. + +Let's take a look at the example below. + +||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. + +### Resources + +- [Governance Description](learn-governance#referenda) +- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) + +## [Usage of DOT](learn-DOT#dots-for-governance) + +## Guides + +### [How to create a proposal]() + +### [How to join the council]() + +### [How to propose a referenda]() diff --git a/website/translated_docs/ru/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/ru/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-democracy.md diff --git a/website/translated_docs/ru/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/ru/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/ru/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/ru/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate-polkadot.md diff --git a/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate.md new file mode 100644 index 000000000000..20b9f634ea64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-nominate.md @@ -0,0 +1,59 @@ +--- +id: maintain-guides-how-to-nominate +title: How to nominate +sidebar_label: How to nominate +--- + +This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. + +It has been updated for the Alexander testnet and Polkadot release PoC-4. + +## Create `stash` and `controller` accounts + +We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. + +The first step is to create two accounts by going to the _Accounts_ tab on the Polkadot Dashboard and clicking on [_Add account_](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. + +![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) + +Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. + +## Nominating + +It is now time to setup our nominator. We will do the following: + +- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. +- Select the `controller`. This is the account that will decide when to start or stop nominating. + +First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. + +![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. +- **Controller account** - select the `controller` account created earlier. +- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). +- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). + +Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. + +![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) + +## Nominating a validator + +Go to the _Staking Overview_ tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. + +![Validators](assets/guides/how-to-nominate/validators.png) + +Go back to the _Account Actions_ tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). + +![Nominating](assets/guides/how-to-nominate/nominating.jpg) + +**Congratulations!** You are now a nominator. + +If you return to the _Staking Overview_ tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. + +![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) + +## How to stop nominating + +To stop nominating simply return to the _Account Actions_ tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/ru/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/ru/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/ru/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/ru/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/ru/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/ru/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/ru/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/ru/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/ru/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ru/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/ru/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ru/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/ru/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/ru/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/ru/maintain-guides-validator-payout.md diff --git a/website/translated_docs/pt-BR/maintain-index.md b/polkadot-wiki/translated_docs/ru/maintain-index.md similarity index 100% rename from website/translated_docs/pt-BR/maintain-index.md rename to polkadot-wiki/translated_docs/ru/maintain-index.md diff --git a/website/translated_docs/ru/maintain-networks.md b/polkadot-wiki/translated_docs/ru/maintain-networks.md similarity index 100% rename from website/translated_docs/ru/maintain-networks.md rename to polkadot-wiki/translated_docs/ru/maintain-networks.md diff --git a/website/translated_docs/ru/maintain-node-operator.md b/polkadot-wiki/translated_docs/ru/maintain-node-operator.md similarity index 100% rename from website/translated_docs/ru/maintain-node-operator.md rename to polkadot-wiki/translated_docs/ru/maintain-node-operator.md diff --git a/website/translated_docs/ru/maintain-nominator.md b/polkadot-wiki/translated_docs/ru/maintain-nominator.md similarity index 100% rename from website/translated_docs/ru/maintain-nominator.md rename to polkadot-wiki/translated_docs/ru/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/ru/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/ru/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/sk-SK/maintain-sync.md b/polkadot-wiki/translated_docs/ru/maintain-sync.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-sync.md rename to polkadot-wiki/translated_docs/ru/maintain-sync.md diff --git a/website/translated_docs/ru/maintain-validator.md b/polkadot-wiki/translated_docs/ru/maintain-validator.md similarity index 100% rename from website/translated_docs/ru/maintain-validator.md rename to polkadot-wiki/translated_docs/ru/maintain-validator.md diff --git a/website/translated_docs/ru/maintain-wss.md b/polkadot-wiki/translated_docs/ru/maintain-wss.md similarity index 100% rename from website/translated_docs/ru/maintain-wss.md rename to polkadot-wiki/translated_docs/ru/maintain-wss.md diff --git a/website/translated_docs/ru/news.md b/polkadot-wiki/translated_docs/ru/news.md similarity index 100% rename from website/translated_docs/ru/news.md rename to polkadot-wiki/translated_docs/ru/news.md diff --git a/polkadot-wiki/translated_docs/ru/redenomination.md b/polkadot-wiki/translated_docs/ru/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ru/research.md b/polkadot-wiki/translated_docs/ru/research.md similarity index 100% rename from website/translated_docs/ru/research.md rename to polkadot-wiki/translated_docs/ru/research.md diff --git a/polkadot-wiki/translated_docs/ru/thousand-validators.md b/polkadot-wiki/translated_docs/ru/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ru/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/sk-SK/ambassadors.md b/polkadot-wiki/translated_docs/sk-SK/ambassadors.md similarity index 100% rename from website/translated_docs/sk-SK/ambassadors.md rename to polkadot-wiki/translated_docs/sk-SK/ambassadors.md diff --git a/website/translated_docs/sk-SK/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/sk-SK/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/sk-SK/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/sk-SK/build-build-with-polkadot.md diff --git a/website/translated_docs/sk-SK/build-cumulus.md b/polkadot-wiki/translated_docs/sk-SK/build-cumulus.md similarity index 100% rename from website/translated_docs/sk-SK/build-cumulus.md rename to polkadot-wiki/translated_docs/sk-SK/build-cumulus.md diff --git a/website/translated_docs/sk-SK/build-deploy-parachains.md b/polkadot-wiki/translated_docs/sk-SK/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/sk-SK/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/sk-SK/build-deploy-parachains.md diff --git a/website/translated_docs/sk-SK/build-dev-roadmap.md b/polkadot-wiki/translated_docs/sk-SK/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/sk-SK/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/sk-SK/build-dev-roadmap.md diff --git a/website/translated_docs/sk-SK/build-examples-index.md b/polkadot-wiki/translated_docs/sk-SK/build-examples-index.md similarity index 100% rename from website/translated_docs/sk-SK/build-examples-index.md rename to polkadot-wiki/translated_docs/sk-SK/build-examples-index.md diff --git a/website/translated_docs/sk-SK/build-hackathon.md b/polkadot-wiki/translated_docs/sk-SK/build-hackathon.md similarity index 100% rename from website/translated_docs/sk-SK/build-hackathon.md rename to polkadot-wiki/translated_docs/sk-SK/build-hackathon.md diff --git a/website/translated_docs/sk-SK/build-index.md b/polkadot-wiki/translated_docs/sk-SK/build-index.md similarity index 100% rename from website/translated_docs/sk-SK/build-index.md rename to polkadot-wiki/translated_docs/sk-SK/build-index.md diff --git a/website/translated_docs/sk-SK/build-integration.md b/polkadot-wiki/translated_docs/sk-SK/build-integration.md similarity index 100% rename from website/translated_docs/sk-SK/build-integration.md rename to polkadot-wiki/translated_docs/sk-SK/build-integration.md diff --git a/website/translated_docs/sk-SK/build-node-interaction.md b/polkadot-wiki/translated_docs/sk-SK/build-node-interaction.md similarity index 100% rename from website/translated_docs/sk-SK/build-node-interaction.md rename to polkadot-wiki/translated_docs/sk-SK/build-node-interaction.md diff --git a/website/translated_docs/sk-SK/build-node-management.md b/polkadot-wiki/translated_docs/sk-SK/build-node-management.md similarity index 100% rename from website/translated_docs/sk-SK/build-node-management.md rename to polkadot-wiki/translated_docs/sk-SK/build-node-management.md diff --git a/website/translated_docs/sk-SK/build-oracle.md b/polkadot-wiki/translated_docs/sk-SK/build-oracle.md similarity index 100% rename from website/translated_docs/sk-SK/build-oracle.md rename to polkadot-wiki/translated_docs/sk-SK/build-oracle.md diff --git a/website/translated_docs/sk-SK/build-parachains-rococo.md b/polkadot-wiki/translated_docs/sk-SK/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/sk-SK/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/sk-SK/build-parachains-rococo.md diff --git a/website/translated_docs/sk-SK/build-pdk.md b/polkadot-wiki/translated_docs/sk-SK/build-pdk.md similarity index 100% rename from website/translated_docs/sk-SK/build-pdk.md rename to polkadot-wiki/translated_docs/sk-SK/build-pdk.md diff --git a/polkadot-wiki/translated_docs/sk-SK/build-protocol-info.md b/polkadot-wiki/translated_docs/sk-SK/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/sk-SK/build-smart-contracts.md b/polkadot-wiki/translated_docs/sk-SK/build-smart-contracts.md similarity index 100% rename from website/translated_docs/sk-SK/build-smart-contracts.md rename to polkadot-wiki/translated_docs/sk-SK/build-smart-contracts.md diff --git a/website/translated_docs/sk-SK/build-tools-index.md b/polkadot-wiki/translated_docs/sk-SK/build-tools-index.md similarity index 100% rename from website/translated_docs/sk-SK/build-tools-index.md rename to polkadot-wiki/translated_docs/sk-SK/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/sk-SK/build-transaction-construction.md b/polkadot-wiki/translated_docs/sk-SK/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/sk-SK/build-wallets.md b/polkadot-wiki/translated_docs/sk-SK/build-wallets.md similarity index 100% rename from website/translated_docs/sk-SK/build-wallets.md rename to polkadot-wiki/translated_docs/sk-SK/build-wallets.md diff --git a/polkadot-wiki/translated_docs/sk-SK/claims.md b/polkadot-wiki/translated_docs/sk-SK/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/sk-SK/community.md b/polkadot-wiki/translated_docs/sk-SK/community.md similarity index 100% rename from website/translated_docs/sk-SK/community.md rename to polkadot-wiki/translated_docs/sk-SK/community.md diff --git a/website/translated_docs/sk-SK/contributing.md b/polkadot-wiki/translated_docs/sk-SK/contributing.md similarity index 100% rename from website/translated_docs/sk-SK/contributing.md rename to polkadot-wiki/translated_docs/sk-SK/contributing.md diff --git a/website/translated_docs/sk-SK/contributors.md b/polkadot-wiki/translated_docs/sk-SK/contributors.md similarity index 100% rename from website/translated_docs/sk-SK/contributors.md rename to polkadot-wiki/translated_docs/sk-SK/contributors.md diff --git a/website/translated_docs/sk-SK/ens.md b/polkadot-wiki/translated_docs/sk-SK/ens.md similarity index 100% rename from website/translated_docs/sk-SK/ens.md rename to polkadot-wiki/translated_docs/sk-SK/ens.md diff --git a/website/translated_docs/sk-SK/faq.md b/polkadot-wiki/translated_docs/sk-SK/faq.md similarity index 100% rename from website/translated_docs/sk-SK/faq.md rename to polkadot-wiki/translated_docs/sk-SK/faq.md diff --git a/polkadot-wiki/translated_docs/sk-SK/getting-started.md b/polkadot-wiki/translated_docs/sk-SK/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/sk-SK/glossary.md b/polkadot-wiki/translated_docs/sk-SK/glossary.md similarity index 100% rename from website/translated_docs/sk-SK/glossary.md rename to polkadot-wiki/translated_docs/sk-SK/glossary.md diff --git a/polkadot-wiki/translated_docs/sk-SK/grants.md b/polkadot-wiki/translated_docs/sk-SK/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/sk-SK/index.md b/polkadot-wiki/translated_docs/sk-SK/index.md similarity index 100% rename from website/translated_docs/sk-SK/index.md rename to polkadot-wiki/translated_docs/sk-SK/index.md diff --git a/polkadot-wiki/translated_docs/sk-SK/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/sk-SK/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/sk-SK/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/sk-SK/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-bug-bounty.md diff --git a/website/translated_docs/sk-SK/kusama-claims.md b/polkadot-wiki/translated_docs/sk-SK/kusama-claims.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-claims.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-claims.md diff --git a/website/translated_docs/sk-SK/kusama-coc.md b/polkadot-wiki/translated_docs/sk-SK/kusama-coc.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-coc.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-coc.md diff --git a/website/translated_docs/sk-SK/kusama-community.md b/polkadot-wiki/translated_docs/sk-SK/kusama-community.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-community.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-community.md diff --git a/website/translated_docs/sk-SK/kusama-endpoints.md b/polkadot-wiki/translated_docs/sk-SK/kusama-endpoints.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-endpoints.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-endpoints.md diff --git a/website/translated_docs/sk-SK/kusama-faucet.md b/polkadot-wiki/translated_docs/sk-SK/kusama-faucet.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-faucet.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-faucet.md diff --git a/website/translated_docs/sk-SK/kusama-getting-started.md b/polkadot-wiki/translated_docs/sk-SK/kusama-getting-started.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-getting-started.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-getting-started.md diff --git a/website/translated_docs/sk-SK/kusama-index.md b/polkadot-wiki/translated_docs/sk-SK/kusama-index.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-index.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-index.md diff --git a/polkadot-wiki/translated_docs/sk-SK/kusama-ledger.md b/polkadot-wiki/translated_docs/sk-SK/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/sk-SK/kusama-parameters.md b/polkadot-wiki/translated_docs/sk-SK/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/sk-SK/kusama-social-recovery.md b/polkadot-wiki/translated_docs/sk-SK/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/sk-SK/kusama-time-periods.md b/polkadot-wiki/translated_docs/sk-SK/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/sk-SK/kusama-timeline.md b/polkadot-wiki/translated_docs/sk-SK/kusama-timeline.md similarity index 100% rename from website/translated_docs/sk-SK/kusama-timeline.md rename to polkadot-wiki/translated_docs/sk-SK/kusama-timeline.md diff --git a/website/translated_docs/sk-SK/learn-DOT.md b/polkadot-wiki/translated_docs/sk-SK/learn-DOT.md similarity index 100% rename from website/translated_docs/sk-SK/learn-DOT.md rename to polkadot-wiki/translated_docs/sk-SK/learn-DOT.md diff --git a/website/translated_docs/sk-SK/learn-account-generation.md b/polkadot-wiki/translated_docs/sk-SK/learn-account-generation.md similarity index 100% rename from website/translated_docs/sk-SK/learn-account-generation.md rename to polkadot-wiki/translated_docs/sk-SK/learn-account-generation.md diff --git a/website/translated_docs/sk-SK/learn-account-restore.md b/polkadot-wiki/translated_docs/sk-SK/learn-account-restore.md similarity index 100% rename from website/translated_docs/sk-SK/learn-account-restore.md rename to polkadot-wiki/translated_docs/sk-SK/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-accounts.md b/polkadot-wiki/translated_docs/sk-SK/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/sk-SK/learn-architecture.md b/polkadot-wiki/translated_docs/sk-SK/learn-architecture.md similarity index 100% rename from website/translated_docs/sk-SK/learn-architecture.md rename to polkadot-wiki/translated_docs/sk-SK/learn-architecture.md diff --git a/website/translated_docs/sk-SK/learn-auction.md b/polkadot-wiki/translated_docs/sk-SK/learn-auction.md similarity index 100% rename from website/translated_docs/sk-SK/learn-auction.md rename to polkadot-wiki/translated_docs/sk-SK/learn-auction.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-availability.md b/polkadot-wiki/translated_docs/sk-SK/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-balance-transfers.md b/polkadot-wiki/translated_docs/sk-SK/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-bridges.md b/polkadot-wiki/translated_docs/sk-SK/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/sk-SK/learn-collator.md b/polkadot-wiki/translated_docs/sk-SK/learn-collator.md similarity index 100% rename from website/translated_docs/sk-SK/learn-collator.md rename to polkadot-wiki/translated_docs/sk-SK/learn-collator.md diff --git a/website/translated_docs/sk-SK/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/sk-SK/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/sk-SK/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/sk-SK/learn-comparison-dfinity.md diff --git a/website/translated_docs/sk-SK/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/sk-SK/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/sk-SK/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/sk-SK/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/sk-SK/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/sk-SK/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/sk-SK/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/sk-SK/learn-comparisons-cosmos.md diff --git a/website/translated_docs/sk-SK/learn-comparisons.md b/polkadot-wiki/translated_docs/sk-SK/learn-comparisons.md similarity index 100% rename from website/translated_docs/sk-SK/learn-comparisons.md rename to polkadot-wiki/translated_docs/sk-SK/learn-comparisons.md diff --git a/website/translated_docs/sk-SK/learn-consensus.md b/polkadot-wiki/translated_docs/sk-SK/learn-consensus.md similarity index 100% rename from website/translated_docs/sk-SK/learn-consensus.md rename to polkadot-wiki/translated_docs/sk-SK/learn-consensus.md diff --git a/website/translated_docs/sk-SK/learn-crosschain.md b/polkadot-wiki/translated_docs/sk-SK/learn-crosschain.md similarity index 100% rename from website/translated_docs/sk-SK/learn-crosschain.md rename to polkadot-wiki/translated_docs/sk-SK/learn-crosschain.md diff --git a/website/translated_docs/sk-SK/learn-crowdloans.md b/polkadot-wiki/translated_docs/sk-SK/learn-crowdloans.md similarity index 100% rename from website/translated_docs/sk-SK/learn-crowdloans.md rename to polkadot-wiki/translated_docs/sk-SK/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-cryptography.md b/polkadot-wiki/translated_docs/sk-SK/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/sk-SK/learn-faq.md b/polkadot-wiki/translated_docs/sk-SK/learn-faq.md similarity index 100% rename from website/translated_docs/sk-SK/learn-faq.md rename to polkadot-wiki/translated_docs/sk-SK/learn-faq.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-governance.md b/polkadot-wiki/translated_docs/sk-SK/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/sk-SK/learn-identity.md b/polkadot-wiki/translated_docs/sk-SK/learn-identity.md similarity index 100% rename from website/translated_docs/sk-SK/learn-identity.md rename to polkadot-wiki/translated_docs/sk-SK/learn-identity.md diff --git a/website/translated_docs/sk-SK/learn-implementations.md b/polkadot-wiki/translated_docs/sk-SK/learn-implementations.md similarity index 100% rename from website/translated_docs/sk-SK/learn-implementations.md rename to polkadot-wiki/translated_docs/sk-SK/learn-implementations.md diff --git a/website/translated_docs/sk-SK/learn-implementers-guide.md b/polkadot-wiki/translated_docs/sk-SK/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/sk-SK/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/sk-SK/learn-implementers-guide.md diff --git a/website/translated_docs/sk-SK/learn-introduction.md b/polkadot-wiki/translated_docs/sk-SK/learn-introduction.md similarity index 100% rename from website/translated_docs/sk-SK/learn-introduction.md rename to polkadot-wiki/translated_docs/sk-SK/learn-introduction.md diff --git a/website/translated_docs/sk-SK/learn-keys.md b/polkadot-wiki/translated_docs/sk-SK/learn-keys.md similarity index 100% rename from website/translated_docs/sk-SK/learn-keys.md rename to polkadot-wiki/translated_docs/sk-SK/learn-keys.md diff --git a/website/translated_docs/sk-SK/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/sk-SK/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/sk-SK/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/sk-SK/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/sk-SK/learn-launch.md b/polkadot-wiki/translated_docs/sk-SK/learn-launch.md similarity index 100% rename from website/translated_docs/sk-SK/learn-launch.md rename to polkadot-wiki/translated_docs/sk-SK/learn-launch.md diff --git a/website/translated_docs/sk-SK/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/sk-SK/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/sk-SK/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/sk-SK/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-ledger.md b/polkadot-wiki/translated_docs/sk-SK/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/sk-SK/learn-nominator.md b/polkadot-wiki/translated_docs/sk-SK/learn-nominator.md similarity index 100% rename from website/translated_docs/sk-SK/learn-nominator.md rename to polkadot-wiki/translated_docs/sk-SK/learn-nominator.md diff --git a/website/translated_docs/sk-SK/learn-parachains.md b/polkadot-wiki/translated_docs/sk-SK/learn-parachains.md similarity index 100% rename from website/translated_docs/sk-SK/learn-parachains.md rename to polkadot-wiki/translated_docs/sk-SK/learn-parachains.md diff --git a/website/translated_docs/sk-SK/learn-parathreads.md b/polkadot-wiki/translated_docs/sk-SK/learn-parathreads.md similarity index 100% rename from website/translated_docs/sk-SK/learn-parathreads.md rename to polkadot-wiki/translated_docs/sk-SK/learn-parathreads.md diff --git a/website/translated_docs/sk-SK/learn-phragmen.md b/polkadot-wiki/translated_docs/sk-SK/learn-phragmen.md similarity index 100% rename from website/translated_docs/sk-SK/learn-phragmen.md rename to polkadot-wiki/translated_docs/sk-SK/learn-phragmen.md diff --git a/website/translated_docs/sk-SK/learn-polkadot-host.md b/polkadot-wiki/translated_docs/sk-SK/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/sk-SK/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/sk-SK/learn-polkadot-host.md diff --git a/website/translated_docs/sk-SK/learn-proxies.md b/polkadot-wiki/translated_docs/sk-SK/learn-proxies.md similarity index 100% rename from website/translated_docs/sk-SK/learn-proxies.md rename to polkadot-wiki/translated_docs/sk-SK/learn-proxies.md diff --git a/website/translated_docs/sk-SK/learn-randomness.md b/polkadot-wiki/translated_docs/sk-SK/learn-randomness.md similarity index 100% rename from website/translated_docs/sk-SK/learn-randomness.md rename to polkadot-wiki/translated_docs/sk-SK/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-registrar.md b/polkadot-wiki/translated_docs/sk-SK/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/sk-SK/learn-relevant-links.md b/polkadot-wiki/translated_docs/sk-SK/learn-relevant-links.md similarity index 100% rename from website/translated_docs/sk-SK/learn-relevant-links.md rename to polkadot-wiki/translated_docs/sk-SK/learn-relevant-links.md diff --git a/website/translated_docs/sk-SK/learn-roadmap.md b/polkadot-wiki/translated_docs/sk-SK/learn-roadmap.md similarity index 100% rename from website/translated_docs/sk-SK/learn-roadmap.md rename to polkadot-wiki/translated_docs/sk-SK/learn-roadmap.md diff --git a/website/translated_docs/sk-SK/learn-scams.md b/polkadot-wiki/translated_docs/sk-SK/learn-scams.md similarity index 100% rename from website/translated_docs/sk-SK/learn-scams.md rename to polkadot-wiki/translated_docs/sk-SK/learn-scams.md diff --git a/website/translated_docs/sk-SK/learn-security.md b/polkadot-wiki/translated_docs/sk-SK/learn-security.md similarity index 100% rename from website/translated_docs/sk-SK/learn-security.md rename to polkadot-wiki/translated_docs/sk-SK/learn-security.md diff --git a/website/translated_docs/sk-SK/learn-simple-payouts.md b/polkadot-wiki/translated_docs/sk-SK/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/sk-SK/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/sk-SK/learn-simple-payouts.md diff --git a/website/translated_docs/sk-SK/learn-spree.md b/polkadot-wiki/translated_docs/sk-SK/learn-spree.md similarity index 100% rename from website/translated_docs/sk-SK/learn-spree.md rename to polkadot-wiki/translated_docs/sk-SK/learn-spree.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-staking.md b/polkadot-wiki/translated_docs/sk-SK/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/sk-SK/learn-transaction-fees.md b/polkadot-wiki/translated_docs/sk-SK/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/sk-SK/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/sk-SK/learn-transaction-fees.md diff --git a/website/translated_docs/sk-SK/learn-transactions.md b/polkadot-wiki/translated_docs/sk-SK/learn-transactions.md similarity index 100% rename from website/translated_docs/sk-SK/learn-transactions.md rename to polkadot-wiki/translated_docs/sk-SK/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/sk-SK/learn-treasury.md b/polkadot-wiki/translated_docs/sk-SK/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/sk-SK/learn-validator.md b/polkadot-wiki/translated_docs/sk-SK/learn-validator.md similarity index 100% rename from website/translated_docs/sk-SK/learn-validator.md rename to polkadot-wiki/translated_docs/sk-SK/learn-validator.md diff --git a/website/translated_docs/sk-SK/learn-wasm.md b/polkadot-wiki/translated_docs/sk-SK/learn-wasm.md similarity index 100% rename from website/translated_docs/sk-SK/learn-wasm.md rename to polkadot-wiki/translated_docs/sk-SK/learn-wasm.md diff --git a/website/translated_docs/sk-SK/maintain-collator.md b/polkadot-wiki/translated_docs/sk-SK/maintain-collator.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-collator.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-collator.md diff --git a/website/translated_docs/sk-SK/maintain-errors.md b/polkadot-wiki/translated_docs/sk-SK/maintain-errors.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-errors.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-errors.md diff --git a/website/translated_docs/sk-SK/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-democracy.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/sk-SK/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/sk-SK/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/sk-SK/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/sk-SK/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-guides-validator-payout.md diff --git a/website/translated_docs/ru/maintain-index.md b/polkadot-wiki/translated_docs/sk-SK/maintain-index.md similarity index 100% rename from website/translated_docs/ru/maintain-index.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-index.md diff --git a/website/translated_docs/sk-SK/maintain-networks.md b/polkadot-wiki/translated_docs/sk-SK/maintain-networks.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-networks.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-networks.md diff --git a/website/translated_docs/sk-SK/maintain-nominator.md b/polkadot-wiki/translated_docs/sk-SK/maintain-nominator.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-nominator.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/sk-SK/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/sk-SK/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/th-TH/maintain-sync.md b/polkadot-wiki/translated_docs/sk-SK/maintain-sync.md similarity index 100% rename from website/translated_docs/th-TH/maintain-sync.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-sync.md diff --git a/website/translated_docs/sk-SK/maintain-validator.md b/polkadot-wiki/translated_docs/sk-SK/maintain-validator.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-validator.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-validator.md diff --git a/website/translated_docs/sk-SK/maintain-wss.md b/polkadot-wiki/translated_docs/sk-SK/maintain-wss.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-wss.md rename to polkadot-wiki/translated_docs/sk-SK/maintain-wss.md diff --git a/website/translated_docs/sk-SK/news.md b/polkadot-wiki/translated_docs/sk-SK/news.md similarity index 100% rename from website/translated_docs/sk-SK/news.md rename to polkadot-wiki/translated_docs/sk-SK/news.md diff --git a/polkadot-wiki/translated_docs/sk-SK/redenomination.md b/polkadot-wiki/translated_docs/sk-SK/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/sk-SK/research.md b/polkadot-wiki/translated_docs/sk-SK/research.md similarity index 100% rename from website/translated_docs/sk-SK/research.md rename to polkadot-wiki/translated_docs/sk-SK/research.md diff --git a/polkadot-wiki/translated_docs/sk-SK/thousand-validators.md b/polkadot-wiki/translated_docs/sk-SK/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/sk-SK/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/th-TH/ambassadors.md b/polkadot-wiki/translated_docs/th-TH/ambassadors.md similarity index 100% rename from website/translated_docs/th-TH/ambassadors.md rename to polkadot-wiki/translated_docs/th-TH/ambassadors.md diff --git a/website/translated_docs/th-TH/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/th-TH/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/th-TH/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/th-TH/build-build-with-polkadot.md diff --git a/website/translated_docs/th-TH/build-cumulus.md b/polkadot-wiki/translated_docs/th-TH/build-cumulus.md similarity index 100% rename from website/translated_docs/th-TH/build-cumulus.md rename to polkadot-wiki/translated_docs/th-TH/build-cumulus.md diff --git a/website/translated_docs/th-TH/build-deploy-parachains.md b/polkadot-wiki/translated_docs/th-TH/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/th-TH/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/th-TH/build-deploy-parachains.md diff --git a/website/translated_docs/th-TH/build-dev-roadmap.md b/polkadot-wiki/translated_docs/th-TH/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/th-TH/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/th-TH/build-dev-roadmap.md diff --git a/website/translated_docs/th-TH/build-examples-index.md b/polkadot-wiki/translated_docs/th-TH/build-examples-index.md similarity index 100% rename from website/translated_docs/th-TH/build-examples-index.md rename to polkadot-wiki/translated_docs/th-TH/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/th-TH/build-exchange-integration.md b/polkadot-wiki/translated_docs/th-TH/build-exchange-integration.md new file mode 100644 index 000000000000..dddd3a779fac --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. Tracking the chain head + +Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). + +That will give you a stream of hashes of the most recent finalised headers. + +When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. + +If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. + +## 2. Decoding blocks + +You will need to decode blocks from the basic data into useful fields. + +All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. + +For Genesis Polkadot, the header format is a five-field structure: + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +It also relies on `Extrinsic`. An _extrinsic_ is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. + +The metadata itself is provided encoded in SCALE. Its format is: + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. + +Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various _modules_. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, _extrinsics_), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. Working with SS58 and account addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) _AccountId_. This is simply the public key for the x25519 cryptography used by Substrate. + +However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this _index_ to identify the account. This index is much smaller than the 32-byte _AccountId_, and can usually be encoded in just a couple of bytes. + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: + +`0x00 ` + +**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. + +Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. + +Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. + +### Looking up an index + +Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. + +The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. + +For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. + +This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. + +This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. + +Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. + +## 4. Working with balances + +In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. + +NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. + +The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10\*\*12). For completeness, The exact denominations of the Polkadot currency are: + +| Balance value | Name | +| ------------- | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### Transferring balances + +To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. + +In general, Polkadot's transactions are encoded as _signed_ `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. + +The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. + +NOTE: The nonce retrieved from storage does not take into account _pending_ transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. + +The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. + +The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. + +Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. + +Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +The `function` _in this case_ (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. + +The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. + +### Submitting and checking transactions + +Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. + +This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. + +The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. + +## Conclusion + +This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. + +If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). + +_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/polkadot-wiki/translated_docs/th-TH/build-extrinsic-format.md b/polkadot-wiki/translated_docs/th-TH/build-extrinsic-format.md new file mode 100644 index 000000000000..39a48b855d09 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/build-extrinsic-format.md @@ -0,0 +1,44 @@ +--- +id: build-extrinsic-format +title: Polkadot Extrinsic Format aka Transaction Format +sidebar_label: Polkadot Extrinsic Format aka Transaction Format +--- + +## Old Format + +For reference, the **old** extrinsic format was: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] +``` + +## Current Format + +The Polkadot extrinsic format is: + +``` +[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] +``` + +The _original_ fields refer to the following from the old extrinsic format: + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] +``` + +The specific format for the new address type is one of 5 sub-formats, switched on the first byte: + +- `0xff, 32-byte account id` +- `0xfe, 8-byte account index` +- `0xfd, 4-byte account index` +- `0xfc, 2-byte account index` +- `[0xf0...0xfb] (invalid, reserved for future use)` +- `[0x00...0xef] 1-byte account index (less than 0xf0)` + +The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. + +In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). + +## Source + +[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/th-TH/build-hackathon.md b/polkadot-wiki/translated_docs/th-TH/build-hackathon.md similarity index 100% rename from website/translated_docs/th-TH/build-hackathon.md rename to polkadot-wiki/translated_docs/th-TH/build-hackathon.md diff --git a/website/translated_docs/th-TH/build-index.md b/polkadot-wiki/translated_docs/th-TH/build-index.md similarity index 100% rename from website/translated_docs/th-TH/build-index.md rename to polkadot-wiki/translated_docs/th-TH/build-index.md diff --git a/website/translated_docs/th-TH/build-integration.md b/polkadot-wiki/translated_docs/th-TH/build-integration.md similarity index 100% rename from website/translated_docs/th-TH/build-integration.md rename to polkadot-wiki/translated_docs/th-TH/build-integration.md diff --git a/website/translated_docs/th-TH/build-networks.md b/polkadot-wiki/translated_docs/th-TH/build-networks.md similarity index 100% rename from website/translated_docs/th-TH/build-networks.md rename to polkadot-wiki/translated_docs/th-TH/build-networks.md diff --git a/website/translated_docs/th-TH/build-node-interaction.md b/polkadot-wiki/translated_docs/th-TH/build-node-interaction.md similarity index 100% rename from website/translated_docs/th-TH/build-node-interaction.md rename to polkadot-wiki/translated_docs/th-TH/build-node-interaction.md diff --git a/website/translated_docs/th-TH/build-node-management.md b/polkadot-wiki/translated_docs/th-TH/build-node-management.md similarity index 100% rename from website/translated_docs/th-TH/build-node-management.md rename to polkadot-wiki/translated_docs/th-TH/build-node-management.md diff --git a/website/translated_docs/th-TH/build-oracle.md b/polkadot-wiki/translated_docs/th-TH/build-oracle.md similarity index 100% rename from website/translated_docs/th-TH/build-oracle.md rename to polkadot-wiki/translated_docs/th-TH/build-oracle.md diff --git a/website/translated_docs/th-TH/build-parachains-rococo.md b/polkadot-wiki/translated_docs/th-TH/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/th-TH/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/th-TH/build-parachains-rococo.md diff --git a/website/translated_docs/th-TH/build-pdk.md b/polkadot-wiki/translated_docs/th-TH/build-pdk.md similarity index 100% rename from website/translated_docs/th-TH/build-pdk.md rename to polkadot-wiki/translated_docs/th-TH/build-pdk.md diff --git a/polkadot-wiki/translated_docs/th-TH/build-protocol-info.md b/polkadot-wiki/translated_docs/th-TH/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/polkadot-wiki/translated_docs/th-TH/build-rust-style-guide.md b/polkadot-wiki/translated_docs/th-TH/build-rust-style-guide.md new file mode 100644 index 000000000000..678bb58481ae --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/build-rust-style-guide.md @@ -0,0 +1,117 @@ +--- +id: build-rust-style-guide +title: Style Guide for Rust in Polkadot +sidebar_label: Style Guide for Rust in Polkadot +--- + +- Indent using tabs +- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. +- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. +- Never have spaces on a line prior to a non-whitespace character +- Follow-on lines are only ever a single indent from the original line. + +```rust +fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { + let x = some_long_variable_a * some_long_variable_b + - some_long_variable_b / some_long_variable_a + + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); + x > 10 +} +``` + +- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: + +```rust +fn calculate( + some_long_variable_a: f32, + some_long_variable_b: f32, + some_long_variable_c: f32, +) -> f32 { + (-some_long_variable_b + sqrt( + // two parens open, but since we open & close them both on the + // same line, only one indent level is used + some_long_variable_b * some_long_variable_b + - 4 * some_long_variable_a * some_long_variable_c + // both closed here at beginning of line, so back to the original indent + // level + )) / (2 * some_long_variable_a) +} +``` + +- `where` is indented, and its items are indented one further +- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. + +```rust +// OK +fn foo( + really_long_parameter_name_1: SomeLongTypeName, + really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, + shrt_nm_2: u8, +) { + ... +} + +// NOT OK +fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, shrt_nm_2: u8) { + ... +} + +``` + +```rust +{ + // Complex line (not just a function call, also a let statement). Full + // structure. + let (a, b) = bar( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Long, simple function call. + waz( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // Short function call. Inline. + baz(a, b); +} +``` + +- Always end last item of a multi-line comma-delimited set with `,` when legal: + +```rust +struct Point { + x: T, + y: T, // <-- Multiline comma-delimited lists end with a trailing , +} + +// Single line comma-delimited items do not have a trailing `,` +enum Meal { Breakfast, Lunch, Dinner }; +``` + +- Avoid trailing `;`s where unneeded. + +```rust +if condition { + return 1 // <-- no ; here +} +``` + +- `match` arms may be either blocks or have a trailing `,` but not both. +- Blocks should not be used unnecessarily. + +```rust +match meal { + Meal::Breakfast => "eggs", + Meal::Lunch => { check_diet(); recipe() }, +// Meal::Dinner => { return Err("Fasting") } // WRONG + Meal::Dinner => return Err("Fasting"), +} +``` diff --git a/website/translated_docs/th-TH/build-smart-contracts.md b/polkadot-wiki/translated_docs/th-TH/build-smart-contracts.md similarity index 100% rename from website/translated_docs/th-TH/build-smart-contracts.md rename to polkadot-wiki/translated_docs/th-TH/build-smart-contracts.md diff --git a/website/translated_docs/th-TH/build-tools-index.md b/polkadot-wiki/translated_docs/th-TH/build-tools-index.md similarity index 100% rename from website/translated_docs/th-TH/build-tools-index.md rename to polkadot-wiki/translated_docs/th-TH/build-tools-index.md diff --git a/website/translated_docs/th-TH/build-tools-subkey.md b/polkadot-wiki/translated_docs/th-TH/build-tools-subkey.md similarity index 100% rename from website/translated_docs/th-TH/build-tools-subkey.md rename to polkadot-wiki/translated_docs/th-TH/build-tools-subkey.md diff --git a/polkadot-wiki/translated_docs/th-TH/build-transaction-construction.md b/polkadot-wiki/translated_docs/th-TH/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/th-TH/build-wallets.md b/polkadot-wiki/translated_docs/th-TH/build-wallets.md similarity index 100% rename from website/translated_docs/th-TH/build-wallets.md rename to polkadot-wiki/translated_docs/th-TH/build-wallets.md diff --git a/polkadot-wiki/translated_docs/th-TH/claims.md b/polkadot-wiki/translated_docs/th-TH/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/th-TH/community.md b/polkadot-wiki/translated_docs/th-TH/community.md similarity index 100% rename from website/translated_docs/th-TH/community.md rename to polkadot-wiki/translated_docs/th-TH/community.md diff --git a/website/translated_docs/th-TH/contributing.md b/polkadot-wiki/translated_docs/th-TH/contributing.md similarity index 100% rename from website/translated_docs/th-TH/contributing.md rename to polkadot-wiki/translated_docs/th-TH/contributing.md diff --git a/website/translated_docs/th-TH/contributors.md b/polkadot-wiki/translated_docs/th-TH/contributors.md similarity index 100% rename from website/translated_docs/th-TH/contributors.md rename to polkadot-wiki/translated_docs/th-TH/contributors.md diff --git a/website/translated_docs/th-TH/ens.md b/polkadot-wiki/translated_docs/th-TH/ens.md similarity index 100% rename from website/translated_docs/th-TH/ens.md rename to polkadot-wiki/translated_docs/th-TH/ens.md diff --git a/website/translated_docs/th-TH/faq.md b/polkadot-wiki/translated_docs/th-TH/faq.md similarity index 100% rename from website/translated_docs/th-TH/faq.md rename to polkadot-wiki/translated_docs/th-TH/faq.md diff --git a/polkadot-wiki/translated_docs/th-TH/getting-started.md b/polkadot-wiki/translated_docs/th-TH/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/th-TH/glossary.md b/polkadot-wiki/translated_docs/th-TH/glossary.md similarity index 100% rename from website/translated_docs/th-TH/glossary.md rename to polkadot-wiki/translated_docs/th-TH/glossary.md diff --git a/polkadot-wiki/translated_docs/th-TH/grants.md b/polkadot-wiki/translated_docs/th-TH/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/th-TH/index.md b/polkadot-wiki/translated_docs/th-TH/index.md similarity index 100% rename from website/translated_docs/th-TH/index.md rename to polkadot-wiki/translated_docs/th-TH/index.md diff --git a/polkadot-wiki/translated_docs/th-TH/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/th-TH/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/th-TH/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/th-TH/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/th-TH/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/th-TH/kusama-bug-bounty.md diff --git a/website/translated_docs/th-TH/kusama-claims.md b/polkadot-wiki/translated_docs/th-TH/kusama-claims.md similarity index 100% rename from website/translated_docs/th-TH/kusama-claims.md rename to polkadot-wiki/translated_docs/th-TH/kusama-claims.md diff --git a/website/translated_docs/th-TH/kusama-coc.md b/polkadot-wiki/translated_docs/th-TH/kusama-coc.md similarity index 100% rename from website/translated_docs/th-TH/kusama-coc.md rename to polkadot-wiki/translated_docs/th-TH/kusama-coc.md diff --git a/website/translated_docs/th-TH/kusama-community.md b/polkadot-wiki/translated_docs/th-TH/kusama-community.md similarity index 100% rename from website/translated_docs/th-TH/kusama-community.md rename to polkadot-wiki/translated_docs/th-TH/kusama-community.md diff --git a/website/translated_docs/th-TH/kusama-endpoints.md b/polkadot-wiki/translated_docs/th-TH/kusama-endpoints.md similarity index 100% rename from website/translated_docs/th-TH/kusama-endpoints.md rename to polkadot-wiki/translated_docs/th-TH/kusama-endpoints.md diff --git a/website/translated_docs/th-TH/kusama-faucet.md b/polkadot-wiki/translated_docs/th-TH/kusama-faucet.md similarity index 100% rename from website/translated_docs/th-TH/kusama-faucet.md rename to polkadot-wiki/translated_docs/th-TH/kusama-faucet.md diff --git a/website/translated_docs/th-TH/kusama-getting-started.md b/polkadot-wiki/translated_docs/th-TH/kusama-getting-started.md similarity index 100% rename from website/translated_docs/th-TH/kusama-getting-started.md rename to polkadot-wiki/translated_docs/th-TH/kusama-getting-started.md diff --git a/website/translated_docs/th-TH/kusama-index.md b/polkadot-wiki/translated_docs/th-TH/kusama-index.md similarity index 100% rename from website/translated_docs/th-TH/kusama-index.md rename to polkadot-wiki/translated_docs/th-TH/kusama-index.md diff --git a/polkadot-wiki/translated_docs/th-TH/kusama-ledger.md b/polkadot-wiki/translated_docs/th-TH/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/th-TH/kusama-parameters.md b/polkadot-wiki/translated_docs/th-TH/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/th-TH/kusama-social-recovery.md b/polkadot-wiki/translated_docs/th-TH/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/th-TH/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/th-TH/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/th-TH/kusama-time-periods.md b/polkadot-wiki/translated_docs/th-TH/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/th-TH/kusama-timeline.md b/polkadot-wiki/translated_docs/th-TH/kusama-timeline.md similarity index 100% rename from website/translated_docs/th-TH/kusama-timeline.md rename to polkadot-wiki/translated_docs/th-TH/kusama-timeline.md diff --git a/website/translated_docs/th-TH/learn-DOT.md b/polkadot-wiki/translated_docs/th-TH/learn-DOT.md similarity index 100% rename from website/translated_docs/th-TH/learn-DOT.md rename to polkadot-wiki/translated_docs/th-TH/learn-DOT.md diff --git a/website/translated_docs/th-TH/learn-PRE.md b/polkadot-wiki/translated_docs/th-TH/learn-PRE.md similarity index 100% rename from website/translated_docs/th-TH/learn-PRE.md rename to polkadot-wiki/translated_docs/th-TH/learn-PRE.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-UI.md b/polkadot-wiki/translated_docs/th-TH/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/th-TH/learn-account-generation.md b/polkadot-wiki/translated_docs/th-TH/learn-account-generation.md similarity index 100% rename from website/translated_docs/th-TH/learn-account-generation.md rename to polkadot-wiki/translated_docs/th-TH/learn-account-generation.md diff --git a/website/translated_docs/th-TH/learn-account-restore.md b/polkadot-wiki/translated_docs/th-TH/learn-account-restore.md similarity index 100% rename from website/translated_docs/th-TH/learn-account-restore.md rename to polkadot-wiki/translated_docs/th-TH/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-accounts.md b/polkadot-wiki/translated_docs/th-TH/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/th-TH/learn-architecture.md b/polkadot-wiki/translated_docs/th-TH/learn-architecture.md similarity index 100% rename from website/translated_docs/th-TH/learn-architecture.md rename to polkadot-wiki/translated_docs/th-TH/learn-architecture.md diff --git a/website/translated_docs/th-TH/learn-auction.md b/polkadot-wiki/translated_docs/th-TH/learn-auction.md similarity index 100% rename from website/translated_docs/th-TH/learn-auction.md rename to polkadot-wiki/translated_docs/th-TH/learn-auction.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-availability.md b/polkadot-wiki/translated_docs/th-TH/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/th-TH/learn-balance-transfers.md b/polkadot-wiki/translated_docs/th-TH/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/th-TH/learn-bridges.md b/polkadot-wiki/translated_docs/th-TH/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/th-TH/learn-collator.md b/polkadot-wiki/translated_docs/th-TH/learn-collator.md similarity index 100% rename from website/translated_docs/th-TH/learn-collator.md rename to polkadot-wiki/translated_docs/th-TH/learn-collator.md diff --git a/website/translated_docs/th-TH/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/th-TH/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/th-TH/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/th-TH/learn-comparison-dfinity.md diff --git a/website/translated_docs/th-TH/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/th-TH/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/th-TH/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/th-TH/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/th-TH/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/th-TH/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/th-TH/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/th-TH/learn-comparisons-cosmos.md diff --git a/website/translated_docs/th-TH/learn-comparisons.md b/polkadot-wiki/translated_docs/th-TH/learn-comparisons.md similarity index 100% rename from website/translated_docs/th-TH/learn-comparisons.md rename to polkadot-wiki/translated_docs/th-TH/learn-comparisons.md diff --git a/website/translated_docs/th-TH/learn-consensus.md b/polkadot-wiki/translated_docs/th-TH/learn-consensus.md similarity index 100% rename from website/translated_docs/th-TH/learn-consensus.md rename to polkadot-wiki/translated_docs/th-TH/learn-consensus.md diff --git a/website/translated_docs/th-TH/learn-crosschain.md b/polkadot-wiki/translated_docs/th-TH/learn-crosschain.md similarity index 100% rename from website/translated_docs/th-TH/learn-crosschain.md rename to polkadot-wiki/translated_docs/th-TH/learn-crosschain.md diff --git a/website/translated_docs/th-TH/learn-crowdloans.md b/polkadot-wiki/translated_docs/th-TH/learn-crowdloans.md similarity index 100% rename from website/translated_docs/th-TH/learn-crowdloans.md rename to polkadot-wiki/translated_docs/th-TH/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-cryptography.md b/polkadot-wiki/translated_docs/th-TH/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/th-TH/learn-faq.md b/polkadot-wiki/translated_docs/th-TH/learn-faq.md similarity index 100% rename from website/translated_docs/th-TH/learn-faq.md rename to polkadot-wiki/translated_docs/th-TH/learn-faq.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-governance.md b/polkadot-wiki/translated_docs/th-TH/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/th-TH/learn-identity.md b/polkadot-wiki/translated_docs/th-TH/learn-identity.md similarity index 100% rename from website/translated_docs/th-TH/learn-identity.md rename to polkadot-wiki/translated_docs/th-TH/learn-identity.md diff --git a/website/translated_docs/th-TH/learn-implementations.md b/polkadot-wiki/translated_docs/th-TH/learn-implementations.md similarity index 100% rename from website/translated_docs/th-TH/learn-implementations.md rename to polkadot-wiki/translated_docs/th-TH/learn-implementations.md diff --git a/website/translated_docs/th-TH/learn-implementers-guide.md b/polkadot-wiki/translated_docs/th-TH/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/th-TH/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/th-TH/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-interchain.md b/polkadot-wiki/translated_docs/th-TH/learn-interchain.md new file mode 100644 index 000000000000..2677ee91d812 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. + +The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. + +## Overview + +- Interchain messages will _not_ go on to the relay chain. +- Interchain messages will be constrained to a maximum size in bytes. +- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. +- Collator nodes are responsible for routing messages between chains. +- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. +- On each block, parachains are expected to route messages from some subset of all other parachains. +- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. +- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. + +## Example + +A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. + +Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. + +The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. + +The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. + +Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. + +When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. + +During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. + +The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. + +## Resources + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/th-TH/learn-introduction.md b/polkadot-wiki/translated_docs/th-TH/learn-introduction.md similarity index 100% rename from website/translated_docs/th-TH/learn-introduction.md rename to polkadot-wiki/translated_docs/th-TH/learn-introduction.md diff --git a/website/translated_docs/th-TH/learn-keys.md b/polkadot-wiki/translated_docs/th-TH/learn-keys.md similarity index 100% rename from website/translated_docs/th-TH/learn-keys.md rename to polkadot-wiki/translated_docs/th-TH/learn-keys.md diff --git a/website/translated_docs/th-TH/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/th-TH/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/th-TH/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/th-TH/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/th-TH/learn-launch.md b/polkadot-wiki/translated_docs/th-TH/learn-launch.md similarity index 100% rename from website/translated_docs/th-TH/learn-launch.md rename to polkadot-wiki/translated_docs/th-TH/learn-launch.md diff --git a/website/translated_docs/th-TH/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/th-TH/learn-lazy-payouts.md similarity index 100% rename from website/translated_docs/th-TH/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/th-TH/learn-lazy-payouts.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-ledger.md b/polkadot-wiki/translated_docs/th-TH/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/th-TH/learn-nominator.md b/polkadot-wiki/translated_docs/th-TH/learn-nominator.md similarity index 100% rename from website/translated_docs/th-TH/learn-nominator.md rename to polkadot-wiki/translated_docs/th-TH/learn-nominator.md diff --git a/website/translated_docs/th-TH/learn-parachains.md b/polkadot-wiki/translated_docs/th-TH/learn-parachains.md similarity index 100% rename from website/translated_docs/th-TH/learn-parachains.md rename to polkadot-wiki/translated_docs/th-TH/learn-parachains.md diff --git a/website/translated_docs/th-TH/learn-parathreads.md b/polkadot-wiki/translated_docs/th-TH/learn-parathreads.md similarity index 100% rename from website/translated_docs/th-TH/learn-parathreads.md rename to polkadot-wiki/translated_docs/th-TH/learn-parathreads.md diff --git a/website/translated_docs/th-TH/learn-phragmen.md b/polkadot-wiki/translated_docs/th-TH/learn-phragmen.md similarity index 100% rename from website/translated_docs/th-TH/learn-phragmen.md rename to polkadot-wiki/translated_docs/th-TH/learn-phragmen.md diff --git a/website/translated_docs/th-TH/learn-polkadot-host.md b/polkadot-wiki/translated_docs/th-TH/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/th-TH/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/th-TH/learn-polkadot-host.md diff --git a/website/translated_docs/th-TH/learn-proxies.md b/polkadot-wiki/translated_docs/th-TH/learn-proxies.md similarity index 100% rename from website/translated_docs/th-TH/learn-proxies.md rename to polkadot-wiki/translated_docs/th-TH/learn-proxies.md diff --git a/website/translated_docs/th-TH/learn-randomness.md b/polkadot-wiki/translated_docs/th-TH/learn-randomness.md similarity index 100% rename from website/translated_docs/th-TH/learn-randomness.md rename to polkadot-wiki/translated_docs/th-TH/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-registrar.md b/polkadot-wiki/translated_docs/th-TH/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/th-TH/learn-relevant-links.md b/polkadot-wiki/translated_docs/th-TH/learn-relevant-links.md similarity index 100% rename from website/translated_docs/th-TH/learn-relevant-links.md rename to polkadot-wiki/translated_docs/th-TH/learn-relevant-links.md diff --git a/website/translated_docs/th-TH/learn-roadmap.md b/polkadot-wiki/translated_docs/th-TH/learn-roadmap.md similarity index 100% rename from website/translated_docs/th-TH/learn-roadmap.md rename to polkadot-wiki/translated_docs/th-TH/learn-roadmap.md diff --git a/website/translated_docs/th-TH/learn-scams.md b/polkadot-wiki/translated_docs/th-TH/learn-scams.md similarity index 100% rename from website/translated_docs/th-TH/learn-scams.md rename to polkadot-wiki/translated_docs/th-TH/learn-scams.md diff --git a/website/translated_docs/th-TH/learn-security.md b/polkadot-wiki/translated_docs/th-TH/learn-security.md similarity index 100% rename from website/translated_docs/th-TH/learn-security.md rename to polkadot-wiki/translated_docs/th-TH/learn-security.md diff --git a/website/translated_docs/th-TH/learn-simple-payouts.md b/polkadot-wiki/translated_docs/th-TH/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/th-TH/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/th-TH/learn-simple-payouts.md diff --git a/website/translated_docs/th-TH/learn-spree.md b/polkadot-wiki/translated_docs/th-TH/learn-spree.md similarity index 100% rename from website/translated_docs/th-TH/learn-spree.md rename to polkadot-wiki/translated_docs/th-TH/learn-spree.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-staking.md b/polkadot-wiki/translated_docs/th-TH/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/th-TH/learn-transaction-fees.md b/polkadot-wiki/translated_docs/th-TH/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/th-TH/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/th-TH/learn-transaction-fees.md diff --git a/website/translated_docs/th-TH/learn-transactions.md b/polkadot-wiki/translated_docs/th-TH/learn-transactions.md similarity index 100% rename from website/translated_docs/th-TH/learn-transactions.md rename to polkadot-wiki/translated_docs/th-TH/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/th-TH/learn-treasury.md b/polkadot-wiki/translated_docs/th-TH/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/th-TH/learn-validator.md b/polkadot-wiki/translated_docs/th-TH/learn-validator.md similarity index 100% rename from website/translated_docs/th-TH/learn-validator.md rename to polkadot-wiki/translated_docs/th-TH/learn-validator.md diff --git a/website/translated_docs/th-TH/learn-wasm.md b/polkadot-wiki/translated_docs/th-TH/learn-wasm.md similarity index 100% rename from website/translated_docs/th-TH/learn-wasm.md rename to polkadot-wiki/translated_docs/th-TH/learn-wasm.md diff --git a/website/translated_docs/th-TH/maintain-collator.md b/polkadot-wiki/translated_docs/th-TH/maintain-collator.md similarity index 100% rename from website/translated_docs/th-TH/maintain-collator.md rename to polkadot-wiki/translated_docs/th-TH/maintain-collator.md diff --git a/website/translated_docs/th-TH/maintain-errors.md b/polkadot-wiki/translated_docs/th-TH/maintain-errors.md similarity index 100% rename from website/translated_docs/th-TH/maintain-errors.md rename to polkadot-wiki/translated_docs/th-TH/maintain-errors.md diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-governance-index.md b/polkadot-wiki/translated_docs/th-TH/maintain-governance-index.md new file mode 100644 index 000000000000..8812e030de6c --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-governance-index.md @@ -0,0 +1,185 @@ +--- +id: maintain-governance-index +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. + +All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. + +The following steps are the governance procedure in the Polkadot network: + +- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) +- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) +- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) + +To better understand how the council is formed, please read [this section](#council). + +### Proposing Referenda + +- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. + +- **[Council](#council)**: + + Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. + + Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) + +### Voting for a proposal + +To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). + +``` +Example: + +Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes +``` + +According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. + +### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +voters - the total number of voting tokens + +electorate - the total number of DOTs tokens issued in the network +``` + +**Super-Majority Approve** + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ + +**Super-Majority Against** + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ + +**Simple-Majority** + +Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ + +_To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume we only have 1,500 DOTs tokens in total. + +John - 500 DOTs +Peter - 100 DOTs +Lilly - 150 DOTs +JJ - 150 DOTs +Ken - 600 DOTs + +John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +voters = 1050 +electorate = 1500 +``` + +$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ + +$${13.887} < {15.492}$$ + +Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. + +## Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: + +``` +Max votes = tokens * periods +``` + +Based on the current testnet setting, the maximum number of lock periods is set to 6. + +**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** + +## Adaptive Quorum Biasing + +Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. + +Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. + +Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. + +In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +## Council + +Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. + +To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. + +Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. + +Let's take a look at the example below. + +||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. + +### Resources + +- [Governance Description](learn-governance#referenda) +- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) + +## [Usage of DOT](learn-DOT#dots-for-governance) + +## Guides + +### [How to create a proposal]() + +### [How to join the council]() + +### [How to propose a referenda]() diff --git a/website/translated_docs/th-TH/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-democracy.md diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..8136931b0fb5 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: การเป็นผู้เสนอชื่อ (Nominator) บนเครือข่าย Alexander +sidebar_label: การเป็นผู้เสนอชื่อ (Nominator) บนเครือข่าย Alexander +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate-polkadot.md diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate.md new file mode 100644 index 000000000000..20b9f634ea64 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-nominate.md @@ -0,0 +1,59 @@ +--- +id: maintain-guides-how-to-nominate +title: How to nominate +sidebar_label: How to nominate +--- + +This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. + +It has been updated for the Alexander testnet and Polkadot release PoC-4. + +## Create `stash` and `controller` accounts + +We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. + +The first step is to create two accounts by going to the _Accounts_ tab on the Polkadot Dashboard and clicking on [_Add account_](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. + +![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) + +Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. + +## Nominating + +It is now time to setup our nominator. We will do the following: + +- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. +- Select the `controller`. This is the account that will decide when to start or stop nominating. + +First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. + +![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. +- **Controller account** - select the `controller` account created earlier. +- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). +- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). + +Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. + +![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) + +## Nominating a validator + +Go to the _Staking Overview_ tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. + +![Validators](assets/guides/how-to-nominate/validators.png) + +Go back to the _Account Actions_ tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). + +![Nominating](assets/guides/how-to-nominate/nominating.jpg) + +**Congratulations!** You are now a nominator. + +If you return to the _Staking Overview_ tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. + +![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) + +## How to stop nominating + +To stop nominating simply return to the _Account Actions_ tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/th-TH/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/th-TH/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/th-TH/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/th-TH/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/th-TH/maintain-guides-validator-payout.md diff --git a/website/translated_docs/sk-SK/maintain-index.md b/polkadot-wiki/translated_docs/th-TH/maintain-index.md similarity index 100% rename from website/translated_docs/sk-SK/maintain-index.md rename to polkadot-wiki/translated_docs/th-TH/maintain-index.md diff --git a/website/translated_docs/th-TH/maintain-networks.md b/polkadot-wiki/translated_docs/th-TH/maintain-networks.md similarity index 100% rename from website/translated_docs/th-TH/maintain-networks.md rename to polkadot-wiki/translated_docs/th-TH/maintain-networks.md diff --git a/website/translated_docs/th-TH/maintain-node-operator.md b/polkadot-wiki/translated_docs/th-TH/maintain-node-operator.md similarity index 100% rename from website/translated_docs/th-TH/maintain-node-operator.md rename to polkadot-wiki/translated_docs/th-TH/maintain-node-operator.md diff --git a/website/translated_docs/th-TH/maintain-nominator.md b/polkadot-wiki/translated_docs/th-TH/maintain-nominator.md similarity index 100% rename from website/translated_docs/th-TH/maintain-nominator.md rename to polkadot-wiki/translated_docs/th-TH/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/th-TH/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/th-TH/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/tr/maintain-sync.md b/polkadot-wiki/translated_docs/th-TH/maintain-sync.md similarity index 100% rename from website/translated_docs/tr/maintain-sync.md rename to polkadot-wiki/translated_docs/th-TH/maintain-sync.md diff --git a/website/translated_docs/th-TH/maintain-validator.md b/polkadot-wiki/translated_docs/th-TH/maintain-validator.md similarity index 100% rename from website/translated_docs/th-TH/maintain-validator.md rename to polkadot-wiki/translated_docs/th-TH/maintain-validator.md diff --git a/website/translated_docs/th-TH/maintain-wss.md b/polkadot-wiki/translated_docs/th-TH/maintain-wss.md similarity index 100% rename from website/translated_docs/th-TH/maintain-wss.md rename to polkadot-wiki/translated_docs/th-TH/maintain-wss.md diff --git a/website/translated_docs/th-TH/news.md b/polkadot-wiki/translated_docs/th-TH/news.md similarity index 100% rename from website/translated_docs/th-TH/news.md rename to polkadot-wiki/translated_docs/th-TH/news.md diff --git a/polkadot-wiki/translated_docs/th-TH/redenomination.md b/polkadot-wiki/translated_docs/th-TH/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/th-TH/research.md b/polkadot-wiki/translated_docs/th-TH/research.md similarity index 100% rename from website/translated_docs/th-TH/research.md rename to polkadot-wiki/translated_docs/th-TH/research.md diff --git a/polkadot-wiki/translated_docs/th-TH/thousand-validators.md b/polkadot-wiki/translated_docs/th-TH/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/th-TH/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/tr/ambassadors.md b/polkadot-wiki/translated_docs/tr/ambassadors.md similarity index 100% rename from website/translated_docs/tr/ambassadors.md rename to polkadot-wiki/translated_docs/tr/ambassadors.md diff --git a/website/translated_docs/tr/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/tr/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/tr/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/tr/build-build-with-polkadot.md diff --git a/website/translated_docs/tr/build-cumulus.md b/polkadot-wiki/translated_docs/tr/build-cumulus.md similarity index 100% rename from website/translated_docs/tr/build-cumulus.md rename to polkadot-wiki/translated_docs/tr/build-cumulus.md diff --git a/website/translated_docs/tr/build-deploy-parachains.md b/polkadot-wiki/translated_docs/tr/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/tr/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/tr/build-deploy-parachains.md diff --git a/website/translated_docs/tr/build-examples-index.md b/polkadot-wiki/translated_docs/tr/build-examples-index.md similarity index 100% rename from website/translated_docs/tr/build-examples-index.md rename to polkadot-wiki/translated_docs/tr/build-examples-index.md diff --git a/website/translated_docs/tr/build-hackathon.md b/polkadot-wiki/translated_docs/tr/build-hackathon.md similarity index 100% rename from website/translated_docs/tr/build-hackathon.md rename to polkadot-wiki/translated_docs/tr/build-hackathon.md diff --git a/website/translated_docs/tr/build-index.md b/polkadot-wiki/translated_docs/tr/build-index.md similarity index 100% rename from website/translated_docs/tr/build-index.md rename to polkadot-wiki/translated_docs/tr/build-index.md diff --git a/website/translated_docs/tr/build-integration.md b/polkadot-wiki/translated_docs/tr/build-integration.md similarity index 100% rename from website/translated_docs/tr/build-integration.md rename to polkadot-wiki/translated_docs/tr/build-integration.md diff --git a/website/translated_docs/tr/build-node-interaction.md b/polkadot-wiki/translated_docs/tr/build-node-interaction.md similarity index 100% rename from website/translated_docs/tr/build-node-interaction.md rename to polkadot-wiki/translated_docs/tr/build-node-interaction.md diff --git a/website/translated_docs/tr/build-node-management.md b/polkadot-wiki/translated_docs/tr/build-node-management.md similarity index 100% rename from website/translated_docs/tr/build-node-management.md rename to polkadot-wiki/translated_docs/tr/build-node-management.md diff --git a/website/translated_docs/tr/build-oracle.md b/polkadot-wiki/translated_docs/tr/build-oracle.md similarity index 100% rename from website/translated_docs/tr/build-oracle.md rename to polkadot-wiki/translated_docs/tr/build-oracle.md diff --git a/website/translated_docs/tr/build-parachains-rococo.md b/polkadot-wiki/translated_docs/tr/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/tr/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/tr/build-parachains-rococo.md diff --git a/website/translated_docs/tr/build-pdk.md b/polkadot-wiki/translated_docs/tr/build-pdk.md similarity index 100% rename from website/translated_docs/tr/build-pdk.md rename to polkadot-wiki/translated_docs/tr/build-pdk.md diff --git a/polkadot-wiki/translated_docs/tr/build-protocol-info.md b/polkadot-wiki/translated_docs/tr/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/tr/build-smart-contracts.md b/polkadot-wiki/translated_docs/tr/build-smart-contracts.md similarity index 100% rename from website/translated_docs/tr/build-smart-contracts.md rename to polkadot-wiki/translated_docs/tr/build-smart-contracts.md diff --git a/website/translated_docs/tr/build-tools-index.md b/polkadot-wiki/translated_docs/tr/build-tools-index.md similarity index 100% rename from website/translated_docs/tr/build-tools-index.md rename to polkadot-wiki/translated_docs/tr/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/tr/build-transaction-construction.md b/polkadot-wiki/translated_docs/tr/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/tr/build-wallets.md b/polkadot-wiki/translated_docs/tr/build-wallets.md similarity index 100% rename from website/translated_docs/tr/build-wallets.md rename to polkadot-wiki/translated_docs/tr/build-wallets.md diff --git a/polkadot-wiki/translated_docs/tr/claims.md b/polkadot-wiki/translated_docs/tr/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/tr/community.md b/polkadot-wiki/translated_docs/tr/community.md similarity index 100% rename from website/translated_docs/tr/community.md rename to polkadot-wiki/translated_docs/tr/community.md diff --git a/website/translated_docs/tr/contributing.md b/polkadot-wiki/translated_docs/tr/contributing.md similarity index 100% rename from website/translated_docs/tr/contributing.md rename to polkadot-wiki/translated_docs/tr/contributing.md diff --git a/website/translated_docs/tr/contributors.md b/polkadot-wiki/translated_docs/tr/contributors.md similarity index 100% rename from website/translated_docs/tr/contributors.md rename to polkadot-wiki/translated_docs/tr/contributors.md diff --git a/website/translated_docs/tr/ens.md b/polkadot-wiki/translated_docs/tr/ens.md similarity index 100% rename from website/translated_docs/tr/ens.md rename to polkadot-wiki/translated_docs/tr/ens.md diff --git a/website/translated_docs/tr/faq.md b/polkadot-wiki/translated_docs/tr/faq.md similarity index 100% rename from website/translated_docs/tr/faq.md rename to polkadot-wiki/translated_docs/tr/faq.md diff --git a/polkadot-wiki/translated_docs/tr/getting-started.md b/polkadot-wiki/translated_docs/tr/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/tr/glossary.md b/polkadot-wiki/translated_docs/tr/glossary.md similarity index 100% rename from website/translated_docs/tr/glossary.md rename to polkadot-wiki/translated_docs/tr/glossary.md diff --git a/polkadot-wiki/translated_docs/tr/grants.md b/polkadot-wiki/translated_docs/tr/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/tr/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/tr/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/tr/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/tr/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/tr/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/tr/kusama-bug-bounty.md diff --git a/website/translated_docs/tr/kusama-claims.md b/polkadot-wiki/translated_docs/tr/kusama-claims.md similarity index 100% rename from website/translated_docs/tr/kusama-claims.md rename to polkadot-wiki/translated_docs/tr/kusama-claims.md diff --git a/website/translated_docs/tr/kusama-coc.md b/polkadot-wiki/translated_docs/tr/kusama-coc.md similarity index 100% rename from website/translated_docs/tr/kusama-coc.md rename to polkadot-wiki/translated_docs/tr/kusama-coc.md diff --git a/website/translated_docs/tr/kusama-community.md b/polkadot-wiki/translated_docs/tr/kusama-community.md similarity index 100% rename from website/translated_docs/tr/kusama-community.md rename to polkadot-wiki/translated_docs/tr/kusama-community.md diff --git a/website/translated_docs/tr/kusama-endpoints.md b/polkadot-wiki/translated_docs/tr/kusama-endpoints.md similarity index 100% rename from website/translated_docs/tr/kusama-endpoints.md rename to polkadot-wiki/translated_docs/tr/kusama-endpoints.md diff --git a/website/translated_docs/tr/kusama-faucet.md b/polkadot-wiki/translated_docs/tr/kusama-faucet.md similarity index 100% rename from website/translated_docs/tr/kusama-faucet.md rename to polkadot-wiki/translated_docs/tr/kusama-faucet.md diff --git a/website/translated_docs/tr/kusama-getting-started.md b/polkadot-wiki/translated_docs/tr/kusama-getting-started.md similarity index 100% rename from website/translated_docs/tr/kusama-getting-started.md rename to polkadot-wiki/translated_docs/tr/kusama-getting-started.md diff --git a/website/translated_docs/tr/kusama-index.md b/polkadot-wiki/translated_docs/tr/kusama-index.md similarity index 100% rename from website/translated_docs/tr/kusama-index.md rename to polkadot-wiki/translated_docs/tr/kusama-index.md diff --git a/polkadot-wiki/translated_docs/tr/kusama-ledger.md b/polkadot-wiki/translated_docs/tr/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/tr/kusama-parameters.md b/polkadot-wiki/translated_docs/tr/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/tr/kusama-social-recovery.md b/polkadot-wiki/translated_docs/tr/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/tr/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/tr/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/tr/kusama-time-periods.md b/polkadot-wiki/translated_docs/tr/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/tr/kusama-timeline.md b/polkadot-wiki/translated_docs/tr/kusama-timeline.md similarity index 100% rename from website/translated_docs/tr/kusama-timeline.md rename to polkadot-wiki/translated_docs/tr/kusama-timeline.md diff --git a/website/translated_docs/tr/learn-DOT.md b/polkadot-wiki/translated_docs/tr/learn-DOT.md similarity index 100% rename from website/translated_docs/tr/learn-DOT.md rename to polkadot-wiki/translated_docs/tr/learn-DOT.md diff --git a/website/translated_docs/tr/learn-account-generation.md b/polkadot-wiki/translated_docs/tr/learn-account-generation.md similarity index 100% rename from website/translated_docs/tr/learn-account-generation.md rename to polkadot-wiki/translated_docs/tr/learn-account-generation.md diff --git a/website/translated_docs/tr/learn-account-restore.md b/polkadot-wiki/translated_docs/tr/learn-account-restore.md similarity index 100% rename from website/translated_docs/tr/learn-account-restore.md rename to polkadot-wiki/translated_docs/tr/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/tr/learn-accounts.md b/polkadot-wiki/translated_docs/tr/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/tr/learn-architecture.md b/polkadot-wiki/translated_docs/tr/learn-architecture.md similarity index 100% rename from website/translated_docs/tr/learn-architecture.md rename to polkadot-wiki/translated_docs/tr/learn-architecture.md diff --git a/website/translated_docs/tr/learn-auction.md b/polkadot-wiki/translated_docs/tr/learn-auction.md similarity index 100% rename from website/translated_docs/tr/learn-auction.md rename to polkadot-wiki/translated_docs/tr/learn-auction.md diff --git a/polkadot-wiki/translated_docs/tr/learn-availability.md b/polkadot-wiki/translated_docs/tr/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/tr/learn-balance-transfers.md b/polkadot-wiki/translated_docs/tr/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/tr/learn-bridges.md b/polkadot-wiki/translated_docs/tr/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/tr/learn-collator.md b/polkadot-wiki/translated_docs/tr/learn-collator.md similarity index 100% rename from website/translated_docs/tr/learn-collator.md rename to polkadot-wiki/translated_docs/tr/learn-collator.md diff --git a/website/translated_docs/tr/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/tr/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/tr/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/tr/learn-comparison-dfinity.md diff --git a/website/translated_docs/tr/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/tr/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/tr/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/tr/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/tr/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/tr/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/tr/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/tr/learn-comparisons-cosmos.md diff --git a/website/translated_docs/tr/learn-comparisons.md b/polkadot-wiki/translated_docs/tr/learn-comparisons.md similarity index 100% rename from website/translated_docs/tr/learn-comparisons.md rename to polkadot-wiki/translated_docs/tr/learn-comparisons.md diff --git a/website/translated_docs/tr/learn-consensus.md b/polkadot-wiki/translated_docs/tr/learn-consensus.md similarity index 100% rename from website/translated_docs/tr/learn-consensus.md rename to polkadot-wiki/translated_docs/tr/learn-consensus.md diff --git a/website/translated_docs/tr/learn-crosschain.md b/polkadot-wiki/translated_docs/tr/learn-crosschain.md similarity index 100% rename from website/translated_docs/tr/learn-crosschain.md rename to polkadot-wiki/translated_docs/tr/learn-crosschain.md diff --git a/website/translated_docs/tr/learn-crowdloans.md b/polkadot-wiki/translated_docs/tr/learn-crowdloans.md similarity index 100% rename from website/translated_docs/tr/learn-crowdloans.md rename to polkadot-wiki/translated_docs/tr/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/tr/learn-cryptography.md b/polkadot-wiki/translated_docs/tr/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/tr/learn-governance.md b/polkadot-wiki/translated_docs/tr/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/tr/learn-identity.md b/polkadot-wiki/translated_docs/tr/learn-identity.md similarity index 100% rename from website/translated_docs/tr/learn-identity.md rename to polkadot-wiki/translated_docs/tr/learn-identity.md diff --git a/website/translated_docs/tr/learn-implementations.md b/polkadot-wiki/translated_docs/tr/learn-implementations.md similarity index 100% rename from website/translated_docs/tr/learn-implementations.md rename to polkadot-wiki/translated_docs/tr/learn-implementations.md diff --git a/website/translated_docs/tr/learn-implementers-guide.md b/polkadot-wiki/translated_docs/tr/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/tr/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/tr/learn-implementers-guide.md diff --git a/website/translated_docs/tr/learn-keys.md b/polkadot-wiki/translated_docs/tr/learn-keys.md similarity index 100% rename from website/translated_docs/tr/learn-keys.md rename to polkadot-wiki/translated_docs/tr/learn-keys.md diff --git a/website/translated_docs/tr/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/tr/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/tr/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/tr/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/tr/learn-launch.md b/polkadot-wiki/translated_docs/tr/learn-launch.md similarity index 100% rename from website/translated_docs/tr/learn-launch.md rename to polkadot-wiki/translated_docs/tr/learn-launch.md diff --git a/polkadot-wiki/translated_docs/tr/learn-ledger.md b/polkadot-wiki/translated_docs/tr/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/tr/learn-nominator.md b/polkadot-wiki/translated_docs/tr/learn-nominator.md similarity index 100% rename from website/translated_docs/tr/learn-nominator.md rename to polkadot-wiki/translated_docs/tr/learn-nominator.md diff --git a/website/translated_docs/tr/learn-parachains.md b/polkadot-wiki/translated_docs/tr/learn-parachains.md similarity index 100% rename from website/translated_docs/tr/learn-parachains.md rename to polkadot-wiki/translated_docs/tr/learn-parachains.md diff --git a/website/translated_docs/tr/learn-parathreads.md b/polkadot-wiki/translated_docs/tr/learn-parathreads.md similarity index 100% rename from website/translated_docs/tr/learn-parathreads.md rename to polkadot-wiki/translated_docs/tr/learn-parathreads.md diff --git a/website/translated_docs/tr/learn-phragmen.md b/polkadot-wiki/translated_docs/tr/learn-phragmen.md similarity index 100% rename from website/translated_docs/tr/learn-phragmen.md rename to polkadot-wiki/translated_docs/tr/learn-phragmen.md diff --git a/website/translated_docs/tr/learn-polkadot-host.md b/polkadot-wiki/translated_docs/tr/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/tr/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/tr/learn-polkadot-host.md diff --git a/website/translated_docs/tr/learn-proxies.md b/polkadot-wiki/translated_docs/tr/learn-proxies.md similarity index 100% rename from website/translated_docs/tr/learn-proxies.md rename to polkadot-wiki/translated_docs/tr/learn-proxies.md diff --git a/website/translated_docs/tr/learn-randomness.md b/polkadot-wiki/translated_docs/tr/learn-randomness.md similarity index 100% rename from website/translated_docs/tr/learn-randomness.md rename to polkadot-wiki/translated_docs/tr/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/tr/learn-registrar.md b/polkadot-wiki/translated_docs/tr/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/tr/learn-scams.md b/polkadot-wiki/translated_docs/tr/learn-scams.md similarity index 100% rename from website/translated_docs/tr/learn-scams.md rename to polkadot-wiki/translated_docs/tr/learn-scams.md diff --git a/website/translated_docs/tr/learn-security.md b/polkadot-wiki/translated_docs/tr/learn-security.md similarity index 100% rename from website/translated_docs/tr/learn-security.md rename to polkadot-wiki/translated_docs/tr/learn-security.md diff --git a/website/translated_docs/tr/learn-simple-payouts.md b/polkadot-wiki/translated_docs/tr/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/tr/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/tr/learn-simple-payouts.md diff --git a/website/translated_docs/tr/learn-spree.md b/polkadot-wiki/translated_docs/tr/learn-spree.md similarity index 100% rename from website/translated_docs/tr/learn-spree.md rename to polkadot-wiki/translated_docs/tr/learn-spree.md diff --git a/polkadot-wiki/translated_docs/tr/learn-staking.md b/polkadot-wiki/translated_docs/tr/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/tr/learn-transaction-fees.md b/polkadot-wiki/translated_docs/tr/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/tr/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/tr/learn-transaction-fees.md diff --git a/website/translated_docs/tr/learn-transactions.md b/polkadot-wiki/translated_docs/tr/learn-transactions.md similarity index 100% rename from website/translated_docs/tr/learn-transactions.md rename to polkadot-wiki/translated_docs/tr/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/tr/learn-treasury.md b/polkadot-wiki/translated_docs/tr/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/tr/learn-validator.md b/polkadot-wiki/translated_docs/tr/learn-validator.md similarity index 100% rename from website/translated_docs/tr/learn-validator.md rename to polkadot-wiki/translated_docs/tr/learn-validator.md diff --git a/website/translated_docs/tr/learn-wasm.md b/polkadot-wiki/translated_docs/tr/learn-wasm.md similarity index 100% rename from website/translated_docs/tr/learn-wasm.md rename to polkadot-wiki/translated_docs/tr/learn-wasm.md diff --git a/website/translated_docs/tr/maintain-collator.md b/polkadot-wiki/translated_docs/tr/maintain-collator.md similarity index 100% rename from website/translated_docs/tr/maintain-collator.md rename to polkadot-wiki/translated_docs/tr/maintain-collator.md diff --git a/website/translated_docs/tr/maintain-errors.md b/polkadot-wiki/translated_docs/tr/maintain-errors.md similarity index 100% rename from website/translated_docs/tr/maintain-errors.md rename to polkadot-wiki/translated_docs/tr/maintain-errors.md diff --git a/website/translated_docs/tr/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/tr/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-democracy.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/tr/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/tr/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/tr/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/tr/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/tr/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/tr/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/tr/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/tr/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/tr/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/tr/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/tr/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/tr/maintain-guides-validator-payout.md diff --git a/website/translated_docs/th-TH/maintain-index.md b/polkadot-wiki/translated_docs/tr/maintain-index.md similarity index 100% rename from website/translated_docs/th-TH/maintain-index.md rename to polkadot-wiki/translated_docs/tr/maintain-index.md diff --git a/website/translated_docs/tr/maintain-networks.md b/polkadot-wiki/translated_docs/tr/maintain-networks.md similarity index 100% rename from website/translated_docs/tr/maintain-networks.md rename to polkadot-wiki/translated_docs/tr/maintain-networks.md diff --git a/website/translated_docs/tr/maintain-nominator.md b/polkadot-wiki/translated_docs/tr/maintain-nominator.md similarity index 100% rename from website/translated_docs/tr/maintain-nominator.md rename to polkadot-wiki/translated_docs/tr/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/tr/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/tr/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ur-IN/maintain-sync.md b/polkadot-wiki/translated_docs/tr/maintain-sync.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-sync.md rename to polkadot-wiki/translated_docs/tr/maintain-sync.md diff --git a/website/translated_docs/tr/maintain-validator.md b/polkadot-wiki/translated_docs/tr/maintain-validator.md similarity index 100% rename from website/translated_docs/tr/maintain-validator.md rename to polkadot-wiki/translated_docs/tr/maintain-validator.md diff --git a/website/translated_docs/tr/maintain-wss.md b/polkadot-wiki/translated_docs/tr/maintain-wss.md similarity index 100% rename from website/translated_docs/tr/maintain-wss.md rename to polkadot-wiki/translated_docs/tr/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/tr/redenomination.md b/polkadot-wiki/translated_docs/tr/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/tr/research.md b/polkadot-wiki/translated_docs/tr/research.md similarity index 100% rename from website/translated_docs/tr/research.md rename to polkadot-wiki/translated_docs/tr/research.md diff --git a/polkadot-wiki/translated_docs/tr/thousand-validators.md b/polkadot-wiki/translated_docs/tr/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/tr/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ur-IN/ambassadors.md b/polkadot-wiki/translated_docs/ur-IN/ambassadors.md similarity index 100% rename from website/translated_docs/ur-IN/ambassadors.md rename to polkadot-wiki/translated_docs/ur-IN/ambassadors.md diff --git a/website/translated_docs/ur-IN/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/ur-IN/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/ur-IN/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/ur-IN/build-build-with-polkadot.md diff --git a/website/translated_docs/ur-IN/build-cumulus.md b/polkadot-wiki/translated_docs/ur-IN/build-cumulus.md similarity index 100% rename from website/translated_docs/ur-IN/build-cumulus.md rename to polkadot-wiki/translated_docs/ur-IN/build-cumulus.md diff --git a/website/translated_docs/ur-IN/build-deploy-parachains.md b/polkadot-wiki/translated_docs/ur-IN/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/ur-IN/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/ur-IN/build-deploy-parachains.md diff --git a/website/translated_docs/ur-IN/build-examples-index.md b/polkadot-wiki/translated_docs/ur-IN/build-examples-index.md similarity index 100% rename from website/translated_docs/ur-IN/build-examples-index.md rename to polkadot-wiki/translated_docs/ur-IN/build-examples-index.md diff --git a/website/translated_docs/ur-IN/build-hackathon.md b/polkadot-wiki/translated_docs/ur-IN/build-hackathon.md similarity index 100% rename from website/translated_docs/ur-IN/build-hackathon.md rename to polkadot-wiki/translated_docs/ur-IN/build-hackathon.md diff --git a/website/translated_docs/ur-IN/build-index.md b/polkadot-wiki/translated_docs/ur-IN/build-index.md similarity index 100% rename from website/translated_docs/ur-IN/build-index.md rename to polkadot-wiki/translated_docs/ur-IN/build-index.md diff --git a/website/translated_docs/ur-IN/build-integration.md b/polkadot-wiki/translated_docs/ur-IN/build-integration.md similarity index 100% rename from website/translated_docs/ur-IN/build-integration.md rename to polkadot-wiki/translated_docs/ur-IN/build-integration.md diff --git a/website/translated_docs/ur-IN/build-node-interaction.md b/polkadot-wiki/translated_docs/ur-IN/build-node-interaction.md similarity index 100% rename from website/translated_docs/ur-IN/build-node-interaction.md rename to polkadot-wiki/translated_docs/ur-IN/build-node-interaction.md diff --git a/website/translated_docs/ur-IN/build-node-management.md b/polkadot-wiki/translated_docs/ur-IN/build-node-management.md similarity index 100% rename from website/translated_docs/ur-IN/build-node-management.md rename to polkadot-wiki/translated_docs/ur-IN/build-node-management.md diff --git a/website/translated_docs/ur-IN/build-oracle.md b/polkadot-wiki/translated_docs/ur-IN/build-oracle.md similarity index 100% rename from website/translated_docs/ur-IN/build-oracle.md rename to polkadot-wiki/translated_docs/ur-IN/build-oracle.md diff --git a/website/translated_docs/ur-IN/build-parachains-rococo.md b/polkadot-wiki/translated_docs/ur-IN/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/ur-IN/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/ur-IN/build-parachains-rococo.md diff --git a/website/translated_docs/ur-IN/build-pdk.md b/polkadot-wiki/translated_docs/ur-IN/build-pdk.md similarity index 100% rename from website/translated_docs/ur-IN/build-pdk.md rename to polkadot-wiki/translated_docs/ur-IN/build-pdk.md diff --git a/polkadot-wiki/translated_docs/ur-IN/build-protocol-info.md b/polkadot-wiki/translated_docs/ur-IN/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ur-IN/build-smart-contracts.md b/polkadot-wiki/translated_docs/ur-IN/build-smart-contracts.md similarity index 100% rename from website/translated_docs/ur-IN/build-smart-contracts.md rename to polkadot-wiki/translated_docs/ur-IN/build-smart-contracts.md diff --git a/website/translated_docs/ur-IN/build-tools-index.md b/polkadot-wiki/translated_docs/ur-IN/build-tools-index.md similarity index 100% rename from website/translated_docs/ur-IN/build-tools-index.md rename to polkadot-wiki/translated_docs/ur-IN/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/ur-IN/build-transaction-construction.md b/polkadot-wiki/translated_docs/ur-IN/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/ur-IN/build-wallets.md b/polkadot-wiki/translated_docs/ur-IN/build-wallets.md similarity index 100% rename from website/translated_docs/ur-IN/build-wallets.md rename to polkadot-wiki/translated_docs/ur-IN/build-wallets.md diff --git a/polkadot-wiki/translated_docs/ur-IN/claims.md b/polkadot-wiki/translated_docs/ur-IN/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ur-IN/community.md b/polkadot-wiki/translated_docs/ur-IN/community.md similarity index 100% rename from website/translated_docs/ur-IN/community.md rename to polkadot-wiki/translated_docs/ur-IN/community.md diff --git a/website/translated_docs/ur-IN/contributing.md b/polkadot-wiki/translated_docs/ur-IN/contributing.md similarity index 100% rename from website/translated_docs/ur-IN/contributing.md rename to polkadot-wiki/translated_docs/ur-IN/contributing.md diff --git a/website/translated_docs/ur-IN/contributors.md b/polkadot-wiki/translated_docs/ur-IN/contributors.md similarity index 100% rename from website/translated_docs/ur-IN/contributors.md rename to polkadot-wiki/translated_docs/ur-IN/contributors.md diff --git a/website/translated_docs/ur-IN/ens.md b/polkadot-wiki/translated_docs/ur-IN/ens.md similarity index 100% rename from website/translated_docs/ur-IN/ens.md rename to polkadot-wiki/translated_docs/ur-IN/ens.md diff --git a/website/translated_docs/ur-IN/faq.md b/polkadot-wiki/translated_docs/ur-IN/faq.md similarity index 100% rename from website/translated_docs/ur-IN/faq.md rename to polkadot-wiki/translated_docs/ur-IN/faq.md diff --git a/polkadot-wiki/translated_docs/ur-IN/getting-started.md b/polkadot-wiki/translated_docs/ur-IN/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ur-IN/glossary.md b/polkadot-wiki/translated_docs/ur-IN/glossary.md similarity index 100% rename from website/translated_docs/ur-IN/glossary.md rename to polkadot-wiki/translated_docs/ur-IN/glossary.md diff --git a/polkadot-wiki/translated_docs/ur-IN/grants.md b/polkadot-wiki/translated_docs/ur-IN/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/ur-IN/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/ur-IN/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ur-IN/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/ur-IN/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-bug-bounty.md diff --git a/website/translated_docs/ur-IN/kusama-claims.md b/polkadot-wiki/translated_docs/ur-IN/kusama-claims.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-claims.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-claims.md diff --git a/website/translated_docs/ur-IN/kusama-coc.md b/polkadot-wiki/translated_docs/ur-IN/kusama-coc.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-coc.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-coc.md diff --git a/website/translated_docs/ur-IN/kusama-community.md b/polkadot-wiki/translated_docs/ur-IN/kusama-community.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-community.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-community.md diff --git a/website/translated_docs/ur-IN/kusama-endpoints.md b/polkadot-wiki/translated_docs/ur-IN/kusama-endpoints.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-endpoints.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-endpoints.md diff --git a/website/translated_docs/ur-IN/kusama-faucet.md b/polkadot-wiki/translated_docs/ur-IN/kusama-faucet.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-faucet.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-faucet.md diff --git a/website/translated_docs/ur-IN/kusama-getting-started.md b/polkadot-wiki/translated_docs/ur-IN/kusama-getting-started.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-getting-started.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-getting-started.md diff --git a/website/translated_docs/ur-IN/kusama-index.md b/polkadot-wiki/translated_docs/ur-IN/kusama-index.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-index.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-index.md diff --git a/polkadot-wiki/translated_docs/ur-IN/kusama-ledger.md b/polkadot-wiki/translated_docs/ur-IN/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/ur-IN/kusama-parameters.md b/polkadot-wiki/translated_docs/ur-IN/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ur-IN/kusama-social-recovery.md b/polkadot-wiki/translated_docs/ur-IN/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/ur-IN/kusama-time-periods.md b/polkadot-wiki/translated_docs/ur-IN/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ur-IN/kusama-timeline.md b/polkadot-wiki/translated_docs/ur-IN/kusama-timeline.md similarity index 100% rename from website/translated_docs/ur-IN/kusama-timeline.md rename to polkadot-wiki/translated_docs/ur-IN/kusama-timeline.md diff --git a/website/translated_docs/ur-IN/learn-DOT.md b/polkadot-wiki/translated_docs/ur-IN/learn-DOT.md similarity index 100% rename from website/translated_docs/ur-IN/learn-DOT.md rename to polkadot-wiki/translated_docs/ur-IN/learn-DOT.md diff --git a/website/translated_docs/ur-IN/learn-account-generation.md b/polkadot-wiki/translated_docs/ur-IN/learn-account-generation.md similarity index 100% rename from website/translated_docs/ur-IN/learn-account-generation.md rename to polkadot-wiki/translated_docs/ur-IN/learn-account-generation.md diff --git a/website/translated_docs/ur-IN/learn-account-restore.md b/polkadot-wiki/translated_docs/ur-IN/learn-account-restore.md similarity index 100% rename from website/translated_docs/ur-IN/learn-account-restore.md rename to polkadot-wiki/translated_docs/ur-IN/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-accounts.md b/polkadot-wiki/translated_docs/ur-IN/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ur-IN/learn-architecture.md b/polkadot-wiki/translated_docs/ur-IN/learn-architecture.md similarity index 100% rename from website/translated_docs/ur-IN/learn-architecture.md rename to polkadot-wiki/translated_docs/ur-IN/learn-architecture.md diff --git a/website/translated_docs/ur-IN/learn-auction.md b/polkadot-wiki/translated_docs/ur-IN/learn-auction.md similarity index 100% rename from website/translated_docs/ur-IN/learn-auction.md rename to polkadot-wiki/translated_docs/ur-IN/learn-auction.md diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-availability.md b/polkadot-wiki/translated_docs/ur-IN/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-balance-transfers.md b/polkadot-wiki/translated_docs/ur-IN/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-bridges.md b/polkadot-wiki/translated_docs/ur-IN/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ur-IN/learn-collator.md b/polkadot-wiki/translated_docs/ur-IN/learn-collator.md similarity index 100% rename from website/translated_docs/ur-IN/learn-collator.md rename to polkadot-wiki/translated_docs/ur-IN/learn-collator.md diff --git a/website/translated_docs/ur-IN/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/ur-IN/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/ur-IN/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/ur-IN/learn-comparison-dfinity.md diff --git a/website/translated_docs/ur-IN/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/ur-IN/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/ur-IN/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/ur-IN/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/ur-IN/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/ur-IN/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/ur-IN/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/ur-IN/learn-comparisons-cosmos.md diff --git a/website/translated_docs/ur-IN/learn-comparisons.md b/polkadot-wiki/translated_docs/ur-IN/learn-comparisons.md similarity index 100% rename from website/translated_docs/ur-IN/learn-comparisons.md rename to polkadot-wiki/translated_docs/ur-IN/learn-comparisons.md diff --git a/website/translated_docs/ur-IN/learn-consensus.md b/polkadot-wiki/translated_docs/ur-IN/learn-consensus.md similarity index 100% rename from website/translated_docs/ur-IN/learn-consensus.md rename to polkadot-wiki/translated_docs/ur-IN/learn-consensus.md diff --git a/website/translated_docs/ur-IN/learn-crosschain.md b/polkadot-wiki/translated_docs/ur-IN/learn-crosschain.md similarity index 100% rename from website/translated_docs/ur-IN/learn-crosschain.md rename to polkadot-wiki/translated_docs/ur-IN/learn-crosschain.md diff --git a/website/translated_docs/ur-IN/learn-crowdloans.md b/polkadot-wiki/translated_docs/ur-IN/learn-crowdloans.md similarity index 100% rename from website/translated_docs/ur-IN/learn-crowdloans.md rename to polkadot-wiki/translated_docs/ur-IN/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-cryptography.md b/polkadot-wiki/translated_docs/ur-IN/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-governance.md b/polkadot-wiki/translated_docs/ur-IN/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ur-IN/learn-identity.md b/polkadot-wiki/translated_docs/ur-IN/learn-identity.md similarity index 100% rename from website/translated_docs/ur-IN/learn-identity.md rename to polkadot-wiki/translated_docs/ur-IN/learn-identity.md diff --git a/website/translated_docs/ur-IN/learn-implementations.md b/polkadot-wiki/translated_docs/ur-IN/learn-implementations.md similarity index 100% rename from website/translated_docs/ur-IN/learn-implementations.md rename to polkadot-wiki/translated_docs/ur-IN/learn-implementations.md diff --git a/website/translated_docs/ur-IN/learn-implementers-guide.md b/polkadot-wiki/translated_docs/ur-IN/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/ur-IN/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/ur-IN/learn-implementers-guide.md diff --git a/website/translated_docs/ur-IN/learn-keys.md b/polkadot-wiki/translated_docs/ur-IN/learn-keys.md similarity index 100% rename from website/translated_docs/ur-IN/learn-keys.md rename to polkadot-wiki/translated_docs/ur-IN/learn-keys.md diff --git a/website/translated_docs/ur-IN/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/ur-IN/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/ur-IN/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/ur-IN/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/ur-IN/learn-launch.md b/polkadot-wiki/translated_docs/ur-IN/learn-launch.md similarity index 100% rename from website/translated_docs/ur-IN/learn-launch.md rename to polkadot-wiki/translated_docs/ur-IN/learn-launch.md diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-ledger.md b/polkadot-wiki/translated_docs/ur-IN/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ur-IN/learn-nominator.md b/polkadot-wiki/translated_docs/ur-IN/learn-nominator.md similarity index 100% rename from website/translated_docs/ur-IN/learn-nominator.md rename to polkadot-wiki/translated_docs/ur-IN/learn-nominator.md diff --git a/website/translated_docs/ur-IN/learn-parachains.md b/polkadot-wiki/translated_docs/ur-IN/learn-parachains.md similarity index 100% rename from website/translated_docs/ur-IN/learn-parachains.md rename to polkadot-wiki/translated_docs/ur-IN/learn-parachains.md diff --git a/website/translated_docs/ur-IN/learn-parathreads.md b/polkadot-wiki/translated_docs/ur-IN/learn-parathreads.md similarity index 100% rename from website/translated_docs/ur-IN/learn-parathreads.md rename to polkadot-wiki/translated_docs/ur-IN/learn-parathreads.md diff --git a/website/translated_docs/ur-IN/learn-phragmen.md b/polkadot-wiki/translated_docs/ur-IN/learn-phragmen.md similarity index 100% rename from website/translated_docs/ur-IN/learn-phragmen.md rename to polkadot-wiki/translated_docs/ur-IN/learn-phragmen.md diff --git a/website/translated_docs/ur-IN/learn-polkadot-host.md b/polkadot-wiki/translated_docs/ur-IN/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/ur-IN/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/ur-IN/learn-polkadot-host.md diff --git a/website/translated_docs/ur-IN/learn-proxies.md b/polkadot-wiki/translated_docs/ur-IN/learn-proxies.md similarity index 100% rename from website/translated_docs/ur-IN/learn-proxies.md rename to polkadot-wiki/translated_docs/ur-IN/learn-proxies.md diff --git a/website/translated_docs/ur-IN/learn-randomness.md b/polkadot-wiki/translated_docs/ur-IN/learn-randomness.md similarity index 100% rename from website/translated_docs/ur-IN/learn-randomness.md rename to polkadot-wiki/translated_docs/ur-IN/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-registrar.md b/polkadot-wiki/translated_docs/ur-IN/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ur-IN/learn-scams.md b/polkadot-wiki/translated_docs/ur-IN/learn-scams.md similarity index 100% rename from website/translated_docs/ur-IN/learn-scams.md rename to polkadot-wiki/translated_docs/ur-IN/learn-scams.md diff --git a/website/translated_docs/ur-IN/learn-security.md b/polkadot-wiki/translated_docs/ur-IN/learn-security.md similarity index 100% rename from website/translated_docs/ur-IN/learn-security.md rename to polkadot-wiki/translated_docs/ur-IN/learn-security.md diff --git a/website/translated_docs/ur-IN/learn-simple-payouts.md b/polkadot-wiki/translated_docs/ur-IN/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/ur-IN/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/ur-IN/learn-simple-payouts.md diff --git a/website/translated_docs/ur-IN/learn-spree.md b/polkadot-wiki/translated_docs/ur-IN/learn-spree.md similarity index 100% rename from website/translated_docs/ur-IN/learn-spree.md rename to polkadot-wiki/translated_docs/ur-IN/learn-spree.md diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-staking.md b/polkadot-wiki/translated_docs/ur-IN/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ur-IN/learn-transaction-fees.md b/polkadot-wiki/translated_docs/ur-IN/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/ur-IN/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/ur-IN/learn-transaction-fees.md diff --git a/website/translated_docs/ur-IN/learn-transactions.md b/polkadot-wiki/translated_docs/ur-IN/learn-transactions.md similarity index 100% rename from website/translated_docs/ur-IN/learn-transactions.md rename to polkadot-wiki/translated_docs/ur-IN/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/ur-IN/learn-treasury.md b/polkadot-wiki/translated_docs/ur-IN/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ur-IN/learn-validator.md b/polkadot-wiki/translated_docs/ur-IN/learn-validator.md similarity index 100% rename from website/translated_docs/ur-IN/learn-validator.md rename to polkadot-wiki/translated_docs/ur-IN/learn-validator.md diff --git a/website/translated_docs/ur-IN/learn-wasm.md b/polkadot-wiki/translated_docs/ur-IN/learn-wasm.md similarity index 100% rename from website/translated_docs/ur-IN/learn-wasm.md rename to polkadot-wiki/translated_docs/ur-IN/learn-wasm.md diff --git a/website/translated_docs/ur-IN/maintain-collator.md b/polkadot-wiki/translated_docs/ur-IN/maintain-collator.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-collator.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-collator.md diff --git a/website/translated_docs/ur-IN/maintain-errors.md b/polkadot-wiki/translated_docs/ur-IN/maintain-errors.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-errors.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-errors.md diff --git a/website/translated_docs/ur-IN/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-democracy.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/ur-IN/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ur-IN/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ur-IN/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/ur-IN/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-guides-validator-payout.md diff --git a/website/translated_docs/tr/maintain-index.md b/polkadot-wiki/translated_docs/ur-IN/maintain-index.md similarity index 100% rename from website/translated_docs/tr/maintain-index.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-index.md diff --git a/website/translated_docs/ur-IN/maintain-networks.md b/polkadot-wiki/translated_docs/ur-IN/maintain-networks.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-networks.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-networks.md diff --git a/website/translated_docs/ur-IN/maintain-nominator.md b/polkadot-wiki/translated_docs/ur-IN/maintain-nominator.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-nominator.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/ur-IN/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/ur-IN/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ur-PK/maintain-sync.md b/polkadot-wiki/translated_docs/ur-IN/maintain-sync.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-sync.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-sync.md diff --git a/website/translated_docs/ur-IN/maintain-validator.md b/polkadot-wiki/translated_docs/ur-IN/maintain-validator.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-validator.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-validator.md diff --git a/website/translated_docs/ur-IN/maintain-wss.md b/polkadot-wiki/translated_docs/ur-IN/maintain-wss.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-wss.md rename to polkadot-wiki/translated_docs/ur-IN/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/ur-IN/redenomination.md b/polkadot-wiki/translated_docs/ur-IN/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ur-IN/research.md b/polkadot-wiki/translated_docs/ur-IN/research.md similarity index 100% rename from website/translated_docs/ur-IN/research.md rename to polkadot-wiki/translated_docs/ur-IN/research.md diff --git a/polkadot-wiki/translated_docs/ur-IN/thousand-validators.md b/polkadot-wiki/translated_docs/ur-IN/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-IN/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ur-PK/ambassadors.md b/polkadot-wiki/translated_docs/ur-PK/ambassadors.md similarity index 100% rename from website/translated_docs/ur-PK/ambassadors.md rename to polkadot-wiki/translated_docs/ur-PK/ambassadors.md diff --git a/website/translated_docs/ur-PK/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/ur-PK/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/ur-PK/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/ur-PK/build-build-with-polkadot.md diff --git a/website/translated_docs/ur-PK/build-cumulus.md b/polkadot-wiki/translated_docs/ur-PK/build-cumulus.md similarity index 100% rename from website/translated_docs/ur-PK/build-cumulus.md rename to polkadot-wiki/translated_docs/ur-PK/build-cumulus.md diff --git a/website/translated_docs/ur-PK/build-deploy-parachains.md b/polkadot-wiki/translated_docs/ur-PK/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/ur-PK/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/ur-PK/build-deploy-parachains.md diff --git a/website/translated_docs/ur-PK/build-examples-index.md b/polkadot-wiki/translated_docs/ur-PK/build-examples-index.md similarity index 100% rename from website/translated_docs/ur-PK/build-examples-index.md rename to polkadot-wiki/translated_docs/ur-PK/build-examples-index.md diff --git a/website/translated_docs/ur-PK/build-hackathon.md b/polkadot-wiki/translated_docs/ur-PK/build-hackathon.md similarity index 100% rename from website/translated_docs/ur-PK/build-hackathon.md rename to polkadot-wiki/translated_docs/ur-PK/build-hackathon.md diff --git a/website/translated_docs/ur-PK/build-index.md b/polkadot-wiki/translated_docs/ur-PK/build-index.md similarity index 100% rename from website/translated_docs/ur-PK/build-index.md rename to polkadot-wiki/translated_docs/ur-PK/build-index.md diff --git a/website/translated_docs/ur-PK/build-integration.md b/polkadot-wiki/translated_docs/ur-PK/build-integration.md similarity index 100% rename from website/translated_docs/ur-PK/build-integration.md rename to polkadot-wiki/translated_docs/ur-PK/build-integration.md diff --git a/website/translated_docs/ur-PK/build-node-interaction.md b/polkadot-wiki/translated_docs/ur-PK/build-node-interaction.md similarity index 100% rename from website/translated_docs/ur-PK/build-node-interaction.md rename to polkadot-wiki/translated_docs/ur-PK/build-node-interaction.md diff --git a/website/translated_docs/ur-PK/build-node-management.md b/polkadot-wiki/translated_docs/ur-PK/build-node-management.md similarity index 100% rename from website/translated_docs/ur-PK/build-node-management.md rename to polkadot-wiki/translated_docs/ur-PK/build-node-management.md diff --git a/website/translated_docs/ur-PK/build-oracle.md b/polkadot-wiki/translated_docs/ur-PK/build-oracle.md similarity index 100% rename from website/translated_docs/ur-PK/build-oracle.md rename to polkadot-wiki/translated_docs/ur-PK/build-oracle.md diff --git a/website/translated_docs/ur-PK/build-parachains-rococo.md b/polkadot-wiki/translated_docs/ur-PK/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/ur-PK/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/ur-PK/build-parachains-rococo.md diff --git a/website/translated_docs/ur-PK/build-pdk.md b/polkadot-wiki/translated_docs/ur-PK/build-pdk.md similarity index 100% rename from website/translated_docs/ur-PK/build-pdk.md rename to polkadot-wiki/translated_docs/ur-PK/build-pdk.md diff --git a/polkadot-wiki/translated_docs/ur-PK/build-protocol-info.md b/polkadot-wiki/translated_docs/ur-PK/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ur-PK/build-smart-contracts.md b/polkadot-wiki/translated_docs/ur-PK/build-smart-contracts.md similarity index 100% rename from website/translated_docs/ur-PK/build-smart-contracts.md rename to polkadot-wiki/translated_docs/ur-PK/build-smart-contracts.md diff --git a/website/translated_docs/ur-PK/build-tools-index.md b/polkadot-wiki/translated_docs/ur-PK/build-tools-index.md similarity index 100% rename from website/translated_docs/ur-PK/build-tools-index.md rename to polkadot-wiki/translated_docs/ur-PK/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/ur-PK/build-transaction-construction.md b/polkadot-wiki/translated_docs/ur-PK/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/ur-PK/build-wallets.md b/polkadot-wiki/translated_docs/ur-PK/build-wallets.md similarity index 100% rename from website/translated_docs/ur-PK/build-wallets.md rename to polkadot-wiki/translated_docs/ur-PK/build-wallets.md diff --git a/polkadot-wiki/translated_docs/ur-PK/claims.md b/polkadot-wiki/translated_docs/ur-PK/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ur-PK/community.md b/polkadot-wiki/translated_docs/ur-PK/community.md similarity index 100% rename from website/translated_docs/ur-PK/community.md rename to polkadot-wiki/translated_docs/ur-PK/community.md diff --git a/website/translated_docs/ur-PK/contributing.md b/polkadot-wiki/translated_docs/ur-PK/contributing.md similarity index 100% rename from website/translated_docs/ur-PK/contributing.md rename to polkadot-wiki/translated_docs/ur-PK/contributing.md diff --git a/website/translated_docs/ur-PK/contributors.md b/polkadot-wiki/translated_docs/ur-PK/contributors.md similarity index 100% rename from website/translated_docs/ur-PK/contributors.md rename to polkadot-wiki/translated_docs/ur-PK/contributors.md diff --git a/website/translated_docs/ur-PK/ens.md b/polkadot-wiki/translated_docs/ur-PK/ens.md similarity index 100% rename from website/translated_docs/ur-PK/ens.md rename to polkadot-wiki/translated_docs/ur-PK/ens.md diff --git a/website/translated_docs/ur-PK/faq.md b/polkadot-wiki/translated_docs/ur-PK/faq.md similarity index 100% rename from website/translated_docs/ur-PK/faq.md rename to polkadot-wiki/translated_docs/ur-PK/faq.md diff --git a/polkadot-wiki/translated_docs/ur-PK/getting-started.md b/polkadot-wiki/translated_docs/ur-PK/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ur-PK/glossary.md b/polkadot-wiki/translated_docs/ur-PK/glossary.md similarity index 100% rename from website/translated_docs/ur-PK/glossary.md rename to polkadot-wiki/translated_docs/ur-PK/glossary.md diff --git a/polkadot-wiki/translated_docs/ur-PK/grants.md b/polkadot-wiki/translated_docs/ur-PK/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/polkadot-wiki/translated_docs/ur-PK/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/ur-PK/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ur-PK/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/ur-PK/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-bug-bounty.md diff --git a/website/translated_docs/ur-PK/kusama-claims.md b/polkadot-wiki/translated_docs/ur-PK/kusama-claims.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-claims.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-claims.md diff --git a/website/translated_docs/ur-PK/kusama-coc.md b/polkadot-wiki/translated_docs/ur-PK/kusama-coc.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-coc.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-coc.md diff --git a/website/translated_docs/ur-PK/kusama-community.md b/polkadot-wiki/translated_docs/ur-PK/kusama-community.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-community.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-community.md diff --git a/website/translated_docs/ur-PK/kusama-endpoints.md b/polkadot-wiki/translated_docs/ur-PK/kusama-endpoints.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-endpoints.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-endpoints.md diff --git a/website/translated_docs/ur-PK/kusama-faucet.md b/polkadot-wiki/translated_docs/ur-PK/kusama-faucet.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-faucet.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-faucet.md diff --git a/website/translated_docs/ur-PK/kusama-getting-started.md b/polkadot-wiki/translated_docs/ur-PK/kusama-getting-started.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-getting-started.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-getting-started.md diff --git a/website/translated_docs/ur-PK/kusama-index.md b/polkadot-wiki/translated_docs/ur-PK/kusama-index.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-index.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-index.md diff --git a/polkadot-wiki/translated_docs/ur-PK/kusama-ledger.md b/polkadot-wiki/translated_docs/ur-PK/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/ur-PK/kusama-parameters.md b/polkadot-wiki/translated_docs/ur-PK/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ur-PK/kusama-social-recovery.md b/polkadot-wiki/translated_docs/ur-PK/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/ur-PK/kusama-time-periods.md b/polkadot-wiki/translated_docs/ur-PK/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ur-PK/kusama-timeline.md b/polkadot-wiki/translated_docs/ur-PK/kusama-timeline.md similarity index 100% rename from website/translated_docs/ur-PK/kusama-timeline.md rename to polkadot-wiki/translated_docs/ur-PK/kusama-timeline.md diff --git a/website/translated_docs/ur-PK/learn-DOT.md b/polkadot-wiki/translated_docs/ur-PK/learn-DOT.md similarity index 100% rename from website/translated_docs/ur-PK/learn-DOT.md rename to polkadot-wiki/translated_docs/ur-PK/learn-DOT.md diff --git a/website/translated_docs/ur-PK/learn-account-generation.md b/polkadot-wiki/translated_docs/ur-PK/learn-account-generation.md similarity index 100% rename from website/translated_docs/ur-PK/learn-account-generation.md rename to polkadot-wiki/translated_docs/ur-PK/learn-account-generation.md diff --git a/website/translated_docs/ur-PK/learn-account-restore.md b/polkadot-wiki/translated_docs/ur-PK/learn-account-restore.md similarity index 100% rename from website/translated_docs/ur-PK/learn-account-restore.md rename to polkadot-wiki/translated_docs/ur-PK/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-accounts.md b/polkadot-wiki/translated_docs/ur-PK/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ur-PK/learn-architecture.md b/polkadot-wiki/translated_docs/ur-PK/learn-architecture.md similarity index 100% rename from website/translated_docs/ur-PK/learn-architecture.md rename to polkadot-wiki/translated_docs/ur-PK/learn-architecture.md diff --git a/website/translated_docs/ur-PK/learn-auction.md b/polkadot-wiki/translated_docs/ur-PK/learn-auction.md similarity index 100% rename from website/translated_docs/ur-PK/learn-auction.md rename to polkadot-wiki/translated_docs/ur-PK/learn-auction.md diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-availability.md b/polkadot-wiki/translated_docs/ur-PK/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-balance-transfers.md b/polkadot-wiki/translated_docs/ur-PK/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-bridges.md b/polkadot-wiki/translated_docs/ur-PK/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ur-PK/learn-collator.md b/polkadot-wiki/translated_docs/ur-PK/learn-collator.md similarity index 100% rename from website/translated_docs/ur-PK/learn-collator.md rename to polkadot-wiki/translated_docs/ur-PK/learn-collator.md diff --git a/website/translated_docs/ur-PK/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/ur-PK/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/ur-PK/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/ur-PK/learn-comparison-dfinity.md diff --git a/website/translated_docs/ur-PK/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/ur-PK/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/ur-PK/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/ur-PK/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/ur-PK/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/ur-PK/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/ur-PK/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/ur-PK/learn-comparisons-cosmos.md diff --git a/website/translated_docs/ur-PK/learn-comparisons.md b/polkadot-wiki/translated_docs/ur-PK/learn-comparisons.md similarity index 100% rename from website/translated_docs/ur-PK/learn-comparisons.md rename to polkadot-wiki/translated_docs/ur-PK/learn-comparisons.md diff --git a/website/translated_docs/ur-PK/learn-consensus.md b/polkadot-wiki/translated_docs/ur-PK/learn-consensus.md similarity index 100% rename from website/translated_docs/ur-PK/learn-consensus.md rename to polkadot-wiki/translated_docs/ur-PK/learn-consensus.md diff --git a/website/translated_docs/ur-PK/learn-crosschain.md b/polkadot-wiki/translated_docs/ur-PK/learn-crosschain.md similarity index 100% rename from website/translated_docs/ur-PK/learn-crosschain.md rename to polkadot-wiki/translated_docs/ur-PK/learn-crosschain.md diff --git a/website/translated_docs/ur-PK/learn-crowdloans.md b/polkadot-wiki/translated_docs/ur-PK/learn-crowdloans.md similarity index 100% rename from website/translated_docs/ur-PK/learn-crowdloans.md rename to polkadot-wiki/translated_docs/ur-PK/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-cryptography.md b/polkadot-wiki/translated_docs/ur-PK/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-governance.md b/polkadot-wiki/translated_docs/ur-PK/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ur-PK/learn-identity.md b/polkadot-wiki/translated_docs/ur-PK/learn-identity.md similarity index 100% rename from website/translated_docs/ur-PK/learn-identity.md rename to polkadot-wiki/translated_docs/ur-PK/learn-identity.md diff --git a/website/translated_docs/ur-PK/learn-implementations.md b/polkadot-wiki/translated_docs/ur-PK/learn-implementations.md similarity index 100% rename from website/translated_docs/ur-PK/learn-implementations.md rename to polkadot-wiki/translated_docs/ur-PK/learn-implementations.md diff --git a/website/translated_docs/ur-PK/learn-implementers-guide.md b/polkadot-wiki/translated_docs/ur-PK/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/ur-PK/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/ur-PK/learn-implementers-guide.md diff --git a/website/translated_docs/ur-PK/learn-keys.md b/polkadot-wiki/translated_docs/ur-PK/learn-keys.md similarity index 100% rename from website/translated_docs/ur-PK/learn-keys.md rename to polkadot-wiki/translated_docs/ur-PK/learn-keys.md diff --git a/website/translated_docs/ur-PK/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/ur-PK/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/ur-PK/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/ur-PK/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/ur-PK/learn-launch.md b/polkadot-wiki/translated_docs/ur-PK/learn-launch.md similarity index 100% rename from website/translated_docs/ur-PK/learn-launch.md rename to polkadot-wiki/translated_docs/ur-PK/learn-launch.md diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-ledger.md b/polkadot-wiki/translated_docs/ur-PK/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ur-PK/learn-nominator.md b/polkadot-wiki/translated_docs/ur-PK/learn-nominator.md similarity index 100% rename from website/translated_docs/ur-PK/learn-nominator.md rename to polkadot-wiki/translated_docs/ur-PK/learn-nominator.md diff --git a/website/translated_docs/ur-PK/learn-parachains.md b/polkadot-wiki/translated_docs/ur-PK/learn-parachains.md similarity index 100% rename from website/translated_docs/ur-PK/learn-parachains.md rename to polkadot-wiki/translated_docs/ur-PK/learn-parachains.md diff --git a/website/translated_docs/ur-PK/learn-parathreads.md b/polkadot-wiki/translated_docs/ur-PK/learn-parathreads.md similarity index 100% rename from website/translated_docs/ur-PK/learn-parathreads.md rename to polkadot-wiki/translated_docs/ur-PK/learn-parathreads.md diff --git a/website/translated_docs/ur-PK/learn-phragmen.md b/polkadot-wiki/translated_docs/ur-PK/learn-phragmen.md similarity index 100% rename from website/translated_docs/ur-PK/learn-phragmen.md rename to polkadot-wiki/translated_docs/ur-PK/learn-phragmen.md diff --git a/website/translated_docs/ur-PK/learn-polkadot-host.md b/polkadot-wiki/translated_docs/ur-PK/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/ur-PK/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/ur-PK/learn-polkadot-host.md diff --git a/website/translated_docs/ur-PK/learn-proxies.md b/polkadot-wiki/translated_docs/ur-PK/learn-proxies.md similarity index 100% rename from website/translated_docs/ur-PK/learn-proxies.md rename to polkadot-wiki/translated_docs/ur-PK/learn-proxies.md diff --git a/website/translated_docs/ur-PK/learn-randomness.md b/polkadot-wiki/translated_docs/ur-PK/learn-randomness.md similarity index 100% rename from website/translated_docs/ur-PK/learn-randomness.md rename to polkadot-wiki/translated_docs/ur-PK/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-registrar.md b/polkadot-wiki/translated_docs/ur-PK/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ur-PK/learn-scams.md b/polkadot-wiki/translated_docs/ur-PK/learn-scams.md similarity index 100% rename from website/translated_docs/ur-PK/learn-scams.md rename to polkadot-wiki/translated_docs/ur-PK/learn-scams.md diff --git a/website/translated_docs/ur-PK/learn-security.md b/polkadot-wiki/translated_docs/ur-PK/learn-security.md similarity index 100% rename from website/translated_docs/ur-PK/learn-security.md rename to polkadot-wiki/translated_docs/ur-PK/learn-security.md diff --git a/website/translated_docs/ur-PK/learn-simple-payouts.md b/polkadot-wiki/translated_docs/ur-PK/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/ur-PK/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/ur-PK/learn-simple-payouts.md diff --git a/website/translated_docs/ur-PK/learn-spree.md b/polkadot-wiki/translated_docs/ur-PK/learn-spree.md similarity index 100% rename from website/translated_docs/ur-PK/learn-spree.md rename to polkadot-wiki/translated_docs/ur-PK/learn-spree.md diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-staking.md b/polkadot-wiki/translated_docs/ur-PK/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ur-PK/learn-transaction-fees.md b/polkadot-wiki/translated_docs/ur-PK/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/ur-PK/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/ur-PK/learn-transaction-fees.md diff --git a/website/translated_docs/ur-PK/learn-transactions.md b/polkadot-wiki/translated_docs/ur-PK/learn-transactions.md similarity index 100% rename from website/translated_docs/ur-PK/learn-transactions.md rename to polkadot-wiki/translated_docs/ur-PK/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/ur-PK/learn-treasury.md b/polkadot-wiki/translated_docs/ur-PK/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ur-PK/learn-validator.md b/polkadot-wiki/translated_docs/ur-PK/learn-validator.md similarity index 100% rename from website/translated_docs/ur-PK/learn-validator.md rename to polkadot-wiki/translated_docs/ur-PK/learn-validator.md diff --git a/website/translated_docs/ur-PK/learn-wasm.md b/polkadot-wiki/translated_docs/ur-PK/learn-wasm.md similarity index 100% rename from website/translated_docs/ur-PK/learn-wasm.md rename to polkadot-wiki/translated_docs/ur-PK/learn-wasm.md diff --git a/website/translated_docs/ur-PK/maintain-collator.md b/polkadot-wiki/translated_docs/ur-PK/maintain-collator.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-collator.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-collator.md diff --git a/website/translated_docs/ur-PK/maintain-errors.md b/polkadot-wiki/translated_docs/ur-PK/maintain-errors.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-errors.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-errors.md diff --git a/website/translated_docs/ur-PK/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-democracy.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/ur-PK/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/ur-PK/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ur-PK/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/ur-PK/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-guides-validator-payout.md diff --git a/website/translated_docs/ur-IN/maintain-index.md b/polkadot-wiki/translated_docs/ur-PK/maintain-index.md similarity index 100% rename from website/translated_docs/ur-IN/maintain-index.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-index.md diff --git a/website/translated_docs/ur-PK/maintain-networks.md b/polkadot-wiki/translated_docs/ur-PK/maintain-networks.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-networks.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-networks.md diff --git a/website/translated_docs/ur-PK/maintain-nominator.md b/polkadot-wiki/translated_docs/ur-PK/maintain-nominator.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-nominator.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/ur-PK/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/ur-PK/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/zh-TW/maintain-sync.md b/polkadot-wiki/translated_docs/ur-PK/maintain-sync.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-sync.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-sync.md diff --git a/website/translated_docs/ur-PK/maintain-validator.md b/polkadot-wiki/translated_docs/ur-PK/maintain-validator.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-validator.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-validator.md diff --git a/website/translated_docs/ur-PK/maintain-wss.md b/polkadot-wiki/translated_docs/ur-PK/maintain-wss.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-wss.md rename to polkadot-wiki/translated_docs/ur-PK/maintain-wss.md diff --git a/polkadot-wiki/translated_docs/ur-PK/redenomination.md b/polkadot-wiki/translated_docs/ur-PK/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ur-PK/research.md b/polkadot-wiki/translated_docs/ur-PK/research.md similarity index 100% rename from website/translated_docs/ur-PK/research.md rename to polkadot-wiki/translated_docs/ur-PK/research.md diff --git a/polkadot-wiki/translated_docs/ur-PK/thousand-validators.md b/polkadot-wiki/translated_docs/ur-PK/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/ur-PK/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/zh-CN/ambassadors.md b/polkadot-wiki/translated_docs/zh-CN/ambassadors.md similarity index 100% rename from website/translated_docs/zh-CN/ambassadors.md rename to polkadot-wiki/translated_docs/zh-CN/ambassadors.md diff --git a/polkadot-wiki/translated_docs/zh-CN/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/zh-CN/build-build-with-polkadot.md new file mode 100644 index 000000000000..0c2bae75c83a --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-build-with-polkadot.md @@ -0,0 +1,194 @@ +--- +id: build-build-with-polkadot +title: Polkadot 開發者入门指南 +sidebar_label: Polkadot 開發者入门指南 +--- + +_本文是对博文[《波卡开发入门需知》](https://medium.com/polkadot-network/everything-you-need-to-know-to-prepare-for-polkadot-32d08b929735)的维护版本。_ + +作为一个区块链协议，波卡希望达成两个目标：为所有接入的平行链提供**共享安全性**，并允许所有接入的链使用[XCMP](learn-crosschain)来实现**互操作**。随着 Parity 的 Substrate 和 Cumulus 这类[PDKs](build-pdk)的问世，开发和启动一条新链所需花费的时间已大大减少。以前开发一条新链需要几年，而现在可能只需要几周甚至几天。 + +这份指南将带你了解想要使用 Polkadot 创建你的愿景，你现在能做的事儿。我们将解释平行链和智能合约之间的区别（以及为什么其中一个可能比另一个更适合你的应用程序）。还将列出现在可用的资源和即将发布的资源，以便你可以开始创建应用程序，并为参与今年晚些时候的 Polkadot 主网发布做准备。 + +## 我们处于哪里？ + +- 主网：**Polkadot** +- Canary network: **Kusama** +- 当前主要测试网络：**Westend**(Polkadot 的克隆) 和**Rococo** (平行链) +- Substrate:**2.0.0** +- ink!: **3.0** ([文献](https://substrate.dev/docs/en/knowledgebase/smart-contracts)) + +## 你需要了解的内容： + +波卡的主网已经上线。 主要的测试网有两个。 - **Wesend**, 其目标是 运行类似于当前的 波卡的主网。 **Roco**, 专门用于 测试平行链。 此外，还有一个叫做 [Kusama](https://kusama.network) 的价值承载网络，在 Polkadot 操作之前 会获得功能。 + +波卡[采用丰富的编程语言](learn-implementations)，支持从 Rust 到 JavaScript 等一系列语言。在 Substrate 框架下当前主要采用 Rust 进行编程。Substrate 是一套支持开发者便捷地开发完整区块链应用的框架。这套框架通过集成核心要素而得以实现，这些要素有网络协议、共识层、Wasm 编译器和运行模块(也称为模块) 等。Cumulus 是一种对 Substrate 的扩展版本，它允许使用 Substrate 开发的链与波卡连接成为平行链。Substrate 当前发布的标签版本是 2.0.0，这一版拥有稳定版 API。 + +波卡的原生功能不支持智能合约，但可以通过平行链实现智能合约。用 Substrate 开发的链能够通过使用 Wasm 合约中的[Contracts](https://github.com/paritytech/substrate/tree/master/frame/contracts)模块和 FRAME 中的[EVM](https://github.com/paritytech/substrate/tree/master/frame/evm)模块来实现智能合约的功能。contracts 模块能够允许任意用户或者根据具体规则在链上部署 Wasm 编译的合约。为了促进 Wasm 智能合约的开发，Parity 也在开发一种基于 Rust 用来专门编写智能合约的语言[ink!](https://github.com/paritytech/ink)。 + +波卡主网自 2020 年 5 月正式上线。现在开发工具已经出现且趋于稳定，那当下正是尝试用波卡开发你项目的大好时机。但别急！在你一头扎进写代码前，你应该仔细考虑你想开发的去中心化应用的类型，并且了解一些适用于波卡开发者的不同范式。 + +## 平行链，平行线程，智能合约的区别是什么？ + +波卡为你提供了多种不同的开发应用的方式：可以作为现有平行链上部署的智能合约，也可作为你自己的平行链或者平行线程来开发。以上 3 种开发方式都有各自的优缺点，阅读本章节会帮助你理解三者的区别。 + +平行链是一条独立的链条，它拥有自己的运行逻辑，并且能够从波卡中继链提供的共享安全性和跨链通信机制中收益。平行链具有更高的灵活性和可定制性，但同时也需要更高的成本来开发和维护。 + +和平行链类似，平行线程使得开发者对其应用掌握更偏底层逻辑的控制。两者的主要区别在于使用成本，因为使用平行线程比用平行链更经济。平行线程的使用成本较低是因为它仅在需要时才产生新的区块，而平行链则不同，它每产生一个新的区块都需要保证插入一个中继链的插槽。当开发平行线程时，你所使用的开发工具 (如 PDKs) 以及获得的好处和开发平行链是一样的，而不用担心高额的使用成本。 + +在波卡主网上，会有一条或多条充当智能合约平台的平行链。智能合约是一种仅存在一条平行链上，复杂度有限的可执行程序。因为它们仅存在某一条链上，它们可以流畅地和同一条链上的其它智能合约互操作。尽管如此，这些合约一直会受其从属的主链特征的限制。 + +如果你需要对自己的应用的设计和特点拥有更多掌控力，平行链将是更好的选择。记住一点，智能合约可以先当做试验场，时机成熟后可再将其转换为平行链。智能合约平台通常具备类似 IDEs 一样便捷的工具以促进快速的迭代。此外，还可以针对智能合约创建一个 MVP 来评估用户兴趣，进而再将其开发为平行链。 + +对于打算从 0 到 1 开发一套货币系统以及面面俱到的链的开发者，平行链将赋予他们更多的发挥空间。相较于智能合约平台所呈现的复杂逻辑，平行链显得更为简单且有效。另外，平行链在治理方式上也赋予了更多的灵活性，相较于现行的硬分叉模式，平行链可以实现争议性更少的完整升级。 + +平行链或平行线程具有以下特点： + +- 定制费用架构(例如: 固定费用交易费或按字节)。 +- 定制货币政策用作原生币币和本地经济。 +- 财政库通过状态转变函数获取资助。 +- 一个通过 DAO 管理的，分配你的链上财政资产的治理模式。 + +![build 1](assets/build-1.png) + +对于因采用智能合约使得成本高昂而难以执行的复杂运行逻辑，平行链为它的构建提供了可能性。然而，与智能合约不同的是，平行链缺少一个完整的 gas 计量系统，且很容易陷入死循环 bug (在智能合约的设计中会避免) 中。这一弱点在 Substrate 所采用的的权重系统中得到了缓解，但这也给平行链的开发者正确执行基准增加了更多负担。 + +你也可以选择套用平行链、平行线程以及智能合约的组合。如果你的部分逻辑必需包含循环，你可以使用运行原生平行链来处理所有这些复杂逻辑，采用智能合约来调用迭代。如果你需要从预言机上导入链下数据，你可以将平行线程用作每 24 小时触发一次数据导入的预言机 (如果这些数据对波卡生态里的其他用户也有价值，那么这种机制就最有意义了) 。 + +你很可能已经意识到了你的应用更适用于其中的某一种方式 (或是几种的混合) ，如果你需要快速回顾来消化这些信息，你可以将这张对比图作为备忘： + +![build 2](assets/build-2.png) + +> **注意:** 此的图片不包括平行线程，但正如我们之前提到平行链所有优点同样适用于平行线程。但是它们部署和维护成本较*低*。因此如果他们在上面的图表上有一列，它会在平行链列的"易于部署"和"维护费用"的更改为 `+`。 + +根据你在构建应用时对智能合约或者是平行链的使用选择，本指南现在将划分为两部分。你可以随意地阅读这两个部分，也可只阅读适用于你的部分。 + +- [你想建立平行链或平行线程!](#so-you-want-to-build-a-parachain-or-parathread) +- [你想建立智能合约!](#so-you-want-to-build-a-smart-contract) + +## 所以你想开发平行链或是平行线程…… + +现在你已经决定将开发平行链或者平行线程作为你新项目的正确方式，下面就是决定使用哪个框架了。用于开发平行链或平行线程的框架被称为平行链开发套件 (PDKs) 。现阶段，只有 Parity Technologies 开发的 Substrate 和 Cumulus 可控选择。 + +未来会有很多不同语言编写的 PDKs，就像波卡 HOST 有多种[实现](learn-implementations.md)一样。 + +> **立即行动:** 您是否想开发一套全新的平行链开发套件？ Web3 基金会这些团队提供资助，了解更多并且在[W3F 资助页面](https://grants.web3.foundation)申请。 + +### 开始使用 Substrate + +Substrate 是用于开发波卡的底层框架。它是为区块链创新者所开发的工具包，提供了开发新链所需的模块。它包含了模块式的运行插件库，你可以用它来开发你的链条逻辑，也可以用它来编写你自己的组件或者共享到社区。 + +开始使用 Substrate 的最佳方式是先去探索一下[Substrate 基础知识](https://substrate.dev/docs/en/)，这是一个由 Parity Technologies 创建并维护的在线知识库。 + +我们推荐你在知识库那里多逛逛，直到你熟悉了常用的模式为止。一旦你有了扎实的理解，你就可以在提供的教程中挑战自己所学来获得进步。 + +### 如何设定你的平行链 + +当你用 Substrate 创建了你的链条的运行逻辑后，你就可以将它编译成 Wasm 的可执行文件。这个 Wasm 代码文件包含了你链条的所有状态转换函数，将项目作为平行链或者平行线程部署到波卡上时将用到这份文件。 + +波卡上的验证人将使用这些已提交的 Wasm 代码来验证你的链条或者线程的状态的转变，但做这一验证需要一些额外的基础设施。验证人需要设法保持对最新的状态转换的跟进，因为波卡上节点无需同时成为你的链上的节点。 + +这里正是检验节点发挥作用的地方。校验器是装载你平行链的容器，它承担着至关重要的功能，为你的链条生成新的候选区块，并将它们传给波卡上的验证人以便验证人将其装入中继链。 + +虽然 Substrate 内置了自己的网络层，但不幸的是它只支持独立的链条 (不连接中继链的链条)。不过 Substrate 的扩展版 Cumulus 内置了校验节点，允许基于 Substrate 逻辑的平行链或者平行线程与波卡兼容。 + +#### Cumulus + +建立[Cumulus](build-cumulus)的目标是作为 Substrate 的扩展，使得任意的 Substrate 运行环境都能与波卡兼容。 + +它能处理任何一条需要接入波卡的平行链其上的网络兼容性。包括： + +- 跨链的信息传递。 +- 开箱即用的收集人节点 +- 一套中继链的嵌入式的轻客户端。 +- Polkadot 出块者兼容性。 +- 将 Cumulus 集成到你的 Substrate 链上使得它能以最少修改的方式工作在波卡上，这大概和导入 crate 模块并添加一条命令行一样的轻松。 + +### 如何在 Polkadot 中部署平行链或平行线程。 + +#### 平行链 + +为了将你的平行链添加到波卡网络中，你需要持有平行链插槽。 + +平行链插槽通过公开拍卖发售，相关的发售规则请参考 wiki 百科中[平行链拍卖](learn-auction)的内容。 + +#### 平行线程 + +平行线程不需要平行链插槽，所以你无需参与蜡烛拍卖。但你可以付费在中继链上注册你的平行线程代码后，然后就能参加按区块进行的拍卖，以使得你的状态转换可以包含到中继链上。 + +更多关于平行线程如何按区块拍卖的信息，请详见[平行线程](learn-parathreads)这页的内容。 + +## 智能合约的创建 + +波卡的中继链本身不支持智能合约，但由于接入波卡的平行链能够支持任意的状态转换，因此这些平行链能够支持智能合约。当平行链接入后，智能合约开发者便可以使用这些选项。如今开发技术已趋于成熟，先在本地链条上启动开发随后将其部署到线上环境的方式成为可能。 + +Substrate 有两种方式来支持开箱即用的智能合约开发。一种方式是使用文章[《合约》](https://github.com/paritytech/substrate/tree/master/frame/contracts)中的框架库所提供的模板，第二种方法是使用 Substrate 的[《EVM 模块》](https://github.com/paritytech/substrate/tree/master/frame/evm)来部署 EVM 作为底层从 Solidity 或 Vyper 语言编译过来的字节码，并能够使用以太坊的技术栈。 + +对于以前写过智能合约的开发者而言，他们对于部署 EVM 的链更为熟练。然而合约模块针对 EVM 的设计做了一些显著的改善，它们是： + +1. **Wasm**. 此合约模块将 WebAssembly 用作自己的编译目标，凡是经过 Wasm 编译的语言都可被用作便携智能合约。不过写智能合约最好是有一个专门的特定领域语言，为此 Parity 提供了[ink!](#ink)语言。 + +2. **租赁**. 合约必须支付租金或者足额的抵押来证明它存在于链上的正当性。当一份合约没有做上述维护时，可能会产生一种叫做*tombstone*的引用。在某些情况下，如果合约没有达到以上要求，它将会随存储一起被彻底删除。 + +3. **缓存**. 默认情况下合约将被缓存，这意味着合约只需被部署一次，之后你就可以任意地对其做实例化。这种方式有助于最小化链上的存储负载。除此以外，当合约不再被使用且*现存的抵押*耗尽时，代码会从存储中被清除(也叫注销)。 + +或许你可能想着手开始在本地搭建测试环境，开始编写你的智能合约。将一个 Substrate 节点搭配两组智能合约模块中的一组一起使用可以完成上述工作。在完成测试环境的开发后，你需要查阅例如[用于部署智能合约的 Edgeware ](https://contracts.edgewa.re/)这样的项目以将你的项目做上线。 + +### Edgeware + +[Edgeware](https://edgewa.re)是一个附带智能合约模块的项目。Edgeware 是一个针对智能合约做的免许可平台，正被用于进行链上治理的实验。它是目前开发智能合约并部署其上线的开发者的最佳选项。 + +Edgeware 的目标是被用于在连接波卡时被视作平行链从而允许其对智能合约的操作。此时，智能合约能够通过[XCMP](learn-crosschain)实现与其它波卡生态系统部分的交互。 + +关于 Edgeware 的通用文档可以看[这里](https://docs.edgewa.re/)以及[如何使用 Edgeware 部署智能合约](https://contracts.edgewa.re/)。 + +## Moonbeam + +[Moonbeam](https://moonbeam.network)是另一个被计划用于将平行链部署到波卡上并且支持智能合约的项目。因为 Moonbeam 用到了[Frontier](https://github.com/paritytech/frontier)，它是一个附带了现有以太坊工具的互操作层，将以很小的摩擦支持所有针对 EVM 环境编写的应用程序。 + +跟着这篇[文档](https://docs.moonbeam.network/)试着去部署一个合约到 Moonbeam 上吧。 + +### Ink + +[ink!](https://github.com/paritytech/ink)是一种特定领域语言用于使用 Rust 语言编写智能合约并将其编译为 Wasm 代码。如 README 中所述，ink 目前尚处于实验阶段，所以勇敢的开发者们也许会体验一段颤栗又可行的开发之旅。一些项目使用 ink!做的开发呈现出相当复杂的程度，例如 Plasm 的[Plasma 合约](https://github.com/staketechnologies/Plasm)，所以开发者需要足够熟练才能开始创造有趣的项目。 + +对于感兴趣的开发者，可以通过研究这些写好的[案例](https://github.com/paritytech/ink/tree/master/examples)开始学习编写智能合约。这些案例可以作为编写逻辑更复杂的会被部署到智能合约平行链的指引。 + +ink! 已经为新的智能合约技术栈打下了很多基础，该技术是基于 Wasm 的虚拟机并且能与 Substrate 链兼容。 + +## 智能合约的部署 + +智能合约简单讲就是一段包含链上地址并且能被外部参与者调用的代码。事实上关键的部分在于，你需要提前将代码放到链上以便任何用户都能对它做执行。 + +在链上部署智能合约的方式与您将使用的特定平行链略有不同，但通常你会发送一个特殊交易，该交易将在账本上创建智能合约。你可能需要为初始化逻辑以及合约占用的存储空间支付相关费用。 + +## 为你的智能合约付费 + +每个平台都有不同的支付方式和维护智能合约状态的方式。 + +你可能会看到为智能合约付费的不同模式，包括： + +- 与部署交易关联的交易费用 +- 订阅方式，你可以定期支付到该平台作费用 +- 您需要持有本机令牌阈值才能使用平台的访问令牌模型 (EOS 具有类似的) 租金存储。 +- 免费试用或开发者促销 +- 大多数智能合约平台使用某种形式的 gas 费来限制用户可以执行的操作数量。用户将需要预先支付 gas 费，不使用的 gas 费将被退还。 + +您将需要考虑智能合约的存储和复杂性，以确保 gas 费用的数量保持在合理范围内。无论您使用哪种智能合约平台，存储费用都可能会很昂贵，因此有必要尽可能多的在链外保存数据。您可以考虑使用[IPFS](https://ipfs.io/)或[STORJ](https://storj.io/)来保留数据并仅在链上提交内容地址。 + +### 现在还处于早期 + +波卡上的智能合约仍处于早期阶段，并且直到现在才有了稳定的开发。我们正在积极地生产内容以帮助开发人员的开发加速，并将使用最新资源维护 Wiki。您也应该及时跟进以下链接的内容： + +- [Edgeware](https://edgewa.re). +- [Moonbeam](https://moonbeam.network) +- [ink!](https://github.com/paritytech/ink). (请注意 Wiki 选项卡上的内容。) +- [Substrate 合约模块](https://github.com/paritytech/substrate/tree/master/frame/contracts) + +## 总结 + +本指南为您提供了一个心智模型，并展示了必要的资源来帮助您确定并开始以平行链或智能合约的形式构建项目。即使工具仍在日趋成熟，但尽早开发的优势将是您对项目的熟悉和超前，使您能够创新并创造出真正全新的东西。 + +如果您对 Polkadot 上的平行链或智能合约抱有有趣的想法，请随时进入[波卡饮水机](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org)进行讨论。开发者或许更感兴趣加入[波卡开发者小酒馆](https://riot.im/app/#/room/#polkadotnoobs:matrix.org)或者[Substrate 技术交流群](https://riot.im/app/#/room/#substrate-technical:matrix.org)提问讨论。与往常一样，请关注 [社区频道](community)以便及时跟进 Polkadot 的最新动态。 + +祝好运！ diff --git a/website/translated_docs/zh-CN/build-cumulus.md b/polkadot-wiki/translated_docs/zh-CN/build-cumulus.md similarity index 100% rename from website/translated_docs/zh-CN/build-cumulus.md rename to polkadot-wiki/translated_docs/zh-CN/build-cumulus.md diff --git a/polkadot-wiki/translated_docs/zh-CN/build-deploy-parachains.md b/polkadot-wiki/translated_docs/zh-CN/build-deploy-parachains.md new file mode 100644 index 000000000000..26dc2747eb2a --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-deploy-parachains.md @@ -0,0 +1,91 @@ +--- +id: build-deploy-parachains +title: 如何部署平行链 +sidebar_label: 如何部署平行链 +--- + +这个指南经已更新到 Alexander 测试网络 + +## 如何查询平行链 + +前往[Polkadot UI](https://polkadot.js.org/apps/#/explorer)的`Chain State`，选择`parachains`模组和`parachains(）`之后按下`+`按钮，之后会回传有效的平行链。 + +## 如何部署 Adder 平行链 + +**You will need to have the minimum deposit needed to create a referendum. Currently this minimum is 5 DOT.** + +The `adder` parachain is a simple parachain that will keep a value in storage and add to this value as messages are sent to it. It can be found in the Polkadot repository under the `test-parachains` folder. + +> 由 Adrian Brink 提出的本指南的过时视频版本 [此处](https://www.youtube.com/watch?v=pDqkzvA4C0E)。 当两个指南有分歧时，请参阅此。 + +### 代码生成 + +第一步首先下载 Polkadot 代码到你本地目录 + +```bash +git clone https://github.com/paritytech/polkadot.git +``` + +确保你经己安装好了 Rust + +```bash +curl https://sh.rustup.rs -sSf | sh +sudo apt install make clang pkg-config libssl-dev +rustup update +``` + +现在前往在 Polkadot 代码库裹的`test-parachains`资料夹并执行生成脚本 + +```bash +cd polkadot/test-parachains +./build.sh +``` + +它会在这个资料夹建立简单`adder`平行链的 Wasm 可执行文件，它将简单地添加发送到给它的消息。Wasm 可执行文件会在`parachains/test/res/adder.wasm`路径，所以确保你能在那找到。 + +你需要生成并运行校对人(Collator)节点从而取得平行链的创世纪状态。 + +前往`test-parachains/adder/collator`资料夹并执行`build`和`run`指令 + +```bash +cargo build +cargo run +[ctrl-c] +``` + +停止校对人节点后你将获得如下结果： + +``` +Starting adder collator with genesis: +Dec: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 27, 77, 3, 221, 140, 1, 241, 4, 145, 67, +207, 156, 76, 129, 126, 75, 22, 127, 29, 27, 131, 229, 198, 240, 241, 13, 137, 186, 30, 123, 206] +Hex: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000011b4d03dd8c01f1049143cf9c4c817e4b167f1d1b83e5c6f0f10d89ba1e7bce +``` + +最重要的资料是 Hex 字串，这是你的创世纪状态，你需要将它保存用于接下来步骤。 + +### 部署平行链 + +前往[Polkadot UI](https://polkadot.js.org/apps/#/extrinsics)的`Extrinsics`标签，选择你要从中部署 parachain 的帐户，你需要创建公投从而部署平行链。 + +Click on `democracy` -> `propose(proposal,value)` -> `parachains` -> `registerParachain(id,code,initial_head_data)`. + +In the `id` input enter in the id of the parachain. In the case of the simple adder it will be `100`. In the `code` field click on the page button and then upload the `adder.wasm` binary that was compiled from before. In the `initial_head_data` we will copy and paste the hex data that we got from running the collator node. In the `value` field you will need to input the minimum required value for creating a referendum. At the time of writing this is _5 DOT_ on the Alexander testnet. + +![registering a parachain](assets/parachain/register.png) + +假如你前往到`Democracy`标签，你应该会看到你的提案在议案部分 + +一旦你等待的提案成为公投，你可以投票选择`赞成(Aye)`或`反对(Nay)`，投赞成票使你能够部署平行链。 + +![parachain referendum](assets/parachain/referendum.png) + +当公投结束后，你可以查询你的平行链状态。 + +前往`Chain State`标签之后选择查询`parachains`状态 ，你应该能够看到一些你的平行链资料。 + +![parachain info](assets/parachain/info.png) + +### 与 Parachain 互动 + +_Coming soon_ diff --git a/website/translated_docs/zh-CN/build-dev-roadmap.md b/polkadot-wiki/translated_docs/zh-CN/build-dev-roadmap.md similarity index 96% rename from website/translated_docs/zh-CN/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/zh-CN/build-dev-roadmap.md index d8a775173c2a..703c2b8b475a 100644 --- a/website/translated_docs/zh-CN/build-dev-roadmap.md +++ b/polkadot-wiki/translated_docs/zh-CN/build-dev-roadmap.md @@ -25,7 +25,7 @@ sidebar_label: 开发路线图 ## Cumulus -Cumulus 目前正处于紧锣密鼓的开发阶段，并将在约10月份进行首个版本的发布。 +Cumulus 目前正处于紧锣密鼓的开发阶段，并将在约 10 月份进行首个版本的发布。 ## ink! diff --git a/website/translated_docs/zh-CN/build-examples-index.md b/polkadot-wiki/translated_docs/zh-CN/build-examples-index.md similarity index 100% rename from website/translated_docs/zh-CN/build-examples-index.md rename to polkadot-wiki/translated_docs/zh-CN/build-examples-index.md diff --git a/polkadot-wiki/translated_docs/zh-CN/build-exchange-integration.md b/polkadot-wiki/translated_docs/zh-CN/build-exchange-integration.md new file mode 100644 index 000000000000..b02b599c5321 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-exchange-integration.md @@ -0,0 +1,276 @@ +--- +id: build-wallet-integration +title: Wallet integration +sidebar_label: Wallet integration +--- + +``` ++--------------------+ +| | +| Substrate/Polkadot | +| | ++---------+----------+ + | + | + +--------+---------+ + | | + | Client interface | + | | + | +--------------+ | + | | Client DB | | + | +--------------+ | + | | + +--------+---------+ + | + | + +--------+---------+ + | | + | Wallet backend | + | | + +------------------+ +``` + +## 1. 追踪链头 + +通过监察 `chain_subscribeFinalizedHeads` RPC (或轮询 `chain_getFinalizedHead` RPC 跟踪每个确认了的区块。 + +这将会提供一列最新确认了的区块头。 + +当新哈希到达，你可以使用 `chain_getBlock` 把该哈希变成区块。 + +如果新区块不是您处理的最后区块的直接子代，确保迭代它们之间的所有区块。因为 `chain_getBlock` 只接受哈希，所以你需要使用 ` chain_getBlockHash` 把那些数字转换成哈希并以这种方式在任意两个最终区块之间迭代。 + +## 2. 解码区块 + +您需要将基本数据的区块解码为有用的字段。 + +所有区块数据是使用基本 SCALE 编码数据，详细资料[在此](https://substrate.dev/docs/en/overview/low-level-data-format)。但是 SCALE 仅提供底层格式，它的字段和内部结构的详细信息可能会在不同链甚至在同一链不同区块之间改变。 + +对于 Polkadot 一开始，区块头格式为五字段结构： + +``` +struct Block: + parent_hash: Hash + number: Compact Number + state_root: Hash + extrinsics_root: Hash + digest: Vec + extrinsics: Vec +``` + +这依赖于 `Hash`，固定长度的 32 字节值或在 SCALE `[u8; 32]`。它还依赖`DigestItem` (枚举类型): + +``` +enum DigestItem: + ChangesTrieRoot: Hash + PreRuntime: ConsensusItem + Consensus: ConsensusItem + Seal: ConsensusItem + Other: Vec +struct ConsensusItem: + id: [u8; 4] + data: Vec +``` + +它还依赖于 `外部交易(Extrinsic)`。*外部交易*是概括了一般和其他(未签名)外部信息的交易。它是种高度可扩展的类型，本身没有固定格式。为了确保将来格式的兼容性，可以通过 RPC `state_getMetadata` 提供外部有关格式的元数据。 + +元数据本身以 SCALE 编码提供，其格式为： + +``` +struct Metadata: + magic: u32 + version: u8 + modules: Vec +struct Module: + name: String + prefix: String + storage: Option Vec + calls: Option Vec + events: Option Vec + constants: Vec +enum StorageHasher: + Blake2_128 + Blake2_256 + Twox128 + Twox256 + Twox64Concat +struct Constant: + name: String + type: Type + value: Vec + documentation: Vec +struct Storage: + name: String + modifier: StorageModifier + type: StorageType + default: Vec + documentation: Vec +enum StorageModifier: + Optional + Default +enum StorageType: + Plain: Type + Map: StorageMapType + DoubleMap: StorageDoubleMapType +struct StorageMapType: + hasher: StorageHasher + key: Type + value: Type + iterable: bool +struct StorageDoubleMapType: + hasher: StorageHasher + first_key: Type + second_key: Type + value: Type + iterable: bool +struct Call: + name: String + arguments: Vec + documentation: Vec +struct CallArg: + name: String + type: Type +struct Event: + name: String + arguments: Vec + documentation: Vec +``` + +`Type`只是`String`，但是字符串的内容将被解释为类型的名称。 + +Substrate 链(实际上 Substrte 链是使用 SRML 构建) 例如 Polkadot 是由不同*模块*组成。每个模块可以想象有点像智能合，有各种交易(或 Substrate 术语，_外部交易_)，数据会持续在交易和区块, 事件和常量参数之间。元数据对所有东西进行编码，允许客户端代码创建特定的交易或解释链上发生了什么，甚至在不同的 Substrate 链之间或同一链不同升级或分叉之间。 + +There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. + +## 3. 处理 SS58 和帐户地址 + +在 Polkadot (和大多数 Substrate 链)中，用户帐户由 32 字节(256 位)的 AccountId 识别。这只是 Substrate 使用的 x25519 加密的公钥。 + +但是为了使地址细小，我们为 Polkadot 上余额大于零的帐户编制索引，并仅使用此*索引*来标识该帐户。该索引比 32 字节长的 _AccountId_ 细小多个，通常仅用几个字节进行编码 。 + +Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. + +SS58 格式是版本前缀(对于 Polkadot 为一个字节，并总是为`0x00`，而 Kusama 为`0x02`)的 base-58 编码(使用与比特币相同的字母)，后跟一个或多个有效载荷字节，并以一个或多个校验字节结尾: + +`0x00 ` + +**地址的长度没有固定长度。**根据长度，有效负载可能具有不同的含义，并且有效负载与校验和字节的比率可能不同。下面是一个表，用于参考如何解释特定大小的地址: + +| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | +| ----------- | ------------- | ------------- | -------------- | ------------ | +| 3 | 1 | 1 | 1 | Index | +| 4 | 1 | 2 | 1 | Index | +| 6 | 1 | 4 | 1 | Index | +| 35 | 1 | 32 | 2 | AccountId | + +注意: 此表仅包含最常见的组合。SS58 包括几个更不常见的。为了达到最大的兼容性，然后根据完整的 SS58 规范实现。 + +一旦解码为字段，则应检查版本为`0x00`。然后应验证 checksum 是否等于 SS58 数据的 Blake2-256 哈希的开头，不包括 checksum 本身。如果 checksum 是一个字节，则检查哈希的第一个字节。如果是两个字节，则检查哈希的前两个字节。 + +最后在使用索引地址的情况下，索引应解码为 32 字节的帐户标识符。这可以通过检查 Indices 模块的存储来实现。 + +### 查找索引 + +查找索引有点麻烦，因为涉及查找存储，解码和解释。 + +我们关心的特定存储是`Indices`模块中的`EnumSet`。通过`state_getStorage` RPC 检查存储，必须向其提供密钥。该键对整个"查询"进行编码。通常应咨询元数据如何生成密钥。为此我们首先找到名称为`Indices`的` 模块`，然后在` Storage 模块中` `storage `字段中找到，名称为`EnumSet`。此项包含我们构造和解释查询所需的所有信息。 + +对于 Polkadot 我们发现该项目的`type`为`Map`，其关联值为`StorageMapType`，其`hasher`为 `Blake2_256`，其`key`是`T:: AccountIndex`(对于 Polkadot 来说是`u32`)，并且其`value`为`Vec `。 + +这意味着如果我们的索引由 SCALE 编码为`u32`为``，那么我们的存储键是通过字符串`Indices EnumSet `的 Blake2 256 哈希确定。 实际上帐户是按 64 个批次存储的，因此要查找特定的索引，我们不按帐户索引查询，而是按其批次的索引查询，这只是意味着我们首先需要在编码之前将索引除以 64。 + +这会返回 SCALE-encoded `Vec` (`T::AccountId` 可能在 SCALE 定义为 `[u8; 32]` 或固定 32 字节数量) 包含我们感兴趣帐户的批次。要获取`AccountId`项，只需从向量中获取第`index％64`项。如果该项目不存在（或您得到一个空的存储)，则帐户索引无效。 + +否则您将拥有您的帐户 ID，并且可以将其及其标识和显示余额给用户。 + +## 4. 处理余额 + +在 Polkadot 中，帳戶结余可以在`Balances`模块内使用元数据的方式查找帐户索引查询被锁上的结余。在这种情况下我们需要查询存储中的`FreeBalance`。这里`StorageMapType`很相似，不同之处在于`key`的类型为`T::AccountId`(32 字节)和`value`是`BalanceOf`，就 Polkadot 而言，它是`u128`(128 位值)。哈希函数与 Blake2 256 相同，因此完整的存储密钥将由字符串`Balances FreeBalance`的 Blake2 256 哈希给出，其中``是 32 字节的`AccountId`。 + +注意: `FreeBalance`是该帐户控制的总余额，但没有考虑暂时锁定的部分，例如抵押中，投票或归属而锁定的部分。这些信息可以从链中查询，但不在本文档的范围之内。 + +DOT 代币结余将编码为 12 个数位。要获得 DOT 的实际数量，您需要将 128 位余额除以 1,000,000,000,000(10 \*\* 12)。 为了完整起见，Polkadot 的货币面额为: + +| 余额值 | 名称 | +| ------ | --------- | +| | | +| 1 | Planck 10 | + +**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10\*\*15 | Blob + +### 转移余额 + +要转移余额，必须准备和发送交易。在准备交易时，有两个关键部分: 一般交易部分和模块特定的交易`功能`部分通常需要来自链元数据的信息。 + +通常 Polkadot 的交易在 SCALE 中编码为 _signed_`Extrinsics`。为了便于之后兼容，外在进行双编码，因此初始编码将传回 SCALE（作为`Vec`）并输出使用的。这样做的效果是向它添加一个小长度前缀，使无法解释事务数据本身的系统仍然能够将它们传递为不透明的数据包。 + +The SCALE format is given by `Extrinsic`: + +``` +struct Extrinsic: + tx: Option TransactionInfo + function: Function +struct TransactionInfo: + sender: Address + sig: [u8; 64] + era: Era + nonce: Compact Nonce + tip: Compact Balance +struct TransactionPayload: + function: Function + era: Era + nonce: Nonce + tip: Balance + checkpoint_hash: Hash +``` + +对于交易，使用可选的`tx`。`Address`类型是经过特殊编码的 SCALE 类型，允许将帐户显示为帐户索引或 32 字节帐户 ID，以较方便的方式显示。格式在 SCALE [TODO] 中进行了说明。假设您希望提供一个 32 字节的帐户 ID，则只需在`0xff`字节前面添加前缀，就可以将其表示为`Address`。 + +`sig`字段必须包含 SCALE 编码的`SigPayload`的 25519 系列签名。 用于对负载进行签名的密钥必须与`sender`帐户相对应。 建议使用 Schnorr / Ristretto 25519("sr25519")签名格式。 + +Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. + +随机数到目前为止，由发送人帐户发送的交易数量，就像在以太坊中一样。 它是`Nonce`类型，在逻辑上等效于`u64`。 为了获得正确的值，必须查询适当的存储，就像查询帐户余额时一样。 在这种情况下，它是`System`模块的`AccountNonce`。 因此所需的存储密钥是字符串` System AccountNonce`的 Blake2 256 哈希，其中``是 32 字节的`AccountId`。 它将返回一个`Nonce`，可以在此处对其进行解码和使用。 + +注意: 从存储中检索的 nonce 没考虑*待处理*交易。如果您从一个帐户发送多个交易，则需要手动递增和跟踪此值。 + +`tip`是`Balance`(在逻辑上等同于 SCALE 中的`u128`类型)，它表示在繁忙的时候，为优先包含创建区块者支付一些额外费用。通常为零。 + +`checkpoint_hash`是 "区块检查点"的哈希，也就是说`era`字段指定的纪元的第一个区块。 如果只是使交易"immortal"，则应使用区块链的创始哈希。 这可以通过 RPC ` chain_getBlockHash(0)`确定。 + +最后 `function`是`Function`类型(在某些情况下有时称为`Call`或`Proposal`)，它描述了应该采取什么行动。它必须根据元数据构造。 在这种情况下，我们希望交易在`Balances`模块中实现`transfer`功能，以将余额从一个帐户转移到另一个帐户。 在模块列表中检查余额模块本身的索引很重要。 在这种情况下，它是第六项或索引 5。还需要检查元数据中余额`Module`的`calls`字段，并确定其中的索引转移功能。它在列表中排在第一位，因此索引为 0。 + +最后我们需要知道该函数需要哪些参数才能创建其余的交易。这在我们刚刚找到的元数据的`Call`项中提供。预期有两个参数： + +- `dest` with a type of `::Source` (aka `Address`); and +- `value` with a type of `Compact` (aka `Compact Balance`). + +在这种情况下 `函数` \* \* (即专门针对并且仅适用于 Polkadot 上的余额转帐交易) 将是以下结构： + +``` +struct BalanceTransferFunction: + module_index: u8 + call_index: u8 + dest: Address + value: Compact Balance +``` + +其中`module_index`是`0x05`，而`call_index`是`0x00`。`dest`与`sender`类似，可以作为帐户索引或 32 字节帐户 ID 提供，以较方便为准。如果提供帐户 ID，则只需在其前面加上字节`0xff`即可将其成为地址。 + +转帐的金额(不包括付给系统的任何费用)由`value`给出，并且必须是 SCALE compact 编码的数字。 + +### 提交和检查交易 + +一旦交易准备好，您将需要将其提交以包含在链中，并最终想要验证它是否真的包含在链中。 + +可以通过两种方式完成: 一种是使用简单 RPC `author_submitExtrinsic`，它将回传交易的哈希值。 提交后您可以继续手动检查交易是否在已确认的区块内(因为您都已经跟踪已确认的区块头)，直到看到您提交的交易为止，此时您知道交易已在链中。 + +另一种方法是使用 pub/sub RPC `author_submitAndWatchExtrinsic`。您同样提供 SCALE 编码的交易，但是在这里您会收到 subscription ID。 当交易被验证，广播并通过单独推送的消息包含在链中时，将通过 RPC 通知您。 + +## 总结 + +文章到此结束。在这里，您应该知道如何与 Substrate/Polkadot 节点进行交互，以便跟踪最终确定的链头、解码 SS58 地址、检查账户信息(如 balances & nonces) 以及构建、提交和跟踪交易。您还了解了 SCALE 编码器、Substrate 元数据系统以及如何构建面向未来的通用 Substrate 系统。 + +如果你有任何问题，请在 [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org) 问。 + +_最初版本发布在[此处](https://hackmd.io/@gavwood/r1jTRX2Zr)。_ diff --git a/polkadot-wiki/translated_docs/zh-CN/build-extrinsic-format.md b/polkadot-wiki/translated_docs/zh-CN/build-extrinsic-format.md new file mode 100644 index 000000000000..a608461fe4a3 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-extrinsic-format.md @@ -0,0 +1,44 @@ +--- +id: build-extrinsic-format +title: Polkadot Extrinsic Format aka Transaction Format +sidebar_label: Polkadot Extrinsic Format aka Transaction Format +--- + +## 原格式 + +**原外部函数格**式可参考如下： + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] +``` + +## 现格式 + +Polkadot 外部函数格式是： + +``` +[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] +``` + +*original*部分指的是原外部函数格式中的下面部分内容： + +``` +[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] +``` + +新地址类型的特定格式是 5 种子格式中的一种，第一个字节不同。 + +- `0xff, 32-byte account id` +- `0xfe, 8-byte account index` +- `0xfd, 4-byte account index` +- `0xfc, 2-byte account index` +- `[0xf0...0xfb] (invalid, reserved for future use)` +- `[0x00...0xef] 1-byte account index (less than 0xf0)` + +帐户索引变量要小得多，但需要在状态下查找。若要避免索引更改帐户时的交易重播攻击，签名的时候不应以第一个字段作为索引，而应以第一个字段作为帐户 ID。因此，一旦索引用于查找不同的 ID，就会使以前的所有签名失效。 + +包括发送器字段在内，所有在旧格式中表示账户 ID（32 字节）的调用/提议（私下调用）字段的参数现在都是地址（1/3/5/9/33 字节）。 + +## 来源 + +[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/polkadot-wiki/translated_docs/zh-CN/build-hackathon.md b/polkadot-wiki/translated_docs/zh-CN/build-hackathon.md new file mode 100644 index 000000000000..6fbc0da160fa --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-hackathon.md @@ -0,0 +1,63 @@ +--- +id: build-hackathon +title: 黑客马拉松 +sidebar_label: 黑客马拉松 +--- + +As one of our objectives in the Web3 Foundation is promoting the [Web3 technology stack](http://wiki.web3.foundation/en/latest/tech_stack/tech_stack_overview/), we would like to support any individual or team who wants to organize a hackathon that gets more developers to understand Polkadot and Substrate in your city or online. + +我们不仅为您提供技术资源，而且还可以安排我们团队的人来做具体的技术工作坊和讲解介绍我们的技术，从而帮助参与者可以更快地开始 hacking。 + +## 一些想法 + +- NFT +- Bonded Tokens +- 具有不同類型投票 & 民主機制的新治理模块 +- 升级 TCR 模块 +- 整合 IPFS +- 分布式身份认证方案 +- 预言机模块 +- 实现通用状态通道 / Plasma 链 +- 去中心化交易所 +- 验证人监视工具 +- 跨不同平行链的 dApp + +## 为什么要举办黑客马拉松？ + +- 热爱实现 Web3 的愿景 +- 学习前沿技术 +- 相信 Web3 技术栈适合开发人员构建他们的应用程序 +- 喜欢建立联系 + +## 黑客马拉松与研讨会有何不同？ + +黑客马拉松是希望参与者在短时间内（几小时到一天）实现出原型并展示他们的想法。研讨会的目的是使开发人员熟悉该工具，并了解更多当前有哪些资源可用以及如何使用它们。 + +## 如何在您的城市里举办黑客马拉松？ + +1. 提交您的申请（即将到来） +2. 评论 +3. 决定 +4. 跟进 + +## 我们如何为您提供协助 + +- 提供技术资源 / 材料。 +- 找场地。 +- 确保黑客马拉松顺利举行 + +## Upcoming Hackathons + +- [Hello World! by Polkadot](https://gitcoin.co/hackathon/polkadot/onboard) - A collaborative hackathon celebrating the integration of Polkadot and Kusama into the Gitcoin platform. Has many sets of smaller challenges that will reward in either DOT or KSM. Open from 15 October - 12 November 2020. + +## Past Hackathons + +- [Hackusama](https://hackusama.devpost.com/) - A 7-week online hackathon being launched for developers to "Build a Blockchain" or submit your wildest tools, visualizations, and ideas to the "Open Hack" category. Many high quality submissions were received. + +## 资源 + +- [Substrate Knowledge Base](https://substrate.dev/docs/en/) + +## 支持 / 联系 + +If you have any questions regarding organizing a hackathon, please free feel to contact us by [email](mailto:events@web3.foundation) or ask us via [Riot](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org) chat. diff --git a/polkadot-wiki/translated_docs/zh-CN/build-index.md b/polkadot-wiki/translated_docs/zh-CN/build-index.md new file mode 100644 index 000000000000..8f2ce03663eb --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-index.md @@ -0,0 +1,51 @@ +--- +id: build-index +title: 开发者专页 +sidebar_label: 开发者专页 +--- + +欢迎访问 Polkadot 维基网站的构建者部份。 + +Here you will be able to find the most up-to-date information on the status of the development tools in the Polkadot ecosystem. We are always adding new tools and frameworks as we learn about them so if you are working on something that should be included please reach out to us on [Element](https://app.element.io/#/room/#polkadot-watercooler:matrix.org). + +Wiki 的这个部分分为以下: + +## 主页 + +- [入门指南](build-build-with-polkadot) - 有关您的项目应选择平行链，平行线程或智能合约的高级概述，以及现在有哪些资源可以使用。 +- [Parachain Development Kits](build-pdk) - PDKs are toolkits for building parachains and parathreads. +- [Smart Contracts](build-smart-contracts) - Smart contracts are fragments of custom logic that can be deployed to a live chain. + +## 集成指南 + +本部分适用于希望学习如何将 Polkadot 集成到其系统中的服务提供商，例如钱包或节点运营商。 + +- [Integration Initiation](build-integration) - The guide to the guide. +- [Polkadot Protocol Information](build-protocol-info) - General information and F.A.Q.s about the Polkadot protocol, e.g. address formats. +- [Node Management](build-node-management) - A short overview of the Parity Polkadot client and the most relevant options/flags for infrastructure providers. +- [Node Interaction](build-node-interaction) - Learn how to interact with your node via RPC. +- [Transaction Construction and Signing](build-transaction-construction) - Learn the transaction format for Polkadot and how to construct and sign transactions offline. + +## 工具 + +- [工具](build-tools-index)-维护的工具。 +- [Subkey](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) - Command line utility for generating and inspecting key pairs. +- [JS tools](https://github.com/polkadot-js/tools) - TypeScript tools for offline signing of transactions, RPC calls, and more. + +## 资源 + +- [例子](build-examples-index) - 来自社区的项目 - 查看其他人开发中的项目. + +### Grants + +- [Grants](grants) - Web3 基金会提供赠款的所有 Polkadot 相关的项目列表。 + +### PSPs + +Polkadot 标准建议 (PSP) 是 Polkadot 生态系统的标准。 + +- [ PSP GitHub 库](https://github.com/w3f/PSPs)-阅读，创建或讨论标准和提案。 + +### 黑客马拉松 + +- [举办骇客松的资源](build-hackathon) diff --git a/website/translated_docs/zh-CN/build-integration.md b/polkadot-wiki/translated_docs/zh-CN/build-integration.md similarity index 100% rename from website/translated_docs/zh-CN/build-integration.md rename to polkadot-wiki/translated_docs/zh-CN/build-integration.md diff --git a/polkadot-wiki/translated_docs/zh-CN/build-networks.md b/polkadot-wiki/translated_docs/zh-CN/build-networks.md new file mode 100644 index 000000000000..aacd3ff61097 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-networks.md @@ -0,0 +1,71 @@ +--- +id: build-networks +title: Networks +sidebar_label: Networks +--- + +您可以通过下面的代码来连接到不同网络。 + +## 开发 + +在以下 `路径` 安装 `Polkadot` 和 Polkadot 二进制文件： + +```bash +cargo install --git https://github.com/paritytech/polkadot.git polkadot +``` + +通过在终端上运行，您可以在机器上跑简单的单节点开发网络： + +```bash +polkadot --dev +``` + +您可以复制和创建以下网站： + +## Krumme Lanke + +http://github.com/paritytech/polka-ui 和 http://github.com/paritytech/polkadot-ui or 或前往到 https://polkadot.js.org/apps. + +Krumme Lanke 是一个在 Poc-2 开发期间使用的测试网络。请在以下路径安装 Polkadot PoC-2 和 `Polkadot 二进制` 文件： + +```bash +cargo install --git https://github.com/paritytech/substrate.git --branch v0.2 polkadot +``` + +通过默认运行以下代码连接到全球 "Krumme Lanke" 测试网： + +```bash +polkadot +``` + +## Alexander（Poc-4） + +Alexander 是一个在 PoC-3 和 PoC-4 开发期间使用的测试网络。 + +请在以下 `路径` 安装 Polkadot Poc-4 和 `polkadot` 二进制文件： + +```bash +cargo install --git https://github.com/paritytech/polkadot.git --branch v0.4 polkadot +``` + +通过默认运行以下代码来连接到全球 "Alexander 测试网:" + +```bash +Polkadot +``` + +## 本地双节点测试网 + +如果您想要在本地看到多节点共识算法操作，那么您可以创建一个本地测试网。您需要开两个终端，其中一个运行以下代码： + +```bash +polkadot --chain=local --validator --key Alice -d /tmp/alice +``` + +另一个运行以下代码： + +```bash +polkadot --chain=local --validator --key Bob -d /tmp/bob --port 30334 --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE' +``` + +请确保将第一个终端的输出结果中的节点 ID 替换为`ALICE_BOOTNODE_ID_HERE` 。 diff --git a/website/translated_docs/zh-CN/build-node-interaction.md b/polkadot-wiki/translated_docs/zh-CN/build-node-interaction.md similarity index 100% rename from website/translated_docs/zh-CN/build-node-interaction.md rename to polkadot-wiki/translated_docs/zh-CN/build-node-interaction.md diff --git a/website/translated_docs/zh-CN/build-node-management.md b/polkadot-wiki/translated_docs/zh-CN/build-node-management.md similarity index 100% rename from website/translated_docs/zh-CN/build-node-management.md rename to polkadot-wiki/translated_docs/zh-CN/build-node-management.md diff --git a/website/translated_docs/zh-CN/build-oracle.md b/polkadot-wiki/translated_docs/zh-CN/build-oracle.md similarity index 100% rename from website/translated_docs/zh-CN/build-oracle.md rename to polkadot-wiki/translated_docs/zh-CN/build-oracle.md diff --git a/website/translated_docs/zh-CN/build-parachains-rococo.md b/polkadot-wiki/translated_docs/zh-CN/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/zh-CN/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/zh-CN/build-parachains-rococo.md diff --git a/polkadot-wiki/translated_docs/zh-CN/build-pdk.md b/polkadot-wiki/translated_docs/zh-CN/build-pdk.md new file mode 100644 index 000000000000..16b0e6c98a7d --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-pdk.md @@ -0,0 +1,43 @@ +--- +id: build-pdk +title: 平行链开发套件 (PDKs) +sidebar_label: 平行链开发套件 (PDKs) +--- + +平行链开发工具包(PDK)是一套便于开发者创建兼容[ Polkadot ](learn-parachains)平行链的工具。 + +## 为什么要创建平行链？ + +在深入了解什么是 PDK 以及它如何使用之前，让我们回顾一下*为什么*开发者希望创建平行链并将其连接到 Polkadot 中。 + +平行链拥有两个关键的附加功能，是开发者创建独立链的不二选择： + +- _共享安全性_ - 去除了自举链的验证人集的必要性。 +- _跨链通信_ - 使得平行链之间通过 ICMP 协议交互操作。 + +Parachains can [lease the security](learn-security) of the Polkadot network by bonding [DOT](learn-DOT) for a parachain slot. This means that the social costs of building a community around your project and convincing validators to participate in your network security are reduced. It is anticipated that Polkadot will have strong security, and decentralized application projects wishing to benefit from this security would want to become a parachain. For more information on the mechanic of leasing a parachain slot through a candle auction see [here](learn-auction). + +所有去中心化的应用程序或链，若想要向其它已连接到 Polkadot 的平行链去信任地传递信息，都会希望成为平行链。主权链之间的互操作性需借助约束和复杂的协议才可广泛实现。在 Polkadot 中，一旦将应用程序构建为平行链，便会立即获得这一特性。[XCMP 协议](learn-crosschain)将传递平行链之间的信息，实现其互操作性。此外，连接其它链的转接桥(例如比特币或以太坊)纷纷推出，平行链也可以与它们进行交互。 + +## 什么是 PDK？ + +如上所述，PDK 是一套便于开发者创建兼容 Polkadot 的平行链的工具。实际上，这意味着 PDK 将包含以下几个关键成分： + +- _状态转变函数(State transition function)_ - 把你应用程序数据状态状变成另一个状态。 +- _收集人节点 (Collator node)_ - Polkadot 网络的另一类点对点节点，专门负责平行链。 + +The state transition function (STF) can be any abstract way for an application to go from one state to another state. The only constraint that Polkadot places on this STF is that it must be easily verifiable -- usually though what we call a _witness_ or _proof_. It must be so because the Relay Chain validators will need to check that each state it receives from the collator node is correct without actually running through the entire computation. Some examples of these proofs include the Proof-of-Validity blocks or zk-SNARKs, which require less computational resources to verify than they do to generate. The verification asymmetry in proof generation of the STF is one of the integral insights that allows Polkadot to scale while keeping high security guarantees. + +A collator node is one of the types of network maintainers in the Polkadot protocol. They are responsible for **keeping availability** of the state of the parachain and the new states returned from iteration of the state transition function. They must remain online in order to keep track of the state and also of the XCMP messages that it will route between itself and other parachains. Collator nodes are responsible for passing the succinct proofs to the Relay Chain validators, and tracking the latest blocks from the Relay Chain. In essence, a collator node also acts as a light client for the Polkadot Relay Chain. For more on collator nodes see [here](learn-collator). + +## 目前存在哪些 PDK？ + +目前唯一存在的 PDK 是 Parity [Substrate](https://github.com/paritytech/substrate) & [Cumulus](https://github.com/paritytech/cumulus)。Substrate 作为区块链框架，提供了区块链的基本构建区块（例如网络层、共识和 Wasm 解释器），以及创建运行时的直观方法。Substrate 旨在简化创建新链，但它并不直接支持 Polkadot 兼容性。因此 Cumulus 附加库将包含所有 Polkadot 兼容性代码。Cumulus 目前还在开发之中，计划做到只通过导入 crates 以及添加一行代码便把你的 Substrate 链变成平行链。 + +Substrate 和 Cumulus 通过区块链格式的抽象化中提供 PDK，但平行链实际上甚至不必是区块链。例如平行链只需满足上文列出的两个要求：*状态转换函数*和*收集人节点*。其它一切功能取决于 PDK 的实现者。 + +One interesting idea for a PDK that would be nice to see is to have a [roll-up](https://ethresear.ch/t/roll-up-roll-back-snark-side-chain-17000-tps/3675) kit that allowed developers to create snark-based parachains. If we review the roll-up write-up, we see that the system uses two roles: users that update **state** and an operator that **aggregates the state updates** into a single on-chain update. It should be straightforward to see how we can translate this to the parachain terms. The state transition function for a roll-up-like parachain would be updating the state (in practice, most likely a merkle tree, which would be easily verifiable) from the user inputs. The operator would act as the collator node, which would aggregate the state and create the zk-SNARK proof that it would hand to the Relay Chain validators for verification. + +## 创建 PDK + +如果您或您的团队对开发 PDK 感兴趣，请随时在 [W3F 合作库](https://github.com/w3f/Web3-collaboration) 上创建 issue。 Web3 基金会可以为这类工作提供资助。 diff --git a/polkadot-wiki/translated_docs/zh-CN/build-protocol-info.md b/polkadot-wiki/translated_docs/zh-CN/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/polkadot-wiki/translated_docs/zh-CN/build-rust-style-guide.md b/polkadot-wiki/translated_docs/zh-CN/build-rust-style-guide.md new file mode 100644 index 000000000000..13df1dc61da7 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-rust-style-guide.md @@ -0,0 +1,114 @@ +--- +id: build-rust-style-guide +title: Style Guide for Rust in Polkadot +sidebar_label: Style Guide for Rust in Polkadot +--- + +- 使用制表符缩进 +- 只有在特殊情况下，每行才应该超过 80 个字符但当然不能超过 120 个。为此，制表符应为 4 个字符宽度。 +- 只有在特殊情况下，缩排格数才应该大于 5，但当然不能大于 8。大于 5 时，可以考虑使用 let 或辅助函数来删除复杂的内联表达式。 +- 切勿在非空格字符之前的行中输入空格 +- 下一行与原始行之间只有一个缩进。 + +```rust +fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -bool { + let x = some_long_variable_a * some_long_variable_b + - some_long_variable_b / some_long_variable_a + + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); + x 10 +} +``` + +- 应在左括号后输入缩进格数，但应折叠为实际使用的最小格数： + +```rust +fn calculate( + some_long_variable_a: f32, + some_long_variable_b: f32, + some_long_variable_c: f32, +) -f32 { + (-some_long_variable_b + sqrt( + // 这里有两个左括号，但因为我们把对应的两个右括号放在同一行，所以只需要缩进一级 + some_long_variable_b * some_long_variable_b + - 4 * some_long_variable_a * some_long_variable_c + // 两个括号都在这里结束了，所以回到最初的缩进级别 + )) / (2 * some_long_variable_a) +} +``` + +- `where`及其项需 +- 过长的参数列表或函数调用无法在一行中使用，需缩进为与代码区块类似。一旦某参数被以这种方式缩进，那么其它所有参数都应该进行相同操作。此外，运行参数列表也适用于基础函数调用的单行运行。 + +```rust +// OK +fn foo( + really_long_parameter_name_1: SomeLongTypeName, + really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, + shrt_nm_2: u8, +) { + ... +} + +// NOT OK +fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, + shrt_nm_1: u8, shrt_nm_2: u8) { + ... +} + +``` + +```rust +{ + // 符合语句（不仅有函数调用，还有一个let声明），采用完整结构 + let (a, b) = bar( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // 很长，但仅是函数调用 + waz( + really_long_parameter_name_1, + really_long_parameter_name_2, + shrt_nm_1, + shrt_nm_2, + ); + + // 短的函数调用 + baz(a, b); +} +``` + +- 合理情况下，逗号分隔的多行集合永远以“ ,”结尾： + +```rust +struct Point | subkey sign diff --git a/polkadot-wiki/translated_docs/zh-CN/build-transaction-construction.md b/polkadot-wiki/translated_docs/zh-CN/build-transaction-construction.md new file mode 100644 index 000000000000..64cade6b1e38 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: 交易创建和签名 +sidebar_label: 交易创建 +--- + +這页将讨论 Polkadot 的交易格式以及如何创建、签名和提交交易。 与其它教程的页面一样，这一页展示了一些可用的工具。 **在整合时请前往每个工具的文档。** + +## 交易格式 + +Polkadot 有一些所有交易的基本交易信息。 + +- 地址(Address)：发送帐户的 SS58 编码地址。 +- 区块哈希(Block Hash)： [检查站](build-protocol-info#transaction-mortality) 区块。 +- 区块编号(Block Number)：检查站区块的数量。 +- 创世纪哈希 (Genesis Hash)：链的创世纪哈希。 +- 元数据 (Metadata)：提交 runtime 的 SCALE 编码元数据。 +- Nonce：此交易的 nonce。 +- Spec 版本：当前 runtime 的 spec 版本。 +- 交易版本：交易格式的当前版本。 +- 提示：提高交易优先级的[提示](build-protocol-info#fees)(可选项)。 +- Era 阶段：检查站之后的有效交易的块数(可选项)。如果为零，则该交易[存续](build-protocol-info#transaction-mortality)。 + +从系统模块中查询的 nonce 不会考虑待处理的交易。如果您想要同时提交多个有效的交易，您必须跟踪并手动递增 nonce。 + +每个交易都有自己(与否)的参数添加。例如来自 Balances pallet 的 `transferKeepAlive`函数将需要： + +- `dest`: 目标地址 +- `#[compact] value`: 代币数量 + +一旦您有了必要的资料，您需要: + +1. 创建未签名的交易 +1. 创建签名的 payload。 +1. payload 签名。 +1. 将已签名的 payload 序列化为交易。 +1. 提交序列化的交易。 + +Parity 提供了以下工具来帮助执行这些步骤。 + +## Polkadot-JS 工具 + +[Polkadot-JS 工具](https://github.com/polkadot-js/tools)包含一组用于与 Substrate 客户端进行交互的命令行工具，包括一个用于创建，签名和广播交易的名为“ Signer CLI”的工具。 + +本示例将使用`signer submit`命令，该命令将创建并提交交易。 `signer sendOffline`命令具有完全相同的 API，但不会广播交易。 `submit`和`sendOffline`必须连接到节点以获取当前元数据并构造一个有效交易。他们的 API 具有以下格式： + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +签名: + +```bash +yarn run:signer sign --account --seed --type +``` + +例如我们从 `121X5bEgTZcGQx5NZjwuTjqkoiG8B2wEAvrUFjuw24ZGZf2` 发送 0.5 DOT 到 `15vrtLsCQF3qRYUcaEeh4JwepolNJkpsrqojqnZPc2y` + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +这将返回 payload 签名和等待签名。 使用这个 payload 并使用 你的正常签名环境 (例如 airgapped 電腦、 VM 等) 签 payload： + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +保存输出并将其带到您要广播的电脑，输入 `submit`'s 签名字段并发送交易(或如果使用 `sendOffline`，则只是退回 serialized 的交易)。 + +## Tx Wrapper + +如果您不想使用 CLI 进行签名操作，Parity 提供了一个称为[TxWrapper](https://github.com/paritytech/txwrapper)的 SDK，它可以离线生成和签名交易。请参阅[示例](https://github.com/paritytech/txwrapper/tree/master/examples)以获取指南。 + +**导入私钥:** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**从公钥中获取地址** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**离线构建交易** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**构建签名的 payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**对已签名的交易做序列化** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**解析 payload 的类型** + +您可能需要对 payload 进行解码，以在提交之前验证其内容。 + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**检查一笔交易的哈希值** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## 提交已签名的 Payload + +有几种提交签名的 payload 的方法： + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc)和`author_submitExtrinsic`或者 `author_submitAndWatchExtrinsic`，后者将使您订阅事件，并在交易得到验证且上链时得到事件的通知。 + +## 注意 + +在示例中使用的一些地址，请参阅[Subkey 文档](https://substrate.dev/docs/en/knowledgebase/integrate/subkey)。 + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/zh-CN/build-wallets.md b/polkadot-wiki/translated_docs/zh-CN/build-wallets.md similarity index 100% rename from website/translated_docs/zh-CN/build-wallets.md rename to polkadot-wiki/translated_docs/zh-CN/build-wallets.md diff --git a/polkadot-wiki/translated_docs/zh-CN/claims.md b/polkadot-wiki/translated_docs/zh-CN/claims.md new file mode 100644 index 000000000000..086f05a24f60 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot 申领 +sidebar_label: 认领 +--- + +如果您在之前的销售中购买了 DOT，则需要通过以下程序认领 DOT 代币。对于那些已在较早创世块之前提交了认领交易到以太坊上的 Claims 合约，那么您应该已经知道您的 Polkadot 地址。您仍然需要提交一个不用交易费的 _attest_ 交易，该交易用于同意您的分配条款和条件。您必须首先声明或证明，之后 DOT 才能在您的帐户中使用。 + +本指南将带领您完成认领或证明声明的步骤。 + +如果您是首次认领 DOT，请阅读下面[认领](#making-a-claim)的部分继续。如果您在创世块之前已经认领，请前往[证明声明](#attesting-to-a-statement)部分。 + +> 了解更多如何认领您的 DOT，请查看我们的攻略 [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22)和视频 [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## 认领 + +如果您在创世块之前期间没有认领，那么您就可以在创世块后的任何时间认领。认领没有时间限制，因此任何时候您都可以这样做。 + +> 注意: 申领时，您还需验证您的 DOT 代币分配协议。申领及验证将在一个同交易里完成，从用户的角度来看，这已是极度简化的流程。 + +### 您将需要什么 + +- 持有 DOT 代币的以太坊账户 +- MyCrypto 钱包 +- Polkadot 帐户 + +您应该已经拥有以太坊账户，该账户持有 Polkadot 的 DOT 代币。 您需要访问该帐户才能进行签名。 + +[ MyCrypto ][] 是款多功能钱包，可为您的以太坊账户提供多种存储方式。请点击链接转到其下载页面，并确保您下载了适用于您操作系统的最新版本。 这很重要，因为最新版本将有最新的安全补丁程序。 + +> **注意**: 在本地下载和使用 MyCrypto 应用程序更加安全。 您可以在其[releases page][mycrypto]上找到桌面应用程序的最新版本。 + +您需要一个 Polkadot 帐户作为获取申领的 DOT 的账户。请根据\[创建账户\]\[\] 页面上的说明生成新的 Polkadot 帐户。 + +#### 使用 MyCrypto 认领您的 DOT + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +一旦下载了 MyCrypto 并使其在本地运行(为了获得最大的安全性，我们建议使用完全离线的电脑)，您可以先访问 Polkadot-JS Apps 上的 Claims 程序。选择您要申请认领 DOT 的帐户，然后点蓝色的 "Continue" 按钮继续。您的屏幕应如下图所示: + +![claim-1](assets/new-claims/claim-1.jpg) + +现在您将需要提供与您将认领 DOT 代币的以太坊地址。在框中输入以太坊地址，然后点击 "Continue"。 + +![claim-2](assets/new-claims/claim-2.jpg) + +接下来，屏幕应如下图所示。 + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +句子后面的十六进制编码字符串: "Pay DOTs to the Polkadot account:" 是您 Polkadot 帐户的十六进制编码公钥，去除 `0x` 前缀。 + +下一步是转到 MyCrypto 程序，然后点击 "Sign & Verify Message" 选项。 + +![claim-3](assets/new-claims/claim-3.png) + +这将提示您选择一种解锁钱包的方法。 + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +当您点击 "Sign Message" 时，您将获得类似于以下 JSON 的内容: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +将会出现一个绿色框，告诉您要认领的金额，并带有 "Claim" 按钮以提出认领。 点击 "Claim" 按钮，然后按 "Submit (no signature)" 以完成认领。 + +![claim-9](assets/new-claims/claim-9.jpg) + +若申领成功，那么您将看到提示成功的消息，同时您的 DOT 将会出现在您在申领时提交的账户中。 + +#### 确认您的认领 + +当您在链上申领 DOT 后，Polkadot UI 上应即时更新了您的余额。 + +遇到麻烦? 在 DOT [Claims Support]()渠道寻求帮助。 + +![claim-10](assets/new-claims/claim-10.jpg) + +恭喜，您现在已经完成了 DOT 申领及签名的流程。 + +### 第三方认领程序 + +**我们不建议使用其它第三方应用程序或流程来进行您 DOT 的申领或获取。** + +使用第三方程序进行申领可能会导致代币分配失败，因此我们不建议您使用任何第三方应用程序这样做。按照我们的申领流程，手动指定您的交易数据，是确保您将收到 DOT 代币的唯一方法。 + +## 证明声明 + +若您已经在创世块前提出申领，您仍然需要使用您的 Polkadot 帐户签署一份协议。 + +## 使用 Polkadot-JS App UI + +### 您将需要什么 + +- 您的 Polkadot 帐户已在 Polkadot-JS Apps UI 上解锁。 + +您将通过您的 Polkadot 帐户发起一次无交易费用的交易。完成交易后，您的代币将出现在您的账户中。 + +### 前往 Polkadot-JS 程序 + +继续使用 [polkadot-js Apps][claims app]。您需要授予应用程序对您账户的访问权限。一种方法是前往到 Accounts 页面并 "创建" 新帐户，将生成的种子或助记词替换为您的帐户的 seed 或助记词。另一种方法是使用 Polkadot-JS 扩展程序，然后在其输入您的 seed 或助记词，这通常比直接在程序页面中输入更安全。 + +### 提交证明 + +当输入帐户后，您应该会在左侧导航栏的 "Claim Tokens" 标签上看到红色的提示。 + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +点击 "Claims Tokens" 选项，您将在页面顶部看到一个大型通知，告诉您需要签署验证声明。 + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +该通知将显示您已在 Polkadot-JS 中加载并需要签名的多个 Polkadot 地址。使用下拉选择来选择已申领 Polkadot 的帐户。如果您没有看到或收到通知，请仔细检查该帐户是否已加载到 Polkadot-JS 中，并且在创世块前已经进行申领。与往常一样，请随时在 [Claims Support]() 中寻求帮助。 + +点击 "Continue"，您将看到右侧的绿弹框。 + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +点击 "I Agree"，然后点击 "Sign and Submit" 提交您无交易费用的验证交易。当交易打包入区块中后，您将看到绿色的成功弹框出现在右上角，同时 DOT 将出现在您的帐户中。 + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## 使用 Parity Signer + +### 您需要准备什么 + +- Parity Signer +- 已链接到 Polkadot-JS Apps UI 的 Polkadot 帐户 + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### 前往 Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### 提交验证声明 + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +点击右侧的“Add via Qr”。 + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +打开 Parity Signer 并选择 "Polkadot" 网络。 + +![ps-1](assets/new-claims/ps-01.jpg) + +选择你在创世块前申领 DOT 的地址。 + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +当二维码信息读取成功后，输入您的地址名称并点击“创建”。 + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[ mycrypto ]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/polkadot-wiki/translated_docs/zh-CN/community.md b/polkadot-wiki/translated_docs/zh-CN/community.md new file mode 100644 index 000000000000..f3d4f648e99d --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/community.md @@ -0,0 +1,80 @@ +--- +id: community +title: 社区 +sidebar_label: 社区 +--- + +Polkadot 社区每天都在壮大。以下是社区频道最重要的链接。请记住，没有任何管理员或主持人不会因任何原因在没有事先联系的情况下欺骗您，任何这样做的人都可能试图欺骗您。 + +## 一般 + +- [Polkadot GitHub](https://github.com/paritytech/polkadot/) - 由 Parity 负责管理和维护的 Rust 实现的 Polkadot 主机的代码库 +- [Polkadot Meetup Hub](https://www.notion.so/web3foundation/Polkadot-Meetup-Hub-4511c156770e4ba9936386d8be5fe5be) -关于主办聚会，申请资金的相关信息。 +- [Polkadot Support Knowledgebase](https://support.polkadot.network/support/home) 和 [ Polkadot Support Email](mailto:support@polkadot.network) +- [Polkadot 最新的研究](https://research.web3.foundation/en/latest/polkadot/) + +### 活动 + +Web3 基金会主办了许多线上和线下的活动。你可以通过[这个 Notion Page](https://www.notion.so/Public-Events-Database-fdd2df4c29d04818a5dd403e2b85920d)来查看我们之前和现在举办的活动。 + +## Matrix 聊天 + +我们整个组织中主要使用[Matrix](https://matrix.org)与社区成员进行沟通。我们最常与 Matrix 协议进行交互的应用程序是[Element](https://app.element.io)信使。 + +### Polkadot + +- [PolkadotWatercooler Chat](https://app.element.io/#/room/!FdCojkeGzZLSEoiecf:web3.foundation?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 一般性问题聊天室 +- [Polkadot Validator Lounge](https://app.element.io/#/room/#polkadot-validator-lounge:matrix.org) - 验证者可以在这里学习如何架设节点 +- [Polkadot Direction](https://app.element.io/#/room/!OwgojQyBzTlUQGGLhq:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 社区治理，以及探讨 Polkadot 未来方向的聊天室 +- [Polkadot 摘要](https://matrix.to/#/!vMpYyTkvjXcevxSdsQ:web3.foundation) - 有关 Polkadot 生态发生的事件新闻，每个工作日（节假日除外）发布 + +### Kusama + +- [Kusama Watercooler Chat](https://app.element.io/#/room/%23kusamawatercooler:polkadot.builders) - 关于 Kusama 的一般性问题聊天室 +- [Kusama Validator Lounge](https://app.element.io/#/room/!LhjZccBOqFNYKLdmbb:polkadot.builders?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - Kusama 的验证者可以在这里学习如何架设节点 +- [Kusama Direction](https://app.element.io/#/room/!QXMnIJzxlnVrvRzhUA:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 关于 Kusama 的社区治理，以及探讨 Kusama 未来方向的聊天室 + +### 技术 + +- [Substract Technical](https://app.element.io/#/room/#substrate-technical:matrix.org) - 关于 Substrate 的更深入的技术问题讨论聊天室 +- [Smart Contract & Parity Ink!](https://app.element.io/#/room/!tYUCYdSvSYPMjWNDDD:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 讨论基于 Parity Ink! 开发的 Substrate 智能合约的聊天室 + +## 媒体 + +### 聊天 + +- [Polkadot Discord](https://discord.gg/wGUDt2p) (推荐） +- [Kusama Discord](https://discord.gg/JSJcRwz8fp) + +### 社交媒体和论坛 + +- [Polkadot 推特](https://twitter.com/Polkadot) +- [Kusama 推特](https://twitter.com/kusamanetwork) +- [Web3 基金会推特](https://twitter.com/web3foundation) + +- [Polkadot Reddit](https://www.reddit.com/r/dot/) +- [Kusama Reddit](https://www.reddit.com/r/Kusama) + +- [Web3 基金会 YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) +- [Polkadot YouTube](https://www.youtube.com/channel/UCB7PbjuZLEba_znc7mEGNgw) +- [Kusama YouTube 频道](http://youtube.com/c/kusamanetwork) + +- [Polkadot 论坛](https://forum.polkadot.network) +- [Kusama 论坛](https://forum.kusama.network) + +### 博客和教程 + +- [Web3 Medium 博客](https://medium.com/@web3) +- [Polkadot 博客](https://polkadot.network/blog/) +- [Gavin Wood Medium 博客](https://medium.com/@gavofyork) +- [Dotleap.com 教程](https://dotleap.com) + +### 邮件公告 + +- [订阅 Polkadot 电子报](https://share.hsforms.com/1LL1CBwiASxC5pJUYZAiDVw4752a) - 在这里订阅我们的电子报。 +- [Dot Leap Newsletter](https://dotleap.substack.com/) - 非官方，每周。 + +## 生态 + +- [Polkadot 上的团队建设](https://polkaproject.com/) - 社区维护的团队列表建立在 Polkadot 和/或 Substrate 上。(请注意，这里可能有些不准确，因为它是非官方的) +- [Polkadot Stack](https://github.com/w3f/General-Grants-Program/blob/master/grants/polkadot_stack.md) - 如果你对正在进行的开发感兴趣，或是想要了解你可以怎样参与贡献。 diff --git a/polkadot-wiki/translated_docs/zh-CN/contributing.md b/polkadot-wiki/translated_docs/zh-CN/contributing.md new file mode 100644 index 000000000000..cc065512411f --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/contributing.md @@ -0,0 +1,45 @@ +--- +id: contributing +title: 参与贡献 +sidebar_label: 参与贡献 +--- + +The wiki was started and is maintained by the Web3 Foundation. It is an open source project and aims to be the most extensive resource of knowledge on Polkadot and the Polkadot ecosystem. A large part of the material currently focuses on Polkadot directly but it is not opposed to covering informational material for community projects. Please do not try to pull request any marketing material as this will be rejected. + +Pull requests, discussions, and contributions from the community are encouraged. Active community members who demonstrate a record of good contributions may be given write access to the repository. Otherwise, Web3 Foundation holds the administrative position and final say on the content that is included. Specifically the Technical Education team at the foundation are most directly involved. + +> There is video guide on how to contribute to the wiki [here](https://www.youtube.com/watch?v=6i55KOcy7B0). + +## 如何参与贡献 + +Contributing to the wiki is easy with a GitHub account. Every page is a MarkDown file, which is a [very easy to learn](https://guides.github.com/features/mastering-markdown/) syntax extension to plain text that makes creating links, rendering images, and nice-looking formatting simple. + +Each page has an "Edit" button in the top right corner of the content. By clicking this button you are taken to the GitHub sign in page, where you can either log in or create an account. + +![](assets/edit_button.png) + +Once logged in, you'll be taken to the GitHub text editor in which you can make your edits directly. When you've completed your changes, you can add any specific details on what was changed and commit to a new branch to create a new Pull Request to the repository. From there one of the maintainers will either merge it in or request changes very soon. + +![](assets/contributing.png) ![](assets/creating-pull-request.png) + +Remember that after you click "Propose Changes", you must also click on "Create Pull Request" on the next page. + +![](assets/creating-pull-request-2.png) + +## 规则 + +There are a few basic ground-rules for contributors: + +1. **没有`--force` pushes **或以任何方式修改 Git 历史记录。 +2. 对于某些问题，尤其是对于诸如错别字之类的较小更改，优先使用 Pull requests。 问题适用于一般或广泛的更改或内容缺少。 +3. Only use **non-master branches**. +4. **Significant modifications**, even by contributors, ought to be subject to a **pull request** to solicit feedback from other contributors. +5. 对于任何其不是非常重要的贡献，_鼓励_ Pull requests，但由贡献者自行决定。 +6. Contributors should attempt to adhere to the prevailing MarkDown style, language, and layout. +7. 应使用正确的语法。带有错别字的 Pull requests 的请求在修复之前不会合并。 +8. 应注意保持尽可能客观和有益的信息。不应故意编造 ，也不应存在外部偏见。 +9. We use a plugin called Prettier to standardize the style across documents. You can run this on your local copy with `npx run prettier --save`, but for simplicity we also have a bot which runs this for us in your PRs. + +## Heritage + +This document was based on the Level contribution guidelines located here: [https://github.com/Level/community/blob/master/CONTRIBUTING.md](https://github.com/Level/community/blob/master/CONTRIBUTING.md) diff --git a/website/translated_docs/zh-CN/contributors.md b/polkadot-wiki/translated_docs/zh-CN/contributors.md similarity index 100% rename from website/translated_docs/zh-CN/contributors.md rename to polkadot-wiki/translated_docs/zh-CN/contributors.md diff --git a/website/translated_docs/zh-CN/ens.md b/polkadot-wiki/translated_docs/zh-CN/ens.md similarity index 100% rename from website/translated_docs/zh-CN/ens.md rename to polkadot-wiki/translated_docs/zh-CN/ens.md diff --git a/website/translated_docs/zh-CN/faq.md b/polkadot-wiki/translated_docs/zh-CN/faq.md similarity index 100% rename from website/translated_docs/zh-CN/faq.md rename to polkadot-wiki/translated_docs/zh-CN/faq.md diff --git a/polkadot-wiki/translated_docs/zh-CN/getting-started.md b/polkadot-wiki/translated_docs/zh-CN/getting-started.md new file mode 100644 index 000000000000..ede46a0aa6f1 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/getting-started.md @@ -0,0 +1,111 @@ +--- +id: getting-started +title: 入门教程 +sidebar_label: 开始 +--- + +欢迎使用 Polkadot Wiki ！这是一份详细介绍如何与波卡核心系统进行交互的指南。wiki 包含三个主要内容：1. 学习 (面向科研)；2. 开发 (面向基于 Polkadot 的个人开发者)；3. 维护 (面向 Polkadot 网络维护者)。 + +## Polkadot 是什么？ + +Polkadot 允许多条专用区块链在安全的、无信任环境中相互沟通，从而实现可扩展性。 + +创建 Polkadot 的目的是为了连接及保护公链、非许可网络、企业集团私有链或是预言机及其他基于 Web3 科技的区块链。它构建了一个可让不同区块链在公共安全保障下，进行信息交换的网络。 + +Polkadot 是一个有生命力的网络，其核心支柱是社区治理和可迭代性。 该网络拥有一套先进的治理工具，以 [WebAssembly](https://webassembly.org/)标准作为“元协议”，可以自动部署网络升级。 Polkadot 会适应您不断增长的需求，同时不会产生区块链网络分叉的风险。 + +> 备注: 如果您是第一次听说“社区治理”，可通过该链接学习 [Governance page](learn-governance) + +综上所述，Polkadot 作为去中心化网络的基础服务，让用户可不受信任边界的限制，自主控制自己的数据。 + +## 为什么是 Polkadot？ + +回到新世纪早期，首次获得大众关注的互联网技术仅有只读、静态等基础网页的功能。 此时的早期网络互联，却是虚拟数据、身份及更多创新的网络新世界的开始。这段时间的互联网也被称为 Web 1.0。 + +随着社交媒体平台和网络商务的出现，互联网转变为 Web 2.0 。这个我们今天仍在使用的互联网版本，其功能是动态、交互式的网页，用户可以读写信息，或与他人分享用户自己的信息。 但是该版本的网络会涉及数据控制、隐私和信任问题。 这就是 Web 3.0 的意义所在。 + +Web 3.0 正在将中心化应用转化为去中心化应用、 去信任协议。其目标是将当前版本的互联网转化为一个去中心化的网络，用户可在去信任的环境中掌控其个人数据及身份。 Web 3.0 运动旨在删除中间人并建立一个去信任的公共基础设施。 + +> 要了解更多关于 Web3 运动的信息，请查看视频 [Web3 Summit](https://youtu.be/l44z35vabvA) + +## Polkadot 如何运作？ + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +为了与其它的区块确认性程序的链条进行交互 (例如: 比特币)，Polkadot 有[桥接链（bridge parachains）](learn-bridges) 提供双向兼容性。 + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> 观看一个有关 Polkadot 简短的，适合初学者的动画，请访问我们的网站。 [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## 为何要使用 Polkadot？ + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## 入门教程 + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot 原始白皮书][white paper] 是一篇技术文档，描述了 Polkadot 网络技术可能的发展方向。文档通过对原理的阐述和技术实现的细节说明来验证其可行性。原始白皮书也描述了 Polkadot 的核心团队是如何协同合作来构建这个去中心化网络的。 +- [Polkadot's overview paper][overview-paper] 是更新版本的白皮书，用更专业的方式描述了该网络协议。若您有兴趣深入研究协议本身，我们建议您阅读这份白皮书。 +- [Polkadot's lightpaper ][light paper]是一个更直观，方便阅读文档。这份文档比较少使用技术数据，可以让你不需要了解太多技术知识的情况下，就可以对 Polkadot 有更深入的理解。 +- [Polkadot's specification][spec]是一个 Github 代码库，其中包含最新的 Polkadot 主机协议规范、Polkadot 对网络中许多组件的测试规范，以及 Polkadot Runtime 规范。该代码库存有算法，并探讨各种进程如何在 Polkadot 网络中发挥作用。Polkadot 规范将 Polkadot 的思想和概念从聚光灯下和白皮书中提取出来，聚焦于技术规范的技术说明。 +- [观看技术演示][teched videos]: 这些是解释及演示如何使用 Polkadot 及其 [用户界面][ui]的介绍视频。 +- 在 Medium 上阅读 [What is Polkadot? A Brief Introduction][article] 。您也可以在 [Polkadot's Medium][p medium] 或 [Web3 Foundation's Medium][w medium]上阅读其余优质文章。 +- [创建 Polkadot 帐户][account generation] +- [发起转账][transfer] +- [作为提名人进行抵押 (Staking)][nominator] +- [作为验证节点运行][validator] +- [身份设定][identity] +- [创建代理账户][proxy] +- [发起提案及投票][democracy] +- [加入议会][council] +- [投票选举议员][council voting] +- [使用国库][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## 相关阅读 + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - Web3 基金会过往 Crowdcast 网络会议列表 +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer)-Polkadot 网络浏览器，可用于 Polkadot、Kusama 或其他基于 Substrate 的区块链网络。 +- [Polkascan](http://polkascan.io/) - Polkadot 中继链及其他 Substrate 链的实时多链数据。 +- [Subscan.io](https://subscan.io) - Substrate 链浏览器。 +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Gavin Wood 博士对 Polkadot 的视频介绍。（视频） +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Jutta Steiner 博士对 Polkadot 的视频介绍。（视频） +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Gavin Wood 博士对 Substrate（区块链框架及 VM）和 Polkadot，并在 30 分钟内基于 Substrate 构建了一个可运行的区块链。（视频） +- [社区/生态 ](community) - 谈论 Polkadot 的社区频道列表。 +- [范例程序](build-examples-index) - 基于 Polkadot 的应用案例及开发中的案例。 +- [贡献手册](contributing) - wiki 贡献者奖励规则。 +- [Polkadot 知识库](https://support.polkadot.network/) - 一些特定错误和问题的疑难解答。 + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ + +[white paper]: https://polkadot.network/PolkaDotPaper. pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/zh-CN/glossary.md b/polkadot-wiki/translated_docs/zh-CN/glossary.md similarity index 100% rename from website/translated_docs/zh-CN/glossary.md rename to polkadot-wiki/translated_docs/zh-CN/glossary.md diff --git a/polkadot-wiki/translated_docs/zh-CN/grants.md b/polkadot-wiki/translated_docs/zh-CN/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/zh-CN/index.md b/polkadot-wiki/translated_docs/zh-CN/index.md similarity index 94% rename from website/translated_docs/zh-CN/index.md rename to polkadot-wiki/translated_docs/zh-CN/index.md index 73de95a7e16a..9712369e34be 100644 --- a/website/translated_docs/zh-CN/index.md +++ b/polkadot-wiki/translated_docs/zh-CN/index.md @@ -11,7 +11,7 @@ sidebar_label: 维基索引 ## 想了解更多？ - [浏览维基](learn-introduction)-阅读维基的信息部分。 -- [相关链接](learn-relevant-links)-**有关Polkadot 的综合链接。** +- [相关链接](learn-relevant-links)-**有关 Polkadot 的综合链接。** ## 想在 Polkadot 建立？ diff --git a/polkadot-wiki/translated_docs/zh-CN/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/zh-CN/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..e177f338f9a2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: 对抗备忘单 +sidebar_label: 对抗备忘单 +--- + +期待 Kusama 会被攻破。为了帮助对手了解哪里可能会被攻破，参考下面的威胁模型。 + +| 黑客想要 … | 防黑客安全承诺 | 黑客奖励 | 破坏性 | 攻击价值详情 | +| ------------------------------------------------- | :------------: | :------: | :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 通过让客户端接受不同的链实现代币双花 | 完整性(全系统) | 高 | 高 | 如果攻击者能够双花代币，他们就能够获得服务而无需支付费用。 这使他们有很大的金钱激励来进行攻击。 | +| 导致系统在他自己的账户中增发代币 | 完整性(全系统) | 中 | 低 - 中 | 如果攻击者能够创建在他们账户里增发代币的交易，那么这将为执行攻击提供了很高的金钱奖励。 | +| 通过验证恶意区块来实现双花 | 可用性(全系统) | 高 | 中 | 如果攻击者能够双花代币，他们就能够获得服务而无需支付费用。 这使他们有很大的金钱激励来进行攻击。 | +| 通过破坏共识机制来分裂链 | 完整性(全系统) | 高 | 高 | 如果攻击者能够双花代币，他们就能够获得服务而无需支付费用。 这使他们有很大的金钱激励来进行攻击。竞争对手押注于加密货币的价值下跌或声誉受损，使得他们自己的区块链价值相对上升。 | +| 篡改/操纵区块链历史记录以使交易无效(例如投票结果) | 完整性(全系统) | 中等 | 中 - 高 | 攻击者可以通过故意使交易发生的区块失效来回滚他们不想要的交易。 攻击者可能迫使有利于他们的治理决定（或甚至是链上更新）被作出。 | +| 破坏区块链或共识机制以破坏生态系统的信誉 | 可用性(全系统) | 高 | 高 | 竞争对手押注于加密货币的价值下跌或声誉受损，使得他们自己的区块链价值相对上升。 | +| 审查 | 可用性(全系统) | 中等 | 高 | 黑客能够阻止他们不想要的交易(例如行业竞争者的交易或公民投票)。 这可以通过与其他利益攸关方勾结或以其他方式获得更多的投票权来实现。 | +| 匿名用户 | 保密性(节点) | 中等 | 中等 | 希望取消用户匿名的政党可以利用信息镇压反对派(例如政治活动家)。 | +| 从节点盗取代币 | 完整性(节点) | 高 | 高 | 能够从节点偷窃代币的攻击者可以为自己索取资产，这给他们实施攻击提供了很高的金钱奖励。 | +| 通过泄漏凭据从节点中盗取代币 | 保密性(节点) | 高 | 高 | 能够从节点偷窃代币的攻击者可以为自己索取资产，这给他们实施攻击提供了很高的金钱奖励。 | +| 阻止节点访问 Polkadot 网络 | 可用性 (节点) | 低 | 低 - 中 | 出于报复、货币利益(如果是相互竞争的货币交易所等)，实施目标明确的拒绝服务攻击。 | +| 诈骗其他参与者 | 完整性(节点) | 中等 | 低 - 中 | 攻击者可能滥用其他参与者对 Polkadot 安全保证对误解，以欺骗他们。而且，如果能够建立起对揭发不良行为的奖励使其高于对应的惩罚，则可以设置一组自处理的节点来形成闭环，该攻击就不需要其他参与者。 | +| 诈骗其他参与者 | 完整性(全系统) | 高 | 高 | 攻击者可能会在 Polkadot 的经济系统中滥用漏洞来欺骗其他参与者。 例如，攻击者可以利用逻辑错误来不支付交易费用。 | diff --git a/website/translated_docs/zh-CN/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/zh-CN/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-bug-bounty.md diff --git a/website/translated_docs/zh-CN/kusama-claims.md b/polkadot-wiki/translated_docs/zh-CN/kusama-claims.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-claims.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-claims.md diff --git a/polkadot-wiki/translated_docs/zh-CN/kusama-coc.md b/polkadot-wiki/translated_docs/zh-CN/kusama-coc.md new file mode 100644 index 000000000000..179164c99303 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/kusama-coc.md @@ -0,0 +1,33 @@ +--- +id: kusama-coc +title: Kusama 行为守则 +sidebar_label: 行为守则 +--- + +While Kusama has been its own network and has had its own ecosystem for a while now, it is still one big experiment and we need your participation for it to continue being a great success. + +## Community + +We want to foster a sense of collaboration amongst ourselves and the open source community. Kusma participants exist to encourage the open exchange of ideas and expression and require an environment that recognizes the inherent worth of every person and group. We are here to collaborate, discuss, and even disagree. The key is doing this is a manner that comes from a place of respect and professionalism. Participants in the Kusama network may consist of participants in an online forum, on-chain governance participants, parachain deployment teams, validators, enthusiasts, and ecosystem tool builders. We expect for there to be participation from all backgrounds but like to set some social boundaries on how you may be treated and treat others. + +Kusama 社区成员来自全球各地，不分种族、性别、或 背景。 社区参与者通过必要的资源阅读了解有关 Kusama 的知识及其所有相关内容。这些知识使社区具备履行参与者职责时所需的必要信息。 + +## Bugs + +Please understand that this network is, despite its success, an experiment with potential flaws, so it’s appreciated that community members help report any sort of exploits directly to the team before sharing publicly. Please see the [bug bounty program](kusama-bug-bounty). + +## Examples of Unacceptable Behavior + +请注意：这仅是几个示例，如果您有任何疑问，您总是可以咨询团队成员。 + +- Angry aggressive comments towards individuals or other projects on any medium of communication. +- Knowingly distributing false information about Kusama or other projects. +- Harassing other individuals or projects. + +That said, please note that Kusama is an edgy and meme-friendly network and community member actions shouldn't be taken too seriously - try to assume jest before malice. + +## What To Do If You Witness or Are Subject To Unacceptable Behavior + +If you are being harassed, notice that someone else is being harassed, or have any other concerns relating to harassment, please contact the administrator of the channel you’re in. + +This Code of Conduct may be revised at any time. We are always willing to revise this document based on feedback from the Kusama participants and/or the Polkadot community. diff --git a/website/translated_docs/zh-CN/kusama-community.md b/polkadot-wiki/translated_docs/zh-CN/kusama-community.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-community.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-community.md diff --git a/website/translated_docs/zh-CN/kusama-endpoints.md b/polkadot-wiki/translated_docs/zh-CN/kusama-endpoints.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-endpoints.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-endpoints.md diff --git a/website/translated_docs/zh-CN/kusama-faucet.md b/polkadot-wiki/translated_docs/zh-CN/kusama-faucet.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-faucet.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-faucet.md diff --git a/website/translated_docs/zh-CN/kusama-getting-started.md b/polkadot-wiki/translated_docs/zh-CN/kusama-getting-started.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-getting-started.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-getting-started.md diff --git a/website/translated_docs/zh-CN/kusama-index.md b/polkadot-wiki/translated_docs/zh-CN/kusama-index.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-index.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-index.md diff --git a/polkadot-wiki/translated_docs/zh-CN/kusama-ledger.md b/polkadot-wiki/translated_docs/zh-CN/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/zh-CN/kusama-parameters.md b/polkadot-wiki/translated_docs/zh-CN/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/zh-CN/kusama-social-recovery.md b/polkadot-wiki/translated_docs/zh-CN/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/zh-CN/kusama-time-periods.md b/polkadot-wiki/translated_docs/zh-CN/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/zh-CN/kusama-timeline.md b/polkadot-wiki/translated_docs/zh-CN/kusama-timeline.md similarity index 100% rename from website/translated_docs/zh-CN/kusama-timeline.md rename to polkadot-wiki/translated_docs/zh-CN/kusama-timeline.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-DOT.md b/polkadot-wiki/translated_docs/zh-CN/learn-DOT.md new file mode 100644 index 000000000000..07ff5c337f19 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-DOT.md @@ -0,0 +1,115 @@ +--- +id: learn-DOT +title: DOT +sidebar_label: DOT +--- + +## What are DOT? + +DOT 是 Polkadot 网络的原生代币，类似于 BTC 是比特币的原生代币或以太币是以太坊区块链的原生代币。 + +The smallest unit of account in a Substrate network (Polkadot, Kusama, etc.) is the Planck (a reference to [Planck Length](https://en.wikipedia.org/wiki/Planck_length), the smallest possible distance in the physical Universe). You can compare the Planck to satoshis or wei, while the DOT is like a bitcoin or an ether. Kusama tokens (KSM) are equal to 1e12 Planck, and Polkadot mainnet DOT are equal to 1e10 Planck. + +### Polkadot + +| 单位 | 小数位 | Example | +| --------------- | ------ | ------------ | +| Planck | 0 | 0.0000000001 | +| Microdot (uDOT) | 4 | 0.0000010000 | +| Millidot (mDOT) | 7 | 0.0010000000 | +| Dot (DOT) | 10 | 1.0000000000 | + +_Note: This changed at block #1,248,328. Previously, DOT were denominated as equal to 1e12 Planck, just like Kusama. This denomination is deprecrated, and, if necessary, referred to as "DOT (old)". See [Redenomination of DOT](redenomination) for more details._ + +### Kusama + +| 单位 | 小数位 | Example | +| --------------- | ------ | -------------- | +| Planck | 0 | 0.000000000001 | +| Point | 3 | 0.000000001000 | +| MicroKSM (uKSM) | 6 | 0.000001000000 | +| MilliKSM (mKSM) | 9 | 0.001000000000 | +| KSM | 12 | 1.000000000000 | + +## What are the uses of DOT? + +DOT serve three key functions in Polkadot: + +- to be used for governance of the network, +- to be staked for operation of the network, +- to be bonded to connect a chain to Polkadot as a parachain. + +DOT can also serve ancillary functions by virtue of being a transferrable token. For example, DOT stored in the Treasury can be sent to teams working on relevant projects for the Polkadot network. + +> These concepts have been further explained in the video [Usage of DOT and KSM on Polkadot and Kusama](https://www.youtube.com/watch?v=POfFgrMfkTo&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=7). + +### DOT for Governance + +The first function of DOT is to entitle holders to control of the governance of the platform. Some functions that are included under the governance mechanism include determining the fees of the network, the addition or removal of parachains, and exceptional events such as upgrades and fixes to the Polkadot platform. + +Polkadot will enable any holder of DOT to participate in governance. For details on how holders can participate in governance, as well as their rights and responsibilities, see the [governance page](learn-governance). + +### DOT for Consensus + +DOT will be used to facilitate the consensus mechanism that underpins Polkadot. In order for the platform to function and allow for valid transactions to be carried out across parachains, Polkadot will rely on holders of DOT to play active roles. Participants will put their DOT at risk (via staking) to perform these functions. The staking of DOT acts as a disincentive for malicious participants who will be punished by the network by getting their DOT slashed. The DOT required to participate in the network will vary depending on the activity that is being performed, the duration the DOT will be staked for, and the total number of DOT staked. + +### DOT for Parachain Slot Acquisition + +DOT will have the ability to be locked for a duration in order to secure a parachain slot in the network. The DOT will be reserved during slot lease and will be released back to the account that reserved them after the duration of the lease has elapsed and the parachain is removed. You can learn more about this aspect by reading about the [auctions](learn-auction) that govern parachain slots. + +### 锁仓 (Vesting) + +DOT may have a lock placed on them to account for vesting funds. Like other types of locks, these funds cannot be transferred but can be used in other parts of the protocol such as voting in governance or being staked as a validator or nominator. + +Vesting funds are on a linear release schedule and unlock a constant number of tokens at each block. Although the tokens are released in this manner, it does not get reflected on-chain automatically due to the fact that locks are [lazy](#lazy-vesting) and require an extrinsic to update. + +There are two ways that vesting schedules can be created. + +- One way is as part of the genesis configuration of the chain. In the case of Polkadot and Kusama, the chain specification genesis script reads the state of the Polkadot Claims contract that exists on the Ethereum blockchain and creates vesting schedules in genesis for all the allocations registered as being vested. +- A second way is through an extrinsic type available in the Vesting pallet, `vested_transfer`. The vested transfer function allows anyone to create a vesting schedule with a transfer of funds, as long as the account for which the vesting schedule will be created does not already have one and the transfer moves at least `MinVestedTransfer` funds, which is specified as a chain constant. + +Vesting schedules have three parameters, `locked`, `per_block`, and `starting_block`. The configuration of these three fields dictate the amount of funds that are originally locked, the slope of the unlock line, and the block number for when the unlocking begins. + +#### Lazy 锁仓 + +Like [simple payouts](learn-simple-payouts), vesting is _lazy_, which means that someone must explicitly call an extrinsic to update the lock that is placed on an account. + +- The `vest` extrinsic will update the lock that is placed on the caller. +- The `vest_other` will update the lock that is placed on another "target" account's funds. + +These extrinsics are exposed from the Vesting pallet. + +If you are using Polkadot-JS, when there are DOT available to vest for an account, then you will have the ability to unlock DOT which have already vested from the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![unbond](assets/unlock-vesting.png) + +#### Calculating When Vesting DOT Will Be Available + +Generally, you should be able to see from the [Accounts](https://polkadot.js.org/apps/#/accounts) by looking at your accounts and seeing when the vesting will finish. However, some DOT vest with "cliffs" - a single block where all the DOT are released, instead of vesting over time. In this case, you will have to query the chain state directly to see when they will be available (since technically, the vesting has not yet started - all of the vesting will occur in a single block in the future). + +1. Navigate to the [Chain State](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/chainstate) page on Polkadot-JS. +2. Query chain state for `vesting.vesting(ACCOUNT_ID)` +3. Note the `startingBlock` where the unlock starts, and how much DOT is unlocked per block (`perBlock`). +4. You will have to calculate the result into “human time". To do this, remember that there are approximately 14’400 blocks per day, and you can see what the latest block is shown on the [Explorer](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/explorer) page. + +## Obtaining Testnet DOT + +DOT are required to make transactions on the Polkadot network. Testnet DOT do not have any value beside allowing you to experiment with the network. + +### 获取 Westies + +The current testnet is called [Westend](maintain-networks#westend-test-network) and you can obtain its native tokens by posting `!drip ` in the Matrix chatroom [#westend_faucet:matrix.org](https://matrix.to/#/#westend_faucet:matrix.org). + +You can also make your own WNDs (testnet DOT) by [becoming a validator](learn-validator). + +### Getting Rococo Tokens + +Rococo is a parachain testnet. It does not have a faucet, and tokens are given only to teams working on parachains or exploring the [crosschain](learn-crosschain) message passing aspects of this testnet. Learn more about Rococo on the [matching wiki page](build-parachains-rococo). + +## Kusama Tokens + +Unlike testnet DOT, Kusama tokens are not freely given away. Kusama tokens are available via the [claims process](https://claim.kusama.network/) (if you had DOT at the time of Kusama genesis) or through the [Treasury](learn-treasury). Alternatively, they can be obtained on the open market. + +## Polkadot Mainnet DOT + +Polkadot Mainnet DOT are not freely given away. If you purchased DOT in the original 2017 offering, you may claim them via the [Polkadot claims process](https://claims.polkadot.network/). Alternatively, they are available on the open market. diff --git a/website/translated_docs/zh-CN/learn-PRE.md b/polkadot-wiki/translated_docs/zh-CN/learn-PRE.md similarity index 86% rename from website/translated_docs/zh-CN/learn-PRE.md rename to polkadot-wiki/translated_docs/zh-CN/learn-PRE.md index 758ea8f6e066..3de80ed2390d 100644 --- a/website/translated_docs/zh-CN/learn-PRE.md +++ b/polkadot-wiki/translated_docs/zh-CN/learn-PRE.md @@ -4,7 +4,7 @@ title: Polkadot Runtime 环境 (PRE) sidebar_label: Polkadot Runtime 环境 (PRE) --- -Polkadot Runtime 环境是 Polkadot 协议的重要组成部分。 它由网络层，共识和 Wasm VM 子系统组成，并充当 Polkadot runtime 和平行链 runtime 的基础堆栈底层。Polkadot RE 可以视为运行Polkadot 中继链的虚拟机的同义词（尽管如下所述，链逻辑本身与其运行的 PRE 之间有明显的分隔）。 +Polkadot Runtime 环境是 Polkadot 协议的重要组成部分。 它由网络层，共识和 Wasm VM 子系统组成，并充当 Polkadot runtime 和平行链 runtime 的基础堆栈底层。Polkadot RE 可以视为运行 Polkadot 中继链的虚拟机的同义词（尽管如下所述，链逻辑本身与其运行的 PRE 之间有明显的分隔）。 Polkadot RE 组件为： diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-UI.md b/polkadot-wiki/translated_docs/zh-CN/learn-UI.md new file mode 100644 index 000000000000..ee9df0dae639 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-UI.md @@ -0,0 +1,111 @@ +--- +id: learn-UI +title: Polkadot UI +sidebar_label: Polkadot UI +--- + +![Polkadot UI](assets/polkadot_ui_1.png) + +Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). + +## Getting started + +By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. + +As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). + +### Creating an account + +To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). + +### Getting testnet DOTs + +To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. + +### Sending a transaction + +Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. + +You will notice the value increase in the destination address after a few blocks. + +## Navigating around the interface + +### Explorer + +The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: + +- Block height/number. +- Hash. +- `parentHash` (hash of the previous block). +- The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). +- State root (merkle root of all the storage). + +### Transfer + +On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: + +1. Select the source account from which to send DOTs. +2. Select the recipient address which will receive the DOTs. +3. Enter the amount of DOTs to transfer. +4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. + +### Staking + +On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. + +On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. + +### Democracy + +The Democracy tab shows the current proposals and referendums. + +### Accounts + +This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. + +### Vanity + +![Polkadot UI 3](assets/polkadot_ui_3.png) + +Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. + +### Addresses + +You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. + +### Chain State + +The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. + +Some useful queries include: + +- `consensus.authorityCount()`: the number of current validators +- `session.validators()`: the current validators by address, useful for verifying your status as a validator +- `staking.intentions()`: accounts with the desire to stake and become validators +- `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function +- `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted +- `staking.freeBalanceOfWho()`: the balance of a given account + +### Extrinsics + +![Polkadot UI 2](assets/polkadot_ui_2.png) + +Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. + +Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. + +### Transferring and staking + +From here you can transfer, stake and unstake tokens. + +- transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. + +- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). + +- unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. + +### Toolbox + +For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. + +You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-account-generation.md b/polkadot-wiki/translated_docs/zh-CN/learn-account-generation.md new file mode 100644 index 000000000000..43a014452443 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-account-generation.md @@ -0,0 +1,235 @@ +--- +id: learn-account-generation +title: 开始生成帐户 +sidebar_label: 创建帐户 +description: Step-by-step guides on generating a Polkadot account. +--- + +An address is the public part of a Polkadot account. The private part is the key used to access this address. The public and private part together make up a Polkadot account. + +There are several ways to generate a Polkadot account: + +- 推荐给大多数用户的 Polkadot {.js}浏览器插件 +- **最安全的** [Subkey](#subkey) +- [Polkadot-JS 应用](#polkadotjs) +- [Parity Signer](#parity-signer) +- [Vanity Generator](#vanity-generator) +- [硬件钱包](learn-ledger) + +> If you prefer video instructions, we have an easy to follow guide [on YouTube](https://www.youtube.com/watch?v=hhUZ40ZWqkE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=19) + +## 免责声明：密钥安全 + +The _only_ ways to get access to your account are via your secret seed or your account's JSON file in combination with a password. You must keep them both secure and private. If you share them with anyone they will have full access to your account, including all of your funds. This information is a target for hackers and others with bad intentions - see also [How to Recognize Scams](learn-scams). + +On this page we recommend a variety of account generation methods that have various convienience and security tradeoffs. Please review this page carefully before making your account so that you understand the risks of the account generation method you choose and how to properly mitigate them in order to keep your funds safe. + +### 密钥的安全存储 + +The seed is your **key** to the account. Knowing the seed allows you, or anyone else who knows the seed, to re-generate and control this account. + +It is imperative to store the seed somewhere safe, secret, and secure. If you lose access to your account (i.e. you forget the password for your account's JSON file), you can re-create it by entering the seed. This also means that somebody else can have control over your account if they have access to your seed. + +For maximum security, the seed should be written down on paper or another non-digital device and stored in a safe place. You may also want to protect your seed from physical damage, as well (e.g. by storing in a sealed plastic bag to prevent water damage, storing it in a fireproof safe, etching it in metal, etc.) It is recommended that you store multiple copies of the seed in geographically separate locations (e.g., one in your home safe and one in a safety deposit box at your bank). + +You should definitely not store your seed on any kind of computer that has or may have access to the internet in the future. + +### Storing your account's JSON file + +The JSON file is encrypted with a password, which means you can import it into any wallet which supports JSON imports, but to then use it, you need the password. You don't have to be as careful with your JSON file's storage as you would with your seed (i.e. it can be on a USB drive near you), but remember that in this case your account is only as secure as the password you used to encrypt it. Do not use easy to guess or hard to remember passwords. It is good practice to use a [mnemonic password of four to five words](https://xkcd.com/936/). These are nearly impossible for computers to guess due to the number of combinations possible, but much easier for humans to remember. + +## Polkadot{.js} 浏览器插件 + +The Polkadot{.js} plugin provides a reasonable balance of security and usability. It provides a separate local mechanism to generate your address and interact with Polkadot. + +This method involves installing the Polkadot{.js} plugin and using it as a “virtual vault," separate from your browser, to store your private keys. It also allows signing of transactions and similar functionality. + +It is still running on the same computer you use to connected to the internet with and thus is less secure than using Parity Signer or other air-gapped approaches. + +### Install the Browser Plugin + +The browser plugin is available for both [Google Chrome](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd?hl=en) (and Chromium based browsers like Brave) and [FireFox](https://addons.mozilla.org/en-US/firefox/addon/polkadot-js-extension). + +If you would like to know more or review the code of the plugin yourself, you can visit the [Github source repository](https://github.com/polkadot-js/extension). + +After installing the plugin, you should see the orange and white Polkadot{.js} logo in the menu bar of your browser. + +![plugin-02](assets/accounts/polkadot_plugin_js_02.jpg) + +### Open Accounts + +Navigate to [Polkadot Apps](https://polkadot.js.org/apps). Click on the "Accounts" tab. + +### Create Account + +Open the Polkadot{.js} browser extension by clicking the logo on the top bar of your browser. You will see a browser popup not unlike the one below. + +![Initial PolkadotJS popup](assets/accounts/polkadot_plugin_js_new_01.png) + +Click the big plus button or select "Create new account" from the small plus icon in the top right. The Polkadot{.js} plugin will then use system randomness to make a new seed for you and display it to you in the form of twelve words. + +![New seed](assets/accounts/polkadot_plugin_js_new_02.png) + +You should back up these words as [explained above](#storing-your-key-safely). It is imperative to store the seed somewhere safe, secret, and secure. If you cannot access your account via Polkadot{.js} for some reason, you can re-enter your seed through the "Add account menu" by selecting "Import account from pre-existing seed". + +![New seed](assets/accounts/polkadot_plugin_js_new_03.png) + +### Name Account + +The account name is arbitrary and for your use only. It is not stored on the blockchain and will not be visible to other users who look at your address via a block explorer. If you're juggling multiple accounts, it helps to make this as descriptive and detailed as needed. + +### Enter Password + +The password will be used to encrypt this account's information. You will need to re-enter it when using the account for any kind of outgoing transaction or when using it to cryptographically sign a message. + +Note that this password does NOT protect your seed phrase. If someone knows the twelve words in your mnemonic seed, they still have control over your account even if they do not know the password. + +### 将 Polkadot 主网设置为地址 + +Now we will ensure that the addresses are displayed as Polkadot mainnet addresses. + +Click on "Options" at the top of the plugin window, and under "Display address format for" select "Polkadot Relay Chain". + +![New seed](assets/accounts/polkadot_plugin_js_new_04.png) + +Your address' format is only visual - the data used to derive this representation of your address are the same, so you can use the same address on multiple chains. However, for privacy reasons, we recommend creating a new address for each chain you're using. + +Our [Accounts page](learn-accounts#address-conversion-tools) also has a tool you can use to convert your address between the different chain formats. + +You can copy your address by clicking on the account's icon while the desired chain format is active. E.g. selecting "Substrate" as the format will change your address to start with the number 5, and clicking the colorful icon of your account will copy it in that format. While in Polkadot mode (starts with 1), that format will be copied, and so on. + +## Subkey + +Subkey is recommended for technically advanced users who are comfortable with the command line and compiling Rust code. Subkey allows you to generate keys on any device that can compile the code. Subkey may also be useful for automated account generation using an air-gapped device. It is not recommended for general users. + +For detailed build and usage instructions of subkey, please see [here](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). + +![subkey-01](assets/accounts/subkey_01.jpg) + +## Polkadot-JS Apps + +> Please note! If you use this method to create your account and clear your cookies in your browser, your account will be lost forever if you do not [back it up](learn-account-restore). Make sure you store your seed phrase in a safe place, or download the account's JSON file if using the Polkadot{.js} browser extension. Learn more about account backup and restoration [here](learn-account-restore). + +Using the Polkadot-JS user interface without the plugin is not recommended. It is the least secure way of generating an account. It should only be used if all of the other methods are not feasible in your situation. + +### Go to Polkadot-JS Apps + +Navigate to [Polkadot-JS Apps](https://polkadot.js.org/apps) and click on "Accounts" underneath the Accounts tab. It is located in the navigation bar at the top of your screen. + +![pjs-01](assets/accounts/polkadot_js_01.png) + +> To create an account on a different network than Polkadot, you'll need to click on the network selection in the top left corner of the navigation menu. A pop-up sidebar will appear listing live, testing, and custom node to choose from. Do remember to hit the "Switch" button when you want to switch your network. + +### Start Account Generation + +Click on the "Add Account" button. You should see a pop-up similar to the process encountered when using the [Polkadot JS Extension method](#polkadotjs-browser-plugin) above. Follow the same instructions and remember to [store your seed safely](#storing-your-key-safely)! + +### Create and Back Up Account + +Click “Save” and your account will be created. It will also generate a [backup JSON file](#storing-your-accounts-json-file) that you should safely store, ideally on a USB off the computer you're using. You should not store it in cloud storage, email it to yourself, etc. + +You can use this backup file to restore your account. This backup file is not readable unless it is decrypted with the password. + +### Multi-signature Accounts + +Multi-signature accounts are accounts created from several standard accounts (or even other multi-sig accounts). For a full explanation, please see the [Accounts Explainer section on multi-sigs](learn-accounts#multi-signature-accounts). + +On the [Accounts](https://polkadot.js.org/apps/#/accounts) tab, click the `Multisig` button. Enter the threshold and add signatories. The threshold must be less than or equal to the number of signatories. The threshold indicates how many members must be in agreement for an extrinsic submission to be successful. Click `Create` when done. + +![Multi-sig account creation](/img/accounts/create-multisig.png) + +This merely calculates the multi-signature's address and adds it to your UI. The account does not exist yet, and is subject to the same [Existential Deposit and Reaping](learn-accounts#existential-deposit-and-reaping) rules as regular accounts. + +Suppose we funded it with some tokens, and now want to send from the multi-sig to another account. + +![Sending from multi-sig account](/img/accounts/send-from-multi.png) + +The next step is to sign the transaction from with enough accounts to meet the threshold; in the above case, two out of three signatories must sign. + +![Signing from multi-sig account](/img/accounts/sign-from-multi-1.png) + +There is currently no indication of a pending transaction from a multi-sig in the UI. This means the second signatory must **repeat the call in full** in order to sign it. In other words: + +- 如果 Alice 发起了从多钱账户给 Ferdie 转账 150 个币的交易，链中将有一 个待处理的交易。 +- 如果 Bob 发起了从多钱账户给 Ferdie 转账 250 个币的交易，链中将有**另一个** 待处理的交易，并且第一个交易还没有完成。 +- 因为阈值是 2/3，Charlie 现在可以通过重复 执行所需交易来完成任意这两笔交易。 + +Other calls work exactly the same - if a multi-sig wants to become a Council member, the candidacy request has to come from the multi-sig, but be signed (re-requested) from each signatory until the threshold is reached. + +Signatories should communicate off-chain to prevent many pending transactions and crossed communication lines on-chain. + +> The bigger the multisig, the more of a deposit an account needs to put down when initiating a multi-sig call. This is to prevent chain storage spam with pending but never-resolved multi-sig transactions. Once a call is resolved (canceled or executed) the deposit is returned to the initiator. The deposit is not taken from the multi-sig's balance, but from the initiator. + +For a more in-depth introduction into multi signature accounts on Polkadot, please see [the accounts page section on Multi-sigs](learn-accounts#multi-signature-accounts). + +## Parity Signer + +Parity Signer is a secure way of storing your DOT on an air-gapped device. It is highly recommended that you turn off wifi, cellular network, Bluetooth, NFC, and any other communications methods after installing it. If you have any communications methods turned on, you will see an "unshielded" icon in red in the top-right corner that indicates your connection may not be secure. + +### Create Account + +Click "Create" to create an identity, or "recover" if you have previously backed up the recovery phrase. You can have multiple identities on one device. Each identity can manage multiple addresses on different networks. + +![Parity Signer Create Account 1](assets/accounts/ps-create-1.jpg) + +### Name Account + +Input the name for your identity and then click "Create". + +![Parity Signer Create Account 2](assets/accounts/ps-create-2.jpg) + +### Back Up Account + +Parity Signer will then generate a recovery phrase for you and display it in the form of 12 or 24 words. + +You should write down this recovery phrase on paper and [store it somewhere safe](#storing-your-key-safely). + +![Parity Signer Create Account 3](assets/accounts/ps-create-3.jpg) + +### Set PIN + +After confirming that you have backed up your seed, a new textbox will appear in which you can set a PIN. The PIN code should contain at least 6 digits. If the PIN codes do not match, it will not allow you to create an account. The PIN code will be used for when signing any transaction, or to protect sensitive operations such as deleting an identity or revealing the recovery phrase. + +Note that if someone knows the 12/24 words in your recovery phrase, they will still have control over your account, even if they do not know the PIN. + +![Parity Signer Create Account 4](assets/accounts/ps-create-4.jpg) + +### Get Address + +Choose which network you would like to create an address for by clicking the name of the network. For example, if you select "Polkadot", a new Polkadot address will be created for you under this identity. + +![Parity Signer Create Account 5](assets/accounts/ps-create-5.jpg) + +There is currently no way to copy your address from Parity signer in plain-text in order to send it via text or email. You must use the QR method. + +### Your Address + +The address will be shown as a QR code. You can import your address to the Polkadot-JS Apps by going to the [Accounts](https://polkadot.js.org/apps/#/accounts) page on an Internet-connected computer and click "Add via QR", and following the instructions to add the account. An account created this way will always require you to sign messages with your Parity Signer device. It will do this only by scanning and displaying QR codes, leaving even someone with total control of your internet-connected computer a very small and limited scope for interacting with the Parity Signer device, which can continue to keep your key safe. + +![Parity Signer Create Account 6](assets/accounts/ps-create-6.jpg) + +## 硬件钱包 + +To use a Ledger hardware wallet to create your address and keep your tokens in cold storage, follow the instructions on our [Ledger hardware wallet guide page](learn-ledger). + +## 靓号地址(Vanity Generator) + +The vanity generator is a tool on [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts/vanity) that lets you generate addresses which contain a specific substring. + +![Vanity Generator page](assets/polkadot_vanity_generator_page.png) + +The vanity generator takes the following parameters: + +- “搜索”: 您想要在您的新地址中包含的子字符串。 +- "区分大小写": "是", 如果搜索是区分大小写; "否" 如果不是。 +- “密钥对加密类型”：指定您要生成的帐户类型；建议在大多数情况下使用 Schnorrkel，以确保安全。 + +If you've filled out all details above and hit the "Start generation" button, a list of accounts will start generating on your screen. Note that depending on the length of the substring and the processing speed of your computer, it may take some time before any accounts appear. + +![Vanity Generator search](assets/polkadot_vanity_generate.png) + +The "Save" button will allow you to save the generated accounts - they are not saved if you do not choose to do this. The next steps are identical to the [steps above on creating an account on the UI](#polkadotjs), where a password and name need to be filled in, and a backup file of your account will be downloaded. + +Note that the [Subkey tool](#subkey) also has vanity generation built-in, and is orders of magnitude faster than the web version. If you need to generate addresses with longer strings, or need plenty of them, we recommend using Subkey instead. + +![Vanity Generator chosen address](assets/polkadot_save_account.png) diff --git a/website/translated_docs/zh-CN/learn-account-restore.md b/polkadot-wiki/translated_docs/zh-CN/learn-account-restore.md similarity index 100% rename from website/translated_docs/zh-CN/learn-account-restore.md rename to polkadot-wiki/translated_docs/zh-CN/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-accounts.md b/polkadot-wiki/translated_docs/zh-CN/learn-accounts.md new file mode 100644 index 000000000000..987c74b76567 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot 账户 +sidebar_label: Polkadot 账户 +description: 账户、账户索引、账户身份和回收机制的解释 +--- + +本文档涵盖 Polkadot 和 Kusama 账户的基本地址及其在链上的保存。 欲了解更多关于加密技术背后的详细解释，请参阅 [加密页面](learn-cryptography)。 + +## 地址格式 + +基于 Substrate 的链的地址格式是 SS58。SS58 是一种对于比特币的 Base-58-Check 进行小幅修改的格式。需要注意，此格式包含*地址类型*前缀，可以识别地址具体属于哪一个网络。 + +例如: + +- Polkadot 地址总是以数字 1 开头。 +- Kusama 地址总是以大写字母开头，如 C、D、F、G、H、J... +- 通用 Substrate 地址以 5 开头。 + +这些前缀在[此处]()定义。 + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## 地址的生成，派生和迁移 + +一个有效的账户只需要一个可以在[supported curves and signature scheme](build-protocol-info#cryptography)签名的私钥。多数钱包然间从助记词到生成账户需要经由许多步骤。同一组助记词，不同钱包采用不同步骤生成的账户也不会相同。 + +### 助记词(种子) 生成 + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +基于 Subkey 和 Polkadot-JS 的钱包采用 BIP39 词典来生成助记词，使用熵字节数组来生成私钥，这有别于其他 BIP39 钱包软件(如 Ledger)采用 PBKDF2。所以，同一组助记词在经由这两种算法后并不能产生同样的私钥。更多相关细节请参阅[Substrate BIP39](https://github.com/paritytech/substrate-bip39) + +### 衍生路径 + +许多 Polkadot 密钥生成工具支持硬派和软派生。更多关于派生路径的细节和例子请参考 [Subkey 文档](https://substrate. dev/docs/en/knowledgebase/integrate/subkey) 。Polkadot-JS 的应用和拓展同 Parity Signer 也支持采用和 Subkey 相同语法的自定义派生路径。 + +一些钱包会自动将派生路径添加到生成的助记词短语的末尾。这将为单独的路径生成单独的种子，从而允许使用相同的助记符，例如`//Polkadot` 和 `//Kusama`。尽管您可以正确保存助记词短语，但除非在两个钱包中使用相同的派生路径，否则在另一个钱包中使用它将不会生成相同的地址。 + +Polkadot 和 Kusama 都在[BIP44 注册表](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)中注册了路径。 + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### 可移植性 + +以上信息为我们带来了可移植性：在多个钱包中使用助记词或种子的能力。可移植性取决于许多因素： + +- 派生路径 +- 助记符格式 +- 种子衍生 +- 签名方案 + +如果要在多个钱包中使用相同的助记符，请确保它们遵循兼容生成密钥和签名消息的方法。如果找不到可理解的文档，请与项目维护人员联系。 + +| | 助记符格式 | 派生路径 | 种子衍生 | 签名支持 | +| :------------------- | :--------: | :-----------: | :-----------: | :-------------------------: | +| Polkadot{.js} 扩展 | 标准 | 用户自定义 | BIP32 | sr25519 | +| Polkadot-JS 应用程序 | 标准\* | 用户自定义 | BIP32 | sr25519, ed25519, secp256k | +| 账本 | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | 标准\* | 用户自定义 | BIP32 | sr25519, ed25519, secp256k1 | + +\ \* 附带 BIP39 的 Ed25519 密钥具有[有限的兼容性](https://github.com/paritytech/substrate-bip39)。 + +† [BIP44 注册表](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ 基于[Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf)的 Ed25519 和 BIP32 + +§ Sr25519 计划 + +### 好奇：前缀的工作原理 + +这是[ SS58 文档]()的申明： + +- Polkadot 的地址类型为`000000000`，所以`0`是十进制。 +- Kusama (Polkadot 金丝雀) 的地址类型为`00000010b`，因此`2`以十进制表示。 +- 通用 Substrate 的地址类型为`00101010b`，十进制为`42`。 + +因为 Base58-check 字母没有数字 0，所以最小值确实是 1。因此，`00000000b`在 Base58 中是 1。如果我们尝试[解码](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder)诸如`1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`的 Polkadot 地址，则结果为` 000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8b7e7bed`。第一个字节是`00`，实际上既是二进制的`00000000`又是十进制的`0`，因此它与 Polkadot 的地址类型匹配。 + +让我们看一下 Substrate 的地址。如果我们解码` 5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`，则会得到` 2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`。第一个字节是`2a`，当[从十六进制转换为十进制](https://www.rapidtables.com/convert/number/hex-to-decimal.html)时是 42。42 的二进制是`00101010`，就像 SS58 文档所述的那样。 + +最后，让我们看一下 Kusama 的地址。解码` CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp`会让我们得到` 020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985`，正如被指定的那样，其中第一个字节为`02`。如果我们尝试以完全不同的字母，例如` J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`，我们仍然将`02`作为第一个字节：` 02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e2114`。从直觉上看，有些地址总是有相同的前缀，而其他一些地址像是用 Kusama 生成的却可能千差万别，但这只是对于 Base58-check 编码的怪癖。 + +## 获取和管理地址 + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +**更方便和推荐**的将帐户保存在计算机上方法是使用[ Polkadot {.js}扩展名](https://github.com/polkadot-js/extension)。此扩展程序可以记住您的帐户，让您不必担心即可清除浏览器缓存。不过，不要忘记备份您的种子短语 - 如果您无法使用这台计算机，或者扩展名以某种方式崩溃而无法修复，则该短语将派上用场。 + +请注意，由于这会将您的帐户保留在浏览器中，因此这里不是一个存放大量资产的安全之地。根据定义，浏览器是一个“热钱包”，容易受到各种各样的攻击，因此，在处理不重要的数额时，请将资金保存在冷库中。为了提高安全性，您可以安全地隐藏帐户的种子短语，并在创建帐户后从计算机中删除所有帐户痕迹。 + +除了扩展名和默认 UI 外，还可以使用[ 子键工具](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey)。子键旨在供用户熟悉使用命令行使用，并且看起来令人生畏，但相当平易近人。请按照[子键文档](https://substrate.dev/docs/en/knowledgebase/integrate/subkey)。如果使用得当，子键是创建帐户的**最安全**的可用方法。 + +还有一个非常安全的[奇偶校验签名人](https://www.parity.io/signer/)。这样可以将您的钥匙保持在气密的手机上。但是，这确实需要获得您常用的且仅用于 Parity Signer 的旧 Android 或 iOS 兼容手机。 + +账本可以与硬件钱包集成。完整指南可在[此处](learn-ledger)获得。 + +另外，您可能会在[钱包](build-wallets)页面上找到其他钱包，但请记住，其中一些是**未经审计的**，除非另有说明，否则它们并不隶属于 Web3 Foundation 或 Polkadot 的正式项目。 + +## 余额类型 + +在 Polkadot 上，有四种不同的余额类型，提示您的余额是否可以用于转账，支付费用，或者由于链上要求而必须冻结且不被使用。 + +余额类型由 Substrate 中的`AccountData`结构定义。四种类型的余额包括`free`，`reserved`，`misc_frozen` (驼峰体为`miscFrozen`) 和` fee_frozen` (驼峰体为`feeFrozen`)。 + +通常，帐户的**可用**余额是`自由`的金额减去任何被视为冻结的资金 (`misc_frozen`或`free_frozen`) ，具体取决于使用资金的原因。如果资金将用于转账，则可用金额为“自由”金额减去任何`misc_frozen`资金。但是，如果要使用这些资金来支付交易费用，则可用金额将是“自由”资金减去`fee_frozen `的任何资金。 + +帐户的“总”余额被认为是帐户中“自由”资金的数量减去任何“保留”的资金。保留的资金是根据链上的要求持有的，通常可以通过执行一些链上操作来释放。例如，“身份”模块在注册链上身份时保留资金，但是通过清除身份，您可以取消保留资金并再次释放它们。 + +## 现有存款和回收 + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +如果帐户低于现有存款，则会导致该帐户*被回收*。该帐户以及该地址中的所有资金将从区块链状态中删除，以节省空间。您不会失去对回收地址的访问权限 - 只要您拥有私钥或恢复短语，您仍然可以使用该地址 - 但它需要充值额外的存续金额才能与链进行交互。 + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## 索引 + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## 身份 + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## 代理账户 + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## 多签名账户 + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- 保护您自己的藏匿处：使用其他签署人作为 2FA 机制来保护您的资金。一个签名者可以在一台计算机上，另一个可以在另一台计算机上，或在冷库中。这减慢了您与链的交互速度，但是安全性提高了几个数量级。 +- 董事会决策：诸如企业和基金会之类的法人实体使用多重签名来共同管理实体的国库。 +- 团体参与治理：多签名帐户可以执行常规帐户可以执行的所有操作。具有多重签名的帐户可以是 Kusama 治理中的理事 ​​ 会成员，在该理事会中，一组社区成员可以作为一个实体进行投票。 + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### 生成多重签名帐户的地址 + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### 使用多重签名帐户进行交易 + +There are three types of actions you can take with a multi-sig account: + +- 执行一笔交易 +- 授权一笔交易 +- 撤销一笔交易 + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +存款=存款基数+阈值*存款因子 +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| -------- | -------------- | -------------- | ----------------- | --------------- | +| 存款基数 | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| 存款因子 | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## 资源 + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-architecture.md b/polkadot-wiki/translated_docs/zh-CN/learn-architecture.md new file mode 100644 index 000000000000..f59b21fe09ed --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-architecture.md @@ -0,0 +1,43 @@ +--- +id: learn-architecture +title: 架构 +sidebar_label: 架构 +--- + +Polkadot 采用共享安全性和可互操作的异构多链结构。 + +## 中继链 (Relay Chain) + +中继链是 Polkadot 的中心链。所有的验证者都在中继链上抵押 DOT 并验证中继链。中继链仅由相对少量的交易类型构成，包括和治理机制互交，平行链拍卖，参与 NPo'S。中继链是可以被设计成具有最精简的功能的 - 例如，中继链并不支持智能合约。中继链的主要只能是负责协调整个系统，包括各个平行链。其他的具体工作应该交予实现不同功能的平行链来执行。 + +## [Parachain](learn-parachains) and [Parathread](learn-parathreads) Slots + +Polkadot can support a number of execution slots. These slots are like cores on a computer's processor (a modern laptop's processor may have eight cores, for example). Each one of these cores can run one process at a time. Polkadot allots these slots using two subscription models: parachains and parathreads. Parachains have a dedicated slot (core) for their chain and are like a process that runs constantly. Parathreads share slots amongst a group, and are thus more like processes that need to be woken up and run less frequently. + +Most of the computation that happens across the Polkadot network as a whole will be delegated to specific parachain or parathread implementations that handle various use cases. Polkadot places no constraints over what parachains are able to do besides that they must be able to generate a proof that can be validated by the validators assigned to the parachain. This proof verifies the state transition of the parachain. Some parachains may be specific to a particular application, others may focus on specific features like smart contracts, privacy, or scalability — still others might be experimental architectures that are not necessarily blockchain in nature. + +Polkadot provides many ways to secure a slot for a parachain slot for a particular length of time. Parathreads are part of a pool that shares slots and must win auctions for individual blocks. Parathreads and parachains have the exact same API; their difference is economic. Parachains will have to reserve DOT for duration of their slot lease; parathreads will pay on a per-block basis. Parathreads can become parachains, and vice-versa. + +## 共享安全性 + +Parachains connected to the Polkadot Relay Chain all share in the security of the Relay Chain. Polkadot has a shared state between the Relay Chain and all of the connected parachains. If the Relay Chain must revert for any reason, then all of the parachains would also revert. This is to ensure that the validity of the entire system can persist and no individual part is corruptible. + +The shared state makes it so that the trust assumptions when using Polkadot parachains are only those of the Relay Chain validator set, and no other. Since the validator set on the Relay Chain is expected to be secure with a large amount of stake put up to back it, it is desirable for parachains to benefit from this security. + +## 角色 + +### 验证人 + +Validators, if elected to the validator set, produce blocks on the Relay Chain. They also accept proofs of valid state transition from collators. In return, they will receive staking rewards. + +### 收集人 + +Collators are full nodes on both a parachain and the Relay Chain. They collect parachain transactions and produce state transition proofs for the validators on the Relay Chain. They can also send and receive messages from other parachains using XCMP. + +### 提名人 + +Nominators bond their stake to particular validators in order to help them get into the active validator set and thus produce blocks for the chain. In return, nominators are generally rewarded with the portion of the staking rewards from that validator. + +## 白板系列 + +For a video overview of the architecture of Polkadot watch the video below for the whiteboard interview with W3F researcher Alistair Stewart: diff --git a/website/translated_docs/zh-CN/learn-auction.md b/polkadot-wiki/translated_docs/zh-CN/learn-auction.md similarity index 100% rename from website/translated_docs/zh-CN/learn-auction.md rename to polkadot-wiki/translated_docs/zh-CN/learn-auction.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-availability.md b/polkadot-wiki/translated_docs/zh-CN/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-balance-transfers.md b/polkadot-wiki/translated_docs/zh-CN/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-bridges.md b/polkadot-wiki/translated_docs/zh-CN/learn-bridges.md new file mode 100644 index 000000000000..03cd60bad885 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: 转接桥 +sidebar_label: 转接桥 +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/zh-CN/learn-collator.md b/polkadot-wiki/translated_docs/zh-CN/learn-collator.md similarity index 100% rename from website/translated_docs/zh-CN/learn-collator.md rename to polkadot-wiki/translated_docs/zh-CN/learn-collator.md diff --git a/website/translated_docs/zh-CN/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/zh-CN/learn-comparison-dfinity.md similarity index 88% rename from website/translated_docs/zh-CN/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/zh-CN/learn-comparison-dfinity.md index 507371e6a766..da1d813abf1e 100644 --- a/website/translated_docs/zh-CN/learn-comparison-dfinity.md +++ b/polkadot-wiki/translated_docs/zh-CN/learn-comparison-dfinity.md @@ -4,13 +4,13 @@ title: Dfinity 与 Polkadot 区别 sidebar_label: Dfinity --- -Dfinity 自称 "互联网计算机" 并与以太坊定位为姐妹项目。 Dfinity 一直自2016年起开发，该产品的发布版本 "Copper" 本应于2017年问世，但似乎从未发布。 2019年大众尚未看到 Dfinity 的大部分客户端代码，因为他们仅在 [GitHub](https://github.com/dfinity) 发布帮助库。 封闭代码的开发本質与 Polkadot 从2017年初开始在[ GitHub 上开放](https://github.com/paritytech/polkadot)了 Rust 参考实现。 +Dfinity 自称 "互联网计算机" 并与以太坊定位为姐妹项目。 Dfinity 一直自 2016 年起开发，该产品的发布版本 "Copper" 本应于 2017 年问世，但似乎从未发布。 2019 年大众尚未看到 Dfinity 的大部分客户端代码，因为他们仅在 [GitHub](https://github.com/dfinity) 发布帮助库。 封闭代码的开发本質与 Polkadot 从 2017 年初开始在[ GitHub 上开放](https://github.com/paritytech/polkadot)了 Rust 参考实现。 ### 算法治理 Dfinity 是算法治理的有力支持者，已经发布了[两篇](https://medium.com/dfinity/the-dfinity-blockchain-nervous-system-a5dd1783288e#.duzxztt9k)关于该主题的[博客文章](https://medium.com/dfinity/future-governance-integrating-traditional-ai-technology-into-the-blockchain-nervous-system-825ababf9d9)。 -Dfinitiy 提出了称为 "区块链神经系统(BNS)" 的治理框架，但是它们没有在2018年发布前两篇博客文章后，确定使用任何的算法或更多信息。 +Dfinitiy 提出了称为 "区块链神经系统(BNS)" 的治理框架，但是它们没有在 2018 年发布前两篇博客文章后，确定使用任何的算法或更多信息。 与 Polkadot 广泛的治理机制相比，博客文章中描述的 BNS 简化了链上治理， 它仅通过 "信任专家" 跟随最重神经元的方法来决定分叉链。 @@ -28,4 +28,4 @@ The blockchain and fork resolution layer used in Dfinity is known as _probablist Finally, in the notarization and _near-instant finality_ layer of Dfinity, the blocks that are produced in the previous layer are notarized by the committee of validators. The notarization is a timestamp and a proof that the block has been published to the network, which prevents a malicious validator from creating a private chain and revealing it later. The notarization mechanism aims to solve the selfish mining attack and the nothing at stake problem. The notarized blocks are then agreed on in a further finalization mechanism. -大家不用太在意术语_接近即时确认性_，因为这术语跟"即时确认性"基本上只是拜占庭协议的营销术语，并且掩盖了确认性工具的实际功能。例如可以将 Dfinity 共识的公证和最终回合与标准 BFT 协议的 pre-commit 和 pre-vote 进行比较。虽然由于 Dfinity 具有用于生成和最终确认区块的两步机制(跟 Polkadot 在 BABE 和 GRANDPA 上的做法非常类似)，因此两种协议的最终确认时间应该是可比的。 GRANDPA 有不错的性能，例如可以一次确认整个链的区块，而不是一次一个区块，这使其对 Dfinity 概述的最终确认性机制有所改进。 +大家不用太在意术语*接近即时确认性*，因为这术语跟"即时确认性"基本上只是拜占庭协议的营销术语，并且掩盖了确认性工具的实际功能。例如可以将 Dfinity 共识的公证和最终回合与标准 BFT 协议的 pre-commit 和 pre-vote 进行比较。虽然由于 Dfinity 具有用于生成和最终确认区块的两步机制(跟 Polkadot 在 BABE 和 GRANDPA 上的做法非常类似)，因此两种协议的最终确认时间应该是可比的。 GRANDPA 有不错的性能，例如可以一次确认整个链的区块，而不是一次一个区块，这使其对 Dfinity 概述的最终确认性机制有所改进。 diff --git a/website/translated_docs/zh-CN/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/zh-CN/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/zh-CN/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/zh-CN/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/zh-CN/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/zh-CN/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/zh-CN/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/zh-CN/learn-comparisons-cosmos.md diff --git a/website/translated_docs/zh-CN/learn-comparisons.md b/polkadot-wiki/translated_docs/zh-CN/learn-comparisons.md similarity index 100% rename from website/translated_docs/zh-CN/learn-comparisons.md rename to polkadot-wiki/translated_docs/zh-CN/learn-comparisons.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-consensus.md b/polkadot-wiki/translated_docs/zh-CN/learn-consensus.md new file mode 100644 index 000000000000..d2855e2b298f --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-consensus.md @@ -0,0 +1,115 @@ +--- +id: learn-consensus +title: 波卡共识 +sidebar_label: 波卡共识 +description: 对 Polkadot 和 Kusama 所用的共识解释 +--- + +## 为什么我们需要共识机制？ + +共识是一种在共享状态上达成协议的方法。为了使区块链的状态继续建立并向前进，网络中的所有节点必须达成一致共识。通过这种方式，去中心网络中的节点可以保持彼此同步。在区块链上如果去中心化网络节点没有共识，就无法确保由其他节点共享的状态 是真实的。共识旨在参与者之间提供状态的*客观*事实，每个参与者对网络都有自己的*主观*观点。这些节点间进行通信的过程并达成协议使能够构建新区块。 + +## 什么是 PoW 和 PoS？ + +工作量证明(PoW) 和权益证明(PoS) 已被用来作为区块链共识机制的简称，但这并不能完整地描述其全貌。 PoW 是达成区块创造者共识的方法，也是[中本聪共识](#nakamoto-consensus)的一部分，该共识还包含链选择算法(根据比特币中最长链的规则)。同样 PoS 是用于选择验证人的一组规则并且没有指定链的选择规则或如何达到链的终点。传统上 PoS 算法已被融合到实现节点之间的拜占庭协议的算法配对。例如[Tendermint](learn-comparisons-cosmos)是实用性拜占庭容错算法，它使用 PoS 作为其验证人的选择方法。 + +## 为什么不使用工作量证明(PoW)? + +尽管在下一个区块生产者达成去中心化共识方面既简单又有效，但中本聪共识实现的工作量证明却消耗了大量的能源，没有经济的或可证明的终结性，也没有有效的策略来抵抗卡特尔。 + +## 概率性 vs 可证明的最终性 + +PoW 中本聪共识只能实现*概率最终性*并会达到*最终共识*。概率最终性意味着假设在某些网络和参与者之下，如果我们看到多过区块在某个区块上构建了，则有很大概率估计它是最终了。最终共识意味着在接下来的某个时间，所有节点都将就一组数据的真实性达成共识。最终共识可能需要很长时间，并且无法确定需要多长时间。但是例如 GRANDPA 或以太坊的 Casper FFG 之类的最终性工具旨在为区块提供更强的最终性 -​​ 特别是更快的保证，在经过拜占庭协议的某些处理后，它们永远无法篡改。不可逆的共识概念称为*可证明的最终性。* + +在 GRANDPA 论文中，它的表达方式如下： + +> 如果在没有指定的时间后向所有参与者返回相同的值，oracle A 在协议中是*最终一致*。 + +## 什么是 GRANDPA / BABE? + +### 混合共识 + +在讨论 Polkadot 的共识协议时，我们使用两个首字母缩写词：GRANDPA 和 BABE。我们讨论这两个的原因是因为 Polkadot 使用的是*混合共识*。混合共识从区块生产机制中拆分了最终性工具。 + +这是在 Polkadot 中获得概率最终性（拥有产生新区块的能力）和可证明的最终性（在规范链上具有通用协议，没有任何逆转机会）的好处。它还避免了每种机制的相应缺点（在概率最终性中不知不觉地遵循了错误的分叉的机会，以及在可证明的最终性中存在"过时"的可能性- 无法产生新的区块）。通过结合这两种机制，Polkadot 可以快速生成区块，而较慢的最终机制可以在单独的流程中运行以确定区块，而不会使交易速度变慢或停顿的风险。 + +过去已经提出了混合共识。值得注意的是它被提议(现已不存在)作为以太坊转向[ EIP 1011 ](http://eips.ethereum.org/EIPS/eip-1011)的权益证明过渡的一步。 [ Casper FFG ](#casper-ffg)。 + +### BABE + +BABE (Blind Assignment for Blockchain Extension) 是在验证人节点与决定谁是产生新区块之间的产生区块机制。 BABE 与 Ouroboros Praos 相比，在链选择规则和时段调整方面存在一些关键差异。 BABE 根据抵押和使用 Polkadot [随机性周期](learn-randomness)分配区块生产插槽给验证人。 + +Polkadot 的验证人将会参与在每次的[抽奖](learn-randomness)去决定它们是否在那个时隙的生产区块候选人。时隙是用时间作单位，长度为 6 秒。由于这种随机性机制，多个验证人可能是同一时隙的候选人。在其余时间，时隙可能为空导致区块时间不一致。 + +#### 同一时隙多个验证人 + +当多个验证人在同一时隙也是区块生产侯选人，全部也会产生区块并广播到网络。那时侯将会是一场比赛。其那个区块到达网络大部分的验证人先获胜。取决于网络拓扑和延迟，两条链都将继续建立一定的容量，直到最终敲定并截断分叉为止。有关其工作原理，请参见下面的"分叉选择"。 + +#### 时隙里没有验证人 + +当没有任何验证人在随机抽奖中达到足够低的资格进行生产区块时，时隙便会没有区块。我们在后台通过运行辅助轮循样式验证人选择算法来避免这种情况。通过选择该算法生成区块的验证人始终生成区块，但是如果同一时隙也从[ VRF 选择](learn-randomness)验证人生成主块，则这些*次要*区块将被忽略。因此时隙可以具有* 主要 *或* 次要 *区块，并且不会跳过任何时隙。 + +有关更多 BABE 的详细信息，请参见[正在研究的草案](http://research.web3.foundation/zh/latest/polkadot/BABE/Babe/)。 + +#### Kusama 和 Polkadot 的 BABE 次生块的区别 + +Both Kusama and Polkadot uses the BABE block production mechanism outlined above. However, there is a slight difference in the secondary blocks that are produced between the two networks. Polkadot attaches the VRF output to secondary blocks (and therefore every block contributes to the Epoch randomness), while Kusama keeps the VRF output off the secondary blocks (meaning only the primary blocks contribute to Epoch randomness). The Polkadot method should give stronger randomness as more inputs are collected during every Epoch. Eventually, this change should make its way into Kusama too. + +### GRANDPA: 最终决定性工具 + +GRANDPA (基于 GHOST 的递归祖先派生前缀协议) 是为 Polkadot 中继链实现的最终性工具。 + +只要 2/3 的节点是诚实的，并且可以在异步设置中处理 1/5 的拜占庭节点，它就可以作为同步的网络模型中的一部分运行。 + +一个明显的区别是，即使在长期的网络分区或其他网络故障之后，GRANDPA 还是在链上达成协议，而不是在区块上达成协议，从而大大加快了最终性确定的过程。 + +换句话说，一旦超过 2/3 的验证者证明包含某个块的链，则导致该块的所有块都会立即完成。 + +#### 协议 + +请参阅[该文件](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf)中的标题 3 以获取该协议的完整说明。 + +#### 实施 + +[Rust 的执行](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs)是 Substrate 框架的一部分。 + +更多详细的相关信息，请参见 W3F 研究页面上的[GRANDPA 研究页面](https://research.web3.foundation/en/latest/polkadot/GRANDPA.html)。 + +### 分叉选择 + +将 BABE 和 GRANDPA 结合在一起，Polkadot 的分叉选择变得很清晰。 BABE 必 须始终建立在 GRANDPA 最终确定的链条上。当最终确定的头后面有分叉时， BABE 通过在具有最主要区块的链上做构建来提供概率的确定。 + +![最佳链的选择](assets/best_chain.png) + +在上图中，黑色块已确认。一个是主要的，两个是次要的块。即使最上面的链是最新确定的区块上的最长链，它仍然不符合条件，因为在评估时它的基数比下面的基数少。 + +## 共识比较 + +### 中本聪共识 + +中本聪共识包括最长链规则，该规则以工作量证明作为其 sybil 反抗机制和领导者选举。 + +中本聪共识只给了我们概率上的终局性。概率终局性指出，过去的区块仅与其确认数或在其之上构建的区块数一样安全。由于在工作量证明链中特定块之上构建了更多块，因此在此特定链之后花费了更多的计算工作。但是，它不能保证包含该块的链将始终保持商定后的链，因为拥有无限资源的参与者可能会构建竞争链并消耗足够的计算资源以创建不包含特定块的链。在这种情况下，比特币和其他工作链证明中采用的最长链规则将作为规范转移到这一新链上。 + +### PBFT / Tendermint + +请参阅 Cosmos 的比较文章中的[相关部分](learn-comparisons-cosmos#consensus)。 + + + +### Casper FFG + +GRANDPA 和 Casper FFG (友好结局小工具) 之间的两个主要区别是： + +- 在 GRANDPA 中，不同的选民可以同时为不同高度的区块投票 +- GRANDPA 依靠最终的区块来影响底层区块生产机制的分叉选择规则 + +### Casper CBC + +_未完待续!_ + +## 资源 + +- [ GRANDPA 论文](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf)- GRANDPA 最终确定性工具的描述。 包含算法证明。 +- [Finality Grandpa - Rust 实现](https://github.com/paritytech/finality-grandpa) - 及[ Substrate Runtime 模块](https://github.com/paritytech/substrate/blob/master/srml/grandpa/src/lib.rs)。 +- [Polkadot 中的区块生产和确认](https://www.crowdcast.io/e/polkadot-block-production) - 说明了 BABE 和 GRANDPA 如何与 Bill Laboon 合作在 Kusama 上生产和确认区块的。 diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-crosschain.md b/polkadot-wiki/translated_docs/zh-CN/learn-crosschain.md new file mode 100644 index 000000000000..05ac546c65eb --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-crosschain.md @@ -0,0 +1,79 @@ +--- +id: learn-crosschain +title: 跨链消息传递 (XCMP) +sidebar_label: 跨链消息传递 (XCMP) +--- + +Polkadot 使用基于 Merkle 树的简单排队机制实现跨链交易，并确保其真实性。中继链验证者应负责将某一平行链上输出队列中的交易移至目标平行链上的输入队列中。然而，在此过程中，中继链仅存储相关元数据的哈希值。 + +通常在代码库和相关文档中将输入和输出队列分别成为“入口”和“出口”消息。 + +## XCMP 概述 + +XCMP 目前仍处于开发阶段，其具体细节可能改变。但是，其总体架构的设计决定如下： + +- 跨链消息将*不会*转发至中继链。 +- 跨链消息有长度限制 +- 平行链可以拒绝接收从其它平行链发出的信息，在这种情况下，发送方会意识到有障碍 +- 收集人节点负责把平行链之间的信息传递 +- 收集人产生"出口"列表信息並会在"入口"接收到其它平行链信息 +- 平行链在每个区块中，将会传递所有其它平行链信息 +- 当收集人产生了区块并提交给验证人，它会收集最新入口队列信息并且处理它 +- 验证人将会对收集人提交的平行链区块进行验证，包括处理到该平行链预期入口的信息 + +XCMP queues must be initiated by first opening a channel between two parachains. The channel is identified by both the sender and recipient parachains, meaning that it's a one-way channel. A pair of parachains can have at most two channels between them, one for sending messages to the other chain and another for receiving messages. The channel will require a deposit in DOT to be opened, which will get returned when the channel is closed. + +## 水平中继消息传递（HRMP） + +当 XCMP 协议处于部署阶段时，HRMP 协议将作为其替代方案存在。HRMP 协议与 XCMP 协议具有相同的接口及功能，但是其对资源的需求明显高于 XCMP，原因在于其将所有消息都存储在中继链中。当 XCMP 完成部署时，HRMP 将被逐步淘汰。 + +> 注：stop-gap 协议是原协议功能未完全实现时的临时替代。当 XCMP 仍处于开发过程中时，HRMP 即为其替代协议。 + +## 垂直消息传递 + +垂直消息传递分为两种形式，上行消息传递（UMP）和下行消息传递（DMP）。当消息由一平行链或平行线程产生并传递至中继链时使用 UMP。当中继链产生的信息需传递至平行链时使用 UMP。通过 DMP 传递的信息可能在平行链中产生。在此情况下，第一个 UMP 将被用于向中继链传递消息，DMP 用于将该信息下传至另一平行链。 + +## XCMP 消息格式 + +关于 XMCP 消息格式的描述，请参阅 GitHub 上的[xcm-format](https://github.com/paritytech/xcm-format) 库。 + +## XCMP 实例 + +平行链 A 上存在的智能合约会将一条消息路由到平行链 B，在该消息中调用另一个智能合约，该合约在该链中转移某些资产。 + +查理(Charlie) 在平行链 A 上执行智能合约，这会为平行链 B 上智能合约的目的地发起新的跨链消息。 + +平行链 A 的收集人节点会将这个新的跨链消息以及`目的地`和`时间戳`放入其出站消息队列。 + +平行链 B 的收集人节点会定期 ping 所有其他收集人节点以询问新消息 (通过`destination`字段过滤)。当平行链 B 的收集人进行下一次 ping 时，它将在平行链 A 上看到此新消息，并将其添加到自己的入站队列中，以便将它处理到下一个块中。 + +平行链 A 的验证者还将读取出站队列并知晓消息。平行链 B 的验证者将执行相同的操作。这样，他们便可以验证消息传输是否发生。 + +当平行链 B 的收集人正在构建其链上的下一个区块时，它将处理入站队列中的新消息以及可能已找到/接收到的任何其他消息。 + +在处理期间，该消息将在平行链 B 上执行智能合约并按预期完成资产转移。 + +收集人现在将此块交给验证程序，验证程序它自己将验证此消息是否已处理。如果消息已处理且该区块的所有其他方面均有效，则验证人会将该平行链 B 的区块包含于中继链中。 + +请查看下面的动画视频，它探讨了 XCMP 的工作原理。 + + + + + + + +## 资源 + +- [XCMP 方案](https://research.web3.foundation/en/latest/polkadot/XCMP.html) - Web3 基金会研究维基上的跨链通信的完整技术描述。 +- [消息传递概述](https://w3f.github.io/parachain-implementers-guide/messaging.html) - 一份来自平行链开发者指南中的消息传递方案概述。 +- [XCM 格式](https://github.com/paritytech/xcm-format) - XCMP 格式的说明。 diff --git a/website/translated_docs/zh-CN/learn-crowdloans.md b/polkadot-wiki/translated_docs/zh-CN/learn-crowdloans.md similarity index 100% rename from website/translated_docs/zh-CN/learn-crowdloans.md rename to polkadot-wiki/translated_docs/zh-CN/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-cryptography.md b/polkadot-wiki/translated_docs/zh-CN/learn-cryptography.md new file mode 100644 index 000000000000..8261db7bffee --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: 密码学解释 +sidebar_label: 密码学解释 +description: An overview of the cryptographic functions used in Polkadot +--- + +这是 Polkadot 中使用密码学技术的高级概述。假设你已了解在区块链中常用的密码学术语例如哈希，椭圆曲线密码学(ECC)和公私密钥对。 + +有关所用密码学的详细说明，请参阅我们[研究团队的维基](https://research.web3.foundation)。 + +## 哈希算法 + +在 Polkadot 使用的哈希算法是 [Blake2b]()。 Blake2 被认为是非常快的加密哈希函数，也用在 [Zcash](https://z.cash) 加密货币。 + +## 密钥对和签名 + +Polkadot 使用 Schnorrkel/Ristretto x25519 ("sr25519") 作为导出密钥和签名算法。 + +Sr25519 基于 [Curve25519](https://en.wikipedia.org/wiki/Curve25519) 相同的底層作為 EdDSA 的哥哥 [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519) ，但是它使用 Schnorr 簽名而不是 EdDSA 方案。与 ECDSA / EdDSA 方案相比，Schnorr 签名带来了一些明显好处，一方面效率更高，但仍保留相同的功能和安全性假设。另外它允许通过簽名集合方式进行原生多重签名。 + +Schnorrkel 和 Ristretto 名称来自实现该方案的两个 Rust 库，分别为[ Schnorrkel ](https://github.com/w3f/schnorrkel)库用于 Schnorr 签名和 [Ristretto](https://ristretto.group/ristretto.html) 库，使可以用诸如 Curve25519 之类的 cofactor-8 曲线。 diff --git a/website/translated_docs/zh-CN/learn-faq.md b/polkadot-wiki/translated_docs/zh-CN/learn-faq.md similarity index 100% rename from website/translated_docs/zh-CN/learn-faq.md rename to polkadot-wiki/translated_docs/zh-CN/learn-faq.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-governance.md b/polkadot-wiki/translated_docs/zh-CN/learn-governance.md new file mode 100644 index 000000000000..740609dc2021 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: 治理 +sidebar_label: 治理 +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## 机制 + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## 公投 + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### 公众投票 + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### 议会公投 + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### 投票时间表 + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### 统计 + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **实体** | **指标** | +| :--------------: | :-------------------: | +| 大众 | Positive Turnout Bias | +| 议会(一致赞成) | Negative Turnout Bias | +| 议会(大部分赞成) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### 自愿锁定 + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## 议会 + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :------------: | :-: | :--------: | :-: | :-: | :-: | +| **代币持有人** | | **候选人** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **总数** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## 技术委员会 + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/zh-CN/learn-identity.md b/polkadot-wiki/translated_docs/zh-CN/learn-identity.md similarity index 100% rename from website/translated_docs/zh-CN/learn-identity.md rename to polkadot-wiki/translated_docs/zh-CN/learn-identity.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-implementations.md b/polkadot-wiki/translated_docs/zh-CN/learn-implementations.md new file mode 100644 index 000000000000..f7bfd042cb36 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-implementations.md @@ -0,0 +1,21 @@ +--- +id: learn-implementations +title: Polkadot 实现 +sidebar_label: Polkadot 实现 +--- + +这里 Rust，C ++，Go 和 JavaScript 开发都是 Polkadot 不同语言的实现。 + +[** Parity Polkadot **](https://github.com/paritytech/polkadot) - Rust 客户端由 Parity 与他们在[ Substrate ](https://github.com/paritytech/substrate)上的工作。 + +[ ** Kagome **](https://github.com/soramitsu/kagome) - 由 [ Soramitsu ](https://github.com/soramitsu) 实现 C++ Polkadot Host 环境 ，他们是日本的数字身份识别公司，之前开发了[ Hyperledger Iroha ](https://iroha.tech)。他们获得了 Web3 基金会的资助，并计划在[ 2019 年 11 月](https://medium.com/web3foundation/w3f-grants-soramitsu-to-implement-polkadot-runtime-environment-in-c-cf3baa08cbe6)发布。他们正在用 C ++ 开发 libp2p 网络层。 + +[** Gossamer ** ](https://github.com/ChainSafeSystems/gossamer) - 由[ ChainSafe Systems ](https://github.com/ChainSafeSystems)，23 人组成在多伦多的开发团队也正在开发 Eth2.0 Serenity 客户程序。[拨款公告](https://medium.com/web3foundation/w3f-grants-chainsafe-to-implement-polkadot-runtime-environment-in-go-ca4973c9edaf)。 + +[**Polkadot-JS**](https://github.com/polkadot-js) - A JavaScript [client](https://github.com/polkadot-js/client) and tool set developed by [Polkadot-JS](https://polkadot.js.org/). + +## 为什么要把 Polkadot 实现多个语言？ + +如 Soramitsu 拨款公告所述: + +> It is critically important to have multiple implementations of the Polkadot protocol for a number of reasons, including decentralization, knowledge dispersion, and better definitions of the protocol... Multiple implementations of Polkadot improves network resilience and adds to the decentralization of the network. The governance of the network is more democratized when multiple teams build clients that run the nodes in the network. diff --git a/website/translated_docs/zh-CN/learn-implementers-guide.md b/polkadot-wiki/translated_docs/zh-CN/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/zh-CN/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/zh-CN/learn-implementers-guide.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-interchain.md b/polkadot-wiki/translated_docs/zh-CN/learn-interchain.md new file mode 100644 index 000000000000..c61a7178b880 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-interchain.md @@ -0,0 +1,42 @@ +--- +id: learn-interchain +title: Interchain Message Passing (XCMP) +sidebar_label: Interchain Message Passing (XCMP) +--- + +跨链交易是基于梅克尔树(Merkle tree)利用简单队列机制方案解决确保正确性。这将会是属于在中继链上验证人的工作，把在平行链上出口队列中的交易发送到刻目的地(平行链)的入口队列中。 + +入口和出口队列在代码中通常称为"入口(ingress)"和"出口(egress)"信息。 + +## 概述 + +- 跨链信息*不会*发送到中继链 +- 跨链信息将会限制于字节(bytes)最大值 +- 平行链可以拒绝接收从其它平行链发出的信息，在这种情况下，发送方会意识到有障碍 +- 校对人负责把平行链之间的信息传递 +- 校对人产生"出口"列表信息並会在"入口"接收到其它平行链信息 +- 平行链在每个区块中，将会传递所有其它平行链信息 +- 当校对人产生了区块并提交给验证人，它会收集最新入口队列信息并且处理它 +- 验证人将会对校对人提交的平行链区块进行验证，包括处理到该平行链预期入口的信息 + +## 例子 + +从平行链 A 里的智能合约发送信息到平行链 B 里的另一个智能合约，达到链与链之间资产转移。 + +Charlie 通过平行链 A 里的智能合约发起一个新跨链信息到在平行链 B 的智能合约。 + +平行链 A 的校对人会把跨链信息连同`目的地(destination)`和`时间(timestamp)`放到出口信息队列中。 + +平行链 B 的校对人会持续地问其它校对人节点是否有新信息(通过筛选`目的地`)，当平行链 B 的校对人问是否有新信息时，它会看到从平行链 A 发送过来的信息并且把它加到下一个区块中的入口队列。 + +平行链 A 和 B 的验证人同样也会读取出口队列并且发现该信息，这样它们就可以验证传输中信息。 + +当平行链 B 的校对人在打包区块的时候，它会处理在入口队列中的新信息和其它发现或接收到的信息。 + +在处理时，平行链 B 里的智能合约会执行该信息并且完成资产转移。 + +然后校对人提交该区块给验证人，并且核对信息是否处已经处理。如果信息经已处理好和区块中其它方面是有效，验证人便会把该区块包括到中继链上。 + +## 资源 + +- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/zh-CN/learn-introduction.md b/polkadot-wiki/translated_docs/zh-CN/learn-introduction.md similarity index 100% rename from website/translated_docs/zh-CN/learn-introduction.md rename to polkadot-wiki/translated_docs/zh-CN/learn-introduction.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-keys.md b/polkadot-wiki/translated_docs/zh-CN/learn-keys.md new file mode 100644 index 000000000000..5efc2e638133 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-keys.md @@ -0,0 +1,115 @@ +--- +id: learn-keys +title: Polkadot 密钥 +sidebar_label: Polkadot 密钥 +--- + +公钥和私钥是大多数密码系统的重要部分，也是使像 Polkadot 这样的区块链得以存在的重要组成部分。 + +## 账户密钥 + +帐户密钥是用来控制资金的密钥，它们可以是： + +- 使用 Schnorr 签名的原版`ed25519`实现。 +- 使用 Schnorr 签名的 Schnorrkel / Ristretto `sr25519`。 +- ECDSA signatures on secp256k1 + +对于简单签名，`ed25519`和`sr25519`之间的安全性没有区别。 + +我们希望在可预见将来，商用 HSM 将更好地支持`ed25519`。 + +同时，`sr25519`使实施更复杂的协议更加安全。 特别是`sr25519`带有许多协议的安全版本，例如比特币和以太坊生态系统中常见的 HDKD。 + +### "Controller" 和 "Stash" 密钥 + +When we talk about "controller" and "stash" keys, we usually talk about them in the context of running a validator or nominating DOT, but they are useful concepts for all users to know. Both keys are types of account keys. They are distinguished by their intended use, not by an underlying cryptographic difference. All the info mentioned in the parent section applies to these keys. When creating new controller or stash keys, all cryptography supported by account keys are an available option. + +The controller key is a semi-online key that will be in the direct control of a user, and used to submit manual extrinsics. For validators or nominators, this means that the controller key will be used to start or stop validating or nominating. Controller keys should hold some DOT to pay for fees, but they should not be used to hold huge amounts or life savings. Since they will be exposed to the internet with relative frequency, they should be treated carefully and occasionally replaced with new ones. + +Stash 密钥在大多数情况下是保存在冷钱包，写在纸上也可以受硬件安全保护。如果可以的话，它应该很少在互联网上或用于提交交易。 Stash 密钥用于存储大量资金，应该将它视为银行的储蓄帐户，只有在紧急情况下才使用该帐户。或者也许更恰当的隐喻是将其视为埋藏在某个岛屿上的藏宝，并且只有最初隐藏它的海盗才知道。 + +因为 stash 密钥是保储在线下，所以它必须拥有自己的资金绑定到指定的 controller。对于非支出操作，controller 拥有其背后 stash 的资金。例如在提名，抵押或投票，controller 可以指出其偏好 stash 的权重，它永远无法移动或拥有其 stash 的资金。但是如果有人获取了你的 controller 密钥，他们可以利用它做出会被惩罚的操作，所以你应小心保存并且时常更改它。 + +## Session 密钥 + +Session 密钥是热钥，验证人必须将其保持在线才能执行网络操作。 Session 密钥通常在客户端中生成，尽管不是必须。它们*不是*意在控制资金，仅应用于其预期目的。它们可以定期更改。 Controller 仅需要通过 session 公钥签名来创建证书，然后通过外部广播该证书。 + +Polkadot 使用四款 session 密钥: + +- GRANDPA: ed25519 +- BABE: sr25519 +- I'm Online: sr25519 +- Parachain: sr25519 + +BABE 需要适用于[可验证随机函数 (VRF)](learn-randomness#vrfs)以及数字签名的密钥。 Sr25519 密钥具有两种功能，并且可用于 BABE。 + +因为 BLS 密钥允许更高效聚合签名，在将来我们计划在 GRANDPA 使用它。 + +## 常见问题 + +### 为什么在`secp256k1`上选择了`ed25519`？ + +为 Polkadot 和 Substrate 链实现的原有密钥导出密码学是`ed25519`，这是在 Edward's 曲线 25519 上实现的 Schnorr 签名算法(由于曲线方程的参数而命名)。 + +大部份加密货币包括比特币, 以太币现在是在 secp256k1 曲线上使用 ECDSA 签名。这曲线被认为比 NIST 曲线安全得多，因为 [NSA 可能有 NIST 曲线的后门](#appendix-a-on-the-security-of-curves)。Curve25519 被认为可能比这*更安全*，并且可以更轻松地实现 Schnorr 签名。最近它的专利即将到期，使它成为在 Polkadot 使用的首选。 + +使用 Schnorr 签名而不是使用 ECDSA 的选择并非人们所预料的。正如 Jeff Burdges (Web3 研究员)所述，[论坛帖子](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70/2): + +> 我们在帐户密钥中选择 Schnorr 签名而不是 ECDSA 做了些牺牲: 两者都需要 64 字节，但是只有 ECDSA 签名才能传递其公钥。有些过时的 Schnorr 变体支持从签名中恢复公钥，但它们破坏了诸如分层确定性密钥导出之类重要的功能。因此 Schnorr 签名通常会为公钥占用额外的 32 个字节。 + +但最终使用 Schnorr 签名的好处大于权衡，将来优化可能会解决上述指出的低效率问题。 + +### 什么是 `sr25519` 并它是从何而来? + +某些情况下: Twisted Edward's 曲线 25519 上的 Schnorr 签名被认为是安全，但是 Ed25519 并没有完全解决其错误。最值得注意的是，[ Monero 和所有其他 CryptoNote 货币](https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html)很容易受到双花的利用，这有可能导致未被发现的无限通胀。 + +这些漏洞的源于是由于 Ed25519 中的特点，即其 8 的协因子。曲线的协因子是深奥的细节，这可能对更复杂协议的安全实现产生可怕的后果。 + +更方便的是，[ Mike Hamburg's Decaf 论文](https://www.shiftleft.org/paper/decaf/index.xhtml)提供了解决这个潜在错误的途径。 Decaf 基本上是种采用 Twisted Edward's 曲线的协因子和数学变化，以很少的成本性能和获得安全的方法。 + +[ Ristretto Group ](https://ristretto.group/)的 Decaf 论文中的方法得到延伸，并在 Rust 中实現，以包含诸如 Curve25519 之类的协因子 8 曲线，并在 Edward's 曲线上做出 Schnorr 签名使它更安全。 + +Web3 基金会已在[ Schnorrkel ](https://github.com/w3f/schnorrkel)库中的 Curve25519 上使用更安全的 Ristretto 压缩实现了 Schnorr 签名库。 Schnorrkel 在此曲线压缩的基础上实现了相关的协议，例如 HDKD，MuSig 和 VRF。它还包括各种较小的改进，例如哈希方案 STROBE，该方案理论上可以通过 Wasm 进行一次调用就可以处理大量数据。 + +在 Polkadot 中使用的 Schnorr 签名实现和通过 Curve25519 的 Ristretto 压缩 Schnorrkel 协议的实现称为** sr25519 **。 + +### BLS 签名是否在 Polkadot 使用? + +还没有，但是会。 BLS 签名允许更高效的聚合签名。由于 GRANDPA 验证人通常对同一件事情(例如区块)进行签名，所以聚合它们可以使其它协议得到优化。 + +如 BLS 库所述， + +> Boneh-Lynn-Shacham(BLS)签名速度慢，验证速度非常慢，需要慢和低安全性的友好曲线，并且可能造成危险的延展性。 但是 BLS 允许多种的聚合签名选项，这使 BLS 成为共识算法中投票和阈值签名的首选方案。 + +即使 Schnorr 签名允许进行聚合签名，但 BLS 签名在某方面还是更有效。因此它将是 session 密钥之一，供 Polkadot 网络上的验证人使用，并且对于 GRANDPA 最终确定性工具特别重要。 + +## 资源 + +- [对 BIP32-Ed25519](https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44) - 论坛帖子详细描述了对 BIP32-Ed25519 的潜在攻击。 向 sr25519 变量过渡的动机。 +- [在 Polkadot 中的账户签名和密钥](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70) - Web3 研究人员 Jeff Burdges 的帖子。 +- [Schnorr 签名有抗量子计算吗?](https://bitcoin.stackexchange.com/questions/57965/are-schnorr-signatures-quantum-computer-resistant/57977#57977) + +## 附录 A: 曲线安全 + +From the [introduction of Curve25519](https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n10) into `libssl`: + +```text +The reason is the following: During summer of 2013, revelations from ex- +consultant at [the] NSA Edward Snowden gave proof that [the] NSA willingly inserts backdoors +into software, hardware components and published standards. While it is still +believed that the mathematics behind ECC (Elliptic-curve cryptography) are still sound and solid, +some people (including Bruce Schneier [SCHNEIER]), showed their lack of confidence +in NIST-published curves such as nistp256, nistp384, nistp521, for which constant +parameters (including the generator point) are defined without explanation. It +is also believed that [the] NSA had a word to say in their definition. These curves +are not the most secure or fastest possible for their key sizes [DJB], and +researchers think it is possible that NSA have ways of cracking NIST curves. +It is also interesting to note that SSH belongs to the list of protocols the NSA +claims to be able to eavesdrop. Having a secure replacement would make passive +attacks much harder if such a backdoor exists. + +However an alternative exists in the form of Curve25519. This algorithm has been +proposed in 2006 by DJB [Curve25519]. Its main strengths are its speed, its +constant-time run time (and resistance against side-channel attacks), and its +lack of nebulous hard-coded constants. +``` diff --git a/website/translated_docs/zh-CN/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/zh-CN/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/zh-CN/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/zh-CN/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/zh-CN/learn-launch.md b/polkadot-wiki/translated_docs/zh-CN/learn-launch.md similarity index 100% rename from website/translated_docs/zh-CN/learn-launch.md rename to polkadot-wiki/translated_docs/zh-CN/learn-launch.md diff --git a/website/translated_docs/zh-CN/learn-lazy-payouts.md b/polkadot-wiki/translated_docs/zh-CN/learn-lazy-payouts.md similarity index 87% rename from website/translated_docs/zh-CN/learn-lazy-payouts.md rename to polkadot-wiki/translated_docs/zh-CN/learn-lazy-payouts.md index 1725ac75076b..61c10fc8d66e 100644 --- a/website/translated_docs/zh-CN/learn-lazy-payouts.md +++ b/polkadot-wiki/translated_docs/zh-CN/learn-lazy-payouts.md @@ -29,15 +29,15 @@ Polkadot 最多可存储达 84 eras 的奖励资料，例如验证人的分数 提供索引将更快搜索，并允许较低的交易费用。 -如果您使用 [ polkadot.js用户界面](https://polkadot.js.org/apps/#/staking/actions)，则会自动为您处理这些详细资料。 +如果您使用 [ polkadot.js 用户界面](https://polkadot.js.org/apps/#/staking/actions)，则会自动为您处理这些详细资料。 ## 常问问题和注意事项 1. **注意：** 一旦用户领取某个时代奖励，该用户的前一个时代的所有奖励信息都会被删除。 正常用户不应该自己构建这些交易，而应该使用一个钱包或前端，以正确的次序安全地领取。 -1. 奖励在84个时代后过期。在 Polkadot, 约84天。在 Kusama, 约为21天。 +1. 奖励在 84 个时代后过期。在 Polkadot, 约 84 天。在 Kusama, 约为 21 天。 1. 用户必须使用他们的 **controller** 密钥领取奖励。 **stash** 密钥应保存在冷钱包中。 1. 领取奖励(或忽略领取奖励)不会以任何方式影响提名。提名在领取奖励或奖励到期后继续有效。 -1. Polkadot 在常用的 pallet 下提供了` batch `功能，该功能使用户可以将多个交易从_同一来源_批量成一个交易，所以用户 可以使用此功能为个别验证人或提名人领取多个时代的奖励。 +1. Polkadot 在常用的 pallet 下提供了`batch`功能，该功能使用户可以将多个交易从*同一来源*批量成一个交易，所以用户 可以使用此功能为个别验证人或提名人领取多个时代的奖励。 1. 在还没有领取奖励之前，奖励不会创造在网络里。因此如果您的奖励目的地是 "stash, increasing amount at stake"，那么您的抵押额直到您申领奖励后才反映您的奖励。如果您想最大化复利，那么您将需要经常领取。 ## 将来计划 diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-ledger.md b/polkadot-wiki/translated_docs/zh-CN/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/zh-CN/learn-nominator.md b/polkadot-wiki/translated_docs/zh-CN/learn-nominator.md similarity index 100% rename from website/translated_docs/zh-CN/learn-nominator.md rename to polkadot-wiki/translated_docs/zh-CN/learn-nominator.md diff --git a/website/translated_docs/zh-CN/learn-parachains.md b/polkadot-wiki/translated_docs/zh-CN/learn-parachains.md similarity index 100% rename from website/translated_docs/zh-CN/learn-parachains.md rename to polkadot-wiki/translated_docs/zh-CN/learn-parachains.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-parathreads.md b/polkadot-wiki/translated_docs/zh-CN/learn-parathreads.md new file mode 100644 index 000000000000..34d4cb76558f --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-parathreads.md @@ -0,0 +1,50 @@ +--- +id: learn-parathreads +title: 平行线程 +sidebar_label: 平行线程 +--- + +Parathreads are an idea for parachains to temporarily participate (on a block by block basis) in Polkadot security without needing to lease a dedicated parachain slot. This is done through economically sharing the scarce resource of a _parachain slot_ among a number of competing resources (parathreads). Chains that otherwise would not be able to acquire a full parachain slot, or do not find it economically sensible to do so, are enabled to participate in Polkadot's shared security — albeit with an associated fee per executed block. It also offers a graceful off-ramp to parachains that no longer require a dedicated parachain slot, but would like to continue using the Relay Chain. + +## 起源 + +根据在成都的[演讲](https://v.douyu.com/show/a4Jj7llO5q47Dk01)，这个想法的起源于于 80 年代末和 90 年代早期个人电脑上有限的内存资源概念类似。由于计算机上的内存记忆体资源有限，当某个程序需要更多内存时，计算机可以在硬盘通过使用*交换空间*创建虚拟记数亿体。交换空间允许计算机内存量扩大，权衡取舍并供更多程序同时运行，某些程序需要更长的时间才能完成。 + +## 平行线程 vs. 平行链 + +Parachains and parathreads are very similar from a development perspective. One can imagine that a chain developed with Substrate can at different points in its lifetime assume one of three states: an independent chain with secured bridge, a parachain, or a parathread. It can switch between these last two states with relatively minimal effort since the difference is more of an economic distinction than a technological one. + +平行线程有着跟平行链连接 Polkadot 一样的好处。换句话说通过 ICMP 并受 Polkadot 验证人全面的经济安全保护发送信息到其它平行{链, 线程}。 + +The difference between parachains and parathreads is economic. Parachains must be registered through a normal means of Polkadot, i.e. governance proposal or parachain slot auction. Parathreads have a fixed fee for registration that would realistically be much lower than the cost of acquiring a parachain slot. Similar to how DOT are locked for the duration of parachain slots and then returned to the winner of the auction, the deposit for a parathread will be returned to the parathread after the conclusion of its term. + +除了将平行线程代码注册到 Polkadot 中继链之外，注册平行线程不提供任何保证。当平行线程产生新的区块时，使用方必须支付费用参加每个区块链的拍卖，以使包含在下一个验证的中继链区块。所有已注册的平行线程都将参与拍卖，使将包含其平行线程。 + +有两个关于平行线程的有趣发现。第一，由于它们是逐个区块竞争，这跟比特币和以太坊处理交易相似。同样将会开发费用市场，意味着当繁忙时间使用平行线程，价格将推高，而较少人使用的时侯，费用将会较低。第二，这种机制与平行链机制明显不同，后者只要持有平行链槽保证可用，而注册平行线程没有给予此权利。 + +## 平行线程将如何运作？ + +中继链上的部分平行链槽将被指定为平行线程池的一部分。换句话说某些插槽将没有附上平行链，而是将被用作拍卖平行线程候选区块的空间，供每个区块获胜者使用。 + +Collators will offer a bid designated in DOT for inclusion of a parathread block candidate. The Relay Chain block author is able to select from these bids to include a parathread block. The obvious incentive is for them to accept the block candidate with the highest bid, which would bring them the most profit. The tokens from the parathread bids will likely be split 80-20, meaning that 80% goes into Polkadot treasury and 20% goes to the block author. This is the same split that applies also to transaction fees and, like many other parameters in Polkadot, can be changed through a governance mechanism. + +## 平行线程经济学 + +There are two sources of compensation for collators: + +1. Assuming a parathread has its own local token system, it pays the collators from the transaction fees in its local token. If the parathread does not implement a local token, or its local token has no value (e.g. it is used only for governance), then it can use DOT to incentivize collators. +2. 平行线程协议补贴。平行线程可以创建新代币，为收集人提供额外的奖励。 或许为平行线程创建代币的数量将是按时间函数決定。 包含在中继链中的平行线程区块传递的时间愈多，平行线程愿意补贴的代币越多使區塊被寫入的機會提高。 创建币过程的具体实施可以是通过本地的通胀或通过国库等资金储备。 + +Collators may be paid in local parathread currency. However, the Relay Chain transacts with the Polkadot universal currency (DOT) only. Collators must then submit block candidates with an associated bid in DOT. + +## 平行链插槽交换 + +It will be possible for a parachain that holds a parachain slot to swap this slot with a parathread so that the parathread "upgrades" to a full parachain and the parachain becomes a parathread. The chain can also stop being a chain and continue as a thread without swapping the slot. The slot, if unoccupied, would be auctioned off in the next [auction period](learn-auction). + +This provides a graceful off-ramp for parachains that have reached the end of their lease and do not have sufficient usage to justify renewal; they can remain registered on the Relay Chain but only produce new blocks when they need to. + +Parathreads help ease the sharp stop of the parachain slot term by allowing parachains that are still doing something useful to produce blocks, even if it is no longer economically viable to rent a parachain slot. + +## Resources + +- [Parathreads: Pay-as-you-go Parachains](https://medium.com/polkadot-network/parathreads-pay-as-you-go-parachains-7440d23dde06) diff --git a/website/translated_docs/zh-CN/learn-phragmen.md b/polkadot-wiki/translated_docs/zh-CN/learn-phragmen.md similarity index 100% rename from website/translated_docs/zh-CN/learn-phragmen.md rename to polkadot-wiki/translated_docs/zh-CN/learn-phragmen.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-polkadot-host.md b/polkadot-wiki/translated_docs/zh-CN/learn-polkadot-host.md new file mode 100644 index 000000000000..635f0195a369 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-polkadot-host.md @@ -0,0 +1,30 @@ +--- +id: learn-polkadot-host +title: Polkadot 组件 +sidebar_label: Polkadot 组件 +--- + +Polkadot 的架构可以分为两个不同的部分：Polkadot *runtime*和 Polkadot _主机_。 Polkadot runtime 是链的核心状态转变逻辑，可以在一段时间内升级而不需要硬分叉。 相比 Polkadot 的主机是执行 runtime 的环境并且保持稳定和在 Polkadot 的生命周期内保持静态状态。 + +The Polkadot host interacts with the Polkadot runtime in limited, and well-specified ways. For this reason, implementation teams can build an alternative implementation of the Polkadot host while treating the Polkadot runtime as a black box. For more details of the interactions between the host and the runtime, please see the [specification](https://github.com/w3f/polkadot-spec/). + +## Polkadot 主机组件 + +- 网络组件如 Libp2p 用于网络的交互 。 +- 狀態储存和 storage trie 与数据库 +- GRANDPA 和 BABE 的共识引擎。 +- Wasm 解析器和虚拟机. +- 底层原始的区块链功能例如像密码学的哈希函数。 + +编译了的 Polkadot runtime，Wasm 代码可以上传到 Polkadot 主机并用作执行状态转变的逻辑。没有 runtime，Polkadot 主机无法进行状态转变或生成任何区块。 + +## 图表 + +下面是显示了 Polkadot runtime 周围的 Polkadot 主机图表。试想像 runtime (白色) 作为是一个可以插入、交换或完全删除的组件。灰色中的部分是稳定的，如果没有明确的硬分叉，就不能更改。 + +![polkadot host](assets/updated_pre.png) + +## 资源 + +- [Polkadot Host Protocol Specification](https://github.com/w3f/polkadot-spec) - Incubator for the Polkadot Host spec, including tests. +- [ChainSafe's Go PH](https://github.com/ChainSafeSystems/go-pre) is a 25-person development team based in Toronto, Canada. ChainSafe is building an implementation of the beacon chain for Ethereum 2.0 client in TypeScript and this Go implementation of Polkadot. diff --git a/website/translated_docs/zh-CN/learn-proxies.md b/polkadot-wiki/translated_docs/zh-CN/learn-proxies.md similarity index 100% rename from website/translated_docs/zh-CN/learn-proxies.md rename to polkadot-wiki/translated_docs/zh-CN/learn-proxies.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-randomness.md b/polkadot-wiki/translated_docs/zh-CN/learn-randomness.md new file mode 100644 index 000000000000..bdcbb127fa2e --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-randomness.md @@ -0,0 +1,56 @@ +--- +id: learn-randomness +title: 随机性 +sidebar_label: 随机性 +--- + +权益证明(PoS)区块链的随机性对于验证人责任的公平并且不可预测的分配是非常重要。 ，因为计算机是确定性设备，所以它们在随机数方面很差(同样输入总是会产生同样输出)。大部份人通常在计算机上(例如游戏应用程序中)称随机数实际上是*伪随机*- 也就是说它们依赖用户或其他类型的*Oracle* 提供足够随机的*seed*，例如[气象站的大气噪声](https://www.random.org/randomness/), [心跳率](https://mdpi.altmetric.com/details/47574324)或什至[熔岩灯](https://en.wikipedia.org/wiki/Lavarand)，就可以从中产生一系列看似随机的数字。但是如果给相同的种子，结果将会是一样。 + +这些输入将根据时间和空间而变化，但是不可能将相同的结果输入到全球特定区块链的所有节点中。如果节点获得不同的输入以创建区块，则会发生分叉。显然现实世界中的熵不适合用作区块链随机性的种子。 + +至今区块链有二种可用的随机性方法: RANDAO 和 VRF。 Polkadot 使用 VRF。 + +## VRF + +可验证随机函数(VRF)是数学运算，需要一些输入并产生随机数以及该提交者生成该随机数的真实性证明。任何挑战者都可以验证该证明，以确保随机数生成有效。 + +Polkadot 中使用的 VRF 与 Ouroboros Praos 中的大致相同。 Ouroboros 随机性对于块生产来说是安全并对 BABE 来说效果很好。它们不同之处在于 Polkadot 的 VRF 不依赖于中央时钟(问题变了-谁的中央时钟?)，而是取决于它自己过去结果来确定现在和将来的结果，并且它使用插槽数字作为时钟模拟器估计时间。 + +具体操作如下: + +Slots are discrete units of time six seconds in length. Each slot can contain a block, but may not. Slots make up epochs - on Polkadot, 2400 slots make one epoch, which makes epochs four hours long. + +In every slot, each validator "rolls a die". They execute a function (the VRF) that takes as input the following: + +- **The "secret key",** a key specifically made for these die rolls. +- **An epoch randomness value,** which is The hash of VRF values from the blocks in the epoch before last (N-2), so past randomness has an effect on the current pending randomness (N). +- **时隙号** + +![](assets/VRF_babe.png) + +输出为两个数值: `RESULT`(随机值)和`PROOF`(证明随机数值已正确生成的证明)。 + +然后将`RESULT`与该协议实现中定义的*阈值 (threshold) *(在 Polkadot Host)进行比较。如果该值小于阈值，那么掷此数字的验证人将是可在该插槽的区块生产候选者。然后，验证人尝试创建一个区块，并将该区块与先前获得的`PROOF`和`RESULT`一起提交到网络中。 + +The fishermen - nodes watching the network for collator and validator wrongdoing - will be verifying Relay Chain blocks. Since an illegal roll will generate an illegal block, and since fishermen will have access to the `RESULT` and `PROOF` in every block produced by a validator, it'll be easy for them to automatically report cheating validators. + +总结: 在 VRF 中，每个验证人都会为自己掷出一个数字，并根据阈值对其进行检查，如果随机掷骰低于该阈值，则会生產區块。 钓鱼人监察网络并报告不良行为验证这些掷骰的有效性，并向系统报告任何作弊行为(例如尽管掷出的人数超过阈值，但有人假装成块生产區塊者)。 + +精明的读者会注意到，这种工作方式某些时隙可能没有验证人作为区块链生产者候选者，因为所有验证候选者的得分都太高而错过了阈值值。我们在[ wiki 共识页面](learn-consensus)中说明了如何解决此问题，并确保 Polkadot 出块时间保持在恒定时间。 + +## RANDAO + +[ RANDAO ](https://github.com/randao/randao) - RANDAO 要求每个验证人通过对某些种子执行一系列哈希操作来进行准备。 验证人然后在一个回合中发布最终的哈希值，加上随机数是从每个参与者进入游戏中得出。只要有一名诚实的验证人参加，随机性就被认为是安全（在经济上进行攻击是不可行）。Polkadot 不选用 VRF 的随机性方法是因为从每个区块生产者处揭示每个时隙的哈希值需要二次带宽或至少二次计算。 + +RANDAO 可选增加 VDF。 + +### VDFs + +[Verifiable Delay Functions](https://vdfresearch.org/) are computations that take a prescribed duration of time to complete, even on parallel computers. They produce unique output that can be independently and efficiently verified in a public setting. By feeding the result of RANDAO into a VDF, a delay is introduced that renders any attacker's attempt at influencing the current randomness obsolete. + +VDFs will likely be implemented through ASIC devices that need to be run separately from the other types of nodes. Although only one is enough to keep the system secure, and they will be open source and distributed at nearly no charge, running them is neither cheap nor incentivized, producing unneccessary friction for users of the blockchains opting for this method. + +## 资源 + +- [ Polkadot 对区块链随机性的研究](https://research.web3.foundation/en/latest/polkadot/BABE/Babe.html) - 包含做出选择的理由以及证明 +- [关于 Polkadot 中使用随机性的讨论](https://github.com/paritytech/ink/issues/57) - W3F 研究人员讨论了 Polkadot 中的随机性，何时用以及在哪些假设下进行。 diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-registrar.md b/polkadot-wiki/translated_docs/zh-CN/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-relevant-links.md b/polkadot-wiki/translated_docs/zh-CN/learn-relevant-links.md new file mode 100644 index 000000000000..37ee618f2a36 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-relevant-links.md @@ -0,0 +1,114 @@ +--- +id: learn-relevant-links +title: 链接 +sidebar_label: 链接 +--- + +## 协议 + +### 概述 + +- [Substrate, Polkadot & The Case for On-Chain Governance](https://www.youtube.com/watch?v=eP4mT19S_jg) - Epicenter interviews Gavin Wood. +- [Blockchain Infrastructure](https://softwareengineeringdaily.com/2018/11/26/parity-blockchain-infrastructure-with-gavin-wood/) - Gavin Wood presents Substrate on Software Daily. +- [Polkadot on Zero Knowledge](https://www.zeroknowledge.fm/46) - Gavin Wood chatted about the history of Polkadot and provided a great overview on Zero Knowledge podcast. +- [Epicenter and Polkadot](https://www.youtube.com/watch?v=oiunBLGHlAU) - Epicenter interviews Peter Czaban of Web3 Foundation about Polkadot. +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Interoperability Intro](https://www.youtube.com/watch?v=RSAFHhTwA8Q) - Rob Habermeier presents "Interoperability: Connecting the Dots." +- [Consensus and Finality in Polkadot](https://www.youtube.com/watch?v=qvoAf2uIF3c) - Talk by Rob Habermeier detailing the consensus mechanism for Polkadot. +- [DOT Day Seoul](https://www.youtube.com/playlist?list=PLOyWqupZ-WGt3mA_d9wu74vVe0bM37-39) - Video playlist of all talks at DOT Day Seoul. + +### Kusama + +- [Kusama 首页](https://kusama.network/) Polkadot 的金丝雀网络(Kusama)所有内容的页面。 +- [Kusama 用户指南](https://guide.kusama.network)Kusama 特定信息的来源。 +- [ Kusam 认领](https://claim.kusama.network/)供 DOT 持有者认领 Kusama 代币的资料。 +- [ Kusama 发布公告](https://medium.com/polkadot-network/kusama-network-7446706b8f4c) Kusama 网络的第一条公告。 + +### Substrate + +- [什么是 Substrate?](https://medium.com/paritytech/what-is-substrate-29af4231d7e0)-介绍用于搭建 Polkadot 的框架。 +- [ Parity Substrate ](https://github.com/paritytech/substrate)-第一个用 Rust 编写。Parity Technologies 是一支 75 人的开发团队，总部位于英国和德国。 Parity 的技术负责运行以太坊的主要客户端，为网络中 40％的节点服务。 Parity 还为[比特币](https://github.com/paritytech/parity-bitcoin)维护客户端，并为[Zcash ](https://github.com/ZcashFoundation/zebra)建立客户端。 +- [Substrate Developer Hub](https://substrate.dev/docs/en/) - Overviews, tutorials and reference documentation for Substrate. +- [Substrate 介绍](https://youtu.be/iUMZyL5kTwc)-Gavin Wood 博士介绍 Substrate ，这是 Polkadot 的底层技术。 +- [Substrate 与 Polkadot 的关系](https://medium.com/polkadot-network/a-tale-of-two-technologies-presentation-transcript-e7397c1c7a49) - 关于两种技术的详细描述 +- [Polkadot & Substrate 概述](https://www.youtube.com/watchv=0iouzddi5is&feature=youtu.be)-Gavin Wood 博士展示了 Substrate（区块链框架 + VM）和 Polkadot，并在 15 分钟内用 Substrate 构建可行的区块链系统 +- [为 Polkadot 的 Substrate 发布做准备](https://medium.com/polkadot-network/preparing-for-polkadots-launch-with-substrate-cb97819ed815)-如何在发布之前开始准备 Polkadot 的概述。 +- [A brief summary of everything Substrate and Polkadot](https://medium.com/polkadot-network/a-brief-summary-of-everything-substrate-and-polkadot-f1f21071499d) - Blog post that recaps information regarding Substrate and Polkadot. +- [在 Substrate](https://www.youtube.com/watch?v=IRc5Jma_eH8) - Gavin Wood 视频上提供 Substrate 的路线图摘要和 MelonportM-1 会议在 Polkadot 上的更新。 +- [The Relationship between Rust, Substrate and Polkadot](https://www.youtube.com/watch?v=aVW_eG-IH7o&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=8) - Logan Saether, from the technical education team presents a technical explaination of the relationship between Rust, Substrate and Polkadot. + +### 治理 + +- [治理](learn-governance) - 治理系统概述。 +- [治理演示](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734)-Gavin wood 博士介绍了 Polkadot 的初始治理结构。(视频) +- [Kusama 推出和治理](https://polkadot.network/kusama-rollout-and-governance/)-关于 Kusama 金丝雀网络的治理信息。 +- [Polkadot 上的治理](https://www.crowdcast.io/e/governance-on-polkadot--) - 网络研讨会解释治理如何在 Polkadot 和 Kusama 中起作用。 + +### 共识与确定性 + +- [ GRANDPA 确定性工具](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf)-Polkadot 的确定性工具。 + +### 研究 + +- [ W3F 研究](https://research.web3.foundation)-Web3 基金会研究中心。 + +## 开发 + +- [在 Polkadot 构建的团队](https://forum.web3.foundation/t/teams-building-on-polkadot/67)-在 Polkadot 上 构建的团队名单。 + +### Kusama + +- [在 Polkadot 构建的团队](https://forum.web3.foundation/t/teams-building-on-polkadot/67)-在 Polkadot 上 构建的团队名单。 +- [样式指南](https://github.com/paritytech/polkadot/wiki/Style-Guide)-为 Polkadot 的 Rust 做贡献。 + +### Polkadot Host + +- [ Polkadot Host 规范](https://github.com/w3f/polkadot-re-spec/blob/master/polkadot_re_spec.pdf)- Polkadot Host 的完整规范。 +- [ Polkadot.js ](https://polkadot.js.org/)-JS 中的工具和客户端。Polkadot JS 是由德国的三人团队开发，正在构建 Polkadot 的 JavaScript 实现。 +- [ChainSafe's Go PH](https://github.com/ChainSafeSystems/go-pre) is a 25-person development team based in Toronto, Canada. ChainSafe is building an implementation of the beacon chain for Ethereum 2.0 client in TypeScript and this Go implementation of Polkadot. + +### Cumulus + +- [ Cumulus ](https://github.com/paritytech/cumulus)-使 Substrate 构建的链与 Polkadot 兼容的库。 +- [Cumulus: 深入学习](https://www.youtube.com/watch?v=thgtXq5YMOo)-Polkadot 联合创始人 Robert Habermeier 于 2019 年 3 月在 EthCC 上的讲话，详细介绍 Cumulus 与平行链的最新进展。 + +### Substrate + +- [ Parity Substrate ](https://github.com/paritytech/substrate)-第一个用 Rust 编写。Parity Technologies 是一支 75 人的开发团队，总部位于英国和德国。 Parity 的技术负责运行以太坊的主要客户端，为网络中 40％的节点服务。 Parity 还为比特币维护客户端，并为 Zcash 建立客户端。 +- [Parity Wasm](https://github.com/paritytech/parity-Wasm)- Rust 中的 WebAssembly 序列化/反序列化。 +- [ Wasm utils ](https://github.com/paritytech/Wasm-utils)-用于 Parity 和 Wasm 合同开发的 Wasm 实用程序合集。 + +### Cumulus + +- [ Rust libp2p ](https://github.com/libp2p/rust-libp2p)- libp2p 网络堆栈的 Rust 实现。 + +### Wasm + +- [Parity Bridge](https://github.com/paritytech/parity-bridge)-任意两个基于以太坊的网络之间的转接桥。 + +## 运行节点 + +- [安装 Kusama ](https://github.com/paritytech/polkadot#22-install-kusama-canary-network)-安装 Polkadot 的客户端并连接到 Kusama 金丝雀网络。 +- [Substrate 节点](https://github.com/paritytech/substrate#joining-the-dried-danta-testnet) -在 Dry-Danta 测试网上安装并运行 Substrate 节点。 + +### 用户界面与浏览器 + +- [Polkadot 浏览器](https://polkadot.js.org/apps/#/explorer)-Polkadot 网络浏览器，可用于 Alexander、Kusama 网络或您的网络。 +- [Telemetry](http://telemetry.polkadot.io/)-节点的信息服务网站。 +- [ Polkascan ](http://polkascan.io/) - Polkadot 的中继链和 Parity Substrate 链上的实时多链数据。 +- [Subscan.io](https://subscan.io) - 基于 Substrate 链的资源管理器。 + +### Crowdcast 网络研讨会 + +- [Polkadot 首页](https://www.crowdcast.io/polkadot) - Web3 基金会所有过去 Crowdcast 网络研讨会的列表。 +- [Polkadot 上的治理](https://www.crowdcast.io/e/governance-on-polkadot--) - 网络研讨会解释治理如何在 Polkadot 和 Kusama 中起作用。 +- [Kusama](https://www.crowdcast.io/e/qpz8aran) - Anson Lau 的 Kusama 概述。 +- [Polkadot 上的出块和最终确定性](https://www.crowdcast.io/e/polkadot-block-production) - Bill Laboon 解释在 Kusama BABE 和 GRANDPA 如何一起运作出块和区块确定性。 +- [在 Polkadot 上验证](https://www.crowdcast.io/e/validating-on-polkadot) - 讲解如何在 Polkadot 上验证 与 Joe Petrowski 和 Equity Technologies 的 David Dorgan 以及 与 Staked 的 Tim Ogilvie 合作。 +- [了解 Polkadot 中的账户和密钥](https://www.crowdcast.io/e/polkadot-keys) - 解释在 Polkadot 中使用的不同类型的账户和密钥 - Bill Laboon 和 BlockX Labs 的 Chinmay Patel。 +- [参与 Kusama](https://www.crowdcast.io/e/participating-on-kusama) - 如何参与 在 Kusama 不同的角色 - Logan Saether 。 +- [开发应用程序与 Polkadot 交互](https://www.crowdcast.io/e/developing-apps-on-polkadot) 。Bill Laboon 讲解如何通过 Polkadot API 编写你自己的脚本和程序与 Polkadot 交互。 +- [将 Web3 登录添加到 Web2.0 应用程序](https://www.crowdcast.io/e/web3-logins-workshop) Bruno Skvorc 解释如何将登录过程添加到 Web2.0 应用程序中。 +- [A Distributed Drawing Program on Kusama](https://www.crowdcast.io/e/distributed-drawing) - Expanding on his previous talk, Bill Laboon uses Shawn Tabrizi's `remarkable` codebase to make a node.js app that listens to the Kusama chain and allows users to set pixels to programmatically draw a shared picture. diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-roadmap.md b/polkadot-wiki/translated_docs/zh-CN/learn-roadmap.md new file mode 100644 index 000000000000..5eb27cb89b3f --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-roadmap.md @@ -0,0 +1,24 @@ +--- +id: learn-roadmap +title: 路线图 +sidebar_label: 路线图 +--- + +## Polkadot 发布 + +Polkadot 预计将于今年年底发布。 + +## 路线图 + +随着新功能的完成和推出，Polkadot 目前正在经历一系列概念验证测试网版本。此外，Kusama 是个金丝雀网络，可以测试早期未经审核 Polkadot 版本的经济状况，以帮助理解 Polkadot 最终的目标。 + +- Polkadot Genesis - 预期 2020 年中。 +- Kusama - [公告](https://polkadot.network/kusama-network-the-canary-network/)于 2019 年 7 月 16 日。[创世块](https://polkadot.network/kusama-rollout-and-governance/)，于 2019 年 8 月 23 日。[Kusama CC2 ](https://polkadot.network/kusama-cc2/)，于 2019 年 9 月 26 日发布 。 +- Westend - (2020 年 1 月发布) - 基于当前 Kusama codebase 的测试网。 +- PoC-4（发布日期为 2019 年 4 月 3 日）-_抵押改变和 GRANDPA 优化_ 博客文章 +- PoC-3(于 2018 年 12 月 21 日发布) - 添加了* GRANDPA 最终决定性工具。 测试网："Alexander" * [发布博客文章 ](https://medium.com/coinmonks/polkadot-hello-world-3-poc-3-on-substrate-is-here-c45d100f72e3) +- BBQ-Birch 测试网（上线时间：2018 年 10 月 15 日）：_添加了智能合约支持。_ +- PoC-2 (于 2018 年 7 月 29 日发布) - _添加了对平行链的支持， 奖励和惩罚已添加到 PoS 共识算法中。 测试网: "Krumme Lanke"。 首次通过治理进行自动升级。_ [发布博客文章](https://medium.com/polkadot-network/polkadot-poc-2-is-here-parachains-runtime-upgrades-and-libp2p-networking-7035bb141c25) +- PoC-1 (Released 16 May 2018, Testnet went live 18 May 2018) - _Initial proof of concept - included basic state transition engine for Relay Chain and on-chain governance._ [Release Blog Post](https://medium.com/polkadot-network/now-live-polkadot-proof-of-concept-1-3e718512a8d) + +有关 Polkadot 路线图和 Polkadot 代码库状态的最新信息，请参阅 Polkadot GitHub 库，尤其是里程碑页面：[ https://github.com/paritytech/polkadot/milestones ](https://github.com/paritytech/polkadot/milestones) diff --git a/website/translated_docs/zh-CN/learn-scams.md b/polkadot-wiki/translated_docs/zh-CN/learn-scams.md similarity index 100% rename from website/translated_docs/zh-CN/learn-scams.md rename to polkadot-wiki/translated_docs/zh-CN/learn-scams.md diff --git a/website/translated_docs/zh-CN/learn-security.md b/polkadot-wiki/translated_docs/zh-CN/learn-security.md similarity index 100% rename from website/translated_docs/zh-CN/learn-security.md rename to polkadot-wiki/translated_docs/zh-CN/learn-security.md diff --git a/website/translated_docs/zh-CN/learn-simple-payouts.md b/polkadot-wiki/translated_docs/zh-CN/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/zh-CN/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/zh-CN/learn-simple-payouts.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-spree.md b/polkadot-wiki/translated_docs/zh-CN/learn-spree.md new file mode 100644 index 000000000000..6e6de5ddbacd --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-spree.md @@ -0,0 +1,51 @@ +--- +id: learn-spree +title: SPREE +sidebar_label: SPREE +--- + +Shared Protected Runtime Execution Enclaves (SPREE) sometimes referred to as "trust wormholes," are fragments of logic comparable to runtime modules in Substrate, but live on the Polkadot Relay Chain and may be opted into by parachains. + +SPREE 简要地描述了以下属性和功能： + +- 平行链可以选择加入特殊的 Runtime 逻辑（例如智能合约）。 +- 这些碎片有自己的存储空间和自己的 [XCMP](learn-crosschain) 端点。 +- 跨链的所有实例具有相同的逻辑。 +- It executes alongside parachain logic. +- 受保护：存储不能通过平行链逻辑更改，消息不能被平行链伪造。 + +## 起源 + +On 28 March, 2019 u/Tawaren, a member of the Polkadot community, made a post on [r/dot](https://www.reddit.com/r/dot/) called "SmartProtocols Idea" and laid out a proposal for [Smart Protocols](https://www.reddit.com/r/dot/comments/b6kljn/smartprotocols_idea/). The core insight of the post was that XCMP had a complication in that it was difficult to verify and prove code was executed on a parachain without trust. A solution was to install the SmartProtocols in the Relay Chain that would be isolated blobs of code with their own storage per instance that could only be changed through an interface with each parachain. SmartProtocols are the precursor to SPREE. + +## 什么是 SPREE 模块？ + +SPREE modules are fragments of logic (in concrete terms they are blobs of [WebAssembly](learn-wasm) code) that are uploaded onto Polkadot through a governance mechanism or by parachains. Once the blob is uploaded to Polkadot, all other parachains can decide to opt-in to the logic. The SPREE module would retain its own storage independent of the parachain, but would be callable through an interface with the parachain. Parachains will send messages to the SPREE module synchronously. + +SPREE 模块对整个 XCMP 结构非常重要，因为它为将在目标平行链上执行。虽然 XCMP 保证消息的传递，但它不保证什么代码将执行，即接收平行链将如何解释消息。XCMP 实现去信任传递消息，SPREE 是 XCMP 效用的关键部分。 + +SPREE 模块就像食谱。 例如如果我们向厨师下令制作舒芙蕾，对厨师的能力非常有信心，我们对将要做的事情有模糊的想法，但实际上并不确定如何做。 但是假设某位厨师的书架上有 "SouffléMaker's 手册"，自己只能从这本书制作舒芙蕾。 现在我们还可以查阅厨师所拥有的一本书，了解当我们告诉厨师做舒芙蕾时会发生什么。 在此示例中" 制作舒芙蕾" 是 XCMP 的信息而菜谱是 SPREE 模块。 + +In concrete terms, SPREE modules could be useful for various functionality on Polkadot. One suggested use case of SPREE modules is for a trustless decentralized exchange that is offered as functionality to any parachain without any extra effort from parachain developers. One can imagine this working by having a SPREE module that exposes the interface for the incrementing and decrementing of balances of various assets based on a unique identifier. + +## 为什么? + +Sending messages across parachains in XCMP only ensures that the message will be delivered but does not specify the code that will be executed, or how the message will be interpreted by the receiving parachain. There would be ways around this such as requesting a verifiable receipt of the execution from the receiving parachain, but in the naked case the other parachain would have to be trusted. Having shared code that exists in appendices that the parachain can opt-in to resolves the need for trust and makes the execution of the appendices completely trustless. + +SPREE 将有助于确保在 SPREE 模块平行链之间共享相同的逻辑。一个特别相关的用例将围绕跨平行链代币转移，在发送和接收平行链就如何更改代币的总供应量和基本接口达成一致非常重要。 + +## 例子 + +![spree example](assets/SPREE/spree_module.png) + +上图是简化 Polkadot 的系统。 + +In this diagram we see that the Wasm code for SPREE module "X" has been uploaded to the Polkadot Relay Chain. The two cylinders "A" and "B" represent two distinct parachains that have both opted-in to this SPREE module creating two distinct instances of it with their own XCMP endpoints "A.X" and "B.X". + +在示例中，我们假设此 SPREE 模块 "X" 包含用于递增或递减该模块特定资产的余额。 + +通过在 A.X 处发起交易以将特定余额减少 1，XCMP 上的消息可以去信任发送到 B.X 以使余额增加 1。 + +Collators, represented as the green triangle are responsible for relaying this message from parachain A to parachain B, as well as mantaining the storage for each particular instance of A.X and B.X for their respective parachains. They provide proofs of valid state transitions to the Relay Chain validators, represented as blue diamonds. + +验证人可以通过提供之前的 SPREE 模块实例的状态根和实例之间的 XCMP 消息的数据以及实例的下一个状态根去验证 SPREE 模块的 A.X 和 B.X 正确状态转换。它们执行此验证是对照 SPREE 模块提供的`验证`函数对其进行检查 API。收集人是需要能够提供此信息，以便处理其平行链。 diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-staking.md b/polkadot-wiki/translated_docs/zh-CN/learn-staking.md new file mode 100644 index 000000000000..e007697d30b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: 抵押 +sidebar_label: 抵押 +--- + +波卡(Polkadot) 使用 NPoS(提名权益证明)机制选择验证人，该机制为了**验证人**和 **提名人**两种角色，以实现链安全性的最大化。对网络维护感兴趣的参与者可以负责运行验证人节点。在创世区块中，波卡链将为验证人提供有限位置，位置数量将逐步增加至 1000 以上。 + +系统鼓励 DOT 持有者作为提名人参与。提名人可以支持最多 16 个他们相信的验证候选人。 + +验证人角色是在 [BABE](learn-consensus#babe) 负责生成区块，验证平行链区块和确保最终性。提名人可以根据验证人抵押量而作选择。 + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## Polkadot 抵押的运作方式 + +### 1. 确定身份 + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. 提名期 + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. 抵押奖励分配 + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. 奖励机制 + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- 验证人本身不持有权益。 +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **验证人池 A** | | | +| :--------: | :------------: | :----------: | :--: | +| 提名人 (4) | 权益 (600) | 所占总权益比 | 奖励 | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **验证人池 B** | | | +| :--------: | :------------: | :----------: | :--: | +| 提名人 (4) | 权益 (400) | 所占总权益比 | 奖励 | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## 账户 + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** 这帐户储存资金用作绑定 DOTs 参与抵押，但将某些功能委托给 Controller。因此使用 Controller 可以积极参与，其保存 Stash 密钥在冷钱包中，这意味着它永远保持离线状态。您还可以指定代理帐户，对[治理](./learn-governance)议案进行投票。 +- **Controller** 这帐户是代表 Stash 帐户负责发出有关提名和验证的操作。它用于设置奖励发送到那个帐户和佣金。如果你是验证人，它亦用作设定[ session 密钥](learn-keys#session-keys)，并只需要足够的资金来支付交易费用。 + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## 验证人和提名人 + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## 惩罚 (Slashing) + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + 设 x = 出错节点, n = 验证人总数 + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- 提名人可以提名多个验证人，然后通过其中任何一个将惩罚。 +- 在惩罚之前，抵押在各个时代都可以重复使用。 连续提名 E 个时代的 N 币并不意味着您要惩罚 N\*E 币 - 您只有 N 币。 +- 惩罚可在事实发生后发现。 + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## 奖励分配 + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### 领取奖励 + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### 奖励分配例子 + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## 通胀率 + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-轴**: 通货膨胀, 年度化百分比 +- **蓝线**: 参与抵押者的通涨奖励 +- **绿线**: 抵押参与者的收益率 + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## 为什么参与抵押? + +- 当主网上线，每年 10% 通胀率 +- 目标抵押为 50％ +- ~20% 年回报 + +## 为什么不参与抵押? + +- 代币解锁在 Kusama 需要 7 天，而 Polkadot 则是 28 天。 +- 如果发现验证人行为不当，将执行处罚（请参见[ #slashing ](#slashing)）。 +- 您将想代币用于平行链插槽。 + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## 资源 + +- [NPoS 在 Polkadot 怎么运作](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Web3 基金会研究员 Alfonso Cevallos 描述 NPoS 在 Polkadot 的博客文章 +- [设置安全验证人](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-transaction-fees.md b/polkadot-wiki/translated_docs/zh-CN/learn-transaction-fees.md new file mode 100644 index 000000000000..9f2d5b7c0cf1 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-transaction-fees.md @@ -0,0 +1,85 @@ +--- +id: learn-transaction-fees +title: 交易费用 +sidebar_label: 交易费用 +--- + +区块链网络中的资源是有限的，例如存储和计算。交易费用是用来防止用户消耗太多资源。 Polkadot 使用基于权重的收费模式，而不是 gas-metering 模式。 因此在执行交易之前需要先收取费用；一旦费用支付，节点将执行交易。 + +[Web3 Foundation Research](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html) designed the Polkadot fee system with the following objectives: + +- 每个中继链的区块链应该有效地处理从而被免延迟生成区块链。 +- 中继链的增长率应该有界限。 +- 每个区块都应有空间给特殊高优先的交易，例如不当行为报告。 +- 该系统应能够处理需求激增的问题。 +- 费用应缓慢变化，以便用户可以准确预测既定交易的费用。 + +## 费用计算 + +Polkadot 中继链的费用是根据以下四个参数计算的: + +- 每字节费用 (亦称"长度费") +- 比重费用 +- 小费(可选) + +长度费是每字节的固定费用和交易的字节大小的结果。 + +Weights are a fixed number designed to manage the time it takes to validate a block. Each transaction has a base weight that accounts for the overhead of inclusion (e.g. signature verification) as well as a dispatch weight that accounts for the time to execute the transaction. The total weight is multiplied by a per-weight fee to calculate the transaction's weight fee. + +小费是一种可选的交易费，用户可以添加来给予交易更优先的处理。 + +这四个费用共同构成了费用。在执行交易之前，将从用户的帐户中扣除这笔费用。一部分费用将给区块生成者，其余部分将流向[库房](learn-treasury)。在 Polkadot 的一开始阶段，该比例分别设置为 20％和 80％。 + +## 区块限制和交易优先 + +Polkadot 中的区块既有最大长度(字节)，也有最大比重。区块生产者将用这些限制填满交易到方块。每个区块的一部分―目前为 25%―保留给与该区块操作相关的重要交易。区块生产者将只能使用区块正常交易的 75%。一些操作交易例子： + +- 错误报告 +- 议会操作 +- 选举中的成员操作(例如放弃候选人) + +区块生产者根据每笔交易的总费用确定交易的优先次序。由于部分费用将给区块生产者，生产者将打包最高费用的交易，以获得最大回报。 + +## 费用调整 + +区块链上的交易量非常不正常，因此交易费用需要一种调整机制。然而，用户应该能够预测交易费用。 + +Polkadot 使用缓慢调整费用机制并提供小费来平衡这两个考虑。除了区块链*限制，* Polkadot 还有阻止填满的*目标。*根据当前区块相对于目标的充满度，下一个区块链的费用增加或减少。每次比重收费可在 24 小时内提高 30％，这个比率反映出需求的长期趋势， 为了考虑短期跳跃，Polkadot 在底线，字节和重量费用上使用小费。用户可以选择在收费中添加小费，给予交易更高的优先等级。 + +## 分片交易 + +在 Polkadot 的分片中进行的交易 - 平行链和对平行线程 - 不会引起中继链交易费用。 分片应用程序的用户甚至不需要持有 DOT， 因为每个分片都有自己的经济模式，可能有代币，也可能没有代币。 然而在有些情况下，这些人自己在中继链上进行交易。 + +[Parachains](learn-parachains) have a dedicated slot on the Relay Chain for execution, so their collators do not need to own DOT in order to include blocks. The parachain will make some transactions itself, for example, opening or closing an [XCMP](learn-crosschain) channel, participating in an [auction](learn-auction) to renew its slot, or upgrading its runtime. Parachains have their own accounts on the Relay Chain and will need to use those funds to issue transactions on the parachain's behalf. + +[Parathreads](learn-parathreads) will also make all the same transactions that a parachain might. In addition, the collators need to participate in an auction every block to progress their chain. The collators will need to have DOT to participate in these auctions. + +## 其他资源限制策略 + +交易比重必须在执行前可以计算，因此只能是固定逻辑。有些交易需要通过其他策略限制资源。例如: + +- 绑定(Bonds)：有些交易，如投票，有可能需要绑定保证金， 并在链上发生事件后退还或惩罚。 在投票的例子中，选举结束时返回，或者如果选民试图恶意行事，就会被惩罚。 +- 存款(Deposits): 有些交易, 如设置[身份](learn-identity) 或认领索引, 无限期地使用存储空间。 如果用户决定释放存储空间，这些存款将会被退还。 +- 烧毁(Burns)：交易可能会根据其内部逻辑烧毁资金。例如如果交易创建了新的存储，从而增加了状态容量，则交易可能会从用户那里烧毁资金。 +- Limits: Some limits are part of the protocol. For example, nominators can only nominate 16 validators. This limits the complexity of [Phragmén](learn-phragmen). + +## 进阶 + +此页面仅涵盖来自普通用户的交易。 不过，如果你看到區塊鏈浏览器的區块，你可能会看到一些"extrinsics"看起来与这些交易不同。 在 Polkadot (以及建立在 Substrate 上的任何链)中，extrinsic 在是一种来自链外的信息。 Extrinsics 可分为三类： + +- 签名交易 +- 无签名交易 +- Inherents + +此页面仅覆盖已签名的交易(signed transactions)，这是大多数用户与 Polkadot 互动的方式。 有签名的交易来自有资金的帐户，因此 Polkadot 可以收取交易费作为防止垃圾邮件的问题。 + +无签名的交易(unsigned transactions) 是指用户需要提交不控制资金的密钥对外在的特殊情况。 例如当用户在上线后 [领取他们的 DOT ](https://claims.polkadot.network) 他们的 DOT 地址还没有任何资金，因此是用了无签名的交易。验证人也会提交一些无签名的交易，其形式为 "heartbeat" 消息，表示它们在线。 这些 heartbeat 必须由验证人 [session keys 之一](learn-keys)签名。 Session keys 永远不会控制资金。 无签名的交易仅用于特殊情况，因为既然 Polkadot 无法为它们收取费用，每个交易需要自定义的验证逻辑。 + +最后，inherents 是没有签名或包含在交易队列中的信息。 因此，只有出块的人才能将固有的东西添加到区块中。 因为仅仅足够多的验证人已经同意它们是合理，就假定不信守者为 "真理"。 例如 Polkadot 区块包括固有的时间戳。 没有办法证明时间戳是真实的，可以证明有签字的资金的发出。 相反验证人根据他们认为时间戳的合理程度接受或拒绝区块。 在《Polkadot》中，它必须在他们自己的系统时钟的某个可接受范围之内。 + +## 了解更多 + +- [Web3 Foundation Research](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html#relay-chain-transaction-fees-and-per-block-transaction-limits) +- [Substrate Weights](https://substrate.dev/docs/en/knowledgebase/learn-substrate/weight) +- [Substrate 费用](https://substrate.dev/docs/en/knowledgebase/runtime/fees) +- [交易 (Extrinsics)](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics) diff --git a/website/translated_docs/zh-CN/learn-transactions.md b/polkadot-wiki/translated_docs/zh-CN/learn-transactions.md similarity index 100% rename from website/translated_docs/zh-CN/learn-transactions.md rename to polkadot-wiki/translated_docs/zh-CN/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-treasury.md b/polkadot-wiki/translated_docs/zh-CN/learn-treasury.md new file mode 100644 index 000000000000..81b3fcfca038 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- 基础架构部署 +- 网络安全操作(监视服务，审核)。 +- 生态系统发展(与友好链的合作)。 +- 推广活动(广告，合作)。 +- 社区活动(聚会，比萨派对，黑客空间)。 +- 软件开发(钱包和钱包整合，客户端升级)。 + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/polkadot-wiki/translated_docs/zh-CN/learn-validator.md b/polkadot-wiki/translated_docs/zh-CN/learn-validator.md new file mode 100644 index 000000000000..983200158fd2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/learn-validator.md @@ -0,0 +1,47 @@ +--- +id: learn-validator +title: 验证人 +sidebar_label: 验证人 +--- + +Validators secure the Relay Chain by staking DOT, validating proofs from collators and participating in consensus with other validators. + +这些参与者将在向中继链以及所有平行链添加新区块方面发挥关键作用。这允许各方通过中继链完成跨链交易。 + +Validators perform two functions. First, verifying that the information contained in an assigned set of parachain blocks is valid (such as the identities of the transacting parties and the subject matter of the contract). Their second role is to participate in the consensus mechanism to produce the Relay Chain blocks based on validity statements from other validators. Any instances of non-compliance with the consensus algorithms result in punishment by removal of some or all of the validator’s staked DOT, thereby discouraging bad actors. Good performance, however, will be rewarded, with validators receiving block rewards (including transaction fees) in the form of DOT in exchange for their activities. + +## 指南 + +- [How to Validate on Polkadot](maintain-guides-how-to-validate-polkadot) - Guide on how to set up a validator on the Polkadot live network. +- [验证人奖励发放概述](maintain-guides-validator-payout) - 简短概述验证人奖励发放机制原理。 +- [如何将验证人程序作为 systemd 进程运行](maintain-guides-how-to-systemd)-有关将验证人程序作为`systemd`进程运行的指南 ，使它在背后运行，并当重新启动时自动启动。 +- [如何升级您的验证人](maintain-guides-how-to-upgrade) - 当要转换到另一台计算机或运行最新版本的客户端时 - 升级验证人指南。 +- [如何使用安全验证人设置](maintain-guides-how-to-use-polkadot-secure-validator) - 关于如何使用 Polkadot / Kusama 安全验证器设置的指南 。 + +## 其他参考 + +- [如何运行 Polkadot 节点 (Docker)](https://medium.com/@acvlls/setting-up-a-maintain-the-easy-way-3a885283091f) +- [Web 3.0 验证人节点的无服务器故障转移解决方案](https://medium.com/hackernoon/a-serverless-failover-solution-for-web-3-0-validator-nodes-e26b9d24c71d) - 博客详细介绍了如何创建可靠的故障转移解决方案运行验证人。 +- [云服务器清单](maintain-guides-how-to-validate-kusama#vps-list) +- [Polkadot 验证人休息室](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 验证人聊天室。 +- [ 惩罚(Slashing)后果](https://wiki.polkadot.network/docs/en/learn-staking#slashing) -了解更多有关运行验证人节点惩罚(Slashing)的后果。 +- [Why You Should be A Validator on Polkadot and Kusama](https://www.youtube.com/watch?v=0EmP0s6JOW4&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=2) +- [Roles and Responsibilities of a Validator](https://www.youtube.com/watch?v=riVg_Up_fCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=15) +- [Validating on Polkadot](https://www.crowdcast.io/e/validating-on-polkadot) - An explanation of how to validate on Polkadot, with Joe Petrowski and David Dorgan of Parity Technologies, along with Tim Ogilvie from Staked. + +## 安全 / 密钥管理 + +- [验证人安全概览](https://github.com/w3f/validator-security) + +## 监控工具 + +- [PANIC for Polkadot](https://github.com/SimplyVC/panic_polkadot) - Polkadot / Kusama 节点的监视和警报方案 +- [Polkadot Telemetry 服务](https://telemetry.polkadot.io/#list/Kusama%20CC3) - 网络信息，包括在某一条链上有什么节点在运行，正在运行的版本以及同步状态。 +- [其它有用链接](https://forum.web3.foundation/t/useful-links-for-validators/20) + +## 验证人统计 + +- [HashQuark Staking Strategy](https://polkacube.hashquark.io/#/polkadot/strategy) - The HashQuark staking strategy dashboard helps you choose the optimal set-up to maximize rewards, and provides other useful network monitoring tools. +- [ Polkastats ](https://polkastats.io/) - Polkastats 是验证程序的精心设计的网页 +- [YieldScan](https://yieldscan.onrender.com/) - Staking yield maximization platform, designed to minimize effort. +- [ Subscan 验证人页面](https://kusama.subscan.io/validator) - 显示当前验证人的信息 - 不像其他站点那样适合验证人。 diff --git a/website/translated_docs/zh-CN/learn-wasm.md b/polkadot-wiki/translated_docs/zh-CN/learn-wasm.md similarity index 100% rename from website/translated_docs/zh-CN/learn-wasm.md rename to polkadot-wiki/translated_docs/zh-CN/learn-wasm.md diff --git a/website/translated_docs/zh-CN/maintain-collator.md b/polkadot-wiki/translated_docs/zh-CN/maintain-collator.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-collator.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-collator.md diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-errors.md b/polkadot-wiki/translated_docs/zh-CN/maintain-errors.md new file mode 100644 index 000000000000..120d6d31b8bc --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-errors.md @@ -0,0 +1,277 @@ +--- +id: maintain-errors +title: 出现错误如何解决 +sidebar_label: 解决错误 +--- + +Errors in Substrate-based chains are usually accompanied by descriptive messages. However, to read these messages, a tool parsing the blockchain data needs to request _chain metadata_ from a node. That metadata explains how to read the messages. One such tool with a built-in parser for chain metadata is the [Polkadot-JS Apps UI](https://polkadot.js.org/apps). + +If this page does not answer your question, try searching for your problem at the [Polkadot Knowledge Base](https://support.polkadot.network/) for more information on troubleshooting your issue. + +## PolkadotJS Apps 浏览器 + +Here's how to find out the detailed error description through Polkadot-JS Apps. + +A typical failed transactions looks something like this: + +![Error while sending a transaction](/img/errors/01.jpg) + +The image displays only the error name as defined in the code, not its error message. Despite this error being rather self-explanatory, let's find its details. + +In the [explorer tab](https://polkadot.js.org/apps/#/explorer), find the block in which this failure occured. Then, expand the `system.ExtrinsicFailed` frame: + +![Error described](/img/errors/02.jpg) + +Notice how the `details` field contains a human-readable description of the error. Most errors will have this, if looked up this way. + +[This block](https://polkadot.js.org/apps/#/explorer/query/0xa10104ed21dfe409c7871a975155766c5dd97e1e2ac7faf3c90f1f8dca89104b) is a live example of the above. + +If you cannot look up the error this way, or there is no message in the `details` field, consult the table below. + +## Polkascan and Subscan + +Polkascan and Subscan show the `ExtrinsicFailed` event when a transaction does not succeed ([example](https://polkascan.io/polkadot/event/2836233-3)). This event gives us the `error` and `index` indices of the error but does not give us a nice message to understand what it means. We will look up the error in the codebase ourselves to understand what went wrong. + +First, we should understand that the `index` number is the index of the pallet in the runtime from which the error originated. The `error` is likewise the index of that pallet's errors which is the exact one we're looking for. Both of these indices start counting from 0. + +For example, if `index` is 5 and `error` is 3, as in the example linked above, we need to look at the runtime for the fourth error (index 3) in the sixth pallet (index 5). + +By looking at the [runtime code](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L914) we see that the pallet at index 5 is "Balances". Now we will check the Balances pallet's code which is hosted in the Substrate repository, and look for the fourth error in the Error enum. According to [its source](https://github.com/paritytech/substrate/blob/master/frame/balances/src/lib.rs#L270) the error that we got is `InsufficientBalance` or in other words "Balance too low to send value". + +## Common Errors + +The table below lists the most commonly encountered errors and ways to resolve them. + +| 錯誤 | 描述 | 解决方案 | +| ------------------ | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| BadOrigin | 不允许您执行此操作，例如尝试使用非议会帐户创建议会动议。 | 要么切换到具有必要权限的帐户，要么检查您试图执行的操作是否被允许(例如调用 `system.setCode` 直接进行 runtime 升级，无需通过投票)。 | +| BadProof | 交易签名似乎无效。 | 您所连接的节点可能会跟随一个过时的分叉—通常待它同步好后再次尝试问题会被解决。 要检查更大的问题，检查您所连接的节点的最后一个最终确定了和当前最佳的区块，并将这些值与其他公开的节点数据进行比较 - 它们是否在同步？ 如果没有，请尝试连接到另一个节点。 | +| Future | 交易 nonce 太高。 | 减少 nonce 为当前 +1。检查您正在使用的发送交易的地址。 | +| Stale | 交易 nonce 太低。 | 将当前的 nonce +1。检查您正在使用发送交易地址的 nonce。 | +| ExhaustsResources | 当前的区块没有足够的资源来提交这笔交易。 | 请在下一个区块中再试一次。 | +| Payment | 无法支付交易费用。 | 您可能没有足够可用的余额来支付这笔交易所需的费用。 | +| Temporarily banned | The transaction is temporarily banned. | The tx is already in pool. Either try on a different node, or wait to see if the initial transaction goes through. | + +## Error Table + +The below table is a reference to the errors that exists in Polkadot. It is generated from the runtime's metadata. + +| Pallet | Error | Documentation | +| ----------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | +| System (0) | | | +| | InvalidSpecName (0) | The name of specification does not match between the current runtime and the new runtime. | +| | SpecVersionNeedsToIncrease (1) | The specification version is not allowed to decrease between the current runtime and the new runtime. | +| | FailedToExtractRuntimeVersion (2) | Failed to extract the runtime version from the new runtime. Either calling `Core_version` or decoding `RuntimeVersion` failed. | +| | NonDefaultComposite (3) | Suicide called when the account has non-default composite data. | +| | NonZeroRefCount (4) | There is a non-zero reference count preventing the account from being purged. | +| Scheduler (1) | | | +| | FailedToSchedule (0) | Failed to schedule a call | +| | NotFound (1) | Cannot find the scheduled call. | +| | TargetBlockNumberInPast (2) | Given target block number is in the past. | +| | RescheduleNoChange (3) | Reschedule failed because it does not change scheduled time. | +| Balances (5) | | | +| | VestingBalance (0) | Vesting balance too high to send value | +| | LiquidityRestrictions (1) | Account liquidity restrictions prevent withdrawal | +| | Overflow (2) | Got an overflow after adding | +| | InsufficientBalance (3) | Balance too low to send value | +| | ExistentialDeposit (4) | Value too low to create account due to existential deposit | +| | KeepAlive (5) | Transfer/payment would kill account | +| | ExistingVestingSchedule (6) | A vesting schedule already exists for this account | +| | DeadAccount (7) | Beneficiary account must pre-exist | +| Authorship (6) | | | +| | InvalidUncleParent (0) | The uncle parent not in the chain. | +| | UnclesAlreadySet (1) | Uncles already set in the block. | +| | TooManyUncles (2) | Too many uncles. | +| | GenesisUncle (3) | The uncle is genesis. | +| | TooHighUncle (4) | The uncle is too high in chain. | +| | UncleAlreadyIncluded (5) | The uncle is already included. | +| | OldUncle (6) | The uncle isn't recent enough to be included. | +| Staking (7) | | | +| | NotController (0) | Not a controller account. | +| | NotStash (1) | Not a stash account. | +| | AlreadyBonded (2) | Stash is already bonded. | +| | AlreadyPaired (3) | Controller is already paired. | +| | EmptyTargets (4) | Targets cannot be empty. | +| | DuplicateIndex (5) | Duplicate index. | +| | InvalidSlashIndex (6) | Slash record index out of bounds. | +| | InsufficientValue (7) | Can not bond with value less than minimum balance. | +| | NoMoreChunks (8) | Can not schedule more unlock chunks. | +| | NoUnlockChunk (9) | Can not rebond without unlocking chunks. | +| | FundedTarget (10) | Attempting to target a stash that still has funds. | +| | InvalidEraToReward (11) | Invalid era to reward. | +| | InvalidNumberOfNominations (12) | Invalid number of nominations. | +| | NotSortedAndUnique (13) | Items are not sorted and unique. | +| | AlreadyClaimed (14) | Rewards for this era have already been claimed for this validator. | +| | OffchainElectionEarlySubmission (15) | The submitted result is received out of the open window. | +| | OffchainElectionWeakSubmission (16) | The submitted result is not as good as the one stored on chain. | +| | SnapshotUnavailable (17) | The snapshot data of the current window is missing. | +| | OffchainElectionBogusWinnerCount (18) | Incorrect number of winners were presented. | +| | OffchainElectionBogusWinner (19) | One of the submitted winners is not an active candidate on chain (index is out of range in snapshot). | +| | OffchainElectionBogusCompact (20) | Error while building the assignment type from the compact. This can happen if an index is invalid, or if the weights _overflow_. | +| | OffchainElectionBogusNominator (21) | One of the submitted nominators is not an active nominator on chain. | +| | OffchainElectionBogusNomination (22) | One of the submitted nominators has an edge to which they have not voted on chain. | +| | OffchainElectionSlashedNomination (23) | One of the submitted nominators has an edge which is submitted before the last non-zero slash of the target. | +| | OffchainElectionBogusSelfVote (24) | A self vote must only be originated from a validator to ONLY themselves. | +| | OffchainElectionBogusEdge (25) | The submitted result has unknown edges that are not among the presented winners. | +| | OffchainElectionBogusScore (26) | The claimed score does not match with the one computed from the data. | +| | OffchainElectionBogusElectionSize (27) | The election size is invalid. | +| | CallNotAllowed (28) | The call is not allowed at the given time due to restrictions of election period. | +| | IncorrectHistoryDepth (29) | Incorrect previous history depth input provided. | +| | IncorrectSlashingSpans (30) | Incorrect number of slashing spans provided. | +| Session (9) | | | +| | InvalidProof (0) | Invalid ownership proof. | +| | NoAssociatedValidatorId (1) | No associated validator ID for account. | +| | DuplicatedKey (2) | Registered duplicate key. | +| | NoKeys (3) | No keys are associated with this account. | +| Grandpa (11) | | | +| | PauseFailed (0) | Attempt to signal GRANDPA pause when the authority set isn't live (either paused or already pending pause). | +| | ResumeFailed (1) | Attempt to signal GRANDPA resume when the authority set isn't paused (either live or already pending resume). | +| | ChangePending (2) | Attempt to signal GRANDPA change with one already pending. | +| | TooSoon (3) | Cannot signal forced change so soon after last. | +| | InvalidKeyOwnershipProof (4) | A key ownership proof provided as part of an equivocation report is invalid. | +| | InvalidEquivocationProof (5) | An equivocation proof provided as part of an equivocation report is invalid. | +| | DuplicateOffenceReport (6) | A given equivocation report is valid but already previously reported. | +| ImOnline (12) | | | +| | InvalidKey (0) | Non existent public key. | +| | DuplicatedHeartbeat (1) | Duplicated heartbeat. | +| Democracy (14) | | | +| | ValueLow (0) | Value too low | +| | ProposalMissing (1) | Proposal does not exist | +| | BadIndex (2) | Unknown index | +| | AlreadyCanceled (3) | Cannot cancel the same proposal twice | +| | DuplicateProposal (4) | Proposal already made | +| | ProposalBlacklisted (5) | Proposal still blacklisted | +| | NotSimpleMajority (6) | Next external proposal not simple majority | +| | InvalidHash (7) | Invalid hash | +| | NoProposal (8) | No external proposal | +| | AlreadyVetoed (9) | Identity may not veto a proposal twice | +| | NotDelegated (10) | Not delegated | +| | DuplicatePreimage (11) | Preimage already noted | +| | NotImminent (12) | Not imminent | +| | TooEarly (13) | Too early | +| | Imminent (14) | Imminent | +| | PreimageMissing (15) | Preimage not found | +| | ReferendumInvalid (16) | Vote given for invalid referendum | +| | PreimageInvalid (17) | Invalid preimage | +| | NoneWaiting (18) | No proposals waiting | +| | NotLocked (19) | The target account does not have a lock. | +| | NotExpired (20) | The lock on the account to be unlocked has not yet expired. | +| | NotVoter (21) | The given account did not vote on the referendum. | +| | NoPermission (22) | The actor has no permission to conduct the action. | +| | AlreadyDelegating (23) | The account is already delegating. | +| | Overflow (24) | An unexpected integer overflow occurred. | +| | Underflow (25) | An unexpected integer underflow occurred. | +| | InsufficientFunds (26) | Too high a balance was provided that the account cannot afford. | +| | NotDelegating (27) | The account is not currently delegating. | +| | VotesExist (28) | The account currently has votes attached to it and the operation cannot succeed until these are removed, either through `unvote` or `reap_vote`. | +| | InstantNotAllowed (29) | The instant referendum origin is currently disallowed. | +| | Nonsense (30) | Delegation to oneself makes no sense. | +| | WrongUpperBound (31) | Invalid upper bound. | +| | MaxVotesReached (32) | Maximum number of votes reached. | +| | InvalidWitness (33) | The provided witness data is wrong. | +| | TooManyProposals (34) | Maximum number of proposals reached. | +| Council (15) | | | +| | NotMember (0) | Account is not a member | +| | DuplicateProposal (1) | Duplicate proposals not allowed | +| | ProposalMissing (2) | Proposal must exist | +| | WrongIndex (3) | Mismatched index | +| | DuplicateVote (4) | Duplicate vote ignored | +| | AlreadyInitialized (5) | Members are already initialized! | +| | TooEarly (6) | The close call was made too early, before the end of the voting. | +| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | +| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | +| | WrongProposalLength (9) | The given length bound for the proposal was too low. | +| TechnicalCommittee (16) | | | +| | NotMember (0) | Account is not a member | +| | DuplicateProposal (1) | Duplicate proposals not allowed | +| | ProposalMissing (2) | Proposal must exist | +| | WrongIndex (3) | Mismatched index | +| | DuplicateVote (4) | Duplicate vote ignored | +| | AlreadyInitialized (5) | Members are already initialized! | +| | TooEarly (6) | The close call was made too early, before the end of the voting. | +| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | +| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | +| | WrongProposalLength (9) | The given length bound for the proposal was too low. | +| ElectionsPhragmen (17) | | | +| | UnableToVote (0) | Cannot vote when no candidates or members exist. | +| | NoVotes (1) | Must vote for at least one candidate. | +| | TooManyVotes (2) | Cannot vote more than candidates. | +| | MaximumVotesExceeded (3) | Cannot vote more than maximum allowed. | +| | LowBalance (4) | Cannot vote with stake less than minimum balance. | +| | UnableToPayBond (5) | Voter can not pay voting bond. | +| | MustBeVoter (6) | Must be a voter. | +| | ReportSelf (7) | Cannot report self. | +| | DuplicatedCandidate (8) | Duplicated candidate submission. | +| | MemberSubmit (9) | Member cannot re-submit candidacy. | +| | RunnerSubmit (10) | Runner cannot re-submit candidacy. | +| | InsufficientCandidateFunds (11) | Candidate does not have enough funds. | +| | NotMember (12) | Not a member. | +| | InvalidCandidateCount (13) | The provided count of number of candidates is incorrect. | +| | InvalidVoteCount (14) | The provided count of number of votes is incorrect. | +| | InvalidRenouncing (15) | The renouncing origin presented a wrong `Renouncing` parameter. | +| | InvalidReplacement (16) | Prediction regarding replacement after member removal is wrong. | +| Treasury (19) | | | +| | InsufficientProposersBalance (0) | Proposer's balance is too low. | +| | InvalidIndex (1) | No proposal or bounty at that index. | +| | ReasonTooBig (2) | The reason given is just too big. | +| | AlreadyKnown (3) | The tip was already found/started. | +| | UnknownTip (4) | The tip hash is unknown. | +| | NotFinder (5) | The account attempting to retract the tip is not the finder of the tip. | +| | StillOpen (6) | The tip cannot be claimed/closed because there are not enough tippers yet. | +| | Premature (7) | The tip cannot be claimed/closed because it's still in the countdown period. | +| | UnexpectedStatus (8) | The bounty status is unexpected. | +| | RequireCurator (9) | Require bounty curator. | +| | InvalidValue (10) | Invalid bounty value. | +| | InvalidFee (11) | Invalid bounty fee. | +| | PendingPayout (12) | A bounty payout is pending. To cancel the bounty, you must unassign and slash the curator. | +| Claims (24) | | | +| | InvalidEthereumSignature (0) | Invalid Ethereum signature. | +| | SignerHasNoClaim (1) | Ethereum address has no claim. | +| | SenderHasNoClaim (2) | Account ID sending tx has no claim. | +| | PotUnderflow (3) | There's not enough in the pot to pay out some unvested amount. Generally implies a logic error. | +| | InvalidStatement (4) | A needed statement was not included. | +| | VestedBalanceExists (5) | The account already has a vested balance. | +| Vesting (25) | | | +| | NotVesting (0) | The account given is not vesting. | +| | ExistingVestingSchedule (1) | An existing vesting schedule already exists for this account that cannot be clobbered. | +| | AmountLow (2) | Amount being transferred is too low to create a vesting schedule. | +| Identity (28) | | | +| | TooManySubAccounts (0) | Too many subs-accounts. | +| | NotFound (1) | Account isn't found. | +| | NotNamed (2) | Account isn't named. | +| | EmptyIndex (3) | Empty index. | +| | FeeChanged (4) | Fee is changed. | +| | NoIdentity (5) | No identity found. | +| | StickyJudgement (6) | Sticky judgement. | +| | JudgementGiven (7) | Judgement given. | +| | InvalidJudgement (8) | Invalid judgement. | +| | InvalidIndex (9) | The index is invalid. | +| | InvalidTarget (10) | The target is invalid. | +| | TooManyFields (11) | Too many additional fields. | +| | TooManyRegistrars (12) | Maximum amount of registrars reached. Cannot add any more. | +| | AlreadyClaimed (13) | Account ID is already named. | +| | NotSub (14) | Sender is not a sub-account. | +| | NotOwned (15) | Sub-account isn't owned by sender. | +| Proxy (29) | | | +| | TooMany (0) | There are too many proxies registered or too many announcements pending. | +| | NotFound (1) | Proxy registration not found. | +| | NotProxy (2) | Sender is not a proxy of the account to be proxied. | +| | Unproxyable (3) | A call which is incompatible with the proxy type's filter was attempted. | +| | Duplicate (4) | Account is already a proxy. | +| | NoPermission (5) | Call may not be made by proxy because it may escalate its privileges. | +| | Unannounced (6) | Announcement, if made at all, was made too recently. | +| Multisig (30) | | | +| | MinimumThreshold (0) | Threshold must be 2 or greater. | +| | AlreadyApproved (1) | Call is already approved by this signatory. | +| | NoApprovalsNeeded (2) | Call doesn't need any (more) approvals. | +| | TooFewSignatories (3) | There are too few signatories in the list. | +| | TooManySignatories (4) | There are too many signatories in the list. | +| | SignatoriesOutOfOrder (5) | The signatories were provided out of order; they should be ordered. | +| | SenderInSignatories (6) | The sender was contained in the other signatories; it shouldn't be. | +| | NotFound (7) | Multisig operation not found when attempting to cancel. | +| | NotOwner (8) | Only the account that originally created the multisig is able to cancel it. | +| | NoTimepoint (9) | No timepoint was given, yet the multisig operation is already underway. | +| | WrongTimepoint (10) | A different timepoint was given to the multisig operation that is underway. | +| | UnexpectedTimepoint (11) | A timepoint was given, yet no multisig operation is underway. | +| | WeightTooLow (12) | The maximum weight information provided was too low. | +| | AlreadyStored (13) | The data to be stored is already stored. | diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-governance-index.md b/polkadot-wiki/translated_docs/zh-CN/maintain-governance-index.md new file mode 100644 index 000000000000..8812e030de6c --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-governance-index.md @@ -0,0 +1,185 @@ +--- +id: maintain-governance-index +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. + +All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. + +The following steps are the governance procedure in the Polkadot network: + +- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) +- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) +- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) + +To better understand how the council is formed, please read [this section](#council). + +### Proposing Referenda + +- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. + +- **[Council](#council)**: + + Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. + + Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) + +### Voting for a proposal + +To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). + +``` +Example: + +Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes +``` + +According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. + +### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +voters - the total number of voting tokens + +electorate - the total number of DOTs tokens issued in the network +``` + +**Super-Majority Approve** + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ + +**Super-Majority Against** + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ + +**Simple-Majority** + +Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ + +_To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume we only have 1,500 DOTs tokens in total. + +John - 500 DOTs +Peter - 100 DOTs +Lilly - 150 DOTs +JJ - 150 DOTs +Ken - 600 DOTs + +John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +voters = 1050 +electorate = 1500 +``` + +$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ + +$${13.887} < {15.492}$$ + +Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. + +## Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: + +``` +Max votes = tokens * periods +``` + +Based on the current testnet setting, the maximum number of lock periods is set to 6. + +**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** + +## Adaptive Quorum Biasing + +Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. + +Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. + +Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. + +In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +## Council + +Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. + +To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. + +Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. + +Let's take a look at the example below. + +||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. + +### Resources + +- [Governance Description](learn-governance#referenda) +- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) + +## [Usage of DOT](learn-DOT#dots-for-governance) + +## Guides + +### [How to create a proposal]() + +### [How to join the council]() + +### [How to propose a referenda]() diff --git a/website/translated_docs/zh-CN/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-guides-democracy.md diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate-polkadot.md diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate.md new file mode 100644 index 000000000000..20b9f634ea64 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-nominate.md @@ -0,0 +1,59 @@ +--- +id: maintain-guides-how-to-nominate +title: How to nominate +sidebar_label: How to nominate +--- + +This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. + +It has been updated for the Alexander testnet and Polkadot release PoC-4. + +## Create `stash` and `controller` accounts + +We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. + +The first step is to create two accounts by going to the _Accounts_ tab on the Polkadot Dashboard and clicking on [_Add account_](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. + +![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) + +Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. + +## Nominating + +It is now time to setup our nominator. We will do the following: + +- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. +- Select the `controller`. This is the account that will decide when to start or stop nominating. + +First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. + +![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. +- **Controller account** - select the `controller` account created earlier. +- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). +- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). + +Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. + +![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) + +## Nominating a validator + +Go to the _Staking Overview_ tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. + +![Validators](assets/guides/how-to-nominate/validators.png) + +Go back to the _Account Actions_ tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). + +![Nominating](assets/guides/how-to-nominate/nominating.jpg) + +**Congratulations!** You are now a nominator. + +If you return to the _Staking Overview_ tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. + +![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) + +## How to stop nominating + +To stop nominating simply return to the _Account Actions_ tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-systemd.md diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-unbond.md new file mode 100644 index 000000000000..609f04098469 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-unbond.md @@ -0,0 +1,59 @@ +--- +id: maintain-guides-how-to-unbond +title: Unbonding and Rebonding +sidebar_label: Unbonding and Rebonding +--- + +The following describes how to stop nominating or validating and retrieve your tokens. Please note that all networks on which you can nominate have a delayed exit period, called the _unbonding period_, which serves as a cooldown. You will not be able to transfer your tokens before this period has elapsed, and you will not receive any staking rewards during this period (as you are not nominating any validators). + +### 第 1 步：停止提名 + +On the [Polkadot-JS Apps](https://polkadot.js.org/apps) navigate to the "Staking" tab. + +在页面左上角点击 "Account Actions"。 + +Here, click "Stop Nominating" or "Stop Validating" (depending on your role) on an account you're staking with and would like to free the funds for. + +![Stop Nominating Button](/img/NPoS/unbond1.png) + +After you confirm this transaction, your tokens will remain _bonded_. This means they stay ready to be distributed among nominees or used as validator self-stake again. To actually withdraw them, you need to unbond. + +### 第 2 步：取消绑定 + +To unbond the amount, click the little gear icon next to the account you want to unbond tokens for, and select "Unbond funds". + +![Unbonding](/img/NPoS/unbond2.png) + +选择您要取消绑定的金额，然后单击 "Unbond"，然后确认交易。 + +![Unbonding all](/img/NPoS/unbond3.png) + +如果成功，您的余额将显示为 "unbonding"，并显示还剩余多少区块，你就会完全解锁该数量。 + +![Unbonding duration](/img/NPoS/unbond4.png) + +该持续时间会因您所使用的网络而异，在 Kusama 上的速度通常是 Polkadot 上速度的四倍。 + +Once this process is complete, you will have to issue another, final transaction: Withdraw Unbonded. + +![Unbonding withdraw](/img/NPoS/unbond5.png) + +You can also check how long you have to wait in order to withdraw your stake in the [Accounts](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/accounts) page by expanding your account balance. There is a tiny icon beside the word "unbonding" that will eventually become an unlock icon once the remaning blocks get passed. + +Then, you can click that icon directly to submit the withdraw transaction. Finally, your transferrable balance will increase by the amount of tokens you've just fully unbonded. + +## Rebonding before the end of the unbonding period + +If you want to rebond your tokens before the unbonding period is over you can do this by issuing a `rebond` extrinsic. This allows you to bond your tokens that are still locked without waiting until the end of the unbonding period. + +In order to do this you will need to issue an extrinsic manually from [Polkadot-JS Apps](https://polkadot.js.org/apps). + +Go to the "Extrinsics" option that's located in the "Developer" dropdown in the top menu. + +![extrinsic menu](assets/rebonding-1.png) + +Select the "staking" pallet and the "rebond" extrinsic. Enter the amount of tokens that are currently locked in unbonding that you want to rebond. Then click "Submit Transaction". + +![confirm](assets/rebonding-2.png) + +Confirm the transaction in the next pop-up. Once the transaction is included in the next block your tokens will be rebonded again and you can start staking with them. diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-upgrade.md new file mode 100644 index 000000000000..9435c767b4aa --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-upgrade.md @@ -0,0 +1,58 @@ +--- +id: maintain-guides-how-to-upgrade +title: 如何升级验证人节点 +sidebar_label: 如何升级验证人节点 +--- + +验证人负责执行网络上的重要工作，所以对在线有严格的要求。验证人有机会更新客户端或系统同时离线一段时间。这教程将会指导您如何升级并保持验证人在线。 + +这过程可能需要数小时，所以确保您先理解说明并制定相应的计划。 + +## 重要组件 + +### Session 密钥 + +Session 密钥储存在客户瑞并供验证人作签名操作。它是把验证人节点和 Controller 帐户联系起来。您不能在 Session 中段更改它。 + +[关于 Polkadot 密钥资料。](learn-keys) + +### 数据库 + +验证人数据库保留所有他们的投票，如果二台电脑在不同数据库拥有相同 Session 密钥，他们会有 equivocating 风险。因此每次更换电脑时，我们都会生成新 Session 密钥。 + +[有关 equivocation 更多信息。](learn-staking#slashing) + +## 步骤 + +当您升级主机验证人时，您需要启动另一台验证人。在升级步骤中，我们将需要升级的验证人称为 "验证人 A"，而第二个称为 "验证人 B"。 + +### Session `N` + +1. 启动另外节点并且连接到你的哨兵节点。一旦同步数据完成，使用 `--validator` 标志。这是 "验证人 B"。 +1. 在验证人 B 生成 Session 密钥。 +1. 在你 Controller 帐户提交 `set_key` 交易设定新的 Session 密钥。 +1. 记下交易执行后的结果。 + +**验证人 A 必须在当下 Session 继续运行** `set_key` 仅在下一个 Session 生效。 + +### Session `N+1` + +现在验证人 B 充当验证人，你可以把验证人 A 停下来。请留意底部的注释。 + +1. 停止验证人 A。 +1. 把您的系统或客户端进行升级。 +1. 启动验证人 A，同步数据库并连接你的哨兵节点。 +1. 在验证人 A 生成新的 Session 密钥。 +1. 在你 Controller 帐户提交 `set_key` 交易设定验证人 A 新的 Session 密钥。 +1. 记下交易执行后的结果。 + +**再重复一次验证人 B 必须在当下 Session 继续运行直至下一个 Session。** + +一旦 Session 改变，验证人 A 将接管。你可以把验证人 B 停下来。 + +**注意:**: 为了确保 Session 已更改，请确保新 Session 中有一个区块已确认。如果成功，您应该看到类似以下的日志消息: + +``` +2019-10-28 21:44:13 Applying authority set change scheduled at block #450092 +2019-10-28 21:44:13 Applying GRANDPA set change to new set with 20 authorities +``` diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..e36119400f6d --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: 成为验证人 (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +本指南将指导您如何在 Kusama 网络上设置验证人节点。 + +## 首先 + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## 初始设置 + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- ** 中央处理器:** 1 - 2。一个 CPU 是可以，但是 2 个更好。 同样地这是一种性能偏好。 + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> 注意：如果您喜欢使用 SSH 而不是 HTTPS，则可以将下面的第一行替换为 `git clone git@github.com:paritytech/polkadot.git`。 + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## 绑定 KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- 选择 Controller，Controller 是决定何时开始或停止验证的帐户。 + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## 设置 Session 密钥 + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## 验证 + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..aca016ab9c6c --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: 运行验证人 (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +本指南将指导您如何在 Polkadot 网络上设置验证人节点。 + +## 首先 + +在主网上运行验证人有很大的责任！你不仅要对自己抵押的 DOTs 负责，还有目前提名你的提名人抵押。如果你犯了错误并且被惩罚，你的钱和声誉将处于危险之中。但是运行验证人也有非常可观的回报，您为安全性做出了贡献，使网络更分散。 + +由于安全性对运行验证人至关重要，因此您最好看一下[设定安全验证人](maintain-guides-secure-validator)资料使您了解在构建网络架构时要考虑的要素。 Web3 基金会也会保持更新[安全验证人设置的参考](https://github.com/w3f/polkadot-secure-validator)使您也可以自己部署来使用(视频教程在[这里](https://www.youtube.com/watch?v=tTn8P6t7JYc))。随着您成为验证人愈长时间，您可能使用此库作为自己的*起点*进行修改和自定义。 + +如果您需要帮助，请前往 [ Riot 上的 Polkadot 验证人聊天室](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) 。团队和其他验证人在那里帮助回答问题并提供经验。 + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## 初始设置 + +### 要求 + +初学者运行验证人的最常见方法是在 Linux 云服务器 上。 您可以选择自己喜欢的[ VPS ](#vps-list)服务商，以及自己喜欢的操作系统。 在本指南中，我们将使用** Ubuntu 18.04 **，但其他平台的设置应相似。 + +Polkadot 中的交易权重以标准硬件为基准。 建议验证人至少运行标准硬件，以确保它们能够及时处理所有区块。以下不是*最低要求*，但是如果您决定以低于此的速度运行，则可能会遇到性能问题。 + +#### 标准硬件 + +关于标准硬件的详细信息，请在[这里](https://github.com/paritytech/substrate/pull/5848)查看。 + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +上面发布的规格绝不是运行验证人时可以使用的最低规格，但是您应该意识到，如果使用的规格较少，则可能需要切换一些额外的优化才能与其他运行标准验证人相同。 + +### 安裝 Rust + +当你选择云端服务供应商并设置新服务器后，第一件您要做的事就是安装 Rust。 + +如果您从未安装过 Rust，则应先执行此指令。该指令将下载最新版本的 Rust 并安装。 + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +相反如果您已经安装了 Rust，请运行以下指令以确保您使用的是最新版本。 + +```sh +rustup update +``` + +最后运行此指令以安装必要的相关依赖，以编译和运行 Polkadot 节点。 + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +注意 - 如果您使用的是 OSX，并且已安装[ Homebrew ](https://brew.sh)，则可以执行以下指令而不是之前的指令： + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### 安装 & 配置网络时间协议 (NTP) 客户端 + +[ NTP ](https://en.wikipedia.org/wiki/Network_Time_Protocol)是种网络协议，旨在通过网络同步计算机的时钟。NTP 允许您同步网络中所有系统的时钟。 验证人现在要求本地时钟保持合理的同步，因此您应该运行 NTP 或类似的服务。 您可以通过运行以下命令检查是否具有 NTP 客户端： + +_如果您正在使用 Ubuntu 18.04 / 19.04, NTP 客户端应默认已安装。_ + +```sh +timedatectl +``` + +如果已安装并正在运行 NTP，则应该看到`System clock synchronized: yes`(或类似的消息)。如果看不到它，可以通过执行以下命令进行安装: + +```sh +sudo apt-get install ntp +``` + +ntpd 将在安装后自动启动。您可以查询 ntpd 获取状态信息以验证一切是否正常: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### 构建并安装 `polkadot` 二进制文件 + +您需要从[ paritytech/polkadot ](https://github.com/paritytech/polkadot) GitHub 库的** v0.8 **分支中构建 `polkadot` 二进制文件。 + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +这步将需要一段时间(通常需要 10 - 40 分钟，具体取决于您的硬件)。 + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +如果您想在本地生成密钥，您还可以在同一目录安装` subkey `。然后您可以把生成好的` subkey `可执行文件，并将其转移到与世隔绝的电脑中，以提高安全性。 + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### 同步链数据 + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +您可以通过运行以下指令来开始同步您的节点: + +```sh +./target/release/polkadot --pruning=archive +``` + +如果您不想马上运行验证模式下。 + +`--pruning=archive`选项意味着`--validator`和`-sentry `选项，因此仅如果在没有这两个选项之一的情况下启动节点，则必须明确要求。 如果您不设置为 archive 节点，即使不在运行验证人和哨兵模式时，也需要切换时重新同步数据库。 + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +根据当时链的大小，此步可能需要几分钟到几个小时不等。 + +如果您想估计还需要再多少时间，服务器日志(在 `polkadot` STDOUT 程序中显示)显示了您的节点已处理和最新验证的区块。 然后您可以与[ Telemetry ](https://telemetry.polkadot.io/#list/Polkadot%20CC1)或当前[ PolkadotJS 区块链浏览器](https://polkadot.js.org/apps/#/explorer)比较。 + +## Bond DOT + +强烈建议您将 controller 和 stash 帐号设为两个单独的帐号。 为此，您将创建两个帐号，并确保每个帐号至少有足够的资金来支付进行交易的费用。 将您的大部分资金保留在 stash 帐号中，因为这是您存入资金的托管人。 + +确保不对所有 DOT 余额进行绑定，因为您将无法从绑定的余额中支付交易费用。 + +现在可以开始设定验证人，首先我们将会做以下步骤： + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- 选择 Controller，Controller 是决定何时开始或停止验证的帐户。 + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +当所有资料填写好后，使用 Stash 帐号按下`Bond`并签署交易。 + +几秒钟后您应该看到 "ExtrinsicSuccess" 信息。现在您应该会看到包含所有帐号的新卡 (注意: 您可能需要重新整理页面)。 右侧的保证金金额对应于 Stash 的绑定帐号。 + +## 设置 Session 密钥 + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +您可以为验证者人改任何名称，但其他人也可以看到。该名称也会显示在 telemetry 服务器里。由于多人也在使用 telemetry，因此建议您的名称尽可能独特一点。 + +### 生成 Session 密钥 + +您需要通过签名并提交交易设定 Session 密钥。这就是用来与您的验证节点和 Controller 帐号连接起来。 + +#### 选项 1: PolkadotJS-APPS + +您可以使用客户端通过 RPC 生成[ Session 密钥](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key)。 如果执行此操作，确保已将 PolkadotJS-Apps 浏览器连接到验证人节点。 您可以在 "Settings" 标签中将应用程序设置连接到验证人的地址。如果您连接到 Web3 Foundation 的 Parity 托管的地址，则不能使用此方法，因为向该节点发出 RPC 请求是*公开节点*上托管的 keystore，因此您需要确认正在与*您的节点*的 keystore 连接。 + +一旦确定已连接到节点，最简单为节点设置 session 密钥的方法是调用 `author_rotateKeys` RPC 请求在验证人的 keystore 中创建新密钥。前往到工具箱选项卡并调用 RPC，然后选择 author > rotateKeys() 选项并记住保存回传结果。 + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### 选项 2: CLI + +如果您在远程服务器上，运行此指令在同一台电脑上会更容易(当节点是运行中并且配置默认 HTTP RPC 端口): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +结果将是十六进制编码的 "result"。這结果是四个公钥的合并。保存结果供后续使用。 + +You can restart your node at this point. + +### 提交`setKeys`交易 + +您需要通过签名并提交交易设定你的 Session 密钥。 这是把您的 Controller 帳戶与验证人连接起来。 + +前往 [ Stake > Account Actions](https://polkadot.js.org/apps/#/staking/actions)，然后在您先前生成的绑定(Stash)帐户。 按下 "Set Session Key" 之后输入之前在`author_rotateKeys`的结果。 + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +提交交易，现在您可以开始验证了。 + +## 验证 + +要核实您的节点是否处于运行状态并已同步，前往[Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) 并找您的节点。注意: 这里显示 Polkadot 网络上的所有节点，因此拥有一个独一无二的名字很重要。 + +如果一切看起来顺利，请继续操作，在 Polkadot UI 中按下 "Validate"。 + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** -您可以指定将获得报酬的百分比。剩余的将与您的提名人之间进行分配。 + +按下 "Validate"。 + +如果您前往 "Staking" 标签，将看到当前在网络上运行的验证人列表。 在页面顶部，它显示了验证人的数量，以及已发出有意表示希望成为验证人节点的数量。 您可以转到 "Waiting" 标签仔细检查以查看是否在此处列出了您的节点。 + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**恭喜你!** 如果你有按照以上步骤操作，你经已设定好 Polkadot 网络的验证人！若果你需要帮助，请前往 **NOTE:** Session keys can also be generated outside the client and inserted into the client's keystore via RPC. For most users, we recommend using the key generation functionality within the client. + +### 客户端外部签署 + +In the future, Polkadot will support signing payloads outside the client so that keys can be stored on another device, e.g. a hardware security module (HSM) or secure enclave. For the time being, however, Session key signatures are performed within the client. + +> **NOTE:** HSMs are not a panacea. They do not incorporate any logic and will just sign and return whatever payload they receive. Therefore, an attacker who gains access to your validator node could still commit slashable behavior. + +An example of highly available, secure setup would be a layer of sentry nodes in front of multiple validators connected to a single signing machine. This machine could implement signing logic to avoid equivocation, even if an attacker gained access to a validator node. + +## 监视工具 + +- [Telemetry](https://github.com/paritytech/substrate-telemetry) This tracks your node details including the version you are running, block height, CPU & memory usage, block propagation time, etc. + +- [Prometheus](https://prometheus.io/)-based monitoring stack, including [Grafana](https://grafana.com) for dashboards and log aggregation. It includes alerting, querying, visualization, and monitoring features and works for both cloud and on-premise systems. The data from `substrate-telemetry` can be made available to Prometheus through exporters like [this](https://github.com/w3f/substrate-telemetry-exporter). + +## Linux 最佳实践 + +- 永不使用 root 用户 +- 保持更新系统的安全补丁 +- 启动并设置防火墙 +- 永不允许基于密码的 ssh，只能使用基于密钥的访问。 +- Disable non-essential SSH subsystems (banner, motd, scp, X11 forwarding) and harden your SSH configuration ([reasonable guide to begin with](https://stribika.github.io/2015/01/04/secure-secure-shell.html)). +- 定期备份您的存储。 + +## 结论 + +- At the moment, Polkadot/Substrate can't interact with HSM/SGX, so we need to provide the signing key seeds to the validator machine. This key is kept in memory for signing operations and persisted to disk (encrypted with a password). + +- Given that HA setups would always be at risk of double-signing and there's currently no built-in mechanism to prevent it, we propose having a single instance of the validator to avoid slashing. Slashing penalties for being offline are much less than those for equivocation. + +### 验证人 + +- Validators should only run the Polkadot binary, and they should not listen on any port other than the configured p2p port. + +- Validators should run on bare-metal machines, as opposed to VMs. This will prevent some of the availability issues with cloud providers, along with potential attacks from other VMs on the same hardware. The provisioning of the validator machine should be automated and defined in code. This code should be kept in private version control, reviewed, audited, and tested. + +- Session 密钥应以安全的方式生成和提供。 + +- 如果任何原因导致 Polkadot 停止运行(supervisor 程序)，Polkadot 应该在开机和重新启动时重新启动。 + +- Polkadot 应该以非 root 用户身份运行。 + +### Monitoring + +- There should be an on-call rotation for managing the alerts. + +- There should be a clear protocol with actions to perform for each level of each alert and an escalation policy. + +## 资源 + +- [Figment Network's Full Disclosure of Cosmos Validator Infrastructure](https://medium.com/figment-networks/full-disclosure-figments-cosmos-validator-infrastructure-3bc707283967) +- [Certus One's Knowledge Base](https://kb.certus.one/) +- [EOS Block Producer Security List](https://github.com/slowmist/eos-bp-nodes-security-checklist) +- [Sentry Node Architecture Overview](https://forum.cosmos.network/t/sentry-node-architecture-overview/454) +- [HSM Policies and the Important of Validator Security](https://medium.com/loom-network/hsm-policies-and-the-importance-of-validator-security-ec8a4cc1b6f) diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-validator-payout.md new file mode 100644 index 000000000000..135afaf48e1b --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-guides-validator-payout.md @@ -0,0 +1,142 @@ +--- +id: maintain-guides-validator-payout +title: 验证人奖励发放概述 +sidebar_label: 验证人奖励发放概述 +--- + +## Era Points + +对于每个时代(era) (在 Kusama 大约 6 小时，在 Polkadot 大约 24 小时），验证人将按照他们的*era points*的数量按比例支付。era points 是指通过以下方式获得的奖励积分: + +- 为[ 平行链 ](learn-parachains)区块发布有效性声明。 +- producing a non-uncle block in the Relay Chain. +- 生成一个引用到以前未引用的叔块。 +- 生成一个引用的叔块。 + +_Note: An uncle block is a Relay Chain block that is valid in every regard, but which failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. We call the lagging blocks uncle blocks._ + +奖励发放在每个时代结束时。 + +## 奖励方式 + +No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on [era points](#era-points), as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. + +Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. + +Validators will receive staking rewards in the form of the native token of that chain (KSM for Kusama and DOT for Polkadot). + +For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1): 18 tokens +Validator 2 Stake (v2): 9 tokens +Validator 3 Stake (v3): 8 tokens +Validator 4 Stake (v4): 7 tokens +Payout (p): 8 DOT + +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 tokens +``` + +Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator `v1`, who had 18 tokens staked, received the same reward (2 tokens) in this era as `v4` who had only 7 tokens staked. + +## 运行多个验证人节点 + +It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough DOT, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. + +For the following example, assume you have 18 DOT to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 DOT in this era. + +Note that while DOT is used as an example, this same formula would apply to KSM when running a validator on Kusama. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1): 18 DOT <- Your validator +Validator 2 Stake (v2): 9 DOT +Validator 3 Stake (v3): 8 DOT +Validator 4 Stake (v4): 7 DOT +Payout (p): 8 DOT + +Your payout = (p / v) * 1 = (8 / 4) * 1 = 2 +``` + +Running two validators, and splitting the stake equally, would result in the original validator `v4` to be kicked out of the validator set, as only the top `v` validators (as measured by stake) are selected to be in the validator set. More important, it would also double the reward that you get from each era. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1): 9 DOT <- Your first validator +Validator 2 Stake (v2): 9 DOT <- Your second validator +Validator 3 Stake (v3): 9 DOT +Validator 4 Stake (v4): 8 DOT +Payout (p): 8 DOT + +Your payout = (p / v) * 1 = (8 / 4) * 2 = 4 +``` + +With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. + +The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. + +## 惩罚 (Slashing) + +Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough DOT to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more DOT for a validator with 18 DOT staked than one with 9 DOT staked. + +Running multiple validators does not absolve you of the consequences of misbehavior. Polkadot punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. + +Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator. + +To clarify this, let us imagine two validators, `v1` and `v2`. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that `v1` has 90 DOT nominating it and `v2` only has 10. If you nominate `v1`, it now has `90 + 10 = 100` DOT, and you will get 10% of the staking rewards for the next era. If you nominate `v2`, it now has `10 + 10 = 20` DOT nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 DOT in each case. + +## 提名人和验证人支付 + +Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. + +> **NOTE:** Validators set their preference as a percentage of the block reward, _not_ an absolute number of DOT. Polkadot's block reward is based on the _total_ amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, and 100% commission means that the validator operator gets all rewards and gives none to its nominators. + +In the following examples, we can see the results of several different validator payment schemes and split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 DOT, and there are four nominators with equal stake bonded, each will receive 0.5 DOT. Note also that a single nominator may stake different validators. + +Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in DOT, although the same calculations work for KSM) is listed in brackets (`[]`) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. + +``` +Validator Set Size (v): 4 +Validator 1 Stake (v1) [20% commission]: 18 DOT (9 validator, 9 nominator) +Validator 2 Stake (v2) [40% commission]: 9 DOT (3 validator, 6 nominator) +Validator 3 Stake (v3) [10% commission]: 8 DOT (4 validator, 4 nominator) +Validator 4 Stake (v4) [ 0% commission]: 6 DOT (1 validator, 5 nominator) +Payout (p): 8 DOT + +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 DOT + +v1: +(0.2 * 2) = 0.4 DOT -> validator payment +(2 - 0.4) = 1.6 -> shared between all stake +(9 / 18) * 1.6 = 0.8 -> validator stake share +(9 / 18) * 1.6 = 0.8 -> nominator stake share +v1 validator total reward: 0.4 + 0.8 = 1.2 DOT +v1 nominator reward: 0.8 DOT + +v2: +(0.4 * 2) = 0.8 DOT -> validator payment +(2 - 0.8) = 1.2 -> shared between all stake +(3 / 9) * 1.2 = 0.4 -> validator stake share +(6 / 9) * 1.2 = 0.8 -> nominator stake share +v2 validator total reward: 0.8 + 0.4 = 1.2 DOT +v2 nominator reward: 0.8 DOT + +v3: +(0.1 * 2) = 0.2 DOT -> validator payment +(2 - 0.2) = 1.8 -> shared between all stake +(4 / 8) * 1.8 = 0.9 -> validator stake share +(4 / 8) * 1.8 = 0.9 -> nominator stake share +v3 validator total reward: 0.2 + 0.9 DOT = 1.1 DOT +v3 nominator reward: 0.9 DOT + +v4: +(0 * 2) = 0 DOT -> validator payment +(2 - 0) = 2.0 -> shared between all stake +(1 / 6) * 2 = 0.33 -> validator stake share +(5 / 6) * 2 = 1.67 -> nominator stake share +v4 validator total reward: 0 + 0.33 DOT = 0.33 DOT +v4 nominator reward: 1.67 DOT +``` diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-index.md b/polkadot-wiki/translated_docs/zh-CN/maintain-index.md new file mode 100644 index 000000000000..6b772c11df96 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-index.md @@ -0,0 +1,42 @@ +--- +id: maintain-index +title: 网络参与者 +sidebar_label: 网络参与者 +--- + +欢迎来到 Polkadot 维基的网络参与者部分。 在这里您将找到有关设置节点和运行指南。 + +## 节点 + +- [网络指南](maintain-networks) - 可以连接到 Polkadot 网络的节点列表。 +- [设置全节点](maintain-sync)-通过运行全节点，同步 Kusama 网络来开始。 该指南中的步骤还将广泛应用于任何基于 Substrate 的网络 (如 Polkadot)。 +- [使用 Nginx 设置 WSS](maintain-wss) - 为您的节点设置安全连接 WebSockets 的服务器。 + +## 收集人 + +- [Learn about Collators](learn-collator) - High level overview of collators and related links. + +## 提名人 + +- [Learn about Nominators](learn-nominator) - High level overview of nominators and related links. +- [提名人指南 (Polkadot)](maintain-guides-how-to-nominate-polkadot)- 如何在 Polkadot 网络上进行提名。 +- [提名人指南 (Kusama)](maintain-guides-how-to-nominate-kusama)- 如何在 Kusama 金丝雀网络上进行提名。 +- [How to stop being a Nominator](maintain-guides-how-to-unbond) - Guide on how to stop nominating. + +## 验证人 + +- [Learn about Validators](learn-validator) - High level overview of validator and related links. +- [验证人奖励收益](maintain-guides-validator-payout) - 验证人奖励的计算和收益 +- [验证人指南 (Polkadot)](maintain-guides-how-to-validate-polkadot)- 如何在 Polkadot 网络上进行验证。 +- [验证人指南 (Kusama)](maintain-guides-how-to-validate-kusama)-逐步介绍如何在 Kusama 金丝雀网络上运行节点。 +- [Using systemmd for the Validator Node](maintain-guides-how-to-systemd) - Configuring systemmd with the Validator node. +- [Secure Validator](maintain-guides-secure-validator) - Best tips and practices for validating. +- [How to use Polkadot Secure Validator](maintain-guides-how-to-use-polkadot-secure-validator) - Walkthrough on how to set up a validator securely. +- [How to upgrade a Validator Node](maintain-guides-how-to-upgrade) - Guide on upgrading your validator node. +- [How to Chill](maintain-guides-how-to-chill) - Walkthrough on how to chill as a validator. + +## 治理 + +- [How to pariticipate in Governance](maintain-guides-democracy) - Walkthrough on how to participate in governance. +- [How to join the Council](maintain-guides-how-to-join-council) - Step by step guide for running for the Council. +- [How to vote for a Councillor](maintain-guides-how-to-vote-councillor) - Step by step guide for voting for your favorite councillors. diff --git a/website/translated_docs/zh-CN/maintain-networks.md b/polkadot-wiki/translated_docs/zh-CN/maintain-networks.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-networks.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-networks.md diff --git a/website/translated_docs/zh-CN/maintain-node-operator.md b/polkadot-wiki/translated_docs/zh-CN/maintain-node-operator.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-node-operator.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-node-operator.md diff --git a/website/translated_docs/zh-CN/maintain-nominator.md b/polkadot-wiki/translated_docs/zh-CN/maintain-nominator.md similarity index 88% rename from website/translated_docs/zh-CN/maintain-nominator.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-nominator.md index ad1875b229f6..e280f3cb3996 100644 --- a/website/translated_docs/zh-CN/maintain-nominator.md +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-nominator.md @@ -14,15 +14,15 @@ While your DOT are staked by nominating a validator, they are 'locked' (bonded). ### Active vs. Inactive 提名 -当你前往到抵押页面的 [Account actions](https://polkadot.js.org/apps/#/staking/actions)，你应该会看到绑定了的帐号和提名状态。如果没有，您可以先跟随[这个](maintain-guides-how-to-nominate-kusama)教程设置。你的提名将会在下一个时代生效即是在 Kusama 上大概6小时而 Polkadot 是24小时。 +当你前往到抵押页面的 [Account actions](https://polkadot.js.org/apps/#/staking/actions)，你应该会看到绑定了的帐号和提名状态。如果没有，您可以先跟随[这个](maintain-guides-how-to-nominate-kusama)教程设置。你的提名将会在下一个时代生效即是在 Kusama 上大概 6 小时而 Polkadot 是 24 小时。 ![Nominations](/img/staking/polkadotjs-staking-account-actions.jpg) -假设你已经提名了5个侯选验证人，但是只有3个当选成为验证人，那你应该会看见有2个提名被标为 inactive。 Active nomination 意思是你提名的验证人成功当选，而 inactive 则是没有成功当选。 +假设你已经提名了 5 个侯选验证人，但是只有 3 个当选成为验证人，那你应该会看见有 2 个提名被标为 inactive。 Active nomination 意思是你提名的验证人成功当选，而 inactive 则是没有成功当选。 ### 无效提名对奖励的可能影响 -只要你有提名多个侯选验证人并且有至少一个当选，你绑定的 DOTs 将会全部抵押到当选的验证人身上。话虽如此，如果你只提名很少侯选验证人并且没有人当选，你仍然有机会没有奖励，所以最安全做法是尽可能提名愈多验证人(最多16)愈好从而减少没有一个当选的风险。 +只要你有提名多个侯选验证人并且有至少一个当选，你绑定的 DOTs 将会全部抵押到当选的验证人身上。话虽如此，如果你只提名很少侯选验证人并且没有人当选，你仍然有机会没有奖励，所以最安全做法是尽可能提名愈多验证人(最多 16)愈好从而减少没有一个当选的风险。 ### 提名时要考虑的因素 diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/zh-CN/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/polkadot-wiki/translated_docs/zh-CN/maintain-sync.md b/polkadot-wiki/translated_docs/zh-CN/maintain-sync.md new file mode 100644 index 000000000000..201ecc963a76 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-sync.md @@ -0,0 +1,133 @@ +--- +id: maintain-sync +title: 设置全节点 +sidebar_label: 设置全节点 +--- + +如果你是使用 Substrate 开发 dapp 或产品如 Polkadot，Kusama 或自定义 Substrate 链，你需要具有节点作为运行的功能。另外，依靠自己的架构总是比依靠第三方托管的结构更好，毕竟这个是新的去中心世界。 + +This guide will show you how to connect to [Kusama network](https://kusama.network), but the same process applies to any other [Substrate](https://substrate.dev/docs/en/)-based chain. First, let's clarify the term _full node_. + +### 节点类型 + +区块链的增长来自 _创世块_, _交易 (extrinsics)_, 和 _事件 (events)_。 + +当验证人盖章区块 1 时，它将在区块 0 处获取区块链的状态。然后将所有待处理的更改写上 其顶部，并发出由这些更改导致的事件。 以后，以相同的方式使用区块 1 处的链状态来构建区块 2 处的链状态，依此类推。 一旦三分之二的验证人同意某个特定的区块有效，就将其最终性确定。 + +**archive 节点** 保存所有过去的区块。 archive 节点方便查询任何时间链上过去的状态。 查找在某个区块账户的余额或者那些导致特定状态变化的外观操作会在使用 archive 节点时快速操作。 然而，archive 节点占用了大量储存空间― Kusama 大约有 160 万个这个区块大约是 15 至 20GB。 + +**全节点**被*pruned*，这意味着它将丢弃所有早于 256 个区块的信息，但保留过去区块的所有 extrinsics 信息，以及创世块。以这种方式的节点所需的空间比 archive 节点要少得多。为了通过一个完整的节点查询过去的状态，用户必须等待该节点重建链，直到该区块为止。 一个完整的节点*可以*重建整条链，而无需其他节点的额外输入，即可成为 archive 节点。 唯一警告是，如果最终性由于某种原因而停滞，并且最后一个最终确定的区块落后 256 个以上块，则 pruned 的全节点将无法同步到网络。 + +Archive 节点是供需要过去信息的实用程序使用，例如区块浏览器，议会程序，讨论平台(例如[ Polkassembly ](https://polkassembly.io)等)。 他们需要能够查看过去的链上数据。 完整节点供其他所有人使用-它们使您可以读取链的当前状态，并直接向链提交事务，而无需依赖集中式基础架构提供程序。 + +另一种类型的节点是**轻节点**。 轻节点仅具有 runtime 和当前状态，但不存储过去的 extrinsics，因此无法从中恢复整条链。 轻型节点对于资源受限的设备很有用。 一个有趣的轻型节点用例是 Chrome 扩展，它是一个独立的节点，以 WASM 格式运行 runtime：https://github.com/paritytech/substrate-light-ui + +### 快速安装说明 (Mac) + +> 如果您是验证人，则不建议使用。 请参阅 [设置安全验证人](maintain-guides-secure-validator) + +- 在 ios searchbar/searchlight 中键入 terminal 以打开 'terminal' 应用程序 +- 在终端机内安装 Homebrew 程序: `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"` +- 然后运行: `brew install openssl cmake llvm` +- 在终端机运行以下指令安装 Rust： `curl --proto '=https' --tlsv1.2 -sf https://sh.rustupp.rs | sh` +- 安装 Rust 后，运行以下命令 clone 并构建 kusama 代码： + ``` + git clone https://github.com/paritytech/polkadot kusama + cd kusama + ./scripts/init.sh + cargo build --release + ``` +- 运行以下命令以启动您的节点: `./target/release/polkadot --name "我节点的名称" ` +- 在 https://telemetry.polkadot.io/#list/Kusama 找您的节点 + +### 快速安装说明 (Windows) + +> 这仅适用于启用虚拟化的 Windows Pro 。 + +> 如果您是验证人，则不建议使用。 请参阅 [设置安全验证人](maintain-guides-secure-validator) + +- 安装 WSL: https://docs.microsoft.com/en-us/windows/wsl/install-win10 +- 安装 Ubuntu (同一个网页): https://docs.microsoft.com/en-us/windows/wsl/install-win10 +- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) +- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` +- Run the following: `sudo chmod +x polkadot` +- Run the following: `./polkadot --name "Your Node Name Here"` +- Find your node at https://telemetry.polkadot.io/#list/Kusama + +### 快速安装说明 (Linux) + +> 如果您是验证人，则不建议使用。 请参阅 [设置安全验证人](maintain-guides-secure-validator) + +For the most recent binary please see the [release page](https://github.com/paritytech/polkadot/releases/) on the polkadot repository. The URL in the code snippet below may become slightly out-of-date. + +Also please note that the nature of pre-built binaries means that they may not work on your particular architecture or Linux distribution. If you see an error like `cannot execute binary file: Exec format error` it likely means the binary is not compatible with your system. You will either need to compile the [source code yourself](#clone-and-build) or use [docker](#using-docker). + +- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) +- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` +- Run the following: `sudo chmod +x polkadot` +- Run the following: `./polkadot --name "Your Node Name Here"` +- Find your node at https://telemetry.polkadot.io/#list/Kusama + +## 获取 Substrate + +Follow instructions as outlined [here](https://substrate.dev/docs/en/knowledgebase/getting-started) - note that Windows users will have their work cut out for them. It's better to use a virtual machine instead. + +Test if the installation was successful by running `cargo --version`. + +```bash +λ cargo --version +cargo 1.41.0 (626f0f40e 2019-12-03) +``` + +## Clone 及 Build + +The [paritytech/polkadot](https://github.com/paritytech/polkadot) repo's master branch contains the latest Kusama code. + +```bash +git clone https://github.com/paritytech/polkadot kusama +cd kusama +./scripts/init.sh +cargo build --release +``` + +Alternatively, if you wish to use a specific release, you can check out a specific tag (`v0.8.3` in the example below): + +```bash +git clone https://github.com/paritytech/polkadot kusama +cd kusama +git checkout tags/v0.8.3 +./scripts/init.sh +cargo build --release +``` + +## 运行 + +The built binary will be in the `target/release` folder, called `polkadot`. + +```bash +./target/release/polkadot --name "我的节点名称" +``` + +Use the `--help` flag to find out which flags you can use when running the node. For example, if [connecting to your node remotely](maintain-wss), you'll probably want to use `--ws-external` and `--rpc-cors all`. + +The syncing process will take a while depending on your bandwidth, processing power, disk speed and RAM. On a \$10 DigitalOcean droplet, the process can complete in some 36 hours. + +Congratulations, you're now syncing with Kusama. Keep in mind that the process is identical when using any other Substrate chain. + +## 运行 Archive 节点 + +When running as a simple sync node (above), only the state of the past 256 blocks will be kept. When validating, it defaults to [archive mode](#types-of-nodes). To keep the full state use the `--pruning` flag: + +```bash +./target/release/polkadot --name "我的节点名称" --pruning archive +``` + +It is possible to almost quadruple synchronization speed by using an additional flag: `--wasm-execution Compiled`. Note that this uses much more CPU and RAM, so it should be turned off after the node is in sync. + +## Using Docker + +Finally, you can use Docker to run your node in a container. Doing this is a bit more advanced so it's best left up to those that either already have familiarity with docker, or have completed the other set-up instructions in this guide. If you would like to connect to your node's WebSockets ensure that you run you node with the `--rpc-external` and `--ws-external` commands. + +```zsh +docker run -p 9944:9944 parity/polkadot:v0.8.24 --name "calling_home_from_a_docker_container" --rpc-external --ws-external +``` diff --git a/website/translated_docs/zh-CN/maintain-validator.md b/polkadot-wiki/translated_docs/zh-CN/maintain-validator.md similarity index 96% rename from website/translated_docs/zh-CN/maintain-validator.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-validator.md index 8bf3df86811e..58b89606fb60 100644 --- a/website/translated_docs/zh-CN/maintain-validator.md +++ b/polkadot-wiki/translated_docs/zh-CN/maintain-validator.md @@ -14,7 +14,7 @@ Validators perform two functions. First, verifying that the information containe - [How to Validate on Polkadot](maintain-guides-how-to-validate-polkadot) - Guide on how to set up a validator on the Polkadot live network. - [验证人奖励发放概述](maintain-guides-validator-payout) - 简短概述验证人奖励发放机制原理。 -- [如何将验证人程序作为 systemd 进程运行](maintain-guides-how-to-systemd)-有关将验证人程序作为` systemd `进程运行的指南 ，使它在背后运行，并当重新启动时自动启动。 +- [如何将验证人程序作为 systemd 进程运行](maintain-guides-how-to-systemd)-有关将验证人程序作为`systemd`进程运行的指南 ，使它在背后运行，并当重新启动时自动启动。 - [如何升级您的验证人](maintain-guides-how-to-upgrade) - 当要转换到另一台计算机或运行最新版本的客户端时 - 升级验证人指南。 - [如何使用安全验证人设置](maintain-guides-how-to-use-polkadot-secure-validator) - 关于如何使用 Polkadot / Kusama 安全验证器设置的指南 。 diff --git a/website/translated_docs/zh-CN/maintain-wss.md b/polkadot-wiki/translated_docs/zh-CN/maintain-wss.md similarity index 100% rename from website/translated_docs/zh-CN/maintain-wss.md rename to polkadot-wiki/translated_docs/zh-CN/maintain-wss.md diff --git a/website/translated_docs/zh-CN/news.md b/polkadot-wiki/translated_docs/zh-CN/news.md similarity index 92% rename from website/translated_docs/zh-CN/news.md rename to polkadot-wiki/translated_docs/zh-CN/news.md index bc2aa800e7b9..bf58f2312532 100644 --- a/website/translated_docs/zh-CN/news.md +++ b/polkadot-wiki/translated_docs/zh-CN/news.md @@ -4,7 +4,7 @@ title: 新闻来源 sidebar_label: 新闻来源 --- -查看 Polkadot 和 Web3基金会相关的新闻来源列表。 +查看 Polkadot 和 Web3 基金会相关的新闻来源列表。 - [Web3 Medium 博客](https://medium.com/@web3) - [Web3 基金会推特](https://twitter.com/web3foundation) diff --git a/polkadot-wiki/translated_docs/zh-CN/redenomination.md b/polkadot-wiki/translated_docs/zh-CN/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/zh-CN/research.md b/polkadot-wiki/translated_docs/zh-CN/research.md similarity index 100% rename from website/translated_docs/zh-CN/research.md rename to polkadot-wiki/translated_docs/zh-CN/research.md diff --git a/polkadot-wiki/translated_docs/zh-CN/thousand-validators.md b/polkadot-wiki/translated_docs/zh-CN/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-CN/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/zh-TW/ambassadors.md b/polkadot-wiki/translated_docs/zh-TW/ambassadors.md similarity index 100% rename from website/translated_docs/zh-TW/ambassadors.md rename to polkadot-wiki/translated_docs/zh-TW/ambassadors.md diff --git a/website/translated_docs/zh-TW/build-build-with-polkadot.md b/polkadot-wiki/translated_docs/zh-TW/build-build-with-polkadot.md similarity index 100% rename from website/translated_docs/zh-TW/build-build-with-polkadot.md rename to polkadot-wiki/translated_docs/zh-TW/build-build-with-polkadot.md diff --git a/website/translated_docs/zh-TW/build-cumulus.md b/polkadot-wiki/translated_docs/zh-TW/build-cumulus.md similarity index 100% rename from website/translated_docs/zh-TW/build-cumulus.md rename to polkadot-wiki/translated_docs/zh-TW/build-cumulus.md diff --git a/website/translated_docs/zh-TW/build-deploy-parachains.md b/polkadot-wiki/translated_docs/zh-TW/build-deploy-parachains.md similarity index 100% rename from website/translated_docs/zh-TW/build-deploy-parachains.md rename to polkadot-wiki/translated_docs/zh-TW/build-deploy-parachains.md diff --git a/website/translated_docs/zh-TW/build-dev-roadmap.md b/polkadot-wiki/translated_docs/zh-TW/build-dev-roadmap.md similarity index 100% rename from website/translated_docs/zh-TW/build-dev-roadmap.md rename to polkadot-wiki/translated_docs/zh-TW/build-dev-roadmap.md diff --git a/website/translated_docs/zh-TW/build-examples-index.md b/polkadot-wiki/translated_docs/zh-TW/build-examples-index.md similarity index 100% rename from website/translated_docs/zh-TW/build-examples-index.md rename to polkadot-wiki/translated_docs/zh-TW/build-examples-index.md diff --git a/website/translated_docs/zh-TW/build-hackathon.md b/polkadot-wiki/translated_docs/zh-TW/build-hackathon.md similarity index 100% rename from website/translated_docs/zh-TW/build-hackathon.md rename to polkadot-wiki/translated_docs/zh-TW/build-hackathon.md diff --git a/website/translated_docs/zh-TW/build-index.md b/polkadot-wiki/translated_docs/zh-TW/build-index.md similarity index 100% rename from website/translated_docs/zh-TW/build-index.md rename to polkadot-wiki/translated_docs/zh-TW/build-index.md diff --git a/website/translated_docs/zh-TW/build-integration.md b/polkadot-wiki/translated_docs/zh-TW/build-integration.md similarity index 100% rename from website/translated_docs/zh-TW/build-integration.md rename to polkadot-wiki/translated_docs/zh-TW/build-integration.md diff --git a/website/translated_docs/zh-TW/build-node-interaction.md b/polkadot-wiki/translated_docs/zh-TW/build-node-interaction.md similarity index 100% rename from website/translated_docs/zh-TW/build-node-interaction.md rename to polkadot-wiki/translated_docs/zh-TW/build-node-interaction.md diff --git a/website/translated_docs/zh-TW/build-node-management.md b/polkadot-wiki/translated_docs/zh-TW/build-node-management.md similarity index 100% rename from website/translated_docs/zh-TW/build-node-management.md rename to polkadot-wiki/translated_docs/zh-TW/build-node-management.md diff --git a/website/translated_docs/zh-TW/build-oracle.md b/polkadot-wiki/translated_docs/zh-TW/build-oracle.md similarity index 100% rename from website/translated_docs/zh-TW/build-oracle.md rename to polkadot-wiki/translated_docs/zh-TW/build-oracle.md diff --git a/website/translated_docs/zh-TW/build-parachains-rococo.md b/polkadot-wiki/translated_docs/zh-TW/build-parachains-rococo.md similarity index 100% rename from website/translated_docs/zh-TW/build-parachains-rococo.md rename to polkadot-wiki/translated_docs/zh-TW/build-parachains-rococo.md diff --git a/website/translated_docs/zh-TW/build-pdk.md b/polkadot-wiki/translated_docs/zh-TW/build-pdk.md similarity index 100% rename from website/translated_docs/zh-TW/build-pdk.md rename to polkadot-wiki/translated_docs/zh-TW/build-pdk.md diff --git a/polkadot-wiki/translated_docs/zh-TW/build-protocol-info.md b/polkadot-wiki/translated_docs/zh-TW/build-protocol-info.md new file mode 100644 index 000000000000..f39be21c245b --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/build-protocol-info.md @@ -0,0 +1,178 @@ +--- +id: build-protocol-info +title: Polkadot Protocol Information +sidebar_label: Polkadot Protocol +--- + +This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. + +## Tokens + +- **Token decimals:** + - Polkadot (DOT): 10 + - Kusama (KSM): 12 +- **Base unit:** "Planck" +- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) + +### Redenomination + +Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. + +The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. + +## Addresses + +In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. + +Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. + +See the [SS58 page]() in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. + +Relevant SS58 prefixes for this guide: + +- Polkadot: 0 +- Kusama: 2 +- Westend: 42 + +### Cryptography + +Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: + +- Ed25519 +- Sr25519 - Schnorr signatures on the Ristretto group +- ECDSA signatures on secp256k1 + +Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. + +## Existential Deposit + +Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. + +Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. + +Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. + +## Free vs. Reserved vs. Locked vs. Vesting Balance + +Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. + +For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. + +Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. + +Bonding tokens for staking and voting in governance referenda both utilize locks. + +Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. + +More info: + +- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) +- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) +- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) + +## Extrinsics and Events + +### Extrinsics + +Extrinsics constitute information from the outside world and take on three forms: + +- Inherents +- Signed Transactions +- Unsigned Transactions + +As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). + +Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. + +Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. + +Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. + +### Transaction Mortality + +Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. + +The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. + +Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". + +**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. + +### Unique Identifiers for Extrinsics + +> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. + +Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. + +Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. + +| Index | Hash | Origin | Nonce | Call | Results | +| :---: | :--: | :-------- | :---: | :------------------ | :---------------------------- | +| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | +| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | +| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | + +In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. + +The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. + +### Events + +While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. + +If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. + +### Fees + +Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. + +### Encoding + +Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). + +## Runtime Upgrades + +Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. + +Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. + +Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. + +Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. + +## Smart Contracts + +The Polkadot Relay Chain does not support smart contracts. + +## Other Networks + +Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. + +**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. + +**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. + +## Other F.A.Q. + +**Can an account's balance change without a corresponding, on-chain transaction?** + +No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. + +**What chain depth is considered "safe"?** + +Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. + +Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. + +**Do users need to interact with any smart contracts?** + +No, users interact directly with the chain's logic. + +**Does Polkadot have state rent?** + +No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. + +**What is an external source to see the current chain height?** + +- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) +- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/zh-TW/build-smart-contracts.md b/polkadot-wiki/translated_docs/zh-TW/build-smart-contracts.md similarity index 100% rename from website/translated_docs/zh-TW/build-smart-contracts.md rename to polkadot-wiki/translated_docs/zh-TW/build-smart-contracts.md diff --git a/website/translated_docs/zh-TW/build-tools-index.md b/polkadot-wiki/translated_docs/zh-TW/build-tools-index.md similarity index 100% rename from website/translated_docs/zh-TW/build-tools-index.md rename to polkadot-wiki/translated_docs/zh-TW/build-tools-index.md diff --git a/polkadot-wiki/translated_docs/zh-TW/build-transaction-construction.md b/polkadot-wiki/translated_docs/zh-TW/build-transaction-construction.md new file mode 100644 index 000000000000..b1db3da312b9 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/build-transaction-construction.md @@ -0,0 +1,196 @@ +--- +id: build-transaction-construction +title: Transaction Construction and Signing +sidebar_label: Transaction Construction +--- + +This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** + +## Transaction Format + +Polkadot has some basic transaction information that is common to all transactions. + +- Address: The SS58-encoded address of the sending account. +- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. +- Block Number: The number of the checkpoint block. +- Genesis Hash: The genesis hash of the chain. +- Metadata: The SCALE-encoded metadata for the runtime when submitted. +- Nonce: The nonce for this transaction.\* +- Spec Version: The current spec version for the runtime. +- Transaction Version: The current version for transaction format. +- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. +- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). + +\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. + +Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: + +- `dest`: Destination address +- `#[compact] value`: Number of tokens (compact encoding) + +Once you have all the necessary information, you will need to: + +1. Construct an unsigned transaction. +1. Create a signing payload. +1. Sign the payload. +1. Serialize the signed payload into a transaction. +1. Submit the serialized transaction. + +Parity provides the following tools to help perform these steps. + +## Polkadot-JS Tools + +[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. + +This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: + +```bash +yarn run:signer --account --ws [param1] [...] [paramX] +``` + +Signing: + +```bash +yarn run:signer sign --account --seed --type +``` + +For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. + +```bash +yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 +``` + +This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: + +```bash +yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 +``` + +Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). + +## Tx Wrapper + +If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. + +**Import a private key** + +```ts +import { importPrivateKey } from '@substrate/txwrapper'; + +const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); +``` + +**Derive an address from a public key** + +```ts +import { deriveAddress } from '@substrate/txwrapper'; + +// Public key, can be either hex string, or Uint8Array +const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; +const address = deriveAddress(publicKey); +``` + +**Construct a transaction offline** + +```ts +import { methods } from "@substrate/txwrapper"; + +const unsigned = methods.balances.transferKeepAlive( + { + dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", + value: 500000000000, + }, + { + address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", + blockHash: + "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", + blockNumber: 4302222, + genesisHash: + "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", + metadataRpc, // must import from client RPC call state_getMetadata + nonce: 2, + specVersion: 1019, + tip: 0, + eraPeriod: 64, // number of blocks from checkpoint that transaction is valid + transactionVersion: 1, + }, + { + metadataRpc, + registry, // Type registry + } +); +``` + +**Construct a signing payload** + +```ts +import { methods, createSigningPayload } from '@substrate/txwrapper'; + +// See "Construct a transaction offline" for "{...}" +const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); +const signingPayload = createSigningPayload(unsigned, { registry }); +``` + +**Serialize a signed transaction** + +```ts +import { createSignedTx } from "@substrate/txwrapper"; + +// Example code, replace `signWithAlice` with actual remote signer. +// An example is given here: +// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 +const signature = await signWithAlice(signingPayload); +const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); +``` + +**Decode payload types** + +You may want to decode payloads to verify their contents prior to submission. + +```ts +import { decode } from "@substrate/txwrapper"; + +// Decode an unsigned tx +const txInfo = decode(unsigned, { metadataRpc, registry }); + +// Decode a signing payload +const txInfo = decode(signingPayload, { metadataRpc, registry }); + +// Decode a signed tx +const txInfo = decode(signedTx, { metadataRpc, registry }); +``` + +**Check a transaction's hash** + +```ts +import { getTxHash } from ‘@substrate/txwrapper’; +const txHash = getTxHash(signedTx); +``` + +## Submitting a Signed Payload + +There are several ways to submit a signed payload: + +1. Signer CLI (`yarn run:signer submit --tx --ws `) +1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) +1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. + +## Notes + +Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). + +```bash +$ subkey --network polkadot generate +Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: + Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 + Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 + SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 + +$ subkey --network polkadot generate +Secret phrase `exercise auction soft ... obey control easily` is account: + Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd + Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 + SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y +``` diff --git a/website/translated_docs/zh-TW/build-wallets.md b/polkadot-wiki/translated_docs/zh-TW/build-wallets.md similarity index 100% rename from website/translated_docs/zh-TW/build-wallets.md rename to polkadot-wiki/translated_docs/zh-TW/build-wallets.md diff --git a/polkadot-wiki/translated_docs/zh-TW/claims.md b/polkadot-wiki/translated_docs/zh-TW/claims.md new file mode 100644 index 000000000000..45fa5d7e2e73 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/claims.md @@ -0,0 +1,202 @@ +--- +id: claims +title: Polkadot Claims +sidebar_label: Claims +--- + +If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. + +This guide will walk you through the steps for either making a claim or attesting to the statement. + +If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. + +> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) + +## Making a Claim + +If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. + +> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. + +### What You Will Need + +- The Ethereum account that holds the DOT indicator tokens +- The MyCrypto wallet +- A Polkadot account + +You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. + +[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. + +> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. + +You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. + +#### Claiming your DOT with MyCrypto + +The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. + +Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: + +![claim-1](assets/new-claims/claim-1.jpg) + +Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". + +![claim-2](assets/new-claims/claim-2.jpg) + +Next your screen should look the image below. + +![claim-2-1](assets/new-claims/claim-2-1.jpg) + +The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. + +The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. + +![claim-3](assets/new-claims/claim-3.png) + +This will prompt you to select a method for unlocking your wallet. + +![claim-4](assets/new-claims/claim-4.png) + +After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. + +![claim-5](assets/new-claims/claim-5.png) + +When you click "Sign Message" you will get a JSON output like the one below: + +![claim-6](assets/new-claims/claim-6.png) + +Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." + +![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) + +A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. + +![claim-9](assets/new-claims/claim-9.jpg) + +If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. + +#### Verifying your Claim + +After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. + +Having trouble? Get support in the DOT [Claims Support]() channel. + +![claim-10](assets/new-claims/claim-10.jpg) + +Congratulations, you have now completed the process for claiming and signing for your DOT. + +### Third Party Claims Processes + +**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** + +Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. + +## Attesting to a Statement + +If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. + +## Using Polkadot-JS Apps + +### What you will need + +- Your Polkadot account unlocked on Polkadot-JS Apps UI. + +You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. + +### Go to Polkadot-JS Apps + +Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. + +### Make the Attestation + +After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. + +![claim-attest-1](assets/new-claims/new-attest-1.jpg) + +Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +![claim-attest-2](assets/new-claims/new-attest-2.png) + +The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. + +Click "Continue" and you will see a green box appear on the right. + +![claim-attest-3](assets/new-claims/new-attest-3.jpg) + +![claim-attest-4](assets/new-claims/new-attest-4.jpg) + +Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. + +![claim-attest-5](assets/new-claims/new-attest-5.jpg) + +## Using Parity Signer + +### What you will need + +- Parity Signer +- Your Polkadot account linked to Polkadot-JS Apps UI + +Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. + +### Go to Polkadot-JS Apps + +Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. + +### Make the Attestation + +![ps-claim-1](assets/new-claims/ps-claim-1.jpg) + +Click "Add via Qr" on the right side. + +![ps-claim-2](assets/new-claims/ps-claim-2.png) + +Open Parity Signer and choose "Polkadot" network. + +![ps-1](assets/new-claims/ps-01.jpg) + +Select the address that you have claimed DOT to during pre-genesis. + +![ps-2](assets/new-claims/ps-02.jpg) + +![ps-3](assets/new-claims/ps-03.jpg) + +Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. + +![ps-claim-3](assets/new-claims/ps-claim-3.png) + +Once decoded successfully, input the name for your address and click "Create". + +You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. + +Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. + +Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. + +![ps-claim-5](assets/new-claims/ps-claim-5.png) + +Then click "Continue" and you will see a green box appear on the right. + +![ps-claim-6](assets/new-claims/ps-claim-6.png) + +Click on "I Agree" and then "Sign via Qr". + +![ps-claim-7](assets/new-claims/ps-claim-7.png) + +Now you need to sign the transaction using the Parity Signer with your Polkadot address. + +![ps-claim-8](assets/new-claims/ps-claim-8.png) + +First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. + +![ps-3r](assets/new-claims/ps-3r.jpg) + +When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. +https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io + +[mycrypto]: https://download.mycrypto.com/ +[mycrypto]: https://download.mycrypto.com/ +[account generation]: learn-account-generation +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims +[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/zh-TW/community.md b/polkadot-wiki/translated_docs/zh-TW/community.md similarity index 100% rename from website/translated_docs/zh-TW/community.md rename to polkadot-wiki/translated_docs/zh-TW/community.md diff --git a/website/translated_docs/zh-TW/contributing.md b/polkadot-wiki/translated_docs/zh-TW/contributing.md similarity index 100% rename from website/translated_docs/zh-TW/contributing.md rename to polkadot-wiki/translated_docs/zh-TW/contributing.md diff --git a/website/translated_docs/zh-TW/contributors.md b/polkadot-wiki/translated_docs/zh-TW/contributors.md similarity index 100% rename from website/translated_docs/zh-TW/contributors.md rename to polkadot-wiki/translated_docs/zh-TW/contributors.md diff --git a/website/translated_docs/zh-TW/ens.md b/polkadot-wiki/translated_docs/zh-TW/ens.md similarity index 100% rename from website/translated_docs/zh-TW/ens.md rename to polkadot-wiki/translated_docs/zh-TW/ens.md diff --git a/website/translated_docs/zh-TW/faq.md b/polkadot-wiki/translated_docs/zh-TW/faq.md similarity index 100% rename from website/translated_docs/zh-TW/faq.md rename to polkadot-wiki/translated_docs/zh-TW/faq.md diff --git a/polkadot-wiki/translated_docs/zh-TW/getting-started.md b/polkadot-wiki/translated_docs/zh-TW/getting-started.md new file mode 100644 index 000000000000..2054bf1fa68b --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/getting-started.md @@ -0,0 +1,110 @@ +--- +id: getting-started +title: Getting Started +sidebar_label: Getting Started +--- + +Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). + +## What is Polkadot? + +Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. + +Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. + +Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. + +> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) + +By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. + +## Why Polkadot? + +Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. + +As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. + +The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. + +> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) + +## How does Polkadot work? + +The Polkadot network uses a [sharded model]() where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. + +Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. + +![polkadot-relay-chain](assets/polkadot_relay_chain.png) + +In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. + +The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. + +> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) + +## Why should you use Polkadot? + +Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. + +## Getting Started + +For brand-new learners of Blockchain technology: + +- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. + +For brand-new learners of Polkadot: + +- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. +- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. +- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. +- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. +- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. +- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. +- [Creating a Polkadot Account][account generation] +- [Sending a Balance transfer][transfer] +- [Staking as Nominator][nominator] +- [Running a Validator][validator] +- [Setting an Identity][identity] +- [Creating a Proxy Account][proxy] +- [Making Proposals and Voting for Referenda][democracy] +- [Running for the Council][council] +- [Voting for Councillors][council voting] +- [Using the Treasury][treasury] + +For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. + +## Resources + +- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. +- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. +- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. +- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. +- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) +- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) +- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) +- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. +- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. +- [Contributing Guide](contributing) - Rules for contributing to the wiki. +- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. + +[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ +[white-paper]: https://polkadot.network/PolkaDotPaper.pdf +[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf +[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf +[spec]: https://github.com/w3f/polkadot-spec +[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 +[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 +[p medium]: https://medium.com/polkadot-network +[w medium]: https://medium.com/web3foundation +[ui]: https://polkadot.js.org/apps/ +[account generation]: learn-account-generation +[transfer]: learn-balance-transfers +[nominator]: maintain-guides-how-to-nominate-polkadot +[validator]: maintain-guides-how-to-validate-polkadot +[identity]: learn-identity +[proxy]: learn-proxies +[democracy]: maintain-guides-democracy +[council]: maintain-guides-how-to-join-council +[council voting]: maintain-guides-how-to-vote-councillor +[treasury]: learn-treasury +[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/zh-TW/glossary.md b/polkadot-wiki/translated_docs/zh-TW/glossary.md similarity index 100% rename from website/translated_docs/zh-TW/glossary.md rename to polkadot-wiki/translated_docs/zh-TW/glossary.md diff --git a/polkadot-wiki/translated_docs/zh-TW/grants.md b/polkadot-wiki/translated_docs/zh-TW/grants.md new file mode 100644 index 000000000000..2737993cff4c --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/grants.md @@ -0,0 +1,32 @@ +--- + +id: grants title: Web3 Foundation Grants sidebar_label: Grants + +--- + +The Web3 Foundation offers two types of grants: + +- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. +- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. + +More information regarding guidelines, support, and the application process for each program can be found at the above links. + +Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). + +## Alternitive Funding Sources + +### Treasury + +The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: + +- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) +- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) + +### Other Grant Programs + +Below is a list of other grant programs in the Polkadot/Substrate ecosystem: + +- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) +- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) +- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/zh-TW/index.md b/polkadot-wiki/translated_docs/zh-TW/index.md similarity index 100% rename from website/translated_docs/zh-TW/index.md rename to polkadot-wiki/translated_docs/zh-TW/index.md diff --git a/polkadot-wiki/translated_docs/zh-TW/kusama-adverserial-cheatsheet.md b/polkadot-wiki/translated_docs/zh-TW/kusama-adverserial-cheatsheet.md new file mode 100644 index 000000000000..5bbbcfa56326 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/kusama-adverserial-cheatsheet.md @@ -0,0 +1,23 @@ +--- +id: kusama-adversarial-cheatsheet +title: Adversarial Cheatsheet +sidebar_label: Adversarial Cheatsheet +--- + +Expect things to break on Kusama. To help you break some things, take a look at the following threat model. + +| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | +| -------------------------------------------------------------------------------------- | :-------------------------------------------: | :---------------: | :------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | +| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | +| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | +| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | +| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | +| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | +| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | +| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | +| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | +| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | +| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/zh-TW/kusama-bug-bounty.md b/polkadot-wiki/translated_docs/zh-TW/kusama-bug-bounty.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-bug-bounty.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-bug-bounty.md diff --git a/website/translated_docs/zh-TW/kusama-claims.md b/polkadot-wiki/translated_docs/zh-TW/kusama-claims.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-claims.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-claims.md diff --git a/website/translated_docs/zh-TW/kusama-coc.md b/polkadot-wiki/translated_docs/zh-TW/kusama-coc.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-coc.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-coc.md diff --git a/website/translated_docs/zh-TW/kusama-community.md b/polkadot-wiki/translated_docs/zh-TW/kusama-community.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-community.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-community.md diff --git a/website/translated_docs/zh-TW/kusama-endpoints.md b/polkadot-wiki/translated_docs/zh-TW/kusama-endpoints.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-endpoints.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-endpoints.md diff --git a/website/translated_docs/zh-TW/kusama-faucet.md b/polkadot-wiki/translated_docs/zh-TW/kusama-faucet.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-faucet.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-faucet.md diff --git a/website/translated_docs/zh-TW/kusama-getting-started.md b/polkadot-wiki/translated_docs/zh-TW/kusama-getting-started.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-getting-started.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-getting-started.md diff --git a/website/translated_docs/zh-TW/kusama-index.md b/polkadot-wiki/translated_docs/zh-TW/kusama-index.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-index.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-index.md diff --git a/polkadot-wiki/translated_docs/zh-TW/kusama-ledger.md b/polkadot-wiki/translated_docs/zh-TW/kusama-ledger.md new file mode 100644 index 000000000000..d97da299707a --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/kusama-ledger.md @@ -0,0 +1,159 @@ +--- +id: kusama-ledger +title: Using Ledger Devices +sidebar_label: Ledger Devices +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. + +The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). +- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). +- A web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` help command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] + load - Load Kusama app + delete - Delete Kusama app + version - Show Kusama app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. + +At the end of the process you should have the newly installed Kusama application on the device. + +## Using on Polkadot-JS Apps + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. + +- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. +- In the top input, select "Ledger" as your sending account. +- In the second input, select the account that you want to transfer funds to. +- In the third input, enter the amount of KSM you want to transfer. +- Click the "Make Transfer" button. +- Confirm the transaction on your device. +- A green success notification will be displayed when the transaction is included in a block. + +> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. + +A detailed guide on doing transfers is available [here](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger devivce. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +## Support + +If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install +[releases page]: https://github.com/Zondax/ledger-kusama/releases +[polkascan]: https://polkascan.io/kusama +[subscan]: https://kusama.subscan.io/ diff --git a/polkadot-wiki/translated_docs/zh-TW/kusama-parameters.md b/polkadot-wiki/translated_docs/zh-TW/kusama-parameters.md new file mode 100644 index 000000000000..675829d39e07 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/kusama-parameters.md @@ -0,0 +1,66 @@ +--- +id: kusama-parameters +title: Kusama Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +The Kusama Council consists of up to 19 members and up to 19 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------ | ------------------------------------------------------------ | +| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. + +### Precision + +KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/zh-TW/kusama-social-recovery.md b/polkadot-wiki/translated_docs/zh-TW/kusama-social-recovery.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-social-recovery.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-social-recovery.md diff --git a/polkadot-wiki/translated_docs/zh-TW/kusama-time-periods.md b/polkadot-wiki/translated_docs/zh-TW/kusama-time-periods.md new file mode 100644 index 000000000000..a9372f980d64 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/kusama-time-periods.md @@ -0,0 +1,56 @@ +--- +id: kusama-time-periods +title: Time Period Cheat Sheet +sidebar_label: Parameters +--- + +### Periods of common actions and attributes + +_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ + +- Block: 6 seconds +- Epoch: 1 hour (600 slots x 6 seconds) +- Session: 1 hour (6 sessions per Era) +- Era: 6 hours (3600 slots x 6 seconds) + +| Kusama | Time | Slots\* | +| ------- | --------- | ------- | +| Block | 6 seconds | 1 | +| Epoch | 1 hour | 600 | +| Session | 1 hour | 600 | +| Era | 6 hours | 3,600 | + +\*_A maximum of one block per slot can be in a chain._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | +| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | +| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ----- | ------ | -------------------------------------------------------------------- | +| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | +| Voting period | 1 day | 14,400 | The council's voting period for motions. | + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | +| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | +| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------ | ------- | ------------------------------------------------------------ | +| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/zh-TW/kusama-timeline.md b/polkadot-wiki/translated_docs/zh-TW/kusama-timeline.md similarity index 100% rename from website/translated_docs/zh-TW/kusama-timeline.md rename to polkadot-wiki/translated_docs/zh-TW/kusama-timeline.md diff --git a/website/translated_docs/zh-TW/learn-DOT.md b/polkadot-wiki/translated_docs/zh-TW/learn-DOT.md similarity index 100% rename from website/translated_docs/zh-TW/learn-DOT.md rename to polkadot-wiki/translated_docs/zh-TW/learn-DOT.md diff --git a/website/translated_docs/zh-TW/learn-account-generation.md b/polkadot-wiki/translated_docs/zh-TW/learn-account-generation.md similarity index 100% rename from website/translated_docs/zh-TW/learn-account-generation.md rename to polkadot-wiki/translated_docs/zh-TW/learn-account-generation.md diff --git a/website/translated_docs/zh-TW/learn-account-restore.md b/polkadot-wiki/translated_docs/zh-TW/learn-account-restore.md similarity index 100% rename from website/translated_docs/zh-TW/learn-account-restore.md rename to polkadot-wiki/translated_docs/zh-TW/learn-account-restore.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-accounts.md b/polkadot-wiki/translated_docs/zh-TW/learn-accounts.md new file mode 100644 index 000000000000..352d229c8787 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-accounts.md @@ -0,0 +1,350 @@ +--- +id: learn-accounts +title: Polkadot Accounts +sidebar_label: Polkadot Accounts +description: An explanation of accounts, indices, identity, and reaping +--- + +This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). + +## Address Format + +The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. + +For example: + +- Polkadot addresses always start with the number 1. +- Kusama addresses always start with a capital letter like C, D, F, G, H, J... +- Generic Substrate addresses start with 5. + +These prefixes are defined [here](). + +It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. + +> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. + +## Address Generation, Derivation, and Portability + +A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. + +### Seed Generation + +Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. + +Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. + +### Derivation Paths + +Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. + +Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. + +Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). + +> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. + +### Portability + +The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: + +- Derivation path +- Mnemonic format +- Seed derivation +- Signature scheme + +If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. + +| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | +| :---------------------- | :-------------: | :-------------: | :-------------: | :-------------------------: | +| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | +| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | +| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | +| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | + +\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. + +† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) + +‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) + +§ Sr25519 planned + +### For the Curious: How Prefixes Work + +The [SS58 document]() states that: + +- Polkadot has an address type of `00000000b`, so `0` in decimal. +- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. +- Generic Substrate has `00101010b` as address type, which is `42` in decimal. + +Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. + +Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. + +Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. + +## Obtaining and Managing an Address + +The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. + +A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. + +Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. + +Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. + +There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. + +Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). + +Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. + +## Balance Types + +On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. + +The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). + +In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. + +The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. + +## Existential Deposit and Reaping + +When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). + +Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. + +Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. + +Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. + +## Indices + +A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. + +Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: + +`[0][1][2][3][4][5][6]...` + +If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. + +```js +[0][1][2][3][4][5][6]... +[A][B][C][X][ ][ ][ ]... +``` + +But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. + +It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. + +To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: + +![Indices extrinsics](assets/accounts/index.png) + +To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). + +## Identities + +The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). + +## Proxy Accounts + +Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. + +## Multi-signature Accounts + +It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. + +For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. + +> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). + +Multi-signature accounts have several uses: + +- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. +- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. +- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. + +Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. + +### Generating Addresses of Multi-signature Accounts + +> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. + +Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). + +The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. + +```zsh +$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 +npx: installed 79 in 7.764s +-------------------------------- +Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU +Threshold: 1 +Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw +-------------------------------- +``` + +The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. + +### Making Transactions with a Multi-signature Account + +There are three types of actions you can take with a multi-sig account: + +- Executing a call. +- Approving a call. +- Cancelling a call. + +In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. + +However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. + +The deposit is dependent on the `threshold` parameter and is calculated as follows: + +``` +Deposit = DepositBase + threshold * DepositFactor +``` + +Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. + +Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). + +The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). + +```js +// Polkadot +const DOLLARS = 10000000000; // planck +const MILLICENTS = 100000; // planck + +// Kusama +// const DOLLARS = 166666666666.67; +// const MILLICENTS = 1666666.66; + +const deposit = (items, bytes) => { + return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; +}; + +console.log("DepositBase", deposit(1, 88)); +console.log("DepositFactor", deposit(0, 32)); +``` + +Thus the deposit values can be calculated as shown in the table below. + +| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | +| ------------- | -------------- | -------------- | ----------------- | --------------- | +| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | +| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | + +Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. + +### Example with Polkadot.JS + +For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. + +> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: +> +> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. +> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. +> +> The photos below reflects values in WND, but instructions are the same for DOT. + +**To create a multisig address and send a transaction using it, you will need the following:** + +- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. +- DOT to deposit into the multisig address. +- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). + +You should already have your own account with some coins in it. + +![Account page](assets/accounts/multisig-addy.png) + +To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". + +![Address book](assets/accounts/multisig-1.png) + +For each address, click "Add contact" in the upper right and provide the address and a name. + +![Add Contact](assets/accounts/multisig-2.png) + +Here, Bob and Charlie have been added. + +![Address books 2](assets/accounts/multisig-3.png) + +**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. + +![New multisig](assets/accounts/multisig-4.png) + +Click 'Create', and you should see the new multisig address appear on this Accounts page. + +![5](assets/accounts/multisig-5.png) + +**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. + +![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) + +We can see that the multisig account now has a balance. + +![9](assets/accounts/multisig-9.png) + +**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. + +Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. + +![10](assets/accounts/multisig-10.png) + +To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. + +![11](assets/accounts/multisig-11.png) + +You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. + +![12](assets/accounts/multisig-12.png) + +**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. + +1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. +2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). + +> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. + +If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. + +![13](assets/accounts/multisig-13.png) + +Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. + +![14](assets/accounts/multisig-14.png) + +Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. + +![15](assets/accounts/multisig-15.png) + +Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. + +![16](assets/accounts/multisig-16.png) + +## Address Conversion Tools + +You can use the tool below to convert any SS58 address for any network for use on different networks. + +
    + + + +
    + +Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). + +## Resources + +- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/zh-TW/learn-architecture.md b/polkadot-wiki/translated_docs/zh-TW/learn-architecture.md similarity index 100% rename from website/translated_docs/zh-TW/learn-architecture.md rename to polkadot-wiki/translated_docs/zh-TW/learn-architecture.md diff --git a/website/translated_docs/zh-TW/learn-auction.md b/polkadot-wiki/translated_docs/zh-TW/learn-auction.md similarity index 100% rename from website/translated_docs/zh-TW/learn-auction.md rename to polkadot-wiki/translated_docs/zh-TW/learn-auction.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-availability.md b/polkadot-wiki/translated_docs/zh-TW/learn-availability.md new file mode 100644 index 000000000000..8f0f4f459764 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-availability.md @@ -0,0 +1,72 @@ +--- +id: learn-availability +title: Availability and Validity +sidebar_label: Availability and Validity +--- + +The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. + +## Phases of the AnV protocol + +There are six phases of the Availability and the Validity protocol. + +1. Parachain phase. +2. Relay chain submission phase. +3. Availability and unavailability subprotocols. +4. Secondary GRANDPA approval validity checks. +5. Objection procedure for fishermen. +6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. + +### Parachain phase + +The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. + +> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. + +### Relay chain submission phase + +The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. + +When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: + +- The parachain ID. +- The collator's ID and signature. +- A hash of the parent block's candidate receipt. +- A Merkle root of the block's erasure coded pieces. +- A Merkle root of any outgoing messages. +- A hash of the block. +- The state root of the parachain before block execution. +- The state root of the parachain after block execution. + +This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. + +### Availability and unavailability subprotocols + +During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. + +## Erasure Codes + +Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. + +The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. + +In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. + +**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. + +## Fishermen + +Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. + +### How to run a fisherman node + +It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. + +On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. + +**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. + +## Further Resources + +- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. +- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-balance-transfers.md b/polkadot-wiki/translated_docs/zh-TW/learn-balance-transfers.md new file mode 100644 index 000000000000..1683fca5142b --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-balance-transfers.md @@ -0,0 +1,57 @@ +--- +id: learn-balance-transfers +title: Balance Transfers +sidebar_label: How to transfer Balances +--- + +Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. + +## Polkadot-JS Apps + +> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. + +Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: + +1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). +2. Clicking the "send" button while in the "Accounts" page. + +### Using the Transfer Tab + +Click on the "Transfer" tab in the "Accounts" dropdown. + +![transfer](assets/transfer-1.png) + +Now a modal window will appear on the page. The modal asks you to enter 3 inputs: + +- "send from account": Your account with funds that you will send from. +- "send to address": The address of the account that will receive the funds. +- "amount": The amount of tokens you will transfer. + +The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. + +![transfer](assets/transfer-2.png) + +After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. + +### Keep-Alive Checks + +At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. + +By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. + +Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. + +Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. + +### From the Accounts Page + +Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. + +You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. + +![transfer](assets/transfer-3.png) + +Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. + +[polkadot-js apps]: https://polkadot.js.org/apps +[existential deposit]: build-protocol-info#existential-deposit diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-bridges.md b/polkadot-wiki/translated_docs/zh-TW/learn-bridges.md new file mode 100644 index 000000000000..304c4b80b21c --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-bridges.md @@ -0,0 +1,84 @@ +--- +id: learn-bridges +title: Bridges +sidebar_label: Bridges +--- + +A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. + +While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. + +> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. + +## Bridging Methods + +Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). +- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). +- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. + +### via Bridge Pallets + +Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. + +An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. + +For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). + +### via Smart Contracts + +Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). + +Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. + +> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) + +### via Higher-Order Protocols + +Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. + +An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. + +## Examples + +### Ethereum Bridge (Smart Contracts <> Polkadot) + +As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. + +1. Polkadot <-> Ethereum Public Bridge. +1. Substrate <-> Parity Ethereum (Openethereum) Bridge. +1. The Substrate EVM module. + +Please read the blog article for fuller descriptions of each one of these options. + +### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) + +The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. + +The Bitcoin bridge as documented in the specification is composed of two logically different components: + +- The XCLAIM component that maintains all accounts that own PolkaBTC. +- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. + +For full details on how it works please refer to the specification. + +## Additional Resources and Examples + +### For Bridge Builders + +If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. + +### Resources and Examples + +- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) +- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. +- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) +- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. +- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. +- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. +- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. +- [POA Network](https://poa.network/) +- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. +- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. +- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/zh-TW/learn-collator.md b/polkadot-wiki/translated_docs/zh-TW/learn-collator.md similarity index 100% rename from website/translated_docs/zh-TW/learn-collator.md rename to polkadot-wiki/translated_docs/zh-TW/learn-collator.md diff --git a/website/translated_docs/zh-TW/learn-comparison-dfinity.md b/polkadot-wiki/translated_docs/zh-TW/learn-comparison-dfinity.md similarity index 100% rename from website/translated_docs/zh-TW/learn-comparison-dfinity.md rename to polkadot-wiki/translated_docs/zh-TW/learn-comparison-dfinity.md diff --git a/website/translated_docs/zh-TW/learn-comparison-ethereum-2.md b/polkadot-wiki/translated_docs/zh-TW/learn-comparison-ethereum-2.md similarity index 100% rename from website/translated_docs/zh-TW/learn-comparison-ethereum-2.md rename to polkadot-wiki/translated_docs/zh-TW/learn-comparison-ethereum-2.md diff --git a/website/translated_docs/zh-TW/learn-comparisons-cosmos.md b/polkadot-wiki/translated_docs/zh-TW/learn-comparisons-cosmos.md similarity index 100% rename from website/translated_docs/zh-TW/learn-comparisons-cosmos.md rename to polkadot-wiki/translated_docs/zh-TW/learn-comparisons-cosmos.md diff --git a/website/translated_docs/zh-TW/learn-comparisons.md b/polkadot-wiki/translated_docs/zh-TW/learn-comparisons.md similarity index 100% rename from website/translated_docs/zh-TW/learn-comparisons.md rename to polkadot-wiki/translated_docs/zh-TW/learn-comparisons.md diff --git a/website/translated_docs/zh-TW/learn-consensus.md b/polkadot-wiki/translated_docs/zh-TW/learn-consensus.md similarity index 100% rename from website/translated_docs/zh-TW/learn-consensus.md rename to polkadot-wiki/translated_docs/zh-TW/learn-consensus.md diff --git a/website/translated_docs/zh-TW/learn-crosschain.md b/polkadot-wiki/translated_docs/zh-TW/learn-crosschain.md similarity index 100% rename from website/translated_docs/zh-TW/learn-crosschain.md rename to polkadot-wiki/translated_docs/zh-TW/learn-crosschain.md diff --git a/website/translated_docs/zh-TW/learn-crowdloans.md b/polkadot-wiki/translated_docs/zh-TW/learn-crowdloans.md similarity index 100% rename from website/translated_docs/zh-TW/learn-crowdloans.md rename to polkadot-wiki/translated_docs/zh-TW/learn-crowdloans.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-cryptography.md b/polkadot-wiki/translated_docs/zh-TW/learn-cryptography.md new file mode 100644 index 000000000000..15864ca1876f --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-cryptography.md @@ -0,0 +1,22 @@ +--- +id: learn-cryptography +title: Cryptography Explainer +sidebar_label: Cryptography Explainer +description: An overview of the cryptographic functions used in Polkadot +--- + +This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. + +For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). + +## Hashing Algorithm + +The hashing algorithm used in Polkadot is [Blake2b](). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). + +## Keypairs and Signing + +Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. + +Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). + +The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/zh-TW/learn-faq.md b/polkadot-wiki/translated_docs/zh-TW/learn-faq.md similarity index 100% rename from website/translated_docs/zh-TW/learn-faq.md rename to polkadot-wiki/translated_docs/zh-TW/learn-faq.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-governance.md b/polkadot-wiki/translated_docs/zh-TW/learn-governance.md new file mode 100644 index 000000000000..d1a2f97c5df3 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-governance.md @@ -0,0 +1,290 @@ +--- +id: learn-governance +title: Governance +sidebar_label: Governance +--- + +Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. + +To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. + +## Mechanism + +In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. + +To better understand how the council is formed, please read [this section](#council). + +## Referenda + +Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. + +Referenda can be started in one of several ways: + +- Publicly submitted proposals; +- Proposals submitted by the council, either through a majority or unanimously; +- Proposals submitted as part of the enactment of a prior referendum; +- Emergency proposals submitted by the Technical Committee and approved by the Council. + +All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. + +Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. + +### Proposing a Referendum + +#### Public Referenda + +Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). + +There can be a maximum of 100 public proposals in the proposal queue. + +#### Council Referenda + +Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). + +Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). + +There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. + +#### Voting Timetable + +Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. + +The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. + +Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. + +#### Voting on a referendum + +To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. + +It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). + +> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). + +``` +Example: + +Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes + +Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes + +Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes +``` + +Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. + +#### Tallying + +Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. + +| **Entity** | **Metric** | +| :--------------------------: | :--------------------------------------------: | +| Public | Positive Turnout Bias (Super-Majority Approve) | +| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | +| Council (Majority agreement) | Simple Majority | + +Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. + +``` +approve - the number of aye votes + +against - the number of nay votes + +turnout - the total number of voting tokens (does not include conviction) + +electorate - the total number of DOT tokens issued in the network +``` + +##### Super-Majority Approve + +A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) + +##### Super-Majority Against + +A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. + +![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) + +##### Simple-Majority + +Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. + +![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) + +_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. + +``` +Example: + +Assume: +- We only have 1,500 DOT tokens in total. +- Public proposal + +John - 500 DOT +Peter - 100 DOT +Lilly - 150 DOT +JJ - 150 DOT +Ken - 600 DOT + +John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes + +Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes + +JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes + +approve = 600 +against = 450 +turnout = 750 +electorate = 1500 +``` + +![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) + +![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) + +Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. + +#### Voluntary Locking + +Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: + +``` +votes = tokens * conviction_multiplier +``` + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | +| :----------: | :-------------: | +| 0 | 0.1 | +| 1 | 1 | +| 2 | 2 | +| 4 | 3 | +| 8 | 4 | +| 16 | 5 | +| 32 | 6 | + +The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. + +While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. + +Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. + +#### Adaptive Quorum Biasing + +Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. + +![](assets/governance/adaptive-quorum-biasing.png) + +Let's use the above image as an example. + +If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. + +In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. + +When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. + +Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. + +In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. + +All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. + +## Council + +> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) + +To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. + +Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. + +For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. + +### Canceling + +A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. + +Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. + +If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. + +### Blacklisting + +A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. + +Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. + +### How to be a council member? + +![](assets/governance/approval-vote.png) + +All stakeholders are free to signal their approval of any of the registered candidates. + +Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. + +At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. + +As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. + +Let's take a look at the example below. + +| Round 1 | | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | | +| | A | B | C | D | E | +| Peter | X | | X | X | X | +| Alice | | X | | | | +| Bob | | | X | X | X | +| Kelvin | X | | X | | | +| **Total** | 2 | 1 | 3 | 2 | 2 | + +The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. + +| Round 2 | | | | | +| :---------------: | :-: | :------------: | :-: | :-: | +| **Token Holders** | | **Candidates** | | | +| | A | B | D | E | +| Peter | X | X | | | +| Alice | X | X | | | +| Bob | X | X | X | X | +| Kelvin | X | X | | | +| **Total** | 4 | 4 | 1 | 1 | + +For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. + +This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. + +### Prime Members + +The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. + +The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). + +The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. + +## Technical Committee + +The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). + +The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. + +Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. + +## Frequently Asked Questions + +### How can I appeal to the council to enact a change on my behalf? + +In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. + +The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. + +At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. + +## Resources + +- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) +- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) +- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) +- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/zh-TW/learn-identity.md b/polkadot-wiki/translated_docs/zh-TW/learn-identity.md similarity index 100% rename from website/translated_docs/zh-TW/learn-identity.md rename to polkadot-wiki/translated_docs/zh-TW/learn-identity.md diff --git a/website/translated_docs/zh-TW/learn-implementations.md b/polkadot-wiki/translated_docs/zh-TW/learn-implementations.md similarity index 100% rename from website/translated_docs/zh-TW/learn-implementations.md rename to polkadot-wiki/translated_docs/zh-TW/learn-implementations.md diff --git a/website/translated_docs/zh-TW/learn-implementers-guide.md b/polkadot-wiki/translated_docs/zh-TW/learn-implementers-guide.md similarity index 100% rename from website/translated_docs/zh-TW/learn-implementers-guide.md rename to polkadot-wiki/translated_docs/zh-TW/learn-implementers-guide.md diff --git a/website/translated_docs/zh-TW/learn-introduction.md b/polkadot-wiki/translated_docs/zh-TW/learn-introduction.md similarity index 100% rename from website/translated_docs/zh-TW/learn-introduction.md rename to polkadot-wiki/translated_docs/zh-TW/learn-introduction.md diff --git a/website/translated_docs/zh-TW/learn-keys.md b/polkadot-wiki/translated_docs/zh-TW/learn-keys.md similarity index 100% rename from website/translated_docs/zh-TW/learn-keys.md rename to polkadot-wiki/translated_docs/zh-TW/learn-keys.md diff --git a/website/translated_docs/zh-TW/learn-kusama-vs-polkadot.md b/polkadot-wiki/translated_docs/zh-TW/learn-kusama-vs-polkadot.md similarity index 100% rename from website/translated_docs/zh-TW/learn-kusama-vs-polkadot.md rename to polkadot-wiki/translated_docs/zh-TW/learn-kusama-vs-polkadot.md diff --git a/website/translated_docs/zh-TW/learn-launch.md b/polkadot-wiki/translated_docs/zh-TW/learn-launch.md similarity index 100% rename from website/translated_docs/zh-TW/learn-launch.md rename to polkadot-wiki/translated_docs/zh-TW/learn-launch.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-ledger.md b/polkadot-wiki/translated_docs/zh-TW/learn-ledger.md new file mode 100644 index 000000000000..f460b39be63e --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-ledger.md @@ -0,0 +1,163 @@ +--- +id: learn-ledger +title: Using the Polkadot Ledger Application +sidebar_label: Ledger Application +--- + +> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. + +The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. + +The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). + +If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). + +> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). + +## Requirements + +Here is a list of what you will need before starting: + +- A Ledger Nano S or a Ledger Nano X. +- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). +- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). +- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. + +## Installing the Ledger Application + +### Using Ledger Live + +- Open the "Manager" tab in Ledger Live. +- Connect and unlock your Ledger device. +- If asked, allow the manager on your device by pressing both buttons on the YES screen. +- Find Polkadot in the app catalog and install it. + +![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) + +Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. + +### Using the Developer Release + +> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. + +Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. + +On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. + +Using `install_app.sh` `help` command will show you the available options: + +```zsh +$ ./install_app.sh --help +Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] + load - Load Polkadot app + delete - Delete Polkadot app + version - Show Polkadot app version +``` + +Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. + +First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. + +After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. + +At the end of the process you should have the newly installed Polkadot application on the device. + +## Using on Polkadot-JS Apps + +> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. + +### Loading Your Account + +[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. + +In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. + +![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) + +Click "Save" to keep your settings. + +Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. + +![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) + +A popup will appear asking you to select an account and derivation path. + +![Picking an account and derivation path](assets/ledger/add-account.png) + +The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. + +Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: + +![Display the device connection popup](assets/ledger/query-device.png) + +Click on the "Unknown device" line and the "Connect" button will become available. + +You should now be able to scroll down and find a new account on the page with the type "ledger". + +![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) + +You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. + +### Confirming the Address on your Device + +On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. + +![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) + +Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. + +### Checking the Balance of Your Account + +There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. + +#### Using Polkadot-JS Apps + +Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. + +![Account row showing empty balance](assets/ledger/ledger-balance.png) + +### Sending a Transfer + +Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). + +### Receiving a Transfer + +In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. + +The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. + +> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. + +### Staking + +Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. + +- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. +- Click the "Account Actions" pane in the inner navigation. +- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). +- Input the amount of tokens to bond and confirm the transaction. +- Confirm the transaction on the Ledger device. +- When the transaction is included you will see the newly bonded account in the "Account Actions" page. +- Select "Start Nominating" or "Start Validating" to start nominating or validating. +- Confirm the transaction on Apps and on the Ledger device. + +### Removing Expired Democracy Locks + +Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. + +- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. +- Go to https://polkadot.js.org/apps/#/extrinsics +- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. +- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. +- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. + +## Support + +If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). + +[ledger]: https://www.ledger.com/ +[polkadot-js apps]: https://polkadot.js.org/apps +[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install +[releases page]: https://github.com/Zondax/ledger-polkadot/releases +[polkascan]: https://polkascan.io/polkadot +[subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/zh-TW/learn-nominator.md b/polkadot-wiki/translated_docs/zh-TW/learn-nominator.md similarity index 100% rename from website/translated_docs/zh-TW/learn-nominator.md rename to polkadot-wiki/translated_docs/zh-TW/learn-nominator.md diff --git a/website/translated_docs/zh-TW/learn-parachains.md b/polkadot-wiki/translated_docs/zh-TW/learn-parachains.md similarity index 100% rename from website/translated_docs/zh-TW/learn-parachains.md rename to polkadot-wiki/translated_docs/zh-TW/learn-parachains.md diff --git a/website/translated_docs/zh-TW/learn-parathreads.md b/polkadot-wiki/translated_docs/zh-TW/learn-parathreads.md similarity index 100% rename from website/translated_docs/zh-TW/learn-parathreads.md rename to polkadot-wiki/translated_docs/zh-TW/learn-parathreads.md diff --git a/website/translated_docs/zh-TW/learn-phragmen.md b/polkadot-wiki/translated_docs/zh-TW/learn-phragmen.md similarity index 100% rename from website/translated_docs/zh-TW/learn-phragmen.md rename to polkadot-wiki/translated_docs/zh-TW/learn-phragmen.md diff --git a/website/translated_docs/zh-TW/learn-polkadot-host.md b/polkadot-wiki/translated_docs/zh-TW/learn-polkadot-host.md similarity index 100% rename from website/translated_docs/zh-TW/learn-polkadot-host.md rename to polkadot-wiki/translated_docs/zh-TW/learn-polkadot-host.md diff --git a/website/translated_docs/zh-TW/learn-proxies.md b/polkadot-wiki/translated_docs/zh-TW/learn-proxies.md similarity index 100% rename from website/translated_docs/zh-TW/learn-proxies.md rename to polkadot-wiki/translated_docs/zh-TW/learn-proxies.md diff --git a/website/translated_docs/zh-TW/learn-randomness.md b/polkadot-wiki/translated_docs/zh-TW/learn-randomness.md similarity index 100% rename from website/translated_docs/zh-TW/learn-randomness.md rename to polkadot-wiki/translated_docs/zh-TW/learn-randomness.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-registrar.md b/polkadot-wiki/translated_docs/zh-TW/learn-registrar.md new file mode 100644 index 000000000000..74255eb15ca2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-registrar.md @@ -0,0 +1,116 @@ +--- +id: learn-registrar +title: Using W3F Registrar +sidebar_label: How to use W3F Registrar +--- + +An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. + +> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! + +If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. + +Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. + +## Setting an On-chain Identity + +> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. + +Go to [Accounts](<(https://polkadot.js.org/apps/#/accounts)>) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". + +![registrar](assets/registrar/1.jpg) + +A popup will appear, offering the default fields. + +Currently, the registrar only supports the following fields: + +- Display Name. +- Element (formerly known as Riot) +- Email +- Twitter + +![registrar](assets/registrar/2.jpg) + +Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. + +![registrar](assets/registrar/3.jpg) + +Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. + +## Request Judgement + +![registrar](assets/registrar/4.jpg) + +Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. + +The `reg_index` is the position of the registrar. For W3F, use 0. + +The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. + +Note that in the future, a fee may be charged for the Polkadot registrar. + +## Element Verification + +Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". + +> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. + +![registrar](assets/registrar/5.jpg) + +Once you accept the invitation, you should see the following information. + +![registrar](assets/registrar/6.jpg) + +Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". + +![registrar](assets/registrar/7.jpg) + +Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. + +![registrar](assets/registrar/8.jpg) + +If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. + +## Email Verification + +Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. + +> Note: Please double-check the sender is "registrar@web3.foundation", not the others. + +![registrar](assets/registrar/9.jpg) + +You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" + +![registrar](assets/registrar/10.jpg) + +And reply with your signed data only in the email. Then click "Send". + +> Note: Do not add anything in the email except the signed data. + +![registrar](assets/registrar/11.jpg) + +Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. + +## Twitter Verification + +Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. + +After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. + +![registrar](assets/registrar/12.jpg) + +After waiting a few mintues you should receive a challenge similar to the previous two. + +![registrar](assets/registrar/13.jpg) + +Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. + +![registrar](assets/registrar/14.jpg) + +Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. + +If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. + +![registrar](assets/registrar/15.jpg) + +Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/zh-TW/learn-relevant-links.md b/polkadot-wiki/translated_docs/zh-TW/learn-relevant-links.md similarity index 100% rename from website/translated_docs/zh-TW/learn-relevant-links.md rename to polkadot-wiki/translated_docs/zh-TW/learn-relevant-links.md diff --git a/website/translated_docs/zh-TW/learn-roadmap.md b/polkadot-wiki/translated_docs/zh-TW/learn-roadmap.md similarity index 100% rename from website/translated_docs/zh-TW/learn-roadmap.md rename to polkadot-wiki/translated_docs/zh-TW/learn-roadmap.md diff --git a/website/translated_docs/zh-TW/learn-scams.md b/polkadot-wiki/translated_docs/zh-TW/learn-scams.md similarity index 100% rename from website/translated_docs/zh-TW/learn-scams.md rename to polkadot-wiki/translated_docs/zh-TW/learn-scams.md diff --git a/website/translated_docs/zh-TW/learn-security.md b/polkadot-wiki/translated_docs/zh-TW/learn-security.md similarity index 100% rename from website/translated_docs/zh-TW/learn-security.md rename to polkadot-wiki/translated_docs/zh-TW/learn-security.md diff --git a/website/translated_docs/zh-TW/learn-simple-payouts.md b/polkadot-wiki/translated_docs/zh-TW/learn-simple-payouts.md similarity index 100% rename from website/translated_docs/zh-TW/learn-simple-payouts.md rename to polkadot-wiki/translated_docs/zh-TW/learn-simple-payouts.md diff --git a/website/translated_docs/zh-TW/learn-spree.md b/polkadot-wiki/translated_docs/zh-TW/learn-spree.md similarity index 100% rename from website/translated_docs/zh-TW/learn-spree.md rename to polkadot-wiki/translated_docs/zh-TW/learn-spree.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-staking.md b/polkadot-wiki/translated_docs/zh-TW/learn-staking.md new file mode 100644 index 000000000000..af949268edac --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-staking.md @@ -0,0 +1,260 @@ +--- +id: learn-staking +title: Staking +sidebar_label: Staking +--- + +Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. + +The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. + +Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. + +The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. + +Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. + +## How does staking work in Polkadot? + +### 1. Identifying which role you are + +In staking, you can be either a [nominator or a validator](#validators-and-nominators). + +As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. + +A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. + +### 2. Nomination period + +Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. + +Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). + +### 3. Staking Rewards Distribution + +To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. + +The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. + +To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. + +### 4. Rewards Mechanism + +We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). + +The following example should clarify the above. For simplicity, we have the following assumptions: + +- These validators do not have a stake of their own. +- They each receive the same number of era points. +- There are no tips for any transactions processed. +- They do NOT charge any commission fees. +- Total reward amount is 100 DOT tokens. +- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). + +| | **A - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | +| Jin | 100 | 0.167 | 16.7 | +| **Sam** | 50 | 0.083 | 8.3 | +| Anson | 250 | 0.417 | 41.7 | +| Bobby | 200 | 0.333 | 33.3 | + +| | **B - Validator Pool** | | | +| :-----------: | :--------------------: | :-------------------------: | :-----: | +| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | +| Alice | 100 | 0.25 | 25 | +| Peter | 100 | 0.25 | 25 | +| John | 150 | 0.375 | 37.5 | +| **Kitty** | 50 | 0.125 | 12.5 | + +_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ + +Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. + +There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than +{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top +{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. + +We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. + +The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). + +## Accounts + +There are two different accounts for managing your funds: `Stash` and `Controller`. + +![staking](assets/NPoS/staking-keys_stash_controller.png) + +- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. +- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. + +We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. + +Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). + +## Validators and nominators + +Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. + +![staking](assets/NPoS/article-2.png) + +> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. + +### Want to stake DOT? + +- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. +- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. + +## Slashing + +Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. + +Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. + +It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. + +As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. + +In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). + +Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. + +The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): + +- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). +- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. +- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. +- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. + +Let's look at these offences in a bit more detail. + +### Unresponsiveness + +For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. + +Here is the formula for calculation: + + Let x = offenders, n = total no. validators + + min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 + +Note that if less than 10% of all validators are offline, no penalty is enacted. + +Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). +A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). + +### GRANDPA Equivocation + +A validator signs two or more votes in the same round on different chains. + +### BABE Equivocation + +A validator produces two or more blocks on the Relay Chain in the same time slot. + +GRANDPA and BABE equivocation slashing penalty is calculated as below: + + Let x = offenders, n = total no. validators + + Min( (3 * x / n )^2, 1) + +Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. + +If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. + +If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). + +### Chilling + +Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. + +This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. + +When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. + +Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. + +For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. + +### Slashing Across Eras + +There are 3 main difficulties to account for with slashing in NPoS: + +- A nominator can nominate multiple validators and be slashed via any of them. +- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. +- Slashable offences can be found after the fact and out of order. + +To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. + +## Reward Distribution + +Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. + +Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. + +Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. + +In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). + +> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. + +### Claiming Rewards + +If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. + +If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. + +### Reward Distribution Example + +``` + PER_ERA * BLOCK_TIME = **Reward Distribution Time** + + 3600 * 6 seconds = 21,600 s = 6 hours + + ***These parameters can be changed by proposing a referendum*** +``` + +Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. + +For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. + +Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. + +For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). + +## Inflation + +DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. + +![staking](assets/NPoS/staking-participation-rate.png) + +

    Source: Research - Web3 Foundation

    + +- **x-axis**: Proportion of DOT staked +- **y-axis**: Inflation, annualized percentage +- **Blue line**: Inflation rewards to stakers +- **Green line**: Staker rate of return + +You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. + +For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). + +## Why stake? + +- 10% inflation/year when the network launches +- 50% targeted active staking +- ~20% annual return + +## Why not stake? + +- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. +- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). +- You want to use the tokens for a parachain slot. + +## How many validators does Polkadot have? + +Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. + +## Resources + +- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. +- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/zh-TW/learn-transaction-fees.md b/polkadot-wiki/translated_docs/zh-TW/learn-transaction-fees.md similarity index 100% rename from website/translated_docs/zh-TW/learn-transaction-fees.md rename to polkadot-wiki/translated_docs/zh-TW/learn-transaction-fees.md diff --git a/website/translated_docs/zh-TW/learn-transactions.md b/polkadot-wiki/translated_docs/zh-TW/learn-transactions.md similarity index 100% rename from website/translated_docs/zh-TW/learn-transactions.md rename to polkadot-wiki/translated_docs/zh-TW/learn-transactions.md diff --git a/polkadot-wiki/translated_docs/zh-TW/learn-treasury.md b/polkadot-wiki/translated_docs/zh-TW/learn-treasury.md new file mode 100644 index 000000000000..dc39848c72ab --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/learn-treasury.md @@ -0,0 +1,169 @@ +--- +id: learn-treasury +title: Treasury +sidebar_label: Treasury +description: Details about Polkadot's on-chain treasury. +--- + +The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to +{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. + +If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. +{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} + +When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. + +Proposals may consist of (but are not limited to): + +- Infrastructure deployment and continued operation. +- Network security operations (monitoring services, continuous auditing). +- Ecosystem provisions (collaborations with friendly chains). +- Marketing activities (advertising, paid features, collaborations). +- Community events and outreach (meetups, pizza parties, hackerspaces). +- Software development (wallets and wallet integration, clients and client upgrades). + +The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. + +## Funding the Treasury + +The Treasury is funded from different sources: + +1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. +2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. +3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. +4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. + +## Creating a Treasury Proposal + +The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. + +Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. + +### Announcing the Proposal + +To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: + +- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. +- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. +- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} + {{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. +- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. + +Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} +{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. + +### Creating the Proposal + +One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: + +![A proposal being created](assets/treasury/submit-new.png) + +The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). + +Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. + +![Pending proposals](assets/treasury/proposals.png) + +Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. + +At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. + +The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. + +![Motions in action](assets/treasury/motion.png) + +## Tipping + +Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. + +Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. + +A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. + +There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of +{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. + +To better understand the process a tip goes through until it is paid out, let's consider an example. + +### Example + +Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. + +Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on +{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} +{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. + +As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. + +For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. + +Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. + +Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. + +Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips +{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. + +The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. + +Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out +{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. + +In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. + +## Bounties Spending + +There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. + +Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. + +A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. + +When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. + +In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. + +After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. + +To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. + +The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. + +### Creating a Bounty Proposal + +Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. + +To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. + +After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the +{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} +{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our +{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} +{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. + +A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. + +### Closing a bounty + +The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. + +A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. + +To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). + +## FAQ + +### What prevents the Treasury from being captured by a majority of the Council? + +The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. + +For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. + +However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. + +Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. + +## Further Reading + +- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/zh-TW/learn-validator.md b/polkadot-wiki/translated_docs/zh-TW/learn-validator.md similarity index 100% rename from website/translated_docs/zh-TW/learn-validator.md rename to polkadot-wiki/translated_docs/zh-TW/learn-validator.md diff --git a/website/translated_docs/zh-TW/learn-wasm.md b/polkadot-wiki/translated_docs/zh-TW/learn-wasm.md similarity index 100% rename from website/translated_docs/zh-TW/learn-wasm.md rename to polkadot-wiki/translated_docs/zh-TW/learn-wasm.md diff --git a/website/translated_docs/zh-TW/maintain-collator.md b/polkadot-wiki/translated_docs/zh-TW/maintain-collator.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-collator.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-collator.md diff --git a/website/translated_docs/zh-TW/maintain-errors.md b/polkadot-wiki/translated_docs/zh-TW/maintain-errors.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-errors.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-errors.md diff --git a/website/translated_docs/zh-TW/maintain-guides-democracy.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-democracy.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-democracy.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-democracy.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-chill.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-chill.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-chill.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-chill.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-join-council.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-join-council.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-join-council.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-join-council.md diff --git a/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-monitor-your-node.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-monitor-your-node.md new file mode 100644 index 000000000000..f4726fba17f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-monitor-your-node.md @@ -0,0 +1,453 @@ +--- +id: maintain-guides-how-to-monitor-your-node +title: Monitor your node +sidebar_label: Monitor your node +--- + +This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. + +A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. + +## Preparation + +First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. + +```bash +sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus +``` + +Create the directories required to store the configuration and executable files. + +```bash +sudo mkdir /etc/prometheus +sudo mkdir /var/lib/prometheus +``` + +Change the ownership of these directories to `prometheus` so that only prometheus can access them. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus +sudo chown -R prometheus:prometheus /var/lib/prometheus +``` + +## Installing and Configuring Prometheus + +After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. + +```bash +sudo apt-get update && apt-get upgrade +wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz +tar xfz prometheus-*.tar.gz +cd prometheus-2.20.1.linux-amd64 +``` + +The following two binaries are in the directory: + +- prometheus - Prometheus main binary file +- promtool + +The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: + +- consoles +- console_libraries + +Copy the executable files to the `/usr/local/bin/` directory. + +```bash +sudo cp ./prometheus /usr/local/bin/ +sudo cp ./promtool /usr/local/bin/ +``` + +Change the ownership of these files to the `prometheus` user. + +```bash +sudo chown prometheus:prometheus /usr/local/bin/prometheus +sudo chown prometheus:prometheus /usr/local/bin/promtool +``` + +Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` + +```bash +sudo cp -r ./consoles /etc/prometheus +sudo cp -r ./console_libraries /etc/prometheus +``` + +Change the ownership of these directories to the `prometheus` user. + +```bash +sudo chown -R prometheus:prometheus /etc/prometheus/consoles +sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries +``` + +Once everything is done, run this command to remove `prometheus` directory. + +```bash +cd .. && rm -rf prometheus* +``` + +Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. + +```bash +sudo nano /etc/prometheus/prometheus.yml +``` + +The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. + +- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. + +- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. + +- `scrape_configs` contains the information which resources Prometheus monitors. + +The configuration file should look like this below: + +```yaml +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + # - "first.rules" + # - "second.rules" + +scrape_configs: + - job_name: "prometheus" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9090"] + - job_name: "substrate_node" + scrape_interval: 5s + static_configs: + - targets: ["localhost:9615"] +``` + +With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. + +You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. + +Save the configuration file and change the ownership of the file to `prometheus` user. + +```bash +sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml +``` + +## Starting Prometheus + +To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. + +```bash +sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries +``` + +The following messages indicate the status of the server. If you see the following messages, your server is set up properly. + +```bash +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" +level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" +level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 +level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs +level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 +level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" +level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml +level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." +``` + +Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. + +Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. + +```bash +sudo nano /etc/systemd/system/prometheus.service +``` + +```bash +[Unit] + Description=Prometheus Monitoring + Wants=network-online.target + After=network-online.target + +[Service] + User=prometheus + Group=prometheus + Type=simple + ExecStart=/usr/local/bin/prometheus \ + --config.file /etc/prometheus/prometheus.yml \ + --storage.tsdb.path /var/lib/prometheus/ \ + --web.console.templates=/etc/prometheus/consoles \ + --web.console.libraries=/etc/prometheus/console_libraries + ExecReload=/bin/kill -HUP $MAINPID + +[Install] + WantedBy=multi-user.target +``` + +Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. + +```bash +sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus +``` + +Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. + +## Installing Grafana + +In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. + +```bash +sudo apt-get install -y adduser libfontconfig1 +wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb +sudo dpkg -i grafana_7.1.3_amd64.deb +``` + +If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. + +Now configure Grafana to auto-start on boot. + +> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. + +```bash +sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server +``` + +![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) + +In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) + +Click `Add data source` to choose where the data is coming from. + +![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) + +Select `Prometheus`. + +![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) + +The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. + +![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) + +Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. + +`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) + +Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. + +![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) + +In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. + +![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) + +## Installing and Configuring Alertmanager (Optional) + +In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. + +First, download the latest binary of AlertManager and unzip it by running the command below: + +``` +wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) +tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz +mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ +``` + +### Gmail Setup + +To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. + +You should see something like below: + +![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) + +Copy and save it somewhere else first. + +### AlertManager Configuration + +There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. + +> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing +> +> sudo chown -R prometheus:prometheus /etc/alertmanager + +``` +global: + resolve_timeout: 1m + +route: + receiver: 'gmail-notifications' + +receivers: +- name: 'gmail-notifications' + email_configs: + - to: YOUR_EMAIL + from: YOUR_EMAIL + smarthost: smtp.gmail.com:587 + auth_username: YOUR_EMAIL + auth_identity: YOUR_EMAIL + auth_password: YOUR_APP_PASSWORD + send_resolved: true +``` + +With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. + +Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. + +> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened + +``` +[Unit] +Description=AlertManager Server Service +Wants=network-online.target +After=network-online.target + +[Service] +User=root +Group=root +Type=simple +ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' + + +[Install] +WantedBy=multi-user.target +``` + +To the start the Alertmanager, run the following commands: + +``` +sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager +``` + +``` +● alertmanager.service - AlertManager Server Service + Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago + Main PID: 20592 (alertmanager) + Tasks: 70 (limit: 9830) + CGroup: /system.slice/alertmanager.service +``` + +You should see the process status is "active (running)" if you have configured properly. + +There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: + +``` +sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource +``` + +And restart Grafana once the plugin is successfully installed. + +``` +sudo service grafana-server restart +``` + +Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. + +![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) + +Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. + +![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) + +Fill in the `URL` to your server location followed by the port number used in the Alertmanager. + +Then click "Save & Test" at the bottom to test the connection. + +![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) + +To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". + +You will end up having the follwing: + +![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) + +### AlertManager Integration + +To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. + +``` +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 +``` + +That is the updated `etc/prometheus/prometheus.yml`. + +``` +global: + scrape_interval: 15s + evaluation_interval: 15s + +rule_files: + - 'rules.yml' + +alerting: + alertmanagers: + - static_configs: + - targets: + - localhost:9093 + +scrape_configs: + - job_name: 'prometheus' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9090'] + - job_name: 'substrate_node' + scrape_interval: 5s + static_configs: + - targets: ['localhost:9615'] +``` + +We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). + +``` +groups: + - name: alert_rules + rules: + - alert: InstanceDown + expr: up == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "Instance [{{ $labels.instance }}] down" + description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." +``` + +Change the ownership of this file to `prometheus` instead of `root` by running: + +``` +sudo chown prometheus:prometheus rules.yml +``` + +To check the rules defined in the "rules.yml" is syntactically correct, run the following command: + +``` +promtool check rules rules.yml +``` + +Finally, restart everthing by running: + +``` +sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager +``` + +Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. + +![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-nominate-alexander.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-nominate-alexander.md new file mode 100644 index 000000000000..c4b21ad8a5f2 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-nominate-alexander.md @@ -0,0 +1,11 @@ +--- +id: maintain-guides-how-to-nominate-alexander +title: Be a Nominator (Alexander) +sidebar_label: Be a Nominator (Alexander) +--- + +**The Alexander testnet (PoC-4) has been deprecated.** + +If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). + + diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-nominate-kusama.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-nominate-kusama.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-nominate-kusama.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-nominate-kusama.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-nominate-polkadot.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-nominate-polkadot.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-nominate-polkadot.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-nominate-polkadot.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-systemd.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-systemd.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-systemd.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-systemd.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-unbond.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-unbond.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-unbond.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-unbond.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-upgrade.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-upgrade.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-upgrade.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-upgrade.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-use-polkadot-secure-validator.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-use-polkadot-secure-validator.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-use-polkadot-secure-validator.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-use-polkadot-secure-validator.md diff --git a/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate-kusama.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate-kusama.md new file mode 100644 index 000000000000..328b28939775 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate-kusama.md @@ -0,0 +1,262 @@ +--- +id: maintain-guides-how-to-validate-kusama +title: Run a Validator (Kusama) +sidebar_label: How to run a Validator on Kusama +--- + +This guide will instruct you how to set up a validator node on the Kusama network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. + +### How Many KSM Do I Need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: + +- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. +- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. +- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. + +On most cloud service providers, these specs are usually within the $10 - $20 per month range. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> `sh rustup install nightly-2020-05-15 rustup override set nightly-2020-05-15 rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +``` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive --chain kusama +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. +> +> If you want to test out ParityDB you can add the flag `--database paritydb`. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond KSM + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. +- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. + +```sh +./target/release/polkadot --validator --name "name on telemetry" --chain kusama +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: Polkadot-JS Apps + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama +``` diff --git a/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate-polkadot.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate-polkadot.md new file mode 100644 index 000000000000..43ee6898daed --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate-polkadot.md @@ -0,0 +1,278 @@ +--- +id: maintain-guides-how-to-validate-polkadot +title: Run a Validator (Polkadot) +sidebar_label: How to run a Validator on Polkadot +--- + +> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. + +This guide will instruct you how to set up a validator node on the Polkadot network. + +## Preliminaries + +Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. + +Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. + +If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. + +### How many DOT do I need? + +You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. + +**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. + +## Initial Set-up + +### Requirements + +The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. + +The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. + +#### Standard Hardware + +For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). + +- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz +- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. +- **Memory** - 64GB. + +The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. + +### Install Rust + +Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. + +If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. + +```sh +curl https://sh.rustup.rs -sSf | sh +``` + +Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. + +```sh +rustup update +``` + +Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. + +```sh +sudo apt install make clang pkg-config libssl-dev build-essential +``` + +Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: + +```sh +brew install cmake pkg-config openssl git llvm +``` + +### Install & Configure Network Time Protocol (NTP) Client + +[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: + +_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ + +```sh +timedatectl +``` + +If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: + +```sh +sudo apt-get install ntp +``` + +ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: + +```sh +sudo ntpq -p +``` + +> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. + +### Building and Installing the `polkadot` Binary + +You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. + +You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). + +> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. + +```sh +git clone https://github.com/paritytech/polkadot.git +cd polkadot +git tag -l | sort -V | grep -v -- '-rc' +echo Get the latest version and replace VERSION (below) with it. +git checkout VERSION +./scripts/init.sh +cargo build --release +``` + +This step will take a while (generally 10 - 40 minutes, depending on your hardware). + +> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: +> +> ```sh +> rustup install nightly-2020-10-06 +> rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 +> cargo +nightly-2020-10-06 build --release +> ``` + +```` + +If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. + +```sh +cargo install --force --git https://github.com/paritytech/substrate subkey +```` + +### Synchronize Chain Data + +> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. +> +> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. + +You can begin syncing your node by running the following command: + +```sh +./target/release/polkadot --pruning=archive +``` + +if you do not want to start in validator mode right away. + +The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. + +> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. +> +> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. + +Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. + +If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). + +## Bond DOT + +It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. + +Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. + +It is now time to set up our validator. We will do the following: + +- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. +- Select the Controller. This is the account that will decide when to start or stop validating. + +First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. + +![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) + +- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. +- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. +- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. +- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. + +Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. + +After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. + +## Set Session Keys + +> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. + +Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. + +```sh +./target/release/polkadot --validator --name "name on telemetry" +``` + +You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. + +### Generating the Session Keys + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. + +#### Option 1: PolkadotJS-APPS + +You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. + +Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. + +![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) + +#### Option 2: CLI + +If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): + +```sh +curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 +``` + +The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. + +You can restart your node at this point. + +### Submitting the `setKeys` Transaction + +You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. + +Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". + +![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) + +Submit this extrinsic and you are now ready to start validating. + +## Validate + +To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! + +If everything looks good, go ahead and click on "Validate" in Polkadot UI. + +![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) + +- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. + +Click "Validate". + +If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. + +![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) + +The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. + +**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). + +## Thousand Validators Programme + +The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). + +## FAQ + +### Why am I unable to synchronize the chain with 0 peers? + +![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) + +Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. + +### How do I clear all my chain data? + +```sh +./target/release/polkadot purge-chain +``` + +## VPS List + +- [OVH](https://www.ovh.com.au/) +- [Digital Ocean](https://www.digitalocean.com/) +- [Vultr](https://www.vultr.com/) +- [Linode](https://www.linode.com/) +- [Contabo](https://contabo.com/) +- [Scaleway](https://www.scaleway.com/) + +## Using Docker + +If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: + +```sh +$ docker run parity/polkadot:latest --validator --name "name on telemetry" +``` diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-validate.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-validate.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-validate.md diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-vote-councillor.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-vote-councillor.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-how-to-vote-councillor.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-how-to-vote-councillor.md diff --git a/website/translated_docs/zh-TW/maintain-guides-secure-validator.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-secure-validator.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-secure-validator.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-secure-validator.md diff --git a/polkadot-wiki/translated_docs/zh-TW/maintain-guides-society-kusama.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-society-kusama.md new file mode 100644 index 000000000000..bb0212ae5f50 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-society-kusama.md @@ -0,0 +1,121 @@ +--- +id: maintain-guides-society-kusama +title: Join Kappa Sigma Mu +sidebar_label: Join Kappa Sigma Mu +--- + +Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. + +![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) + +Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. + +## UI Overview + +- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. +- `Rotation`: The time period for membership rotations. +- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. +- `Pot`: Resource balance that is used to support members of the society. +- `Bids`: A list of users who submitted a bid to join the society. + +## User Types + +Below are the various types of users at different stages. + +- `Bidder` - A token holder who intends to join the society by placing a bid. +- `Candidate` - The selected bidders that will be voted on by members of the society. +- `Suspended Candidate` - The candidates that failed to join the society. +- `Member` - Member of the society. +- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. +- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. +- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). + +## Procedure + +Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. + +### 1. Bid Phase + +To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). + +Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. + +Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. + +![Society Dashboard](assets/society/test_bid.jpg) + +Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. + +You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. + +> vouch(who,value,tip) +> +> who - The user you are vouching for +> +> value - The value that the user would like to get when joining the society +> +> tip - Fees you get +> +> Note: The final value that the candidate will get = (value - tip) + +![Society Dashboard](assets/society/vouch.jpg) + +### 2. Candidate Phase + +Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: + +> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. + +A - Accept, R - Reject, S - Skeptic + +| Member | 1 | 2 | 3 | 4 | 5 | +| -------- | --- | --- | --- | --- | --- | +| Vote | A | A | A | R | S | +| Selected | | | X | | | + +In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. + +Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. + +> Note: The maximum number of strikes you can have is on Kusama is 10. + +The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. + +#### Lock-up Time + +It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. + +Example: + +``` +Let's assume we have 5 members in the society. + +lock_duration = 100 - 50,000 / (5 + 500) +lock_duration * MAX_LOCK_DURATION_IN_BLOCKS + +Result = 1% * 15,552,000 ~ 11 days +``` + +Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. + +If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. + +If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. + +### 3. Member Phase + +Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. + +Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. + +![Society Payout](assets/society/payout.jpg) + +Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. + +> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. + +If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. + +## Useful links + +[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/zh-TW/maintain-guides-validator-payout.md b/polkadot-wiki/translated_docs/zh-TW/maintain-guides-validator-payout.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-guides-validator-payout.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-guides-validator-payout.md diff --git a/website/translated_docs/ur-PK/maintain-index.md b/polkadot-wiki/translated_docs/zh-TW/maintain-index.md similarity index 100% rename from website/translated_docs/ur-PK/maintain-index.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-index.md diff --git a/website/translated_docs/zh-TW/maintain-networks.md b/polkadot-wiki/translated_docs/zh-TW/maintain-networks.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-networks.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-networks.md diff --git a/website/translated_docs/zh-TW/maintain-nominator.md b/polkadot-wiki/translated_docs/zh-TW/maintain-nominator.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-nominator.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-nominator.md diff --git a/polkadot-wiki/translated_docs/zh-TW/maintain-polkadot-parameters.md b/polkadot-wiki/translated_docs/zh-TW/maintain-polkadot-parameters.md new file mode 100644 index 000000000000..7fceea6dcf8a --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/maintain-polkadot-parameters.md @@ -0,0 +1,68 @@ +--- +id: maintain-polkadot-parameters +title: Polkadot Parameters +sidebar_label: Parameters +--- + +Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). + +### Periods of common actions and attributes + +_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ + +- Slot: 6 seconds \*(generally one block per slot, although see note below) +- Epoch: 4 hours (2,400 slots x 6 seconds) +- Session: 4 hours (Session and Epoch lengths are the same) +- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) + +| Polkadot | Time | Slots\* | +| -------- | --------- | ------- | +| Slot | 6 seconds | 1 | +| Epoch | 4 hours | 2,400 | +| Session | 4 hours | 2,400 | +| Era | 24 hours | 14,400 | + +\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ + +### Governance + +| Democracy | Time | Slots | Description | +| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | +| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | +| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | + +| Council | Time | Slots | Description | +| ------------- | ------ | ------- | -------------------------------------------------------------------- | +| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | +| Voting period | 7 days | 100,800 | The council's voting period for motions. | + +The Polkadot Council consists of up to 13 members and up to 20 runners up. + +| Technical committee | Time | Slots | Description | +| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | +| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | +| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | + +### Staking, Validating, and Nominating + +| Kusama | Time | Slots | Description | +| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | +| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | +| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | +| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | + +### Treasury + +| Treasury | Time | Slots | Description | +| ---------------------- | ------- | ------- | ------------------------------------------------------------ | +| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | + +Burn percentage is currently `1.00%`. + +### Precision + +DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. + +The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/polkadot-wiki/translated_docs/zh-TW/maintain-sync.md b/polkadot-wiki/translated_docs/zh-TW/maintain-sync.md new file mode 100644 index 000000000000..1dfb2466251c --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/maintain-sync.md @@ -0,0 +1,133 @@ +--- +id: maintain-sync +title: Set up a Full Node +sidebar_label: Set up a Full Node +--- + +If you're building dapps or products on a Substrate-based chain like Polkadot, Kusama or a custom Substrate implementation, you probably want the ability to run a node-as-a-back-end. After all, it's always better to rely on your own infrastructure than on a third-party-hosted one in this brave new decentralized world. + +This guide will show you how to connect to [Kusama network](https://kusama.network), but the same process applies to any other [Substrate](https://substrate.dev/docs/en/)-based chain. First, let's clarify the term _full node_. + +### Types of Nodes + +A blockchain's growth comes from a _genesis block_, _extrinsics_, and _events_. + +When a validator seals block 1, it takes the blockchain's state at block 0. It then applies all pending changes on top of it, and emits the events that are the result of these changes. Later, the state of the chain at block 1 is used in the same way to build the state of the chain at block 2, and so on. Once two thirds of the validators agree on a specific block being valid, it is finalized. + +An **archive node** keeps all the past blocks. An archive node makes it convenient to query the past state of the chain at any point in time. Finding out what an account's balance at a certain block was, or which extrinsics resulted in a certain state change are fast operations when using an archive node. However, an archive node takes up a lot of disk space - around Kusama's 1.6 millionth block this was around 15 to 20GB. + +A **full node** is _pruned_, meaning it discards all information older than 256 blocks, but keeps the extrinsics for all past blocks, and the genesis block. A node that is pruned this way requires much less space than an archive node. In order to query past state through a full node, a user would have to wait for the node to rebuild the chain up until that block. A full node _can_ rebuild the entire chain with no additional input from other nodes and become an archive node. One caveat is that if finality stalled for some reason and the last finalized block is more than 256 blocks behind, a pruned full node will not be able to sync to the network. + +Archive nodes are used by utilities that need past information - like block explorers, council scanners, discussion platforms like [Polkassembly](https://polkassembly.io), and others. They need to be able to look at past on-chain data. Full nodes are used by everyone else - they allow you to read the current state of the chain and to submit transactions directly to the chain without relying on a centralized infrastructure provider. + +Another type of node is a **light node**. A light node has only the runtime and the current state, but does not store past extrinsics and so cannot restore the full chain from genesis. Light nodes are useful for resource restricted devices. An interesting use-case of light nodes is a Chrome extension, which is a node in its own right, running the runtime in WASM format: https://github.com/paritytech/substrate-light-ui + +### Fast Install Instructions (Mac) + +> Not recommended if you're a validator. Please see [secure validator setup](maintain-guides-secure-validator) + +- Type terminal in the ios searchbar/searchlight to open the 'terminal' application +- Install Homebrew within the terminal by running: `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"` +- Then run: `brew install openssl cmake llvm` +- Install Rust in your terminal by running: `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh` +- Once Rust is installed, run the following command to clone and build the kusama code: + ``` + git clone https://github.com/paritytech/polkadot kusama + cd kusama + ./scripts/init.sh + cargo build --release + ``` +- Run the following command to start your node: `./target/release/polkadot --name "My node's name"` +- Find your node at https://telemetry.polkadot.io/#list/Kusama + +### Fast Install Instructions (Windows) + +> This works only on Windows Pro with virtualization enabled. + +> Not recommended if you're a validator. Please see [secure validator setup](maintain-guides-secure-validator) + +- Install WSL: https://docs.microsoft.com/en-us/windows/wsl/install-win10 +- Install Ubuntu (same webpage): https://docs.microsoft.com/en-us/windows/wsl/install-win10 +- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) +- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` +- Run the following: `sudo chmod +x polkadot` +- Run the following: `./polkadot --name "Your Node Name Here"` +- Find your node at https://telemetry.polkadot.io/#list/Kusama + +### Fast Install Instructions (Linux) + +> Not recommended if you're a validator. Please see [secure validator setup](maintain-guides-secure-validator) + +For the most recent binary please see the [release page](https://github.com/paritytech/polkadot/releases/) on the polkadot repository. The URL in the code snippet below may become slightly out-of-date. + +Also please note that the nature of pre-built binaries means that they may not work on your particular architecture or Linux distribution. If you see an error like `cannot execute binary file: Exec format error` it likely means the binary is not compatible with your system. You will either need to compile the [source code yourself](#clone-and-build) or use [docker](#using-docker). + +- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) +- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` +- Run the following: `sudo chmod +x polkadot` +- Run the following: `./polkadot --name "Your Node Name Here"` +- Find your node at https://telemetry.polkadot.io/#list/Kusama + +## Get Substrate + +Follow instructions as outlined [here](https://substrate.dev/docs/en/knowledgebase/getting-started) - note that Windows users will have their work cut out for them. It's better to use a virtual machine instead. + +Test if the installation was successful by running `cargo --version`. + +```bash +λ cargo --version +cargo 1.41.0 (626f0f40e 2019-12-03) +``` + +## Clone and Build + +The [paritytech/polkadot](https://github.com/paritytech/polkadot) repo's master branch contains the latest Kusama code. + +```bash +git clone https://github.com/paritytech/polkadot kusama +cd kusama +./scripts/init.sh +cargo build --release +``` + +Alternatively, if you wish to use a specific release, you can check out a specific tag (`v0.8.3` in the example below): + +```bash +git clone https://github.com/paritytech/polkadot kusama +cd kusama +git checkout tags/v0.8.3 +./scripts/init.sh +cargo build --release +``` + +## Run + +The built binary will be in the `target/release` folder, called `polkadot`. + +```bash +./target/release/polkadot --name "My node's name" +``` + +Use the `--help` flag to find out which flags you can use when running the node. For example, if [connecting to your node remotely](maintain-wss), you'll probably want to use `--ws-external` and `--rpc-cors all`. + +The syncing process will take a while depending on your bandwidth, processing power, disk speed and RAM. On a \$10 DigitalOcean droplet, the process can complete in some 36 hours. + +Congratulations, you're now syncing with Kusama. Keep in mind that the process is identical when using any other Substrate chain. + +## Running an Archive Node + +When running as a simple sync node (above), only the state of the past 256 blocks will be kept. When validating, it defaults to [archive mode](#types-of-nodes). To keep the full state use the `--pruning` flag: + +```bash +./target/release/polkadot --name "My node's name" --pruning archive +``` + +It is possible to almost quadruple synchronization speed by using an additional flag: `--wasm-execution Compiled`. Note that this uses much more CPU and RAM, so it should be turned off after the node is in sync. + +## Using Docker + +Finally, you can use Docker to run your node in a container. Doing this is a bit more advanced so it's best left up to those that either already have familiarity with docker, or have completed the other set-up instructions in this guide. If you would like to connect to your node's WebSockets ensure that you run you node with the `--rpc-external` and `--ws-external` commands. + +```zsh +docker run -p 9944:9944 parity/polkadot:v0.8.24 --name "calling_home_from_a_docker_container" --rpc-external --ws-external +``` diff --git a/website/translated_docs/zh-TW/maintain-validator.md b/polkadot-wiki/translated_docs/zh-TW/maintain-validator.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-validator.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-validator.md diff --git a/website/translated_docs/zh-TW/maintain-wss.md b/polkadot-wiki/translated_docs/zh-TW/maintain-wss.md similarity index 100% rename from website/translated_docs/zh-TW/maintain-wss.md rename to polkadot-wiki/translated_docs/zh-TW/maintain-wss.md diff --git a/website/translated_docs/zh-TW/news.md b/polkadot-wiki/translated_docs/zh-TW/news.md similarity index 100% rename from website/translated_docs/zh-TW/news.md rename to polkadot-wiki/translated_docs/zh-TW/news.md diff --git a/polkadot-wiki/translated_docs/zh-TW/redenomination.md b/polkadot-wiki/translated_docs/zh-TW/redenomination.md new file mode 100644 index 000000000000..f8c6b99188b3 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/redenomination.md @@ -0,0 +1,94 @@ +--- +id: redenomination +title: Redenomination of DOT +sidebar_label: Redenomination of DOT +--- + +> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block +> +> # 1,248,328. + +While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". + +> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). + +The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. + +The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. + +``` + Before the change the decimal was here + v + 1.000000000000 DOT + + 100.0000000000 DOT + ^ + After the change the decimal is here +``` + +**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** + +## Origins + +The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. + +> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. +> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. +> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. +> - The precision of DOT will change from 12 decimal places to 10 decimal places. +> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. + +The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. + +Web3 Foundation summarized the decision not to change: + +> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** + +## The Vote + +After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. + +Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. + +The important notes of the Polkadot vote were as follows: + +> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! +> - Approving of all or none of the options is equivalent and will not affect the outcome. +> - All voters may alter their votes any number of times prior to the close of the poll. +> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) +> - Locked funds (e.g. for staking) are counted. +> - No discretionary lock-voting is in place; all DOT used to vote counts the same. +> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. +> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. + +With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. + +## The Outcome + +![redenomination](assets/redenomination.png) + +After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). + +Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block + +# 1,248,328. + +### What This Means for the Community + +If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. + +### What This Means for Builders of Tools + +If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. + +However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. + +Please see our [Ecosystem Redenomination Guide]() for recommendations. + +Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. +https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# + +[referendum 52]: https://kusama.polkassembly.io/referendum/52 +[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ +[blog 2]: https://polkadot.network/the-first-polkadot-vote/ +[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/zh-TW/research.md b/polkadot-wiki/translated_docs/zh-TW/research.md similarity index 100% rename from website/translated_docs/zh-TW/research.md rename to polkadot-wiki/translated_docs/zh-TW/research.md diff --git a/polkadot-wiki/translated_docs/zh-TW/thousand-validators.md b/polkadot-wiki/translated_docs/zh-TW/thousand-validators.md new file mode 100644 index 000000000000..2185e7378a73 --- /dev/null +++ b/polkadot-wiki/translated_docs/zh-TW/thousand-validators.md @@ -0,0 +1,86 @@ +--- +id: thousand-validators +title: Thousand Validators Programme +sidebar_label: Thousand Validators Programme +--- + +The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. + +It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. + +## How it Works + +The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. + +## Setting up a Validator + +Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). + +## How to Apply + +### Kusama + +In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Minimum of 50 KSM self-stake +- No more than 10% commission +- Separate controller and stash (or have a Staking proxy set up) +- Must be on latest release +- Max two nodes (under same sub/super identity) + +#### Leaderboard + +The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` +- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` +- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` +- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` +- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` +- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` +- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` +- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` + +A time delay proxy is used as the interaction method for some of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. + +### Polkadot + +> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. + +In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. + +#### Requirements + +- Verified identity (see [here]() for instructions) +- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) +- Rank 25 or higher on Kusama Thousand Validators Programme +- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) +- Reward destination 'Staked' +- No more than 3% commission +- Separate stash and controller (or have a Staking proxy set up) +- Must be on latest release + +#### Nominators + +The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". + +- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` +- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` +- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` + +A time delay proxy is used as the main interaction method for all of these accounts. + +Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. +https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity + +[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/scripts/mirror.mjs b/scripts/mirror.mjs index 4b0237aa0f7c..253d3cefb779 100644 --- a/scripts/mirror.mjs +++ b/scripts/mirror.mjs @@ -19,29 +19,121 @@ import fs from "fs"; // List of mirrored files that should be in both the Polkadot wiki and the Kusama // user guide. -const mirrored = [ - "build-build-with-polkadot", + +const mirrored_general = ["ens", "thousand-validators"]; + +const mirrored_learn = [ "learn-identity", "learn-balance-transfers", - "ens", "learn-governance", "learn-treasury", "learn-registrar", - "maintain-guides-how-to-nominate-kusama", - "maintain-guides-how-to-validate-kusama", - "maintain-guides-how-to-stop-validating", - "maintain-errors", - "thousand-validators", "learn-auction", "learn-parachains", "learn-parathreads", "learn-crowdloans", - "build-parachains-rococo", ]; -for (const file of mirrored) { - const doc = "./docs/" + file + ".md"; - const mirror = "./docs/mirror-" + file + ".md"; +const mirrored_build = ["build-build-with-polkadot", "build-parachains-rococo"]; + +const mirrored_maintain = [ + "maintain-guides-how-to-stop-validating", + "maintain-errors", +]; + +const mirrored_maintain_kusama = [ + "maintain-guides-how-to-nominate-kusama", + "maintain-guides-how-to-validate-kusama", +]; + +// Mirror general docs +for (const file of mirrored_general) { + const doc = "./docs/general/" + file + ".md"; + const mirror = "./docs/general/mirror-" + file + ".md"; + if (!fs.existsSync(doc)) { + throw new Error(`${doc} doesn't exist!`); + } + + const content = fs.readFileSync(doc, "utf8"); + const mirroredContent = content + .split("\n") + .map((line) => { + if (line.startsWith("id:")) { + const [before, after] = line.split(" "); + return before + " mirror-" + after; + } else return line; + }) + .join("\n"); + + fs.writeFileSync(mirror, mirroredContent); +} +// Mirror learn docs +for (const file of mirrored_learn) { + const doc = "./docs/learn/" + file + ".md"; + const mirror = "./docs/learn/mirror-" + file + ".md"; + if (!fs.existsSync(doc)) { + throw new Error(`${doc} doesn't exist!`); + } + + const content = fs.readFileSync(doc, "utf8"); + const mirroredContent = content + .split("\n") + .map((line) => { + if (line.startsWith("id:")) { + const [before, after] = line.split(" "); + return before + " mirror-" + after; + } else return line; + }) + .join("\n"); + + fs.writeFileSync(mirror, mirroredContent); +} +// Mirror build docs +for (const file of mirrored_build) { + const doc = "./docs/build/" + file + ".md"; + const mirror = "./docs/build/mirror-" + file + ".md"; + if (!fs.existsSync(doc)) { + throw new Error(`${doc} doesn't exist!`); + } + + const content = fs.readFileSync(doc, "utf8"); + const mirroredContent = content + .split("\n") + .map((line) => { + if (line.startsWith("id:")) { + const [before, after] = line.split(" "); + return before + " mirror-" + after; + } else return line; + }) + .join("\n"); + + fs.writeFileSync(mirror, mirroredContent); +} +// Mirror maintain docs +for (const file of mirrored_maintain) { + const doc = "./docs/maintain/" + file + ".md"; + const mirror = "./docs/maintain/mirror-" + file + ".md"; + if (!fs.existsSync(doc)) { + throw new Error(`${doc} doesn't exist!`); + } + + const content = fs.readFileSync(doc, "utf8"); + const mirroredContent = content + .split("\n") + .map((line) => { + if (line.startsWith("id:")) { + const [before, after] = line.split(" "); + return before + " mirror-" + after; + } else return line; + }) + .join("\n"); + + fs.writeFileSync(mirror, mirroredContent); +} +// Mirror kusama maintain docs +for (const file of mirrored_maintain_kusama) { + const doc = "./docs/maintain/kusama/" + file + ".md"; + const mirror = "./docs/maintain/kusama/mirror-" + file + ".md"; if (!fs.existsSync(doc)) { throw new Error(`${doc} doesn't exist!`); } diff --git a/scripts/mirror1.mjs b/scripts/mirror1.mjs deleted file mode 100644 index 96d779e57dc5..000000000000 --- a/scripts/mirror1.mjs +++ /dev/null @@ -1,88 +0,0 @@ -import fs from "fs"; - -/** - * The wiki hosts both the Polkadot Wiki and the Kusama User Guide. This means - * that we can "mirror" the same document between the two. However, due to - * a peculiarity in Docusaurus, when we put the same document into both sub-wikis - * in `website/sidebars.json` only the most recent entry is read. - * - * To solve this, we create an explicit mirror of the document. The process for - * adding content to both wikis is as follows: - * - * 1) Create the source document and put it under the relevant sidebar in the - * Polkadot wiki configuration in `sidebars.json`. - * 2) Add the source document's name to the `mirrored` array below. - * 3) Run `node mirror.js`. - * 4) Add `mirror-DOCUMENT_NAME` to the sidebar for Kusama in `sidebars.json`. - * - */ - -// List of mirrored files that should be in both the Polkadot wiki and the Kusama -// user guide. -const mirrored = [ - "build-build-with-polkadot", - "learn-identity", - "learn-balance-transfers", - "ens", - "learn-governance", - "learn-treasury", - "learn-registrar", - "maintain-guides-how-to-nominate-kusama", - "maintain-guides-how-to-validate-kusama", - "maintain-guides-how-to-stop-validating", - "maintain-errors", - "thousand-validators", - "learn-auction", - "learn-parachains", - "learn-parathreads", - "learn-crowdloans", - "build-parachains-rococo", -]; - -for (const file of mirrored) { - const doc = "./docs/" + file + ".md"; - const mirror = "./docs/mirror-" + file + ".md"; - if (!fs.existsSync(doc)) { - throw new Error(`${doc} doesn't exist!`); - } - - const content = fs.readFileSync(doc, { encoding: "utf-8" }); - const mirroredContent = content - .split("\n") - .map((line) => { - if (line.startsWith("id:")) { - const [before, after] = line.split(" "); - return before + " mirror-" + after; - } else return line; - }) - .join("\n"); - - fs.writeFileSync(mirror, mirroredContent); -} - -const langDirectories = fs.readdirSync("./website/translated_docs"); -for (const lang of langDirectories) { - for (const file of mirrored) { - const doc = `./website/translated_docs/${lang}/${file}.md`; - const mirror = `./website/translated_docs/${lang}/mirror-${file}.md`; - // console.log(mirror); - if (!fs.existsSync(doc)) { - // Disable for now, tends to fail due to unmerged crowdin - //throw new Error(`${doc} doesn't exist!`); - continue; - } - - const content = fs.readFileSync(doc, { encoding: "utf-8" }); - const mirroredContent = content - .split("\n") - .map((line) => { - if (line.startsWith("id:")) { - const [before, after] = line.split(" "); - return `${before} mirror-${after}`; - } else return line; - }) - .join("\n"); - - fs.writeFileSync(mirror, mirroredContent); - } -} diff --git a/website-v2/i18n/en/code.json b/website-v2/i18n/en/code.json deleted file mode 100644 index 9d9572976617..000000000000 --- a/website-v2/i18n/en/code.json +++ /dev/null @@ -1,342 +0,0 @@ -{ - "homePage.navContainer.build.title": { - "message": "Build", - "description": "Title of Build Navigator in Home page" - }, - "homePage.navContainer.build.content": { - "message": "Most up-to-date information on the status of the development tools in the Polkadot ecosystem.", - "description": "Content of Build Navigator in Home page" - }, - "homePage.navContainer.learn.title": { - "message": "Learn", - "description": "Title of Learn Navigator in Home page" - }, - "homePage.navContainer.learn.content": { - "message": "Polkadot is a sharded protocol that enables blockchain networks to operate together seamlessly.", - "description": "Content of Learn Navigator in Home page" - }, - "homePage.navContainer.maintain.title": { - "message": "Maintain", - "description": "Title of Maintain Navigator in Home page" - }, - "homePage.navContainer.maintain.content": { - "message": "Information and guides on how to deploy a node and run the network.", - "description": "Content of Maintain Navigator in Home page" - }, - "homepage.homeFooter.learnKusama.title": { - "message": "Learn about Polkadot’s canary network Kusama", - "description": "Title of Learn Kusama Footer Section in Home Page" - }, - "homepage.homeFooter.learnKusama.content": { - "message": "Kusama is Polkadot’s “canary network”, a scalable, multi-chain network for radical innovation and early stage Polkadot deployments. For developers, Kusama is a proving ground for all things Polkadot I.e runtime upgrades, on-chain governance, parachains, parathreads, etc.", - "description": "Content of Learn Kusama Footer Section in Home Page" - }, - "homepage.homeFooter.learnKusama.discoverKusamaButton": { - "message": "Discover Kusama", - "description": "Discover Kusama Button Label of Improve Wiki Footer Section in Home page" - }, - "homepage.homeFooter.improveWiki.title": { - "message": "Help improve this wiki", - "description": "Title of Improve Wiki Footer Section in Home page" - }, - "homepage.homeFooter.improveWiki.content": { - "message": "This wiki was started by and is maintained by Web3 Foundation. It is an open-source-ish project and aims to be the most extensive resource of knowledge on Polkadot and the Polkadot ecosystem.", - "description": "Content of Improve Wiki Footer Section in Home page" - }, - "homepage.homeFooter.improveWiki.contributeButton": { - "message": "Contribute", - "description": "Contribute Button Label of Improve Wiki Footer Section in Home page" - }, - "homepage.homeFooter.improveWiki.helpTranslateButton": { - "message": "Help Translate", - "description": "Help Translate Button Label of Improve Wiki Footer Section in Home page" - }, - "footer.subscribeMessage": { - "message": "Subscribe to the newsletter to hear about Polkadot updates and events.", - "description": "Subscribe message in Footer" - }, - "footer.subscribeButton": { - "message": "Subscribe", - "description": "Label of Subscribe button in Footer" - }, - "footer.body.general": { - "message": "General", - "description": "Headline of General column in Footer" - }, - "footer.body.general.about": { - "message": "About", - "description": "About link in General column in Footer" - }, - "footer.body.general.faq": { - "message": "FAQ", - "description": "FAQ link in General column in Footer" - }, - "footer.body.general.contact": { - "message": "Contact", - "description": "Contact link in General column in Footer" - }, - "footer.body.general.build": { - "message": "Build", - "description": "Build link in General column in Footer" - }, - "footer.body.general.grantsAndBounties": { - "message": "Grants and Bounties", - "description": "Grants and Bounties link in General column in Footer" - }, - "footer.body.general.careers": { - "message": "Careers", - "description": "Careers link in General column in Footer" - }, - "footer.body.technology": { - "message": "Technology", - "description": "Headline of Technology column in Footer" - }, - "footer.body.technology.technology": { - "message": "Technology", - "description": "Technology link in Technology column in Footer" - }, - "footer.body.technology.token": { - "message": "Token", - "description": "Token link in Technology column in Footer" - }, - "footer.body.technology.telemetry": { - "message": "Telemetry", - "description": "Telemetry link in Technology column in Footer" - }, - "footer.body.technology.substrate": { - "message": "Substrate", - "description": "Substrate link in Technology column in Footer" - }, - "footer.body.technology.whitepaper": { - "message": "Whitepaper", - "description": "Whitepaper link in Technology column in Footer" - }, - "footer.body.technology.lightpaper": { - "message": "Lightpaper", - "description": "Lightpaper link in Technology column in Footer" - }, - "footer.body.community": { - "message": "Community", - "description": "Headline of Community column in Footer" - }, - "footer.body.community.community": { - "message": "Community", - "description": "Community link in Community column in Footer" - }, - "footer.body.community.documentation": { - "message": "Documentation", - "description": "Documentation link in Community column in Footer" - }, - "footer.body.community.brandAssets": { - "message": "Brand Assets", - "description": "Brand Assets link in Community column in Footer" - }, - "footer.footerLegal.impressum": { - "message": "Impressum", - "description": "Impressum Button Label in Footer Legal" - }, - "footer.footerLegal.disclaimer": { - "message": "Disclaimer", - "description": "Disclaimer Button Label in Footer Legal" - }, - "footer.footerLegal.privacy": { - "message": "Privacy", - "description": "Privacy Button Label in Footer Legal" - }, - "footer.footerLegal.cookieSettings": { - "message": "Cookie Settings", - "description": "Cookie Settings Button Label in Footer Legal" - }, - "theme.NotFound.title": { - "message": "Page Not Found", - "description": "The title of the 404 page" - }, - "theme.NotFound.p1": { - "message": "We could not find what you were looking for.", - "description": "The first paragraph of the 404 page" - }, - "theme.NotFound.p2": { - "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", - "description": "The 2nd paragraph of the 404 page" - }, - "theme.blog.paginator.navAriaLabel": { - "message": "Blog list page navigation", - "description": "The ARIA label for the blog pagination" - }, - "theme.blog.paginator.newerEntries": { - "message": "Newer Entries", - "description": "The label used to navigate to the newer blog posts page (previous page)" - }, - "theme.blog.paginator.olderEntries": { - "message": "Older Entries", - "description": "The label used to navigate to the older blog posts page (next page)" - }, - "theme.AnnouncementBar.closeButtonAriaLabel": { - "message": "Close", - "description": "The ARIA label for close button of announcement bar" - }, - "theme.blog.post.paginator.navAriaLabel": { - "message": "Blog post page navigation", - "description": "The ARIA label for the blog posts pagination" - }, - "theme.blog.post.paginator.newerPost": { - "message": "Newer Post", - "description": "The blog post button label to navigate to the newer/previous post" - }, - "theme.blog.post.paginator.olderPost": { - "message": "Older Post", - "description": "The blog post button label to navigate to the older/next post" - }, - "theme.blog.post.readingTime.plurals": { - "message": "One min read|{readingTime} min read", - "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.tags.tagsListLabel": { - "message": "Tags:", - "description": "The label alongside a tag list" - }, - "theme.blog.post.readMore": { - "message": "Read More", - "description": "The label used in blog post item excerpts to link to full blog posts" - }, - "theme.tags.tagsPageTitle": { - "message": "Tags", - "description": "The title of the tag list page" - }, - "theme.blog.post.plurals": { - "message": "One post|{count} posts", - "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.tagTitle": { - "message": "{nPosts} tagged with \"{tagName}\"", - "description": "The title of the page for a blog tag" - }, - "theme.tags.tagsPageLink": { - "message": "View All Tags", - "description": "The label of the link targeting the tag list page" - }, - "theme.CodeBlock.copyButtonAriaLabel": { - "message": "Copy code to clipboard", - "description": "The ARIA label for copy code blocks button" - }, - "theme.CodeBlock.copied": { - "message": "Copied", - "description": "The copied button label on code blocks" - }, - "theme.CodeBlock.copy": { - "message": "Copy", - "description": "The copy button label on code blocks" - }, - "theme.docs.sidebar.expandButtonTitle": { - "message": "Expand sidebar", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.sidebar.expandButtonAriaLabel": { - "message": "Expand sidebar", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.paginator.navAriaLabel": { - "message": "Docs pages navigation", - "description": "The ARIA label for the docs pagination" - }, - "theme.docs.paginator.previous": { - "message": "Previous", - "description": "The label used to navigate to the previous doc" - }, - "theme.docs.paginator.next": { - "message": "Next", - "description": "The label used to navigate to the next doc" - }, - "theme.docs.sidebar.collapseButtonTitle": { - "message": "Collapse sidebar", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.docs.sidebar.collapseButtonAriaLabel": { - "message": "Collapse sidebar", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.docs.sidebar.responsiveCloseButtonLabel": { - "message": "Close menu", - "description": "The ARIA label for close button of mobile doc sidebar" - }, - "theme.docs.sidebar.responsiveOpenButtonLabel": { - "message": "Open menu", - "description": "The ARIA label for open button of mobile doc sidebar" - }, - "theme.docs.versions.unreleasedVersionLabel": { - "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", - "description": "The label used to tell the user that he's browsing an unreleased doc version" - }, - "theme.docs.versions.unmaintainedVersionLabel": { - "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", - "description": "The label used to tell the user that he's browsing an unmaintained doc version" - }, - "theme.docs.versions.latestVersionSuggestionLabel": { - "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", - "description": "The label userd to tell the user that he's browsing an unmaintained doc version" - }, - "theme.docs.versions.latestVersionLinkLabel": { - "message": "latest version", - "description": "The label used for the latest version suggestion link label" - }, - "theme.common.editThisPage": { - "message": "Edit this page", - "description": "The link label to edit the current page" - }, - "theme.common.headingLinkTitle": { - "message": "Direct link to heading", - "description": "Title for link to heading" - }, - "theme.lastUpdated.atDate": { - "message": " on {date}", - "description": "The words used to describe on which date a page has been last updated" - }, - "theme.lastUpdated.byUser": { - "message": " by {user}", - "description": "The words used to describe by who the page has been last updated" - }, - "theme.lastUpdated.lastUpdatedAtBy": { - "message": "Last updated{atDate}{byUser}", - "description": "The sentence used to display when a page has been last updated, and by who" - }, - "theme.common.skipToMainContent": { - "message": "Skip to main content", - "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" - }, - "theme.SearchPage.documentsFound.plurals": { - "message": "One document found|{count} documents found", - "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.SearchPage.existingResultsTitle": { - "message": "Search results for \"{query}\"", - "description": "The search page title for non-empty query" - }, - "theme.SearchPage.emptyResultsTitle": { - "message": "Search the documentation", - "description": "The search page title for empty query" - }, - "theme.SearchPage.inputPlaceholder": { - "message": "Type your search here", - "description": "The placeholder for search page input" - }, - "theme.SearchPage.inputLabel": { - "message": "Search", - "description": "The ARIA label for search page input" - }, - "theme.SearchPage.algoliaLabel": { - "message": "Search by Algolia", - "description": "The ARIA label for Algolia mention" - }, - "theme.SearchPage.noResultsText": { - "message": "No results were found", - "description": "The paragraph for empty search result" - }, - "theme.SearchPage.fetchingNewResults": { - "message": "Fetching new results...", - "description": "The paragraph for fetching new search results" - }, - "theme.SearchBar.label": { - "message": "Search", - "description": "The ARIA label and placeholder for search button" - } -} \ No newline at end of file diff --git a/website-v2/i18n/en/docusaurus-plugin-content-docs/current.json b/website-v2/i18n/en/docusaurus-plugin-content-docs/current.json deleted file mode 100644 index efecf0c8f164..000000000000 --- a/website-v2/i18n/en/docusaurus-plugin-content-docs/current.json +++ /dev/null @@ -1,74 +0,0 @@ -{ - "version.label": { - "message": "Next", - "description": "The label for version current" - }, - "sidebar.docs.category.General": { - "message": "General", - "description": "The label for category General in sidebar docs" - }, - "sidebar.docs.category.Learn": { - "message": "Learn", - "description": "The label for category Learn in sidebar docs" - }, - "sidebar.docs.category.Basics": { - "message": "Basics", - "description": "The label for category Basics in sidebar docs" - }, - "sidebar.docs.category.Parachains": { - "message": "Parachains", - "description": "The label for category Parachains in sidebar docs" - }, - "sidebar.docs.category.Advanced": { - "message": "Advanced", - "description": "The label for category Advanced in sidebar docs" - }, - "sidebar.docs.category.Cryptography": { - "message": "Cryptography", - "description": "The label for category Cryptography in sidebar docs" - }, - "sidebar.docs.category.Polkadot Comparisons": { - "message": "Polkadot Comparisons", - "description": "The label for category Polkadot Comparisons in sidebar docs" - }, - "sidebar.docs.category.Build": { - "message": "Build", - "description": "The label for category Build in sidebar docs" - }, - "sidebar.docs.category.Development Guide": { - "message": "Development Guide", - "description": "The label for category Development Guide in sidebar docs" - }, - "sidebar.docs.category.Integration Guide": { - "message": "Integration Guide", - "description": "The label for category Integration Guide in sidebar docs" - }, - "sidebar.docs.category.Tools": { - "message": "Tools", - "description": "The label for category Tools in sidebar docs" - }, - "sidebar.docs.category.Resources": { - "message": "Resources", - "description": "The label for category Resources in sidebar docs" - }, - "sidebar.docs.category.Maintain": { - "message": "Maintain", - "description": "The label for category Maintain in sidebar docs" - }, - "sidebar.docs.category.Nodes and Dapps": { - "message": "Nodes and Dapps", - "description": "The label for category Nodes and Dapps in sidebar docs" - }, - "sidebar.docs.category.Nominator Guides": { - "message": "Nominator Guides", - "description": "The label for category Nominator Guides in sidebar docs" - }, - "sidebar.docs.category.Validator Guides": { - "message": "Validator Guides", - "description": "The label for category Validator Guides in sidebar docs" - }, - "sidebar.docs.category.Governance Guides": { - "message": "Governance Guides", - "description": "The label for category Governance Guides in sidebar docs" - } -} \ No newline at end of file diff --git a/website-v2/i18n/en/docusaurus-theme-classic/footer.json b/website-v2/i18n/en/docusaurus-theme-classic/footer.json deleted file mode 100644 index 78d923d89d75..000000000000 --- a/website-v2/i18n/en/docusaurus-theme-classic/footer.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "copyright": { - "message": "© 2021 Web3 Foundation", - "description": "The footer copyright" - } -} \ No newline at end of file diff --git a/website-v2/i18n/en/docusaurus-theme-classic/navbar.json b/website-v2/i18n/en/docusaurus-theme-classic/navbar.json deleted file mode 100644 index 73986d6d162d..000000000000 --- a/website-v2/i18n/en/docusaurus-theme-classic/navbar.json +++ /dev/null @@ -1,26 +0,0 @@ -{ - "item.label.Get Started": { - "message": "Get Started", - "description": "Navbar item with label Get Started" - }, - "item.label.Learn": { - "message": "Learn", - "description": "Navbar item with label Learn" - }, - "item.label.Build": { - "message": "Build", - "description": "Navbar item with label Build" - }, - "item.label.Maintain ": { - "message": "Maintain ", - "description": "Navbar item with label Maintain " - }, - "item.label.Kusama": { - "message": "Kusama", - "description": "Navbar item with label Kusama" - }, - "item.label.Contribute": { - "message": "Contribute", - "description": "Navbar item with label Contribute" - } -} \ No newline at end of file diff --git a/website-v2/sidebars.js b/website-v2/sidebars.js deleted file mode 100644 index 2d5fd5c135b2..000000000000 --- a/website-v2/sidebars.js +++ /dev/null @@ -1,188 +0,0 @@ -module.exports = { - docs: [ - { - type: "category", - label: "General", - items: [ - "getting-started", - "claims", - "redenomination", - "grants", - "thousand-validators", - "ambassadors", - "research", - "community", - "contributing", - "contributors", - "glossary", - "ens", - "learn-ledger", - "learn-scams", - "learn-dyor", - "faq", - ], - }, - { - type: "category", - label: "Learn", - items: [ - "learn-launch", - { - type: "category", - label: "Basics", - items: [ - "learn-architecture", - "learn-accounts", - "learn-account-generation", - "learn-account-restore", - "learn-DOT", - "learn-security", - "learn-consensus", - "learn-nominator", - "learn-validator", - "learn-collator", - "learn-governance", - "learn-identity", - "learn-balance-transfers", - "learn-transaction-fees", - "learn-polkadot-host", - "learn-treasury", - "learn-registrar", - "learn-runtime-upgrades", - ], - }, - { - type: "category", - label: "Parachains", - items: [ - "learn-parachains", - "learn-parathreads", - "learn-bridges", - "learn-common-goods", - "learn-auction", - "learn-crowdloans", - "learn-teleport", - ], - }, - { - type: "category", - label: "Advanced", - items: [ - "learn-staking", - "learn-proxies", - "learn-availability", - "learn-randomness", - "learn-crosschain", - "learn-spree", - "learn-wasm", - "learn-phragmen", - "learn-simple-payouts", - ], - }, - { - type: "category", - label: "Cryptography", - items: ["learn-cryptography", "learn-keys"], - }, - { - type: "category", - label: "Polkadot Comparisons", - items: [ - "learn-kusama-vs-polkadot", - "learn-comparisons-ethereum-2", - "learn-comparisons-cosmos", - "learn-comparisons", - ], - }, - "learn-video-tutorials", - ], - }, - { - type: "category", - label: "Build", - items: [ - "build-index", - { - type: "category", - label: "Development Guide", - items: [ - "build-build-with-polkadot", - "build-pdk", - "learn-implementers-guide", - "build-cumulus", - "build-parachains-rococo", - "build-smart-contracts", - "build-oracle", - "build-ss58-registry", - "build-wallets", - ], - }, - { - type: "category", - label: "Integration Guide", - items: [ - "build-integration", - "build-protocol-info", - "build-integrate-assets", - "build-node-management", - "build-node-interaction", - "build-transaction-construction", - ], - }, - { - type: "category", - label: "Tools", - items: ["build-tools-index"], - }, - { - type: "category", - label: "Resources", - items: ["build-hackathon"], - }, - ], - }, - { - type: "category", - label: "Maintain", - items: [ - "maintain-index", - "maintain-polkadot-parameters", - { - type: "category", - label: "Nodes and Dapps", - items: ["maintain-sync", "maintain-networks", "maintain-wss", "maintain-errors"], - }, - { - type: "category", - label: "Nominator Guides", - items: ["maintain-guides-how-to-nominate-polkadot", "maintain-guides-how-to-unbond"], - }, - { - type: "category", - label: "Validator Guides", - items: [ - "maintain-guides-how-to-validate-polkadot", - "maintain-guides-validator-payout", - "maintain-guides-how-to-systemd", - "maintain-guides-secure-validator", - "maintain-guides-how-to-use-polkadot-validator-setup", - "maintain-guides-how-to-setup-a-validator-with-reverse-proxy", - "maintain-guides-how-to-upgrade", - "maintain-guides-how-to-monitor-your-node", - "maintain-guides-how-to-chill", - "maintain-guides-how-to-stop-validating", - ], - }, - { - type: "category", - label: "Governance Guides", - items: [ - "maintain-guides-democracy", - "maintain-guides-how-to-join-council", - "maintain-guides-how-to-vote-councillor", - ], - }, - ], - }, - ], -}; diff --git a/website-v2/src/pages/index.js b/website-v2/src/pages/index.js deleted file mode 100644 index b4e031159680..000000000000 --- a/website-v2/src/pages/index.js +++ /dev/null @@ -1,233 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -import * as React from "react"; - -import Container from "react-bootstrap/Container"; -import Row from "react-bootstrap/Row"; -import Col from "react-bootstrap/Col"; -import Translate from "@docusaurus/Translate"; -import Layout from "@theme/Layout"; -import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; - -import KusamaCanary from "@site/static/img/kusama_canary_white.svg"; - -function HomeNav() { - const NavContainer = ({ children }) => ( -
    - - {children} - -
    - ); - - const NavItem = ({ href, aosDelay, children }) => ( - - -
    {children}
    -     - - ); - - const NavItemTitle = ({ children }) => ( -

    {children}

    - ); - - const NavItemContent = ({ children }) =>

    {children}

    ; - - return ( - - - - - Learn - - - - - Polkadot is a sharded protocol that enables blockchain networks to operate together - seamlessly. - - - - - - - Build - - - - - Most up-to-date information on the status of the development tools in the Polkadot - ecosystem. - - - - - - - Maintain - - - - - Information and guides on how to deploy a node and run the network. - - - - - ); -} - -function HomeFooter() { - const FooterContainer = ({ children }) => ( -
    - - {children} - -
    - ); - - const LearnKusama = () => ( - - -

    - - Learn about Polkadot’s canary network Kusama - -

    -

    - - Kusama is Polkadot’s “canary network”, a scalable, multi-chain network for radical - innovation and early stage Polkadot deployments. For developers, Kusama is a proving - ground for all things Polkadot I.e runtime upgrades, on-chain governance, parachains, - parathreads, etc. - -

    - - - ); - - const ImproveWiki = () => ( - - - language - -

    - - Help improve this wiki - -

    -

    - - This wiki was started by and is maintained by Web3 Foundation. It is an open-source-ish - project and aims to be the most extensive resource of knowledge on Polkadot and the - Polkadot ecosystem. - -

    - - - ); - - return ( - - - - - ); -} - -export default function Index() { - const { siteConfig } = useDocusaurusContext(); - - return ( - -
    - - -
    -     - ); -} - -function useDocUrl(url) { - const { siteConfig } = useDocusaurusContext(); - const { baseUrl } = siteConfig; - const docsPart = "docs/"; - return `${baseUrl}${docsPart}${url}`; -} diff --git a/website-v2/src/theme/Footer.js b/website-v2/src/theme/Footer.js deleted file mode 100644 index c42690a458c3..000000000000 --- a/website-v2/src/theme/Footer.js +++ /dev/null @@ -1,302 +0,0 @@ -import * as React from "react"; - -import Container from "react-bootstrap/Container"; -import Row from "react-bootstrap/Row"; -import Col from "react-bootstrap/Col"; -import Button from "react-bootstrap/Button"; -import Translate, { translate } from "@docusaurus/Translate"; -import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; - -import Logo from "@site/static/img/logo-polkadot-light.svg"; - -function FooterNavColumn({ headline, children }) { - return ( - -
    {headline}
    -
      {children}
    - - ); -} - -function FooterSocialColumn() { - const SocialItem = ({ href, className }) => { - return ( -
  • - - - -
    • - ); - }; - - const Social = () => ( -
      - - - - - -
    - ); - - const Newsletter = () => ( - <> -

    - - Subscribe to the newsletter to hear about Polkadot updates and events. - -

    - - - ); - - return ( - - - - - ); -} - -function FooterLegalLink({ href, content }) { - return ( -
  • - - {content} - -
    • - ); -} - -function FooterLink({ href, content }) { - return ( -
  • - - {content} - -
    • - ); -} - -export default function Footer() { - const { siteConfig } = useDocusaurusContext(); - const { footer } = siteConfig.themeConfig; - - return ( -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - {footer && ( - - - - - - )} - -
      - - - - - {/* TODO: FIX the replacement */} - -
    - -     -     -
    - ); -} diff --git a/website-v2/static/css/copycode.css b/website-v2/static/css/copycode.css deleted file mode 100644 index aa97eca12c13..000000000000 --- a/website-v2/static/css/copycode.css +++ /dev/null @@ -1,40 +0,0 @@ -/* "Copy" code block button */ -pre { - position: relative; -} - -pre .btnIcon { - position: absolute; - top: 4px; - z-index: 2; - cursor: pointer; - border: 1px solid transparent; - padding: 3px; - color: black; - background-color: rgba(255, 255, 255, 0.7); - height: 30px; - transition: all 0.25s ease-out; -} - -pre .btnIcon:hover { - text-decoration: none; - border: 1px solid silver; -} - -.btnIcon__body { - align-items: center; - display: flex; -} - -.btnIcon svg { - fill: currentColor; - margin-right: 0.4em; -} - -.btnIcon__label { - font-size: 11px; -} - -.btnClipboard { - right: 10px; -} diff --git a/website-v2/static/css/custom.css b/website-v2/static/css/custom.css deleted file mode 100755 index 38206d2a827f..000000000000 --- a/website-v2/static/css/custom.css +++ /dev/null @@ -1,585 +0,0 @@ -:root { - --ifm-color-primary: #e6007a; - --ifm-color-primary-dark: #cf006e; - --ifm-color-primary-darker: #c40068; - --ifm-color-primary-darkest: #a10055; - --ifm-color-primary-light: #fd0086; - --ifm-color-primary-lighter: #ff0a8c; - --ifm-color-primary-lightest: #ff2c9c; - --secondaryColor: #172026; - --snowColor: #efefef; - --silverColor: #b7b8bb; - --nickelColor: #6d7278; - --blackColor: black; - --ifm-navbar-height: 50px; - --sansFontFamily: "Work Sans", sans-serif !important; - --docsearch-searchbox-background: white; - --docsearch-searchbox-shadow: var(--snowColor); - - --custom-code-block-background: #f6f8fa; - --custom-content-max-width: 1400px; -} - -body { - font-family: var(--sansFontFamily); -} - -/* ========================================================================== - Typography - ========================================================================== */ - -.h1, -.h2, -.h3, -.h4, -.h5, -.h6 { - margin-top: 0; -} - -/* ========================================================================== - General components - ========================================================================== */ - -/* Back to top button */ -#back-to-top { - left: 16px; - bottom: 26px; - background-color: #ebedf0; - color: #1c1e21; - height: 48px; - width: 48px; -} - -#back-to-top svg { - margin-top: 12px; -} - -/* Sidebar menu button */ -button.menu__button { - box-shadow: 0 2px 5px 0 rgba(0,0,0,.26); -} - -/* ========================================================================== - Navigation bar - ========================================================================== */ - -.navbar.navbar--fixed-top { - height: auto; -} - -.navbar__inner { - max-width: var(--custom-content-max-width); - margin-left: auto; - margin-right: auto; -} - -.navbar__inner a.navbar__item svg[class^="iconExternalLink"] { - display: none -} - -/* Contribute button */ -@media only screen and (min-width: 1024px) { - .navbar__inner a.navbar__item[href*="contributing"] { - background: white; - color: var(--ifm-color-primary); - border: solid 1px var(--ifm-color-primary); - border-radius: 20px; - - height: 35px; - padding: 0 16px; - margin-left: 16px; - line-height: 35px; - font-size: 14px; - font-weight: bold; - } - - .navbar__inner a.navbar__item[href*="contributing"]:hover { - background: var(--ifm-color-primary); - color: white; - } -} - -/* Search button */ -.DocSearch.DocSearch-Button { - background-color: white; - color: var(--silverColor); - border: 1px solid var(--snowColor); - width: 170px; - cursor: text; -} - -@media only screen and (max-width: 750px) { - .DocSearch.DocSearch-Button { - width: 38px; - } -} - -.DocSearch.DocSearch-Button .DocSearch-Search-Icon { - color: var(--silverColor); -} - -.DocSearch.DocSearch-Button:hover .DocSearch-Search-Icon { - color: var(--secondaryColor) -} - -.DocSearch.DocSearch-Button .DocSearch-Button-Placeholder { - font-weight: 500; - font-size: 13px; -} - -.DocSearch.DocSearch-Button .DocSearch-Button-Keys { - display: none; -} - -/* Languages button */ -.navbar__inner .navbar__item:last-child { - margin-left: 5px; - margin-right: 5px; - opacity: 1; -} - -.navbar__inner .navbar__item:last-child a::after { - display: none; -} - -.navbar__inner .navbar__item:last-child .dropdown__menu { - right: 0; - top: 32px; - box-shadow: 0 1rem 3rem rgba(0, 0, 0, 0.175); - border-radius: 1.5rem; - text-align: center; -} - -.navbar__inner .navbar__item:last-child .dropdown__menu > li a { - padding: 12px 24px; - color: var(--secondaryColor); -} - -.navbar__inner .navbar__item:last-child .dropdown__menu > li a.dropdown__link--active { - color: var(--blackColor); - background-color: white; -} - -.navbar__inner .navbar__item:last-child .dropdown__menu > li a.dropdown__link--active:hover { - color: var(--ifm-color-primary); -} - -.navbar__inner .navbar__item:last-child .dropdown__menu > li a:hover { - background-color: var(--snowColor); - color: var(--ifm-color-primary); -} - -/* ========================================================================== - Home - ========================================================================== */ - -.homeContainer { - background: white; - text-align: center; -} - -.homeContainer a { - text-decoration: none -} - -.text-dark { - color: var(--secondaryColor) !important; -} - -.homeNavContainer { - padding: 3rem 0; -} - -.homeNavItem { - -webkit-transition: all 0.15s ease-in-out; - transition: all 0.15s ease-in-out; - padding: 3rem 0; - border-radius: 3.25rem !important; -} - -.homeNavItem p { - max-width: 300px; -} - -@media (min-width: 992px) { - .homeNavContainer { - height: 90vh; - min-height: 600px; - max-height: 900px; - } - - .homeNavItem { - -webkit-transition: all 0.15s ease-in-out; - transition: all 0.15s ease-in-out; - height: 60vh; - max-height: 500px; - border-radius: 3.25rem !important; - margin-top: -3rem; - } - - .homeNavItem::after { - font-size: 1.5rem; - font-family: "Material Icons"; - content: "arrow_upward"; - -webkit-font-feature-settings: "liga"; - position: absolute; - left: 50%; - bottom: 3rem; - color: var(--silverColor); - opacity: 0; - -webkit-transform: translate(-50%, 0); - transform: translate(-50%, 0); - -webkit-transition: all 0.2s ease-in-out; - transition: all 0.2s ease-in-out; - } - - .homeNavItem:hover { - box-shadow: 0 1rem 3rem rgba(0, 0, 0, 0.04); - transform: translateY(-1rem); - } - - .homeNavItem:hover::after { - opacity: 1; - } - - .homeNavItem h2 { - font-size: 3.5rem; - font-weight: 400; - line-height: 1.2; - } -} - -@media (min-width: 1200px) { - .homeNavItem h2 { - font-size: 4.5rem; - font-weight: 400; - line-height: 1.2; - } -} - -/* ========================================================================== - Home Footer - ========================================================================== */ - -.homeFooterContainer { - padding: 6rem 0 4rem; - background-image: linear-gradient(217deg, rgba(196, 0, 97, 0.8), rgba(196, 0, 97, 0) 70%), - linear-gradient(127deg, rgba(230, 0, 122, 0.8), rgba(230, 0, 122, 0) 70%), - linear-gradient(336deg, rgba(103, 69, 210, 0.7), rgba(103, 69, 210, 0) 70%); - background-color: #e6007a; -} - - -.homeFooterContainer .col-lg-6 { - display: flex; - flex-flow: column nowrap; - align-items: flex-start; - margin-bottom: 2rem; -} - -.homeFooterContainer .col-lg-6 > *:first-child { - margin-bottom: 1.3rem; -} - -.homeFooterContainer p { - margin-bottom: 2.5rem; -} - -/* ========================================================================== - Doc pages - ========================================================================== */ - -.docs-wrapper { - max-width: var(--custom-content-max-width); - margin: 0 auto; - padding-bottom: 80px -} - -article blockquote { - background-color: rgba(255,229,100,.3); - border-left: 8px solid #ffe564; -} - -article img, article iframe { - display: block; - margin-left: auto; - margin-right: auto; - max-width: 100% -} - -/* two following style is a workaround to prevent the code blocks expand in mobile */ - -.prism-code { - background-color: var(--custom-code-block-background) !important -} - -.prism-code > div { - width: 100px !important -} - -/* Table of content */ -.table-of-contents__link:hover, -.table-of-contents__link:hover code, -.table-of-contents__link--active, -.table-of-contents__link--active code { - font-weight: 600; -} - -/* - Button - ========================================================================== */ - -.btn { - font-weight: 700; - border-radius: 1.5rem; - font-size: 16px; - padding: 8px 16px; -} -.btn:before { - width: 42px; - left: -42px; - border-radius: 1.5rem; -} -.btn-lg, -.btn-group-lg > .btn { - border-radius: 2rem; - padding: 16px 20px; -} -.btn-lg:before, -.btn-group-lg > .btn:before { - width: 58px; - left: -58px; - border-radius: 2rem; -} -.btn-sm, -.btn-group-sm > .btn { - border-radius: 1.5rem; - font-size: 16px; - padding: 8px 16px; -} -.btn-sm:before, -.btn-group-sm > .btn:before { - width: 42px; - left: -42px; - border-radius: 1.5rem; -} -.btn-primary { - color: var(--ifm-color-primary); - background-color: transparent; - border-color: var(--ifm-color-primary); - position: relative; - z-index: 1; - overflow: hidden; - border: solid 1px var(--ifm-color-primary); - transition: all 0.2s ease, border 1ms ease; - will-change: transform; - transform: scale(0.999); -} -.btn-primary:before { - content: ""; - height: 100%; - position: absolute; - top: 0; - background: var(--ifm-color-primary); - transition: all 0.2s ease; - will-change: transform; - color: transparent; - z-index: -1; - border: solid 1px var(--ifm-color-primary); -} -.btn-primary:hover, -.btn-primary:focus, -.btn-primary:active { - background: none; - color: white; - will-change: transform; - transform: scale(1.05); - border: solid 1px transparent; -} -.btn-primary:focus, -.btn-primary.focus { - box-shadow: 0 0 0.2rem 0.2rem rgba(0, 0, 0, 0.1); -} -.btn-primary:not(:disabled):not(.disabled):active { - background-color: transparent; -} -.btn-primary[type="submit"]:hover, -.btn-primary[type="submit"]:focus, -.btn-primary[type="submit"]:active { - background: var(--ifm-color-primary); -} -.btn-primary:hover:before, -.btn-primary:focus:before, -.btn-primary:active:before { - left: 0; - width: 100%; -} -.btn-bg-primary.btn-primary { - color: white !important; - border: solid 1px white; -} -.btn-bg-primary.btn-primary:hover, -.btn-bg-primary.btn-primary:focus, -.btn-bg-primary.btn-primary:active { - background: white; - color: var(--ifm-color-primary) !important; -} -.btn-bg-primary.btn-primary:before { - content: none; - height: 100%; - position: absolute; - top: 0; - background: white; - transition: all 0.2s ease; - will-change: transform; - color: transparent; - z-index: -1; - border: solid 1px white; -} -.btn-white { - color: white !important; -} - -/* ========================================================================== - Bootstrap fix - ========================================================================== */ - -.nav-footer.spacer-y-4 { - padding-top: 3rem; - padding-bottom: 3rem; -} - -.nav-footer.pb-4 { - padding-bottom: 2.25rem !important; -} - -.nav-footer .text-small { - font-size: 0.875rem; -} - -@media (min-width: 768px) { - .nav-footer.spacer-y-4 { - padding-top: 6rem; - padding-bottom: 6rem; - } - - .nav-footer .py-md-1 { - padding-bottom: 0.375rem !important; - padding-top: 0.375rem !important; - } -} - -/* ========================================================================== - Footer - ========================================================================== */ - -.nav-footer { - background: var(--secondaryColor); - border: none; - color: #202020; - font-size: 16px; - line-height: 24px; - position: relative; -} - -/* - Footer Nav - ========================================================================== */ - -.nav-footer h5 { - font-size: 1.25rem; - font-weight: 400; - letter-spacing: -0.04em; - margin-top: 0; -} - -.nav-footer a:hover { - text-decoration: none; -} - -.nav-footer a.text-white { - color: var(--silverColor) !important; -} - -.nav-footer a.text-white:visited { - color: var(--silverColor) !important; -} - -.nav-footer a.text-white:hover { - color: white !important; -} - -/* - Footer Social - ========================================================================== */ - -.list-social-links { - padding: 0; - list-style: none; - display: flex; -} - -footer .list-social-links i { - font-size: 1.2rem; -} - -footer .list-social-links a { - padding: 0.25rem 0.9rem; - text-decoration: none; -} - -footer [class^="socicon-"] { - line-height: 2; -} - -footer .list-social-links { - margin-left: 0; -} -footer .list-social-links li { - margin-top: 0 !important; -} - -footer .list-social-links a { - background: transparent !important; - border: 1px solid white; - color: white; - padding: 0.25rem 0.9rem; - display: block; - border-radius: 50%; -} - -/* - Footer Legal - ========================================================================== */ - -.footer-legal .navbar-brand { - display: block; - padding-bottom: 0; -} - -.footer-legal ul { - margin-bottom: 0; -} - -.footer-legal li + li { - margin-top: 0; -} - -.footer-legal .list-pipe-separator > li:not(:last-child) > a:after { - content: "|"; - margin: 0 0.375rem; - opacity: 0.5; -} - -.footer-legal a.text-white { - color: #b5aeae !important; -} - -.footer-legal a.text-white:visited { - color: #b5aeae !important; -} - -.footer-legal a.text-white:hover { - color: #fff !important; -} diff --git a/website-v2/static/img/PRE.png b/website-v2/static/img/PRE.png deleted file mode 100644 index 85968c24db35..000000000000 Binary files a/website-v2/static/img/PRE.png and /dev/null differ diff --git a/website-v2/static/img/Polkadot_Logotype_color.png b/website-v2/static/img/Polkadot_Logotype_color.png deleted file mode 100644 index f9bcc3505c6c..000000000000 Binary files a/website-v2/static/img/Polkadot_Logotype_color.png and /dev/null differ diff --git a/website-v2/static/img/Polkadot_Logotype_white.png b/website-v2/static/img/Polkadot_Logotype_white.png deleted file mode 100644 index 82516058d395..000000000000 Binary files a/website-v2/static/img/Polkadot_Logotype_white.png and /dev/null differ diff --git a/website-v2/static/img/Polkadot_logotype_color.svg b/website-v2/static/img/Polkadot_logotype_color.svg deleted file mode 100644 index aaac889947a2..000000000000 --- a/website-v2/static/img/Polkadot_logotype_color.svg +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - - - - - - diff --git a/website-v2/static/img/Polkadot_symbol_color.png b/website-v2/static/img/Polkadot_symbol_color.png deleted file mode 100644 index 5e36153e4df3..000000000000 Binary files a/website-v2/static/img/Polkadot_symbol_color.png and /dev/null differ diff --git a/website-v2/static/img/Polkadot_symbol_white.svg b/website-v2/static/img/Polkadot_symbol_white.svg deleted file mode 100644 index e283b20ee5c9..000000000000 --- a/website-v2/static/img/Polkadot_symbol_white.svg +++ /dev/null @@ -1,18 +0,0 @@ - - - - - - - - - - diff --git a/website-v2/static/img/favicon.ico b/website-v2/static/img/favicon.ico deleted file mode 100644 index 539c922aaae1..000000000000 Binary files a/website-v2/static/img/favicon.ico and /dev/null differ diff --git a/website-v2/static/img/icon_collator.svg b/website-v2/static/img/icon_collator.svg deleted file mode 100644 index 9d30d2b9c78d..000000000000 --- a/website-v2/static/img/icon_collator.svg +++ /dev/null @@ -1 +0,0 @@ -icon-users \ No newline at end of file diff --git a/website-v2/static/img/logo.svg b/website-v2/static/img/logo.svg deleted file mode 100644 index b72118a9038b..000000000000 --- a/website-v2/static/img/logo.svg +++ /dev/null @@ -1 +0,0 @@ -Asset 1 \ No newline at end of file diff --git a/website-v2/static/img/parachain-roadmap.jpg b/website-v2/static/img/parachain-roadmap.jpg deleted file mode 100644 index a2fb6ab9fa02..000000000000 Binary files a/website-v2/static/img/parachain-roadmap.jpg and /dev/null differ diff --git a/website-v2/static/img/polkadot-wechat.jpg b/website-v2/static/img/polkadot-wechat.jpg deleted file mode 100644 index b324eb10568b..000000000000 Binary files a/website-v2/static/img/polkadot-wechat.jpg and /dev/null differ diff --git a/website-v2/static/img/polkadot_overview.svg b/website-v2/static/img/polkadot_overview.svg deleted file mode 100644 index 8e4f599f8a90..000000000000 --- a/website-v2/static/img/polkadot_overview.svg +++ /dev/null @@ -1 +0,0 @@ -Asset 1 \ No newline at end of file diff --git a/website-v2/static/img/polkadot_ui_1.png b/website-v2/static/img/polkadot_ui_1.png deleted file mode 100644 index a8b3168db5e0..000000000000 Binary files a/website-v2/static/img/polkadot_ui_1.png and /dev/null differ diff --git a/website-v2/static/img/polkadot_ui_2.png b/website-v2/static/img/polkadot_ui_2.png deleted file mode 100644 index 2104967172e5..000000000000 Binary files a/website-v2/static/img/polkadot_ui_2.png and /dev/null differ diff --git a/website-v2/static/img/polkadot_ui_3.png b/website-v2/static/img/polkadot_ui_3.png deleted file mode 100644 index 555c7832617c..000000000000 Binary files a/website-v2/static/img/polkadot_ui_3.png and /dev/null differ diff --git a/website-v2/static/img/spree.jpg b/website-v2/static/img/spree.jpg deleted file mode 100644 index 8c2d64fef8bb..000000000000 Binary files a/website-v2/static/img/spree.jpg and /dev/null differ diff --git a/website-v2/static/js/clipboard.min.js b/website-v2/static/js/clipboard.min.js deleted file mode 100644 index 28650f3cc98a..000000000000 --- a/website-v2/static/js/clipboard.min.js +++ /dev/null @@ -1,7 +0,0 @@ -/*! - * clipboard.js v2.0.6 - * https://clipboardjs.com/ - * - * Licensed MIT © Zeno Rocha - */ -!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.ClipboardJS=e():t.ClipboardJS=e()}(this,function(){return o={},r.m=n=[function(t,e){t.exports=function(t){var e;if("SELECT"===t.nodeName)t.focus(),e=t.value;else if("INPUT"===t.nodeName||"TEXTAREA"===t.nodeName){var n=t.hasAttribute("readonly");n||t.setAttribute("readonly",""),t.select(),t.setSelectionRange(0,t.value.length),n||t.removeAttribute("readonly"),e=t.value}else{t.hasAttribute("contenteditable")&&t.focus();var o=window.getSelection(),r=document.createRange();r.selectNodeContents(t),o.removeAllRanges(),o.addRange(r),e=o.toString()}return e}},function(t,e){function n(){}n.prototype={on:function(t,e,n){var o=this.e||(this.e={});return(o[t]||(o[t]=[])).push({fn:e,ctx:n}),this},once:function(t,e,n){var o=this;function r(){o.off(t,r),e.apply(n,arguments)}return r._=e,this.on(t,r,n)},emit:function(t){for(var e=[].slice.call(arguments,1),n=((this.e||(this.e={}))[t]||[]).slice(),o=0,r=n.length;o' + - icon + - '' + - label + - "" + - "
    "; - return btn; - } - - function addButtons(codeBlockSelector, btn) { - document.querySelectorAll(codeBlockSelector).forEach(function (code) { - code.parentNode.appendChild(btn.cloneNode(true)); - }); - } - - const copyIcon = - ''; - - addButtons(".hljs", button("Copy", "Copy code to clipboard", copyIcon, "btnClipboard")); - - const clipboard = new ClipboardJS(".btnClipboard", { - target: function (trigger) { - return trigger.parentNode.querySelector("code"); - }, - }); - - clipboard.on("success", function (event) { - event.clearSelection(); - const textEl = event.trigger.querySelector(".btnIcon__label"); - textEl.textContent = "Copied"; - setTimeout(function () { - textEl.textContent = "Copy"; - }, 2000); - }); -}); diff --git a/website-v2/static/js/packaged/addressChanger.js b/website-v2/static/js/packaged/addressChanger.js deleted file mode 100644 index b5a3da4b5349..000000000000 --- a/website-v2/static/js/packaged/addressChanger.js +++ /dev/null @@ -1 +0,0 @@ -!function(){return function A(e,t,i){function g(n,B){if(!t[n]){if(!e[n]){var I="function"==typeof require&&require;if(!B&&I)return I(n,!0);if(r)return r(n,!0);var o=new Error("Cannot find module '"+n+"'");throw o.code="MODULE_NOT_FOUND",o}var a=t[n]={exports:{}};e[n][0].call(a.exports,function(A){return g(e[n][1][A]||A)},a,a.exports,A,e,t,i)}return t[n].exports}for(var r="function"==typeof require&&require,n=0;n>6],g=0==(32&t);if(31==(31&t)){let i=t;for(t=0;128==(128&i);){if(i=A.readUInt8(e),A.isError(i))return i;t<<=7,t|=127&i}}else t&=31;return{cls:i,primitive:g,tag:t,tagStr:B.tag[t]}}function Q(A,e,t){let i=A.readUInt8(t);if(A.isError(i))return i;if(!e&&128===i)return null;if(0==(128&i))return i;const g=127&i;if(g>4)return A.error("length octect is too long");i=0;for(let e=0;e=31)return i.error("Multi-octet tag encoding unsupported");e||(g|=32);return g|=n.tagClassByName[t||"universal"]<<6}(A,e,t,this.reporter);if(i.length<128){const A=g.alloc(2);return A[0]=r,A[1]=i.length,this._createEncoderBuffer([A,i])}let B=1;for(let A=i.length;A>=256;A>>=8)B++;const I=g.alloc(2+B);I[0]=r,I[1]=128|B;for(let A=1+B,e=i.length;e>0;A--,e>>=8)I[A]=255&e;return this._createEncoderBuffer([I,i])},I.prototype._encodeStr=function(A,e){if("bitstr"===e)return this._createEncoderBuffer([0|A.unused,A.data]);if("bmpstr"===e){const e=g.alloc(2*A.length);for(let t=0;t=40)return this.reporter.error("Second objid identifier OOB");A.splice(0,2,40*A[0]+A[1])}let i=0;for(let e=0;e=128;t>>=7)i++}const r=g.alloc(i);let n=r.length-1;for(let e=A.length-1;e>=0;e--){let t=A[e];for(r[n--]=127&t;(t>>=7)>0;)r[n--]=128|127&t}return this._createEncoderBuffer(r)},I.prototype._encodeTime=function(A,e){let t;const i=new Date(A);return"gentime"===e?t=[o(i.getUTCFullYear()),o(i.getUTCMonth()+1),o(i.getUTCDate()),o(i.getUTCHours()),o(i.getUTCMinutes()),o(i.getUTCSeconds()),"Z"].join(""):"utctime"===e?t=[o(i.getUTCFullYear()%100),o(i.getUTCMonth()+1),o(i.getUTCDate()),o(i.getUTCHours()),o(i.getUTCMinutes()),o(i.getUTCSeconds()),"Z"].join(""):this.reporter.error("Encoding "+e+" time is not supported yet"),this._encodeStr(t,"octstr")},I.prototype._encodeNull=function(){return this._createEncoderBuffer("")},I.prototype._encodeInt=function(A,e){if("string"==typeof A){if(!e)return this.reporter.error("String int or enum given, but no values map");if(!e.hasOwnProperty(A))return this.reporter.error("Values map doesn't contain: "+JSON.stringify(A));A=e[A]}if("number"!=typeof A&&!g.isBuffer(A)){const e=A.toArray();!A.sign&&128&e[0]&&e.unshift(0),A=g.from(e)}if(g.isBuffer(A)){let e=A.length;0===A.length&&e++;const t=g.alloc(e);return A.copy(t),0===A.length&&(t[0]=0),this._createEncoderBuffer(t)}if(A<128)return this._createEncoderBuffer(A);if(A<256)return this._createEncoderBuffer([0,A]);let t=1;for(let e=A;e>=256;e>>=8)t++;const i=new Array(t);for(let e=i.length-1;e>=0;e--)i[e]=255&A,A>>=8;return 128&i[0]&&i.unshift(0),this._createEncoderBuffer(g.from(i))},I.prototype._encodeBool=function(A){return this._createEncoderBuffer(A?255:0)},I.prototype._use=function(A,e){return"function"==typeof A&&(A=A(e)),A._getEncoder("der").tree},I.prototype._skipDefault=function(A,e,t){const i=this._baseState;let g;if(null===i.default)return!1;const r=A.join();if(void 0===i.defaultBuffer&&(i.defaultBuffer=this._encodeValue(i.default,e,t).join()),r.length!==i.defaultBuffer.length)return!1;for(g=0;g=49&&n<=54?n-49+10:n>=17&&n<=22?n-17+10:15&n}return i}function I(A,e,t,i){for(var g=0,r=Math.min(A.length,t),n=e;n=49?B-49+10:B>=17?B-17+10:B}return g}r.isBN=function(A){return A instanceof r||null!==A&&"object"==typeof A&&A.constructor.wordSize===r.wordSize&&Array.isArray(A.words)},r.max=function(A,e){return A.cmp(e)>0?A:e},r.min=function(A,e){return A.cmp(e)<0?A:e},r.prototype._init=function(A,e,t){if("number"==typeof A)return this._initNumber(A,e,t);if("object"==typeof A)return this._initArray(A,e,t);"hex"===e&&(e=16),i(e===(0|e)&&e>=2&&e<=36);var g=0;"-"===(A=A.toString().replace(/\s+/g,""))[0]&&g++,16===e?this._parseHex(A,g):this._parseBase(A,e,g),"-"===A[0]&&(this.negative=1),this.strip(),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initNumber=function(A,e,t){A<0&&(this.negative=1,A=-A),A<67108864?(this.words=[67108863&A],this.length=1):A<4503599627370496?(this.words=[67108863&A,A/67108864&67108863],this.length=2):(i(A<9007199254740992),this.words=[67108863&A,A/67108864&67108863,1],this.length=3),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initArray=function(A,e,t){if(i("number"==typeof A.length),A.length<=0)return this.words=[0],this.length=1,this;this.length=Math.ceil(A.length/3),this.words=new Array(this.length);for(var g=0;g=0;g-=3)n=A[g]|A[g-1]<<8|A[g-2]<<16,this.words[r]|=n<>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);else if("le"===t)for(g=0,r=0;g>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);return this.strip()},r.prototype._parseHex=function(A,e){this.length=Math.ceil((A.length-e)/6),this.words=new Array(this.length);for(var t=0;t=e;t-=6)g=B(A,t,t+6),this.words[i]|=g<>>26-r&4194303,(r+=24)>=26&&(r-=26,i++);t+6!==e&&(g=B(A,e,t+6),this.words[i]|=g<>>26-r&4194303),this.strip()},r.prototype._parseBase=function(A,e,t){this.words=[0],this.length=1;for(var i=0,g=1;g<=67108863;g*=e)i++;i--,g=g/e|0;for(var r=A.length-t,n=r%i,B=Math.min(r,r-n)+t,o=0,a=t;a1&&0===this.words[this.length-1];)this.length--;return this._normSign()},r.prototype._normSign=function(){return 1===this.length&&0===this.words[0]&&(this.negative=0),this},r.prototype.inspect=function(){return(this.red?""};var o=["","0","00","000","0000","00000","000000","0000000","00000000","000000000","0000000000","00000000000","000000000000","0000000000000","00000000000000","000000000000000","0000000000000000","00000000000000000","000000000000000000","0000000000000000000","00000000000000000000","000000000000000000000","0000000000000000000000","00000000000000000000000","000000000000000000000000","0000000000000000000000000"],a=[0,0,25,16,12,11,10,9,8,8,7,7,7,7,6,6,6,6,6,6,6,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5],Q=[0,0,33554432,43046721,16777216,48828125,60466176,40353607,16777216,43046721,1e7,19487171,35831808,62748517,7529536,11390625,16777216,24137569,34012224,47045881,64e6,4084101,5153632,6436343,7962624,9765625,11881376,14348907,17210368,20511149,243e5,28629151,33554432,39135393,45435424,52521875,60466176];function C(A,e,t){t.negative=e.negative^A.negative;var i=A.length+e.length|0;t.length=i,i=i-1|0;var g=0|A.words[0],r=0|e.words[0],n=g*r,B=67108863&n,I=n/67108864|0;t.words[0]=B;for(var o=1;o>>26,Q=67108863&I,C=Math.min(o,e.length-1),s=Math.max(0,o-A.length+1);s<=C;s++){var c=o-s|0;a+=(n=(g=0|A.words[c])*(r=0|e.words[s])+Q)/67108864|0,Q=67108863&n}t.words[o]=0|Q,I=0|a}return 0!==I?t.words[o]=0|I:t.length--,t.strip()}r.prototype.toString=function(A,e){var t;if(A=A||10,e=0|e||1,16===A||"hex"===A){t="";for(var g=0,r=0,n=0;n>>24-g&16777215)||n!==this.length-1?o[6-I.length]+I+t:I+t,(g+=2)>=26&&(g-=26,n--)}for(0!==r&&(t=r.toString(16)+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}if(A===(0|A)&&A>=2&&A<=36){var C=a[A],s=Q[A];t="";var c=this.clone();for(c.negative=0;!c.isZero();){var h=c.modn(s).toString(A);t=(c=c.idivn(s)).isZero()?h+t:o[C-h.length]+h+t}for(this.isZero()&&(t="0"+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}i(!1,"Base should be between 2 and 36")},r.prototype.toNumber=function(){var A=this.words[0];return 2===this.length?A+=67108864*this.words[1]:3===this.length&&1===this.words[2]?A+=4503599627370496+67108864*this.words[1]:this.length>2&&i(!1,"Number can only safely store up to 53 bits"),0!==this.negative?-A:A},r.prototype.toJSON=function(){return this.toString(16)},r.prototype.toBuffer=function(A,e){return i(void 0!==n),this.toArrayLike(n,A,e)},r.prototype.toArray=function(A,e){return this.toArrayLike(Array,A,e)},r.prototype.toArrayLike=function(A,e,t){var g=this.byteLength(),r=t||Math.max(1,g);i(g<=r,"byte array longer than desired length"),i(r>0,"Requested array length <= 0"),this.strip();var n,B,I="le"===e,o=new A(r),a=this.clone();if(I){for(B=0;!a.isZero();B++)n=a.andln(255),a.iushrn(8),o[B]=n;for(;B=4096&&(t+=13,e>>>=13),e>=64&&(t+=7,e>>>=7),e>=8&&(t+=4,e>>>=4),e>=2&&(t+=2,e>>>=2),t+e},r.prototype._zeroBits=function(A){if(0===A)return 26;var e=A,t=0;return 0==(8191&e)&&(t+=13,e>>>=13),0==(127&e)&&(t+=7,e>>>=7),0==(15&e)&&(t+=4,e>>>=4),0==(3&e)&&(t+=2,e>>>=2),0==(1&e)&&t++,t},r.prototype.bitLength=function(){var A=this.words[this.length-1],e=this._countBits(A);return 26*(this.length-1)+e},r.prototype.zeroBits=function(){if(this.isZero())return 0;for(var A=0,e=0;eA.length?this.clone().ior(A):A.clone().ior(this)},r.prototype.uor=function(A){return this.length>A.length?this.clone().iuor(A):A.clone().iuor(this)},r.prototype.iuand=function(A){var e;e=this.length>A.length?A:this;for(var t=0;tA.length?this.clone().iand(A):A.clone().iand(this)},r.prototype.uand=function(A){return this.length>A.length?this.clone().iuand(A):A.clone().iuand(this)},r.prototype.iuxor=function(A){var e,t;this.length>A.length?(e=this,t=A):(e=A,t=this);for(var i=0;iA.length?this.clone().ixor(A):A.clone().ixor(this)},r.prototype.uxor=function(A){return this.length>A.length?this.clone().iuxor(A):A.clone().iuxor(this)},r.prototype.inotn=function(A){i("number"==typeof A&&A>=0);var e=0|Math.ceil(A/26),t=A%26;this._expand(e),t>0&&e--;for(var g=0;g0&&(this.words[g]=~this.words[g]&67108863>>26-t),this.strip()},r.prototype.notn=function(A){return this.clone().inotn(A)},r.prototype.setn=function(A,e){i("number"==typeof A&&A>=0);var t=A/26|0,g=A%26;return this._expand(t+1),this.words[t]=e?this.words[t]|1<A.length?(t=this,i=A):(t=A,i=this);for(var g=0,r=0;r>>26;for(;0!==g&&r>>26;if(this.length=t.length,0!==g)this.words[this.length]=g,this.length++;else if(t!==this)for(;rA.length?this.clone().iadd(A):A.clone().iadd(this)},r.prototype.isub=function(A){if(0!==A.negative){A.negative=0;var e=this.iadd(A);return A.negative=1,e._normSign()}if(0!==this.negative)return this.negative=0,this.iadd(A),this.negative=1,this._normSign();var t,i,g=this.cmp(A);if(0===g)return this.negative=0,this.length=1,this.words[0]=0,this;g>0?(t=this,i=A):(t=A,i=this);for(var r=0,n=0;n>26,this.words[n]=67108863&e;for(;0!==r&&n>26,this.words[n]=67108863&e;if(0===r&&n>>13,s=0|n[1],c=8191&s,h=s>>>13,f=0|n[2],E=8191&f,u=f>>>13,d=0|n[3],l=8191&d,w=d>>>13,p=0|n[4],D=8191&p,b=p>>>13,y=0|n[5],M=8191&y,m=y>>>13,G=0|n[6],k=8191&G,F=G>>>13,N=0|n[7],S=8191&N,Y=N>>>13,v=0|n[8],K=8191&v,U=v>>>13,J=0|n[9],H=8191&J,R=J>>>13,q=0|B[0],L=8191&q,x=q>>>13,Z=0|B[1],j=8191&Z,W=Z>>>13,O=0|B[2],P=8191&O,V=O>>>13,X=0|B[3],z=8191&X,T=X>>>13,_=0|B[4],$=8191&_,AA=_>>>13,eA=0|B[5],tA=8191&eA,iA=eA>>>13,gA=0|B[6],rA=8191&gA,nA=gA>>>13,BA=0|B[7],IA=8191&BA,oA=BA>>>13,aA=0|B[8],QA=8191&aA,CA=aA>>>13,sA=0|B[9],cA=8191&sA,hA=sA>>>13;t.negative=A.negative^e.negative,t.length=19;var fA=(o+(i=Math.imul(Q,L))|0)+((8191&(g=(g=Math.imul(Q,x))+Math.imul(C,L)|0))<<13)|0;o=((r=Math.imul(C,x))+(g>>>13)|0)+(fA>>>26)|0,fA&=67108863,i=Math.imul(c,L),g=(g=Math.imul(c,x))+Math.imul(h,L)|0,r=Math.imul(h,x);var EA=(o+(i=i+Math.imul(Q,j)|0)|0)+((8191&(g=(g=g+Math.imul(Q,W)|0)+Math.imul(C,j)|0))<<13)|0;o=((r=r+Math.imul(C,W)|0)+(g>>>13)|0)+(EA>>>26)|0,EA&=67108863,i=Math.imul(E,L),g=(g=Math.imul(E,x))+Math.imul(u,L)|0,r=Math.imul(u,x),i=i+Math.imul(c,j)|0,g=(g=g+Math.imul(c,W)|0)+Math.imul(h,j)|0,r=r+Math.imul(h,W)|0;var uA=(o+(i=i+Math.imul(Q,P)|0)|0)+((8191&(g=(g=g+Math.imul(Q,V)|0)+Math.imul(C,P)|0))<<13)|0;o=((r=r+Math.imul(C,V)|0)+(g>>>13)|0)+(uA>>>26)|0,uA&=67108863,i=Math.imul(l,L),g=(g=Math.imul(l,x))+Math.imul(w,L)|0,r=Math.imul(w,x),i=i+Math.imul(E,j)|0,g=(g=g+Math.imul(E,W)|0)+Math.imul(u,j)|0,r=r+Math.imul(u,W)|0,i=i+Math.imul(c,P)|0,g=(g=g+Math.imul(c,V)|0)+Math.imul(h,P)|0,r=r+Math.imul(h,V)|0;var dA=(o+(i=i+Math.imul(Q,z)|0)|0)+((8191&(g=(g=g+Math.imul(Q,T)|0)+Math.imul(C,z)|0))<<13)|0;o=((r=r+Math.imul(C,T)|0)+(g>>>13)|0)+(dA>>>26)|0,dA&=67108863,i=Math.imul(D,L),g=(g=Math.imul(D,x))+Math.imul(b,L)|0,r=Math.imul(b,x),i=i+Math.imul(l,j)|0,g=(g=g+Math.imul(l,W)|0)+Math.imul(w,j)|0,r=r+Math.imul(w,W)|0,i=i+Math.imul(E,P)|0,g=(g=g+Math.imul(E,V)|0)+Math.imul(u,P)|0,r=r+Math.imul(u,V)|0,i=i+Math.imul(c,z)|0,g=(g=g+Math.imul(c,T)|0)+Math.imul(h,z)|0,r=r+Math.imul(h,T)|0;var lA=(o+(i=i+Math.imul(Q,$)|0)|0)+((8191&(g=(g=g+Math.imul(Q,AA)|0)+Math.imul(C,$)|0))<<13)|0;o=((r=r+Math.imul(C,AA)|0)+(g>>>13)|0)+(lA>>>26)|0,lA&=67108863,i=Math.imul(M,L),g=(g=Math.imul(M,x))+Math.imul(m,L)|0,r=Math.imul(m,x),i=i+Math.imul(D,j)|0,g=(g=g+Math.imul(D,W)|0)+Math.imul(b,j)|0,r=r+Math.imul(b,W)|0,i=i+Math.imul(l,P)|0,g=(g=g+Math.imul(l,V)|0)+Math.imul(w,P)|0,r=r+Math.imul(w,V)|0,i=i+Math.imul(E,z)|0,g=(g=g+Math.imul(E,T)|0)+Math.imul(u,z)|0,r=r+Math.imul(u,T)|0,i=i+Math.imul(c,$)|0,g=(g=g+Math.imul(c,AA)|0)+Math.imul(h,$)|0,r=r+Math.imul(h,AA)|0;var wA=(o+(i=i+Math.imul(Q,tA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,iA)|0)+Math.imul(C,tA)|0))<<13)|0;o=((r=r+Math.imul(C,iA)|0)+(g>>>13)|0)+(wA>>>26)|0,wA&=67108863,i=Math.imul(k,L),g=(g=Math.imul(k,x))+Math.imul(F,L)|0,r=Math.imul(F,x),i=i+Math.imul(M,j)|0,g=(g=g+Math.imul(M,W)|0)+Math.imul(m,j)|0,r=r+Math.imul(m,W)|0,i=i+Math.imul(D,P)|0,g=(g=g+Math.imul(D,V)|0)+Math.imul(b,P)|0,r=r+Math.imul(b,V)|0,i=i+Math.imul(l,z)|0,g=(g=g+Math.imul(l,T)|0)+Math.imul(w,z)|0,r=r+Math.imul(w,T)|0,i=i+Math.imul(E,$)|0,g=(g=g+Math.imul(E,AA)|0)+Math.imul(u,$)|0,r=r+Math.imul(u,AA)|0,i=i+Math.imul(c,tA)|0,g=(g=g+Math.imul(c,iA)|0)+Math.imul(h,tA)|0,r=r+Math.imul(h,iA)|0;var pA=(o+(i=i+Math.imul(Q,rA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,nA)|0)+Math.imul(C,rA)|0))<<13)|0;o=((r=r+Math.imul(C,nA)|0)+(g>>>13)|0)+(pA>>>26)|0,pA&=67108863,i=Math.imul(S,L),g=(g=Math.imul(S,x))+Math.imul(Y,L)|0,r=Math.imul(Y,x),i=i+Math.imul(k,j)|0,g=(g=g+Math.imul(k,W)|0)+Math.imul(F,j)|0,r=r+Math.imul(F,W)|0,i=i+Math.imul(M,P)|0,g=(g=g+Math.imul(M,V)|0)+Math.imul(m,P)|0,r=r+Math.imul(m,V)|0,i=i+Math.imul(D,z)|0,g=(g=g+Math.imul(D,T)|0)+Math.imul(b,z)|0,r=r+Math.imul(b,T)|0,i=i+Math.imul(l,$)|0,g=(g=g+Math.imul(l,AA)|0)+Math.imul(w,$)|0,r=r+Math.imul(w,AA)|0,i=i+Math.imul(E,tA)|0,g=(g=g+Math.imul(E,iA)|0)+Math.imul(u,tA)|0,r=r+Math.imul(u,iA)|0,i=i+Math.imul(c,rA)|0,g=(g=g+Math.imul(c,nA)|0)+Math.imul(h,rA)|0,r=r+Math.imul(h,nA)|0;var DA=(o+(i=i+Math.imul(Q,IA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,oA)|0)+Math.imul(C,IA)|0))<<13)|0;o=((r=r+Math.imul(C,oA)|0)+(g>>>13)|0)+(DA>>>26)|0,DA&=67108863,i=Math.imul(K,L),g=(g=Math.imul(K,x))+Math.imul(U,L)|0,r=Math.imul(U,x),i=i+Math.imul(S,j)|0,g=(g=g+Math.imul(S,W)|0)+Math.imul(Y,j)|0,r=r+Math.imul(Y,W)|0,i=i+Math.imul(k,P)|0,g=(g=g+Math.imul(k,V)|0)+Math.imul(F,P)|0,r=r+Math.imul(F,V)|0,i=i+Math.imul(M,z)|0,g=(g=g+Math.imul(M,T)|0)+Math.imul(m,z)|0,r=r+Math.imul(m,T)|0,i=i+Math.imul(D,$)|0,g=(g=g+Math.imul(D,AA)|0)+Math.imul(b,$)|0,r=r+Math.imul(b,AA)|0,i=i+Math.imul(l,tA)|0,g=(g=g+Math.imul(l,iA)|0)+Math.imul(w,tA)|0,r=r+Math.imul(w,iA)|0,i=i+Math.imul(E,rA)|0,g=(g=g+Math.imul(E,nA)|0)+Math.imul(u,rA)|0,r=r+Math.imul(u,nA)|0,i=i+Math.imul(c,IA)|0,g=(g=g+Math.imul(c,oA)|0)+Math.imul(h,IA)|0,r=r+Math.imul(h,oA)|0;var bA=(o+(i=i+Math.imul(Q,QA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,CA)|0)+Math.imul(C,QA)|0))<<13)|0;o=((r=r+Math.imul(C,CA)|0)+(g>>>13)|0)+(bA>>>26)|0,bA&=67108863,i=Math.imul(H,L),g=(g=Math.imul(H,x))+Math.imul(R,L)|0,r=Math.imul(R,x),i=i+Math.imul(K,j)|0,g=(g=g+Math.imul(K,W)|0)+Math.imul(U,j)|0,r=r+Math.imul(U,W)|0,i=i+Math.imul(S,P)|0,g=(g=g+Math.imul(S,V)|0)+Math.imul(Y,P)|0,r=r+Math.imul(Y,V)|0,i=i+Math.imul(k,z)|0,g=(g=g+Math.imul(k,T)|0)+Math.imul(F,z)|0,r=r+Math.imul(F,T)|0,i=i+Math.imul(M,$)|0,g=(g=g+Math.imul(M,AA)|0)+Math.imul(m,$)|0,r=r+Math.imul(m,AA)|0,i=i+Math.imul(D,tA)|0,g=(g=g+Math.imul(D,iA)|0)+Math.imul(b,tA)|0,r=r+Math.imul(b,iA)|0,i=i+Math.imul(l,rA)|0,g=(g=g+Math.imul(l,nA)|0)+Math.imul(w,rA)|0,r=r+Math.imul(w,nA)|0,i=i+Math.imul(E,IA)|0,g=(g=g+Math.imul(E,oA)|0)+Math.imul(u,IA)|0,r=r+Math.imul(u,oA)|0,i=i+Math.imul(c,QA)|0,g=(g=g+Math.imul(c,CA)|0)+Math.imul(h,QA)|0,r=r+Math.imul(h,CA)|0;var yA=(o+(i=i+Math.imul(Q,cA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,hA)|0)+Math.imul(C,cA)|0))<<13)|0;o=((r=r+Math.imul(C,hA)|0)+(g>>>13)|0)+(yA>>>26)|0,yA&=67108863,i=Math.imul(H,j),g=(g=Math.imul(H,W))+Math.imul(R,j)|0,r=Math.imul(R,W),i=i+Math.imul(K,P)|0,g=(g=g+Math.imul(K,V)|0)+Math.imul(U,P)|0,r=r+Math.imul(U,V)|0,i=i+Math.imul(S,z)|0,g=(g=g+Math.imul(S,T)|0)+Math.imul(Y,z)|0,r=r+Math.imul(Y,T)|0,i=i+Math.imul(k,$)|0,g=(g=g+Math.imul(k,AA)|0)+Math.imul(F,$)|0,r=r+Math.imul(F,AA)|0,i=i+Math.imul(M,tA)|0,g=(g=g+Math.imul(M,iA)|0)+Math.imul(m,tA)|0,r=r+Math.imul(m,iA)|0,i=i+Math.imul(D,rA)|0,g=(g=g+Math.imul(D,nA)|0)+Math.imul(b,rA)|0,r=r+Math.imul(b,nA)|0,i=i+Math.imul(l,IA)|0,g=(g=g+Math.imul(l,oA)|0)+Math.imul(w,IA)|0,r=r+Math.imul(w,oA)|0,i=i+Math.imul(E,QA)|0,g=(g=g+Math.imul(E,CA)|0)+Math.imul(u,QA)|0,r=r+Math.imul(u,CA)|0;var MA=(o+(i=i+Math.imul(c,cA)|0)|0)+((8191&(g=(g=g+Math.imul(c,hA)|0)+Math.imul(h,cA)|0))<<13)|0;o=((r=r+Math.imul(h,hA)|0)+(g>>>13)|0)+(MA>>>26)|0,MA&=67108863,i=Math.imul(H,P),g=(g=Math.imul(H,V))+Math.imul(R,P)|0,r=Math.imul(R,V),i=i+Math.imul(K,z)|0,g=(g=g+Math.imul(K,T)|0)+Math.imul(U,z)|0,r=r+Math.imul(U,T)|0,i=i+Math.imul(S,$)|0,g=(g=g+Math.imul(S,AA)|0)+Math.imul(Y,$)|0,r=r+Math.imul(Y,AA)|0,i=i+Math.imul(k,tA)|0,g=(g=g+Math.imul(k,iA)|0)+Math.imul(F,tA)|0,r=r+Math.imul(F,iA)|0,i=i+Math.imul(M,rA)|0,g=(g=g+Math.imul(M,nA)|0)+Math.imul(m,rA)|0,r=r+Math.imul(m,nA)|0,i=i+Math.imul(D,IA)|0,g=(g=g+Math.imul(D,oA)|0)+Math.imul(b,IA)|0,r=r+Math.imul(b,oA)|0,i=i+Math.imul(l,QA)|0,g=(g=g+Math.imul(l,CA)|0)+Math.imul(w,QA)|0,r=r+Math.imul(w,CA)|0;var mA=(o+(i=i+Math.imul(E,cA)|0)|0)+((8191&(g=(g=g+Math.imul(E,hA)|0)+Math.imul(u,cA)|0))<<13)|0;o=((r=r+Math.imul(u,hA)|0)+(g>>>13)|0)+(mA>>>26)|0,mA&=67108863,i=Math.imul(H,z),g=(g=Math.imul(H,T))+Math.imul(R,z)|0,r=Math.imul(R,T),i=i+Math.imul(K,$)|0,g=(g=g+Math.imul(K,AA)|0)+Math.imul(U,$)|0,r=r+Math.imul(U,AA)|0,i=i+Math.imul(S,tA)|0,g=(g=g+Math.imul(S,iA)|0)+Math.imul(Y,tA)|0,r=r+Math.imul(Y,iA)|0,i=i+Math.imul(k,rA)|0,g=(g=g+Math.imul(k,nA)|0)+Math.imul(F,rA)|0,r=r+Math.imul(F,nA)|0,i=i+Math.imul(M,IA)|0,g=(g=g+Math.imul(M,oA)|0)+Math.imul(m,IA)|0,r=r+Math.imul(m,oA)|0,i=i+Math.imul(D,QA)|0,g=(g=g+Math.imul(D,CA)|0)+Math.imul(b,QA)|0,r=r+Math.imul(b,CA)|0;var GA=(o+(i=i+Math.imul(l,cA)|0)|0)+((8191&(g=(g=g+Math.imul(l,hA)|0)+Math.imul(w,cA)|0))<<13)|0;o=((r=r+Math.imul(w,hA)|0)+(g>>>13)|0)+(GA>>>26)|0,GA&=67108863,i=Math.imul(H,$),g=(g=Math.imul(H,AA))+Math.imul(R,$)|0,r=Math.imul(R,AA),i=i+Math.imul(K,tA)|0,g=(g=g+Math.imul(K,iA)|0)+Math.imul(U,tA)|0,r=r+Math.imul(U,iA)|0,i=i+Math.imul(S,rA)|0,g=(g=g+Math.imul(S,nA)|0)+Math.imul(Y,rA)|0,r=r+Math.imul(Y,nA)|0,i=i+Math.imul(k,IA)|0,g=(g=g+Math.imul(k,oA)|0)+Math.imul(F,IA)|0,r=r+Math.imul(F,oA)|0,i=i+Math.imul(M,QA)|0,g=(g=g+Math.imul(M,CA)|0)+Math.imul(m,QA)|0,r=r+Math.imul(m,CA)|0;var kA=(o+(i=i+Math.imul(D,cA)|0)|0)+((8191&(g=(g=g+Math.imul(D,hA)|0)+Math.imul(b,cA)|0))<<13)|0;o=((r=r+Math.imul(b,hA)|0)+(g>>>13)|0)+(kA>>>26)|0,kA&=67108863,i=Math.imul(H,tA),g=(g=Math.imul(H,iA))+Math.imul(R,tA)|0,r=Math.imul(R,iA),i=i+Math.imul(K,rA)|0,g=(g=g+Math.imul(K,nA)|0)+Math.imul(U,rA)|0,r=r+Math.imul(U,nA)|0,i=i+Math.imul(S,IA)|0,g=(g=g+Math.imul(S,oA)|0)+Math.imul(Y,IA)|0,r=r+Math.imul(Y,oA)|0,i=i+Math.imul(k,QA)|0,g=(g=g+Math.imul(k,CA)|0)+Math.imul(F,QA)|0,r=r+Math.imul(F,CA)|0;var FA=(o+(i=i+Math.imul(M,cA)|0)|0)+((8191&(g=(g=g+Math.imul(M,hA)|0)+Math.imul(m,cA)|0))<<13)|0;o=((r=r+Math.imul(m,hA)|0)+(g>>>13)|0)+(FA>>>26)|0,FA&=67108863,i=Math.imul(H,rA),g=(g=Math.imul(H,nA))+Math.imul(R,rA)|0,r=Math.imul(R,nA),i=i+Math.imul(K,IA)|0,g=(g=g+Math.imul(K,oA)|0)+Math.imul(U,IA)|0,r=r+Math.imul(U,oA)|0,i=i+Math.imul(S,QA)|0,g=(g=g+Math.imul(S,CA)|0)+Math.imul(Y,QA)|0,r=r+Math.imul(Y,CA)|0;var NA=(o+(i=i+Math.imul(k,cA)|0)|0)+((8191&(g=(g=g+Math.imul(k,hA)|0)+Math.imul(F,cA)|0))<<13)|0;o=((r=r+Math.imul(F,hA)|0)+(g>>>13)|0)+(NA>>>26)|0,NA&=67108863,i=Math.imul(H,IA),g=(g=Math.imul(H,oA))+Math.imul(R,IA)|0,r=Math.imul(R,oA),i=i+Math.imul(K,QA)|0,g=(g=g+Math.imul(K,CA)|0)+Math.imul(U,QA)|0,r=r+Math.imul(U,CA)|0;var SA=(o+(i=i+Math.imul(S,cA)|0)|0)+((8191&(g=(g=g+Math.imul(S,hA)|0)+Math.imul(Y,cA)|0))<<13)|0;o=((r=r+Math.imul(Y,hA)|0)+(g>>>13)|0)+(SA>>>26)|0,SA&=67108863,i=Math.imul(H,QA),g=(g=Math.imul(H,CA))+Math.imul(R,QA)|0,r=Math.imul(R,CA);var YA=(o+(i=i+Math.imul(K,cA)|0)|0)+((8191&(g=(g=g+Math.imul(K,hA)|0)+Math.imul(U,cA)|0))<<13)|0;o=((r=r+Math.imul(U,hA)|0)+(g>>>13)|0)+(YA>>>26)|0,YA&=67108863;var vA=(o+(i=Math.imul(H,cA))|0)+((8191&(g=(g=Math.imul(H,hA))+Math.imul(R,cA)|0))<<13)|0;return o=((r=Math.imul(R,hA))+(g>>>13)|0)+(vA>>>26)|0,vA&=67108863,I[0]=fA,I[1]=EA,I[2]=uA,I[3]=dA,I[4]=lA,I[5]=wA,I[6]=pA,I[7]=DA,I[8]=bA,I[9]=yA,I[10]=MA,I[11]=mA,I[12]=GA,I[13]=kA,I[14]=FA,I[15]=NA,I[16]=SA,I[17]=YA,I[18]=vA,0!==o&&(I[19]=o,t.length++),t};function c(A,e,t){return(new h).mulp(A,e,t)}function h(A,e){this.x=A,this.y=e}Math.imul||(s=C),r.prototype.mulTo=function(A,e){var t=this.length+A.length;return 10===this.length&&10===A.length?s(this,A,e):t<63?C(this,A,e):t<1024?function(A,e,t){t.negative=e.negative^A.negative,t.length=A.length+e.length;for(var i=0,g=0,r=0;r>>26)|0)>>>26,n&=67108863}t.words[r]=B,i=n,n=g}return 0!==i?t.words[r]=i:t.length--,t.strip()}(this,A,e):c(this,A,e)},h.prototype.makeRBT=function(A){for(var e=new Array(A),t=r.prototype._countBits(A)-1,i=0;i>=1;return i},h.prototype.permute=function(A,e,t,i,g,r){for(var n=0;n>>=1)g++;return 1<>>=13,t[2*n+1]=8191&r,r>>>=13;for(n=2*e;n>=26,e+=g/67108864|0,e+=r>>>26,this.words[t]=67108863&r}return 0!==e&&(this.words[t]=e,this.length++),this},r.prototype.muln=function(A){return this.clone().imuln(A)},r.prototype.sqr=function(){return this.mul(this)},r.prototype.isqr=function(){return this.imul(this.clone())},r.prototype.pow=function(A){var e=function(A){for(var e=new Array(A.bitLength()),t=0;t>>g}return e}(A);if(0===e.length)return new r(1);for(var t=this,i=0;i=0);var e,t=A%26,g=(A-t)/26,r=67108863>>>26-t<<26-t;if(0!==t){var n=0;for(e=0;e>>26-t}n&&(this.words[e]=n,this.length++)}if(0!==g){for(e=this.length-1;e>=0;e--)this.words[e+g]=this.words[e];for(e=0;e=0),g=e?(e-e%26)/26:0;var r=A%26,n=Math.min((A-r)/26,this.length),B=67108863^67108863>>>r<n)for(this.length-=n,o=0;o=0&&(0!==a||o>=g);o--){var Q=0|this.words[o];this.words[o]=a<<26-r|Q>>>r,a=Q&B}return I&&0!==a&&(I.words[I.length++]=a),0===this.length&&(this.words[0]=0,this.length=1),this.strip()},r.prototype.ishrn=function(A,e,t){return i(0===this.negative),this.iushrn(A,e,t)},r.prototype.shln=function(A){return this.clone().ishln(A)},r.prototype.ushln=function(A){return this.clone().iushln(A)},r.prototype.shrn=function(A){return this.clone().ishrn(A)},r.prototype.ushrn=function(A){return this.clone().iushrn(A)},r.prototype.testn=function(A){i("number"==typeof A&&A>=0);var e=A%26,t=(A-e)/26,g=1<=0);var e=A%26,t=(A-e)/26;if(i(0===this.negative,"imaskn works only with positive numbers"),this.length<=t)return this;if(0!==e&&t++,this.length=Math.min(t,this.length),0!==e){var g=67108863^67108863>>>e<=67108864;e++)this.words[e]-=67108864,e===this.length-1?this.words[e+1]=1:this.words[e+1]++;return this.length=Math.max(this.length,e+1),this},r.prototype.isubn=function(A){if(i("number"==typeof A),i(A<67108864),A<0)return this.iaddn(-A);if(0!==this.negative)return this.negative=0,this.iaddn(A),this.negative=1,this;if(this.words[0]-=A,1===this.length&&this.words[0]<0)this.words[0]=-this.words[0],this.negative=1;else for(var e=0;e>26)-(I/67108864|0),this.words[g+t]=67108863&r}for(;g>26,this.words[g+t]=67108863&r;if(0===B)return this.strip();for(i(-1===B),B=0,g=0;g>26,this.words[g]=67108863&r;return this.negative=1,this.strip()},r.prototype._wordDiv=function(A,e){var t=(this.length,A.length),i=this.clone(),g=A,n=0|g.words[g.length-1];0!==(t=26-this._countBits(n))&&(g=g.ushln(t),i.iushln(t),n=0|g.words[g.length-1]);var B,I=i.length-g.length;if("mod"!==e){(B=new r(null)).length=I+1,B.words=new Array(B.length);for(var o=0;o=0;Q--){var C=67108864*(0|i.words[g.length+Q])+(0|i.words[g.length+Q-1]);for(C=Math.min(C/n|0,67108863),i._ishlnsubmul(g,C,Q);0!==i.negative;)C--,i.negative=0,i._ishlnsubmul(g,1,Q),i.isZero()||(i.negative^=1);B&&(B.words[Q]=C)}return B&&B.strip(),i.strip(),"div"!==e&&0!==t&&i.iushrn(t),{div:B||null,mod:i}},r.prototype.divmod=function(A,e,t){return i(!A.isZero()),this.isZero()?{div:new r(0),mod:new r(0)}:0!==this.negative&&0===A.negative?(B=this.neg().divmod(A,e),"mod"!==e&&(g=B.div.neg()),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.iadd(A)),{div:g,mod:n}):0===this.negative&&0!==A.negative?(B=this.divmod(A.neg(),e),"mod"!==e&&(g=B.div.neg()),{div:g,mod:B.mod}):0!=(this.negative&A.negative)?(B=this.neg().divmod(A.neg(),e),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.isub(A)),{div:B.div,mod:n}):A.length>this.length||this.cmp(A)<0?{div:new r(0),mod:this}:1===A.length?"div"===e?{div:this.divn(A.words[0]),mod:null}:"mod"===e?{div:null,mod:new r(this.modn(A.words[0]))}:{div:this.divn(A.words[0]),mod:new r(this.modn(A.words[0]))}:this._wordDiv(A,e);var g,n,B},r.prototype.div=function(A){return this.divmod(A,"div",!1).div},r.prototype.mod=function(A){return this.divmod(A,"mod",!1).mod},r.prototype.umod=function(A){return this.divmod(A,"mod",!0).mod},r.prototype.divRound=function(A){var e=this.divmod(A);if(e.mod.isZero())return e.div;var t=0!==e.div.negative?e.mod.isub(A):e.mod,i=A.ushrn(1),g=A.andln(1),r=t.cmp(i);return r<0||1===g&&0===r?e.div:0!==e.div.negative?e.div.isubn(1):e.div.iaddn(1)},r.prototype.modn=function(A){i(A<=67108863);for(var e=(1<<26)%A,t=0,g=this.length-1;g>=0;g--)t=(e*t+(0|this.words[g]))%A;return t},r.prototype.idivn=function(A){i(A<=67108863);for(var e=0,t=this.length-1;t>=0;t--){var g=(0|this.words[t])+67108864*e;this.words[t]=g/A|0,e=g%A}return this.strip()},r.prototype.divn=function(A){return this.clone().idivn(A)},r.prototype.egcd=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g=new r(1),n=new r(0),B=new r(0),I=new r(1),o=0;e.isEven()&&t.isEven();)e.iushrn(1),t.iushrn(1),++o;for(var a=t.clone(),Q=e.clone();!e.isZero();){for(var C=0,s=1;0==(e.words[0]&s)&&C<26;++C,s<<=1);if(C>0)for(e.iushrn(C);C-- >0;)(g.isOdd()||n.isOdd())&&(g.iadd(a),n.isub(Q)),g.iushrn(1),n.iushrn(1);for(var c=0,h=1;0==(t.words[0]&h)&&c<26;++c,h<<=1);if(c>0)for(t.iushrn(c);c-- >0;)(B.isOdd()||I.isOdd())&&(B.iadd(a),I.isub(Q)),B.iushrn(1),I.iushrn(1);e.cmp(t)>=0?(e.isub(t),g.isub(B),n.isub(I)):(t.isub(e),B.isub(g),I.isub(n))}return{a:B,b:I,gcd:t.iushln(o)}},r.prototype._invmp=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g,n=new r(1),B=new r(0),I=t.clone();e.cmpn(1)>0&&t.cmpn(1)>0;){for(var o=0,a=1;0==(e.words[0]&a)&&o<26;++o,a<<=1);if(o>0)for(e.iushrn(o);o-- >0;)n.isOdd()&&n.iadd(I),n.iushrn(1);for(var Q=0,C=1;0==(t.words[0]&C)&&Q<26;++Q,C<<=1);if(Q>0)for(t.iushrn(Q);Q-- >0;)B.isOdd()&&B.iadd(I),B.iushrn(1);e.cmp(t)>=0?(e.isub(t),n.isub(B)):(t.isub(e),B.isub(n))}return(g=0===e.cmpn(1)?n:B).cmpn(0)<0&&g.iadd(A),g},r.prototype.gcd=function(A){if(this.isZero())return A.abs();if(A.isZero())return this.abs();var e=this.clone(),t=A.clone();e.negative=0,t.negative=0;for(var i=0;e.isEven()&&t.isEven();i++)e.iushrn(1),t.iushrn(1);for(;;){for(;e.isEven();)e.iushrn(1);for(;t.isEven();)t.iushrn(1);var g=e.cmp(t);if(g<0){var r=e;e=t,t=r}else if(0===g||0===t.cmpn(1))break;e.isub(t)}return t.iushln(i)},r.prototype.invm=function(A){return this.egcd(A).a.umod(A)},r.prototype.isEven=function(){return 0==(1&this.words[0])},r.prototype.isOdd=function(){return 1==(1&this.words[0])},r.prototype.andln=function(A){return this.words[0]&A},r.prototype.bincn=function(A){i("number"==typeof A);var e=A%26,t=(A-e)/26,g=1<>>26,B&=67108863,this.words[n]=B}return 0!==r&&(this.words[n]=r,this.length++),this},r.prototype.isZero=function(){return 1===this.length&&0===this.words[0]},r.prototype.cmpn=function(A){var e,t=A<0;if(0!==this.negative&&!t)return-1;if(0===this.negative&&t)return 1;if(this.strip(),this.length>1)e=1;else{t&&(A=-A),i(A<=67108863,"Number is too big");var g=0|this.words[0];e=g===A?0:gA.length)return 1;if(this.length=0;t--){var i=0|this.words[t],g=0|A.words[t];if(i!==g){ig&&(e=1);break}}return e},r.prototype.gtn=function(A){return 1===this.cmpn(A)},r.prototype.gt=function(A){return 1===this.cmp(A)},r.prototype.gten=function(A){return this.cmpn(A)>=0},r.prototype.gte=function(A){return this.cmp(A)>=0},r.prototype.ltn=function(A){return-1===this.cmpn(A)},r.prototype.lt=function(A){return-1===this.cmp(A)},r.prototype.lten=function(A){return this.cmpn(A)<=0},r.prototype.lte=function(A){return this.cmp(A)<=0},r.prototype.eqn=function(A){return 0===this.cmpn(A)},r.prototype.eq=function(A){return 0===this.cmp(A)},r.red=function(A){return new p(A)},r.prototype.toRed=function(A){return i(!this.red,"Already a number in reduction context"),i(0===this.negative,"red works only with positives"),A.convertTo(this)._forceRed(A)},r.prototype.fromRed=function(){return i(this.red,"fromRed works only with numbers in reduction context"),this.red.convertFrom(this)},r.prototype._forceRed=function(A){return this.red=A,this},r.prototype.forceRed=function(A){return i(!this.red,"Already a number in reduction context"),this._forceRed(A)},r.prototype.redAdd=function(A){return i(this.red,"redAdd works only with red numbers"),this.red.add(this,A)},r.prototype.redIAdd=function(A){return i(this.red,"redIAdd works only with red numbers"),this.red.iadd(this,A)},r.prototype.redSub=function(A){return i(this.red,"redSub works only with red numbers"),this.red.sub(this,A)},r.prototype.redISub=function(A){return i(this.red,"redISub works only with red numbers"),this.red.isub(this,A)},r.prototype.redShl=function(A){return i(this.red,"redShl works only with red numbers"),this.red.shl(this,A)},r.prototype.redMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.mul(this,A)},r.prototype.redIMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.imul(this,A)},r.prototype.redSqr=function(){return i(this.red,"redSqr works only with red numbers"),this.red._verify1(this),this.red.sqr(this)},r.prototype.redISqr=function(){return i(this.red,"redISqr works only with red numbers"),this.red._verify1(this),this.red.isqr(this)},r.prototype.redSqrt=function(){return i(this.red,"redSqrt works only with red numbers"),this.red._verify1(this),this.red.sqrt(this)},r.prototype.redInvm=function(){return i(this.red,"redInvm works only with red numbers"),this.red._verify1(this),this.red.invm(this)},r.prototype.redNeg=function(){return i(this.red,"redNeg works only with red numbers"),this.red._verify1(this),this.red.neg(this)},r.prototype.redPow=function(A){return i(this.red&&!A.red,"redPow(normalNum)"),this.red._verify1(this),this.red.pow(this,A)};var f={k256:null,p224:null,p192:null,p25519:null};function E(A,e){this.name=A,this.p=new r(e,16),this.n=this.p.bitLength(),this.k=new r(1).iushln(this.n).isub(this.p),this.tmp=this._tmp()}function u(){E.call(this,"k256","ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f")}function d(){E.call(this,"p224","ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001")}function l(){E.call(this,"p192","ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff")}function w(){E.call(this,"25519","7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed")}function p(A){if("string"==typeof A){var e=r._prime(A);this.m=e.p,this.prime=e}else i(A.gtn(1),"modulus must be greater than 1"),this.m=A,this.prime=null}function D(A){p.call(this,A),this.shift=this.m.bitLength(),this.shift%26!=0&&(this.shift+=26-this.shift%26),this.r=new r(1).iushln(this.shift),this.r2=this.imod(this.r.sqr()),this.rinv=this.r._invmp(this.m),this.minv=this.rinv.mul(this.r).isubn(1).div(this.m),this.minv=this.minv.umod(this.r),this.minv=this.r.sub(this.minv)}E.prototype._tmp=function(){var A=new r(null);return A.words=new Array(Math.ceil(this.n/13)),A},E.prototype.ireduce=function(A){var e,t=A;do{this.split(t,this.tmp),e=(t=(t=this.imulK(t)).iadd(this.tmp)).bitLength()}while(e>this.n);var i=e0?t.isub(this.p):void 0!==t.strip?t.strip():t._strip(),t},E.prototype.split=function(A,e){A.iushrn(this.n,0,e)},E.prototype.imulK=function(A){return A.imul(this.k)},g(u,E),u.prototype.split=function(A,e){for(var t=Math.min(A.length,9),i=0;i>>22,g=r}g>>>=22,A.words[i-10]=g,0===g&&A.length>10?A.length-=10:A.length-=9},u.prototype.imulK=function(A){A.words[A.length]=0,A.words[A.length+1]=0,A.length+=2;for(var e=0,t=0;t>>=26,A.words[t]=g,e=i}return 0!==e&&(A.words[A.length++]=e),A},r._prime=function(A){if(f[A])return f[A];var e;if("k256"===A)e=new u;else if("p224"===A)e=new d;else if("p192"===A)e=new l;else{if("p25519"!==A)throw new Error("Unknown prime "+A);e=new w}return f[A]=e,e},p.prototype._verify1=function(A){i(0===A.negative,"red works only with positives"),i(A.red,"red works only with red numbers")},p.prototype._verify2=function(A,e){i(0==(A.negative|e.negative),"red works only with positives"),i(A.red&&A.red===e.red,"red works only with red numbers")},p.prototype.imod=function(A){return this.prime?this.prime.ireduce(A)._forceRed(this):A.umod(this.m)._forceRed(this)},p.prototype.neg=function(A){return A.isZero()?A.clone():this.m.sub(A)._forceRed(this)},p.prototype.add=function(A,e){this._verify2(A,e);var t=A.add(e);return t.cmp(this.m)>=0&&t.isub(this.m),t._forceRed(this)},p.prototype.iadd=function(A,e){this._verify2(A,e);var t=A.iadd(e);return t.cmp(this.m)>=0&&t.isub(this.m),t},p.prototype.sub=function(A,e){this._verify2(A,e);var t=A.sub(e);return t.cmpn(0)<0&&t.iadd(this.m),t._forceRed(this)},p.prototype.isub=function(A,e){this._verify2(A,e);var t=A.isub(e);return t.cmpn(0)<0&&t.iadd(this.m),t},p.prototype.shl=function(A,e){return this._verify1(A),this.imod(A.ushln(e))},p.prototype.imul=function(A,e){return this._verify2(A,e),this.imod(A.imul(e))},p.prototype.mul=function(A,e){return this._verify2(A,e),this.imod(A.mul(e))},p.prototype.isqr=function(A){return this.imul(A,A.clone())},p.prototype.sqr=function(A){return this.mul(A,A)},p.prototype.sqrt=function(A){if(A.isZero())return A.clone();var e=this.m.andln(3);if(i(e%2==1),3===e){var t=this.m.add(new r(1)).iushrn(2);return this.pow(A,t)}for(var g=this.m.subn(1),n=0;!g.isZero()&&0===g.andln(1);)n++,g.iushrn(1);i(!g.isZero());var B=new r(1).toRed(this),I=B.redNeg(),o=this.m.subn(1).iushrn(1),a=this.m.bitLength();for(a=new r(2*a*a).toRed(this);0!==this.pow(a,o).cmp(I);)a.redIAdd(I);for(var Q=this.pow(a,g),C=this.pow(A,g.addn(1).iushrn(1)),s=this.pow(A,g),c=n;0!==s.cmp(B);){for(var h=s,f=0;0!==h.cmp(B);f++)h=h.redSqr();i(f=0;i--){for(var o=e.words[i],a=I-1;a>=0;a--){var Q=o>>a&1;g!==t[0]&&(g=this.sqr(g)),0!==Q||0!==n?(n<<=1,n|=Q,(4===++B||0===i&&0===a)&&(g=this.mul(g,t[n]),B=0,n=0)):B=0}I=26}return g},p.prototype.convertTo=function(A){var e=A.umod(this.m);return e===A?e.clone():e},p.prototype.convertFrom=function(A){var e=A.clone();return e.red=null,e},r.mont=function(A){return new D(A)},g(D,p),D.prototype.convertTo=function(A){return this.imod(A.ushln(this.shift))},D.prototype.convertFrom=function(A){var e=this.imod(A.mul(this.rinv));return e.red=null,e},D.prototype.imul=function(A,e){if(A.isZero()||e.isZero())return A.words[0]=0,A.length=1,A;var t=A.imul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),r=g;return g.cmp(this.m)>=0?r=g.isub(this.m):g.cmpn(0)<0&&(r=g.iadd(this.m)),r._forceRed(this)},D.prototype.mul=function(A,e){if(A.isZero()||e.isZero())return new r(0)._forceRed(this);var t=A.mul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),n=g;return g.cmp(this.m)>=0?n=g.isub(this.m):g.cmpn(0)<0&&(n=g.iadd(this.m)),n._forceRed(this)},D.prototype.invm=function(A){return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this)}}(void 0===e||e,this)},{buffer:19}],16:[function(A,e,t){"use strict";t.byteLength=function(A){var e=o(A),t=e[0],i=e[1];return 3*(t+i)/4-i},t.toByteArray=function(A){var e,t,i=o(A),n=i[0],B=i[1],I=new r(function(A,e,t){return 3*(e+t)/4-t}(0,n,B)),a=0,Q=B>0?n-4:n;for(t=0;t>16&255,I[a++]=e>>8&255,I[a++]=255&e;2===B&&(e=g[A.charCodeAt(t)]<<2|g[A.charCodeAt(t+1)]>>4,I[a++]=255&e);1===B&&(e=g[A.charCodeAt(t)]<<10|g[A.charCodeAt(t+1)]<<4|g[A.charCodeAt(t+2)]>>2,I[a++]=e>>8&255,I[a++]=255&e);return I},t.fromByteArray=function(A){for(var e,t=A.length,g=t%3,r=[],n=0,B=t-g;nB?B:n+16383));1===g?(e=A[t-1],r.push(i[e>>2]+i[e<<4&63]+"==")):2===g&&(e=(A[t-2]<<8)+A[t-1],r.push(i[e>>10]+i[e>>4&63]+i[e<<2&63]+"="));return r.join("")};for(var i=[],g=[],r="undefined"!=typeof Uint8Array?Uint8Array:Array,n="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/",B=0,I=n.length;B0)throw new Error("Invalid string. Length must be a multiple of 4");var t=A.indexOf("=");return-1===t&&(t=e),[t,t===e?0:4-t%4]}function a(A,e,t){for(var g,r,n=[],B=e;B>18&63]+i[r>>12&63]+i[r>>6&63]+i[63&r]);return n.join("")}g["-".charCodeAt(0)]=62,g["_".charCodeAt(0)]=63},{}],17:[function(A,e,t){!function(e,t){"use strict";function i(A,e){if(!A)throw new Error(e||"Assertion failed")}function g(A,e){A.super_=e;var t=function(){};t.prototype=e.prototype,A.prototype=new t,A.prototype.constructor=A}function r(A,e,t){if(r.isBN(A))return A;this.negative=0,this.words=null,this.length=0,this.red=null,null!==A&&("le"!==e&&"be"!==e||(t=e,e=10),this._init(A||0,e||10,t||"be"))}var n;"object"==typeof e?e.exports=r:t.BN=r,r.BN=r,r.wordSize=26;try{n=A("buffer").Buffer}catch(A){}function B(A,e,t){for(var g=0,r=Math.min(A.length,t),n=0,B=e;B=49&&o<=54?o-49+10:o>=17&&o<=22?o-17+10:o,n|=I}return i(!(240&n),"Invalid character in "+A),g}function I(A,e,t,g){for(var r=0,n=0,B=Math.min(A.length,t),I=e;I=49?o-49+10:o>=17?o-17+10:o,i(o>=0&&n0?A:e},r.min=function(A,e){return A.cmp(e)<0?A:e},r.prototype._init=function(A,e,t){if("number"==typeof A)return this._initNumber(A,e,t);if("object"==typeof A)return this._initArray(A,e,t);"hex"===e&&(e=16),i(e===(0|e)&&e>=2&&e<=36);var g=0;"-"===(A=A.toString().replace(/\s+/g,""))[0]&&g++,16===e?this._parseHex(A,g):this._parseBase(A,e,g),"-"===A[0]&&(this.negative=1),this._strip(),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initNumber=function(A,e,t){A<0&&(this.negative=1,A=-A),A<67108864?(this.words=[67108863&A],this.length=1):A<4503599627370496?(this.words=[67108863&A,A/67108864&67108863],this.length=2):(i(A<9007199254740992),this.words=[67108863&A,A/67108864&67108863,1],this.length=3),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initArray=function(A,e,t){if(i("number"==typeof A.length),A.length<=0)return this.words=[0],this.length=1,this;this.length=Math.ceil(A.length/3),this.words=new Array(this.length);for(var g=0;g=0;g-=3)n=A[g]|A[g-1]<<8|A[g-2]<<16,this.words[r]|=n<>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);else if("le"===t)for(g=0,r=0;g>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);return this._strip()},r.prototype._parseHex=function(A,e){this.length=Math.ceil((A.length-e)/6),this.words=new Array(this.length);for(var t=0;t=e;t-=6)g=B(A,t,t+6),this.words[i]|=g<>>26-r&4194303,(r+=24)>=26&&(r-=26,i++);t+6!==e&&(g=B(A,e,t+6),this.words[i]|=g<>>26-r&4194303),this._strip()},r.prototype._parseBase=function(A,e,t){this.words=[0],this.length=1;for(var i=0,g=1;g<=67108863;g*=e)i++;i--,g=g/e|0;for(var r=A.length-t,n=r%i,B=Math.min(r,r-n)+t,o=0,a=t;a1&&0===this.words[this.length-1];)this.length--;return this._normSign()},r.prototype._normSign=function(){return 1===this.length&&0===this.words[0]&&(this.negative=0),this},"undefined"!=typeof Symbol&&"function"==typeof Symbol.for)try{r.prototype[Symbol.for("nodejs.util.inspect.custom")]=a}catch(A){r.prototype.inspect=a}else r.prototype.inspect=a;function a(){return(this.red?""}var Q=["","0","00","000","0000","00000","000000","0000000","00000000","000000000","0000000000","00000000000","000000000000","0000000000000","00000000000000","000000000000000","0000000000000000","00000000000000000","000000000000000000","0000000000000000000","00000000000000000000","000000000000000000000","0000000000000000000000","00000000000000000000000","000000000000000000000000","0000000000000000000000000"],C=[0,0,25,16,12,11,10,9,8,8,7,7,7,7,6,6,6,6,6,6,6,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5],s=[0,0,33554432,43046721,16777216,48828125,60466176,40353607,16777216,43046721,1e7,19487171,35831808,62748517,7529536,11390625,16777216,24137569,34012224,47045881,64e6,4084101,5153632,6436343,7962624,9765625,11881376,14348907,17210368,20511149,243e5,28629151,33554432,39135393,45435424,52521875,60466176];r.prototype.toString=function(A,e){var t;if(A=A||10,e=0|e||1,16===A||"hex"===A){t="";for(var g=0,r=0,n=0;n>>24-g&16777215)||n!==this.length-1?Q[6-I.length]+I+t:I+t,(g+=2)>=26&&(g-=26,n--)}for(0!==r&&(t=r.toString(16)+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}if(A===(0|A)&&A>=2&&A<=36){var o=C[A],a=s[A];t="";var c=this.clone();for(c.negative=0;!c.isZero();){var h=c.modrn(a).toString(A);t=(c=c.idivn(a)).isZero()?h+t:Q[o-h.length]+h+t}for(this.isZero()&&(t="0"+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}i(!1,"Base should be between 2 and 36")},r.prototype.toNumber=function(){var A=this.words[0];return 2===this.length?A+=67108864*this.words[1]:3===this.length&&1===this.words[2]?A+=4503599627370496+67108864*this.words[1]:this.length>2&&i(!1,"Number can only safely store up to 53 bits"),0!==this.negative?-A:A},r.prototype.toJSON=function(){return this.toString(16,2)},n&&(r.prototype.toBuffer=function(A,e){return this.toArrayLike(n,A,e)}),r.prototype.toArray=function(A,e){return this.toArrayLike(Array,A,e)};function c(A,e,t){t.negative=e.negative^A.negative;var i=A.length+e.length|0;t.length=i,i=i-1|0;var g=0|A.words[0],r=0|e.words[0],n=g*r,B=67108863&n,I=n/67108864|0;t.words[0]=B;for(var o=1;o>>26,Q=67108863&I,C=Math.min(o,e.length-1),s=Math.max(0,o-A.length+1);s<=C;s++){var c=o-s|0;a+=(n=(g=0|A.words[c])*(r=0|e.words[s])+Q)/67108864|0,Q=67108863&n}t.words[o]=0|Q,I=0|a}return 0!==I?t.words[o]=0|I:t.length--,t._strip()}r.prototype.toArrayLike=function(A,e,t){this._strip();var g=this.byteLength(),r=t||Math.max(1,g);i(g<=r,"byte array longer than desired length"),i(r>0,"Requested array length <= 0");var n=function(A,e){return A.allocUnsafe?A.allocUnsafe(e):new A(e)}(A,r);return this["_toArrayLike"+("le"===e?"LE":"BE")](n,g),n},r.prototype._toArrayLikeLE=function(A,e){for(var t=0,i=0,g=0,r=0;g>8&255),t>16&255),6===r?(t>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t=0&&(A[t--]=n>>8&255),t>=0&&(A[t--]=n>>16&255),6===r?(t>=0&&(A[t--]=n>>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t>=0)for(A[t--]=i;t>=0;)A[t--]=0},Math.clz32?r.prototype._countBits=function(A){return 32-Math.clz32(A)}:r.prototype._countBits=function(A){var e=A,t=0;return e>=4096&&(t+=13,e>>>=13),e>=64&&(t+=7,e>>>=7),e>=8&&(t+=4,e>>>=4),e>=2&&(t+=2,e>>>=2),t+e},r.prototype._zeroBits=function(A){if(0===A)return 26;var e=A,t=0;return 0==(8191&e)&&(t+=13,e>>>=13),0==(127&e)&&(t+=7,e>>>=7),0==(15&e)&&(t+=4,e>>>=4),0==(3&e)&&(t+=2,e>>>=2),0==(1&e)&&t++,t},r.prototype.bitLength=function(){var A=this.words[this.length-1],e=this._countBits(A);return 26*(this.length-1)+e},r.prototype.zeroBits=function(){if(this.isZero())return 0;for(var A=0,e=0;eA.length?this.clone().ior(A):A.clone().ior(this)},r.prototype.uor=function(A){return this.length>A.length?this.clone().iuor(A):A.clone().iuor(this)},r.prototype.iuand=function(A){var e;e=this.length>A.length?A:this;for(var t=0;tA.length?this.clone().iand(A):A.clone().iand(this)},r.prototype.uand=function(A){return this.length>A.length?this.clone().iuand(A):A.clone().iuand(this)},r.prototype.iuxor=function(A){var e,t;this.length>A.length?(e=this,t=A):(e=A,t=this);for(var i=0;iA.length?this.clone().ixor(A):A.clone().ixor(this)},r.prototype.uxor=function(A){return this.length>A.length?this.clone().iuxor(A):A.clone().iuxor(this)},r.prototype.inotn=function(A){i("number"==typeof A&&A>=0);var e=0|Math.ceil(A/26),t=A%26;this._expand(e),t>0&&e--;for(var g=0;g0&&(this.words[g]=~this.words[g]&67108863>>26-t),this._strip()},r.prototype.notn=function(A){return this.clone().inotn(A)},r.prototype.setn=function(A,e){i("number"==typeof A&&A>=0);var t=A/26|0,g=A%26;return this._expand(t+1),this.words[t]=e?this.words[t]|1<A.length?(t=this,i=A):(t=A,i=this);for(var g=0,r=0;r>>26;for(;0!==g&&r>>26;if(this.length=t.length,0!==g)this.words[this.length]=g,this.length++;else if(t!==this)for(;rA.length?this.clone().iadd(A):A.clone().iadd(this)},r.prototype.isub=function(A){if(0!==A.negative){A.negative=0;var e=this.iadd(A);return A.negative=1,e._normSign()}if(0!==this.negative)return this.negative=0,this.iadd(A),this.negative=1,this._normSign();var t,i,g=this.cmp(A);if(0===g)return this.negative=0,this.length=1,this.words[0]=0,this;g>0?(t=this,i=A):(t=A,i=this);for(var r=0,n=0;n>26,this.words[n]=67108863&e;for(;0!==r&&n>26,this.words[n]=67108863&e;if(0===r&&n>>13,s=0|n[1],c=8191&s,h=s>>>13,f=0|n[2],E=8191&f,u=f>>>13,d=0|n[3],l=8191&d,w=d>>>13,p=0|n[4],D=8191&p,b=p>>>13,y=0|n[5],M=8191&y,m=y>>>13,G=0|n[6],k=8191&G,F=G>>>13,N=0|n[7],S=8191&N,Y=N>>>13,v=0|n[8],K=8191&v,U=v>>>13,J=0|n[9],H=8191&J,R=J>>>13,q=0|B[0],L=8191&q,x=q>>>13,Z=0|B[1],j=8191&Z,W=Z>>>13,O=0|B[2],P=8191&O,V=O>>>13,X=0|B[3],z=8191&X,T=X>>>13,_=0|B[4],$=8191&_,AA=_>>>13,eA=0|B[5],tA=8191&eA,iA=eA>>>13,gA=0|B[6],rA=8191&gA,nA=gA>>>13,BA=0|B[7],IA=8191&BA,oA=BA>>>13,aA=0|B[8],QA=8191&aA,CA=aA>>>13,sA=0|B[9],cA=8191&sA,hA=sA>>>13;t.negative=A.negative^e.negative,t.length=19;var fA=(o+(i=Math.imul(Q,L))|0)+((8191&(g=(g=Math.imul(Q,x))+Math.imul(C,L)|0))<<13)|0;o=((r=Math.imul(C,x))+(g>>>13)|0)+(fA>>>26)|0,fA&=67108863,i=Math.imul(c,L),g=(g=Math.imul(c,x))+Math.imul(h,L)|0,r=Math.imul(h,x);var EA=(o+(i=i+Math.imul(Q,j)|0)|0)+((8191&(g=(g=g+Math.imul(Q,W)|0)+Math.imul(C,j)|0))<<13)|0;o=((r=r+Math.imul(C,W)|0)+(g>>>13)|0)+(EA>>>26)|0,EA&=67108863,i=Math.imul(E,L),g=(g=Math.imul(E,x))+Math.imul(u,L)|0,r=Math.imul(u,x),i=i+Math.imul(c,j)|0,g=(g=g+Math.imul(c,W)|0)+Math.imul(h,j)|0,r=r+Math.imul(h,W)|0;var uA=(o+(i=i+Math.imul(Q,P)|0)|0)+((8191&(g=(g=g+Math.imul(Q,V)|0)+Math.imul(C,P)|0))<<13)|0;o=((r=r+Math.imul(C,V)|0)+(g>>>13)|0)+(uA>>>26)|0,uA&=67108863,i=Math.imul(l,L),g=(g=Math.imul(l,x))+Math.imul(w,L)|0,r=Math.imul(w,x),i=i+Math.imul(E,j)|0,g=(g=g+Math.imul(E,W)|0)+Math.imul(u,j)|0,r=r+Math.imul(u,W)|0,i=i+Math.imul(c,P)|0,g=(g=g+Math.imul(c,V)|0)+Math.imul(h,P)|0,r=r+Math.imul(h,V)|0;var dA=(o+(i=i+Math.imul(Q,z)|0)|0)+((8191&(g=(g=g+Math.imul(Q,T)|0)+Math.imul(C,z)|0))<<13)|0;o=((r=r+Math.imul(C,T)|0)+(g>>>13)|0)+(dA>>>26)|0,dA&=67108863,i=Math.imul(D,L),g=(g=Math.imul(D,x))+Math.imul(b,L)|0,r=Math.imul(b,x),i=i+Math.imul(l,j)|0,g=(g=g+Math.imul(l,W)|0)+Math.imul(w,j)|0,r=r+Math.imul(w,W)|0,i=i+Math.imul(E,P)|0,g=(g=g+Math.imul(E,V)|0)+Math.imul(u,P)|0,r=r+Math.imul(u,V)|0,i=i+Math.imul(c,z)|0,g=(g=g+Math.imul(c,T)|0)+Math.imul(h,z)|0,r=r+Math.imul(h,T)|0;var lA=(o+(i=i+Math.imul(Q,$)|0)|0)+((8191&(g=(g=g+Math.imul(Q,AA)|0)+Math.imul(C,$)|0))<<13)|0;o=((r=r+Math.imul(C,AA)|0)+(g>>>13)|0)+(lA>>>26)|0,lA&=67108863,i=Math.imul(M,L),g=(g=Math.imul(M,x))+Math.imul(m,L)|0,r=Math.imul(m,x),i=i+Math.imul(D,j)|0,g=(g=g+Math.imul(D,W)|0)+Math.imul(b,j)|0,r=r+Math.imul(b,W)|0,i=i+Math.imul(l,P)|0,g=(g=g+Math.imul(l,V)|0)+Math.imul(w,P)|0,r=r+Math.imul(w,V)|0,i=i+Math.imul(E,z)|0,g=(g=g+Math.imul(E,T)|0)+Math.imul(u,z)|0,r=r+Math.imul(u,T)|0,i=i+Math.imul(c,$)|0,g=(g=g+Math.imul(c,AA)|0)+Math.imul(h,$)|0,r=r+Math.imul(h,AA)|0;var wA=(o+(i=i+Math.imul(Q,tA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,iA)|0)+Math.imul(C,tA)|0))<<13)|0;o=((r=r+Math.imul(C,iA)|0)+(g>>>13)|0)+(wA>>>26)|0,wA&=67108863,i=Math.imul(k,L),g=(g=Math.imul(k,x))+Math.imul(F,L)|0,r=Math.imul(F,x),i=i+Math.imul(M,j)|0,g=(g=g+Math.imul(M,W)|0)+Math.imul(m,j)|0,r=r+Math.imul(m,W)|0,i=i+Math.imul(D,P)|0,g=(g=g+Math.imul(D,V)|0)+Math.imul(b,P)|0,r=r+Math.imul(b,V)|0,i=i+Math.imul(l,z)|0,g=(g=g+Math.imul(l,T)|0)+Math.imul(w,z)|0,r=r+Math.imul(w,T)|0,i=i+Math.imul(E,$)|0,g=(g=g+Math.imul(E,AA)|0)+Math.imul(u,$)|0,r=r+Math.imul(u,AA)|0,i=i+Math.imul(c,tA)|0,g=(g=g+Math.imul(c,iA)|0)+Math.imul(h,tA)|0,r=r+Math.imul(h,iA)|0;var pA=(o+(i=i+Math.imul(Q,rA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,nA)|0)+Math.imul(C,rA)|0))<<13)|0;o=((r=r+Math.imul(C,nA)|0)+(g>>>13)|0)+(pA>>>26)|0,pA&=67108863,i=Math.imul(S,L),g=(g=Math.imul(S,x))+Math.imul(Y,L)|0,r=Math.imul(Y,x),i=i+Math.imul(k,j)|0,g=(g=g+Math.imul(k,W)|0)+Math.imul(F,j)|0,r=r+Math.imul(F,W)|0,i=i+Math.imul(M,P)|0,g=(g=g+Math.imul(M,V)|0)+Math.imul(m,P)|0,r=r+Math.imul(m,V)|0,i=i+Math.imul(D,z)|0,g=(g=g+Math.imul(D,T)|0)+Math.imul(b,z)|0,r=r+Math.imul(b,T)|0,i=i+Math.imul(l,$)|0,g=(g=g+Math.imul(l,AA)|0)+Math.imul(w,$)|0,r=r+Math.imul(w,AA)|0,i=i+Math.imul(E,tA)|0,g=(g=g+Math.imul(E,iA)|0)+Math.imul(u,tA)|0,r=r+Math.imul(u,iA)|0,i=i+Math.imul(c,rA)|0,g=(g=g+Math.imul(c,nA)|0)+Math.imul(h,rA)|0,r=r+Math.imul(h,nA)|0;var DA=(o+(i=i+Math.imul(Q,IA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,oA)|0)+Math.imul(C,IA)|0))<<13)|0;o=((r=r+Math.imul(C,oA)|0)+(g>>>13)|0)+(DA>>>26)|0,DA&=67108863,i=Math.imul(K,L),g=(g=Math.imul(K,x))+Math.imul(U,L)|0,r=Math.imul(U,x),i=i+Math.imul(S,j)|0,g=(g=g+Math.imul(S,W)|0)+Math.imul(Y,j)|0,r=r+Math.imul(Y,W)|0,i=i+Math.imul(k,P)|0,g=(g=g+Math.imul(k,V)|0)+Math.imul(F,P)|0,r=r+Math.imul(F,V)|0,i=i+Math.imul(M,z)|0,g=(g=g+Math.imul(M,T)|0)+Math.imul(m,z)|0,r=r+Math.imul(m,T)|0,i=i+Math.imul(D,$)|0,g=(g=g+Math.imul(D,AA)|0)+Math.imul(b,$)|0,r=r+Math.imul(b,AA)|0,i=i+Math.imul(l,tA)|0,g=(g=g+Math.imul(l,iA)|0)+Math.imul(w,tA)|0,r=r+Math.imul(w,iA)|0,i=i+Math.imul(E,rA)|0,g=(g=g+Math.imul(E,nA)|0)+Math.imul(u,rA)|0,r=r+Math.imul(u,nA)|0,i=i+Math.imul(c,IA)|0,g=(g=g+Math.imul(c,oA)|0)+Math.imul(h,IA)|0,r=r+Math.imul(h,oA)|0;var bA=(o+(i=i+Math.imul(Q,QA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,CA)|0)+Math.imul(C,QA)|0))<<13)|0;o=((r=r+Math.imul(C,CA)|0)+(g>>>13)|0)+(bA>>>26)|0,bA&=67108863,i=Math.imul(H,L),g=(g=Math.imul(H,x))+Math.imul(R,L)|0,r=Math.imul(R,x),i=i+Math.imul(K,j)|0,g=(g=g+Math.imul(K,W)|0)+Math.imul(U,j)|0,r=r+Math.imul(U,W)|0,i=i+Math.imul(S,P)|0,g=(g=g+Math.imul(S,V)|0)+Math.imul(Y,P)|0,r=r+Math.imul(Y,V)|0,i=i+Math.imul(k,z)|0,g=(g=g+Math.imul(k,T)|0)+Math.imul(F,z)|0,r=r+Math.imul(F,T)|0,i=i+Math.imul(M,$)|0,g=(g=g+Math.imul(M,AA)|0)+Math.imul(m,$)|0,r=r+Math.imul(m,AA)|0,i=i+Math.imul(D,tA)|0,g=(g=g+Math.imul(D,iA)|0)+Math.imul(b,tA)|0,r=r+Math.imul(b,iA)|0,i=i+Math.imul(l,rA)|0,g=(g=g+Math.imul(l,nA)|0)+Math.imul(w,rA)|0,r=r+Math.imul(w,nA)|0,i=i+Math.imul(E,IA)|0,g=(g=g+Math.imul(E,oA)|0)+Math.imul(u,IA)|0,r=r+Math.imul(u,oA)|0,i=i+Math.imul(c,QA)|0,g=(g=g+Math.imul(c,CA)|0)+Math.imul(h,QA)|0,r=r+Math.imul(h,CA)|0;var yA=(o+(i=i+Math.imul(Q,cA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,hA)|0)+Math.imul(C,cA)|0))<<13)|0;o=((r=r+Math.imul(C,hA)|0)+(g>>>13)|0)+(yA>>>26)|0,yA&=67108863,i=Math.imul(H,j),g=(g=Math.imul(H,W))+Math.imul(R,j)|0,r=Math.imul(R,W),i=i+Math.imul(K,P)|0,g=(g=g+Math.imul(K,V)|0)+Math.imul(U,P)|0,r=r+Math.imul(U,V)|0,i=i+Math.imul(S,z)|0,g=(g=g+Math.imul(S,T)|0)+Math.imul(Y,z)|0,r=r+Math.imul(Y,T)|0,i=i+Math.imul(k,$)|0,g=(g=g+Math.imul(k,AA)|0)+Math.imul(F,$)|0,r=r+Math.imul(F,AA)|0,i=i+Math.imul(M,tA)|0,g=(g=g+Math.imul(M,iA)|0)+Math.imul(m,tA)|0,r=r+Math.imul(m,iA)|0,i=i+Math.imul(D,rA)|0,g=(g=g+Math.imul(D,nA)|0)+Math.imul(b,rA)|0,r=r+Math.imul(b,nA)|0,i=i+Math.imul(l,IA)|0,g=(g=g+Math.imul(l,oA)|0)+Math.imul(w,IA)|0,r=r+Math.imul(w,oA)|0,i=i+Math.imul(E,QA)|0,g=(g=g+Math.imul(E,CA)|0)+Math.imul(u,QA)|0,r=r+Math.imul(u,CA)|0;var MA=(o+(i=i+Math.imul(c,cA)|0)|0)+((8191&(g=(g=g+Math.imul(c,hA)|0)+Math.imul(h,cA)|0))<<13)|0;o=((r=r+Math.imul(h,hA)|0)+(g>>>13)|0)+(MA>>>26)|0,MA&=67108863,i=Math.imul(H,P),g=(g=Math.imul(H,V))+Math.imul(R,P)|0,r=Math.imul(R,V),i=i+Math.imul(K,z)|0,g=(g=g+Math.imul(K,T)|0)+Math.imul(U,z)|0,r=r+Math.imul(U,T)|0,i=i+Math.imul(S,$)|0,g=(g=g+Math.imul(S,AA)|0)+Math.imul(Y,$)|0,r=r+Math.imul(Y,AA)|0,i=i+Math.imul(k,tA)|0,g=(g=g+Math.imul(k,iA)|0)+Math.imul(F,tA)|0,r=r+Math.imul(F,iA)|0,i=i+Math.imul(M,rA)|0,g=(g=g+Math.imul(M,nA)|0)+Math.imul(m,rA)|0,r=r+Math.imul(m,nA)|0,i=i+Math.imul(D,IA)|0,g=(g=g+Math.imul(D,oA)|0)+Math.imul(b,IA)|0,r=r+Math.imul(b,oA)|0,i=i+Math.imul(l,QA)|0,g=(g=g+Math.imul(l,CA)|0)+Math.imul(w,QA)|0,r=r+Math.imul(w,CA)|0;var mA=(o+(i=i+Math.imul(E,cA)|0)|0)+((8191&(g=(g=g+Math.imul(E,hA)|0)+Math.imul(u,cA)|0))<<13)|0;o=((r=r+Math.imul(u,hA)|0)+(g>>>13)|0)+(mA>>>26)|0,mA&=67108863,i=Math.imul(H,z),g=(g=Math.imul(H,T))+Math.imul(R,z)|0,r=Math.imul(R,T),i=i+Math.imul(K,$)|0,g=(g=g+Math.imul(K,AA)|0)+Math.imul(U,$)|0,r=r+Math.imul(U,AA)|0,i=i+Math.imul(S,tA)|0,g=(g=g+Math.imul(S,iA)|0)+Math.imul(Y,tA)|0,r=r+Math.imul(Y,iA)|0,i=i+Math.imul(k,rA)|0,g=(g=g+Math.imul(k,nA)|0)+Math.imul(F,rA)|0,r=r+Math.imul(F,nA)|0,i=i+Math.imul(M,IA)|0,g=(g=g+Math.imul(M,oA)|0)+Math.imul(m,IA)|0,r=r+Math.imul(m,oA)|0,i=i+Math.imul(D,QA)|0,g=(g=g+Math.imul(D,CA)|0)+Math.imul(b,QA)|0,r=r+Math.imul(b,CA)|0;var GA=(o+(i=i+Math.imul(l,cA)|0)|0)+((8191&(g=(g=g+Math.imul(l,hA)|0)+Math.imul(w,cA)|0))<<13)|0;o=((r=r+Math.imul(w,hA)|0)+(g>>>13)|0)+(GA>>>26)|0,GA&=67108863,i=Math.imul(H,$),g=(g=Math.imul(H,AA))+Math.imul(R,$)|0,r=Math.imul(R,AA),i=i+Math.imul(K,tA)|0,g=(g=g+Math.imul(K,iA)|0)+Math.imul(U,tA)|0,r=r+Math.imul(U,iA)|0,i=i+Math.imul(S,rA)|0,g=(g=g+Math.imul(S,nA)|0)+Math.imul(Y,rA)|0,r=r+Math.imul(Y,nA)|0,i=i+Math.imul(k,IA)|0,g=(g=g+Math.imul(k,oA)|0)+Math.imul(F,IA)|0,r=r+Math.imul(F,oA)|0,i=i+Math.imul(M,QA)|0,g=(g=g+Math.imul(M,CA)|0)+Math.imul(m,QA)|0,r=r+Math.imul(m,CA)|0;var kA=(o+(i=i+Math.imul(D,cA)|0)|0)+((8191&(g=(g=g+Math.imul(D,hA)|0)+Math.imul(b,cA)|0))<<13)|0;o=((r=r+Math.imul(b,hA)|0)+(g>>>13)|0)+(kA>>>26)|0,kA&=67108863,i=Math.imul(H,tA),g=(g=Math.imul(H,iA))+Math.imul(R,tA)|0,r=Math.imul(R,iA),i=i+Math.imul(K,rA)|0,g=(g=g+Math.imul(K,nA)|0)+Math.imul(U,rA)|0,r=r+Math.imul(U,nA)|0,i=i+Math.imul(S,IA)|0,g=(g=g+Math.imul(S,oA)|0)+Math.imul(Y,IA)|0,r=r+Math.imul(Y,oA)|0,i=i+Math.imul(k,QA)|0,g=(g=g+Math.imul(k,CA)|0)+Math.imul(F,QA)|0,r=r+Math.imul(F,CA)|0;var FA=(o+(i=i+Math.imul(M,cA)|0)|0)+((8191&(g=(g=g+Math.imul(M,hA)|0)+Math.imul(m,cA)|0))<<13)|0;o=((r=r+Math.imul(m,hA)|0)+(g>>>13)|0)+(FA>>>26)|0,FA&=67108863,i=Math.imul(H,rA),g=(g=Math.imul(H,nA))+Math.imul(R,rA)|0,r=Math.imul(R,nA),i=i+Math.imul(K,IA)|0,g=(g=g+Math.imul(K,oA)|0)+Math.imul(U,IA)|0,r=r+Math.imul(U,oA)|0,i=i+Math.imul(S,QA)|0,g=(g=g+Math.imul(S,CA)|0)+Math.imul(Y,QA)|0,r=r+Math.imul(Y,CA)|0;var NA=(o+(i=i+Math.imul(k,cA)|0)|0)+((8191&(g=(g=g+Math.imul(k,hA)|0)+Math.imul(F,cA)|0))<<13)|0;o=((r=r+Math.imul(F,hA)|0)+(g>>>13)|0)+(NA>>>26)|0,NA&=67108863,i=Math.imul(H,IA),g=(g=Math.imul(H,oA))+Math.imul(R,IA)|0,r=Math.imul(R,oA),i=i+Math.imul(K,QA)|0,g=(g=g+Math.imul(K,CA)|0)+Math.imul(U,QA)|0,r=r+Math.imul(U,CA)|0;var SA=(o+(i=i+Math.imul(S,cA)|0)|0)+((8191&(g=(g=g+Math.imul(S,hA)|0)+Math.imul(Y,cA)|0))<<13)|0;o=((r=r+Math.imul(Y,hA)|0)+(g>>>13)|0)+(SA>>>26)|0,SA&=67108863,i=Math.imul(H,QA),g=(g=Math.imul(H,CA))+Math.imul(R,QA)|0,r=Math.imul(R,CA);var YA=(o+(i=i+Math.imul(K,cA)|0)|0)+((8191&(g=(g=g+Math.imul(K,hA)|0)+Math.imul(U,cA)|0))<<13)|0;o=((r=r+Math.imul(U,hA)|0)+(g>>>13)|0)+(YA>>>26)|0,YA&=67108863;var vA=(o+(i=Math.imul(H,cA))|0)+((8191&(g=(g=Math.imul(H,hA))+Math.imul(R,cA)|0))<<13)|0;return o=((r=Math.imul(R,hA))+(g>>>13)|0)+(vA>>>26)|0,vA&=67108863,I[0]=fA,I[1]=EA,I[2]=uA,I[3]=dA,I[4]=lA,I[5]=wA,I[6]=pA,I[7]=DA,I[8]=bA,I[9]=yA,I[10]=MA,I[11]=mA,I[12]=GA,I[13]=kA,I[14]=FA,I[15]=NA,I[16]=SA,I[17]=YA,I[18]=vA,0!==o&&(I[19]=o,t.length++),t};function f(A,e,t){t.negative=e.negative^A.negative,t.length=A.length+e.length;for(var i=0,g=0,r=0;r>>26)|0)>>>26,n&=67108863}t.words[r]=B,i=n,n=g}return 0!==i?t.words[r]=i:t.length--,t._strip()}function E(A,e,t){return f(A,e,t)}function u(A,e){this.x=A,this.y=e}Math.imul||(h=c),r.prototype.mulTo=function(A,e){var t=this.length+A.length;return 10===this.length&&10===A.length?h(this,A,e):t<63?c(this,A,e):t<1024?f(this,A,e):E(this,A,e)},u.prototype.makeRBT=function(A){for(var e=new Array(A),t=r.prototype._countBits(A)-1,i=0;i>=1;return i},u.prototype.permute=function(A,e,t,i,g,r){for(var n=0;n>>=1)g++;return 1<>>=13,t[2*n+1]=8191&r,r>>>=13;for(n=2*e;n>=26,t+=r/67108864|0,t+=n>>>26,this.words[g]=67108863&n}return 0!==t&&(this.words[g]=t,this.length++),e?this.ineg():this},r.prototype.muln=function(A){return this.clone().imuln(A)},r.prototype.sqr=function(){return this.mul(this)},r.prototype.isqr=function(){return this.imul(this.clone())},r.prototype.pow=function(A){var e=function(A){for(var e=new Array(A.bitLength()),t=0;t>>g&1}return e}(A);if(0===e.length)return new r(1);for(var t=this,i=0;i=0);var e,t=A%26,g=(A-t)/26,r=67108863>>>26-t<<26-t;if(0!==t){var n=0;for(e=0;e>>26-t}n&&(this.words[e]=n,this.length++)}if(0!==g){for(e=this.length-1;e>=0;e--)this.words[e+g]=this.words[e];for(e=0;e=0),g=e?(e-e%26)/26:0;var r=A%26,n=Math.min((A-r)/26,this.length),B=67108863^67108863>>>r<n)for(this.length-=n,o=0;o=0&&(0!==a||o>=g);o--){var Q=0|this.words[o];this.words[o]=a<<26-r|Q>>>r,a=Q&B}return I&&0!==a&&(I.words[I.length++]=a),0===this.length&&(this.words[0]=0,this.length=1),this._strip()},r.prototype.ishrn=function(A,e,t){return i(0===this.negative),this.iushrn(A,e,t)},r.prototype.shln=function(A){return this.clone().ishln(A)},r.prototype.ushln=function(A){return this.clone().iushln(A)},r.prototype.shrn=function(A){return this.clone().ishrn(A)},r.prototype.ushrn=function(A){return this.clone().iushrn(A)},r.prototype.testn=function(A){i("number"==typeof A&&A>=0);var e=A%26,t=(A-e)/26,g=1<=0);var e=A%26,t=(A-e)/26;if(i(0===this.negative,"imaskn works only with positive numbers"),this.length<=t)return this;if(0!==e&&t++,this.length=Math.min(t,this.length),0!==e){var g=67108863^67108863>>>e<=67108864;e++)this.words[e]-=67108864,e===this.length-1?this.words[e+1]=1:this.words[e+1]++;return this.length=Math.max(this.length,e+1),this},r.prototype.isubn=function(A){if(i("number"==typeof A),i(A<67108864),A<0)return this.iaddn(-A);if(0!==this.negative)return this.negative=0,this.iaddn(A),this.negative=1,this;if(this.words[0]-=A,1===this.length&&this.words[0]<0)this.words[0]=-this.words[0],this.negative=1;else for(var e=0;e>26)-(I/67108864|0),this.words[g+t]=67108863&r}for(;g>26,this.words[g+t]=67108863&r;if(0===B)return this._strip();for(i(-1===B),B=0,g=0;g>26,this.words[g]=67108863&r;return this.negative=1,this._strip()},r.prototype._wordDiv=function(A,e){var t=(this.length,A.length),i=this.clone(),g=A,n=0|g.words[g.length-1];0!==(t=26-this._countBits(n))&&(g=g.ushln(t),i.iushln(t),n=0|g.words[g.length-1]);var B,I=i.length-g.length;if("mod"!==e){(B=new r(null)).length=I+1,B.words=new Array(B.length);for(var o=0;o=0;Q--){var C=67108864*(0|i.words[g.length+Q])+(0|i.words[g.length+Q-1]);for(C=Math.min(C/n|0,67108863),i._ishlnsubmul(g,C,Q);0!==i.negative;)C--,i.negative=0,i._ishlnsubmul(g,1,Q),i.isZero()||(i.negative^=1);B&&(B.words[Q]=C)}return B&&B._strip(),i._strip(),"div"!==e&&0!==t&&i.iushrn(t),{div:B||null,mod:i}},r.prototype.divmod=function(A,e,t){return i(!A.isZero()),this.isZero()?{div:new r(0),mod:new r(0)}:0!==this.negative&&0===A.negative?(B=this.neg().divmod(A,e),"mod"!==e&&(g=B.div.neg()),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.iadd(A)),{div:g,mod:n}):0===this.negative&&0!==A.negative?(B=this.divmod(A.neg(),e),"mod"!==e&&(g=B.div.neg()),{div:g,mod:B.mod}):0!=(this.negative&A.negative)?(B=this.neg().divmod(A.neg(),e),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.isub(A)),{div:B.div,mod:n}):A.length>this.length||this.cmp(A)<0?{div:new r(0),mod:this}:1===A.length?"div"===e?{div:this.divn(A.words[0]),mod:null}:"mod"===e?{div:null,mod:new r(this.modrn(A.words[0]))}:{div:this.divn(A.words[0]),mod:new r(this.modrn(A.words[0]))}:this._wordDiv(A,e);var g,n,B},r.prototype.div=function(A){return this.divmod(A,"div",!1).div},r.prototype.mod=function(A){return this.divmod(A,"mod",!1).mod},r.prototype.umod=function(A){return this.divmod(A,"mod",!0).mod},r.prototype.divRound=function(A){var e=this.divmod(A);if(e.mod.isZero())return e.div;var t=0!==e.div.negative?e.mod.isub(A):e.mod,i=A.ushrn(1),g=A.andln(1),r=t.cmp(i);return r<0||1===g&&0===r?e.div:0!==e.div.negative?e.div.isubn(1):e.div.iaddn(1)},r.prototype.modrn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=(1<<26)%A,g=0,r=this.length-1;r>=0;r--)g=(t*g+(0|this.words[r]))%A;return e?-g:g},r.prototype.modn=function(A){return this.modrn(A)},r.prototype.idivn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=0,g=this.length-1;g>=0;g--){var r=(0|this.words[g])+67108864*t;this.words[g]=r/A|0,t=r%A}return this._strip(),e?this.ineg():this},r.prototype.divn=function(A){return this.clone().idivn(A)},r.prototype.egcd=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g=new r(1),n=new r(0),B=new r(0),I=new r(1),o=0;e.isEven()&&t.isEven();)e.iushrn(1),t.iushrn(1),++o;for(var a=t.clone(),Q=e.clone();!e.isZero();){for(var C=0,s=1;0==(e.words[0]&s)&&C<26;++C,s<<=1);if(C>0)for(e.iushrn(C);C-- >0;)(g.isOdd()||n.isOdd())&&(g.iadd(a),n.isub(Q)),g.iushrn(1),n.iushrn(1);for(var c=0,h=1;0==(t.words[0]&h)&&c<26;++c,h<<=1);if(c>0)for(t.iushrn(c);c-- >0;)(B.isOdd()||I.isOdd())&&(B.iadd(a),I.isub(Q)),B.iushrn(1),I.iushrn(1);e.cmp(t)>=0?(e.isub(t),g.isub(B),n.isub(I)):(t.isub(e),B.isub(g),I.isub(n))}return{a:B,b:I,gcd:t.iushln(o)}},r.prototype._invmp=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g,n=new r(1),B=new r(0),I=t.clone();e.cmpn(1)>0&&t.cmpn(1)>0;){for(var o=0,a=1;0==(e.words[0]&a)&&o<26;++o,a<<=1);if(o>0)for(e.iushrn(o);o-- >0;)n.isOdd()&&n.iadd(I),n.iushrn(1);for(var Q=0,C=1;0==(t.words[0]&C)&&Q<26;++Q,C<<=1);if(Q>0)for(t.iushrn(Q);Q-- >0;)B.isOdd()&&B.iadd(I),B.iushrn(1);e.cmp(t)>=0?(e.isub(t),n.isub(B)):(t.isub(e),B.isub(n))}return(g=0===e.cmpn(1)?n:B).cmpn(0)<0&&g.iadd(A),g},r.prototype.gcd=function(A){if(this.isZero())return A.abs();if(A.isZero())return this.abs();var e=this.clone(),t=A.clone();e.negative=0,t.negative=0;for(var i=0;e.isEven()&&t.isEven();i++)e.iushrn(1),t.iushrn(1);for(;;){for(;e.isEven();)e.iushrn(1);for(;t.isEven();)t.iushrn(1);var g=e.cmp(t);if(g<0){var r=e;e=t,t=r}else if(0===g||0===t.cmpn(1))break;e.isub(t)}return t.iushln(i)},r.prototype.invm=function(A){return this.egcd(A).a.umod(A)},r.prototype.isEven=function(){return 0==(1&this.words[0])},r.prototype.isOdd=function(){return 1==(1&this.words[0])},r.prototype.andln=function(A){return this.words[0]&A},r.prototype.bincn=function(A){i("number"==typeof A);var e=A%26,t=(A-e)/26,g=1<>>26,B&=67108863,this.words[n]=B}return 0!==r&&(this.words[n]=r,this.length++),this},r.prototype.isZero=function(){return 1===this.length&&0===this.words[0]},r.prototype.cmpn=function(A){var e,t=A<0;if(0!==this.negative&&!t)return-1;if(0===this.negative&&t)return 1;if(this._strip(),this.length>1)e=1;else{t&&(A=-A),i(A<=67108863,"Number is too big");var g=0|this.words[0];e=g===A?0:gA.length)return 1;if(this.length=0;t--){var i=0|this.words[t],g=0|A.words[t];if(i!==g){ig&&(e=1);break}}return e},r.prototype.gtn=function(A){return 1===this.cmpn(A)},r.prototype.gt=function(A){return 1===this.cmp(A)},r.prototype.gten=function(A){return this.cmpn(A)>=0},r.prototype.gte=function(A){return this.cmp(A)>=0},r.prototype.ltn=function(A){return-1===this.cmpn(A)},r.prototype.lt=function(A){return-1===this.cmp(A)},r.prototype.lten=function(A){return this.cmpn(A)<=0},r.prototype.lte=function(A){return this.cmp(A)<=0},r.prototype.eqn=function(A){return 0===this.cmpn(A)},r.prototype.eq=function(A){return 0===this.cmp(A)},r.red=function(A){return new y(A)},r.prototype.toRed=function(A){return i(!this.red,"Already a number in reduction context"),i(0===this.negative,"red works only with positives"),A.convertTo(this)._forceRed(A)},r.prototype.fromRed=function(){return i(this.red,"fromRed works only with numbers in reduction context"),this.red.convertFrom(this)},r.prototype._forceRed=function(A){return this.red=A,this},r.prototype.forceRed=function(A){return i(!this.red,"Already a number in reduction context"),this._forceRed(A)},r.prototype.redAdd=function(A){return i(this.red,"redAdd works only with red numbers"),this.red.add(this,A)},r.prototype.redIAdd=function(A){return i(this.red,"redIAdd works only with red numbers"),this.red.iadd(this,A)},r.prototype.redSub=function(A){return i(this.red,"redSub works only with red numbers"),this.red.sub(this,A)},r.prototype.redISub=function(A){return i(this.red,"redISub works only with red numbers"),this.red.isub(this,A)},r.prototype.redShl=function(A){return i(this.red,"redShl works only with red numbers"),this.red.shl(this,A)},r.prototype.redMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.mul(this,A)},r.prototype.redIMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.imul(this,A)},r.prototype.redSqr=function(){return i(this.red,"redSqr works only with red numbers"),this.red._verify1(this),this.red.sqr(this)},r.prototype.redISqr=function(){return i(this.red,"redISqr works only with red numbers"),this.red._verify1(this),this.red.isqr(this)},r.prototype.redSqrt=function(){return i(this.red,"redSqrt works only with red numbers"),this.red._verify1(this),this.red.sqrt(this)},r.prototype.redInvm=function(){return i(this.red,"redInvm works only with red numbers"),this.red._verify1(this),this.red.invm(this)},r.prototype.redNeg=function(){return i(this.red,"redNeg works only with red numbers"),this.red._verify1(this),this.red.neg(this)},r.prototype.redPow=function(A){return i(this.red&&!A.red,"redPow(normalNum)"),this.red._verify1(this),this.red.pow(this,A)};var d={k256:null,p224:null,p192:null,p25519:null};function l(A,e){this.name=A,this.p=new r(e,16),this.n=this.p.bitLength(),this.k=new r(1).iushln(this.n).isub(this.p),this.tmp=this._tmp()}function w(){l.call(this,"k256","ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f")}function p(){l.call(this,"p224","ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001")}function D(){l.call(this,"p192","ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff")}function b(){l.call(this,"25519","7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed")}function y(A){if("string"==typeof A){var e=r._prime(A);this.m=e.p,this.prime=e}else i(A.gtn(1),"modulus must be greater than 1"),this.m=A,this.prime=null}function M(A){y.call(this,A),this.shift=this.m.bitLength(),this.shift%26!=0&&(this.shift+=26-this.shift%26),this.r=new r(1).iushln(this.shift),this.r2=this.imod(this.r.sqr()),this.rinv=this.r._invmp(this.m),this.minv=this.rinv.mul(this.r).isubn(1).div(this.m),this.minv=this.minv.umod(this.r),this.minv=this.r.sub(this.minv)}l.prototype._tmp=function(){var A=new r(null);return A.words=new Array(Math.ceil(this.n/13)),A},l.prototype.ireduce=function(A){var e,t=A;do{this.split(t,this.tmp),e=(t=(t=this.imulK(t)).iadd(this.tmp)).bitLength()}while(e>this.n);var i=e0?t.isub(this.p):void 0!==t.strip?t.strip():t._strip(),t},l.prototype.split=function(A,e){A.iushrn(this.n,0,e)},l.prototype.imulK=function(A){return A.imul(this.k)},g(w,l),w.prototype.split=function(A,e){for(var t=Math.min(A.length,9),i=0;i>>22,g=r}g>>>=22,A.words[i-10]=g,0===g&&A.length>10?A.length-=10:A.length-=9},w.prototype.imulK=function(A){A.words[A.length]=0,A.words[A.length+1]=0,A.length+=2;for(var e=0,t=0;t>>=26,A.words[t]=g,e=i}return 0!==e&&(A.words[A.length++]=e),A},r._prime=function(A){if(d[A])return d[A];var e;if("k256"===A)e=new w;else if("p224"===A)e=new p;else if("p192"===A)e=new D;else{if("p25519"!==A)throw new Error("Unknown prime "+A);e=new b}return d[A]=e,e},y.prototype._verify1=function(A){i(0===A.negative,"red works only with positives"),i(A.red,"red works only with red numbers")},y.prototype._verify2=function(A,e){i(0==(A.negative|e.negative),"red works only with positives"),i(A.red&&A.red===e.red,"red works only with red numbers")},y.prototype.imod=function(A){return this.prime?this.prime.ireduce(A)._forceRed(this):(o(A,A.umod(this.m)._forceRed(this)),A)},y.prototype.neg=function(A){return A.isZero()?A.clone():this.m.sub(A)._forceRed(this)},y.prototype.add=function(A,e){this._verify2(A,e);var t=A.add(e);return t.cmp(this.m)>=0&&t.isub(this.m),t._forceRed(this)},y.prototype.iadd=function(A,e){this._verify2(A,e);var t=A.iadd(e);return t.cmp(this.m)>=0&&t.isub(this.m),t},y.prototype.sub=function(A,e){this._verify2(A,e);var t=A.sub(e);return t.cmpn(0)<0&&t.iadd(this.m),t._forceRed(this)},y.prototype.isub=function(A,e){this._verify2(A,e);var t=A.isub(e);return t.cmpn(0)<0&&t.iadd(this.m),t},y.prototype.shl=function(A,e){return this._verify1(A),this.imod(A.ushln(e))},y.prototype.imul=function(A,e){return this._verify2(A,e),this.imod(A.imul(e))},y.prototype.mul=function(A,e){return this._verify2(A,e),this.imod(A.mul(e))},y.prototype.isqr=function(A){return this.imul(A,A.clone())},y.prototype.sqr=function(A){return this.mul(A,A)},y.prototype.sqrt=function(A){if(A.isZero())return A.clone();var e=this.m.andln(3);if(i(e%2==1),3===e){var t=this.m.add(new r(1)).iushrn(2);return this.pow(A,t)}for(var g=this.m.subn(1),n=0;!g.isZero()&&0===g.andln(1);)n++,g.iushrn(1);i(!g.isZero());var B=new r(1).toRed(this),I=B.redNeg(),o=this.m.subn(1).iushrn(1),a=this.m.bitLength();for(a=new r(2*a*a).toRed(this);0!==this.pow(a,o).cmp(I);)a.redIAdd(I);for(var Q=this.pow(a,g),C=this.pow(A,g.addn(1).iushrn(1)),s=this.pow(A,g),c=n;0!==s.cmp(B);){for(var h=s,f=0;0!==h.cmp(B);f++)h=h.redSqr();i(f=0;i--){for(var o=e.words[i],a=I-1;a>=0;a--){var Q=o>>a&1;g!==t[0]&&(g=this.sqr(g)),0!==Q||0!==n?(n<<=1,n|=Q,(4===++B||0===i&&0===a)&&(g=this.mul(g,t[n]),B=0,n=0)):B=0}I=26}return g},y.prototype.convertTo=function(A){var e=A.umod(this.m);return e===A?e.clone():e},y.prototype.convertFrom=function(A){var e=A.clone();return e.red=null,e},r.mont=function(A){return new M(A)},g(M,y),M.prototype.convertTo=function(A){return this.imod(A.ushln(this.shift))},M.prototype.convertFrom=function(A){var e=this.imod(A.mul(this.rinv));return e.red=null,e},M.prototype.imul=function(A,e){if(A.isZero()||e.isZero())return A.words[0]=0,A.length=1,A;var t=A.imul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),r=g;return g.cmp(this.m)>=0?r=g.isub(this.m):g.cmpn(0)<0&&(r=g.iadd(this.m)),r._forceRed(this)},M.prototype.mul=function(A,e){if(A.isZero()||e.isZero())return new r(0)._forceRed(this);var t=A.mul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),n=g;return g.cmp(this.m)>=0?n=g.isub(this.m):g.cmpn(0)<0&&(n=g.iadd(this.m)),n._forceRed(this)},M.prototype.invm=function(A){return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this)}}(void 0===e||e,this)},{buffer:19}],18:[function(A,e,t){var i;function g(A){this.rand=A}if(e.exports=function(A){return i||(i=new g(null)),i.generate(A)},e.exports.Rand=g,g.prototype.generate=function(A){return this._rand(A)},g.prototype._rand=function(A){if(this.rand.getBytes)return this.rand.getBytes(A);for(var e=new Uint8Array(A),t=0;t>>24]^a[c>>>16&255]^Q[h>>>8&255]^C[255&f]^e[E++],n=o[c>>>24]^a[h>>>16&255]^Q[f>>>8&255]^C[255&s]^e[E++],B=o[h>>>24]^a[f>>>16&255]^Q[s>>>8&255]^C[255&c]^e[E++],I=o[f>>>24]^a[s>>>16&255]^Q[c>>>8&255]^C[255&h]^e[E++],s=r,c=n,h=B,f=I;return r=(i[s>>>24]<<24|i[c>>>16&255]<<16|i[h>>>8&255]<<8|i[255&f])^e[E++],n=(i[c>>>24]<<24|i[h>>>16&255]<<16|i[f>>>8&255]<<8|i[255&s])^e[E++],B=(i[h>>>24]<<24|i[f>>>16&255]<<16|i[s>>>8&255]<<8|i[255&c])^e[E++],I=(i[f>>>24]<<24|i[s>>>16&255]<<16|i[c>>>8&255]<<8|i[255&h])^e[E++],[r>>>=0,n>>>=0,B>>>=0,I>>>=0]}var B=[0,1,2,4,8,16,32,64,128,27,54],I=function(){for(var A=new Array(256),e=0;e<256;e++)A[e]=e<128?e<<1:e<<1^283;for(var t=[],i=[],g=[[],[],[],[]],r=[[],[],[],[]],n=0,B=0,I=0;I<256;++I){var o=B^B<<1^B<<2^B<<3^B<<4;o=o>>>8^255&o^99,t[n]=o,i[o]=n;var a=A[n],Q=A[a],C=A[Q],s=257*A[o]^16843008*o;g[0][n]=s<<24|s>>>8,g[1][n]=s<<16|s>>>16,g[2][n]=s<<8|s>>>24,g[3][n]=s,s=16843009*C^65537*Q^257*a^16843008*n,r[0][o]=s<<24|s>>>8,r[1][o]=s<<16|s>>>16,r[2][o]=s<<8|s>>>24,r[3][o]=s,0===n?n=B=1:(n=a^A[A[A[C^a]]],B^=A[A[B]])}return{SBOX:t,INV_SBOX:i,SUB_MIX:g,INV_SUB_MIX:r}}();function o(A){this._key=g(A),this._reset()}o.blockSize=16,o.keySize=32,o.prototype.blockSize=o.blockSize,o.prototype.keySize=o.keySize,o.prototype._reset=function(){for(var A=this._key,e=A.length,t=e+6,i=4*(t+1),g=[],r=0;r>>24,n=I.SBOX[n>>>24]<<24|I.SBOX[n>>>16&255]<<16|I.SBOX[n>>>8&255]<<8|I.SBOX[255&n],n^=B[r/e|0]<<24):e>6&&r%e==4&&(n=I.SBOX[n>>>24]<<24|I.SBOX[n>>>16&255]<<16|I.SBOX[n>>>8&255]<<8|I.SBOX[255&n]),g[r]=g[r-e]^n}for(var o=[],a=0;a>>24]]^I.INV_SUB_MIX[1][I.SBOX[C>>>16&255]]^I.INV_SUB_MIX[2][I.SBOX[C>>>8&255]]^I.INV_SUB_MIX[3][I.SBOX[255&C]]}this._nRounds=t,this._keySchedule=g,this._invKeySchedule=o},o.prototype.encryptBlockRaw=function(A){return n(A=g(A),this._keySchedule,I.SUB_MIX,I.SBOX,this._nRounds)},o.prototype.encryptBlock=function(A){var e=this.encryptBlockRaw(A),t=i.allocUnsafe(16);return t.writeUInt32BE(e[0],0),t.writeUInt32BE(e[1],4),t.writeUInt32BE(e[2],8),t.writeUInt32BE(e[3],12),t},o.prototype.decryptBlock=function(A){var e=(A=g(A))[1];A[1]=A[3],A[3]=e;var t=n(A,this._invKeySchedule,I.INV_SUB_MIX,I.INV_SBOX,this._nRounds),r=i.allocUnsafe(16);return r.writeUInt32BE(t[0],0),r.writeUInt32BE(t[3],4),r.writeUInt32BE(t[2],8),r.writeUInt32BE(t[1],12),r},o.prototype.scrub=function(){r(this._keySchedule),r(this._invKeySchedule),r(this._key)},e.exports.AES=o},{"safe-buffer":180}],21:[function(A,e,t){var i=A("./aes"),g=A("safe-buffer").Buffer,r=A("cipher-base"),n=A("inherits"),B=A("./ghash"),I=A("buffer-xor"),o=A("./incr32");function a(A,e,t,n){r.call(this);var I=g.alloc(4,0);this._cipher=new i.AES(e);var a=this._cipher.encryptBlock(I);this._ghash=new B(a),t=function(A,e,t){if(12===e.length)return A._finID=g.concat([e,g.from([0,0,0,1])]),g.concat([e,g.from([0,0,0,2])]);var i=new B(t),r=e.length,n=r%16;i.update(e),n&&(n=16-n,i.update(g.alloc(n,0))),i.update(g.alloc(8,0));var I=8*r,a=g.alloc(8);a.writeUIntBE(I,0,8),i.update(a),A._finID=i.state;var Q=g.from(A._finID);return o(Q),Q}(this,t,a),this._prev=g.from(t),this._cache=g.allocUnsafe(0),this._secCache=g.allocUnsafe(0),this._decrypt=n,this._alen=0,this._len=0,this._mode=A,this._authTag=null,this._called=!1}n(a,r),a.prototype._update=function(A){if(!this._called&&this._alen){var e=16-this._alen%16;e<16&&(e=g.alloc(e,0),this._ghash.update(e))}this._called=!0;var t=this._mode.encrypt(this,A);return this._decrypt?this._ghash.update(A):this._ghash.update(t),this._len+=A.length,t},a.prototype._final=function(){if(this._decrypt&&!this._authTag)throw new Error("Unsupported state or unable to authenticate data");var A=I(this._ghash.final(8*this._alen,8*this._len),this._cipher.encryptBlock(this._finID));if(this._decrypt&&function(A,e){var t=0;A.length!==e.length&&t++;for(var i=Math.min(A.length,e.length),g=0;g16)throw new Error("unable to decrypt data");var t=-1;for(;++t16)return e=this.cache.slice(0,16),this.cache=this.cache.slice(16),e}else if(this.cache.length>=16)return e=this.cache.slice(0,16),this.cache=this.cache.slice(16),e;return null},Q.prototype.flush=function(){if(this.cache.length)return this.cache},t.createDecipher=function(A,e){var t=r[A.toLowerCase()];if(!t)throw new TypeError("invalid suite type");var i=o(e,!1,t.key,t.iv);return C(A,i.key,i.iv)},t.createDecipheriv=C},{"./aes":20,"./authCipher":21,"./modes":33,"./streamCipher":36,"cipher-base":65,evp_bytestokey:103,inherits:134,"safe-buffer":180}],24:[function(A,e,t){var i=A("./modes"),g=A("./authCipher"),r=A("safe-buffer").Buffer,n=A("./streamCipher"),B=A("cipher-base"),I=A("./aes"),o=A("evp_bytestokey");function a(A,e,t){B.call(this),this._cache=new C,this._cipher=new I.AES(e),this._prev=r.from(t),this._mode=A,this._autopadding=!0}A("inherits")(a,B),a.prototype._update=function(A){var e,t;this._cache.add(A);for(var i=[];e=this._cache.get();)t=this._mode.encrypt(this,e),i.push(t);return r.concat(i)};var Q=r.alloc(16,16);function C(){this.cache=r.allocUnsafe(0)}function s(A,e,t){var B=i[A.toLowerCase()];if(!B)throw new TypeError("invalid suite type");if("string"==typeof e&&(e=r.from(e)),e.length!==B.key/8)throw new TypeError("invalid key length "+e.length);if("string"==typeof t&&(t=r.from(t)),"GCM"!==B.mode&&t.length!==B.iv)throw new TypeError("invalid iv length "+t.length);return"stream"===B.type?new n(B.module,e,t):"auth"===B.type?new g(B.module,e,t):new a(B.module,e,t)}a.prototype._final=function(){var A=this._cache.flush();if(this._autopadding)return A=this._mode.encrypt(this,A),this._cipher.scrub(),A;if(!A.equals(Q))throw this._cipher.scrub(),new Error("data not multiple of block length")},a.prototype.setAutoPadding=function(A){return this._autopadding=!!A,this},C.prototype.add=function(A){this.cache=r.concat([this.cache,A])},C.prototype.get=function(){if(this.cache.length>15){var A=this.cache.slice(0,16);return this.cache=this.cache.slice(16),A}return null},C.prototype.flush=function(){for(var A=16-this.cache.length,e=r.allocUnsafe(A),t=-1;++t>>0,0),e.writeUInt32BE(A[1]>>>0,4),e.writeUInt32BE(A[2]>>>0,8),e.writeUInt32BE(A[3]>>>0,12),e}function n(A){this.h=A,this.state=i.alloc(16,0),this.cache=i.allocUnsafe(0)}n.prototype.ghash=function(A){for(var e=-1;++e0;e--)i[e]=i[e]>>>1|(1&i[e-1])<<31;i[0]=i[0]>>>1,t&&(i[0]=i[0]^225<<24)}this.state=r(g)},n.prototype.update=function(A){var e;for(this.cache=i.concat([this.cache,A]);this.cache.length>=16;)e=this.cache.slice(0,16),this.cache=this.cache.slice(16),this.ghash(e)},n.prototype.final=function(A,e){return this.cache.length&&this.ghash(i.concat([this.cache,g],16)),this.ghash(r([0,A,0,e])),this.state},e.exports=n},{"safe-buffer":180}],26:[function(A,e,t){e.exports=function(A){for(var e,t=A.length;t--;){if(255!==(e=A.readUInt8(t))){e++,A.writeUInt8(e,t);break}A.writeUInt8(0,t)}}},{}],27:[function(A,e,t){var i=A("buffer-xor");t.encrypt=function(A,e){var t=i(e,A._prev);return A._prev=A._cipher.encryptBlock(t),A._prev},t.decrypt=function(A,e){var t=A._prev;A._prev=e;var g=A._cipher.decryptBlock(e);return i(g,t)}},{"buffer-xor":63}],28:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("buffer-xor");function r(A,e,t){var r=e.length,n=g(e,A._cache);return A._cache=A._cache.slice(r),A._prev=i.concat([A._prev,t?e:n]),n}t.encrypt=function(A,e,t){for(var g,n=i.allocUnsafe(0);e.length;){if(0===A._cache.length&&(A._cache=A._cipher.encryptBlock(A._prev),A._prev=i.allocUnsafe(0)),!(A._cache.length<=e.length)){n=i.concat([n,r(A,e,t)]);break}g=A._cache.length,n=i.concat([n,r(A,e.slice(0,g),t)]),e=e.slice(g)}return n}},{"buffer-xor":63,"safe-buffer":180}],29:[function(A,e,t){var i=A("safe-buffer").Buffer;function g(A,e,t){for(var i,g,n,B=-1,I=0;++B<8;)i=A._cipher.encryptBlock(A._prev),g=e&1<<7-B?128:0,I+=(128&(n=i[0]^g))>>B%8,A._prev=r(A._prev,t?g:n);return I}function r(A,e){var t=A.length,g=-1,r=i.allocUnsafe(A.length);for(A=i.concat([A,i.from([e])]);++g>7;return r}t.encrypt=function(A,e,t){for(var r=e.length,n=i.allocUnsafe(r),B=-1;++B=0||!t.umod(A.prime1)||!t.umod(A.prime2);)t=new i(g(e));return t}e.exports=r,r.getr=n}).call(this,A("buffer").Buffer)},{"bn.js":41,buffer:64,randombytes:162}],41:[function(A,e,t){arguments[4][15][0].apply(t,arguments)},{buffer:19,dup:15}],42:[function(A,e,t){e.exports=A("./browser/algorithms.json")},{"./browser/algorithms.json":43}],43:[function(A,e,t){e.exports={sha224WithRSAEncryption:{sign:"rsa",hash:"sha224",id:"302d300d06096086480165030402040500041c"},"RSA-SHA224":{sign:"ecdsa/rsa",hash:"sha224",id:"302d300d06096086480165030402040500041c"},sha256WithRSAEncryption:{sign:"rsa",hash:"sha256",id:"3031300d060960864801650304020105000420"},"RSA-SHA256":{sign:"ecdsa/rsa",hash:"sha256",id:"3031300d060960864801650304020105000420"},sha384WithRSAEncryption:{sign:"rsa",hash:"sha384",id:"3041300d060960864801650304020205000430"},"RSA-SHA384":{sign:"ecdsa/rsa",hash:"sha384",id:"3041300d060960864801650304020205000430"},sha512WithRSAEncryption:{sign:"rsa",hash:"sha512",id:"3051300d060960864801650304020305000440"},"RSA-SHA512":{sign:"ecdsa/rsa",hash:"sha512",id:"3051300d060960864801650304020305000440"},"RSA-SHA1":{sign:"rsa",hash:"sha1",id:"3021300906052b0e03021a05000414"},"ecdsa-with-SHA1":{sign:"ecdsa",hash:"sha1",id:""},sha256:{sign:"ecdsa",hash:"sha256",id:""},sha224:{sign:"ecdsa",hash:"sha224",id:""},sha384:{sign:"ecdsa",hash:"sha384",id:""},sha512:{sign:"ecdsa",hash:"sha512",id:""},"DSA-SHA":{sign:"dsa",hash:"sha1",id:""},"DSA-SHA1":{sign:"dsa",hash:"sha1",id:""},DSA:{sign:"dsa",hash:"sha1",id:""},"DSA-WITH-SHA224":{sign:"dsa",hash:"sha224",id:""},"DSA-SHA224":{sign:"dsa",hash:"sha224",id:""},"DSA-WITH-SHA256":{sign:"dsa",hash:"sha256",id:""},"DSA-SHA256":{sign:"dsa",hash:"sha256",id:""},"DSA-WITH-SHA384":{sign:"dsa",hash:"sha384",id:""},"DSA-SHA384":{sign:"dsa",hash:"sha384",id:""},"DSA-WITH-SHA512":{sign:"dsa",hash:"sha512",id:""},"DSA-SHA512":{sign:"dsa",hash:"sha512",id:""},"DSA-RIPEMD160":{sign:"dsa",hash:"rmd160",id:""},ripemd160WithRSA:{sign:"rsa",hash:"rmd160",id:"3021300906052b2403020105000414"},"RSA-RIPEMD160":{sign:"rsa",hash:"rmd160",id:"3021300906052b2403020105000414"},md5WithRSAEncryption:{sign:"rsa",hash:"md5",id:"3020300c06082a864886f70d020505000410"},"RSA-MD5":{sign:"rsa",hash:"md5",id:"3020300c06082a864886f70d020505000410"}}},{}],44:[function(A,e,t){e.exports={"1.3.132.0.10":"secp256k1","1.3.132.0.33":"p224","1.2.840.10045.3.1.1":"p192","1.2.840.10045.3.1.7":"p256","1.3.132.0.34":"p384","1.3.132.0.35":"p521"}},{}],45:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("create-hash"),r=A("readable-stream"),n=A("inherits"),B=A("./sign"),I=A("./verify"),o=A("./algorithms.json");function a(A){r.Writable.call(this);var e=o[A];if(!e)throw new Error("Unknown message digest");this._hashType=e.hash,this._hash=g(e.hash),this._tag=e.id,this._signType=e.sign}function Q(A){r.Writable.call(this);var e=o[A];if(!e)throw new Error("Unknown message digest");this._hash=g(e.hash),this._tag=e.id,this._signType=e.sign}function C(A){return new a(A)}function s(A){return new Q(A)}Object.keys(o).forEach(function(A){o[A].id=i.from(o[A].id,"hex"),o[A.toLowerCase()]=o[A]}),n(a,r.Writable),a.prototype._write=function(A,e,t){this._hash.update(A),t()},a.prototype.update=function(A,e){return"string"==typeof A&&(A=i.from(A,e)),this._hash.update(A),this},a.prototype.sign=function(A,e){this.end();var t=this._hash.digest(),i=B(t,A,this._hashType,this._signType,this._tag);return e?i.toString(e):i},n(Q,r.Writable),Q.prototype._write=function(A,e,t){this._hash.update(A),t()},Q.prototype.update=function(A,e){return"string"==typeof A&&(A=i.from(A,e)),this._hash.update(A),this},Q.prototype.verify=function(A,e,t){"string"==typeof e&&(e=i.from(e,t)),this.end();var g=this._hash.digest();return I(e,g,A,this._signType,this._tag)},e.exports={Sign:C,Verify:s,createSign:C,createVerify:s}},{"./algorithms.json":43,"./sign":46,"./verify":47,"create-hash":69,inherits:134,"readable-stream":62,"safe-buffer":180}],46:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("create-hmac"),r=A("browserify-rsa"),n=A("elliptic").ec,B=A("bn.js"),I=A("parse-asn1"),o=A("./curves.json");function a(A,e,t,r){if((A=i.from(A.toArray())).length0&&t.ishrn(i),t}function C(A,e,t){var r,n;do{for(r=i.alloc(0);8*r.length=e)throw new Error("invalid sig")}e.exports=function(A,e,t,o,a){var Q=n(t);if("ec"===Q.type){if("ecdsa"!==o&&"ecdsa/rsa"!==o)throw new Error("wrong public key type");return function(A,e,t){var i=B[t.data.algorithm.curve.join(".")];if(!i)throw new Error("unknown curve "+t.data.algorithm.curve.join("."));var g=new r(i),n=t.data.subjectPrivateKey.data;return g.verify(e,A,n)}(A,e,Q)}if("dsa"===Q.type){if("dsa"!==o)throw new Error("wrong public key type");return function(A,e,t){var i=t.data.p,r=t.data.q,B=t.data.g,o=t.data.pub_key,a=n.signature.decode(A,"der"),Q=a.s,C=a.r;I(Q,r),I(C,r);var s=g.mont(i),c=Q.invm(r);return 0===B.toRed(s).redPow(new g(e).mul(c).mod(r)).fromRed().mul(o.toRed(s).redPow(C.mul(c).mod(r)).fromRed()).mod(i).mod(r).cmp(C)}(A,e,Q)}if("rsa"!==o&&"ecdsa/rsa"!==o)throw new Error("wrong public key type");e=i.concat([a,e]);for(var C=Q.modulus.byteLength(),s=[1],c=0;e.length+s.length+22?"one of ".concat(e," ").concat(A.slice(0,t-1).join(", "),", or ")+A[t-1]:2===t?"one of ".concat(e," ").concat(A[0]," or ").concat(A[1]):"of ".concat(e," ").concat(A[0])}return"of ".concat(e," ").concat(String(A))}g("ERR_INVALID_OPT_VALUE",function(A,e){return'The value "'+e+'" is invalid for option "'+A+'"'},TypeError),g("ERR_INVALID_ARG_TYPE",function(A,e,t){var i,g,n,B;if("string"==typeof e&&(g="not ",e.substr(!n||n<0?0:+n,g.length)===g)?(i="must not be",e=e.replace(/^not /,"")):i="must be",function(A,e,t){return(void 0===t||t>A.length)&&(t=A.length),A.substring(t-e.length,t)===e}(A," argument"))B="The ".concat(A," ").concat(i," ").concat(r(e,"type"));else{var I=function(A,e,t){return"number"!=typeof t&&(t=0),!(t+e.length>A.length)&&-1!==A.indexOf(e,t)}(A,".")?"property":"argument";B='The "'.concat(A,'" ').concat(I," ").concat(i," ").concat(r(e,"type"))}return B+=". Received type ".concat(typeof t)},TypeError),g("ERR_STREAM_PUSH_AFTER_EOF","stream.push() after EOF"),g("ERR_METHOD_NOT_IMPLEMENTED",function(A){return"The "+A+" method is not implemented"}),g("ERR_STREAM_PREMATURE_CLOSE","Premature close"),g("ERR_STREAM_DESTROYED",function(A){return"Cannot call "+A+" after a stream was destroyed"}),g("ERR_MULTIPLE_CALLBACK","Callback called multiple times"),g("ERR_STREAM_CANNOT_PIPE","Cannot pipe, not readable"),g("ERR_STREAM_WRITE_AFTER_END","write after end"),g("ERR_STREAM_NULL_VALUES","May not write null values to stream",TypeError),g("ERR_UNKNOWN_ENCODING",function(A){return"Unknown encoding: "+A},TypeError),g("ERR_STREAM_UNSHIFT_AFTER_END_EVENT","stream.unshift() after end event"),e.exports.codes=i},{}],49:[function(A,e,t){(function(t){"use strict";var i=Object.keys||function(A){var e=[];for(var t in A)e.push(t);return e};e.exports=o;var g=A("./_stream_readable"),r=A("./_stream_writable");A("inherits")(o,g);for(var n=i(r.prototype),B=0;B0)if("string"==typeof e||n.objectMode||Object.getPrototypeOf(e)===B.prototype||(e=function(A){return B.from(A)}(e)),i)n.endEmitted?p(A,new w):m(A,n,e,!0);else if(n.ended)p(A,new d);else{if(n.destroyed)return!1;n.reading=!1,n.decoder&&!t?(e=n.decoder.write(e),n.objectMode||0!==e.length?m(A,n,e,!1):S(A,n)):m(A,n,e,!1)}else i||(n.reading=!1,S(A,n));return!n.ended&&(n.lengthe.highWaterMark&&(e.highWaterMark=function(A){return A>=G?A=G:(A--,A|=A>>>1,A|=A>>>2,A|=A>>>4,A|=A>>>8,A|=A>>>16,A++),A}(A)),A<=e.length?A:e.ended?e.length:(e.needReadable=!0,0))}function F(A){var e=A._readableState;o("emitReadable",e.needReadable,e.emittedReadable),e.needReadable=!1,e.emittedReadable||(o("emitReadable",e.flowing),e.emittedReadable=!0,t.nextTick(N,A))}function N(A){var e=A._readableState;o("emitReadable_",e.destroyed,e.length,e.ended),e.destroyed||!e.length&&!e.ended||(A.emit("readable"),e.emittedReadable=!1),e.needReadable=!e.flowing&&!e.ended&&e.length<=e.highWaterMark,J(A)}function S(A,e){e.readingMore||(e.readingMore=!0,t.nextTick(Y,A,e))}function Y(A,e){for(;!e.reading&&!e.ended&&(e.length0,e.resumeScheduled&&!e.paused?e.flowing=!0:A.listenerCount("data")>0&&A.resume()}function K(A){o("readable nexttick read 0"),A.read(0)}function U(A,e){o("resume",e.reading),e.reading||A.read(0),e.resumeScheduled=!1,A.emit("resume"),J(A),e.flowing&&!e.reading&&A.read(0)}function J(A){var e=A._readableState;for(o("flow",e.flowing);e.flowing&&null!==A.read(););}function H(A,e){return 0===e.length?null:(e.objectMode?t=e.buffer.shift():!A||A>=e.length?(t=e.decoder?e.buffer.join(""):1===e.buffer.length?e.buffer.first():e.buffer.concat(e.length),e.buffer.clear()):t=e.buffer.consume(A,e.decoder),t);var t}function R(A){var e=A._readableState;o("endReadable",e.endEmitted),e.endEmitted||(e.ended=!0,t.nextTick(q,e,A))}function q(A,e){if(o("endReadableNT",A.endEmitted,A.length),!A.endEmitted&&0===A.length&&(A.endEmitted=!0,e.readable=!1,e.emit("end"),A.autoDestroy)){var t=e._writableState;(!t||t.autoDestroy&&t.finished)&&e.destroy()}}function L(A,e){for(var t=0,i=A.length;t=e.highWaterMark:e.length>0)||e.ended))return o("read: emitReadable",e.length,e.ended),0===e.length&&e.ended?R(this):F(this),null;if(0===(A=k(A,e))&&e.ended)return 0===e.length&&R(this),null;var i,g=e.needReadable;return o("need readable",g),(0===e.length||e.length-A0?H(A,e):null)?(e.needReadable=e.length<=e.highWaterMark,A=0):(e.length-=A,e.awaitDrain=0),0===e.length&&(e.ended||(e.needReadable=!0),t!==A&&e.ended&&R(this)),null!==i&&this.emit("data",i),i},y.prototype._read=function(A){p(this,new l("_read()"))},y.prototype.pipe=function(A,e){var i=this,g=this._readableState;switch(g.pipesCount){case 0:g.pipes=A;break;case 1:g.pipes=[g.pipes,A];break;default:g.pipes.push(A)}g.pipesCount+=1,o("pipe count=%d opts=%j",g.pipesCount,e);var n=(!e||!1!==e.end)&&A!==t.stdout&&A!==t.stderr?I:f;function B(e,t){o("onunpipe"),e===i&&t&&!1===t.hasUnpiped&&(t.hasUnpiped=!0,o("cleanup"),A.removeListener("close",c),A.removeListener("finish",h),A.removeListener("drain",a),A.removeListener("error",s),A.removeListener("unpipe",B),i.removeListener("end",I),i.removeListener("end",f),i.removeListener("data",C),Q=!0,!g.awaitDrain||A._writableState&&!A._writableState.needDrain||a())}function I(){o("onend"),A.end()}g.endEmitted?t.nextTick(n):i.once("end",n),A.on("unpipe",B);var a=function(A){return function(){var e=A._readableState;o("pipeOnDrain",e.awaitDrain),e.awaitDrain&&e.awaitDrain--,0===e.awaitDrain&&r(A,"data")&&(e.flowing=!0,J(A))}}(i);A.on("drain",a);var Q=!1;function C(e){o("ondata");var t=A.write(e);o("dest.write",t),!1===t&&((1===g.pipesCount&&g.pipes===A||g.pipesCount>1&&-1!==L(g.pipes,A))&&!Q&&(o("false write response, pause",g.awaitDrain),g.awaitDrain++),i.pause())}function s(e){o("onerror",e),f(),A.removeListener("error",s),0===r(A,"error")&&p(A,e)}function c(){A.removeListener("finish",h),f()}function h(){o("onfinish"),A.removeListener("close",c),f()}function f(){o("unpipe"),i.unpipe(A)}return i.on("data",C),function(A,e,t){if("function"==typeof A.prependListener)return A.prependListener(e,t);A._events&&A._events[e]?Array.isArray(A._events[e])?A._events[e].unshift(t):A._events[e]=[t,A._events[e]]:A.on(e,t)}(A,"error",s),A.once("close",c),A.once("finish",h),A.emit("pipe",i),g.flowing||(o("pipe resume"),i.resume()),A},y.prototype.unpipe=function(A){var e=this._readableState,t={hasUnpiped:!1};if(0===e.pipesCount)return this;if(1===e.pipesCount)return A&&A!==e.pipes?this:(A||(A=e.pipes),e.pipes=null,e.pipesCount=0,e.flowing=!1,A&&A.emit("unpipe",this,t),this);if(!A){var i=e.pipes,g=e.pipesCount;e.pipes=null,e.pipesCount=0,e.flowing=!1;for(var r=0;r0,!1!==g.flowing&&this.resume()):"readable"===A&&(g.endEmitted||g.readableListening||(g.readableListening=g.needReadable=!0,g.flowing=!1,g.emittedReadable=!1,o("on readable",g.length,g.reading),g.length?F(this):g.reading||t.nextTick(K,this))),i},y.prototype.addListener=y.prototype.on,y.prototype.removeListener=function(A,e){var i=n.prototype.removeListener.call(this,A,e);return"readable"===A&&t.nextTick(v,this),i},y.prototype.removeAllListeners=function(A){var e=n.prototype.removeAllListeners.apply(this,arguments);return"readable"!==A&&void 0!==A||t.nextTick(v,this),e},y.prototype.resume=function(){var A=this._readableState;return A.flowing||(o("resume"),A.flowing=!A.readableListening,function(A,e){e.resumeScheduled||(e.resumeScheduled=!0,t.nextTick(U,A,e))}(this,A)),A.paused=!1,this},y.prototype.pause=function(){return o("call pause flowing=%j",this._readableState.flowing),!1!==this._readableState.flowing&&(o("pause"),this._readableState.flowing=!1,this.emit("pause")),this._readableState.paused=!0,this},y.prototype.wrap=function(A){var e=this,t=this._readableState,i=!1;for(var g in A.on("end",function(){if(o("wrapped end"),t.decoder&&!t.ended){var A=t.decoder.end();A&&A.length&&e.push(A)}e.push(null)}),A.on("data",function(g){(o("wrapped data"),t.decoder&&(g=t.decoder.write(g)),!t.objectMode||null!==g&&void 0!==g)&&((t.objectMode||g&&g.length)&&(e.push(g)||(i=!0,A.pause())))}),A)void 0===this[g]&&"function"==typeof A[g]&&(this[g]=function(e){return function(){return A[e].apply(A,arguments)}}(g));for(var r=0;r-1))throw new w(A);return this._writableState.defaultEncoding=A,this},Object.defineProperty(y.prototype,"writableBuffer",{enumerable:!1,get:function(){return this._writableState&&this._writableState.getBuffer()}}),Object.defineProperty(y.prototype,"writableHighWaterMark",{enumerable:!1,get:function(){return this._writableState.highWaterMark}}),y.prototype._write=function(A,e,t){t(new h("_write()"))},y.prototype._writev=null,y.prototype.end=function(A,e,i){var g=this._writableState;return"function"==typeof A?(i=A,A=null,e=null):"function"==typeof e&&(i=e,e=null),null!==A&&void 0!==A&&this.write(A,e),g.corked&&(g.corked=1,this.uncork()),g.ending||function(A,e,i){e.ending=!0,N(A,e),i&&(e.finished?t.nextTick(i):A.once("finish",i));e.ended=!0,A.writable=!1}(this,g,i),this},Object.defineProperty(y.prototype,"writableLength",{enumerable:!1,get:function(){return this._writableState.length}}),Object.defineProperty(y.prototype,"destroyed",{enumerable:!1,get:function(){return void 0!==this._writableState&&this._writableState.destroyed},set:function(A){this._writableState&&(this._writableState.destroyed=A)}}),y.prototype.destroy=Q.destroy,y.prototype._undestroy=Q.undestroy,y.prototype._destroy=function(A,e){e(A)}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"../errors":48,"./_stream_duplex":49,"./internal/streams/destroy":56,"./internal/streams/state":60,"./internal/streams/stream":61,_process:154,buffer:64,inherits:134,"util-deprecate":193}],54:[function(A,e,t){(function(t){"use strict";var i;function g(A,e,t){return e in A?Object.defineProperty(A,e,{value:t,enumerable:!0,configurable:!0,writable:!0}):A[e]=t,A}var r=A("./end-of-stream"),n=Symbol("lastResolve"),B=Symbol("lastReject"),I=Symbol("error"),o=Symbol("ended"),a=Symbol("lastPromise"),Q=Symbol("handlePromise"),C=Symbol("stream");function s(A,e){return{value:A,done:e}}function c(A){var e=A[n];if(null!==e){var t=A[C].read();null!==t&&(A[a]=null,A[n]=null,A[B]=null,e(s(t,!1)))}}var h=Object.getPrototypeOf(function(){}),f=Object.setPrototypeOf((g(i={get stream(){return this[C]},next:function(){var A=this,e=this[I];if(null!==e)return Promise.reject(e);if(this[o])return Promise.resolve(s(void 0,!0));if(this[C].destroyed)return new Promise(function(e,i){t.nextTick(function(){A[I]?i(A[I]):e(s(void 0,!0))})});var i,g=this[a];if(g)i=new Promise(function(A,e){return function(t,i){A.then(function(){e[o]?t(s(void 0,!0)):e[Q](t,i)},i)}}(g,this));else{var r=this[C].read();if(null!==r)return Promise.resolve(s(r,!1));i=new Promise(this[Q])}return this[a]=i,i}},Symbol.asyncIterator,function(){return this}),g(i,"return",function(){var A=this;return new Promise(function(e,t){A[C].destroy(null,function(A){A?t(A):e(s(void 0,!0))})})}),i),h);e.exports=function(A){var e,i=Object.create(f,(g(e={},C,{value:A,writable:!0}),g(e,n,{value:null,writable:!0}),g(e,B,{value:null,writable:!0}),g(e,I,{value:null,writable:!0}),g(e,o,{value:A._readableState.endEmitted,writable:!0}),g(e,Q,{value:function(A,e){var t=i[C].read();t?(i[a]=null,i[n]=null,i[B]=null,A(s(t,!1))):(i[n]=A,i[B]=e)},writable:!0}),e));return i[a]=null,r(A,function(A){if(A&&"ERR_STREAM_PREMATURE_CLOSE"!==A.code){var e=i[B];return null!==e&&(i[a]=null,i[n]=null,i[B]=null,e(A)),void(i[I]=A)}var t=i[n];null!==t&&(i[a]=null,i[n]=null,i[B]=null,t(s(void 0,!0))),i[o]=!0}),A.on("readable",function(A){t.nextTick(c,A)}.bind(null,i)),i}}).call(this,A("_process"))},{"./end-of-stream":57,_process:154}],55:[function(A,e,t){"use strict";function i(A,e){var t=Object.keys(A);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(A);e&&(i=i.filter(function(e){return Object.getOwnPropertyDescriptor(A,e).enumerable})),t.push.apply(t,i)}return t}function g(A,e,t){return e in A?Object.defineProperty(A,e,{value:t,enumerable:!0,configurable:!0,writable:!0}):A[e]=t,A}function r(A,e){for(var t=0;t0?this.tail.next=e:this.head=e,this.tail=e,++this.length}},{key:"unshift",value:function(A){var e={data:A,next:this.head};0===this.length&&(this.tail=e),this.head=e,++this.length}},{key:"shift",value:function(){if(0!==this.length){var A=this.head.data;return 1===this.length?this.head=this.tail=null:this.head=this.head.next,--this.length,A}}},{key:"clear",value:function(){this.head=this.tail=null,this.length=0}},{key:"join",value:function(A){if(0===this.length)return"";for(var e=this.head,t=""+e.data;e=e.next;)t+=A+e.data;return t}},{key:"concat",value:function(A){if(0===this.length)return n.alloc(0);for(var e,t,i,g=n.allocUnsafe(A>>>0),r=this.head,B=0;r;)e=r.data,t=g,i=B,n.prototype.copy.call(e,t,i),B+=r.data.length,r=r.next;return g}},{key:"consume",value:function(A,e){var t;return Ag.length?g.length:A;if(r===g.length?i+=g:i+=g.slice(0,A),0===(A-=r)){r===g.length?(++t,e.next?this.head=e.next:this.head=this.tail=null):(this.head=e,e.data=g.slice(r));break}++t}return this.length-=t,i}},{key:"_getBuffer",value:function(A){var e=n.allocUnsafe(A),t=this.head,i=1;for(t.data.copy(e),A-=t.data.length;t=t.next;){var g=t.data,r=A>g.length?g.length:A;if(g.copy(e,e.length-A,0,r),0===(A-=r)){r===g.length?(++i,t.next?this.head=t.next:this.head=this.tail=null):(this.head=t,t.data=g.slice(r));break}++i}return this.length-=i,e}},{key:I,value:function(A,e){return B(this,function(A){for(var e=1;e0,function(A){a||(a=A),A&&C.forEach(I),r||(C.forEach(I),Q(a))})});return t.reduce(o)}},{"../../../errors":48,"./end-of-stream":57}],60:[function(A,e,t){"use strict";var i=A("../../../errors").codes.ERR_INVALID_OPT_VALUE;e.exports={getHighWaterMark:function(A,e,t,g){var r=function(A,e,t){return null!=A.highWaterMark?A.highWaterMark:e?A[t]:null}(e,g,t);if(null!=r){if(!isFinite(r)||Math.floor(r)!==r||r<0)throw new i(g?t:"highWaterMark",r);return Math.floor(r)}return A.objectMode?16:16384}}},{"../../../errors":48}],61:[function(A,e,t){e.exports=A("events").EventEmitter},{events:102}],62:[function(A,e,t){(t=e.exports=A("./lib/_stream_readable.js")).Stream=t,t.Readable=t,t.Writable=A("./lib/_stream_writable.js"),t.Duplex=A("./lib/_stream_duplex.js"),t.Transform=A("./lib/_stream_transform.js"),t.PassThrough=A("./lib/_stream_passthrough.js"),t.finished=A("./lib/internal/streams/end-of-stream.js"),t.pipeline=A("./lib/internal/streams/pipeline.js")},{"./lib/_stream_duplex.js":49,"./lib/_stream_passthrough.js":50,"./lib/_stream_readable.js":51,"./lib/_stream_transform.js":52,"./lib/_stream_writable.js":53,"./lib/internal/streams/end-of-stream.js":57,"./lib/internal/streams/pipeline.js":59}],63:[function(A,e,t){(function(A){e.exports=function(e,t){for(var i=Math.min(e.length,t.length),g=new A(i),r=0;rr)throw new RangeError('The value "'+A+'" is invalid for option "size"');var t=new Uint8Array(A);return t.__proto__=e.prototype,t}function e(A,e,t){if("number"==typeof A){if("string"==typeof e)throw new TypeError('The "string" argument must be of type string. Received type number');return o(A)}return B(A,e,t)}function B(A,t,i){if("string"==typeof A)return function(A,t){"string"==typeof t&&""!==t||(t="utf8");if(!e.isEncoding(t))throw new TypeError("Unknown encoding: "+t);var i=0|C(A,t),g=n(i),r=g.write(A,t);r!==i&&(g=g.slice(0,r));return g}(A,t);if(ArrayBuffer.isView(A))return a(A);if(null==A)throw TypeError("The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type "+typeof A);if(R(A,ArrayBuffer)||A&&R(A.buffer,ArrayBuffer))return function(A,t,i){if(t<0||A.byteLength=r)throw new RangeError("Attempt to allocate Buffer larger than maximum size: 0x"+r.toString(16)+" bytes");return 0|A}function C(A,t){if(e.isBuffer(A))return A.length;if(ArrayBuffer.isView(A)||R(A,ArrayBuffer))return A.byteLength;if("string"!=typeof A)throw new TypeError('The "string" argument must be one of type string, Buffer, or ArrayBuffer. Received type '+typeof A);var i=A.length,g=arguments.length>2&&!0===arguments[2];if(!g&&0===i)return 0;for(var r=!1;;)switch(t){case"ascii":case"latin1":case"binary":return i;case"utf8":case"utf-8":return U(A).length;case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return 2*i;case"hex":return i>>>1;case"base64":return J(A).length;default:if(r)return g?-1:U(A).length;t=(""+t).toLowerCase(),r=!0}}function s(A,e,t){var i=A[e];A[e]=A[t],A[t]=i}function c(A,t,i,g,r){if(0===A.length)return-1;if("string"==typeof i?(g=i,i=0):i>2147483647?i=2147483647:i<-2147483648&&(i=-2147483648),q(i=+i)&&(i=r?0:A.length-1),i<0&&(i=A.length+i),i>=A.length){if(r)return-1;i=A.length-1}else if(i<0){if(!r)return-1;i=0}if("string"==typeof t&&(t=e.from(t,g)),e.isBuffer(t))return 0===t.length?-1:h(A,t,i,g,r);if("number"==typeof t)return t&=255,"function"==typeof Uint8Array.prototype.indexOf?r?Uint8Array.prototype.indexOf.call(A,t,i):Uint8Array.prototype.lastIndexOf.call(A,t,i):h(A,[t],i,g,r);throw new TypeError("val must be string, number or Buffer")}function h(A,e,t,i,g){var r,n=1,B=A.length,I=e.length;if(void 0!==i&&("ucs2"===(i=String(i).toLowerCase())||"ucs-2"===i||"utf16le"===i||"utf-16le"===i)){if(A.length<2||e.length<2)return-1;n=2,B/=2,I/=2,t/=2}function o(A,e){return 1===n?A[e]:A.readUInt16BE(e*n)}if(g){var a=-1;for(r=t;rB&&(t=B-I),r=t;r>=0;r--){for(var Q=!0,C=0;Cg&&(i=g):i=g;var r=e.length;i>r/2&&(i=r/2);for(var n=0;n>8,g=t%256,r.push(g),r.push(i);return r}(e,A.length-t),A,t,i)}function p(A,e,t){return 0===e&&t===A.length?i.fromByteArray(A):i.fromByteArray(A.slice(e,t))}function D(A,e,t){t=Math.min(A.length,t);for(var i=[],g=e;g239?4:o>223?3:o>191?2:1;if(g+Q<=t)switch(Q){case 1:o<128&&(a=o);break;case 2:128==(192&(r=A[g+1]))&&(I=(31&o)<<6|63&r)>127&&(a=I);break;case 3:r=A[g+1],n=A[g+2],128==(192&r)&&128==(192&n)&&(I=(15&o)<<12|(63&r)<<6|63&n)>2047&&(I<55296||I>57343)&&(a=I);break;case 4:r=A[g+1],n=A[g+2],B=A[g+3],128==(192&r)&&128==(192&n)&&128==(192&B)&&(I=(15&o)<<18|(63&r)<<12|(63&n)<<6|63&B)>65535&&I<1114112&&(a=I)}null===a?(a=65533,Q=1):a>65535&&(a-=65536,i.push(a>>>10&1023|55296),a=56320|1023&a),i.push(a),g+=Q}return function(A){var e=A.length;if(e<=b)return String.fromCharCode.apply(String,A);var t="",i=0;for(;ithis.length)return"";if((void 0===t||t>this.length)&&(t=this.length),t<=0)return"";if((t>>>=0)<=(e>>>=0))return"";for(A||(A="utf8");;)switch(A){case"hex":return m(this,e,t);case"utf8":case"utf-8":return D(this,e,t);case"ascii":return y(this,e,t);case"latin1":case"binary":return M(this,e,t);case"base64":return p(this,e,t);case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return G(this,e,t);default:if(i)throw new TypeError("Unknown encoding: "+A);A=(A+"").toLowerCase(),i=!0}}.apply(this,arguments)},e.prototype.toLocaleString=e.prototype.toString,e.prototype.equals=function(A){if(!e.isBuffer(A))throw new TypeError("Argument must be a Buffer");return this===A||0===e.compare(this,A)},e.prototype.inspect=function(){var A="",e=t.INSPECT_MAX_BYTES;return A=this.toString("hex",0,e).replace(/(.{2})/g,"$1 ").trim(),this.length>e&&(A+=" ... "),""},e.prototype.compare=function(A,t,i,g,r){if(R(A,Uint8Array)&&(A=e.from(A,A.offset,A.byteLength)),!e.isBuffer(A))throw new TypeError('The "target" argument must be one of type Buffer or Uint8Array. Received type '+typeof A);if(void 0===t&&(t=0),void 0===i&&(i=A?A.length:0),void 0===g&&(g=0),void 0===r&&(r=this.length),t<0||i>A.length||g<0||r>this.length)throw new RangeError("out of range index");if(g>=r&&t>=i)return 0;if(g>=r)return-1;if(t>=i)return 1;if(t>>>=0,i>>>=0,g>>>=0,r>>>=0,this===A)return 0;for(var n=r-g,B=i-t,I=Math.min(n,B),o=this.slice(g,r),a=A.slice(t,i),Q=0;Q>>=0,isFinite(t)?(t>>>=0,void 0===i&&(i="utf8")):(i=t,t=void 0)}var g=this.length-e;if((void 0===t||t>g)&&(t=g),A.length>0&&(t<0||e<0)||e>this.length)throw new RangeError("Attempt to write outside buffer bounds");i||(i="utf8");for(var r=!1;;)switch(i){case"hex":return f(this,A,e,t);case"utf8":case"utf-8":return E(this,A,e,t);case"ascii":return u(this,A,e,t);case"latin1":case"binary":return d(this,A,e,t);case"base64":return l(this,A,e,t);case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return w(this,A,e,t);default:if(r)throw new TypeError("Unknown encoding: "+i);i=(""+i).toLowerCase(),r=!0}},e.prototype.toJSON=function(){return{type:"Buffer",data:Array.prototype.slice.call(this._arr||this,0)}};var b=4096;function y(A,e,t){var i="";t=Math.min(A.length,t);for(var g=e;gi)&&(t=i);for(var g="",r=e;rt)throw new RangeError("Trying to access beyond buffer length")}function F(A,t,i,g,r,n){if(!e.isBuffer(A))throw new TypeError('"buffer" argument must be a Buffer instance');if(t>r||tA.length)throw new RangeError("Index out of range")}function N(A,e,t,i,g,r){if(t+i>A.length)throw new RangeError("Index out of range");if(t<0)throw new RangeError("Index out of range")}function S(A,e,t,i,r){return e=+e,t>>>=0,r||N(A,0,t,4),g.write(A,e,t,i,23,4),t+4}function Y(A,e,t,i,r){return e=+e,t>>>=0,r||N(A,0,t,8),g.write(A,e,t,i,52,8),t+8}e.prototype.slice=function(A,t){var i=this.length;A=~~A,t=void 0===t?i:~~t,A<0?(A+=i)<0&&(A=0):A>i&&(A=i),t<0?(t+=i)<0&&(t=0):t>i&&(t=i),t>>=0,e>>>=0,t||k(A,e,this.length);for(var i=this[A],g=1,r=0;++r>>=0,e>>>=0,t||k(A,e,this.length);for(var i=this[A+--e],g=1;e>0&&(g*=256);)i+=this[A+--e]*g;return i},e.prototype.readUInt8=function(A,e){return A>>>=0,e||k(A,1,this.length),this[A]},e.prototype.readUInt16LE=function(A,e){return A>>>=0,e||k(A,2,this.length),this[A]|this[A+1]<<8},e.prototype.readUInt16BE=function(A,e){return A>>>=0,e||k(A,2,this.length),this[A]<<8|this[A+1]},e.prototype.readUInt32LE=function(A,e){return A>>>=0,e||k(A,4,this.length),(this[A]|this[A+1]<<8|this[A+2]<<16)+16777216*this[A+3]},e.prototype.readUInt32BE=function(A,e){return A>>>=0,e||k(A,4,this.length),16777216*this[A]+(this[A+1]<<16|this[A+2]<<8|this[A+3])},e.prototype.readIntLE=function(A,e,t){A>>>=0,e>>>=0,t||k(A,e,this.length);for(var i=this[A],g=1,r=0;++r=(g*=128)&&(i-=Math.pow(2,8*e)),i},e.prototype.readIntBE=function(A,e,t){A>>>=0,e>>>=0,t||k(A,e,this.length);for(var i=e,g=1,r=this[A+--i];i>0&&(g*=256);)r+=this[A+--i]*g;return r>=(g*=128)&&(r-=Math.pow(2,8*e)),r},e.prototype.readInt8=function(A,e){return A>>>=0,e||k(A,1,this.length),128&this[A]?-1*(255-this[A]+1):this[A]},e.prototype.readInt16LE=function(A,e){A>>>=0,e||k(A,2,this.length);var t=this[A]|this[A+1]<<8;return 32768&t?4294901760|t:t},e.prototype.readInt16BE=function(A,e){A>>>=0,e||k(A,2,this.length);var t=this[A+1]|this[A]<<8;return 32768&t?4294901760|t:t},e.prototype.readInt32LE=function(A,e){return A>>>=0,e||k(A,4,this.length),this[A]|this[A+1]<<8|this[A+2]<<16|this[A+3]<<24},e.prototype.readInt32BE=function(A,e){return A>>>=0,e||k(A,4,this.length),this[A]<<24|this[A+1]<<16|this[A+2]<<8|this[A+3]},e.prototype.readFloatLE=function(A,e){return A>>>=0,e||k(A,4,this.length),g.read(this,A,!0,23,4)},e.prototype.readFloatBE=function(A,e){return A>>>=0,e||k(A,4,this.length),g.read(this,A,!1,23,4)},e.prototype.readDoubleLE=function(A,e){return A>>>=0,e||k(A,8,this.length),g.read(this,A,!0,52,8)},e.prototype.readDoubleBE=function(A,e){return A>>>=0,e||k(A,8,this.length),g.read(this,A,!1,52,8)},e.prototype.writeUIntLE=function(A,e,t,i){(A=+A,e>>>=0,t>>>=0,i)||F(this,A,e,t,Math.pow(2,8*t)-1,0);var g=1,r=0;for(this[e]=255&A;++r>>=0,t>>>=0,i)||F(this,A,e,t,Math.pow(2,8*t)-1,0);var g=t-1,r=1;for(this[e+g]=255&A;--g>=0&&(r*=256);)this[e+g]=A/r&255;return e+t},e.prototype.writeUInt8=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,1,255,0),this[e]=255&A,e+1},e.prototype.writeUInt16LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,65535,0),this[e]=255&A,this[e+1]=A>>>8,e+2},e.prototype.writeUInt16BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,65535,0),this[e]=A>>>8,this[e+1]=255&A,e+2},e.prototype.writeUInt32LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,4294967295,0),this[e+3]=A>>>24,this[e+2]=A>>>16,this[e+1]=A>>>8,this[e]=255&A,e+4},e.prototype.writeUInt32BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,4294967295,0),this[e]=A>>>24,this[e+1]=A>>>16,this[e+2]=A>>>8,this[e+3]=255&A,e+4},e.prototype.writeIntLE=function(A,e,t,i){if(A=+A,e>>>=0,!i){var g=Math.pow(2,8*t-1);F(this,A,e,t,g-1,-g)}var r=0,n=1,B=0;for(this[e]=255&A;++r>0)-B&255;return e+t},e.prototype.writeIntBE=function(A,e,t,i){if(A=+A,e>>>=0,!i){var g=Math.pow(2,8*t-1);F(this,A,e,t,g-1,-g)}var r=t-1,n=1,B=0;for(this[e+r]=255&A;--r>=0&&(n*=256);)A<0&&0===B&&0!==this[e+r+1]&&(B=1),this[e+r]=(A/n>>0)-B&255;return e+t},e.prototype.writeInt8=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,1,127,-128),A<0&&(A=255+A+1),this[e]=255&A,e+1},e.prototype.writeInt16LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,32767,-32768),this[e]=255&A,this[e+1]=A>>>8,e+2},e.prototype.writeInt16BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,32767,-32768),this[e]=A>>>8,this[e+1]=255&A,e+2},e.prototype.writeInt32LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,2147483647,-2147483648),this[e]=255&A,this[e+1]=A>>>8,this[e+2]=A>>>16,this[e+3]=A>>>24,e+4},e.prototype.writeInt32BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,2147483647,-2147483648),A<0&&(A=4294967295+A+1),this[e]=A>>>24,this[e+1]=A>>>16,this[e+2]=A>>>8,this[e+3]=255&A,e+4},e.prototype.writeFloatLE=function(A,e,t){return S(this,A,e,!0,t)},e.prototype.writeFloatBE=function(A,e,t){return S(this,A,e,!1,t)},e.prototype.writeDoubleLE=function(A,e,t){return Y(this,A,e,!0,t)},e.prototype.writeDoubleBE=function(A,e,t){return Y(this,A,e,!1,t)},e.prototype.copy=function(A,t,i,g){if(!e.isBuffer(A))throw new TypeError("argument should be a Buffer");if(i||(i=0),g||0===g||(g=this.length),t>=A.length&&(t=A.length),t||(t=0),g>0&&g=this.length)throw new RangeError("Index out of range");if(g<0)throw new RangeError("sourceEnd out of bounds");g>this.length&&(g=this.length),A.length-t=0;--n)A[n+t]=this[n+i];else Uint8Array.prototype.set.call(A,this.subarray(i,g),t);return r},e.prototype.fill=function(A,t,i,g){if("string"==typeof A){if("string"==typeof t?(g=t,t=0,i=this.length):"string"==typeof i&&(g=i,i=this.length),void 0!==g&&"string"!=typeof g)throw new TypeError("encoding must be a string");if("string"==typeof g&&!e.isEncoding(g))throw new TypeError("Unknown encoding: "+g);if(1===A.length){var r=A.charCodeAt(0);("utf8"===g&&r<128||"latin1"===g)&&(A=r)}}else"number"==typeof A&&(A&=255);if(t<0||this.length>>=0,i=void 0===i?this.length:i>>>0,A||(A=0),"number"==typeof A)for(n=t;n55295&&t<57344){if(!g){if(t>56319){(e-=3)>-1&&r.push(239,191,189);continue}if(n+1===i){(e-=3)>-1&&r.push(239,191,189);continue}g=t;continue}if(t<56320){(e-=3)>-1&&r.push(239,191,189),g=t;continue}t=65536+(g-55296<<10|t-56320)}else g&&(e-=3)>-1&&r.push(239,191,189);if(g=null,t<128){if((e-=1)<0)break;r.push(t)}else if(t<2048){if((e-=2)<0)break;r.push(t>>6|192,63&t|128)}else if(t<65536){if((e-=3)<0)break;r.push(t>>12|224,t>>6&63|128,63&t|128)}else{if(!(t<1114112))throw new Error("Invalid code point");if((e-=4)<0)break;r.push(t>>18|240,t>>12&63|128,t>>6&63|128,63&t|128)}}return r}function J(A){return i.toByteArray(function(A){if((A=(A=A.split("=")[0]).trim().replace(v,"")).length<2)return"";for(;A.length%4!=0;)A+="=";return A}(A))}function H(A,e,t,i){for(var g=0;g=e.length||g>=A.length);++g)e[g+t]=A[g];return g}function R(A,e){return A instanceof e||null!=A&&null!=A.constructor&&null!=A.constructor.name&&A.constructor.name===e.name}function q(A){return A!=A}}).call(this,A("buffer").Buffer)},{"base64-js":16,buffer:64,ieee754:133}],65:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("stream").Transform,r=A("string_decoder").StringDecoder;function n(A){g.call(this),this.hashMode="string"==typeof A,this.hashMode?this[A]=this._finalOrDigest:this.final=this._finalOrDigest,this._final&&(this.__final=this._final,this._final=null),this._decoder=null,this._encoding=null}A("inherits")(n,g),n.prototype.update=function(A,e,t){"string"==typeof A&&(A=i.from(A,e));var g=this._update(A);return this.hashMode?this:(t&&(g=this._toString(g,t)),g)},n.prototype.setAutoPadding=function(){},n.prototype.getAuthTag=function(){throw new Error("trying to get auth tag in unsupported state")},n.prototype.setAuthTag=function(){throw new Error("trying to set auth tag in unsupported state")},n.prototype.setAAD=function(){throw new Error("trying to set aad in unsupported state")},n.prototype._transform=function(A,e,t){var i;try{this.hashMode?this._update(A):this.push(this._update(A))}catch(A){i=A}finally{t(i)}},n.prototype._flush=function(A){var e;try{this.push(this.__final())}catch(A){e=A}A(e)},n.prototype._finalOrDigest=function(A){var e=this.__final()||i.alloc(0);return A&&(e=this._toString(e,A,!0)),e},n.prototype._toString=function(A,e,t){if(this._decoder||(this._decoder=new r(e),this._encoding=e),this._encoding!==e)throw new Error("can't switch encodings");var i=this._decoder.write(A);return t&&(i+=this._decoder.end()),i},e.exports=n},{inherits:134,"safe-buffer":180,stream:190,string_decoder:191}],66:[function(A,e,t){(function(A){function e(A){return Object.prototype.toString.call(A)}t.isArray=function(A){return Array.isArray?Array.isArray(A):"[object Array]"===e(A)},t.isBoolean=function(A){return"boolean"==typeof A},t.isNull=function(A){return null===A},t.isNullOrUndefined=function(A){return null==A},t.isNumber=function(A){return"number"==typeof A},t.isString=function(A){return"string"==typeof A},t.isSymbol=function(A){return"symbol"==typeof A},t.isUndefined=function(A){return void 0===A},t.isRegExp=function(A){return"[object RegExp]"===e(A)},t.isObject=function(A){return"object"==typeof A&&null!==A},t.isDate=function(A){return"[object Date]"===e(A)},t.isError=function(A){return"[object Error]"===e(A)||A instanceof Error},t.isFunction=function(A){return"function"==typeof A},t.isPrimitive=function(A){return null===A||"boolean"==typeof A||"number"==typeof A||"string"==typeof A||"symbol"==typeof A||void 0===A},t.isBuffer=A.isBuffer}).call(this,{isBuffer:A("../../is-buffer/index.js")})},{"../../is-buffer/index.js":135}],67:[function(A,e,t){(function(t){var i=A("elliptic"),g=A("bn.js");e.exports=function(A){return new n(A)};var r={secp256k1:{name:"secp256k1",byteLength:32},secp224r1:{name:"p224",byteLength:28},prime256v1:{name:"p256",byteLength:32},prime192v1:{name:"p192",byteLength:24},ed25519:{name:"ed25519",byteLength:32},secp384r1:{name:"p384",byteLength:48},secp521r1:{name:"p521",byteLength:66}};function n(A){this.curveType=r[A],this.curveType||(this.curveType={name:A}),this.curve=new i.ec(this.curveType.name),this.keys=void 0}function B(A,e,i){Array.isArray(A)||(A=A.toArray());var g=new t(A);if(i&&g.lengtht)?e=("rmd160"===A?new I:o(A)).update(e).digest():e.lengthB?e=A(e):e.length0;i--)e+=this._buffer(A,e),t+=this._flushBuffer(g,t);return e+=this._buffer(A,e),g},g.prototype.final=function(A){var e,t;return A&&(e=this.update(A)),t="encrypt"===this.type?this._finalEncrypt():this._finalDecrypt(),e?e.concat(t):t},g.prototype._pad=function(A,e){if(0===e)return!1;for(;e>>1];t=r.r28shl(t,B),g=r.r28shl(g,B),r.pc2(t,g,A.keys,n)}},B.prototype._update=function(A,e,t,i){var g=this._desState,n=r.readUInt32BE(A,e),B=r.readUInt32BE(A,e+4);r.ip(n,B,g.tmp,0),n=g.tmp[0],B=g.tmp[1],"encrypt"===this.type?this._encrypt(g,n,B,g.tmp,0):this._decrypt(g,n,B,g.tmp,0),n=g.tmp[0],B=g.tmp[1],r.writeUInt32BE(t,n,i),r.writeUInt32BE(t,B,i+4)},B.prototype._pad=function(A,e){for(var t=A.length-e,i=e;i>>0,n=C}r.rip(B,n,i,g)},B.prototype._decrypt=function(A,e,t,i,g){for(var n=t,B=e,I=A.keys.length-2;I>=0;I-=2){var o=A.keys[I],a=A.keys[I+1];r.expand(n,A.tmp,0),o^=A.tmp[0],a^=A.tmp[1];var Q=r.substitute(o,a),C=n;n=(B^r.permute(Q))>>>0,B=C}r.rip(n,B,i,g)}},{"./cipher":76,"./utils":79,inherits:134,"minimalistic-assert":140}],78:[function(A,e,t){"use strict";var i=A("minimalistic-assert"),g=A("inherits"),r=A("./cipher"),n=A("./des");function B(A){r.call(this,A);var e=new function(A,e){i.equal(e.length,24,"Invalid key length");var t=e.slice(0,8),g=e.slice(8,16),r=e.slice(16,24);this.ciphers="encrypt"===A?[n.create({type:"encrypt",key:t}),n.create({type:"decrypt",key:g}),n.create({type:"encrypt",key:r})]:[n.create({type:"decrypt",key:r}),n.create({type:"encrypt",key:g}),n.create({type:"decrypt",key:t})]}(this.type,this.options.key);this._edeState=e}g(B,r),e.exports=B,B.create=function(A){return new B(A)},B.prototype._update=function(A,e,t,i){var g=this._edeState;g.ciphers[0]._update(A,e,t,i),g.ciphers[1]._update(t,i,t,i),g.ciphers[2]._update(t,i,t,i)},B.prototype._pad=n.prototype._pad,B.prototype._unpad=n.prototype._unpad},{"./cipher":76,"./des":77,inherits:134,"minimalistic-assert":140}],79:[function(A,e,t){"use strict";t.readUInt32BE=function(A,e){return(A[0+e]<<24|A[1+e]<<16|A[2+e]<<8|A[3+e])>>>0},t.writeUInt32BE=function(A,e,t){A[0+t]=e>>>24,A[1+t]=e>>>16&255,A[2+t]=e>>>8&255,A[3+t]=255&e},t.ip=function(A,e,t,i){for(var g=0,r=0,n=6;n>=0;n-=2){for(var B=0;B<=24;B+=8)g<<=1,g|=e>>>B+n&1;for(B=0;B<=24;B+=8)g<<=1,g|=A>>>B+n&1}for(n=6;n>=0;n-=2){for(B=1;B<=25;B+=8)r<<=1,r|=e>>>B+n&1;for(B=1;B<=25;B+=8)r<<=1,r|=A>>>B+n&1}t[i+0]=g>>>0,t[i+1]=r>>>0},t.rip=function(A,e,t,i){for(var g=0,r=0,n=0;n<4;n++)for(var B=24;B>=0;B-=8)g<<=1,g|=e>>>B+n&1,g<<=1,g|=A>>>B+n&1;for(n=4;n<8;n++)for(B=24;B>=0;B-=8)r<<=1,r|=e>>>B+n&1,r<<=1,r|=A>>>B+n&1;t[i+0]=g>>>0,t[i+1]=r>>>0},t.pc1=function(A,e,t,i){for(var g=0,r=0,n=7;n>=5;n--){for(var B=0;B<=24;B+=8)g<<=1,g|=e>>B+n&1;for(B=0;B<=24;B+=8)g<<=1,g|=A>>B+n&1}for(B=0;B<=24;B+=8)g<<=1,g|=e>>B+n&1;for(n=1;n<=3;n++){for(B=0;B<=24;B+=8)r<<=1,r|=e>>B+n&1;for(B=0;B<=24;B+=8)r<<=1,r|=A>>B+n&1}for(B=0;B<=24;B+=8)r<<=1,r|=A>>B+n&1;t[i+0]=g>>>0,t[i+1]=r>>>0},t.r28shl=function(A,e){return A<>>28-e};var i=[14,11,17,4,27,23,25,0,13,22,7,18,5,9,16,24,2,20,12,21,1,8,15,26,15,4,25,19,9,1,26,16,5,11,23,8,12,7,17,0,22,3,10,14,6,20,27,24];t.pc2=function(A,e,t,g){for(var r=0,n=0,B=i.length>>>1,I=0;I>>i[I]&1;for(I=B;I>>i[I]&1;t[g+0]=r>>>0,t[g+1]=n>>>0},t.expand=function(A,e,t){var i=0,g=0;i=(1&A)<<5|A>>>27;for(var r=23;r>=15;r-=4)i<<=6,i|=A>>>r&63;for(r=11;r>=3;r-=4)g|=A>>>r&63,g<<=6;g|=(31&A)<<1|A>>>31,e[t+0]=i>>>0,e[t+1]=g>>>0};var g=[14,0,4,15,13,7,1,4,2,14,15,2,11,13,8,1,3,10,10,6,6,12,12,11,5,9,9,5,0,3,7,8,4,15,1,12,14,8,8,2,13,4,6,9,2,1,11,7,15,5,12,11,9,3,7,14,3,10,10,0,5,6,0,13,15,3,1,13,8,4,14,7,6,15,11,2,3,8,4,14,9,12,7,0,2,1,13,10,12,6,0,9,5,11,10,5,0,13,14,8,7,10,11,1,10,3,4,15,13,4,1,2,5,11,8,6,12,7,6,12,9,0,3,5,2,14,15,9,10,13,0,7,9,0,14,9,6,3,3,4,15,6,5,10,1,2,13,8,12,5,7,14,11,12,4,11,2,15,8,1,13,1,6,10,4,13,9,0,8,6,15,9,3,8,0,7,11,4,1,15,2,14,12,3,5,11,10,5,14,2,7,12,7,13,13,8,14,11,3,5,0,6,6,15,9,0,10,3,1,4,2,7,8,2,5,12,11,1,12,10,4,14,15,9,10,3,6,15,9,0,0,6,12,10,11,1,7,13,13,8,15,9,1,4,3,5,14,11,5,12,2,7,8,2,4,14,2,14,12,11,4,2,1,12,7,4,10,7,11,13,6,1,8,5,5,0,3,15,15,10,13,3,0,9,14,8,9,6,4,11,2,8,1,12,11,7,10,1,13,14,7,2,8,13,15,6,9,15,12,0,5,9,6,10,3,4,0,5,14,3,12,10,1,15,10,4,15,2,9,7,2,12,6,9,8,5,0,6,13,1,3,13,4,14,14,0,7,11,5,3,11,8,9,4,14,3,15,2,5,12,2,9,8,5,12,15,3,10,7,11,0,14,4,1,10,7,1,6,13,0,11,8,6,13,4,13,11,0,2,11,14,7,15,4,0,9,8,1,13,10,3,14,12,3,9,5,7,12,5,2,10,15,6,8,1,6,1,6,4,11,11,13,13,8,12,1,3,4,7,10,14,7,10,9,15,5,6,0,8,15,0,14,5,2,9,3,2,12,13,1,2,15,8,13,4,8,6,10,15,3,11,7,1,4,10,12,9,5,3,6,14,11,5,0,0,14,12,9,7,2,7,2,11,1,4,14,1,7,9,4,12,10,14,8,2,13,0,15,6,12,10,9,13,0,15,3,3,5,5,6,8,11];t.substitute=function(A,e){for(var t=0,i=0;i<4;i++){t<<=4,t|=g[64*i+(A>>>18-6*i&63)]}for(i=0;i<4;i++){t<<=4,t|=g[256+64*i+(e>>>18-6*i&63)]}return t>>>0};var r=[16,25,12,11,3,20,4,15,31,17,9,6,27,14,1,22,30,24,8,18,0,5,29,23,13,19,2,26,10,21,28,7];t.permute=function(A){for(var e=0,t=0;t>>r[t]&1;return e>>>0},t.padSplit=function(A,e,t){for(var i=A.toString(2);i.lengthA;)t.ishrn(1);if(t.isEven()&&t.iadd(B),t.testn(1)||t.iadd(I),e.cmp(I)){if(!e.cmp(o))for(;t.mod(a).cmp(Q);)t.iadd(s)}else for(;t.mod(r).cmp(C);)t.iadd(s);if(f(c=t.shrn(1))&&f(t)&&E(c)&&E(t)&&n.test(c)&&n.test(t))return t}}},{"bn.js":84,"miller-rabin":138,randombytes:162}],83:[function(A,e,t){e.exports={modp1:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a63a3620ffffffffffffffff"},modp2:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece65381ffffffffffffffff"},modp5:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca237327ffffffffffffffff"},modp14:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aacaa68ffffffffffffffff"},modp15:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a93ad2caffffffffffffffff"},modp16:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c934063199ffffffffffffffff"},modp17:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dcc4024ffffffffffffffff"},modp18:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dbe115974a3926f12fee5e438777cb6a932df8cd8bec4d073b931ba3bc832b68d9dd300741fa7bf8afc47ed2576f6936ba424663aab639c5ae4f5683423b4742bf1c978238f16cbe39d652de3fdb8befc848ad922222e04a4037c0713eb57a81a23f0c73473fc646cea306b4bcbc8862f8385ddfa9d4b7fa2c087e879683303ed5bdd3a062b3cf5b3a278a66d2a13f83f44f82ddf310ee074ab6a364597e899a0255dc164f31cc50846851df9ab48195ded7ea1b1d510bd7ee74d73faf36bc31ecfa268359046f4eb879f924009438b481c6cd7889a002ed5ee382bc9190da6fc026e479558e4475677e9aa9e3050e2765694dfc81f56e880b96e7160c980dd98edd3dfffffffffffffffff"}}},{}],84:[function(A,e,t){arguments[4][15][0].apply(t,arguments)},{buffer:19,dup:15}],85:[function(A,e,t){"use strict";var i=t;i.version=A("../package.json").version,i.utils=A("./elliptic/utils"),i.rand=A("brorand"),i.curve=A("./elliptic/curve"),i.curves=A("./elliptic/curves"),i.ec=A("./elliptic/ec"),i.eddsa=A("./elliptic/eddsa")},{"../package.json":101,"./elliptic/curve":88,"./elliptic/curves":91,"./elliptic/ec":92,"./elliptic/eddsa":95,"./elliptic/utils":99,brorand:18}],86:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("../utils"),r=g.getNAF,n=g.getJSF,B=g.assert;function I(A,e){this.type=A,this.p=new i(e.p,16),this.red=e.prime?i.red(e.prime):i.mont(this.p),this.zero=new i(0).toRed(this.red),this.one=new i(1).toRed(this.red),this.two=new i(2).toRed(this.red),this.n=e.n&&new i(e.n,16),this.g=e.g&&this.pointFromJSON(e.g,e.gRed),this._wnafT1=new Array(4),this._wnafT2=new Array(4),this._wnafT3=new Array(4),this._wnafT4=new Array(4),this._bitLength=this.n?this.n.bitLength():0;var t=this.n&&this.p.div(this.n);!t||t.cmpn(100)>0?this.redN=null:(this._maxwellTrick=!0,this.redN=this.n.toRed(this.red))}function o(A,e){this.curve=A,this.type=e,this.precomputed=null}e.exports=I,I.prototype.point=function(){throw new Error("Not implemented")},I.prototype.validate=function(){throw new Error("Not implemented")},I.prototype._fixedNafMul=function(A,e){B(A.precomputed);var t=A._getDoubles(),i=r(e,1,this._bitLength),g=(1<=I;e--)o=(o<<1)+i[e];n.push(o)}for(var a=this.jpoint(null,null,null),Q=this.jpoint(null,null,null),C=g;C>0;C--){for(I=0;I=0;o--){for(e=0;o>=0&&0===n[o];o--)e++;if(o>=0&&e++,I=I.dblp(e),o<0)break;var a=n[o];B(0!==a),I="affine"===A.type?a>0?I.mixedAdd(g[a-1>>1]):I.mixedAdd(g[-a-1>>1].neg()):a>0?I.add(g[a-1>>1]):I.add(g[-a-1>>1].neg())}return"affine"===A.type?I.toP():I},I.prototype._wnafMulAdd=function(A,e,t,i,g){for(var B=this._wnafT1,I=this._wnafT2,o=this._wnafT3,a=0,Q=0;Q=1;Q-=2){var s=Q-1,c=Q;if(1===B[s]&&1===B[c]){var h=[e[s],null,null,e[c]];0===e[s].y.cmp(e[c].y)?(h[1]=e[s].add(e[c]),h[2]=e[s].toJ().mixedAdd(e[c].neg())):0===e[s].y.cmp(e[c].y.redNeg())?(h[1]=e[s].toJ().mixedAdd(e[c]),h[2]=e[s].add(e[c].neg())):(h[1]=e[s].toJ().mixedAdd(e[c]),h[2]=e[s].toJ().mixedAdd(e[c].neg()));var f=[-3,-1,-5,-7,0,7,5,1,3],E=n(t[s],t[c]);a=Math.max(E[0].length,a),o[s]=new Array(a),o[c]=new Array(a);for(var u=0;u=0;Q--){for(var D=0;Q>=0;){var b=!0;for(u=0;u=0&&D++,w=w.dblp(D),Q<0)break;for(u=0;u0?y=I[u][M-1>>1]:M<0&&(y=I[u][-M-1>>1].neg()),w="affine"===y.type?w.mixedAdd(y):w.add(y))}}for(Q=0;Q=Math.ceil((A.bitLength()+1)/e.step)},o.prototype._getDoubles=function(A,e){if(this.precomputed&&this.precomputed.doubles)return this.precomputed.doubles;for(var t=[this],i=this,g=0;g":""},o.prototype.isInfinity=function(){return 0===this.x.cmpn(0)&&(0===this.y.cmp(this.z)||this.zOne&&0===this.y.cmp(this.curve.c))},o.prototype._extDbl=function(){var A=this.x.redSqr(),e=this.y.redSqr(),t=this.z.redSqr();t=t.redIAdd(t);var i=this.curve._mulA(A),g=this.x.redAdd(this.y).redSqr().redISub(A).redISub(e),r=i.redAdd(e),n=r.redSub(t),B=i.redSub(e),I=g.redMul(n),o=r.redMul(B),a=g.redMul(B),Q=n.redMul(r);return this.curve.point(I,o,Q,a)},o.prototype._projDbl=function(){var A,e,t,i=this.x.redAdd(this.y).redSqr(),g=this.x.redSqr(),r=this.y.redSqr();if(this.curve.twisted){var n=(o=this.curve._mulA(g)).redAdd(r);if(this.zOne)A=i.redSub(g).redSub(r).redMul(n.redSub(this.curve.two)),e=n.redMul(o.redSub(r)),t=n.redSqr().redSub(n).redSub(n);else{var B=this.z.redSqr(),I=n.redSub(B).redISub(B);A=i.redSub(g).redISub(r).redMul(I),e=n.redMul(o.redSub(r)),t=n.redMul(I)}}else{var o=g.redAdd(r);B=this.curve._mulC(this.z).redSqr(),I=o.redSub(B).redSub(B);A=this.curve._mulC(i.redISub(o)).redMul(I),e=this.curve._mulC(o).redMul(g.redISub(r)),t=o.redMul(I)}return this.curve.point(A,e,t)},o.prototype.dbl=function(){return this.isInfinity()?this:this.curve.extended?this._extDbl():this._projDbl()},o.prototype._extAdd=function(A){var e=this.y.redSub(this.x).redMul(A.y.redSub(A.x)),t=this.y.redAdd(this.x).redMul(A.y.redAdd(A.x)),i=this.t.redMul(this.curve.dd).redMul(A.t),g=this.z.redMul(A.z.redAdd(A.z)),r=t.redSub(e),n=g.redSub(i),B=g.redAdd(i),I=t.redAdd(e),o=r.redMul(n),a=B.redMul(I),Q=r.redMul(I),C=n.redMul(B);return this.curve.point(o,a,C,Q)},o.prototype._projAdd=function(A){var e,t,i=this.z.redMul(A.z),g=i.redSqr(),r=this.x.redMul(A.x),n=this.y.redMul(A.y),B=this.curve.d.redMul(r).redMul(n),I=g.redSub(B),o=g.redAdd(B),a=this.x.redAdd(this.y).redMul(A.x.redAdd(A.y)).redISub(r).redISub(n),Q=i.redMul(I).redMul(a);return this.curve.twisted?(e=i.redMul(o).redMul(n.redSub(this.curve._mulA(r))),t=I.redMul(o)):(e=i.redMul(o).redMul(n.redSub(r)),t=this.curve._mulC(I).redMul(o)),this.curve.point(Q,e,t)},o.prototype.add=function(A){return this.isInfinity()?A:A.isInfinity()?this:this.curve.extended?this._extAdd(A):this._projAdd(A)},o.prototype.mul=function(A){return this._hasDoubles(A)?this.curve._fixedNafMul(this,A):this.curve._wnafMul(this,A)},o.prototype.mulAdd=function(A,e,t){return this.curve._wnafMulAdd(1,[this,e],[A,t],2,!1)},o.prototype.jmulAdd=function(A,e,t){return this.curve._wnafMulAdd(1,[this,e],[A,t],2,!0)},o.prototype.normalize=function(){if(this.zOne)return this;var A=this.z.redInvm();return this.x=this.x.redMul(A),this.y=this.y.redMul(A),this.t&&(this.t=this.t.redMul(A)),this.z=this.curve.one,this.zOne=!0,this},o.prototype.neg=function(){return this.curve.point(this.x.redNeg(),this.y,this.z,this.t&&this.t.redNeg())},o.prototype.getX=function(){return this.normalize(),this.x.fromRed()},o.prototype.getY=function(){return this.normalize(),this.y.fromRed()},o.prototype.eq=function(A){return this===A||0===this.getX().cmp(A.getX())&&0===this.getY().cmp(A.getY())},o.prototype.eqXToP=function(A){var e=A.toRed(this.curve.red).redMul(this.z);if(0===this.x.cmp(e))return!0;for(var t=A.clone(),i=this.curve.redN.redMul(this.z);;){if(t.iadd(this.curve.n),t.cmp(this.curve.p)>=0)return!1;if(e.redIAdd(i),0===this.x.cmp(e))return!0}},o.prototype.toP=o.prototype.normalize,o.prototype.mixedAdd=o.prototype.add},{"../utils":99,"./base":86,"bn.js":100,inherits:134}],88:[function(A,e,t){"use strict";var i=t;i.base=A("./base"),i.short=A("./short"),i.mont=A("./mont"),i.edwards=A("./edwards")},{"./base":86,"./edwards":87,"./mont":89,"./short":90}],89:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("inherits"),r=A("./base"),n=A("../utils");function B(A){r.call(this,"mont",A),this.a=new i(A.a,16).toRed(this.red),this.b=new i(A.b,16).toRed(this.red),this.i4=new i(4).toRed(this.red).redInvm(),this.two=new i(2).toRed(this.red),this.a24=this.i4.redMul(this.a.redAdd(this.two))}function I(A,e,t){r.BasePoint.call(this,A,"projective"),null===e&&null===t?(this.x=this.curve.one,this.z=this.curve.zero):(this.x=new i(e,16),this.z=new i(t,16),this.x.red||(this.x=this.x.toRed(this.curve.red)),this.z.red||(this.z=this.z.toRed(this.curve.red)))}g(B,r),e.exports=B,B.prototype.validate=function(A){var e=A.normalize().x,t=e.redSqr(),i=t.redMul(e).redAdd(t.redMul(this.a)).redAdd(e);return 0===i.redSqrt().redSqr().cmp(i)},g(I,r.BasePoint),B.prototype.decodePoint=function(A,e){return this.point(n.toArray(A,e),1)},B.prototype.point=function(A,e){return new I(this,A,e)},B.prototype.pointFromJSON=function(A){return I.fromJSON(this,A)},I.prototype.precompute=function(){},I.prototype._encode=function(){return this.getX().toArray("be",this.curve.p.byteLength())},I.fromJSON=function(A,e){return new I(A,e[0],e[1]||A.one)},I.prototype.inspect=function(){return this.isInfinity()?"":""},I.prototype.isInfinity=function(){return 0===this.z.cmpn(0)},I.prototype.dbl=function(){var A=this.x.redAdd(this.z).redSqr(),e=this.x.redSub(this.z).redSqr(),t=A.redSub(e),i=A.redMul(e),g=t.redMul(e.redAdd(this.curve.a24.redMul(t)));return this.curve.point(i,g)},I.prototype.add=function(){throw new Error("Not supported on Montgomery curve")},I.prototype.diffAdd=function(A,e){var t=this.x.redAdd(this.z),i=this.x.redSub(this.z),g=A.x.redAdd(A.z),r=A.x.redSub(A.z).redMul(t),n=g.redMul(i),B=e.z.redMul(r.redAdd(n).redSqr()),I=e.x.redMul(r.redISub(n).redSqr());return this.curve.point(B,I)},I.prototype.mul=function(A){for(var e=A.clone(),t=this,i=this.curve.point(null,null),g=[];0!==e.cmpn(0);e.iushrn(1))g.push(e.andln(1));for(var r=g.length-1;r>=0;r--)0===g[r]?(t=t.diffAdd(i,this),i=i.dbl()):(i=t.diffAdd(i,this),t=t.dbl());return i},I.prototype.mulAdd=function(){throw new Error("Not supported on Montgomery curve")},I.prototype.jumlAdd=function(){throw new Error("Not supported on Montgomery curve")},I.prototype.eq=function(A){return 0===this.getX().cmp(A.getX())},I.prototype.normalize=function(){return this.x=this.x.redMul(this.z.redInvm()),this.z=this.curve.one,this},I.prototype.getX=function(){return this.normalize(),this.x.fromRed()}},{"../utils":99,"./base":86,"bn.js":100,inherits:134}],90:[function(A,e,t){"use strict";var i=A("../utils"),g=A("bn.js"),r=A("inherits"),n=A("./base"),B=i.assert;function I(A){n.call(this,"short",A),this.a=new g(A.a,16).toRed(this.red),this.b=new g(A.b,16).toRed(this.red),this.tinv=this.two.redInvm(),this.zeroA=0===this.a.fromRed().cmpn(0),this.threeA=0===this.a.fromRed().sub(this.p).cmpn(-3),this.endo=this._getEndomorphism(A),this._endoWnafT1=new Array(4),this._endoWnafT2=new Array(4)}function o(A,e,t,i){n.BasePoint.call(this,A,"affine"),null===e&&null===t?(this.x=null,this.y=null,this.inf=!0):(this.x=new g(e,16),this.y=new g(t,16),i&&(this.x.forceRed(this.curve.red),this.y.forceRed(this.curve.red)),this.x.red||(this.x=this.x.toRed(this.curve.red)),this.y.red||(this.y=this.y.toRed(this.curve.red)),this.inf=!1)}function a(A,e,t,i){n.BasePoint.call(this,A,"jacobian"),null===e&&null===t&&null===i?(this.x=this.curve.one,this.y=this.curve.one,this.z=new g(0)):(this.x=new g(e,16),this.y=new g(t,16),this.z=new g(i,16)),this.x.red||(this.x=this.x.toRed(this.curve.red)),this.y.red||(this.y=this.y.toRed(this.curve.red)),this.z.red||(this.z=this.z.toRed(this.curve.red)),this.zOne=this.z===this.curve.one}r(I,n),e.exports=I,I.prototype._getEndomorphism=function(A){if(this.zeroA&&this.g&&this.n&&1===this.p.modn(3)){var e,t;if(A.beta)e=new g(A.beta,16).toRed(this.red);else{var i=this._getEndoRoots(this.p);e=(e=i[0].cmp(i[1])<0?i[0]:i[1]).toRed(this.red)}if(A.lambda)t=new g(A.lambda,16);else{var r=this._getEndoRoots(this.n);0===this.g.mul(r[0]).x.cmp(this.g.x.redMul(e))?t=r[0]:(t=r[1],B(0===this.g.mul(t).x.cmp(this.g.x.redMul(e))))}return{beta:e,lambda:t,basis:A.basis?A.basis.map(function(A){return{a:new g(A.a,16),b:new g(A.b,16)}}):this._getEndoBasis(t)}}},I.prototype._getEndoRoots=function(A){var e=A===this.p?this.red:g.mont(A),t=new g(2).toRed(e).redInvm(),i=t.redNeg(),r=new g(3).toRed(e).redNeg().redSqrt().redMul(t);return[i.redAdd(r).fromRed(),i.redSub(r).fromRed()]},I.prototype._getEndoBasis=function(A){for(var e,t,i,r,n,B,I,o,a,Q=this.n.ushrn(Math.floor(this.n.bitLength()/2)),C=A,s=this.n.clone(),c=new g(1),h=new g(0),f=new g(0),E=new g(1),u=0;0!==C.cmpn(0);){var d=s.div(C);o=s.sub(d.mul(C)),a=f.sub(d.mul(c));var l=E.sub(d.mul(h));if(!i&&o.cmp(Q)<0)e=I.neg(),t=c,i=o.neg(),r=a;else if(i&&2==++u)break;I=o,s=C,C=o,f=c,c=a,E=h,h=l}n=o.neg(),B=a;var w=i.sqr().add(r.sqr());return n.sqr().add(B.sqr()).cmp(w)>=0&&(n=e,B=t),i.negative&&(i=i.neg(),r=r.neg()),n.negative&&(n=n.neg(),B=B.neg()),[{a:i,b:r},{a:n,b:B}]},I.prototype._endoSplit=function(A){var e=this.endo.basis,t=e[0],i=e[1],g=i.b.mul(A).divRound(this.n),r=t.b.neg().mul(A).divRound(this.n),n=g.mul(t.a),B=r.mul(i.a),I=g.mul(t.b),o=r.mul(i.b);return{k1:A.sub(n).sub(B),k2:I.add(o).neg()}},I.prototype.pointFromX=function(A,e){(A=new g(A,16)).red||(A=A.toRed(this.red));var t=A.redSqr().redMul(A).redIAdd(A.redMul(this.a)).redIAdd(this.b),i=t.redSqrt();if(0!==i.redSqr().redSub(t).cmp(this.zero))throw new Error("invalid point");var r=i.fromRed().isOdd();return(e&&!r||!e&&r)&&(i=i.redNeg()),this.point(A,i)},I.prototype.validate=function(A){if(A.inf)return!0;var e=A.x,t=A.y,i=this.a.redMul(e),g=e.redSqr().redMul(e).redIAdd(i).redIAdd(this.b);return 0===t.redSqr().redISub(g).cmpn(0)},I.prototype._endoWnafMulAdd=function(A,e,t){for(var i=this._endoWnafT1,g=this._endoWnafT2,r=0;r":""},o.prototype.isInfinity=function(){return this.inf},o.prototype.add=function(A){if(this.inf)return A;if(A.inf)return this;if(this.eq(A))return this.dbl();if(this.neg().eq(A))return this.curve.point(null,null);if(0===this.x.cmp(A.x))return this.curve.point(null,null);var e=this.y.redSub(A.y);0!==e.cmpn(0)&&(e=e.redMul(this.x.redSub(A.x).redInvm()));var t=e.redSqr().redISub(this.x).redISub(A.x),i=e.redMul(this.x.redSub(t)).redISub(this.y);return this.curve.point(t,i)},o.prototype.dbl=function(){if(this.inf)return this;var A=this.y.redAdd(this.y);if(0===A.cmpn(0))return this.curve.point(null,null);var e=this.curve.a,t=this.x.redSqr(),i=A.redInvm(),g=t.redAdd(t).redIAdd(t).redIAdd(e).redMul(i),r=g.redSqr().redISub(this.x.redAdd(this.x)),n=g.redMul(this.x.redSub(r)).redISub(this.y);return this.curve.point(r,n)},o.prototype.getX=function(){return this.x.fromRed()},o.prototype.getY=function(){return this.y.fromRed()},o.prototype.mul=function(A){return A=new g(A,16),this.isInfinity()?this:this._hasDoubles(A)?this.curve._fixedNafMul(this,A):this.curve.endo?this.curve._endoWnafMulAdd([this],[A]):this.curve._wnafMul(this,A)},o.prototype.mulAdd=function(A,e,t){var i=[this,e],g=[A,t];return this.curve.endo?this.curve._endoWnafMulAdd(i,g):this.curve._wnafMulAdd(1,i,g,2)},o.prototype.jmulAdd=function(A,e,t){var i=[this,e],g=[A,t];return this.curve.endo?this.curve._endoWnafMulAdd(i,g,!0):this.curve._wnafMulAdd(1,i,g,2,!0)},o.prototype.eq=function(A){return this===A||this.inf===A.inf&&(this.inf||0===this.x.cmp(A.x)&&0===this.y.cmp(A.y))},o.prototype.neg=function(A){if(this.inf)return this;var e=this.curve.point(this.x,this.y.redNeg());if(A&&this.precomputed){var t=this.precomputed,i=function(A){return A.neg()};e.precomputed={naf:t.naf&&{wnd:t.naf.wnd,points:t.naf.points.map(i)},doubles:t.doubles&&{step:t.doubles.step,points:t.doubles.points.map(i)}}}return e},o.prototype.toJ=function(){return this.inf?this.curve.jpoint(null,null,null):this.curve.jpoint(this.x,this.y,this.curve.one)},r(a,n.BasePoint),I.prototype.jpoint=function(A,e,t){return new a(this,A,e,t)},a.prototype.toP=function(){if(this.isInfinity())return this.curve.point(null,null);var A=this.z.redInvm(),e=A.redSqr(),t=this.x.redMul(e),i=this.y.redMul(e).redMul(A);return this.curve.point(t,i)},a.prototype.neg=function(){return this.curve.jpoint(this.x,this.y.redNeg(),this.z)},a.prototype.add=function(A){if(this.isInfinity())return A;if(A.isInfinity())return this;var e=A.z.redSqr(),t=this.z.redSqr(),i=this.x.redMul(e),g=A.x.redMul(t),r=this.y.redMul(e.redMul(A.z)),n=A.y.redMul(t.redMul(this.z)),B=i.redSub(g),I=r.redSub(n);if(0===B.cmpn(0))return 0!==I.cmpn(0)?this.curve.jpoint(null,null,null):this.dbl();var o=B.redSqr(),a=o.redMul(B),Q=i.redMul(o),C=I.redSqr().redIAdd(a).redISub(Q).redISub(Q),s=I.redMul(Q.redISub(C)).redISub(r.redMul(a)),c=this.z.redMul(A.z).redMul(B);return this.curve.jpoint(C,s,c)},a.prototype.mixedAdd=function(A){if(this.isInfinity())return A.toJ();if(A.isInfinity())return this;var e=this.z.redSqr(),t=this.x,i=A.x.redMul(e),g=this.y,r=A.y.redMul(e).redMul(this.z),n=t.redSub(i),B=g.redSub(r);if(0===n.cmpn(0))return 0!==B.cmpn(0)?this.curve.jpoint(null,null,null):this.dbl();var I=n.redSqr(),o=I.redMul(n),a=t.redMul(I),Q=B.redSqr().redIAdd(o).redISub(a).redISub(a),C=B.redMul(a.redISub(Q)).redISub(g.redMul(o)),s=this.z.redMul(n);return this.curve.jpoint(Q,C,s)},a.prototype.dblp=function(A){if(0===A)return this;if(this.isInfinity())return this;if(!A)return this.dbl();if(this.curve.zeroA||this.curve.threeA){for(var e=this,t=0;t=0)return!1;if(t.redIAdd(g),0===this.x.cmp(t))return!0}},a.prototype.inspect=function(){return this.isInfinity()?"":""},a.prototype.isInfinity=function(){return 0===this.z.cmpn(0)}},{"../utils":99,"./base":86,"bn.js":100,inherits:134}],91:[function(A,e,t){"use strict";var i,g=t,r=A("hash.js"),n=A("./curve"),B=A("./utils").assert;function I(A){"short"===A.type?this.curve=new n.short(A):"edwards"===A.type?this.curve=new n.edwards(A):this.curve=new n.mont(A),this.g=this.curve.g,this.n=this.curve.n,this.hash=A.hash,B(this.g.validate(),"Invalid curve"),B(this.g.mul(this.n).isInfinity(),"Invalid curve, G*N != O")}function o(A,e){Object.defineProperty(g,A,{configurable:!0,enumerable:!0,get:function(){var t=new I(e);return Object.defineProperty(g,A,{configurable:!0,enumerable:!0,value:t}),t}})}g.PresetCurve=I,o("p192",{type:"short",prime:"p192",p:"ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff",a:"ffffffff ffffffff ffffffff fffffffe ffffffff fffffffc",b:"64210519 e59c80e7 0fa7e9ab 72243049 feb8deec c146b9b1",n:"ffffffff ffffffff ffffffff 99def836 146bc9b1 b4d22831",hash:r.sha256,gRed:!1,g:["188da80e b03090f6 7cbf20eb 43a18800 f4ff0afd 82ff1012","07192b95 ffc8da78 631011ed 6b24cdd5 73f977a1 1e794811"]}),o("p224",{type:"short",prime:"p224",p:"ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001",a:"ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff fffffffe",b:"b4050a85 0c04b3ab f5413256 5044b0b7 d7bfd8ba 270b3943 2355ffb4",n:"ffffffff ffffffff ffffffff ffff16a2 e0b8f03e 13dd2945 5c5c2a3d",hash:r.sha256,gRed:!1,g:["b70e0cbd 6bb4bf7f 321390b9 4a03c1d3 56c21122 343280d6 115c1d21","bd376388 b5f723fb 4c22dfe6 cd4375a0 5a074764 44d58199 85007e34"]}),o("p256",{type:"short",prime:null,p:"ffffffff 00000001 00000000 00000000 00000000 ffffffff ffffffff ffffffff",a:"ffffffff 00000001 00000000 00000000 00000000 ffffffff ffffffff fffffffc",b:"5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f6 3bce3c3e 27d2604b",n:"ffffffff 00000000 ffffffff ffffffff bce6faad a7179e84 f3b9cac2 fc632551",hash:r.sha256,gRed:!1,g:["6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0 f4a13945 d898c296","4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ece cbb64068 37bf51f5"]}),o("p384",{type:"short",prime:null,p:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe ffffffff 00000000 00000000 ffffffff",a:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe ffffffff 00000000 00000000 fffffffc",b:"b3312fa7 e23ee7e4 988e056b e3f82d19 181d9c6e fe814112 0314088f 5013875a c656398d 8a2ed19d 2a85c8ed d3ec2aef",n:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff c7634d81 f4372ddf 581a0db2 48b0a77a ecec196a ccc52973",hash:r.sha384,gRed:!1,g:["aa87ca22 be8b0537 8eb1c71e f320ad74 6e1d3b62 8ba79b98 59f741e0 82542a38 5502f25d bf55296c 3a545e38 72760ab7","3617de4a 96262c6f 5d9e98bf 9292dc29 f8f41dbd 289a147c e9da3113 b5f0b8c0 0a60b1ce 1d7e819d 7a431d7c 90ea0e5f"]}),o("p521",{type:"short",prime:null,p:"000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff",a:"000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffc",b:"00000051 953eb961 8e1c9a1f 929a21a0 b68540ee a2da725b 99b315f3 b8b48991 8ef109e1 56193951 ec7e937b 1652c0bd 3bb1bf07 3573df88 3d2c34f1 ef451fd4 6b503f00",n:"000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffa 51868783 bf2f966b 7fcc0148 f709a5d0 3bb5c9b8 899c47ae bb6fb71e 91386409",hash:r.sha512,gRed:!1,g:["000000c6 858e06b7 0404e9cd 9e3ecb66 2395b442 9c648139 053fb521 f828af60 6b4d3dba a14b5e77 efe75928 fe1dc127 a2ffa8de 3348b3c1 856a429b f97e7e31 c2e5bd66","00000118 39296a78 9a3bc004 5c8a5fb4 2c7d1bd9 98f54449 579b4468 17afbd17 273e662c 97ee7299 5ef42640 c550b901 3fad0761 353c7086 a272c240 88be9476 9fd16650"]}),o("curve25519",{type:"mont",prime:"p25519",p:"7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed",a:"76d06",b:"1",n:"1000000000000000 0000000000000000 14def9dea2f79cd6 5812631a5cf5d3ed",hash:r.sha256,gRed:!1,g:["9"]}),o("ed25519",{type:"edwards",prime:"p25519",p:"7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed",a:"-1",c:"1",d:"52036cee2b6ffe73 8cc740797779e898 00700a4d4141d8ab 75eb4dca135978a3",n:"1000000000000000 0000000000000000 14def9dea2f79cd6 5812631a5cf5d3ed",hash:r.sha256,gRed:!1,g:["216936d3cd6e53fec0a4e231fdd6dc5c692cc7609525a7b2c9562d608f25d51a","6666666666666666666666666666666666666666666666666666666666666658"]});try{i=A("./precomputed/secp256k1")}catch(A){i=void 0}o("secp256k1",{type:"short",prime:"k256",p:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f",a:"0",b:"7",n:"ffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141",h:"1",hash:r.sha256,beta:"7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee",lambda:"5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72",basis:[{a:"3086d221a7d46bcde86c90e49284eb15",b:"-e4437ed6010e88286f547fa90abfe4c3"},{a:"114ca50f7a8e2f3f657c1108d9d44cfd8",b:"3086d221a7d46bcde86c90e49284eb15"}],gRed:!1,g:["79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8",i]})},{"./curve":88,"./precomputed/secp256k1":98,"./utils":99,"hash.js":120}],92:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("hmac-drbg"),r=A("../utils"),n=A("../curves"),B=A("brorand"),I=r.assert,o=A("./key"),a=A("./signature");function Q(A){if(!(this instanceof Q))return new Q(A);"string"==typeof A&&(I(n.hasOwnProperty(A),"Unknown curve "+A),A=n[A]),A instanceof n.PresetCurve&&(A={curve:A}),this.curve=A.curve.curve,this.n=this.curve.n,this.nh=this.n.ushrn(1),this.g=this.curve.g,this.g=A.curve.g,this.g.precompute(A.curve.n.bitLength()+1),this.hash=A.hash||A.curve.hash}e.exports=Q,Q.prototype.keyPair=function(A){return new o(this,A)},Q.prototype.keyFromPrivate=function(A,e){return o.fromPrivate(this,A,e)},Q.prototype.keyFromPublic=function(A,e){return o.fromPublic(this,A,e)},Q.prototype.genKeyPair=function(A){A||(A={});for(var e=new g({hash:this.hash,pers:A.pers,persEnc:A.persEnc||"utf8",entropy:A.entropy||B(this.hash.hmacStrength),entropyEnc:A.entropy&&A.entropyEnc||"utf8",nonce:this.n.toArray()}),t=this.n.byteLength(),r=this.n.sub(new i(2));;){var n=new i(e.generate(t));if(!(n.cmp(r)>0))return n.iaddn(1),this.keyFromPrivate(n)}},Q.prototype._truncateToN=function(A,e){var t=8*A.byteLength()-this.n.bitLength();return t>0&&(A=A.ushrn(t)),!e&&A.cmp(this.n)>=0?A.sub(this.n):A},Q.prototype.sign=function(A,e,t,r){"object"==typeof t&&(r=t,t=null),r||(r={}),e=this.keyFromPrivate(e,t),A=this._truncateToN(new i(A,16));for(var n=this.n.byteLength(),B=e.getPrivate().toArray("be",n),I=A.toArray("be",n),o=new g({hash:this.hash,entropy:B,nonce:I,pers:r.pers,persEnc:r.persEnc||"utf8"}),Q=this.n.sub(new i(1)),C=0;;C++){var s=r.k?r.k(C):new i(o.generate(this.n.byteLength()));if(!((s=this._truncateToN(s,!0)).cmpn(1)<=0||s.cmp(Q)>=0)){var c=this.g.mul(s);if(!c.isInfinity()){var h=c.getX(),f=h.umod(this.n);if(0!==f.cmpn(0)){var E=s.invm(this.n).mul(f.mul(e.getPrivate()).iadd(A));if(0!==(E=E.umod(this.n)).cmpn(0)){var u=(c.getY().isOdd()?1:0)|(0!==h.cmp(f)?2:0);return r.canonical&&E.cmp(this.nh)>0&&(E=this.n.sub(E),u^=1),new a({r:f,s:E,recoveryParam:u})}}}}}},Q.prototype.verify=function(A,e,t,g){A=this._truncateToN(new i(A,16)),t=this.keyFromPublic(t,g);var r=(e=new a(e,"hex")).r,n=e.s;if(r.cmpn(1)<0||r.cmp(this.n)>=0)return!1;if(n.cmpn(1)<0||n.cmp(this.n)>=0)return!1;var B,I=n.invm(this.n),o=I.mul(A).umod(this.n),Q=I.mul(r).umod(this.n);return this.curve._maxwellTrick?!(B=this.g.jmulAdd(o,t.getPublic(),Q)).isInfinity()&&B.eqXToP(r):!(B=this.g.mulAdd(o,t.getPublic(),Q)).isInfinity()&&0===B.getX().umod(this.n).cmp(r)},Q.prototype.recoverPubKey=function(A,e,t,g){I((3&t)===t,"The recovery param is more than two bits"),e=new a(e,g);var r=this.n,n=new i(A),B=e.r,o=e.s,Q=1&t,C=t>>1;if(B.cmp(this.curve.p.umod(this.curve.n))>=0&&C)throw new Error("Unable to find sencond key candinate");B=C?this.curve.pointFromX(B.add(this.curve.n),Q):this.curve.pointFromX(B,Q);var s=e.r.invm(r),c=r.sub(n).mul(s).umod(r),h=o.mul(s).umod(r);return this.g.mulAdd(c,B,h)},Q.prototype.getKeyRecoveryParam=function(A,e,t,i){if(null!==(e=new a(e,i)).recoveryParam)return e.recoveryParam;for(var g=0;g<4;g++){var r;try{r=this.recoverPubKey(A,e,g)}catch(A){continue}if(r.eq(t))return g}throw new Error("Unable to find valid recovery factor")}},{"../curves":91,"../utils":99,"./key":93,"./signature":94,"bn.js":100,brorand:18,"hmac-drbg":132}],93:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("../utils").assert;function r(A,e){this.ec=A,this.priv=null,this.pub=null,e.priv&&this._importPrivate(e.priv,e.privEnc),e.pub&&this._importPublic(e.pub,e.pubEnc)}e.exports=r,r.fromPublic=function(A,e,t){return e instanceof r?e:new r(A,{pub:e,pubEnc:t})},r.fromPrivate=function(A,e,t){return e instanceof r?e:new r(A,{priv:e,privEnc:t})},r.prototype.validate=function(){var A=this.getPublic();return A.isInfinity()?{result:!1,reason:"Invalid public key"}:A.validate()?A.mul(this.ec.curve.n).isInfinity()?{result:!0,reason:null}:{result:!1,reason:"Public key * N != O"}:{result:!1,reason:"Public key is not a point"}},r.prototype.getPublic=function(A,e){return"string"==typeof A&&(e=A,A=null),this.pub||(this.pub=this.ec.g.mul(this.priv)),e?this.pub.encode(e,A):this.pub},r.prototype.getPrivate=function(A){return"hex"===A?this.priv.toString(16,2):this.priv},r.prototype._importPrivate=function(A,e){this.priv=new i(A,e||16),this.priv=this.priv.umod(this.ec.curve.n)},r.prototype._importPublic=function(A,e){if(A.x||A.y)return"mont"===this.ec.curve.type?g(A.x,"Need x coordinate"):"short"!==this.ec.curve.type&&"edwards"!==this.ec.curve.type||g(A.x&&A.y,"Need both x and y coordinate"),void(this.pub=this.ec.curve.point(A.x,A.y));this.pub=this.ec.curve.decodePoint(A,e)},r.prototype.derive=function(A){return A.mul(this.priv).getX()},r.prototype.sign=function(A,e,t){return this.ec.sign(A,this,e,t)},r.prototype.verify=function(A,e){return this.ec.verify(A,e,this)},r.prototype.inspect=function(){return""}},{"../utils":99,"bn.js":100}],94:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("../utils"),r=g.assert;function n(A,e){if(A instanceof n)return A;this._importDER(A,e)||(r(A.r&&A.s,"Signature without r or s"),this.r=new i(A.r,16),this.s=new i(A.s,16),void 0===A.recoveryParam?this.recoveryParam=null:this.recoveryParam=A.recoveryParam)}function B(A,e){var t=A[e.place++];if(!(128&t))return t;var i=15&t;if(0===i||i>4)return!1;for(var g=0,r=0,n=e.place;r>>=0;return!(g<=127)&&(e.place=n,g)}function I(A){for(var e=0,t=A.length-1;!A[e]&&!(128&A[e+1])&&e>>3);for(A.push(128|t);--t;)A.push(e>>>(t<<3)&255);A.push(e)}}e.exports=n,n.prototype._importDER=function(A,e){A=g.toArray(A,e);var t=new function(){this.place=0};if(48!==A[t.place++])return!1;var r=B(A,t);if(!1===r)return!1;if(r+t.place!==A.length)return!1;if(2!==A[t.place++])return!1;var n=B(A,t);if(!1===n)return!1;var I=A.slice(t.place,n+t.place);if(t.place+=n,2!==A[t.place++])return!1;var o=B(A,t);if(!1===o)return!1;if(A.length!==o+t.place)return!1;var a=A.slice(t.place,o+t.place);if(0===I[0]){if(!(128&I[1]))return!1;I=I.slice(1)}if(0===a[0]){if(!(128&a[1]))return!1;a=a.slice(1)}return this.r=new i(I),this.s=new i(a),this.recoveryParam=null,!0},n.prototype.toDER=function(A){var e=this.r.toArray(),t=this.s.toArray();for(128&e[0]&&(e=[0].concat(e)),128&t[0]&&(t=[0].concat(t)),e=I(e),t=I(t);!(t[0]||128&t[1]);)t=t.slice(1);var i=[2];o(i,e.length),(i=i.concat(e)).push(2),o(i,t.length);var r=i.concat(t),n=[48];return o(n,r.length),n=n.concat(r),g.encode(n,A)}},{"../utils":99,"bn.js":100}],95:[function(A,e,t){"use strict";var i=A("hash.js"),g=A("../curves"),r=A("../utils"),n=r.assert,B=r.parseBytes,I=A("./key"),o=A("./signature");function a(A){if(n("ed25519"===A,"only tested with ed25519 so far"),!(this instanceof a))return new a(A);A=g[A].curve;this.curve=A,this.g=A.g,this.g.precompute(A.n.bitLength()+1),this.pointClass=A.point().constructor,this.encodingLength=Math.ceil(A.n.bitLength()/8),this.hash=i.sha512}e.exports=a,a.prototype.sign=function(A,e){A=B(A);var t=this.keyFromSecret(e),i=this.hashInt(t.messagePrefix(),A),g=this.g.mul(i),r=this.encodePoint(g),n=this.hashInt(r,t.pubBytes(),A).mul(t.priv()),I=i.add(n).umod(this.curve.n);return this.makeSignature({R:g,S:I,Rencoded:r})},a.prototype.verify=function(A,e,t){A=B(A),e=this.makeSignature(e);var i=this.keyFromPublic(t),g=this.hashInt(e.Rencoded(),i.pubBytes(),A),r=this.g.mul(e.S());return e.R().add(i.pub().mul(g)).eq(r)},a.prototype.hashInt=function(){for(var A=this.hash(),e=0;e(g>>1)-1?(g>>1)-I:I,r.isubn(B)):B=0,i[n]=B,r.iushrn(1)}return i},i.getJSF=function(A,e){var t=[[],[]];A=A.clone(),e=e.clone();for(var i=0,g=0;A.cmpn(-i)>0||e.cmpn(-g)>0;){var r,n,B,I=A.andln(3)+i&3,o=e.andln(3)+g&3;3===I&&(I=-1),3===o&&(o=-1),r=0==(1&I)?0:3!=(B=A.andln(7)+i&7)&&5!==B||2!==o?I:-I,t[0].push(r),n=0==(1&o)?0:3!=(B=e.andln(7)+g&7)&&5!==B||2!==I?o:-o,t[1].push(n),2*i===r+1&&(i=1-i),2*g===n+1&&(g=1-g),A.iushrn(1),e.iushrn(1)}return t},i.cachedProperty=function(A,e,t){var i="_"+e;A.prototype[e]=function(){return void 0!==this[i]?this[i]:this[i]=t.call(this)}},i.parseBytes=function(A){return"string"==typeof A?i.toArray(A,"hex"):A},i.intFromLE=function(A){return new g(A,"hex","le")}},{"bn.js":100,"minimalistic-assert":140,"minimalistic-crypto-utils":141}],100:[function(A,e,t){arguments[4][15][0].apply(t,arguments)},{buffer:19,dup:15}],101:[function(A,e,t){e.exports={_from:"elliptic@^6.5.3",_id:"elliptic@6.5.3",_inBundle:!1,_integrity:"sha512-IMqzv5wNQf+E6aHeIqATs0tOLeOTwj1QKbRcS3jBbYkl5oLAserA8yJTT7/VyHUYG91PRmPyeQDObKLPpeS4dw==",_location:"/browserify/elliptic",_phantomChildren:{},_requested:{type:"range",registry:!0,raw:"elliptic@^6.5.3",name:"elliptic",escapedName:"elliptic",rawSpec:"^6.5.3",saveSpec:null,fetchSpec:"^6.5.3"},_requiredBy:["/browserify/browserify-sign","/browserify/create-ecdh"],_resolved:"https://registry.npmjs.org/elliptic/-/elliptic-6.5.3.tgz",_shasum:"cb59eb2efdaf73a0bd78ccd7015a62ad6e0f93d6",_spec:"elliptic@^6.5.3",_where:"/home/volt/.npm/_npx/29682/lib/node_modules/browserify/node_modules/browserify-sign",author:{name:"Fedor Indutny",email:"fedor@indutny.com"},bugs:{url:"https://github.com/indutny/elliptic/issues"},bundleDependencies:!1,dependencies:{"bn.js":"^4.4.0",brorand:"^1.0.1","hash.js":"^1.0.0","hmac-drbg":"^1.0.0",inherits:"^2.0.1","minimalistic-assert":"^1.0.0","minimalistic-crypto-utils":"^1.0.0"},deprecated:!1,description:"EC cryptography",devDependencies:{brfs:"^1.4.3",coveralls:"^3.0.8",grunt:"^1.0.4","grunt-browserify":"^5.0.0","grunt-cli":"^1.2.0","grunt-contrib-connect":"^1.0.0","grunt-contrib-copy":"^1.0.0","grunt-contrib-uglify":"^1.0.1","grunt-mocha-istanbul":"^3.0.1","grunt-saucelabs":"^9.0.1",istanbul:"^0.4.2",jscs:"^3.0.7",jshint:"^2.10.3",mocha:"^6.2.2"},files:["lib"],homepage:"https://github.com/indutny/elliptic",keywords:["EC","Elliptic","curve","Cryptography"],license:"MIT",main:"lib/elliptic.js",name:"elliptic",repository:{type:"git",url:"git+ssh://git@github.com/indutny/elliptic.git"},scripts:{jscs:"jscs benchmarks/*.js lib/*.js lib/**/*.js lib/**/**/*.js test/index.js",jshint:"jscs benchmarks/*.js lib/*.js lib/**/*.js lib/**/**/*.js test/index.js",lint:"npm run jscs && npm run jshint",test:"npm run lint && npm run unit",unit:"istanbul test _mocha --reporter=spec test/index.js",version:"grunt dist && git add dist/"},version:"6.5.3"}},{}],102:[function(A,e,t){var i=Object.create||function(A){var e=function(){};return e.prototype=A,new e},g=Object.keys||function(A){var e=[];for(var t in A)Object.prototype.hasOwnProperty.call(A,t)&&e.push(t);return t},r=Function.prototype.bind||function(A){var e=this;return function(){return e.apply(A,arguments)}};function n(){this._events&&Object.prototype.hasOwnProperty.call(this,"_events")||(this._events=i(null),this._eventsCount=0),this._maxListeners=this._maxListeners||void 0}e.exports=n,n.EventEmitter=n,n.prototype._events=void 0,n.prototype._maxListeners=void 0;var B,I=10;try{var o={};Object.defineProperty&&Object.defineProperty(o,"x",{value:0}),B=0===o.x}catch(A){B=!1}function a(A){return void 0===A._maxListeners?n.defaultMaxListeners:A._maxListeners}function Q(A,e,t,g){var r,n,B;if("function"!=typeof t)throw new TypeError('"listener" argument must be a function');if((n=A._events)?(n.newListener&&(A.emit("newListener",e,t.listener?t.listener:t),n=A._events),B=n[e]):(n=A._events=i(null),A._eventsCount=0),B){if("function"==typeof B?B=n[e]=g?[t,B]:[B,t]:g?B.unshift(t):B.push(t),!B.warned&&(r=a(A))&&r>0&&B.length>r){B.warned=!0;var I=new Error("Possible EventEmitter memory leak detected. "+B.length+' "'+String(e)+'" listeners added. Use emitter.setMaxListeners() to increase limit.');I.name="MaxListenersExceededWarning",I.emitter=A,I.type=e,I.count=B.length,"object"==typeof console&&console.warn&&console.warn("%s: %s",I.name,I.message)}}else B=n[e]=t,++A._eventsCount;return A}function C(){if(!this.fired)switch(this.target.removeListener(this.type,this.wrapFn),this.fired=!0,arguments.length){case 0:return this.listener.call(this.target);case 1:return this.listener.call(this.target,arguments[0]);case 2:return this.listener.call(this.target,arguments[0],arguments[1]);case 3:return this.listener.call(this.target,arguments[0],arguments[1],arguments[2]);default:for(var A=new Array(arguments.length),e=0;e1&&(e=arguments[1]),e instanceof Error)throw e;var I=new Error('Unhandled "error" event. ('+e+")");throw I.context=e,I}if(!(t=n[A]))return!1;var o="function"==typeof t;switch(i=arguments.length){case 1:!function(A,e,t){if(e)A.call(t);else for(var i=A.length,g=f(A,i),r=0;r=0;n--)if(t[n]===e||t[n].listener===e){B=t[n].listener,r=n;break}if(r<0)return this;0===r?t.shift():function(A,e){for(var t=e,i=t+1,g=A.length;i=0;r--)this.removeListener(A,e[r]);return this},n.prototype.listeners=function(A){return c(this,A,!0)},n.prototype.rawListeners=function(A){return c(this,A,!1)},n.listenerCount=function(A,e){return"function"==typeof A.listenerCount?A.listenerCount(e):h.call(A,e)},n.prototype.listenerCount=h,n.prototype.eventNames=function(){return this._eventsCount>0?Reflect.ownKeys(this._events):[]}},{}],103:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("md5.js");e.exports=function(A,e,t,r){if(i.isBuffer(A)||(A=i.from(A,"binary")),e&&(i.isBuffer(e)||(e=i.from(e,"binary")),8!==e.length))throw new RangeError("salt should be Buffer with 8 byte length");for(var n=t/8,B=i.alloc(n),I=i.alloc(r||0),o=i.alloc(0);n>0||r>0;){var a=new g;a.update(o),a.update(A),e&&a.update(e),o=a.digest();var Q=0;if(n>0){var C=B.length-n;Q=Math.min(n,o.length),o.copy(B,C,0,Q),n-=Q}if(Q0){var s=I.length-r,c=Math.min(r,o.length-Q);o.copy(I,s,Q,Q+c),r-=c}}return o.fill(0),{key:B,iv:I}}},{"md5.js":137,"safe-buffer":180}],104:[function(A,e,t){"use strict";var i=A("safe-buffer").Buffer,g=A("readable-stream").Transform;function r(A){g.call(this),this._block=i.allocUnsafe(A),this._blockSize=A,this._blockOffset=0,this._length=[0,0,0,0],this._finalized=!1}A("inherits")(r,g),r.prototype._transform=function(A,e,t){var i=null;try{this.update(A,e)}catch(A){i=A}t(i)},r.prototype._flush=function(A){var e=null;try{this.push(this.digest())}catch(A){e=A}A(e)},r.prototype.update=function(A,e){if(function(A,e){if(!i.isBuffer(A)&&"string"!=typeof A)throw new TypeError(e+" must be a string or a buffer")}(A,"Data"),this._finalized)throw new Error("Digest already called");i.isBuffer(A)||(A=i.from(A,e));for(var t=this._block,g=0;this._blockOffset+A.length-g>=this._blockSize;){for(var r=this._blockOffset;r0;++n)this._length[n]+=B,(B=this._length[n]/4294967296|0)>0&&(this._length[n]-=4294967296*B);return this},r.prototype._update=function(){throw new Error("_update is not implemented")},r.prototype.digest=function(A){if(this._finalized)throw new Error("Digest already called");this._finalized=!0;var e=this._digest();void 0!==A&&(e=e.toString(A)),this._block.fill(0),this._blockOffset=0;for(var t=0;t<4;++t)this._length[t]=0;return e},r.prototype._digest=function(){throw new Error("_digest is not implemented")},e.exports=r},{inherits:134,"readable-stream":119,"safe-buffer":180}],105:[function(A,e,t){arguments[4][48][0].apply(t,arguments)},{dup:48}],106:[function(A,e,t){arguments[4][49][0].apply(t,arguments)},{"./_stream_readable":108,"./_stream_writable":110,_process:154,dup:49,inherits:134}],107:[function(A,e,t){arguments[4][50][0].apply(t,arguments)},{"./_stream_transform":109,dup:50,inherits:134}],108:[function(A,e,t){arguments[4][51][0].apply(t,arguments)},{"../errors":105,"./_stream_duplex":106,"./internal/streams/async_iterator":111,"./internal/streams/buffer_list":112,"./internal/streams/destroy":113,"./internal/streams/from":115,"./internal/streams/state":117,"./internal/streams/stream":118,_process:154,buffer:64,dup:51,events:102,inherits:134,"string_decoder/":191,util:19}],109:[function(A,e,t){arguments[4][52][0].apply(t,arguments)},{"../errors":105,"./_stream_duplex":106,dup:52,inherits:134}],110:[function(A,e,t){arguments[4][53][0].apply(t,arguments)},{"../errors":105,"./_stream_duplex":106,"./internal/streams/destroy":113,"./internal/streams/state":117,"./internal/streams/stream":118,_process:154,buffer:64,dup:53,inherits:134,"util-deprecate":193}],111:[function(A,e,t){arguments[4][54][0].apply(t,arguments)},{"./end-of-stream":114,_process:154,dup:54}],112:[function(A,e,t){arguments[4][55][0].apply(t,arguments)},{buffer:64,dup:55,util:19}],113:[function(A,e,t){arguments[4][56][0].apply(t,arguments)},{_process:154,dup:56}],114:[function(A,e,t){arguments[4][57][0].apply(t,arguments)},{"../../../errors":105,dup:57}],115:[function(A,e,t){arguments[4][58][0].apply(t,arguments)},{dup:58}],116:[function(A,e,t){arguments[4][59][0].apply(t,arguments)},{"../../../errors":105,"./end-of-stream":114,dup:59}],117:[function(A,e,t){arguments[4][60][0].apply(t,arguments)},{"../../../errors":105,dup:60}],118:[function(A,e,t){arguments[4][61][0].apply(t,arguments)},{dup:61,events:102}],119:[function(A,e,t){arguments[4][62][0].apply(t,arguments)},{"./lib/_stream_duplex.js":106,"./lib/_stream_passthrough.js":107,"./lib/_stream_readable.js":108,"./lib/_stream_transform.js":109,"./lib/_stream_writable.js":110,"./lib/internal/streams/end-of-stream.js":114,"./lib/internal/streams/pipeline.js":116,dup:62}],120:[function(A,e,t){var i=t;i.utils=A("./hash/utils"),i.common=A("./hash/common"),i.sha=A("./hash/sha"),i.ripemd=A("./hash/ripemd"),i.hmac=A("./hash/hmac"),i.sha1=i.sha.sha1,i.sha256=i.sha.sha256,i.sha224=i.sha.sha224,i.sha384=i.sha.sha384,i.sha512=i.sha.sha512,i.ripemd160=i.ripemd.ripemd160},{"./hash/common":121,"./hash/hmac":122,"./hash/ripemd":123,"./hash/sha":124,"./hash/utils":131}],121:[function(A,e,t){"use strict";var i=A("./utils"),g=A("minimalistic-assert");function r(){this.pending=null,this.pendingTotal=0,this.blockSize=this.constructor.blockSize,this.outSize=this.constructor.outSize,this.hmacStrength=this.constructor.hmacStrength,this.padLength=this.constructor.padLength/8,this.endian="big",this._delta8=this.blockSize/8,this._delta32=this.blockSize/32}t.BlockHash=r,r.prototype.update=function(A,e){if(A=i.toArray(A,e),this.pending?this.pending=this.pending.concat(A):this.pending=A,this.pendingTotal+=A.length,this.pending.length>=this._delta8){var t=(A=this.pending).length%this._delta8;this.pending=A.slice(A.length-t,A.length),0===this.pending.length&&(this.pending=null),A=i.join32(A,0,A.length-t,this.endian);for(var g=0;g>>24&255,i[g++]=A>>>16&255,i[g++]=A>>>8&255,i[g++]=255&A}else for(i[g++]=255&A,i[g++]=A>>>8&255,i[g++]=A>>>16&255,i[g++]=A>>>24&255,i[g++]=0,i[g++]=0,i[g++]=0,i[g++]=0,r=8;rthis.blockSize&&(A=(new this.Hash).update(A).digest()),g(A.length<=this.blockSize);for(var e=A.length;e>>3},t.g1_256=function(A){return i(A,17)^i(A,19)^A>>>10}},{"../utils":131}],131:[function(A,e,t){"use strict";var i=A("minimalistic-assert"),g=A("inherits");function r(A,e){return 55296==(64512&A.charCodeAt(e))&&(!(e<0||e+1>=A.length)&&56320==(64512&A.charCodeAt(e+1)))}function n(A){return(A>>>24|A>>>8&65280|A<<8&16711680|(255&A)<<24)>>>0}function B(A){return 1===A.length?"0"+A:A}function I(A){return 7===A.length?"0"+A:6===A.length?"00"+A:5===A.length?"000"+A:4===A.length?"0000"+A:3===A.length?"00000"+A:2===A.length?"000000"+A:1===A.length?"0000000"+A:A}t.inherits=g,t.toArray=function(A,e){if(Array.isArray(A))return A.slice();if(!A)return[];var t=[];if("string"==typeof A)if(e){if("hex"===e)for((A=A.replace(/[^a-z0-9]+/gi,"")).length%2!=0&&(A="0"+A),g=0;g>6|192,t[i++]=63&n|128):r(A,g)?(n=65536+((1023&n)<<10)+(1023&A.charCodeAt(++g)),t[i++]=n>>18|240,t[i++]=n>>12&63|128,t[i++]=n>>6&63|128,t[i++]=63&n|128):(t[i++]=n>>12|224,t[i++]=n>>6&63|128,t[i++]=63&n|128)}else for(g=0;g>>0}return n},t.split32=function(A,e){for(var t=new Array(4*A.length),i=0,g=0;i>>24,t[g+1]=r>>>16&255,t[g+2]=r>>>8&255,t[g+3]=255&r):(t[g+3]=r>>>24,t[g+2]=r>>>16&255,t[g+1]=r>>>8&255,t[g]=255&r)}return t},t.rotr32=function(A,e){return A>>>e|A<<32-e},t.rotl32=function(A,e){return A<>>32-e},t.sum32=function(A,e){return A+e>>>0},t.sum32_3=function(A,e,t){return A+e+t>>>0},t.sum32_4=function(A,e,t,i){return A+e+t+i>>>0},t.sum32_5=function(A,e,t,i,g){return A+e+t+i+g>>>0},t.sum64=function(A,e,t,i){var g=A[e],r=i+A[e+1]>>>0,n=(r>>0,A[e+1]=r},t.sum64_hi=function(A,e,t,i){return(e+i>>>0>>0},t.sum64_lo=function(A,e,t,i){return e+i>>>0},t.sum64_4_hi=function(A,e,t,i,g,r,n,B){var I=0,o=e;return I+=(o=o+i>>>0)>>0)>>0)>>0},t.sum64_4_lo=function(A,e,t,i,g,r,n,B){return e+i+r+B>>>0},t.sum64_5_hi=function(A,e,t,i,g,r,n,B,I,o){var a=0,Q=e;return a+=(Q=Q+i>>>0)>>0)>>0)>>0)>>0},t.sum64_5_lo=function(A,e,t,i,g,r,n,B,I,o){return e+i+r+B+o>>>0},t.rotr64_hi=function(A,e,t){return(e<<32-t|A>>>t)>>>0},t.rotr64_lo=function(A,e,t){return(A<<32-t|e>>>t)>>>0},t.shr64_hi=function(A,e,t){return A>>>t},t.shr64_lo=function(A,e,t){return(A<<32-t|e>>>t)>>>0}},{inherits:134,"minimalistic-assert":140}],132:[function(A,e,t){"use strict";var i=A("hash.js"),g=A("minimalistic-crypto-utils"),r=A("minimalistic-assert");function n(A){if(!(this instanceof n))return new n(A);this.hash=A.hash,this.predResist=!!A.predResist,this.outLen=this.hash.outSize,this.minEntropy=A.minEntropy||this.hash.hmacStrength,this._reseed=null,this.reseedInterval=null,this.K=null,this.V=null;var e=g.toArray(A.entropy,A.entropyEnc||"hex"),t=g.toArray(A.nonce,A.nonceEnc||"hex"),i=g.toArray(A.pers,A.persEnc||"hex");r(e.length>=this.minEntropy/8,"Not enough entropy. Minimum is: "+this.minEntropy+" bits"),this._init(e,t,i)}e.exports=n,n.prototype._init=function(A,e,t){var i=A.concat(e).concat(t);this.K=new Array(this.outLen/8),this.V=new Array(this.outLen/8);for(var g=0;g=this.minEntropy/8,"Not enough entropy. Minimum is: "+this.minEntropy+" bits"),this._update(A.concat(t||[])),this._reseed=1},n.prototype.generate=function(A,e,t,i){if(this._reseed>this.reseedInterval)throw new Error("Reseed is required");"string"!=typeof e&&(i=t,t=e,e=null),t&&(t=g.toArray(t,i||"hex"),this._update(t));for(var r=[];r.length>1,a=-7,Q=t?g-1:0,C=t?-1:1,s=A[e+Q];for(Q+=C,r=s&(1<<-a)-1,s>>=-a,a+=B;a>0;r=256*r+A[e+Q],Q+=C,a-=8);for(n=r&(1<<-a)-1,r>>=-a,a+=i;a>0;n=256*n+A[e+Q],Q+=C,a-=8);if(0===r)r=1-o;else{if(r===I)return n?NaN:1/0*(s?-1:1);n+=Math.pow(2,i),r-=o}return(s?-1:1)*n*Math.pow(2,r-i)},t.write=function(A,e,t,i,g,r){var n,B,I,o=8*r-g-1,a=(1<>1,C=23===g?Math.pow(2,-24)-Math.pow(2,-77):0,s=i?0:r-1,c=i?1:-1,h=e<0||0===e&&1/e<0?1:0;for(e=Math.abs(e),isNaN(e)||e===1/0?(B=isNaN(e)?1:0,n=a):(n=Math.floor(Math.log(e)/Math.LN2),e*(I=Math.pow(2,-n))<1&&(n--,I*=2),(e+=n+Q>=1?C/I:C*Math.pow(2,1-Q))*I>=2&&(n++,I/=2),n+Q>=a?(B=0,n=a):n+Q>=1?(B=(e*I-1)*Math.pow(2,g),n+=Q):(B=e*Math.pow(2,Q-1)*Math.pow(2,g),n=0));g>=8;A[t+s]=255&B,s+=c,B/=256,g-=8);for(n=n<0;A[t+s]=255&n,s+=c,n/=256,o-=8);A[t+s-c]|=128*h}},{}],134:[function(A,e,t){"function"==typeof Object.create?e.exports=function(A,e){e&&(A.super_=e,A.prototype=Object.create(e.prototype,{constructor:{value:A,enumerable:!1,writable:!0,configurable:!0}}))}:e.exports=function(A,e){if(e){A.super_=e;var t=function(){};t.prototype=e.prototype,A.prototype=new t,A.prototype.constructor=A}}},{}],135:[function(A,e,t){function i(A){return!!A.constructor&&"function"==typeof A.constructor.isBuffer&&A.constructor.isBuffer(A)}e.exports=function(A){return null!=A&&(i(A)||function(A){return"function"==typeof A.readFloatLE&&"function"==typeof A.slice&&i(A.slice(0,0))}(A)||!!A._isBuffer)}},{}],136:[function(A,e,t){var i={}.toString;e.exports=Array.isArray||function(A){return"[object Array]"==i.call(A)}},{}],137:[function(A,e,t){"use strict";var i=A("inherits"),g=A("hash-base"),r=A("safe-buffer").Buffer,n=new Array(16);function B(){g.call(this,64),this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878}function I(A,e){return A<>>32-e}function o(A,e,t,i,g,r,n){return I(A+(e&t|~e&i)+g+r|0,n)+e|0}function a(A,e,t,i,g,r,n){return I(A+(e&i|t&~i)+g+r|0,n)+e|0}function Q(A,e,t,i,g,r,n){return I(A+(e^t^i)+g+r|0,n)+e|0}function C(A,e,t,i,g,r,n){return I(A+(t^(e|~i))+g+r|0,n)+e|0}i(B,g),B.prototype._update=function(){for(var A=n,e=0;e<16;++e)A[e]=this._block.readInt32LE(4*e);var t=this._a,i=this._b,g=this._c,r=this._d;i=C(i=C(i=C(i=C(i=Q(i=Q(i=Q(i=Q(i=a(i=a(i=a(i=a(i=o(i=o(i=o(i=o(i,g=o(g,r=o(r,t=o(t,i,g,r,A[0],3614090360,7),i,g,A[1],3905402710,12),t,i,A[2],606105819,17),r,t,A[3],3250441966,22),g=o(g,r=o(r,t=o(t,i,g,r,A[4],4118548399,7),i,g,A[5],1200080426,12),t,i,A[6],2821735955,17),r,t,A[7],4249261313,22),g=o(g,r=o(r,t=o(t,i,g,r,A[8],1770035416,7),i,g,A[9],2336552879,12),t,i,A[10],4294925233,17),r,t,A[11],2304563134,22),g=o(g,r=o(r,t=o(t,i,g,r,A[12],1804603682,7),i,g,A[13],4254626195,12),t,i,A[14],2792965006,17),r,t,A[15],1236535329,22),g=a(g,r=a(r,t=a(t,i,g,r,A[1],4129170786,5),i,g,A[6],3225465664,9),t,i,A[11],643717713,14),r,t,A[0],3921069994,20),g=a(g,r=a(r,t=a(t,i,g,r,A[5],3593408605,5),i,g,A[10],38016083,9),t,i,A[15],3634488961,14),r,t,A[4],3889429448,20),g=a(g,r=a(r,t=a(t,i,g,r,A[9],568446438,5),i,g,A[14],3275163606,9),t,i,A[3],4107603335,14),r,t,A[8],1163531501,20),g=a(g,r=a(r,t=a(t,i,g,r,A[13],2850285829,5),i,g,A[2],4243563512,9),t,i,A[7],1735328473,14),r,t,A[12],2368359562,20),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[5],4294588738,4),i,g,A[8],2272392833,11),t,i,A[11],1839030562,16),r,t,A[14],4259657740,23),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[1],2763975236,4),i,g,A[4],1272893353,11),t,i,A[7],4139469664,16),r,t,A[10],3200236656,23),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[13],681279174,4),i,g,A[0],3936430074,11),t,i,A[3],3572445317,16),r,t,A[6],76029189,23),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[9],3654602809,4),i,g,A[12],3873151461,11),t,i,A[15],530742520,16),r,t,A[2],3299628645,23),g=C(g,r=C(r,t=C(t,i,g,r,A[0],4096336452,6),i,g,A[7],1126891415,10),t,i,A[14],2878612391,15),r,t,A[5],4237533241,21),g=C(g,r=C(r,t=C(t,i,g,r,A[12],1700485571,6),i,g,A[3],2399980690,10),t,i,A[10],4293915773,15),r,t,A[1],2240044497,21),g=C(g,r=C(r,t=C(t,i,g,r,A[8],1873313359,6),i,g,A[15],4264355552,10),t,i,A[6],2734768916,15),r,t,A[13],1309151649,21),g=C(g,r=C(r,t=C(t,i,g,r,A[4],4149444226,6),i,g,A[11],3174756917,10),t,i,A[2],718787259,15),r,t,A[9],3951481745,21),this._a=this._a+t|0,this._b=this._b+i|0,this._c=this._c+g|0,this._d=this._d+r|0},B.prototype._digest=function(){this._block[this._blockOffset++]=128,this._blockOffset>56&&(this._block.fill(0,this._blockOffset,64),this._update(),this._blockOffset=0),this._block.fill(0,this._blockOffset,56),this._block.writeUInt32LE(this._length[0],56),this._block.writeUInt32LE(this._length[1],60),this._update();var A=r.allocUnsafe(16);return A.writeInt32LE(this._a,0),A.writeInt32LE(this._b,4),A.writeInt32LE(this._c,8),A.writeInt32LE(this._d,12),A},e.exports=B},{"hash-base":104,inherits:134,"safe-buffer":180}],138:[function(A,e,t){var i=A("bn.js"),g=A("brorand");function r(A){this.rand=A||new g.Rand}e.exports=r,r.create=function(A){return new r(A)},r.prototype._randbelow=function(A){var e=A.bitLength(),t=Math.ceil(e/8);do{var g=new i(this.rand.generate(t))}while(g.cmp(A)>=0);return g},r.prototype._randrange=function(A,e){var t=e.sub(A);return A.add(this._randbelow(t))},r.prototype.test=function(A,e,t){var g=A.bitLength(),r=i.mont(A),n=new i(1).toRed(r);e||(e=Math.max(1,g/48|0));for(var B=A.subn(1),I=0;!B.testn(I);I++);for(var o=A.shrn(I),a=B.toRed(r);e>0;e--){var Q=this._randrange(new i(2),B);t&&t(Q);var C=Q.toRed(r).redPow(o);if(0!==C.cmp(n)&&0!==C.cmp(a)){for(var s=1;s0;e--){var a=this._randrange(new i(2),n),Q=A.gcd(a);if(0!==Q.cmpn(1))return Q;var C=a.toRed(g).redPow(I);if(0!==C.cmp(r)&&0!==C.cmp(o)){for(var s=1;s>8,n=255&g;r?t.push(r,n):t.push(n)}return t},i.zero2=g,i.toHex=r,i.encode=function(A,e){return"hex"===e?r(A):A}},{}],142:[function(A,e,t){e.exports={"2.16.840.1.101.3.4.1.1":"aes-128-ecb","2.16.840.1.101.3.4.1.2":"aes-128-cbc","2.16.840.1.101.3.4.1.3":"aes-128-ofb","2.16.840.1.101.3.4.1.4":"aes-128-cfb","2.16.840.1.101.3.4.1.21":"aes-192-ecb","2.16.840.1.101.3.4.1.22":"aes-192-cbc","2.16.840.1.101.3.4.1.23":"aes-192-ofb","2.16.840.1.101.3.4.1.24":"aes-192-cfb","2.16.840.1.101.3.4.1.41":"aes-256-ecb","2.16.840.1.101.3.4.1.42":"aes-256-cbc","2.16.840.1.101.3.4.1.43":"aes-256-ofb","2.16.840.1.101.3.4.1.44":"aes-256-cfb"}},{}],143:[function(A,e,t){"use strict";var i=A("asn1.js");t.certificate=A("./certificate");var g=i.define("RSAPrivateKey",function(){this.seq().obj(this.key("version").int(),this.key("modulus").int(),this.key("publicExponent").int(),this.key("privateExponent").int(),this.key("prime1").int(),this.key("prime2").int(),this.key("exponent1").int(),this.key("exponent2").int(),this.key("coefficient").int())});t.RSAPrivateKey=g;var r=i.define("RSAPublicKey",function(){this.seq().obj(this.key("modulus").int(),this.key("publicExponent").int())});t.RSAPublicKey=r;var n=i.define("SubjectPublicKeyInfo",function(){this.seq().obj(this.key("algorithm").use(B),this.key("subjectPublicKey").bitstr())});t.PublicKey=n;var B=i.define("AlgorithmIdentifier",function(){this.seq().obj(this.key("algorithm").objid(),this.key("none").null_().optional(),this.key("curve").objid().optional(),this.key("params").seq().obj(this.key("p").int(),this.key("q").int(),this.key("g").int()).optional())}),I=i.define("PrivateKeyInfo",function(){this.seq().obj(this.key("version").int(),this.key("algorithm").use(B),this.key("subjectPrivateKey").octstr())});t.PrivateKey=I;var o=i.define("EncryptedPrivateKeyInfo",function(){this.seq().obj(this.key("algorithm").seq().obj(this.key("id").objid(),this.key("decrypt").seq().obj(this.key("kde").seq().obj(this.key("id").objid(),this.key("kdeparams").seq().obj(this.key("salt").octstr(),this.key("iters").int())),this.key("cipher").seq().obj(this.key("algo").objid(),this.key("iv").octstr()))),this.key("subjectPrivateKey").octstr())});t.EncryptedPrivateKey=o;var a=i.define("DSAPrivateKey",function(){this.seq().obj(this.key("version").int(),this.key("p").int(),this.key("q").int(),this.key("g").int(),this.key("pub_key").int(),this.key("priv_key").int())});t.DSAPrivateKey=a,t.DSAparam=i.define("DSAparam",function(){this.int()});var Q=i.define("ECPrivateKey",function(){this.seq().obj(this.key("version").int(),this.key("privateKey").octstr(),this.key("parameters").optional().explicit(0).use(C),this.key("publicKey").optional().explicit(1).bitstr())});t.ECPrivateKey=Q;var C=i.define("ECParameters",function(){this.choice({namedCurve:this.objid()})});t.signature=i.define("signature",function(){this.seq().obj(this.key("r").int(),this.key("s").int())})},{"./certificate":144,"asn1.js":1}],144:[function(A,e,t){"use strict";var i=A("asn1.js"),g=i.define("Time",function(){this.choice({utcTime:this.utctime(),generalTime:this.gentime()})}),r=i.define("AttributeTypeValue",function(){this.seq().obj(this.key("type").objid(),this.key("value").any())}),n=i.define("AlgorithmIdentifier",function(){this.seq().obj(this.key("algorithm").objid(),this.key("parameters").optional(),this.key("curve").objid().optional())}),B=i.define("SubjectPublicKeyInfo",function(){this.seq().obj(this.key("algorithm").use(n),this.key("subjectPublicKey").bitstr())}),I=i.define("RelativeDistinguishedName",function(){this.setof(r)}),o=i.define("RDNSequence",function(){this.seqof(I)}),a=i.define("Name",function(){this.choice({rdnSequence:this.use(o)})}),Q=i.define("Validity",function(){this.seq().obj(this.key("notBefore").use(g),this.key("notAfter").use(g))}),C=i.define("Extension",function(){this.seq().obj(this.key("extnID").objid(),this.key("critical").bool().def(!1),this.key("extnValue").octstr())}),s=i.define("TBSCertificate",function(){this.seq().obj(this.key("version").explicit(0).int().optional(),this.key("serialNumber").int(),this.key("signature").use(n),this.key("issuer").use(a),this.key("validity").use(Q),this.key("subject").use(a),this.key("subjectPublicKeyInfo").use(B),this.key("issuerUniqueID").implicit(1).bitstr().optional(),this.key("subjectUniqueID").implicit(2).bitstr().optional(),this.key("extensions").explicit(3).seqof(C).optional())}),c=i.define("X509Certificate",function(){this.seq().obj(this.key("tbsCertificate").use(s),this.key("signatureAlgorithm").use(n),this.key("signatureValue").bitstr())});e.exports=c},{"asn1.js":1}],145:[function(A,e,t){var i=/Proc-Type: 4,ENCRYPTED[\n\r]+DEK-Info: AES-((?:128)|(?:192)|(?:256))-CBC,([0-9A-H]+)[\n\r]+([0-9A-z\n\r+/=]+)[\n\r]+/m,g=/^-----BEGIN ((?:.*? KEY)|CERTIFICATE)-----/m,r=/^-----BEGIN ((?:.*? KEY)|CERTIFICATE)-----([0-9A-z\n\r+/=]+)-----END \1-----$/m,n=A("evp_bytestokey"),B=A("browserify-aes"),I=A("safe-buffer").Buffer;e.exports=function(A,e){var t,o=A.toString(),a=o.match(i);if(a){var Q="aes"+a[1],C=I.from(a[2],"hex"),s=I.from(a[3].replace(/[\r\n]/g,""),"base64"),c=n(e,C.slice(0,8),parseInt(a[1],10)).key,h=[],f=B.createDecipheriv(Q,c,C);h.push(f.update(s)),h.push(f.final()),t=I.concat(h)}else{var E=o.match(r);t=I.from(E[2].replace(/[\r\n]/g,""),"base64")}return{tag:o.match(g)[1],data:t}}},{"browserify-aes":22,evp_bytestokey:103,"safe-buffer":180}],146:[function(A,e,t){var i=A("./asn1"),g=A("./aesid.json"),r=A("./fixProc"),n=A("browserify-aes"),B=A("pbkdf2"),I=A("safe-buffer").Buffer;function o(A){var e;"object"!=typeof A||I.isBuffer(A)||(e=A.passphrase,A=A.key),"string"==typeof A&&(A=I.from(A));var t,o,a=r(A,e),Q=a.tag,C=a.data;switch(Q){case"CERTIFICATE":o=i.certificate.decode(C,"der").tbsCertificate.subjectPublicKeyInfo;case"PUBLIC KEY":switch(o||(o=i.PublicKey.decode(C,"der")),t=o.algorithm.algorithm.join(".")){case"1.2.840.113549.1.1.1":return i.RSAPublicKey.decode(o.subjectPublicKey.data,"der");case"1.2.840.10045.2.1":return o.subjectPrivateKey=o.subjectPublicKey,{type:"ec",data:o};case"1.2.840.10040.4.1":return o.algorithm.params.pub_key=i.DSAparam.decode(o.subjectPublicKey.data,"der"),{type:"dsa",data:o.algorithm.params};default:throw new Error("unknown key id "+t)}case"ENCRYPTED PRIVATE KEY":C=function(A,e){var t=A.algorithm.decrypt.kde.kdeparams.salt,i=parseInt(A.algorithm.decrypt.kde.kdeparams.iters.toString(),10),r=g[A.algorithm.decrypt.cipher.algo.join(".")],o=A.algorithm.decrypt.cipher.iv,a=A.subjectPrivateKey,Q=parseInt(r.split("-")[1],10)/8,C=B.pbkdf2Sync(e,t,i,Q,"sha1"),s=n.createDecipheriv(r,C,o),c=[];return c.push(s.update(a)),c.push(s.final()),I.concat(c)}(C=i.EncryptedPrivateKey.decode(C,"der"),e);case"PRIVATE KEY":switch(t=(o=i.PrivateKey.decode(C,"der")).algorithm.algorithm.join(".")){case"1.2.840.113549.1.1.1":return i.RSAPrivateKey.decode(o.subjectPrivateKey,"der");case"1.2.840.10045.2.1":return{curve:o.algorithm.curve,privateKey:i.ECPrivateKey.decode(o.subjectPrivateKey,"der").privateKey};case"1.2.840.10040.4.1":return o.algorithm.params.priv_key=i.DSAparam.decode(o.subjectPrivateKey,"der"),{type:"dsa",params:o.algorithm.params};default:throw new Error("unknown key id "+t)}case"RSA PUBLIC KEY":return i.RSAPublicKey.decode(C,"der");case"RSA PRIVATE KEY":return i.RSAPrivateKey.decode(C,"der");case"DSA PRIVATE KEY":return{type:"dsa",params:i.DSAPrivateKey.decode(C,"der")};case"EC PRIVATE KEY":return{curve:(C=i.ECPrivateKey.decode(C,"der")).parameters.value,privateKey:C.privateKey};default:throw new Error("unknown key type "+Q)}}e.exports=o,o.signature=i.signature},{"./aesid.json":142,"./asn1":143,"./fixProc":145,"browserify-aes":22,pbkdf2:147,"safe-buffer":180}],147:[function(A,e,t){t.pbkdf2=A("./lib/async"),t.pbkdf2Sync=A("./lib/sync")},{"./lib/async":148,"./lib/sync":151}],148:[function(A,e,t){(function(t,i){var g,r=A("safe-buffer").Buffer,n=A("./precondition"),B=A("./default-encoding"),I=A("./sync"),o=A("./to-buffer"),a=i.crypto&&i.crypto.subtle,Q={sha:"SHA-1","sha-1":"SHA-1",sha1:"SHA-1",sha256:"SHA-256","sha-256":"SHA-256",sha384:"SHA-384","sha-384":"SHA-384","sha-512":"SHA-512",sha512:"SHA-512"},C=[];function s(A,e,t,i,g){return a.importKey("raw",A,{name:"PBKDF2"},!1,["deriveBits"]).then(function(A){return a.deriveBits({name:"PBKDF2",salt:e,iterations:t,hash:{name:g}},A,i<<3)}).then(function(A){return r.from(A)})}e.exports=function(A,e,c,h,f,E){"function"==typeof f&&(E=f,f=void 0);var u=Q[(f=f||"sha1").toLowerCase()];if(!u||"function"!=typeof i.Promise)return t.nextTick(function(){var t;try{t=I(A,e,c,h,f)}catch(A){return E(A)}E(null,t)});if(n(c,h),A=o(A,B,"Password"),e=o(e,B,"Salt"),"function"!=typeof E)throw new Error("No callback provided to pbkdf2");!function(A,e){A.then(function(A){t.nextTick(function(){e(null,A)})},function(A){t.nextTick(function(){e(A)})})}(function(A){if(i.process&&!i.process.browser)return Promise.resolve(!1);if(!a||!a.importKey||!a.deriveBits)return Promise.resolve(!1);if(void 0!==C[A])return C[A];var e=s(g=g||r.alloc(8),g,10,128,A).then(function(){return!0}).catch(function(){return!1});return C[A]=e,e}(u).then(function(t){return t?s(A,e,c,h,u):I(A,e,c,h,f)}),E)}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"./default-encoding":149,"./precondition":150,"./sync":151,"./to-buffer":152,_process:154,"safe-buffer":180}],149:[function(A,e,t){(function(A){var t;if(A.browser)t="utf-8";else if(A.version){t=parseInt(A.version.split(".")[0].slice(1),10)>=6?"utf-8":"binary"}else t="utf-8";e.exports=t}).call(this,A("_process"))},{_process:154}],150:[function(A,e,t){var i=Math.pow(2,30)-1;e.exports=function(A,e){if("number"!=typeof A)throw new TypeError("Iterations not a number");if(A<0)throw new TypeError("Bad iterations");if("number"!=typeof e)throw new TypeError("Key length not a number");if(e<0||e>i||e!=e)throw new TypeError("Bad key length")}},{}],151:[function(A,e,t){var i=A("create-hash/md5"),g=A("ripemd160"),r=A("sha.js"),n=A("safe-buffer").Buffer,B=A("./precondition"),I=A("./default-encoding"),o=A("./to-buffer"),a=n.alloc(128),Q={md5:16,sha1:20,sha224:28,sha256:32,sha384:48,sha512:64,rmd160:20,ripemd160:20};function C(A,e,t){var B=function(A){return"rmd160"===A||"ripemd160"===A?function(A){return(new g).update(A).digest()}:"md5"===A?i:function(e){return r(A).update(e).digest()}}(A),I="sha512"===A||"sha384"===A?128:64;e.length>I?e=B(e):e.length1)for(var t=1;tc||new n(e).cmp(s.modulus)>=0)throw new Error("decryption error");C=t?o(new n(e),s):B(e,s);var h=a.alloc(c-C.length);if(C=a.concat([h,C],c),4===Q)return function(A,e){var t=A.modulus.byteLength(),i=I("sha1").update(a.alloc(0)).digest(),n=i.length;if(0!==e[0])throw new Error("decryption error");var B=e.slice(1,n+1),o=e.slice(n+1),Q=r(B,g(o,n)),C=r(o,g(Q,t-n-1));if(function(A,e){A=a.from(A),e=a.from(e);var t=0,i=A.length;A.length!==e.length&&(t++,i=Math.min(A.length,e.length));var g=-1;for(;++g=e.length){r++;break}var n=e.slice(2,g-1);("0002"!==i.toString("hex")&&!t||"0001"!==i.toString("hex")&&t)&&r++;n.length<8&&r++;if(r)throw new Error("decryption error");return e.slice(g)}(0,C,t);if(3===Q)return C;throw new Error("unknown padding")}},{"./mgf":156,"./withPublic":160,"./xor":161,"bn.js":157,"browserify-rsa":40,"create-hash":69,"parse-asn1":146,"safe-buffer":180}],159:[function(A,e,t){var i=A("parse-asn1"),g=A("randombytes"),r=A("create-hash"),n=A("./mgf"),B=A("./xor"),I=A("bn.js"),o=A("./withPublic"),a=A("browserify-rsa"),Q=A("safe-buffer").Buffer;e.exports=function(A,e,t){var C;C=A.padding?A.padding:t?1:4;var s,c=i(A);if(4===C)s=function(A,e){var t=A.modulus.byteLength(),i=e.length,o=r("sha1").update(Q.alloc(0)).digest(),a=o.length,C=2*a;if(i>t-C-2)throw new Error("message too long");var s=Q.alloc(t-i-C-2),c=t-a-1,h=g(a),f=B(Q.concat([o,s,Q.alloc(1,1),e],c),n(h,c)),E=B(h,n(f,a));return new I(Q.concat([Q.alloc(1),E,f],t))}(c,e);else if(1===C)s=function(A,e,t){var i,r=e.length,n=A.modulus.byteLength();if(r>n-11)throw new Error("message too long");i=t?Q.alloc(n-r-3,255):function(A){var e,t=Q.allocUnsafe(A),i=0,r=g(2*A),n=0;for(;i=0)throw new Error("data too long for modulus")}return t?a(s,c):o(s,c)}},{"./mgf":156,"./withPublic":160,"./xor":161,"bn.js":157,"browserify-rsa":40,"create-hash":69,"parse-asn1":146,randombytes:162,"safe-buffer":180}],160:[function(A,e,t){var i=A("bn.js"),g=A("safe-buffer").Buffer;e.exports=function(A,e){return g.from(A.toRed(i.mont(e.modulus)).redPow(new i(e.publicExponent)).fromRed().toArray())}},{"bn.js":157,"safe-buffer":180}],161:[function(A,e,t){e.exports=function(A,e){for(var t=A.length,i=-1;++ir)throw new RangeError("requested too many random bytes");var i=n.allocUnsafe(A);if(A>0)if(A>g)for(var I=0;Ia||A<0)throw new TypeError("offset must be a uint32");if(A>I||A>e)throw new RangeError("offset out of range")}function C(A,e,t){if("number"!=typeof A||A!=A)throw new TypeError("size must be a number");if(A>a||A<0)throw new TypeError("size must be a uint32");if(A+e>t||A>I)throw new RangeError("buffer too small")}function s(A,t,i,g){if(e.browser){var r=A.buffer,B=new Uint8Array(r,t,i);return o.getRandomValues(B),g?void e.nextTick(function(){g(null,A)}):A}if(!g)return n(i).copy(A,t),A;n(i,function(e,i){if(e)return g(e);i.copy(A,t),g(null,A)})}o&&o.getRandomValues||!e.browser?(t.randomFill=function(A,e,t,g){if(!(B.isBuffer(A)||A instanceof i.Uint8Array))throw new TypeError('"buf" argument must be a Buffer or Uint8Array');if("function"==typeof e)g=e,e=0,t=A.length;else if("function"==typeof t)g=t,t=A.length-e;else if("function"!=typeof g)throw new TypeError('"cb" argument must be a function');return Q(e,A.length),C(t,e,A.length),s(A,e,t,g)},t.randomFillSync=function(A,e,t){void 0===e&&(e=0);if(!(B.isBuffer(A)||A instanceof i.Uint8Array))throw new TypeError('"buf" argument must be a Buffer or Uint8Array');Q(e,A.length),void 0===t&&(t=A.length-e);return C(t,e,A.length),s(A,e,t)}):(t.randomFill=g,t.randomFillSync=g)}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{_process:154,randombytes:162,"safe-buffer":180}],164:[function(A,e,t){e.exports=A("./lib/_stream_duplex.js")},{"./lib/_stream_duplex.js":165}],165:[function(A,e,t){"use strict";var i=A("process-nextick-args"),g=Object.keys||function(A){var e=[];for(var t in A)e.push(t);return e};e.exports=Q;var r=Object.create(A("core-util-is"));r.inherits=A("inherits");var n=A("./_stream_readable"),B=A("./_stream_writable");r.inherits(Q,n);for(var I=g(B.prototype),o=0;o0?("string"==typeof e||n.objectMode||Object.getPrototypeOf(e)===o.prototype||(e=function(A){return o.from(A)}(e)),i?n.endEmitted?A.emit("error",new Error("stream.unshift() after end event")):w(A,n,e,!0):n.ended?A.emit("error",new Error("stream.push() after EOF")):(n.reading=!1,n.decoder&&!t?(e=n.decoder.write(e),n.objectMode||0!==e.length?w(A,n,e,!1):M(A,n)):w(A,n,e,!1))):i||(n.reading=!1));return function(A){return!A.ended&&(A.needReadable||A.lengthe.highWaterMark&&(e.highWaterMark=function(A){return A>=p?A=p:(A--,A|=A>>>1,A|=A>>>2,A|=A>>>4,A|=A>>>8,A|=A>>>16,A++),A}(A)),A<=e.length?A:e.ended?e.length:(e.needReadable=!0,0))}function b(A){var e=A._readableState;e.needReadable=!1,e.emittedReadable||(s("emitReadable",e.flowing),e.emittedReadable=!0,e.sync?g.nextTick(y,A):y(A))}function y(A){s("emit readable"),A.emit("readable"),F(A)}function M(A,e){e.readingMore||(e.readingMore=!0,g.nextTick(m,A,e))}function m(A,e){for(var t=e.length;!e.reading&&!e.flowing&&!e.ended&&e.length=e.length?(t=e.decoder?e.buffer.join(""):1===e.buffer.length?e.buffer.head.data:e.buffer.concat(e.length),e.buffer.clear()):t=function(A,e,t){var i;Ar.length?r.length:A;if(n===r.length?g+=r:g+=r.slice(0,A),0===(A-=n)){n===r.length?(++i,t.next?e.head=t.next:e.head=e.tail=null):(e.head=t,t.data=r.slice(n));break}++i}return e.length-=i,g}(A,e):function(A,e){var t=o.allocUnsafe(A),i=e.head,g=1;i.data.copy(t),A-=i.data.length;for(;i=i.next;){var r=i.data,n=A>r.length?r.length:A;if(r.copy(t,t.length-A,0,n),0===(A-=n)){n===r.length?(++g,i.next?e.head=i.next:e.head=e.tail=null):(e.head=i,i.data=r.slice(n));break}++g}return e.length-=g,t}(A,e);return i}(A,e.buffer,e.decoder),t);var t}function S(A){var e=A._readableState;if(e.length>0)throw new Error('"endReadable()" called on non-empty stream');e.endEmitted||(e.ended=!0,g.nextTick(Y,e,A))}function Y(A,e){A.endEmitted||0!==A.length||(A.endEmitted=!0,e.readable=!1,e.emit("end"))}function v(A,e){for(var t=0,i=A.length;t=e.highWaterMark||e.ended))return s("read: emitReadable",e.length,e.ended),0===e.length&&e.ended?S(this):b(this),null;if(0===(A=D(A,e))&&e.ended)return 0===e.length&&S(this),null;var i,g=e.needReadable;return s("need readable",g),(0===e.length||e.length-A0?N(A,e):null)?(e.needReadable=!0,A=0):e.length-=A,0===e.length&&(e.ended||(e.needReadable=!0),t!==A&&e.ended&&S(this)),null!==i&&this.emit("data",i),i},d.prototype._read=function(A){this.emit("error",new Error("_read() is not implemented"))},d.prototype.pipe=function(A,e){var i=this,r=this._readableState;switch(r.pipesCount){case 0:r.pipes=A;break;case 1:r.pipes=[r.pipes,A];break;default:r.pipes.push(A)}r.pipesCount+=1,s("pipe count=%d opts=%j",r.pipesCount,e);var I=(!e||!1!==e.end)&&A!==t.stdout&&A!==t.stderr?a:d;function o(e,t){s("onunpipe"),e===i&&t&&!1===t.hasUnpiped&&(t.hasUnpiped=!0,s("cleanup"),A.removeListener("close",E),A.removeListener("finish",u),A.removeListener("drain",Q),A.removeListener("error",f),A.removeListener("unpipe",o),i.removeListener("end",a),i.removeListener("end",d),i.removeListener("data",h),C=!0,!r.awaitDrain||A._writableState&&!A._writableState.needDrain||Q())}function a(){s("onend"),A.end()}r.endEmitted?g.nextTick(I):i.once("end",I),A.on("unpipe",o);var Q=function(A){return function(){var e=A._readableState;s("pipeOnDrain",e.awaitDrain),e.awaitDrain&&e.awaitDrain--,0===e.awaitDrain&&B(A,"data")&&(e.flowing=!0,F(A))}}(i);A.on("drain",Q);var C=!1;var c=!1;function h(e){s("ondata"),c=!1,!1!==A.write(e)||c||((1===r.pipesCount&&r.pipes===A||r.pipesCount>1&&-1!==v(r.pipes,A))&&!C&&(s("false write response, pause",i._readableState.awaitDrain),i._readableState.awaitDrain++,c=!0),i.pause())}function f(e){s("onerror",e),d(),A.removeListener("error",f),0===B(A,"error")&&A.emit("error",e)}function E(){A.removeListener("finish",u),d()}function u(){s("onfinish"),A.removeListener("close",E),d()}function d(){s("unpipe"),i.unpipe(A)}return i.on("data",h),function(A,e,t){if("function"==typeof A.prependListener)return A.prependListener(e,t);A._events&&A._events[e]?n(A._events[e])?A._events[e].unshift(t):A._events[e]=[t,A._events[e]]:A.on(e,t)}(A,"error",f),A.once("close",E),A.once("finish",u),A.emit("pipe",i),r.flowing||(s("pipe resume"),i.resume()),A},d.prototype.unpipe=function(A){var e=this._readableState,t={hasUnpiped:!1};if(0===e.pipesCount)return this;if(1===e.pipesCount)return A&&A!==e.pipes?this:(A||(A=e.pipes),e.pipes=null,e.pipesCount=0,e.flowing=!1,A&&A.emit("unpipe",this,t),this);if(!A){var i=e.pipes,g=e.pipesCount;e.pipes=null,e.pipesCount=0,e.flowing=!1;for(var r=0;r-1?g:r.nextTick;u.WritableState=E;var o=Object.create(A("core-util-is"));o.inherits=A("inherits");var a={deprecate:A("util-deprecate")},Q=A("./internal/streams/stream"),C=A("safe-buffer").Buffer,s=i.Uint8Array||function(){};var c,h=A("./internal/streams/destroy");function f(){}function E(e,t){B=B||A("./_stream_duplex"),e=e||{};var i=t instanceof B;this.objectMode=!!e.objectMode,i&&(this.objectMode=this.objectMode||!!e.writableObjectMode);var g=e.highWaterMark,o=e.writableHighWaterMark,a=this.objectMode?16:16384;this.highWaterMark=g||0===g?g:i&&(o||0===o)?o:a,this.highWaterMark=Math.floor(this.highWaterMark),this.finalCalled=!1,this.needDrain=!1,this.ending=!1,this.ended=!1,this.finished=!1,this.destroyed=!1;var Q=!1===e.decodeStrings;this.decodeStrings=!Q,this.defaultEncoding=e.defaultEncoding||"utf8",this.length=0,this.writing=!1,this.corked=0,this.sync=!0,this.bufferProcessing=!1,this.onwrite=function(A){!function(A,e){var t=A._writableState,i=t.sync,g=t.writecb;if(function(A){A.writing=!1,A.writecb=null,A.length-=A.writelen,A.writelen=0}(t),e)!function(A,e,t,i,g){--e.pendingcb,t?(r.nextTick(g,i),r.nextTick(b,A,e),A._writableState.errorEmitted=!0,A.emit("error",i)):(g(i),A._writableState.errorEmitted=!0,A.emit("error",i),b(A,e))}(A,t,i,e,g);else{var n=p(t);n||t.corked||t.bufferProcessing||!t.bufferedRequest||w(A,t),i?I(l,A,t,n,g):l(A,t,n,g)}}(t,A)},this.writecb=null,this.writelen=0,this.bufferedRequest=null,this.lastBufferedRequest=null,this.pendingcb=0,this.prefinished=!1,this.errorEmitted=!1,this.bufferedRequestCount=0,this.corkedRequestsFree=new n(this)}function u(e){if(B=B||A("./_stream_duplex"),!(c.call(u,this)||this instanceof B))return new u(e);this._writableState=new E(e,this),this.writable=!0,e&&("function"==typeof e.write&&(this._write=e.write),"function"==typeof e.writev&&(this._writev=e.writev),"function"==typeof e.destroy&&(this._destroy=e.destroy),"function"==typeof e.final&&(this._final=e.final)),Q.call(this)}function d(A,e,t,i,g,r,n){e.writelen=i,e.writecb=n,e.writing=!0,e.sync=!0,t?A._writev(g,e.onwrite):A._write(g,r,e.onwrite),e.sync=!1}function l(A,e,t,i){t||function(A,e){0===e.length&&e.needDrain&&(e.needDrain=!1,A.emit("drain"))}(A,e),e.pendingcb--,i(),b(A,e)}function w(A,e){e.bufferProcessing=!0;var t=e.bufferedRequest;if(A._writev&&t&&t.next){var i=e.bufferedRequestCount,g=new Array(i),r=e.corkedRequestsFree;r.entry=t;for(var B=0,I=!0;t;)g[B]=t,t.isBuf||(I=!1),t=t.next,B+=1;g.allBuffers=I,d(A,e,!0,e.length,g,"",r.finish),e.pendingcb++,e.lastBufferedRequest=null,r.next?(e.corkedRequestsFree=r.next,r.next=null):e.corkedRequestsFree=new n(e),e.bufferedRequestCount=0}else{for(;t;){var o=t.chunk,a=t.encoding,Q=t.callback;if(d(A,e,!1,e.objectMode?1:o.length,o,a,Q),t=t.next,e.bufferedRequestCount--,e.writing)break}null===t&&(e.lastBufferedRequest=null)}e.bufferedRequest=t,e.bufferProcessing=!1}function p(A){return A.ending&&0===A.length&&null===A.bufferedRequest&&!A.finished&&!A.writing}function D(A,e){A._final(function(t){e.pendingcb--,t&&A.emit("error",t),e.prefinished=!0,A.emit("prefinish"),b(A,e)})}function b(A,e){var t=p(e);return t&&(!function(A,e){e.prefinished||e.finalCalled||("function"==typeof A._final?(e.pendingcb++,e.finalCalled=!0,r.nextTick(D,A,e)):(e.prefinished=!0,A.emit("prefinish")))}(A,e),0===e.pendingcb&&(e.finished=!0,A.emit("finish"))),t}o.inherits(u,Q),E.prototype.getBuffer=function(){for(var A=this.bufferedRequest,e=[];A;)e.push(A),A=A.next;return e},function(){try{Object.defineProperty(E.prototype,"buffer",{get:a.deprecate(function(){return this.getBuffer()},"_writableState.buffer is deprecated. Use _writableState.getBuffer instead.","DEP0003")})}catch(A){}}(),"function"==typeof Symbol&&Symbol.hasInstance&&"function"==typeof Function.prototype[Symbol.hasInstance]?(c=Function.prototype[Symbol.hasInstance],Object.defineProperty(u,Symbol.hasInstance,{value:function(A){return!!c.call(this,A)||this===u&&(A&&A._writableState instanceof E)}})):c=function(A){return A instanceof this},u.prototype.pipe=function(){this.emit("error",new Error("Cannot pipe, not readable"))},u.prototype.write=function(A,e,t){var i,g=this._writableState,n=!1,B=!g.objectMode&&(i=A,C.isBuffer(i)||i instanceof s);return B&&!C.isBuffer(A)&&(A=function(A){return C.from(A)}(A)),"function"==typeof e&&(t=e,e=null),B?e="buffer":e||(e=g.defaultEncoding),"function"!=typeof t&&(t=f),g.ended?function(A,e){var t=new Error("write after end");A.emit("error",t),r.nextTick(e,t)}(this,t):(B||function(A,e,t,i){var g=!0,n=!1;return null===t?n=new TypeError("May not write null values to stream"):"string"==typeof t||void 0===t||e.objectMode||(n=new TypeError("Invalid non-string/buffer chunk")),n&&(A.emit("error",n),r.nextTick(i,n),g=!1),g}(this,g,A,t))&&(g.pendingcb++,n=function(A,e,t,i,g,r){if(!t){var n=function(A,e,t){A.objectMode||!1===A.decodeStrings||"string"!=typeof e||(e=C.from(e,t));return e}(e,i,g);i!==n&&(t=!0,g="buffer",i=n)}var B=e.objectMode?1:i.length;e.length+=B;var I=e.length-1))throw new TypeError("Unknown encoding: "+A);return this._writableState.defaultEncoding=A,this},Object.defineProperty(u.prototype,"writableHighWaterMark",{enumerable:!1,get:function(){return this._writableState.highWaterMark}}),u.prototype._write=function(A,e,t){t(new Error("_write() is not implemented"))},u.prototype._writev=null,u.prototype.end=function(A,e,t){var i=this._writableState;"function"==typeof A?(t=A,A=null,e=null):"function"==typeof e&&(t=e,e=null),null!==A&&void 0!==A&&this.write(A,e),i.corked&&(i.corked=1,this.uncork()),i.ending||i.finished||function(A,e,t){e.ending=!0,b(A,e),t&&(e.finished?r.nextTick(t):A.once("finish",t));e.ended=!0,A.writable=!1}(this,i,t)},Object.defineProperty(u.prototype,"destroyed",{get:function(){return void 0!==this._writableState&&this._writableState.destroyed},set:function(A){this._writableState&&(this._writableState.destroyed=A)}}),u.prototype.destroy=h.destroy,u.prototype._undestroy=h.undestroy,u.prototype._destroy=function(A,e){this.end(),e(A)}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{},A("timers").setImmediate)},{"./_stream_duplex":165,"./internal/streams/destroy":171,"./internal/streams/stream":172,_process:154,"core-util-is":66,inherits:134,"process-nextick-args":153,"safe-buffer":173,timers:192,"util-deprecate":193}],170:[function(A,e,t){"use strict";var i=A("safe-buffer").Buffer,g=A("util");e.exports=function(){function A(){!function(A,e){if(!(A instanceof e))throw new TypeError("Cannot call a class as a function")}(this,A),this.head=null,this.tail=null,this.length=0}return A.prototype.push=function(A){var e={data:A,next:null};this.length>0?this.tail.next=e:this.head=e,this.tail=e,++this.length},A.prototype.unshift=function(A){var e={data:A,next:this.head};0===this.length&&(this.tail=e),this.head=e,++this.length},A.prototype.shift=function(){if(0!==this.length){var A=this.head.data;return 1===this.length?this.head=this.tail=null:this.head=this.head.next,--this.length,A}},A.prototype.clear=function(){this.head=this.tail=null,this.length=0},A.prototype.join=function(A){if(0===this.length)return"";for(var e=this.head,t=""+e.data;e=e.next;)t+=A+e.data;return t},A.prototype.concat=function(A){if(0===this.length)return i.alloc(0);if(1===this.length)return this.head.data;for(var e,t,g,r=i.allocUnsafe(A>>>0),n=this.head,B=0;n;)e=n.data,t=r,g=B,e.copy(t,g),B+=n.data.length,n=n.next;return r},A}(),g&&g.inspect&&g.inspect.custom&&(e.exports.prototype[g.inspect.custom]=function(){var A=g.inspect({length:this.length});return this.constructor.name+" "+A})},{"safe-buffer":173,util:19}],171:[function(A,e,t){"use strict";var i=A("process-nextick-args");function g(A,e){A.emit("error",e)}e.exports={destroy:function(A,e){var t=this,r=this._readableState&&this._readableState.destroyed,n=this._writableState&&this._writableState.destroyed;return r||n?(e?e(A):!A||this._writableState&&this._writableState.errorEmitted||i.nextTick(g,this,A),this):(this._readableState&&(this._readableState.destroyed=!0),this._writableState&&(this._writableState.destroyed=!0),this._destroy(A||null,function(A){!e&&A?(i.nextTick(g,t,A),t._writableState&&(t._writableState.errorEmitted=!0)):e&&e(A)}),this)},undestroy:function(){this._readableState&&(this._readableState.destroyed=!1,this._readableState.reading=!1,this._readableState.ended=!1,this._readableState.endEmitted=!1),this._writableState&&(this._writableState.destroyed=!1,this._writableState.ended=!1,this._writableState.ending=!1,this._writableState.finished=!1,this._writableState.errorEmitted=!1)}}},{"process-nextick-args":153}],172:[function(A,e,t){arguments[4][61][0].apply(t,arguments)},{dup:61,events:102}],173:[function(A,e,t){var i=A("buffer"),g=i.Buffer;function r(A,e){for(var t in A)e[t]=A[t]}function n(A,e,t){return g(A,e,t)}g.from&&g.alloc&&g.allocUnsafe&&g.allocUnsafeSlow?e.exports=i:(r(i,t),t.Buffer=n),r(g,n),n.from=function(A,e,t){if("number"==typeof A)throw new TypeError("Argument must not be a number");return g(A,e,t)},n.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError("Argument must be a number");var i=g(A);return void 0!==e?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i},n.allocUnsafe=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return g(A)},n.allocUnsafeSlow=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return i.SlowBuffer(A)}},{buffer:64}],174:[function(A,e,t){"use strict";var i=A("safe-buffer").Buffer,g=i.isEncoding||function(A){switch((A=""+A)&&A.toLowerCase()){case"hex":case"utf8":case"utf-8":case"ascii":case"binary":case"base64":case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":case"raw":return!0;default:return!1}};function r(A){var e;switch(this.encoding=function(A){var e=function(A){if(!A)return"utf8";for(var e;;)switch(A){case"utf8":case"utf-8":return"utf8";case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return"utf16le";case"latin1":case"binary":return"latin1";case"base64":case"ascii":case"hex":return A;default:if(e)return;A=(""+A).toLowerCase(),e=!0}}(A);if("string"!=typeof e&&(i.isEncoding===g||!g(A)))throw new Error("Unknown encoding: "+A);return e||A}(A),this.encoding){case"utf16le":this.text=I,this.end=o,e=4;break;case"utf8":this.fillLast=B,e=4;break;case"base64":this.text=a,this.end=Q,e=3;break;default:return this.write=C,void(this.end=s)}this.lastNeed=0,this.lastTotal=0,this.lastChar=i.allocUnsafe(e)}function n(A){return A<=127?0:A>>5==6?2:A>>4==14?3:A>>3==30?4:A>>6==2?-1:-2}function B(A){var e=this.lastTotal-this.lastNeed,t=function(A,e,t){if(128!=(192&e[0]))return A.lastNeed=0,"�";if(A.lastNeed>1&&e.length>1){if(128!=(192&e[1]))return A.lastNeed=1,"�";if(A.lastNeed>2&&e.length>2&&128!=(192&e[2]))return A.lastNeed=2,"�"}}(this,A);return void 0!==t?t:this.lastNeed<=A.length?(A.copy(this.lastChar,e,0,this.lastNeed),this.lastChar.toString(this.encoding,0,this.lastTotal)):(A.copy(this.lastChar,e,0,A.length),void(this.lastNeed-=A.length))}function I(A,e){if((A.length-e)%2==0){var t=A.toString("utf16le",e);if(t){var i=t.charCodeAt(t.length-1);if(i>=55296&&i<=56319)return this.lastNeed=2,this.lastTotal=4,this.lastChar[0]=A[A.length-2],this.lastChar[1]=A[A.length-1],t.slice(0,-1)}return t}return this.lastNeed=1,this.lastTotal=2,this.lastChar[0]=A[A.length-1],A.toString("utf16le",e,A.length-1)}function o(A){var e=A&&A.length?this.write(A):"";if(this.lastNeed){var t=this.lastTotal-this.lastNeed;return e+this.lastChar.toString("utf16le",0,t)}return e}function a(A,e){var t=(A.length-e)%3;return 0===t?A.toString("base64",e):(this.lastNeed=3-t,this.lastTotal=3,1===t?this.lastChar[0]=A[A.length-1]:(this.lastChar[0]=A[A.length-2],this.lastChar[1]=A[A.length-1]),A.toString("base64",e,A.length-t))}function Q(A){var e=A&&A.length?this.write(A):"";return this.lastNeed?e+this.lastChar.toString("base64",0,3-this.lastNeed):e}function C(A){return A.toString(this.encoding)}function s(A){return A&&A.length?this.write(A):""}t.StringDecoder=r,r.prototype.write=function(A){if(0===A.length)return"";var e,t;if(this.lastNeed){if(void 0===(e=this.fillLast(A)))return"";t=this.lastNeed,this.lastNeed=0}else t=0;return t=0)return g>0&&(A.lastNeed=g-1),g;if(--i=0)return g>0&&(A.lastNeed=g-2),g;if(--i=0)return g>0&&(2===g?g=0:A.lastNeed=g-3),g;return 0}(this,A,e);if(!this.lastNeed)return A.toString("utf8",e);this.lastTotal=t;var i=A.length-(t-this.lastNeed);return A.copy(this.lastChar,0,i),A.toString("utf8",e,i)},r.prototype.fillLast=function(A){if(this.lastNeed<=A.length)return A.copy(this.lastChar,this.lastTotal-this.lastNeed,0,this.lastNeed),this.lastChar.toString(this.encoding,0,this.lastTotal);A.copy(this.lastChar,this.lastTotal-this.lastNeed,0,A.length),this.lastNeed-=A.length}},{"safe-buffer":173}],175:[function(A,e,t){e.exports=A("./readable").PassThrough},{"./readable":176}],176:[function(A,e,t){(t=e.exports=A("./lib/_stream_readable.js")).Stream=t,t.Readable=t,t.Writable=A("./lib/_stream_writable.js"),t.Duplex=A("./lib/_stream_duplex.js"),t.Transform=A("./lib/_stream_transform.js"),t.PassThrough=A("./lib/_stream_passthrough.js")},{"./lib/_stream_duplex.js":165,"./lib/_stream_passthrough.js":166,"./lib/_stream_readable.js":167,"./lib/_stream_transform.js":168,"./lib/_stream_writable.js":169}],177:[function(A,e,t){e.exports=A("./readable").Transform},{"./readable":176}],178:[function(A,e,t){e.exports=A("./lib/_stream_writable.js")},{"./lib/_stream_writable.js":169}],179:[function(A,e,t){"use strict";var i=A("buffer").Buffer,g=A("inherits"),r=A("hash-base"),n=new Array(16),B=[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,7,4,13,1,10,6,15,3,12,0,9,5,2,14,11,8,3,10,14,4,9,15,8,1,2,7,0,6,13,11,5,12,1,9,11,10,0,8,12,4,13,3,7,15,14,5,6,2,4,0,5,9,7,12,2,10,14,1,3,8,11,6,15,13],I=[5,14,7,0,9,2,11,4,13,6,15,8,1,10,3,12,6,11,3,7,0,13,5,10,14,15,8,12,4,9,1,2,15,5,1,3,7,14,6,9,11,8,12,2,10,0,4,13,8,6,4,1,3,11,15,0,5,12,2,13,9,7,10,14,12,15,10,4,1,5,8,7,6,2,13,14,0,3,9,11],o=[11,14,15,12,5,8,7,9,11,13,14,15,6,7,9,8,7,6,8,13,11,9,7,15,7,12,15,9,11,7,13,12,11,13,6,7,14,9,13,15,14,8,13,6,5,12,7,5,11,12,14,15,14,15,9,8,9,14,5,6,8,6,5,12,9,15,5,11,6,8,13,12,5,12,13,14,11,8,5,6],a=[8,9,9,11,13,15,15,5,7,7,8,11,14,14,12,6,9,13,15,7,12,8,9,11,7,7,12,7,6,15,13,11,9,7,15,11,8,6,6,14,12,13,5,14,13,13,7,5,15,5,8,11,14,14,6,14,6,9,12,9,12,5,15,8,8,5,12,9,12,5,14,6,8,13,6,5,15,13,11,11],Q=[0,1518500249,1859775393,2400959708,2840853838],C=[1352829926,1548603684,1836072691,2053994217,0];function s(){r.call(this,64),this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878,this._e=3285377520}function c(A,e){return A<>>32-e}function h(A,e,t,i,g,r,n,B){return c(A+(e^t^i)+r+n|0,B)+g|0}function f(A,e,t,i,g,r,n,B){return c(A+(e&t|~e&i)+r+n|0,B)+g|0}function E(A,e,t,i,g,r,n,B){return c(A+((e|~t)^i)+r+n|0,B)+g|0}function u(A,e,t,i,g,r,n,B){return c(A+(e&i|t&~i)+r+n|0,B)+g|0}function d(A,e,t,i,g,r,n,B){return c(A+(e^(t|~i))+r+n|0,B)+g|0}g(s,r),s.prototype._update=function(){for(var A=n,e=0;e<16;++e)A[e]=this._block.readInt32LE(4*e);for(var t=0|this._a,i=0|this._b,g=0|this._c,r=0|this._d,s=0|this._e,l=0|this._a,w=0|this._b,p=0|this._c,D=0|this._d,b=0|this._e,y=0;y<80;y+=1){var M,m;y<16?(M=h(t,i,g,r,s,A[B[y]],Q[0],o[y]),m=d(l,w,p,D,b,A[I[y]],C[0],a[y])):y<32?(M=f(t,i,g,r,s,A[B[y]],Q[1],o[y]),m=u(l,w,p,D,b,A[I[y]],C[1],a[y])):y<48?(M=E(t,i,g,r,s,A[B[y]],Q[2],o[y]),m=E(l,w,p,D,b,A[I[y]],C[2],a[y])):y<64?(M=u(t,i,g,r,s,A[B[y]],Q[3],o[y]),m=f(l,w,p,D,b,A[I[y]],C[3],a[y])):(M=d(t,i,g,r,s,A[B[y]],Q[4],o[y]),m=h(l,w,p,D,b,A[I[y]],C[4],a[y])),t=s,s=r,r=c(g,10),g=i,i=M,l=b,b=D,D=c(p,10),p=w,w=m}var G=this._b+g+D|0;this._b=this._c+r+b|0,this._c=this._d+s+l|0,this._d=this._e+t+w|0,this._e=this._a+i+p|0,this._a=G},s.prototype._digest=function(){this._block[this._blockOffset++]=128,this._blockOffset>56&&(this._block.fill(0,this._blockOffset,64),this._update(),this._blockOffset=0),this._block.fill(0,this._blockOffset,56),this._block.writeUInt32LE(this._length[0],56),this._block.writeUInt32LE(this._length[1],60),this._update();var A=i.alloc?i.alloc(20):new i(20);return A.writeInt32LE(this._a,0),A.writeInt32LE(this._b,4),A.writeInt32LE(this._c,8),A.writeInt32LE(this._d,12),A.writeInt32LE(this._e,16),A},e.exports=s},{buffer:64,"hash-base":104,inherits:134}],180:[function(A,e,t){var i=A("buffer"),g=i.Buffer;function r(A,e){for(var t in A)e[t]=A[t]}function n(A,e,t){return g(A,e,t)}g.from&&g.alloc&&g.allocUnsafe&&g.allocUnsafeSlow?e.exports=i:(r(i,t),t.Buffer=n),n.prototype=Object.create(g.prototype),r(g,n),n.from=function(A,e,t){if("number"==typeof A)throw new TypeError("Argument must not be a number");return g(A,e,t)},n.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError("Argument must be a number");var i=g(A);return void 0!==e?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i},n.allocUnsafe=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return g(A)},n.allocUnsafeSlow=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return i.SlowBuffer(A)}},{buffer:64}],181:[function(A,e,t){(function(t){"use strict";var i,g=A("buffer"),r=g.Buffer,n={};for(i in g)g.hasOwnProperty(i)&&"SlowBuffer"!==i&&"Buffer"!==i&&(n[i]=g[i]);var B=n.Buffer={};for(i in r)r.hasOwnProperty(i)&&"allocUnsafe"!==i&&"allocUnsafeSlow"!==i&&(B[i]=r[i]);if(n.Buffer.prototype=r.prototype,B.from&&B.from!==Uint8Array.from||(B.from=function(A,e,t){if("number"==typeof A)throw new TypeError('The "value" argument must not be of type number. Received type '+typeof A);if(A&&void 0===A.length)throw new TypeError("The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type "+typeof A);return r(A,e,t)}),B.alloc||(B.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError('The "size" argument must be of type number. Received type '+typeof A);if(A<0||A>=2*(1<<30))throw new RangeError('The value "'+A+'" is invalid for option "size"');var i=r(A);return e&&0!==e.length?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i}),!n.kStringMaxLength)try{n.kStringMaxLength=t.binding("buffer").kStringMaxLength}catch(A){}n.constants||(n.constants={MAX_LENGTH:n.kMaxLength},n.kStringMaxLength&&(n.constants.MAX_STRING_LENGTH=n.kStringMaxLength)),e.exports=n}).call(this,A("_process"))},{_process:154,buffer:64}],182:[function(A,e,t){var i=A("safe-buffer").Buffer;function g(A,e){this._block=i.alloc(A),this._finalSize=e,this._blockSize=A,this._len=0}g.prototype.update=function(A,e){"string"==typeof A&&(e=e||"utf8",A=i.from(A,e));for(var t=this._block,g=this._blockSize,r=A.length,n=this._len,B=0;B=this._finalSize&&(this._update(this._block),this._block.fill(0));var t=8*this._len;if(t<=4294967295)this._block.writeUInt32BE(t,this._blockSize-4);else{var i=(4294967295&t)>>>0,g=(t-i)/4294967296;this._block.writeUInt32BE(g,this._blockSize-8),this._block.writeUInt32BE(i,this._blockSize-4)}this._update(this._block);var r=this._hash();return A?r.toString(A):r},g.prototype._update=function(){throw new Error("_update must be implemented by subclass")},e.exports=g},{"safe-buffer":180}],183:[function(A,e,t){(t=e.exports=function(A){A=A.toLowerCase();var e=t[A];if(!e)throw new Error(A+" is not supported (we accept pull requests)");return new e}).sha=A("./sha"),t.sha1=A("./sha1"),t.sha224=A("./sha224"),t.sha256=A("./sha256"),t.sha384=A("./sha384"),t.sha512=A("./sha512")},{"./sha":184,"./sha1":185,"./sha224":186,"./sha256":187,"./sha384":188,"./sha512":189}],184:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1518500249,1859775393,-1894007588,-899497514],B=new Array(80);function I(){this.init(),this._w=B,g.call(this,64,56)}function o(A){return A<<30|A>>>2}function a(A,e,t,i){return 0===A?e&t|~e&i:2===A?e&t|e&i|t&i:e^t^i}i(I,g),I.prototype.init=function(){return this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878,this._e=3285377520,this},I.prototype._update=function(A){for(var e,t=this._w,i=0|this._a,g=0|this._b,r=0|this._c,B=0|this._d,I=0|this._e,Q=0;Q<16;++Q)t[Q]=A.readInt32BE(4*Q);for(;Q<80;++Q)t[Q]=t[Q-3]^t[Q-8]^t[Q-14]^t[Q-16];for(var C=0;C<80;++C){var s=~~(C/20),c=0|((e=i)<<5|e>>>27)+a(s,g,r,B)+I+t[C]+n[s];I=B,B=r,r=o(g),g=i,i=c}this._a=i+this._a|0,this._b=g+this._b|0,this._c=r+this._c|0,this._d=B+this._d|0,this._e=I+this._e|0},I.prototype._hash=function(){var A=r.allocUnsafe(20);return A.writeInt32BE(0|this._a,0),A.writeInt32BE(0|this._b,4),A.writeInt32BE(0|this._c,8),A.writeInt32BE(0|this._d,12),A.writeInt32BE(0|this._e,16),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],185:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1518500249,1859775393,-1894007588,-899497514],B=new Array(80);function I(){this.init(),this._w=B,g.call(this,64,56)}function o(A){return A<<5|A>>>27}function a(A){return A<<30|A>>>2}function Q(A,e,t,i){return 0===A?e&t|~e&i:2===A?e&t|e&i|t&i:e^t^i}i(I,g),I.prototype.init=function(){return this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878,this._e=3285377520,this},I.prototype._update=function(A){for(var e,t=this._w,i=0|this._a,g=0|this._b,r=0|this._c,B=0|this._d,I=0|this._e,C=0;C<16;++C)t[C]=A.readInt32BE(4*C);for(;C<80;++C)t[C]=(e=t[C-3]^t[C-8]^t[C-14]^t[C-16])<<1|e>>>31;for(var s=0;s<80;++s){var c=~~(s/20),h=o(i)+Q(c,g,r,B)+I+t[s]+n[c]|0;I=B,B=r,r=a(g),g=i,i=h}this._a=i+this._a|0,this._b=g+this._b|0,this._c=r+this._c|0,this._d=B+this._d|0,this._e=I+this._e|0},I.prototype._hash=function(){var A=r.allocUnsafe(20);return A.writeInt32BE(0|this._a,0),A.writeInt32BE(0|this._b,4),A.writeInt32BE(0|this._c,8),A.writeInt32BE(0|this._d,12),A.writeInt32BE(0|this._e,16),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],186:[function(A,e,t){var i=A("inherits"),g=A("./sha256"),r=A("./hash"),n=A("safe-buffer").Buffer,B=new Array(64);function I(){this.init(),this._w=B,r.call(this,64,56)}i(I,g),I.prototype.init=function(){return this._a=3238371032,this._b=914150663,this._c=812702999,this._d=4144912697,this._e=4290775857,this._f=1750603025,this._g=1694076839,this._h=3204075428,this},I.prototype._hash=function(){var A=n.allocUnsafe(28);return A.writeInt32BE(this._a,0),A.writeInt32BE(this._b,4),A.writeInt32BE(this._c,8),A.writeInt32BE(this._d,12),A.writeInt32BE(this._e,16),A.writeInt32BE(this._f,20),A.writeInt32BE(this._g,24),A},e.exports=I},{"./hash":182,"./sha256":187,inherits:134,"safe-buffer":180}],187:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1116352408,1899447441,3049323471,3921009573,961987163,1508970993,2453635748,2870763221,3624381080,310598401,607225278,1426881987,1925078388,2162078206,2614888103,3248222580,3835390401,4022224774,264347078,604807628,770255983,1249150122,1555081692,1996064986,2554220882,2821834349,2952996808,3210313671,3336571891,3584528711,113926993,338241895,666307205,773529912,1294757372,1396182291,1695183700,1986661051,2177026350,2456956037,2730485921,2820302411,3259730800,3345764771,3516065817,3600352804,4094571909,275423344,430227734,506948616,659060556,883997877,958139571,1322822218,1537002063,1747873779,1955562222,2024104815,2227730452,2361852424,2428436474,2756734187,3204031479,3329325298],B=new Array(64);function I(){this.init(),this._w=B,g.call(this,64,56)}function o(A,e,t){return t^A&(e^t)}function a(A,e,t){return A&e|t&(A|e)}function Q(A){return(A>>>2|A<<30)^(A>>>13|A<<19)^(A>>>22|A<<10)}function C(A){return(A>>>6|A<<26)^(A>>>11|A<<21)^(A>>>25|A<<7)}function s(A){return(A>>>7|A<<25)^(A>>>18|A<<14)^A>>>3}i(I,g),I.prototype.init=function(){return this._a=1779033703,this._b=3144134277,this._c=1013904242,this._d=2773480762,this._e=1359893119,this._f=2600822924,this._g=528734635,this._h=1541459225,this},I.prototype._update=function(A){for(var e,t=this._w,i=0|this._a,g=0|this._b,r=0|this._c,B=0|this._d,I=0|this._e,c=0|this._f,h=0|this._g,f=0|this._h,E=0;E<16;++E)t[E]=A.readInt32BE(4*E);for(;E<64;++E)t[E]=0|(((e=t[E-2])>>>17|e<<15)^(e>>>19|e<<13)^e>>>10)+t[E-7]+s(t[E-15])+t[E-16];for(var u=0;u<64;++u){var d=f+C(I)+o(I,c,h)+n[u]+t[u]|0,l=Q(i)+a(i,g,r)|0;f=h,h=c,c=I,I=B+d|0,B=r,r=g,g=i,i=d+l|0}this._a=i+this._a|0,this._b=g+this._b|0,this._c=r+this._c|0,this._d=B+this._d|0,this._e=I+this._e|0,this._f=c+this._f|0,this._g=h+this._g|0,this._h=f+this._h|0},I.prototype._hash=function(){var A=r.allocUnsafe(32);return A.writeInt32BE(this._a,0),A.writeInt32BE(this._b,4),A.writeInt32BE(this._c,8),A.writeInt32BE(this._d,12),A.writeInt32BE(this._e,16),A.writeInt32BE(this._f,20),A.writeInt32BE(this._g,24),A.writeInt32BE(this._h,28),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],188:[function(A,e,t){var i=A("inherits"),g=A("./sha512"),r=A("./hash"),n=A("safe-buffer").Buffer,B=new Array(160);function I(){this.init(),this._w=B,r.call(this,128,112)}i(I,g),I.prototype.init=function(){return this._ah=3418070365,this._bh=1654270250,this._ch=2438529370,this._dh=355462360,this._eh=1731405415,this._fh=2394180231,this._gh=3675008525,this._hh=1203062813,this._al=3238371032,this._bl=914150663,this._cl=812702999,this._dl=4144912697,this._el=4290775857,this._fl=1750603025,this._gl=1694076839,this._hl=3204075428,this},I.prototype._hash=function(){var A=n.allocUnsafe(48);function e(e,t,i){A.writeInt32BE(e,i),A.writeInt32BE(t,i+4)}return e(this._ah,this._al,0),e(this._bh,this._bl,8),e(this._ch,this._cl,16),e(this._dh,this._dl,24),e(this._eh,this._el,32),e(this._fh,this._fl,40),A},e.exports=I},{"./hash":182,"./sha512":189,inherits:134,"safe-buffer":180}],189:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1116352408,3609767458,1899447441,602891725,3049323471,3964484399,3921009573,2173295548,961987163,4081628472,1508970993,3053834265,2453635748,2937671579,2870763221,3664609560,3624381080,2734883394,310598401,1164996542,607225278,1323610764,1426881987,3590304994,1925078388,4068182383,2162078206,991336113,2614888103,633803317,3248222580,3479774868,3835390401,2666613458,4022224774,944711139,264347078,2341262773,604807628,2007800933,770255983,1495990901,1249150122,1856431235,1555081692,3175218132,1996064986,2198950837,2554220882,3999719339,2821834349,766784016,2952996808,2566594879,3210313671,3203337956,3336571891,1034457026,3584528711,2466948901,113926993,3758326383,338241895,168717936,666307205,1188179964,773529912,1546045734,1294757372,1522805485,1396182291,2643833823,1695183700,2343527390,1986661051,1014477480,2177026350,1206759142,2456956037,344077627,2730485921,1290863460,2820302411,3158454273,3259730800,3505952657,3345764771,106217008,3516065817,3606008344,3600352804,1432725776,4094571909,1467031594,275423344,851169720,430227734,3100823752,506948616,1363258195,659060556,3750685593,883997877,3785050280,958139571,3318307427,1322822218,3812723403,1537002063,2003034995,1747873779,3602036899,1955562222,1575990012,2024104815,1125592928,2227730452,2716904306,2361852424,442776044,2428436474,593698344,2756734187,3733110249,3204031479,2999351573,3329325298,3815920427,3391569614,3928383900,3515267271,566280711,3940187606,3454069534,4118630271,4000239992,116418474,1914138554,174292421,2731055270,289380356,3203993006,460393269,320620315,685471733,587496836,852142971,1086792851,1017036298,365543100,1126000580,2618297676,1288033470,3409855158,1501505948,4234509866,1607167915,987167468,1816402316,1246189591],B=new Array(160);function I(){this.init(),this._w=B,g.call(this,128,112)}function o(A,e,t){return t^A&(e^t)}function a(A,e,t){return A&e|t&(A|e)}function Q(A,e){return(A>>>28|e<<4)^(e>>>2|A<<30)^(e>>>7|A<<25)}function C(A,e){return(A>>>14|e<<18)^(A>>>18|e<<14)^(e>>>9|A<<23)}function s(A,e){return(A>>>1|e<<31)^(A>>>8|e<<24)^A>>>7}function c(A,e){return(A>>>1|e<<31)^(A>>>8|e<<24)^(A>>>7|e<<25)}function h(A,e){return(A>>>19|e<<13)^(e>>>29|A<<3)^A>>>6}function f(A,e){return(A>>>19|e<<13)^(e>>>29|A<<3)^(A>>>6|e<<26)}function E(A,e){return A>>>0>>0?1:0}i(I,g),I.prototype.init=function(){return this._ah=1779033703,this._bh=3144134277,this._ch=1013904242,this._dh=2773480762,this._eh=1359893119,this._fh=2600822924,this._gh=528734635,this._hh=1541459225,this._al=4089235720,this._bl=2227873595,this._cl=4271175723,this._dl=1595750129,this._el=2917565137,this._fl=725511199,this._gl=4215389547,this._hl=327033209,this},I.prototype._update=function(A){for(var e=this._w,t=0|this._ah,i=0|this._bh,g=0|this._ch,r=0|this._dh,B=0|this._eh,I=0|this._fh,u=0|this._gh,d=0|this._hh,l=0|this._al,w=0|this._bl,p=0|this._cl,D=0|this._dl,b=0|this._el,y=0|this._fl,M=0|this._gl,m=0|this._hl,G=0;G<32;G+=2)e[G]=A.readInt32BE(4*G),e[G+1]=A.readInt32BE(4*G+4);for(;G<160;G+=2){var k=e[G-30],F=e[G-30+1],N=s(k,F),S=c(F,k),Y=h(k=e[G-4],F=e[G-4+1]),v=f(F,k),K=e[G-14],U=e[G-14+1],J=e[G-32],H=e[G-32+1],R=S+U|0,q=N+K+E(R,S)|0;q=(q=q+Y+E(R=R+v|0,v)|0)+J+E(R=R+H|0,H)|0,e[G]=q,e[G+1]=R}for(var L=0;L<160;L+=2){q=e[L],R=e[L+1];var x=a(t,i,g),Z=a(l,w,p),j=Q(t,l),W=Q(l,t),O=C(B,b),P=C(b,B),V=n[L],X=n[L+1],z=o(B,I,u),T=o(b,y,M),_=m+P|0,$=d+O+E(_,m)|0;$=($=($=$+z+E(_=_+T|0,T)|0)+V+E(_=_+X|0,X)|0)+q+E(_=_+R|0,R)|0;var AA=W+Z|0,eA=j+x+E(AA,W)|0;d=u,m=M,u=I,M=y,I=B,y=b,B=r+$+E(b=D+_|0,D)|0,r=g,D=p,g=i,p=w,i=t,w=l,t=$+eA+E(l=_+AA|0,_)|0}this._al=this._al+l|0,this._bl=this._bl+w|0,this._cl=this._cl+p|0,this._dl=this._dl+D|0,this._el=this._el+b|0,this._fl=this._fl+y|0,this._gl=this._gl+M|0,this._hl=this._hl+m|0,this._ah=this._ah+t+E(this._al,l)|0,this._bh=this._bh+i+E(this._bl,w)|0,this._ch=this._ch+g+E(this._cl,p)|0,this._dh=this._dh+r+E(this._dl,D)|0,this._eh=this._eh+B+E(this._el,b)|0,this._fh=this._fh+I+E(this._fl,y)|0,this._gh=this._gh+u+E(this._gl,M)|0,this._hh=this._hh+d+E(this._hl,m)|0},I.prototype._hash=function(){var A=r.allocUnsafe(64);function e(e,t,i){A.writeInt32BE(e,i),A.writeInt32BE(t,i+4)}return e(this._ah,this._al,0),e(this._bh,this._bl,8),e(this._ch,this._cl,16),e(this._dh,this._dl,24),e(this._eh,this._el,32),e(this._fh,this._fl,40),e(this._gh,this._gl,48),e(this._hh,this._hl,56),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],190:[function(A,e,t){e.exports=g;var i=A("events").EventEmitter;function g(){i.call(this)}A("inherits")(g,i),g.Readable=A("readable-stream/readable.js"),g.Writable=A("readable-stream/writable.js"),g.Duplex=A("readable-stream/duplex.js"),g.Transform=A("readable-stream/transform.js"),g.PassThrough=A("readable-stream/passthrough.js"),g.Stream=g,g.prototype.pipe=function(A,e){var t=this;function g(e){A.writable&&!1===A.write(e)&&t.pause&&t.pause()}function r(){t.readable&&t.resume&&t.resume()}t.on("data",g),A.on("drain",r),A._isStdio||e&&!1===e.end||(t.on("end",B),t.on("close",I));var n=!1;function B(){n||(n=!0,A.end())}function I(){n||(n=!0,"function"==typeof A.destroy&&A.destroy())}function o(A){if(a(),0===i.listenerCount(this,"error"))throw A}function a(){t.removeListener("data",g),A.removeListener("drain",r),t.removeListener("end",B),t.removeListener("close",I),t.removeListener("error",o),A.removeListener("error",o),t.removeListener("end",a),t.removeListener("close",a),A.removeListener("close",a)}return t.on("error",o),A.on("error",o),t.on("end",a),t.on("close",a),A.on("close",a),A.emit("pipe",t),A}},{events:102,inherits:134,"readable-stream/duplex.js":164,"readable-stream/passthrough.js":175,"readable-stream/readable.js":176,"readable-stream/transform.js":177,"readable-stream/writable.js":178}],191:[function(A,e,t){arguments[4][174][0].apply(t,arguments)},{dup:174,"safe-buffer":180}],192:[function(A,e,t){(function(e,i){var g=A("process/browser.js").nextTick,r=Function.prototype.apply,n=Array.prototype.slice,B={},I=0;function o(A,e){this._id=A,this._clearFn=e}t.setTimeout=function(){return new o(r.call(setTimeout,window,arguments),clearTimeout)},t.setInterval=function(){return new o(r.call(setInterval,window,arguments),clearInterval)},t.clearTimeout=t.clearInterval=function(A){A.close()},o.prototype.unref=o.prototype.ref=function(){},o.prototype.close=function(){this._clearFn.call(window,this._id)},t.enroll=function(A,e){clearTimeout(A._idleTimeoutId),A._idleTimeout=e},t.unenroll=function(A){clearTimeout(A._idleTimeoutId),A._idleTimeout=-1},t._unrefActive=t.active=function(A){clearTimeout(A._idleTimeoutId);var e=A._idleTimeout;e>=0&&(A._idleTimeoutId=setTimeout(function(){A._onTimeout&&A._onTimeout()},e))},t.setImmediate="function"==typeof e?e:function(A){var e=I++,i=!(arguments.length<2)&&n.call(arguments,1);return B[e]=!0,g(function(){B[e]&&(i?A.apply(null,i):A.call(null),t.clearImmediate(e))}),e},t.clearImmediate="function"==typeof i?i:function(A){delete B[A]}}).call(this,A("timers").setImmediate,A("timers").clearImmediate)},{"process/browser.js":154,timers:192}],193:[function(A,e,t){(function(A){function t(e){try{if(!A.localStorage)return!1}catch(A){return!1}var t=A.localStorage[e];return null!=t&&"true"===String(t).toLowerCase()}e.exports=function(A,e){if(t("noDeprecation"))return A;var i=!1;return function(){if(!i){if(t("throwDeprecation"))throw new Error(e);t("traceDeprecation")?console.trace(e):console.warn(e),i=!0}return A.apply(this,arguments)}}}).call(this,"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{}],194:[function(A,e,t){"function"==typeof Object.create?e.exports=function(A,e){A.super_=e,A.prototype=Object.create(e.prototype,{constructor:{value:A,enumerable:!1,writable:!0,configurable:!0}})}:e.exports=function(A,e){A.super_=e;var t=function(){};t.prototype=e.prototype,A.prototype=new t,A.prototype.constructor=A}},{}],195:[function(A,e,t){e.exports=function(A){return A&&"object"==typeof A&&"function"==typeof A.copy&&"function"==typeof A.fill&&"function"==typeof A.readUInt8}},{}],196:[function(A,e,t){(function(e,i){var g=/%[sdj%]/g;t.format=function(A){if(!E(A)){for(var e=[],t=0;t=r)return A;switch(A){case"%s":return String(i[t++]);case"%d":return Number(i[t++]);case"%j":try{return JSON.stringify(i[t++])}catch(A){return"[Circular]"}default:return A}}),I=i[t];t=3&&(i.depth=arguments[2]),arguments.length>=4&&(i.colors=arguments[3]),c(e)?i.showHidden=e:e&&t._extend(i,e),u(i.showHidden)&&(i.showHidden=!1),u(i.depth)&&(i.depth=2),u(i.colors)&&(i.colors=!1),u(i.customInspect)&&(i.customInspect=!0),i.colors&&(i.stylize=I),a(i,A,i.depth)}function I(A,e){var t=B.styles[e];return t?"["+B.colors[t][0]+"m"+A+"["+B.colors[t][1]+"m":A}function o(A,e){return A}function a(A,e,i){if(A.customInspect&&e&&D(e.inspect)&&e.inspect!==t.inspect&&(!e.constructor||e.constructor.prototype!==e)){var g=e.inspect(i,A);return E(g)||(g=a(A,g,i)),g}var r=function(A,e){if(u(e))return A.stylize("undefined","undefined");if(E(e)){var t="'"+JSON.stringify(e).replace(/^"|"$/g,"").replace(/'/g,"\\'").replace(/\\"/g,'"')+"'";return A.stylize(t,"string")}if(f(e))return A.stylize(""+e,"number");if(c(e))return A.stylize(""+e,"boolean");if(h(e))return A.stylize("null","null")}(A,e);if(r)return r;var n=Object.keys(e),B=function(A){var e={};return A.forEach(function(A,t){e[A]=!0}),e}(n);if(A.showHidden&&(n=Object.getOwnPropertyNames(e)),p(e)&&(n.indexOf("message")>=0||n.indexOf("description")>=0))return Q(e);if(0===n.length){if(D(e)){var I=e.name?": "+e.name:"";return A.stylize("[Function"+I+"]","special")}if(d(e))return A.stylize(RegExp.prototype.toString.call(e),"regexp");if(w(e))return A.stylize(Date.prototype.toString.call(e),"date");if(p(e))return Q(e)}var o,l="",b=!1,y=["{","}"];(s(e)&&(b=!0,y=["[","]"]),D(e))&&(l=" [Function"+(e.name?": "+e.name:"")+"]");return d(e)&&(l=" "+RegExp.prototype.toString.call(e)),w(e)&&(l=" "+Date.prototype.toUTCString.call(e)),p(e)&&(l=" "+Q(e)),0!==n.length||b&&0!=e.length?i<0?d(e)?A.stylize(RegExp.prototype.toString.call(e),"regexp"):A.stylize("[Object]","special"):(A.seen.push(e),o=b?function(A,e,t,i,g){for(var r=[],n=0,B=e.length;n=0&&0,A+e.replace(/\u001b\[\d\d?m/g,"").length+1},0)>60)return t[0]+(""===e?"":e+"\n ")+" "+A.join(",\n ")+" "+t[1];return t[0]+e+" "+A.join(", ")+" "+t[1]}(o,l,y)):y[0]+l+y[1]}function Q(A){return"["+Error.prototype.toString.call(A)+"]"}function C(A,e,t,i,g,r){var n,B,I;if((I=Object.getOwnPropertyDescriptor(e,g)||{value:e[g]}).get?B=I.set?A.stylize("[Getter/Setter]","special"):A.stylize("[Getter]","special"):I.set&&(B=A.stylize("[Setter]","special")),m(i,g)||(n="["+g+"]"),B||(A.seen.indexOf(I.value)<0?(B=h(t)?a(A,I.value,null):a(A,I.value,t-1)).indexOf("\n")>-1&&(B=r?B.split("\n").map(function(A){return" "+A}).join("\n").substr(2):"\n"+B.split("\n").map(function(A){return" "+A}).join("\n")):B=A.stylize("[Circular]","special")),u(n)){if(r&&g.match(/^\d+$/))return B;(n=JSON.stringify(""+g)).match(/^"([a-zA-Z_][a-zA-Z_0-9]*)"$/)?(n=n.substr(1,n.length-2),n=A.stylize(n,"name")):(n=n.replace(/'/g,"\\'").replace(/\\"/g,'"').replace(/(^"|"$)/g,"'"),n=A.stylize(n,"string"))}return n+": "+B}function s(A){return Array.isArray(A)}function c(A){return"boolean"==typeof A}function h(A){return null===A}function f(A){return"number"==typeof A}function E(A){return"string"==typeof A}function u(A){return void 0===A}function d(A){return l(A)&&"[object RegExp]"===b(A)}function l(A){return"object"==typeof A&&null!==A}function w(A){return l(A)&&"[object Date]"===b(A)}function p(A){return l(A)&&("[object Error]"===b(A)||A instanceof Error)}function D(A){return"function"==typeof A}function b(A){return Object.prototype.toString.call(A)}function y(A){return A<10?"0"+A.toString(10):A.toString(10)}t.debuglog=function(A){if(u(r)&&(r=e.env.NODE_DEBUG||""),A=A.toUpperCase(),!n[A])if(new RegExp("\\b"+A+"\\b","i").test(r)){var i=e.pid;n[A]=function(){var e=t.format.apply(t,arguments);console.error("%s %d: %s",A,i,e)}}else n[A]=function(){};return n[A]},t.inspect=B,B.colors={bold:[1,22],italic:[3,23],underline:[4,24],inverse:[7,27],white:[37,39],grey:[90,39],black:[30,39],blue:[34,39],cyan:[36,39],green:[32,39],magenta:[35,39],red:[31,39],yellow:[33,39]},B.styles={special:"cyan",number:"yellow",boolean:"yellow",undefined:"grey",null:"bold",string:"green",date:"magenta",regexp:"red"},t.isArray=s,t.isBoolean=c,t.isNull=h,t.isNullOrUndefined=function(A){return null==A},t.isNumber=f,t.isString=E,t.isSymbol=function(A){return"symbol"==typeof A},t.isUndefined=u,t.isRegExp=d,t.isObject=l,t.isDate=w,t.isError=p,t.isFunction=D,t.isPrimitive=function(A){return null===A||"boolean"==typeof A||"number"==typeof A||"string"==typeof A||"symbol"==typeof A||void 0===A},t.isBuffer=A("./support/isBuffer");var M=["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"];function m(A,e){return Object.prototype.hasOwnProperty.call(A,e)}t.log=function(){var A,e;console.log("%s - %s",(A=new Date,e=[y(A.getHours()),y(A.getMinutes()),y(A.getSeconds())].join(":"),[A.getDate(),M[A.getMonth()],e].join(" ")),t.format.apply(t,arguments))},t.inherits=A("inherits"),t._extend=function(A,e){if(!e||!l(e))return A;for(var t=Object.keys(e),i=t.length;i--;)A[t[i]]=e[t[i]];return A}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"./support/isBuffer":195,_process:154,inherits:194}],197:[function(A,e,t){e.exports=function(A,e){if(!Object.prototype.hasOwnProperty.call(A,e))throw new TypeError("attempted to use private field on non-instance");return A}},{}],198:[function(A,e,t){var i=0;e.exports=function(A){return"__private_"+i+++"_"+A}},{}],199:[function(A,e,t){e.exports=function(A,e,t){return e in A?Object.defineProperty(A,e,{value:t,enumerable:!0,configurable:!0,writable:!0}):A[e]=t,A}},{}],200:[function(A,e,t){e.exports=function(A){return A&&A.__esModule?A:{default:A}}},{}],201:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){const e=35===A.length,t=A.length-(e?2:1),i=(0,g.default)(A.subarray(0,t));return[e?A[A.length-2]===i[0]&&A[A.length-1]===i[1]:A[A.length-1]===i[0],t]};var g=i(A("./sshash"))},{"./sshash":206,"@babel/runtime/helpers/interopRequireDefault":200}],202:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e,t=99){if((0,r.isU8a)(A)||(0,r.isHex)(A))return(0,r.u8aToU8a)(A);const i=(0,r.bufferToU8a)(g.default.decode(A)),I=e=>`Decoding ${A}: ${e}`;(0,r.assert)(B.default.allowedEncodedLengths.includes(i.length),I("Invalid decoded address length"));const[o,a]=(0,n.default)(i);return(0,r.assert)(e||o,I("Invalid decoded address checksum")),i.slice(1,a)};var g=i(A("bs58")),r=A("@polkadot/util"),n=i(A("./checkChecksum")),B=i(A("./defaults"))},{"./checkChecksum":201,"./defaults":203,"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246,bs58:317}],203:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var i={allowedDecodedLengths:[1,2,4,8,32],allowedEncodedLengths:[3,4,6,10,35],allowedPrefix:A("./ss58").allowedSS58,prefix:42};t.default=i},{"./ss58":205}],204:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=B.default.prefix){const t=(0,n.default)(A);(0,r.assert)(B.default.allowedDecodedLengths.includes(t.length),`Expected a valid key to convert, with length ${B.default.allowedDecodedLengths.join(", ")}`);const i=32===t.length,o=(0,r.u8aConcat)(new Uint8Array([e]),t),a=(0,I.default)(o);return g.default.encode((0,r.u8aToBuffer)((0,r.u8aConcat)(o,a.subarray(0,i?2:1))))};var g=i(A("bs58")),r=A("@polkadot/util"),n=i(A("./decode")),B=i(A("./defaults")),I=i(A("./sshash"))},{"./decode":202,"./defaults":203,"./sshash":206,"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246,bs58:317}],205:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.allowedSS58=void 0;t.allowedSS58=[0,1,2,3,16,17,20,42,43,68,69]},{}],206:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,r.default)((0,g.u8aConcat)(n,A),512)};var g=A("@polkadot/util"),r=i(A("../blake2/asU8a"));const n=(0,g.stringToU8a)("SS58PRE")},{"../blake2/asU8a":207,"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246}],207:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=256,t=null,i=!1){const B=Math.ceil(e/8);return(0,n.isReady)()&&!i?(0,n.blake2b)((0,r.u8aToU8a)(A),(0,r.u8aToU8a)(t),B):g.default.blake2b((0,r.u8aToU8a)(A),t,B)};var g=i(A("blakejs")),r=A("@polkadot/util"),n=A("@polkadot/wasm-crypto")},{"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246,"@polkadot/wasm-crypto":301,blakejs:314}],208:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=!0){return A.filter(A=>!(0,r.default)(A)&&(e||!(0,g.default)(A)))};var g=i(A("../is/null")),r=i(A("../is/undefined"))},{"../is/null":259,"../is/undefined":267,"@babel/runtime/helpers/interopRequireDefault":200}],209:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"arrayFilter",{enumerable:!0,get:function(){return g.default}});var g=i(A("./filter"))},{"./filter":208,"@babel/runtime/helpers/interopRequireDefault":200}],210:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e){if(!A)throw new Error((0,g.default)(e)?e():e)};var g=i(A("./is/function"))},{"./is/function":253,"@babel/runtime/helpers/interopRequireDefault":200}],211:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.BN_THOUSAND=t.BN_HUNDRED=t.BN_TEN=t.BN_ONE=t.BN_ZERO=void 0;var g=i(A("bn.js"));const r=new g.default(0);t.BN_ZERO=r;const n=new g.default(1);t.BN_ONE=n;const B=new g.default(10);t.BN_TEN=B;const I=new g.default(100);t.BN_HUNDRED=I;const o=new g.default(1e3);t.BN_THOUSAND=o},{"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],212:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var g=i(A("../hex/toBn")).default;t.default=g},{"../hex/toBn":242,"@babel/runtime/helpers/interopRequireDefault":200}],213:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0});var g={bnFromHex:!0,bnMax:!0,bnMin:!0,bnSqrt:!0,bnToBn:!0,bnToHex:!0,bnToU8a:!0};Object.defineProperty(t,"bnFromHex",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"bnMax",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"bnMin",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"bnSqrt",{enumerable:!0,get:function(){return o.default}}),Object.defineProperty(t,"bnToBn",{enumerable:!0,get:function(){return a.default}}),Object.defineProperty(t,"bnToHex",{enumerable:!0,get:function(){return Q.default}}),Object.defineProperty(t,"bnToU8a",{enumerable:!0,get:function(){return C.default}});var r=A("./consts");Object.keys(r).forEach(function(A){"default"!==A&&"__esModule"!==A&&(Object.prototype.hasOwnProperty.call(g,A)||Object.defineProperty(t,A,{enumerable:!0,get:function(){return r[A]}}))});var n=i(A("./fromHex")),B=i(A("./max")),I=i(A("./min")),o=i(A("./sqrt")),a=i(A("./toBn")),Q=i(A("./toHex")),C=i(A("./toU8a"))},{"./consts":211,"./fromHex":212,"./max":214,"./min":215,"./sqrt":216,"./toBn":217,"./toHex":218,"./toU8a":219,"@babel/runtime/helpers/interopRequireDefault":200}],214:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(...A){return(0,r.default)(A&&A.length>=1,"Must provide one or more BN arguments"),A.reduce((A,e)=>g.default.max(A,e),A[0])};var g=i(A("bn.js")),r=i(A("../assert"))},{"../assert":210,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],215:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(...A){return(0,r.default)(A&&A.length>=1,"Must provide one or more BN arguments"),A.reduce((A,e)=>g.default.min(A,e),A[0])};var g=i(A("bn.js")),r=i(A("../assert"))},{"../assert":210,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],216:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,r.default)(A.gten(0),"square root of negative numbers is not supported"),A.ltn(2)?A:function A(e,t){const i=e.div(t).add(t).shrn(1);return t.eq(i)||t.eq(i.subn(1))?t:A(e,i)}(A,new g.default(1))};var g=i(A("bn.js")),r=i(A("../assert"))},{"../assert":210,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],217:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){if(!A)return new g.default(0);if((0,B.default)(A))return(0,I.default)(A.toString());if((0,r.default)(A))return new g.default(A.toString());return g.default.isBN(A)?A:(0,n.default)(A)?A.toBn():new g.default(A)};var g=i(A("bn.js")),r=i(A("../is/bigInt")),n=i(A("../is/toBn")),B=i(A("../is/hex")),I=i(A("../hex/toBn"))},{"../hex/toBn":242,"../is/bigInt":247,"../is/hex":254,"../is/toBn":265,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],218:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var g=i(A("@babel/runtime/helpers/defineProperty")),r=i(A("../is/number")),n=i(A("./toU8a")),B=A("../u8a");function I(A,e){var t=Object.keys(A);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(A);e&&(i=i.filter(function(e){return Object.getOwnPropertyDescriptor(A,e).enumerable})),t.push.apply(t,i)}return t}const o="0x00";var a=function(A,e={bitLength:-1,isLe:!1,isNegative:!1},t){if(!A)return o;const i=function(A){for(var e=1;e=4,"Previous tests match anyting less than 2^30; qed"),(0,B.u8aConcat)(new Uint8Array([3+(i-4<<2)]),t.subarray(0,i))};var g=i(A("bn.js")),r=i(A("../assert")),n=A("../bn"),B=A("../u8a");const I=new g.default(2).pow(new g.default(6)).subn(1),o=new g.default(2).pow(new g.default(14)).subn(1),a=new g.default(2).pow(new g.default(30)).subn(1)},{"../assert":210,"../bn":213,"../u8a":293,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],228:[function(A,e,t){(function(e){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function({name:A,version:t},i){const n="undefined"!=typeof window?window:e;n.__polkadotjs||(n.__polkadotjs={});if((0,g.default)(A.startsWith("@polkadot"),`Invalid package descriptor ${A}`),n.__polkadotjs[A]=[...n.__polkadotjs[A]||[],{path:i||"",version:t}],1!==n.__polkadotjs[A].length){const e=function(A){const e=A.map(A=>(0,r.default)(A)?{version:A}:A),t=e.reduce((A,{version:e})=>Math.max(A,e.length),0);return e.map(({path:A,version:e})=>`\t${e.padEnd(t)}\t${A=A,!A||A.length<5?"":A}`).join("\n");var i}(n.__polkadotjs[A]);console.warn(`Multiple instances of ${A} detected, ensure that there is only one package in your dependency tree.\n${e}`)}};var g=i(A("./assert")),r=i(A("./is/string"))}).call(this,"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"./assert":210,"./is/string":263,"@babel/runtime/helpers/interopRequireDefault":200}],229:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function A(e){if(!e)return a;if(e<1e3)return n(n({},a),{},{milliseconds:e});const t=e/1e3;if(t<60){const i=Math.floor(t);return o(n(n({},a),{},{seconds:i}),A(e-1e3*i))}const i=t/60;if(i<60){const t=Math.floor(i);return o(n(n({},a),{},{minutes:t}),A(e-60*t*1e3))}const g=i/60;if(g<24){const t=Math.floor(g);return o(n(n({},a),{},{hours:t}),A(e-t*B*1e3))}const r=Math.floor(g/24);return o(n(n({},a),{},{days:r}),A(e-r*I*1e3))};var g=i(A("@babel/runtime/helpers/defineProperty"));function r(A,e){var t=Object.keys(A);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(A);e&&(i=i.filter(function(e){return Object.getOwnPropertyDescriptor(A,e).enumerable})),t.push.apply(t,i)}return t}function n(A){for(var e=1;e(0,I.calcSi)(A,e)),Q.findSi=I.findSi,Q.getDefaults=(()=>({decimals:o,unit:a})),Q.getOptions=((A=o)=>I.SI.filter(({power:e})=>!(e<0)||A+e>=0)),Q.setDefaults=(({decimals:A,unit:e})=>{o=(0,n.default)(A)?o:A,a=(0,n.default)(e)?a:e,I.SI[I.SI_MID].text=a});var C=Q;t.default=C},{"../bn/toBn":217,"../is/boolean":249,"../is/undefined":267,"./formatDecimal":232,"./si":236,"@babel/runtime/helpers/interopRequireDefault":200}],231:[function(A,e,t){"use strict";function i(A){return A.toString().padStart(2,"0")}Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){const e=A.getFullYear().toString(),t=i(A.getMonth()+1),g=i(A.getDate()),r=i(A.getHours()),n=i(A.getMinutes()),B=i(A.getSeconds());return`${e}-${t}-${g} ${r}:${n}:${B}`}},{}],232:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){const e=A[0].startsWith("-"),t=e?A.substr(1).match(i):A.match(i);return t?`${e?"-":""}${t.join(",")}`:A};const i=new RegExp("(\\d+?)(?=(\\d{3})+(?!\\d)|$)","g")},{}],233:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e){const t=A&&A.getTime()||0,i=function A(e){if(e){if((0,r.default)(e))return A(e.toBn());if(e instanceof Date)return A(e.getTime());if(e instanceof g.default)return A(e.toNumber())}return e||0}(e);let n="0.0s";if(t&&i){const A=Math.max(Math.abs(t-i),0)/1e3;n=A<15?`${A.toFixed(1)}s`:A<60?`${0|A}s`:A<3600?`${A/60|0}m`:`${A/3600|0}h`}return n};var g=i(A("bn.js")),r=i(A("../is/toBn"))},{"../is/toBn":265,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],234:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,r.default)((0,g.default)(A).toString())};var g=i(A("../bn/toBn")),r=i(A("./formatDecimal"))},{"../bn/toBn":217,"./formatDecimal":232,"@babel/runtime/helpers/interopRequireDefault":200}],235:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"formatBalance",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"formatDate",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"formatDecimal",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"formatElapsed",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"formatNumber",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"calcSi",{enumerable:!0,get:function(){return o.calcSi}}),Object.defineProperty(t,"findSi",{enumerable:!0,get:function(){return o.findSi}});var g=i(A("./formatBalance")),r=i(A("./formatDate")),n=i(A("./formatDecimal")),B=i(A("./formatElapsed")),I=i(A("./formatNumber")),o=A("./si")},{"./formatBalance":230,"./formatDate":231,"./formatDecimal":232,"./formatElapsed":233,"./formatNumber":234,"./si":236,"@babel/runtime/helpers/interopRequireDefault":200}],236:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.findSi=r,t.calcSi=function(A,e,t){if(t)return r(t);const n=i-1+Math.ceil((A.length-e)/3);return g[n]||g[n<0?0:g.length-1]},t.SI=t.SI_MID=void 0;const i=8;t.SI_MID=i;const g=[{power:-24,text:"yocto",value:"y"},{power:-21,text:"zepto",value:"z"},{power:-18,text:"atto",value:"a"},{power:-15,text:"femto",value:"f"},{power:-12,text:"pico",value:"p"},{power:-9,text:"nano",value:"n"},{power:-6,text:"micro",value:"µ"},{power:-3,text:"milli",value:"m"},{power:0,text:"Unit",value:"-"},{power:3,text:"Kilo",value:"k"},{power:6,text:"Mega",value:"M"},{power:9,text:"Giga",value:"G"},{power:12,text:"Tera",value:"T"},{power:15,text:"Peta",value:"P"},{power:18,text:"Exa",value:"E"},{power:21,text:"Zeta",value:"Z"},{power:24,text:"Yotta",value:"Y"}];function r(A){for(let e=0;en?(0,r.default)(A).slice(-1*i):`${"0".repeat(i)}${(0,r.default)(A)}`.slice(-1*i))};var g=i(A("./addPrefix")),r=i(A("./stripPrefix"))},{"./addPrefix":237,"./stripPrefix":241,"@babel/runtime/helpers/interopRequireDefault":200}],239:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return!(!A||!(0,g.default)(A,-1,!0)||"0x"!==A.substr(0,2))};var g=i(A("../is/hex"))},{"../is/hex":254,"@babel/runtime/helpers/interopRequireDefault":200}],240:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"hexAddPrefix",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"hexFixLength",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"hexHasPrefix",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"hexStripPrefix",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"hexToBn",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"hexToNumber",{enumerable:!0,get:function(){return o.default}}),Object.defineProperty(t,"hexToString",{enumerable:!0,get:function(){return a.default}}),Object.defineProperty(t,"hexToU8a",{enumerable:!0,get:function(){return Q.default}});var g=i(A("./addPrefix")),r=i(A("./fixLength")),n=i(A("./hasPrefix")),B=i(A("./stripPrefix")),I=i(A("./toBn")),o=i(A("./toNumber")),a=i(A("./toString")),Q=i(A("./toU8a"))},{"./addPrefix":237,"./fixLength":238,"./hasPrefix":239,"./stripPrefix":241,"./toBn":242,"./toNumber":243,"./toString":244,"./toU8a":245,"@babel/runtime/helpers/interopRequireDefault":200}],241:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){if(!A)return"";if((0,g.default)(A))return A.substr(2);if(r.test(A))return A;throw new Error(`Invalid hex ${A} passed to hexStripPrefix`)};var g=i(A("./hasPrefix"));const r=/^[a-fA-F0-9]+$/},{"./hasPrefix":239,"@babel/runtime/helpers/interopRequireDefault":200}],242:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e={isLe:!1,isNegative:!1}){if(!A)return new r.default(0);const t=function(A){for(var e=1;eA.startsWith(e))}catch(A){i=!1}return{debug:i?(...A)=>h("debug",t,A):f,error:(...A)=>h("error",t,A),log:(...A)=>h("log",t,A),noop:f,warn:(...A)=>h("warn",t,A)}};var g=i(A("chalk")),r=i(A("./format/formatDate")),n=i(A("./is/bn")),B=i(A("./is/buffer")),I=i(A("./is/function")),o=i(A("./is/object")),a=i(A("./is/u8a")),Q=i(A("./u8a/toHex"));const C={debug:"log",error:"error",log:"log",warn:"warn"},s={debug:g.default.gray,error:g.default.red,log:g.default.reset,warn:g.default.yellow};function c(A){return Array.isArray(A)?A.map(c):(0,n.default)(A)?A.toString():(0,B.default)(A)?`0x${A.toString("hex")}`:(0,a.default)(A)?(0,Q.default)(A):A&&(0,o.default)(A)&&A.constructor===Object?function(A){return Object.keys(A).reduce((e,t)=>(e[t]=c(A[t]),e),{})}(A):A}function h(A,e,t){if(1===t.length&&(0,I.default)(t[0])){const i=t[0]();return h(A,e,Array.isArray(i)?i:[i])}const i=e=>s[A](e);console[C[A]](i((0,r.default)(new Date)),i(e),...t.map(c))}function f(){}}).call(this,A("_process"))},{"./format/formatDate":231,"./is/bn":248,"./is/buffer":250,"./is/function":253,"./is/object":261,"./is/u8a":266,"./u8a/toHex":297,"@babel/runtime/helpers/interopRequireDefault":200,_process:154,chalk:269}],269:[function(A,e,t){"use strict";const i=A("ansi-styles"),{stdout:g,stderr:r}=A("supports-color"),{stringReplaceAll:n,stringEncaseCRLFWithFirstIndex:B}=A("./util"),{isArray:I}=Array,o=["ansi","ansi","ansi256","ansi16m"],a=Object.create(null);class Q{constructor(A){return C(A)}}const C=A=>{const e={};return((A,e={})=>{if(e.level&&!(Number.isInteger(e.level)&&e.level>=0&&e.level<=3))throw new Error("The `level` option should be an integer from 0 to 3");const t=g?g.level:0;A.level=void 0===e.level?t:e.level})(e,A),e.template=((...A)=>l(e.template,...A)),Object.setPrototypeOf(e,s.prototype),Object.setPrototypeOf(e.template,e),e.template.constructor=(()=>{throw new Error("`chalk.constructor()` is deprecated. Use `new chalk.Instance()` instead.")}),e.template.Instance=Q,e.template};function s(A){return C(A)}for(const[A,e]of Object.entries(i))a[A]={get(){const t=E(this,f(e.open,e.close,this._styler),this._isEmpty);return Object.defineProperty(this,A,{value:t}),t}};a.visible={get(){const A=E(this,this._styler,!0);return Object.defineProperty(this,"visible",{value:A}),A}};const c=["rgb","hex","keyword","hsl","hsv","hwb","ansi","ansi256"];for(const A of c)a[A]={get(){const{level:e}=this;return function(...t){const g=f(i.color[o[e]][A](...t),i.color.close,this._styler);return E(this,g,this._isEmpty)}}};for(const A of c){a["bg"+A[0].toUpperCase()+A.slice(1)]={get(){const{level:e}=this;return function(...t){const g=f(i.bgColor[o[e]][A](...t),i.bgColor.close,this._styler);return E(this,g,this._isEmpty)}}}}const h=Object.defineProperties(()=>{},{...a,level:{enumerable:!0,get(){return this._generator.level},set(A){this._generator.level=A}}}),f=(A,e,t)=>{let i,g;return void 0===t?(i=A,g=e):(i=t.openAll+A,g=e+t.closeAll),{open:A,close:e,openAll:i,closeAll:g,parent:t}},E=(A,e,t)=>{const i=(...A)=>I(A[0])&&I(A[0].raw)?u(i,l(i,...A)):u(i,1===A.length?""+A[0]:A.join(" "));return Object.setPrototypeOf(i,h),i._generator=A,i._styler=e,i._isEmpty=t,i},u=(A,e)=>{if(A.level<=0||!e)return A._isEmpty?"":e;let t=A._styler;if(void 0===t)return e;const{openAll:i,closeAll:g}=t;if(-1!==e.indexOf(""))for(;void 0!==t;)e=n(e,t.close,t.open),t=t.parent;const r=e.indexOf("\n");return-1!==r&&(e=B(e,g,i,r)),i+e+g};let d;const l=(e,...t)=>{const[i]=t;if(!I(i)||!I(i.raw))return t.join(" ");const g=t.slice(1),r=[i.raw[0]];for(let A=1;Ae?I(e):t))}else t.push(i)}return t}function a(A,e){const t={};for(const A of e)for(const e of A.styles)t[e[0]]=A.inverse?null:e.slice(1);let i=A;for(const[A,e]of Object.entries(t))if(Array.isArray(e)){if(!(A in i))throw new Error(`Unknown Chalk style: ${A}`);i=e.length>0?i[A](...e):i[A]}return i}e.exports=((A,e)=>{const t=[],r=[];let n=[];if(e.replace(i,(e,i,B,Q,C,s)=>{if(i)n.push(I(i));else if(Q){const e=n.join("");n=[],r.push(0===t.length?e:a(A,t)(e)),t.push({inverse:B,styles:function(A){g.lastIndex=0;const e=[];let t;for(;null!==(t=g.exec(A));){const A=t[1];if(t[2]){const i=o(A,t[2]);e.push([A].concat(i))}else e.push([A])}return e}(Q)})}else if(C){if(0===t.length)throw new Error("Found extraneous } in Chalk template literal");r.push(a(A,t)(n.join(""))),n=[],t.pop()}else n.push(s)}),r.push(n.join("")),t.length>0){const A=`Chalk template literal is missing ${t.length} closing bracket${1===t.length?"":"s"} (\`}\`)`;throw new Error(A)}return r.join("")})},{}],271:[function(A,e,t){"use strict";e.exports={stringReplaceAll:(A,e,t)=>{let i=A.indexOf(e);if(-1===i)return A;const g=e.length;let r=0,n="";do{n+=A.substr(r,i-r)+e+t,r=i+g,i=A.indexOf(e,r)}while(-1!==i);return n+=A.substr(r)},stringEncaseCRLFWithFirstIndex:(A,e,t,i)=>{let g=0,r="";do{const n="\r"===A[i-1];r+=A.substr(g,(n?i-1:i)-g)+e+(n?"\r\n":"\n")+t,g=i+1,i=A.indexOf("\n",g)}while(-1!==i);return r+=A.substr(g)}}},{}],272:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"numberToHex",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"numberToU8a",{enumerable:!0,get:function(){return r.default}});var g=i(A("./toHex")),r=i(A("./toU8a"))},{"./toHex":273,"./toU8a":274,"@babel/runtime/helpers/interopRequireDefault":200}],273:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=-1){if((0,n.default)(A)||(0,r.default)(A)||isNaN(A))return"0x";return(0,g.default)(A.toString(16),e,!0)};var g=i(A("../hex/fixLength")),r=i(A("../is/null")),n=i(A("../is/undefined"))},{"../hex/fixLength":238,"../is/null":259,"../is/undefined":267,"@babel/runtime/helpers/interopRequireDefault":200}],274:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=-1){if(!A||isNaN(A))return new Uint8Array;return(0,g.default)((0,r.default)(A,e))};var g=i(A("../hex/toU8a")),r=i(A("./toHex"))},{"../hex/toU8a":245,"./toHex":273,"@babel/runtime/helpers/interopRequireDefault":200}],275:[function(A,e,t){"use strict";Array.prototype.fill||(Array.prototype.fill=function(A,e=0,t){if(!this)throw new TypeError("this is null or not defined");const i=Object(this),g=i.length>>>0,r=e>>0;let n=r<0?Math.max(g+r,0):Math.min(r,g);const B=void 0===t?g:t>>0,I=B<0?Math.max(g+B,0):Math.min(B,g);for(;n{e.apply(A,t.concat((A,e)=>{A?g(A):i(e)}))})}},{}],283:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var g=i(A("camelcase")).default;t.default=g},{"@babel/runtime/helpers/interopRequireDefault":200,camelcase:318}],284:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"stringCamelCase",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"stringLowerFirst",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"stringShorten",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"stringToHex",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"stringToU8a",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"stringUpperFirst",{enumerable:!0,get:function(){return o.default}});var g=i(A("./camelCase")),r=i(A("./lowerFirst")),n=i(A("./shorten")),B=i(A("./toHex")),I=i(A("./toU8a")),o=i(A("./upperFirst"))},{"./camelCase":283,"./lowerFirst":285,"./shorten":286,"./toHex":287,"./toU8a":288,"./upperFirst":289,"@babel/runtime/helpers/interopRequireDefault":200}],285:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return A?A.charAt(0).toLowerCase()+A.slice(1):""}},{}],286:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=6){if(A.length<=2+2*e)return A;return`${A.substr(0,e)}…${A.slice(-e)}`}},{}],287:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,g.default)((0,r.default)(A))};var g=i(A("../u8a/toHex")),r=i(A("./toU8a"))},{"../u8a/toHex":297,"./toU8a":288,"@babel/runtime/helpers/interopRequireDefault":200}],288:[function(A,e,t){"use strict";let i;Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return A?i.encode(A):new Uint8Array};try{i=new TextEncoder}catch(A){i={encode:function(A){const e=new Uint8Array(A.length);for(let t=0;ti)return A.subarray(0,i);const g=new Uint8Array(i);t?g.set(A,0):g.set(A,i-A.length);return g}},{}],293:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"u8aConcat",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"u8aEq",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"u8aFixLength",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"u8aSorted",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"u8aToBn",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"u8aToBuffer",{enumerable:!0,get:function(){return o.default}}),Object.defineProperty(t,"u8aToHex",{enumerable:!0,get:function(){return a.default}}),Object.defineProperty(t,"u8aToString",{enumerable:!0,get:function(){return Q.default}}),Object.defineProperty(t,"u8aToU8a",{enumerable:!0,get:function(){return C.default}});var g=i(A("./concat")),r=i(A("./eq")),n=i(A("./fixLength")),B=i(A("./sorted")),I=i(A("./toBn")),o=i(A("./toBuffer")),a=i(A("./toHex")),Q=i(A("./toString")),C=i(A("./toU8a"))},{"./concat":290,"./eq":291,"./fixLength":292,"./sorted":294,"./toBn":295,"./toBuffer":296,"./toHex":297,"./toString":298,"./toU8a":299,"@babel/runtime/helpers/interopRequireDefault":200}],294:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return A.sort((A,e)=>{let t=0;for(;;){if((0,g.default)(A[t])&&(0,g.default)(e[t]))return 0;if((0,g.default)(A[t]))return-1;if((0,g.default)(e[t]))return 1;const i=A[t]-e[t];if(0!==i)return i;t++}})};var g=i(A("../is/undefined"))},{"../is/undefined":267,"@babel/runtime/helpers/interopRequireDefault":200}],295:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e={isLe:!0,isNegative:!1}){return(0,g.default)((0,r.default)(A),e)};var g=i(A("../hex/toBn")),r=i(A("./toHex"))},{"../hex/toBn":242,"./toHex":297,"@babel/runtime/helpers/interopRequireDefault":200}],296:[function(A,e,t){(function(A){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(e){return e?A.from(e):A.from([])}}).call(this,A("buffer").Buffer)},{buffer:64}],297:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function A(e,t=-1,g=!0){const r=g?"0x":"";if(!(null===e||void 0===e?void 0:e.length))return r;const n=Math.ceil(t/8);if(n>0&&e.length>n){const t=Math.ceil(n/2);return`${A(e.subarray(0,t),-1,g)}…${A(e.subarray(e.length-t),-1,!1)}`}const B=new Array(e.length);for(let A=0;AA+String.fromCharCode(e),"")}}}},{}],299:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){if(!A)return new Uint8Array;if((0,g.default)(A))return(0,B.default)(A);if((0,n.default)(A))return(0,r.default)(A)?(0,I.default)(A):(0,o.default)(A);return Array.isArray(A)?Uint8Array.from(A):A};var g=i(A("../is/buffer")),r=i(A("../is/hex")),n=i(A("../is/string")),B=i(A("../buffer/toU8a")),I=i(A("../hex/toU8a")),o=i(A("../string/toU8a"))},{"../buffer/toU8a":221,"../hex/toU8a":245,"../is/buffer":250,"../is/hex":254,"../is/string":263,"../string/toU8a":288,"@babel/runtime/helpers/interopRequireDefault":200}],300:[function(A,e,t){const{assert:i}=A("@polkadot/util");e.exports=function(A){const e=e=>(...t)=>(i(A.isReady(),"@polkadot/wasm-crypto has not been initialized"),e(...t));return{bip39Generate:e(A.ext_bip39_generate),bip39ToEntropy:e(A.ext_bip39_to_entropy),bip39ToMiniSecret:e(A.ext_bip39_to_mini_secret),bip39ToSeed:e(A.ext_bip39_to_seed),bip39Validate:e(A.ext_bip39_validate),ed25519KeypairFromSeed:e(A.ext_ed_from_seed),ed25519Sign:e(A.ext_ed_sign),ed25519Verify:e(A.ext_ed_verify),sr25519DeriveKeypairHard:e(A.ext_sr_derive_keypair_hard),sr25519DeriveKeypairSoft:e(A.ext_sr_derive_keypair_soft),sr25519DerivePublicSoft:e(A.ext_sr_derive_public_soft),sr25519KeypairFromSeed:e(A.ext_sr_from_seed),sr25519Sign:e(A.ext_sr_sign),sr25519Verify:e(A.ext_sr_verify),blake2b:e(A.ext_blake2b),keccak256:e(A.ext_keccak256),pbkdf2:e(A.ext_pbkdf2),sha512:e(A.ext_sha512),twox:e(A.ext_twox),isReady:A.isReady,waitReady:A.waitReady}}},{"@polkadot/util":246}],301:[function(A,e,t){const i=A("./wasm");e.exports=A("./exports")(i)},{"./exports":300,"./wasm":303}],302:[function(A,e,t){e.exports={name:"@polkadot/wasm-crypto",version:"1.2.1",author:"Jaco Greeff ",files:["crypto-polyfill.js","exports.js","index.d.ts","index.js","wasm.d.ts","wasm.js","wasm_asm.js","wasm_asm_stub.js","wasm_promise.js","wasm_wasm.js"],"react-native":{"./wasm_asm_stub.js":"./wasm_asm.js"},main:"index.js",types:"index.d.ts",devDependencies:{"@polkadot/dev":"^0.50.8"},peerDependencies:{"@polkadot/util":"*"}}},{}],303:[function(A,e,t){let i;const g={crypto:A("crypto")};let r=null;function n(){return null!==r&&r.buffer===i.memory.buffer||(r=new Uint8Array(i.memory.buffer)),r}let B=0;function I(A){const e=i.__wbindgen_malloc(1*A.length);return n().set(A,e/1),B=A.length,e}function o(A,e){return n().subarray(A/1,A/1+e)}let a=null;function Q(){return null===a&&(a=i.__wbindgen_global_argument_ptr()),a}let C=null;function s(){return null!==C&&C.buffer===i.memory.buffer||(C=new Uint32Array(i.memory.buffer)),C}e.exports.ext_sr_derive_keypair_hard=function(A,e){const t=I(A),g=B,r=I(e),n=B,a=Q();try{i.ext_sr_derive_keypair_hard(a,t,g,r,n);const A=s(),e=A[a/4],B=A[a/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_sr_derive_keypair_soft=function(A,e){const t=I(A),g=B,r=I(e),n=B,a=Q();try{i.ext_sr_derive_keypair_soft(a,t,g,r,n);const A=s(),e=A[a/4],B=A[a/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_sr_derive_public_soft=function(A,e){const t=I(A),g=B,r=I(e),n=B,a=Q();try{i.ext_sr_derive_public_soft(a,t,g,r,n);const A=s(),e=A[a/4],B=A[a/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_sr_from_seed=function(A){const e=I(A),t=B,g=Q();try{i.ext_sr_from_seed(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_sr_sign=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=I(t),c=B,h=Q();try{i.ext_sr_sign(h,g,r,n,a,C,c);const A=s(),e=A[h/4],t=A[h/4+1],B=o(e,t).slice();return i.__wbindgen_free(e,1*t),B}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a),i.__wbindgen_free(C,1*c)}},e.exports.ext_sr_verify=function(A,e,t){const g=I(A),r=B,n=I(e),o=B,a=I(t),Q=B;try{return 0!==i.ext_sr_verify(g,r,n,o,a,Q)}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*o),i.__wbindgen_free(a,1*Q)}},e.exports.ext_blake2b=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=Q();try{i.ext_blake2b(C,g,r,n,a,t);const A=s(),e=A[C/4],B=A[C/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a)}},e.exports.ext_keccak256=function(A){const e=I(A),t=B,g=Q();try{i.ext_keccak256(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_pbkdf2=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=Q();try{i.ext_pbkdf2(C,g,r,n,a,t);const A=s(),e=A[C/4],B=A[C/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a)}},e.exports.ext_sha512=function(A){const e=I(A),t=B,g=Q();try{i.ext_sha512(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_twox=function(A,e){const t=I(A),g=B,r=Q();try{i.ext_twox(r,t,g,e);const A=s(),n=A[r/4],B=A[r/4+1],I=o(n,B).slice();return i.__wbindgen_free(n,1*B),I}finally{i.__wbindgen_free(t,1*g)}};const{u8aToString:c}=A("@polkadot/util");function h(A,e){return c(n().subarray(A,A+e))}e.exports.ext_bip39_generate=function(A){const e=Q();i.ext_bip39_generate(e,A);const t=s(),g=t[e/4],r=t[e/4+1],n=h(g,r).slice();return i.__wbindgen_free(g,1*r),n};const{stringToU8a:f}=A("@polkadot/util");let E;E="function"==typeof stringToU8aInto?function(A){let e=A.length,t=i.__wbindgen_malloc(e),g=0;for(;;){const r=n().subarray(t+g,t+e),{read:B,written:I}=stringToU8aInto(A,r);if(g+=I,0===(A=A.substring(B)).length)break;t=i.__wbindgen_realloc(t,e,2*e),e*=2}return B=g,t}:function(A){const e=f(A),t=i.__wbindgen_malloc(e.length);return n().set(e,t),B=e.length,t},e.exports.ext_bip39_to_entropy=function(A){const e=E(A),t=B,g=Q();try{i.ext_bip39_to_entropy(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_bip39_to_mini_secret=function(A,e){const t=E(A),g=B,r=E(e),n=B,I=Q();try{i.ext_bip39_to_mini_secret(I,t,g,r,n);const A=s(),e=A[I/4],B=A[I/4+1],a=o(e,B).slice();return i.__wbindgen_free(e,1*B),a}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_bip39_to_seed=function(A,e){const t=E(A),g=B,r=E(e),n=B,I=Q();try{i.ext_bip39_to_seed(I,t,g,r,n);const A=s(),e=A[I/4],B=A[I/4+1],a=o(e,B).slice();return i.__wbindgen_free(e,1*B),a}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_bip39_validate=function(A){const e=E(A),t=B;try{return 0!==i.ext_bip39_validate(e,t)}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_ed_from_seed=function(A){const e=I(A),t=B,g=Q();try{i.ext_ed_from_seed(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_ed_sign=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=I(t),c=B,h=Q();try{i.ext_ed_sign(h,g,r,n,a,C,c);const A=s(),e=A[h/4],t=A[h/4+1],B=o(e,t).slice();return i.__wbindgen_free(e,1*t),B}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a),i.__wbindgen_free(C,1*c)}},e.exports.ext_ed_verify=function(A,e,t){const g=I(A),r=B,n=I(e),o=B,a=I(t),Q=B;try{return 0!==i.ext_ed_verify(g,r,n,o,a,Q)}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*o),i.__wbindgen_free(a,1*Q)}};const u=new Array(32);u.fill(void 0),u.push(void 0,null,!0,!1);let d=u.length;function l(A){d===u.length&&u.push(u.length+1);const e=d;return d=u[e],u[e]=A,e}function w(A){return u[A]}e.exports.__wbg_new_3a746f2619705add=function(A,e){let t=h(A,e);return l(new Function(t))},e.exports.__wbg_call_f54d3a6dadb199ca=function(A,e){return l(w(A).call(w(e)))},e.exports.__wbg_self_ac379e780a0d8b94=function(A){return l(w(A).self)},e.exports.__wbg_crypto_1e4302b85d4f64a2=function(A){return l(w(A).crypto)},e.exports.__wbg_getRandomValues_1b4ba144162a5c9e=function(A){return l(w(A).getRandomValues)},e.exports.__wbg_getRandomValues_1ef11e888e5228e9=function(A,e,t){let i=o(e,t);w(A).getRandomValues(i)},e.exports.__wbg_require_6461b1e9a0d7c34a=function(A,e){let t=h(A,e);return l(g[t])},e.exports.__wbg_randomFillSync_1b52c8482374c55b=function(A,e,t){let i=o(e,t);w(A).randomFillSync(i)},e.exports.__wbindgen_is_undefined=function(A){return void 0===w(A)?1:0},e.exports.__wbindgen_jsval_eq=function(A,e){return w(A)===w(e)?1:0},e.exports.__wbindgen_object_drop_ref=function(A){var e;(e=A)<36||(u[e]=d,d=e)},e.exports.abort=function(){throw new Error("abort")};const p=A("./wasm_promise")().catch(()=>null);e.exports.isReady=function(){return!!i},e.exports.waitReady=function(){return p.then(()=>!!i)},p.then(A=>{i=A})},{"./wasm_promise":305,"@polkadot/util":246,crypto:73}],304:[function(A,e,t){e.exports={}},{}],305:[function(A,e,t){const i=A("./package.json"),g=A("./wasm_asm_stub"),r=A("./wasm_wasm"),n=A("./wasm");e.exports=async function(){try{const{instance:A}=await WebAssembly.instantiate(r,{"./wasm":n});return A.exports}catch(A){return g&&g.ext_blake2b?g:(console.error(`ERROR: Unable to initialize ${i.name} ${i.version}`),console.error(A),null)}}},{"./package.json":302,"./wasm":303,"./wasm_asm_stub":304,"./wasm_wasm":306}],306:[function(A,e,t){(function(A){e.exports=A.from("AGFzbQEAAAABywEdYAJ/fwBgA39/fwBgAn9/AX9gAX8AYAN/f38Bf2AEf39/fwBgAX8Bf2AFf39/f38AYAABf2AHf39/f39/fwBgAX8BfmAGf39/f39/AGAEf39/fwF/YAAAYAZ/f39/f38Bf2AFf39/f38Bf2ACf34AYAJ/fwF+YAF+AX5gCH9/f39/f39/AGADf39+AGAFf35/fn8AYAN/fn4AYAh/fn5+fn5+fgBgCn9+fn5+fn5+fn4AYAJ/fgF/YAN/fn8Bf2ACfn8Bf2ACfn4BfgKvAwsGLi93YXNtGl9fd2JpbmRnZW5fb2JqZWN0X2Ryb3BfcmVmAAMGLi93YXNtF19fd2JpbmRnZW5faXNfdW5kZWZpbmVkAAYGLi93YXNtE19fd2JpbmRnZW5fanN2YWxfZXEAAgYuL3dhc20aX193YmdfbmV3XzNhNzQ2ZjI2MTk3MDVhZGQAAgYuL3dhc20bX193YmdfY2FsbF9mNTRkM2E2ZGFkYjE5OWNhAAIGLi93YXNtG19fd2JnX3NlbGZfYWMzNzllNzgwYTBkOGI5NAAGBi4vd2FzbR1fX3diZ19jcnlwdG9fMWU0MzAyYjg1ZDRmNjRhMgAGBi4vd2FzbSZfX3diZ19nZXRSYW5kb21WYWx1ZXNfMWI0YmExNDQxNjJhNWM5ZQAGBi4vd2FzbR5fX3diZ19yZXF1aXJlXzY0NjFiMWU5YTBkN2MzNGEAAgYuL3dhc20mX193YmdfZ2V0UmFuZG9tVmFsdWVzXzFlZjExZTg4OGU1MjI4ZTkAAQYuL3dhc20lX193YmdfcmFuZG9tRmlsbFN5bmNfMWI1MmM4NDgyMzc0YzU1YgABA/UF8wUQAAEBAAAAAQEAAAEBAgEHCwAOAQcHAAMOAQABAwQFAQEOAAQBBwMGBAAPAwkFBQUFAAEDAAsCAAABDQQAAAMJBAkAAAICCg8FCQMDAQMBAQABAQEHAAEAAAIFAAEBAQcGAAMABQAAAgEIBQEbAgEFAAAFAQAGAwIBAQAAAAIABRoBAQEABgABAQMCAAMCAQEIBQIFAwEBAQABAAAFAAABAAEFBQUFBQUFAAMBAAcAAwQHBQIEBQAABAgAAgAAAQIHAAAEAAUBAAABBAITAAMDAAMCAQEREQUHBwYDAQEFAQMDBQEAAgIJAwECAgYBAQMBAQIFAwYFAwAAGQAHAQAAAwUCAAEABwEAAAIABQIHAAADAxYDAwIDAgEFAwMHFAAAAwEQBQgGAQMDAAAHCQkAABgAAAsLAQEDBgMDAQEHBwcHBwAAAgADBQAABgYDAwUBAQEBAQEPAAEBAAACAgABAQAAAAwCAAABAQICAgcAAwwCAAcAAAAAAAABDQACAQAVAgABAAgDAgECBgAAAwAAAAEAAQABAAADAAIBAAMFBQEDAwEAAAMDBgQLAAUMAAsAAQAAAAEAAQQABgECAwMDBwYBAQsDDQcHBwEAAggAAQAABAIDAwAAAAAABQUDAwADAQAACAACBAwBAQECAQABAAEAAwMDBQYHAwEGAAEGAAAFBQMIBQICAAUGFwMDAwIIBQUFAAEAAQwBCgIBAAAAAAEBAAEAAAAAAQMAAAABAQIBAAYFAAQGAAEABQYICAADAAAAAAMAAwAAAAYCAAYCAQQDAAAAAAICBQICAAMAAAAGAgIDAQMGAwMDAwAAAAAAAQADEhIDABwDCAICBAIJAQMDAwICAgMCDAUGAwMAAwAODgUCBgIDAwIDAQAAAAABAgIBAgICAAYGBgEDAwAAAAEGAAwDAg0CBAIAAgABAgICAQICAAEGAwMCAgACAgICAgACBAIGAAAACAgIAwIDDQMDAw0CBgIGCgoICgoKCgIDAAQHAXABwgHCAQUDAQATBgkBfwFBgIDAAAsH6AMYBm1lbW9yeQIAHl9fd2JpbmRnZW5fZ2xvYmFsX2FyZ3VtZW50X3B0cgD2BRpleHRfc3JfZGVyaXZlX2tleXBhaXJfaGFyZADJAhpleHRfc3JfZGVyaXZlX2tleXBhaXJfc29mdADKAhlleHRfc3JfZGVyaXZlX3B1YmxpY19zb2Z0AMsCEGV4dF9zcl9mcm9tX3NlZWQA3AILZXh0X3NyX3NpZ24AuAINZXh0X3NyX3ZlcmlmeQCcBQtleHRfYmxha2UyYgC/Ag1leHRfa2VjY2FrMjU2AN0CCmV4dF9wYmtkZjIAwAIKZXh0X3NoYTUxMgDeAghleHRfdHdveADTAhJleHRfYmlwMzlfZ2VuZXJhdGUA7AIUZXh0X2JpcDM5X3RvX2VudHJvcHkA3wIYZXh0X2JpcDM5X3RvX21pbmlfc2VjcmV0AMwCEWV4dF9iaXAzOV90b19zZWVkAM0CEmV4dF9iaXAzOV92YWxpZGF0ZQDgBRBleHRfZWRfZnJvbV9zZWVkAOACC2V4dF9lZF9zaWduALkCDWV4dF9lZF92ZXJpZnkAnQURX193YmluZGdlbl9tYWxsb2MAggQSX193YmluZGdlbl9yZWFsbG9jANwED19fd2JpbmRnZW5fZnJlZQCZBQmDAwEAQQELwQH8BXj8BeED/AXiA60F+gHWAfwF4wP8BdcD/AXkA/wFpQLyBfMF/AX8BYEC8AXxBfwFxwX8BcUF/AXKBfwFkgTnApEElQKSBJIE/AWWA/cE/AX0BZIE/AXKBfwFkgT8BcsF/AWoBeMF8QX1BWS+AfwFlgHOBPwFkwLNBLEDNs4FzwX8BfwFkgT8BZcD+gT8BfQFwwX8BfIE8gT8BdMF0wX8BasFqwXsBeUFmAHtBeYF7gXVBe4F1QXcAecF/AWaBJIE/AWaA/sE/AX0Ba0FkAX8BdYF/AX8BdgF/AWPBdAD4wX3BfEF0AXXBaEC2QWRBe4F2gWSBPwFmwP9BPwF9AX8BdEC1ATSBNsFhQXpBaYE6AX6Ar8BwwPfBfwF/AXGAZIE/QX8BcMBQfUCkQT4BYcF9gSUA4YF3wPcBfUE4wX6BfEFmwWvBbAF3QSFAagB+QWkA4IF9AXwAvwFwwHBBfYCiQWxBaMCUPsFoQX8BfgFRpUB/ALEBd4F9wKYAgr46grzBZouAgZ/Kn4gAEGQAWoiAiAAKQM4IiMgACkDMCIkIABBuAFqIgMpAwAiKyAAQZgBaiIEKQMAIi98fCIffCAfQvnC+JuRo7Pw2wCFQiCJIh9C8e30+KWn/aelf3wiJSArhUIoiSIcfCImIB+FQjCJIg0gJXwiGyAchUIBiSIdIAApA2AiHyAAKQMoIiUgACkDICIcIABBsAFqIgUpAwAiLCACKQMAIip8fCIofCABICiFQuv6htq/tfbBH4VCIIkiJ0Kr8NP0r+68tzx8IiAgLIVCKIkiHnwiCnx8IiEgACkDaCIBfCAdICEgACkDGCIoIAApAxAiKSAAQagBaiICKQMAIi0gAEGIAWoiBikDACIwfHwiInwgIkKf2PnZwpHagpt/hUIgiSIiQrvOqqbY0Ouzu398Ig4gLYVCKIkiCHwiDyAihUIwiSIJhUIgiSITIAApAwgiISAAKQMAIiIgAEGgAWoiBykDACIuIAApA4ABIjF8fCIMfCAAKQPAASAMhULRhZrv+s+Uh9EAhUIgiSIMQoiS853/zPmE6gB8IgsgLoVCKIkiEXwiFCAMhUIwiSIMIAt8Igt8IhWFQiiJIhB8IhIgACkDSCIdfCAeIAogJ4VCMIkiCiAgfCIWhUIBiSIeIAApA1AiJyAPfHwiDyAAKQNYIiB8IB4gGyAMIA+FQiCJIg98IhuFQiiJIh58IgwgD4VCMIkiDyAbfCIXIB6FQgGJIhh8IhkgACkDeCIbfCAYIBkgGyALIBGFQgGJIgsgJiAAKQNwIh58fCImfCAKICaFQiCJIiYgCSAOfCIKfCIOIAuFQiiJIgl8IgsgJoVCMIkiEYVCIIkiGSAIIAqFQgGJIgogACkDQCImIBR8fCIIIB18IAogCCANhUIgiSINIBZ8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIWhUIoiSIYfCIaICB8IBIgE4VCMIkiEyAVfCIVIBCFQgGJIhAgASALfHwiCyAkfCALIA2FQiCJIg0gF3wiCyAQhUIoiSIQfCISIA2FQjCJIg0gC3wiCyAQhUIBiSIQfCIXICN8IBAgFyAIIAqFQgGJIgogDCAcfHwiCCAmfCAKIAggE4VCIIkiCCAOIBF8Ig58IhOFQiiJIgp8IgwgCIVCMIkiCIVCIIkiESAJIA6FQgGJIg4gFCAefHwiCSAnfCAOIAkgD4VCIIkiDyAVfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiFYVCKIkiEHwiFyAlfCAYIBYgGSAahUIwiSIZfCIWhUIBiSIYIAwgInx8IgwgKXwgDCAPhUIgiSIPIAt8IgwgGIVCKIkiC3wiGCAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiApfCALIBogCSAOhUIBiSIOIBIgJXx8IgkgKHwgDiAJIBmFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhkgCCAKhUIBiSIKIBQgIXx8IgggH3wgCiAIIA2FQiCJIg0gFnwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhaFQiiJIgt8IhogI3wgECARIBeFQjCJIhEgFXwiFYVCAYkiECASIBt8fCISIAF8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhcgIXwgECAXIAggCoVCAYkiCiAYIB98fCIIICJ8IAogCCARhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIXIAkgDoVCAYkiDiAUICB8fCIJICZ8IA4gCSAPhUIgiSIPIBV8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIVhUIoiSIQfCIYIAF8IAsgFiAZIBqFQjCJIhZ8IhmFQgGJIgsgESAofHwiESAkfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaIB98IAsgGiAJIA6FQgGJIg4gEiAdfHwiCSAcfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAnfHwiCCAefCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAcfCAQIBUgFyAYhUIwiSIVfCIXhUIBiSIQIBIgIHx8IhIgHnwgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCAifCAQIBggCCAKhUIBiSIKIBEgKHx8IgggIXwgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgI3x8IgkgHXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggKXwgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARICV8fCIRICd8IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogHHwgCyAaIAkgDoVCAYkiDiASIBt8fCIJICZ8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUICl8fCIIICR8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaICR8IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAnfHwiEiAbfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYICZ8IBAgGCAIIAqFQgGJIgogESAlfHwiCCAjfCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gFCAdfHwiCSAifCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAifCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgIHx8IhEgH3wgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAgfCALIBogCSAOhUIBiSIOIBIgKHx8IgkgAXwgDiAJIBaFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhYgCCAKhUIBiSIKIBQgHnx8IgggIXwgCiAIIA2FQiCJIg0gGXwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhmFQiiJIgt8IhogG3wgECAVIBiFQjCJIhUgF3wiF4VCAYkiECASICZ8fCISICh8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhggHnwgECAYIAggCoVCAYkiCiARICR8fCIIICd8IAogCCAVhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIVIAkgDoVCAYkiDiAUICl8fCIJIB98IA4gCSAPhUIgiSIPIBd8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIXhUIoiSIQfCIYIB58IAsgFiAahUIwiSIWIBl8IhmFQgGJIgsgESAjfHwiESAlfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaIAF8IAsgGiAJIA6FQgGJIg4gEiAhfHwiCSAdfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAcfHwiCCABfCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAdfCAQIBUgGIVCMIkiFSAXfCIXhUIBiSIQIBIgHHx8IhIgJ3wgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCApfCAQIBggCCAKhUIBiSIKIBEgIXx8IgggG3wgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgH3x8IgkgJXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggH3wgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARICR8fCIRICh8IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogIXwgCyAaIAkgDoVCAYkiDiASICZ8fCIJICB8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUICJ8fCIIICN8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaICZ8IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAofHwiEiAdfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYICR8IBAgGCAIIAqFQgGJIgogESAjfHwiCCAefCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gASAUfHwiCSAgfCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAgfCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgG3x8IhEgHHwgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAofCALIBogCSAOhUIBiSIOIBIgKXx8IgkgJ3wgDiAJIBaFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhYgCCAKhUIBiSIKIBQgJXx8IgggInwgCiAIIA2FQiCJIg0gGXwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhmFQiiJIgt8IhogIXwgECAVIBiFQjCJIhUgF3wiF4VCAYkiECASICJ8fCISICZ8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhggHHwgECAYIAggCoVCAYkiCiARIB58fCIIIB18IAogCCAVhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIVIAkgDoVCAYkiDiAUICR8fCIJIBt8IA4gCSAPhUIgiSIPIBd8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIXhUIoiSIQfCIYICN8IAsgFiAahUIwiSIWIBl8IhmFQgGJIgsgASARfHwiESAjfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaICR8IAsgGiAJIA6FQgGJIg4gEiAnfHwiCSAlfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAffHwiCCApfCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAofCAQIBUgGIVCMIkiFSAXfCIXhUIBiSIQIBIgIXx8IhIgJXwgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCAffCAQIBggCCAKhUIBiSIKIBEgJnx8IgggHHwgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgJ3x8IgkgKXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggHHwgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARIB18fCIRIB58IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogJXwgCyAaIAkgDoVCAYkiDiABIBJ8fCIJICJ8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUIBt8fCIIICB8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaIB98IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAkfHwiEiAjfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYIAF8IBAgGCAIIAqFQgGJIgogESApfHwiCCAofCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gFCAifHwiCSAhfCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAdfCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgJ3x8IhEgIHwgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAbfCALIBogGyAJIA6FQgGJIg4gEiAefHwiCXwgDiAJIBaFQiCJIhsgCCATfCIIfCIJhUIoiSIOfCITIBuFQjCJIhuFQiCJIhIgHSAIIAqFQgGJIgogFCAmfHwiCHwgCiAIIA2FQiCJIh0gGXwiDYVCKIkiCnwiCCAdhUIwiSIdIA18Ig18IhSFQiiJIgt8IhYgIHwgJCAQIBUgGIVCMIkiICAXfCIVhUIBiSIQIAEgE3x8IgF8IAEgHYVCIIkiASAMfCIkIBCFQiiJIh18IhMgAYVCMIkiASAkfCIkIB2FQgGJIh18IgwgI3wgHSAMIAogDYVCAYkiIyARIBx8fCIcICZ8ICMgHCAghUIgiSIcIAkgG3wiIHwiG4VCKIkiI3wiJiAchUIwiSIchUIgiSINICcgDiAghUIBiSIgIAggHnx8Ih58ICAgDyAehUIgiSInIBV8Ih6FQiiJIiB8IgogJ4VCMIkiJyAefCIefCIOhUIoiSIdfCIIICqFIB8gIyAbIBx8IhyFQgGJIiMgCiAhfHwiIXwgIyABICGFQiCJIgEgEiAWhUIwiSIfIBR8IiF8IhuFQiiJIiN8IiogAYVCMIkiASAbfCIbhTcDACAEICkgCyAhhUIBiSIhICIgJnx8IiJ8ICEgJCAiICeFQiCJIil8IiSFQiiJIiF8IiIgKYVCMIkiKSAkfCIkIC8gKCAeICCFQgGJIicgEyAlfHwiJXwgHCAfICWFQiCJIh98IiUgJ4VCKIkiHHwiKIWFNwMAIAYgJSAfICiFQjCJIh98IiUgIiAwhYU3AwAgACAIIA2FQjCJIiggDnwiIiAqIDGFhTcDgAEgAiAoIC2FIBsgI4VCAYmFNwMAIAMgASArhSAdICKFQgGJhTcDACAFIB8gLIUgISAkhUIBiYU3AwAgByApIC6FIBwgJYVCAYmFNwMAC6g+Ah5/AX4jAEGQAWsiBSQAIAUgAUHAABDyAyEBQQAhBQNAIAVBwABHBEAgASAFaiIGIAYoAgAiBkEYdCAGQQh0QYCA/AdxciAGQQh2QYD+A3EgBkEYdnJyNgIAIAVBBGohBQwBCwsgACgCACEFIAAoAgQhBiAAKAIQIQsgACgCFCEMIAApAgghICABKAIMIRIgASgCCCETIAEoAgQhFCABKAIAIQ0gASAAKQIYNwNoIAEgIDcDYCABIAw2AnwgASALNgJ4IAEgBjYCdCABIAU2AnAgASANQZjfqJQEaiIPNgKMASABIBRBkYndiQdqIhA2AogBIAEgE0HP94Oue2oiETYChAEgASASQaW3181+aiIYNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIRUgASgCVCEWIAEoAlghFyABKAJcIRkgASAMNgJsIAEgCzYCaCABIAY2AmQgASAFNgJgIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIBE2AowBIAEgGDYCiAEgASAPNgKEASABIBA2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhBSABKAJUIQYgASgCWCELIAEoAlwhDCABKAIcIQ8gASgCGCEQIAEoAhQhESABKAIQIRggASAZNgJsIAEgFzYCaCABIBY2AmQgASAVNgJgIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIBhB24TbygNqIhU2AowBIAEgEUHxo8TPBWoiFjYCiAEgASAQQaSF/pF5aiIXNgKEASABIA9B1b3x2HpqIhk2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhGiABKAJUIQIgASgCWCEDIAEoAlwhBCABIAw2AmwgASALNgJoIAEgBjYCZCABIAU2AmAgASAENgJ8IAEgAzYCeCABIAI2AnQgASAaNgJwIAEgFzYCjAEgASAZNgKIASABIBU2AoQBIAEgFjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEFIAEoAlQhBiABKAJYIQsgASgCXCEMIAEoAiwhFSABKAIoIRYgASgCJCEXIAEoAiAhGSABIAQ2AmwgASADNgJoIAEgAjYCZCABIBo2AmAgASAMNgJ8IAEgCzYCeCABIAY2AnQgASAFNgJwIAEgGUGY1Z7AfWoiBzYCjAEgASAXQYG2jZQBaiIINgKIASABIBZBvovGoQJqIgk2AoQBIAEgFUHD+7GoBWoiCjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEaIAEoAlQhAiABKAJYIQMgASgCXCEEIAEgDDYCbCABIAs2AmggASAGNgJkIAEgBTYCYCABIAQ2AnwgASADNgJ4IAEgAjYCdCABIBo2AnAgASAJNgKMASABIAo2AogBIAEgBzYChAEgASAINgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQcgASgCVCEIIAEoAlghCSABKAJcIQogASgCPCEFIAEoAjghBiABKAI0IQsgASgCMCEMIAEgBDYCbCABIAM2AmggASACNgJkIAEgGjYCYCABIAo2AnwgASAJNgJ4IAEgCDYCdCABIAc2AnAgASAMQfS6+ZUHaiIONgKMASABIAtB/uP6hnhqIh02AogBIAEgBkGnjfDeeWoiGzYChAEgASAFQfTi74x8aiIcNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIRogASgCVCECIAEoAlghAyABKAJcIQQgASAKNgJsIAEgCTYCaCABIAg2AmQgASAHNgJgIAEgBDYCfCABIAM2AnggASACNgJ0IAEgGjYCcCABIBs2AowBIAEgHDYCiAEgASAONgKEASABIB02AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhByABKAJUIQggASgCWCEJIAEoAlwhCiABIA02AnwgASAUNgJ4IAEgEzYCdCABIBI2AnAgASAYNgKMASABIBE2AogBIAEgEDYChAEgASAPNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIBcgASgCbGo2AlwgASAWIAEoAmhqNgJYIAEgFSABKAJkajYCVCABIAwgASgCYGo2AlAgASAMNgKMASABIAs2AogBIAEgBjYChAEgASAFNgKAASABQUBrIAFB0ABqIAFBgAFqEPQBIAEgBDYCbCABIAM2AmggASACNgJkIAEgGjYCYCABIAo2AnwgASAJNgJ4IAEgCDYCdCABIAc2AnAgASABKAJMIhpBwdPtpH5qIgI2AowBIAEgASgCSEGGj/n9fmoiAzYCiAEgASABKAJEQca7hv4AaiIENgKEASABIAEoAkBBzMOyoAJqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhEiABKAJUIRMgASgCWCEUIAEoAlwhDSABIAo2AmwgASAJNgJoIAEgCDYCZCABIAc2AmAgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIAEgBDYCjAEgASAONgKIASABIAI2AoQBIAEgAzYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGDYCfCABIBE2AnggASAQNgJ0IAEgDzYCcCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgCyABKAJsajYCXCABIAYgASgCaGo2AlggASAFIAEoAmRqNgJUIAEgGiABKAJgajYCUCABQYgBaiIaIAEpA0g3AwAgASABKQNANwOAASABQfAAaiABQdAAaiABQYABahD0ASABKAJwIQ8gASgCdCEQIAEoAnghESABKAJ8IRggASANNgJsIAEgFDYCaCABIBM2AmQgASASNgJgIAEgBzYCfCABIAQ2AnggASADNgJ0IAEgAjYCcCABIBhB79ik7wJqIgg2AowBIAEgEUGqidLTBGoiCTYCiAEgASAQQdzTwuUFaiIKNgKEASABIA9B2pHmtwdqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhEiABKAJUIRMgASgCWCEUIAEoAlwhDSABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIAEgCjYCjAEgASAONgKIASABIAg2AoQBIAEgCTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgASgCbCABKAJIajYCXCABIAEoAmggASgCRGo2AlggASABKAJkIAEoAkBqNgJUIAEgGCABKAJgajYCUCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhFSABKAJ0IRYgASgCeCEXIAEoAnwhGSABIA02AmwgASAUNgJoIAEgEzYCZCABIBI2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgGUHSovnBeWoiCDYCjAEgASAXQe2Mx8F6aiIJNgKIASABIBZByM+MgHtqIgo2AoQBIAEgFUHH/+X6e2oiDjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCESIAEoAlQhEyABKAJYIRQgASgCXCENIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA02AnwgASAUNgJ4IAEgEzYCdCABIBI2AnAgASAKNgKMASABIA42AogBIAEgCDYChAEgASAJNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASAMNgJ8IAEgCzYCeCABIAY2AnQgASAFNgJwIBogASkDSDcDACABIAEpA0A3A4ABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgESABKAJsajYCXCABIBAgASgCaGo2AlggASAPIAEoAmRqNgJUIAEgGSABKAJgajYCUCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhBSABKAJ0IQYgASgCeCELIAEoAnwhDCABIA02AmwgASAUNgJoIAEgEzYCZCABIBI2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDEHzl4C3fGoiEjYCjAEgASALQceinq19aiITNgKIASABIAZB0capNmoiFDYChAEgASAFQefSpKEBaiINNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQggASgCVCEJIAEoAlghCiABKAJcIQ4gASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgDjYCfCABIAo2AnggASAJNgJ0IAEgCDYCcCABIBQ2AowBIAEgDTYCiAEgASASNgKEASABIBM2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhAiABKAJUIQMgASgCWCEEIAEoAlwhByABQfgAaiIdIAEpA0g3AwAgASABKQNANwNwIAEgGDYCjAEgASARNgKIASABIBA2AoQBIAEgDzYCgAEgAUHgAGogAUHwAGogAUGAAWoQ/AEgASAXIAEoAmxqNgJcIAEgFiABKAJoajYCWCABIBUgASgCZGo2AlQgASAMIAEoAmBqNgJQIAEgDDYCjAEgASALNgKIASABIAY2AoQBIAEgBTYCgAEgAUHwAGogAUHQAGogAUGAAWoQ9AEgASgCcCESIAEoAnQhEyABKAJ4IRQgASgCfCENIAEgDjYCbCABIAo2AmggASAJNgJkIAEgCDYCYCABIAc2AnwgASAENgJ4IAEgAzYCdCABIAI2AnAgASANQYWV3L0CaiIbNgKMASABIBRBuMLs8AJqIhw2AogBIAEgE0H827HpBGoiHjYChAEgASASQZOa4JkFaiIfNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQggASgCVCEJIAEoAlghCiABKAJcIQ4gASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgDjYCfCABIAo2AnggASAJNgJ0IAEgCDYCcCABIB42AowBIAEgHzYCiAEgASAbNgKEASABIBw2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhAiABKAJUIQMgASgCWCEEIAEoAlwhByABIBg2AnwgASARNgJ4IAEgEDYCdCABIA82AnAgASAZNgKMASABIBc2AogBIAEgFjYChAEgASAVNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIAsgASgCbGo2AlwgASAGIAEoAmhqNgJYIAEgBSABKAJkajYCVCABIA0gASgCYGo2AlAgASANNgKMASABIBQ2AogBIAEgEzYChAEgASASNgKAASABQUBrIAFB0ABqIAFBgAFqEPQBIAEgDjYCbCABIAo2AmggASAJNgJkIAEgCDYCYCABIAc2AnwgASAENgJ4IAEgAzYCdCABIAI2AnAgASABKAJMIg9B1OapqAZqIhA2AowBIAEgASgCSCIbQbuVqLMHaiIRNgKIASABIAEoAkQiHEGukouOeGoiGDYChAEgASABKAJAIh5BhdnIk3lqIh82AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhCCABKAJUIQkgASgCWCEKIAEoAlwhDiABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASAONgJ8IAEgCjYCeCABIAk2AnQgASAINgJwIAEgGDYCjAEgASAfNgKIASABIBA2AoQBIAEgETYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgFCABKAJsajYCXCABIBMgASgCaGo2AlggASASIAEoAmRqNgJUIAEgDyABKAJgajYCUCAaIAEpA0g3AwAgASABKQNANwOAASABQfAAaiABQdAAaiABQYABahD0ASABKAJwIQ8gASgCdCEQIAEoAnghESABKAJ8IRggASAONgJsIAEgCjYCaCABIAk2AmQgASAINgJgIAEgBzYCfCABIAQ2AnggASADNgJ0IAEgAjYCcCABIBhBodH/lXpqIgg2AowBIAEgEUHLzOnAemoiCTYCiAEgASAQQfCWrpJ8aiIKNgKEASABIA9Bo6Oxu3xqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhFSABKAJUIRYgASgCWCEXIAEoAlwhGSABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASAZNgJ8IAEgFzYCeCABIBY2AnQgASAVNgJwIAEgCjYCjAEgASAONgKIASABIAg2AoQBIAEgCTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIA02AowBIAEgFDYCiAEgASATNgKEASABIBI2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgGyABKAJsajYCXCABIBwgASgCaGo2AlggASAeIAEoAmRqNgJUIAEgGCABKAJgajYCUCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhBSABKAJ0IQYgASgCeCELIAEoAnwhDCABIBk2AmwgASAXNgJoIAEgFjYCZCABIBU2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDEGZ0MuMfWoiFTYCjAEgASALQaSM5LR9aiIWNgKIASABIAZBheu4oH9qIhc2AoQBIAEgBUHwwKqDAWoiGTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAXNgKMASABIBk2AogBIAEgFTYChAEgASAWNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIBogASkDSDcDACABIAEpA0A3A4ABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgESABKAJsajYCXCABIBAgASgCaGo2AlggASAPIAEoAmRqNgJUIAEgDCABKAJgajYCUCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhFSABKAJ0IRYgASgCeCEXIAEoAnwhGSABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgGUGWgpPNAWoiEjYCjAEgASAXQYjY3fEBaiITNgKIASABIBZBzO6hugJqIhQ2AoQBIAEgFUG1+cKlA2oiDTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAUNgKMASABIA02AogBIAEgEjYChAEgASATNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgHSABKQNINwMAIAEgASkDQDcDcCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgCyABKAJsajYCXCABIAYgASgCaGo2AlggASAFIAEoAmRqNgJUIAEgGSABKAJgajYCUCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhEiABKAJ0IRMgASgCeCEUIAEoAnwhDSABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDUGzmfDIA2oiHTYCjAEgASAUQcrU4vYEaiIbNgKIASABIBNBz5Tz3AVqIhw2AoQBIAEgEkHz37nBBmoiHjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAcNgKMASABIB42AogBIAEgHTYChAEgASAbNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASAYNgJ8IAEgETYCeCABIBA2AnQgASAPNgJwIAEgDDYCjAEgASALNgKIASABIAY2AoQBIAEgBTYCgAEgAUHgAGogAUHwAGogAUGAAWoQ/AEgASAXIAEoAmxqNgJcIAEgFiABKAJoajYCWCABIBUgASgCZGo2AlQgASANIAEoAmBqNgJQIAEgDTYCjAEgASAUNgKIASABIBM2AoQBIAEgEjYCgAEgAUFAayABQdAAaiABQYABahD0ASABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgASgCTCIIQe6FvqQHaiINNgKMASABIAEoAkhB78aVxQdqIgk2AogBIAEgASgCREGU8KGmeGoiCjYChAEgASABKAJAQYiEnOZ4aiIONgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQ8gASgCVCEQIAEoAlghESABKAJcIRggASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgGDYCfCABIBE2AnggASAQNgJ0IAEgDzYCcCABIAo2AowBIAEgDjYCiAEgASANNgKEASABIAk2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhDSABKAJUIQIgASgCWCEDIAEoAlwhBCABIAw2AnwgASALNgJ4IAEgBjYCdCABIAU2AnAgASAZNgKMASABIBc2AogBIAEgFjYChAEgASAVNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIBQgASgCbGo2AlwgASATIAEoAmhqNgJYIAEgEiABKAJkajYCVCABIAggASgCYGo2AlAgGiABKQNINwMAIAEgASkDQDcDgAEgAUHwAGogAUHQAGogAUGAAWoQ9AEgASgCcCEFIAEoAnQhBiABKAJ4IQsgASgCfCEMIAEgGDYCbCABIBE2AmggASAQNgJkIAEgDzYCYCABIAQ2AnwgASADNgJ4IAEgAjYCdCABIA02AnAgASAMQfr/+4V5aiIPNgKMASABIAtB69nBonpqIhA2AogBIAEgBkH3x+b3e2oiETYChAEgASAFQfLxxbN8aiIYNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQUgASgCVCEGIAEoAlghCyABKAJcIQwgASAENgJsIAEgAzYCaCABIAI2AmQgASANNgJgIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIBE2AowBIAEgGDYCiAEgASAPNgKEASABIBA2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlwhDyABKAJYIRAgASgCVCERIAAgACgCACABKAJQajYCACAAIBEgACgCBGo2AgQgACAFIAAoAghqNgIIIAAgBiAAKAIMajYCDCAAIBAgACgCEGo2AhAgACAPIAAoAhRqNgIUIAAgCyAAKAIYajYCGCAAIAwgACgCHGo2AhwgAUGQAWokAAvWIgIBfx5+IwBB0AprIgMkACADQfAGaiACKQMAIgUgASkDACIEEJ4CIANB4AZqIAMpA/AGIgxCm/zRkrG0xwJ+Qv////////8HgyIJQu2n1+el45gBEJ4CIANBgAdqIAIpAwgiBiAEEJ4CIANBwAdqIAEpAwgiByAFEJ4CIANB0AZqIAlCgcu1zvfF+gYQngIgA0HABmogAykDwAciECADKQOAB3wiESADKQPQBnwiDiAMIAMpA+AGIgh8IgxCNIggDCAIVK0gA0HoBmopAwAgA0H4BmopAwB8fCIUQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GACGogByAGEJ4CIANBkAdqIAIpAxAiCCAEEJ4CIANB0AdqIAEpAxAiDSAFEJ4CIANBkAZqIAlC+b3TABCeAiADQbAGaiAMQoHLtc73xfoGEJ4CIANBgAZqIAMpA5AHIhcgAykDgAh8IhIgAykD0Ad8IgogAykDkAZ8Ig8gAykDsAZ8IhMgAykDwAYiFSALfCIWQjSIIBYgFVStIANByAZqKQMAIAsgDlStIA4gEVStIANB2AZqKQMAIBEgEFStIANByAdqKQMAIANBiAdqKQMAfHx8fCAUQjSIfHx8fCIYQgyGhHwiEEKb/NGSsbTHAn5C/////////weDIhFC7afX56XjmAEQngIgA0HACGogCCAHEJ4CIANBkAhqIA0gBhCeAiADQaAHaiACKQMYIg4gBBCeAiADQeAHaiABKQMYIgsgBRCeAiADQaAGaiAMQvm90wAQngIgA0HwBWogEUKBy7XO98X6BhCeAiADQeAFaiADKQOQCCIeIAMpA8AIfCIUIAMpA6AHfCIVIAMpA+AHfCIWIAMpA6AGfCIZIAMpA/AFfCIaIAMpA4AGIhsgEHwiHEI0iCAcIBtUrSADQYgGaikDACAQIBNUrSATIA9UrSADQbgGaikDACAPIApUrSADQZgGaikDACAKIBJUrSADQdgHaikDACASIBdUrSADQZgHaikDACADQYgIaikDAHx8fHx8fHx8IBhCNIh8fHx8Ih9CDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiEkLtp9fnpeOYARCeAiADQfAIaiANIAgQngIgA0HQCGogDiAHEJ4CIANBoAhqIAsgBhCeAiADQbAHaiACKQMgIgogBBCeAiADQfAHaiABKQMgIgQgBRCeAiADQbAFaiARQvm90wAQngIgA0HQBWogEkKBy7XO98X6BhCeAiADQaAFaiADKQPQCCIgIAMpA/AIfCITIAlCLIZ8IhAgAykDoAh8IhcgAykDsAd8IhggAykD8Ad8IhsgAykDsAV8IhwgAykD0AV8Ih0gAykD4AUiBSAPfCIhQjSIICEgBVStIANB6AVqKQMAIA8gGlStIBogGVStIANB+AVqKQMAIBkgFlStIANBqAZqKQMAIBYgFVStIANB6AdqKQMAIBUgFFStIANBqAdqKQMAIBQgHlStIANBmAhqKQMAIANByAhqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIUQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GgCWogDiANEJ4CIANBgAlqIAsgCBCeAiADQeAIaiAKIAcQngIgA0GwCGogBCAGEJ4CIANBwAVqIBJC+b3TABCeAiADQZAFaiAFQoHLtc73xfoGEJ4CIANBwAlqIAsgDhCeAiADQbAJaiAKIA0QngIgA0GQCWogBCAIEJ4CIANBgAVqIAVC+b3TABCeAiADQeAJaiAKIAsQngIgA0HQCWogBCAOEJ4CIANB8AlqIAQgChCeAiADIAMpA4AJIhUgAykDoAl8IgQgAykD4Ah8IgYgAykDsAh8IgcgDEIshnwiCCADKQPABXwiDSADKQOQBXwiDiADKQOgBSILIA98IgpCNIggCiALVK0gA0GoBWopAwAgDyAdVK0gHSAcVK0gA0HYBWopAwAgHCAbVK0gA0G4BWopAwAgGyAYVK0gA0H4B2opAwAgGCAXVK0gA0G4B2opAwAgFyAQVK0gA0GoCGopAwAgECATVK0gEyAgVK0gA0HYCGopAwAgA0H4CGopAwB8fCAJQhSIfHx8fHx8fHx8fHx8IBRCNIh8fHx8IhBCDIaEfCIJQv////////8HgzcDqAogAyADKQOwCSIUIAMpA8AJfCILIAMpA5AJfCIKIBFCLIZ8Ig8gAykDgAV8IhMgCSAOVK0gDiANVK0gA0GYBWopAwAgDSAIVK0gA0HIBWopAwAgCCAHVK0gByAGVK0gA0G4CGopAwAgBiAEVK0gA0HoCGopAwAgBCAVVK0gA0GICWopAwAgA0GoCWopAwB8fHx8fHwgDEIUiHx8fHx8fCAQQjSIfHwiB0IMhiAJQjSIhHwiBEL/////////B4M3A7AKIAMgAykD0AkiDCADKQPgCXwiCSASQiyGfCIGIAQgE1StIBMgD1StIANBiAVqKQMAIA8gClStIAogC1StIANBmAlqKQMAIAsgFFStIANBuAlqKQMAIANByAlqKQMAfHx8fCARQhSIfHx8fCAHQjSIfHwiCEIMhiAEQjSIhHwiBEL/////////B4M3A7gKIAMgBUIshiINIAMpA/AJfCIHIAQgBlStIAYgCVStIAkgDFStIANB2AlqKQMAIANB6AlqKQMAfHwgEkIUiHx8IAhCNIh8fCIJQgyGIARCNIiEfCIEQv////////8HgzcDwAogAyAEIAdUrSAHIA1UrSADQfgJaikDACAFQhSIfHwgCUI0iHx8QgyGIARCNIiENwPICiADQYAKaiADQagKakGAvMQAEKABIANBsAJqIAMpA4AKIgVCu6LLyt7M9AQQngIgA0HgAWogAykDsAIiBkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgA0GgAmogBUKfzfqt8fjYBhCeAiADQYADaiADKQOICiIJQruiy8rezPQEEJ4CIANB0AFqIARCgcu1zvfF+gYQngIgA0GwAWogAykDgAMiCiADKQOgAnwiDCADKQPQAXwiCCAGIAMpA+ABIgd8IgZCNIggBiAHVK0gA0HoAWopAwAgA0G4AmopAwB8fCIPQgyGhHwiDUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GQAmogBUKE7KHb3MzvAhCeAiADQfACaiAJQp/N+q3x+NgGEJ4CIANB0ANqIAMpA5AKIgdCu6LLyt7M9AQQngIgA0HAAWogBEL5vdMAEJ4CIANBoAFqIAZCgcu1zvfF+gYQngIgA0GAAWogAykD8AIiFSADKQOQAnwiESADKQPQA3wiDiADKQPAAXwiCyADKQOgAXwiEiADKQOwASITIA18IhBCNIggECATVK0gA0G4AWopAwAgDSAIVK0gCCAMVK0gA0HYAWopAwAgDCAKVK0gA0GIA2opAwAgA0GoAmopAwB8fHx8IA9CNIh8fHx8IhZCDIaEfCINQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYACaiAFQv/C9LnsnfcBEJ4CIANB4AJqIAlChOyh29zM7wIQngIgA0HAA2ogB0Kfzfqt8fjYBhCeAiADQaAEaiADKQOYCiIIQruiy8rezPQEEJ4CIANBkAFqIAZC+b3TABCeAiADQfAAaiAMQoHLtc73xfoGEJ4CIANB0ABqIAMpA+ACIhcgAykDgAJ8IgogAykDwAN8Ig8gAykDoAR8IhMgAykDkAF8IhAgAykDcHwiFCADKQOAASIZIA18IhpCNIggGiAZVK0gA0GIAWopAwAgDSASVK0gEiALVK0gA0GoAWopAwAgCyAOVK0gA0HIAWopAwAgDiARVK0gA0HYA2opAwAgESAVVK0gA0H4AmopAwAgA0GYAmopAwB8fHx8fHx8fCAWQjSIfHx8fCIYQgyGhHwiEUKb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0HwAWogBUKa4fDbkagCEJ4CIANB0AJqIAlC/8L0ueyd9wEQngIgA0GwA2ogB0KE7KHb3MzvAhCeAiADQZAEaiAIQp/N+q3x+NgGEJ4CIANB8ARqIAMpA6AKIgVCu6LLyt7M9AQQngIgA0HgAGogDEL5vdMAEJ4CIANBQGsgDUKBy7XO98X6BhCeAiADQSBqIAMpA9ACIhsgAykD8AF8Ig4gAykDsAN8IgsgAykDkAR8IhIgAykD8AR8IhUgBEIshnwiFiADKQNgfCIZIAMpA0B8IhogAykDUCIcIBF8Ih1CNIggHSAcVK0gA0HYAGopAwAgESAUVK0gFCAQVK0gA0H4AGopAwAgECATVK0gA0GYAWopAwAgEyAPVK0gA0GoBGopAwAgDyAKVK0gA0HIA2opAwAgCiAXVK0gA0HoAmopAwAgA0GIAmopAwB8fHx8fHx8fHx8IBhCNIh8fHx8IhBCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiEULtp9fnpeOYARCeAiADQcACaiAJQprh8NuRqAIQngIgA0GgA2ogB0L/wvS57J33ARCeAiADQYAEaiAIQoTsodvczO8CEJ4CIANB4ARqIAVCn836rfH42AYQngIgA0EwaiANQvm90wAQngIgA0EQaiARQoHLtc73xfoGEJ4CIANBkANqIAdCmuHw25GoAhCeAiADQfADaiAIQv/C9LnsnfcBEJ4CIANB0ARqIAVChOyh29zM7wIQngIgAyARQvm90wAQngIgA0HgA2ogCEKa4fDbkagCEJ4CIANBwARqIAVC/8L0ueyd9wEQngIgA0GwBGogBUKa4fDbkagCEJ4CIAMgAykDoAMiFCADKQPAAnwiBSADKQOABHwiCSADKQPgBHwiByAGQiyGfCIIIAMpAzB8Ig8gAykDEHwiEyADKQMgIhcgCnwiGEI0iCAYIBdUrSADQShqKQMAIAogGlStIBogGVStIANByABqKQMAIBkgFlStIANB6ABqKQMAIBYgFVStIBUgElStIANB+ARqKQMAIBIgC1StIANBmARqKQMAIAsgDlStIANBuANqKQMAIA4gG1StIANB2AJqKQMAIANB+AFqKQMAfHx8fHx8fHwgBEIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBEL/////////B4M3A6gKIAMgAykD8AMiFSADKQOQA3wiDiADKQPQBHwiCyAMQiyGfCISIAMpAwB8IgogBCATVK0gEyAPVK0gA0EYaikDACAPIAhUrSADQThqKQMAIAggB1StIAcgCVStIANB6ARqKQMAIAkgBVStIANBiARqKQMAIAUgFFStIANBqANqKQMAIANByAJqKQMAfHx8fHx8IAZCFIh8fHx8fHwgEEI0iHx8IgZCDIYgBEI0iIR8IgVC/////////weDNwOwCiADIAMpA8AEIgcgAykD4AN8IgQgDUIshnwiCSAFIApUrSAKIBJUrSADQQhqKQMAIBIgC1StIAsgDlStIANB2ARqKQMAIA4gFVStIANB+ANqKQMAIANBmANqKQMAfHx8fCAMQhSIfHx8fCAGQjSIfHwiDEIMhiAFQjSIhHwiBUL/////////B4M3A7gKIAMgEUIshiIIIAMpA7AEfCIGIAUgCVStIAkgBFStIAQgB1StIANByARqKQMAIANB6ANqKQMAfHwgDUIUiHx8IAxCNIh8fCIEQgyGIAVCNIiEfCIFQv////////8HgzcDwAogAyAFIAZUrSAGIAhUrSADQbgEaikDACARQhSIfHwgBEI0iHx8QgyGIAVCNIiENwPICiAAIANBqApqQYC8xAAQoAEgA0HQCmokAAvWIgIBfx5+IwBB0AprIgMkACADQfAGaiACKQMAIgUgASkDACIEEJ4CIANB4AZqIAMpA/AGIgxCm/zRkrG0xwJ+Qv////////8HgyIJQu2n1+el45gBEJ4CIANBgAdqIAIpAwgiBiAEEJ4CIANBwAdqIAEpAwgiByAFEJ4CIANB0AZqIAlCgcu1zvfF+gYQngIgA0HABmogAykDwAciECADKQOAB3wiESADKQPQBnwiDiAMIAMpA+AGIgh8IgxCNIggDCAIVK0gA0HoBmopAwAgA0H4BmopAwB8fCIUQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GACGogByAGEJ4CIANBkAdqIAIpAxAiCCAEEJ4CIANB0AdqIAEpAxAiDSAFEJ4CIANBkAZqIAlC+b3TABCeAiADQbAGaiAMQoHLtc73xfoGEJ4CIANBgAZqIAMpA5AHIhcgAykDgAh8IhIgAykD0Ad8IgogAykDkAZ8Ig8gAykDsAZ8IhMgAykDwAYiFSALfCIWQjSIIBYgFVStIANByAZqKQMAIAsgDlStIA4gEVStIANB2AZqKQMAIBEgEFStIANByAdqKQMAIANBiAdqKQMAfHx8fCAUQjSIfHx8fCIYQgyGhHwiEEKb/NGSsbTHAn5C/////////weDIhFC7afX56XjmAEQngIgA0HACGogCCAHEJ4CIANBkAhqIA0gBhCeAiADQaAHaiACKQMYIg4gBBCeAiADQeAHaiABKQMYIgsgBRCeAiADQaAGaiAMQvm90wAQngIgA0HwBWogEUKBy7XO98X6BhCeAiADQeAFaiADKQOQCCIeIAMpA8AIfCIUIAMpA6AHfCIVIAMpA+AHfCIWIAMpA6AGfCIZIAMpA/AFfCIaIAMpA4AGIhsgEHwiHEI0iCAcIBtUrSADQYgGaikDACAQIBNUrSATIA9UrSADQbgGaikDACAPIApUrSADQZgGaikDACAKIBJUrSADQdgHaikDACASIBdUrSADQZgHaikDACADQYgIaikDAHx8fHx8fHx8IBhCNIh8fHx8Ih9CDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiEkLtp9fnpeOYARCeAiADQfAIaiANIAgQngIgA0HQCGogDiAHEJ4CIANBoAhqIAsgBhCeAiADQbAHaiACKQMgIgogBBCeAiADQfAHaiABKQMgIgQgBRCeAiADQbAFaiARQvm90wAQngIgA0HQBWogEkKBy7XO98X6BhCeAiADQaAFaiADKQPQCCIgIAMpA/AIfCITIAlCLIZ8IhAgAykDoAh8IhcgAykDsAd8IhggAykD8Ad8IhsgAykDsAV8IhwgAykD0AV8Ih0gAykD4AUiBSAPfCIhQjSIICEgBVStIANB6AVqKQMAIA8gGlStIBogGVStIANB+AVqKQMAIBkgFlStIANBqAZqKQMAIBYgFVStIANB6AdqKQMAIBUgFFStIANBqAdqKQMAIBQgHlStIANBmAhqKQMAIANByAhqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIUQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GgCWogDiANEJ4CIANBgAlqIAsgCBCeAiADQeAIaiAKIAcQngIgA0GwCGogBCAGEJ4CIANBwAVqIBJC+b3TABCeAiADQZAFaiAFQoHLtc73xfoGEJ4CIANBwAlqIAsgDhCeAiADQbAJaiAKIA0QngIgA0GQCWogBCAIEJ4CIANBgAVqIAVC+b3TABCeAiADQeAJaiAKIAsQngIgA0HQCWogBCAOEJ4CIANB8AlqIAQgChCeAiADIAMpA4AJIhUgAykDoAl8IgQgAykD4Ah8IgYgAykDsAh8IgcgDEIshnwiCCADKQPABXwiDSADKQOQBXwiDiADKQOgBSILIA98IgpCNIggCiALVK0gA0GoBWopAwAgDyAdVK0gHSAcVK0gA0HYBWopAwAgHCAbVK0gA0G4BWopAwAgGyAYVK0gA0H4B2opAwAgGCAXVK0gA0G4B2opAwAgFyAQVK0gA0GoCGopAwAgECATVK0gEyAgVK0gA0HYCGopAwAgA0H4CGopAwB8fCAJQhSIfHx8fHx8fHx8fHx8IBRCNIh8fHx8IhBCDIaEfCIJQv////////8HgzcDqAogAyADKQOwCSIUIAMpA8AJfCILIAMpA5AJfCIKIBFCLIZ8Ig8gAykDgAV8IhMgCSAOVK0gDiANVK0gA0GYBWopAwAgDSAIVK0gA0HIBWopAwAgCCAHVK0gByAGVK0gA0G4CGopAwAgBiAEVK0gA0HoCGopAwAgBCAVVK0gA0GICWopAwAgA0GoCWopAwB8fHx8fHwgDEIUiHx8fHx8fCAQQjSIfHwiB0IMhiAJQjSIhHwiBEL/////////B4M3A7AKIAMgAykD0AkiDCADKQPgCXwiCSASQiyGfCIGIAQgE1StIBMgD1StIANBiAVqKQMAIA8gClStIAogC1StIANBmAlqKQMAIAsgFFStIANBuAlqKQMAIANByAlqKQMAfHx8fCARQhSIfHx8fCAHQjSIfHwiCEIMhiAEQjSIhHwiBEL/////////B4M3A7gKIAMgBUIshiINIAMpA/AJfCIHIAQgBlStIAYgCVStIAkgDFStIANB2AlqKQMAIANB6AlqKQMAfHwgEkIUiHx8IAhCNIh8fCIJQgyGIARCNIiEfCIEQv////////8HgzcDwAogAyAEIAdUrSAHIA1UrSADQfgJaikDACAFQhSIfHwgCUI0iHx8QgyGIARCNIiENwPICiADQYAKaiADQagKakHY7cgAEKEBIANBsAJqIAMpA4AKIgVCu6LLyt7M9AQQngIgA0HgAWogAykDsAIiBkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgA0GgAmogBUKfzfqt8fjYBhCeAiADQYADaiADKQOICiIJQruiy8rezPQEEJ4CIANB0AFqIARCgcu1zvfF+gYQngIgA0GwAWogAykDgAMiCiADKQOgAnwiDCADKQPQAXwiCCAGIAMpA+ABIgd8IgZCNIggBiAHVK0gA0HoAWopAwAgA0G4AmopAwB8fCIPQgyGhHwiDUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GQAmogBUKE7KHb3MzvAhCeAiADQfACaiAJQp/N+q3x+NgGEJ4CIANB0ANqIAMpA5AKIgdCu6LLyt7M9AQQngIgA0HAAWogBEL5vdMAEJ4CIANBoAFqIAZCgcu1zvfF+gYQngIgA0GAAWogAykD8AIiFSADKQOQAnwiESADKQPQA3wiDiADKQPAAXwiCyADKQOgAXwiEiADKQOwASITIA18IhBCNIggECATVK0gA0G4AWopAwAgDSAIVK0gCCAMVK0gA0HYAWopAwAgDCAKVK0gA0GIA2opAwAgA0GoAmopAwB8fHx8IA9CNIh8fHx8IhZCDIaEfCINQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYACaiAFQv/C9LnsnfcBEJ4CIANB4AJqIAlChOyh29zM7wIQngIgA0HAA2ogB0Kfzfqt8fjYBhCeAiADQaAEaiADKQOYCiIIQruiy8rezPQEEJ4CIANBkAFqIAZC+b3TABCeAiADQfAAaiAMQoHLtc73xfoGEJ4CIANB0ABqIAMpA+ACIhcgAykDgAJ8IgogAykDwAN8Ig8gAykDoAR8IhMgAykDkAF8IhAgAykDcHwiFCADKQOAASIZIA18IhpCNIggGiAZVK0gA0GIAWopAwAgDSASVK0gEiALVK0gA0GoAWopAwAgCyAOVK0gA0HIAWopAwAgDiARVK0gA0HYA2opAwAgESAVVK0gA0H4AmopAwAgA0GYAmopAwB8fHx8fHx8fCAWQjSIfHx8fCIYQgyGhHwiEUKb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0HwAWogBUKa4fDbkagCEJ4CIANB0AJqIAlC/8L0ueyd9wEQngIgA0GwA2ogB0KE7KHb3MzvAhCeAiADQZAEaiAIQp/N+q3x+NgGEJ4CIANB8ARqIAMpA6AKIgVCu6LLyt7M9AQQngIgA0HgAGogDEL5vdMAEJ4CIANBQGsgDUKBy7XO98X6BhCeAiADQSBqIAMpA9ACIhsgAykD8AF8Ig4gAykDsAN8IgsgAykDkAR8IhIgAykD8AR8IhUgBEIshnwiFiADKQNgfCIZIAMpA0B8IhogAykDUCIcIBF8Ih1CNIggHSAcVK0gA0HYAGopAwAgESAUVK0gFCAQVK0gA0H4AGopAwAgECATVK0gA0GYAWopAwAgEyAPVK0gA0GoBGopAwAgDyAKVK0gA0HIA2opAwAgCiAXVK0gA0HoAmopAwAgA0GIAmopAwB8fHx8fHx8fHx8IBhCNIh8fHx8IhBCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiEULtp9fnpeOYARCeAiADQcACaiAJQprh8NuRqAIQngIgA0GgA2ogB0L/wvS57J33ARCeAiADQYAEaiAIQoTsodvczO8CEJ4CIANB4ARqIAVCn836rfH42AYQngIgA0EwaiANQvm90wAQngIgA0EQaiARQoHLtc73xfoGEJ4CIANBkANqIAdCmuHw25GoAhCeAiADQfADaiAIQv/C9LnsnfcBEJ4CIANB0ARqIAVChOyh29zM7wIQngIgAyARQvm90wAQngIgA0HgA2ogCEKa4fDbkagCEJ4CIANBwARqIAVC/8L0ueyd9wEQngIgA0GwBGogBUKa4fDbkagCEJ4CIAMgAykDoAMiFCADKQPAAnwiBSADKQOABHwiCSADKQPgBHwiByAGQiyGfCIIIAMpAzB8Ig8gAykDEHwiEyADKQMgIhcgCnwiGEI0iCAYIBdUrSADQShqKQMAIAogGlStIBogGVStIANByABqKQMAIBkgFlStIANB6ABqKQMAIBYgFVStIBUgElStIANB+ARqKQMAIBIgC1StIANBmARqKQMAIAsgDlStIANBuANqKQMAIA4gG1StIANB2AJqKQMAIANB+AFqKQMAfHx8fHx8fHwgBEIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBEL/////////B4M3A6gKIAMgAykD8AMiFSADKQOQA3wiDiADKQPQBHwiCyAMQiyGfCISIAMpAwB8IgogBCATVK0gEyAPVK0gA0EYaikDACAPIAhUrSADQThqKQMAIAggB1StIAcgCVStIANB6ARqKQMAIAkgBVStIANBiARqKQMAIAUgFFStIANBqANqKQMAIANByAJqKQMAfHx8fHx8IAZCFIh8fHx8fHwgEEI0iHx8IgZCDIYgBEI0iIR8IgVC/////////weDNwOwCiADIAMpA8AEIgcgAykD4AN8IgQgDUIshnwiCSAFIApUrSAKIBJUrSADQQhqKQMAIBIgC1StIAsgDlStIANB2ARqKQMAIA4gFVStIANB+ANqKQMAIANBmANqKQMAfHx8fCAMQhSIfHx8fCAGQjSIfHwiDEIMhiAFQjSIhHwiBUL/////////B4M3A7gKIAMgEUIshiIIIAMpA7AEfCIGIAUgCVStIAkgBFStIAQgB1StIANByARqKQMAIANB6ANqKQMAfHwgDUIUiHx8IAxCNIh8fCIEQgyGIAVCNIiEfCIFQv////////8HgzcDwAogAyAFIAZUrSAGIAhUrSADQbgEaikDACARQhSIfHwgBEI0iHx8QgyGIAVCNIiENwPICiAAIANBqApqQdjtyAAQoQEgA0HQCmokAAucIgEVfyMAQbDAAGsiAiQAIAJBIGogAUEYaikAADcDAEEQIQQgAkEYaiIDIAFBEGopAAA3AwAgAkEQaiIKIAFBCGoiDykAADcDACACIAEpAAA3AwggAkHIAGpBAEHgHxDBBCACQTBqIA8pAAA3AwAgAkFAayAKKQMANwMAIAIgASkAADcDKCACIAIpAwg3AzggAxCpASACQdgAaiADEKkBA0AgBUGACEYEQCACQShqIAJBqAhqQcAAEPIDGkEAIQVBkAIhBANAIAVBwB9GBEACQCACQaggaiACQShqQYAgEPIDGkEAIQUgAkEANgKoQCACQagwaiEBQcAAIRUDQCAVBEAgBUEPcQ0CIAVB/wNxIgNBAWohBCAFQRBqQf8DcSEWIAVB8ANqQf8DcSIKQQRqIQ8gCkEGaiEJIApBDWohBwJ/IAVBgARPBEAgASADQQJ0aiIFIAUoAgAgASAJQQJ0aiIMKAIAQQh3aiABIAdBAnRqIg0oAgBBCncgASAEQQJ0aiIJKAIAIgdBF3dzaiIRNgIAIAJBqCBqIANBgARyIgRBAnRqIAJBqCBqIAEgD0ECdGooAgAiA0EOdkH8B3FBgAhyaigCACACQaggaiADQf8BcUECdGooAgBqIBFzIg82AgAgCSAHIApBAnQgAWoiA0EcaiIOKAIAQQh3aiADQThqIhEoAgBBCncgBUEIaiIJKAIAIgdBF3dzaiIUNgIAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQCAEQQFqIgpBgAhJBEAgAkGoIGogCkECdGogAkGoIGogA0EUaigCACIKQf8BcUECdGooAgAgAkGoIGogCkEOdkH8B3FBgAhyaigCAGogFHMiCjYCACAJIANBIGoiBigCAEEIdyAHaiADQTxqIhQoAgBBCncgBUEMaiIHKAIAIgtBF3dzaiIINgIAIARBAmoiCUH/B0sNASACQaggaiAJQQJ0aiACQaggaiAMKAIAIglB/wFxQQJ0aigCACACQaggaiAJQQ52QfwHcUGACHJqKAIAaiAIcyIJNgIAIAcgCyADQSRqIggoAgBBCHdqIAVBEGoiDCgCACILQRd3IA9BCndzaiISNgIAIARBA2oiB0H/B0sNAiACQaggaiAHQQJ0aiACQaggaiAOKAIAIgdB/wFxQQJ0aigCACACQaggaiAHQQ52QfwHcUGACHJqKAIAaiAScyIHNgIAIAwgCyADQShqIhIoAgBBCHdqIAVBFGoiDigCACILQRd3IApBCndzaiIQNgIAIARBBGoiDEH/B0sNAyACQaggaiAMQQJ0aiACQaggaiAGKAIAIgxB/wFxQQJ0aigCACACQaggaiAMQQ52QfwHcUGACHJqKAIAaiAQcyIMNgIAIA4gA0EsaiIGKAIAQQh3IAtqIAVBGGoiCygCACIQQRd3IAlBCndzaiITNgIAIARBBWoiDkH/B0sNBCACQaggaiAOQQJ0aiACQaggaiAIKAIAIg5B/wFxQQJ0aigCACACQaggaiAOQQ52QfwHcUGACHJqKAIAaiATcyIONgIAIAsgA0EwaiILKAIAQQh3IBBqIAVBHGoiCCgCACIQQRd3IAdBCndzaiITNgIAIARBBmoiA0H/B0sNBSACQaggaiADQQJ0aiACQaggaiASKAIAIgNB/wFxQQJ0aigCACACQaggaiADQQ52QfwHcUGACHJqKAIAaiATcyISNgIAIAggDSgCAEEIdyAQaiAFQSBqIggoAgAiEEEXdyAMQQp3c2oiEzYCACAEQQdqIgNB/wdLDQYgAkGoIGogA0ECdGogAkGoIGogBigCACIDQf8BcUECdGooAgAgAkGoIGogA0EOdkH8B3FBgAhyaigCAGogE3MiBjYCACAIIBEoAgBBCHcgEGogBUEkaiIIKAIAIhBBF3cgDkEKd3NqIhM2AgAgBEEIaiIDQf8HSw0HIAJBqCBqIANBAnRqIAJBqCBqIAsoAgAiA0H/AXFBAnRqKAIAIAJBqCBqIANBDnZB/AdxQYAIcmooAgBqIBNzIgs2AgAgCCAUKAIAQQh3IBBqIAVBKGoiCCgCACIQQRd3IBJBCndzaiISNgIAIARBCWoiA0H/B0sNCCACQaggaiADQQJ0aiACQaggaiANKAIAIgNB/wFxQQJ0aigCACACQaggaiADQQ52QfwHcUGACHJqKAIAaiAScyINNgIAIAggECAPQQh3aiAFQSxqIggoAgAiEkEXdyAGQQp3c2oiBjYCACAEQQpqIgNB/wdLDQkgAkGoIGogA0ECdGogAkGoIGogESgCACIDQf8BcUECdGooAgAgAkGoIGogA0EOdkH8B3FBgAhyaigCAGogBnMiETYCACAIIBIgCkEId2ogBUEwaiIGKAIAIghBF3cgC0EKd3NqIgs2AgAgBEELaiIDQf8HSw0KIAJBqCBqIANBAnRqIAJBqCBqIBQoAgAiA0H/AXFBAnRqKAIAIAJBqCBqIANBDnZB/AdxQYAIcmooAgBqIAtzIhQ2AgAgBiAIIAlBCHdqIAVBNGoiBigCACILQRd3IA1BCndzaiINNgIAIARBDGoiA0H/B0sNCyACQaggaiADQQJ0aiACQaggaiAPQf8BcUECdGooAgAgAkGoIGogD0EOdkH8B3FBgAhyaigCAGogDXMiDzYCACAGIAsgB0EId2ogBUE4aiINKAIAIgZBF3cgEUEKd3NqIhE2AgAgBEENaiIDQf8HSw0MIAJBqCBqIANBAnRqIAJBqCBqIApB/wFxQQJ0aigCACACQaggaiAKQQ52QfwHcUGACHJqKAIAaiARczYCACANIAYgDEEId2ogBUE8aiIDKAIAIgpBF3cgFEEKd3NqIg02AgAgBEEOaiIFQf8HSw0NIAJBqCBqIAVBAnRqIAJBqCBqIAlB/wFxQQJ0aigCACACQaggaiAJQQ52QfwHcUGACHJqKAIAaiANczYCACADIAogDkEId2ogASAWQQJ0aigCAEEXdyAPQQp3c2oiBTYCACAEQQ9qIgRB/wdLDQ4gAkGoIGogB0EOdkH8B3FBgAhyaiEDIAJBqCBqIAdB/wFxQQJ0agwQC0HY/skAIApBgAgQ5AIAC0Ho/skAIAlBgAgQ5AIAC0H4/skAIAdBgAgQ5AIAC0GI/8kAIAxBgAgQ5AIAC0GY/8kAIA5BgAgQ5AIAC0Go/8kAIANBgAgQ5AIAC0G4/8kAIANBgAgQ5AIAC0HI/8kAIANBgAgQ5AIAC0HY/8kAIANBgAgQ5AIAC0Ho/8kAIANBgAgQ5AIAC0H4/8kAIANBgAgQ5AIAC0GIgMoAIANBgAgQ5AIAC0GYgMoAIANBgAgQ5AIAC0GogMoAIAVBgAgQ5AIAC0G4gMoAIARBgAgQ5AIACyACQaggaiADQQJ0aiIFIAUoAgAgAkGoIGogCUECdGoiDigCAEEYd2ogAkGoIGogB0ECdGoiDSgCAEEWdyACQaggaiAEQQJ0aiIJKAIAIgdBCXdzaiIENgIAIAUgBCABIAJBqCBqIA9BAnRqKAIAIg9BDnZB/AdxQYAIcmooAgAgASAPQf8BcUECdGooAgBqcyIPNgIAIAkgByACQaggaiAKQQJ0aiIEQRxqIgYoAgBBGHdqIARBOGoiESgCAEEWdyAFQQhqIgcoAgAiFEEJd3NqIgo2AgAgCSAKIAEgBEEUaigCACIJQQ52QfwHcUGACHJqKAIAIAEgCUH/AXFBAnRqKAIAanMiCjYCACAHIBQgBEEgaiILKAIAQRh3aiAEQTxqIhQoAgBBFncgBUEMaiIMKAIAIghBCXdzaiIJNgIAIAcgCSABIA4oAgAiB0EOdkH8B3FBgAhyaigCACABIAdB/wFxQQJ0aigCAGpzIgk2AgAgDCAIIARBJGoiEigCAEEYd2ogBUEQaiIOKAIAIghBCXcgD0EWd3NqIgc2AgAgDCAHIAEgBigCACIMQQ52QfwHcUGACHJqKAIAIAEgDEH/AXFBAnRqKAIAanMiBzYCACAOIAggBEEoaiIQKAIAQRh3aiAFQRRqIgwoAgAiBkEJdyAKQRZ3c2oiCDYCACAOIAEgCygCACIOQQ52QfwHcUGACHJqKAIAIAEgDkH/AXFBAnRqKAIAaiAIcyIONgIAIAwgBiAEQSxqIgsoAgBBGHdqIAVBGGoiBigCACIIQQl3IAlBFndzaiITNgIAIAwgASASKAIAIgxBDnZB/AdxQYAIcmooAgAgASAMQf8BcUECdGooAgBqIBNzIgw2AgAgBiAIIARBMGoiEigCAEEYd2ogBUEcaiIEKAIAIghBCXcgB0EWd3NqIhM2AgAgBiABIBAoAgAiBkEOdkH8B3FBgAhyaigCACABIAZB/wFxQQJ0aigCAGogE3MiEDYCACAEIAggDSgCAEEYd2ogBUEgaiIGKAIAIghBCXcgDkEWd3NqIhM2AgAgBCABIAsoAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogE3MiCzYCACAGIAggESgCAEEYd2ogBUEkaiIEKAIAIghBCXcgDEEWd3NqIhM2AgAgBiABIBIoAgAiBkEOdkH8B3FBgAhyaigCACABIAZB/wFxQQJ0aigCAGogE3MiEjYCACAEIAggFCgCAEEYd2ogBUEoaiIGKAIAIghBCXcgEEEWd3NqIhA2AgAgBCABIA0oAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogEHMiEDYCACAGIAggD0EYd2ogBUEsaiIEKAIAIg1BCXcgC0EWd3NqIgs2AgAgBiABIBEoAgAiEUEOdkH8B3FBgAhyaigCACABIBFB/wFxQQJ0aigCAGogC3MiETYCACAEIA0gCkEYd2ogBUEwaiINKAIAIgZBCXcgEkEWd3NqIgs2AgAgBCABIBQoAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogC3MiFDYCACANIAYgCUEYd2ogBUE0aiIEKAIAIgZBCXcgEEEWd3NqIgs2AgAgDSABIA9BDnZB/AdxQYAIcmooAgAgASAPQf8BcUECdGooAgBqIAtzIg82AgAgBCAGIAdBGHdqIAVBOGoiBSgCACINQQl3IBFBFndzaiIRNgIAIAQgASAKQQ52QfwHcUGACHJqKAIAIAEgCkH/AXFBAnRqKAIAaiARczYCACAFIA0gDkEYd2ogAkGoIGogA0EPaiIEQQJ0aiIDKAIAIgpBCXcgFEEWd3NqIg02AgAgBSABIAlBDnZB/AdxQYAIcmooAgAgASAJQf8BcUECdGooAgBqIA1zNgIAIAMgCiAMQRh3aiACQaggaiAWQQJ0aigCAEEJdyAPQRZ3c2oiBTYCACABIAdB/wFxQQJ0aiEDIAEgB0EOdkH8B3FBgAhyagshCiACQaggaiAEQQJ0aiAKKAIAIAMoAgBqIAVzNgIAIAIgAigCqEBBEGoiBTYCqEAgFUF/aiEVDAELCyACQQA2AqhAIAAgAkGoIGpBhCAQ8gMaIAJBsMAAaiQADwsFIAJBKGogBWoiAUFAayAEIAEoAgAgAUEkaigCAGogAUE4aigCACIDQQ93IANBDXdzIANBCnZzaiABQQRqKAIAIgFBGXcgAUEOd3MgAUEDdnNqajYCACAEQQFqIQQgBUEEaiEFDAELC0G0/ckAQSxByP7JABDOAwAFIAJBKGogBWoiAUFAayAEIAEoAgAgAUEkaigCAGogAUE4aigCACIDQQ93IANBDXdzIANBCnZzaiABQQRqKAIAIgFBGXcgAUEOd3MgAUEDdnNqajYCACAFQQRqIQUgBEEBaiEEDAELAAsAC5grAgJ/IH4jAEGAD2siAiQAIAJBgA5qIAFBgAEQ8gMaQQAhAQNAIAFBgAFHBEAgAkGADmogAWoiAyADKQMAIhtCOIYgG0IohkKAgICAgIDA/wCDhCAbQhiGQoCAgICA4D+DIBtCCIZCgICAgPAfg4SEIBtCCIhCgICA+A+DIBtCGIhCgID8B4OEIBtCKIhCgP4DgyAbQjiIhISENwMAIAFBCGohAQwBCwsgAkHwDWogACkDACIbIAApAyAiHCAAKQMIIh4gACkDKCIfIAApAxAiICAAKQMwIiEgACkDGCIiIAApAzgiIyACKQOADiISQqLcormN84vFwgB8ELwCIAJB4A1qIAIpA/ANIg8gAikD+A0iECAbIBwgHiAfICAgISACKQOIDiIHQs3LvZ+SktGb8QB8ELwCIAJB0A1qIAIpA+ANIgkgAikD6A0iDCAPIBAgGyAcIB4gHyACKQOQDiIXQq/2tOL++b7gtX98ELwCIAJBwA1qIAIpA9ANIgsgAikD2A0iEyAJIAwgDyAQIBsgHCACKQOYDiIIQry3p4zY9PbaaXwQvAIgAkGwDWogAikDwA0iDSACKQPIDSIRIAsgEyAJIAwgDyAQIAIpA6AOIhhCuOqimr/LsKs5fBC8AiACQaANaiACKQOwDSIPIAIpA7gNIhAgDSARIAsgEyAJIAwgAikDqA4iCkKZoJewm77E+NkAfBC8AiACQZANaiACKQOgDSIJIAIpA6gNIgwgDyAQIA0gESALIBMgAikDsA4iFEKbn+X4ytTgn5J/fBC8AiACQYANaiACKQOQDSILIAIpA5gNIhMgCSAMIA8gECANIBEgAikDuA4iHUKYgrbT3dqXjqt/fBC8AiACQfAMaiACKQOADSINIAIpA4gNIhEgCyATIAkgDCAPIBAgAikDwA4iGkLChIyYitPqg1h8ELwCIAJB4AxqIAIpA/AMIg8gAikD+AwiECANIBEgCyATIAkgDCACKQPIDiIWQr7fwauU4NbBEnwQvAIgAkHQDGogAikD4AwiCSACKQPoDCIMIA8gECANIBEgCyATIAIpA9AOIhNCjOWS9+S34ZgkfBC8AiACQcAMaiACKQPQDCILIAIpA9gMIgQgCSAMIA8gECANIBEgAikD2A4iFULi6f6vvbifhtUAfBC8AiACQbAMaiACKQPADCINIAIpA8gMIhEgCyAEIAkgDCAPIBAgAikD4A4iGULvku6Tz66X3/IAfBC8AiACQaAMaiACKQOwDCIFIAIpA7gMIgYgDSARIAsgBCAJIAwgAikD6A4iDkKxrdrY47+s74B/fBC8AiACQZAMaiACKQOgDCIJIAIpA6gMIgwgBSAGIA0gESALIAQgAikD8A4iD0K1pJyu8tSB7pt/fBC8AiACQYAMaiACKQOQDCILIAIpA5gMIgQgCSAMIAUgBiANIBEgAikD+A4iEUKUzaT7zK78zUF8ELwCIAJB8AtqIAcgEiAXIBMgFiARIA8QlgQgAkHgC2ogCCAXIBggGSAVIAIpA/ALIhcgAikD+AsiEBCWBCACQdALaiACKQOADCINIAIpA4gMIhIgCyAEIAkgDCAFIAYgEELSlcX3mbjazWR8ELwCIAJBwAtqIAIpA9ALIgUgAikD2AsiBiANIBIgCyAEIAkgDCAXQuPLvMLj8JHfb3wQvAIgAkGwC2ogAikDwAsiByACKQPICyIIIAUgBiANIBIgCyAEIAIpA+gLIglCtauz3Oi45+APfBC8AiACQaALaiACKQOwCyILIAIpA7gLIgQgByAIIAUgBiANIBIgAikD4AsiEkLluLK9x7mohiR8ELwCIAJBkAtqIAogGCAUIA8gDiASIAkQlgQgAkGAC2ogHSAUIBogECARIAIpA5ALIhggAikDmAsiDBCWBCACQfAKaiACKQOgCyINIAIpA6gLIhQgCyAEIAcgCCAFIAYgDEL1hKzJ9Y3L9C18ELwCIAJB4ApqIAIpA/AKIgUgAikD+AoiBiANIBQgCyAEIAcgCCAYQoPJm/WmlaG6ygB8ELwCIAJB0ApqIAIpA+AKIgcgAikD6AoiCCAFIAYgDSAUIAsgBCACKQOICyILQtT3h+rLu6rY3AB8ELwCIAJBwApqIAIpA9AKIgQgAikD2AoiCiAHIAggBSAGIA0gFCACKQOACyIUQrWnxZiom+L89gB8ELwCIAJBsApqIBYgGiATIAkgFyAUIAsQlgQgAkGgCmogFSATIBkgDCASIAIpA7AKIhogAikDuAoiExCWBCACQZAKaiACKQPACiIWIAIpA8gKIhUgBCAKIAcgCCAFIAYgE0Krv5vzrqqUn5h/fBC8AiACQYAKaiACKQOQCiIFIAIpA5gKIgYgFiAVIAQgCiAHIAggGkKQ5NDt0s3xmKh/fBC8AiACQfAJaiACKQOACiIHIAIpA4gKIgggBSAGIBYgFSAEIAogAikDqAoiDUK/wuzHifnJgbB/fBC8AiACQeAJaiACKQPwCSIEIAIpA/gJIgogByAIIAUgBiAWIBUgAikDoAoiFkLknbz3+/jfrL9/fBC8AiACQdAJaiAOIBkgDyALIBggFiANEJYEIAJBwAlqIBEgDyAQIBMgFCACKQPQCSIZIAIpA9gJIg8QlgQgAkGwCWogAikD4AkiFSACKQPoCSIOIAQgCiAHIAggBSAGIA9Cwp+i7bP+gvBGfBC8AiACQaAJaiACKQOwCSIFIAIpA7gJIgYgFSAOIAQgCiAHIAggGUKlzqqY+ajk01V8ELwCIAJBkAlqIAIpA6AJIgcgAikDqAkiCCAFIAYgFSAOIAQgCiACKQPICSIRQu+EjoCe6pjlBnwQvAIgAkGACWogAikDkAkiBCACKQOYCSIKIAcgCCAFIAYgFSAOIAIpA8AJIhVC8Ny50PCsypQUfBC8AiACQfAIaiAXIBAgCSANIBogFSAREJYEIAJB4AhqIBIgCSAMIA8gFiACKQPwCCIXIAIpA/gIIhAQlgQgAkHQCGogAikDgAkiEiACKQOICSIOIAQgCiAHIAggBSAGIBBC/N/IttTQwtsnfBC8AiACQcAIaiACKQPQCCIFIAIpA9gIIgYgEiAOIAQgCiAHIAggF0KmkpvhhafIjS58ELwCIAJBsAhqIAIpA8AIIgcgAikDyAgiCCAFIAYgEiAOIAQgCiACKQPoCCIJQu3VkNbFv5uWzQB8ELwCIAJBoAhqIAIpA7AIIgQgAikDuAgiCiAHIAggBSAGIBIgDiACKQPgCCISQt/n1uy5ooOc0wB8ELwCIAJBkAhqIBggDCALIBEgGSASIAkQlgQgAkGACGogFCALIBMgECAVIAIpA5AIIhggAikDmAgiDBCWBCACQfAHaiACKQOgCCIUIAIpA6gIIg4gBCAKIAcgCCAFIAYgDELex73dyOqcheUAfBC8AiACQeAHaiACKQPwByIFIAIpA/gHIgYgFCAOIAQgCiAHIAggGEKo5d7js9eCtfYAfBC8AiACQdAHaiACKQPgByIHIAIpA+gHIgggBSAGIBQgDiAEIAogAikDiAgiC0Lm3ba/5KWy4YF/fBC8AiACQcAHaiACKQPQByIEIAIpA9gHIgogByAIIAUgBiAUIA4gAikDgAgiFEK76oik0ZCLuZJ/fBC8AiACQbAHaiAaIBMgDSAJIBcgFCALEJYEIAJBoAdqIBYgDSAPIAwgEiACKQOwByIaIAIpA7gHIhMQlgQgAkGQB2ogAikDwAciFiACKQPIByIOIAQgCiAHIAggBSAGIBNC5IbE55SU+t+if3wQvAIgAkGAB2ogAikDkAciBSACKQOYByIGIBYgDiAEIAogByAIIBpCgeCI4rvJmY2of3wQvAIgAkHwBmogAikDgAciByACKQOIByIIIAUgBiAWIA4gBCAKIAIpA6gHIg1Cka/ih43u4qVCfBC8AiACQeAGaiACKQPwBiIEIAIpA/gGIgogByAIIAUgBiAWIA4gAikDoAciFkKw/NKysLSUtkd8ELwCIAJB0AZqIBkgDyARIAsgGCAWIA0QlgQgAkHABmogFSARIBAgEyAUIAIpA9AGIhkgAikD2AYiDxCWBCACQbAGaiACKQPgBiIVIAIpA+gGIg4gBCAKIAcgCCAFIAYgD0KYpL23nYO6yVF8ELwCIAJBoAZqIAIpA7AGIgUgAikDuAYiBiAVIA4gBCAKIAcgCCAZQpDSlqvFxMHMVnwQvAIgAkGQBmogAikDoAYiByACKQOoBiIIIAUgBiAVIA4gBCAKIAIpA8gGIhFCqsDEu9WwjYd0fBC8AiACQYAGaiACKQOQBiIEIAIpA5gGIgogByAIIAUgBiAVIA4gAikDwAYiFUK4o++Vg46otRB8ELwCIAJB8AVqIBcgECAJIA0gGiAVIBEQlgQgAkHgBWogEiAJIAwgDyAWIAIpA/AFIhcgAikD+AUiEBCWBCACQdAFaiACKQOABiISIAIpA4gGIg4gBCAKIAcgCCAFIAYgEELIocvG66Kw0hl8ELwCIAJBwAVqIAIpA9AFIgUgAikD2AUiBiASIA4gBCAKIAcgCCAXQtPWhoqFgdubHnwQvAIgAkGwBWogAikDwAUiByACKQPIBSIIIAUgBiASIA4gBCAKIAIpA+gFIglCmde7/M3pnaQnfBC8AiACQaAFaiACKQOwBSIEIAIpA7gFIgogByAIIAUgBiASIA4gAikD4AUiEkKoke2M3pav2DR8ELwCIAJBkAVqIBggDCALIBEgGSASIAkQlgQgAkGABWogFCALIBMgECAVIAIpA5AFIhggAikDmAUiDBCWBCACQfAEaiACKQOgBSIUIAIpA6gFIg4gBCAKIAcgCCAFIAYgDELjtKWuvJaDjjl8ELwCIAJB4ARqIAIpA/AEIgUgAikD+AQiBiAUIA4gBCAKIAcgCCAYQsuVhpquyarszgB8ELwCIAJB0ARqIAIpA+AEIgcgAikD6AQiCCAFIAYgFCAOIAQgCiACKQOIBSILQvPGj7v3ybLO2wB8ELwCIAJBwARqIAIpA9AEIgQgAikD2AQiCiAHIAggBSAGIBQgDiACKQOABSIUQqPxyrW9/puX6AB8ELwCIAJBsARqIBogEyANIAkgFyAUIAsQlgQgAkGgBGogFiANIA8gDCASIAIpA7AEIhogAikDuAQiExCWBCACQZAEaiACKQPABCIWIAIpA8gEIg4gBCAKIAcgCCAFIAYgE0L85b7v5d3gx/QAfBC8AiACQYAEaiACKQOQBCIFIAIpA5gEIgYgFiAOIAQgCiAHIAggGkLg3tyY9O3Y0vgAfBC8AiACQfADaiACKQOABCIHIAIpA4gEIgggBSAGIBYgDiAEIAogAikDqAQiDULy1sKPyoKe5IR/fBC8AiACQeADaiACKQPwAyIEIAIpA/gDIgogByAIIAUgBiAWIA4gAikDoAQiFkLs85DTgcHA44x/fBC8AiACQdADaiAZIA8gESALIBggFiANEJYEIAJBwANqIBUgESAQIBMgFCACKQPQAyIZIAIpA9gDIg8QlgQgAkGwA2ogAikD4AMiFSACKQPoAyIOIAQgCiAHIAggBSAGIA9CqLyMm6L/v9+Qf3wQvAIgAkGgA2ogAikDsAMiBSACKQO4AyIGIBUgDiAEIAogByAIIBlC6fuK9L2dm6ikf3wQvAIgAkGQA2ogAikDoAMiByACKQOoAyIIIAUgBiAVIA4gBCAKIAIpA8gDIhFClfKZlvv+6Py+f3wQvAIgAkGAA2ogAikDkAMiBCACKQOYAyIKIAcgCCAFIAYgFSAOIAIpA8ADIhVCq6bJm66e3rhGfBC8AiACQfACaiAXIBAgCSANIBogFSAREJYEIAJB4AJqIBIgCSAMIA8gFiACKQPwAiIOIAIpA/gCIhAQlgQgAkHQAmogAikDgAMiCSACKQOIAyIXIAQgCiAHIAggBSAGIBBCnMOZ0e7Zz5NKfBC8AiACQcACaiACKQPQAiIFIAIpA9gCIgYgCSAXIAQgCiAHIAggDkKHhIOO8piuw1F8ELwCIAJBsAJqIAIpA8ACIhIgAikDyAIiByAFIAYgCSAXIAQgCiACKQPoAiIKQp7Wg+/sup/tanwQvAIgAkGgAmogAikDsAIiBCACKQO4AiIIIBIgByAFIAYgCSAXIAIpA+ACIh1C+KK78/7v0751fBC8AiACQZACaiAYIAwgCyARIBkgHSAKEJYEIAJBgAJqIBQgCyATIBAgFSACKQOQAiIYIAIpA5gCIhQQlgQgAkHwAWogAikDoAIiCSACKQOoAiIMIAQgCCASIAcgBSAGIBRCut/dkKf1mfgGfBC8AiACQeABaiACKQPwASILIAIpA/gBIgUgCSAMIAQgCCASIAcgGEKmsaKW2rjfsQp8ELwCIAJB0AFqIAIpA+ABIgYgAikD6AEiFyALIAUgCSAMIAQgCCACKQOIAiIHQq6b5PfLgOafEXwQvAIgAkHAAWogAikD0AEiBCACKQPYASISIAYgFyALIAUgCSAMIAIpA4ACIghCm47xmNHmwrgbfBC8AiACQbABaiAaIBMgDSAKIA4gCCAHEJYEIAJBoAFqIBYgDSAPIBQgHSACKQOwASINIAIpA7gBIhQQlgQgAkGQAWogAikDwAEiCSACKQPIASIMIAQgEiAGIBcgCyAFIBRChPuRmNL+3e0ofBC8AiACQYABaiACKQOQASILIAIpA5gBIhMgCSAMIAQgEiAGIBcgDUKTyZyGtO+q5TJ8ELwCIAJB8ABqIAIpA4ABIg0gAikDiAEiBSALIBMgCSAMIAQgEiACKQOoASIXQrz9pq6hwa/PPHwQvAIgAkHgAGogAikDcCIEIAIpA3giBiANIAUgCyATIAkgDCACKQOgASIJQsyawODJ+NmOwwB8ELwCIAJB0ABqIBkgDyARIAcgGCAJIBcQlgQgAkFAayAVIBEgECAUIAggAikDUCIRIAIpA1giCRCWBCACQTBqIAIpA2AiDyACKQNoIhAgBCAGIA0gBSALIBMgCUK2hfnZ7Jf14swAfBC8AiACQSBqIAIpAzAiCSACKQM4IgwgDyAQIAQgBiANIAUgEUKq/JXjz7PKv9kAfBC8AiACQRBqIAIpAyAiCyACKQMoIhMgCSAMIA8gECAEIAYgAikDSELs9dvWs/Xb5d8AfBC8AiACIAIpAxAiDSACKQMYIhEgCyATIAkgDCAPIBAgAikDQEKXsJ3SxLGGouwAfBC8AiACKQMAIQ8gAikDCCEQIAAgDCAjfDcDOCAAIBMgIXw3AzAgACARIB98NwMoIAAgCSAifDcDGCAAIAsgIHw3AxAgACANIB58NwMIIAAgECAcfDcDICAAIA8gG3w3AwAgAkGAD2okAAulGQERfyAAKAKAICICQQ9xRQRAIABBgBBqIQQgAkH/A3EiCEEBaiEOIAJBEGpB/wNxIRIgAkHwA2pB/wNxIgNBBGohCSADQQZqIQsgA0ENaiEMAn8gAkGABHEEQCAEIAhBAnRqIgIgAigCACAEIAtBAnRqIgsoAgBBCHdqIAQgDEECdGoiCigCAEEKdyAEIA5BAnRqIggoAgBBF3dzaiIONgIAIAEgDiAAIAQgCUECdGooAgAiCUEOdkH8B3FBgAhyaigCACAAIAlB/wFxQQJ0aigCAGpzNgIAIAggCCgCACADQQJ0IARqIgNBHGoiDCgCAEEId2ogA0E4aiIPKAIAQQp3IAJBCGoiDigCAEEXd3NqIgk2AgAgASAJIAAgA0EUaigCACIFQQ52QfwHcUGACHJqKAIAIAAgBUH/AXFBAnRqKAIAanM2AgQgDiAOKAIAIANBIGoiBSgCAEEId2ogA0E8aiIRKAIAQQp3IAJBDGoiCSgCAEEXd3NqIgc2AgAgASAAIAsoAgAiC0EOdkH8B3FBgAhyaigCACAAIAtB/wFxQQJ0aigCAGogB3M2AgggCSAJKAIAIANBJGoiBygCAEEId2ogAigCAEEKdyACQRBqIgsoAgBBF3dzaiIGNgIAIAEgACAMKAIAIgxBDnZB/AdxQYAIcmooAgAgACAMQf8BcUECdGooAgBqIAZzNgIMIAsgCygCACADQShqIgYoAgBBCHdqIAgoAgBBCncgAkEUaiIMKAIAQRd3c2oiDTYCACABIAAgBSgCACIFQQ52QfwHcUGACHJqKAIAIAAgBUH/AXFBAnRqKAIAaiANczYCECAMIAwoAgAgA0EsaiINKAIAQQh3aiAOKAIAQQp3IAJBGGoiBSgCAEEXd3NqIhA2AgAgASAAIAcoAgAiB0EOdkH8B3FBgAhyaigCACAAIAdB/wFxQQJ0aigCAGogEHM2AhQgBSAFKAIAIANBMGoiECgCAEEId2ogCSgCAEEKdyACQRxqIgMoAgBBF3dzaiIHNgIAIAEgByAAIAYoAgAiBkEOdkH8B3FBgAhyaigCACAAIAZB/wFxQQJ0aigCAGpzNgIYIAMgAygCACAKKAIAQQh3aiALKAIAQQp3IAJBIGoiBygCAEEXd3NqIgY2AgAgASAGIAAgDSgCACINQQ52QfwHcUGACHJqKAIAIAAgDUH/AXFBAnRqKAIAanM2AhwgByAHKAIAIA8oAgBBCHdqIAwoAgBBCncgAkEkaiIGKAIAQRd3c2oiDTYCACABIA0gACAQKAIAIhBBDnZB/AdxQYAIcmooAgAgACAQQf8BcUECdGooAgBqczYCICAGIAYoAgAgESgCAEEId2ogBSgCAEEKdyACQShqIgUoAgBBF3dzaiINNgIAIAEgACAKKAIAIgpBDnZB/AdxQYAIcmooAgAgACAKQf8BcUECdGooAgBqIA1zNgIkIAUgBSgCACACKAIAQQh3aiADKAIAQQp3IAJBLGoiAygCAEEXd3NqIgo2AgAgASAKIAAgDygCACIPQQ52QfwHcUGACHJqKAIAIAAgD0H/AXFBAnRqKAIAanM2AiggAyADKAIAIAgoAgBBCHdqIAcoAgBBCncgAkEwaiIHKAIAQRd3c2oiCjYCACABIAogACARKAIAIg9BDnZB/AdxQYAIcmooAgAgACAPQf8BcUECdGooAgBqczYCLCAHIAcoAgAgDigCAEEId2ogBigCAEEKdyACQTRqIgYoAgBBF3dzaiIKNgIAIAEgCiAAIAIoAgAiD0EOdkH8B3FBgAhyaigCACAAIA9B/wFxQQJ0aigCAGpzNgIwIAYgBigCACAJKAIAQQh3aiAFKAIAQQp3IAJBOGoiBSgCAEEXd3NqIgY2AgAgASAAIAgoAgAiCEEOdkH8B3FBgAhyaigCACAAIAhB/wFxQQJ0aigCAGogBnM2AjQgBSAFKAIAIAsoAgBBCHdqIAMoAgBBCncgAkE8aiICKAIAQRd3c2oiAzYCACABIAMgACAOKAIAIghBDnZB/AdxQYAIcmooAgAgACAIQf8BcUECdGooAgBqczYCOCACIAIoAgAgDCgCAEEId2ogBygCAEEKdyAEIBJBAnRqKAIAQRd3c2oiAjYCACAAIAkoAgAiBEH/AXFBAnRqIQMgACAEQQ52QfwHcUGACHJqDAELIAAgCEECdGoiAiACKAIAIAAgC0ECdGoiCygCAEEYd2ogACAMQQJ0aiIKKAIAQRZ3IAAgDkECdGoiCCgCAEEJd3NqIg42AgAgASAOIAQgACAJQQJ0aigCACIJQQ52QfwHcUGACHJqKAIAIAQgCUH/AXFBAnRqKAIAanM2AgAgCCAIKAIAIANBAnQgAGoiA0EcaiIMKAIAQRh3aiADQThqIg8oAgBBFncgAkEIaiIOKAIAQQl3c2oiCTYCACABIAkgBCADQRRqKAIAIgVBDnZB/AdxQYAIcmooAgAgBCAFQf8BcUECdGooAgBqczYCBCAOIA4oAgAgA0EgaiIFKAIAQRh3aiADQTxqIhEoAgBBFncgAkEMaiIJKAIAQQl3c2oiBzYCACABIAQgCygCACILQQ52QfwHcUGACHJqKAIAIAQgC0H/AXFBAnRqKAIAaiAHczYCCCAJIAkoAgAgA0EkaiIHKAIAQRh3aiACKAIAQRZ3IAJBEGoiCygCAEEJd3NqIgY2AgAgASAEIAwoAgAiDEEOdkH8B3FBgAhyaigCACAEIAxB/wFxQQJ0aigCAGogBnM2AgwgCyALKAIAIANBKGoiBigCAEEYd2ogCCgCAEEWdyACQRRqIgwoAgBBCXdzaiINNgIAIAEgBCAFKAIAIgVBDnZB/AdxQYAIcmooAgAgBCAFQf8BcUECdGooAgBqIA1zNgIQIAwgDCgCACADQSxqIg0oAgBBGHdqIA4oAgBBFncgAkEYaiIFKAIAQQl3c2oiEDYCACABIAQgBygCACIHQQ52QfwHcUGACHJqKAIAIAQgB0H/AXFBAnRqKAIAaiAQczYCFCAFIAUoAgAgA0EwaiIQKAIAQRh3aiAJKAIAQRZ3IAJBHGoiAygCAEEJd3NqIgc2AgAgASAHIAQgBigCACIGQQ52QfwHcUGACHJqKAIAIAQgBkH/AXFBAnRqKAIAanM2AhggAyADKAIAIAooAgBBGHdqIAsoAgBBFncgAkEgaiIHKAIAQQl3c2oiBjYCACABIAYgBCANKAIAIg1BDnZB/AdxQYAIcmooAgAgBCANQf8BcUECdGooAgBqczYCHCAHIAcoAgAgDygCAEEYd2ogDCgCAEEWdyACQSRqIgYoAgBBCXdzaiINNgIAIAEgDSAEIBAoAgAiEEEOdkH8B3FBgAhyaigCACAEIBBB/wFxQQJ0aigCAGpzNgIgIAYgBigCACARKAIAQRh3aiAFKAIAQRZ3IAJBKGoiBSgCAEEJd3NqIg02AgAgASAEIAooAgAiCkEOdkH8B3FBgAhyaigCACAEIApB/wFxQQJ0aigCAGogDXM2AiQgBSAFKAIAIAIoAgBBGHdqIAMoAgBBFncgAkEsaiIDKAIAQQl3c2oiCjYCACABIAogBCAPKAIAIg9BDnZB/AdxQYAIcmooAgAgBCAPQf8BcUECdGooAgBqczYCKCADIAMoAgAgCCgCAEEYd2ogBygCAEEWdyACQTBqIgcoAgBBCXdzaiIKNgIAIAEgCiAEIBEoAgAiD0EOdkH8B3FBgAhyaigCACAEIA9B/wFxQQJ0aigCAGpzNgIsIAcgBygCACAOKAIAQRh3aiAGKAIAQRZ3IAJBNGoiBigCAEEJd3NqIgo2AgAgASAKIAQgAigCACIPQQ52QfwHcUGACHJqKAIAIAQgD0H/AXFBAnRqKAIAanM2AjAgBiAGKAIAIAkoAgBBGHdqIAUoAgBBFncgAkE4aiIFKAIAQQl3c2oiBjYCACABIAQgCCgCACIIQQ52QfwHcUGACHJqKAIAIAQgCEH/AXFBAnRqKAIAaiAGczYCNCAFIAUoAgAgCygCAEEYd2ogAygCAEEWdyACQTxqIgIoAgBBCXdzaiIDNgIAIAEgAyAEIA4oAgAiCEEOdkH8B3FBgAhyaigCACAEIAhB/wFxQQJ0aigCAGpzNgI4IAIgAigCACAMKAIAQRh3aiAHKAIAQRZ3IAAgEkECdGooAgBBCXdzaiICNgIAIAQgCSgCACIIQf8BcUECdGohAyAEIAhBDnZB/AdxQYAIcmoLIQQgASAEKAIAIAMoAgBqIAJzNgI8IAAgACgCgCBBEGo2AoAgDwtBtP3JAEEsQbj+yQAQzgMAC7MSAgF/Gn4jAEGABmsiAyQAIANBsAVqIAEQhgEgA0HYBWogAhCGASADQYgFaiADQbAFaiADQdgFahCPAiADQbgCaiADKQOIBSIEQu3Nh7nWl9IHEJ4CIANB6AFqIAMpA7gCIgVCm/zRkrG0xwJ+Qv////////8HgyIGQu2n1+el45gBEJ4CIANBqAJqIARC2sif49rW7gEQngIgA0GIA2ogAykDkAUiCULtzYe51pfSBxCeAiADQdgBaiAGQoHLtc73xfoGEJ4CIANBuAFqIAMpA4gDIgogAykDqAJ8Ig0gAykD2AF8IgcgBSADKQPoASIIfCIFQjSIIAUgCFStIANB8AFqKQMAIANBwAJqKQMAfHwiEkIMhoR8IgtCm/zRkrG0xwJ+Qv////////8HgyIFQu2n1+el45gBEJ4CIANBmAJqIARCm8rX2f7//wcQngIgA0H4AmogCULayJ/j2tbuARCeAiADQdgDaiADKQOYBSIIQu3Nh7nWl9IHEJ4CIANByAFqIAZC+b3TABCeAiADQagBaiAFQoHLtc73xfoGEJ4CIANBiAFqIAMpA/gCIhQgAykDmAJ8IgwgAykD2AN8Ig4gAykDyAF8Ig8gAykDqAF8IhAgAykDuAEiEyALfCIRQjSIIBEgE1StIANBwAFqKQMAIAsgB1StIAcgDVStIANB4AFqKQMAIA0gClStIANBkANqKQMAIANBsAJqKQMAfHx8fCASQjSIfHx8fCIVQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0GIAmogBEL/////////BxCeAiADQegCaiAJQpvK19n+//8HEJ4CIANByANqIAhC2sif49rW7gEQngIgA0GoBGogAykDoAUiB0LtzYe51pfSBxCeAiADQZgBaiAFQvm90wAQngIgA0H4AGogDUKBy7XO98X6BhCeAiADQdgAaiADKQPoAiIZIAMpA4gCfCIKIAMpA8gDfCISIAMpA6gEfCITIAMpA5gBfCIRIAMpA3h8IhYgAykDiAEiFyALfCIYQjSIIBggF1StIANBkAFqKQMAIAsgEFStIBAgD1StIANBsAFqKQMAIA8gDlStIANB0AFqKQMAIA4gDFStIANB4ANqKQMAIAwgFFStIANBgANqKQMAIANBoAJqKQMAfHx8fHx8fHwgFUI0iHx8fHwiGkIMhoR8IgxCm/zRkrG0xwJ+Qv////////8HgyILQu2n1+el45gBEJ4CIANB+AFqIARC////////AxCeAiADQdgCaiAJQv////////8HEJ4CIANBuANqIAhCm8rX2f7//wcQngIgA0GYBGogB0LayJ/j2tbuARCeAiADQfgEaiADKQOoBSIEQu3Nh7nWl9IHEJ4CIANB6ABqIA1C+b3TABCeAiADQcgAaiALQoHLtc73xfoGEJ4CIANBKGogAykD2AIiGyADKQP4AXwiDiADKQO4A3wiDyADKQOYBHwiECADKQP4BHwiFCAGQiyGfCIVIAMpA2h8IhcgAykDSHwiGCADKQNYIhwgDHwiHUI0iCAdIBxUrSADQeAAaikDACAMIBZUrSAWIBFUrSADQYABaikDACARIBNUrSADQaABaikDACATIBJUrSADQbAEaikDACASIApUrSADQdADaikDACAKIBlUrSADQfACaikDACADQZACaikDAHx8fHx8fHx8fHwgGkI0iHx8fHwiEUIMhoR8IgpCm/zRkrG0xwJ+Qv////////8HgyIMQu2n1+el45gBEJ4CIANByAJqIAlC////////AxCeAiADQagDaiAIQv////////8HEJ4CIANBiARqIAdCm8rX2f7//wcQngIgA0HoBGogBELayJ/j2tbuARCeAiADQThqIAtC+b3TABCeAiADQRhqIAxCgcu1zvfF+gYQngIgA0GYA2ogCEL///////8DEJ4CIANB+ANqIAdC/////////wcQngIgA0HYBGogBEKbytfZ/v//BxCeAiADQQhqIAxC+b3TABCeAiADQegDaiAHQv///////wMQngIgA0HIBGogBEL/////////BxCeAiADQbgEaiAEQv///////wMQngIgAyADKQOoAyIWIAMpA8gCfCIEIAMpA4gEfCIJIAMpA+gEfCIIIAVCLIZ8IgcgAykDOHwiEiADKQMYfCITIAMpAygiGSAKfCIaQjSIIBogGVStIANBMGopAwAgCiAYVK0gGCAXVK0gA0HQAGopAwAgFyAVVK0gA0HwAGopAwAgFSAUVK0gFCAQVK0gA0GABWopAwAgECAPVK0gA0GgBGopAwAgDyAOVK0gA0HAA2opAwAgDiAbVK0gA0HgAmopAwAgA0GAAmopAwB8fHx8fHx8fCAGQhSIfHx8fHx8IBFCNIh8fHx8IhFCDIaEfCIGQv////////8HgzcD2AUgAyADKQP4AyIUIAMpA5gDfCIOIAMpA9gEfCIPIA1CLIZ8IhAgAykDCHwiCiAGIBNUrSATIBJUrSADQSBqKQMAIBIgB1StIANBQGspAwAgByAIVK0gCCAJVK0gA0HwBGopAwAgCSAEVK0gA0GQBGopAwAgBCAWVK0gA0GwA2opAwAgA0HQAmopAwB8fHx8fHwgBUIUiHx8fHx8fCARQjSIfHwiBUIMhiAGQjSIhHwiBEL/////////B4M3A+AFIAMgAykDyAQiCCADKQPoA3wiBiALQiyGfCIJIAQgClStIAogEFStIANBEGopAwAgECAPVK0gDyAOVK0gA0HgBGopAwAgDiAUVK0gA0GABGopAwAgA0GgA2opAwB8fHx8IA1CFIh8fHx8IAVCNIh8fCINQgyGIARCNIiEfCIEQv////////8HgzcD6AUgAyAMQiyGIgcgAykDuAR8IgUgBCAJVK0gCSAGVK0gBiAIVK0gA0HQBGopAwAgA0HwA2opAwB8fCALQhSIfHwgDUI0iHx8IgZCDIYgBEI0iIR8IgRC/////////weDNwPwBSADIAQgBVStIAUgB1StIANBwARqKQMAIAxCFIh8fCAGQjSIfHxCDIYgBEI0iIQ3A/gFIANBsAVqIANB2AVqQaC9xAAQoAEgACADQbAFahBxIANBgAZqJAALsxICAX8afiMAQYAGayIDJAAgA0GwBWogARCHASADQdgFaiACEIcBIANBiAVqIANBsAVqIANB2AVqEJICIANBuAJqIAMpA4gFIgRC7c2HudaX0gcQngIgA0HoAWogAykDuAIiBUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GoAmogBELayJ/j2tbuARCeAiADQYgDaiADKQOQBSIJQu3Nh7nWl9IHEJ4CIANB2AFqIAZCgcu1zvfF+gYQngIgA0G4AWogAykDiAMiCiADKQOoAnwiDSADKQPYAXwiByAFIAMpA+gBIgh8IgVCNIggBSAIVK0gA0HwAWopAwAgA0HAAmopAwB8fCISQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GYAmogBEKbytfZ/v//BxCeAiADQfgCaiAJQtrIn+Pa1u4BEJ4CIANB2ANqIAMpA5gFIghC7c2HudaX0gcQngIgA0HIAWogBkL5vdMAEJ4CIANBqAFqIAVCgcu1zvfF+gYQngIgA0GIAWogAykD+AIiFCADKQOYAnwiDCADKQPYA3wiDiADKQPIAXwiDyADKQOoAXwiECADKQO4ASITIAt8IhFCNIggESATVK0gA0HAAWopAwAgCyAHVK0gByANVK0gA0HgAWopAwAgDSAKVK0gA0GQA2opAwAgA0GwAmopAwB8fHx8IBJCNIh8fHx8IhVCDIaEfCILQpv80ZKxtMcCfkL/////////B4MiDULtp9fnpeOYARCeAiADQYgCaiAEQv////////8HEJ4CIANB6AJqIAlCm8rX2f7//wcQngIgA0HIA2ogCELayJ/j2tbuARCeAiADQagEaiADKQOgBSIHQu3Nh7nWl9IHEJ4CIANBmAFqIAVC+b3TABCeAiADQfgAaiANQoHLtc73xfoGEJ4CIANB2ABqIAMpA+gCIhkgAykDiAJ8IgogAykDyAN8IhIgAykDqAR8IhMgAykDmAF8IhEgAykDeHwiFiADKQOIASIXIAt8IhhCNIggGCAXVK0gA0GQAWopAwAgCyAQVK0gECAPVK0gA0GwAWopAwAgDyAOVK0gA0HQAWopAwAgDiAMVK0gA0HgA2opAwAgDCAUVK0gA0GAA2opAwAgA0GgAmopAwB8fHx8fHx8fCAVQjSIfHx8fCIaQgyGhHwiDEKb/NGSsbTHAn5C/////////weDIgtC7afX56XjmAEQngIgA0H4AWogBEL///////8DEJ4CIANB2AJqIAlC/////////wcQngIgA0G4A2ogCEKbytfZ/v//BxCeAiADQZgEaiAHQtrIn+Pa1u4BEJ4CIANB+ARqIAMpA6gFIgRC7c2HudaX0gcQngIgA0HoAGogDUL5vdMAEJ4CIANByABqIAtCgcu1zvfF+gYQngIgA0EoaiADKQPYAiIbIAMpA/gBfCIOIAMpA7gDfCIPIAMpA5gEfCIQIAMpA/gEfCIUIAZCLIZ8IhUgAykDaHwiFyADKQNIfCIYIAMpA1giHCAMfCIdQjSIIB0gHFStIANB4ABqKQMAIAwgFlStIBYgEVStIANBgAFqKQMAIBEgE1StIANBoAFqKQMAIBMgElStIANBsARqKQMAIBIgClStIANB0ANqKQMAIAogGVStIANB8AJqKQMAIANBkAJqKQMAfHx8fHx8fHx8fCAaQjSIfHx8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0HIAmogCUL///////8DEJ4CIANBqANqIAhC/////////wcQngIgA0GIBGogB0KbytfZ/v//BxCeAiADQegEaiAEQtrIn+Pa1u4BEJ4CIANBOGogC0L5vdMAEJ4CIANBGGogDEKBy7XO98X6BhCeAiADQZgDaiAIQv///////wMQngIgA0H4A2ogB0L/////////BxCeAiADQdgEaiAEQpvK19n+//8HEJ4CIANBCGogDEL5vdMAEJ4CIANB6ANqIAdC////////AxCeAiADQcgEaiAEQv////////8HEJ4CIANBuARqIARC////////AxCeAiADIAMpA6gDIhYgAykDyAJ8IgQgAykDiAR8IgkgAykD6AR8IgggBUIshnwiByADKQM4fCISIAMpAxh8IhMgAykDKCIZIAp8IhpCNIggGiAZVK0gA0EwaikDACAKIBhUrSAYIBdUrSADQdAAaikDACAXIBVUrSADQfAAaikDACAVIBRUrSAUIBBUrSADQYAFaikDACAQIA9UrSADQaAEaikDACAPIA5UrSADQcADaikDACAOIBtUrSADQeACaikDACADQYACaikDAHx8fHx8fHx8IAZCFIh8fHx8fHwgEUI0iHx8fHwiEUIMhoR8IgZC/////////weDNwPYBSADIAMpA/gDIhQgAykDmAN8Ig4gAykD2AR8Ig8gDUIshnwiECADKQMIfCIKIAYgE1StIBMgElStIANBIGopAwAgEiAHVK0gA0FAaykDACAHIAhUrSAIIAlUrSADQfAEaikDACAJIARUrSADQZAEaikDACAEIBZUrSADQbADaikDACADQdACaikDAHx8fHx8fCAFQhSIfHx8fHx8IBFCNIh8fCIFQgyGIAZCNIiEfCIEQv////////8HgzcD4AUgAyADKQPIBCIIIAMpA+gDfCIGIAtCLIZ8IgkgBCAKVK0gCiAQVK0gA0EQaikDACAQIA9UrSAPIA5UrSADQeAEaikDACAOIBRUrSADQYAEaikDACADQaADaikDAHx8fHwgDUIUiHx8fHwgBUI0iHx8Ig1CDIYgBEI0iIR8IgRC/////////weDNwPoBSADIAxCLIYiByADKQO4BHwiBSAEIAlUrSAJIAZUrSAGIAhUrSADQdAEaikDACADQfADaikDAHx8IAtCFIh8fCANQjSIfHwiBkIMhiAEQjSIhHwiBEL/////////B4M3A/AFIAMgBCAFVK0gBSAHVK0gA0HABGopAwAgDEIUiHx8IAZCNIh8fEIMhiAEQjSIhDcD+AUgA0GwBWogA0HYBWpB+O7IABChASAAIANBsAVqEHEgA0GABmokAAuTEgIBfxp+IwBBgAZrIgIkACACQYgFaiABEIYBIAJB+AFqIAIpA4gFIgNC7c2HudaX0gcQngIgAkHoAWogAikD+AEiBEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgAkGIAmogA0LayJ/j2tbuARCeAiACQcgCaiACKQOQBSIIQu3Nh7nWl9IHEJ4CIAJB2AFqIAVCgcu1zvfF+gYQngIgAkHIAWogAikDyAIiCSACKQOIAnwiDCACKQPYAXwiBiAEIAIpA+gBIgd8IgRCNIggBCAHVK0gAkHwAWopAwAgAkGAAmopAwB8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgAkGYAmogA0KbytfZ/v//BxCeAiACQdgCaiAIQtrIn+Pa1u4BEJ4CIAJBmANqIAIpA5gFIgdC7c2HudaX0gcQngIgAkGYAWogBUL5vdMAEJ4CIAJBuAFqIARCgcu1zvfF+gYQngIgAkGIAWogAikD2AIiEyACKQOYAnwiCyACKQOYA3wiDSACKQOYAXwiDiACKQO4AXwiDyACKQPIASISIAp8IhBCNIggECASVK0gAkHQAWopAwAgCiAGVK0gBiAMVK0gAkHgAWopAwAgDCAJVK0gAkHQAmopAwAgAkGQAmopAwB8fHx8IBFCNIh8fHx8IhRCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiACQagCaiADQv////////8HEJ4CIAJB6AJqIAhCm8rX2f7//wcQngIgAkGoA2ogB0LayJ/j2tbuARCeAiACQegDaiACKQOgBSIGQu3Nh7nWl9IHEJ4CIAJBqAFqIARC+b3TABCeAiACQfgAaiAMQoHLtc73xfoGEJ4CIAJB6ABqIAIpA+gCIhggAikDqAJ8IgkgAikDqAN8IhEgAikD6AN8IhIgAikDqAF8IhAgAikDeHwiFSACKQOIASIWIAp8IhdCNIggFyAWVK0gAkGQAWopAwAgCiAPVK0gDyAOVK0gAkHAAWopAwAgDiANVK0gAkGgAWopAwAgDSALVK0gAkGgA2opAwAgCyATVK0gAkHgAmopAwAgAkGgAmopAwB8fHx8fHx8fCAUQjSIfHx8fCIZQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgpC7afX56XjmAEQngIgAkG4AmogA0L///////8DEJ4CIAJB+AJqIAhC/////////wcQngIgAkG4A2ogB0KbytfZ/v//BxCeAiACQfgDaiAGQtrIn+Pa1u4BEJ4CIAJBuARqIAIpA6gFIgNC7c2HudaX0gcQngIgAkE4aiAMQvm90wAQngIgAkHYAGogCkKBy7XO98X6BhCeAiACQShqIAIpA/gCIhogAikDuAJ8Ig0gAikDuAN8Ig4gAikD+AN8Ig8gAikDuAR8IhMgBUIshnwiFCACKQM4fCIWIAIpA1h8IhcgAikDaCIbIAt8IhxCNIggHCAbVK0gAkHwAGopAwAgCyAVVK0gFSAQVK0gAkGAAWopAwAgECASVK0gAkGwAWopAwAgEiARVK0gAkHwA2opAwAgESAJVK0gAkGwA2opAwAgCSAYVK0gAkHwAmopAwAgAkGwAmopAwB8fHx8fHx8fHx8IBlCNIh8fHx8IhBCDIaEfCIJQpv80ZKxtMcCfkL/////////B4MiC0Ltp9fnpeOYARCeAiACQYgDaiAIQv///////wMQngIgAkHIA2ogB0L/////////BxCeAiACQYgEaiAGQpvK19n+//8HEJ4CIAJByARqIANC2sif49rW7gEQngIgAkHIAGogCkL5vdMAEJ4CIAJBGGogC0KBy7XO98X6BhCeAiACQdgDaiAHQv///////wMQngIgAkGYBGogBkL/////////BxCeAiACQdgEaiADQpvK19n+//8HEJ4CIAJBCGogC0L5vdMAEJ4CIAJBqARqIAZC////////AxCeAiACQegEaiADQv////////8HEJ4CIAJB+ARqIANC////////AxCeAiACIAIpA8gDIhUgAikDiAN8IgMgAikDiAR8IgggAikDyAR8IgcgBEIshnwiBiACKQNIfCIRIAIpAxh8IhIgAikDKCIYIAl8IhlCNIggGSAYVK0gAkEwaikDACAJIBdUrSAXIBZUrSACQeAAaikDACAWIBRUrSACQUBrKQMAIBQgE1StIBMgD1StIAJBwARqKQMAIA8gDlStIAJBgARqKQMAIA4gDVStIAJBwANqKQMAIA0gGlStIAJBgANqKQMAIAJBwAJqKQMAfHx8fHx8fHwgBUIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBUL/////////B4M3A9gFIAIgAikDmAQiEyACKQPYA3wiDSACKQPYBHwiDiAMQiyGfCIPIAIpAwh8IgkgBSASVK0gEiARVK0gAkEgaikDACARIAZUrSACQdAAaikDACAGIAdUrSAHIAhUrSACQdAEaikDACAIIANUrSACQZAEaikDACADIBVUrSACQdADaikDACACQZADaikDAHx8fHx8fCAEQhSIfHx8fHx8IBBCNIh8fCIEQgyGIAVCNIiEfCIDQv////////8HgzcD4AUgAiACKQPoBCIHIAIpA6gEfCIFIApCLIZ8IgggAyAJVK0gCSAPVK0gAkEQaikDACAPIA5UrSAOIA1UrSACQeAEaikDACANIBNUrSACQaAEaikDACACQeADaikDAHx8fHwgDEIUiHx8fHwgBEI0iHx8IgxCDIYgA0I0iIR8IgNC/////////weDNwPoBSACIAtCLIYiBiACKQP4BHwiBCADIAhUrSAIIAVUrSAFIAdUrSACQfAEaikDACACQbAEaikDAHx8IApCFIh8fCAMQjSIfHwiBUIMhiADQjSIhHwiA0L/////////B4M3A/AFIAIgAyAEVK0gBCAGVK0gAkGABWopAwAgC0IUiHx8IAVCNIh8fEIMhiADQjSIhDcD+AUgAkGwBWogAkHYBWpBoL3EABCgASAAIAJBsAVqEHEgAkGABmokAAuTEgIBfxp+IwBBgAZrIgIkACACQYgFaiABEIcBIAJB+AFqIAIpA4gFIgNC7c2HudaX0gcQngIgAkHoAWogAikD+AEiBEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgAkGIAmogA0LayJ/j2tbuARCeAiACQcgCaiACKQOQBSIIQu3Nh7nWl9IHEJ4CIAJB2AFqIAVCgcu1zvfF+gYQngIgAkHIAWogAikDyAIiCSACKQOIAnwiDCACKQPYAXwiBiAEIAIpA+gBIgd8IgRCNIggBCAHVK0gAkHwAWopAwAgAkGAAmopAwB8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgAkGYAmogA0KbytfZ/v//BxCeAiACQdgCaiAIQtrIn+Pa1u4BEJ4CIAJBmANqIAIpA5gFIgdC7c2HudaX0gcQngIgAkGYAWogBUL5vdMAEJ4CIAJBuAFqIARCgcu1zvfF+gYQngIgAkGIAWogAikD2AIiEyACKQOYAnwiCyACKQOYA3wiDSACKQOYAXwiDiACKQO4AXwiDyACKQPIASISIAp8IhBCNIggECASVK0gAkHQAWopAwAgCiAGVK0gBiAMVK0gAkHgAWopAwAgDCAJVK0gAkHQAmopAwAgAkGQAmopAwB8fHx8IBFCNIh8fHx8IhRCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiACQagCaiADQv////////8HEJ4CIAJB6AJqIAhCm8rX2f7//wcQngIgAkGoA2ogB0LayJ/j2tbuARCeAiACQegDaiACKQOgBSIGQu3Nh7nWl9IHEJ4CIAJBqAFqIARC+b3TABCeAiACQfgAaiAMQoHLtc73xfoGEJ4CIAJB6ABqIAIpA+gCIhggAikDqAJ8IgkgAikDqAN8IhEgAikD6AN8IhIgAikDqAF8IhAgAikDeHwiFSACKQOIASIWIAp8IhdCNIggFyAWVK0gAkGQAWopAwAgCiAPVK0gDyAOVK0gAkHAAWopAwAgDiANVK0gAkGgAWopAwAgDSALVK0gAkGgA2opAwAgCyATVK0gAkHgAmopAwAgAkGgAmopAwB8fHx8fHx8fCAUQjSIfHx8fCIZQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgpC7afX56XjmAEQngIgAkG4AmogA0L///////8DEJ4CIAJB+AJqIAhC/////////wcQngIgAkG4A2ogB0KbytfZ/v//BxCeAiACQfgDaiAGQtrIn+Pa1u4BEJ4CIAJBuARqIAIpA6gFIgNC7c2HudaX0gcQngIgAkE4aiAMQvm90wAQngIgAkHYAGogCkKBy7XO98X6BhCeAiACQShqIAIpA/gCIhogAikDuAJ8Ig0gAikDuAN8Ig4gAikD+AN8Ig8gAikDuAR8IhMgBUIshnwiFCACKQM4fCIWIAIpA1h8IhcgAikDaCIbIAt8IhxCNIggHCAbVK0gAkHwAGopAwAgCyAVVK0gFSAQVK0gAkGAAWopAwAgECASVK0gAkGwAWopAwAgEiARVK0gAkHwA2opAwAgESAJVK0gAkGwA2opAwAgCSAYVK0gAkHwAmopAwAgAkGwAmopAwB8fHx8fHx8fHx8IBlCNIh8fHx8IhBCDIaEfCIJQpv80ZKxtMcCfkL/////////B4MiC0Ltp9fnpeOYARCeAiACQYgDaiAIQv///////wMQngIgAkHIA2ogB0L/////////BxCeAiACQYgEaiAGQpvK19n+//8HEJ4CIAJByARqIANC2sif49rW7gEQngIgAkHIAGogCkL5vdMAEJ4CIAJBGGogC0KBy7XO98X6BhCeAiACQdgDaiAHQv///////wMQngIgAkGYBGogBkL/////////BxCeAiACQdgEaiADQpvK19n+//8HEJ4CIAJBCGogC0L5vdMAEJ4CIAJBqARqIAZC////////AxCeAiACQegEaiADQv////////8HEJ4CIAJB+ARqIANC////////AxCeAiACIAIpA8gDIhUgAikDiAN8IgMgAikDiAR8IgggAikDyAR8IgcgBEIshnwiBiACKQNIfCIRIAIpAxh8IhIgAikDKCIYIAl8IhlCNIggGSAYVK0gAkEwaikDACAJIBdUrSAXIBZUrSACQeAAaikDACAWIBRUrSACQUBrKQMAIBQgE1StIBMgD1StIAJBwARqKQMAIA8gDlStIAJBgARqKQMAIA4gDVStIAJBwANqKQMAIA0gGlStIAJBgANqKQMAIAJBwAJqKQMAfHx8fHx8fHwgBUIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBUL/////////B4M3A9gFIAIgAikDmAQiEyACKQPYA3wiDSACKQPYBHwiDiAMQiyGfCIPIAIpAwh8IgkgBSASVK0gEiARVK0gAkEgaikDACARIAZUrSACQdAAaikDACAGIAdUrSAHIAhUrSACQdAEaikDACAIIANUrSACQZAEaikDACADIBVUrSACQdADaikDACACQZADaikDAHx8fHx8fCAEQhSIfHx8fHx8IBBCNIh8fCIEQgyGIAVCNIiEfCIDQv////////8HgzcD4AUgAiACKQPoBCIHIAIpA6gEfCIFIApCLIZ8IgggAyAJVK0gCSAPVK0gAkEQaikDACAPIA5UrSAOIA1UrSACQeAEaikDACANIBNUrSACQaAEaikDACACQeADaikDAHx8fHwgDEIUiHx8fHwgBEI0iHx8IgxCDIYgA0I0iIR8IgNC/////////weDNwPoBSACIAtCLIYiBiACKQP4BHwiBCADIAhUrSAIIAVUrSAFIAdUrSACQfAEaikDACACQbAEaikDAHx8IApCFIh8fCAMQjSIfHwiBUIMhiADQjSIhHwiA0L/////////B4M3A/AFIAIgAyAEVK0gBCAGVK0gAkGABWopAwAgC0IUiHx8IAVCNIh8fEIMhiADQjSIhDcD+AUgAkGwBWogAkHYBWpB+O7IABChASAAIAJBsAVqEHEgAkGABmokAAvkEAIBfx5+IwBBsAVrIgMkACADQfgBaiACKQMAIgkgASkDACIEEJ4CIANB6AFqIAMpA/gBIgxCm/zRkrG0xwJ+Qv////////8HgyIFQu2n1+el45gBEJ4CIANBiAJqIAIpAwgiDSAEEJ4CIANByAJqIAEpAwgiBiAJEJ4CIANB2AFqIAVCgcu1zvfF+gYQngIgA0HIAWogAykDyAIiDyADKQOIAnwiEyADKQPYAXwiDiAMIAMpA+gBIgp8IgxCNIggDCAKVK0gA0HwAWopAwAgA0GAAmopAwB8fCIRQgyGhHwiB0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GIA2ogBiANEJ4CIANBmAJqIAIpAxAiCiAEEJ4CIANB2AJqIAEpAxAiECAJEJ4CIANBmAFqIAVC+b3TABCeAiADQbgBaiAMQoHLtc73xfoGEJ4CIANBiAFqIAMpA5gCIhYgAykDiAN8IhQgAykD2AJ8IgggAykDmAF8IgsgAykDuAF8IhIgAykDyAEiFSAHfCIXQjSIIBcgFVStIANB0AFqKQMAIAcgDlStIA4gE1StIANB4AFqKQMAIBMgD1StIANB0AJqKQMAIANBkAJqKQMAfHx8fCARQjSIfHx8fCIYQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIhNC7afX56XjmAEQngIgA0HIA2ogCiAGEJ4CIANBmANqIBAgDRCeAiADQagCaiACKQMYIg4gBBCeAiADQegCaiABKQMYIgcgCRCeAiADQagBaiAMQvm90wAQngIgA0H4AGogE0KBy7XO98X6BhCeAiADQegAaiADKQOYAyIeIAMpA8gDfCIRIAMpA6gCfCIVIAMpA+gCfCIXIAMpA6gBfCIbIAMpA3h8IhwgAykDiAEiGSAPfCIaQjSIIBogGVStIANBkAFqKQMAIA8gElStIBIgC1StIANBwAFqKQMAIAsgCFStIANBoAFqKQMAIAggFFStIANB4AJqKQMAIBQgFlStIANBoAJqKQMAIANBkANqKQMAfHx8fHx8fHwgGEI0iHx8fHwiH0IMhoR8IgtCm/zRkrG0xwJ+Qv////////8HgyIUQu2n1+el45gBEJ4CIANB+ANqIBAgChCeAiADQdgDaiAOIAYQngIgA0GoA2ogByANEJ4CIANBuAJqIAIpAyAiCCAEEJ4CIANB+AJqIAEpAyAiBCAJEJ4CIANBOGogE0L5vdMAEJ4CIANB2ABqIBRCgcu1zvfF+gYQngIgA0EoaiADKQPYAyIgIAMpA/gDfCISIAVCLIZ8Ig8gAykDqAN8IhYgAykDuAJ8IhggAykD+AJ8IhkgAykDOHwiGiADKQNYfCIdIAMpA2giCSALfCIhQjSIICEgCVStIANB8ABqKQMAIAsgHFStIBwgG1StIANBgAFqKQMAIBsgF1StIANBsAFqKQMAIBcgFVStIANB8AJqKQMAIBUgEVStIANBsAJqKQMAIBEgHlStIANBoANqKQMAIANB0ANqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIRQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIglC7afX56XjmAEQngIgA0GoBGogDiAQEJ4CIANBiARqIAcgChCeAiADQegDaiAIIAYQngIgA0G4A2ogBCANEJ4CIANByABqIBRC+b3TABCeAiADQRhqIAlCgcu1zvfF+gYQngIgA0HIBGogByAOEJ4CIANBuARqIAggEBCeAiADQZgEaiAEIAoQngIgA0EIaiAJQvm90wAQngIgA0HoBGogCCAHEJ4CIANB2ARqIAQgDhCeAiADQfgEaiAEIAgQngIgAyADKQOIBCIVIAMpA6gEfCIEIAMpA+gDfCINIAMpA7gDfCIGIAxCLIZ8IgogAykDSHwiECADKQMYfCIOIAMpAygiByALfCIIQjSIIAggB1StIANBMGopAwAgCyAdVK0gHSAaVK0gA0HgAGopAwAgGiAZVK0gA0FAaykDACAZIBhUrSADQYADaikDACAYIBZUrSADQcACaikDACAWIA9UrSADQbADaikDACAPIBJUrSASICBUrSADQeADaikDACADQYAEaikDAHx8IAVCFIh8fHx8fHx8fHx8fHwgEUI0iHx8fHwiD0IMhoR8IgVC/////////weDNwOIBSADIAMpA7gEIhEgAykDyAR8IgcgAykDmAR8IgggE0IshnwiCyADKQMIfCISIAUgDlStIA4gEFStIANBIGopAwAgECAKVK0gA0HQAGopAwAgCiAGVK0gBiANVK0gA0HAA2opAwAgDSAEVK0gA0HwA2opAwAgBCAVVK0gA0GQBGopAwAgA0GwBGopAwB8fHx8fHwgDEIUiHx8fHx8fCAPQjSIfHwiBkIMhiAFQjSIhHwiBEL/////////B4M3A5AFIAMgAykD2AQiDCADKQPoBHwiBSAUQiyGfCINIAQgElStIBIgC1StIANBEGopAwAgCyAIVK0gCCAHVK0gA0GgBGopAwAgByARVK0gA0HABGopAwAgA0HQBGopAwB8fHx8IBNCFIh8fHx8IAZCNIh8fCIKQgyGIARCNIiEfCIEQv////////8HgzcDmAUgAyAJQiyGIhAgAykD+AR8IgYgBCANVK0gDSAFVK0gBSAMVK0gA0HgBGopAwAgA0HwBGopAwB8fCAUQhSIfHwgCkI0iHx8IgVCDIYgBEI0iIR8IgRC/////////weDNwOgBSADIAQgBlStIAYgEFStIANBgAVqKQMAIAlCFIh8fCAFQjSIfHxCDIYgBEI0iIQ3A6gFIAAgA0GIBWpBgLzEABCgASADQbAFaiQAC+QQAgF/Hn4jAEGwBWsiAyQAIANB+AFqIAIpAwAiCSABKQMAIgQQngIgA0HoAWogAykD+AEiDEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GIAmogAikDCCINIAQQngIgA0HIAmogASkDCCIGIAkQngIgA0HYAWogBUKBy7XO98X6BhCeAiADQcgBaiADKQPIAiIPIAMpA4gCfCITIAMpA9gBfCIOIAwgAykD6AEiCnwiDEI0iCAMIApUrSADQfABaikDACADQYACaikDAHx8IhFCDIaEfCIHQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYgDaiAGIA0QngIgA0GYAmogAikDECIKIAQQngIgA0HYAmogASkDECIQIAkQngIgA0GYAWogBUL5vdMAEJ4CIANBuAFqIAxCgcu1zvfF+gYQngIgA0GIAWogAykDmAIiFiADKQOIA3wiFCADKQPYAnwiCCADKQOYAXwiCyADKQO4AXwiEiADKQPIASIVIAd8IhdCNIggFyAVVK0gA0HQAWopAwAgByAOVK0gDiATVK0gA0HgAWopAwAgEyAPVK0gA0HQAmopAwAgA0GQAmopAwB8fHx8IBFCNIh8fHx8IhhCDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiE0Ltp9fnpeOYARCeAiADQcgDaiAKIAYQngIgA0GYA2ogECANEJ4CIANBqAJqIAIpAxgiDiAEEJ4CIANB6AJqIAEpAxgiByAJEJ4CIANBqAFqIAxC+b3TABCeAiADQfgAaiATQoHLtc73xfoGEJ4CIANB6ABqIAMpA5gDIh4gAykDyAN8IhEgAykDqAJ8IhUgAykD6AJ8IhcgAykDqAF8IhsgAykDeHwiHCADKQOIASIZIA98IhpCNIggGiAZVK0gA0GQAWopAwAgDyASVK0gEiALVK0gA0HAAWopAwAgCyAIVK0gA0GgAWopAwAgCCAUVK0gA0HgAmopAwAgFCAWVK0gA0GgAmopAwAgA0GQA2opAwB8fHx8fHx8fCAYQjSIfHx8fCIfQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIhRC7afX56XjmAEQngIgA0H4A2ogECAKEJ4CIANB2ANqIA4gBhCeAiADQagDaiAHIA0QngIgA0G4AmogAikDICIIIAQQngIgA0H4AmogASkDICIEIAkQngIgA0E4aiATQvm90wAQngIgA0HYAGogFEKBy7XO98X6BhCeAiADQShqIAMpA9gDIiAgAykD+AN8IhIgBUIshnwiDyADKQOoA3wiFiADKQO4AnwiGCADKQP4AnwiGSADKQM4fCIaIAMpA1h8Ih0gAykDaCIJIAt8IiFCNIggISAJVK0gA0HwAGopAwAgCyAcVK0gHCAbVK0gA0GAAWopAwAgGyAXVK0gA0GwAWopAwAgFyAVVK0gA0HwAmopAwAgFSARVK0gA0GwAmopAwAgESAeVK0gA0GgA2opAwAgA0HQA2opAwB8fHx8fHx8fHx8IB9CNIh8fHx8IhFCDIaEfCILQpv80ZKxtMcCfkL/////////B4MiCULtp9fnpeOYARCeAiADQagEaiAOIBAQngIgA0GIBGogByAKEJ4CIANB6ANqIAggBhCeAiADQbgDaiAEIA0QngIgA0HIAGogFEL5vdMAEJ4CIANBGGogCUKBy7XO98X6BhCeAiADQcgEaiAHIA4QngIgA0G4BGogCCAQEJ4CIANBmARqIAQgChCeAiADQQhqIAlC+b3TABCeAiADQegEaiAIIAcQngIgA0HYBGogBCAOEJ4CIANB+ARqIAQgCBCeAiADIAMpA4gEIhUgAykDqAR8IgQgAykD6AN8Ig0gAykDuAN8IgYgDEIshnwiCiADKQNIfCIQIAMpAxh8Ig4gAykDKCIHIAt8IghCNIggCCAHVK0gA0EwaikDACALIB1UrSAdIBpUrSADQeAAaikDACAaIBlUrSADQUBrKQMAIBkgGFStIANBgANqKQMAIBggFlStIANBwAJqKQMAIBYgD1StIANBsANqKQMAIA8gElStIBIgIFStIANB4ANqKQMAIANBgARqKQMAfHwgBUIUiHx8fHx8fHx8fHx8fCARQjSIfHx8fCIPQgyGhHwiBUL/////////B4M3A4gFIAMgAykDuAQiESADKQPIBHwiByADKQOYBHwiCCATQiyGfCILIAMpAwh8IhIgBSAOVK0gDiAQVK0gA0EgaikDACAQIApUrSADQdAAaikDACAKIAZUrSAGIA1UrSADQcADaikDACANIARUrSADQfADaikDACAEIBVUrSADQZAEaikDACADQbAEaikDAHx8fHx8fCAMQhSIfHx8fHx8IA9CNIh8fCIGQgyGIAVCNIiEfCIEQv////////8HgzcDkAUgAyADKQPYBCIMIAMpA+gEfCIFIBRCLIZ8Ig0gBCASVK0gEiALVK0gA0EQaikDACALIAhUrSAIIAdUrSADQaAEaikDACAHIBFUrSADQcAEaikDACADQdAEaikDAHx8fHwgE0IUiHx8fHwgBkI0iHx8IgpCDIYgBEI0iIR8IgRC/////////weDNwOYBSADIAlCLIYiECADKQP4BHwiBiAEIA1UrSANIAVUrSAFIAxUrSADQeAEaikDACADQfAEaikDAHx8IBRCFIh8fCAKQjSIfHwiBUIMhiAEQjSIhHwiBEL/////////B4M3A6AFIAMgBCAGVK0gBiAQVK0gA0GABWopAwAgCUIUiHx8IAVCNIh8fEIMhiAEQjSIhDcDqAUgACADQYgFakHY7cgAEKEBIANBsAVqJAALphIBDH8jAEGAAmsiAiQAAn8gAC0AHARAIABBDGooAgAhCCACQfABakEEciENIAAoAhghCyAAKAIIIQkDQAJAAkAgByALRg0AIAdBAWohCiAJIQUgCCEGAkADQCACIAU2AvABIAIgBSAGajYC9AEgAkHwAWoQkAEiA0GAgMQARg0BIANBUGpBCkkEQCACIAUgBkEBEP4BIAIoAgQhBiACKAIAIQUMAQsLIAJB6AFqIAkgCCAIIAZrENoCIAJB8AFqIAIoAugBIAIoAuwBELYBIAItAPABQQFHBEAgAkHgAWogBSAGIAIoAvQBIgMQ/gEgAigC5AEhCCACKALgASEJIAJB2AFqIAUgBiADENoCIAIoAtwBIQMgAigC2AEhBCABELMFRSAKIAtHcg0DIAQgA0HoABDdA0UNAyACQdABaiAEIANBARD+ASACIAIoAtABIgU2AvABIAIgBSACKALUAWo2AvQBA0AgAkHwAWoQkAEiBUGAgMQARg0DAkAgBUFQaiIGQQpJDQAgBUGff2pBGk8EQCAFQb9/akEaTw0GIAVBSWohBgwBCyAFQal/aiEGCyAGQRBJDQALDAMLIAIgAi0A8QE6AP8BQaOXygBBKyACQf8BakHQl8oAQeCYygAQqAIAC0H4lsoAQStB0JjKABDOAwALIAEgACgCECAAQRRqKAIAEIgFIAJBgAJqJAAPCwJAIAcEQCABQfCYygBBAhCIBQ0BCyAEIANB8pjKAEECEPsCBEAgAkHIAWogBCADQQEQ/gEgAigCyAEhBCACKALMASEDCwNAIANFBEAgCiEHDAMLIAQgA0EuEN0DRQRAIAQgA0EkEN0DRQRAIAIgBDYC9AEgAkEANgLwASACIAMgBGoiBjYC+AEgBCEFA0ACQCANEJABIgxBgIDEAEYEQCADIQcMAQsgAiACKALwASIHIAYgBWtqIAIoAvQBIgVqIAIoAvgBIgZrNgLwASAMQSRGDQAgDEEuRw0BCwsgAkHAAWogBCADIAcQ2gIgASACKALAASACKALEARCIBQ0DIAJBuAFqIAQgAyAHEP4BIAIoArwBIQMgAigCuAEhBAwCCwJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAIAQgA0H1mMoAQQQQ+wJFBEAgBCADQfqYygBBBBD7Ag0BIAQgA0H/mMoAQQQQ+wINAiAEIANBhJnKAEEEEPsCDQMgBCADQYmZygBBBBD7Ag0EIAQgA0GOmcoAQQQQ+wINBSAEIANBk5nKAEEEEPsCDQYgBCADQZiZygBBAxD7Ag0HIAQgA0GcmcoAQQUQ+wINCCAEIANBopnKAEEFEPsCDQkgBCADQaiZygBBBRD7Ag0KIAQgA0GumcoAQQUQ+wINCyAEIANBtJnKAEEFEPsCDQwgBCADQbqZygBBBRD7Ag0NIAQgA0HAmcoAQQUQ+wINDiAEIANBxpnKAEEFEPsCDQ8gBCADQcyZygBBBRD7Ag0QIAQgA0HSmcoAQQUQ+wINESAEIANB2JnKAEEFEPsCDRIgBCADQd6ZygBBBRD7Ag0TIAohByABIAQgAxCIBUUNFwwWC0EBIAFB+ZjKAEEBEIgFDRgaIAJBGGogBCADQQQQ/gEgAigCHCEDIAIoAhghBAwUC0EBIAFB/pjKAEEBEIgFDRcaIAJBIGogBCADQQQQ/gEgAigCJCEDIAIoAiAhBAwTC0EBIAFBg5nKAEEBEIgFDRYaIAJBKGogBCADQQQQ/gEgAigCLCEDIAIoAighBAwSC0EBIAFBiJnKAEEBEIgFDRUaIAJBMGogBCADQQQQ/gEgAigCNCEDIAIoAjAhBAwRC0EBIAFBjZnKAEEBEIgFDRQaIAJBOGogBCADQQQQ/gEgAigCPCEDIAIoAjghBAwQC0EBIAFBkpnKAEEBEIgFDRMaIAJBQGsgBCADQQQQ/gEgAigCRCEDIAIoAkAhBAwPC0EBIAFBl5nKAEEBEIgFDRIaIAJByABqIAQgA0EEEP4BIAIoAkwhAyACKAJIIQQMDgtBASABQZuZygBBARCIBQ0RGiACQdAAaiAEIANBAxD+ASACKAJUIQMgAigCUCEEDA0LQQEgAUGhmcoAQQEQiAUNEBogAkHYAGogBCADQQUQ/gEgAigCXCEDIAIoAlghBAwMC0EBIAFBp5nKAEEBEIgFDQ8aIAJB4ABqIAQgA0EFEP4BIAIoAmQhAyACKAJgIQQMCwtBASABQa2ZygBBARCIBQ0OGiACQegAaiAEIANBBRD+ASACKAJsIQMgAigCaCEEDAoLQQEgAUGzmcoAQQEQiAUNDRogAkHwAGogBCADQQUQ/gEgAigCdCEDIAIoAnAhBAwJC0EBIAFBuZnKAEEBEIgFDQwaIAJB+ABqIAQgA0EFEP4BIAIoAnwhAyACKAJ4IQQMCAtBASABQb+ZygBBARCIBQ0LGiACQYABaiAEIANBBRD+ASACKAKEASEDIAIoAoABIQQMBwtBASABQcWZygBBARCIBQ0KGiACQYgBaiAEIANBBRD+ASACKAKMASEDIAIoAogBIQQMBgtBASABQcuZygBBARCIBQ0JGiACQZABaiAEIANBBRD+ASACKAKUASEDIAIoApABIQQMBQtBASABQdGZygBBARCIBQ0IGiACQZgBaiAEIANBBRD+ASACKAKcASEDIAIoApgBIQQMBAtBASABQdeZygBBARCIBQ0HGiACQaABaiAEIANBBRD+ASACKAKkASEDIAIoAqABIQQMAwtBASABQd2ZygBBARCIBQ0GGiACQagBaiAEIANBBRD+ASACKAKsASEDIAIoAqgBIQQMAgtBASABQeOZygBBARCIBQ0FGiACQbABaiAEIANBBRD+ASACKAK0ASEDIAIoArABIQQMAQsgAkEQaiAEIANBARD+ASACIAIoAhAiBzYC8AEgAiAHIAIoAhRqNgL0AQJAIAJB8AFqEJABQS5HBEBBASEFIAFB9JjKAEEBEIgFDQMMAQtBAiEFIAFB8JjKAEECEIgFDQILIAJBCGogBCADIAUQ/gEgAigCDCEDIAIoAgghBAwACwALC0EBDAELIAEgACgCACAAKAIEEIgFCyACQYACaiQAC9wOAgt/AX4jAEGQAWsiAyQAIANB0ABqIAEgAkHgl8oAQQYQIAJAIAMoAlBBAUcEQCADQdwAai0AACEGIANBhAFqKAIAIQggAygCVCEHIAMoAoABIQkCQANAAkAgA0EwaiAJIAggBxD+ASADIAMoAjAiBTYCOCADIAUgAygCNGo2AjwgBiIFRSEGIANBOGoQkAEhBCAFDQAgBEGAgMQARg0CAn9BASAEQYABSQ0AGkECIARBgBBJDQAaQQNBBCAEQYCABEkbCyAHaiEHDAELCyADQcgAaiAHNgIAIAMgBzYCVCADIAY6AFwgAyAHNgJEIANBATYCQAwCCyADIAc2AlQgAyAGOgBcIANBADYCQAwBCyADQdgAaiEFIANBjAFqKAIAIQYgA0GEAWooAgAhBCADKAKIASEIIAMoAoABIQcgA0H0AGooAgBBf0YEQCADQUBrIAUgByAEIAggBkEBEFQMAQsgA0FAayAFIAcgBCAIIAZBABBUCwJAIAMoAkBBAUcNACADQShqIAEgAiADKAJEIgZBBmoQ/gEgAyADKAIoIgUgAygCLGo2AlQgAyAFNgJQA0AgA0HQAGoQkAEiBUGAgMQARwRAIAVBwABGIAVBv39qQQZJciAFQVBqQQpJcg0BDAILCyADQSBqIAEgAiAGENoCIAMoAiQhAiADKAIgIQELIANB0ABqIAEgAkHml8oAQQIQIAJAIAMoAlBBAUcEQCADQYQBaigCACELIANB2ABqKAIAIQcgA0HdAGotAAAhBiADKAKAASEMAkADQCADIAYiBUUiBjoAXSADQRhqIAwgCyAHENoCQYCAxAAhBAJAIAMoAhwiCUUNACAJIAMoAhgiCGoiCUF/aiIKLQAAIgRBGHRBGHUiDUEATg0AIA1BP3ECf0EAIAggCkYNABogCUF+aiIKLQAAIgRBwAFxQYABRwRAIARBH3EMAQsgBEE/cQJ/QQAgCCAKRg0AGiAJQX1qIgotAAAiBEHAAXFBgAFHBEAgBEEPcQwBCyAIIApGBH9BAAUgCUF8ai0AAEEHcUEGdAsgBEE/cXILQQZ0cgtBBnRyIQQLIAVFBEAgBEGAgMQARg0CIAMgBwJ/QQEgBEGAAUkNABpBAiAEQYAQSQ0AGkEDQQQgBEGAgARJGwtrIgc2AlgMAQsLIANByABqIAc2AgAgAyAHNgJEIANBATYCQAwCCyADQQA2AkAMAQsgA0HYAGohBSADQYwBaigCACEGIANBhAFqKAIAIQQgAygCiAEhCCADKAKAASEHIANB9ABqKAIAQX9GBEAgA0FAayAFIAcgBCAIIAZBARBMDAELIANBQGsgBSAHIAQgCCAGQQAQTAsgAwJ/AkACQAJAIAMoAkBBAUYEQCADKAJEIgZBAWoiBSAGSSACIAVGckUEQCACIAVNDQMgASAFaiwAAEG/f0wNAwsgAyABIAJqNgJUIAMgASAFaiIMNgJQIAIgBWshCgNAIANB0ABqEJABIgZBgIDEAEYEQCAFIQIMAwsgBkFfakEPSSAGQVBqQQpJciAGQd///wBxQb9/akEaSSAGQUZqQQdJcnIgBkGlf2pBBkkgBkGFf2pBBElycg0ACwtB5pfKACEMQQAhCgsCQCACQQRLBEAgASACQeiXygBBAxD7AkUNASABIAIQ3gNFDQEgAyABIAJBAyACQX9qEMsBQQEhBCADKAIEIQUgAygCAAwEC0EAIQQgAiEFIAEgAkEERw0DGgsgASACQeuXygBBAhD7AkUNASABIAIQ3gNFDQEgA0EIaiABIAJBAiACQX9qEMsBQQEhBCADKAIMIQUgAygCCAwCCyABIAJBACAFECkAC0EAIQQCQCACQQVNDQAgASACQe2XygBBBBD7AkUNACACIQUgASABIAIQ3gNFDQEaIANBEGogASACQQQgAkF/ahDLAUEBIQQgAygCFCEFIAMoAhAMAQsgAiEFIAELIgs2AlAgAyAFIAtqIgY2AlQgA0HQAGoQxQMhCEEAIQ0CQCAERQRAQQAhCQwBC0EAIQkgCA0AIANBgYDEADYCWCADIAY2AlQgAyALNgJQQQEhBANAIARBAXFFDQFBACEEAkACQAJAA0AgBCEIIAMoAlgiBEGBgMQARgRAIAMgA0HQAGoQkAEiBDYCWAtBASEGIARBgIDEAEYNASAEQVBqIgRBCUsNASADQdAAahDsBBogCK1CCn4iDkIgiKcEQEEAIQYMAwsgDqciBiAEaiIEIAZPDQALQQAhBgsgCEUNAQsgAyAINgJEIAhBf2ohBCADIANB0ABqNgJAQQAhBwNAIANBQGsQgAFBgIDEAEcEQCAHQQFqIQcgAyAENgJEIARBf2oiBEF/Rw0BCwsgCSAHIAhGIgRqIQkgBCAGcSEEDAELCyADQdAAahDsBEGAgMQARiENCyAAIA06ABwgACAMNgIQIAAgCzYCCCAAIAI2AgQgACABNgIAIAAgCTYCGCAAQRRqIAo2AgAgAEEMaiAFNgIAIANBkAFqJAALiA8BCX8jAEGQEWsiBSQAIAUgBDYCvAEgBSADNgK4ASAFQbABaiAFQbgBakEHEKYFIAVBtAtqQQE2AgAgBUIBNwKkCyAFQcD6wQA2AqALIAUgBSkDsAE3A/AGIAUgBUHwBmo2ArALIAVBwAFqIAVBoAtqEGYgBUGgC2ogASACEKwBIAVB0AFqIAVBoAtqQcj6wQAQ6wIgBUHoAWpBAEHAABDBBBogBUGoAWogBUHQAWoQsAQgBSgCqAEhASAFKAKsASECIAVBoAFqIAVBwAFqEJsFIAUoAqQBIQsgBSgCoAEhDCAFQagCahCyAyAFQdAPahDaASAFQfAGahCyAyAFQaALaiAFQagCakHYARDyAxogBUHQDmogBUHQD2pBgAEQ8gMhAyAFQfgMaiAFQfAGakHYARDyAyAFQdAPahDZASAFQZgBaiADEKoFAkACQAJAAkACQCAFKAKcASACSQRAIAVBqAJqELIDIAVBqAJqIAEgAhDRBSAFQfAGaiAFQagCakHYARDyAxogBUHQEGogBUHwBmoQ7gMgBUGAAWogBUHQEGoQqQUgBSgChAEhASAFQfgAaiADEKoFIAVB8ABqQQAgBSgCfCICIAEgASACSxsQpgUgBSAFKQNwNwPwBgNAIAVB6ABqIAVB8AZqELkDIAUoAmhFDQYgBSgCbCEBIAVB4ABqIAVB0BBqEKkFIAEgBSgCZCICTw0CIAUoAmAgAWotAAAhAiAFQdgAaiADEKoFIAEgBSgCXCIGTw0DIAUoAlggAWoiBiAGLQAAIAJzOgAAIAVB0ABqIAVB0BBqEKkFIAEgBSgCVCICTw0EIAUoAlAgAWotAAAhAiAFQcgAaiAFQdAPahCqBSABIAUoAkwiBk8NBSAFKAJIIAFqIgEgAS0AACACczoAAAwACwALIAVB8AZqIAEgASACahCLBSAFQagCaiAFQfAGahD5BCAFKAKwAiEBIAUoAqwCIQYgBSgCqAIhAgJAA0AgAiAGRg0GIAItAAAhCCAFQZABaiADEKoFIAEgBSgClAEiB0kEQCAFKAKQASABaiIHIActAAAgCHM6AAAgAi0AACEIIAVBiAFqIAVB0A9qEKoFIAEgBSgCjAEiB08NAiACQQFqIQIgBSgCiAEgAWoiByAHLQAAIAhzOgAAIAFBAWohAQwBCwtBwPjBACABIAcQ5AIAC0HQ+MEAIAEgBxDkAgALQeD4wQAgASACEOQCAAtB8PjBACABIAYQ5AIAC0GA+cEAIAEgAhDkAgALQZD5wQAgASAGEOQCAAsgBUGgC2ogAxCxBCAFQdAPahCxBCAFQagCaiAFQaALakGwBBDyAxogBULAgICAgAg3AvQGIAUgBUHoAWo2AvAGIAVBoAtqIAVB8AZqEOsEIAVB2AZqIAVBoAtqEPgEIAVBqAtqIQcgBUHYD2ohCCAFKALkBiEEIAUoAuAGIQogBSgC3AYhBiAFKALYBiECA0ACQCAGRSACRXJFBEAgBEEBaiEEIAYgCiAGIAYgCksbIgFrIQYgBUFAayACIAEgAmoiAxCmBSAFKAJEIQkgBSgCQCEBA0AgASAJRgRAIAVB8AZqIAVBqAJqEIIDIAVB8AZqIAwgCxDRBSAFIARBCHRBgID8B3EgBEEYdHIgBEEIdkGA/gNxIARBGHZycjYC6AYgBUHwBmogBUHoBmpBBBDRBSAFQaALaiAFQfAGakGwBBDyAxogBUHQD2ogBUGgC2oQvgIgBUGgC2ogBUHQD2oQuQUgBUE4aiAFQaALahCpBSAFQTBqIAUoAjgiASABIAUoAjxqEKYFIAVB0BBqIAIgAyAFKAIwIAUoAjQQywMgBUHgD2oiDSAFQeAQaikDADcDACAIIAVB2BBqKQMANwMAIAUgBSkD0BA3A9APA0AgBSgC4A8iASAFKALkD08EQCAFQdAQaiAFQaALakHAABDyAxogBUEoakEBQYAQEKYFIAUgBSkDKDcD6AYDQCAFQSBqIAVB6AZqELkDIAUoAiBFDQYgBUHwBmogBUGoAmoQggMgBUEYaiAFQdAQahCpBSAFQfAGaiAFKAIYIAUoAhwQ0QUgBUGgC2ogBUHwBmpBsAQQ8gMaIAVB0A9qIAVBoAtqEL4CIAVBoAtqIAVB0A9qELkFIAVB0BBqIAVBoAtqQcAAEPIDGiAFQRBqIAVB0BBqEKkFIAVBCGogBSgCECIBIAEgBSgCFGoQpgUgBUHQD2ogAiADIAUoAgggBSgCDBDLAyAFQbALaiANKQMANwMAIAcgCCkDADcDACAFIAUpA9APNwOgCwNAIAUoArALIgEgBSgCtAtPBEAMAgUgBSABQQFqNgKwCyAFQaALaiABEMwFIQkgByABEMwFIQEgCSAJLQAAIAEtAABzOgAADAELAAsACwAFIAUgAUEBajYC4A8gBUHQD2ogARDMBSEJIAggARDMBSEBIAkgCS0AACABLQAAczoAAAwBCwALAAUgAUEAOgAAIAFBAWohAQwBCwALAAsgACAFQegBakEgEJwDIAVB0AFqEKMFIAVBwAFqEIEFIAVBkBFqJAAPCyADIQIMAAsAC60NAQl/IwBBwBBrIgYkACAGQZgBakEAQcAAEMEEGiAGQdgBahCyAyAGQYAPahDaASAGQaAGahCyAyAGQdAKaiAGQdgBakHYARDyAxogBkGADmogBkGAD2pBgAEQ8gMhCSAGQagMaiAGQaAGakHYARDyAyAGQYAPahDZASAGQZABaiAJEKoFAkACQAJAAkACQCAGKAKUASACSQRAIAZB2AFqELIDIAZB2AFqIAEgAhDRBSAGQaAGaiAGQdgBakHYARDyAxogBkGAEGogBkGgBmoQ7gMgBkH4AGogBkGAEGoQqQUgBigCfCEBIAZB8ABqIAkQqgUgBkHoAGpBACAGKAJ0IgIgASABIAJLGxCmBSAGIAYpA2g3A6AGA0AgBkHgAGogBkGgBmoQuQMgBigCYEUNBiAGKAJkIQEgBkHYAGogBkGAEGoQqQUgASAGKAJcIgJPDQIgBigCWCABai0AACECIAZB0ABqIAkQqgUgASAGKAJUIgdPDQMgBigCUCABaiIHIActAAAgAnM6AAAgBkHIAGogBkGAEGoQqQUgASAGKAJMIgJPDQQgBigCSCABai0AACECIAZBQGsgBkGAD2oQqgUgASAGKAJEIgdPDQUgBigCQCABaiIBIAEtAAAgAnM6AAAMAAsACyAGQaAGaiABIAEgAmoQiwUgBkHYAWogBkGgBmoQ+QQgBigC4AEhAiAGKALcASEHIAYoAtgBIQECQANAIAEgB0YNBiABLQAAIQsgBkGIAWogCRCqBSACIAYoAowBIghJBEAgBigCiAEgAmoiCCAILQAAIAtzOgAAIAEtAAAhCyAGQYABaiAGQYAPahCqBSACIAYoAoQBIghPDQIgAUEBaiEBIAYoAoABIAJqIgggCC0AACALczoAACACQQFqIQIMAQsLQfyEwAAgAiAIEOQCAAtBjIXAACACIAgQ5AIAC0GchcAAIAEgAhDkAgALQayFwAAgASAHEOQCAAtBvIXAACABIAIQ5AIAC0HMhcAAIAEgBxDkAgALIAZB0ApqIAkQsQQgBkGAD2oQsQQgBkHYAWogBkHQCmpBsAQQ8gMaIAZCwICAgIAINwKkBiAGIAZBmAFqNgKgBiAGQdAKaiAGQaAGahDrBCAGQYgGaiAGQdAKahD4BCAGQdgKaiEIIAZBiA9qIQsgBigClAYhCiAGKAKQBiENIAYoAowGIQcgBigCiAYhAQNAAkAgB0UgAUVyRQRAIApBAWohCiAHIA0gByAHIA1LGyICayEHIAZBOGogASABIAJqIgkQpgUgBigCPCEMIAYoAjghAgNAIAIgDEYEQCAGQaAGaiAGQdgBahCCAyAGQaAGaiADIAQQ0QUgBiAKQQh0QYCA/AdxIApBGHRyIApBCHZBgP4DcSAKQRh2cnI2ApgGIAZBoAZqIAZBmAZqQQQQ0QUgBkHQCmogBkGgBmpBsAQQ8gMaIAZBgA9qIAZB0ApqEL4CIAZB0ApqIAZBgA9qELkFIAZBMGogBkHQCmoQqQUgBkEoaiAGKAIwIgIgAiAGKAI0ahCmBSAGQYAQaiABIAkgBigCKCAGKAIsEMsDIAZBkA9qIg4gBkGQEGopAwA3AwAgCyAGQYgQaikDADcDACAGIAYpA4AQNwOADwNAIAYoApAPIgIgBigClA9PBEAgBkGAEGogBkHQCmpBwAAQ8gMaIAZBIGpBASAFEKYFIAYgBikDIDcDmAYDQCAGQRhqIAZBmAZqELkDIAYoAhhFDQYgBkGgBmogBkHYAWoQggMgBkEQaiAGQYAQahCpBSAGQaAGaiAGKAIQIAYoAhQQ0QUgBkHQCmogBkGgBmpBsAQQ8gMaIAZBgA9qIAZB0ApqEL4CIAZB0ApqIAZBgA9qELkFIAZBgBBqIAZB0ApqQcAAEPIDGiAGQQhqIAZBgBBqEKkFIAYgBigCCCICIAIgBigCDGoQpgUgBkGAD2ogASAJIAYoAgAgBigCBBDLAyAGQeAKaiAOKQMANwMAIAggCykDADcDACAGIAYpA4APNwPQCgNAIAYoAuAKIgIgBigC5ApPBEAMAgUgBiACQQFqNgLgCiAGQdAKaiACEMwFIQwgCCACEMwFIQIgDCAMLQAAIAItAABzOgAADAELAAsACwAFIAYgAkEBajYCkA8gBkGAD2ogAhDMBSEMIAsgAhDMBSECIAwgDC0AACACLQAAczoAAAwBCwALAAUgAkEAOgAAIAJBAWohAgwBCwALAAsgACAGQZgBakHAABCcAyAGQcAQaiQADwsgCSEBDAALAAvHCwINfwJ+IwBBMGsiBiQAAkACQAJAAkAgAUEdai0AACIEIAFBHmotAAAiC0sgBEEDRnIgC0EDRnINACABQQhqIQwgAUEdaiEJAkACQAJAAkADQAJAAkACQAJAAkACQAJAIARBAWsOAwIDAAELQbCdygBBKEHoocoAELwEAAsgDC0AACIHQQZGBEBBASEEIAlBAToAAAwECwJAAn8CQAJAAkACQAJAQQAgDCAHQQZGGyIDLQAAIghBAWsOBQADAgEDBAsgAygCCCADKAIQIgRBAWpBACAEG2pBCGoMBAsgAygCCCADKAIQIgRBAWpBACAEG2pBAmoMAwsgAygCCEEEagwCCyABQR1qQQE6AAAMAgsgAygCCEEEagtBASEEIAlBAToAAEUNBAsgASgCBCEFIAEoAgAhCUECIQQCQAJAAkACQAJAAkAgCEEBaw4FAQIEAwUACyADKAIIQQRqIQQMBAsgAygCCCADKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAygCCCADKAIQIgRBAWpBACAEG2pBAmohBAwBCyADKAIIQQRqIQQLIAUgBEkNBEECIQICQAJAAkACQAJAAkAgCEEBaw4FAQIEAwUACyADKAIIQQRqIQIMBAsgAygCCCADKAIQIgJBAWpBACACG2pBCGohAgwDC0EGIQIMAgsgAygCCCADKAIQIgJBAWpBACACG2pBAmohAgwBCyADKAIIQQRqIQILIAUgAkkNBiABIAUgAms2AgQgASACIAlqNgIAIAZBJ2oiAiABQRhqKAAANgAAIAZBIGoiAyABQRFqKQAANwMAIAZBD2oiBSACKAAANgAAIAZBCGoiAiADKQMANwMAIAYgAUEJaikAACIPNwMAIABBDGogBzoAACAAQQhqIAQ2AgAgACAJNgIEIABBADYCACAAIA83AA0gAEEVaiACKQMANwAAIABBHGogBSgAADYAAAwNCyAJQQI6AAACQAJAIAEtABxFBEAgAS0ACCIEQQZHDQJBAiEEIAEoAgQiAkUNBSABKAIAIgMtAAAhBSADQQFqIgggAyACGyIHIAIgA2oiA0YgBUEuR3INASAHLQAAQS9HDQUMDgsgASgCBCIERQ0IIABBATYCACABIARBf2o2AgQgASABKAIAQQFqNgIADA4LIAMgB0cNAyAFQS5GDQwMAwsgBEEDakEHcSICQQZJDQEMCgsgASgCBCIDBEAgASgCACEHQQAhCEEAIQUCQANAIAMgBUYEQCADIQIMAgsgBSAHaiAFQQFqIQUtAAAiCkEvRw0AC0EBIQggAyAKQS9GQQFqQQFxIAVqQX9qIgJJDQgLIAIgCGohCEEEIQUCQCACQQJLDQACQAJAAkAgAkEBaw4CAAECCyAHQdChygBHBEAgBy0AAEEuRw0DC0ECQQVBAiABLQAIIgVBA0kgBUEGRhsiBUEBcRtBBSAFQQJHGyEFDAILIAdB46HKAEcEQCAHLwAAQa7cAEcNAgtBAyEFDAELQQUhBQsgBkEQaiAGQShqIgooAgAiDTYCACAGQQhqIAZBIGoiDikCACIPNwMAIAYgBikCGCIQNwMAIAogDTYCACAOIA83AwAgBiAQNwMYIAMgCEkNCCABIAMgCGs2AgQgASAHIAhqNgIAIAVBBUYNAiAAIAc2AgQgACAFNgIAIABBCGogAjYCACAAQQxqIAYpAxg3AgAgAEEUaiAGQSBqKQMANwIAIABBHGogBkEoaigCADYCAAwMCyABQR1qQQM6AAAMCAtBAiEEQTkgAnZBAXFFDQgLIAQiAiALSw0GIAJBA0cNAQwGCwsgBCAFEOUCAAsgAiAFEOYCAAtBAUEAEOYCAAsgCkEvRkEBakEBcSAFakF/aiADEOUCAAsgCCADEOYCAAsgAEEFNgIADAILIABBATYCAAwBCyABIAg2AgAgAEECNgIAIAEgAkF/ajYCBAsgBkEwaiQAC9ELAgR/An4jAEGQCGsiBiQAAn8CfwJAIAFBwABGBEAgBkHYBWpCADcDACAGQdAFakIANwMAIAZByAVqQgA3AwAgBkIANwPABSAGQegCakIANwMAIAZB4AJqIgdCADcDACAGQdgCaiIIQgA3AwAgBkIANwPQAiAGQcAFakEgIABBIBCuASAGQdACakEgIABBIGpBIBCuASAGQb8EaiIAIAZB5wJqKQAANwAAIAZBuARqIgEgBykDADcDACAGQbAEaiIHIAgpAwA3AwAgBiAGKQPQAjcDqAQgBi0A7wIiCEEQSQ0BIAZBxwJqIAApAAA3AAAgBkHAAmogASkDADcDACAGQbgCaiAHKQMANwMAIAYgBikDqAQ3A7ACIAYgCDoAzwIgBkHoAGogBkGwAmoQzQEgBi0AaEEBRgRAIAZBrgJqIAYtAGs6AAAgBiAGLwBpOwGsAiAGIAZB/ABqKQIANwOIBCAGIAZBgQFqKQAANwCNBCAGQfQAaigCACEBIAZB+ABqKAIAIQAgBigCbCEHIAZB8ABqKAIADAMLIAZB4ABqIAZBkARqKQIANwMAIAYgBikCiAQ3A1gLQQAMAgsgBkH/AGogACkAADcAACAGQfgAaiABKQMANwMAIAZB8ABqIAcpAwA3AwAgBiAGKQOoBDcDaCAGIAg6AIcBIAZB2AZqIAZB6ABqELsDIAZBrgJqIAYtANoGOgAAIAYgBi8B2AY7AawCIAYgBikA6wY3A4gEIAYgBkHwBmopAAA3AI0EIAYoANsGIQcgBigA4wYhASAGKADnBiEAIAYoAN8GCyEIIAZBqgJqIgkgBkGuAmotAAA6AAAgBiAGLwGsAjsBqAIgBiAGKQOIBDcDSCAGIAYpAI0ENwBNIAYgBi8BwAU7AQggBiAGLQDCBToACiAGKQDDBSEKIAYpAMsFIQsgBiAGQdgFaikAADcAbSAGIAYpANMFNwNoIAZB9wBqIAktAAA6AAAgBiAGLwGoAjsAdSAGQeAAaiIJIAZB8ABqKQMANwMAIAYgBikDaDcDWCAGIAs3ABMgBiAKNwALIAZBI2ogCSkDADcAACAGIAYpA1g3ABsgBkE3aiAANgAAIAZBM2ogATYAACAGQS9qIAg2AAAgBkEraiAHNgAAIAZBQGsgBikATTcAACAGQTtqIAYpA0g3AAACQCAFQSBGBEAgBkHIAmoiAEIANwMAIAZBwAJqIgFCADcDACAGQbgCaiIFQgA3AwAgBkIANwOwAiAGQbACakEgIARBIBCuASAGQaAEaiAAKQMANwMAIAZBmARqIgAgASkDADcDACAGQZAEaiAFKQMANwMAIAYgBikDsAI3A4gEIAZB6ABqIAZBiARqEGwgBikDaEIBUQ0BIAZB6AZqIgAgBkHgAmoiASkCADcDACAGQeAGaiAGQdgCaiICKQIANwMAIAYgBikC0AI3A9gGIAZBwAVqIAZB2AZqQZQBEPIDGiAGQfgAaiAGKQLABTcDACAGQYABaiAGQcgFaikCADcDACAGQYgBaiAGQdAFaikCADcDACAGQQA2AmggBkHYBmogBkHoAGpBKBDyAxogAiAGQfAGaikDADcDACABIAZB+AZqKQMANwMAIAYgACkDADcD0AILQdD8wQBBH0Hw/MEAELQEAAsgBkH4AGooAgAhASAGKQNwIQogBkHYBmogBkH8AGpBlAEQ8gMaIAZBwAVqIAZB2AZqQZQBEPIDGiAGQagEaiAGQcAFakGUARDyAxogBkHYBmogBkGoBGpBlAEQ8gMaIAZBhAhqIAZBoARqKQMANwIAIAZB/AdqIAApAwA3AgAgBkH0B2ogBkGQBGopAwA3AgAgBiAGKQOIBDcC7AcgBkHQAmogBkHYBmpBtAEQ8gMaIAYgATYCcCAGIAo3A2ggBkH0AGogBkHQAmpBtAEQ8gMaIAZB2AZqIAZB6ABqIAIgAyAGQQhqELwBIAYoAtgGQQVGCyAGQZAIaiQAC6AJAgF/D34jAEGQA2siAyQAIANBEGogASkDACIEIAIpAwgiBhCeAiADQaABaiABKQMgIgcgAikDECILQhN+IhAQngIgA0HgAWogASkDGCIIIAIpAxgiDUITfiIOEJ4CIANBoAJqIAEpAxAiBSACKQMgIg9CE34iDBCeAiADQdAAaiABKQMIIgkgAikDACIKEJ4CIAMgCiAEEJ4CIANBkAFqIAcgBkITfhCeAiADQdABaiAIIBAQngIgA0GQAmogBSAOEJ4CIANB0AJqIAkgDBCeAiADQSBqIAQgCxCeAiADQbABaiAHIA4QngIgA0HwAWogCCAMEJ4CIANB4ABqIAUgChCeAiADQeACaiAJIAYQngIgA0EwaiAEIA0QngIgA0HAAWogByAMEJ4CIANB8ABqIAggChCeAiADQbACaiAFIAYQngIgA0HwAmogCSALEJ4CIANBQGsgBCAPEJ4CIANBgAFqIAcgChCeAiADQYACaiAIIAYQngIgA0HAAmogBSALEJ4CIANBgANqIAkgDRCeAiAAIAMpA7ABIg8gAykDIHwiBCADKQPwAXwiBiADKQNgfCIHIAMpA+ACfCIIIAMpA6ABIhEgAykDEHwiBSADKQPgAXwiCSADKQOgAnwiCiADKQNQfCILIAMpA5ABIhIgAykDAHwiDCADKQPQAXwiDSADKQOQAnwiDiADKQPQAnwiEEIziCAQIA5UrSADQdgCaikDACAOIA1UrSADQZgCaikDACANIAxUrSADQdgBaikDACAMIBJUrSADQZgBaikDACADQQhqKQMAfHx8fHx8fHxCDYaEfCIMQjOIIAwgC1StIAsgClStIANB2ABqKQMAIAogCVStIANBqAJqKQMAIAkgBVStIANB6AFqKQMAIAUgEVStIANBqAFqKQMAIANBGGopAwB8fHx8fHx8fHxCDYaEfCIFQv////////8DgzcDECAAIAMpA8ABIg4gAykDMHwiCSADKQNwfCIKIAMpA7ACfCILIAMpA/ACfCINIAUgCFStIAggB1StIANB6AJqKQMAIAcgBlStIANB6ABqKQMAIAYgBFStIANB+AFqKQMAIAQgD1StIANBuAFqKQMAIANBKGopAwB8fHx8fHx8fHxCDYYgBUIziIR8IgRC/////////wODNwMYIAAgAykDgAEiDyADKQNAfCIGIAMpA4ACfCIHIAMpA8ACfCIIIAMpA4ADfCIFIAQgDVStIA0gC1StIANB+AJqKQMAIAsgClStIANBuAJqKQMAIAogCVStIANB+ABqKQMAIAkgDlStIANByAFqKQMAIANBOGopAwB8fHx8fHx8fHxCDYYgBEIziIR8IgRC/////////wODNwMgIAAgBCAFVK0gBSAIVK0gA0GIA2opAwAgCCAHVK0gA0HIAmopAwAgByAGVK0gA0GIAmopAwAgBiAPVK0gA0GIAWopAwAgA0HIAGopAwB8fHx8fHx8fHxCDYYgBEIziIRCE34gEEL/////////A4N8IgRC/////////wODNwMAIAAgDEL/////////A4MgBEIziHw3AwggA0GQA2okAAugCwEJfyMAQYAQayIFJAAgBUGYAWpBwAAQtQIgBUGQAWogBUGYAWoQmwUgBSgClAEhCyAFKAKQASEJIAVBqAFqELIDIAVBwA5qENoBIAVB4AVqELIDIAVBkApqIAVBqAFqQdgBEPIDGiAFQcANaiAFQcAOakGAARDyAyEHIAVB6AtqIAVB4AVqQdgBEPIDIAVBwA5qENkBIAVBiAFqIAcQqgUCQAJAAkACQAJAIAUoAowBIAJJBEAgBUGoAWoQsgMgBUGoAWogASACENEFIAVB4AVqIAVBqAFqQdgBEPIDGiAFQcAPaiAFQeAFahDuAyAFQfAAaiAFQcAPahCpBSAFKAJ0IQEgBUHoAGogBxCqBSAFQeAAakEAIAUoAmwiAiABIAEgAksbEKYFIAUgBSkDYDcD4AUDQCAFQdgAaiAFQeAFahC5AyAFKAJYRQ0GIAUoAlwhASAFQdAAaiAFQcAPahCpBSABIAUoAlQiAk8NAiAFKAJQIAFqLQAAIQIgBUHIAGogBxCqBSABIAUoAkwiBk8NAyAFKAJIIAFqIgYgBi0AACACczoAACAFQUBrIAVBwA9qEKkFIAEgBSgCRCICTw0EIAUoAkAgAWotAAAhAiAFQThqIAVBwA5qEKoFIAEgBSgCPCIGTw0FIAUoAjggAWoiASABLQAAIAJzOgAADAALAAsCQANAIAIgBkYNBiABIAZqIgotAAAhCCAFQYABaiAHEKoFIAYgBSgChAEiDUkEQCAFKAKAASAGaiINIA0tAAAgCHM6AAAgCi0AACEKIAVB+ABqIAVBwA5qEKoFIAYgBSgCfCIITw0CIAUoAnggBmoiCCAILQAAIApzOgAAIAZBAWohBgwBCwtB3PLIACAGIA0Q5AIAC0Hs8sgAIAYgCBDkAgALQfzyyAAgASACEOQCAAtBjPPIACABIAYQ5AIAC0Gc88gAIAEgAhDkAgALQazzyAAgASAGEOQCAAsgBUGQCmogBxCxBCAFQcAOahCxBCAFQagBaiAFQZAKakGwBBDyAxpBACECA0ACQCALRSAJRXJFBEAgAkEBaiECIAsgC0HAACALQcAASRsiBmshCyAGIAlqIQEgCSEHA0AgBgRAIAdBADoAACAGQX9qIQYgB0EBaiEHDAEFAkAgBUHgBWogBUGoAWoQhAMgBUHgBWogAyAEENEFIAUgAkEIdEGAgPwHcSACQRh0ciACQQh2QYD+A3EgAkEYdnJyNgLYBSAFQeAFaiAFQdgFakEEENEFIAVBkApqIAVB4AVqQbAEEPIDGiAFQcAOaiAFQZAKahCAAyAFQZAKaiAFQcAOakHAABDyAxogBUEwaiAFQZAKahCpBSAFQShqIAUoAjAiByAHIAUoAjRqEKYFIAUoAiwgBSgCKCIMayIGIAEgCWsiByAHIAZLGyEKQQAhBgNAIAYgCk8NASAGIAlqIgggCC0AACAGIAxqLQAAczoAACAGQQFqIQYMAAsACwsLIAVBwA9qIAVBkApqQcAAEPIDGiAFQSBqQQFBgBAQpgUgBSAFKQMgNwPYBQNAIAVBGGogBUHYBWoQuQMgBSgCGEUNAiAFQeAFaiAFQagBahCEAyAFQRBqIAVBwA9qEKkFIAVB4AVqIAUoAhAgBSgCFBDRBSAFQZAKaiAFQeAFakGwBBDyAxogBUHADmogBUGQCmoQgAMgBUHAD2ogBUHADmpBwAAQ8gMaIAVBCGogBUHAD2oQqQUgBSAFKAIIIgYgBiAFKAIMahCmBSAFKAIEIAUoAgAiDGsiBiAHIAcgBksbIQpBACEGA0AgBiAKTw0BIAYgCWoiCCAILQAAIAYgDGotAABzOgAAIAZBAWohBgwACwALAAsgACAFKQOYATcCACAAQQhqIAVBoAFqKAIANgIAIAVBgBBqJAAPCyABIQkMAAsAC/QJAgp/AX4CQAJAAkACfwJAAkACQCAEQQFNBEAgBCENIAQhCCAEQQFrDQIMAQtBASEFQQEhBkEBIQ0DQCAGIQkCQCAHIApqIgggBEkEQCADIAVqLQAAIgYgAyAIai0AACIFTwRAIAUgBkcEQEEBIQ0gCUEBaiEGQQAhByAJIQoMAwtBACAHQQFqIgYgBiANRiIFGyEHIAZBACAFGyAJaiEGDAILIAcgCWpBAWoiBiAKayENQQAhBwwBC0GgsMoAIAggBBDkAgALIAYgB2oiBSAESQ0AC0EBIQVBASEGQQAhB0EBIQgDQCAGIQkCQCAHIAtqIgwgBEkEQCADIAVqLQAAIgYgAyAMai0AACIFTQRAIAUgBkcEQEEBIQggCUEBaiEGQQAhByAJIQsMAwtBACAHQQFqIgYgBiAIRiIFGyEHIAZBACAFGyAJaiEGDAILIAcgCWpBAWoiBiALayEIQQAhBwwBC0GgsMoAIAwgBBDkAgALIAYgB2oiBSAESQ0ACwsCQAJAIAogCyAKIAtLIgUbIgsgBE0EQCANIAggBRsiBiALaiIFIAZJDQEgBSAESw0CIAZFDQQgAyADIAZqIAsQtANFDQQgCyAEIAtrIgUgCyAFSxsgBCEGIAMhBwNAQgEgBzEAAEI/g4YgD4QhDyAHQQFqIQcgBkF/aiIGDQALQQFqIQZBfyEIIAshBUF/DAULIAsgBBDlAgALIAYgBRDmAgALIAUgBBDlAgALIAAgAzYCOCAAIAE2AjAgAEIANwMAIABBPGpBADYCACAAQTRqIAI2AgAgAEEMakGBAjsBACAAQQhqIAI2AgAPC0EBIQpBACEHQQEhBUEAIQ0DQCAFIgkgB2oiDCAESQRAIAQgB2sgCUF/c2oiCCAETw0FIAdBf3MgBGogDWsiBSAETw0EAkACQCADIAhqLQAAIgggAyAFai0AACIFTwRAIAUgCEYNASAJQQFqIQVBACEHQQEhCiAJIQ0MAgsgDEEBaiIFIA1rIQpBACEHDAELQQAgB0EBaiIIIAggCkYiBRshByAIQQAgBRsgCWohBQsgBiAKRw0BCwtBASEKQQAhB0EBIQVBACEIAkACQAJAAkADQCAFIgkgB2oiDiAESQRAIAQgB2sgCUF/c2oiDCAETw0CIAdBf3MgBGogCGsiBSAETw0DAkACQCADIAxqLQAAIgwgAyAFai0AACIFTQRAIAUgDEYNASAJQQFqIQVBACEHQQEhCiAJIQgMAgsgDkEBaiIFIAhrIQpBACEHDAELQQAgB0EBaiIMIAogDEYiBRshByAMQQAgBRsgCWohBQsgBiAKRw0BCwsgBiAESw0FIAQgDSAIIA0gCEsbayEFIAYNAkEAIQZBACEIDAMLQbCwygAgDCAEEOQCAAtBwLDKACAFIAQQ5AIAC0EAIQhBACEHA0BCASADIAdqMQAAQj+DhiAPhCEPIAYgB0EBaiIHRw0ACwsgBAshCSAAIAM2AjggACABNgIwIABBATYCACAAQTxqIAQ2AgAgAEE0aiACNgIAIABBKGogCTYCACAAQSRqIAg2AgAgAEEgaiACNgIAIABBHGpBADYCACAAQRhqIAY2AgAgAEEUaiAFNgIAIABBEGogCzYCACAAQQhqIA83AgAPCyAGIAQQ5QIAC0HAsMoAIAUgBBDkAgALQbCwygAgCCAEEOQCAAuUCAEJfwJAAkACQAJAAkACQCABKAIEIgIEQCABKAIAIQcCQAJAAkACQAJAAkADQAJ/IANBAWoiBiADIAdqIgotAAAiCEEYdEEYdSIJQX9KDQAaAkACQAJAIAhBsrHKAGotAABBfmoiBUECTQRAIAVBAWsOAgIDAQsgAiADSQ0JIAIgA00NCiAAIAM2AgQgACAHNgIAIAEgAiAGazYCBCABIAYgB2o2AgAMDwsgA0ECaiAGIAdqIgVBACACIAZLGyIEQcWqygAgBBstAABBwAFxQYABRg0CGiACIANJDQggAiADTQ0JDA0LIAYgB2oiBUEAIAIgBksbIgRBxarKACAEGy0AACEEAkACQCAIQaB+aiIIQQ1LDQACQAJAIAhBAWsODQICAgICAgICAgICAgEACyAEQeABcUGgAUYNAgwJCyAEQRh0QRh1QX9KIARBoAFPcg0IDAELIAlBH2pB/wFxQQtNBEAgBEEYdEEYdUF/SiAEQcABT3INCAwBCyAJQf4BcUHuAUcgBEG/AUtyIARBGHRBGHVBf0pyDQcLIANBA2ogByADQQJqIgVqIgZBACACIAVLGyIEQcWqygAgBBstAABBwAFxQYABRg0BGiACIANJDQcgA0F9Sw0KIAIgBUkNCwwOCyAGIAdqIgVBACACIAZLGyIEQcWqygAgBBstAAAhBAJAAkAgCEGQfmoiCEEESw0AAkACQCAIQQFrDgQCAgIBAAsgBEHwAGpB/wFxQTBJDQIMBwsgBEEYdEEYdUF/SiAEQZABT3INBgwBCyAEQb8BSyAJQQ9qQf8BcUECS3IgBEEYdEEYdUF/SnINBQsgByADQQJqIgVqIgZBACACIAVLGyIEQcWqygAgBBstAABBwAFxQYABRw0CIAcgA0EDaiIFaiIGQQAgAiAFSxsiBEHFqsoAIAQbLQAAQcABcUGAAUcNAyADQQRqCyIDIAJJDQALIAFBADYCBCABQcSqygA2AgAgACACNgIEIAAgBzYCACAAQQxqQQA2AgAgAEEIakHEqsoANgIADwsgAiADSQ0DIANBfUsNBiACIAVJDQcMCgsgAiADSQ0CIANBfEsNBSACIAVJDQYgASAGNgIAIAAgAzYCBCAAIAc2AgAgASACIAVrNgIEIABBDGpBAzYCAAwKCyACIANJDQEgAiADTQ0CDAYLIAIgA0kNACACIANNDQEMBQsgAyACEOUCAAsgBiACEOUCAAsgAEEANgIADwsgAyAFEOYCAAsgBSACEOUCAAsgASAFNgIAIAAgAzYCBCAAIAc2AgAgASACIAZrNgIECyAAQQxqQQE2AgAMAQsgASAGNgIAIAAgAzYCBCAAIAc2AgAgASACIAVrNgIEIABBDGpBAjYCAAsgAEEIaiAKNgIAC6MJAgR/LH4jAEHwB2siAiQAIAJByAdqQQBBKBDBBBoDQCABQcAHRgRAAkAgACkDwAEhEyAAKQOYASEFIAApA3AhDSAAKQNIIRQgACkDICEGIAApA7gBIQcgACkDkAEhCiAAKQNoIQggACkDQCEJIAApAxghCyAAKQOwASEVIAApA4gBIRYgACkDYCEXIAApAzghGCAAKQMQIQ4gACkDqAEhGSAAKQOAASEaIAApA1ghGyAAKQMwIRwgACkDCCEdIAApA6ABIQwgACkDeCEeIAApA1AhHyAAKQMoISAgACkDACEhQQAhAUGI98MAIQQDQCABQcAHRg0BIAJBCGogAWoiA0EIaiAOIBiFIBeFIBaFIBWFIg8gBiAUhSANhSAFhSAThSIQQgGJhSIiIAmFQjeJIiM3AwAgA0EQaiANIAkgC4UgCIUgCoUgB4UiESAgICGFIB+FIB6FIAyFIhJCAYmFIgmFQieJIiQ3AwAgA0EgaiAPQgGJIBKFIg8gGYVCAokiEjcDACADQRhqIBAgHCAdhSAbhSAahSAZhSINQgGJhSIQIB6FQimJIiU3AwAgAyAOIBFCAYkgDYUiEYVCPokiJjcDACAPIByFIAkgE4UhDiAjICZCf4WDIBKFIRMgIyAlICRCf4WDhSEZIA8gG4VCCokiJyAHICKFQjiJIiggESAWhUIPiSIpQn+Fg4UhFiAGIAmFQhuJIiogJyAQICCFQiSJIitCf4WDhSEeIAwgEIVCEokiDCARIBiFQgaJIiwgDyAdhUIBiSItQn+Fg4UhDSAFIAmFQgiJIi4gCCAihUIZiSIvQn+FgyAshSEbIBEgFYVCPYkiBSAJIBSFQhSJIgYgCyAihUIciSIHQn+Fg4UhFCAPIBqFQi2JIgggByAFQn+Fg4UhCSAQIB+FQgOJIgsgBSAIQn+Fg4UhGCAIIAtCf4WDIAaFIRwgByALIAZCf4WDhSEgIAogIoVCFYkiBSAQICGFIgYgDkIOiSIHQn+Fg4UhCyARIBeFQiuJIgogByAFQn+Fg4UhDkIsiSIIIAUgCkJ/hYOFIR0gBCkDACAGIAogCEJ/hYOFhSEhIARBCGohBCABQShqIQEgKCArICpCf4WDhSEFIAggBkJ/hYMgB4UhBiAlICYgEkJ/hYOFIQcgKiAoQn+FgyAphSEKIC0gDEJ/hYMgLoUhCCASICVCf4WDICSFIRUgLyAMIC5Cf4WDhSEXICsgKSAnQn+Fg4UhGiAkICNCf4WDICaFIQwgLyAsQn+FgyAthSEfDAALAAsFIAJBCGogAWogAkHIB2pBKBDyAxogAUEoaiEBDAELCyAAIAw3A6ABIAAgHjcDeCAAIB83A1AgACAgNwMoIAAgITcDACAAIBk3A6gBIAAgGjcDgAEgACAbNwNYIAAgHDcDMCAAIB03AwggACAVNwOwASAAIBY3A4gBIAAgFzcDYCAAIBg3AzggACAONwMQIAAgBzcDuAEgACAKNwOQASAAIAg3A2ggACAJNwNAIAAgCzcDGCAAIBM3A8ABIAAgBTcDmAEgACANNwNwIAAgFDcDSCAAIAY3AyAgAkHwB2okAAukCwICfwF+IwBB0AFrIgYkACAGQTRqIAJBJBDyAxogBkEyaiACQSdqLQAAOgAAIAYgAi8AJTsBMCACLQAkIQIgAygCACEHIAMpAgQhCCAGIAE2AlggACgCACEDAn8CQCABRQRAIAMtABBFDQELIAMoAgAhAQJAAkAgACgCBARAIAZBnAFqQQA2AgAgBkH8jsoANgKYASAGQgE3AowBIAZB8I/KADYCiAEgASAGQYgBahDoAg0CIAAoAgAiAS0AEEEBRw0BIAEoAgAgBkEoakGAkMoAELIFIAZBnAFqQQI2AgAgBkGUAWpBATYCACAGQQc2AmQgBkH4j8oANgJgIAZByI/KADYCkAEgBkEBNgKMASAGQfiPygA2AogBIAYgBikDKDcDaCAGIAZB4ABqNgKYASAGQYgBahDoAkUNAQwCCyAGQSBqIANBBGpBywAQpgUgBkGcAWpBATYCACAGQZQBakEBNgIAIAZBkI/KADYCkAEgBkECNgKMASAGQYCPygA2AogBIAYgBikDIDcDYCAGIAZB4ABqNgKYASABIAZBiAFqEOgCDQEgACgCACIBLQAQQQFHDQAgASgCACAGQRhqQcSPygAQsgUgBkGcAWpBAjYCACAGQZQBakEBNgIAIAZBiAE2AmQgBkHIj8oANgKQASAGQQI2AowBIAZBtI/KADYCiAEgBiAGKQMYNwNoIAYgBkHYAGo2AmAgBiAGQeAAajYCmAEgBkGIAWoQ6AINAQsgBkHgAGogBkE0akEkEPIDGiAGQd4AaiAGQTJqLQAAOgAAIAYgBi8BMDsBXCAAKAIAIQECQAJAIAJBA0YNACABLQAQIgNBAUsNACADQQFrBEAgBkGIAWogBkHgAGpBJBDyAxogBkGtAWogBi8BXDsAACAGQawBaiACOgAAIAZBrwFqIAZB3gBqLQAAOgAAIAEoAgAgBkHEAWpBATYCACAGQbwBakEBNgIAIAZBhJDKADYCuAEgBkEBNgK0ASAGQfiPygA2ArABIAZBiQE2AswBIAYgBkHIAWo2AsABIAYgBkGIAWo2AsgBIAZBsAFqEOgCRQ0CDAMLIAZBiAFqIAZB4ABqQSQQ8gMaIAZBrQFqIAYvAVw7AAAgBkGsAWogAjoAACAGQa8BaiAGQd4Aai0AADoAACABKAIAIAZBxAFqQQE2AgAgBkIBNwK0ASAGQfiPygA2ArABIAZBiQE2AswBIAYgBkHIAWo2AsABIAYgBkGIAWo2AsgBIAZBsAFqEOgCRQ0BDAILIAEoAgAgBkGcAWpBADYCACAGQfyOygA2ApgBIAZCATcCjAEgBkGwkMoANgKIASAGQYgBahDoAg0BCyAAKAIAKAIAQbiQygBBARCIBQ0AIAdBAkYgBEEBR3INASAGIAU2ArABAkAgACgCACIBLQAQQQFGBH8gASgCACAGQRBqQcSPygAQsgUgBkGcAWpBAjYCACAGQZQBakEBNgIAIAZBBzYCZCAGQfiPygA2AmAgBkHIj8oANgKQASAGQQE2AowBIAZB+I/KADYCiAEgBiAGKQMQNwNoIAYgBkHgAGo2ApgBIAZBiAFqEOgCDQEgACgCAAUgAQsoAgAgBkGcAWpBADYCACAGQfyOygA2ApgBIAZCATcCjAEgBkHMkMoANgKIASAGQYgBahDoAg0AIAAoAgAiAUEMaigCACECIAEoAgggBkGQAWogCDcDACAGIAc2AowBIAYgASgCACIBNgKIASABIAZBiAFqQQRyIAIoAgwRBAANACAAKAIAKAIAIAZBCGogBkGwAWpBywAQpgUgBkGcAWpBATYCACAGQgI3AowBIAZB2JDKADYCiAEgBiAGKQMINwNgIAYgBkHgAGo2ApgBIAZBiAFqEOgCRQ0CCwtBAQwBCyAAIAAoAgRBAWo2AgRBAAsgBkHQAWokAAv6CQELfyMAQYACayIDJAAQyQQhCyADQRhqEKgDIANBgAFqIAEgAkGI8sgAQQEQICADQQE7AcgBIAMgAjYCxAEgA0EANgLAASADQTBqIANBgAFqQdAAEPIDGiADQYABaiADQTBqQdAAEPIDGiADQYgBaiEMAkACQAJAAkACQANAIAMtAMkBDQEgAygCsAEhBiADQfABaiALAn8CfwJAAkAgAygCgAFBAUcEQCAGIAMoArQBIgdqIQEgAy0AjAEhBCADKAKEASECA0AgAyAHNgLkASADIAY2AuABIAMgAjYC6AEgAyAHNgLsASACRSACIAdGckUEQCAHIAJNDQkgAiAGaiwAAEG/f0wNCQsgBCEJAn8gAiAHRwRAIAIgBmoiCCwAACIFQX9KBEAgBUH/AXEMAgsCfyABIAhBAWpGBEAgASEEQQAMAQsgCEECaiEEIAgtAAFBP3ELIg0gBUEfcSIKQQZ0ciAFQf8BcSIIQd8BTQ0BGgJ/IAEgBEYEQCABIQVBAAwBCyAEQQFqIQUgBC0AAEE/cQsgDUEGdHIiBCAKQQx0ciAIQfABSQ0BGiABIAVGBH9BAAUgBS0AAEE/cQsgCkESdEGAgPAAcSAEQQZ0cnIMAQtBgIDEAAshBSAJRSEEIAkNAyAFQYCAxABHBEACf0EBIAVBgAFJDQAaQQIgBUGAEEkNABpBA0EEIAVBgIAESRsLIAJqIQIMAQsLIAMgAjYChAEgAyAEOgCMASADQQA2AtABDAELIANB0AFqIAwgBiADKAK0ASADKAK4ASADKAK8ASADKAKkAUF/RhBKIAMoAtABQQFGBEAgAygC2AEhAiADKALUAQwDCyADLQDJAQ0FCwJAIAMtAMgBBEAgAygCxAEhAiADKALAASEBDAELIAMoAsQBIgIgAygCwAEiAUYNBQsgA0EBOgDJASACIAFrIQIgAygCsAEgAWoMAgsgAyACNgKEASADIAQ6AIwBIAMgAjYC2AEgAyACNgLUASADQQE2AtABIAILIAMoAsABIQQgAyACNgLAASAEayECIAQgBmoLIAIQfSADLwHwAUEBRwRAIANBGGogAy8B8gEQzgIMAQsLIAAgAykC9AE3AgQgAEEBNgIADAILIANBgAFqIAMoAhggA0EoaiICKAIAQQN0akELbhDvASADKAKEASEEIAMoAoABQQFHDQIgACAENgIEIABBATYCACAAQQhqIANBiAFqKAIANgIADAELIAMgA0HsAWo2AvgBIAMgA0HoAWo2AvQBIAMgA0HgAWo2AvABIANB8AFqEO8EAAsgA0EgahCBBQwBCyADQYABaiIBKAIABEAgAUEEahD6AQsgA0GQAWogAigCADYCACADQYgBaiADQSBqKQMANwMAIAMgAykDGDcDgAEgA0EwaiADQYABahDtAyADQRBqIANBMGoQmwUgAygCFCIBIARBC3YiAksEQCADKAIQIAJqLQAAIANBMGogAhCLBCADQQhqIANBMGoQmwVBACAEa0EHcSIBdkH/AXEgAygCCCADKAIMENoEQf8BcSABdkH/AXFHBEAgA0EANgKAASADIANBgAFqEMEDIAAgAykDADcCBCAAQQE2AgAgA0EwahCBBQwCCyAAIAMpAzA3AgQgAEEANgIAIABBDGogA0E4aigCADYCAAwBC0H48cgAIAIgARDkAgALIANBgAJqJAALigkBCX8jAEHQAGsiAyQAIAFBBGooAgAhBSABKAIAIQIgAS0ACCIGQQZHBEAgA0E3aiABQRhqKAAANgAAIANBMGogAUERaikAADcDACADIAFBCWopAAA3AygLIANBEWogAykDKDcAACADQRlqIANBMGopAwA3AAAgA0EgaiADQTdqKAAANgAAIAMgBjoAECADIAU2AgwgAyACNgIIIAMgAS0AHiIJOgAmIAMgAS0AHSIEOgAlIAMgAS0AHEEARzoAJAJAAkAgBUUgBEH/AXFBAkdyDQACQAJAIAZBAk0EQANAQQAhB0EAIQECQANAIAEgBUYEQCAFIQYMAgsgASACaiABQQFqIQEtAAAiCEEvRw0AC0EBIQcgBSAIQS9GQQFqQQFxIAFqQX9qIgZJDQYLIAYNBCAFIAYgB2oiAUkNAiADIAUgAWsiBTYCDCADIAEgAmoiAjYCCCAFDQAMAwsACwNAQQAhB0EAIQECQAJAA0AgASAFRgRAIAUhBgwCCyABIAJqIAFBAWohAS0AACIIQS9HDQALQQEhByAFIAhBL0ZBAWpBAXEgAWpBf2oiBkkNAQsgBkEBSw0EIAZBAWsgAkHQocoARnJFBEAgAi0AAEEuRw0FCyAFIAYgB2oiAUkNAiADIAUgAWsiBTYCDCADIAEgAmoiAjYCCCAFRQ0DDAELCwwDCyABIAUQ5gIAC0EAIQULAkAgCUECRw0AIANBEGohBwJAA0ACQEEAIQFBACEGAkBBAEEBQX8gBEH/AXEiCBsgCEEBRhtBAWpBAUsiBA0AIAQgAy0AJCIBcg0AIAMtABAiAkF7akH/AXFBAUsNAEEAIQQgAkEGRiICRQRAQQIhBAJAAkACQAJAAkACQEEAIAcgAhsiAi0AAEEBaw4FAQIEAwUACyACKAIIQQRqIQQMBAsgAigCCCACKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAigCCCACKAIQIgRBAWpBACAEG2pBAmohBAwBCyACKAIIQQRqIQQLIAUgBEkNAgsgBCAFRiIJDQAgAygCCCIGIARqIgIgAkEBaiAJGyAFIAZqRiIJIAItAAAiCkEuRnEhBiAJIApBLkdyDQAgAiAEIAVHai0AAEEvRiEGC0EAIQQCQCAIDQAgAy0AEEEGRiICDQBBAiEEAkACQAJAAkACQEEAIAcgAhsiAi0AAEEBaw4FAQIEAwUACyACKAIIQQRqIQQMBAsgAigCCCACKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAigCCCACKAIQIgRBAWpBACAEG2pBAmohBAwBCyACKAIIQQRqIQQLAkAgBSABIAZqIARqSwRAIANBKGogA0EIahAtIAMoAgwhASADKAIsQQVGDQEgASEFCyADKAIIIQIMBAsgASADKAIoIgZrIQUgASAGSQ0CIAMgBTYCDCADLQAlIQQMAQsLIAQgBRDmAgALIAUgARDlAgALIAAgBTYCBCAAIAI2AgAgA0HQAGokAA8LIAhBL0ZBAWpBAXEgAWpBf2ogBRDlAgAL2AkCBX8BfiMAQbAKayIDJAACQAJAIAJBwABGBEAgA0EYaiABQcAAEKIEQSAhAgJ/IAMoAhxBIEcEQEGgucYAIQRBCSEFQQIhBkEBDAELIAMoAhghAiADQfgEaiIEQgA3AwAgA0HwBGpCADcDACADQegEakIANwMAIANCADcD4AQgA0EQaiACQSAQogQgA0HgBGpBICADKAIQIAMoAhQQsAEgA0H2AWogAy0A4gQ6AAAgAyADLwHgBDsB9AEgAyADKQDzBDcDqAMgAyAEKQAANwCtAyADKADjBCEGIAMoAOcEIQQgAygA6wQhBSADKADvBCECQQALIQcgA0GICWogAjYCACADQYQJaiAFNgIAIANBgAlqIAQ2AgAgA0GMCWogAykDqAM3AgAgA0GUCWogA0GwA2opAwA3AgAgA0GcCWogA0G4A2opAwA3AgAgAyAHOgD4CCADIAMvAfQBOwD5CCADIAY2AvwIIAMgA0H2AWotAAA6APsIIAdFDQEgAEEEaiADQfgIakEEckEoEPIDGiAAQQE2AgAMAgsgAEKBgICAIDcDACAAQQxqQoeAgICACDcCACAAQQhqQZC5xgA2AgAMAQsgA0E4aiIEIANB+AhqQQFyIgJBGGopAAA3AwAgA0EwaiACQRBqKQAANwMAIANBKGogAkEIaikAADcDACADIAIpAAA3AyAgA0H4BGoiAkIANwMAIANB8ARqIgVCADcDACADQegEaiIGQgA3AwAgA0IANwPgBCADQQhqIAFBIGpBIBCiBCADQeAEakEgIAMoAgggAygCDBCwASADQZgFaiIBIAIpAwA3AwAgA0GQBWogBSkDADcDACADQYgFaiAGKQMANwMAIAMgAykD4AQ3A4AFIANB+AhqIANBgAVqEGwgAykD+AhCAVEEQCADQYgJaigCACECIAMpA4AJIQggA0HIB2ogA0GMCWpBlAEQ8gMaIANBtAZqIANByAdqQZQBEPIDGiADQaAFaiADQbQGakGUARDyAxogA0H4CGogA0GgBWpBlAEQ8gMaIANBpApqIAEpAwA3AgAgA0GcCmogA0GQBWopAwA3AgAgA0GUCmogA0GIBWopAwA3AgAgAyADKQOABTcCjAogA0GoA2ogA0H4CGpBtAEQ8gMaIANB9AFqIANBqANqQbQBEPIDGiADQUBrIANB9AFqQbQBEPIDGiAAQRBqIAI2AgAgAEEIaiAINwMAIABBFGogA0FAa0G0ARDyAxogAEEANgIAIABB4AFqIAQpAwA3AAAgAEHYAWogA0EwaikDADcAACAAQdABaiADQShqKQMANwAAIABByAFqIAMpAyA3AAAMAQsgA0HYB2ogA0HwCGopAgA3AwAgA0HQB2ogA0HoCGopAgA3AwAgAyADKQLgCDcDyAcgA0G0BmogA0HIB2pBlAEQ8gMaIANBsANqIANBvAZqKQIANwMAIANBuANqIANBxAZqKQIANwMAIAMgAykCtAY3A6gDIANB9AFqIANBqANqQbQBEPIDGiAAQQxqQomAgICABDcCACAAQQhqQZe5xgA2AgAgAEEUaiADKQL0ATcCACAAQRxqIANB/AFqKQIANwIAIABBJGogA0GEAmopAgA3AgAgAEIBNwMAIANBIGoQswILIANBsApqJAALlQgCAX8tfiAAKQPAASEOIAApA5gBIQIgACkDcCEPIAApA0ghECAAKQMgIQMgACkDuAEhBCAAKQOQASEHIAApA2ghBSAAKQNAIQogACkDGCEIIAApA7ABIREgACkDiAEhEiAAKQNgIRMgACkDOCEUIAApAxAhBiAAKQOoASEVIAApA4ABIRYgACkDWCEXIAApAzAhGCAAKQMIIRkgACkDoAEhCSAAKQN4IRogACkDUCEbIAApAyghHCAAKQMAIR1BwH4hAQNAIAEEQCAcIB2FIBuFIBqFIAmFIgsgBiAUhSAThSAShSARhSIMQgGJhSIeIBiFIA4gCCAKhSAFhSAHhSAEhSINIAtCAYmFIguFIS4gFSAehUICiSIgIAogAyAQhSAPhSAChSAOhSIfQgGJIAyFIgyFQjeJIiEgBiAYIBmFIBeFIBaFIBWFIgogDUIBiYUiDYVCPokiIkJ/hYOFIQ4gISAfIApCAYmFIgYgGoVCKYkiHyALIA+FQieJIiNCf4WDhSEVIBcgHoVCCokiJCAEIAyFQjiJIiUgDSAShUIPiSImQn+Fg4UhEiADIAuFQhuJIicgJCAGIByFQiSJIihCf4WDhSEaIAYgCYVCEokiCSANIBSFQgaJIikgGSAehUIBiSIqQn+Fg4UhDyACIAuFQgiJIisgBSAMhUIZiSIsQn+FgyAphSEXIA0gEYVCPYkiAiALIBCFQhSJIgMgCCAMhUIciSIEQn+Fg4UhECAWIB6FQi2JIgUgBCACQn+Fg4UhCiAGIBuFQgOJIgggAiAFQn+Fg4UhFCAFIAhCf4WDIAOFIRggBCAIIANCf4WDhSEcIAcgDIVCFYkiAiAGIB2FIgMgLkIOiSIEQn+Fg4UhCCANIBOFQiuJIgcgBCACQn+Fg4UhBkIsiSIFIAIgB0J/hYOFIRkgAUHYw8QAaikDACADIAcgBUJ/hYOFhSEdIAFBCGohASAlICggJ0J/hYOFIQIgBSADQn+FgyAEhSEDIB8gIiAgQn+Fg4UhBCAnICVCf4WDICaFIQcgKiAJQn+FgyArhSEFICAgH0J/hYMgI4UhESAsIAkgK0J/hYOFIRMgKCAmICRCf4WDhSEWICMgIUJ/hYMgIoUhCSAsIClCf4WDICqFIRsMAQUgACAJNwOgASAAIBo3A3ggACAbNwNQIAAgHDcDKCAAIB03AwAgACAVNwOoASAAIBY3A4ABIAAgFzcDWCAAIBg3AzAgACAZNwMIIAAgETcDsAEgACASNwOIASAAIBM3A2AgACAUNwM4IAAgBjcDECAAIAQ3A7gBIAAgBzcDkAEgACAFNwNoIAAgCjcDQCAAIAg3AxggACAONwPAASAAIAI3A5gBIAAgDzcDcCAAIBA3A0ggACADNwMgCwsLyAgBDX8jAEEwayIEJABBASEOAkACQCACKAIYQSIgAkEcaigCACgCEBECAA0AAkAgAUUNACAAIAFqIQwgACEIAkACQANAIAghDyAIQQFqIQkCQAJ/IAgsAAAiBUF/TARAAn8gCSAMRgRAQQAhBiAMDAELIAgtAAFBP3EhBiAIQQJqIgkLIQggBiAFQR9xIg1BBnRyIAVB/wFxIgdB3wFNDQEaAn8gCCAMRgRAIAwhBUEADAELIAhBAWoiCSEFIAgtAABBP3ELIAZBBnRyIgYgDUEMdHIgB0HwAUkNARoCfyAFIAxGBEBBACELIAkMAQsgBS0AAEE/cSELIAVBAWoLIQggDUESdEGAgPAAcSAGQQZ0ciALciILQYCAxABHDQIMBQsgBUH/AXELIQsgCSEICyAEIAsQfwJAAkACQAJAIAQoAgAiCUEBaw4DAgEAAQsgBCgCCCAELQAMakEBRg0BCyAEIAE2AhQgBCAANgIQIAQgAzYCGCAEIAo2AhwgCiADSQ0DIANFIAEgA0ZyRQRAIAMgAU8NBCAAIANqLAAAQb9/TA0ECyAKRSABIApGckUEQCAKIAFPDQQgACAKaiwAAEG/f0wNBAsgAigCGCAAIANqIAogA2sgAigCHCgCDBEEAA0BIAQtAAwhByAEKAIIIQUCQCAEKAIEIgZBgIDEAEYEQANAIAkhA0EBIQlB3AAhBgJAAkAgA0ECaw4CAQAECyAHQf8BcSEDQQMhCUEEIQcCQAJAAkACQCADQQFrDgUDAgEABAcLQQMhB0H1ACEGDAMLQQIhB0H7ACEGDAILQQJBASAFGyEHQYCAxAAgBUECdEEccXZBD3FBMHIhBiAFQX9qQQAgBRshBQwBC0EAIQdB/QAhBgsgAigCGCAGIAIoAhwoAhARAgBFDQAMBAsACwNAIAkhDUEBIQlB3AAhAwJAAkACQAJAIA1BAWsOAwEDAAULIAdB/wFxIQ1BAyEJQQQhBwJAAkACQCANQQFrDgUCAQAEBQcLQQIhB0H7ACEDDAQLIAYgBUECdEEccXZBD3EiA0EwciADQdcAaiADQQpJGyEDQQJBASAFGyEHIAVBf2pBACAFGyEFDAMLQQAhB0H9ACEDDAILQQAhCSAGIQMMAQtBAyEHQfUAIQMLIAIoAhggAyACKAIcKAIQEQIARQ0ACwwCCwJ/QQEgC0GAAUkNABpBAiALQYAQSQ0AGkEDQQQgC0GAgARJGwsgCmohAwsgCiAPayAIaiEKIAggDEcNAQwDCwsMAwsgBCAEQRxqNgIoIAQgBEEYajYCJCAEIARBEGo2AiAgBEEgahDvBAALIANFIAEgA0ZyDQAgAyABTw0CIAAgA2osAABBv39MDQILIAIoAhggACADaiABIANrIAIoAhwoAgwRBAANACACKAIYQSIgAigCHCgCEBECACEOCyAEQTBqJAAgDg8LIAAgASADIAEQKQALuAgBBn8jAEHwAGsiBCQAIAQgAzYCDCAEIAI2AghBASEHIAEhBgJAIAFBgQJJDQBBACABayEIQYACIQUDQAJAIAUgAU8NACAAIAVqLAAAQb9/TA0AQQAhByAFIQYMAgsgBUF/aiEGQQAhByAFQQFGDQEgBSAIaiAGIQVBAUcNAAsLIAQgBjYCFCAEIAA2AhAgBEEAQQUgBxs2AhwgBEHEqsoAQbKzygAgBxs2AhgCQAJAAkAgAiABSyIFIAMgAUtyRQRAIAIgA0sNAQJAIAJFIAEgAkZyRQRAIAEgAk0NASAAIAJqLAAAQUBIDQELIAMhAgsgBCACNgIgIAJFIAEgAkZyDQIgAUEBaiEDA0AgAiABSQRAIAAgAmosAABBQE4NBAsgAkF/aiEFIAJBAUYNBCACIANGIAUhAkUNAAsMAwsgBCACIAMgBRs2AiggBEHEAGpBAzYCACAEQdwAakG0ATYCACAEQdQAakG0ATYCACAEQgM3AjQgBEHYs8oANgIwIARBywA2AkwgBCAEQcgAajYCQCAEIARBGGo2AlggBCAEQRBqNgJQIAQgBEEoajYCSCAEQTBqQfCzygAQvQQACyAEQeQAakG0ATYCACAEQdwAakG0ATYCACAEQdQAakHLADYCACAEQcQAakEENgIAIARCBDcCNCAEQaS0ygA2AjAgBEHLADYCTCAEIARByABqNgJAIAQgBEEYajYCYCAEIARBEGo2AlggBCAEQQxqNgJQIAQgBEEIajYCSCAEQTBqQcS0ygAQvQQACyACIQULAkAgASAFRg0AQQEhBgJAAkACQCAAIAVqIgMsAAAiAkF/TARAQQAhByAAIAFqIgAhASAAIANBAWpHBEAgAy0AAUE/cSEHIANBAmohAQsgAkEfcSEDIAJB/wFxQd8BSw0BIAcgA0EGdHIhAQwCCyAEIAJB/wFxNgIkIARBKGohAgwCC0EAIQggACIGIAFHBH8gAUEBaiEGIAEtAABBP3EFIAgLIAdBBnRyIQEgAkH/AXFB8AFJBEAgASADQQx0ciEBDAELQQAhAiAAIAZHBH8gBi0AAEE/cQUgAgsgA0ESdEGAgPAAcSABQQZ0cnIiAUGAgMQARg0CCyAEIAE2AiRBASEGIARBKGohAiABQYABSQ0AQQIhBiABQYAQSQ0AQQNBBCABQYCABEkbIQYLIAQgBTYCKCAEIAUgBmo2AiwgBEHEAGpBBTYCACAEQewAakG0ATYCACAEQeQAakG0ATYCACAEQdwAakG1ATYCACAEQdQAakG2ATYCACAEQgU3AjQgBEGYtcoANgIwIAQgAjYCWCAEQcsANgJMIAQgBEHIAGo2AkAgBCAEQRhqNgJoIAQgBEEQajYCYCAEIARBJGo2AlAgBCAEQSBqNgJIIARBMGpBwLXKABC9BAALQemqygBBK0HUtMoAEM4DAAvpBgIBfxR+IwBB8AFrIgMkACABKQMgIQUgASkDGCEGIAEpAxAhBCABKQMIIQcgASkDACEIA0AgA0HwAGogCCAHEJ4CIANBMGogBCAFQhN+IgoQngIgA0HgAWogBkITfiIJIAYQngIgA0FAayAJIAQQngIgA0GAAWogByAKEJ4CIANBIGogCCAEEJ4CIANB0AFqIAkgBRCeAiADQRBqIAcgBBCeAiADQaABaiAIIAYQngIgA0HAAWogCiAFEJ4CIANB0ABqIAcgBhCeAiADQZABaiAIIAUQngIgA0GwAWogCCAIEJ4CIANB4ABqIAcgBxCeAiADIAQgBBCeAiADKQOQASIOIAMpA1B8IgRCAYYiDyADKQMAfCIHIAMpA6ABIhAgAykDEHwiCEIBhiIRIAMpA8ABfCIFIAMpAyAiEiADKQPQAXwiBkIBhiITIAMpA2B8IgogAykDcCIUIAMpAzB8IglCAYYiFSADKQPgAXwiDCADKQOAASIWIAMpA0B8IgtCAYYiFyADKQOwAXwiDUIziCANIBdUrSADQbgBaikDACALIBZUrSADQYgBaikDACADQcgAaikDAHx8QgGGIAtCP4iEfHxCDYaEfCILQjOIIAsgDFStIAwgFVStIANB6AFqKQMAIAkgFFStIANB+ABqKQMAIANBOGopAwB8fEIBhiAJQj+IhHx8fEINhoR8IglCM4ggCSAKVK0gCiATVK0gA0HoAGopAwAgBiASVK0gA0EoaikDACADQdgBaikDAHx8QgGGIAZCP4iEfHx8Qg2GhHwiBkIziCAGIAVUrSAFIBFUrSADQcgBaikDACAIIBBUrSADQagBaikDACADQRhqKQMAfHxCAYYgCEI/iIR8fHxCDYaEfCIFQjOIIAUgB1StIAcgD1StIANBCGopAwAgBCAOVK0gA0GYAWopAwAgA0HYAGopAwB8fEIBhiAEQj+IhHx8fEINhoRCE34gDUL/////////A4N8IgRC/////////wODIQggC0L/////////A4MgBEIziHwhByAFQv////////8DgyEFIAZC/////////wODIQYgCUL/////////A4MhBCACQX9qIgINAAsgACAFNwMgIAAgBjcDGCAAIAQ3AxAgACAHNwMIIAAgCDcDACADQfABaiQAC5AIAQl/IwBBwAZrIgMkAAJAAkAgAkHgAEYEQEHAACECIANBCGogAUHgAEHAABCeBAJ/IAMoAgxBwABHBEBBAyEEQdH+wQAhBUEJIQZB2v7BACEIQckAIQlBAQwBCyADKAIIIQIgA0H4BWoiBEIANwMAIANB8AVqIgVCADcDACADQegFaiIGQgA3AwAgA0IANwPgBSADQeAFakEgIAJBIBCtASADQeAFahDIAyADQbACaiAEKQMANwMAIANBqAJqIAUpAwA3AwAgA0GgAmogBikDADcDACADIAMpA+AFNwOYAiADQYAGaiADQZgCahC7AyADQbgGaiIHQgA3AwAgA0GwBmoiCkIANwMAIANBqAZqIgtCADcDACADQgA3A6AGIANBoAZqQSAgAkEgakEgEK0BIANB1gBqIAMtAIIGOgAAIANB0gBqIAMtAIYGOgAAIANB3ABqIANBnwZqLQAAOgAAIAMgAy8BgAY7AVQgAyADLwGEBjsBUCADIAMoAJsGNgJYIAMtAIMGIQQgAygAhwYhBSADKACLBiEGIAMoAI8GIQggAygAkwYhCSADKACXBiECIANB9QBqIAcpAwA3AAAgA0HtAGogCikDADcAACADQeUAaiALKQMANwAAIAMgAykDoAY3AF0gA0GYAmogA0HYAGpBJRDyAxpBAAshByADQfgDaiACNgIAIANB9ANqIAk2AgAgA0HwA2ogCDYCACADQewDaiAGNgIAIANB6ANqIAU2AgAgAyAHOgDgAyADIAMvAVQ7AOEDIAMgBDoA5AMgAyADLwFQOwDlAyADIANB1gBqLQAAOgDjAyADIANB0gBqLQAAOgDnAyADQfwDaiADQZgCakEoEPIDGiADQeADakEEciECIAdFDQEgAEEBNgIAIAAgAikCADcCBCAAQRRqIAJBEGopAgA3AgAgAEEMaiACQQhqKQIANwIAIANB4ANqIgAtAABFBEAgAEEBahCfAQsMAgsgAEEDOgAEIABBATYCACAAQRRqQqSAgICADDcCACAAQRBqQYrwwwA2AgAgAEEMakEHNgIAIABBCGpBg/DDADYCAAwBCyADQRBqIANB4ANqQQFyQcAAEPIDGiADIAFB4ABBwAAQnQQgA0HgA2ogAygCACADKAIEEGkgAygC4AMgA0GYAmogAkHEARDyAxpBAUcEQCADQdgAaiADQZwCakHAARDyAxogA0HgA2ogA0HYAGpBwAEQ8gMaIANBoAVqIANBEGpBwAAQ8gMaIABBCGogA0HgA2pBgAIQ8gMaIABBADYCAAwBCyAAIAMpApgCNwIEIABBATYCACAAQRRqIANBqAJqKQIANwIAIABBDGogA0GgAmopAgA3AgAgA0EQahCfAQsgA0HABmokAAvoBwIJfwR+IwBBsARrIgYkAAJAIAFBwABHDQAgBkHoA2pCADcDACAGQeADakIANwMAIAZB2ANqQgA3AwAgBkIANwPQAyAGQSBqIgFCADcDACAGQRhqIgdCADcDACAGQRBqIghCADcDACAGQgA3AwggBkHQA2pBICAAQSAQrgEgBkEIakEgIABBIGpBIBCuASAGLAAnIgBBf0oNACAGIABB/wBxOgAnIAZB4ABqIAEpAwA3AwAgBkHYAGogBykDADcDACAGQdAAaiAIKQMANwMAIAYgBikDCDcDSCAGQYgCaiAGQcgAahDMAUEBIQECfyAGLQCIAkEBRwRAIAZBpwRqIAZB1wBqKQAANwAAIAZBoARqIAZB0ABqKQAANwMAIAYgBikASDcDmARBAgwBCyAGQaAEaiAGQZUCaikAADcDACAGQacEaiAGQZwCaikAADcAACAGQZQEaiAGQagCai0AADoAACAGIAYpAI0CNwOYBCAGIAZBpAJqKAIANgKQBCAGLwCJAiAGLQCLAkEQdHIhDUEAIQEgBi0AjAILIQAgBkGABGoiByAGQaAEaiIIKQMANwMAIAZBhwRqIgkgBkGnBGoiCykAADcAACAGQfQDaiIKIAZBlARqIgwtAAA6AAAgBiAGKQOYBDcD+AMgBiAGKAKQBDYC8AMgAQRAIAZBkQJqIAcpAwA3AAAgBkGYAmogCSkAADcAACAGIAA6AIgCIAYgBikD+AM3AIkCIAZByABqIAZBiAJqEKoEIAZBAmogBi0ASzoAACAGIAYvAEk7AQAMAQsgCyAJKQAANwAAIAggBykDADcDACAMIAotAAA6AAAgBkEGaiIBIAYtANIDOgAAIAYgBikD+AM3A5gEIAYgBigC8AM2ApAEIAYgBi8B0AM7AQQgBi0A0wMhByAGQQJqIgkgBi0A1gM6AAAgBiAGLwHUAzsBACAGQe8DajEAACEPIAYpANcDIRAgBikA3wMhESAGKADnAyEKIAY1AOsDIRIgBkEraiAAOgAAIAYgBzoACyAGIAEtAAA6AAogBiAGLwEEOwEIIAYgEiAPQiCGhCANrUIohoQ3ACMgBiAKNgAfIAYgETcAFyAGIBA3AA8gBiAGLwEAOwEMIAYgCS0AADoADiAGQSxqIAYpA5gENwIAIAZBNGogCCkDADcCACAGQTtqIAspAAA3AAAgBkHHAGogDC0AADoAACAGQcMAaiAGKAKQBDYAACAGQYgCaiAEIAUQXiAGQcgAaiAGQYgCakGYhMAAEMcCIAZBiAJqIAZByABqIAIgAyAGQQhqEOQBIAYtAIgCQQdGIQ4LIAZBsARqJAAgDgvUBgENfyMAQSBrIgokAAJAAkACQEEAQQFBfyABLQAdIggbIAhBAUYbQQFqQQFLIgINACACIAEtABwiBnINACABLQAIIgNBe2pB/wFxQQFLDQAgASgCBCEHQQAhAiADQQZGIgNFBEBBAiECAkACQAJAAkACQAJAQQAgAUEIaiADGyIDLQAAQQFrDgUBAgQDBQALIAMoAghBBGohAgwECyADKAIIIAMoAhAiAkEBakEAIAIbakEIaiECDAMLQQYhAgwCCyADKAIIIAMoAhAiAkEBakEAIAIbakECaiECDAELIAMoAghBBGohAgsgByACSQ0CCyACIAdGIgkNACABKAIAIgQgAmoiAyADQQFqIAkbIAQgB2pGIgkgAy0AACILQS5GcSEEIAkgC0EuR3INACADIAIgB0dqLQAAQS9GIQQLAkAgCA0AIAEtAAhBBkYiAg0AQQIhBQJAAkACQAJAAkBBACABQQhqIAIbIgItAABBAWsOBQECBAMFAAsgAigCCEEEaiEFDAQLIAIoAgggAigCECICQQFqQQAgAhtqQQhqIQUMAwtBBiEFDAILIAIoAgggAigCECICQQFqQQAgAhtqQQJqIQUMAQsgAigCCEEEaiEFCyABKAIEIgMgBCAGaiAFaiIHSQ0BIAEoAgAiCCAHaiECIAMgCGoiCUF/aiELIAUgBmogBGoiDCADayENQQAhBEEAIQYCQANAIAYgDUYNASAGIAtqIAZBf2oiBSEGLQAAQS9HDQALQQEhBCADIAkgDGogAmsiAiAFakEBaiIHSQ0CIAIgCGogBWpBAWohAgsgBCADIAdrIgZqIQVBBCEEAkAgBkECSw0AAkACQAJAIAZBAWsOAgABAgsgAkHQocoARwRAIAItAABBLkcNAwtBAkEFQQIgAS0ACCIBQQNJIAFBBkYbIgFBAXEbQQUgAUECRxshBAwCCyACQeOhygBHBEAgAi8AAEGu3ABHDQILQQMhBAwBC0EFIQQLIAAgBDYCBCAAIAU2AgAgAEEMaiAGNgIAIABBCGogAjYCACAAQRBqIAopAgw3AgAgAEEYaiAKQRRqKQIANwIAIABBIGogCkEcaigCADYCACAKQSBqJAAPCyACIAcQ5gIACyAHIAMQ5gIAC8QGAQt/IABBEGooAgAhAwJAAkACQAJAIABBCGooAgAiDUEBRwRAIANBAUYNASAAKAIYIAEgAiAAQRxqKAIAKAIMEQQAIQMMAwsgA0EBRw0BCwJAIAJFBEBBACECDAELIAEgAmohCCAAQRRqKAIAQQFqIQsgASIDIQkDQCADQQFqIQUCQAJ/IAMsAAAiBEF/TARAAn8gBSAIRgRAQQAhCiAIDAELIAMtAAFBP3EhCiADQQJqIgULIQcgCiAEQR9xIgxBBnRyIARB/wFxIgNB3wFNDQEaAn8gByAIRgRAQQAhBCAIDAELIActAABBP3EhBCAHQQFqIgULIQcgBCAKQQZ0ciIEIAxBDHRyIANB8AFJDQEaAn8gByAIRgRAIAUhA0EADAELIAdBAWohAyAHLQAAQT9xCyAMQRJ0QYCA8ABxIARBBnRyciIEQYCAxABHDQIMBAsgBEH/AXELIQQgBSEDCyALQX9qIgsEQCAGIAlrIANqIQYgAyEJIAMgCEcNAQwCCwsgBEGAgMQARg0AAkAgBkUgAiAGRnJFBEBBACEDIAYgAk8NASABIAZqLAAAQUBIDQELIAEhAwsgBiACIAMbIQIgAyABIAMbIQELIA1BAUYNAAwCC0EAIQUgAgRAIAIhBCABIQMDQCAFIAMtAABBwAFxQYABRmohBSADQQFqIQMgBEF/aiIEDQALCyACIAVrIAAoAgwiCU8NAUEAIQZBACEFIAIEQCACIQQgASEDA0AgBSADLQAAQcABcUGAAUZqIQUgA0EBaiEDIARBf2oiBA0ACwsgBSACayAJaiIDIQQCQAJAAkBBACAALQAgIgUgBUEDRhtBAWsOAwEAAQILIANBAXYhBiADQQFqQQF2IQQMAQtBACEEIAMhBgsgBkEBaiEDAkADQCADQX9qIgNFDQEgACgCGCAAKAIEIAAoAhwoAhARAgBFDQALQQEPCyAAKAIEIQVBASEDIAAoAhggASACIAAoAhwoAgwRBAANACAEQQFqIQMgACgCHCEBIAAoAhghAANAIANBf2oiA0UEQEEADwsgACAFIAEoAhARAgBFDQALQQEPCyADDwsgACgCGCABIAIgAEEcaigCACgCDBEEAAvDBwIGfwJ+AkACQAJAAkAgAkUNAEEAIAFrQQAgAUEDcRshCCACQXlqQQAgAkEHSxshBwNAAkAgASAEai0AACIFQRh0QRh1IgZBf0wEQEKAgICAgCAhCiAFQbKxygBqLQAAQX5qIgNBAksEQEKAgICAECEJDAcLAkACQAJAAkACQCADQQFrDgIBAgALIARBAWoiAyACSQ0CQgAhCQwJC0IAIQkgBEEBaiIDIAJPDQggASADai0AACEDAkACQCAFQaB+aiIFQQ1LDQACQAJAIAVBAWsODQICAgICAgICAgICAgEACyADQeABcUGgAUYNAkKAgICAECEJDAwLIANBGHRBGHVBf0oEQEKAgICAECEJDAwLIANBoAFJDQFCgICAgBAhCQwLCyAGQR9qQf8BcUELTQRAIANBGHRBGHVBf0oEQEKAgICAECEJDAwLIANBwAFJDQFCgICAgBAhCQwLCyADQb8BSwRAQoCAgIAQIQkMCwsgBkH+AXFB7gFHBEBCgICAgBAhCQwLCyADQRh0QRh1QX9MDQBCgICAgBAhCQwKC0IAIQogBEECaiIDIAJPDQkgASADai0AAEHAAXFBgAFGDQIMBwtCACEJIARBAWoiAyACTw0HIAEgA2otAAAhAwJAAkAgBUGQfmoiBUEESw0AAkACQCAFQQFrDgQCAgIBAAsgA0HwAGpB/wFxQTBJDQJCgICAgBAhCQwLCyADQRh0QRh1QX9KBEBCgICAgBAhCQwLCyADQZABSQ0BQoCAgIAQIQkMCgsgA0G/AUsEQEKAgICAECEJDAoLIAZBD2pB/wFxQQJLBEBCgICAgBAhCQwKCyADQRh0QRh1QX9MDQBCgICAgBAhCQwJCyAEQQJqIgMgAk8NByABIANqLQAAQcABcUGAAUcNBkIAIQogBEEDaiIDIAJPDQggASADai0AAEHAAXFBgAFGDQFCgICAgIDgACEKQoCAgIAQIQkMCAtCgICAgBAhCSABIANqLQAAQcABcUGAAUcNBwsgA0EBaiEEDAELIAggBGtBA3FFBEACQCAEIAdPDQADQCABIARqIgNBBGooAgAgAygCAHJBgIGChHhxDQEgBEEIaiIEIAdJDQALCyAEIAJPDQEDQCABIARqLAAAQQBIDQIgAiAEQQFqIgRHDQALDAMLIARBAWohBAsgBCACSQ0ACwsgACABNgIEIABBCGogAjYCACAAQQA2AgAPC0KAgICAgMAAIQpCgICAgBAhCQwBC0IAIQoLIAAgCSAErYQgCoQ3AgQgAEEBNgIAC9cGAQx/IwBBwAFrIgUkAAJ/IAIEQEEBIAEtAABBL0YNARoLQQALIQYgBSAFKABgNgIIIAUgBUHjAGooAAA2AAsCfyAEBEBBASADLQAAQS9GDQEaC0EACyEHIAVBKWogBSgAYDYAACAFQSxqIAVB4wBqKAAANgAAIAVBBjoAKCAFIAQ2AiQgBSADNgIgIAVBgAQ7AD0gBSAHOgA8IAVBhAFqIQwgBUHgAGpBBHIhDSAFQckAaiEDIAVBgAFqIQRBAiEIQQYhBwJ/AkADQCAHQQZHBEAgBUHvAGogBUEXaigAADYAACAFQegAaiAFQRBqKQIANwMAIAUgBSkCCDcDYAsgAyAFKQNgNwAAIANBCGoiDiAFQegAaikDADcAACADQQ9qIg8gBUHvAGooAAA2AAAgBSAHOgBIIAUgAjYCRCAFIAE2AkAgBSAIOgBeIAUgCzoAXSAFIAZBAEc6AFwgBUHgAGogBUFAaxAcIAVBoAFqIAVBIGoQHCAEQRhqIAVBuAFqKQMANwIAIARBEGogBUGwAWopAwA3AgAgBEEIaiAFQagBaikDADcCACAEIAUpA6ABNwIAIAUoAoABIQkCQCAFKAJgIgpBBUYEQCAJQQVHDQMMAQsgCUEFRg0AIAkgCkcNAgJAIApBBEsNAAJAAkAgCkEBaw4EAgICAAELIAUoAmgiASAFKAKIAUcNBCAFKAJkIgIgBSgChAEiBkYNASACIAYgARC0Aw0EDAELIA0gDBBPRQ0DCyAFQRBqIA4pAAA3AwAgBUEXaiAPKAAANgAAIAUgAykAADcDCCAFKAJAIQEgBSgCRCECIAUtAEghByAFLQBcIQYgBS0AXSELIAUtAF4hCCAFLQBfIRAMAQsLIAVBrwFqIgQgBUEXaigAADYAACAFQagBaiIDIAVBEGopAwA3AwAgBSAFKQMINwOgASAGQQJGDQAgBUHpAGogBSkDoAE3AAAgBUHxAGogAykDADcAACAFQfgAaiAEKAAANgAAIAUgBzoAaCAFIAI2AmQgBSABNgJgIAUgEDoAfyAFIAg6AH4gBSALOgB9IAUgBjoAfCAFIAVB4ABqECUgBSgCBCEEIAUoAgAMAQtBAAshASAAIAQ2AgQgACABNgIAIAVBwAFqJAALogYCC38BfiMAQeACayIBJAAgABDEAiIGKAIkIQIgAUIANwMQIAZBJGohCSABQRhqIQcgAUEcaiELA0ACQCACRQRAIAZBIGoQ0AQgASgCFCEDIAECfyABKAIQIgRBCE0EQCABKAIcDAELIAEoAhwLIgA2AsACIAEgBDYC0AIgASgCGCEIIAFB0AFqIAFBIGpB2AAQ8gMaQQAhAiABQcACaiABQdACaiAEQQhLIgcbQQA2AgAgASgC0AIhBiABKALAAiEFIAFB+ABqIAFB0AFqQdgAEPIDGiABQdwBaiAFNgIAIAFB2AFqIgUgCDYCACABIAM2AtQBIAEgBjYC0AEgAUHgAWogAUH4AGpB2AAQ8gMaIAEgACAEIAcbIgM2ArwCIAFBADYCuAIMAQsgAigCGCEEIAAgAigCFEcEQCACQRhqIQkgAiEIIAQhAgwCCyAJIAQ2AgAgAiAGKAIoRgRAIAYgCDYCKAsgAkEANgIcIAFB0AFqIAIQmQMCQAJ/IAEoAhAiA0EISyIFRQRAQQghAiADDAELIAMhAiABKAIcCyIKIAJHDQACfyAFRQRAQQghAiADDAELIAMhAiABKAIcCyEFIAIgBUcNACABQQhqIAVBAWoiAiAFTyACEMIDIAFBEGogASgCDEF/IAEoAggbEKUBIAEoAhAhAwsCfyADQQhNBEAgByECIAFBEGoMAQsgASgCGCECIAsLIApBAWo2AgAgAiAKQQxsaiICIAEpA9ABNwIAIAJBCGogAUHYAWooAgA2AgAgBCECDAELCwNAAkAgAiADRgRAIAFBAjoA2AIMAQsgASACQQFqNgK4AiABQdgCaiIAAn8gBSABKALQAUEITQ0AGiABKALYAQsgAkEMbGoiAkEIaigCACIENgIAIAEgAikCADcD0AIgBEH/AXFBAkYNACABQcgCaiAAKAIAIgI2AgAgASABKQPQAiIMNwPAAiAAIAI2AgAgASAMNwPQAiABQdACahDzBCABKAK8AiEDIAEoArgCIQIMAQsLIAFB0AJqEP8DIAFB0AFqEMUCIAFB0AFqEJ0CIAFB4AJqJAALlQYBB38CQAJAAkACQAJAAkACQAJAAkAgAEGAgARPBEAgAEGAgAhJDQEgAEHii3RqQeKNLEkgAEGfqHRqQZ8YSXIgAEH+//8AcUGe8ApGIABB3uJ0akEOSXJyIABBqbJ1akEpSSAAQcuRdWpBC0lycg0IIABBkPxHakGP/AtLDwsgAEGA/gNxQQh2IQZBgLbKACEBIABB/wFxIQcDQCABQQJqIQUgAiABLQABIgRqIQMgBiABLQAAIgFHBEAgASAGSw0IIAMhAiAFIgFB0rbKAEcNAQwICyADIAJJDQIgA0GlAksNAyACQdK2ygBqIQECQANAIARFDQEgBEF/aiEEIAEtAAAgAUEBaiEBIAdHDQALQQAhBAwJCyADIQIgBSIBQdK2ygBHDQALDAYLIABBgP4DcUEIdiEGQbG7ygAhASAAQf8BcSEHA0AgAUECaiEFIAIgAS0AASIEaiEDIAYgAS0AACIBRwRAIAEgBksNBiADIQIgBSIBQfe7ygBHDQEMBgsgAyACSQ0DIANBpgFLDQQgAkH3u8oAaiEBAkADQCAERQ0BIARBf2ohBCABLQAAIAFBAWohASAHRw0AC0EAIQQMCAsgAyECIAUiAUH3u8oARw0ACwwECyACIAMQ5gIACyADQaUCEOUCAAsgAiADEOYCAAsgA0GmARDlAgALIABB//8DcSEAQZ29ygAhAUEBIQQDQAJAAn8gAUEBaiIDIAEtAAAiAkEYdEEYdSIFQQBODQAaIANBtcDKAEYNASABLQABIAVB/wBxQQh0ciECIAFBAmoLIQEgACACayIAQQBIDQMgBEEBcyEEIAFBtcDKAEcNAQwDCwtB6arKAEErQfC1ygAQzgMACyAAQf//A3EhAEH3uMoAIQFBASEEA0ACfyABQQFqIgMgAS0AACICQRh0QRh1IgVBAE4NABogA0Gxu8oARg0DIAEtAAEgBUH/AHFBCHRyIQIgAUECagshASAAIAJrIgBBAEgNASAEQQFzIQQgAUGxu8oARw0ACwsgBEEBcQ8LQemqygBBK0HwtcoAEM4DAAuhBgEKfyMAQTBrIgMkACADQSRqIAE2AgAgA0EDOgAoIANCgICAgIAENwMIIAMgADYCICADQQA2AhggA0EANgIQAkACQAJAIAIoAggiBQRAIAIoAgAhByACKAIEIgkgAkEMaigCACIEIAQgCUsbIgtFDQEgAkEUaigCACEIIAIoAhAhCkEBIQQgACAHKAIAIAcoAgQgASgCDBEEAA0DIAdBDGohAkEBIQYCQAJAA0AgAyAFQQRqKAIANgIMIAMgBUEcai0AADoAKCADIAVBCGooAgA2AgggBUEYaigCACEEQQAhAUEAIQACQAJAAkAgBUEUaigCAEEBaw4CAAIBCyAEIAhPDQMgBEEDdCAKaiIMKAIEQbcBRw0BIAwoAgAoAgAhBAtBASEACyADIAQ2AhQgAyAANgIQIAVBEGooAgAhBAJAAkACQCAFQQxqKAIAQQFrDgIAAgELIAQgCE8NBCAEQQN0IApqIgAoAgRBtwFHDQEgACgCACgCACEEC0EBIQELIAMgBDYCHCADIAE2AhggBSgCACIAIAhJBEAgCiAAQQN0aiIAKAIAIANBCGogACgCBBECAA0GIAYgC08NBSACQXxqIQAgAigCACEBIAJBCGohAiAFQSBqIQVBASEEIAZBAWohBiADKAIgIAAoAgAgASADKAIkKAIMEQQARQ0BDAcLC0G0rsoAIAAgCBDkAgALQcSuygAgBCAIEOQCAAtBxK7KACAEIAgQ5AIACyACKAIAIQcgAigCBCIJIAJBFGooAgAiBCAEIAlLGyIIRQ0AIAIoAhAhBUEBIQQgACAHKAIAIAcoAgQgASgCDBEEAA0CIAdBDGohAkEBIQYDQCAFKAIAIANBCGogBUEEaigCABECAA0CIAYgCE8NASACQXxqIQAgAigCACEBIAJBCGohAiAFQQhqIQUgBkEBaiEGIAMoAiAgACgCACABIAMoAiQoAgwRBABFDQALDAILIAkgBksEQEEBIQQgAygCICAHIAZBA3RqIgAoAgAgACgCBCADKAIkKAIMEQQADQILQQAhBAwBC0EBIQQLIANBMGokACAEC/sFAgh/AX4jAEHQAGsiAiQAIAIgATYCLCAAKAIEIQEgAkEBOgA8IAJBAzYCOCACIAFBAWo2AjQgAkEANgIwQQEhAQNAAkAgAUH/AXFFBEAgAkEYaiACQTBqIAIoAjgQ8AQgAgJ/IAIoAhhBAUcEQEEAIQMgAigCNAwBCyACKAIcIgFBAWogAigCNCIDIAEgA0kiAxsLNgIwDAELIAJBADoAPCACQSBqIAJBMGoQ+QIgAigCJCEBIAIoAiAhAwsgAwRAIAAoAgAgAWoiASABKAIAIgFBB3ZBf3NBgYKECHEgAUH//v37B3JqNgIAIAItADwhAQwBBSAAKAIAIQECQCAAKAIEQQFqIgNBBE8EQCABIANqIAEoAAA2AAAMAQsgAUEEaiABIAMQrQIgACgCBCIBIAAoAgBqQQFqQYABQQMgAWsQwQQaCyACQRBqQQAgACgCBEEBahCmBSACIAIpAxA3AzADQCACQQhqIAJBMGoQ+QIgAigCCEUEQCAAIAAoAgQiAUEITwR/IAFBAWpBA3ZBB2wFIAELIAAoAgxrNgIQIAJB0ABqJAAPCyACKAIMIgEgACgCAGotAABBgAFHDQACQANAIAAgACgCCCABQQxsaiIDEKUEIgoQhQIhBCABIAAoAgQiBSAKpyIGcSIHayAEIAdrcyAFcUEESQ0BIAAoAgAiByAEaiIILQAAIAggBkEZdiIGOgAAIAcgBSAEQXxqcWpBBGogBjoAAEH/AUcEQCAAKAIIIARBDGxqIgQpAgAhCiAEIAMpAgA3AgAgBEEIaiIEKAIAIQUgBCADQQhqIgQoAgA2AgAgAyAKNwIAIAQgBTYCAAwBCwsgACgCACIFIAFqQf8BOgAAIAUgACgCBCABQXxqcWpBBGpB/wE6AAAgA0EIaigCACEBIAAoAgggBEEMbGoiBCADKQIANwIAIARBCGogATYCAAwBCyAAKAIAIgMgAWogBkEZdiIEOgAAIAMgBSABQXxqcWpBBGogBDoAAAwACwALAAsAC9AFAQd/QStBgIDEACAAKAIAIglBAXEiBRshCiAEIAVqIQgCQCAJQQRxRQRAQQAhAQwBCyACBEAgAiEGIAEhBQNAIAcgBS0AAEHAAXFBgAFGaiEHIAVBAWohBSAGQX9qIgYNAAsLIAIgCGogB2shCAtBASEFAkAgACgCCEEBRwRAIAAgCiABIAIQuAMNASAAKAIYIAMgBCAAQRxqKAIAKAIMEQQAIQUMAQsgAEEMaigCACIGIAhNBEAgACAKIAEgAhC4Aw0BIAAoAhggAyAEIABBHGooAgAoAgwRBAAPCwJAIAlBCHFFBEBBACEFIAYgCGsiBiEIAkACQAJAQQEgAC0AICIHIAdBA0YbQQFrDgMBAAECCyAGQQF2IQUgBkEBakEBdiEIDAELQQAhCCAGIQULIAVBAWohBQNAIAVBf2oiBUUNAiAAKAIYIAAoAgQgACgCHCgCEBECAEUNAAtBAQ8LIAAoAgQhCSAAQTA2AgQgAC0AICELIABBAToAICAAIAogASACELgDDQFBACEFIAYgCGsiASECAkACQAJAQQEgAC0AICIGIAZBA0YbQQFrDgMBAAECCyABQQF2IQUgAUEBakEBdiECDAELQQAhAiABIQULIAVBAWohBQJAA0AgBUF/aiIFRQ0BIAAoAhggACgCBCAAKAIcKAIQEQIARQ0AC0EBDwsgACgCBCEBQQEhBSAAKAIYIAMgBCAAKAIcKAIMEQQADQEgAkEBaiEHIAAoAhwhAiAAKAIYIQMDQCAHQX9qIgcEQCADIAEgAigCEBECAEUNAQwDCwsgACALOgAgIAAgCTYCBEEADwsgACgCBCEGQQEhBSAAIAogASACELgDDQAgACgCGCADIAQgACgCHCgCDBEEAA0AIAhBAWohByAAKAIcIQEgACgCGCEAA0AgB0F/aiIHRQRAQQAPCyAAIAYgASgCEBECAEUNAAsLIAULuQUCE38CfiMAQUBqIgEkABDIBCIEKAIAIQcgAUEoaiAEKAIIIgQQtgMgByAEQQN0aiEQQQAhBANAIAcgEEcEQCAHKAIAIQogASAHKAIEIgw2AhQgASAKNgIQQQAhCCABQQA2AjwgAUEQaiABQTxqEKcFIAEoAjwiDUEZdiILQQh0IAtyIglBEHQgCXIhESAEQQFqIQkgB0EIaiEHIAEoAiwiDiANcSEDIAEoAjAhEiABKAIoIRMCQAJAA0AgAyATaigAACIPIBFzIgZBf3MgBkH//ft3anFBgIGChHhxIQIgCEEEaiIIIANqIA5xIQYDQCABQQhqIAIQzAQgASgCCEUEQCAGIQMgDyAPQQF0cUGAgYKEeHFFDQIMAwsgAkF/aiACcSECIAogDCASIAEoAgwgA2ogDnFBDGxqIgUoAgAgBSgCBBC/BUUNAAsLIAUNAQsgASABQShqNgI8IAEoAjhFBEAgAUEoaiABQTxqEIQCCyABKAIsIgggDXEhA0EEIQIgASgCKCEFA0AgASAFIAMiBmooAABBgIGChHhxEMwEIAIgA2ogCHEhAyACQQRqIQIgASgCAEEBRw0ACyAFIAEoAgQgBmogCHEiAmosAABBAE4EQCAFKAIAQYCBgoR4cRDSBSECCyABIAEoAjggASgCKCIDIAJqIgYtAABBAXFrNgI4IAEoAjAhBSAGIAs6AAAgAyABKAIsIAJBfGpxakEEaiALOgAAIAJBDGwgBWoiAyAEOwEIIAMgDDYCBCADIAo2AgAgASABKAI0QQFqNgI0IAkhBAwCCyAFIAQ7AQggCSEEDAELCyABQSBqIAFBOGooAgAiBDYCACABQRhqIAFBMGopAwAiFDcDACABIAEpAygiFTcDECAAQRBqIAQ2AgAgAEEIaiAUNwIAIAAgFTcCACABQUBrJAAL8AUCA38CfiMAQfAEayIHJAAgBEHAAEcEQCAHQZgDakLJgICAgAg3AwAgB0GUA2pBqoHAADYCACAHQZADakEJNgIAIAdBAzoAiAMgByAHLwDEATsAiQMgB0GhgcAANgKMAyAHIAdBxgFqLQAAOgCLA0HzgcAAQSsgB0GIA2pBoILAAEHsg8AAEKgCAAsgB0HoBGoiBEIANwMAIAdB4ARqIghCADcDACAHQdgEaiIJQgA3AwAgB0IANwPQBCAHQdAEakEgIANBIBCuASAHQdAEahDIAyAHQaADaiAEKQMANwMAIAdBmANqIAgpAwA3AwAgB0GQA2ogCSkDADcDACAHIAcpA9AENwOIAyAHIAdBiANqELsDIAdB2ABqIgRCADcDACAHQdAAaiIIQgA3AwAgB0HIAGoiCUIANwMAIAdCADcDQCAHQUBrQSAgA0EgakEgEK4BIAdBxgFqIgMgBy0ABjoAACAHQcwBaiAHQR9qLQAAOgAAIAdB1QFqIAkpAwA3AAAgB0HdAWogCCkDADcAACAHQeUBaiAEKQMANwAAIAcgBy8BADsBgAEgByAHLQACOgCCASAHIAcvAQQ7AcQBIAcgBygAGzYCyAEgByAHKQNANwDNASAHKQAHIQogBykADyELIAcoABchBCAHLQADIQggB0GIA2ogB0HIAWpBJRDyAxogByAIOgCDASAHIAQ2AJcBIAcgCzcAjwEgByAKNwCHASAHIAcvAcQBOwGEASAHIAMtAAA6AIYBIAdBmwFqIAdBiANqQSUQ8gMaIAdBiANqIAEgAhBeIAdByAFqIAdBiANqQYiEwAAQxwIgB0FAayAHQYABaiAFIAYgB0HIAWoQ4wEgB0GIA2pBAEHAABDBBBogB0GIA2pBICAHQUBrQSAQrgEgB0GoA2pBICAHQeAAakEgEK4BIAcgBy0AxwNBgAFyOgDHAyAAIAcgB0GIA2pBwAAQ8gMiAEHAABCcAyAAQYABahCfASAAQfAEaiQAC7IFARB/IwBBgAJrIgQkACAEQfgAaiIFIANBGGopAAA3AwAgBEHwAGoiBiADQRBqKQAANwMAIARB6ABqIgcgA0EIaikAADcDACAEIAMpAAA3A2AgBEHAAWogASACIARB4ABqEO0BIARBGGoiAyAEQdgBaikDADcDACAEQRBqIgggBEHQAWopAwA3AwAgBEEIaiIJIARByAFqKQMANwMAIAQgBCkDwAE3AwAgBEE4aiIKIARB+AFqIgspAwA3AwAgBEEwaiIMIARB8AFqIg0pAwA3AwAgBEEoaiIOIARB6AFqIg8pAwA3AwAgBCAEKQPgATcDICAEQdgAaiIQQgA3AwAgBEHQAGoiEUIANwMAIARByABqIhJCADcDACAEQgA3A0AgBEHAAWpBAEHAABDBBBogBEHgAGogAUHAAWoQ1gMgBEHAAWpBICAEQeAAakEgEK4BIARB4AFqQSAgAUHgAWoiE0EgEK4BIARB4ABqIARBwAFqQcAAEPIDGiAEQawBakHAADYCACAEQSA2AqQBIAQgEzYCoAEgBCAEQeAAajYCqAEgAkHmhsAAQQogBEFAa0EgIARBoAFqQQIQigUgBEG4AWogAUHYAWopAAA3AwAgBEGwAWogAUHQAWopAAA3AwAgBEGoAWogAUHIAWopAAA3AwAgBCABKQDAATcDoAEgBSADKQMANwMAIAYgCCkDADcDACAHIAkpAwA3AwAgBCAEKQMANwNgIARBwAFqIARBoAFqIARB4ABqEBIgDyASKQMANwMAIA0gESkDADcDACALIBApAwA3AwAgBCAEKQNANwPgASAAIARBwAFqQcAAEPIDIgBB2ABqIAopAwA3AAAgAEHQAGogDCkDADcAACAAQcgAaiAOKQMANwAAIAAgBCkDIDcAQCACELcFIARBgAJqJAALpQUBBH8jAEGAFGsiBCQAIARBCGogAUEFEGcgBEGIAmogA0EIEGdBgAIhBUH/ASEGQf8BIQcDQAJAIAchAyAGIgFBf0YNACAEQQhqIAFqLQAABEAgASEDDAELIAFBf2ohBiABIQcgBUF/aiIFIQMgBEGIAmogAWotAABFDQELCyAEQYgEaiACEMcBIARBiA5qQQBBKBDBBBogBEG4DmpCADcDACAEQcAOakIANwMAIARByA5qQgA3AwAgBEHQDmpCADcDACAEQeAOakIANwMAIARB6A5qQgA3AwAgBEHwDmpCADcDACAEQfgOakIANwMAIARCATcDsA4gBEIBNwPYDgNAIARBgA9qIARBiA5qEKMBAkAgBEGAD2oCfyAEQQhqIANqLAAAIgFBAU4EQCAEQcARaiAEQYAPahCDAiAEQeASaiAEQYgEaiABEPgDIARBoBBqIARBwBFqIARB4BJqEJIBIARBoBBqDAELIAFBf0oNASAEQcARaiAEQYAPahCDAiAEQeASaiAEQYgEakEAIAFrQRh0QRh1EPgDIARBoBBqIARBwBFqIARB4BJqEJMBIARBoBBqC0GgARDyAxoLAkAgBEGAD2oCfyAEQYgCaiADaiwAACIBQQFOBEAgBEHgEmogBEGAD2oQgwIgBEGgEGogARD5AyAEQcARaiAEQeASaiAEQaAQahCZASAEQcARagwBCyABQX9KDQEgBEHgEmogBEGAD2oQgwIgBEGgEGpBACABa0EYdEEYdRD5AyAEQcARaiAEQeASaiAEQaAQahCaASAEQcARagtBoAEQ8gMaCyAEQeASaiAEQYAPahDyAiAEQYgOaiAEQeASakH4ABDyAxogAwRAIANBf2ohAwwBCwsgACAEQYgOahCWAiAEQYAUaiQAC6UFAQR/IwBBgBRrIgQkACAEQQhqIAFBBRBnIARBiAJqIANBCBBnQYACIQVB/wEhBkH/ASEHA0ACQCAHIQMgBiIBQX9GDQAgBEEIaiABai0AAARAIAEhAwwBCyABQX9qIQYgASEHIAVBf2oiBSEDIARBiAJqIAFqLQAARQ0BCwsgBEGIBGogAhDIASAEQYgOakEAQSgQwQQaIARBuA5qQgA3AwAgBEHADmpCADcDACAEQcgOakIANwMAIARB0A5qQgA3AwAgBEHgDmpCADcDACAEQegOakIANwMAIARB8A5qQgA3AwAgBEH4DmpCADcDACAEQgE3A7AOIARCATcD2A4DQCAEQYAPaiAEQYgOahCjAQJAIARBgA9qAn8gBEEIaiADaiwAACIBQQFOBEAgBEHAEWogBEGAD2oQgwIgBEHgEmogBEGIBGogARD6AyAEQaAQaiAEQcARaiAEQeASahCSASAEQaAQagwBCyABQX9KDQEgBEHAEWogBEGAD2oQgwIgBEHgEmogBEGIBGpBACABa0EYdEEYdRD6AyAEQaAQaiAEQcARaiAEQeASahCTASAEQaAQagtBoAEQ8gMaCwJAIARBgA9qAn8gBEGIAmogA2osAAAiAUEBTgRAIARB4BJqIARBgA9qEIMCIARBoBBqIAEQ+wMgBEHAEWogBEHgEmogBEGgEGoQmQEgBEHAEWoMAQsgAUF/Sg0BIARB4BJqIARBgA9qEIMCIARBoBBqQQAgAWtBGHRBGHUQ+wMgBEHAEWogBEHgEmogBEGgEGoQmgEgBEHAEWoLQaABEPIDGgsgBEHgEmogBEGAD2oQ8gIgBEGIDmogBEHgEmpB+AAQ8gMaIAMEQCADQX9qIQMMAQsLIAAgBEGIDmoQlgIgBEGAFGokAAv/BAEFfyMAQYABayIEJAAgBEEFOgAYAkACQAJAAkACQCABKAIAIgVBAUYgBUF+akECS3JFBEAgBEEgaiACIAMQYSAEKAIgQQFHDQEgBEHgAGogBEEYaiIDKAIAIgI2AgAgBEHYAGogBEEQaiIFKQMANwMAIAQgBCkDCDcDUCAEQfgAaiAEQTRqKAIANgIAIARB8ABqIARBLGopAgA3AwAgBCAEKQIkNwNoIARBQGsiBiAEQegAaiAEQdAAaiACQf8BcUEFRiIHGyICQQhqKQIANwMAIARByABqIgggAkEQaigCADYCACAEIAIpAgA3AzggBEHQAGogBEHoAGogBxsQmAUgBSAGKQMANwMAIAMgCCgCADYCACAEIAQpAzg3AwgMBAsgBEEgaiABIAIgAxCnASAELQAwQQVHDQEgAEEFOgAQIARBIGoQmAUMAgsgBEEoaigCACECIAQoAiQhAyABKAIAIgVBAUdBACAFQX5qQQNJG0UEQCABEIwFCyABIAI2AgQgASADNgIAIABBBToAEAwBCyAEQQhqEJgFIARBGGogBEEwaigCADYCACAEQRBqIARBKGopAwA3AwAgBCAEKQMgNwMIDAELIARBCGoQmAUMAQsgASgCACIBQX5qIQIgAUECRyACQQJLckUEQEGh+ckAQShBzPnJABC5BAALIAFBA0ZBACACQQJNG0UEQCAELQAYQQVHBEAgBEEwaiAEQRhqKAIANgIAIARBKGogBEEQaikDADcDACAEIAQpAwg3AyAgACAEQSBqEM8CDAILIABB6/jJAEEcEPwEIARBCGoQmAUMAQtBofnJAEEoQcz5yQAQuQQACyAEQYABaiQAC5sFAQF/IwBB8AZrIgIkACACQQhqIAEQmgIgAkEwaiACQQhqEEMCQAJAAkAgAkEwaiABEIwDQf8BcUUgAkEIahDCBEH/AXFBAUZyRQRAIAJB4ABqQgA3AwAgAkHoAGpCADcDACACQfAAakIANwMAIAJCADcDWCACQgE3A1AgAkH4AGogAkEIahDIBSACQaABaiACQdAAaiACQfgAahDfASACQcgBaiACQdAAaiACQfgAahDVAyACQfABaiACQcgBahDIBSACQbAEakGAucQAENkDIAJB0AVqIAJBoAFqEMgFIAJBiARqIAJBsARqIAJB0AVqEB4gAkGYAmogAkGIBGogAkHwAWoQ3wEgAkGwBGogAkGYAmogAkHwAWoQHiACQdAFaiACQbAEahCwAyACLQDQBSACQcACaiACQdgFakEoEPIDGiACQegCaiACQcACaiACQcgBahAeIAJB0AVqIAJB6AJqIAJBmAJqEB4gAkGQA2ogAkHAAmogAkHQBWoQHiACQdAFaiACQQhqIAJBCGoQ1QMgAkG4A2ogAkHQBWogAkHoAmoQHiACQbgDaiACQbgDahDCBBCrBCACQeADaiACQaABaiACQZADahAeIAJBiARqIAJBuANqIAJB4ANqEB5FDQIgAkGIBGoQwgRB/wFxQQFHDQEMAgsgAEIANwMADAILIAJB4ANqEJUDQf8BcUEBRg0AIAJB0AVqIAJBuANqQSgQ8gMaIAJB+AVqIAJB4ANqQSgQ8gMaIAJBoAZqIAJB0ABqQSgQ8gMaIAJByAZqIAJBiARqQSgQ8gMaIAJBsARqIAJB0AVqQaABEPIDGiAAQQhqIAJBsARqQaABEPIDGiAAQgE3AwAMAQsgAEIANwMACyACQfAGaiQAC5UGAgZ/BH4jAEHgAGsiAyQAIABBMGohBgJAIABB0ABqKAIAIgRFBEAgAiEEDAELIANBKGogASACIAJBICAEayIEIAQgAksbIgUQngQgAygCLCEHIAMoAighCCADQSBqIAUgAiABIAIQ1AMgAygCJCEEIAMoAiAhASADQRhqIAAoAlBBICAGQSAQ1AMgA0EQaiADKAIYIAMoAhwgBRCeBCADKAIQIAMoAhQgCCAHELIBIAAgACgCUCAFaiIFNgJQIAVBIEcNACADQQhqIAYQnwQgAyADKQMINwMwIABBKGopAwAhCSAAQSBqKQMAIQogAEEYaikDACELIAApAxAhDANAIANBOGogA0EwahCQAiADKQM4QgFRBEAgAykDWELP1tO+0ser2UJ+IAl8Qh+JQoeVr6+Ytt6bnn9+IQkgAykDUELP1tO+0ser2UJ+IAp8Qh+JQoeVr6+Ytt6bnn9+IQogAykDSELP1tO+0ser2UJ+IAt8Qh+JQoeVr6+Ytt6bnn9+IQsgAykDQELP1tO+0ser2UJ+IAx8Qh+JQoeVr6+Ytt6bnn9+IQwMAQsLIABBADYCUCAAIAk3AyggACAKNwMgIAAgCzcDGCAAIAw3AxALIAQEQCADIAQ2AjQgAyABNgIwIABBKGopAwAhCSAAQSBqKQMAIQogAEEYaikDACELIAApAxAhDANAIANBOGogA0EwahCQAiADKQM4QgFRBEAgAykDWELP1tO+0ser2UJ+IAl8Qh+JQoeVr6+Ytt6bnn9+IQkgAykDUELP1tO+0ser2UJ+IAp8Qh+JQoeVr6+Ytt6bnn9+IQogAykDSELP1tO+0ser2UJ+IAt8Qh+JQoeVr6+Ytt6bnn9+IQsgAykDQELP1tO+0ser2UJ+IAx8Qh+JQoeVr6+Ytt6bnn9+IQwMAQsLIAAgCTcDKCAAIAo3AyAgACALNwMYIAAgDDcDECADKAIwIQQgAyAGQSAgAygCNCIBEJ4EIAMoAgAgAygCBCAEIAEQsgEgACABNgJQCyAAIAApAwAgAq18NwMAIANB4ABqJAALsQMBBX8jAEEQayICJAAgAkECciEEQeT5ygAoAgAhAQJAAkADQAJAAkAgAUEDSw0AAkACQCABQQFrDgMAAgUBC0G4o8oAQSpB5KPKABC8BAALQeT5ygBB5PnKACgCACIBQQIgARs2AgAgAQ0CDAELIAFBA3FBAkcNAwJAAkADQEH4+coAKAIAQQFHBEBB+PnKAEIBNwIAQYD6ygBBADYCAAsgASEDEJsBIQVB5PnKACAEQeT5ygAoAgAiASABIANGGzYCACACQQA6AAggAiAFNgIAIAIgA0F8cTYCBAJAIAEgA0YEQCACLQAIRQ0BDAMLAkAgAigCACIDRQ0AIAMgAygCACIDQX9qNgIAIANBAUcNACACENICCyABQQNxQQJGDQEMAwsLA0AQRSACLQAIRQ0ACwsgAigCACIBRQ0AIAEgASgCACIBQX9qNgIAIAFBAUcNACACENICQeT5ygAoAgAhAQwCC0Hk+coAKAIAIQEMAQsLIAJB5PnKADYCACAAQQBBnIzKACgCABEAACACQQM2AgQgAhBVCyACQRBqJAAPC0HvosoAQTlBqKPKABC8BAALtgMBA38jAEHQBGsiAiQAIAJBIGoQsgMgAkEgaiABEMYFIAJBuAJqIAJBIGpB2AEQ8gMaIAJB+AFqIAJBuAJqEO4DIAJBqARqIgFCADcDACACQaAEaiIDQgA3AwAgAkGYBGoiBEIANwMAIAJCADcDkAQgAkEYaiACQfgBahCpBSACQRBqQQBBICACKAIYIAIoAhwQ1AMgAkGQBGpBICACKAIQIAIoAhQQrQEgAiACLQCQBEH4AXE6AJAEIAIgAi0ArwRBP3FBwAByOgCvBCACQZAEahDIAyACQdACaiABKQMANwMAIAJByAJqIAMpAwA3AwAgAkHAAmogBCkDADcDACACIAIpA5AENwO4AiAAIAJBuAJqELsDIAJByARqIgFCADcDACACQcAEaiIDQgA3AwAgAkG4BGoiBEIANwMAIAJCADcDsAQgAkEIaiACQfgBahCpBSACQSBBwAAgAigCCCACKAIMENQDIAJBsARqQSAgAigCACACKAIEEK0BIABBOGogASkDADcAACAAQTBqIAMpAwA3AAAgAEEoaiAEKQMANwAAIAAgAikDsAQ3ACAgAkHQBGokAAuUBQIGfwF+IwBB4ABrIggkACAIQQI6ACAgCEEIakGU7ckAELcEAn8gCCgCCARAIAhBOGoQSSAIQRBqEJcEIAhBEGogCEE4akEoEPIDGiAIQRBqIAgtACBBAkcNARpB6OzJAEErQYDuyQAQzgMACyAIKAIMCyEGIAEQxAIhBwJ/AkACQCACQezqyQAoAgARBgAEQCAFKQMAIQwgBkEANgIYIAYgDDwAJCAGQQA2AiAgBiABNgIUIAZBAToAECAHKAIoQRhqIAdBJGogBygCJBsgBjYCACAHIAY2AiggB0EgahDQBCADQYDryQAoAgARAwAgBSkDAEIBUQ0BIAYQ5gEMAgsgB0EgahDQBEEBDAILIAYgBSkDCCAFQRBqKAIAEIsBDQACQANAAkAQkAMhASAGKAIUIgtBufPd8XlsQQAgASgCCGtBH3F2IgkgASgCBCICTw0AIAEoAgAiCiAJQfAAbGpBIGoiAhDxBCABQaDYygAoAgBGBEAgBigCFCALRg0DCyACENAEDAELC0HA7skAIAkgAhDkAgALAkAgBCALAn8CQCAGELMDBEAgCiAJQfAAbGoiAUEkaiEDIAEoAiQhBUEAIQcDQCADIQEgByECIAUiB0UNBCAHQRhqIQMgBygCGCEFIAYgB0cNAAsgASAFNgIAIAYgCiAJQfAAbGoiASgCKEYEQCABQShqIAI2AgAMAgsDQCAFRQ0CIAsgBSgCFEcEQCAFKAIYIQUMAQsLQQAMAgsgCiAJQfAAbGpBIGoQ0AQMAwtBAQsiB0GU68kAKAIAEQEACyAKIAlB8ABsakEgahDQBEECDAELIAYoAhwhB0EACyEBIAhBEGoQlwQgACAHNgIEIAAgATYCACAIQeAAaiQAC8oEAQV/IwBBEGsiBCQAIAAoAgAhAAJAAkACQAJAAkACQCABQYABTwRAIARBADYCDCABQYAQSQ0BIARBDGohBSABQYCABEkEQCAEIAFBP3FBgAFyOgAOIAQgAUEGdkE/cUGAAXI6AA0gBCABQQx2QQ9xQeABcjoADEEDIQEMBAsgBCABQT9xQYABcjoADyAEIAFBEnZB8AFyOgAMIAQgAUEGdkE/cUGAAXI6AA4gBCABQQx2QT9xQYABcjoADUEEIQEMAwsgACgCCCICIABBBGooAgBHBEAgACgCACEDDAILIAJBAWoiAyACSQ0DIAJBAXQiBSADIAUgA0sbIgVBAEgNAwJ/IAJFBEAgBUEBEKQFDAELIAAoAgAgAkEBIAUQlAULIgMEQCAAIAM2AgAgAEEEaiAFNgIAIAAoAgghAgwCCyAFQQEQ3QUACyAEIAFBP3FBgAFyOgANIAQgAUEGdkEfcUHAAXI6AAwgBEEMaiEFQQIhAQwBCyACIANqIAE6AAAgACAAKAIIQQFqNgIIDAMLIABBBGooAgAiAyAAQQhqKAIAIgJrIAFPBEAgACgCACEDDAILIAEgAmoiBiACSQ0AIANBAXQiAiAGIAIgBksbIgJBAEgNAAJ/IANFBEAgAkEBEKQFDAELIAAoAgAgA0EBIAIQlAULIgMEQCAAIAM2AgAgAEEEaiACNgIAIABBCGooAgAhAgwCCyACQQEQ3QUACxDCBQALIABBCGogASACajYCACACIANqIAUgARDyAxoLIARBEGokAEEAC8EEAQV/IwBBEGsiBCQAAkACQAJAAkACQAJAIAFBgAFPBEAgBEEANgIMIAFBgBBJDQEgBEEMaiEFIAFBgIAESQRAIAQgAUE/cUGAAXI6AA4gBCABQQZ2QT9xQYABcjoADSAEIAFBDHZBD3FB4AFyOgAMQQMhAQwECyAEIAFBP3FBgAFyOgAPIAQgAUESdkHwAXI6AAwgBCABQQZ2QT9xQYABcjoADiAEIAFBDHZBP3FBgAFyOgANQQQhAQwDCyAAKAIIIgIgAEEEaigCAEcEQCAAKAIAIQMMAgsgAkEBaiIDIAJJDQMgAkEBdCIFIAMgBSADSxsiBUEASA0DAn8gAkUEQCAFQQEQpAUMAQsgACgCACACQQEgBRCUBQsiAwRAIAAgAzYCACAAQQRqIAU2AgAgACgCCCECDAILIAVBARDdBQALIAQgAUE/cUGAAXI6AA0gBCABQQZ2QR9xQcABcjoADCAEQQxqIQVBAiEBDAELIAIgA2ogAToAACAAIAAoAghBAWo2AggMAwsgAEEEaigCACIDIABBCGooAgAiAmsgAU8EQCAAKAIAIQMMAgsgASACaiIGIAJJDQAgA0EBdCICIAYgAiAGSxsiAkEASA0AAn8gA0UEQCACQQEQpAUMAQsgACgCACADQQEgAhCUBQsiAwRAIAAgAzYCACAAQQRqIAI2AgAgAEEIaigCACECDAILIAJBARDdBQALEMIFAAsgAEEIaiABIAJqNgIAIAIgA2ogBSABEPIDGgsgBEEQaiQAC8gEAQZ+IAAgASkDICIDQjOIQhN+IAEpAwAiAkL/////////A4N8IgRCE3xCM4ggASkDCCIFQv////////8DgyACQjOIfCICfEIziCABKQMQIgZC/////////wODIAVCM4h8IgV8QjOIIAEpAxgiB0L/////////A4MgBkIziHwiBnxCM4ggA0L/////////A4MgB0IziHwiB3xCM4hCE34gBHwiAzwAACAAIANCKIg8AAUgACADQiCIPAAEIAAgA0IYiDwAAyAAIANCEIg8AAIgACADQgiIPAABIAAgA0IziCACfCIEQiWIPAALIAAgBEIdiDwACiAAIARCFYg8AAkgACAEQg2IPAAIIAAgBEIFiDwAByAAIARCM4ggBXwiAkIqiDwAEiAAIAJCIog8ABEgACACQhqIPAAQIAAgAkISiDwADyAAIAJCCog8AA4gACACQgKIPAANIAAgA0IwiEIHgyAEQv////////8DgyIEQgOGhDwABiAAIAJCM4ggBnwiA0IniDwAGCAAIANCH4g8ABcgACADQheIPAAWIAAgA0IPiDwAFSAAIANCB4g8ABQgACACQv////////8DgyIFQgaGIARCLYiEPAAMIAAgA0IziCAHfCICQiSIPAAeIAAgAkIciDwAHSAAIAJCFIg8ABwgACACQgyIPAAbIAAgAkIEiDwAGiAAIANC/////////wODIgNCAYYgBUIyiIQ8ABMgACACQv////////8DgyICQiyIPAAfIAAgAkIEhiADQi+IhDwAGQuvBAEBfyMAQfAAayIDJAAgAyABOgALAkACQAJAIAJFBEAgAyABQQhxIgI6AAwgAg0CIAAgAToAygEgAC0AyQEhAiAAIAAtAMgBQQFqOgDJASADIAE6AFkgAyACOgBYIAAgA0HYAGpBAhDBAiADLQALQSRxRQ0BIAAtAMgBRQ0BIAAQnAIMAQsgAC0AygEgAUH/AXFHDQILIANB8ABqJAAPCyADQcwAakEhNgIAIANBxABqQSI2AgAgA0E0akEDNgIAIAMgA0EMajYCVCADQbD2wwA2AhAgA0HsAGpBADYCACADQgM3AiQgA0GI9cMANgIgIANBIjYCPCADQYDzwwA2AmggA0IBNwJcIANB8PbDADYCWCADIANBOGo2AjAgAyADQdgAajYCSCADIANBEGo2AkAgAyADQdQAajYCOCADQSBqQfj2wwAQvQQACyADQcwAakEhNgIAIANBxABqQSI2AgAgAyAAQcoBaiIANgIMIAMgA0ELajYCVCADQewAakECNgIAIANB5ABqQQI2AgAgA0EcakEjNgIAIANBIjYCPCADQeD1wwA2AmAgA0ECNgJcIANB0PXDADYCWCADQSM2AhQgAyAANgIQIAMgA0HYAGo2AkggAyADQdQAajYCQCADIANBDGo2AjggAyADQRBqNgJoIAMgA0ELajYCGCADQTRqQQM2AgAgA0IDNwIkIANBiPXDADYCICADIANBOGo2AjAgA0EgakGg9sMAEL0EAAvxBAEGfyMAQeAAayIAJABB+PnKACgCAEEBRwRAQfj5ygBCATcCAEGA+soAQQA2AgALEJsBIgFBACABKAIYIgIgAkECRiICGzYCGCAAIAE2AggCQCACDQACQAJAAkAgACgCCCIBQRxqIgQoAgAiAi0AAEUEQCACQQE6AABBACECAkBBiPrKACgCAEEBRgRAQYz6ygAoAgAhAgwBC0GI+soAQgE3AwALQYz6ygAgAjYCACABLQAgDQEgASABKAIYIgNBASADGzYCGCADRQRAIAAoAghBJGogBCgCABCoBEEAEMAFAAsgA0ECRw0CIAAoAggiBSgCGCEDIAVBADYCGCAAIAM2AgwgA0ECRw0DAkAgAg0AQYj6ygAoAgBBAUcEQEGI+soAQgE3AwAMAQtBjPrKACgCAEUNACABQQE6ACALIAQoAgBBADoAAAwEC0Hop8oAQSBBpKjKABC8BAALIAAgBDYCSCAAIAJBAEc6AExB9JzKAEErIABByABqQaCdygBB4J7KABCoAgALQfCeygBBF0GIn8oAELwEAAsgAEE8akEhNgIAIABBNGpBkgE2AgAgAEEkakEDNgIAIAAgAEEMajYCQCAAQZifygA2AkQgAEHcAGpBADYCACAAQgM3AhQgAEGAnMoANgIQIABBkgE2AiwgAEHsm8oANgJYIABCATcCTCAAQbyfygA2AkggACAAQShqNgIgIAAgAEHIAGo2AjggACAAQcQAajYCMCAAIABBQGs2AiggAEEQakHEn8oAEKkEAAsgACgCCCIBIAEoAgAiAUF/ajYCACABQQFGBEAgAEEIahDSAgsgAEHgAGokAAuFBAEHfyMAQTBrIgMkAAJ/QQAgAkUNABogA0EoaiEIAkACQAJAAkADQCAAKAIILQAABEAgACgCAEGcrMoAQQQgACgCBCgCDBEEAA0FCyADQQo2AiggA0KKgICAEDcDICADIAI2AhwgA0EANgIYIAMgAjYCFCADIAE2AhAgA0EIakEKIAEgAhBlAn8CQAJAIAMoAghBAUYEQCADKAIMIQQDQCADIAQgAygCGGpBAWoiBDYCGAJAIAQgAygCJCIFSQRAIAMoAhQhBwwBCyADKAIUIgcgBEkNACAFQQVPDQcgBCAFayIGIAMoAhBqIgkgCEYNBCAJIAggBRC0A0UNBAsgAygCHCIGIARJIAcgBklyDQIgAyADIAVqQSdqLQAAIAMoAhAgBGogBiAEaxBlIAMoAgQhBCADKAIAQQFGDQALCyADIAMoAhw2AhgLIAAoAghBADoAACACDAELIAAoAghBAToAACAGQQFqCyEEIAAoAgQhBSAAKAIAIARFIAIgBEZyIgZFBEAgAiAETQ0DIAEgBGosAABBv39MDQMLIAEgBCAFKAIMEQQADQQgBkUEQCACIARNDQQgASAEaiwAAEG/f0wNBAsgASAEaiEBIAIgBGsiAg0AC0EADAQLIAVBBBDlAgALIAEgAkEAIAQQKQALIAEgAiAEIAIQKQALQQELIANBMGokAAvsAwEKfwNAAkBBACEIIAEtAB0NACABKAIIIQoCfwJAA0AgASgCGCICIAEoAhQiBEYNASABIARBAWoiAzYCFAJAAkAgBCwAACIFQX9MBEACfyACIANGBEBBACEGIAIMAQsgASAEQQJqIgM2AhQgBC0AAUE/cSEGIAMLIQcgBUEfcSEJIAVB/wFxIgtB3wFLDQEgBiAJQQZ0ciECDAILIAVB/wFxIQIMAQsCfyACIAdGBEBBACEHIAIMAQsgASAHQQFqIgM2AhQgBy0AAEE/cSEHIAMLIQUgByAGQQZ0ciEGIAtB8AFJBEAgBiAJQQx0ciECDAELIAIgBUYEf0EABSABIAVBAWoiAzYCFCAFLQAAQT9xCyAJQRJ0QYCA8ABxIAZBBnRyciICQYCAxABGDQILIAEgASgCECIFIAMgBGtqIgQ2AhAgAkF3aiIDQRdNQQBBASADdEGfgIAEcRtFBEAgAkGAAUkNASACEPcBRQ0BCwsgASgCACEDIAEgBDYCACADIApqIQggBSADawwBCyABLQAdDQECQCABLQAcBEAgASgCBCEDIAEoAgAhAgwBCyABKAIEIgMgASgCACICRg0CCyABQQE6AB0gASgCCCACaiEIIAMgAmsLIgRFDQELCyAAIAQ2AgQgACAINgIAC4wEAQJ/IwBBwARrIgIkACACQQhqIAFBKBDyAxogAkEwaiABQShqQSgQ8gMaIAJBmARqIAFB0ABqIgMgAkEwahDVAyACQdABaiADIAJBMGoQ3wEgAkHYAGogAkGYBGogAkHQAWoQHiACQYABaiACQQhqIAJBMGoQHiACQZgEaiACQYABahDIBSACQfADaiACQdgAaiACQZgEahAeIAJB0AFqIAJB8ANqELADIAJBqAFqIAJB2AFqQSgQ8gMaIAJBgAJqIAJBqAFqIAJB2ABqEB4gAkGoAmogAkGoAWogAkGAAWoQHiACQdABaiACQagCaiABQfgAaiIBEB4gAkHQAmogAkGAAmogAkHQAWoQHiACQfgCaiACQagCakEoEPIDGiACQaADaiACQQhqQai5xAAQHiACQcgDaiACQTBqQai5xAAQHiACQfADaiACQYACakHQucQAEB4gAkHQAWogASACQdACahAeIAJBCGogAkHIA2ogAkHQAWoQwgQiARCIAiACQTBqIAJBoANqIAEQiAIgAkH4AmogAkHwA2ogARCIAiACQdABaiACQQhqIAJB0AJqEB4gAkEwaiACQdABahDCBBCrBCACQdABaiADIAJBMGoQ3wEgAkGYBGogAkH4AmogAkHQAWoQHiACQZgEaiACQZgEahDCBBCrBCAAIAJBmARqEEMgAkHABGokAAu5BAELfyMAQRBrIggkAEGc2MoAQZzYygAoAgBBAWoiBjYCAAJAQaDYygAoAgBFBEAgBkEAEJ0BIQFBoNjKAEGg2MoAKAIAIgIgASACGzYCACACRQ0BIAggATYCDCAIQQxqEP4DCyAGQQNsIQQDQEGg2MoAKAIAIgMoAgQiAiAETw0BIAJB8ABsIQEgAygCACECA0AgAQRAIAJBIGoQ8QQgAUGQf2ohASACQfAAaiECDAEFIANBoNjKACgCAEcEQCADKAIEQfAAbCEBIAMoAgAhAgNAIAFFDQQgAkEgahDQBCABQZB/aiEBIAJB8ABqIQIMAAsACyAGIAMQnQEhBSADKAIAIgEgAygCBEHwAGxqIQkCQAJAA0AgASAJRwRAIAFB8ABqIQIgASgCJCEBA0AgAUUEQCACIQEMAwsgASgCFEG5893xeWxBACAFKAIIa0EfcXYiByAFKAIEIgRPDQMgASgCGCAHQfAAbCILIAUoAgBqIgYoAigiBEEYaiAGQSRqIAQbIAE2AgAgByAFKAIEIgRPDQQgBSgCACALaiABNgIoIAFBADYCGCEBDAALAAsLQaDYygAgBTYCACADKAIEQfAAbCEBIAMoAgAhAgNAIAFFDQYgAkEgahDQBCABQZB/aiEBIAJB8ABqIQIMAAsAC0GQ7skAIAcgBBDkAgALQaDuyQAgByAEEOQCAAsACwALAAsgABDoAyAAQSRqQQA6AAAgAEEcakIANwIAIABCADcCFCAIQRBqJAALhgQBBn8jAEEgayIIJAAgASgCFCEHA0ACQCAFIAdqIgdBf2oiCSADTwRAIAEgAzYCFEEAIQcMAQsCQCABKQMAQgEgAiAJajEAAEI/g4aDUA0AIAEoAgghByAIQRhqIAYEfyAHBSAHIAEoAhwiCSAHIAlLGwsgBRCmBSAIKAIcIQogCCgCGCEHAkACQANAAkAgByAKSQRAIAdBAWoiCSAHTw0BCyAIQRBqQQAgASgCHCAGGyABKAIIEKYFIAhBCGogCCgCECAIKAIUEKYFIAEoAhQhCiAIKAIMIQcgCCgCCCEJAkACQANAIAkgB08EQCABIAUgCmoiAjYCFCAGRQRAIAFBADYCHAsgACAKNgIEIABBCGogAjYCAEEBIQcMCQsgB0F/aiIHIAVPDQEgByAKaiILIANPDQIgBCAHai0AACACIAtqLQAARg0ACyABIAEoAhAiCSAKaiIHNgIUIAYNCCABIAUgCWs2AhwMCAtBkPHIACAHIAUQ5AIAC0Gg8cgAIAsgAxDkAgALIAcgBU8NASABKAIUIAdqIgwgA08NAiAEIAdqIAkhBy0AACACIAxqLQAARg0ACyAMIAEoAghrQQFqIQcMAgtB8PDIACAHIAUQ5AIAC0GA8cgAIAwgAxDkAgALIAEgBzYCFCAGDQEgAUEANgIcDAELCyAAIAc2AgAgCEEgaiQAC/MDAgd/An4jAEHgAGsiAyQAIAMgAjYCDCADQTBqIAEQWyADIAMpATI3AyAgAyADQThqIgIpAQA3ASYCfwJAIAMtADBBAUcEQCADQcQAaigCACEEIANBGGogA0EqaigBACIFNgIAIAMgAykBIiIKNwMQIAAoAgwhASACIAU2AgAgAyAKNwMwIAMgBCABazYCQCADIAE2AjwgACgCACICIAAoAgRqQQFqIQggAigCAEF/c0GAgYKEeHEhASAAKAIIIQQMAQsgAy0AMUEARwwBCwNAIAMgARDMBCADKAIAQQFGBEAgA0EwaiAEIAMoAgRBDGxqIgUQpQQiChCFAiIGIAMoAjAiB2ogCqdBGXYiCToAACAHIAMoAjQgBkF8anFqQQRqIAk6AAAgBUEIaigCACEHIAMoAjggBkEMbGoiBiAFKQIANwIAIAZBCGogBzYCACABQX9qIAFxIQEMAQsgAkEEaiICIAhJBEAgBEEwaiEEIAIoAgBBf3NBgIGChHhxIQEMAQsLIAApAgAhCiAAIAMpAzA3AgAgA0E4aiIBKQMAIQsgASAAQQhqIgEpAgA3AwAgASALNwIAIANBQGsiASgCACECIAEgAEEQaiIAKAIANgIAIAAgAjYCACADIAo3AzAgA0EwahDYAkECCyADQeAAaiQAC+UDAgx/AX4gAiAFayEPQQAgBWshECABKAIQIQ0gASgCDCEKIAEpAwAhEyABKAIYIQgCQAJAA0AgCCAFayIJIANPBEBBACEHIAFBADYCGAwDC0IBIAIgCWoxAABCP4OGIBODUARAIAEgCTYCGCAJIQggBg0BIAEgBTYCIAwBCyAKIQcgCCAPaiEOIAYEfyAHBSABKAIgIgcgCiAKIAdLGwtBf2ohBwJAA0AgB0F/RgRAIAUgASgCICAGGyELIAggEGohDCAKIQcCQAJAA0AgByALTwRAIAEgCTYCGCAGRQRAIAEgBTYCIAsgACAJNgIEIABBCGogCDYCAEEBIQcMCQsgByAFTw0BIAcgDGogA08NAiAHIA5qIREgBCAHaiAHQQFqIQctAAAgES0AAEYNAAsgASAIIA1rIgg2AhggBg0FIAEgDTYCIAwFC0HYlsoAIAcgBRDkAgALQeiWygAgCCAFayAHaiADEOQCAAsgByAFTw0BIAcgCWogA08NAyAHIA5qIQsgBCAHaiAHQX9qIQctAAAgCy0AAEYNAAsgASAIIAprIAdqQQFqIgg2AhggBg0BIAEgBTYCIAwBCwtBuJbKACAHIAUQ5AIAC0HIlsoAIAggBWsgB2ogAxDkAgALIAAgBzYCAAuWBAIGfwR+IwBBwAFrIgIkACACQQhqQQBBwAAQwQQaA0ACQCADQQhHBEAgA0EBaiEHIAJBCGogA0EDdGohBUEAIQMgBiEEA0AgA0HAAEYNAiAEQcAARwRAIAUgBSkDACABIARqMQAAIANBOHGthoQ3AwAgA0EIaiEDIARBAWohBAwBCwtBnLvEACAEQcAAEOQCAAsgAiACKQMIIghC/////////weDNwNIIAIgAikDQCILQhSINwOQASACIAIpAygiCUIEiEL/////////B4M3A3AgAiACKQMQIgpCDIZCgOD//////weDIAhCNIiENwNQIAIgAikDGCIIQhiGQoCAgPj///8HgyAKQiiIhDcDWCACIAIpAyAiCkIkhkKAgICAgP7/B4MgCEIciIQ3A2AgAiAJQjCGQoCAgICAgMAHgyAKQhCIhDcDaCACIAIpAzAiCEIIhkKA/v//////B4MgCUI4iIQ3A3ggAiACKQM4IglCFIZCgIDA/////weDIAhCLIiENwOAASACIAtCIIZCgICAgPD//weDIAlCIIiENwOIASACQZgBaiACQcgAakGwu8QAEBYgAkHIAGogAkGYAWpBKBDyAxogAkGYAWogAkHwAGpB2LvEABAWIAJB8ABqIAJBmAFqQSgQ8gMaIAAgAkHwAGogAkHIAGoQjwIgAkHAAWokAA8LIAZBCGohBiAHIQMMAAsAC5YEAgZ/BH4jAEHAAWsiAiQAIAJBCGpBAEHAABDBBBoDQAJAIANBCEcEQCADQQFqIQcgAkEIaiADQQN0aiEFQQAhAyAGIQQDQCADQcAARg0CIARBwABHBEAgBSAFKQMAIAEgBGoxAAAgA0E4ca2GhDcDACADQQhqIQMgBEEBaiEEDAELC0H07MgAIARBwAAQ5AIACyACIAIpAwgiCEL/////////B4M3A0ggAiACKQNAIgtCFIg3A5ABIAIgAikDKCIJQgSIQv////////8HgzcDcCACIAIpAxAiCkIMhkKA4P//////B4MgCEI0iIQ3A1AgAiACKQMYIghCGIZCgICA+P///weDIApCKIiENwNYIAIgAikDICIKQiSGQoCAgICA/v8HgyAIQhyIhDcDYCACIAlCMIZCgICAgICAwAeDIApCEIiENwNoIAIgAikDMCIIQgiGQoD+//////8HgyAJQjiIhDcDeCACIAIpAzgiCUIUhkKAgMD/////B4MgCEIsiIQ3A4ABIAIgC0IghkKAgICA8P//B4MgCUIgiIQ3A4gBIAJBmAFqIAJByABqQYjtyAAQFyACQcgAaiACQZgBakEoEPIDGiACQZgBaiACQfAAakGw7cgAEBcgAkHwAGogAkGYAWpBKBDyAxogACACQfAAaiACQcgAahCSAiACQcABaiQADwsgBkEIaiEGIAchAwwACwALmwMBA38CQAJAAkACQAJAIAAtAAgiAiABLQAIRw0AAkACQAJAAkACQAJAIAJBAWsOBQEKAgMKAAsgAEEQaigCACICIAFBEGooAgBHDQUMCAsgAEEQaigCACICIAFBEGooAgBHDQYgAEEMaigCACIDIAFBDGooAgAiBEYNAiADIAQgAhC0A0UNAgwGCyAAQRBqKAIAIgIgAUEQaigCAEcNAwwGCyAAQRBqKAIAIgIgAUEQaigCAEcNAyAAQQxqKAIAIgMgAUEMaigCACIERg0BIAMgBCACELQDRQ0BDAMLIABBGGooAgAiAiABQRhqKAIARw0DQQEhAyAAQRRqKAIAIgAgAUEUaigCACIBRg0BIAAgASACELQDDQMMAQsgAEEYaigCACICIAFBGGooAgBHDQFBASEDIABBFGooAgAiACABQRRqKAIAIgFGDQAgACABIAIQtAMNAQsgAw8LQQAPC0EADwsgAEEMaigCACIAIAFBDGooAgAiAUYEQEEBDwsgACABIAIQtANFDwsgAEEJai0AACABQQlqLQAARgvxAwEHfyMAQRBrIgYkAEEBIQgCQCABKAIYQScgAUEcaigCACgCEBECAA0AIAYgACgCABB/IAZBDGotAAAhAyAGQQhqKAIAIQQgBigCACEAAkAgBigCBCIFQYCAxABGBEADQCAAIQJB3AAhBUEBIQACQAJAIAJBAmsOAgEABAsgA0H/AXEhAkEEIQNBAyEAAkACQAJAAkAgAkEBaw4FAwIBAAQHC0H1ACEFQQMhAwwDC0ECIQNB+wAhBQwCC0ECQQEgBBshA0GAgMQAIARBAnRBHHF2QQ9xQTByIQUgBEF/akEAIAQbIQQMAQtBACEDQf0AIQULIAEoAhggBSABKAIcKAIQEQIARQ0ADAMLAAsDQCAAIQdB3AAhAkEBIQACQAJAAkACQCAHQQFrDgMBAwAFCyADQf8BcSEHQQQhA0EDIQACQAJAAkAgB0EBaw4FAgEABAUHC0ECIQNB+wAhAgwECyAFIARBAnRBHHF2QQ9xIgJBMHIgAkHXAGogAkEKSRshAkECQQEgBBshAyAEQX9qQQAgBBshBAwDC0EAIQNB/QAhAgwCC0EAIQAgBSECDAELQfUAIQJBAyEDCyABKAIYIAIgASgCHCgCEBECAEUNAAsMAQsgASgCGEEnIAEoAhwoAhARAgAhCAsgBkEQaiQAIAgLhQUCAn8FfiMAQTBrIgEkAAJ+IAApAwAiA0IfWARAIAApAwhCxc/ZsvHluuonfAwBCyAAQRhqKQMAIgRCB4kgACkDECIFQgGJfCAAQSBqKQMAIgZCDIl8IABBKGopAwAiB0ISiXwgBULP1tO+0ser2UJ+Qh+JQoeVr6+Ytt6bnn9+hUKHla+vmLbem55/fkLj3MqV/M7y9YV/fCAEQs/W077Sx6vZQn5CH4lCh5Wvr5i23puef36FQoeVr6+Ytt6bnn9+QuPcypX8zvL1hX98IAZCz9bTvtLHq9lCfkIfiUKHla+vmLbem55/foVCh5Wvr5i23puef35C49zKlfzO8vWFf3wgB0LP1tO+0ser2UJ+Qh+JQoeVr6+Ytt6bnn9+hUKHla+vmLbem55/fkLj3MqV/M7y9YV/fAshBCABQRhqIABBMGoQnwQgASABKQMYNwMgIAMgBHwhAwN+IAFBCGogAUEgahC9AyABKQMIpwR+IAEpAxBCz9bTvtLHq9lCfkIfiUKHla+vmLbem55/fiADhUIbiUKHla+vmLbem55/fkLj3MqV/M7y9YV/fCEDDAEFIAEgASkDIDcDKAN+IAEgAUEoahC+AyABKAIABH4gASgCBK1Ch5Wvr5i23puef34gA4VCF4lCz9bTvtLHq9lCfkL5893xmfaZqxZ8IQMMAQUgASgCKCECIAEoAiwhAANAIAAEQCAAQX9qIQAgAjEAAELFz9my8eW66id+IAOFQguJQoeVr6+Ytt6bnn9+IQMgAkEBaiECDAELCyABQTBqJAAgA0IhiCADhULP1tO+0ser2UJ+IgNCHYggA4VC+fPd8Zn2masWfiIDQiCIIAOFCwsLCwuxAwEHfyABQX9qIQggAEECdCEHQQAgAWshCSACKAIAIQUCQAJAA0AgBUUNAiAFIQEDQAJAIAEoAggiBUEBcUUEQAJAIAEoAgBBfHEiCiABQQhqIgZrIAdPBEAgBiADIAAgBCgCEBECAEECdGpBCGogCiAHayAJcSIFTQ0BIAYgCHFFDQMgBigCACEFCyACIAU2AgAMBAsgBUEANgIAIAVBeGoiBUIANwIAIAUgASgCAEF8cTYCACABKAIAIgJBfHEiAEUgAkECcXJFBEAgACAAKAIEQQNxIAVyNgIECyAFIAUoAgRBA3EgAXI2AgQgASABKAIIQX5xNgIIIAEgASgCACIAQQNxIAVyIgI2AgAgAEECcUUNBCABIAJBfXE2AgAgBSAFKAIAQQJyNgIADAQLIAEgBUF+cTYCCAJ/QQAgASgCBEF8cSIFRQ0AGkEAIAUgBS0AAEEBcRsLIQUgARCfAiABLQAAQQJxBEAgBSAFKAIAQQJyNgIACyACIAU2AgAgBSEBDAELCwsgAiABKAIIQXxxNgIAIAEhBQsgBSAFKAIAQQFyNgIAIAVBCGohCwsgCwulAwECfyMAQcACayIEJAAgAhClBSACQdHwwwBBByADQaABahCeBSAEQSA2AkQgBCABQSBqNgJAIAQgAiAEQUBrEPQDIARBQGsgBEGo/8EAEMkFIARBIGogBEFAaxBIIAJB3/DDAEEGIARBIGoQngUgBEHgAWogAkHl8MMAQQYQkAQgBEFAayAEQeABaiABELwDIARBgAJqIARBQGsgBBASIARBoAJqEMsEIARByABqIgEgBEGoAmopAwA3AwAgBEHQAGoiAyAEQbACaikDADcDACAEQdgAaiIFIARBuAJqKQMANwMAIARBCGogASkDADcDACAEQRBqIAMpAwA3AwAgBEEYaiAFKQMANwMAIAQgBCkDoAI3A0AgBCAEKQNANwMAIABBGGogBEE4aikDADcAACAAQRBqIARBMGopAwA3AAAgAEEIaiAEQShqKQMANwAAIAAgBCkDIDcAACAAIAQpA4ACNwAgIABBKGogBEGIAmopAwA3AAAgAEEwaiAEQZACaikDADcAACAAQThqIARBmAJqKQMANwAAIAIQtwUgBEHAAmokAAuyAwIKfwF+QQAgASgCCCIKayENIAUgASgCECIOayEPIAEpAwAhESABKAIUIQgCQANAIAUgCGoiC0F/aiIHIANPBEAgASADNgIUQQAhBwwCC0IBIAIgB2oxAABCP4OGIBGDUARAIAEgCzYCFCALIQggBg0BIAFBADYCHAwBCyAKIQcgBkUEQCAKIAEoAhwiByAKIAdLGyEHCyACIAhqIRACQANAIAcgBU8EQEEAIAEoAhwgBhshCSAKIQcCQAJAA0AgCSAHTwRAIAEgCzYCFCAGRQRAIAFBADYCHAsgACAINgIEIABBCGogCzYCAEEBIQcMCAsgB0F/aiIHIAVPDQEgByAIaiIMIANPDQIgBCAHai0AACACIAxqLQAARg0ACyABIAggDmoiCDYCFCAGDQUgASAPNgIcDAULQZiWygAgByAFEOQCAAtBqJbKACAMIAMQ5AIACyAHIAhqIgkgA08NASAHIBBqIQwgBCAHaiAHQQFqIQctAAAgDC0AAEYNAAsgASAIIA1qIAdqIgg2AhQgBg0BIAFBADYCHAwBCwtBiJbKACAJIAMQ5AIACyAAIAc2AgAL8AMBBH8jAEFAaiIBJAAgACgCACIDKAIAIQIgAyAAKAIENgIAIAEgAkEDcSIANgIMIABBAkYEQAJAAkACQCACQXxxIgAEQANAIAAoAgQgACgCACECIABBADYCACACRQ0CIABBAToACCACKAIYIQAgAkECNgIYIAEgAjYCKAJAAkAgAEECTQRAIABBAWsNAgwBC0HsoMoAQRxBiKHKABC8BAALIAEoAigiAkEcaiIAKAIAIgQtAAANBCAEQQE6AABBjPrKAAJ/QYj6ygAoAgBBAUYEQEGM+soAKAIADAELQYj6ygBCATcDAEEACyIENgIAIAItACANBSAAKAIAQQA6AAALIAEoAigiACAAKAIAIgBBf2o2AgAgAEEBRgRAIAFBKGoQ0gILIgANAAsLIAFBQGskAA8LQZicygBBK0GEpMoAEM4DAAtB6KfKAEEgQaSoygAQvAQACyABIAA2AhAgASAEQQBHOgAUQfScygBBKyABQRBqQaCdygBBmKHKABCoAgALIAFBNGpBkgE2AgAgAUEkakECNgIAIAFCAzcCFCABQdSbygA2AhAgAUGSATYCLCABIAFBDGo2AjggAUGYn8oANgI8IAEgAUEoajYCICABIAFBPGo2AjAgASABQThqNgIoIAFBEGpB9KPKABCpBAALmAMCBX8BfiMAQdAAayIBJAAgACgCACECA0BBACEFA0ACQAJAAkACQAJAIAJBAXEEQCACQXxxIgMgBUEJS3INASAFQQFqIgVBBEkNAgwDCyAAIAJBAXIgACgCACIDIAIgA0YbNgIAIAIgA0cgAyECDQUgAUHQAGokAA8LIAFBAjoAICABQdTwyQAQtwQCfyABKAIABEAgAUEwahCXBSABQRBqEOgEIAFBKGogAUHIAGopAwA3AwAgAUEgaiABQUBrKQMAIgY3AwAgAUEYaiABQThqKQMANwMAIAEgASkDMDcDECABQRBqIAanQf8BcUECRw0BGkGo8MkAQStBvPHJABDOAwALIAEoAgQLIgRBAToAECADRQ0CIAQgAzYCHCAEQgA3AhQMAwsgAUEIakEAQQEgBUEfcXQQpgULIAAoAgAhAgwCCyAEQQA2AhggBCAENgIUCyAAIAJBA3EgBHIgACgCACIDIAIgA0YbNgIAIAIgA0YEQCAEEOYBIAFBEGoQ6AQMAgUgAUEQahDoBCADIQIMAQsACwALAAuFAwEFfyMAQUBqIgMkACADIAA2AhAgACgCACEAA0ACQCAAQQFxDQACQCAAQQJxIgZBAXZFBEACQAJAAkACQCAAQQRxBEAgAEEIcQ0DIAVBCUsNAiAFQQFqIgVBBEkNAQwGCyADKAIQIgQgAEF5cUEEciAEKAIAIgQgACAERhs2AgAgACAERyAEIQANByABIAZBAXYgAigCDBEAACADKAIQIgAoAgAgAEEBNgIAQQhxDQMMBgsgA0EIakEAQQEgBUEfcXQQpgUMBAsgAygCECIEIABBCHIgBCgCACIEIAAgBEYbNgIAIAAgBEcgBCEADQULIAMoAhAhACADIANBEGo2AhQgA0EBOgAaIANBAToAGyADIANBFGo2AhwgAyADQRpqNgIgIAMgA0EbajYCJCADQgA3AyhBACEFIAMgACADQRxqIANBIGogA0EkaiADQShqEEAMAgsgAygCEBAxDAILQZzryQBBKkGg7MkAELkEAAsgAygCECgCACEADAELCyADQUBrJAALwwMBA38jAEEwayIBJAAgAUHIgMoAQQsQAyICNgIUIAFBIDYCGCABIAJBIBAEIgI2AgggAUEYahCNBSABQRRqEI0FIAFBIDYCGCABQQhqIAFBGGoQrAUhAyABQRhqEI0FAkAgAwRAIAEgAjYCDCABIAIQBTYCFCABQSA2AhggAUEUaiABQRhqEKwFIQMgAUEYahCNBSABQRRqEI0FAkACQCADBEAgASACEAYiAjYCECABQRBqEL0FDQEgASACNgIUIAEgAhAHNgIYIAFBGGoQvQUgAUEYahCNBQ0CIABCgICAgBA3AgAgAEEIaiACNgIADAQLIABBCGpB9IHKAEEGEAg2AgAgAEIANwIADAMLIAFBGGpB+oHKAEEYEPwEIABBATYCACAAQRRqIAFBKGooAgA2AgAgAEEMaiABQSBqKQMANwIAIAAgASkDGDcCBCABQRBqEI0FDAILIAFBGGpBkoLKAEEjEPwEIABBATYCACAAQRRqIAFBKGooAgA2AgAgAEEMaiABQSBqKQMANwIAIAAgASkDGDcCBCABQRRqEI0FDAELQdOAygBBLkHkgcoAELkEAAsgAUEMahCNBSABQTBqJAALrQMBAn8jAEHwAmsiAyQAIANBoAJqIAIQyAUgA0EIaiADQaACaiACEB4gA0GgAmogA0EIahDIBSADQTBqIANBoAJqIAIQHiADQYABaiABIANBCGoQHiADQdABaiABIANBMGoQHiADQaACaiADQdABahBjIANB+AFqIANBoAJqQSgQ8gMaIANBoAJqIANB+AFqQQIQKiADQagBaiADQdABaiADQaACahAeIANB2ABqIANBgAFqIANBqAFqEB4gA0GgAmogA0HYAGoQyAUgA0HQAWogAiADQaACahAeIANB0AFqIAEQ9wMhBCADQaACaiABENkDIANB0AFqIANBoAJqEPcDIQIgA0GgAmogARDZAyADQfgBaiADQaACakG4+sMAEB4gA0HQAWogA0H4AWoQ9wMhASADQfgBakG4+sMAIANB2ABqEB4gA0HYAGogA0H4AWogASACchCWBRCIAiADQdgAahDCBCEBIANBoAJqIANB2ABqENkDIANB2ABqIANBoAJqIAEQiAIgACACIARyEJYFOgAAIABBCGogA0HYAGpBKBDyAxogA0HwAmokAAutAwECfyMAQfACayIDJAAgA0GgAmogAhDIBSADQQhqIANBoAJqIAIQHiADQaACaiADQQhqEMgFIANBMGogA0GgAmogAhAeIANBgAFqIAEgA0EIahAeIANB0AFqIAEgA0EwahAeIANBoAJqIANB0AFqEGMgA0H4AWogA0GgAmpBKBDyAxogA0GgAmogA0H4AWpBAhAqIANBqAFqIANB0AFqIANBoAJqEB4gA0HYAGogA0GAAWogA0GoAWoQHiADQaACaiADQdgAahDIBSADQdABaiACIANBoAJqEB4gA0HQAWogARD3AyEEIANBoAJqIAEQ2QMgA0HQAWogA0GgAmoQ9wMhAiADQaACaiABENkDIANB+AFqIANBoAJqQeCsyAAQHiADQdABaiADQfgBahD3AyEBIANB+AFqQeCsyAAgA0HYAGoQHiADQdgAaiADQfgBaiABIAJyEJYFEIgCIANB2ABqEMIEIQEgA0GgAmogA0HYAGoQ2QMgA0HYAGogA0GgAmogARCIAiAAIAIgBHIQlgU6AAAgAEEIaiADQdgAakEoEPIDGiADQfACaiQAC/ACAgZ/AX4jAEEQayIDJAAgA0EBOgAOIAACfwJAAkACQAJAAn8CQCABBEAgAUEISQ0BIAFB/////wFxIAFHDQMgAUEDdEEHbgwCCyAAQRBqQgA3AgAgAEEIakKAgICAwAA3AgAgAEEEakGU9cgANgIAQQAMBgsgAUEBagshASADQQE6AA9BfyABQX9qZ3YiAUEIaiICIAFBBWoiBkkNASABQQFqIgWtQgx+IghCIIinDQEgAkF8cSICIAinaiIEIAJJDQEgBEEEEKQFIgcNAiAEQQQQ3QUACyADQQ5qEP4EDAILIANBD2oQ/gQMAQsgAiAHQf8BIAYQwQQiBGohAiAFQQRJBEAgBCAFakGAAUEDIAFrEMEEGgsgAEEUaiABIAVBA3ZBB2wgAUEISRs2AgAgAEEQakEANgIAIABBDGogAjYCACAAQQhqIAE2AgAgAEEEaiAENgIAQQAMAQsgAEEAOgABQQELOgAAIANBEGokAAuZAwECfyMAQaAFayIDJAAgA0EIaiACEMEBQQAhAiADQcgAakEAQSgQwQQaIANB+ABqQgA3AwAgA0GAAWpCADcDACADQYgBakIANwMAIANBkAFqQgA3AwAgA0IBNwNwIANCATcDmAEgA0GgAWpBAEHIABDBBBoDQCACIgRBP00EQCAEQQFqIQIgBEEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgA0GIA2ogA0HIAGoQxQEgA0HIAGogA0GIA2pBoAEQ8gMaQQAhAgNAIAIiBEE/TQRAIARBAWoiAkEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgACADQcgAakGgARDyAxogA0GgBWokAAuZAwECfyMAQaAFayIDJAAgA0EIaiACEMIBQQAhAiADQcgAakEAQSgQwQQaIANB+ABqQgA3AwAgA0GAAWpCADcDACADQYgBakIANwMAIANBkAFqQgA3AwAgA0IBNwNwIANCATcDmAEgA0GgAWpBAEHIABDBBBoDQCACIgRBP00EQCAEQQFqIQIgBEEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgA0GIA2ogA0HIAGoQxQEgA0HIAGogA0GIA2pBoAEQ8gMaQQAhAgNAIAIiBEE/TQRAIARBAWoiAkEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgACADQcgAakGgARDyAxogA0GgBWokAAudAwEDfyMAQbADayIDJAAgAAJ/AkAgAkEgRwRAIANB3AFqQtKAgICABDcCACADQdgBakHPgMAANgIAIANB1AFqQQk2AgAgA0HQAWpBxoDAADYCACADQQM6AMwBIANBATYCyAEgAyADQcgBakEEckHEARDyAxoMAQsgA0GoA2oiAkIANwMAIANBoANqIgRCADcDACADQZgDaiIFQgA3AwAgA0IANwOQAyADQZADakEgIAFBIBCuASADQRhqIAIpAwA3AwAgA0EQaiAEKQMANwMAIANBCGogBSkDADcDACADIAMpA5ADNwMAIANByAFqIAMQiQEgAygCyAEgAyADQcgBakEEckHEARDyAyECQQFGDQAgAEEIaiACQQRqQcABEPIDGkEADAELIANB2AFqIANBEGopAgA3AwAgA0HQAWogA0EIaikCADcDACADIAMpAgA3A8gBIANBkANqIANByAFqEKoEIABBFGogA0GgA2opAwA3AgAgAEEMaiADQZgDaikDADcCACAAIAMpA5ADNwIEQQELNgIAIANBsANqJAALkAMBAX8jAEHABGsiBSQAIAUgAzYCDCAFIAI2AgggBUEQahCyAyAFQRBqIAFBIGoQxgUgBUEQaiAFQQhqEK4EIAVB6AJqIAVBEGpB2AEQ8gMaIAVBiAJqIAVB6AJqEOICIAVB6AJqIAVBiAJqQZDJxAAQzQUgBUHoAWogBUHoAmoQ2AEgBUHoAmoQsgMgBUEQaiAFQegCakHYARDyAxogBUEQaiAFQegBahDGBSAFQRBqIARBoAFqEMYFIAVBEGogBUEIahCuBCAFQegCaiAFQRBqQdgBEPIDGiAFQcgCaiAFQegCahDiAiAFQegCaiAFQcgCaiABEMADIAVBqAJqIAVB6AJqIAVBiAJqEBMgAEEYaiAFQYACaikDADcAACAAQRBqIAVB+AFqKQMANwAAIABBCGogBUHwAWopAwA3AAAgACAFKQPoATcAACAAIAUpAKgCNwAgIABBKGogBUGwAmopAAA3AAAgAEEwaiAFQbgCaikAADcAACAAQThqIAVBwAJqKQAANwAAIAVBwARqJAALlgMBB38jAEGABWsiAiQAIAJBEGoQsgMgAkHoAWpBAEHAABDBBBogAkHAAmoiA0IANwMAIAJBuAJqIgRCADcDACACQbACaiIFQgA3AwAgAkIANwOoAiACQeACaiIGQgA3AwAgAkHYAmoiB0IANwMAIAJB0AJqIghCADcDACACQgA3A8gCIAJBEGogARDGBSACQagDaiACQRBqQdgBEPIDGiACQegCaiACQagDahChBCACQQhqIAJB6AJqEKkFIAJB6AFqQcAAIAIoAgggAigCDBCwASACQagCakEgIAJB6AFqQSAQsAEgAkHIAmpBICACQYgCakEgELABIAIgAi0AqAJB+AFxOgCoAiACIAItAMcCQT9xQcAAcjoAxwIgAkHAA2ogAykDADcDACACQbgDaiAEKQMANwMAIAJBsANqIAUpAwA3AwAgAiACKQOoAjcDqAMgACACQagDahC7AyAAQThqIAYpAwA3AAAgAEEwaiAHKQMANwAAIABBKGogCCkDADcAACAAIAIpA8gCNwAgIAJBgAVqJAAL9AIBBH8jAEHQAGsiAyQAIANBCGoQrAIgA0EoaiIGIANBHGooAgA2AgAgAyADQRRqKQIANwMgIANBEGooAgAhBCADKAIMIQUCQAJAIAMoAghBAUcEQCADIAQ2AgQgAyAFNgIAIANBIGogAyABIAIQpwEgAy0AMEEFRw0BIANBIGoQmAUgACADKQMANwIEIABBADYCAAwCCyADQRhqIAYoAgA2AgAgAyAENgIMIAMgBTYCCCADIAMpAyA3AxAgA0E4aiADQQhqELgEIABBFGogA0HIAGooAgA2AgAgAEEMaiADQUBrKQMANwIAIAAgAykDODcCBCAAQQE2AgAMAQsgA0EYaiADQTBqKAIANgIAIANBEGogA0EoaikDADcDACADIAMpAyA3AwggA0E4aiADQQhqELgEIABBFGogA0HIAGooAgA2AgAgAEEMaiADQUBrKQMANwIAIAAgAykDODcCBCAAQQE2AgAgAxCMBQsgA0HQAGokAAuRAgECfyMAQeAAayICJAAgAkEgNgIQIAJBIDYCFCACQQQ2AkggAkEgNgJEIAIgATYCQCACQSBqIAAgAEEgaiACQUBrEOYDIAJB2ABqIAJBOGooAgA2AgAgAkHQAGogAkEwaikDADcDACACQcgAaiIBIAJBKGopAwA3AwAgAiACKQMgNwNAAkADQCACKAJUIgAgAigCWEkEQCACIABBAWo2AlQgAigCQCEDIAJBCGogASAAEM0DIAIoAgxBA00NAiACKAIIIAMgAEECdGooAgAiAEEYdCAAQQh0QYCA/AdxciAAQQh2QYD+A3EgAEEYdnJyNgAADAELCyACQeAAaiQADwtByOXJAEEgQdTkyQAQtAQAC4sDAQF/IwBBgAZrIgIkACACQQhqIAEQyAUgAkHYBWogAkEIahDIBSACQTBqIAJB2AVqEMgFIAJB2ABqIAEgAkEwahAeIAJBgAFqIAJBCGogAkHYAGoQHiACQagBaiACQYABahDIBSACQdABaiACQdgAaiACQagBahAeIAJB+AFqIAJB0AFqQQUQKiACQaACaiACQfgBaiACQdABahAeIAJByAJqIAJBoAJqQQoQKiACQfACaiACQcgCaiACQaACahAeIAJBmANqIAJB8AJqQRQQKiACQcADaiACQZgDaiACQfACahAeIAJB6ANqIAJBwANqQQoQKiACQZAEaiACQegDaiACQaACahAeIAJBuARqIAJBkARqQTIQKiACQeAEaiACQbgEaiACQZAEahAeIAJBiAVqIAJB4ARqQeQAECogAkGwBWogAkGIBWogAkHgBGoQHiACQdgFaiACQbAFakEyECogACACQdgFaiACQZAEahAeIABBKGogAkGAAWpBKBDyAxogAkGABmokAAu2AwEBfyMAQdAAayICJAACfwJAAkACQAJAAkAgACgCAEEBaw4EAgMEAAELIAIgAEEEajYCICACIABBCGo2AiQgAkEYaiACQSBqQcEAEKYFIAJBzABqQcIANgIAIAJBPGpBAjYCACACQgI3AiwgAkHE3skANgIoIAIgAikDGDcDQCACIAJBJGo2AkggAiACQUBrNgI4IAEgAkEoahDoAgwECyACQTxqQQA2AgAgAkG838kANgI4IAJCATcCLCACQczfyQA2AiggASACQShqEOgCDAMLIAJBPGpBADYCACACQbzfyQA2AjggAkIBNwIsIAJBtN/JADYCKCABIAJBKGoQ6AIMAgsgAiAAQQRqNgIkIAJBCGogAkEkakHBABCmBSACQTxqQQE2AgAgAkIBNwIsIAJBlN/JADYCKCACIAIpAwg3A0AgAiACQUBrNgI4IAEgAkEoahDoAgwBCyACIABBBGo2AiQgAkEQaiACQSRqQcEAEKYFIAJBPGpBATYCACACQgE3AiwgAkH43skANgIoIAIgAikDEDcDQCACIAJBQGs2AjggASACQShqEOgCCyACQdAAaiQAC+cCAQZ/AkACQCACQQNxIgRFDQBBBCAEayIERQ0AIAMgBCAEIANLGyEFQQAhBCABQf8BcSEIA0AgBCAFRg0BIAIgBGogBEEBaiEELQAAIgYgCEcNAAtBASEDIAYgAUH/AXFGQQFqQQFxIARqQX9qIQQMAQsgAUH/AXEhCAJAAkAgA0EISQ0AIAUgA0F4aiIGSw0AIAhBgYKECGwhBANAIAIgBWoiB0EEaigCACAEcyIJQX9zIAlB//37d2pxIAcoAgAgBHMiB0F/cyAHQf/9+3dqcXJBgIGChHhxRQRAIAVBCGoiBSAGTQ0BCwsgBSADSw0BCyACIAVqIQIgAyAFayEGQQAhA0EAIQQCQANAIAQgBkYNASACIARqIARBAWohBC0AACIHIAhHDQALQQEhAyAHIAFB/wFxRkEBakEBcSAEakF/aiEECyAEIAVqIQQMAQsgBSADEOYCAAsgACAENgIEIAAgAzYCAAv8AgEGfyMAQTBrIgIkACABKAIAIQYgASgCBCIHQQN0IgUEQCAGQQRqIQMDQCADKAIAIARqIQQgA0EIaiEDIAVBeGoiBQ0ACwsCQAJAAkACQAJAIAFBFGooAgBFBEAgBCEDDAELIAdFBEBBlKnKAEEAQQAQ5AIACwJAIARBD00EQCAGQQRqKAIARQ0BCyAEIARqIgMgBE8NAQtBASEFQQAhAyACQQhqIQQMAQsgA0F/TA0BIAJBCGohBCADRQRAQQEhBUEAIQMMAQsgA0EBEKQFIgVFDQILIAJBADYCECACIAM2AgwgAiAFNgIIIAIgAkEIajYCFCACQShqIAFBEGopAgA3AwAgAkEgaiABQQhqKQIANwMAIAIgASkCADcDGCACQRRqQbSoygAgAkEYahAzDQIgACAEKQIANwIAIABBCGogBEEIaigCADYCACACQTBqJAAPCxDrBQALIANBARDdBQALQbSpygBBMyACQRhqQaSpygBB/KnKABCoAgAL1AICBn8EfiMAQbACayIDJAAgA0EIakEAQYACEMEEGiADQZACaiABQQhqKQAANwMAIANBmAJqIAFBEGopAAA3AwAgA0GgAmogAUEYaikAADcDACADQgA3A6gCIAMgASkAADcDiAJBwAAgAmshB0IBIAJBP3GthiIJQgGIIQogCUJ/fCELIAmnIQhBACEBA0BBACABayEEA0AgAUGAAkkEQCABQQZ2IQUCfiABQT9xIgYgB0kEQCADQYgCaiAFQQN0aikDACAGrYgMAQsgA0GIAmogBUEDdGoiBUEIaikDACAEQT9xrYYgBSkDACAGrYiECyALgyAMfCIJQgGDUARAIARBf2ohBCABQQFqIQEMAgUgA0EIaiABaiAJp0EAIAggCSAKVBtrOgAAIAIgBGshASAJIAparSEMDAMLAAsLCyAAIANBCGpBgAIQ8gMaIANBsAJqJAALnQMBBX8jAEGQAmsiAyQAIANByIbAAEEUEPUDIANB3IbAAEEKQayDwABBABDSAyACLQAABEAgA0GIAmogAkEZaikAADcDACADQYACaiACQRFqKQAANwMAIANB+AFqIAJBCWopAAA3AwAgAyACKQABNwPwASADQfCGwABBCiADQfABakEgENIDCyADQfABaiABENYDIANBnYfAAEEKIANB8AFqQSAQ0gMgA0HoAWoiAUIANwMAIANB4AFqIgJCADcDACADQdgBaiIEQgA3AwAgA0IANwPQASADQaeHwABBCSADQdABakEgENMDIANBiAJqIgVCADcDACADQYACaiIGQgA3AwAgA0H4AWoiB0IANwMAIANCADcD8AEgA0GPh8AAQQ4gA0HwAWpBIBDTAyAAQRhqIAEpAwA3AAAgAEEQaiACKQMANwAAIABBCGogBCkDADcAACAAIAMpA9ABNwAAIAAgAykD8AE3ACAgAEEoaiAHKQMANwAAIABBMGogBikDADcAACAAQThqIAUpAwA3AAAgAxC3BSADQZACaiQAC/oCAQN/IwBBwANrIgMkACAAAn8CQCACQSBHBEAgA0HsAWpC0oCAgIAENwIAIANB6AFqQbHvwwA2AgAgA0HkAWpBCTYCACADQeABakGo78MANgIAIANBAzoA3AEgA0EBNgLYASADQRBqIANB2AFqQQRyQcQBEPIDGgwBCyADQbgDaiICQgA3AwAgA0GwA2oiBEIANwMAIANBqANqIgVCADcDACADQgA3A6ADIANBCGogAUEgQSAQngQgA0GgA2pBICADKAIIIAMoAgwQrQEgA0EoaiACKQMANwMAIANBIGogBCkDADcDACADQRhqIAUpAwA3AwAgAyADKQOgAzcDECADQdgBaiADQRBqEIkBIAMoAtgBIANBEGogA0HYAWpBBHJBxAEQ8gMaQQFGDQAgAEEIaiADQRRqQcABEPIDGkEADAELIAAgAykCEDcCBCAAQRRqIANBIGopAgA3AgAgAEEMaiADQRhqKQIANwIAQQELNgIAIANBwANqJAALlwMCBH8CfiMAQUBqIgUkAEEBIQcCQCAALQAEDQAgAC0ABSEIIAAoAgAiBi0AAEEEcUUEQCAGKAIYQaWsygBBp6zKACAIG0ECQQMgCBsgBkEcaigCACgCDBEEAA0BIAAoAgAiBigCGCABIAIgBkEcaigCACgCDBEEAA0BIAAoAgAiASgCGEGcq8oAQQIgAUEcaigCACgCDBEEAA0BIAMgACgCACAEKAIMEQIAIQcMAQsgCEUEQCAGKAIYQaCsygBBAyAGQRxqKAIAKAIMEQQADQEgACgCACEGCyAFQQE6ABcgBUE0akGErMoANgIAIAUgBikCGDcDCCAFIAVBF2o2AhAgBikCCCEJIAYpAhAhCiAFIAYtACA6ADggBSAKNwMoIAUgCTcDICAFIAYpAgA3AxggBSAFQQhqNgIwIAVBCGogASACEEYNACAFQQhqQZyrygBBAhBGDQAgAyAFQRhqIAQoAgwRAgANACAFKAIwQaOsygBBAiAFKAI0KAIMEQQAIQcLIABBAToABSAAIAc6AAQgBUFAayQAC7YDAgR/AX4jAEEwayIBJAACQAJAAkACQAJ/QQAgACgCACICRQ0AGiABIAApAgQ3AiQgASACNgIgIAFBEGogAUEgahD5BCABQQhqQQAgASgCECIAIAEoAhgQZSABKAIIDQEgAUEoaiABQRhqKAIANgIAIAEgASkDEDcDICABIAFBIGoQbiABKAIEIQMgASgCAAshBEGQ+soALQAADQFBkPrKAEEBOgAAAkBBmPvKACkDACIFQn9SBEBBmPvKACAFQgF8NwMAIAVCAFINAUGYnMoAQStBnKDKABDOAwALQdSfygBBN0GMoMoAELwEAAtBkPrKAEEAOgAAQQFBARCkBSICRQ0CIAJBADoAAEEwQQgQpAUiAEUNAyAAQgE3AiQgAEEANgIYIAAgAzYCFCAAIAQ2AhAgACAFNwMIIABCgYCAgBA3AwAgACACrTcCHCABQTBqJAAgAA8LIAEoAgwhAiABQShqIAEpAhQ3AwAgASAANgIkIAEgAjYCIEGsoMoAQS8gAUEgakHUnMoAQdygygAQqAIAC0Hop8oAQSBBpKjKABC8BAALQQFBARDdBQALQTBBCBDdBQAL9AIBAn8jAEHgA2siAiQAIAIgARCbAiACQThqQgA3AwAgAkFAa0IANwMAIAJByABqQgA3AwAgAkIANwMwIAJCATcDKCACQdAAaiACEMgFIAJB+ABqIAJB0ABqIAJBKGoQ3wEgAkHwAWogAkHQAGpBgOvIABAeIAJBoAFqIAJB8AFqIAJBKGoQ1QMgAkHwAWogAkH4AGogAkGgAWoQWiACLQDwASEDIAJByAFqIAJB+AFqQSgQ8gMaIAAgA0EBRgR+IAEtAB9BB3YQlgUhASACQfABaiACQcgBahDZAyACQcgBaiACQfABaiABEIgCIAJB8AFqIAJByAFqQSgQ8gMaIAJBkANqIAJBKBDyAxogAkG4A2ogAkHIAWogAhAeIAJBmAJqIAJBkANqQSgQ8gMaIAJBwAJqIAJBKGpBKBDyAxogAkHoAmogAkG4A2pBKBDyAxogAEEIaiACQfABakGgARDyAxpCAQVCAAs3AwAgAkHgA2okAAuWAwIEfwF+IwBBIGsiASQAIAEgAEHMAGo2AhggAEEMaiEDIAApAwAhBSAAKAIIIQIgASABQRhqNgIcAkACQAJAIAJBwABGBEAgAUEcaiADELoFQQAhAiAAQQA2AggMAQsgAkE/Sw0BCyACIABBDGoiBGpBgAE6AAAgACAAKAIIQQFqIgI2AgggAUEQaiAEQcAAIAIQnQQgASgCEEEAIAEoAhQQwQQaQcAAIAAoAghrQQdNBEAgAUEcaiADELoFIAFBCGpBACAAKAIIIARBwAAQ1AMgASgCCEEAIAEoAgwQwQQaCyABIARBwABBOBCdBCABKAIEQQdNDQEgASgCACAFQiiGQoCAgICAgMD/AIMgBUI4hoQgBUIYhkKAgICAgOA/gyAFQgiGQoCAgIDwH4OEhCAFQgiIQoCAgPgPgyAFQhiIQoCA/AeDhCAFQiiIQoD+A4MgBUI4iISEhDcAACABQRxqIAMQugUgAEEANgIIIAFBIGokAA8LQaTkyQAgAkHAABDkAgALQejlyQBBIEHU5MkAELQEAAvwAgEEfwJAAkACQCABQQRqKAIAIgIgASgCCCIDRgRAIANBAWoiAiADSSACQQBIcg0BAn8gA0UEQCACQQEQpAUMAQsgASgCACADQQEgAhCUBQsiBEUNAiABIAQ2AgAgAUEEaiACNgIACyACIANHBEAgA0EBaiEEIAEoAgAhBQwDCyADQQFqIgQgA0kNACADQQF0IgIgBCACIARLGyICQQBIDQACfyADRQRAIAJBARCkBQwBCyABKAIAIANBASACEJQFCyIFBEAgASAFNgIAIAFBBGogAjYCAAwDCyACQQEQ3QUACxDCBQALIAJBARDdBQALIAMgBWpBADoAACABIAQ2AggCQAJAAkAgAiAERg0AIAIgBEkNASAERQRAIAJFBEBBASEFDAILIAUgAkEBELYFQQEhBQwBCyAFIAJBASAEEJQFIgVFDQILIAAgBDYCBCAAIAU2AgAPC0GInsoAQSRB+J3KABDOAwALIARBARDdBQAL3gIBA38jAEGAA2siBCQAIARB2ABqIANBGGopAAA3AwAgBEHQAGogA0EQaikAADcDACAEQcgAaiADQQhqKQAANwMAIAQgAykAADcDQCAEQeABaiABIAIgBEFAaxDtASAEQRhqIARB+AFqKQMANwMAIARBEGogBEHwAWopAwA3AwAgBEEIaiAEQegBaikDADcDACAEIAQpA+ABNwMAIARBOGoiAyAEQZgCaikDADcDACAEQTBqIgUgBEGQAmopAwA3AwAgBEEoaiIGIARBiAJqKQMANwMAIAQgBCkDgAI3AyAgBEHgAWogBEGwh8AAEMkFIARBQGsgASAEQeABahCIBCAEQeABaiAEQUBrQaABEPIDGiAAIARB4AFqEOEEIABB2AFqIAMpAwA3AAAgAEHQAWogBSkDADcAACAAQcgBaiAGKQMANwAAIAAgBCkDIDcAwAEgAhC3BSAEQYADaiQAC+UBAQR/IwBB4ABrIgIkACACQcAANgIQIAJBwAA2AhQgAkHAADYCRCACIAE2AkAgAkEINgJIIAJBIGogACAAQUBrIAJBQGsQ5wMgAkHQAGogAkEwaikDADcDACACQdgAaiACQThqKAIAIgM2AgAgAkHIAGoiBCACQShqKQMANwMAIAIgAikDIDcDQCACKAJUIgFBA3QhAANAIAEgA0kEQCACIAFBAWoiBTYCVCACQQhqIAQgARDNAyACKAIIIAIoAgwgAigCQCAAaikDABCpAiAAQQhqIQAgBSEBDAELCyACQeAAaiQAC+ACAQR+IAAgASkDICICPAAaIAAgASkDECIDPAANIAAgASkDACIEPAAAIAAgAkIoiDwAHyAAIAJCIIg8AB4gACACQhiIPAAdIAAgAkIQiDwAHCAAIAJCCIg8ABsgACABKQMYIgJCLIg8ABkgACACQiSIPAAYIAAgAkIciDwAFyAAIAJCFIg8ABYgACACQgyIPAAVIAAgAkIEiDwAFCAAIANCKIg8ABIgACADQiCIPAARIAAgA0IYiDwAECAAIANCEIg8AA8gACADQgiIPAAOIAAgASkDCCIFQiyIPAAMIAAgBUIkiDwACyAAIAVCHIg8AAogACAFQhSIPAAJIAAgBUIMiDwACCAAIAVCBIg8AAcgACAEQiiIPAAFIAAgBEIgiDwABCAAIARCGIg8AAMgACAEQhCIPAACIAAgBEIIiDwAASAAIAJCBIYgA0IwiIQ8ABMgACAFQgSGIARCMIiEPAAGC40DAQF/IwBBEGsiAiQAAn8CQAJAAkACQAJAAkAgACgCAEEBaw4EAgMEAAELIAIgAUGpucYAQRAQvwQgAiAAQQRqNgIMIAJBubnGAEEGIAJBDGpBwLnGABBqIAIgAEEMajYCDCACQdC5xgBBCCACQQxqQdi5xgAQaiACIABBEGo2AgwgAkHoucYAQQYgAkEMakHAucYAEGogAiAAQRhqNgIMIAJB7rnGAEEIIAJBDGpB2LnGABBqIAIgAEEcajYCDCACQfa5xgBBBiACQQxqQcC5xgAQaiACIABBJGo2AgwgAkH8ucYAQQggAkEMakHYucYAEGogAhCxAgwFCyACIAFBurrGAEEXEJwEDAMLIAIgAUGpusYAQREQnAQMAgsgAiABQY+6xgBBEBC/BCACIABBBGo2AgwgAkGfusYAQQQgAkEMakHAucYAEGogAiAAQQxqNgIMIAJBo7rGAEEGIAJBDGpB2LnGABBqIAIQsQIMAgsgAiABQYS6xgBBCxCcBAsgAhCAAgsgAkEQaiQAC9kCAgR/An4jAEEwayIDJAAgACkDwAEiB6dB/wBxIQRBACAHUEUgBBtFBEAgA0EoaiABIAIgAkGAASAEayIFIAUgAksbEJ4EIAMoAighBiADQSBqIAEgAiADKAIsIgUQnQQgAygCJCECIAMoAiAhASADQRhqIAAgBBDEBCADKAIYIAMoAhwgBiAFEOQEIAAgACkDwAEiByAFrXwiCCAHWq0gCBCDBTcDwAELA0AgAkH/AE0EQCACBEAgAEIAEAsgAEGAASABIAIQ5AQgACAAKQPAASIHIAKtfCIIIAdarSAIEIMFNwPAAQsgA0EwaiQABSAAQgAQCyADQRBqIAEgAkGAARCeBCADKAIQIQUgA0EIaiABIAIgAygCFCIEEJ0EIAMoAgwhAiADKAIIIQEgAEGAASAFIAQQ5AQgACAAKQPAASIHIAStfCIIIAdarSAIEIMFNwPAAQwBCwsL1QICBn8DfiMAQYDCAGsiASQAIAFBCGoQ3AEgAUH4IGogAUEIakHoIBDyAxogAUIBNwPwIANAIABBIGoiA0HwIE0EQCAAQajYygBqIgIpAwAhBiACIAFB8CBqIABqIgApAwA3AwAgACAGNwMAIAJBCGoiBCkDACEGIAQgAEEIaiIEKQMANwMAIAJBEGoiBSkDACEHIAUgAEEQaiIFKQMANwMAIAJBGGoiAikDACEIIAIgAEEYaiIAKQMANwMAIAAgCDcDACAFIAc3AwAgBCAGNwMAIAMhAAwBCwsgAUHQwQBqIgApAwAhBiAAQYj5ygApAwA3AwBBiPnKACAGNwMAQZD5ygAoAgAhAEGQ+coAIAFB2MEAaikDADcDAAJAIAEpA/AgUCAAQSRJcg0AIAEoAtRBIgNBAUYgA0F+akECS3JFDQAgABAACyABQYDCAGokAEGw2MoAC4wCAgJ/AX4jAEEwayIEJAACQCABKAIEIAJrIANPDQAgBEEgaiABIAIgAxCvAkEBIQUgBCgCJCECIAQoAiBBAUYEQCAEIAIgBEEoaigCABCmBSAAIAQpAwA3AgQMAQsCQAJAAkAgAq1C8AB+IgZCIIinRQRAIAanIgNBAEgNAQJ/IAEoAgQiBUUEQCADQQgQpAUMAQsgASgCACAFQfAAbEEIIAMQlAULIgUEQCABIAI2AgQgASAFNgIAQQAhBQwFCwwCCyAEQQhqIARBABCmBSAAIAQpAwg3AgQMAgsgBEEQaiAEQQAQpgUgACAEKQMQNwIEDAELIANBCBDdBQALCyAAIAU2AgAgBEEwaiQAC4kCAQN/IwBBMGsiAyQAAkAgASgCBCACa0EBTw0AIANBIGogASACQQEQrwJBASEEIAMoAiQhAiADKAIgQQFGBEAgAyACIANBKGooAgAQpgUgACADKQMANwIEDAELAkACQAJAIAIgAkH/////AXFGBEAgAkEDdCIFQQBIDQECfyABKAIEIgRFBEAgBUEEEKQFDAELIAEoAgAgBEEDdEEEIAUQlAULIgQEQCABIAI2AgQgASAENgIAQQAhBAwFCwwCCyADQQhqIANBABCmBSAAIAMpAwg3AgQMAgsgA0EQaiADQQAQpgUgACADKQMQNwIEDAELIAVBBBDdBQALCyAAIAQ2AgAgA0EwaiQAC74CAgV/AX4jAEEwayIEJABBJyECAkAgAEKQzgBUBEAgACEHDAELA0AgBEEJaiACaiIDQXxqIAAgAEKQzgCAIgdCkM4Afn2nIgVB//8DcUHkAG4iBkEBdEG5rMoAai8AADsAACADQX5qIAUgBkHkAGxrQf//A3FBAXRBuazKAGovAAA7AAAgAkF8aiECIABC/8HXL1YgByEADQALCyAHpyIDQeMASgRAIAJBfmoiAiAEQQlqaiAHpyIDIANB//8DcUHkAG4iA0HkAGxrQf//A3FBAXRBuazKAGovAAA7AAALAkAgA0EKTgRAIAJBfmoiAiAEQQlqaiADQQF0QbmsygBqLwAAOwAADAELIAJBf2oiAiAEQQlqaiADQTBqOgAACyABQcSqygBBACAEQQlqIAJqQScgAmsQNSAEQTBqJAALgQMBAX8jAEEQayICJAACfwJAAkACQAJAAkACQAJAAkAgAC0AAEEBaw4GAgMEBQYAAQsgAiABQYbxwwBBERC/BCACIABBAWo2AgwgAkGX8cMAQQsgAkEMakGk8cMAEGogAiAAQQJqNgIMIAJBtPHDAEEJIAJBDGpBwPHDABBqDAYLIAIgAUHg8sMAQQ0QnAQgAhCAAgwGCyACIAFByfLDAEEXEJwEIAIQgAIMBQsgAiABQbjywwBBERCcBCACEIACDAQLIAIgAUHu8cMAQRAQvwQgAiAAQQRqNgIMIAJB/vHDAEEEIAJBDGpBhPLDABBqIAIgAEEMajYCDCACQZTywwBBCyACQQxqQYTywwAQaiACIABBFGo2AgwgAkGf8sMAQQYgAkEMakGo8sMAEGoMAgsgAiABQdvxwwBBExCcBCACEIACDAILIAIgAUHQ8cMAQQsQvwQgAiAAQQFqNgIMIAJBl/HDAEELIAJBDGpBpPHDABBqCyACELECCyACQRBqJAALqAIBAn8jAEHQAGsiAyQAIANBMGogASACEC8Cf0ECIAMoAjBBAUYNABpBAiADKAI0IgRFDQAaIANBMGogBCADQThqKAIAENsCQQIgAy0ATCIEQQJGDQAaIANBKGogA0HIAGooAgA2AgAgA0EgaiADQUBrKQMANwMAIANBGGogA0E4aikDADcDACADQQ5qIANBzwBqLQAAOgAAIAMgAykDMDcDECADIAMvAE07AQwgBAshBCAAIAI2AgQgACABNgIAIAAgAykDEDcCCCAAQSRqIAQ6AAAgAEElaiADLwEMOwAAIABBEGogA0EYaikDADcCACAAQRhqIANBIGopAwA3AgAgAEEgaiADQShqKAIANgIAIABBJ2ogA0EOai0AADoAACADQdAAaiQAC+0BAQJ/IwBBIGsiBCQAIAACf0EAIAEoAgQiBSACayADTw0AGgJAAkAgAiADaiIDIAJPBEAgBUEBdCICIAMgAiADSxshAwwBCyAAIAM2AgQMAQsgBEKBgICAEDcDGCAEQQhqIARBGGogAxD0AiAEKAIIIQICQCAEKAIMIgUEQCACQQBIDQICfyABKAIEIgBFBEAgAiAFEKQFDAELIAEoAgAgAEEBIAIQlAULIgAEQCABIAM2AgQgASAANgIAQQAMBAsMAQsgACACNgIEDAELIAIgBRDdBQALIABBCGpBADYCAEEBCzYCACAEQSBqJAAL3wIBB38jAEEwayICJAACQAJAIAAtANEBRQRAIABBAToA0QEgAC0A0AEhAyAAKALMASEEIAJBKGogAEHIASAAKALIARCdBCACQSBqIAIoAiggAigCLEEBEJ4EIAIoAiRFDQEgAigCICIFIAUtAAAgA3M6AAAgAkEYaiAAQcgBIARBf2oQnQQgAkEQaiACKAIYIAIoAhxBARCeBCACKAIURQ0CIAIoAhAiAyADLQAAQYABczoAACAAELgFCyAAKALMASAAKALIASIFayEDQSAhBANAIAJBCGogAUEgIAYQnQQgAigCDCEHIAIoAgghCCAEIANPBEAgACAIIAcgBSADEP4CIAAQJyAEIANrIQQgAyAGaiEGIAAoAswBIQNBACEFDAELCyAAIAggByAFIAQQ/gIgACAEIAVqNgLIASACQTBqJAAPC0HMwcQAQQBBABDkAgALQdzBxABBAEEAEOQCAAuoAgEEfyMAQeAgayICJAAgAkEYaiIDQgA3AwAgAkEQaiIEQgA3AwAgAkEIaiIFQgA3AwAgAkIANwMAIAJBIGogASACQSAQOyAAAn8gAi0AMEEFRgRAIAJBIGoQygMgAkHYIGogAykDADcDACACQdAgaiAEKQMANwMAIAJByCBqIAUpAwA3AwAgAiACKQMANwPAICACQThqIAJBwCBqEA8gAEEEaiACQThqQYQgEPIDGkEADAELIAJByABqIAJBMGooAgA2AgAgAkFAayACQShqKQMANwMAIAIgAikDIDcDOCACQcAgaiACQThqELgEIABBFGogAkHQIGooAgA2AgAgAEEMaiACQcggaikDADcCACAAIAIpA8AgNwIEQQELNgIAIAJB4CBqJAALsAIBC38jAEEgayIEJAAgBEEANgIQIAIgAyAEQRBqEMkBIAQoAhAiBUEZdiIGQQh0IAZyIgZBEHQgBnIhCyABKAIEIgggBXEhBSABKAIIIQkgASgCACEMIAACfwJAA0AgBSAMaigAACIKIAtzIgFBf3MgAUH//ft3anFBgIGChHhxIQEgDUEEaiINIAVqIAhxIQYDQCABRQRAIAYhBSAKIApBAXRxQYCBgoR4cUUNAgwDCyABENIFIQcgAUF/aiABcSEBIAIgAyAJIAUgB2ogCHEiDkEMbGoiBygCACAHKAIEEL8FRQ0ACwsgB0UNACAAIAkgDkEMbGovAQg7AQJBAAwBCyAEQQE2AhAgBEEIaiAEQRBqEMEDIABBBGogBCkDCDcCAEEBCzsBACAEQSBqJAALygICBH8CfiMAQTBrIgMkACAAIAApAwgiByACrUIDhnwiCDcDCCAIIAdUBEAgACAAKQMAQgF8NwMACyADIABBEGo2AhggACgCUCEEIAMgA0EYajYCHAJAIARFDQBBgAEgBGsiBCACSw0AIANBIGogASACIAQQtwMgA0EsaigCACECIAMoAighASADKAIkIQQgAygCICEFIANBEGogAEHUAGoiBkGAASAAKAJQEJ0EIAMoAhAgAygCFCAFIAQQsQEgAEEANgJQIANBHGogBhC7BQsDQCACQYABTwRAIANBIGogASACQYABELcDIAMoAiwhAiADKAIoIQEgA0EcaiADKAIgELsFDAELCyADQQhqIAAoAlAiBCACIARqIABB1ABqQYABENQDIAMoAgggAygCDCABIAIQsQEgACAAKAJQIAJqNgJQIANBMGokAAvcAgIDfwF+QQIhAwJAAkACQCABQXdqIgRBHksEQCABQdwARw0BDAILQfQAIQICQAJAIARBAWsOHgECAgACAgICAgICAgICAgICAgICAgICAgMCAgICAwQLQfIAIQIMAwtB7gAhAgwCCyABQQp2IQICQAJAAkACQCABQYDYB08EQEEeIQMgAkGAB0cNBAwBCyACQb7BygBqLQAAIgNBHksNAQsgAUEGdkEPcSADQQR0ckG5wsoAai0AACICQYsBTw0BQQMhAyACQQN0QbDGygBqKQMAQgEgAUE/ca2Gg1ANAiABQQFyZ0ECdkEHc61CgICAgNAAhCEFDAMLQdDAygAgA0EfEOQCAAtB4MDKACACQYsBEOQCAAsgARAyBEBBASEDDAELIAFBAXJnQQJ2QQdzrUKAgICA0ACEIQVBAyEDCyABIQILIAAgAjYCBCAAIAM2AgAgAEEIaiAFNwIAC5oCAQZ/IAAoAgAiAygCCCEAIANBgYDEADYCCCAAQYGAxABGBH8gAygCACIBIAMoAgQiAEYEQEGAgMQADwsgAyABQQFqIgI2AgAgASwAACIEQX9KBEAgBEH/AXEPCwJ/IAAgAkYEQCAAIQJBAAwBCyADIAFBAmoiAjYCACABLQABQT9xCyEGIARBH3EhBSAEQf8BcUHfAU0EQCAGIAVBBnRyDwsCfyAAIAJGBEAgACEBQQAMAQsgAyACQQFqIgE2AgAgAi0AAEE/cQsgBkEGdHIhAiAEQf8BcUHwAUkEQCACIAVBDHRyDwsgACABRgR/QQAFIAMgAUEBajYCACABLQAAQT9xCyAFQRJ0QYCA8ABxIAJBBnRycgUgAAsL0AICBH8CfiMAQTBrIgEkACABIABBEGo2AiggAEHUAGohBCAAKQMAIQUgACkDCCEGIAAoAlAhAiABIAFBKGo2AiwCQAJAIAJBgAFGBEAgAUEsaiAEELsFQQAhAiAAQQA2AlAMAQsgAkH/AEsNAQsgAiAAQdQAaiIDakGAAToAACAAIAAoAlBBAWoiAjYCUCABQSBqIANBgAEgAhCdBCABKAIgQQAgASgCJBDBBBpBgAEgACgCUGtBD00EQCABQSxqIAQQuwUgAUEYaiADQYABIAAoAlAQngQgASgCGEEAIAEoAhwQwQQaCyABQRBqQfAAQfgAIANBgAEQ1AMgASgCECABKAIUIAUQqQIgAUEIaiADQYABQfgAEJ0EIAEoAgggASgCDCAGEKkCIAFBLGogBBC7BSAAQQA2AlAgAUEwaiQADwtB5ObJACACQYABEOQCAAuiAgEDfyMAQYABayIEJAACQAJAAn8CQCABKAIAIgNBEHFFBEAgACgCACECIANBIHENASACrSABEHcMAgsgACgCACECQQAhAANAIAAgBGpB/wBqIAJBD3EiA0EwciADQdcAaiADQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPDQIgAUG1rMoAQQIgACAEakGAAWpBACAAaxA1DAELQQAhAANAIAAgBGpB/wBqIAJBD3EiA0EwciADQTdqIANBCkkbOgAAIABBf2ohACACQQR2IgINAAsgAEGAAWoiAkGBAU8NAiABQbWsygBBAiAAIARqQYABakEAIABrEDULIARBgAFqJAAPCyACQYABEOYCAAsgAkGAARDmAgAL3AIBAX8jAEHAA2siAyQAIAJBIEcEQCADQQhqQomAgICABDcDACADQRBqIAMpAoACNwMAIANBGGogA0GIAmopAgA3AwAgA0EgaiADQZACaikCADcDACADQej6wQA2AgQgA0ECNgIAQfH6wQBBKyADQZz7wQBBwPzBABCoAgALIANBGGoiAkIANwMAIANBEGpCADcDACADQQhqQgA3AwAgA0IANwMAIANBICABQSAQrgEgAyACKQAANwCFAiADIAMpABM3A4ACIANB+AFqIAMpAIUCNwAAIAMgAy0AAjoA4gEgAyADLwEAOwHgASADIAMpAAs3AOsBIAMgAykAAzcA4wEgAyADKQOAAjcA8wEgA0GAAmogA0HgAWoQ0gEgAyADQaADakEgIAFBIBCHAiADQeABahCzAiADQYACaiADEL8DIAAgA0GAAmoQnwMgA0HAAWoQswIgA0HAA2okAAugAgIBfwF+IwBB8ABrIgMkACADIAI2AhQgAyABNgIQIANBIGoiAUIANwMAIANCADcDGCADQShqIANBEGogA0EYakEQEDsCfyADLQA4QQVGBEAgA0EoahDKAyADQeAAaiABKQMANwMAIAMgAykDGDcDWCADIANB2ABqEPADIAMpAwAhBCAAQRBqIAMpAwg3AwAgAEEIaiAENwMAQQAMAQsgA0HoAGogA0E4aigCADYCACADQeAAaiADQTBqKQMANwMAIAMgAykDKDcDWCADQUBrIANB2ABqELgEIABBFGogA0HQAGooAgA2AgAgAEEMaiADQcgAaikDADcCACAAIAMpA0A3AgRBAQshASADQRBqEJgEIAAgATYCACADQfAAaiQAC7oCAQV/IwBBQGoiAiQAIAEoAgQiA0UEQCABQQRqIQMgASgCACEEIAJBADYCICACQgE3AxggAiACQRhqNgIkIAJBOGogBEEQaikCADcDACACQTBqIARBCGopAgA3AwAgAiAEKQIANwMoIAJBJGpB5JnKACACQShqEDMaIAJBEGoiBCACKAIgNgIAIAIgAikDGDcDCAJAIAEoAgQiBUUNACABQQhqKAIAIgZFDQAgBSAGQQEQtgULIAMgAikDCDcCACADQQhqIAQoAgA2AgAgAygCACEDCyABQQE2AgQgAUEMaigCACEEIAFBCGoiASgCACEFIAFCADcCAEEMQQQQpAUiAUUEQEEMQQQQ3QUACyABIAQ2AgggASAFNgIEIAEgAzYCACAAQcClygA2AgQgACABNgIAIAJBQGskAAu4AgIGfwJ+IwBBIGsiAiQAIAJBGGpCADcDACACQRBqQgA3AwAgAkEIakIANwMAIAJCADcDAANAAkAgA0EERwRAIANBAWohByACIANBA3RqIQVBACEDIAYhBANAIANBwABGDQIgBEEgRwRAIAUgBSkDACABIARqMQAAIANBOHGthoQ3AwAgA0EIaiEDIARBAWohBAwBCwtBjLvEACAEQSAQ5AIACyAAIAIpAxgiCEIQiDcDICAAIAIpAwAiCUL/////////B4M3AwAgACAIQiSGQoCAgICA/v8HgyACKQMQIghCHIiENwMYIAAgCEIYhkKAgID4////B4MgAikDCCIIQiiIhDcDECAAIAhCDIZCgOD//////weDIAlCNIiENwMIIAJBIGokAA8LIAZBCGohBiAHIQMMAAsAC7gCAgZ/An4jAEEgayICJAAgAkEYakIANwMAIAJBEGpCADcDACACQQhqQgA3AwAgAkIANwMAA0ACQCADQQRHBEAgA0EBaiEHIAIgA0EDdGohBUEAIQMgBiEEA0AgA0HAAEYNAiAEQSBHBEAgBSAFKQMAIAEgBGoxAAAgA0E4ca2GhDcDACADQQhqIQMgBEEBaiEEDAELC0Hk7MgAIARBIBDkAgALIAAgAikDGCIIQhCINwMgIAAgAikDACIJQv////////8HgzcDACAAIAhCJIZCgICAgID+/weDIAIpAxAiCEIciIQ3AxggACAIQhiGQoCAgPj///8HgyACKQMIIghCKIiENwMQIAAgCEIMhkKA4P//////B4MgCUI0iIQ3AwggAkEgaiQADwsgBkEIaiEGIAchAwwACwALugIBBH8jAEHQAGsiAiQAAn8gARCzBSIERQRAIAIgACAAKAIMEIUEIAIoAgQhAyACKAIADAELIAAoAgghA0EBIQUgACgCAAshACACQQhqELUBIAJBIGogAkEQaikDADcDACACIAQ6ACggAiACKQMINwMYIAJBPGpB/JHKADYCACACIAU6AEAgAkEANgI0IAIgATYCMCACIAJBGGo2AjgCfyACQTBqKAIAQemOygBBERCIBQR/QQEFQQALRQRAIANBGGwhAQNAQQAgAUUNAhogAkEANgJMIAIgAkEwajYCSCACQcgAaiAAEMoBRQRAIAIoAkgiAyADKAIEQQFqNgIEIAFBaGohASAAQRhqIQAMAQsLIAIoAkgiACAAKAIEQQFqNgIEQQEMAQtBAQsgAkEYahD6AiACQdAAaiQAC6oCAQJ/IwBBkARrIgIkACACIAEQPCAAAn8gAikDAEIBUgRAIAJB9wJqIAJB1AFqIgEpAAA3AAAgAkHwAmogAkHNAWoiAykAADcDACACIAIpAMUBNwPoAiACQcUBaiACQegCakGjARDyAxogAEEBOgAEIAAgAikAxQE3AAUgAEENaiADKQAANwAAIABBFGogASkAADcAAEEBDAELIAJB6AJqQQNyIAJBCGpBoAEQ8gMaIAJBxQFqIAJB6AJqQaMBEPIDGiACIAJByAFqQaABEPIDIgNBuAFqIAFBGGopAAA3AwAgA0GwAWogAUEQaikAADcDACADQagBaiABQQhqKQAANwMAIAMgASkAADcDoAEgAEEIaiADQcABEPIDGkEACzYCACACQZAEaiQAC7YCAQF/IwBBoARrIgQkACAEQaACaiACQdABEPIDGiAEQRhqIANBGGopAAA3AwAgBEEQaiADQRBqKQAANwMAIARBCGogA0EIaikAADcDACAEIAMpAAA3AwAgBEHgAGogASAEQaACaiAEEDggBCAEQeAAakHAABDyAyIBQdgAaiICIAFBuAFqKQMANwMAIAFB0ABqIgMgAUGwAWopAwA3AwAgAUHIAGoiBCABQagBaikDADcDACABIAEpA6ABNwNAIAFB4ABqIAEQ4AQgAUGgAmogAUHgAGpBwAEQ8gMaIAFB4ANqIAFBwAAQ8gMaIAAgAUGgAmpBgAIQ8gMiAEGYAmogAikDADcAACAAQZACaiADKQMANwAAIABBiAJqIAQpAwA3AAAgACABKQNANwCAAiABQaAEaiQAC/ABAgV/AX4jAEHQAGsiAyQAIANBMGogABDRBCADQSBqIANBMGpBlPXJABCFAyADIAMtACQiBzoALCADIAMoAiAiBTYCKCAAQQhqIQZBASEEAkAgAC0AEARAEO8FIAMoAhghAAJAQX8gAykDECIIIAFSIAggAVYbIgQEfyAEBSAAIAJLDQEgACACRwtBAUYNAgtBACEECyADIAc6ACwgAyAFNgIoIANBKGoQ0gQgA0HQAGokACAEDwsgAyABIAIgCCAAEIsDIAMpAwAaIAMoAggaIAYgBSgCABCoBCAGKAIAGkGLp8oAQR1B2KfKABC8BAAL1wIBAX8jAEGAA2siAyQAIAJBIEcEQCADQfAAakK5gICAgAQ3AwAgA0HsAGpBjYDAADYCACADQegAakENNgIAIANBAzoAYCADIAMvAAA7AGEgA0GAgMAANgJkIAMgA0ECai0AADoAY0HzgcAAQSsgA0HgAGpBoILAAEHcg8AAEKgCAAsgA0H4AGpCADcDACADQfAAakIANwMAIANB6ABqQgA3AwAgA0IANwNgIANB4ABqQSAgAUEgEK4BIANBAmogAy0AZiIBOgAAIANB/wJqIANB/wBqMQAAPAAAIAMgAygCYDYC4AIgAyADLwFkOwHkAiADIAE6AOYCIAMgAykAdzcA9wIgAyADKQBnNwDnAiADIAMpAG83AO8CIANB4ABqIANB4AJqEN8EIAMgA0HgAGoQkQEgACADQeAAEJwDIANB4ABqEKIFIANB4AJqEPMBIANBgANqJAALrgIBBH8jAEEwayIDJAAgACAAKQMAIAKtQgOGfDcDACADIABBzABqNgIYIAAoAgghBCADIANBGGo2AhwCQCAERQ0AQcAAIARrIgQgAksNACADQSBqIAEgAiAEELcDIANBLGooAgAhAiADKAIoIQEgAygCJCEEIAMoAiAhBSADQRBqIABBDGoiBkHAACAAKAIIEJ0EIAMoAhAgAygCFCAFIAQQsQEgAEEANgIIIANBHGogBhC6BQsDQCACQcAATwRAIANBIGogASACQcAAELcDIAMoAiwhAiADKAIoIQEgA0EcaiADKAIgELoFDAELCyADQQhqIAAoAggiBCACIARqIABBDGpBwAAQ1AMgAygCCCADKAIMIAEgAhCxASAAIAAoAgggAmo2AgggA0EwaiQAC8MCAgN/An4jAEFAaiIDJAAgAAJ/QQEgAC0ACA0AGiAAKAIEIQUgACgCACIELQAAQQRxRQRAQQEgBCgCGEGlrMoAQa+sygAgBRtBAkEBIAUbIARBHGooAgAoAgwRBAANARogASAAKAIAIAIoAgwRAgAMAQsgBUUEQEEBIAQoAhhBrazKAEECIARBHGooAgAoAgwRBAANARogACgCACEECyADQQE6ABcgA0E0akGErMoANgIAIAMgBCkCGDcDCCADIANBF2o2AhAgBCkCCCEGIAQpAhAhByADIAQtACA6ADggAyAHNwMoIAMgBjcDICADIAQpAgA3AxggAyADQQhqNgIwQQEgASADQRhqIAIoAgwRAgANABogAygCMEGjrMoAQQIgAygCNCgCDBEEAAs6AAggACAAKAIEQQFqNgIEIANBQGskAAvCAgIDfwJ+IwBBQGoiAiQAAn9BASAALQAEDQAaIAAtAAUhBCAAKAIAIgMtAABBBHFFBEAgASAEBH9BASADKAIYQaWsygBBAiADQRxqKAIAKAIMEQQADQIaIAAoAgAFIAMLQYiaygAoAgARAgAMAQsgBEUEQEEBIAMoAhhBsqzKAEEBIANBHGooAgAoAgwRBAANARogACgCACEDCyACQQE6ABcgAkE0akGErMoANgIAIAIgAykCGDcDCCACIAJBF2o2AhAgAykCCCEFIAMpAhAhBiACIAMtACA6ADggAiAGNwMoIAIgBTcDICACIAMpAgA3AxggAiACQQhqNgIwQQEgASACQRhqQYiaygAoAgARAgANABogAigCMEGjrMoAQQIgAigCNCgCDBEEAAshASAAQQE6AAUgACABOgAEIAJBQGskAAv2AQEGfyAAKAIAIgEgACgCBCIDRgRAQYCAxAAPCyAAIAFBAWoiAjYCACABLAAAIgRBf0oEQCAEQf8BcQ8LAn8gAiADRgRAIAMhAkEADAELIAAgAUECaiICNgIAIAEtAAFBP3ELIQYgBEEfcSEFIARB/wFxQd8BTQRAIAYgBUEGdHIPCwJ/IAIgA0YEQCADIQFBAAwBCyAAIAJBAWoiATYCACACLQAAQT9xCyAGQQZ0ciECIARB/wFxQfABSQRAIAIgBUEMdHIPCyABIANGBH9BAAUgACABQQFqNgIAIAEtAABBP3ELIAVBEnRBgIDwAHEgAkEGdHJyC6ECAQN/IwBBoAJrIgIkACACQSBqQQBB4AAQwQQaIAJBGGogAkEgakHgAEHAABCeBCACKAIcIQMgAigCGCACQcABakEAQcAAEMEEGiACQYACaiABQcABahDWAyACQYACahDJAyACQRBqIAJBwAFqQcAAQSAQngQgAigCECACKAIUIAJBgAJqQSAQrQEgAkEIaiACQcABakHAAEEgEJ0EIAIoAgggAigCDCABQeABakEgEK0BIAJBgAFqIAJBwAFqQcAAEPIDGiADIAJBgAFqQcAAEK0BIAIgAkEgakHgAEHAABCdBCACKAIEIQMgAigCACACQcABaiABQaABahDWAyADIAJBwAFqQSAQrQEgACACQSBqQeAAEPIDGiACQaACaiQAC5ACAQJ/IwBBkANrIgMkACADIAFBKGoiBCABENUDIANBKGogBCABEN8BIANB0ABqIAMgAhAeIANB+ABqIANBKGogAkEoahAeIANBoAFqIAFB+ABqIAJB+ABqEB4gA0HIAWogAUHQAGogAkHQAGoQHiADQfABaiADQcgBaiADQcgBahDVAyAAIANB0ABqIANB+ABqEN8BIANBmAJqIANB0ABqIANB+ABqENUDIANBwAJqIANB8AFqIANBoAFqENUDIANB6AJqIANB8AFqIANBoAFqEN8BIABBKGogA0GYAmpBKBDyAxogAEHQAGogA0HAAmpBKBDyAxogAEH4AGogA0HoAmpBKBDyAxogA0GQA2okAAuQAgECfyMAQZADayIDJAAgAyABQShqIgQgARDVAyADQShqIAQgARDfASADQdAAaiADIAJBKGoQHiADQfgAaiADQShqIAIQHiADQaABaiABQfgAaiACQfgAahAeIANByAFqIAFB0ABqIAJB0ABqEB4gA0HwAWogA0HIAWogA0HIAWoQ1QMgACADQdAAaiADQfgAahDfASADQZgCaiADQdAAaiADQfgAahDVAyADQcACaiADQfABaiADQaABahDfASADQegCaiADQfABaiADQaABahDVAyAAQShqIANBmAJqQSgQ8gMaIABB0ABqIANBwAJqQSgQ8gMaIABB+ABqIANB6AJqQSgQ8gMaIANBkANqJAALkQIBBX8jAEEQayIEJAAgACgCACEBAkADQCABIgJBBEkgAkECcXINASAAIAJBAnIgACgCACIBIAEgAkYbNgIAIAEgAkcNAAsDQCACQXxxIgUhAQNAIAEoAhQiA0UEQCABKAIcIgMgATYCGCADIQEMAQsLIAUgAzYCFAJAAkAgAkEBcUUEQCACIQEgAygCGCICRQ0BIAUgAjYCFCAAIAAoAgBBfXE2AgAMAgsgACACQX1xIAAoAgAiASABIAJGIgMbNgIAIAEhAiADRQ0CDAMLA0AgACABQQFxIAAoAgAiAiABIAJGIgEbNgIAIAENASACIQEgAkEESQ0ACwwBCwsgBCADEJkDIAQQ8wQLIARBEGokAAv/AQECfyMAQRBrIgIkACACQQA2AgwCfwJAAkAgAUGAAU8EQCABQYAQSQ0BIAJBDGohAyABQYCABE8NAiACIAFBP3FBgAFyOgAOIAIgAUEGdkE/cUGAAXI6AA0gAiABQQx2QQ9xQeABcjoADEEDDAMLIAIgAToADCACQQxqIQNBAQwCCyACIAFBP3FBgAFyOgANIAIgAUEGdkEfcUHAAXI6AAwgAkEMaiEDQQIMAQsgAiABQT9xQYABcjoADyACIAFBEnZB8AFyOgAMIAIgAUEGdkE/cUGAAXI6AA4gAiABQQx2QT9xQYABcjoADUEECyEBIAAgAyABEEYgAkEQaiQAC/0BAgR/AX4jAEEwayIBJAAgACgCACIAKAIAIQIgAEEANgIAIAAoAgQgASACKAIAKAIYEQMAKAIAIQAgAUEoaiIEIAFBEGooAgA2AgAgAUEgaiIFIAFBCGopAwA3AwAgASABKQMANwMYIABBBGohAgJAIAAoAgRFDQAgAEEIaigCACIARQ0AAn8CQCAAQQhqIgMgAEEFakkNACAAQQFqrUIMfiIGQiCIpw0AIANBfHEiAyAGp2oiACADSQ0AQQQMAQtBAAshAyACKAIAIAAgAxC2BQsgAiABKQMYNwIAIAJBEGogBCgCADYCACACQQhqIAUpAwA3AgAgAUEwaiQAC4oCAQJ/IwBBIGsiASQAAkACQAJAAkBB3PnKACgCACICQQFNBEACQAJAIAJBAWsEQCABQRBqEOoFIAEoAhBFDQEgASABQRBqNgIAIAEQoAUEQCABQRBqEJIFDAMLIAFBEGoQhgRFDQEMBQsgAEEANgIADAYLIAEQ6gUgASgCAEUNAiABIAE2AhwgAUEcahCgBSABEJIFIAFBEGoQkgVFDQQLQdz5ygBBAjYCAAsgAUEQahCEBCABEKICIAAgASkDEDcCACAAQQhqIAEpAwA3AgAgAEEQaiABQQhqKQMANwIADAMLIAEQkgULIAFBEGoQkgULIABBADYCAEHc+coAQQE2AgALIAFBIGokAAuYAgEBfyMAQdAAayICJAACfyAAKAIIRQRAIAIgAC0AEBChAyACQSRqQegANgIAIAJBxABqQQI2AgAgAkHoADYCHCACIAA2AhggAkIDNwI0IAJBvITKADYCMCACIAIpAwA3A0ggAiACQcgAajYCICACIAJBGGo2AkAgASACQTBqEOgCDAELIAIgAEEIajYCFCACQQhqIAAtABAQoQMgAkHEAGpB6QA2AgAgAkE8akHoADYCACACQSxqQQM2AgAgAkHoADYCNCACIAA2AjAgAkIDNwIcIAJB4ITKADYCGCACIAIpAwg3A0ggAiACQRRqNgJAIAIgAkHIAGo2AjggAiACQTBqNgIoIAEgAkEYahDoAgsgAkHQAGokAAuAAgECfyMAQfACayIDJAAgA0EIaiABQShqIgQgARDVAyADQTBqIAQgARDfASADQdgAaiADQQhqIAIQHiADQYABaiADQTBqIAJBKGoQHiADQagBaiABQfgAaiACQdAAahAeIANB0AFqIAFB0ABqIgEgARDVAyAAIANB2ABqIANBgAFqEN8BIANB+AFqIANB2ABqIANBgAFqENUDIANBoAJqIANB0AFqIANBqAFqENUDIANByAJqIANB0AFqIANBqAFqEN8BIABBKGogA0H4AWpBKBDyAxogAEHQAGogA0GgAmpBKBDyAxogAEH4AGogA0HIAmpBKBDyAxogA0HwAmokAAuAAgECfyMAQfACayIDJAAgA0EIaiABQShqIgQgARDVAyADQTBqIAQgARDfASADQdgAaiADQQhqIAJBKGoQHiADQYABaiADQTBqIAIQHiADQagBaiABQfgAaiACQdAAahAeIANB0AFqIAFB0ABqIgEgARDVAyAAIANB2ABqIANBgAFqEN8BIANB+AFqIANB2ABqIANBgAFqENUDIANBoAJqIANB0AFqIANBqAFqEN8BIANByAJqIANB0AFqIANBqAFqENUDIABBKGogA0H4AWpBKBDyAxogAEHQAGogA0GgAmpBKBDyAxogAEH4AGogA0HIAmpBKBDyAxogA0HwAmokAAulAgEDfyMAQSBrIgEkAAJAAkBB/PnKACgCACIAQQFqQQBKBEBB/PnKACAANgIAQYD6ygAoAgAiAkUEQCABQQA2AgggAUEIahBrIQJB/PnKACgCAA0DQfz5ygBBfzYCAAJAQYD6ygAoAgAiAEUNACAAIAAoAgAiAEF/ajYCACAAQQFHDQBBgPrKABDSAgtBgPrKACACNgIAQfz5ygBB/PnKACgCAEEBaiIANgIACyAADQJB/PnKAEF/NgIAIAIgAigCACIAQQFqNgIAIABBf0wNAUH8+coAQfz5ygAoAgBBAWo2AgAgAUEgaiQAIAIPC0HwmsoAQRggAUEYakHknMoAQYibygAQqAIACwALQYyaygBBECABQRhqQcScygBB4JrKABCoAgAL3gEBCH8gACABKAIMIAMoAgwgAigCCCIEQRp3IARBFXdzIARBB3dzamogASgCCCIGIAIoAgwiB3MgBHEgBnNqIgogASgCBGoiBTYCDCAAIAogASgCACIIIAIoAgAiAXEgAigCBCIJIAFxIgtzIAggCXFzIAFBHncgAUETd3MgAUEKd3NqaiICNgIEIAAgCCAGIAMoAghqIAcgBSAEIAdzcXNqIAVBGncgBUEVd3MgBUEHd3NqIgNqNgIIIAAgAkEedyACQRN3cyACQQp3cyACIAEgCXNxIAtzaiADajYCAAuHAgEEfyMAQbABayICJABBASEDIAJBEGoQmAMgAkHYAGogAkEoaikDADcDACACQdAAaiACQSBqKQMANwMAIAJByABqIAJBGGopAwA3AwAgAiACKQMQNwNAIAJBADYCaCACQgA3A2AgAkEwaiACQUBrIABBA2wiAEECTwRAQX8gAEF/amd2QQFqIQMLIAMQ2wQgAkEwaiIEIgAoAggiBSAAKAIERwRAIAAgBRC2AgsgAkEIaiAEKQIANwIAIAIoAgwhBCACKAIIIQVBEEEEEKQFIgBFBEBBEEEEEN0FAAsgACABNgIMIAAgBTYCACAAIAQ2AgQgAEEfIANnazYCCCACQbABaiQAIAALpwEBAX8gAAJ/QQAgASgCBCIEIAJrIANPDQAaAkACQCACIANqIgMgAk8EQCAEQQF0IgIgAyACIANLGyECDAELIAAgAzYCBAwBCwJAIAJBAE4EQAJ/IARFBEAgAkEBEKQFDAELIAEoAgAgBEEBIAIQlAULIgAEQCABIAI2AgQgASAANgIAQQAMBAsMAQsMAQsgAkEBEN0FAAsgAEEIakEANgIAQQELNgIAC/QBAQd/IwBBQGoiASQAIAFBIGoQywQgAUEIaiICIAFBKGoiBSkDADcDACABQRBqIgMgAUEwaiIGKQMANwMAIAFBGGoiBCABQThqIgcpAwA3AwAgASABKQMgNwMAIAAgASkDADcAACAAQQhqIAIpAwA3AAAgAEEQaiADKQMANwAAIABBGGogBCkDADcAACABQSBqEMsEIAIgBSkAADcDACADIAYpAAA3AwAgBCAHKQAANwMAIAEgASkAIDcDACAAIAEpAwA3ACAgAEEoaiACKQMANwAAIABBMGogAykDADcAACAAQThqIAQpAwA3AAAgAUFAayQAC/MBAgJ/BH4jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAAkBCACEFQgAgBkIBg30hBkEAIQMDQCADQQVGDQEgBEEIaiADEOIEKQMAIQdBgLzEACADEOIEKQMAIQggBEEIaiADEOMEIAcgBUI0iHwgBiAIg3wiBUL/////////B4M3AwAgA0EBaiEDDAALAAsFIAEgAxDiBCkDACEFIAIgAxDiBCkDACEHIARBCGogAxDjBCAFIAZ9IAd9IgVC/////////weDNwMAIAVCP4ghBiADQQFqIQMMAQsLIAAgBEEIakEoEPIDGiAEQTBqJAAL8wECAn8EfiMAQTBrIgQkACAEQQhqQQBBKBDBBBoDQCADQQVGBEACQEIAIQVCACAGQgGDfSEGQQAhAwNAIANBBUYNASAEQQhqIAMQ5QQpAwAhB0HY7cgAIAMQ5QQpAwAhCCAEQQhqIAMQ5gQgByAFQjSIfCAGIAiDfCIFQv////////8HgzcDACADQQFqIQMMAAsACwUgASADEOUEKQMAIQUgAiADEOUEKQMAIQcgBEEIaiADEOYEIAUgBn0gB30iBUL/////////B4M3AwAgBUI/iCEGIANBAWohAwwBCwsgACAEQQhqQSgQ8gMaIARBMGokAAvrAQIHfwR+IwBBIGsiByQAA0AgA0EgaiIEIAJLBEAgAyACSQRAIAcgACADaiIAIAIgA2siBBDyAyECIAAgASADaiIAIAQQ8gMaIAAgAiAEEPIDGgsgB0EgaiQABSAAIANqIgUpAAAhCiAFIAEgA2oiBikAADcAACAFQRhqIgMpAAAhCyADIAZBGGoiCCkAADcAACAFQRBqIgMpAAAhDCADIAZBEGoiCSkAADcAACAFQQhqIgMpAAAhDSADIAZBCGoiAykAADcAACADIA03AAAgCSAMNwAAIAggCzcAACAGIAo3AAAgBCEDDAELCwvtAQECfyMAQfACayICJAAgAkEIaiABEMgFIAJBMGogAUEoaiIDEMgFIAJB2ABqIAFB0ABqEPECIAJBgAFqIAEgAxDVAyACQagBaiACQYABahDIBSACQdABaiACQTBqIAJBCGoQ1QMgAkH4AWogAkEwaiACQQhqEN8BIAAgAkGoAWogAkHQAWoQ3wEgAkGgAmogAkH4AWpBKBDyAxogAkHIAmogAkHYAGogAkH4AWoQ3wEgAEEoaiACQdABakEoEPIDGiAAQdAAaiACQaACakEoEPIDGiAAQfgAaiACQcgCakEoEPIDGiACQfACaiQAC+kBAQN/IwBBgAJrIgMkACADQRhqQgA3AwAgA0EgakIANwMAIANBKGpCADcDACADQgA3AxAgA0IBNwMIIANCATcDMCADQThqQQBByAAQwQQaIAJBGHRBH3UiBCACaiAEcyEFQQEhAgNAIAJBCUYEQCAEQQFxEJYFIQEgA0GIAWogA0EIahCHAyADQQhqIANBiAFqIAEQrAQgACADQQhqQfgAEPIDGiADQYACaiQABSADIAU6AIcBIAMgAjoAiAEgA0EIaiABIANBhwFqIANBiAFqENcEEKwEIAFB+ABqIQEgAkEBaiECDAELCwviAQEGfyMAQRBrIgQkAEEIIQUCfyAAKAIAIgJBCE0EQCAAQQhqIQMgAgwBCyAAQQhqKAIAIQMgAiEFIABBDGooAgALIgYgAU0EQAJAAkAgAUEISwRAIAEgBUYNASAEQQhqIAEQqgIgBCgCCCADIAZBDGwQ8gMhByAAQQxqIAY2AgAgAEEIaiAHNgIAIABBATYCBCAAIAE2AgAgAkEJTw0BDAILIAJBCUkNASAAQQA2AgQgAEEIaiADIAZBDGwQ8gMaCyADIAUQtgQLIARBEGokAA8LQczxyQBBIEGM8skAELkEAAvfAQECfyMAQeAAayICJAAgAkEQaiABQQt2EIEDIAJBKGoiASACQRhqKAIANgIAIAIgAikDEDcDICACEMgENgIwIAJBCGogAkEgahCbBSACIAIoAgggAigCDBDaBDoANyACIAJBIGoQmwUgAkHMAGpBADoAACACQcQAaiACKAIAIgMgAigCBGo2AgAgAkEANgJQIAJByABqIAJBN2o2AgAgAkIANwM4IAIgAzYCQCACIAJBMGo2AlggACACQThqEM8BIABBFGogASgCADYCACAAIAIpAyA3AgwgAkHgAGokAAvoAQEDfyMAQSBrIgQkAAJAIANFBEAgAEEFOgAQDAELIARCADcDCCAEQQhqIgUoAgAEQCAFQQRqENADCyAEIAIgA0EAEMYEQYCABEF/IAEoAgBBAUYbIQUgBCgCACECIAQoAgQhAwNAIANBACACG0UEQCAAQQU6ABAMAgsgBEEIaiABIAIgBSADIAMgBUsbIgYQjAQgBC0AGEEFRgRAIAMgBmshAyACIAZqIQIgBEEIahCYBQwBCwsgACAEKQMINwIAIABBEGogBEEYaigCADYCACAAQQhqIARBEGopAwA3AgALIARBIGokAAvjAQEEfyMAQUBqIgIkACABQQRqIQQgASgCBEUEQCABKAIAIQMgAkEANgIgIAJCATcDGCACIAJBGGo2AiQgAkE4aiADQRBqKQIANwMAIAJBMGogA0EIaikCADcDACACIAMpAgA3AyggAkEkakHkmcoAIAJBKGoQMxogAkEQaiIDIAIoAiA2AgAgAiACKQMYNwMIAkAgASgCBCIFRQ0AIAFBCGooAgAiAUUNACAFIAFBARC2BQsgBCACKQMINwIAIARBCGogAygCADYCAAsgAEHApcoANgIEIAAgBDYCACACQUBrJAALLgEBfyMAQeAAayICJAAgAkEENgIIIAJBBDYCDCAAIAFBEBDyAxogAkHgAGokAAvTAQAgAAJ/AkACQCABQYABTwRAIAFBgBBJDQEgAUGAgARPDQIgAiABQT9xQYABcjoAAiACIAFBBnZBP3FBgAFyOgABIAIgAUEMdkEPcUHgAXI6AABBAwwDCyACIAE6AABBAQwCCyACIAFBP3FBgAFyOgABIAIgAUEGdkEfcUHAAXI6AABBAgwBCyACIAFBP3FBgAFyOgADIAIgAUESdkHwAXI6AAAgAiABQQZ2QT9xQYABcjoAAiACIAFBDHZBP3FBgAFyOgABQQQLNgIEIAAgAjYCAAvrAQIDfwF+QTggASgCGCIDayEEA0ACQAJAAn8gA0ELTwRAIAEgA0F1ajYCGCABIAEpAwAiBUILhjcDACAFQjWIpyEBQQEMAQsCQAJAAkACQCABLQAUQQFrDgICAQALIAEoAggiAiABKAIMRw0EIAFBAjoAFAsgASgCECECIAFBADYCECACDQQMAQsgASgCCCICIAEoAgxHDQILQQALIQIgACABOwECIAAgAjsBAA8LIAEgAkEBajYCCAsgAjEAACEFIAEgA0EIaiIDNgIYIAEgASkDACAFIARBP3GthoQ3AwAgBEF4aiEEDAALAAvLAQECfyMAQTBrIgMkACADQRBqIAEgAhCgAyADQQhqIANBEGoQmwUgA0EgaiADKAIIIAMoAgwQJEEBIQEgA0EoaigCACECIAMoAiQhBAJAIAMoAiBBAUcEQCADQSxqKAIAIQEgACADKQMQNwIEIABBGGogATYCACAAQRRqIAI2AgAgAEEQaiAENgIAIABBDGogA0EYaigCADYCAEEAIQEMAQsgAyAEIAIQpgUgACADKQMANwIEIANBEGoQgQULIAAgATYCACADQTBqJAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBJDYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQYT5wwA2AhAgBEEkNgIsIARB2PnDADYCWCAEQgE3AkwgBEHQ+cMANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBpPrDABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBJTYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQYi/xAA2AhAgBEElNgIsIARB3L/EADYCWCAEQgE3AkwgBEHUv8QANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBqMDEABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBKzYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQeDHxAA2AhAgBEErNgIsIARBtMjEADYCWCAEQgE3AkwgBEGsyMQANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBgMnEABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBLzYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQayryAA2AhAgBEEvNgIsIARBgKzIADYCWCAEQgE3AkwgBEH4q8gANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBzKzIABC9BAAL4QEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBxQA2AgAgBEEkakEDNgIAIAQgBEEIajYCQCAEIARBDGo2AkQgBEHcAGpBADYCACAEQgM3AhQgBEGY4skANgIQIARBxQA2AiwgBEHs4skANgJYIARCATcCTCAEQeTiyQA2AkggBCAEQShqNgIgIAQgBEHIAGo2AjggBCAEQcQAajYCMCAEIARBQGs2AiggBEEQakG448kAEL0EAAvhAQEBfyMAQeAAayIEJAAgBCABNgIIIAQgAzYCDCABIANGBEAgACACIAEQ8gMaIARB4ABqJAAPCyAEQTxqQSE2AgAgBEE0akHiADYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQZj6yQA2AhAgBEHiADYCLCAEQez6yQA2AlggBEIBNwJMIARB5PrJADYCSCAEIARBKGo2AiAgBCAEQcgAajYCOCAEIARBxABqNgIwIAQgBEFAazYCKCAEQRBqQbj7yQAQvQQAC+EBAQF/IwBB4ABrIgQkACAEIAE2AgggBCADNgIMIAEgA0YEQCAAIAIgARDyAxogBEHgAGokAA8LIARBPGpBITYCACAEQTRqQfwANgIAIARBJGpBAzYCACAEIARBCGo2AkAgBCAEQQxqNgJEIARB3ABqQQA2AgAgBEIDNwIUIARBvIrKADYCECAEQfwANgIsIARBkIvKADYCWCAEQgE3AkwgBEGIi8oANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpB3IvKABC9BAAL0wEBBX8jAEFAaiICJAAgAkEIaiABEEcCQCACKAIIIgQEQCACKAIMIQUgAhC0AiACKAIEIQYgAigCACIDIAU2AgQgAyAENgIAIAJBATYCGCACIAY2AhQgAiADNgIQIAJBOGogAUEYaikCADcDACACQTBqIAFBEGopAgA3AwAgAkEoaiABQQhqKQIANwMAIAIgASkCADcDICACQRBqIAJBIGoQjwMgAEEIaiACKAIYNgIAIAAgAikDEDcCAAwBCyAAQQA2AgggAEIENwIACyACQUBrJAAL/gEBA38jAEEQayICJAACQAJAQSNBARCkBSIBBEAgAUEfakGHp8oAKAAANgAAIAFBGGpBgKfKACkAADcAACABQRBqQfimygApAAA3AAAgAUEIakHwpsoAKQAANwAAIAFB6KbKACkAADcAAEEMQQQQpAUiA0UNASADQqOAgICwBDcCBCADIAE2AgBBDEEEEKQFIgFFDQIgAUEQOgAIIAFBqKHKADYCBCABIAM2AgAgASACLwANOwAJIAFBC2ogAkEPai0AADoAACAAQQhqIAE2AgAgAEKBgICAIDcCACACQRBqJAAPC0EjQQEQ3QUAC0EMQQQQ3QUAC0EMQQQQ3QUAC7wBAgN/AX4CQCACRQRAIABBADoAAQwBCwJAAkAgAS0AAEErRgRAIAJBf2oiAkUNASABQQFqIQELAkACQANAIAJFDQIgAS0AAEFQaiIEQQlLDQEgA61CCn4iBkIgiKcNBCABQQFqIQEgAkF/aiECIAQgBqciBWoiAyAFTw0ACwwDCyAAQQE6AAEMAwsgAEEEaiADNgIAIABBADoAAA8LIABBADoAASAAQQE6AAAPCyAAQQI6AAELIABBAToAAAvhAQEBfyMAQcABayICJAAgASABLQAAQfgBcToAACABIAEtAB9BP3FBwAByOgAfIAJBGGogAUEYaikAADcDACACQRBqIAFBEGopAAA3AwAgAkEIaiABQQhqKQAANwMAIAIgASkAADcDACACQaABaiACELsDIAIgAkGgAWpB8LrGABDNBSACQaABaiACENgBIAAgAkGgARDyAyIAQbgBaiACQbgBaikDADcAACAAQbABaiACQbABaikDADcAACAAQagBaiACQagBaikDADcAACAAIAIpA6ABNwCgASACQcABaiQAC+EBAQF/IwBBsAVrIgUkACAFQagDaiABIAIQKyAFQagBaiAFQagDakGcg8AAEMgCIAVBCGogAyAEEKQCIAVBwQNqIAVBIGopAwA3AAAgBUG5A2ogBUEYaikDADcAACAFQbEDaiAFQRBqKQMANwAAIAVBAToAqAMgBSAFKQMINwCpAyAFQegAaiAFQegCaiAFQagDahBoIAVBqANqIAVB6ABqEN8EIAVBCGogBUGoA2oQkQEgACAFQQhqQeAAEJwDIAVBqANqEKIFIAVB6ABqEPMBIAVBqAFqEKIFIAVBsAVqJAAL4QEBAn8jAEHQAGsiAiQAIAEoAsABQf8AcSIDBEAgAkEIaiABIAMQxAQgAigCCEEAIAIoAgwQwQQaCyABQn8QCyACQShqIAFBmAFqKQMANwMAIAJBIGogAUGQAWopAwA3AwAgAkEYaiABQYgBaikDADcDACACQThqIAFBqAFqKQMANwMAIAJBQGsgAUGwAWopAwA3AwAgAkHIAGogAUG4AWopAwA3AwAgAiABKQOAATcDECACIAFBoAFqKQMANwMwIAEoAsgBIQEgACACQRBqQcAAEPIDIAE2AkAgAkHQAGokAAvLAQEDfyMAQSBrIgEkACAAKAIIQRhsIQIgACgCAEEMaiEAA0ACQAJAIAIEQCAAKAIARQ0BDAILIAFBIGokAA8LIAFBADYCCCABQgQ3AwACQCAAQXRqKAIAQQFGBEAgAEF4aigCABCOBAwBCyAAQXhqEI4ECyABQRhqIgMgAUEIaigCADYCACABIAEpAwA3AxAgACgCAARAIAAQowMgABD0BAsgACABKQMQNwIAIABBCGogAygCADYCAAsgAkFoaiECIABBGGohAAwACwAL3AEBBH8jAEEgayIDJAACQAJAIAEEQCADIAE2AgwgAyAANgIIIANBEGogA0EIahAhIAMoAhAiAARAA0AgAygCHCEFIAMoAhQiBiABRg0DQQEhBCACKAIYIAAgBiACKAIcKAIMEQQADQQgBQRAIAIoAhhB/f8DIAIoAhwoAhARAgANBQsgA0EQaiADQQhqECEgAygCECIADQALC0EAIQQMAgsgAkHEqsoAQQAQLiEEDAELIAVFBEAgAiAAIAEQLiEEDAELQdCwygBBI0GMscoAEM4DAAsgA0EgaiQAIAQL0QEBAX8jAEGgBWsiBSQAIAUgAzYCDCAFIAI2AgggBUEQahCyAyAFQagDaiABQaABEPIDGiAFQYgCaiAFQagDahDiBSAFQRBqIAQQxgUgBUEQaiABQaABahDGBSAFQRBqIAVBCGoQrgQgBUGoA2ogBUEQakHYARDyAxogBUHoAWogBUGoA2oQ4gIgBUGoA2ogBUHoAWogBUGIAmogBEEgahA6IAVBgAVqIAVBqANqENgBIABBBUEDIAVBgAVqQSAgBEEgEKMEGzYCACAFQaAFaiQAC58CAQF/IwBB0AFrIgQkACABQX9qQT9LIANBwQBPckUEQCAEQQBBgAEQwQQiBEG4AWpC+cL4m5Gjs/DbADcDACAEQbABakLr+obav7X2wR83AwAgBEGoAWpCn9j52cKR2oKbfzcDACAEQaABakLRhZrv+s+Uh9EANwMAIARBmAFqQvHt9Pilp/2npX83AwAgBEGQAWpCq/DT9K/uvLc8NwMAIARBiAFqQrvOqqbY0Ouzu383AwAgBEIANwPAASAEIAE2AsgBIAQgAa0gA61CCIaFQoiS95X/zPmE6gCFNwOAASADBEAgBEGAASACIAMQ5AQgBEKAATcDwAELIAAgBEHQARDyAxogBEHQAWokAA8LQezExABBMUH8xcQAEK0EAAvsAQEBfyMAQRBrIgIkAAJAAkACQAJAAkACQCAAKAIAQQFrDgQCAwQAAQsgAiABQdTfyQBBFBCcBCACIABBBGo2AgwgAiACQQxqQejfyQAQjgEgAiAAQQhqNgIMIAIgAkEMakH438kAEI4BDAQLIAIgAUGy4MkAQQ8QnAQMAwsgAiABQafgyQBBCxCcBAwCCyACIAFBmeDJAEEOEJwEIAIgAEEEajYCDCACIAJBDGpB6N/JABCOAQwBCyACIAFBiODJAEEREJwEIAIgAEEEajYCDCACIAJBDGpB6N/JABCOAQsgAhCAAiACQRBqJAALuQEBAX8jAEFAaiIDJAAgA0E4aiACQQhqKAIANgIAIAMgAikCADcDMCADQSBqIANBMGoQogMCQAJAIAAtABANACAAKAIADQAgA0EYaiADKAIgIAMoAiggAEEEahCNBCADKAIYIgBFDQAgA0EQaiAAIAMoAhwQpgUgAyADKQMQNwMwDAELIANBCGogAygCICADKAIoEKYFIAMgAykDCDcDMAsgA0EwaiABEPEDIANBIGoQgQUgA0FAayQAC4UCAQJ/IwBBIGsiBCQAQQEhBQJAAkACQEGI+soAKAIAQQFHBEBBiPrKAEKBgICAEDcDAAwBC0GM+soAQYz6ygAoAgBBAWoiBTYCACAFQQJLDQELIAQgAzYCHCAEIAI2AhggBEHsm8oANgIUIARB7JvKADYCEEHs+coAKAIAIgJBf0wNAEHs+coAIAJBAWoiAjYCAEHs+coAQfT5ygAoAgAiAwR/QfD5ygAoAgAgBEEIaiAAIAEoAhARAAAgBCAEKQMINwMQIARBEGogAygCDBEAAEHs+coAKAIABSACC0F/ajYCACAFQQFNDQELAAsjAEEQayICJAAgAiABNgIMIAIgADYCCAALwwEBA38jAEFAaiICJAAgAkEAQcAAEMEEIgQhAgNAIANBIEYEQAJAQQAhAwNAIANBP0YNASADIARqIgEgAS0AACICIAJBCGoiAkHwAXFrOgAAIAFBAWoiASABLQAAIAJBGHRBGHVBBHZqOgAAIANBAWohAwwACwALBSACIAEgAxDtBC0AAEEPcToAACACQQFqIAEgAxDtBC0AAEEEdjoAACACQQJqIQIgA0EBaiEDDAELCyAAIARBwAAQ8gMaIARBQGskAAvDAQEDfyMAQUBqIgIkACACQQBBwAAQwQQiBCECA0AgA0EgRgRAAkBBACEDA0AgA0E/Rg0BIAMgBGoiASABLQAAIgIgAkEIaiICQfABcWs6AAAgAUEBaiIBIAEtAAAgAkEYdEEYdUEEdmo6AAAgA0EBaiEDDAALAAsFIAIgASADEO4ELQAAQQ9xOgAAIAJBAWogASADEO4ELQAAQQR2OgAAIAJBAmohAiADQQFqIQMMAQsLIAAgBEHAABDyAxogBEFAayQAC78BAQN/AkAgACgCACIAQQRqKAIAIgQgAEEIaigCACIDayACTwRAIAAoAgAhBAwBCwJAIAIgA2oiBSADSQ0AIARBAXQiAyAFIAMgBUsbIgNBAEgNAAJ/IARFBEAgA0EBEKQFDAELIAAoAgAgBEEBIAMQlAULIgQEQCAAIAQ2AgAgAEEEaiADNgIAIABBCGooAgAhAwwCCyADQQEQ3QUACxDCBQALIABBCGogAiADajYCACADIARqIAEgAhDyAxpBAAu8AQIEfwF+IwBB4ABrIgAkACAAEJcFIABB2ABqIgEgAEEYaikDADcDACAAQdAAaiICIABBEGopAwA3AwAgAEHIAGoiAyAAQQhqKQMANwMAIAAgACkDADcDQEHw+soAIABBQGtBIBCiASAAQThqIAEpAwA3AwAgAEEwaiACKQMAIgQ3AwAgAEEoaiADKQMANwMAIAAgACkDQDcDICAEp0H/AXFBAkcEQCAAQSBqEIQFCyAAQeAAaiQAQfD6ygALuQEBAX8jAEHAA2siAiQAIAJBqAFqIAFBKBDyAxogAkHQAWogAUEoakEoEPIDGiACQfgBaiABQdAAakEoEPIDGkEDIQEDQCABBEAgAkGgAmogAkGoAWoQowEgAkEIaiACQaACakGgARDyAxogAkGgAmogAkEIahDyAiACQagBaiACQaACakH4ABDyAxogAUF/aiEBDAEFIAJBoAJqIAJBqAFqEKMBIAAgAkGgAmoQgwIgAkHAA2okAAsLC9EBAQJ/IwBBEGsiAiQAIAEoAhhB/cDKAEENIAFBHGooAgAoAgwRBAAhAyACQQA6AAUgAiADOgAEIAIgATYCACACIAA2AgwgAkHwwMoAQQQgAkEMakGMwcoAEGogAi0ABCEBIAItAAUEQCACAn9BASABQf8BcQ0AGiACKAIAIgBBHGooAgAoAgwhASAAKAIYIQMgAC0AAEEEcUUEQCADQausygBBAiABEQQADAELIANBqqzKAEEBIAERBAALIgE6AAQLIAJBEGokACABQf8BcUEARwvEAQECfyMAQYAPayICJAAgAkHgDWogARCJAgNAIANBgApGBEACQCACQYAKaiABENUCQQAhAwNAIANB4AhGDQEgAkHgDWogAkGACmogAiADaiIBEJIBIAJBwAxqIAJB4A1qEIMCIAJBoAtqIAJBwAxqEIkCIAFBoAFqIAJBoAtqQaABEPIDGiADQaABaiEDDAALAAsFIAIgA2ogAkHgDWpBoAEQ8gMaIANBoAFqIQMMAQsLIAAgAkGAChDyAxogAkGAD2okAAvEAQECfyMAQYAPayICJAAgAkHgDWogARCKAgNAIANBgApGBEACQCACQYAKaiABENUCQQAhAwNAIANB4AhGDQEgAkHgDWogAkGACmogAiADaiIBEJIBIAJBwAxqIAJB4A1qEIMCIAJBoAtqIAJBwAxqEIoCIAFBoAFqIAJBoAtqQaABEPIDGiADQaABaiEDDAALAAsFIAIgA2ogAkHgDWpBoAEQ8gMaIANBoAFqIQMMAQsLIAAgAkGAChDyAxogAkGAD2okAAvDAQEDfyMAQRBrIgMkACACKAIAIQQDQCABQQNNBEAgAUEBSwRAIAAvAAAhBSADQQhqIAAgAUECEMYEIARBBXcgBXNBufPd8XlsIQQgAygCDCEBIAMoAgghAAsgAiABBH8gAC0AACAEQQV3c0G5893xeWwFIAQLQQV3Qf8Bc0G5893xeWw2AgAgA0EQaiQABSAAKAAAIQUgAyAAIAFBBBDGBCAEQQV3IAVzQbnz3fF5bCEEIAMoAgQhASADKAIAIQAMAQsLC7MBAQV/IwBBQGoiBCQAIAEoAgwiA0H8kcoAIAMbIQIgAUEUaigCAEEAIAMbIgVBKGwhAwJAA0ACQCADQQAgAhtFBEBBACECIAUNAyABKAIEIQIgASgCACEBIARBAzoALCAEQQI2AjAgACACQQAgAUEBRhsgBEEIaiAEQTBqQQBBACICECMNAQwDCyAAIAEgAhDVASADQVhqIQMgAkEoaiECRQ0BCwtBASECCyAEQUBrJAAgAgu3AQEBfyMAQSBrIgUkACAFIAI2AgQgBSABNgIAIAUgAzYCCCAFIAQ2AgwCQCAEIANJDQAgA0UgAiADRnJFBEAgAiADTQ0BIAEgA2osAABBv39MDQELIARFIAIgBEZyRQRAIAIgBE0NASABIARqLAAAQb9/TA0BCyAAIAQgA2s2AgQgACABIANqNgIAIAVBIGokAA8LIAUgBUEMajYCGCAFIAVBCGo2AhQgBSAFNgIQIAVBEGoQ7wQAC7wBAQR/IwBBIGsiAiQAAkAgASwAHyIDQQBOBEAgAkEXaiABQRdqKQAANwAAIAJBEGoiBCABQRBqKQAANwMAIAJBCGoiBSABQQhqKQAANwMAIAIgASkAADcDACACIANB/wBxOgAfIAAgAhDWBAR/IAAgAikDADcAASAAQRlqIAJBGGopAwA3AAAgAEERaiAEKQMANwAAIABBCWogBSkDADcAAEEBBUEACzoAAAwBCyAAQQA6AAALIAJBIGokAAu8AQEEfyMAQSBrIgIkAAJAIAEsAB8iA0EATgRAIAJBF2ogAUEXaikAADcAACACQRBqIgQgAUEQaikAADcDACACQQhqIgUgAUEIaikAADcDACACIAEpAAA3AwAgAiADQf8AcToAHyAAIAIQ2QQEfyAAIAIpAwA3AAEgAEEZaiACQRhqKQMANwAAIABBEWogBCkDADcAACAAQQlqIAUpAwA3AABBAQVBAAs6AAAMAQsgAEEAOgAACyACQSBqJAALxQEBAn8jAEEgayIDJAACfwNAAkAgAUUNACADQQhqIAAgARAvAkACQCADKAIIQQFGBEAgAyADKQIMNwMYQZCSygBBAyACEN8FDQEgAyADQRhqIgRBBWotAAA2AgQgAyAELQAENgIAIAMoAgBFDQMgASADQRhqKAIAIAMoAgRqIgRPDQIgBCABEOYCAAtBACADKAIMIANBEGooAgAgAhDfBUUNBBoLQQEMAwsgACAEaiEAIAEgBGshAQwBCwtBAAsgA0EgaiQAC7sBAQN/IwBBIGsiAiQAIAJBCGogARCNAwJAIAIoAggiA0UEQCAAQQA2AgggAEIBNwIADAELIAIoAgwhBCACQRBqIAEQ0wEgAkEQaiACKAIQQQtsEP0DIAJBEGogAyAEEK4FA0AgAiABEI0DIAIoAgAiAwRAIAIoAgQhBCACQRBqQYjyyABBARCuBSACQRBqIAMgBBCuBQwBCwsgACACKQMQNwIAIABBCGogAkEYaigCADYCAAsgAkEgaiQAC7YBAQF/IAAoAgAiBEEANgIAIARBeGoiACAAKAIAQX5xNgIAAkAgAiADKAIUEQYARQ0AAkAgBEF8aigCAEF8cSICBEAgAi0AAEEBcUUNAQsgACgCACIDQXxxIgJFIANBAnFyDQEgAi0AAEEBcQ0BIAQgAigCCEF8cTYCACACIABBAXI2AggPCyAAEJ8CIAAtAABBAnEEQCACIAIoAgBBAnI2AgALDwsgBCABKAIANgIAIAEgADYCAAu3AQEEfyMAQZACayIDJAAgA0EANgIAIANBiAFqIAMQxAMgAygCjAEgAygCiAEiBmsiBSACIAFrIgIgAiAFSxshBSADKAKQASECA0AgBCAFTwRAIAMoAgAiAUGAAUkEQCABENkCAAsFIAQgBmogASAEai0AADoAACACIAIoAgBBAWo2AgAgBEEBaiEEDAELCyADQYgBaiADQYQBEPIDGiAAIANBiAFqQQRyQYABEPIDGiADQZACaiQAC8MBAQF/IwBB4ARrIgIkACACQRBqELIDIAJB6AFqQQBBwAAQwQQaIAJBwAJqQgA3AwAgAkG4AmpCADcDACACQbACakIANwMAIAJCADcDqAIgAkEQaiABEMYFIAJBiANqIAJBEGpB2AEQ8gMaIAJByAJqIAJBiANqEKEEIAJBCGogAkHIAmoQqQUgAkHoAWpBwAAgAigCCCACKAIMELABIAJBqAJqQSAgAkHoAWpBIBCwASAAIAJBqAJqELcBIAJB4ARqJAALpQEBAn8gAAJ/AkACfwJAAkAgAUEUai0AAEEBaw4CAQADCyABQRBqKAIAQQBHDAELIAFBDGooAgAgASgCCGsLQQN0QQtuIgIhAUEBDAELQX8gAUEMaigCACABKAIIayICIAFBEGooAgBBAEdqIgEgASACSSIDG0EDdEELbiECQQAgAw0AGiABQQN0QQtuIQFBAQs2AgQgACACNgIAIABBCGogATYCAAvFAQEGfyMAQYABayIEJAAgACAAKAIIIAEQqwMgACgCACEDIAAoAgghBSAEQQhqQQEgARCmBSAFQfAAbCADaiEGIAQoAgwhByAEKAIIIQMDQAJAIAMgB0kEQCADQQFqIgggA08NAQsgACABBH8gBiACQfAAEK0CIAVBAWoFIAULNgIIIARBgAFqJAAPCyAEQRBqIgMQmAMgA0EANgIoIANCADcDICAFQQFqIQUgBiAEQRBqQfAAEPIDQfAAaiEGIAghAwwACwALpgEBBX8jAEFAaiIDJAAgASgCBCEGIAEoAgAhByADQQhqIAIQ6gRBACEBQQIhBSADIAIoAhQiBAR/IAMgBCACQRxqKAIAEMYDIAMoAgAiBAR/IANBOGogAygCBDYCACADIAQ2AjRBAAUgBQsFIAULNgIwIAAgBkEAIAdBAUYbIANBCGogA0EwaiACKAIgIAJBJGooAgAQIwRAQQEhAQsgA0FAayQAIAELvgEBAn8jAEHQAGsiAiQAIAIgACgCACIDNgIUAn8gAygCAARAIAJBCGogABDKBCACQTxqQfgANgIAIAJBLGpBAjYCACACQfkANgI0IAJCAjcCHCACQbiGygA2AhggAiACKQMINwNIIAIgAkHIAGo2AkQgAiACQRRqNgI4IAIgAkHEAGo2AjAgAiACQTBqNgIoIAEgAkEYahDoAgwBCyACIAAQygQgAigCACABIAIoAgQoAjARAgALIAJB0ABqJAALzAEBAX8jAEGABWsiCCQAIAggBzYCDCAIQRBqIABByAEQ8gMiByAALQDKAToAygEgByAALwHIATsByAEgBkEDdCEGA0AgBgRAIAhBsANqIAhBEGpB0AEQ8gMaIAhBEGogCEGwA2ogASACIAUoAgAgBSgCBBC6AyAGQXhqIQYgBUEIaiEFDAEFIAhBsANqIAhBEGpB0AEQ8gMaIAhB4AFqIAhBsANqIAhBDGoQ5wEgCEHgAWogAyAEEPYDIAhB4AFqELcFIAhBgAVqJAALCwunAQEBfyMAQaABayICJAAgAkEIaiABQdAAahD/AiACQTBqIAEgAkEIahAeIAJB2ABqIAFBKGogAkEIahAeIAJBgAFqIAJB2ABqEEMgAEEXaiACQZcBaikAADcAACAAQRBqIAJBkAFqKQAANwAAIABBCGogAkGIAWopAAA3AAAgACACKQCAATcAACAAIAItAJ8BIAJBMGoQwgRBB3RzOgAfIAJBoAFqJAALvAEBA38jAEGgAmsiASQAIAFBADYCACABQZgBaiABEMQDIAEoAqABIQIgAUGYAWogASgCmAEgASgCnAEQiwUgAUGIAWogAUGYAWoQ+QQgAUGgAWogAUGQAWooAgA2AgAgASABKQOIATcDmAEDQCABQZgBahCJBCIDBEAgA0HcADoAACACIAIoAgBBAWo2AgAMAQUgAUGYAWogAUGEARDyAxogACABQZgBakEEckGAARDyAxogAUGgAmokAAsLC7sBAQN/IwBBoAJrIgEkACABQQA2AgAgAUGYAWogARDEAyABKAKgASECIAFBmAFqIAEoApgBIAEoApwBEIsFIAFBiAFqIAFBmAFqEPkEIAFBoAFqIAFBkAFqKAIANgIAIAEgASkDiAE3A5gBA0AgAUGYAWoQiQQiAwRAIANBNjoAACACIAIoAgBBAWo2AgAMAQUgAUGYAWogAUGEARDyAxogACABQZgBakEEckGAARDyAxogAUGgAmokAAsLC6gBAgR/AX4jAEEgayICJAAgAkEIaiAAEJQCAkAgAi0AGCIDQQVHBEAgAkEUaigCACEEQsAAIQYgAigCECEFIANBAkcEQCAAKQMAIgZCCIcgBiADGyEGCyAFRQ0BIAUgBCgCABEDACAEKAIEIgNFDQEgBSADIAQoAggQtgUMAQsgAEEANgKcICAAKQMAIQYLIAAgBkJAfDcDCCAAQRBqIAEQESACQSBqJAALqwEBAn8jAEGgwABrIgEkACABQQQ2AgggAUGYIGogAUEIahB8IAFBmCBqQQRyIQIgASgCmCBBAUYEQCABQSBqIAJBEGooAgA2AgAgAUEYaiACQQhqKQIANwMAIAEgAikCADcDECABQRBqEK0DAAsgAUEQaiACQYQgEPIDGiABQZggaiABQRBqQYQgEPIDGiAAIAFBmCBqIAEoAgggASgCDBCXAiABQaDAAGokAAu9AQECfyMAQRBrIgIkACABQQEgARshAQJAIABFDQAgAEEDakECdiEAAkAgAUEESw0AIABBf2oiA0H/AUsNACACQZjQygA2AgQgAiADQQJ0QZzQygBqIgMoAgA2AgwgACABIAJBDGogAkEEakGU/sEAEOECIQEgAyACKAIMNgIADAELIAJBmNDKACgCADYCCCAAIAEgAkEIakH8/cEAQfz9wQAQ4QIhAUGY0MoAIAIoAgg2AgALIAJBEGokACABC7gBAQF/IwBBEGsiAyQAAkAgAEUNACADIAA2AgQgAUUNAAJAIAJBBEsNACABQQNqQQJ2QX9qIgBB/wFLDQAgA0GY0MoANgIIIAMgAEECdEGc0MoAaiIAKAIANgIMIANBBGogA0EMaiADQQhqQZT+wQAQ0AEgACADKAIMNgIADAELIANBmNDKACgCADYCDCADQQRqIANBDGpB/P3BAEH8/cEAENABQZjQygAgAygCDDYCAAsgA0EQaiQAC+MBAQJ+IAAgASkDICACKQMgfULw////////P3wiBEL/////////A4MgASkDGCACKQMYfULw////////P3wiA0IziHw3AyAgACADQv////////8DgyABKQMQIAIpAxB9QvD///////8/fCIDQjOIfDcDGCAAIANC/////////wODIAEpAwggAikDCH1C8P///////z98IgNCM4h8NwMQIAAgA0L/////////A4MgASkDACACKQMAfULQ/f//////P3wiA0IziHw3AwggACAEQjOIQhN+IANC/////////wODfDcDAAvDAQACQAJAAkACQAJAAkACQAJAIAFBAU0EQCABQQFrDQEMAgsgAUEDSQ0CIAFBA0YNAyABQQVJDQQgAUEFRg0FIAFBB0kNBiABQQdGDQcgACkAAA8LQdT7wwBBAEEAEOQCAAtB5PvDAEEBQQEQ5AIAC0H0+8MAQQIgARDkAgALQYT8wwBBA0EDEOQCAAtBlPzDAEEEIAEQ5AIAC0Gk/MMAQQVBBRDkAgALQbT8wwBBBiABEOQCAAtBxPzDAEEHQQcQ5AIAC8MBAAJAAkACQAJAAkACQAJAAkAgAUEBTQRAIAFBAWsNAQwCCyABQQNJDQIgAUEDRg0DIAFBBUkNBCABQQVGDQUgAUEHSQ0GIAFBB0YNByAAKQAADwtB/K3IAEEAQQAQ5AIAC0GMrsgAQQFBARDkAgALQZyuyABBAiABEOQCAAtBrK7IAEEDQQMQ5AIAC0G8rsgAQQQgARDkAgALQcyuyABBBUEFEOQCAAtB3K7IAEEGIAEQ5AIAC0HsrsgAQQdBBxDkAgALrAEBAX8jAEHQAGsiBCQAIAQgAzYCHCAEIAI2AhggBEEQaiAEQRhqQQcQpgUgBEHEAGpBATYCACAEQgE3AjQgBEGc3ckANgIwIAQgBCkDEDcDSCAEIARByABqNgJAIARBIGogBEEwahBmIARBCGogARCbBSAEKAIMIQEgBCgCCCECIAQgBEEgahCbBSAAIAIgASAEKAIAIAQoAgQQHyAEQSBqEIEFIARB0ABqJAALwwEBAX8jAEHwBGsiBSQAIAVBoANqQa7wwwBBDhD1AyAFQaADakG88MMAQQBB/IPAAEEJENIDIAVB0AFqIAVBoANqQdABEPIDGiAFQaADaiAFQdABakHIARDyAxogBSAFLQCaAzoA6gQgBSAFLwGYAzsB6AQgBUGgA2pBvPDDAEEKIAIgAxDSAyAFIAVBoANqQdABEPIDIgJB0AFqELcFIAJBoANqIAJB0AEQ8gMaIAAgASACQaADaiAEEFMgAkHwBGokAAvEAQEBfyMAQfAEayIFJAAgBUGgA2pBrvDDAEEOEPUDIAVBoANqQbzwwwBBAEH8g8AAQQkQ0gMgBUHQAWogBUGgA2pB0AEQ8gMaIAVBoANqIAVB0AFqQcgBEPIDGiAFIAUtAJoDOgDqBCAFIAUvAZgDOwHoBCAFQaADakG88MMAQQogAiADENIDIAUgBUGgA2pB0AEQ8gMiAkHQAWoQtwUgAkGgA2ogAkHQARDyAxogACABIAJBoANqIAQQjAIgAkHwBGokAAupAQECfyMAQSBrIgEkAAJAAn9BACAAKAIARQ0AGiABQQhqIAAQ0wQgASgCCEEBRg0BIAEgASgCDCICNgIYIAEgAUEQai0AADoAHCACLQAFRQRAIABBCGoQugEgAkEBOgAFCyABQRhqENIEIABBCGoLIAFBIGokAA8LIAEgASgCDDYCGCABIAFBEGotAAA6ABxBvIfKAEErIAFBGGpB6IfKAEHciMoAEKgCAAunAQEEfyMAQTBrIgEkACABQSBqIAAQ0QQgAUEQaiABQSBqQfT0yQAQhQMgASABLQAUIgI6ABwgASABKAIQIgM2AhggAEEIaiEEA0AgAC0AEARAIAFBIGogBCADIAJBAEcQgQQgAUEIaiABQSBqQYT1yQAQhQMgAS0ADEEBcSECIAEoAgghAwwBBSABIAI6ABwgASADNgIYIAFBGGoQ0gQgAUEwaiQACwsLngEBBH8jAEFAaiIDJAAgA0E4aiIEQgA3AwAgA0EwaiIFQgA3AwAgA0EoaiIGQgA3AwAgA0IANwMgIAIgA0EgakEgELwFIANBGGogBCkDADcDACADQRBqIAUpAwA3AwAgA0EIaiAGKQMANwMAIAMgAykDIDcDACABQaz+wQBBA0EAEJUFIAEgA0EgEMICIAAgAUHQARDyAxogA0FAayQAC5gBAQR/IwBBEGsiBSQAIABByABqIQYCQANAIAMgAkkEQCAAKAJAIgRBEE8EQCAGIAAQ3AMgAEEANgJAQQAhBAsgAyACSw0CIAVBCGogACAEQQJ0akEQIARrIAEgA2ogAiADaxCDBCAFKAIMIQQgACAAKAJAIAUoAghqNgJAIAMgBGohAwwBCwsgBUEQaiQADwsgAyACEOYCAAuZAQIBfwJ+IwBBgAFrIgQkACAEQRBqEI4FIARBCGpBACADEKYFIAQ1AgwhBiAENQIIIQUDQCAFIAZaBEAgACAEKQMQNwIAIABBCGogBEEYaigCADYCACAEQYABaiQABSAEQShqIAUQrgIgBEEoaiABIAIQPSAEIARBKGoQUTcDICAEQRBqIARBIGpBCBCuBSAFQgF8IQUMAQsLC58BAQZ/IAAtANEBBEAgAEEAOgDRASAAELgFCyAAKALMASAAKALIASIGayEDIAIhBAJAA0AgBSACTQRAIAIgBWshByABIAVqIQggBCADSQ0CIAAgCCAHIAYgAxCRAiAAECcgBCADayEEIAMgBWohBSAAKALMASEDQQAhBgwBCwsgBSACEOYCAAsgACAIIAcgBiAEEJECIAAgBCAGajYCyAELvQEBAX8jAEGgA2siASQAIAFB4gFqQQBBtgEQwQQaIAFB3gFqQY7zwwAoAAA2AQAgAUGE88MALwAAOwHUASABQYDzwwAoAAA2AtABIAFBhvPDACkAADcB1gEgAUHQAWoQIiABQQhqIAFB0AFqQcgBEPIDGiABQdABaiABQQhqQcgBEPIDGiABQQA6AJoDIAFBADsBmAMgAUHQAWpB7fLDAEELQQAQlQUgACABQdABakHQARDyAxogAUGgA2okAAuYAQEDfyMAQdAAayIBJAAgAUEANgIAIAFBBHIhAwNAIAJBIEYEQCABQShqIAFBJBDyAxogAEEYaiABQcQAaikCADcAACAAQRBqIAFBPGopAgA3AAAgAEEIaiABQTRqKQIANwAAIAAgASkCLDcAACABQdAAaiQABSACIANqQQA6AAAgASABKAIAQQFqNgIAIAJBAWohAgwBCwsLrwEBAn8jAEEgayIEJAAgAkHwhsAAQQogA0EgENIDIAJB+obAAEEKIAEQ4QUQngUgACACQYSHwABBCxCQBCAEQRhqIgFCADcDACAEQRBqIgNCADcDACAEQQhqIgVCADcDACAEQgA3AwAgAkGPh8AAQQ4gBEEgENMDIABBOGogASkDADcAACAAQTBqIAMpAwA3AAAgAEEoaiAFKQMANwAAIAAgBCkDADcAICAEQSBqJAALiQEBAX8jAEEgayIDJAAgA0EIaiABIAIQhAFBASEBAkAgAygCCEEBRgRAIAAgAykCDDcCBCAAQRRqIANBHGooAgA2AgAgAEEMaiADQRRqKQIANwIADAELIABBEGogA0EYaikDADcDACAAQQhqIANBEGopAwA3AwBBACEBCyAAIAE2AgAgA0EgaiQAC6EBAQJ/IwBBIGsiAiQAIAACfwJAIAACfyABQXFqIgNBCUsEQEGEgAIgAUEMRg0BGgwCCwJAAkACQAJAIANBAWsOCQUFAAUFAQUFAgMLQYaAAwwDC0GHwAMMAgtBiIAEDAELQYXAAgs2AgRBAAwBCyACQQM2AhAgAiABrTcCFCACQQhqIAJBEGoQwQMgACACKQMINwIEQQELNgIAIAJBIGokAAuHAQEDfyMAQYABayIDJAAgAC0AACECQQAhAANAIAAgA2pB/wBqIAJBD3EiBEEwciAEQdcAaiAEQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPBEAgAkGAARDmAgALIAFBtazKAEECIAAgA2pBgAFqQQAgAGsQNSADQYABaiQAC4YBAQN/IwBBgAFrIgMkACAALQAAIQJBACEAA0AgACADakH/AGogAkEPcSIEQTByIARBN2ogBEEKSRs6AAAgAEF/aiEAIAJBBHYiAg0ACyAAQYABaiICQYEBTwRAIAJBgAEQ5gIACyABQbWsygBBAiAAIANqQYABakEAIABrEDUgA0GAAWokAAuLAQEBfyMAQaADayIHJAAgB0GAAWogASACIAMgBBCHAiAHQUBrIAdBgAFqIAUgBhCUBCAHQeACakEAQcAAEMEEGiAHQeACakEgIAdBQGtBIBCuASAHQYADakEgIAdB4ABqQSAQrgEgACAHIAdB4AJqQcAAEPIDIgAQnwMgAEHAAmoQswIgAEGgA2okAAuKAQEEfyMAQUBqIgEkACABEMsEIAFBKGoiAiABQQhqKQMANwMAIAFBMGoiAyABQRBqKQMANwMAIAFBOGoiBCABQRhqKQMANwMAIAEgASkDADcDICAAIAEpAyA3AAAgAEEIaiACKQMANwAAIABBEGogAykDADcAACAAQRhqIAQpAwA3AAAgAUFAayQAC4IBAQF/IAAgASgCDCACKAIEIgNBD3cgA0ENd3MgA0EKdnNqIgM2AgwgACABKAIIIAIoAgAiAkEPdyACQQ13cyACQQp2c2oiAjYCCCAAIAEoAgQgA0EPdyADQQ13cyADQQp2c2o2AgQgACABKAIAIAJBD3cgAkENd3MgAkEKdnNqNgIAC4cBAQN/IwBBgAFrIgMkACAAKAIAIQJBACEAA0AgACADakH/AGogAkEPcSIEQTByIARB1wBqIARBCkkbOgAAIABBf2ohACACQQR2IgINAAsgAEGAAWoiAkGBAU8EQCACQYABEOYCAAsgAUG1rMoAQQIgACADakGAAWpBACAAaxA1IANBgAFqJAALhgEBA38jAEGAAWsiAyQAIAAoAgAhAkEAIQADQCAAIANqQf8AaiACQQ9xIgRBMHIgBEE3aiAEQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPBEAgAkGAARDmAgALIAFBtazKAEECIAAgA2pBgAFqQQAgAGsQNSADQYABaiQAC5IBAQJ/IABBCnYhAgJAAkACQCAAQYDIAE8EQEECIQEgAkEMRg0BQQAPCyACQYjPygBqLQAAIgFBBEsNAQsgAEEGdkEPcSABQQR0ckGRz8oAai0AACIBQQVLDQEgAUEDdEHoz8oAaikDAEIBIABBP3GthoNCAFIPC0HQwMoAIAFBBRDkAgALQeDAygAgAUEGEOQCAAuUAQEBfyMAQcADayIDJAAgA0HIhsAAQRQQ9QMgA0HchsAAQQpBrIPAAEEAENIDIANB0AFqIANB0AEQ8gMaIANBuANqIAJBGGopAAA3AwAgA0GwA2ogAkEQaikAADcDACADQagDaiACQQhqKQAANwMAIAMgAikAADcDoAMgACABIANB0AFqIANBoANqEG8gA0HAA2okAAuVAQEBfyMAQcADayIDJAAgA0HIhsAAQRQQ9QMgA0HchsAAQQpBrIPAAEEAENIDIANB0AFqIANB0AEQ8gMaIANBuANqIAJBGGopAAA3AwAgA0GwA2ogAkEQaikAADcDACADQagDaiACQQhqKQAANwMAIAMgAikAADcDoAMgACABIANB0AFqIANBoANqEIoBIANBwANqJAALhAEBA38gACgCBCECIAAoAgAiASgCAARAIAEoAgBBAUEBELYFIAFBCGoiAxDGAiADEOkDCyABIAIoAggiA0EXakEAIANrcWogAigCABEDACAAKAIEIgEoAgQgASgCCCIBQQQgAUEESxsiAWpBF2pBACABa3EiAgRAIAAoAgAgAiABELYFCwudAQEBfyAAQQdBABBEAkACQANAIAJFDQIgAC0AyAEiA0HHAU0EQCABIAAgA2otAAA6AAAgAC0AyAEiA0HHAUsNAiAAIANqQQA6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0Gs9MMAIANByAEQ5AIAC0G89MMAIANByAEQ5AIACwt/AQJ/IAAgASgCDCABKAIIIgNBGXcgA0EDdnMgA0EOd3NqNgIMIAAgAyABKAIEIgRBGXcgBEEDdnMgBEEOd3NqNgIIIAAgBCABKAIAIgFBGXcgAUEDdnMgAUEOd3NqNgIEIAAgASACKAIMIgBBGXcgAEEDdnMgAEEOd3NqNgIAC5cBAQZ/IwBBEGsiAiQAIAFBDGooAgAhBCABKAIAIQUgASgCCCEGIAEQswUhByABKAIAIQMCQCAHRQ0AIAEgA0EIciIDNgIAIAEoAghBAUYNACABQoGAgICgATcCCAsgASADQQRyNgIAIAIgACgCADYCDCACQQxqIAEQ9QEgASAENgIMIAEgBjYCCCABIAU2AgAgAkEQaiQAC4wBAQF/IwBBIGsiBCQAIAQgAjYCBCAEIAE2AgAgBCADNgIIIAQgAjYCDAJAIANFIAIgA0ZyDQAgAiADSwRAIAEgA2osAABBv39KDQELIAQgBEEMajYCGCAEIARBCGo2AhQgBCAENgIQIARBEGoQ7wQACyAAIAIgA2s2AgQgACABIANqNgIAIARBIGokAAuuAQECfyMAQSBrIgEkAAJAIAACf0ECENgDDQAaAn9BAUG8jsoAKAIAEQgAIgJFDQAaIAJBAToAAEEACxCZBBDRAyABQQhqQeD5ygAoAgAQ1QQgASgCCEEBRg0BIAEoAgwhAiABQRBqLQAACzoABCAAIAI2AgAgAUEgaiQADwsgASABKAIMNgIYIAEgAUEQai0AADoAHEGnjcoAQSsgAUEYakHUjcoAQcCOygAQqAIAC5IBAQJ/IAAtAAghASAAKAIEIgIEQCAAAn9BASABQf8BcQ0AGgJAIAJBAUcNACAALQAJRQ0AIAAoAgAiAS0AAEEEcQ0AQQEgASgCGEGwrMoAQQEgAUEcaigCACgCDBEEAA0BGgsgACgCACIAKAIYQbGsygBBASAAQRxqKAIAKAIMEQQACyIBOgAICyABQf8BcUEARwuMAQEBfyMAQRBrIgMkACADIAEoAgAiBCgCADYCDCACQQJqIgEgAWwiAUGAECABQYAQSxsiAkEEIANBDGpB5P3BAEHk/cEAEOECIQEgBCADKAIMNgIAIAEEfyABQgA3AgQgASABIAJBAnRqQQJyNgIAQQAFQQELIQIgACABNgIEIAAgAjYCACADQRBqJAALxQEBAn4gAELw////////PyAAKQMgfSICQv////////8Dg0Lw////////PyAAKQMYfSIBQjOIfDcDICAAIAFC/////////wODQvD///////8/IAApAxB9IgFCM4h8NwMYIAAgAUL/////////A4NC8P///////z8gACkDCH0iAUIziHw3AxAgACABQv////////8Dg0LQ/f//////PyAAKQMAfSIBQjOIfDcDCCAAIAJCM4hCE34gAUL/////////A4N8NwMAC4QBAQR/IwBBgAFrIgIkACAAIAEgAUH4AGoiAxAeIAJBCGogAUEoaiIEIAFB0ABqIgUQHiACQTBqIAUgAxAeIAJB2ABqIAEgBBAeIABBKGogAkEIakEoEPIDGiAAQdAAaiACQTBqQSgQ8gMaIABB+ABqIAJB2ABqQSgQ8gMaIAJBgAFqJAALdwEDfyMAQRBrIgMkACADQQE6AA8CfyAAKAIMIgJBAWoiBCACSQRAIANBD2oQ/gRBAAwBCyAEIAAoAgQiAkEITwR/IAJBAWpBA3ZBB2wFIAILQQF2TwRAIAAgBCABEEtB/wFxDAELIAAgARA0QQALGiADQRBqJAALjAEBBX8jAEEQayIDJAAgACgCACEEIAGnIQIgACgCBCEFQQAhAANAIANBCGogBCACIAVxIgZqKAAAQYCBgoR4cRDMBCAAQQRqIgAgBmohAiADKAIIQQFHDQALIAQgAygCDCAGaiAFcSICaiwAAEEATgRAIAQoAgBBgIGChHhxENIFIQILIANBEGokACACC4wBAQN/IwBBIGsiAiQAIAJBGGoiAyABQRBqKAIANgIAIAJBEGoiBCABQQhqKQIANwMAIAIgASkCADcDCEEUQQQQpAUiAUUEQEEUQQQQ3QUACyABIAIpAwg3AgAgAUEQaiADKAIANgIAIAFBCGogBCkDADcCACAAQYyGygA2AgQgACABNgIAIAJBIGokAAuCAQEBfyMAQYACayIFJAAgBUEIahCOBSAFQQhqIAMgBBCuBSAFQQhqIAEgAhCuBSAFIAVBCGoQmwUgBUEYaiAFKAIAIAUoAgQQJiAFKAIYQQFGBEBBiPzBAEEZQbD8wQAQtAQACyAAIAVBIGpB4AEQ8gMaIAVBCGoQgQUgBUGAAmokAAuGAQECfiAAQgAgAq1C/wGDfSIEIAApAwAiAyABKQMAhYMgA4U3AwAgACAAKQMIIgMgASkDCIUgBIMgA4U3AwggACAAKQMQIgMgASkDEIUgBIMgA4U3AxAgACAAKQMYIgMgASkDGIUgBIMgA4U3AxggACAEIAApAyAiAyABKQMghYMgA4U3AyALhwEBAn8jAEGAAWsiAiQAIAAgAUEoaiIDIAEQ1QMgAkEIaiADIAEQ3wEgAkEwaiABQdAAakEoEPIDGiACQdgAaiABQfgAakHYuMQAEB4gAEEoaiACQQhqQSgQ8gMaIABB0ABqIAJBMGpBKBDyAxogAEH4AGogAkHYAGpBKBDyAxogAkGAAWokAAuHAQECfyMAQYABayICJAAgACABQShqIgMgARDVAyACQQhqIAMgARDfASACQTBqIAFB0ABqQSgQ8gMaIAJB2ABqIAFB+ABqQajryAAQHiAAQShqIAJBCGpBKBDyAxogAEHQAGogAkEwakEoEPIDGiAAQfgAaiACQdgAakEoEPIDGiACQYABaiQAC44BAgF/AX4jAEFAaiIBJAAgAUEIakEENgIAIAFBEGogASgCCCABKAIMEO4BIAEoAhBBAUYEQCABQThqIAFBJGooAgA2AgAgAUEwaiABQRxqKQIANwMAIAEgASkCFDcDKCABQShqEKwDAAsgAUEYaikDACECIAAgAUEgaikDADcDCCAAIAI3AwAgAUFAayQAC5MBAQF/IwBB4AJrIgQkACACEKUFIAJB0fDDAEEHIAFBoAFqEJ4FIAJB3/DDAEEGIAMQngUgBCACQeXwwwBBBhCQBCAEQcABaiABEOIFIARBIGogBCAEQcABaiADQSBqEDkgBEHAAWogBEEgahBIIABBB0EAIARBwAFqQSAgA0EgEL8FGzoAACACELcFIARB4AJqJAALnQEBAX8jAEEQayICJAACQAJAAkACQCAAKAIAIgBBhIACRwRAIABBhcACRg0BIABBhoADRg0CIABBh8ADRg0DIAIgAUHB4MkAQQcQnAQMBAsgAiABQd3gyQBBBxCcBAwDCyACIAFB1uDJAEEHEJwEDAILIAIgAUHP4MkAQQcQnAQMAQsgAiABQcjgyQBBBxCcBAsgAhCAAiACQRBqJAALgAEBAX8jAEGAAWsiAiQAIAAgARDZAyACQQhqIAFBKGpBKBDyAxogAkEwaiABQdAAakEoEPIDGiACQdgAaiABQfgAahDZAyAAQShqIAJBCGpBKBDyAxogAEHQAGogAkEwakEoEPIDGiAAQfgAaiACQdgAakEoEPIDGiACQYABaiQAC4MBAgJ/A34jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAIAAgBEEIakGAvMQAEKABIARBMGokAAUgASADEOIEKQMAIQUgAiADEOIEKQMAIQYgBEEIaiADEOMEIAYgBSAHQjSIfHwiB0L/////////B4M3AwAgA0EBaiEDDAELCwt8AgJ/A34gACABKAIEIgNBIE8EfiAAIAEoAgAiAikAADcDCCACQRhqKQAAIQQgAkEQaikAACEFIAJBCGopAAAhBiABIANBYGo2AgQgASACQSBqNgIAIABBEGogBjcDACAAQRhqIAU3AwAgAEEgaiAENwMAQgEFQgALNwMAC4gBAQF/IwBBEGsiBSQAIAVBCGogAEHIASADEJ0EIAUgBSgCCCAFKAIMIAQQngQgBSgCBCIEIAJNBEAgBSgCACECA0AgBARAIAIgAi0AACABLQAAczoAACAEQX9qIQQgAkEBaiECIAFBAWohAQwBCwsgBUEQaiQADwtBuMDEAEEoQbzBxAAQzgMAC4MBAgJ/A34jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAIAAgBEEIakHY7cgAEKEBIARBMGokAAUgASADEOUEKQMAIQUgAiADEOUEKQMAIQYgBEEIaiADEOYEIAYgBSAHQjSIfHwiB0L/////////B4M3AwAgA0EBaiEDDAELCwubAQEDfyMAQSBrIgEkACAAKAIAIgAoAgAhAiAAQQA2AgAgACgCBCABIAIoAgAoAhARAwAoAgAhAiABQRhqIgMgAUEIaigCADYCACABIAEpAwA3AxAgAkEEaiEAIAIoAgQEQCAAIgIoAgQiBARAIAIoAgAgBEEDdEEEELYFCwsgACABKQMQNwIAIABBCGogAygCADYCACABQSBqJAALhgEBAn8jAEGQIGsiAiQAIAJBCGogAUGUIGoQfCACQQhqQQRyIQMCQCACKAIIQQFGBEAgACADKQIANwIAIABBEGogA0EQaigCADYCACAAQQhqIANBCGopAgA3AgAMAQsgASABKQMANwMIIAFBEGogA0GEIBDyAxogAEEFOgAQCyACQZAgaiQAC3kBAn8jAEGAAWsiAyQAIAAtAAAhAkEAIQADQCAAIANqQf8AaiACQQFxQTByOgAAIABBf2ohACACQQF2IgINAAsgAEGAAWoiAkGBAU8EQCACQYABEOYCAAsgAUG3rMoAQQIgACADakGAAWpBACAAaxA1IANBgAFqJAALfQEDfyMAQYABayICJAAgACABIAFB0ABqIgMQHiACQQhqIAFBKGoiBCADEB4gAkEwaiADEMgFIAJB2ABqIAEgBBAeIABBKGogAkEIakEoEPIDGiAAQdAAaiACQTBqQSgQ8gMaIABB+ABqIAJB2ABqQSgQ8gMaIAJBgAFqJAALgQEBAX8jAEHwIGsiBCQAIARBCGpBAEHAABDBBBogBEHYAGpCgICAEDcDACAEQRA2AkggBEKAgIAQNwNQIARB4ABqIAFBhCAQ8gMaIARB7CBqQQA2AgAgBEHoIGogAzYCACAEQeQgaiACNgIAIAAgBEEIakHoIBDyAxogBEHwIGokAAupAQACQAJAAkACQAJAIAAoAgAtAABBAWsOBAIDBAABCyABKAIYQfnAygBBBCABQRxqKAIAKAIMEQQADwsgASgCGEH0wMoAQQUgAUEcaigCACgCDBEEAA8LIAEoAhhBrcHKAEEMIAFBHGooAgAoAgwRBAAPCyABKAIYQaXBygBBCCABQRxqKAIAKAIMEQQADwsgASgCGEGcwcoAQQkgAUEcaigCACgCDBEEAAt+AQF/IwBBQGoiBSQAIAVBIGogASACEKwBIAVBCGogBUEgakHY+sEAEOsCIAVBIGogBUEIaiADIAQQ4gEgBSAFQSBqEM8EIAUoAgQiAUEfTQRAQSAgARDlAgALIAAgBSgCAEEgEJwDIAVBCGoQowUgBUEgahCBBSAFQUBrJAALngEBBX4gAUEgEOABIQIgAUEGakEaEOABIQMgAUEMakEUEOABIQQgAUETakENEOABIQUgAUEYakEIEOABIQYgACAEQgaIQv////////8DgzcDECAAIANCA4hC/////////wODNwMIIAAgAkL/////////A4M3AwAgACAFQgGIQv////////8DgzcDGCAAIAZCDIhC/////////wODNwMgC54BAQV+IAFBIBDhASECIAFBBmpBGhDhASEDIAFBDGpBFBDhASEEIAFBE2pBDRDhASEFIAFBGGpBCBDhASEGIAAgBEIGiEL/////////A4M3AxAgACADQgOIQv////////8DgzcDCCAAIAJC/////////wODNwMAIAAgBUIBiEL/////////A4M3AxggACAGQgyIQv////////8DgzcDIAuMAQEBfwJAIAAtAMgBIgFBxwFNBEAgACABaiIBIAEtAAAgAC0AyQFzOgAAIAAtAMgBQQFqQf8BcSIBQccBSw0BIAAgAWoiASABLQAAQQRzOgAAIAAgAC0ApwFBgAFzOgCnASAAECIgAEEAOwHIAQ8LQezzwwAgAUHIARDkAgALQfzzwwAgAUHIARDkAgALegEDfyMAQRBrIgIkAAJAIAAoAgAiAUEITQRAIAFBDGwhASAAQQhqIQADQCABRQ0CIAFBdGohASAAELUEIABBDGohAAwACwALIABBCGooAgAhAyACIABBDGooAgA2AgggAiABNgIEIAIgAzYCACACENQFCyACQRBqJAALbwEDfiAAIAJCIIgiAyABQiCIIgR+QgB8QgB8IAJC/////w+DIgIgAUL/////D4MiAX4iBUIgiCACIAR+fCICQiCIfCABIAN+IAJC/////w+DfCIBQiCIfDcDCCAAIAVC/////w+DIAFCIIaENwMAC3MBAn8gACgCACICQXxxIgFFIAJBAnFyRQRAIAEgASgCBEEDcSAAKAIEQXxxcjYCBAsgACAAKAIEIgJBfHEiAQR/IAEgASgCAEEDcSAAKAIAQXxxcjYCACAAKAIEBSACC0EDcTYCBCAAIAAoAgBBA3E2AgALfQEEfyMAQSBrIgEkACAAQgA3AAAgAEEYaiICQgA3AAAgAEEQaiIDQgA3AAAgAEEIaiIEQgA3AAAgARDLBCACIAFBGGopAwA3AAAgAyABQRBqKQMANwAAIAQgAUEIaikDADcAACAAIAEpAwA3AAAgAEEgahCzAiABQSBqJAALgQEBAX8jAEEQayICJAAgAiABQa2FygBBBRC/BCACIABBEGo2AgwgAkGyhcoAQQQgAkEMakG4hcoAEGogAiAANgIMIAJByIXKAEEDIAJBDGpBzIXKABBqIAIgAEEIajYCDCACQdyFygBBBSACQQxqQeSFygAQaiACELECIAJBEGokAAt7AQF/IwBBMGsiASQAIAFBigE2AgQgAUEANgIQIAFCBDcDCCABQQA2AhggASABQRhqNgIoIAEgAUEEajYCJCABIAFBCGo2AiAQhgMgAEEIaiABKAIQNgIAIAAgASkDCDcCACAAIAEoAhxBACABKAIYGzYCDCABQTBqJAALdgEDfyMAQSBrIgIkAAJAIAAgARCCAUUEQCABQRxqKAIAIQMgASgCGCACQRxqQQA2AgAgAkHEqsoANgIYIAJCATcCDCACQciqygA2AgggAyACQQhqEDNFDQELIAJBIGokAEEBDwsgAEEEaiABEIIBIAJBIGokAAt7AQR/IwBBIGsiAyQAIANBGGoiBEIANwMAIANBEGoiBUIANwMAIANBCGoiBkIANwMAIANCADcDACADQSAgASACEK4BIABBGGogBCkDADcAACAAQRBqIAUpAwA3AAAgAEEIaiAGKQMANwAAIAAgAykDADcAACADQSBqJAALcQACfyACQQJ0IgEgA0EDdEGAgAFqIgIgASACSxtBh4AEaiIBQRB2QAAiAkF/RgRAQQAhA0EBDAELIAJBEHQiA0IANwMAIANBADYCCCADIAMgAUGAgHxxakECcjYCAEEACyEBIAAgAzYCBCAAIAE2AgALcgEDfyMAQZABayIBJAAgAUEANgIAIAFBBHIhAwNAIAJBwABGBEAgAUHIAGogAUHEABDyAxogACABQcgAakEEckHAABDyAxogAUGQAWokAAUgAiADakEAOgAAIAEgASgCAEEBajYCACACQQFqIQIMAQsLC3IBA38jAEGQAmsiASQAIAFBADYCACABQQRyIQMDQCACQYABRgRAIAFBiAFqIAFBhAEQ8gMaIAAgAUGIAWpBBHJBgAEQ8gMaIAFBkAJqJAAFIAIgA2pBADoAACABIAEoAgBBAWo2AgAgAkEBaiECDAELCwuAAQEBfyMAQUBqIgUkACAFIAE2AgwgBSAANgIIIAUgAzYCFCAFIAI2AhAgBUEsakECNgIAIAVBPGpBuAE2AgAgBUICNwIcIAVBoKvKADYCGCAFQbQBNgI0IAUgBUEwajYCKCAFIAVBEGo2AjggBSAFQQhqNgIwIAVBGGogBBC9BAALfQAgAUEITwRAIAAgAkIohkKAgICAgIDA/wCDIAJCOIaEIAJCGIZCgICAgIDgP4MgAkIIhkKAgICA8B+DhIQgAkIIiEKAgID4D4MgAkIYiEKAgPwHg4QgAkIoiEKA/gODIAJCOIiEhIQ3AAAPC0GI6MkAQSBBlOfJABC0BAALYAICfwF+AkACQCABrUIMfiIEQiCIp0UEQCAEpyICQX9MDQECQCACRQRAQQQhAwwBCyACQQQQpAUiA0UNAwsgACABNgIEIAAgAzYCAA8LEOsFAAsQ6wUACyACQQQQ3QUAC2ECAn8BfgJAAkAgAa1C8AB+IgRCIIinRQRAIASnIgJBf0wNAQJAIAJFBEBBCCEDDAELIAJBCBCkBSIDRQ0DCyAAIAE2AgQgACADNgIADwsQ6wUACxDrBQALIAJBCBDdBQALbgECfyMAQSBrIgEkACABQQhqEFhBASECAkAgASgCCEEBRgRAIAAgASkCDDcCBCAAQRRqIAFBHGooAgA2AgAgAEEMaiABQRRqKQIANwIADAELIAAgASkCDDcCBEEAIQILIAAgAjYCACABQSBqJAALZwACQCABIABPBEAgAkUNAQNAIAAgAS0AADoAACABQQFqIQEgAEEBaiEAIAJBf2oiAg0ACwwBCyACRQ0AIAFBf2ohASAAQX9qIQADQCAAIAJqIAEgAmotAAA6AAAgAkF/aiICDQALCwuJAQEBfyMAQTBrIgIkACACQQhqEMsEIABBKGogAUL56tDQ58mh5OEAfDcDACAAQSBqIAE3AwAgAEEYaiABQs/W077Sx6vZQnw3AwAgACABQtbrgu7q/Yn14AB8NwMQIAAgATcDCCAAQgA3AwAgAkEANgIoIABBMGogAkEIakEoEPIDGiACQTBqJAALagEBfyMAQRBrIgQkACAAAn8gAiADaiIDIAJPBEAgASgCBEEBdCIBIAMgASADSxshAkEADAELIARBCGogA0EAEKYFIAQoAgghAiAAQQhqIAQoAgw2AgBBAQs2AgAgACACNgIEIARBEGokAAt6AQF/IwBBgAFrIgAkACAAQQhqEEkgAEHYAGogAEEIakEoEPIDGkHI+soAIABB2ABqQSgQogEgAEEwaiAAQdgAakEoEPIDGiAALQBAQQJHBEBBnNjKAEGc2MoAKAIAQX9qNgIAIABBMGoQhAULIABBgAFqJABByPrKAAt0AQJ/IAAtAAQhASAALQAFBEAgAAJ/QQEgAUH/AXENABogACgCACIAQRxqKAIAKAIMIQEgACgCGCECIAAtAABBBHFFBEAgAkGrrMoAQQIgAREEAAwBCyACQaqsygBBASABEQQACyIBOgAECyABQf8BcUEARwuWAQECfyMAQdADayIDJAAgA0EAQcwBEMEEIgRBADoA0QEgBEEBOgDQASAEQYgBNgLMASADQfABakIANwMAIANB6AFqQgA3AwAgA0HgAWpCADcDACADQgA3A9gBIAMgASACEOoBIANB+AFqIANB2AEQ8gMaIANB+AFqIANB2AFqEJMEIAAgA0HYAWpBIBCcAyADQdADaiQAC3UBBH8jAEEgayIBJAAgAEIANwAAIABBGGoiAkIANwAAIABBEGoiA0IANwAAIABBCGoiBEIANwAAIAEQywQgAiABQRhqKQAANwAAIAMgAUEQaikAADcAACAEIAFBCGopAAA3AAAgACABKQAANwAAIAFBIGokAAsnAQF/QQhBBBCkBSIBBEAgAEEBNgIEIAAgATYCAA8LQQhBBBDdBQALNwIBfwF+IwBBIGsiAiQAIAJBCGogAUEBEIkDIAIpAwghAyAAIAE2AgggACADNwIAIAJBIGokAAuRAQECfwJAAkACQCAAKAIEIgIgAU8EQCABBEAgASACRg0EIAAoAgAgAkHwAGxBCCABQfAAbCICEJQFIgMNAiACQQgQ3QUACyAAIgEoAgQiAgRAIAEoAgAgAkHwAGxBCBC2BQsgAEEINgIAQQAhAQwCC0HQ7skAQSRBlO/JABDOAwALIAAgAzYCAAsgACABNgIECwt3AQF/IwBBgAVrIgUkACAFQeAAaiABIAIQKyAFQYADaiAFQeAAakG8g8AAEMgCIAUgAyAEEKQCIAVB4ABqIAVBgANqIAUQ+QEgBSAFQeAAahCRASAAIAVB4AAQnAMgBUHgAGoQogUgBUGAA2oQogUgBUGABWokAAtfAQF/IwBBMGsiByQAIAdBEGogASACIAMgBCAFIAYQNyAHQShqIAdBGGooAgA2AgAgByAHKQMQNwMgIAdBADYCLCAHQQhqIAdBIGoQrwMgACAHKQMINwIAIAdBMGokAAtgAQF/IwBBMGsiByQAIAdBEGogASACIAMgBCAFIAYQ8gEgB0EoaiAHQRhqKAIANgIAIAcgBykDEDcDICAHQQA2AiwgB0EIaiAHQSBqEK8DIAAgBykDCDcCACAHQTBqJAALdgEBfyMAQdAAayICJAAgAhCXASACQSBqIAFBCGooAgA2AgAgAiABKQIANwMYIAJBKGogAkEkEPIDGkEkQQQQpAUiAUUEQEEkQQQQ3QUACyABIAJBKGpBJBDyAyEBIABBvPPIADYCBCAAIAE2AgAgAkHQAGokAAtzAQV/IwBBEGsiAiQAA0ACQCACQQhqIAEQRyACKAIIIgRFDQAgAigCDCEFIAAoAggiAyAAKAIERgRAIAAgACgCCBCnAwsgACgCACADQQN0aiIGIAU2AgQgBiAENgIAIAAgA0EBajYCCAwBCwsgAkEQaiQAC1cAIAAgAkIyiSACQi6JhSACQheJhSAIfCAEIAaFIAKDIAaFfCAJfCICIAd8NwMIIAAgAyAFhSABgyADIAWDhSABQiSJIAFCHomFIAFCGYmFfCACfDcDAAtmAQF/IAEoAgAiASgCaCICIAEoAmxHBEAgASACQQFqNgJoIAACfyABQQhqIAEoAgBBCE0NABogAUEIaigCAAsgAkEMbGoiASkCADcCACAAQQhqIAFBCGooAgA2AgAPCyAAQQI6AAgLcwEBfyMAQbAEayICJAAgAiABQdgBahDpAiACQdgCaiABQdgBEPIDGiACQdgBaiACQdgCahDuAyACIAJB2AFqELIEIAJB2AJqIAJB2AEQ8gMaIAJBmAJqIAJB2AJqEO4DIAAgAkGYAmoQuQUgAkGwBGokAAteAQF/IwBBMGsiBiQAIAZBEGogASACIAMgBCAFELUDIAZBKGogBkEYaigCADYCACAGIAYpAxA3AyAgBkEANgIsIAZBCGogBkEgahCvAyAAIAYpAwg3AgAgBkEwaiQAC10BAX8jAEEwayIGJAAgBkEQaiABIAIgAyAEIAUQGyAGQShqIAZBGGooAgA2AgAgBiAGKQMQNwMgIAZBADYCLCAGQQhqIAZBIGoQrwMgACAGKQMINwIAIAZBMGokAAt0AQF/AkADQCACRQ0BIAAtAMgBIgNBxwFNBEAgACADaiIDIAMtAAAgAS0AAHM6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0GM9MMAIANByAEQ5AIACwt0AQF/IABBBkEAEEQCQANAIAJFDQEgAC0AyAEiA0HHAU0EQCAAIANqIAEtAAA6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0Gc9MMAIANByAEQ5AIACwt1AQF/IwBBQGoiASQAIAEQpgIgAEEANgIIIABCADcDACAAQQxqIAFBwAAQ8gMaIABB5ABqQcDoyQApAgA3AgAgAEHcAGpBuOjJACkCADcCACAAQdQAakGw6MkAKQIANwIAIABBqOjJACkCADcCTCABQUBrJAALdAEEfyAAQbnz3fF5bCEDAkADQCADQQAQkAMiACgCCGtBH3F2IgEgACgCBCICTw0BIAAoAgAiAiABQfAAbGpBIGoiBBDxBCAAQaDYygAoAgBHBEAgBBDQBAwBCwsgAiABQfAAbGoPC0Gw7skAIAEgAhDkAgALcAEBfyMAQTBrIgEkACABIAA2AgwDQCABQSBqIAFBDGoQvQIgAS0AKEECRgRAIAFBIGoiAC0ACEECRwRAIAAQtQQLIAFBMGokAAUgAUEYaiABQShqKAIANgIAIAEgASkDIDcDECABQRBqELUEDAELCwtlAQN/IwBBEGsiASQAIAFBCGogABCbBSABKAIMQRhsIQIgASgCCCIDQQxqIQADQCACBEAgAygCDARAIAAQowMgABD0BAsgA0EYaiEDIAJBaGohAiAAQRhqIQAMAQsLIAFBEGokAAtuAQF/IwBBIGsiAyQAIAEoAgBBAUYEQCADQRhqIAFBFGopAgA3AwAgA0EQaiABQQxqKQIANwMAIAMgASkCBDcDCEHzgcAAQSsgA0EIakGggsAAIAIQqAIACyAAIAFBCGpBwAEQ8gMaIANBIGokAAtuAQF/IwBBIGsiAyQAIAEoAgBBAUYEQCADQRhqIAFBFGopAgA3AwAgA0EQaiABQQxqKQIANwMAIAMgASkCBDcDCEHzgcAAQSsgA0EIakGggsAAIAIQqAIACyAAIAFBCGpBgAIQ8gMaIANBIGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBC4ASAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBC3AiAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBD4AiAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtbAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBAaIAVBKGogBUEYaigCADYCACAFIAUpAxA3AyAgBUEANgIsIAVBCGogBUEgahCvAyAAIAUpAwg3AgAgBUEwaiQAC1wBAX8jAEEwayIFJAAgBUEQaiABIAIgAyAEEJkCIAVBKGogBUEYaigCADYCACAFIAUpAxA3AyAgBUEANgIsIAVBCGogBUEgahCvAyAAIAUpAwg3AgAgBUEwaiQAC2YBAn8gACAAKAIEIAFBFXQgACgCACIBQR9xdnIiAjYCBCAAQQhqIQMgAUELaiEBA0AgACABNgIAIAFBB0sEQCADIAJBGHYQigQgACAAKAIEQQh0IgI2AgQgACgCAEF4aiEBDAELCwtqAQF/IwBBIGsiAiQAIAJBGGogAUEQaigCADYCACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAIgAkEIahCKAyAAIAIpAwA3AgggAEEaNgIEIABBh/nJADYCACAAQQA6ABAgAkEgaiQAC4gBAQF/IwBBEGsiAiQAAkACQAJAAkACQAJAIAAtAABBAWsOBAIDBAABCyACIAFB+ITKAEEPEJwEDAQLIAIgAUGihcoAQQsQnAQMAwsgAiABQZiFygBBChCcBAwCCyACIAFBj4XKAEEJEJwEDAELIAIgAUGHhcoAQQgQnAQLIAIQgAIgAkEQaiQAC3MBAX8jAEEQayIBJAAgACgCACIALQAAIQIgAEEAOgAAAkAgAkEBcQRAIAFBCGoQkQNBCEEEEKQFIgBFDQEgACABKQMINwIAQeD5ygAgADYCACABQRBqJAAPC0H8jMoAQStB7IzKABDOAwALQQhBBBDdBQALcAECfwJAIAAoAgAiAUEQaigCACICRQ0AIAJBADoAACABQRRqKAIAIgJFDQAgASgCECACQQEQtgULIAFBHGooAgBBAUEBELYFIAAoAgAiASABKAIEIgFBf2o2AgQgAUEBRgRAIAAoAgBBMEEIELYFCwtaAQF/IwBBMGsiBCQAIARBEGogASACIAMQ6QEgBEEoaiAEQRhqKAIANgIAIAQgBCkDEDcDICAEQQA2AiwgBEEIaiAEQSBqEK8DIAAgBCkDCDcCACAEQTBqJAALcAEBfwJAAkACQCAAKAIEIgIgAU8EQCABBEAgASACRg0EIAAoAgAgAkEBIAEQlAUiAg0CIAFBARDdBQALIAAQgQUgAEEBNgIAQQAhAQwCC0GQ/cEAQSRB1P3BABDOAwALIAAgAjYCAAsgACABNgIECwtfAQF/IwBBoAJrIgIkACACQagBaiABQSgQ8gMaIAJB0AFqIAFBKGpBKBDyAxogAkH4AWogAUHQAGpBKBDyAxogAkEIaiACQagBahCjASAAIAJBCGoQgwIgAkGgAmokAAt4AQF/IwBBIGsiASQAIAFBrPrKADYCDEGs+soAKAIAQQFHBEAgASAANgIQIAEgAUEMajYCFCABIAFBEGo2AhxBrPrKACABQRxqQZj1yAAQVwsgASgCDBDHBCIARQRAQcD1yABBK0HI9sgAEM4DAAsgAUEgaiQAIAALeAEBfyMAQSBrIgEkACABQZj6ygA2AgxBmPrKACgCAEEBRwRAIAEgADYCECABIAFBDGo2AhQgASABQRBqNgIcQZj6ygAgAUEcakGs9cgAEFcLIAEoAgwQxwQiAEUEQEHA9cgAQStByPbIABDOAwALIAFBIGokACAAC1wCAn8BfiAAKAIEIgEEQAJ/AkAgAUEIaiICIAFBBWpJDQAgAUEBaq1CDH4iA0IgiKcNACACQXxxIgIgA6dqIgEgAkkNAEEEDAELQQALIQIgACgCACABIAIQtgULC3MBAX8jAEEwayIBJAAgAUGAATYCBCABIAA2AgAgAUEcakECNgIAIAFBLGpBywA2AgAgAUICNwIMIAFB5OnJADYCCCABQcsANgIkIAEgAUEgajYCGCABIAFBBGo2AiggASABNgIgIAFBCGpB0OrJABC9BAALcgEBfyMAQRBrIgQkACAEIAI2AgQgBCABNgIAIAQgAzYCDAJAIANFIAIgA0ZyDQAgAiADSwRAIAEgA2osAABBv39KDQELIAQoAgAgBCgCBEEAIARBDGooAgAQKQALIAAgAzYCBCAAIAE2AgAgBEEQaiQAC2sBAX8jAEEgayIDJAAgAyABIAIQGQJAIAMtABxFBEAgAEECOgAcDAELIAAgAykDADcCACAAQRhqIANBGGopAwA3AgAgAEEQaiADQRBqKQMANwIAIABBCGogA0EIaikDADcCAAsgA0EgaiQAC1gBAX8jAEEwayIDJAAgA0EQaiABIAIQjAEgA0EoaiADQRhqKAIANgIAIAMgAykDEDcDICADQQA2AiwgA0EIaiADQSBqEK8DIAAgAykDCDcCACADQTBqJAALWAEBfyMAQTBrIgMkACADQRBqIAEgAhCyAiADQShqIANBGGooAgA2AgAgAyADKQMQNwMgIANBADYCLCADQQhqIANBIGoQrwMgACADKQMINwIAIANBMGokAAtYAQF/IwBBMGsiAyQAIANBEGogASACEOoCIANBKGogA0EYaigCADYCACADIAMpAxA3AyAgA0EANgIsIANBCGogA0EgahCvAyAAIAMpAwg3AgAgA0EwaiQAC1gBAX8jAEEwayIDJAAgA0EQaiABIAIQngMgA0EoaiADQRhqKAIANgIAIAMgAykDEDcDICADQQA2AiwgA0EIaiADQSBqEK8DIAAgAykDCDcCACADQTBqJAALWAEBfyMAQTBrIgMkACADQRBqIAEgAhCDASADQShqIANBGGooAgA2AgAgAyADKQMQNwMgIANBADYCLCADQQhqIANBIGoQrwMgACADKQMINwIAIANBMGokAAtrAQJ/IwBBEGsiBiQAAkAgACABIAIgAyAEEFIiBQ0AIAZBCGogAyAAIAEgBCgCDBEFAEEAIQUgBigCCA0AIAYoAgwiBSACKAIANgIIIAIgBTYCACAAIAEgAiADIAQQUiEFCyAGQRBqJAAgBQtsAQF/IwBB4AJrIgIkACACQQhqQQBBwAAQwQQaIAJBiAFqIAFB2AEQ8gMaIAJByABqIAJBiAFqEKEEIAIgAkHIAGoQqQUgAkEIakHAACACKAIAIAIoAgQQsAEgACACQQhqEMUEIAJB4AJqJAALagEBfyMAQRBrIgMkACADIAEgAhAkIANBCGooAgAhASADKAIEIQIgAygCAEEBRwRAIAMgA0EMaigCADYCCCADIAE2AgQgAyACNgIAIAMQgQVBACECCyAAIAE2AgQgACACNgIAIANBEGokAAtvAQF/IwBBMGsiAyQAIAMgAjYCBCADIAE2AgAgA0EcakECNgIAIANBLGpBywA2AgAgA0ICNwIMIANB9KvKADYCCCADQcsANgIkIAMgA0EgajYCGCADIAM2AiggAyADQQRqNgIgIANBCGogABC9BAALcgEBfyMAQTBrIgIkACACIAE2AgQgAiAANgIAIAJBHGpBAjYCACACQSxqQcsANgIAIAJCAjcCDCACQaCvygA2AgggAkHLADYCJCACIAJBIGo2AhggAiACQQRqNgIoIAIgAjYCICACQQhqQbCvygAQvQQAC3IBAX8jAEEwayICJAAgAiABNgIEIAIgADYCACACQRxqQQI2AgAgAkEsakHLADYCACACQgI3AgwgAkHkr8oANgIIIAJBywA2AiQgAiACQSBqNgIYIAIgAkEEajYCKCACIAI2AiAgAkEIakH0r8oAEL0EAAtWAQJ/IwBBIGsiAiQAIAFBHGooAgAhAyABKAIYIAJBGGogAEEQaikCADcDACACQRBqIABBCGopAgA3AwAgAiAAKQIANwMIIAMgAkEIahAzIAJBIGokAAtWAQJ/IwBBIGsiAiQAIABBHGooAgAhAyAAKAIYIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAMgAkEIahAzIAJBIGokAAttAgJ/An4jAEGAAWsiAiQAIAEpAwAhBCABKQMIIQUgAiABQdQAahDkBSAAIAU3AwggACAENwMAIAEoAlAhAyAAQRBqIAFBEGpBwAAQ8gMaIAAgAzYCUCAAQdQAaiACQYABEPIDGiACQYABaiQAC2gBAX8jAEGABGsiAyQAIANBEGoQsgMgA0EQaiABIAIQ0QUgA0GoAmogA0EQakHYARDyAxogA0HoAWogA0GoAmoQoQQgA0EIaiADQegBahCpBSAAIAMoAgggAygCDBCcAyADQYAEaiQAC2oBAX8jAEEQayIDJAAgASgCAEEBRgRAIAMgASkCBDcDCEGw98EAQSsgA0EIakHc98EAIAIQqAIACyAAIAEpAgQ3AgAgAEEQaiABQRRqKQIANwIAIABBCGogAUEMaikCADcCACADQRBqJAALVgEBfyMAQTBrIgIkACACQRBqIAEQnQMgAkEoaiACQRhqKAIANgIAIAIgAikDEDcDICACQQA2AiwgAkEIaiACQSBqEK8DIAAgAikDCDcCACACQTBqJAALbQICfwJ+IwBBgAFrIgIkACABKQMAIQQgASkDCCEFIAIgAUHUAGoQswQgACAFNwMIIAAgBDcDACABKAJQIQMgAEEQaiABQRBqQcAAEPIDGiAAIAM2AlAgAEHUAGogAkGAARDyAxogAkGAAWokAAthAQF/IwBBIGsiAiQAIAEQbSACEOwBIAFBzABqIAIQYiAAQRhqIAJBGGopAwA3AAAgAEEQaiACQRBqKQMANwAAIABBCGogAkEIaikDADcAACAAIAIpAwA3AAAgAkEgaiQAC14BAX8jAEEgayIEJAAgBCADNgIUIAQgAjYCEAJ/IAEgA08EQCAEQQhqIAEgA2sgASAAIAEQ1AMgBCAEKQMINwMYQQEgBEEQaiAEQRhqEJMFDQEaC0EACyAEQSBqJAALXAECfyMAQRBrIgIkACAAKAIAIgAoAgghAyAAKAIAIQAgAiABEMAEIAMEQANAIAIgADYCDCACIAJBDGoQjwEgAEEBaiEAIANBf2oiAw0ACwsgAhC+BCACQRBqJAALWgECfyMAQTBrIgIkACACQQhqIAFBARAqQQAhAQNAIAFBKEYEQCAAIAJBCGpBKBDyAxogAkEwaiQABSACQQhqIAFqIgMgAykDAEIBhjcDACABQQhqIQEMAQsLC14BAn8jAEHQAGsiAiQAIAAgASABQfgAaiIDEB4gAiABQShqIAFB0ABqIgEQHiACQShqIAEgAxAeIABBKGogAkEoEPIDGiAAQdAAaiACQShqQSgQ8gMaIAJB0ABqJAALZQEBfyMAQZABayIDJAAgA0EIaiACEKsCIANBADYCGCADIAMpAwg3AxAgA0EgaiABQfAAEPIDGiADQRBqIAIgA0EgahDUASAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBkAFqJAALXQICfwF+AkAgASgCACIEIAEoAgQiAWpBf2pBACABa3EiAyAETwRAIAOtIAKtfiIFQiCIpw0BIAAgAzYCCCAAIAE2AgQgACAFPgIADwsgAEEANgIEDwsgAEEANgIEC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpB5JnKACACQQhqEDMgAkEgaiQAC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpBtKjKACACQQhqEDMgAkEgaiQAC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpBhK7KACACQQhqEDMgAkEgaiQAC2cBAX8jAEHAA2siBSQAIAUgASACEF4gBUHgAWogBUHMg8AAEMcCIAVBoANqIAMgBBCkAiAFIAVB4AFqIAVBoANqEPgBIAVBoANqIAUQ4QUQ1gMgACAFQaADakEgEJwDIAVBwANqJAALXQEDfyMAQRBrIgIkAAJAIAEoAgAgASgCBE8NACACQQhqIAFBARDwBCACKAIIQQFHDQAgASgCACEDIAEgAigCDDYCAEEBIQQLIAAgAzYCBCAAIAQ2AgAgAkEQaiQAC2cBA38gAEEEaiEBIAAoAgBFBEAgARCBBQ8LIAEtAABBAk8EQCAAQQhqKAIAIgEoAgAgASgCBCgCABEDACABKAIEIgIoAgQiAwRAIAEoAgAgAyACKAIIELYFCyAAKAIIQQxBBBC2BQsLWwEBfyMAQSBrIgQkACAEIAM2AhQgBCACNgIQAn8gASADTwRAIARBCGpBACADIAAgARDUAyAEIAQpAwg3AxhBASAEQRBqIARBGGoQkwUNARoLQQALIARBIGokAAtWAQF/IwBBIGsiAiQAIAIgADYCBCACQRhqIAFBEGopAgA3AwAgAkEQaiABQQhqKQIANwMAIAIgASkCADcDCCACQQRqQYSuygAgAkEIahAzIAJBIGokAAtTAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqEIcEIAIoAgghASAAIAIoAgw2AgQgACABNgIAIAJBIGokAAtkAQF/IwBBIGsiBSQAIAVBGGogAEHIASADEJ0EIAVBEGogBSgCGCAFKAIcIAQQngQgBSgCFCEAIAUoAhAhAyAFQQhqIAEgAiAEEJ4EIAUoAgggBSgCDCADIAAQrgEgBUEgaiQAC1kBAX8jAEGgAWsiAiQAIAJB0ABqIAEQYyACIAJB0ABqQSgQ8gMiAUEoaiABQfgAakEoEPIDGiABQdAAaiABQQUQKiAAIAFB0ABqIAFBKGoQHiABQaABaiQAC2QBAX8jAEHwA2siAiQAIAIgAUHYAWoQ7QIgAkGYAmogAUHYARDyAxogAkHYAWogAkGYAmoQ7gMgAiACQdgBahCyBCACQZgCaiACQdgBEPIDGiAAIAJBmAJqEO4DIAJB8ANqJAALXAEBfyMAQSBrIgIkACACEO8DNgIMIAJBEGogARC1AiACIAJBEGoQmwUgAkEMaiACKAIAIAIoAgQQvAUgAEEIaiACQRhqKAIANgIAIAAgAikDEDcCACACQSBqJAALXwEBfyMAQeACayICJAAgACABEOkCIAJBCGogAUGwA2oQ5AUgAkGIAWogAUHYAWoQ6QIgAEGwA2ogAkEIakGAARDyAxogAEHYAWogAkGIAWpB2AEQ8gMaIAJB4AJqJAALYgEBfyMAQSBrIgIkACACIAEQSCAAIAFBoAEQ8gMiAEG4AWogAkEYaikDADcAACAAQbABaiACQRBqKQMANwAAIABBqAFqIAJBCGopAwA3AAAgACACKQMANwCgASACQSBqJAALXwEBfyMAQeACayICJAAgACABEO0CIAJBCGogAUGwA2oQswQgAkGIAWogAUHYAWoQ7QIgAEGwA2ogAkEIakGAARDyAxogAEHYAWogAkGIAWpB2AEQ8gMaIAJB4AJqJAALZAEBfyMAQRBrIgMkACABKAIAQQFGBEAgAyABKAIENgIIIAMgAUEIai0AADoADEGp88kAQSsgA0EIakHU88kAIAIQqAIACyAAIAEoAgQ2AgAgACABQQhqLQAAOgAEIANBEGokAAtqAQN/IwBBEGsiACQAIAAQ/wEgACAALQAEIgE6AAwgACAAKAIAIgI2AgggAEEIahCaBQJAAkAgAUECSw0AAkAgAUEBaw4CAQIACxCbBEUNACACQQE6AAQLIAIoAgBBADoAAAsgAEEQaiQAC1kBAX8jAEHQAGsiAiQAIAAgAUEoakEoEPIDIQAgAiABQSgQ8gMiAkEoaiABQdAAahDZAyAAQShqIAJBKBDyAxogAEHQAGogAkEoakEoEPIDGiACQdAAaiQAC00BA39BASEDA38gAkEgRgR/IAMQlgUFIAEgAmotAAAgACACai0AAHMiBEEAIARrckF/c0GAAXFBB3YQlgUgA3EhAyACQQFqIQIMAQsLC2oBAX8CQCABQX9KBEACQCABRQRAQQEhAgwBCwJ/IAJFBEAgAUEBEKQFDAELIAEiAkEBEN0BIgMEQCADQQAgAhDBBBoLIAMLIgJFDQILIAAgATYCBCAAIAI2AgAPCxDrBQALIAFBARDdBQALUgEBfyMAQSBrIgIkACACQRhqIAFBEGooAgA2AgAgAkEQaiABQQhqKQIANwMAIAIgASkCADcDCCACIAJBCGoQhgIgACACKQMANwIAIAJBIGokAAtbAAJAIAEgA30iAyABVg0AAkAgAiAETwRAIAMhAQwBCyADQn98IgEgA1YNASACQYCU69wDaiECCyAAIAE3AwAgACACIARrNgIIDwtBlKTKAEEjQcykygAQjgMAC0wBA39BASEDA0AgAkEgRwRAIAEgAmotAAAgACACai0AAHMiBEEAIARrckF/c0GAAXFBB3YQlgUgA3EhAyACQQFqIQIMAQsLIAMQlgULVwECfyMAQRBrIgIkACACQQhqIAEQqwECf0EAIAIvAQhFDQAaIAIgAUEgaiACLwEKEKQEIAIoAgQhAyACKAIACyEBIAAgAzYCBCAAIAE2AgAgAkEQaiQAC10BAX8jAEEwayIDJAAgAyABNgIMIAMgADYCCCADQSRqQQE2AgAgA0IBNwIUIANBlKvKADYCECADQbQBNgIsIAMgA0EoajYCICADIANBCGo2AiggA0EQaiACEL0EAAtVAQF/IwBBIGsiAiQAIAJBGGogAUEYaikCADcDACACQRBqIAFBEGopAgA3AwAgAkEIaiABQQhqKQIANwMAIAIgASkCADcDACAAIAIQuwIgAkEgaiQAC2ABA38jAEEQayIBJAACQEGg2MoAKAIAIgANAEEDQQAQnQEhAkGg2MoAQaDYygAoAgAiACACIAAbNgIAIABFBEAgAiEADAELIAEgAjYCDCABQQxqEP4DCyABQRBqJAAgAAtYAQJ/IwBBEGsiASQAQQFBARCkBSICRQRAQQFBARDdBQALIAJBADoAACAAQQA6AAQgACACNgIAIAAgAS8ADTsABSAAQQdqIAFBD2otAAA6AAAgAUEQaiQAC1gBAX8jAEEQayICJAACQCAAKAIABEAgAiABQfSFygBBBBCcBCACIAA2AgwgAiACQQxqQfiFygAQjgEMAQsgAiABQYiGygBBBBCcBAsgAhCAAiACQRBqJAALVwEBfwJAIAJBf0oEQAJAIAJFBEBBASEDDAELIAJBARCkBSIDRQ0CCyADIAEgAhDyAyEBIAAgAjYCCCAAIAI2AgQgACABNgIADwsQ6wUACyACQQEQ3QUAC1YBAX8jAEEQayICJAAgAiABQfSlygBBCBCcBCACIAA2AgwgAiACQQxqQayeygAQjgEgAiAAQQRqNgIMIAIgAkEMakH8pcoAEI4BIAIQgAIgAkEQaiQAC0wBAX8jAEFAaiIBJAAgAUEYakIANwMAIAFBEGpCADcDACABQQhqQgA3AwAgAUIANwMAIAFBIGogABBDIAFBIGogARCIAyABQUBrJAALVgECfyABKAIAIQIgAUEANgIAAkAgAgRAIAEoAgQhA0EIQQQQpAUiAUUNASABIAM2AgQgASACNgIAIABBvMbEADYCBCAAIAE2AgAPCwALQQhBBBDdBQALVgECfyABKAIAIQIgAUEANgIAAkAgAgRAIAEoAgQhA0EIQQQQpAUiAUUNASABIAM2AgQgASACNgIAIABBnOnJADYCBCAAIAE2AgAPCwALQQhBBBDdBQALVQICfwJ+IwBBIGsiASQAEO8FIAEpAxAhAyABKAIYIQIgARCLAiABKQMAIQQgAEEYaiABKQMINwMAIAAgBDcDECAAIAI2AgggACADNwMAIAFBIGokAAtVAQJ/IwBBIGsiAiQAIAJBEGogARDRBCACQQhqIAJBEGpBtPXJABCFAyACKAIIIQMgAEEIaiACLQAMQQFxOgAAIAAgAzYCBCAAIAE2AgAgAkEgaiQAC1YBAn8gASgCACECIAFBADYCAAJAIAIEQCABKAIEIQNBCEEEEKQFIgFFDQEgASADNgIEIAEgAjYCACAAQcyCygA2AgQgACABNgIADwsAC0EIQQQQ3QUAC1YBAn8gASgCACECIAFBADYCAAJAIAIEQCABKAIEIQNBCEEEEKQFIgFFDQEgASADNgIEIAEgAjYCACAAQYCMygA2AgQgACABNgIADwsAC0EIQQQQ3QUAC1QBAX8jAEEgayIDJAAgA0EIaiACQQAQiQMgA0EANgIYIAMgAykDCDcDECADQRBqIAEgAhCuBSAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBIGokAAtbAQF/IwBBIGsiAiQAIAIgARDvASACKAIAQQFGBEAgAiACKQIENwMYQbD3wQBBKyACQRhqQdz3wQBBiPrBABCoAgALIAIgAigCBBCmASAAIAIQ5wQgAkEgaiQAC1MBAX8jAEFAaiIDJAAgA0EgaiABIAIQrAEgA0EIaiADQSBqQaj6wQAQ6wIgAyADQQhqELAEIAAgAygCACADKAIEEJwDIANBCGoQowUgA0FAayQAC1YBAX8jAEEgayICJAAgAkEIakHAAEEAEIkDIAJBADYCGCACIAIpAwg3AxAgAkEQaiABQcAAEK4FIABBCGogAigCGDYCACAAIAIpAxA3AgAgAkEgaiQAC1cBAX8jAEEgayIDJAAgA0EIaiACQQAQiQMgA0EANgIYIAMgAykDCDcDECADQRBqIAEgASACahCgBCAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBIGokAAtxAQJ/QRchAkGghMoAIQMCQAJAAkACQAJAIAFB/wFxQQFrDgQBAgMABAtB3ILKAEEoQeCDygAQuQQAC0ESIQJBjoTKACEDDAILQREhAkH9g8oAIQMMAQtBDSECQfCDygAhAwsgACACNgIEIAAgAzYCAAtZAQF/IwBBEGsiAiQAAkAgASgCAA0AIAIgASgCBCABQQhqKAIAEC8gAigCAA0AIAAgAigCBCACQQhqKAIAEJMDIAJBEGokAA8LQeiQygBBKEHskcoAELoEAAtKAQF/IAAoAghBKGwhASAAKAIAIQADQCABBEAgACgCAARAIAAQgQULIAAoAhQEQCAAQRRqEIEFCyAAQShqIQAgAUFYaiEBDAELCwtWAQJ/IAEoAgAhAiABQQA2AgACQCACBEAgASgCBCEDQQhBBBCkBSIBRQ0BIAEgAzYCBCABIAI2AgAgAEHkpcoANgIEIAAgATYCAA8LAAtBCEEEEN0FAAtgAQF/IwBBEGsiAiQAAkACQAJAAkAgAC0AAEEBaw4CAgABCyACIAFB6/DDAEELEJwEDAILIAIgAUH88MMAQQoQnAQMAQsgAiABQfbwwwBBBhCcBAsgAhCAAiACQRBqJAALTQEBfyMAQRBrIgMkACADIAAgASACEJ4BAkAgAygCAEEBRgRAIANBCGooAgBFDQFBzMbEAEEoQZTHxAAQzgMACyADQRBqJAAPCxDCBQALSgEBfyMAQRBrIgIkACACIAAgARB2AkAgAigCAEEBRgRAIAJBCGooAgBFDQFBpN3JAEEoQezdyQAQzgMACyACQRBqJAAPCxDCBQALQQIBfwF+IwBBEGsiASQAIAFBCGpBIUEAEIkDIAEpAwghAiAAQRBqQQA2AgAgAEIANwIAIAAgAjcCCCABQRBqJAALUQEBfyADEMwDIQQgACACNgIEIAAgATYCACAAQQA2AhQgACADKQIANwIIIABBEGogA0EIaigCADYCACAAIAQgAiABa0EDdiIAIAAgBEsbNgIYC1EBAX8gAxDMAyEEIAAgAjYCBCAAIAE2AgAgAEEANgIUIAAgAykCADcCCCAAQRBqIANBCGooAgA2AgAgACAEIAIgAWtBAnYiACAAIARLGzYCGAtMAQF/IwBBEGsiAyQAIAMgACABIAIQdQJAIAMoAgBBAUYEQCADQQhqKAIARQ0BQaTvyQBBKEGU78kAEM4DAAsgA0EQaiQADwsQwgUAC1cBAX8jAEEwayIBJAAgAUEIaiAAQdcAEKYFIAFBJGpBATYCACABQgE3AhQgAUHw78kANgIQIAEgASkDCDcDKCABIAFBKGo2AiAgAUEQakGY8MkAEKkEAAtXAQF/IwBBMGsiASQAIAFBCGogAEHXABCmBSABQSRqQQE2AgAgAUIBNwIUIAFB7PXJADYCECABIAEpAwg3AyggASABQShqNgIgIAFBEGpB0PbJABCpBAALTAEBfyMAQRBrIgMkACADIAAgASACEHoCQCADKAIAQQFGBEAgA0EIaigCAEUNAUGqicoAQShB8InKABDOAwALIANBEGokAA8LEMIFAAtFAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqEP0CIAAgAikDCDcCACACQSBqJAALSwEBfyMAQTBrIgIkACACQRhqQgA3AwAgAkEgakIANwMAIAJBKGpCADcDACACQgA3AxAgAkIBNwMIIAAgAkEIaiABEFkgAkEwaiQAC18BAX8jAEEgayIBJAAgAUEYakGU3ckANgIAIAFBFGpB2PbIADYCACABQQxqQrzmADcCACABQQE7ARwgAUHY9sgANgIIIAFCgICAgMDnDDcDACAAIAEQtAEgAUEgaiQAC1MBAX8jAEGAAWsiASQAIAEQpwIgAEIANwMAIABBADYCUCAAQQhqQgA3AwAgAEHUAGogAUGAARDyAxogAEEQakHI6MkAQcAAEPIDGiABQYABaiQAC04BAX8jAEEgayIBJAAgAUEQaiAAENEEIAEgAUEQakHk9MkAEIUDIAEgAS0ABDoADCABIAEoAgA2AgggAC0AECABQQhqENIEIAFBIGokAAtDAQN/AkAgAkUNAANAIAAtAAAiAyABLQAAIgRGBEAgAEEBaiEAIAFBAWohASACQX9qIgINAQwCCwsgAyAEayEFCyAFC0sBAX8jAEHQAGsiBiQAIAZBCGogBSADIAQgASACEM8DIAYoAkgiAUHBAE8EQCABQcAAEOUCAAsgACAGQQhqIAEQnAMgBkHQAGokAAtHAQF/IwBBIGsiAiQAIAJBCGogARBbIAAgAikCDDcCACAAQQhqIAJBFGopAgA3AgAgAEEQaiACQRxqKAIANgIAIAJBIGokAAtPAgF/An4jAEEQayIEJAAgBEEIakEAIAMgASACENQDIAQpAwghBSAEIAMgAiABIAIQ1AMgBCkDACEGIAAgBTcCACAAIAY3AgggBEEQaiQAC0oAAn8gAUGAgMQARwRAQQEgACgCGCABIABBHGooAgAoAhARAgANARoLIAJFBEBBAA8LIAAoAhggAiADIABBHGooAgAoAgwRBAALC0IBBH8CQCABKAIAIgIgASgCBE8NACACQQFqIgMgAkkNACABKAIAIQQgASADNgIAQQEhBQsgACAENgIEIAAgBTYCAAtIAQF/IwBBEGsiBiQAIAYgBTYCDCABIAIgA0EAEJUFIAEgBkEMakEEQQEQlQUgASAEIAUQwgIgACABQdABEPIDGiAGQRBqJAALSgAgACABKQAANwAAIABBF2ogAUEXaikAADcAACAAQRBqIAFBEGopAAA3AAAgAEEIaiABQQhqKQAANwAAIAAgAS0AH0H/AHE6AB8LRgEBfyMAQYABayIDJAAgA0EwaiABEIYBIANB2ABqIAIQhgEgA0EIaiADQTBqIANB2ABqEA0gACADQQhqEHEgA0GAAWokAAtKAgJ/An4CfkIAIAEoAgQiAkEISQ0AGiABKAIAIgMpAAAhBCABIAJBeGo2AgQgASADQQhqNgIAQgELIQUgACAENwMIIAAgBTcDAAtIAQN/An9BACABKAIEIgJBBEkNABogASgCACIDKAAAIQQgASACQXxqNgIEIAEgA0EEajYCAEEBCyEBIAAgBDYCBCAAIAE2AgALSgEBfyMAQUBqIgIkACACQQBBwAAQwQQiAkEgIAFBwAFqQSAQsAEgAkEgakEgIAFBoAFqQSAQsAEgACACQcAAEPIDGiACQUBrJAALRgEBfyMAQYABayIDJAAgA0EwaiABEIcBIANB2ABqIAIQhwEgA0EIaiADQTBqIANB2ABqEA4gACADQQhqEHEgA0GAAWokAAtFAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqELoCIAAgAikDCDcCACACQSBqJAALNQAgAQR/QX8gAkF/amd2QQAgAkECTxsiAUEBaiICIAFPBUEACyEBIAAgAjYCBCAAIAE2AgALRgEBfyMAQRBrIgMkACADQQxqIAJBCGooAgA2AgAgAyACKQIANwIEIAMgATYCACAAIAEgA0EEchC/ASAAEPoCIANBEGokAAtHAQN/IwBBEGsiAiQAIAJBCGogAUEEahCqBSACKAIMIQQgAigCCCEDIAAgATYCCCAAIAM2AgAgACADIARqNgIEIAJBEGokAAtCAQR/IAAoAgQgACgCACIBayECA0AgAkUEQEEADwsgACABQQFqIgM2AgAgAkF/aiECIAEsAAAgAyEBQX9KDQALQQELRgEBfyMAQRBrIgMkACADIAEgAhAvIAMoAgQhASADKAIAIQIgACADQQhqKAIANgIEIABBACABIAJBAUYbNgIAIANBEGokAAtDAQF/IwBBEGsiAiQAIAIgACABEOMCIAIgAigCBDYCDCACIAIoAgAiADYCCCAABEAgAkEIahD6AQsgAkEQaiQAIABFCzoBA39BHyEBA0AgAUF/RwRAIAAgAWoiAiADIAItAAAiAkEDdnI6AAAgAUF/aiEBIAJBBXQhAwwBCwsLNgEDfwNAIAFBIEcEQCAAIAFqIgIgAyACLQAAIgJBA3RyOgAAIAFBAWohASACQQV2IQMMAQsLC0YBAn8CQCAALQAQQQVGDQAgACgCCCIBRQ0AIAEgACgCDCgCABEDACAAKAIMIgEoAgQiAkUNACAAKAIIIAIgASgCCBC2BQsLQQAgAEEANgIQIAAgAzYCCCAAIAI2AgQgACABNgIAIABBDGogBDYCACAAIAQgA2siACACIAFrIgEgASAASxs2AhQLQAECfyAAKAIEIgFFBEBBAA8LIAAoAggiAARAIAEgAG4iAiABIAAgAmxrQQBHag8LQcDhyQBBGUGs4ckAEM4DAAs/AQF/IAAgASgCCCIDIAJsIgIgASgCAGo2AgAgACABKAIEIgAgACACIANqIgEgASAASxsgASACSRsgAms2AgQLSAEBfyMAQSBrIgMkACADQRRqQQA2AgAgA0HEqsoANgIQIANCATcCBCADIAE2AhwgAyAANgIYIAMgA0EYajYCACADIAIQvQQAC0MBAX8jAEGgA2siBiQAIAYgASACIAMQvQEgBiAEIAUQcyAGQdABaiAGQdABEPIDGiAAIAZB0AFqENgEIAZBoANqJAALQQECfwJAIAAoAggiAUUNACABIABBDGoiASgCACgCABEDACABKAIAIgEoAgQiAkUNACAAKAIIIAIgASgCCBC2BQsLOgEBfyMAQRBrIgAkAEHk+coAKAIAQQNHBEAgAEEBOgALIAAgAEELajYCDCAAQQxqED4LIABBEGokAAtFAQF/IwBBEGsiBSQAIAUgBDYCDCAAIAEgAkEAEJUFIAAgBUEMakEEQQEQlQUgAEECQQAQRCAAIAMgBBDBAiAFQRBqJAALPQEBfyMAQRBrIgUkACAFIAQ2AgwgACABIAJBABCVBSAAIAVBDGpBBEEBEJUFIAAgAyAEEPsBIAVBEGokAAs4AAJAIAIgAU8EQCAEIAJPDQEgAiAEEOUCAAsgASACEOYCAAsgACACIAFrNgIEIAAgASADajYCAAs4AQF/IwBBMGsiAyQAIANBCGogAUEoEPIDGiADQQhqIAIQ5QMgACADQQhqQSgQ8gMaIANBMGokAAs8ACAAIAEpAAA3AAAgAEEYaiABQRhqKQAANwAAIABBEGogAUEQaikAADcAACAAQQhqIAFBCGopAAA3AAALPQEBfyMAQRBrIgIkACACIAFB0brGAEEOEJwEIAIgADYCDCACIAJBDGpB4LrGABCOASACEIACIAJBEGokAAtFAQJ/IwBBEGsiASQAQbyOygAoAgARCAAiAEUEQEGIk8oAQcYAIAFBCGpBqJTKAEGYlMoAEKgCAAsgAC0AACABQRBqJAALNgEBfyMAQTBrIgIkACACQQhqIAFBKBDyAxogAkEIahCCAiAAIAJBCGpBKBDyAxogAkEwaiQACz4BAX8jAEHgAWsiAyQAIAMQwwIgAyABIAIQjQEgA0HwAGogA0HwABDyAxogACADQfAAahDuAiADQeABaiQACzsBAn8jAEEQayICJAAgAkEIaiABEKoFIAIoAgwhASAAIAIoAggiAzYCACAAIAEgA2o2AgQgAkEQaiQACzkBAX4CQCAAKQMIIgJCAVMNACAAKAKcIEEASA0AIAAgAkJAfDcDCCAAQRBqIAEQEQ8LIAAgARDbAQs4AQF/IwBBEGsiAyQAIANBADYCDCADIAIgA0EMahCqASAAIAEgAygCACADKAIEEPsCIANBEGokAAs5AQF/IwBBEGsiAiQAIAJBADYCDCACQcUAIAJBDGoQqgEgACABIAIoAgAgAigCBBDvAiACQRBqJAALSAACQCAALQAEDQBBiPrKACgCAEEBRwRAQYj6ygBCATcDAAwBC0GM+soAKAIARQ0AIAAoAgBBAToABAsgACgCACgCAEEAOgAAC2MBA38jAEEQayIBJAAgACgCDCICRQRAQZicygBBK0GMpcoAEM4DAAsgACgCCCIDRQRAQZicygBBK0GcpcoAEM4DAAsgAUEANgIEIAEgAzYCACABQaylygAgACgCCCACEMABAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQbCCwABBLkH8gsAAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQdyFwABBLkGohsAAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQaD5wQBBLkHs+cEAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQaz7wQBBLkH4+8EAEM4DAAswAQJ/A0AgAkEoRwRAIAAgAmoiAyADKQMAIAEgAmopAwB8NwMAIAJBCGohAgwBCwsLOQEBfyMAQRBrIgQkACAEQQhqIANBCGooAgA2AgAgBCADKQIANwMAIAAgASACIAQQqgMgBEEQaiQACzkBAX8jAEEQayIEJAAgBEEIaiADQQhqKAIANgIAIAQgAykCADcDACAAIAEgAiAEEKkDIARBEGokAAs+AQF/IwBBEGsiASQAIAEQkQMgAUEIakIBNwIAIABBADoAECAAIAEpAwA3AgAgACABKQMINwIIIAFBEGokAAtOAQN/IwBBEGsiASQAIAFBCGoiAiAAKAIEIgNBGGw2AgAgAiADQQBHQQJ0NgIEIAEoAgwiAgRAIAAoAgAgASgCCCACELYFCyABQRBqJAALMwECfxCbBCECAn9BACABLQAERQ0AGkEBCyEDIAAgATYCBCAAIAM2AgAgAEEIaiACOgAACzoBAX8gABCaBSAALQAEIgFBAkcEQAJAIAENACAAKAIAEJsERQ0AQQE6AAQLIAAoAgAoAgBBADoAAAsLOQEBfyMAQRBrIgMkACADIAI2AgwgAyABNgIIIAAgA0EIaigCADYCACAAIAMoAgw2AgQgA0EQaiQACzQAIAEoAgAEQCABQQhqIAFBB2otAAAQigQLIAAgASkCCDcCACAAQQhqIAFBEGooAgA2AgALMgEBfyMAQUBqIgIkACABEIEBIAIQpgIgAUEQaiACEHAgACACQcAAEPIDGiACQUBrJAALQgECfyMAQRBrIgAkAEHE9ckAKAIAEQgAIgFFBEBB4PbJAEHGACAAQQhqQYD4yQBB8PfJABCoAgALIABBEGokACABCzYBAn4gASkAACEDIAAgAUEIaikAAEIBhCICNwMIIAAgAiADfEKt/tXk1IX9qNgAfiACfDcDAAs1AQF/IwBBEGsiAiQAIAJBCGogACgCACAAKAIEEKYFIAIoAgggAigCDCABELsBIAJBEGokAAszAQF/IAIEQCAAIQMDQCADIAEtAAA6AAAgA0EBaiEDIAFBAWohASACQX9qIgINAAsLIAALLQEBfyADIAIQ3QEiBARAIAQgACADIAEgASADSxsQ8gMaIAAgASACEN4BCyAECzoBAX8jAEFAaiIDJAAgAUHY8MMAQQcgA0EAQcAAEMEEIgFBwAAgAkEBEIoFIAAgARDDBCABQUBrJAALNgEBfyMAQdABayIDJAAgAxDrASADQfjywwBBByABIAIQ0gMgACADQdABEPIDGiADQdABaiQACzIBAX8jAEEQayIDJAAgAyACNgIMIAAgA0EMakEEQQAQlQUgACABIAIQ+wEgA0EQaiQACy0BAX8jAEFAaiICJAAgAiAAEEMgAkEgaiABEEMgAiACQSBqEIgDIAJBQGskAAszAQF/IAJBAXYhAyACQQ9NBEAgACABIANBoAFsakGgARDyAxoPC0GsvsQAIANBCBDkAgALOAEBfyABQQF2IQIgAUH/AE0EQCAAIAJB+ABsQdj8wwBqQfgAEPIDGg8LQby+xAAgAkHAABDkAgALMwEBfyACQQF2IQMgAkEPTQRAIAAgASADQaABbGpBoAEQ8gMaDwtBhPDIACADQQgQ5AIACzgBAX8gAUEBdiECIAFB/wBNBEAgACACQfgAbEGAr8gAakH4ABDyAxoPC0GU8MgAIAJBwAAQ5AIACzgBAX8gASgCCCIDIAJB//8DcSICTQRAQbj0yAAgAiADEOQCAAsgACABKAIAIAJBA3RqKQIANwIACzcCAX8BfiMAQRBrIgIkACACQQhqIAFBABCJAyACKQMIIQMgAEEANgIIIAAgAzcCACACQRBqJAALMgECfyAAKAIAIgEoAgRB8ABsIgIEfyABKAIAIAJBCBC2BSAAKAIABSABC0EQQQQQtgULNQEBfyAALQAIIgFBAkcEQAJAIAENACAAKAIEEJsERQ0AQQE6AAQLIAAoAgQoAgBBADoAAAsLMgEBfyAAKAIIQQxsIQEgACgCACEAA0AgAQRAIAFBdGohASAAELUEIABBDGohAAwBCwsLNgEBfyABIAIoAgAiBBCoBCABKAIAEMAFIABBCGogAzoAACAAIAI2AgQgACACLQAEQQBHNgIACysAAkAgAEF8Sw0AIABFBEBBBA8LIAAgAEF9SUECdBCkBSIARQ0AIAAPCwALLwAgAyABIAQgAkECdCIBIAEgBEsbIgEQ8gMaIAAgATYCBCAAIAFBA2pBAnY2AgALNQEBf0EBQQEQpAUiAUUEQEEBQQEQ3QUACyABQQA6AAAgAEEAOgAFIABBADoABCAAIAE2AgALMwEBfyABKAIIIgMgAkkEQCACIAMQ5gIACyAAIAMgAms2AgQgACABKAIAIAJBGGxqNgIACzAAIAAoAghBAUYEfyAAKAIAIgBBgonKAEYEQEEBDwsgAEGCicoAQQEQtANFBUEACwtJAQN/IwBBEGsiAiQAIAEiAygCCCIEIAEoAgRHBEAgAyAEENQCCyACQQhqIAEoAgAgASgCBBDsAyAAIAIpAwg3AgAgAkEQaiQACzUBAX8jAEHAAmsiAyQAIANBoAFqIAIQiQIgAyABIANBoAFqEJIBIAAgAxCDAiADQcACaiQACzABAX8gACgCACIBIAAoAgRHBEAgACABQQFqNgIAIAAgACgCCEEBajYCCCABDwtBAAs0ACAAKAIIIAAoAgRGBEAgAEEBEL4FCyAAKAIAIAAoAghqIAE6AAAgACAAKAIIQQFqNgIICzABAX8jAEEQayICJAAgACgCCCABTwRAIAJBCGogABCbBSAAIAE2AggLIAJBEGokAAs4AQF/IAFBBGohBAJAIAEoAgBBAUYEQCAEKAIAIAIgAxAJDAELIAQoAgAgAiADEAoLIABBBToAEAszAQF/IwBBEGsiBCQAIARBCGogASACIAMoAgAgAygCCBAwIAAgBCkDCDcCACAEQRBqJAALMwAjAEEQayIAJAAgABD/ASAAIAAtAAQ6AAwgACAAKAIANgIIIABBCGoQ6wMgAEEQaiQACzoBAX9BvI7KACgCABEIACIARQRAQQEPCyAALQAABEAgAEEAOgAAQQAPC0G4lMoAQRxBrJXKABC6BAALMwEBfyMAQUBqIgQkACABIAIgAyAEQQBBwAAQwQQiAUHAABDTAyAAIAEQwwQgAUFAayQACzQAIAAoAgAhACABELQFRQRAIAEQtQVFBEAgADEAACABEHcPCyAAIAEQ8QEPCyAAIAEQ8AELMgAgACgCACEAIAEQtAVFBEAgARC1BUUEQCAAIAEQwwUPCyAAIAEQ9gEPCyAAIAEQ9QELLQEBfyMAQeABayICJAAgAkEIaiAAQdgBEPIDGiACQQhqIAEQeyACQeABaiQACy8BAX8jAEFAaiIEJAAgBCABQcABahBgIAAgBCACIAMgARBfIAQQoAIgBEFAayQACyYAAn9BAyAAKAIAIgBBAXENABpBAiAAQQRxDQAaIABBAXZBAXELCy4AIAAgBxD/BCACIAV8fCABEIAFfDcDCCAAIAYQ/wQgASAEfHwgAxCABXw3AwALLAAgAC0AEEECRwRAQZzYygBBnNjKACgCAEF/ajYCACAAKAIAQQFBARC2BQsLLgEBfwJAIAAoAgAiAUEBR0EAIAFBfmpBA0kbDQAgACgCBCIAQSRJDQAgABAACws0AQF/IwBBEGsiASQAIAAEQEGIk8oAQcYAIAFBCGpBqJTKAEGYlMoAEKgCAAsgAUEQaiQACysAIwBBEGsiACQAIABBCGogAUG8nsoAQQsQvwQgAEEIahCxAiAAQRBqJAALOgEBfwJAQYj6ygAoAgBBAUYEQEGM+soAKAIAIQAMAQtBiPrKAEIBNwMAC0GM+soAIAA2AgAgAEEARws0ACAAIAEoAhggAiADIAFBHGooAgAoAgwRBAA6AAggACABNgIAIAAgA0U6AAkgAEEANgIECy4BAX8jAEEQayIEJAAgBEEIaiADIAIgASACENQDIAAgBCkDCDcCACAEQRBqJAALLgEBfyMAQRBrIgQkACAEQQhqQQAgAyABIAIQ1AMgACAEKQMINwIAIARBEGokAAsvAQF/IwBBEGsiAiQAIAJBCGogAUEgIAEoAiAQngQgACACKQMINwIAIAJBEGokAAs1AQF/IAAgACgCCCACIAFrIgIQpgMgACAAKAIIIgMgAmo2AgggAyAAKAIAaiACIAEgAhCvAQsuAQF/IwBB4AFrIgIkACACQQhqIAFB2AEQ8gMaIAAgAkEIahDuAyACQeABaiQACyoBAX8jAEEQayIDJAAgA0EIaiABIAIQrwQgACADKQMINwIAIANBEGokAAskAAJAIAEgA0YEfyAAIAJHDQFBAQVBAAsPCyAAIAIgARC0A0ULMAEBfyMAQRBrIgMkACADQQhqIAEoAgAoAgAgAhD8AyAAIAMpAwg3AgAgA0EQaiQACywCAX8BfiMAQRBrIgEkACABQQA2AgwgACABQQxqEKcFIAE1AgwgAUEQaiQACykAIABBJGotAABBAkYEQCAAKAIAIAAoAgQgARDOAQ8LIABBCGogARAYCzABAX8gACACIAFrIgIQvgUgACAAKAIIIgMgAmo2AgggAyAAKAIAaiACIAEgAhCzAQswACAAIAAoAgQiACABIAAbNgIEIABFIAAgAUZyRQRAQfihygBBNkHIosoAELwEAAsLNQEBfyMAQRBrIgIkACACIAE2AgwgAiAANgIIIAJB7JvKADYCBCACQeybygA2AgAgAhDgAwALLAAgACABKQIANwIAIABBEGogAUEQaikCADcCACAAQQhqIAFBCGopAgA3AgALKgEBfyMAQTBrIgIkACACQQhqIAAQ2QMgACACQQhqIAEQiAIgAkEwaiQACysAIAAgASACEIgCIABBKGogAUEoaiACEIgCIABB0ABqIAFB0ABqIAIQiAILLQEBfyMAQRBrIgMkACADIAE2AgwgAyAANgIIIANBCGpBqMbEAEEAIAIQwAEACywBAX8jAEEQayICJAAgAkEIaiABENAFIAAgAigCCCACKAIMEH4gAkEQaiQACyEAIAJBIE8EQCAAQSA2AgQgACABNgIADwtBICACEOUCAAsrAQF/IwBBEGsiAiQAIAJBCGogAUEMahCbBSAAIAIpAwg3AgAgAkEQaiQACywBAX8jAEEQayICJAAgAkEIaiABEKoFIAAgAigCCCACKAIMEH4gAkEQaiQACywBAX8jAEEQayICJAAgAkEIaiABEKkFIAAgAigCCCACKAIMEH4gAkEQaiQACy0BAX8jAEEQayICJAAgAkEIaiABENsDIAAgAigCCCACKAIMENEBIAJBEGokAAstAQF/IwBBEGsiAyQAIAMgATYCDCADIAA2AgggA0EIakGI6ckAQQAgAhDAAQALLgEBfwJAIABBCGotAAANACAAKAIEEJsERQ0AQQE6AAQLIAAoAgQoAgBBADoAAAsuAQF/IwBBEGsiAiQAIAJBADYCCCACIAE2AgQgAiAANgIAIAIQ1AUgAkEQaiQACygBAX8Cf0EAIAEoAgARCAAiAQ0AGkEBCyECIAAgATYCBCAAIAI2AgALLAAgACABKQIANwIAIABBEGogAUEQaigCADYCACAAQQhqIAFBCGopAgA3AgALLQEBfyMAQRBrIgMkACADIAE2AgwgAyAANgIIIANBCGpBuILKAEEAIAIQwAEACy0BAX8jAEEQayIDJAAgAyABNgIMIAMgADYCCCADQQhqQeyLygBBACACEMABAAsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQ/QEgAkEQaiQACy0BAX8jAEEQayIDJAAgAyABNgIMIAMgADYCCCADQQhqQdClygBBACACEMABAAs1AQF/IwBBEGsiAiQAIAIgATYCDCACIAA2AgggAkGwq8oANgIEIAJBxKrKADYCACACEOADAAsyAQF/QQEhASAALQAEBH8gAQUgACgCACIAKAIYQbSsygBBASAAQRxqKAIAKAIMEQQACwswACABKAIYIAIgAyABQRxqKAIAKAIMEQQAIQIgAEEAOgAFIAAgAjoABCAAIAE2AgALNQEBfyABKAIYQbOsygBBASABQRxqKAIAKAIMEQQAIQIgAEEAOgAFIAAgAjoABCAAIAE2AgALKQEBfyACBEAgACEDA0AgAyABOgAAIANBAWohAyACQX9qIgINAAsLIAALJQEBfyMAQSBrIgEkACABIAAQQyABLQAAQQFxEJYFIAFBIGokAAsmAQF/IwBBMGsiAiQAIAJBCGogARBNIAAgAkEIahBxIAJBMGokAAspACACQYEBTwRAIAJBgAEQ5gIACyAAQYABIAJrNgIEIAAgASACajYCAAsmAQF/IwBBMGsiAiQAIAJBCGogARBOIAAgAkEIahBxIAJBMGokAAsmACACIANJBEAgAyACEOYCAAsgACACIANrNgIEIAAgASADajYCAAshACAAEJUEQf8BcUEDRgR/IABBBGpBACAAKAIEGwVBAAsLJgECfyMAQRBrIgAkACAAQZj6ygA2AgwgAEEMahDXAiAAQRBqJAALJgECfyMAQRBrIgAkACAAQaz6ygA2AgwgAEEMahDWAiAAQRBqJAALKwEBfyAAIAEoAgQiAjYCBCAAIAEoAgAgAigCCCIAQRdqQQAgAGtxajYCAAsnACAAQgA3AAAgAEEYakIANwAAIABBEGpCADcAACAAQQhqQgA3AAALJQEBfyABBH8gARDSBSECQQEFQQALIQEgACACNgIEIAAgATYCAAsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQkwIgAkEQaiQACygBAX8jAEEQayICJAAgAiAAKAIANgIMIAJBDGogARCWASACQRBqJAALKAEBfyMAQRBrIgIkACACQQhqIAEQmwUgACACKQMINwIAIAJBEGokAAsnAQF/IAAgACgCACIBQX9qNgIAIAFBAnEgAUEESXJFBEAgABCUAQsLLwEBfyABKAIAIgItAAAEQEGc8skAQSBBgPPJABC5BAALIAJBAToAACAAIAEQ6QQLKwEBfwJAIAAtAAQNACAAKAIAEJsERQ0AQQE6AAQLIAAoAgAoAgBBADoAAAsvAQF/IAEoAgAiAi0AAARAQciGygBBIEGsh8oAELoEAAsgAkEBOgAAIAAgARDqAwsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQ0QIgAkEQaiQACy8BAX8gASgCACICLQAABEBBk5LKAEEgQfiSygAQugQACyACQQE6AAAgACABEOkECyEBAX8jAEEgayIBJAAgASAAEBQgACABEJ8FIAFBIGokAAsiACABLQAAIAAtAABzIgBBACAAa3JBf3NBgAFxQQd2EJYFCycBAX8jAEHQAWsiAiQAIAAgAiABQdABEPIDIgAQuQEgAEHQAWokAAshAQF/IwBBIGsiASQAIAEgABAVIAAgARCfBSABQSBqJAALIgEBfyMAQSBrIgIkACACIAAgARDaAyACLQAAIAJBIGokAAspAQF/IwBB8ABrIgMkACAAIAMgAUHwABDyAyIAIAIQ8wIgAEHwAGokAAsgAAJAIAFBfEsNACAAIAFBBCACEJQFIgBFDQAgAA8LAAsnAQF/AkAgACgCBCIBRQ0AIABBCGooAgAiAEUNACABIABBARC2BQsLNgEBfyMAQUBqIgIkACAAIAIgAUHAABDyAyIBIgIQ4AQgAEHAAWogAkHAABDyAxogAUFAayQACyEBAX8jAEFAaiICJAAgAiABED8gACACEN4EIAJBQGskAAspAQF/IwBBoAFrIgIkACACIAFBqP/BABDJBSAAIAIQ4QQgAkGgAWokAAsnAQF/IwBBoAFrIgIkACAAIAIgAUGgARDyAyIAEIMDIABBoAFqJAALIAAgAUEETQRAIAAgAUEDdGoPC0HsusQAIAFBBRDkAgALIAAgAUEETQRAIAAgAUEDdGoPC0H8usQAIAFBBRDkAgALJQAgAyABTQRAIAAgAiADEPIDGg8LQdjDxABBKUHcxMQAEK0EAAsgACABQQRNBEAgACABQQN0ag8LQcTsyAAgAUEFEOQCAAsgACABQQRNBEAgACABQQN0ag8LQdTsyAAgAUEFEOQCAAskACAAIAEpAgA3AgAgAEEIaiABQQhqKAIANgIAIAFBDGoQgQULGQAgAC0AEEECRwRAIAAoAgBBAUEBELYFCwsnAQF/EJsEIQIgACABNgIEIABBCGogAjoAACAAIAEtAARBAEc2AgALJQEBfyABKAIAIgJFBEAgAEEDOgAkDwsgACACIAFBCGooAgAQeQsjACAAQQA2AgwgACABKQIANwIAIABBCGogAUEIaigCADYCAAsoAQF/IAAoAgghASAAQYGAxAA2AgggAUGBgMQARgR/IAAQkAEFIAELCx0AIAFBH00EQCAAIAFqDwtBjL3EACABQSAQ5AIACx0AIAFBH00EQCAAIAFqDwtB5O7IACABQSAQ5AIACyYBAX8gACgCACIBKAIAIAEoAgQgACgCBCgCACAAKAIIKAIAECkACx0AIAAgASgCACIBIAJqIgI2AgQgACACIAFPNgIACx4BAX8gACAAKAIAIgFBASABGzYCACABBEAgABBWCwseAQF/IAAoAgAiACgCACAAQQA2AgAoAgAoAgBBDEYLFAAgACgCAEEAOgAQIABBBGoQ0gQLHQEBfyAAKAIEIgEEQCAAKAIAIAFBKGxBBBC2BQsLHQEBfyAAQQRqKAIAIgEEQCAAKAIAIAFBARC2BQsLHQEBfyAAQQhqKAIAIgEEQCAAKAIEIAFBARC2BQsLHQAgASgCAEUEQAALIABBvMbEADYCBCAAIAE2AgALHAAgACABKQIANwIAIABBCGogAUEIaikCADcCAAscACAAIAEpAgA3AgAgAEEIaiABQQhqKAIANgIACx0AIAEoAgBFBEAACyAAQZzpyQA2AgQgACABNgIACx0AIAEoAgBFBEAACyAAQcyCygA2AgQgACABNgIACx4AIABBADYCCCAAIAI2AgQgACABNgIAIABBADoAEAsdACABKAIARQRAAAsgAEGAjMoANgIEIAAgATYCAAsdACAALQAAQQFGBEBByPTIAEEcQYT1yAAQzgMACwsTACAAQgaIIABCA4mFIABCLYmFCxMAIABCB4ggAEI4iYUgAEI/iYULGgEBfyAAKAIEIgEEQCAAKAIAIAFBARC2BQsLHQAgASgCAEUEQAALIABB5KXKADYCBCAAIAE2AgALGwAgAKdFBEBBjMbEAEEZQfzFxAAQjgMACyABCw4AIAAoAgBBAUEBELYFCx8AQZD7ygAtAABBAkYEQEGQ+8oAQQA6AAALQZD7ygALHAAgASgCGEHQqsoAQQsgAUEcaigCACgCDBEEAAscACABKAIYQduqygBBDiABQRxqKAIAKAIMEQQACxkAIAAoAhggASACIABBHGooAgAoAgwRBAALHAAgASgCGEG5wcoAQQUgAUEcaigCACgCDBEEAAsWACAAIAEgAiADIAQgBSAGEO8DENcBCxcAIABBADYCCCAAIAI2AgQgACABNgIACxMAIAAoAgQiAEEkTwRAIAAQAAsLEwAgACgCACIAQSRPBEAgABAACwsXACAAQQA2AgggAEEANgIEIABBATYCAAsZACAAKAIAIgAoAgAgASAAKAIEKAIkEQIACxkAIAAoAgAiACgCACABIAAoAgQoAiARAgALGQAgACgCACIAKAIAIAEgACgCBCgCMBECAAsPACAAKAIABEAgABCBBQsLGQAgACgCACAAKAIEIAEoAgAgASgCBBCjBAsNACAAIAEgAiADEPMDCxMAIABBEiADEEQgACABIAIQwQILFQEBfyMAQRBrIgEgADoADyABLQAPCxUAIAAQ6AMgAEEANgIcIABCADcCFAsSACAALQAQQQVHBEAgABDQAwsLEAAgAQRAIAAgAUEEELYFCwsTACAALQAEQQJHBEAQjwQQmQQLCxYAIAAgASgCCDYCBCAAIAEoAgA2AgALEAAgACABIAIgAyAEIAUQLAsQACAAIAEgAiADIAQgBRAdCw8AIAAgASACIANBIBDSAwsQACAAIAEQjANB/wFxQQFGCw0AIAAoAgAQhgRBAXMLFAAgACgCACABIAAoAgQoAgwRAgALFAAgAEHAAWoQnwEgAEHAAWoQnwELDwAgABCBBSAAQQxqEIEFCwkAIAAgARDdAQsVACAAQa/+wQBBCkHG8MMAQQsQ0gMLEAAgACACNgIEIAAgATYCAAsRACAAKAIAIAAoAgQgARDJAQsTACAAQRc2AgQgAEH83ckANgIACxEAIABBwAA2AgQgACABNgIACxEAIABBgAE2AgQgACABNgIACxwAIAAoAgBBADoAAEGw7MkAQShB2OzJABC5BAALDwAgACgCACABKAIAEAJFCxEAIAAoAgAgACgCBCABEN8FCw4AIAAgASABIAJqEKcECxEAIAAoAgAgACgCCCABEN8FCxAAIAAoAgAgACgCCCABECgLEAAgASAAKAIAIAAoAgQQLgsRACAAQbcBNgIEIAAgATYCAAsNACAALQAAQQRxQQJ2Cw0AIAAtAABBEHFBBHYLDQAgAC0AAEEgcUEFdgsLACAAIAEgAhDeAQsNACAAQQBByAEQwQQaCw4AIAAQJyAAQQA2AsgBCw0AIAAgAUHAABDyAxoLDgAgACgCACgCACABEAwLDgAgACgCACgCACABEBALDgAgACgCACABIAIQ6AELDAAgACgCABABQQFGCw4AIAAgACgCCCABEK4DCw0AIAAgASACIAMQowQLEgBBi6fKAEEdQcinygAQvAQACw0AIAAoAgAgARBCQQALEgBBo6rKAEERQbSqygAQzgMACwsAIAA1AgAgARB3Cw0AIAAoAgAgASACEEYLKQACfyAAKAIALQAARQRAIAFB2K7KAEEFEC4MAQsgAUHUrsoAQQQQLgsLCgAgACABQSAQfgsMACAAKAIAIAEQpQMLCgAgACABQQEQKgsKACAAIAIgARBcCxUAIAAoAgAiACgCACAAKAIEIAEQKAsLACAAKAIAIAEQcgsKACAAKAIAIAFqCwoAIAAgAiABEF0LDAAgACgCACABEMMFCwwAIAAoAgAgARCNAgsMACAAIAEpAgA3AgALCgAgACABIAIQfgsIACAAaEEDdgsMACAAKAIAQQA6AAALIgEBfyAAEIAEIAAoAgQiAQRAIAAoAgAgAUEMbEEEELYFCwsNAEGQ88kAQRkgARAoCwwAIAAoAgAgARDQAgsMACAAIAEpAgg3AgALDAAgACgCACABEJIDCxwAAn9BACAAKAIAEOUBIgBFDQAaIAAgARCIAQsLDQBBkYnKAEEZIAEQKAsNAEHQjsoAQRkgARAoCw0AQdykygBBGSABECgLGgAgACABQej5ygAoAgAiAEGTASAAGxEAAAALDAAgACgCACABEJUBCwoAIAIgACABEC4LCQAgACABEMcDCwgAIABBoAFqCwkAIAAgARCOAgsJACAAQQA2AgALCQAgACABELMECxkAQdj6ygAtAABBAkYEfxCwAgVByPrKAAsLGQBBgPvKAC0AAEECRgR/EMQBBUHw+soACwscAAJ/QajYygApAwBCAVIEQBB0DAELQbDYygALCwcAIAAQogILCQAgACABELsECwkAIABBADYCAAsGABDCBQALBgAgABBJCwcAIAAQlwULBwAgABDSBAsSAEGMpsoAQS5B2KbKABC8BAALBAAgAQsEAEEACwUAQYAECwQAQQELDABC5K7ChZebpYgRCwwAQrOPmIHv8ID7VwsHAEGY+coACw0AQp2ezqyTrKLEgH8LDQBCxfbN6sGgwvaHfwsNAELl0Iz4nPvoupx/CwwAQpv/8avd9Y2acQsDAAALAwABCwMAAQsLos4KLABBgIDAAAuTvARNaW5pU2VjcmV0S2V5QW5hbG9nb3VzIHRvIGVkMjU1MTkgc2VjcmV0IGtleSBhcyAzMiBieXRlcywgc2VlIFJGQzgwMzIuUHVibGljS2V5QSBSaXN0cmV0dG8gU2Nobm9yciBwdWJsaWMga2V5IHJlcHJlc2VudGVkIGFzIGEgMzItYnl0ZSBSaXN0cmV0dG8gY29tcHJlc3NlZCBwb2ludFNlY3JldEtleUFuIGVkMjU1MTktbGlrZSBleHBhbmRlZCBzZWNyZXQga2V5IGFzIDY0IGJ5dGVzLCBhcyBzcGVjaWZpZWQgaW4gUkZDODAzMi5jYWxsZWQgYFJlc3VsdDo6dW53cmFwKClgIG9uIGFuIGBFcnJgIHZhbHVlAAABAAAAGAAAAAQAAAACAAAAYXNzZXJ0aW9uIGZhaWxlZDogc2VsZi5uZXh0IDwgR0xPQkFMX1NUQUNLX0NBUDw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPl4BEAAeAAAAAgAAAAIAAABzcmMvc3IyNTUxOS5ycwAAjAEQAA4AAAAkAAAABQAAAAMAAAAEAAAABAAAAAQAAACMARAADgAAADUAAAAFAAAAjAEQAA4AAABEAAAABQAAAIwBEAAOAAAAUwAAAAUAAACMARAADgAAAHMAAAAFAAAAc3Vic3RyYXRlAAAAjAEQAA4AAAB1AAAALQAAAIwBEAAOAAAAggAAABoAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvaG1hYy0wLjcuMC9zcmMvbGliLnJzAAAoAhAAUgAAAHYAAAARAAAAKAIQAFIAAAB3AAAAEQAAACgCEABSAAAAgQAAACgAAAAoAhAAUgAAAIEAAAARAAAAKAIQAFIAAACCAAAAHgAAACgCEABSAAAAggAAABEAAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLm5leHQgPCBHTE9CQUxfU1RBQ0tfQ0FQPDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+CgMQAB4AAAACAAAAAgAAAAUAAAAEAAAABAAAAAYAAABTY2hub3JyUmlzdHJldHRvSERLRHNpZ24tYnl0ZXNIREtELW5vbmNlY2hhaW4tY29kZXB1YmxpYy1rZXlIREtELXNjYWxhckhES0QtY2hhaW5jb2Rlc2VjcmV0LWtleUhES0QtaGFyZHI7jPXGkwwA9iXDgXHfCAC2TD4LC/UIADFMpIWTMgUASz2j0/l8CAA+kUDXBTkAAKJz1hcougAAfOb0Jyg+AgA0GsLg0jMBAIGPKfnSTwQAaKp6hwUSAQB51ZNYlXkEAKBnmzBmDQUA7uW+DS3UAgDG8Im2F/EGANdxPJP85wwAQ7K2/kHPAgB2Gn0KHFgHAPAyTVMtFwcA0of6Y8CQBQCo1bRCYKUBAFPRnhXMiQEABK48qt64BQDYtRFP8KoCAJKcZlpZuwYAX3qbpbOoAgB/CO9Zs6sDAK8F28So9QQABULQB6i5BQBQ6hNbrwEHADCX7kyosAUA5FVxyRAdBgAQagnInAUEAE8BqI1gegwADqi54WShBwBl0vyk6B8BAMyqTze4vAcAT03v9FovBQAQjfmYQDEFAL1VdViRqwIAidjQDT+TBgCVQky7hkMEAIxQYjFtywMAxqJyuGhjAgCbK/FqgqIFAJ8J/I65UQMADgWnpL+PBgAbl52VSSoEAP2eRhrlkwMAWB4yEOmABgC/GGgFCgUGAL8yVR/MKgYAJfrJzEGBAgCD5nH0YU0CAFpEx/QzeQIACf92xOn7AwBCSy6Ya68AAOV4ulESrQAAiHzu7a4VBwBTNfbL0PkHACC7pQhEvAIAQlSg3et4CAAiQTUSsf8KACyG9Y3udQsAH24Uz1yUCgC61kekw4IBAPLvNuVkKQIAUwBUH4KSAQBcjnie8fkCALWxPuenVAEAhYIqgfHbAwCXlz+6F/oAACA4nLSc9gYAjYWzDVpNAwC7s5bmqzoEADFxFXfr7gQAQQfxFRkgAQBWnGzanGYJAGw02zLAXgQAwyxqu1ceBQCkjH17tgYAADMp50T6hAAAim9d5U4VAQCQcy6EXUIEABfkGsRkiwMAcUvqAmcyBAC1MGA3NGgAAIDD+RIF7wAAhCVR8qnxAADW8KmRjgsBAL+jTpTQXAoAYk0auHNWBwDUwNEluVAJABNBKdk4PwkAyIOSpr5hBACxITKqmiwHAE33dER3ZwIAhYCy6bBkAADJJzv1TvADADHl0tXt1gEAorO4AchtAwAwXpPUp+AAAH0NzM633gEALN0gTqlTAAD5oMax+6kHAHw+3QRmWQ8ANYsFDlH8DgAMzLKNDGcDAC8zzpnYlwIAzhsGdl6RCADZNJLz7V0HAFQ8H6s2HAAA2vVY7o/wAAA31qATluEAAOAgE0oCqQMAGpGiydn1AQD4/PqUeREHAMWN4sqo2AIAhwwJsrFKBwDE7MLFB2kCAB2cL2MO3QQA2aUiJtHOCgDZQkdh6Y0JANO122+pnAcA7gCa1DfdBgBeUapJVGMDAKtdR9B44QMAEpehEkcLBQCt9A+GwtwCADE98NZ2DQMAx+QGIRdEBACILe2vURIAAFpP7Zv8NAUANFLPOVrYBQBk6BJxaQwBAPLHWIOgKgYAlOFICERvBAAr9ahxt0cEAB3TaTK6dwMAgFD1uvk7CADeX759J8QDAJJM1K81owUAPnWZQBbBAAAj5G8AhwQHAG/WvsphXgIABGZYzCjhAwDix48ui5YFAM9hvdWjSQAA5vYeW1AWAQBuWDSG12YFAL0vWsaFQg0AH3T4zGJeBQBEkLFhuWsMADggcQU0FQkAOnk0X7pPCQA0CMGcn6QHAMYiingTtQIAWznybkv/BQC/B/ZajuwCAMPspbx1OQMA1PeFaRZGBwCa5woAOZkAAHr5ZHlMhAUAPVv54Rc2AQDFP6jOKUgBAKXscU4vCwcAPGT8jhQoBwB2W5kDPnUIAGZnq7Jfvw0A1jVFvMNfCADCld2XhHsDAOj/tNZJFQYAONGxLaIXAgCesC4Gz7kAAFj35XGc/QIA3d6vUq6zAACX5Blmp50BAI5V0lQG+gYA1EFe0hmCBwBRxnV0dnMDAJBlJBTLlQgAZ6ymKtgCCABQSLyD8UIMAEMGChxPRgYABwlzBVm/BgDZrdFA/ZkCAPflBJre8gUAWRzMuu7ABwAKKfixocwEAI+xw1bq+wEAiltB4fF4BwD0we90WPcGAH8CGUBpigIATdxrqTcrBQA1pmfPISUAANFeL3cgZwQAItZZ88AyBgBS4qMrCbICAIAmEXwlYg4A1XyfPXUBCACUUp0KC+4HACfKTOv7gQMAnWM+Oh+EBwBfRMMw6nYGAIIT56cA+gMANNs9li0jAQCNBwvnklYDAB96dxTKRwIA0Pzoa1XbBgCOBPriXysBAJIeb60mfAsA5HsicQlqBABMmy0NL3IEADrgTiBG3AMAbHkgPOn3BgBN4/yWxPsAAD6ufWu+dQUACebOhRWjBAD/MDkC6TcAABL7lm+3SQcABa6mrgT2AgDrI5OT3DcGAEeNBJut/QMA91oE1LCoAAACHvAQ7PwAAEVOJMSd0gIAvkfBG3uSBgA5CKw0hTAIAEA/A2Q2hQQAq/5mkXcTBABEHv5JplgFAInM7641RgQAuvKHSEP/AQBELQ4igfkAAFE8GKcakAQA8PgajFS3AQAWgTZTjIQHAOk9OOdkGwAAj3xYsPsJAQDRJreHuBsEAJuRZnxZTAsAww+ZtlChBwB0IpKd6ysFABqGZHHtDgcAqcZw4HGoCAC+RkN0RH0AAB2oZKW2ggIAayN1+IDtBABQDEUdvvsGANv8Eoxy6wQAiYm8S5m1AQBgBkyoe0sHALiuzfF4VgcADPHWsAYyAgBdaPIAc+4DABh1HoRHeQoAfujaiHMsCwDoG5fTrRQEAPEOL4NQGAgAiPssanzUBwC31n2e5FUCALqe1WMhjAMARVgAKh+GAwDJrstMHuECABJ5KXYVOAEA4NbwjhTQAgD7h+eNKlIDANL5dF4F7gIAEwgx9jhABgCeTNNYz0gBAFp15Jp9LwcASvwPaR5xDwAVDVs1ooINALO2hejP3AgA6erUuv54CgAn8DR59pIEANQoVYHQ3gcAEmYaUWGEBQBEFd5QLuoFANvV66Ev/wMAZjmTjB9oAgA1FpMhBYQDAFKGMErxdAYAkEipiJy9AwDG6S/QTRAEAKVqCdsGTgkAI7DmiZwhCQDaoobUq3gKAB+VYJKyQAoAye9IWlsWCAAqQiQRXr8CAFauVmcUcwYAMOiHmtlKAQD9gLBlyuoBAPX6CrBjyAIAdmqEoHSkAAAyHpjvpZkAAOa/SzyuqAIALIMUrzRcBADs/5t9tpEFAF21GJ9xswkANtODjDFUBwCXl5G3F3wKAGCbCISwRQkAAANn+LSJBAD6m7SAHA0HACVGkX1+1QMAReVlIXLAAwBP4Bk4ueUFAPeofOwC3gMA75LrOi0QAgBGOgzVIowGAE6JhZOoLgQAjPNVv55fBwDLlqS7X58EABtXnB6MYgUAqyLoCLGYBQAaNimuj10FACh7qdHIrQgAdIYobBpqCADUz1uKEJoEABJmfY6MFwYAdQNxczTwAQCYYEphSToHAKa/3IZKYAUAtmQXfNTRAABRLmoxCBwAAEVQyUXbswIADDCNgU9jAQB04p/oiQkCABvs6oWLJwwAzeJ7ZVnvCABvh1hp0S8PAC8LJgWy6QoAWHAPlbkwDwB/zC06/XcHADJJEvuplAUA8BXKgI4fAABpMuw80RQHAGfK0NE+QAAAUsVOhzUtAwApufGNBPMBACObFzvXAAMAC32j5XvmBgADgzBUdL0FACp55xUhkwwAtzC5u7lXBAAmMhmLXY8GAFbUHo9OFgQAfwYjsX27BQDCTLIoldECAPMvMLhmrAQAUa392cgBBwAnN1tcs8EGAAo4B4CnMwEAvmLKxmf0AQAswV0qI8QCAIewE8AdVQcAzTuwEQxpAAAOj9Wm3EAHADxDeARXjAIAY6RzKFDYAQCc1N5+HmQHAHH1TNXt7AEAsMJWUj/AAgBOzs9SB+4AAOn7FoHdYAYA6/8PE2dRBQBclYW4gsYBAOpjqV/SYQEAfaRTe3UYBwAhLw+L4RkGAATsweTf+wUAkrseyJjXBQBr2duLRpkGADUZqWrmPQ0AGptZGvhFCACSQSG9qPcLABkzEqRNHQcAosTmxOGTCgDP/tr0Ri8HAKP33vqPlAIABLzz/c0eAQAl7f6P6cIDAAU5R5ohJQUA4RJRkksTBgDtBrQrlLsGAOLdwEXEcAAAo9fEItgRBAAy8EfEBbYFADnw5/DG/gkAfEcsabzOAwBeqRlqmHcIAA6Ld6Gq6gYAq8VM7y/xCgCJfMQgWYAFACyX+XFHkgEAQMCf372LAwCBspIAAPcBAOuK6tx2SgIAQMfA37IiBQBI4YA0GegHALlBQ6DZPwMAvCCKZ2PIAwBDilGyB+YFAAHPlqUcQwwABBSAfNoVCAC0EI9vmzwIABZAkyJpNAgAVuQ5MfMBCgAYGN9sjx0DABZLFEts+AEAnT7XuHWYAwCzp//Z8PsCAN3Mtsp6BgUAUZ0DCGt/AgCq3wCAL4AEACXFYqCSlgAAF1gHkeq6AQBgJIaoy5cDAOd5E8j7wwUAAi9eJbwbBABQhplW96MOAEF84NR/KQkAGx4sArRxBwCyWVnwkzABABjGLi81vQEAhuqIm3h1AAC5SOoXER0GAOZmBzKdMwIApy86UYbZBQAPG+GZOj8GAG2y1s8OigIAj43hNWg7BQBxmSGJoTEDAJxydZ06LwkAycRT6QANCQCJL28R3wMGAIjg4HbCPQMAmmT/GZasCQDGgE/7RW8GAKL+ue44zAMAH9twcmQHAQDIDXTq8RAHAN87uMZnEQMAaBBLUkI4AwBF/jCd030HANCgQSFDiQEAJcK4Tv6IAACL8EFjQxIGACUmLRrjSQMAbLGmf3oTCADbfneSroEOAFDc+MW/IgIAkI0XoypSCQCNiU6H20EFADMbhPuALQYAl/on8G4+AADoM5aePKAHAO/lCSO+bgQAOElhaVMvAACHBaKt5VYDAAL5a5/IGwEA28gZZHQ2AABDUlAP518EAH4UlcggSQoAXUyUYewHCQAewBfgUicHAHrpot23IgkAoVfb9hlmCQCMCwyWpnUAAEkb5MXh3QYAQaNtUT8uBACe56j9A2oBADkOOmLRKAQA/QijAURKBwAJgVW51G4AAGeIoPbxRgcAISNvXG9jBADTC9aSFdgBANXFhXuftg0A61BWFy16CQCdwb9tPswEAA6+czgdPgcA+Aob1falCwBfrA2mVocGACbsint1XQUAvYBf9D04AwCmlp+MP3gGAM2eeKc0AgIAUrJ4cbYNAgDaDizaozoHANNwHMBFkAcAWRAlFXuzAQD+z1MjaM0HAOD0rGhgzQUAzHR6/JoHCwCzZAtll4AFAJlOnKyrfwQAzbKyUwLvCwC2+ofYW6QBAHzBbQdIVwYAqBGqAIC5BQB0CQjJ7KEEAMC9Y4iMgwIAMFBGSs+wAwAtevWuuCIAAK0l6XcGrQIAekXXZ0EJBACCamCKyx0CALoxd776AA0AUDMRw1PMBwCBDQj+Zc8HAKEbAWbZxQMA9sb220DYBQDIn52MRgQAAIxreVSF2gUAJQCVcL64AwAJpqYtidUGADFKGQg9vAAAi+GfMA04BgAN7rgsPNcEALbAuq2CuAYAvkzd3atuAwAZrDJiJ6QDALh+RNtywQgAfqe3BcX4AwAQP3/5V6gGADrgf1bA/AwAGU6Cngx3CAD6hHCKLEMCAGipqDz3ewQAZygmdpFjAQDOEIBP3+gFAN4W6nwX/wEA/bW1RZrZAQDsmSRPZyMFABMmGCb6+AAAmIwEmHOPBQAAFdRPJp8DAM57Cf6rSgsAMjolA/w7DADyt5H+x5sCABZKhORhpwgAXsNyEmJcDgCc4ufbFzQFAPWUc4JzRQUA3VD2pu5lBQBJx410UCAEAImIRnMtcQEA3ZMxzviJAwDlfBe4JNQCAM1ANA36cwAAl57UDAI5AQDOGasAmC8CAJn9bprdnwoAPygoqZTGBwA6S+TuzfcGAMNcsgcyWgUAjFk4TRoXDADL+J4+ijYCAAus4giqVAQAAKePP5KQBAAvWKSeqnIDAGJH1mxBPwEAjEzJmapYBwBE/wAXAPYFAL0BjEhOaQcA1u5I6f3VAAC9dKVPIQgFAMMD0FO7FQoAwqgseZ4XCQChQMhq6aABALY6u+KTIwoAyoZMinWnCwBL/tY+FWkCAECY+K4jKgcAnGmZUr5SAAAWIxPv5aUDALr6xg6WLwIAdlCuk/YRAQCQypSqv+MDAIe4dpR5RQQAeUhGEglKAgB/3vgV/dkFAAtS1+4qTQQA5KfC0mUIBQBA6jhSW3AKAJY7XbJwbAwAuH6kfxi8CwB/cmNt0wgEAGJgpvb4+gUAa96oLYm7AgDm4sfw1GkHAPv4FFnzMgMADMKG6hUBBwCorSTaiG0BAN8qZiIGmAEAnVoZvOsBBQD7Bukc2FAEAD90rhyW2AQADrp9jMO9BgBjtOGntNMHAPOt4t5LhAgAqmOWJ63LBAB1UiCmobYDAM9t0JEn6AIAhzypynI9AgD0qmirt/AFAEVjutQl3gIAzR/XoCSQAQAaEF8RZV8BAAiXFGeQ6QQAr6XL0dgZAQAHIP7O+9cHAJSQwvPFXQwArnm1IFJFCwCJBh5jwXAIACCbDmPAawoAjM1tGc35BAABKGsmah4HAF3f4nOumgAAo7EZstgNBAAN3hdF+0YFAHV76DVUlwUAaDd7atiXAgAyY0wvWoMEAGBBQ18wcAAArlZOAd2DAQCgh0MI3cwHAIDMYGcYhAQAYTNTZVZDBwABuDZjaC8IADBD9kZUIg0ACxlIqDxZCwAXBCZtLEIGAJS7F0iQEgIA9VS43hmjBQB92mDg1KkHAAwd1g69KAQAp5qEXpoYAwBCslkfu6wGAAxjU0fv9gcAqS0qKUbzAQDWoo0wmHMCAFMkcApMDgkAM9d7o6/aBABhiT7ca58MAOXa7Nz//gEAw5JUlMJyBQAT1F5DKI0DAFgomRlPBgQAzUP1vg9oBwA8jdWD3aoBAMPo63pZaQIAvjDN1kXHBwDveN9Vd3wCAKN/kzNodwEAVRhEFlFABQC8BYxJhfkHAFBjvw9SFQ4Aadp0v+m5CABoESAIg/4MAELeJ2H3cwkAsGnNUyYPCwAX4QufiM4BAAkHUZRqbwMAtBYAckjyBwCRz+HRHoIBAB+jcMQubAcAhQzBqjjJAABBcXntZBsEAG1eGMGxvgEABw9gkFTtAQBHlhU/J/ECAMALp1XXiwgACOZciDqeBADWWhuIhWUJAF1P02h1wgMAX9x+mcGKAwARHuCKfPwBAOfoc1VNCQIA0kn1uzzKBQBDQcXsIPkEALaFrXLl2QUAO7FRpxe1BgDMgLFw088AABr00SV5NwUAoghgVlZOAwCe/svZ/C0CAI7gOxC0WQQA3SotP0uaBQDrjrvINNcHAAlKWb48OQIA3kyCd5j+CADZDA3D4NIDALtxZmiX9QMAmTm2fliqAAAZxpK1x+MAAIxEBWyRsgYAO5G6CtE0AwDbz4G1zUUAADaPOlXg4wUAsv8eBLMLBQAA/wfzA8MEAO1E2Q1YAwQAP2WSffeNDADpSbPjn4oDAOGvCoWJ6ggAaXCrUbEWDACFjLIX1jsCAGFafecu5wYA3k0X/3KpAQAPxnNjY+IDAKuyeI8b1gAAsDbB6e/XAADVCmSJHKsBAJcf9K6CXwUADe0X81dpBAB+J3SvopEBAOgORk9DKw4A+9P6wMaUAgAPTHuTaIMGAFuHECn4yQUARQXg2+c3CgAxFDzFS/cGAMLZu10OxAEAl1yunPvIBgDat+FcXIQEAMy1UOTg4gcAMLQBZ+11BQAmAKJ/4dMEAFNCjIj8kQcAwYoHmbrxAgAVEZtp+hoHAMNQO0ccPAIASB3iHWfnAwDooUdV+iYDANmvX8JNDg0AiI/H+zEHCAAdtlM5m28GALnMPCj0VQUA52AZ+2fdBwDU/q+hB0cBABwrnC4UIQAAgBj4SBjHAACGPCPY2UsEADBY/o5X6AYAtUFwbVsEBAAVfjTz1sQEAF0Zj5j83QQA4WWjPhf2BACIRa752kUOADpi22M31AcA+YgKUPmLCwDJH33Bz+wHAB6DggcoygQA1texfTO4BwD7lTjvbREFAEd+qtr9kwEAb4foNzzJAgD6g8UoGkMDAHnYi9pJkAQAHMF6QKi0BADU8OuZ+6YGAMYj5La1IgkA1d3x31AeCgC/dU4ydj0HAI5BlVRIiAUAXiz0qf02AQDrVQhWu8EGAEitE34SHwcA7FqQBLPGBQDHm4iOa3UDAIkxSpF2XwcA0b0Fo7HfBAApH4EF/7MDAC7ZPChi7QYA4VLsQxVdBgCNvhA1GCIAAGx6MEMBcQIAq/OLtI/YAwB6j8FO60kKAF4p/10RNgkAA9QfRHw4CQAULa1eOGYHAF4JBotPGQAAYjuC9niEAAAIc9OJhgEGAAa4F85xoAYA+IqXh9HDAwC6doLI4a8HAGityIHyHQUAXSSkvQZJBgDt8aomGxcDANFHirLYtw0AwDSeFO7CAgBT/Jpi9XYHAKlJ/FDq9AEAJEQzphTFBgCoTFaXkDEHACU1I7xOhAEA4e79Q0UdAgDSG/+qJ60BAAjPc0j9IQIAQWMVOk8gAgBkpGVAQTcFAIPP7TsMPAQAIKZucH5VBQAkuW9Zqo0EAICXTMhdHQYAnsJAMOh9BADnB2Wy3okJAJlH3Prm1AQAp+igf4OMDQDHnKVcZo4CANkNlBXHZQEAlRyhOl94AABphOPXmHsFAIStzG/ddgYAWJD8loVoAQCfYQPUam8GAO9yd6hZ1wQApL5zYW6FBwBXaiw/98QBAIQ0fPxucAYAbTbsOXiYBgAmf8+VH3MAALzkvI51rgsA9dq3rVkEBwC7oF8wvU8CAM+hdcyYCgQAM3UKIuGMBwCXweEQeiEGAGS/0YCslQcAsyu0kUnbAQByQ5lbYGkEAFiaXHHjMQYAj3LP78/pBwAhzkgoFv4FAPWxfF0thQEAD+Vcvg8NBgB1e+NG4qEFAJDV/wXuGg0A2Xc2BEy0CgAalpThTyEBAMvpqTmu4QAA9/kmtchDBQAd6WeASRkBABfJb0SdeAQAjrdOB6uHBABD44xeO9MBAEYb659BPgEApOZdVh9yAgCau/LuUgwGABFtrnzCxQsABG6VkZRqCwClHRPJuiQJAFwrIN73tgsAZZuNJHcNBwDxi/07vIkFAGtBo2o++QYASK7B1qPABABqWAsmh1UFAPzMEsPJCwEAW6DCPkvoAgBRFTzwop0GAHumYUYXOgIAOPKJorwJAgBvlzq9VTcGALes8ZcYEAcAuAd7tyzYCwD0aXc9CIQGAAfOLUcoKw0AUXxzUTd2AgBTCNEqPqAHAKs2rcbcEwIA1r3VQOKmAQDf/vj8T8IHABa8SBzM2AAAqRm0btMCBABSoBSM9s4HADnRwlsl8QAAahgx1OdzAwAWrafYLQwHAAB+7bh9lgQAOlIv0O5aCQC7lNCRlRQGAAZwwQTycgYAU2qBE4YrCwAO7G+fUJQBAKysMcrYKAUA+rm4c22CBwCz+eCZy0oCAEg5Nsb64AIAZM1I5L73BwA8D9oQD+EEAOkgq7lskwMA0GzqT/ygBwCkNccVkhcEACHNayi5Mw4AlJzburPKDgD5vd9+OE4HANkPisUTQwkAGyRiVqgfCwAq7dzX55QAAI4RjnP6aAAAK+5fCmQbBADUGfCdcLsGAJnNMEo0AAcA9CI2LkJsAgDwtQVqBvMAAKaABI9E4gQAlfDb4M1EAgBSmSoxsksCAFhc+PUqDAgAPojyTJ9gCAASyqG1bugGANHM76JEiw4AtP6fr9LRCADDZ94yF+0AADUWKWnDCAMAUNLySPM+AwC7oaFeRwQAAIjhcejj/gAA3x5iMqGKAgA7Na9MJCsEAIrgwkwGawYA070MAiC7BgAxhXF5zWoBAK22h3jFxgkAKlnXH/KrDQB5hlMS1AsFAFExJ3ELgAsAYIGxNO1kAQA9HZstr3IHAFtOi0SG1AYAqBiN3VjOAgCLPFBnn4QBAAKTa+/gIwEAmuYvGUzZBgAPaaIiUkcFALO4hp14kwYA3Gn7vcP1AQA/B2H8oI0HAIE6DGjxgAcAU9T8PF2jCgD33cfN5QUIACOseICI7gYAOGsxS6pUCABqxivlKF0BAH7LUQMeDgMAjB+xdC8KAwAD3tcMEp0DALFWsu5d0gIAuHwmGY1GAAD5+7Wp3IwDAOKhLFywuwEAM5WOdRWwAwDat2oKYTQBABX10XfnZQoApDkeTPXxCABFJlKVG/ACAG3endvY/QQAzJe6jIdUBgD+sPaNx44DACJqo76uPAEAal9O5cbrBQC4Dj2QBCgDAA2yotsvEAIAoeZcBQXkBgDTMqU1SgIFAJ3y2lSQ9gEA1Yt6DR1dAQDLnrJdcq0AAIVvBZsMvAcA2P/6v/4cBQBJ9U3pu0oMACAx49e77AcAmSMw9XX2BABXJE6DsWcCAIi7eMMZrgYAEtXZXntFBwD7BT14DSgDAAMat//8rgQAHhcVBDY2BQBleAcJMzECALyvNENEUQIA6FY3hcOwAgCGKiq3y7wAAJYS/lBMXg0ADMPvE91fCADt5YDDxsAJAKdi++Md4QMA8wiR1o9nBgDIqbHqL5YGAAujuY+irAYAmJ8byrdtBQDdGHBJWJ8DAGudtQpPAgQAwmNoYzH6BgCwQn6m5QoBADHaH/C7egIAvE/muaeAAwDU6gghLtQCAIB1Uw8NewkALYTJwGNiCQCjOUV+gqsEADrXQ9sNNwYAI7R5Or8gDACb0t+UFRMFAP5SjeknpgMAYVaFQUAVAQCEg5/QdZEBAC2Ni2CydgYARytbHGW6AAAnEHBjI4YFANvGGcLWxAAA3liG/z3wAADPwKn/0kUHAFdO0yFX3wYABgx6di/zBAAgbsfqq9UJAOPhBOHpHAwA28FUvhVuCAC9yMkrHloCAOo3sPPIBAEAmGypb1cFBABvh+OIaugCAM9guc4jrgEASpkyGYddAgBuC1Y71rkGAHLUyBQo3wIA7aQK4r77AADseBKG7Y0FAJXJwraoWwMAv4Uxi6XeCQC9uyPNVbQEAPiDSMAZ7AUA1TG1lqaLCABcxWbykzcHAAI7yamIuQAA2yUjow6bAABefMFxrnwDAF9Ihd45/wIAesXvw+4+BQD9LgLpn/oCAFSBEyzHmQYA+B+9HnUqBwDPR0k7YyABAPcPEklHMQUAV9DA982vBQDtjXgb56kHAIgMO49w7wUAk7M8vjN0CABCAGGReJgEAHIBXX+dnQcAxJ47AZPCAwDKyjlfuMIAAFlNm6kwXQMA9JfpXMBEAQDvfzSKC5YEAPd0XfER2gEArf7AGaxPBQBtr+ftc9gCAG75XU7hAgoAS7U+vALqAgBkNYiydYgDAN3pOlGMKQkA/xWgGDZUCAAJNDdDZDECAK8iO1CV3gUA3+LqGyCZBgB6c/9JWNsDAPoHR2Vz5wIAwSNMl/S9AgC9YdLIubMEACi8qbLoagIAUVwWEIIGAwB50GIzRLEEALicUhzpVAQAz3K/xphMCgCZ2MOUZUgIADv616MTrgcAZq+OQThwCQB6H262x7cEAJjZ74WhvgQA+FUQcbz6BAA4/jZ4n/sBAKYtdUb0ggUA5EwyINN7AQDGmHgRiRQFAAtBoJJNaAEAp8V4D9nkBgAo2rzEocIAADJpvWlIgQQAuF2kkcO3BwBBtjWsFnMFAGoJ6R3jQQYATTEKs6mmDQBHBB9v0McFAEk6C/hw2wcAeJrIPkrLBgB9OYGt6DsEAGRvHL1YxQcAPUaW0yQVBAAdGp5Ea1gBAIrtSpB+8QIAjjwdhtLhBwC6r6BcSkAAAL5vQSobngwAVmwxC2ocDQDbG9eepXUNAB3sHxoCTAcAjn9uUSeVCwDWQ6cKB0AHAIMR3ctkawEAQ+sye0s/AgCzNYKlqxkDANmt3L+VYwQAnJpdGi3bBwAvQoULIJoHABbdcaq/VQMAqnhf6ncLAAAtgp6ieWUHAN80tFITtQQAZyYc0HsyCQCgyGA71zQEALpDlKja4AsAdqKyS1EsCAAXKsBJfo4GALbobzSVVwQARjWPbDCJAAD2iC9rn9gGAFvgyU04OgQARbbxi9rVAwAJbWqp1t4HAE0v7k9JwwYA1GuLnJgsAABIFZYgCRYBALpNmzYWVggARm+shqvsDACxANeFAMYLAOn8DeE+IQgAbR5J1zf2CgCqz9opaRYFAIn2MWuCkAEAfUppZ1X1BAAi5bH39AUHAJhWvCXhUQMAvnv2GkabBACWOixxFVkHAA0MWO9nmgYA/M9w7zhNBQDifG7QgvEHAA91IY5ySwUAKAEbl5CaBgCjY6nyQBoNAL6mEqzpCwkAxEEyBMxKDADsaAGrZI4EAE9vqLi9ogIAKWktazs0BwCj6YyqBNgBAOlDw8hKfQYAd1d6T7trBQCPI3xiMJICAPvXLBIarQUAZONQbqXeAADXKjHI0VYFAA7oG7FWZwgAPbB7fhRiDADfvz50GWUKALQqaFn8ggcAx8iM46uXCACCOY0M40AHAP2CRn+0wgcAHNzHuJHNBQCD5fmQp38HACTY0cbGRgcApC2lfofJAQCJYaiDe7MCAKUNMUmvMwcA+wQcFoFeAgDovjRK4XcFACvXTb2+zgYAnzJC5MFACwA+qdH/RyMDAOC7LCWJSgEACbCPSzAFBwAKO6dhrGgCABy+vjTyBgIA6OvLpwO0BQA1QZ/wYKEHAHj9lu6nDwYAxm4pTTUdBQDHFjum9csHABQMz7ML9QIAWsbKhbP+AQA1FsrgmBMCAO5Vt7T5qggA8kSutZFrAgDIsXqNgN4GALAwVWdppwYA95hOKPu7CQDzMys4igUFAD6RFhipdQEA6Ipruc32BADSgdrJR3MBACNa2dk+qgUAYWXZx+l3BwCszAbwWI4CAEmsLLu7QQUA7EyZgjLmAwCV6OUUfqAEAJukd8TNWAsAgOQC/ojMCwBq4/S3qiEHAFOZRsmMQAgA+UrYrvcKBQCZ+Q2YyxIEANwp7tiN5wUAXVeM9t9xAQBJ7/bSXQECABPTkcO68AMA5Vv2FQHeBwDJTTYhLCQEAJhgpmRbtwYAhcACATwDAAC9rmsxGpIBAIvB89marQoA6pozOBbsBQA7qFllO3AFABLWBU2f+gsAKwbK3kmwBwD8cLjffi8CACixd9buaQUAr6Ww3DcJAwAb6nicA1gHADonHvSNRQYAg0RENXrjAwCZe9K3/WEGAOQh1h12FwMAiWECMDwyBwBQKbzMPQkGAEsDhGC+7gYAe40K9wHPBgAKZ8ZUGrQIANpVu5lLyAYAR7aYDBjjBgBtcOCFhZoDAP5jJud8FgMAl0Lb7BQ9BgC4cPncIb4EAHqChKAefQUAcbAooee2AgDPXXURdbIFAGUFk8KEhQAAWUFv2nuMBgB72d2Z6WMDALOuS+LcSAAA4wXslVe3AgDJbdrFpL8LAB03nmXIqgkAmm+8efkxCgDEH+41wUMAANXyGZkcoQIAzbpdwkwzBgDaALQX2pUCAKCThrfpjgQAxvMqzEveAQCG66MRxB8GAMAuwZrRPgUA4AS4xtsJAgCSh7Cpv3kAADJC1aKA7QkAeF4qx/4OBwAtgirUUSEEAOgx1rbrtQkABUdZsU/vCQD0DTDaUToAAHIcViu1ZwQAkOUQApLVBACFlniedsoAABdIaH/HOAAA7HsWW+ZeBgCpULgZ2lIAAClkZWWGQAAATJpvWTmrBwC/oKSS7nUFAO7XpApFvAYAqAs7d6b0DABHvA4LGyQGABWTHU+cDQwA9ILj56EACgDPLxiKkIAAAJi6txMpUwAAw4XDeM/cAwCpq17dAoAGAD/NEnFOPQQAxTr56me5BQAxCljKrGADAGLyxtVfxgEAq+zCFX8cBwDkUSal7FAAAOpo5mB2OQwA9PKSVqfCBwDvZmx+nrILAJnavFimKwcAGhP6CRwVBgCcDD9F3hoDAGh4cwfu3wMAEdSn9+wRBgD2ZL1sfmMCAI/FIWzusAQAll3w/Q1cBQBeR8+dVgUEALuYdCdcXAAAicNd2YiFAQDwAKhP8v4BAHNrlzD1rwoAWYTASFrYCADfQjaW65YHACa2xFDuCwYAQINs/gWACgCWMaca+1MGAPoGg+z6BwYAVFI+yF7oBAD9hAWQVp8AAIb8kpLURAUAiIZSNJ+6BwBdLbQPooQCAP5vcNksZQMAs+bdrXv9BgAW8zApRy4HABR2KtM19gsA/QDerOzLCAA1qepBEUEDAJTL80IeHAIABv4A8Of+CQBPCIGXjCAFANIk3KFoZAEAqEDFCni/BwABU9fOfqYBADpzwujSqQUA5ffbA9oFAwDKrreZhiIBAMlrk7IjKgEA6eZqpb2hAgBA4B4FlA8AAECXrwe7kwcA/frU7LbnCQBC+2AVeywIALZfzDRnKQoAP90l/X97DACyMNPDI2sFAKbRYOMIdgMALnLI8+AKAQA3thi22YYAAKu+6Md5fQAAEt0IvJz7AwD/cFPYPVwHAKwZKP4GfwQA7RWSqwbbBQBk6jUKUsMBAEbAayFAbwgAtNkPm1eiCwCL7H5AJhwHAAtPtUraKgcAEm22w1CHCwBKo8u8plMCABpwMwQHJwQADof5WI4LAgDMANthyDcDAO7QdVfQwwEAGuUilEDxBgAlLc6+a4UHABwDL6eAMwEAuvOngBA+BAAEM30sHmIAAPPw27CWFwYA9dYynC88DwC9flPRjqoGAPQ4GMmSTgcAAhDKieXYBQCNg1mCzGAAAPOVW/PTOAAAI6lDwnhgBQCyGySTMt4CADq9l2B9AAAAS6lCCJUdBwAX2MflEWsEAA1Py76LRwUAXRwKSwXDBwDLwYN3PVgBAMconcwERwMAAPKxmOXeAwCebXSYHG4BAN+vlXALBQQAVTzoZICVBADheqJd76IGAJ2dLuCsigIA6PBl6VkkAAAzCRXTZLgHANge6PKlUgIADehmUCaUAAClYY2RD6YAAN4P8/dLRAAABjztqQ3EAQA7hL1wwXkAAFbQ1cBQzQ4AuXnnamC3BQCh3WsivQ8HAPkfOVMeZgUAuBdzDYx2BgD/b/pk5OwGAKBgpLxAzAMADI37CqnjBgAoEqG8GoAFAJ+sNF7A3gYAs8FV8eUlBgCWMnJvL/MEAM7vBQGYrAUANu5eFmF6AQDV3E3hRRQFAEKkviurRwEAJjEl8kDyCQCITjGe3sMIAF6k/KSlHgoA/OSGAJkuCQBRSRQ7SysAAOpqlneJaAUA/Z85bheOAQCLk7ReXOQCACk5HvOGMQEALrvff7OWBAAhPl+dQ8IDAE1qfv5gbgEAHWKbiO/XBADp0wU/LnsHAJGw3RKcYwgAsnrNkAQYDgB7RpeCkfMDAKyBF75oRQcAleBSURl6CADexC6cxakHAC1leZ7w6QcAhi3yIuSjBgCLbIM7jq4CADKtx195OwYAyF+eOAKPBgAGdYe88VkAAOwMQQ6ZBAUA4q7+0NebAADwMtCD/ugDACnR7+iNTAgADSHmBnzGCQBpFH+PN4MBAInSrs5SQwYAWGKaiWAtCgCUonAFuRUDAPElqQjhDAYACclTEvbvBgCwcC0O7wMAAMT6l7ejWwcAltHNcMDbAQBHTFOxj20BACr6g4FJAAUAdd4jxFkvBwB5d7gHTZAAALlA+UhmLQIAhj6HoaWXCQC7VBrE5AcKAM/WSzsLNgUAcq/rrAokBgCckbrd1B8GAJlWtZHp2AcAbMc8RzEbBgDWMeYxlgMHAN3B+0MhPgQAoJWiW5x0BAAGX0v6RnkDAPFRWqvFJAcA89OdeDNWBgBA2zjy2msFAJ87ncFs0wgAYSLXcETsBgCuqRhwPYUGAOvIwk0+qgMA5eEHFaM6CADrMzX147kCAMUGqCfXrQIAoxXOyFVpBQAOKQoHT4wBAEE32IZK0gEAH87U/0h2BACdnoORlQoGAKsXgfPVJAQADsESacQsBAC0rskdJjsEAFETlWyLPQkAKWOPfgHABADE+VOeVT4FAOpuiEYBsgwAPykkXk0rCAC7ebuIGR4DAKu8s0YvuAcAQXuCzqj3AAAwcRcWWOEFAHay9VwFJgMA8o3RKMtVAQCUFqGcDcMAABkxqycOCQIAtkl6TmIIAgDT5ZqAbHoCAEFpPcQKJwQApVlW2UztAgD5KHWzDVwPADOSLP28zAIAwtgDNlAhCgCIsQ0fzesGAHQRfUvrTAcAXE/faGHVBwCK0W8Xeb8AAAr2TxdnywIA0OELOfnNBgA9K36cUY4AAIEIpdLDUwIAPTOOREEbAgAPiXNL37EHAIz1+AcYIgYA5Ys6gZL6AwByVY3DmNoGAI9GVFXZHggALTVdJJiGBgAkorKz4PICAJIcLKJqxQAAeLLxOez9BQAG8cf1CskEAMWPZfLOHwYAehgYKoVdAQB2+5q123ACAKuSzwsS2wcAh0BxXaLnAADw2nPE9GwEAC2BSfGnbgQAJ4QKaSUHDwD6efDpOqcIACrGYUSS3QIAzNhQrloGCQD55cSe7SUFAExoYAbSIgAAaHs5cCuXBwBl+dNYOaAHALVO0byHkwIAVw0g3yVFBACFQ+lM+dcCALfscMEADQYA8NjzAwWLAwDO8WSOGZoGAO3Kxdw0RAkAH3xmn5DHCgB1tR+dgxoGAHa7ygA48gwAfia9lyZbAgC8eBrZ4LICAAzyzBIKmQMAIiYf4cJBAQAgM6X6zt8AADpJkmqeNgcAZGiYE/s/BwCsE/e4KygDAO+X8njtnAQA7x1mJ3BpBgDkVNuDBkIBANBazMFvuwYAnWaR1cgyDQAybKhNea8JANIkbdjp4AgABx0WtIMeAwCX0Z0kHr0AAI9WIBjLCwAA1DCIcbHqAgDml2mB/ZYDAIpQv75jCwYATysGnhLHAAD9EltBJuUBAD2SJ/2gYQQAt6Vw9q2LAQBQ1WLr8VwFAD+M9X3jtQ4ADcaGOfO8CwDm6lyDuE8MAKNxjsHemQgAnyumum+lCQBYPcJlEBABAA+LM5ASqgUAIXQunn4VAwCJ1BcgceoAAIlwRVamaQYA7MmdXFBrBgCHUuOG73QHAF6VwETZ0QQAICvXOUwuBQBYnHk2SDwBAIDQi11q+wQAm1gISeOKDQASr3uXTZUDANxBdFnqEwQAW47ch9wLBQC54bNaRl0CAEco7Cf++AAABk/w2+bWAgB2Mhv8jAMDAHtjOsmAbwYAEeHfboM3BQANLHs1Ar4CAPjUyFju3AYAkmEdWDLXAgD9JUdEVt0BAIfIuggA5gcAUhh8OFw9CgCnM/XxXZ4HAM/wxfH55goALzr2UKSjCwB9EmIz+H8EAPSxgq85jgAAq33yLjKIBACkoaI4N5cBAPcZIpFF5gAAJ0Y52DEvBwDxAKKU0nsAAMZ04gC+ZQYAiza28eg9BACaOjnZyBgDAIXTHaspngYArGvHs4UGAwBZSPI3z2UFAPn+jsIqew0AT1kyHKQJDQAZ/v8qA10EAE7ebJvkLwEA8XwyvGMWAgDd8WlMXooBANWhecbHJAIA6SX5ptxuAAC4d+Zjg4wGAM/75CX6DAYATkAJdsHEAQARijIC/1sAAOQSxQ3doAkAD81fv5QICQA2nD8BSSkFAMc1R7oP9QkAGeDefCd2BQAL4MojcBMCAMYm65k1WgEAPCtRIXJoAADpJAg6y1MCAKSiP8y4gAcAXzBPI7yKAwDeA8G7gKIHAP5daTaomAMAGopSQa/QAwAbJyaHQf8FAC2VthPoRwsAujwcwmRoBwCodM3bSeAJAJt0kw/WtAUADArKuE2dCgCd24kXDAgGADGnHu98vgQAgICddg30AgADpkRMfV8DAJZawj2gBgEA0FMzM68KBQA1uzxhmrUEAHaa4cDfIwIAZMWyKx59BwDLUhClOKsEAInA3V/v0QcA2dq56+q+BwD7rKAL01gIAI+uteqSzQUA0k6waxwECwCT1WhnJSsEAE97QlmE6AIAAQdjdjgrAADl6gXUeEgDAIoI3BrdnAIASOFW2fnyAgD+wWWt5rMGAF2et3IJsAUAr11MI409BQBJQIHWuwQBAFDxf9Zfmg0AKjXQ6pipCwCZr6RfyYMIAG4mAfzb+g4AcbAPovIECgBn7fFoMf0AAD5KeOcNuwEAdwSyeMtLAwCCIS5uoqQAAKeScMWMvgUAebDrMD07BAACGcalrFcDAFUk1sVwtQUAxxgenrIPAwCRJ3yxD1cCAEckuAtVqQYAJSMaCvIRBQDumyPXJJMKAMMWdcM8NAsAF+Ad+cVBCgB1FbYsfzYCAN+HTcCawwYAveXXi5XUBgAyFYpj9GYFADAwpV623AMAqmzeQCkXAAAbRWcuWwQGALP8PkYHbAUAkW7+a4tyAADf/NXtIIQAALsQ9AROwwgAaqDQwO1EAwBtTdiGVOQOAPRjOMsuTgwAtx0yT2VNCABK+mKDqyAHAL/ZzUdDnAIAY4RfrZjnAAD+C8uL8f4EAHbB+z6l2QAA1bW93RbBBQDPq6W7tNEGAHpTpUiK0gQAmQsEW45rBQCRiWHypKcEAEsqN6+RsgsAl0T+KDAOBgAJak/KeyYKAEKyQsLuGQcADj4iFGOpBACVX7FfAhgHAJT+cYNrjQYAfNn3SESAAwCAQnj+ZiQEADHdzcRQGwEA1v+kCEQnAADdNNuugtMHAF04zsnPCgQAHlukmbsoBgC85tzkvPQEAG8LncRuYQIAHOZihF35CQDFWZGbPq0JAPhNoHWkmwcAlRVW7iwEAwCEJSTiWs4HAOPUU7Fe0gIAyamb0POoAwCO6wQNafMAAMBxS9HNPwcAQaybRHlwBgBPSCFGnLcFAI1rFfJpEAYArxA7VybrAADOqclA54kDABWsDlf2eAUANzmcM/JEBgAsbJW3R24GANBVH/4ySAsAYmJdXkJcCgDOudw0rrMEAJ+sFRppfAQADEBdbuAYAwCxPvjZIsQDAKZllDdFFQYAbt7X8aYGBgDnB2HEwPEEANjl+9yxKQIAJxN7CsasAwCEVJEImlMGAAZKuxTU2wQAuNvxSQiTDwDvymakxSkDAJvrT1QkyAYAmwHvIFP2CABz99LDdB8CADq9CI24JAAAUUEFz3jmBgB8dC4nMTYEANFcrEpeHAEAxuD9yrHRBgCQOjBqx2IEAJv/PGlOygMA/YZX1CyVAwAww957vMoEAInSeD+PeAcAEfizCSiUDQCbwvh3MpcFAGf+xTv5EAgAsaxlgUnuBwAuCpwIJJYGAHME58hfBwAAEyMdq4Q+AQA7lfbtC8ECAMghAz+5OQYAw6ERkeMIBQB6L5EOEpACAEOurGT0ywEAV2FX6XNTAQBgW8iT9O0AAABBdoTSxAcA7KwGv/7+BwAAQYJ6+5oDAGX950eOtAkA+R1NxQBMCABoWptZWIEEANnVQbx1/QEAPF2pH/zZAgARug7yJ9oHANQZMC65AwQA+FxGi4EvAgC4Cf8dkEIDAM2Dxl1ZHwMAgtZfdFd6AwAXJqsSu1UDABhzjFrH2gEAYDRC1Xm2CwANQLa3/LgGAJ1fvoM3xwYAKgWOr45RBwD0u5N0zGQGAON0GHaUPQMAE/aWF54XAAB9huI1BYkBAOyCIRO4+QAAMmx/G8RZAACRFFMGh54HAIK1PGRHxwYA5JTUCgziAgB1sbtxOHwEALBmUMhQXQYAfB82U3QWBgASs4uBo2sIACF1qpvyrwYASI3OAuqPAABIT+xxl1MEACjKrYsxuQcAxRbgrxkPBwAjjWCxe+4EAGlkV7iJCwAA0OreaHbdBQBJcKQLbQkEABSRIZdZJwYAruZnitqbAgBd93SagnMEAMkCOa06UwkAeuQRa+DdCQB2C5PRvoQHAGfIuZIKyAkATE7UtGjGBgAYxHlGddoCAFoQvjFMFgMAX++YK6wfAQBWknevGloDADyDxISGBwIADIJ4eiHPAABp59LnJFAGACqo3e+1OwIAxtMyttSfAQCk+FRgGkEHALR1sRg95QIA80ogVHI+CwDExKHV17wLAA5d9irCxwQAw1gkh5rsAQBtyJ25Mp0FAKypIl4HrAYAcTMRIJILAwBuljim2X8CABO4T1c2wQcAm1CiANSkBgAcl1YQeUEAAFwHbobVVQYA+E3m8yswAgDWfFyK2K0DAEYwOVnUmAoAt5A9y/4LAwDW+D3quNkDAHkVUZYOkAMAakAaE6EbBgDy3DW2cFcBAHGV94PNngUAvX8LHEbbAgBfNIGpQjoHAHnIzJ+SSQIAKZCVFvGgAAB6NLHXT5cFAK3tCBzM4AEAEx+t+L1zBgCOvcsQA2IFANaF4nf0tQYAyGwy7JHtDAD8owN1U9YOANSIOXbTJgYAzlg2b4TsBwBD1jRJQ5MBAFGqXkSi1AAA4G/ninDQBwDhx8O2R5gDANnZpKJ2dgMAxy6iHT+PBgBrc6I5gO0GAHU8TOB+YgIA0edHppDqBgC5mTNyr9oGAI+Oray/BAMAB4sQfZECBQAP3aZsF0MIAIMdLI8V1QUAO+tYnkS1CgBHvj3rYnUCAOcLF7TXkQIA4ajfZ8rRBQCimPJhgKgCAH1icZ5OMAEA/pzcatIUAAATb6EbafEHAKxu8CgY5wUA/P/wB+1JAwDdwtfijUYEALsHY/jG2AoAcgmFoWsoDgDTRISw3OkFALJiM1RqqQkARjLmJ2TaDQCeRhmUXjUDADeK6rh7hAEAcZvPiGX+AQAia9vSybEGAEu0/8bnzAYAyiKs3ojGBABSA//DdfcGALsZ5D5gZQUARhzGVkRUBgDyef6rKY8FAPbNDnG/ZAoAaoknhcUIBwCUM8Xm6iwMAGkr6CEbOAQAtIVBcpOvBgBoPueNq88GACG91M7v5gMAvg1QCWYFAADfha0keBsHAEF/SpxidwUAiKjGCUUCAABEZi6xamkCANiAS3+izAAAnhEb8cHHAADsyrBb8gEHABPBvnzZ9gAAo5N8+5fODAAaKBFagzkJAFWR2nqQKAcAVQkFvKUgBwDtbGHk+LAAAHW4D7XE0wEAmAHcc5byAgD6D4PxsPQFAEDc+yvJ4AIANVqAm0MJBwCHgX9VSOwGACw6oRtNigAArvkLijR2AADvRLHLuekAANu+sV3VmwYAvTH3R07hBgCsDidHXqMJAI3feFQibwYA08+RQdRmCwCtIFf7j9QCAHffoSF/ewUARQa6/w5VBQAxqZhAauwFADfzs04QIQIAFIy88kMXBADHc4etsJYHAJtou1zunwIANIcXXGYiAQCTxWtOehYEANuPzvhlJgYAV5jFGhCdCgD7n6W7O9kEABc/N5d4ewkA7LcMNzNLCwAAJ/Z2KJ0DAIdsHc3OAQAAdXZ0ERrwBwCQgaGlDTUCAFIl4reLkwcAzNaBhu6RBQC4eeq0sJ0DAEIIOA8iAgIArOBCunbyAgDm3+LGbxcBAKUOd0mJ4gAAcnsUiJ5VBQAw72NuHl4LAG7/p5oQWwMAkCZP5aP2CQCbYZxb0GwHAJUWkLBUlgYAJ3+3EDelBwB1gdKnHpoHANV3xqTDjwAA6jQH05nBBAAUzJrLIsYGABYCA1UKZgUA+xGfGfFoAACQaxHQ+vIEACW2O7cd2QwAxBKBU4JfDQDdFZgnWtgGAPmczbC3QAcATpTylRlFCwBUTq6UQbIGAJeI7f0KIwIAcVB9YRI0AgCbljUP09UDAO9ySUpIRQQAfH3qn9D8AgAq0p5rEpYCALIFKgFxoQQAI1VNx5LbAQCJQmDKiQsBAFvwRVq+QQkApq7si7OtBQC78kHbRv0LADjOtbuI1A4A0/CeHS19CQCcKBiXSUcBAKvH5GeKpAAA469LVLwPAwCK5V8xAccAAHV7V42HCwIAaj4/BxivAgD+JA1C6joDAJT/9IsAmAIAHpbbcZFTAwBcxjz2FCIHALYpO/S5twUAs6PuMepJCQAIFlgTd74EAJheOWB52AoAU6FVyEryCQCTpgdTQH8DAJy28mzm5QIAU5yuZkLYBQC5U+h96+QFABwXWIz0/QUAqgWVjjIIBgCaxB2EgiECAAcjHYmW7AMAAy7y/2PzAgA5ruI5pwsAACa7iOr1JgQAyHV/55IwAwDnGdhAOaUBABOGgU8uEwkAjFF93pciBwDWkIdc3pgGACXrW1S4aAIA3/6Wi2TSBgB8sB2tiHkEANd65qODMgAAObkMvscdBAAECRBmbLEBAG3GyyBMogAAgYbk7+miBABxYoSWEl4AAFBFLCTIuwcAtzU7EAaaDQAyIPNKfiMHAHpTsxpCJgcAjCU4XfKMBwBaSZwts+4CAFCXL3clngcAI787g0fXBgBJ19UW2M0GAJg2wckAnAMAaJ1IMY5rBgC14hB+hXMFAHIUqhboOwEA+Eut02QZBAD/s3YgtQYAAC0IzrkWfgsAuD6FVy+ICQDEH9CsntIHABXntVlq5woA9qlhlS7eBwAceJWd4c8AADxFHGLMEgMAfAfa5qxFAQC46ZzvK5EAAHa8QzR+1QQAy16ltvTUAADOO3O7sOsHAEkFIAVqugcAaSDi5O32BAACpvEKqbIGAArYslsk8wsA/G7zIPflCABswGDPzLkLACV58yPjhAgAwXaCLIFlBACXHuaa/PQDACQt+usHvAMAoNRctUS3AwDzIVeyUyUHANMSnU6P/QUA2WIQKrK+AwCoyYI7BqcGAO2XwV2jpQAA7z2lBgzIAwAWy7HCMlsAAIKB1XospAwA/p55fmbIBQChUMh0Xi4IAJmGTmHb8AMAMGeFpHEXCwD9qE3SzF4AABh58P27gAUAajyHhjXnBwA++Xff7UwHAHG0N2pVtQMAgtRN4STFAABWxpZ0RYMCAEXNts9rrQAAFCSw6NF1AwAzpyedB/wEAA3FhgxEiwwAhTvKnJI5CQAu30zk8vgIALGmexEyhA4AO64rDBdBAgB/L7+JsDgBADnqNP1boAQA9V6STJEDAgA8TuD/f0kHAJiv7HxWJAEAtHPECoarAQD/p4Z8IsAFAHdEwr8SGwcAdTCoc6UGAABwyGYpYfgDAACNBDb6/AgAgrO7M3FuBgB2VqSoQksGAM+Fmk9u6gwAoHjo7ldvCgDeDSp4yQwCALOqcDBOXQYANndUMY68BwCYLUOxv54AADaXZ3eqBAUAse+HVtUsAwCVYS9ej0QEAEUDRp2RaAUAJxqt4MI0AACj29lDGQQEAMqqbKJDdwEAZMn5VpGMBADQmh6NJ+8HAAG9p47lDAgADIApFJMtCQCWzOtDuu4AAHj4lVPdhAMActI1GjPfAQAO90r97AcCAENolx0KQgEAT1k305l3BgAYYI9URxYAAEXxeFXOfwUAcSoUDCIJAACaNRQj+bQBALFmmKQwMAcAeSYL6StECgDOfZTY03sHACggVcFV+wkAoflWHRn/BQBRCRWJnRAEAMtHLS29JQIA6jvngMB8BQDLH3J1ENcGADLxp3K1OQIAaJAtrDPUBgAzcKQw+SsHAK0OovSsTwYAKkC5ovdlAwDzWKcmxSAAAHbMQvBZ7wkAJd12ScKxAwByYrFcZh0LAFbFcORWhgoAK2Cl4M9SDAC829ie+DQAAPOOjZSPOwcAq8oj08GGBwBRbiap1DsEABNTYcSsKgAA33d4ZKD3AADU8JMPzOEEAJAR7yZH7AcA+BL1i9W9AwC4BLPXt88EABLviZfCmQYAULwh4+o7BgA1u61AwyULAPUr5KHhYgUA0zTEy9SxBQD+dZu4bD0EAFYOkFuNMwMAUxpTfTKNAwCfG9VhXLIBAHWQsyJGSwEAJp8KzBUmAwDftpy5EXcFADg86RScpgUAmcWkgInoBgCShSVxj/kCAO6mVE9ErgoAwcX7ejkVBgD7+PODdw0OALmGxF9nqgoAE3aeLgbYCQBWng+1TKcEAJIBZMLRMQUA0n9snT3AAADBEGYVzXwFAGqAnSSupgMAWnyQqYXaAgCvTOwhN7IGAKI6aKTT0gQA7/0Oh8b5BwAl74rOuJgCAN5lIQrqcgoAbtA+73mBBgAerP7AueIMALpjGwsp7gsAfDqAcWK6BgCyDPfvU3kCAFLFDq4iTwUAJCcuqT2fAgAYvSIMykICAM7VBISKSwMANTNpg7XsBgBNuN+/duwDAE+gVs+VyAIAUk3VSVE1BgDhZdS9Yh0HAPVe97HatQUApbm+DNbiCQBW/l0XwicFAB/1jyuKng0AsWISYjPDAQCA33jTKMwDAKaMlvRBIQcADW3ba2kHBAD7/C+ycdIFAHIxfzFfTQcAgcrZZ1TlBwAN9YYxZaUGAPEt5uyIsQYAcUmENm3GBACdflTEvK4EAP21VHOejQAAaMFtC3VrAgDJrAEeiGIBAKUBHfNtlgcAHZrcnb1zCQDJAW0nGwcAAF4CjpHYsAAA6+Kep+5bBwC4TQmEKckDANujlb+P2AUA33JY/h4PAABqJRgjh9oFAGBZY4HrnAUAZMeTdvOMAQDqGTvRHG4AAFMDW55irwsA5OiIoPEECgAtqO6c/A4JAEqjLzyGiQ0ANtiooabzBwAjbxZvUa0AABrIV231YwIAyjhGOCI0AQBQCq/xHzMBABZuUgMGCAMAC4A9XTlEBgD83r49ILkCAFWjVuaMsQQALBi8ZjQ/AAAT5dLeDw0DAD1HuGgelwwAlfN5l8wsBQDIVYKuBOkLADiT80au7AQAWBw1hFBhDACzMxLyGk0BAAucs4kZ3gEAnm9v3GkmBQDHP4yyNDQEAJnAAkIhqQAALqC5rsAZAACS15VpwKIBAEQcV7HLZAYAsoD6Ngf/BgClXInSoLwDAL8BzJ62jggAjPMtkci0DQAN8sKLf+oFAK+vyhblIAkAJ984QIvqBACkYl08vDEAAB4ITA/+2QcALPJnFNU+BAAJ0R4MzOYBAPHo2u0dYwUAAtLK8QpGBQBdZdCdkbQAAEzBGH1pxAcApKK7kMgxAgDKQgWT4EwCAIUL8/1VoQcA+YfU5cbGCQBZ3EsT4UsKADFvMnBZQAkA8yRzipJJBQAGwQb99ZAAAP1DHgKxqwYAoBHX+rwyAgA3fwQ8waUDAG2gKDxOHQQALhruY6cyBgBNXr3/S/oGAJJHuqY1/QUA6J3pHV61BwDPDexttpEEAKFk2tCOSggAvW4JRfzsDQCxiLST7u0NAI68URrBswUAGHALi2vPBACnMurHPbEFAB4Tc9vCjwEA41ePH2XjBwBlqV8FVlYCAO6FDI0zjwAAvXMamSGoAwBwWI9B5jsAAPCerI7B3QEAwo2ZnuBMBQB4sC6o1DAFAIu/mmxFcwkArA0QFSCJBwDL/pVA4T4DAGQJetaVrQYA+8sAfj7bCAAlSPnhMDYEAAlAa2qV0QQA4LX4Lf4TAgDmkRGk41wAAHcB8VOnXgYAY2MJ4j78BgCsZ225NuwHALFYB2rsEAUACSEC34ftAAAaHpLBTioAAEx5z/FiYQgAuF7+yt0kCwAXMkbg1RgIAI1CkpCL5wcAZ8DetRJtCwCiuCQ7miUGAJwLF/S1iAEA613h3sCBBgBFdPNl5t8EAIAnEcVD0QMAV0UVeZEnBQBNQkEHj58DAD2SV7NuXgQAb3TbXpssBACCuoV4Ue8CAFEvWzD7vwYA3RLXshKxBQDi5E+XdFcDAKPjlnr4SggAn7MLKWh5BQDcrliMTpcHAMaINAh+dQcAi7znKsYBBgB0q+zCcFMEADoUq4+38QIAAeEgCkO4AgDj/ogdnqQBAJZNzke7iwMAN9SEuufwAQCqwl3jQ9wHABiXPidcKggATouy38krCwAZ29X49I0EAI8CbJeHTAUAUC3YgftEAADD2X2IZWYGALKwagp2KQYAbD4kx+aBBAB3/EZw45cAAMxYZwFy7wcA2eMHqcUYBwA7OGuMybkDANzMXiXtBgAAWZoiOGWXBgANw/kjmPcHALqH9WjwHwQAU80bGQrACQAkniCcb7UHAL6qzF8eeAsAbMAxBJtKBgDoE7WjOdIEAGYQG/UjlwIAw9kEz/RCBgB6m6BaCdoEAE14PTfgpAAAGSl9W6HWAwDWpUZQpxoEANrTwh51kQYAxCFnqzg2AgCD4azQp3EAADFE4SBSNQQAgTkoKjbhAABUljXYfHUKAI8NsXrN6QoAdBd2z5vGBwALuofIqi0HAGDaXaz0twAApJgELNq9AwBgARiqZ04HAKduFMe8wwIAXynoBOvXAAD+oG8e6qUEAGBsQ1xjXgQAi9HUqPSOAgDKKjKnqfUGAKtE2aPr1AkA5NzzFQ8QCAAkeDYOcBoGACM9q5IikgUA0+gOaLkqCADFxkEvDAABAHRxc9+fIQAA530Sf3IUAwAeuCN9J+UHAHoULhrilAQAmg3l3YWKBAD0PUk098EBAIlohmTbewQA7I6PBH2aBQBrpL5s17UGACIleB4XQQEAH3zaJm2ABgC5mscbHfMDAGhRn0UgnwgA0j3AabhvAQCU2QzsbFUHAApRtwOa6wUAccuR3dEKBQBHirSAV6oBAHdSaD8zrgAAYgm2M5cZBgARZSZ8FZsGAMrxk/hARwYAhPb7CKQ6AAAN97g4HvgDABHIF181fwsAWoE0U+h6CACO5NLdq+MHAOVFH77qHgYA7c00LT6tCAD+r9l+zA8BAPJv6bCMJAQA4nJRERwxBAAlab8c1MkEAFBPEPwQBQUAnSRuM8UPBADhLfs5ZjgDAHh70XH4uwcABIB+a3lfBwChD79YwScBAHS5Ua7EjwoA09vSv4luCgDOZXagIuEMAMIFNCCxygcAfRadR4LtBACieZguQnwBAMP+yEZZigIAdyuRLrM6BQCl4J+gTbQHAPR+0IfvVAMAddnFYCK1AwDcHxc2aJ0HALvUQPGU2QcAVBhWBMS2AQCSUyAt2QIDAGTx4OS2bwQAt2VSrZc0BQD8hhOg2+sJADtqswwvMAgAbELr9cXtCAA9KKS8osEDAAIvu8cwNAIAwou1G+qjAQBhXN5jVyYHAMrxdjtdDgEAZ47aU9a/AwCKKsg+lYQFAHtwp48oXgUAgR2Tw185BQDLYRPFRlsEANHjf4rdTQ0A0hnGQczOCgCQTaxiZToMANi9p6yl7wwAISHzrsDBDQChf08xvyoAACgVip7RkQMAx1+JE/qiBgCRperdjp0AALfcNvp7FwIAj9t5+rwbAADhZjbrS9gDAAQigR2SDAIAzjI7PYTdAgCr2IeTYa4EAIP7W5hEfgkAIcwmxjJODQAXgfMvQZYIAGkkGtZBsg4AQrrlq4VWBwAuo0RTqvYDALsRD2iDlgYAqiP2gTVMAACly3VYrwEHAPN7sZENoAEAsvJh6zMJBgDSTSrpPxkFAD70UKWV2QMAPYg6uW9VAwAOO2KbUjUBAOuDLuK8FgcAuD64MAE9AwCsr9C6KpUIAIkb0072CQMACllRoC6XDQAY1dGt19sAAB4j4iP4GQEA4n1ebtZRBAA4+HCZwwAFAKNcpoFbmwcAEXiP3CCsBAD6AfWpiZUCAEpratIQ2AQAWbKWDeDtBQDzBVnJ6fcEAOuZUjU9RAgAOO5afX2bCwDrNC+aUZIGAHjPJElA5A4ASRRK7C6UCQAuMIFXvEsHAEzsgbs1MQcAPEhhG2fvBwAp18wURiYHADjmkq2TGQMAkkkjrhlTBAC1T9JHnSECAPZssIhE8AQAEkpynqo6BQCc7xRTpqACACd5HDzNGg4A5XmHt0aLBQDyer6smjYLANN0MHSwCQUAod62OdxVCADCJ/n3f5MHALalxhT6wgAAfNBt271WBQAI0XnBrPYGAMJHhiFuzwQAtluNwnwiAQAjdvW/6Y4HADqJHySyjAIAcmc8HlRbAgCiCnEHoyEBAMmDdMc+cQkAyvrVcgX3BgCB/yJO814KAIcRFE+UTQ0A0s6mlLsnBQCXSgOfXl0DAJu8hZcGJgEA8E+Fx05HBQDKSKMCo5YCAA6kx3b8MwMALkhbmSqZBQDHKgAHx40HAEEX0JRjkwUAF+8aKKT7BAB6CrJpkLgGAGTbx7WM+goAD6gqmOYYDwAaGhr4lZ4LAPpsZPOU5wUAOXaKMD1HCAANInBiQaACACXQaYskXwcAJ2plFrzLAQAoZ+LW/7kFAD6nOhDCOwIABZ5YAyZ5BgBdWZKY20gCAAgtrTylBgAAc7r3UAENAgBD4P079wIBAJocUbXg2gwAVdTg/38lBQCAIevRCEENAPmumw/MlggA6aRdcr32AwDGRVd/q7kAAGMd0vjwygUAK+oIpL7eBwAWbYmT254AAMClXtKXZQMArFhgEHuNBQBp7gvS+M0DAF4BZbdMCgAAyXx8MzJoAwANpp3B7LcHAIj6fKdRSgYAtQ3KcPScCgDYmAhuC7YEAMfm/90EXQUAXL9hxu07CAANaVxpPDcCABjPDVLIwAQAuZR0S6+EAwAlIqKOSqsEAEMXYNdaIwQA9XWJBw3LAABLDFM+MZICAAmlJJG7jQMA8RFaZdBQAwAG3wwrzucAAOZwS9nf/gYA1L9Flz84CgAAw8Qnrr4EAD8/akGkWgcAzq44YSUVDgCjhYzEOmQEAJK4NSeMhwYAd9j0IzWlAwCd7ovtBKUDAEb72KXgZgYADctwSE72AwBXZW2xSBUGAPOWNXdhogcAOl0nX01yBwBNUQ2BvPAHAI0TcnOtnQwAdBDT5d5FBwDi239epbEHAKFuF4+YugUAWuzdB6nTCQBvE/QmpGsAACC3Bgb8ygMA2pw1ovAYBQCn7G/k5foFAO2Oz9v40QAA3IHQPjGTBgBCF5Bmo7AFAH7KpCyHDAQAAZ4AlIDxBgC/MUq0EQAAAFynCmppHwYAykKtVwqLCwDI/Qa3muUJAMy/btQIEwgAUCgtipg9BgAMbMY/bKAHAPtHusG6yQEAjgN1xTU5AgATnMVxvfADADXoFtlIrAMALiO9r1MHAgACYNAeux8HADqvpEeunAMAwtk0C3wzAACKNrJSrT8DAOjPIsTQyAQApXFZJ7RgBwA9rRy8ldoLAHVzW/9R8QgAppDLXDXMAwAWHuTFxkkGAICq5u5nBgYAkOErGJ0XBAB5aX5W2VMGAG0lmkIPbAEAMZE+kEOUBgA23fnGSm8BAFOS4hJJ6gIAXdJoPmS0AgDnuib06jEGAOgNcKO5dQEA+0iqAF98BwAXA8qFd5ELAJiTx7KpWggA92X2x/IxBACf/mbaEAQBAH3WtNyCTQIALXUXDv7mAwCPsMse3toEAJHqsUiWWQUAGXuPhURjAgDAWilKPfQFANSsUlynQgIAEA0igESTBQBTEvkVR7AHAMa65sSAwgYAbnZhs6OtCwBOO1wS5S8EACKsSk3YEQkA3XylzwqNBABDrvasKL0FAH2QVo+rbwEA8tUYErGsBwDbtCMg4B8EAGUvXL83mwUAcearfeQmBwDB9kbnRewCAIZGx1MOWAYAdD9nBKHtBQDTNhMZNGIBAECG8x/WnAkAqBu0xMZgCABuNqcM91wHAB4BbPGoGAEAuQOiB1eiBAD2fyb23pkEADx3CIGFbgcAKcvdxcqTBgD0nwrQEQMAAAVdzf79zQIAau32U4pmBwBWJRQuugMDAAkJwYQFiAMAHSYKACD+BADkSNKWGHIFADva0KGRUA0ACgXBx7/2BAC+qS7NTk4OAG++i/KxfggAAkv8WpM8CACuGxj9F1UGAG2Bdix35QMAiolAlhgZAACZdN6EKu0BAMFjT9fteAUAPQwrScZ2AgAuk79A/JsAAAszH/HoiAUAbsJNaW7RAwCMKJC1KuwDALjRMq4JOgEA5LRauB7oCwAerjykrHoIAHNjUtcFLwYAuq3GZr/hCAC5e9jke9IAADS0XSMnbAUANy2mDm4uBwA56G7QTGcFAPwAoiVc3QIAfogseenVAwBVvKtNchkDAAAIaHh8uQIA3eY03d+vBwCIrjWLVDAHADTj1qFLCQMACzDjpybhBgDF+/yuwIkIAIJlgx+h7goAg4d9J6KFBQDuuKjLo1EFAIbY4itCtgMAvImWQeEwBgBVqacHO2UEANsRtEM0BAMAYonUM4JfAgAx9K8Ej70GABJjmv0H+QQAm9I3x9MPBAD5DpV4YmUHAIrPhuqjcwgALZz7q+LgBgDuM+o4Kg4GABj+8ykkCwsAPmFLSL+LCgDAyB/VWc8DABhH3tagoAcAS7dvPjpcBQDVT4hfE1MDAIQbjAoW9AMAfGwTb1wvAQBM3jei2/4AAESrv868eQcACWlNP6muAwCPGFiznOcBAG6B4PXYUwkA/C7buzOFCAAwlBKWlxQJAEKGFjZuegkAHp3TUqt4DADx4/fuwzYEACYAH8LT/wcAqS0K8nvnAwDecoT8vxgEALOjs1F5XQYAWdFSktOkBgDU7ABZ45AHAIZ3l78lBwMAU6A1FlwKAQASohGkh20BAHAFTtXi1QQAdF8/s9flAgC/fog/3qULALY5Yb0k7wYApqV3tZD5CQAVYgZCWn4FAHc2mESLoQEAj28e3lLmAwDr2C7gK1MGADhfFsiHjwIA1vfoG61OBABm9DFPnXUFAEN59EmBNwAAKU8r4zufBgDWNBX+glgEAORvPJQpmQQAFVtUcnA0DADE59fOayILAN6J7UwTOggAXkDOQ/jcBwDWg3l1XTQBAM3MNEL1IgIAtNuKPUp4AQDMK4zuvm4DAG9ij1v+iAYAwDJHSkjWAACSLVPGSrkHAA+FVIcbdwUAyGEU39mNBABxMueHlnMGAMAaDMidzAUAzdSGFGeDBgBzgV4aX28HAErf+fXT1Q4A5tdojwvaBwCmdVY4FCAAAO8dPbVfFQYAfJKJLqN+AwAuqPVoplkAANzUoasVYQQAdtq1w1MZBwCBetMzImQGAL2xdoBlyQIA/xAw5oGlBQB0NuiH+KUFALlDpqDTKAYA0pMMZNgcCAArD9fKsLcIAL1EgalNhgsAG10trjc+BAARPaFwzwEDAOyRGLqhpgIA4Do/+5HyAgBS6kuBexoCANFEbmWbZgMAM+Gm7QY/BgAPB1gnNDMCAHXAnEXgmAAAG3xsrV7fBABe/dRsHqIGANCymWYSKQkA5z1gohHuCAAgTMf1wgoGAAhoGSoZmwUA6AFwsHFTDABf5kYwChcGADiepEYaQAUAqMRhVd0KAgBGnt7ttKsHAF8ZGp+/hgUAC3n4Xo0IAwDbtPwmIYwDAMPjSeG6hQYAMOmkAda8AABSDnkD++oAAB2udQ9egAgAJwqGWcxkDADuC7C35UgKAHSP73WW2QUANVRMNONKBAAvBEg3wVUFAMAyQnVB0AQAB2mGMLQhBQA5nPtAjjADACygdcasCQMA7kOlu7mJAgCeUyguWasDADrYzauCTQYAJ+NywY7HAwBG+bchUi0GACl69zom1AUAsK6JIt0/CgDruX73ZNwHACxAOIPSGwgAITk4pSlPCQBtk9AYnCkEAEmKQYNBkQUA1a4hxxgqBQBtl4K6UbECAFTHS97vwAUA9deyJdx+AQDuGwimNnMDAMPlh4gxtQcA4VsaSW2fBADgvsdlI+cFAD6zCC8GOQsAsc9X5vO7BABnWW7193oOAI7Wnn/W2wwAM7dcVSALBwB/IXFFB/wDAOtqK5vSoAMAneXdzHhkAAD63RsFTV4FAE57xAQRfwcATCwRVcUTAQDKt/kDUVMHAAghmh3tQAEAr8I7MyIlAABkoPSYQ+MAACgZSz4JCwMAEgPIfn7OCQCDj/e9deUMADjtCxl6Hw4AeKNs7a34BgDovc4+2SIFAM/24EXwJAAAoc8mNLZtAQDYD9MfOrkBAGKjaFNA5QUAmrK3/T0SAABoPFJWQzQEAF/uIXlSmgcAfoE+y/xLBwA9jexy3oAHAHIn9ADz6gcA40w1iFFFDQCryz1KytwEAMvrv9AU0wsAVyvTavzeAQC855oIRYUCAFzBoOmP4wEAezfi4EYgAQCFqApWHHIGACgZZ78o6wAAp5VR7xq+AwDrtb1iL/IGAEkwUrholwMAvf37yJQzBADSjb8B0mcEAJbnela99AYAg7cXk8haBgAyif0gO30IABVpMgjyAAgAg6NbWpzvCgCtT+90mpEGAL9SFGHUngUA7wnqBOyRBgCE6QAny8sDADy69cRDHAcAzXSe+vZtBQDfVs/klZwHAOIJxjtkvgcAeOjZKsFJAQBfDDnKWKcFAIHcYR2LkQgAm9EMJlDTCADYtDdOq6IHANcUVHPqHwIAnWN/AjinCACVJEbZECcHAFZ0AKqvWgIAG6PqKB/SAgDQXwDqcXYBALc+SySu2wIAzOH/Vy9KBwABcwhzMLwBADScAfRX7AcAJKUfLghOAwBqEjWmjGkCAA7ZPV4vcAUAx8VwSpocAwAk/HiqpTYJAAB7nzsvmQkAoq/EsATAAwB4urAyiDEFAOx88Z9L8gYAx2DgMH+kAADQyA1UhIMFAK6cxNxD+wEAK7j0BqxGAQBVc57YALUEABKKchweNQMA4y+TaZ8LAQD90RzQP7QGAPMOdj5YQg8AtxYyV8E9BwBKcdf9SK4EAAPhE4pf+AQADf/WsiA0BwBExZdGS10HAPT49//hGwEA4fdXaOEZAQDV9Vw0FIoDAC+1BXGNpgUABh6Fnsv2BADllRhHxHgCAORkPc7N7wcATEtcRW1PBgBLo/4yVtsDAMIlmIKxkAkAyCUyUdPnCACtq7fjK8EJAKWcHnh3hwUA8l1J6peRDQDY2V33K+4GAI2+NOssxwYAx140zMl5BgCkmGj5jYkHAHWd9K0hQwAArlrl5BlgAQCcIF3yxU8HAA3tnZNqVgQAt+AW52NgBgBwTR/cr14EANqxzM8kRgYAwbZygKtXCgAJb2clBxIIAO2OTtAYoAwAbNWl7jz3CwAr10WAhQEEADAtyuDlWQQA6oswGbeIBAC1MhsNSm8FAC02gLzupQUAxo1OCtG/BwD0Nmc2mcgHAAFc+eq7XgUAij+QYLBtBAAhZhKJWGACAC/ldsY8jgkAj6mV2XlgCgCxCHkhfEoIAFll5gN23AEARCQLod/eCAAE/2CDpgQHAD6L3jzMzgMA/2QPR9UcAgCJOZWNwasGABXm5MLQSgUAKlIruNVnAwDHfT249NMAAI3F20x/BgMAN3lp2lIEAgCpd6oryy4GAHQotq82KAcAQLKUIDyvAAB6NX8phcIIAOLWgFYtzAcAY1YH1RMZBgA9KxVhUnkFAL08+rrboQcA1YglxTGtBQBcaGRBOl8EAG2WmpGf5QIA2jEyGjYtBgC4AU4AhFIGAGAd6TtTVgYAn6gAbAGuBgAFHBMqvN0DABS7lieiVwoAdD5E+2DzBgDq6iBy5IAGABgM8aXy/AoAH4ONs3/uBQBLxV7O+Q8EAFuzYeKFcQUAqXAOVFTiAwD44wNAgbUBAEvASjFoiQcAjmpEQcv9BQBxKv8maSgFAPazluIx8gAAk0bIV6OEBgCgvMkzBh0GAN9z/Pi8KAsAs5X/Bt60CwCkEbonpAoLAJtt2r8x7gUAZ4DfwjqyBQBmJdv/NUkEAG5sF20BLwEArvUWD7D7BAAqQJmNt/oDAO16hP1l6QYAe1KA7lO5AgBas7HNW18FAGY8oj8LOgQACoKLOAduBwBd2Z27m5sHAGFzn46ufQkAMtoCYfcZBwCLyoAqfBENADUJXbZmGgwAyqxgFIG6CQDCJjFqQFUDAHZ9chgZDQUADo5JC+rlBgDyFDIGtqMAANKfjBVfBgUAVJlCDPtpAQAQ7uzZ7ZoFAAIYhesWmQMAOMVcVRd5BQBPiuU5H5gDAMtv5m2l3wUACFkHCYgFCACTSoXL2NMGAOOxcOn0sgUAwcvtUkQPCwCTCiNZdYoDAB+ji94cLAUAPVp01PKkAgCKotRCnX4AAM1acIPAjQMAQJd1xYInBQCtkNmXMz8FABVN6Mc5qQMA4Dl+IsQ0AgDyk6Wh2TIGAJSEDO0R/QkA4Fcn7bMhCADFwY/lHT4HAKsWRsgQ0QUAZK8o36elCwCmywe4FWsDANf+Gp6K9wMAH49gLJylAAC3gcuO3SsFANR+hEhPsgAAx+obUb7UAgCbW57ZpL0GAAFOkZZpfgEAgM9/zvCxBwCBVEd0z08DAIWqz3irHQMAt1RebiHjBACJtnM5gkkKAISI5IRJWAoANvtCMJoRCADKZ5d4TOAHADK4zygbZwEAN8Xhon7lBwBBQUTvqvsBAKbfZMG90wMAfRfC6JzYAgD0LBi6Es0GAJd2msGKCgIA2XLMsvo5BQAg3h6PCGwFAO+O8ySsXwsAAquXYVzXBwCnL6TCSz4LAESBtBDNxwkAjzVI6rc4CAAXbqgQET0FAG1GX7ZuQQYAIM5fI6YcBAASu5mK/MMFAAiRucZ0lgAA+G8xmSH4BgDp86nxVF0AAEonvdDFvAMArdXSuISyBQCeliUQ4+UGAA9iBmMO+wQAYOZHl/UwCQAZ1OyPhkEIAMU7koxeEAMAOBg91IoFCwD7k+WH9WIEAC02zqdL2QMAt2cmtfkwAwAK8OBIWtQFAI2aeBRRjwAA0GN25f0PBABHBsLURRQHAHwPF2g+ZQIA1l7F495MBgA9/k76SWUCAG5mP69JhQYAaLvUQSmeAAA8/10fMegCANL7H/meQg4A4iwT/g2hAwDW+WseRloFAIMusPTujgcAzxaMZE/TAQAyUboq6n8AAB5Axh1ukgEAoM4X6opOBwAPvD/4Q8cAAFVUv8QDywcAmH6RqYuKBgDlYdgBHfoBAKuU39EArAwAGie9ASG6AwCvxLmIiVcPAH2f9Im/8ggAn+mO0c4/BwAymFl9lFUAAJAZpCr+RgMAWxl5gEwWAAAnunv7zJkHAFynxjtWcwcAs5wTYwjpAQDWoNkHtPgEAGlPksokjgUAVmTnu0aiBwBkuAG3JvQBAD8loZHINQYAL96O0+tqAgAFrt36yG0GAIY3oEF9HAoAffqzsWu3CAABHJFBTCYBAPm9hEX0AgcA3o7GH1E8BAD5Ne06LEgAABvTcVKv4QQAm5OSf/nBAAAXwW2ViHoBAMed+V4A7gYAzDGycpGqBAAqd+th3bYHAMfSAav5qwgA5QpjhwKIAwDb7VsEyi4LAM8yXzZDfw0A9b9Ztqk/BQCSPfNQ6MEFAPX2uZoR7AEA6WPmbW/xBwDG3hbL1qcHANLx6rzpAwcAVVSIlOnIBACCrZzatcwEAHXpEMZrWQMAXp/bDQyoBwBhTFw+2ZgDAPLj59JgfAcAcDh2URAGBACq0uzgxHsGALlzEx+UuwIAMCwAycmZBgDzSOIzZ9EDAInjS+G34gAASnj22g0sBABQeMYf6okFAJHx3bUJOwUAzPFGWSOnBgBgvi+7nLkGAGJcSNal0wYAwCPpZpSDBADd/MYwrxwFALRUrBia+QoAbu5hlqOYCwDizUAeM4QDAKYZ3sQVzQQAjp8YnOIqCQAK4HR2QqcDAMF0fk8vFAYAFTqMMZPMBADnHiusG9UGAD84kqJKUAUAzwENH8vABgAz1fWeRocBAL9HN4g4cQIA6JA65Sr1AgC6jpX+FP0FAI7Lk79e/goAh+fLitomAgChfvuigwgBAETPQnhwlAgAXHJg+XPdBwAsq0Uo3y0EALt2Mv1PIQYARlIaGI0LAAAg63nVpmgCAEeG5Sb/kwAAKZgFaP4kBQAhtnzkdVsGABnM1aWwXgEAWp2SswlSAABHa8jLm/UCAO7CkbZg1QkAB87j/Lr1BwBsgBQWVs0MAIexcGGLWAwAgRDQ41WqCgBfExeZQn0EAHDweqDP6gMARG60RqveAQDfbKQ7P6UHABrl4kKLRQUAT0QHDOaSAQCqHaJDiK4FADgVC5Eh1wYAfkGmlRoyAwBop6gEkD4BAGyHOxnJAAYAZXcNihscCgChjrN/knkLABrg23l2DQcA6Y2JQGD0DQDbzi+DRYgFAHNuDH/NNQEAW+Po3/s/BQBb5QZeGS8CAM5Lgeg3OQcAjfR7KRZxAwAglwYNnloEAOxEpxr3WgIAo6uKy/AaBABeHYlOis8CAKJr0Bd+SAUAlmUtAyqHCwDfSJPAKF4GAMJAzrJrewoAaR2J8vemBwBnDxEHh/0DALItqRaHbwIAJzB1G6rNAQBhJrVYvgQFAFKC5dabBAIASe+aao39AQChbyG3Z8sHAIK5w1P/egYAKJbaEKYOAgBZVPytGgEGAH34ywLI0AYAe0xV7b9BCQBiQu9nttsGANx+hSYxjwUAQJN3i+GcDgA8+JXPbZIHAOwrDhIlLgQAFfrxbek9BgDM+fNQa/AEAC+2sMFc/AYAy3mYsihVBwA9WhLSj5oHALhqdEuNfAIADCECP4n4AAAQV66zllUBAMokUX4WMQcAP+G76Dh7CQBVkC+UW9ULAD6RvpUUnAgAbPsaJE6qAwCieZE/0jkHAMToudv6MgYASAz+K1LIBwCpWu+DCe0GAPS1h3Yj0gAA9QUzKr84AQCYZdgkXfQBAP5gIa1LJwUAKtFYHQS2AQB6aOSmyi8DAN/MhydzpAcAQAZ/fEIeCQBjjF84WTYIAPprdtnq9AUAACZsM/ZGBwD1mn3FjW4FAHhPvhe+swUASy/4jJK/AwARbwpgVS4FANbr75x+YgQAHJdsq0XzAgDp52NuKFMGAK0jirdhEAUAAUW1rJlJAQBm7QdwkbQHAMqiU90oGwwAheqHX+h7AwBBXqjS40sHAKZsyfqHvgkAzAj+IDbQCQBksISrXPsFALCFgnc+UQIAQ+AlMThXBAA9Im61o70GAE+Ebze6IgEAVOW0os0yAgBA+A+jK0IAAPVDe2bnUQcAPl/aVRcmBgCOtlK/cCwAAOFyjUW/Mg0Am7WW55YPDACinW+d9y4CAHfKvmerAQUAQ+s/fmmwBgC7LwtdS+wHAFBUWRDpAAIAXnEFcQVCBwBgD1MicPACAO8JpPA0YwIAwKNi30rwAADZtou07eAFAAPA+6RKwwcAJKxcTk7XBwCyQTT0N8wBAKauzsnxVgYA7FqtrBwDBwBXbHHQjDABAEIZlHMTHAwAlfFy90ajCwBPMsdcWlYHABFKJNWgHAAAE4dBZ7AWAQCu7VWMfaUAAAM4EJyAxgYAyGra4hJRBQBauj0KPTYGAAz0povJGQMAx26jA0voAgB87/a5EVkAANzqLlHzrAkAaCppOZhjCgAGBYM0omkGANQDBgySiwYAsmQcne9VDQC7Dt/1g5kDACaYlYkl6gEA1s0Dh2POBgAFhYl4FjEGAHCims/OswYACL1zO7pwBwDUhuH3dRQBALwrickbJQAAWsz/m6tOAgAXOBPe9HUGAAqz2jvZ9gcAJdS/pazzAQBglxwcUvoCAM35J86AIQYA0yyIC0UPDgD8ghdrA1IEAMWBdrCVLQAAsgWS+RyQBQC07F5uaJACAEwWcN+ZPQEAysDlIcNeAwApQPQ34zoBAKctP4GOAAQAOgyOLydABgDaXuXpbcABAKppbf9AKwUA+n83CYgbCwArTNFcYjYFANEXLiWvFgUAK9Pn+JaABwDixD6j1noHACHTEdzFFwcA5COYVRShBACx4qFQzgYDANvC/qE4zwQA51z6DWWqAgAVlPGoFkkFAHgS52/JDQAAuD7mhCdfBQCRYKLTynMDAJq73Yn7qAYAN37Z1TWMBwCyLO90Nm4GAI/dU6xHQwMAKhGl7UcVCgB89cmCTWMEAFLWpmiSJAQA9y9/aG0zBgCg2SZOT/4EAEFUlD0PBAAA04ZZ/TnpBQDfmwFHISoBALKc0OdmxAQA3QPSlVv6BgBUojSjUDUGADZ7VHJFWAIAdxMcgVhcBwAbF8w3xtMMAOI0fXQwPQMA16f6upKaCwA3z2m17dYHAKAs3KWUAQYAphBedFmvBQB1SAA+9agHAHivfSym7gMATieT5hPHBACks256G+0GABWOfWnOKgYAdbAqKbhmAgCcXGagNoQGAGkQIOgX0wYAyqMsXYGQCACgmRTr8T8IABjjUPBgOQoAEBbJaTY3DQAnPy8g6DUCAIAXti6fTAQAA3AdW5AwBgDR6nTSyPwEAHiraH9uewEAV1IOmqsUAACli39WOZkAAII8Qip7tAQALcR65deIBgCHj2daS8sBANQHoKJiqgwAbS32OA4eBgCCR8yPiC8IAP8b8oMrVgcA9i7Y0g/cCgBs/Eo5a8AEAMw29ksbkwQAeCMy0GArBwAli4HGJ1ECAEPnjae8MAMATnQZEYT/BgAFk+ToYMUCAHql5e9PJQcA36dgxeJ6BgDxabPhG8MDAHJCy/mTvAgALBhz2/n4AwDE4brqNbIKABlVKYe/3QIA1eeXEOwcBADuipQITYYEAB72jUM30gUAZ3AfYIWyAgBT1+a6vF0CAC0mNBG2MAMAioBtotcZBgDyvq3Cs8MDAFJ/7J58hwYAbbbh67m+AwCH8pHNRGsCAIMDc2KT8gcANpxFUXn9BwDnSS1RTFAHAF/FO37thwgAJcdJAbHeBwB1dDiPR0gAAD6KZ9mXkwYA83bJVoF8BgBsIolVTesCAArBweYJxwIAeu5mh2qvAgBs2aF5qooAALAvm9WSLwQAB5wAQCx1AQDOYv/paI4AAPnyuArVCQ0A5OV7JKu4CQCF5LLmstkNADgTmkel+gwAcI9zvRPLBACtMMFLClAFAJWGk3qhJwEAbeM0+iYqAAAozB4u0YQFAKPrfvjz8QIASrYV5XWMBADwHgdSaVsHAAZUlkJt1AUAn5+YBmF0BwDiCjw1HpoBAL29ltXNcgkAgxaI3x1zCAAUgU/WJgQJANmjqdhPGgcAaiaQOb02BwDDBfq6YHUEAKMvzKvcGAQAgobPzpFZAwBgjEupcUMCAMMgHLFGFQQAtLM0k1AtAwCqcK4sEGwBAEX0G9UNcgEAIZivL2auBQD6hytaKRIEALPqk+JhUg0Ay2WbdSZkCABHahGuZQIEALzlugQjwAYArZXRuAt2CADp1n71iJsBADmjBBm/zQQALE9OzUkrBADZCRl3LhoHANJSuz4VTgEAioHmzRcaBgAniBA0rT0FALZVXMUyKwMAo0eTXxb5AgCsM7zpS7MGAMDycWVlaQwAPkJvzmGqCACgJxvXQPkLAGnRc53xhQkA3OZie5wbCACywHg6ZC8HAHueT8BF3gMAXPowjdYGBwAkL44+9pYGAC2S8BgsAQIAKZ3IWuVVAwABcewUtOgDAJAMUnywnQMA4e93mx70BgC65IS39YoAAEsszInSFAsATbzx4lA0CgDzki85k80IAHxrlGoMNwkAl/1aHTxCBgAzJR+I3JkEAAbFdmTyTgMAlxR00gfRBACz/W69xEYDAKFjEdd5KwMAarP87dn4BQCQOb/c6OYBAArzijRPlwcAfJzxTnLmBgDiE7zvpYAEAAwizkLkTAkAyxYlp4CJCQB2ZrgN+HIIAG1S2h8zAwcAyJF21DFLCgBxIGIBC+cBAGqh+LVj8QEAF9QaNK9qBQD3MNg1lpgHAHvLAHaiegQAw/gVwO0eBABKhe8njc8HAPmTRljjiQIApwmzV3hKAADaTdGFtUUFAOEhs+PQ5AQAQKzS4x9FBwCNqe549mYGAK3+Z4aFOAgAjEzmwy3SBAAPOtSgXicHAPfM130TgQYAOJq3upznAQBqpolEISoCAKUrM5wv9gAAOV871ollBACWP+x5+eoHAKi5chXo6wQASmlhXX8bAgBxY6MB+sABAD1qk4wOKwgAIM22WDu4BgCAJufT2H4DAGIqn9s3oAgAu9KxGVQADAD/PZQitgQGAFgadPaZyAEA+zLy4hkCBgDL+aeSrl8DAMqx8xQ2+gAA8IK+ub3+AwAAFJKVSOcFAAYngjjqUwUAjMjPJHyhBQAK9K4YovsBAJQBez4EVwYA5+nvVRvBBQD7dKDGe3MHAMxV4xzk6ggAdfc/0TXFBgA+9cj6SJQEAGo16MZ0TwMAotsHBnitAAC2PrZ+OiEHAIaMqqzjkgMArzWKPuk0BQCXyQL9EIsAAAUeuKzCagIAeTvOmIydAACsUE3+F14CAKch8Xb1fwcAK3L8sPnlDADHKA2blG8EACbvF13mzQwAl5b4KKi7BgB29gQe15sAAEWh8kHIWgIAcTiCrH6kAQAaWGzDqKgBAPupQhR1VQIAATn+kGa8AQBavFovExQDACjVMlGDEQYAV4q0jkvyBQC39vcE1VkFAP1m0vbnkQgAiHMD72BgAwCGEh3siIcJAK+ORxxEhwIAvVQzauojAQDVVOuzeIMDAO6Uj6eq1AQATad16AKgBAB8sWcThQsBAOMHWC2xGgAAli3jQZAYBQAxAgkrBlsAAI+352YXyQAA7DihVQ+qAACKkSwelqMEAB4/I/NE1gcAZMACnp/GCQCXaCbl5WoDAHmL09rBjwgAQL3Z6s6KBgCgu+b44DsEADtOYfzfjwYA4Dtbqx3pBADwLyHJ1LEDANuxP85rzQIAEMLX8w7JBAAWh4Gg9ZYEALg5woz4nAcA2/hsMJzLAgCPUFsNdpUFAJAnAv3rywIABRHsKoK4CADLvCbSz9EMAL1xSfqyFQUAFUX1XSzLAgCXY6oE4b8BACVsmf+UFAEAAFg+YlFCBgC+RODFn9QAACnL7UP6CQcAyir9Y4xdAgBh/d8pzcUEAAWvSOvALgMAfLf5kZOPAQCBDM+eAg8HALmwEF6qrwoATCVVg+AdBgCNwuN9WOsIANS7fZ+78AQAvXQqWspOBAAzPu0uswcDAMLoPLCKdAYAvBC4mg18BQCM6SSiZCwEABTDptjVtwAAQ9WVezJIBAC6pOOBZhQAAAxOw60UhwMAMI4pDm/yBADexxJFInICAPx1qUKKuwsA7hdrtNXyBgDlcDEiqbYHAOa34z9xUwgAwWt//TWXAQAuNMVJr5IEAFcDWt9cNgIAYLv/pzghAwD+RkbR96ECAMxEivFdGwEAZkLIQtCQAwB13I8q4+8BADgSrudekgYAMujQgZKvBAD4HRkR+f4AAGNhbGxlZCBgUmVzdWx0Ojp1bndyYXAoKWAgb24gYW4gYEVycmAgdmFsdWUACAAAAAgAAAAEAAAACQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9obWFjLTAuNy4wL3NyYy9saWIucnMAAOx7EABSAAAAdgAAABEAAADsexAAUgAAAHcAAAARAAAA7HsQAFIAAACBAAAAKAAAAOx7EABSAAAAgQAAABEAAADsexAAUgAAAIIAAAAeAAAA7HsQAFIAAACCAAAAEQAAAGFzc2VydGlvbiBmYWlsZWQ6IHNlbGYubmV4dCA8IEdMT0JBTF9TVEFDS19DQVA8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz7OfBAAHgAAAAIAAAACAAAAc3JjL2JpcDM5LnJz/HwQAAwAAAASAAAAEwAAAAoAAAAEAAAABAAAAAsAAAD8fBAADAAAAB0AAAAFAAAAbW5lbW9uaWM4fRAACAAAAPx8EAAMAAAAKwAAABQAAAD8fBAADAAAADoAAAAUAAAAU2VjcmV0S2V5Y2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQwAAAAoAAAABAAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLm5leHQgPCBHTE9CQUxfU1RBQ0tfQ0FQPDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+2n0QAB4AAAACAAAAAgAAAFByb3ZpZGVkIHBhaXIgaXMgaW52YWxpZC5zcmMvZWQyNTUxOS5ycwAhfhAADgAAAAwAAAATAAAAIX4QAA4AAAAcAAAAEgAAAFByb3ZpZGVkIHB1YmxpYyBrZXkgaXMgaW52YWxpZC4AIX4QAA4AAAAmAAAAEwAAAA4AAAAEAAAABAAAAA8AAABUcmllZCB0byBzaHJpbmsgdG8gYSBsYXJnZXIgY2FwYWNpdHk8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AALR+EAAeAAAAAgAAAAIAAAAQAAAAAAAAAAEAAAARAAAAEgAAABMAAAAUAAAAAAAAAAEAAAARAAAAEgAAABMAAAAVAAAABAAAAAQAAAAWAAAAFwAAABgAAABybmdwcm90by1uYW1lRXhwYW5kU2VjcmV0S2V5c21pbmlza25vU2VjcmV0S2V5QW4gZWQyNTUxOS1saWtlIGV4cGFuZGVkIHNlY3JldCBrZXkgYXMgNjQgYnl0ZXMsIGFzIHNwZWNpZmllZCBpbiBSRkM4MDMyLgAAAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYA13E8k/znDABDsrb+Qc8CAHYafQocWAcA8DJNUy0XBwDSh/pjwJAFAKjVtEJgpQEAU9GeFcyJAQAErjyq3rgFANi1EU/wqgIAkpxmWlm7BgBfepuls6gCAH8I71mzqwMArwXbxKj1BAAFQtAHqLkFAFDqE1uvAQcAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAnwn8jrlRAwAOBaekv48GABuXnZVJKgQA/Z5GGuWTAwBYHjIQ6YAGAL8YaAUKBQYAvzJVH8wqBgAl+snMQYECAIPmcfRhTQIAWkTH9DN5AgAJ/3bE6fsDAEJLLphrrwAA5Xi6URKtAACIfO7trhUHAFM19svQ+QcAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAMXEVd+vuBABBB/EVGSABAFacbNqcZgkAbDTbMsBeBADDLGq7Vx4FAKSMfXu2BgAAMynnRPqEAACKb13lThUBAJBzLoRdQgQAF+QaxGSLAwBxS+oCZzIEALUwYDc0aAAAgMP5EgXvAACEJVHyqfEAANbwqZGOCwEAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAfD7dBGZZDwA1iwUOUfwOAAzMso0MZwMALzPOmdiXAgDOGwZ2XpEIANk0kvPtXQcAVDwfqzYcAADa9Vjuj/AAADfWoBOW4QAA4CATSgKpAwAakaLJ2fUBAPj8+pR5EQcAxY3iyqjYAgCHDAmysUoHAMTswsUHaQIAHZwvYw7dBADZpSIm0c4KANlCR2HpjQkA07Xbb6mcBwDuAJrUN90GAF5RqklUYwMAq11H0HjhAwASl6ESRwsFAK30D4bC3AIAMT3w1nYNAwDH5AYhF0QEAIgt7a9REgAAWk/tm/w0BQA0Us85WtgFAGToEnFpDAEA8sdYg6AqBgCU4UgIRG8EACv1qHG3RwQAHdNpMrp3AwCAUPW6+TsIAN5fvn0nxAMAkkzUrzWjBQA+dZlAFsEAACPkbwCHBAcAb9a+ymFeAgAEZljMKOEDAOLHjy6LlgUAz2G91aNJAADm9h5bUBYBAG5YNIbXZgUAvS9axoVCDQAfdPjMYl4FAESQsWG5awwAOCBxBTQVCQA6eTRfuk8JADQIwZyfpAcAxiKKeBO1AgBbOfJuS/8FAL8H9lqO7AIAw+ylvHU5AwDU94VpFkYHAJrnCgA5mQAAevlkeUyEBQA9W/nhFzYBAMU/qM4pSAEApexxTi8LBwA8ZPyOFCgHAHZbmQM+dQgAZmersl+/DQDWNUW8w18IAMKV3ZeEewMA6P+01kkVBgA40bEtohcCAJ6wLgbPuQAAWPflcZz9AgDd3q9SrrMAAJfkGWannQEAjlXSVAb6BgDUQV7SGYIHAFHGdXR2cwMAkGUkFMuVCABnrKYq2AIIAFBIvIPxQgwAQwYKHE9GBgAHCXMFWb8GANmt0UD9mQIA9+UEmt7yBQBZHMy67sAHAAop+LGhzAQAj7HDVur7AQCKW0Hh8XgHAPTB73RY9wYAfwIZQGmKAgBN3GupNysFADWmZ88hJQAA0V4vdyBnBAAi1lnzwDIGAFLioysJsgIAgCYRfCViDgDVfJ89dQEIAJRSnQoL7gcAJ8pM6/uBAwCdYz46H4QHAF9EwzDqdgYAghPnpwD6AwA02z2WLSMBAI0HC+eSVgMAH3p3FMpHAgDQ/OhrVdsGAI4E+uJfKwEAkh5vrSZ8CwDkeyJxCWoEAEybLQ0vcgQAOuBOIEbcAwBseSA86fcGAE3j/JbE+wAAPq59a751BQAJ5s6FFaMEAP8wOQLpNwAAEvuWb7dJBwAFrqauBPYCAOsjk5PcNwYAR40Em639AwD3WgTUsKgAAAIe8BDs/AAARU4kxJ3SAgC+R8Ebe5IGADkIrDSFMAgAQD8DZDaFBACr/maRdxMEAEQe/kmmWAUAiczvrjVGBAC68odIQ/8BAEQtDiKB+QAAUTwYpxqQBADw+BqMVLcBABaBNlOMhAcA6T0452QbAACPfFiw+wkBANEmt4e4GwQAm5FmfFlMCwDDD5m2UKEHAHQikp3rKwUAGoZkce0OBwCpxnDgcagIAL5GQ3REfQAAHahkpbaCAgBrI3X4gO0EAFAMRR2++wYA2/wSjHLrBACJibxLmbUBAGAGTKh7SwcAuK7N8XhWBwAM8dawBjICAF1o8gBz7gMAGHUehEd5CgB+6NqIcywLAOgbl9OtFAQA8Q4vg1AYCACI+yxqfNQHALfWfZ7kVQIAup7VYyGMAwBFWAAqH4YDAMmuy0we4QIAEnkpdhU4AQDg1vCOFNACAPuH540qUgMA0vl0XgXuAgATCDH2OEAGAJ5M01jPSAEAWnXkmn0vBwBK/A9pHnEPABUNWzWigg0As7aF6M/cCADp6tS6/ngKACfwNHn2kgQA1ChVgdDeBwASZhpRYYQFAEQV3lAu6gUA29XroS//AwBmOZOMH2gCADUWkyEFhAMAUoYwSvF0BgCQSKmInL0DAMbpL9BNEAQApWoJ2wZOCQAjsOaJnCEJANqihtSreAoAH5VgkrJACgDJ70haWxYIACpCJBFevwIAVq5WZxRzBgAw6Iea2UoBAP2AsGXK6gEA9foKsGPIAgB2aoSgdKQAADIemO+lmQAA5r9LPK6oAgAsgxSvNFwEAOz/m322kQUAXbUYn3GzCQA204OMMVQHAJeXkbcXfAoAYJsIhLBFCQAAA2f4tIkEAPqbtIAcDQcAJUaRfX7VAwBF5WUhcsADAE/gGTi55QUA96h87ALeAwDvkus6LRACAEY6DNUijAYATomFk6guBACM81W/nl8HAMuWpLtfnwQAG1ecHoxiBQCrIugIsZgFABo2Ka6PXQUAKHup0citCAB0hihsGmoIANTPW4oQmgQAEmZ9jowXBgB1A3FzNPABAJhgSmFJOgcApr/chkpgBQC2ZBd81NEAAFEuajEIHAAARVDJRduzAgAMMI2BT2MBAHTin+iJCQIAG+zqhYsnDADN4ntlWe8IAG+HWGnRLw8ALwsmBbLpCgBYcA+VuTAPAH/MLTr9dwcAMkkS+6mUBQDwFcqAjh8AAGky7DzRFAcAZ8rQ0T5AAABSxU6HNS0DACm58Y0E8wEAI5sXO9cAAwALfaPle+YGAAODMFR0vQUAKnnnFSGTDAC3MLm7uVcEACYyGYtdjwYAVtQej04WBAB/BiOxfbsFAMJMsiiV0QIA8y8wuGasBABRrf3ZyAEHACc3W1yzwQYACjgHgKczAQC+YsrGZ/QBACzBXSojxAIAh7ATwB1VBwDNO7ARDGkAAA6P1abcQAcAPEN4BFeMAgBjpHMoUNgBAJzU3n4eZAcAcfVM1e3sAQCwwlZSP8ACAE7Oz1IH7gAA6fsWgd1gBgDr/w8TZ1EFAFyVhbiCxgEA6mOpX9JhAQB9pFN7dRgHACEvD4vhGQYABOzB5N/7BQCSux7ImNcFAGvZ24tGmQYANRmpauY9DQAam1ka+EUIAJJBIb2o9wsAGTMSpE0dBwCixObE4ZMKAM/+2vRGLwcAo/fe+o+UAgAEvPP9zR4BACXt/o/pwgMABTlHmiElBQDhElGSSxMGAO0GtCuUuwYA4t3ARcRwAACj18Qi2BEEADLwR8QFtgUAOfDn8Mb+CQB8RyxpvM4DAF6pGWqYdwgADot3oarqBgCrxUzvL/EKAIl8xCBZgAUALJf5cUeSAQBAwJ/fvYsDAIGykgAA9wEA64rq3HZKAgBAx8DfsiIFAEjhgDQZ6AcAuUFDoNk/AwC8IIpnY8gDAEOKUbIH5gUAAc+WpRxDDAAEFIB82hUIALQQj2+bPAgAFkCTImk0CABW5Dkx8wEKABgY32yPHQMAFksUS2z4AQCdPte4dZgDALOn/9nw+wIA3cy2ynoGBQBRnQMIa38CAKrfAIAvgAQAJcVioJKWAAAXWAeR6roBAGAkhqjLlwMA53kTyPvDBQACL14lvBsEAFCGmVb3ow4AQXzg1H8pCQAbHiwCtHEHALJZWfCTMAEAGMYuLzW9AQCG6oibeHUAALlI6hcRHQYA5mYHMp0zAgCnLzpRhtkFAA8b4Zk6PwYAbbLWzw6KAgCPjeE1aDsFAHGZIYmhMQMAnHJ1nTovCQDJxFPpAA0JAIkvbxHfAwYAiODgdsI9AwCaZP8ZlqwJAMaAT/tFbwYAov657jjMAwAf23ByZAcBAMgNdOrxEAcA3zu4xmcRAwBoEEtSQjgDAEX+MJ3TfQcA0KBBIUOJAQAlwrhO/ogAAIvwQWNDEgYAJSYtGuNJAwBssaZ/ehMIANt+d5KugQ4AUNz4xb8iAgCQjRejKlIJAI2JTofbQQUAMxuE+4AtBgCX+ifwbj4AAOgzlp48oAcA7+UJI75uBAA4SWFpUy8AAIcFoq3lVgMAAvlrn8gbAQDbyBlkdDYAAENSUA/nXwQAfhSVyCBJCgBdTJRh7AcJAB7AF+BSJwcAeumi3bciCQChV9v2GWYJAIwLDJamdQAASRvkxeHdBgBBo21RPy4EAJ7nqP0DagEAOQ46YtEoBAD9CKMBREoHAAmBVbnUbgAAZ4ig9vFGBwAhI29cb2MEANML1pIV2AEA1cWFe5+2DQDrUFYXLXoJAJ3Bv20+zAQADr5zOB0+BwD4ChvV9qULAF+sDaZWhwYAJuyKe3VdBQC9gF/0PTgDAKaWn4w/eAYAzZ54pzQCAgBSsnhxtg0CANoOLNqjOgcA03AcwEWQBwBZECUVe7MBAP7PUyNozQcA4PSsaGDNBQDMdHr8mgcLALNkC2WXgAUAmU6crKt/BADNsrJTAu8LALb6h9hbpAEAfMFtB0hXBgCoEaoAgLkFAHQJCMnsoQQAwL1jiIyDAgAwUEZKz7ADAC169a64IgAArSXpdwatAgB6RddnQQkEAIJqYIrLHQIAujF3vvoADQBQMxHDU8wHAIENCP5lzwcAoRsBZtnFAwD2xvbbQNgFAMifnYxGBAAAjGt5VIXaBQAlAJVwvrgDAAmmpi2J1QYAMUoZCD28AACL4Z8wDTgGAA3uuCw81wQAtsC6rYK4BgC+TN3dq24DABmsMmInpAMAuH5E23LBCAB+p7cFxfgDABA/f/lXqAYAOuB/VsD8DAAZToKeDHcIAPqEcIosQwIAaKmoPPd7BABnKCZ2kWMBAM4QgE/f6AUA3hbqfBf/AQD9tbVFmtkBAOyZJE9nIwUAEyYYJvr4AACYjASYc48FAAAV1E8mnwMAznsJ/qtKCwAyOiUD/DsMAPK3kf7HmwIAFkqE5GGnCABew3ISYlwOAJzi59sXNAUA9ZRzgnNFBQDdUPam7mUFAEnHjXRQIAQAiYhGcy1xAQDdkzHO+IkDAOV8F7gk1AIAzUA0DfpzAACXntQMAjkBAM4ZqwCYLwIAmf1umt2fCgA/KCiplMYHADpL5O7N9wYAw1yyBzJaBQCMWThNGhcMAMv4nj6KNgIAC6ziCKpUBAAAp48/kpAEAC9YpJ6qcgMAYkfWbEE/AQCMTMmZqlgHAET/ABcA9gUAvQGMSE5pBwDW7kjp/dUAAL10pU8hCAUAwwPQU7sVCgDCqCx5nhcJAKFAyGrpoAEAtjq74pMjCgDKhkyKdacLAEv+1j4VaQIAQJj4riMqBwCcaZlSvlIAABYjE+/lpQMAuvrGDpYvAgB2UK6T9hEBAJDKlKq/4wMAh7h2lHlFBAB5SEYSCUoCAH/e+BX92QUAC1LX7ipNBADkp8LSZQgFAEDqOFJbcAoAljtdsnBsDAC4fqR/GLwLAH9yY23TCAQAYmCm9vj6BQBr3qgtibsCAObix/DUaQcA+/gUWfMyAwAMwobqFQEHAKitJNqIbQEA3ypmIgaYAQCdWhm86wEFAPsG6RzYUAQAP3SuHJbYBAAOun2Mw70GAGO04ae00wcA863i3kuECACqY5YnrcsEAHVSIKahtgMAz23QkSfoAgCHPKnKcj0CAPSqaKu38AUARWO61CXeAgDNH9egJJABABoQXxFlXwEACJcUZ5DpBACvpcvR2BkBAAcg/s771wcAlJDC88VdDACuebUgUkULAIkGHmPBcAgAIJsOY8BrCgCMzW0ZzfkEAAEoayZqHgcAXd/ic66aAACjsRmy2A0EAA3eF0X7RgUAdXvoNVSXBQBoN3tq2JcCADJjTC9agwQAYEFDXzBwAACuVk4B3YMBAKCHQwjdzAcAgMxgZxiEBABhM1NlVkMHAAG4NmNoLwgAMEP2RlQiDQALGUioPFkLABcEJm0sQgYAlLsXSJASAgD1VLjeGaMFAH3aYODUqQcADB3WDr0oBACnmoRemhgDAEKyWR+7rAYADGNTR+/2BwCpLSopRvMBANaijTCYcwIAUyRwCkwOCQAz13ujr9oEAGGJPtxrnwwA5drs3P/+AQDDklSUwnIFABPUXkMojQMAWCiZGU8GBADNQ/W+D2gHADyN1YPdqgEAw+jrellpAgC+MM3WRccHAO9431V3fAIAo3+TM2h3AQBVGEQWUUAFALwFjEmF+QcAUGO/D1IVDgBp2nS/6bkIAGgRIAiD/gwAQt4nYfdzCQCwac1TJg8LABfhC5+IzgEACQdRlGpvAwC0FgBySPIHAJHP4dEeggEAH6NwxC5sBwCFDMGqOMkAAEFxee1kGwQAbV4YwbG+AQAHD2CQVO0BAEeWFT8n8QIAwAunVdeLCAAI5lyIOp4EANZaG4iFZQkAXU/TaHXCAwBf3H6ZwYoDABEe4Ip8/AEA5+hzVU0JAgDSSfW7PMoFAENBxewg+QQAtoWtcuXZBQA7sVGnF7UGAMyAsXDTzwAAGvTRJXk3BQCiCGBWVk4DAJ7+y9n8LQIAjuA7ELRZBADdKi0/S5oFAOuOu8g01wcACUpZvjw5AgDeTIJ3mP4IANkMDcPg0gMAu3FmaJf1AwCZObZ+WKoAABnGkrXH4wAAjEQFbJGyBgA7kboK0TQDANvPgbXNRQAANo86VeDjBQCy/x4EswsFAAD/B/MDwwQA7UTZDVgDBAA/ZZJ9940MAOlJs+OfigMA4a8KhYnqCABpcKtRsRYMAIWMshfWOwIAYVp95y7nBgDeTRf/cqkBAA/Gc2Nj4gMAq7J4jxvWAACwNsHp79cAANUKZIkcqwEAlx/0roJfBQAN7RfzV2kEAH4ndK+ikQEA6A5GT0MrDgD70/rAxpQCAA9Me5NogwYAW4cQKfjJBQBFBeDb5zcKADEUPMVL9wYAwtm7XQ7EAQCXXK6c+8gGANq34VxchAQAzLVQ5ODiBwAwtAFn7XUFACYAon/h0wQAU0KMiPyRBwDBigeZuvECABURm2n6GgcAw1A7Rxw8AgBIHeIdZ+cDAOihR1X6JgMA2a9fwk0ODQCIj8f7MQcIAB22UzmbbwYAucw8KPRVBQDnYBn7Z90HANT+r6EHRwEAHCucLhQhAACAGPhIGMcAAIY8I9jZSwQAMFj+jlfoBgC1QXBtWwQEABV+NPPWxAQAXRmPmPzdBADhZaM+F/YEAIhFrvnaRQ4AOmLbYzfUBwD5iApQ+YsLAMkffcHP7AcAHoOCByjKBADW17F9M7gHAPuVOO9tEQUAR36q2v2TAQBvh+g3PMkCAPqDxSgaQwMAediL2kmQBAAcwXpAqLQEANTw65n7pgYAxiPktrUiCQDV3fHfUB4KAL91TjJ2PQcAjkGVVEiIBQBeLPSp/TYBAOtVCFa7wQYASK0TfhIfBwDsWpAEs8YFAMebiI5rdQMAiTFKkXZfBwDRvQWjsd8EACkfgQX/swMALtk8KGLtBgDhUuxDFV0GAI2+EDUYIgAAbHowQwFxAgCr84u0j9gDAHqPwU7rSQoAXin/XRE2CQAD1B9EfDgJABQtrV44ZgcAXgkGi08ZAABiO4L2eIQAAAhz04mGAQYABrgXznGgBgD4ipeH0cMDALp2gsjhrwcAaK3IgfIdBQBdJKS9BkkGAO3xqiYbFwMA0UeKsti3DQDANJ4U7sICAFP8mmL1dgcAqUn8UOr0AQAkRDOmFMUGAKhMVpeQMQcAJTUjvE6EAQDh7v1DRR0CANIb/6onrQEACM9zSP0hAgBBYxU6TyACAGSkZUBBNwUAg8/tOww8BAAgpm5wflUFACS5b1mqjQQAgJdMyF0dBgCewkAw6H0EAOcHZbLeiQkAmUfc+ubUBACn6KB/g4wNAMecpVxmjgIA2Q2UFcdlAQCVHKE6X3gAAGmE49eYewUAhK3Mb912BgBYkPyWhWgBAJ9hA9RqbwYA73J3qFnXBACkvnNhboUHAFdqLD/3xAEAhDR8/G5wBgBtNuw5eJgGACZ/z5UfcwAAvOS8jnWuCwD12retWQQHALugXzC9TwIAz6F1zJgKBAAzdQoi4YwHAJfB4RB6IQYAZL/RgKyVBwCzK7SRSdsBAHJDmVtgaQQAWJpcceMxBgCPcs/vz+kHACHOSCgW/gUA9bF8XS2FAQAP5Vy+Dw0GAHV740bioQUAkNX/Be4aDQDZdzYETLQKABqWlOFPIQEAy+mpOa7hAAD3+Sa1yEMFAB3pZ4BJGQEAF8lvRJ14BACOt04Hq4cEAEPjjF470wEARhvrn0E+AQCk5l1WH3ICAJq78u5SDAYAEW2ufMLFCwAEbpWRlGoLAKUdE8m6JAkAXCsg3ve2CwBlm40kdw0HAPGL/Tu8iQUAa0Gjaj75BgBIrsHWo8AEAGpYCyaHVQUA/MwSw8kLAQBboMI+S+gCAFEVPPCinQYAe6ZhRhc6AgA48omivAkCAG+XOr1VNwYAt6zxlxgQBwC4B3u3LNgLAPRpdz0IhAYAB84tRygrDQBRfHNRN3YCAFMI0So+oAcAqzatxtwTAgDWvdVA4qYBAN/++PxPwgcAFrxIHMzYAACpGbRu0wIEAFKgFIz2zgcAOdHCWyXxAABqGDHU53MDABatp9gtDAcAAH7tuH2WBAA6Ui/Q7loJALuU0JGVFAYABnDBBPJyBgBTaoEThisLAA7sb59QlAEArKwxytgoBQD6ubhzbYIHALP54JnLSgIASDk2xvrgAgBkzUjkvvcHADwP2hAP4QQA6SCruWyTAwDQbOpP/KAHAKQ1xxWSFwQAIc1rKLkzDgCUnNu6s8oOAPm93344TgcA2Q+KxRNDCQAbJGJWqB8LACrt3NfnlAAAjhGOc/poAAAr7l8KZBsEANQZ8J1wuwYAmc0wSjQABwD0IjYuQmwCAPC1BWoG8wAApoAEj0TiBACV8NvgzUQCAFKZKjGySwIAWFz49SoMCAA+iPJMn2AIABLKobVu6AYA0czvokSLDgC0/p+v0tEIAMNn3jIX7QAANRYpacMIAwBQ0vJI8z4DALuhoV5HBAAAiOFx6OP+AADfHmIyoYoCADs1r0wkKwQAiuDCTAZrBgDTvQwCILsGADGFcXnNagEArbaHeMXGCQAqWdcf8qsNAHmGUxLUCwUAUTEncQuACwBggbE07WQBAD0dmy2vcgcAW06LRIbUBgCoGI3dWM4CAIs8UGefhAEAApNr7+AjAQCa5i8ZTNkGAA9poiJSRwUAs7iGnXiTBgDcafu9w/UBAD8HYfygjQcAgToMaPGABwBT1Pw8XaMKAPfdx83lBQgAI6x4gIjuBgA4azFLqlQIAGrGK+UoXQEAfstRAx4OAwCMH7F0LwoDAAPe1wwSnQMAsVay7l3SAgC4fCYZjUYAAPn7tancjAMA4qEsXLC7AQAzlY51FbADANq3agphNAEAFfXRd+dlCgCkOR5M9fEIAEUmUpUb8AIAbd6d29j9BADMl7qMh1QGAP6w9o3HjgMAImqjvq48AQBqX07lxusFALgOPZAEKAMADbKi2y8QAgCh5lwFBeQGANMypTVKAgUAnfLaVJD2AQDVi3oNHV0BAMuesl1yrQAAhW8Fmwy8BwDY//q//hwFAEn1Tem7SgwAIDHj17vsBwCZIzD1dfYEAFckToOxZwIAiLt4wxmuBgAS1dlee0UHAPsFPXgNKAMAAxq3//yuBAAeFxUENjYFAGV4BwkzMQIAvK80Q0RRAgDoVjeFw7ACAIYqKrfLvAAAlhL+UExeDQAMw+8T3V8IAO3lgMPGwAkAp2L74x3hAwDzCJHWj2cGAMipseovlgYAC6O5j6KsBgCYnxvKt20FAN0YcElYnwMAa521Ck8CBADCY2hjMfoGALBCfqblCgEAMdof8Lt6AgC8T+a5p4ADANTqCCEu1AIAgHVTDw17CQAthMnAY2IJAKM5RX6CqwQAOtdD2w03BgAjtHk6vyAMAJvS35QVEwUA/lKN6SemAwBhVoVBQBUBAISDn9B1kQEALY2LYLJ2BgBHK1scZboAACcQcGMjhgUA28YZwtbEAADeWIb/PfAAAM/Aqf/SRQcAV07TIVffBgAGDHp2L/MEACBux+qr1QkA4+EE4ekcDADbwVS+FW4IAL3IySseWgIA6jew88gEAQCYbKlvVwUEAG+H44hq6AIAz2C5ziOuAQBKmTIZh10CAG4LVjvWuQYActTIFCjfAgDtpArivvsAAOx4EobtjQUAlcnCtqhbAwC/hTGLpd4JAL27I81VtAQA+INIwBnsBQDVMbWWposIAFzFZvKTNwcAAjvJqYi5AADbJSOjDpsAAF58wXGufAMAX0iF3jn/AgB6xe/D7j4FAP0uAumf+gIAVIETLMeZBgD4H70edSoHAM9HSTtjIAEA9w8SSUcxBQBX0MD3za8FAO2NeBvnqQcAiAw7j3DvBQCTszy+M3QIAEIAYZF4mAQAcgFdf52dBwDEnjsBk8IDAMrKOV+4wgAAWU2bqTBdAwD0l+lcwEQBAO9/NIoLlgQA93Rd8RHaAQCt/sAZrE8FAG2v5+1z2AIAbvldTuECCgBLtT68AuoCAGQ1iLJ1iAMA3ek6UYwpCQD/FaAYNlQIAAk0N0NkMQIAryI7UJXeBQDf4uobIJkGAHpz/0lY2wMA+gdHZXPnAgDBI0yX9L0CAL1h0si5swQAKLypsuhqAgBRXBYQggYDAHnQYjNEsQQAuJxSHOlUBADPcr/GmEwKAJnYw5RlSAgAO/rXoxOuBwBmr45BOHAJAHofbrbHtwQAmNnvhaG+BAD4VRBxvPoEADj+Nnif+wEApi11RvSCBQDkTDIg03sBAMaYeBGJFAUAC0Ggkk1oAQCnxXgP2eQGACjavMShwgAAMmm9aUiBBAC4XaSRw7cHAEG2NawWcwUAagnpHeNBBgBNMQqzqaYNAEcEH2/QxwUASToL+HDbBwB4msg+SssGAH05ga3oOwQAZG8cvVjFBwA9RpbTJBUEAB0ankRrWAEAiu1KkH7xAgCOPB2G0uEHALqvoFxKQAAAvm9BKhueDABWbDELahwNANsb156ldQ0AHewfGgJMBwCOf25RJ5ULANZDpwoHQAcAgxHdy2RrAQBD6zJ7Sz8CALM1gqWrGQMA2a3cv5VjBACcml0aLdsHAC9ChQsgmgcAFt1xqr9VAwCqeF/qdwsAAC2CnqJ5ZQcA3zS0UhO1BABnJhzQezIJAKDIYDvXNAQAukOUqNrgCwB2orJLUSwIABcqwEl+jgYAtuhvNJVXBABGNY9sMIkAAPaIL2uf2AYAW+DJTTg6BABFtvGL2tUDAAltaqnW3gcATS/uT0nDBgDUa4ucmCwAAEgVliAJFgEAuk2bNhZWCABGb6yGq+wMALEA14UAxgsA6fwN4T4hCABtHknXN/YKAKrP2ilpFgUAifYxa4KQAQB9SmlnVfUEACLlsff0BQcAmFa8JeFRAwC+e/YaRpsEAJY6LHEVWQcADQxY72eaBgD8z3DvOE0FAOJ8btCC8QcAD3UhjnJLBQAoARuXkJoGAKNjqfJAGg0AvqYSrOkLCQDEQTIEzEoMAOxoAatkjgQAT2+ouL2iAgApaS1rOzQHAKPpjKoE2AEA6UPDyEp9BgB3V3pPu2sFAI8jfGIwkgIA+9csEhqtBQBk41Bupd4AANcqMcjRVgUADugbsVZnCAA9sHt+FGIMAN+/PnQZZQoAtCpoWfyCBwDHyIzjq5cIAII5jQzjQAcA/YJGf7TCBwAc3Me4kc0FAIPl+ZCnfwcAJNjRxsZGBwCkLaV+h8kBAIlhqIN7swIApQ0xSa8zBwD7BBwWgV4CAOi+NErhdwUAK9dNvb7OBgCfMkLkwUALAD6p0f9HIwMA4LssJYlKAQAJsI9LMAUHAAo7p2GsaAIAHL6+NPIGAgDo68unA7QFADVBn/BgoQcAeP2W7qcPBgDGbilNNR0FAMcWO6b1ywcAFAzPswv1AgBaxsqFs/4BADUWyuCYEwIA7lW3tPmqCADyRK61kWsCAMixeo2A3gYAsDBVZ2mnBgD3mE4o+7sJAPMzKziKBQUAPpEWGKl1AQDoimu5zfYEANKB2slHcwEAI1rZ2T6qBQBhZdnH6XcHAKzMBvBYjgIASawsu7tBBQDsTJmCMuYDAJXo5RR+oAQAm6R3xM1YCwCA5AL+iMwLAGrj9LeqIQcAU5lGyYxACAD5Stiu9woFAJn5DZjLEgQA3Cnu2I3nBQBdV4z233EBAEnv9tJdAQIAE9ORw7rwAwDlW/YVAd4HAMlNNiEsJAQAmGCmZFu3BgCFwAIBPAMAAL2uazEakgEAi8Hz2ZqtCgDqmjM4FuwFADuoWWU7cAUAEtYFTZ/6CwArBsreSbAHAPxwuN9+LwIAKLF31u5pBQCvpbDcNwkDABvqeJwDWAcAOice9I1FBgCDREQ1euMDAJl70rf9YQYA5CHWHXYXAwCJYQIwPDIHAFApvMw9CQYASwOEYL7uBgB7jQr3Ac8GAApnxlQatAgA2lW7mUvIBgBHtpgMGOMGAG1w4IWFmgMA/mMm53wWAwCXQtvsFD0GALhw+dwhvgQAeoKEoB59BQBxsCih57YCAM9ddRF1sgUAZQWTwoSFAABZQW/ae4wGAHvZ3ZnpYwMAs65L4txIAADjBeyVV7cCAMlt2sWkvwsAHTeeZciqCQCab7x5+TEKAMQf7jXBQwAA1fIZmRyhAgDNul3CTDMGANoAtBfalQIAoJOGt+mOBADG8yrMS94BAIbroxHEHwYAwC7BmtE+BQDgBLjG2wkCAJKHsKm/eQAAMkLVooDtCQB4XirH/g4HAC2CKtRRIQQA6DHWtuu1CQAFR1mxT+8JAPQNMNpROgAAchxWK7VnBACQ5RACktUEAIWWeJ52ygAAF0hof8c4AADsexZb5l4GAKlQuBnaUgAAKWRlZYZAAABMmm9ZOasHAL+gpJLudQUA7tekCkW8BgCoCzt3pvQMAEe8DgsbJAYAFZMdT5wNDAD0guPnoQAKAM8vGIqQgAAAmLq3EylTAADDhcN4z9wDAKmrXt0CgAYAP80ScU49BADFOvnqZ7kFADEKWMqsYAMAYvLG1V/GAQCr7MIVfxwHAORRJqXsUAAA6mjmYHY5DAD08pJWp8IHAO9mbH6esgsAmdq8WKYrBwAaE/oJHBUGAJwMP0XeGgMAaHhzB+7fAwAR1Kf37BEGAPZkvWx+YwIAj8UhbO6wBACWXfD9DVwFAF5Hz51WBQQAu5h0J1xcAACJw13ZiIUBAPAAqE/y/gEAc2uXMPWvCgBZhMBIWtgIAN9CNpbrlgcAJrbEUO4LBgBAg2z+BYAKAJYxpxr7UwYA+gaD7PoHBgBUUj7IXugEAP2EBZBWnwAAhvySktREBQCIhlI0n7oHAF0ttA+ihAIA/m9w2SxlAwCz5t2te/0GABbzMClHLgcAFHYq0zX2CwD9AN6s7MsIADWp6kERQQMAlMvzQh4cAgAG/gDw5/4JAE8IgZeMIAUA0iTcoWhkAQCoQMUKeL8HAAFT185+pgEAOnPC6NKpBQDl99sD2gUDAMqut5mGIgEAyWuTsiMqAQDp5mqlvaECAEDgHgWUDwAAQJevB7uTBwD9+tTstucJAEL7YBV7LAgAtl/MNGcpCgA/3SX9f3sMALIw08MjawUAptFg4wh2AwAucsjz4AoBADe2GLbZhgAAq77ox3l9AAAS3Qi8nPsDAP9wU9g9XAcArBko/gZ/BADtFZKrBtsFAGTqNQpSwwEARsBrIUBvCAC02Q+bV6ILAIvsfkAmHAcAC0+1StoqBwASbbbDUIcLAEqjy7ymUwIAGnAzBAcnBAAOh/lYjgsCAMwA22HINwMA7tB1V9DDAQAa5SKUQPEGACUtzr5rhQcAHAMvp4AzAQC686eAED4EAAQzfSweYgAA8/DbsJYXBgD11jKcLzwPAL1+U9GOqgYA9DgYyZJOBwACEMqJ5dgFAI2DWYLMYAAA85Vb89M4AAAjqUPCeGAFALIbJJMy3gIAOr2XYH0AAABLqUIIlR0HABfYx+URawQADU/LvotHBQBdHApLBcMHAMvBg3c9WAEAxyidzARHAwAA8rGY5d4DAJ5tdJgcbgEA36+VcAsFBABVPOhkgJUEAOF6ol3vogYAnZ0u4KyKAgDo8GXpWSQAADMJFdNkuAcA2B7o8qVSAgAN6GZQJpQAAKVhjZEPpgAA3g/z90tEAAAGPO2pDcQBADuEvXDBeQAAVtDVwFDNDgC5eedqYLcFAKHdayK9DwcA+R85Ux5mBQC4F3MNjHYGAP9v+mTk7AYAoGCkvEDMAwAMjfsKqeMGACgSobwagAUAn6w0XsDeBgCzwVXx5SUGAJYycm8v8wQAzu8FAZisBQA27l4WYXoBANXcTeFFFAUAQqS+K6tHAQAmMSXyQPIJAIhOMZ7ewwgAXqT8pKUeCgD85IYAmS4JAFFJFDtLKwAA6mqWd4loBQD9nzluF44BAIuTtF5c5AIAKTke84YxAQAuu99/s5YEACE+X51DwgMATWp+/mBuAQAdYpuI79cEAOnTBT8uewcAkbDdEpxjCACyes2QBBgOAHtGl4KR8wMArIEXvmhFBwCV4FJRGXoIAN7ELpzFqQcALWV5nvDpBwCGLfIi5KMGAItsgzuOrgIAMq3HX3k7BgDIX544Ao8GAAZ1h7zxWQAA7AxBDpkEBQDirv7Q15sAAPAy0IP+6AMAKdHv6I1MCAANIeYGfMYJAGkUf483gwEAidKuzlJDBgBYYpqJYC0KAJSicAW5FQMA8SWpCOEMBgAJyVMS9u8GALBwLQ7vAwAAxPqXt6NbBwCW0c1wwNsBAEdMU7GPbQEAKvqDgUkABQB13iPEWS8HAHl3uAdNkAAAuUD5SGYtAgCGPoehpZcJALtUGsTkBwoAz9ZLOws2BQByr+usCiQGAJyRut3UHwYAmVa1kenYBwBsxzxHMRsGANYx5jGWAwcA3cH7QyE+BACglaJbnHQEAAZfS/pGeQMA8VFaq8UkBwDz0514M1YGAEDbOPLaawUAnzudwWzTCABhItdwROwGAK6pGHA9hQYA68jCTT6qAwDl4QcVozoIAOszNfXjuQIAxQaoJ9etAgCjFc7IVWkFAA4pCgdPjAEAQTfYhkrSAQAfztT/SHYEAJ2eg5GVCgYAqxeB89UkBAAOwRJpxCwEALSuyR0mOwQAUROVbIs9CQApY49+AcAEAMT5U55VPgUA6m6IRgGyDAA/KSReTSsIALt5u4gZHgMAq7yzRi+4BwBBe4LOqPcAADBxFxZY4QUAdrL1XAUmAwDyjdEoy1UBAJQWoZwNwwAAGTGrJw4JAgC2SXpOYggCANPlmoBsegIAQWk9xAonBAClWVbZTO0CAPkodbMNXA8AM5Is/bzMAgDC2AM2UCEKAIixDR/N6wYAdBF9S+tMBwBcT99oYdUHAIrRbxd5vwAACvZPF2fLAgDQ4Qs5+c0GAD0rfpxRjgAAgQil0sNTAgA9M45EQRsCAA+Jc0vfsQcAjPX4BxgiBgDlizqBkvoDAHJVjcOY2gYAj0ZUVdkeCAAtNV0kmIYGACSisrPg8gIAkhwsomrFAAB4svE57P0FAAbxx/UKyQQAxY9l8s4fBgB6GBgqhV0BAHb7mrXbcAIAq5LPCxLbBwCHQHFdoucAAPDac8T0bAQALYFJ8aduBAAnhAppJQcPAPp58Ok6pwgAKsZhRJLdAgDM2FCuWgYJAPnlxJ7tJQUATGhgBtIiAABoezlwK5cHAGX501g5oAcAtU7RvIeTAgBXDSDfJUUEAIVD6Uz51wIAt+xwwQANBgDw2PMDBYsDAM7xZI4ZmgYA7crF3DRECQAffGafkMcKAHW1H52DGgYAdrvKADjyDAB+Jr2XJlsCALx4GtngsgIADPLMEgqZAwAiJh/hwkEBACAzpfrO3wAAOkmSap42BwBkaJgT+z8HAKwT97grKAMA75fyeO2cBADvHWYncGkGAORU24MGQgEA0FrMwW+7BgCdZpHVyDINADJsqE15rwkA0iRt2OngCAAHHRa0gx4DAJfRnSQevQAAj1YgGMsLAADUMIhxseoCAOaXaYH9lgMAilC/vmMLBgBPKwaeEscAAP0SW0Em5QEAPZIn/aBhBAC3pXD2rYsBAFDVYuvxXAUAP4z1feO1DgANxoY587wLAObqXIO4TwwAo3GOwd6ZCACfK6a6b6UJAFg9wmUQEAEAD4szkBKqBQAhdC6efhUDAInUFyBx6gAAiXBFVqZpBgDsyZ1cUGsGAIdS44bvdAcAXpXARNnRBAAgK9c5TC4FAFiceTZIPAEAgNCLXWr7BACbWAhJ44oNABKve5dNlQMA3EF0WeoTBABbjtyH3AsFALnhs1pGXQIARyjsJ/74AAAGT/Db5tYCAHYyG/yMAwMAe2M6yYBvBgAR4d9ugzcFAA0sezUCvgIA+NTIWO7cBgCSYR1YMtcCAP0lR0RW3QEAh8i6CADmBwBSGHw4XD0KAKcz9fFdngcAz/DF8fnmCgAvOvZQpKMLAH0SYjP4fwQA9LGCrzmOAACrffIuMogEAKShojg3lwEA9xkikUXmAAAnRjnYMS8HAPEAopTSewAAxnTiAL5lBgCLNrbx6D0EAJo6OdnIGAMAhdMdqymeBgCsa8ezhQYDAFlI8jfPZQUA+f6Owip7DQBPWTIcpAkNABn+/yoDXQQATt5sm+QvAQDxfDK8YxYCAN3xaUxeigEA1aF5xsckAgDpJfmm3G4AALh35mODjAYAz/vkJfoMBgBOQAl2wcQBABGKMgL/WwAA5BLFDd2gCQAPzV+/lAgJADacPwFJKQUAxzVHug/1CQAZ4N58J3YFAAvgyiNwEwIAxibrmTVaAQA8K1EhcmgAAOkkCDrLUwIApKI/zLiABwBfME8jvIoDAN4DwbuAogcA/l1pNqiYAwAailJBr9ADABsnJodB/wUALZW2E+hHCwC6PBzCZGgHAKh0zdtJ4AkAm3STD9a0BQAMCsq4TZ0KAJ3biRcMCAYAMace73y+BACAgJ12DfQCAAOmREx9XwMAllrCPaAGAQDQUzMzrwoFADW7PGGatQQAdprhwN8jAgBkxbIrHn0HAMtSEKU4qwQAicDdX+/RBwDZ2rnr6r4HAPusoAvTWAgAj6616pLNBQDSTrBrHAQLAJPVaGclKwQAT3tCWYToAgABB2N2OCsAAOXqBdR4SAMAigjcGt2cAgBI4VbZ+fICAP7BZa3mswYAXZ63cgmwBQCvXUwjjT0FAElAgda7BAEAUPF/1l+aDQAqNdDqmKkLAJmvpF/JgwgAbiYB/Nv6DgBxsA+i8gQKAGft8Wgx/QAAPkp45w27AQB3BLJ4y0sDAIIhLm6ipAAAp5JwxYy+BQB5sOswPTsEAAIZxqWsVwMAVSTWxXC1BQDHGB6esg8DAJEnfLEPVwIARyS4C1WpBgAlIxoK8hEFAO6bI9ckkwoAwxZ1wzw0CwAX4B35xUEKAHUVtix/NgIA34dNwJrDBgC95deLldQGADIVimP0ZgUAMDClXrbcAwCqbN5AKRcAABtFZy5bBAYAs/w+RgdsBQCRbv5ri3IAAN/81e0ghAAAuxD0BE7DCABqoNDA7UQDAG1N2IZU5A4A9GM4yy5ODAC3HTJPZU0IAEr6YoOrIAcAv9nNR0OcAgBjhF+tmOcAAP4Ly4vx/gQAdsH7PqXZAADVtb3dFsEFAM+rpbu00QYAelOlSIrSBACZCwRbjmsFAJGJYfKkpwQASyo3r5GyCwCXRP4oMA4GAAlqT8p7JgoAQrJCwu4ZBwAOPiIUY6kEAJVfsV8CGAcAlP5xg2uNBgB82fdIRIADAIBCeP5mJAQAMd3NxFAbAQDW/6QIRCcAAN00266C0wcAXTjOyc8KBAAeW6SZuygGALzm3OS89AQAbwudxG5hAgAc5mKEXfkJAMVZkZs+rQkA+E2gdaSbBwCVFVbuLAQDAIQlJOJazgcA49RTsV7SAgDJqZvQ86gDAI7rBA1p8wAAwHFL0c0/BwBBrJtEeXAGAE9IIUactwUAjWsV8mkQBgCvEDtXJusAAM6pyUDniQMAFawOV/Z4BQA3OZwz8kQGACxslbdHbgYA0FUf/jJICwBiYl1eQlwKAM653DSuswQAn6wVGml8BAAMQF1u4BgDALE++NkixAMApmWUN0UVBgBu3tfxpgYGAOcHYcTA8QQA2OX73LEpAgAnE3sKxqwDAIRUkQiaUwYABkq7FNTbBAC42/FJCJMPAO/KZqTFKQMAm+tPVCTIBgCbAe8gU/YIAHP30sN0HwIAOr0IjbgkAABRQQXPeOYGAHx0LicxNgQA0VysSl4cAQDG4P3KsdEGAJA6MGrHYgQAm/88aU7KAwD9hlfULJUDADDD3nu8ygQAidJ4P494BwAR+LMJKJQNAJvC+HcylwUAZ/7FO/kQCACxrGWBSe4HAC4KnAgklgYAcwTnyF8HAAATIx2rhD4BADuV9u0LwQIAyCEDP7k5BgDDoRGR4wgFAHovkQ4SkAIAQ66sZPTLAQBXYVfpc1MBAGBbyJP07QAAAEF2hNLEBwDsrAa//v4HAABBgnr7mgMAZf3nR460CQD5HU3FAEwIAGham1lYgQQA2dVBvHX9AQA8Xakf/NkCABG6DvIn2gcA1BkwLrkDBAD4XEaLgS8CALgJ/x2QQgMAzYPGXVkfAwCC1l90V3oDABcmqxK7VQMAGHOMWsfaAQBgNELVebYLAA1Atrf8uAYAnV++gzfHBgAqBY6vjlEHAPS7k3TMZAYA43QYdpQ9AwAT9pYXnhcAAH2G4jUFiQEA7IIhE7j5AAAybH8bxFkAAJEUUwaHngcAgrU8ZEfHBgDklNQKDOICAHWxu3E4fAQAsGZQyFBdBgB8HzZTdBYGABKzi4GjawgAIXWqm/KvBgBIjc4C6o8AAEhP7HGXUwQAKMqtizG5BwDFFuCvGQ8HACONYLF77gQAaWRXuIkLAADQ6t5odt0FAElwpAttCQQAFJEhl1knBgCu5meK2psCAF33dJqCcwQAyQI5rTpTCQB65BFr4N0JAHYLk9G+hAcAZ8i5kgrICQBMTtS0aMYGABjEeUZ12gIAWhC+MUwWAwBf75grrB8BAFaSd68aWgMAPIPEhIYHAgAMgnh6Ic8AAGnn0uckUAYAKqjd77U7AgDG0zK21J8BAKT4VGAaQQcAtHWxGD3lAgDzSiBUcj4LAMTEodXXvAsADl32KsLHBADDWCSHmuwBAG3InbkynQUArKkiXgesBgBxMxEgkgsDAG6WOKbZfwIAE7hPVzbBBwCbUKIA1KQGAByXVhB5QQAAXAduhtVVBgD4TebzKzACANZ8XIrYrQMARjA5WdSYCgC3kD3L/gsDANb4Peq42QMAeRVRlg6QAwBqQBoToRsGAPLcNbZwVwEAcZX3g82eBQC9fwscRtsCAF80galCOgcAecjMn5JJAgApkJUW8aAAAHo0sddPlwUAre0IHMzgAQATH634vXMGAI69yxADYgUA1oXid/S1BgDIbDLske0MAPyjA3VT1g4A1Ig5dtMmBgDOWDZvhOwHAEPWNElDkwEAUapeRKLUAADgb+eKcNAHAOHHw7ZHmAMA2dmkonZ2AwDHLqIdP48GAGtzojmA7QYAdTxM4H5iAgDR50emkOoGALmZM3Kv2gYAj46trL8EAwAHixB9kQIFAA/dpmwXQwgAgx0sjxXVBQA761ieRLUKAEe+PetidQIA5wsXtNeRAgDhqN9nytEFAKKY8mGAqAIAfWJxnk4wAQD+nNxq0hQAABNvoRtp8QcArG7wKBjnBQD8//AH7UkDAN3C1+KNRgQAuwdj+MbYCgByCYWhaygOANNEhLDc6QUAsmIzVGqpCQBGMuYnZNoNAJ5GGZReNQMAN4rquHuEAQBxm8+IZf4BACJr29LJsQYAS7T/xufMBgDKIqzeiMYEAFID/8N19wYAuxnkPmBlBQBGHMZWRFQGAPJ5/qspjwUA9s0Ocb9kCgBqiSeFxQgHAJQzxebqLAwAaSvoIRs4BAC0hUFyk68GAGg+542rzwYAIb3Uzu/mAwC+DVAJZgUAAN+FrSR4GwcAQX9KnGJ3BQCIqMYJRQIAAERmLrFqaQIA2IBLf6LMAACeERvxwccAAOzKsFvyAQcAE8G+fNn2AACjk3z7l84MABooEVqDOQkAVZHaepAoBwBVCQW8pSAHAO1sYeT4sAAAdbgPtcTTAQCYAdxzlvICAPoPg/Gw9AUAQNz7K8ngAgA1WoCbQwkHAIeBf1VI7AYALDqhG02KAACu+QuKNHYAAO9Escu56QAA276xXdWbBgC9MfdHTuEGAKwOJ0deowkAjd94VCJvBgDTz5FB1GYLAK0gV/uP1AIAd9+hIX97BQBFBrr/DlUFADGpmEBq7AUAN/OzThAhAgAUjLzyQxcEAMdzh62wlgcAm2i7XO6fAgA0hxdcZiIBAJPFa056FgQA24/O+GUmBgBXmMUaEJ0KAPufpbs72QQAFz83l3h7CQDstww3M0sLAAAn9nYonQMAh2wdzc4BAAB1dnQRGvAHAJCBoaUNNQIAUiXit4uTBwDM1oGG7pEFALh56rSwnQMAQgg4DyICAgCs4EK6dvICAObf4sZvFwEApQ53SYniAAByexSInlUFADDvY24eXgsAbv+nmhBbAwCQJk/lo/YJAJthnFvQbAcAlRaQsFSWBgAnf7cQN6UHAHWB0qcemgcA1XfGpMOPAADqNAfTmcEEABTMmssixgYAFgIDVQpmBQD7EZ8Z8WgAAJBrEdD68gQAJbY7tx3ZDADEEoFTgl8NAN0VmCda2AYA+ZzNsLdABwBOlPKVGUULAFROrpRBsgYAl4jt/QojAgBxUH1hEjQCAJuWNQ/T1QMA73JJSkhFBAB8feqf0PwCACrSnmsSlgIAsgUqAXGhBAAjVU3HktsBAIlCYMqJCwEAW/BFWr5BCQCmruyLs60FALvyQdtG/QsAOM61u4jUDgDT8J4dLX0JAJwoGJdJRwEAq8fkZ4qkAADjr0tUvA8DAIrlXzEBxwAAdXtXjYcLAgBqPj8HGK8CAP4kDULqOgMAlP/0iwCYAgAelttxkVMDAFzGPPYUIgcAtik79Lm3BQCzo+4x6kkJAAgWWBN3vgQAmF45YHnYCgBToVXISvIJAJOmB1NAfwMAnLbybOblAgBTnK5mQtgFALlT6H3r5AUAHBdYjPT9BQCqBZWOMggGAJrEHYSCIQIAByMdiZbsAwADLvL/Y/MCADmu4jmnCwAAJruI6vUmBADIdX/nkjADAOcZ2EA5pQEAE4aBTy4TCQCMUX3elyIHANaQh1zemAYAJetbVLhoAgDf/paLZNIGAHywHa2IeQQA13rmo4MyAAA5uQy+xx0EAAQJEGZssQEAbcbLIEyiAACBhuTv6aIEAHFihJYSXgAAUEUsJMi7BwC3NTsQBpoNADIg80p+IwcAelOzGkImBwCMJThd8owHAFpJnC2z7gIAUJcvdyWeBwAjvzuDR9cGAEnX1RbYzQYAmDbByQCcAwBonUgxjmsGALXiEH6FcwUAchSqFug7AQD4S63TZBkEAP+zdiC1BgAALQjOuRZ+CwC4PoVXL4gJAMQf0Kye0gcAFee1WWrnCgD2qWGVLt4HABx4lZ3hzwAAPEUcYswSAwB8B9rmrEUBALjpnO8rkQAAdrxDNH7VBADLXqW29NQAAM47c7uw6wcASQUgBWq6BwBpIOLk7fYEAAKm8QqpsgYACtiyWyTzCwD8bvMg9+UIAGzAYM/MuQsAJXnzI+OECADBdoIsgWUEAJce5pr89AMAJC366we8AwCg1Fy1RLcDAPMhV7JTJQcA0xKdTo/9BQDZYhAqsr4DAKjJgjsGpwYA7ZfBXaOlAADvPaUGDMgDABbLscIyWwAAgoHVeiykDAD+nnl+ZsgFAKFQyHReLggAmYZOYdvwAwAwZ4WkcRcLAP2oTdLMXgAAGHnw/buABQBqPIeGNecHAD75d9/tTAcAcbQ3alW1AwCC1E3hJMUAAFbGlnRFgwIARc22z2utAAAUJLDo0XUDADOnJ50H/AQADcWGDESLDACFO8qckjkJAC7fTOTy+AgAsaZ7ETKEDgA7risMF0ECAH8vv4mwOAEAOeo0/VugBAD1XpJMkQMCADxO4P9/SQcAmK/sfFYkAQC0c8QKhqsBAP+nhnwiwAUAd0TCvxIbBwB1MKhzpQYAAHDIZilh+AMAAI0ENvr8CACCs7szcW4GAHZWpKhCSwYAz4WaT27qDACgeOjuV28KAN4NKnjJDAIAs6pwME5dBgA2d1QxjrwHAJgtQ7G/ngAANpdnd6oEBQCx74dW1SwDAJVhL16PRAQARQNGnZFoBQAnGq3gwjQAAKPb2UMZBAQAyqpsokN3AQBkyflWkYwEANCaHo0n7wcAAb2njuUMCAAMgCkUky0JAJbM60O67gAAePiVU92EAwBy0jUaM98BAA73Sv3sBwIAQ2iXHQpCAQBPWTfTmXcGABhgj1RHFgAARfF4Vc5/BQBxKhQMIgkAAJo1FCP5tAEAsWaYpDAwBwB5JgvpK0QKAM59lNjTewcAKCBVwVX7CQCh+VYdGf8FAFEJFYmdEAQAy0ctLb0lAgDqO+eAwHwFAMsfcnUQ1wYAMvGncrU5AgBokC2sM9QGADNwpDD5KwcArQ6i9KxPBgAqQLmi92UDAPNYpybFIAAAdsxC8FnvCQAl3XZJwrEDAHJisVxmHQsAVsVw5FaGCgArYKXgz1IMALzb2J74NAAA846NlI87BwCryiPTwYYHAFFuJqnUOwQAE1NhxKwqAADfd3hkoPcAANTwkw/M4QQAkBHvJkfsBwD4EvWL1b0DALgEs9e3zwQAEu+Jl8KZBgBQvCHj6jsGADW7rUDDJQsA9SvkoeFiBQDTNMTL1LEFAP51m7hsPQQAVg6QW40zAwBTGlN9Mo0DAJ8b1WFcsgEAdZCzIkZLAQAmnwrMFSYDAN+2nLkRdwUAODzpFJymBQCZxaSAiegGAJKFJXGP+QIA7qZUT0SuCgDBxft6ORUGAPv484N3DQ4AuYbEX2eqCgATdp4uBtgJAFaeD7VMpwQAkgFkwtExBQDSf2ydPcAAAMEQZhXNfAUAaoCdJK6mAwBafJCphdoCAK9M7CE3sgYAojpopNPSBADv/Q6HxvkHACXvis64mAIA3mUhCupyCgBu0D7veYEGAB6s/sC54gwAumMbCynuCwB8OoBxYroGALIM9+9TeQIAUsUOriJPBQAkJy6pPZ8CABi9IgzKQgIAztUEhIpLAwA1M2mDtewGAE2437927AMAT6BWz5XIAgBSTdVJUTUGAOFl1L1iHQcA9V73sdq1BQClub4M1uIJAFb+XRfCJwUAH/WPK4qeDQCxYhJiM8MBAIDfeNMozAMApoyW9EEhBwANbdtraQcEAPv8L7Jx0gUAcjF/MV9NBwCBytlnVOUHAA31hjFlpQYA8S3m7IixBgBxSYQ2bcYEAJ1+VMS8rgQA/bVUc56NAABowW0LdWsCAMmsAR6IYgEApQEd822WBwAdmtydvXMJAMkBbScbBwAAXgKOkdiwAADr4p6n7lsHALhNCYQpyQMA26OVv4/YBQDfclj+Hg8AAGolGCOH2gUAYFljgeucBQBkx5N284wBAOoZO9EcbgAAUwNbnmKvCwDk6Iig8QQKAC2o7pz8DgkASqMvPIaJDQA22KihpvMHACNvFm9RrQAAGshXbfVjAgDKOEY4IjQBAFAKr/EfMwEAFm5SAwYIAwALgD1dOUQGAPzevj0guQIAVaNW5oyxBAAsGLxmND8AABPl0t4PDQMAPUe4aB6XDACV83mXzCwFAMhVgq4E6QsAOJPzRq7sBABYHDWEUGEMALMzEvIaTQEAC5yziRneAQCeb2/caSYFAMc/jLI0NAQAmcACQiGpAAAuoLmuwBkAAJLXlWnAogEARBxXsctkBgCygPo2B/8GAKVcidKgvAMAvwHMnraOCACM8y2RyLQNAA3ywot/6gUAr6/KFuUgCQAn3zhAi+oEAKRiXTy8MQAAHghMD/7ZBwAs8mcU1T4EAAnRHgzM5gEA8eja7R1jBQAC0srxCkYFAF1l0J2RtAAATMEYfWnEBwCkoruQyDECAMpCBZPgTAIAhQvz/VWhBwD5h9TlxsYJAFncSxPhSwoAMW8ycFlACQDzJHOKkkkFAAbBBv31kAAA/UMeArGrBgCgEdf6vDICADd/BDzBpQMAbaAoPE4dBAAuGu5jpzIGAE1evf9L+gYAkke6pjX9BQDonekdXrUHAM8N7G22kQQAoWTa0I5KCAC9bglF/OwNALGItJPu7Q0AjrxRGsGzBQAYcAuLa88EAKcy6sc9sQUAHhNz28KPAQDjV48fZeMHAGWpXwVWVgIA7oUMjTOPAAC9cxqZIagDAHBYj0HmOwAA8J6sjsHdAQDCjZme4EwFAHiwLqjUMAUAi7+abEVzCQCsDRAVIIkHAMv+lUDhPgMAZAl61pWtBgD7ywB+PtsIACVI+eEwNgQACUBrapXRBADgtfgt/hMCAOaREaTjXAAAdwHxU6deBgBjYwniPvwGAKxnbbk27AcAsVgHauwQBQAJIQLfh+0AABoeksFOKgAATHnP8WJhCAC4Xv7K3SQLABcyRuDVGAgAjUKSkIvnBwBnwN61Em0LAKK4JDuaJQYAnAsX9LWIAQDrXeHewIEGAEV082Xm3wQAgCcRxUPRAwBXRRV5kScFAE1CQQePnwMAPZJXs25eBABvdNtemywEAIK6hXhR7wIAUS9bMPu/BgDdEteyErEFAOLkT5d0VwMAo+OWevhKCACfswspaHkFANyuWIxOlwcAxog0CH51BwCLvOcqxgEGAHSr7MJwUwQAOhSrj7fxAgAB4SAKQ7gCAOP+iB2epAEAlk3OR7uLAwA31IS65/ABAKrCXeND3AcAGJc+J1wqCABOi7LfySsLABnb1fj0jQQAjwJsl4dMBQBQLdiB+0QAAMPZfYhlZgYAsrBqCnYpBgBsPiTH5oEEAHf8RnDjlwAAzFhnAXLvBwDZ4wepxRgHADs4a4zJuQMA3MxeJe0GAABZmiI4ZZcGAA3D+SOY9wcAuof1aPAfBABTzRsZCsAJACSeIJxvtQcAvqrMXx54CwBswDEEm0oGAOgTtaM50gQAZhAb9SOXAgDD2QTP9EIGAHqboFoJ2gQATXg9N+CkAAAZKX1bodYDANalRlCnGgQA2tPCHnWRBgDEIWerODYCAIPhrNCncQAAMUThIFI1BACBOSgqNuEAAFSWNdh8dQoAjw2xes3pCgB0F3bPm8YHAAu6h8iqLQcAYNpdrPS3AACkmAQs2r0DAGABGKpnTgcAp24Ux7zDAgBfKegE69cAAP6gbx7qpQQAYGxDXGNeBACL0dSo9I4CAMoqMqep9QYAq0TZo+vUCQDk3PMVDxAIACR4Ng5wGgYAIz2rkiKSBQDT6A5ouSoIAMXGQS8MAAEAdHFz358hAADnfRJ/chQDAB64I30n5QcAehQuGuKUBACaDeXdhYoEAPQ9STT3wQEAiWiGZNt7BADsjo8EfZoFAGukvmzXtQYAIiV4HhdBAQAffNombYAGALmaxxsd8wMAaFGfRSCfCADSPcBpuG8BAJTZDOxsVQcAClG3A5rrBQBxy5Hd0QoFAEeKtIBXqgEAd1JoPzOuAABiCbYzlxkGABFlJnwVmwYAyvGT+EBHBgCE9vsIpDoAAA33uDge+AMAEcgXXzV/CwBagTRT6HoIAI7k0t2r4wcA5UUfvuoeBgDtzTQtPq0IAP6v2X7MDwEA8m/psIwkBADiclERHDEEACVpvxzUyQQAUE8Q/BAFBQCdJG4zxQ8EAOEt+zlmOAMAeHvRcfi7BwAEgH5reV8HAKEPv1jBJwEAdLlRrsSPCgDT29K/iW4KAM5ldqAi4QwAwgU0ILHKBwB9Fp1Hgu0EAKJ5mC5CfAEAw/7IRlmKAgB3K5EuszoFAKXgn6BNtAcA9H7Qh+9UAwB12cVgIrUDANwfFzZonQcAu9RA8ZTZBwBUGFYExLYBAJJTIC3ZAgMAZPHg5LZvBAC3ZVKtlzQFAPyGE6Db6wkAO2qzDC8wCABsQuv1xe0IAD0opLyiwQMAAi+7xzA0AgDCi7Ub6qMBAGFc3mNXJgcAyvF2O10OAQBnjtpT1r8DAIoqyD6VhAUAe3CnjyheBQCBHZPDXzkFAMthE8VGWwQA0eN/it1NDQDSGcZBzM4KAJBNrGJlOgwA2L2nrKXvDAAhIfOuwMENAKF/TzG/KgAAKBWKntGRAwDHX4kT+qIGAJGl6t2OnQAAt9w2+nsXAgCP23n6vBsAAOFmNutL2AMABCKBHZIMAgDOMjs9hN0CAKvYh5NhrgQAg/tbmER+CQAhzCbGMk4NABeB8y9BlggAaSQa1kGyDgBCuuWrhVYHAC6jRFOq9gMAuxEPaIOWBgCqI/aBNUwAAKXLdVivAQcA83uxkQ2gAQCy8mHrMwkGANJNKuk/GQUAPvRQpZXZAwA9iDq5b1UDAA47YptSNQEA64Mu4rwWBwC4PrgwAT0DAKyv0LoqlQgAiRvTTvYJAwAKWVGgLpcNABjV0a3X2wAAHiPiI/gZAQDifV5u1lEEADj4cJnDAAUAo1ymgVubBwAReI/cIKwEAPoB9amJlQIASmtq0hDYBABZspYN4O0FAPMFWcnp9wQA65lSNT1ECAA47lp9fZsLAOs0L5pRkgYAeM8kSUDkDgBJFErsLpQJAC4wgVe8SwcATOyBuzUxBwA8SGEbZ+8HACnXzBRGJgcAOOaSrZMZAwCSSSOuGVMEALVP0kedIQIA9mywiETwBAASSnKeqjoFAJzvFFOmoAIAJ3kcPM0aDgDleYe3RosFAPJ6vqyaNgsA03QwdLAJBQCh3rY53FUIAMIn+fd/kwcAtqXGFPrCAAB80G3bvVYFAAjRecGs9gYAwkeGIW7PBAC2W43CfCIBACN29b/pjgcAOokfJLKMAgByZzweVFsCAKIKcQejIQEAyYN0xz5xCQDK+tVyBfcGAIH/Ik7zXgoAhxEUT5RNDQDSzqaUuycFAJdKA59eXQMAm7yFlwYmAQDwT4XHTkcFAMpIowKjlgIADqTHdvwzAwAuSFuZKpkFAMcqAAfHjQcAQRfQlGOTBQAX7xoopPsEAHoKsmmQuAYAZNvHtYz6CgAPqCqY5hgPABoaGviVngsA+mxk85TnBQA5doowPUcIAA0icGJBoAIAJdBpiyRfBwAnamUWvMsBAChn4tb/uQUAPqc6EMI7AgAFnlgDJnkGAF1ZkpjbSAIACC2tPKUGAABzuvdQAQ0CAEPg/Tv3AgEAmhxRteDaDABV1OD/fyUFAIAh69EIQQ0A+a6bD8yWCADppF1yvfYDAMZFV3+ruQAAYx3S+PDKBQAr6gikvt4HABZtiZPbngAAwKVe0pdlAwCsWGAQe40FAGnuC9L4zQMAXgFlt0wKAADJfHwzMmgDAA2mncHstwcAiPp8p1FKBgC1Dcpw9JwKANiYCG4LtgQAx+b/3QRdBQBcv2HG7TsIAA1pXGk8NwIAGM8NUsjABAC5lHRLr4QDACUioo5KqwQAQxdg11ojBAD1dYkHDcsAAEsMUz4xkgIACaUkkbuNAwDxEVpl0FADAAbfDCvO5wAA5nBL2d/+BgDUv0WXPzgKAADDxCeuvgQAPz9qQaRaBwDOrjhhJRUOAKOFjMQ6ZAQAkrg1J4yHBgB32PQjNaUDAJ3ui+0EpQMARvvYpeBmBgANy3BITvYDAFdlbbFIFQYA85Y1d2GiBwA6XSdfTXIHAE1RDYG88AcAjRNyc62dDAB0ENPl3kUHAOLbf16lsQcAoW4Xj5i6BQBa7N0HqdMJAG8T9CakawAAILcGBvzKAwDanDWi8BgFAKfsb+Tl+gUA7Y7P2/jRAADcgdA+MZMGAEIXkGajsAUAfsqkLIcMBAABngCUgPEGAL8xSrQRAAAAXKcKamkfBgDKQq1XCosLAMj9Brea5QkAzL9u1AgTCABQKC2KmD0GAAxsxj9soAcA+0e6wbrJAQCOA3XFNTkCABOcxXG98AMANegW2UisAwAuI72vUwcCAAJg0B67HwcAOq+kR66cAwDC2TQLfDMAAIo2slKtPwMA6M8ixNDIBAClcVkntGAHAD2tHLyV2gsAdXNb/1HxCACmkMtcNcwDABYe5MXGSQYAgKrm7mcGBgCQ4SsYnRcEAHlpflbZUwYAbSWaQg9sAQAxkT6QQ5QGADbd+cZKbwEAU5LiEknqAgBd0mg+ZLQCAOe6JvTqMQYA6A1wo7l1AQD7SKoAX3wHABcDyoV3kQsAmJPHsqlaCAD3ZfbH8jEEAJ/+ZtoQBAEAfda03IJNAgAtdRcO/uYDAI+wyx7e2gQAkeqxSJZZBQAZe4+FRGMCAMBaKUo99AUA1KxSXKdCAgAQDSKARJMFAFMS+RVHsAcAxrrmxIDCBgBudmGzo60LAE47XBLlLwQAIqxKTdgRCQDdfKXPCo0EAEOu9qwovQUAfZBWj6tvAQDy1RgSsawHANu0IyDgHwQAZS9cvzebBQBx5qt95CYHAMH2RudF7AIAhkbHUw5YBgB0P2cEoe0FANM2Exk0YgEAQIbzH9acCQCoG7TExmAIAG42pwz3XAcAHgFs8agYAQC5A6IHV6IEAPZ/JvbemQQAPHcIgYVuBwApy93FypMGAPSfCtARAwAABV3N/v3NAgBq7fZTimYHAFYlFC66AwMACQnBhAWIAwAdJgoAIP4EAORI0pYYcgUAO9rQoZFQDQAKBcHHv/YEAL6pLs1OTg4Ab76L8rF+CAACS/xakzwIAK4bGP0XVQYAbYF2LHflAwCKiUCWGBkAAJl03oQq7QEAwWNP1+14BQA9DCtJxnYCAC6Tv0D8mwAACzMf8eiIBQBuwk1pbtEDAIwokLUq7AMAuNEyrgk6AQDktFq4HugLAB6uPKSseggAc2NS1wUvBgC6rcZmv+EIALl72OR70gAANLRdIydsBQA3LaYObi4HADnobtBMZwUA/ACiJVzdAgB+iCx56dUDAFW8q01yGQMAAAhoeHy5AgDd5jTd368HAIiuNYtUMAcANOPWoUsJAwALMOOnJuEGAMX7/K7AiQgAgmWDH6HuCgCDh30nooUFAO64qMujUQUAhtjiK0K2AwC8iZZB4TAGAFWppwc7ZQQA2xG0QzQEAwBiidQzgl8CADH0rwSPvQYAEmOa/Qf5BACb0jfH0w8EAPkOlXhiZQcAis+G6qNzCAAtnPur4uAGAO4z6jgqDgYAGP7zKSQLCwA+YUtIv4sKAMDIH9VZzwMAGEfe1qCgBwBLt28+OlwFANVPiF8TUwMAhBuMChb0AwB8bBNvXC8BAEzeN6Lb/gAARKu/zrx5BwAJaU0/qa4DAI8YWLOc5wEAboHg9dhTCQD8Ltu7M4UIADCUEpaXFAkAQoYWNm56CQAendNSq3gMAPHj9+7DNgQAJgAfwtP/BwCpLQrye+cDAN5yhPy/GAQAs6OzUXldBgBZ0VKS06QGANTsAFnjkAcAhneXvyUHAwBToDUWXAoBABKiEaSHbQEAcAVO1eLVBAB0Xz+z1+UCAL9+iD/epQsAtjlhvSTvBgCmpXe1kPkJABViBkJafgUAdzaYRIuhAQCPbx7eUuYDAOvYLuArUwYAOF8WyIePAgDW9+gbrU4EAGb0MU+ddQUAQ3n0SYE3AAApTyvjO58GANY0Ff6CWAQA5G88lCmZBAAVW1RycDQMAMTn185rIgsA3ontTBM6CABeQM5D+NwHANaDeXVdNAEAzcw0QvUiAgC024o9SngBAMwrjO6+bgMAb2KPW/6IBgDAMkdKSNYAAJItU8ZKuQcAD4VUhxt3BQDIYRTf2Y0EAHEy54eWcwYAwBoMyJ3MBQDN1IYUZ4MGAHOBXhpfbwcASt/59dPVDgDm12iPC9oHAKZ1VjgUIAAA7x09tV8VBgB8kokuo34DAC6o9WimWQAA3NShqxVhBAB22rXDUxkHAIF60zMiZAYAvbF2gGXJAgD/EDDmgaUFAHQ26If4pQUAuUOmoNMoBgDSkwxk2BwIACsP18qwtwgAvUSBqU2GCwAbXS2uNz4EABE9oXDPAQMA7JEYuqGmAgDgOj/7kfICAFLqS4F7GgIA0URuZZtmAwAz4abtBj8GAA8HWCc0MwIAdcCcReCYAAAbfGytXt8EAF791GweogYA0LKZZhIpCQDnPWCiEe4IACBMx/XCCgYACGgZKhmbBQDoAXCwcVMMAF/mRjAKFwYAOJ6kRhpABQCoxGFV3QoCAEae3u20qwcAXxkan7+GBQALefhejQgDANu0/CYhjAMAw+NJ4bqFBgAw6aQB1rwAAFIOeQP76gAAHa51D16ACAAnCoZZzGQMAO4LsLflSAoAdI/vdZbZBQA1VEw040oEAC8ESDfBVQUAwDJCdUHQBAAHaYYwtCEFADmc+0COMAMALKB1xqwJAwDuQ6W7uYkCAJ5TKC5ZqwMAOtjNq4JNBgAn43LBjscDAEb5tyFSLQYAKXr3OibUBQCwroki3T8KAOu5fvdk3AcALEA4g9IbCAAhOTilKU8JAG2T0BicKQQASYpBg0GRBQDVriHHGCoFAG2XgrpRsQIAVMdL3u/ABQD117Il3H4BAO4bCKY2cwMAw+WHiDG1BwDhWxpJbZ8EAOC+x2Uj5wUAPrMILwY5CwCxz1fm87sEAGdZbvX3eg4Ajtaef9bbDAAzt1xVIAsHAH8hcUUH/AMA62orm9KgAwCd5d3MeGQAAPrdGwVNXgUATnvEBBF/BwBMLBFVxRMBAMq3+QNRUwcACCGaHe1AAQCvwjszIiUAAGSg9JhD4wAAKBlLPgkLAwASA8h+fs4JAIOP97115QwAOO0LGXofDgB4o2ztrfgGAOi9zj7ZIgUAz/bgRfAkAAChzyY0tm0BANgP0x86uQEAYqNoU0DlBQCasrf9PRIAAGg8UlZDNAQAX+4heVKaBwB+gT7L/EsHAD2N7HLegAcAcif0APPqBwDjTDWIUUUNAKvLPUrK3AQAy+u/0BTTCwBXK9Nq/N4BALznmghFhQIAXMGg6Y/jAQB7N+LgRiABAIWoClYccgYAKBlnvyjrAACnlVHvGr4DAOu1vWIv8gYASTBSuGiXAwC9/fvIlDMEANKNvwHSZwQAlud6Vr30BgCDtxeTyFoGADKJ/SA7fQgAFWkyCPIACACDo1tanO8KAK1P73SakQYAv1IUYdSeBQDvCeoE7JEGAITpACfLywMAPLr1xEMcBwDNdJ769m0FAN9Wz+SVnAcA4gnGO2S+BwB46NkqwUkBAF8MOcpYpwUAgdxhHYuRCACb0QwmUNMIANi0N06rogcA1xRUc+ofAgCdY38COKcIAJUkRtkQJwcAVnQAqq9aAgAbo+ooH9ICANBfAOpxdgEAtz5LJK7bAgDM4f9XL0oHAAFzCHMwvAEANJwB9FfsBwAkpR8uCE4DAGoSNaaMaQIADtk9Xi9wBQDHxXBKmhwDACT8eKqlNgkAAHufOy+ZCQCir8SwBMADAHi6sDKIMQUA7Hzxn0vyBgDHYOAwf6QAANDIDVSEgwUArpzE3EP7AQAruPQGrEYBAFVzntgAtQQAEopyHB41AwDjL5NpnwsBAP3RHNA/tAYA8w52PlhCDwC3FjJXwT0HAEpx1/1IrgQAA+ETil/4BAAN/9ayIDQHAETFl0ZLXQcA9Pj3/+EbAQDh91do4RkBANX1XDQUigMAL7UFcY2mBQAGHoWey/YEAOWVGEfEeAIA5GQ9zs3vBwBMS1xFbU8GAEuj/jJW2wMAwiWYgrGQCQDIJTJR0+cIAK2rt+MrwQkApZweeHeHBQDyXUnql5ENANjZXfcr7gYAjb406yzHBgDHXjTMyXkGAKSYaPmNiQcAdZ30rSFDAACuWuXkGWABAJwgXfLFTwcADe2dk2pWBAC34BbnY2AGAHBNH9yvXgQA2rHMzyRGBgDBtnKAq1cKAAlvZyUHEggA7Y5O0BigDABs1aXuPPcLACvXRYCFAQQAMC3K4OVZBADqizAZt4gEALUyGw1KbwUALTaAvO6lBQDGjU4K0b8HAPQ2ZzaZyAcAAVz56rteBQCKP5BgsG0EACFmEolYYAIAL+V2xjyOCQCPqZXZeWAKALEIeSF8SggAWWXmA3bcAQBEJAuh394IAAT/YIOmBAcAPovePMzOAwD/ZA9H1RwCAIk5lY3BqwYAFebkwtBKBQAqUiu41WcDAMd9Pbj00wAAjcXbTH8GAwA3eWnaUgQCAKl3qivLLgYAdCi2rzYoBwBAspQgPK8AAHo1fymFwggA4taAVi3MBwBjVgfVExkGAD0rFWFSeQUAvTz6utuhBwDViCXFMa0FAFxoZEE6XwQAbZaakZ/lAgDaMTIaNi0GALgBTgCEUgYAYB3pO1NWBgCfqABsAa4GAAUcEyq83QMAFLuWJ6JXCgB0PkT7YPMGAOrqIHLkgAYAGAzxpfL8CgAfg42zf+4FAEvFXs75DwQAW7Nh4oVxBQCpcA5UVOIDAPjjA0CBtQEAS8BKMWiJBwCOakRBy/0FAHEq/yZpKAUA9rOW4jHyAACTRshXo4QGAKC8yTMGHQYA33P8+LwoCwCzlf8G3rQLAKQRuiekCgsAm23avzHuBQBngN/COrIFAGYl2/81SQQAbmwXbQEvAQCu9RYPsPsEACpAmY23+gMA7XqE/WXpBgB7UoDuU7kCAFqzsc1bXwUAZjyiPws6BAAKgos4B24HAF3ZnbubmwcAYXOfjq59CQAy2gJh9xkHAIvKgCp8EQ0ANQldtmYaDADKrGAUgboJAMImMWpAVQMAdn1yGBkNBQAOjkkL6uUGAPIUMga2owAA0p+MFV8GBQBUmUIM+2kBABDu7NntmgUAAhiF6xaZAwA4xVxVF3kFAE+K5TkfmAMAy2/mbaXfBQAIWQcJiAUIAJNKhcvY0wYA47Fw6fSyBQDBy+1SRA8LAJMKI1l1igMAH6OL3hwsBQA9WnTU8qQCAIqi1EKdfgAAzVpwg8CNAwBAl3XFgicFAK2Q2ZczPwUAFU3oxzmpAwDgOX4ixDQCAPKTpaHZMgYAlIQM7RH9CQDgVyftsyEIAMXBj+UdPgcAqxZGyBDRBQBkryjfp6ULAKbLB7gVawMA1/4anor3AwAfj2AsnKUAALeBy47dKwUA1H6ESE+yAADH6htRvtQCAJtbntmkvQYAAU6Rlml+AQCAz3/O8LEHAIFUR3TPTwMAharPeKsdAwC3VF5uIeMEAIm2czmCSQoAhIjkhElYCgA2+0IwmhEIAMpnl3hM4AcAMrjPKBtnAQA3xeGifuUHAEFBRO+q+wEApt9kwb3TAwB9F8LonNgCAPQsGLoSzQYAl3aawYoKAgDZcsyy+jkFACDeHo8IbAUA747zJKxfCwACq5dhXNcHAKcvpMJLPgsARIG0EM3HCQCPNUjqtzgIABduqBARPQUAbUZftm5BBgAgzl8jphwEABK7mYr8wwUACJG5xnSWAAD4bzGZIfgGAOnzqfFUXQAASie90MW8AwCt1dK4hLIFAJ6WJRDj5QYAD2IGYw77BABg5keX9TAJABnU7I+GQQgAxTuSjF4QAwA4GD3UigULAPuT5Yf1YgQALTbOp0vZAwC3Zya1+TADAArw4Eha1AUAjZp4FFGPAADQY3bl/Q8EAEcGwtRFFAcAfA8XaD5lAgDWXsXj3kwGAD3+TvpJZQIAbmY/r0mFBgBou9RBKZ4AADz/XR8x6AIA0vsf+Z5CDgDiLBP+DaEDANb5ax5GWgUAgy6w9O6OBwDPFoxkT9MBADJRuirqfwAAHkDGHW6SAQCgzhfqik4HAA+8P/hDxwAAVVS/xAPLBwCYfpGpi4oGAOVh2AEd+gEAq5Tf0QCsDAAaJ70BIboDAK/EuYiJVw8AfZ/0ib/yCACf6Y7Rzj8HADKYWX2UVQAAkBmkKv5GAwBbGXmATBYAACe6e/vMmQcAXKfGO1ZzBwCznBNjCOkBANag2Qe0+AQAaU+SyiSOBQBWZOe7RqIHAGS4Abcm9AEAPyWhkcg1BgAv3o7T62oCAAWu3frIbQYAhjegQX0cCgB9+rOxa7cIAAEckUFMJgEA+b2ERfQCBwDejsYfUTwEAPk17TosSAAAG9NxUq/hBACbk5J/+cEAABfBbZWIegEAx535XgDuBgDMMbJykaoEACp362HdtgcAx9IBq/mrCADlCmOHAogDANvtWwTKLgsAzzJfNkN/DQD1v1m2qT8FAJI981DowQUA9fa5mhHsAQDpY+Ztb/EHAMbeFsvWpwcA0vHqvOkDBwBVVIiU6cgEAIKtnNq1zAQAdekQxmtZAwBen9sNDKgHAGFMXD7ZmAMA8uPn0mB8BwBwOHZREAYEAKrS7ODEewYAuXMTH5S7AgAwLADJyZkGAPNI4jNn0QMAieNL4bfiAABKePbaDSwEAFB4xh/qiQUAkfHdtQk7BQDM8UZZI6cGAGC+L7ucuQYAYlxI1qXTBgDAI+lmlIMEAN38xjCvHAUAtFSsGJr5CgBu7mGWo5gLAOLNQB4zhAMAphnexBXNBACOnxic4ioJAArgdHZCpwMAwXR+Ty8UBgAVOowxk8wEAOceK6wb1QYAPziSokpQBQDPAQ0fy8AGADPV9Z5GhwEAv0c3iDhxAgDokDrlKvUCALqOlf4U/QUAjsuTv17+CgCH58uK2iYCAKF++6KDCAEARM9CeHCUCABccmD5c90HACyrRSjfLQQAu3Yy/U8hBgBGUhoYjQsAACDredWmaAIAR4blJv+TAAApmAVo/iQFACG2fOR1WwYAGczVpbBeAQBanZKzCVIAAEdryMub9QIA7sKRtmDVCQAHzuP8uvUHAGyAFBZWzQwAh7FwYYtYDACBENDjVaoKAF8TF5lCfQQAcPB6oM/qAwBEbrRGq94BAN9spDs/pQcAGuXiQotFBQBPRAcM5pIBAKodokOIrgUAOBULkSHXBgB+QaaVGjIDAGinqASQPgEAbIc7GckABgBldw2KGxwKAKGOs3+SeQsAGuDbeXYNBwDpjYlAYPQNANvOL4NFiAUAc24Mf801AQBb4+jf+z8FAFvlBl4ZLwIAzkuB6Dc5BwCN9HspFnEDACCXBg2eWgQA7ESnGvdaAgCjq4rL8BoEAF4diU6KzwIAomvQF35IBQCWZS0DKocLAN9Ik8AoXgYAwkDOsmt7CgBpHYny96YHAGcPEQeH/QMAsi2pFodvAgAnMHUbqs0BAGEmtVi+BAUAUoLl1psEAgBJ75pqjf0BAKFvIbdnywcAgrnDU/96BgAoltoQpg4CAFlU/K0aAQYAffjLAsjQBgB7TFXtv0EJAGJC72e22wYA3H6FJjGPBQBAk3eL4ZwOADz4lc9tkgcA7CsOEiUuBAAV+vFt6T0GAMz581Br8AQAL7awwVz8BgDLeZiyKFUHAD1aEtKPmgcAuGp0S418AgAMIQI/ifgAABBXrrOWVQEAyiRRfhYxBwA/4bvoOHsJAFWQL5Rb1QsAPpG+lRScCABs+xokTqoDAKJ5kT/SOQcAxOi52/oyBgBIDP4rUsgHAKla74MJ7QYA9LWHdiPSAAD1BTMqvzgBAJhl2CRd9AEA/mAhrUsnBQAq0VgdBLYBAHpo5KbKLwMA38yHJ3OkBwBABn98Qh4JAGOMXzhZNggA+mt22er0BQAAJmwz9kYHAPWafcWNbgUAeE++F76zBQBLL/iMkr8DABFvCmBVLgUA1uvvnH5iBAAcl2yrRfMCAOnnY24oUwYArSOKt2EQBQABRbWsmUkBAGbtB3CRtAcAyqJT3SgbDACF6odf6HsDAEFeqNLjSwcApmzJ+oe+CQDMCP4gNtAJAGSwhKtc+wUAsIWCdz5RAgBD4CUxOFcEAD0ibrWjvQYAT4RvN7oiAQBU5bSizTICAED4D6MrQgAA9UN7ZudRBwA+X9pVFyYGAI62Ur9wLAAA4XKNRb8yDQCbtZbnlg8MAKKdb533LgIAd8q+Z6sBBQBD6z9+abAGALsvC11L7AcAUFRZEOkAAgBecQVxBUIHAGAPUyJw8AIA7wmk8DRjAgDAo2LfSvAAANm2i7Tt4AUAA8D7pErDBwAkrFxOTtcHALJBNPQ3zAEApq7OyfFWBgDsWq2sHAMHAFdscdCMMAEAQhmUcxMcDACV8XL3RqMLAE8yx1xaVgcAEUok1aAcAAATh0FnsBYBAK7tVYx9pQAAAzgQnIDGBgDIatriElEFAFq6PQo9NgYADPSmi8kZAwDHbqMDS+gCAHzv9rkRWQAA3OouUfOsCQBoKmk5mGMKAAYFgzSiaQYA1AMGDJKLBgCyZByd71UNALsO3/WDmQMAJpiViSXqAQDWzQOHY84GAAWFiXgWMQYAcKKaz86zBgAIvXM7unAHANSG4fd1FAEAvCuJyRslAABazP+bq04CABc4E970dQYACrPaO9n2BwAl1L+lrPMBAGCXHBxS+gIAzfknzoAhBgDTLIgLRQ8OAPyCF2sDUgQAxYF2sJUtAACyBZL5HJAFALTsXm5okAIATBZw35k9AQDKwOUhw14DAClA9DfjOgEApy0/gY4ABAA6DI4vJ0AGANpe5eltwAEAqmlt/0ArBQD6fzcJiBsLACtM0VxiNgUA0RcuJa8WBQAr0+f4loAHAOLEPqPWegcAIdMR3MUXBwDkI5hVFKEEALHioVDOBgMA28L+oTjPBADnXPoNZaoCABWU8agWSQUAeBLnb8kNAAC4PuaEJ18FAJFgotPKcwMAmrvdifuoBgA3ftnVNYwHALIs73Q2bgYAj91TrEdDAwAqEaXtRxUKAHz1yYJNYwQAUtamaJIkBAD3L39obTMGAKDZJk5P/gQAQVSUPQ8EAADThln9OekFAN+bAUchKgEAspzQ52bEBADdA9KVW/oGAFSiNKNQNQYANntUckVYAgB3ExyBWFwHABsXzDfG0wwA4jR9dDA9AwDXp/q6kpoLADfPabXt1gcAoCzcpZQBBgCmEF50Wa8FAHVIAD71qAcAeK99LKbuAwBOJ5PmE8cEAKSzbnob7QYAFY59ac4qBgB1sCopuGYCAJxcZqA2hAYAaRAg6BfTBgDKoyxdgZAIAKCZFOvxPwgAGONQ8GA5CgAQFslpNjcNACc/LyDoNQIAgBe2Lp9MBAADcB1bkDAGANHqdNLI/AQAeKtof257AQBXUg6aqxQAAKWLf1Y5mQAAgjxCKnu0BAAtxHrl14gGAIePZ1pLywEA1AegomKqDABtLfY4Dh4GAIJHzI+ILwgA/xvygytWBwD2LtjSD9wKAGz8SjlrwAQAzDb2SxuTBAB4IzLQYCsHACWLgcYnUQIAQ+eNp7wwAwBOdBkRhP8GAAWT5OhgxQIAeqXl708lBwDfp2DF4noGAPFps+EbwwMAckLL+ZO8CAAsGHPb+fgDAMThuuo1sgoAGVUph7/dAgDV55cQ7BwEAO6KlAhNhgQAHvaNQzfSBQBncB9ghbICAFPX5rq8XQIALSY0EbYwAwCKgG2i1xkGAPK+rcKzwwMAUn/snnyHBgBttuHrub4DAIfykc1EawIAgwNzYpPyBwA2nEVRef0HAOdJLVFMUAcAX8U7fu2HCAAlx0kBsd4HAHV0OI9HSAAAPopn2ZeTBgDzdslWgXwGAGwiiVVN6wIACsHB5gnHAgB67maHaq8CAGzZoXmqigAAsC+b1ZIvBAAHnABALHUBAM5i/+lojgAA+fK4CtUJDQDk5Xskq7gJAIXksuay2Q0AOBOaR6X6DABwj3O9E8sEAK0wwUsKUAUAlYaTeqEnAQBt4zT6JioAACjMHi7RhAUAo+t++PPxAgBKthXldYwEAPAeB1JpWwcABlSWQm3UBQCfn5gGYXQHAOIKPDUemgEAvb2W1c1yCQCDFojfHXMIABSBT9YmBAkA2aOp2E8aBwBqJpA5vTYHAMMF+rpgdQQAoy/Mq9wYBACChs/OkVkDAGCMS6lxQwIAwyAcsUYVBAC0szSTUC0DAKpwriwQbAEARfQb1Q1yAQAhmK8vZq4FAPqHK1opEgQAs+qT4mFSDQDLZZt1JmQIAEdqEa5lAgQAvOW6BCPABgCtldG4C3YIAOnWfvWImwEAOaMEGb/NBAAsT07NSSsEANkJGXcuGgcA0lK7PhVOAQCKgebNFxoGACeIEDStPQUAtlVcxTIrAwCjR5NfFvkCAKwzvOlLswYAwPJxZWVpDAA+Qm/OYaoIAKAnG9dA+QsAadFznfGFCQDc5mJ7nBsIALLAeDpkLwcAe55PwEXeAwBc+jCN1gYHACQvjj72lgYALZLwGCwBAgApncha5VUDAAFx7BS06AMAkAxSfLCdAwDh73ebHvQGALrkhLf1igAASyzMidIUCwBNvPHiUDQKAPOSLzmTzQgAfGuUagw3CQCX/VodPEIGADMlH4jcmQQABsV2ZPJOAwCXFHTSB9EEALP9br3ERgMAoWMR13krAwBqs/zt2fgFAJA5v9zo5gEACvOKNE+XBwB8nPFOcuYGAOITvO+lgAQADCLOQuRMCQDLFiWngIkJAHZmuA34cggAbVLaHzMDBwDIkXbUMUsKAHEgYgEL5wEAaqH4tWPxAQAX1Bo0r2oFAPcw2DWWmAcAe8sAdqJ6BADD+BXA7R4EAEqF7yeNzwcA+ZNGWOOJAgCnCbNXeEoAANpN0YW1RQUA4SGz49DkBABArNLjH0UHAI2p7nj2ZgYArf5nhoU4CACMTObDLdIEAA861KBeJwcA98zXfROBBgA4mre6nOcBAGqmiUQhKgIApSsznC/2AAA5XzvWiWUEAJY/7Hn56gcAqLlyFejrBABKaWFdfxsCAHFjowH6wAEAPWqTjA4rCAAgzbZYO7gGAIAm59PYfgMAYiqf2zegCAC70rEZVAAMAP89lCK2BAYAWBp09pnIAQD7MvLiGQIGAMv5p5KuXwMAyrHzFDb6AADwgr65vf4DAAAUkpVI5wUABieCOOpTBQCMyM8kfKEFAAr0rhii+wEAlAF7PgRXBgDn6e9VG8EFAPt0oMZ7cwcAzFXjHOTqCAB19z/RNcUGAD71yPpIlAQAajXoxnRPAwCi2wcGeK0AALY+tn46IQcAhoyqrOOSAwCvNYo+6TQFAJfJAv0QiwAABR64rMJqAgB5O86YjJ0AAKxQTf4XXgIApyHxdvV/BwArcvyw+eUMAMcoDZuUbwQAJu8XXebNDACXlvgoqLsGAHb2BB7XmwAARaHyQchaAgBxOIKsfqQBABpYbMOoqAEA+6lCFHVVAgABOf6QZrwBAFq8Wi8TFAMAKNUyUYMRBgBXirSOS/IFALf29wTVWQUA/WbS9ueRCACIcwPvYGADAIYSHeyIhwkAr45HHESHAgC9VDNq6iMBANVU67N4gwMA7pSPp6rUBABNp3XoAqAEAHyxZxOFCwEA4wdYLbEaAACWLeNBkBgFADECCSsGWwAAj7fnZhfJAADsOKFVD6oAAIqRLB6WowQAHj8j80TWBwBkwAKen8YJAJdoJuXlagMAeYvT2sGPCABAvdnqzooGAKC75vjgOwQAO05h/N+PBgDgO1urHekEAPAvIcnUsQMA27E/zmvNAgAQwtfzDskEABaHgaD1lgQAuDnCjPicBwDb+GwwnMsCAI9QWw12lQUAkCcC/evLAgAFEewqgrgIAMu8JtLP0QwAvXFJ+rIVBQAVRfVdLMsCAJdjqgThvwEAJWyZ/5QUAQAAWD5iUUIGAL5E4MWf1AAAKcvtQ/oJBwDKKv1jjF0CAGH93ynNxQQABa9I68AuAwB8t/mRk48BAIEMz54CDwcAubAQXqqvCgBMJVWD4B0GAI3C431Y6wgA1Lt9n7vwBAC9dCpayk4EADM+7S6zBwMAwug8sIp0BgC8ELiaDXwFAIzpJKJkLAQAFMOm2NW3AABD1ZV7MkgEALqk44FmFAAADE7DrRSHAwAwjikOb/IEAN7HEkUicgIA/HWpQoq7CwDuF2u01fIGAOVwMSKptgcA5rfjP3FTCADBa3/9NZcBAC40xUmvkgQAVwNa31w2AgBgu/+nOCEDAP5GRtH3oQIAzESK8V0bAQBmQshC0JADAHXcjyrj7wEAOBKu516SBgAy6NCBkq8EAPgdGRH5/gAAUHVibGljS2V5QSBSaXN0cmV0dG8gU2Nobm9yciBwdWJsaWMga2V5IHJlcHJlc2VudGVkIGFzIGEgMzItYnl0ZSBSaXN0cmV0dG8gY29tcHJlc3NlZCBwb2ludEtleXBhaXJBIDk2IGJ5dGVzIFJpc3RyZXR0byBTY2hub3JyIGtleXBhaXJTaWduaW5nQ29udGV4dHNpZ24tYnl0ZXNTY2hub3JyLXNpZ3NpZ246cGtzaWduaW5nc2lnbjpSc2lnbjpjQ29zaWduYXR1cmVSZXZlYWxDb21taXRtZW50TXVTaWdJbmNvbnNpc3RlbnRtdXNpZ19zdGFnZQAAGQAAAAQAAAAEAAAAGgAAAGR1cGxpY2F0ZQAAABsAAAAEAAAABAAAABwAAABNdVNpZ0Fic2VudE5vdE1hcmtlZFNjaG5vcnJrZWxCeXRlc0xlbmd0aEVycm9ybmFtZQAAHQAAAAQAAAAEAAAAHgAAAGRlc2NyaXB0aW9ubGVuZ3RoAAAAHwAAAAQAAAAEAAAAIAAAAFNjYWxhckZvcm1hdEVycm9yUG9pbnREZWNvbXByZXNzaW9uRXJyb3JFcXVhdGlvbkZhbHNlTWVybGluIHYxLjBkb20tc2VwAAGoAQABYFNUUk9CRXYxLjAuMi9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9tZXJsaW4tMS4yLjAvc3JjL3N0cm9iZS5ycwAAAJL5EABXAAAAYwAAAAkAAACS+RAAVwAAAGQAAAAJAAAAkvkQAFcAAABtAAAADQAAAJL5EABXAAAAdwAAAA0AAACS+RAAVwAAAIEAAAAVAAAAkvkQAFcAAACCAAAADQAAAGFzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6IEz6EAAtAAAAefoQAAwAAACF+hAAAwAAAFlvdSB0cmllZCB0byBjb250aW51ZSBvcCAgYnV0IGNoYW5nZWQgZmxhZ3MgdG8gAKD6EAAZAAAAufoQABYAAAAAAAAAIAAAAAQAAAACAAAAAAAAAAIAAAAAAAAAAwAAAAEAAAAgAAAABAAAAAIAAAAAAAAAAgAAAAAAAAADAAAAkvkQAFcAAACNAAAADQAAAABZb3UgdXNlZCB0aGUgVCBmbGFnLCB3aGljaCB0aGlzIGltcGxlbWVudGF0aW9uIGRvZXNuJ3Qgc3VwcG9ydAAx+xAAPgAAAJL5EABXAAAAlgAAAAkAAAABAAAAAAAAAIKAAAAAAAAAioAAAAAAAIAAgACAAAAAgIuAAAAAAAAAAQAAgAAAAACBgACAAAAAgAmAAAAAAACAigAAAAAAAACIAAAAAAAAAAmAAIAAAAAACgAAgAAAAACLgACAAAAAAIsAAAAAAACAiYAAAAAAAIADgAAAAAAAgAKAAAAAAACAgAAAAAAAAIAKgAAAAAAAAAoAAIAAAACAgYAAgAAAAICAgAAAAAAAgAEAAIAAAAAACIAAgAAAAIBhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgOiBI/BAALQAAAHX8EAAMAAAAgfwQAAMAAABkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNsaWNlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhznPwQADQAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9tYWNyb3MvbW9kLnJzAAAA2PwQAEkAAAASAAAADQAAAAAAAACwoA5KJxsGAJ0Yj/yl1QAAYAy9nF7vBwCeTICmlYUHAB38BEgyuAIAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL2JhY2tlbmQvc2VyaWFsL3U2NC9maWVsZC5ycwBg/RAAcwAAAEQBAAARAAAAYP0QAHMAAABFAQAAEQAAAGD9EABzAAAARgEAABEAAABg/RAAcwAAAEcBAAARAAAAYP0QAHMAAABIAQAAEQAAAGD9EABzAAAASQEAABEAAABg/RAAcwAAAEoBAAARAAAAYP0QAHMAAABLAQAAEQAAAAAAAAByO4z1xpMMAPYlw4Fx3wgAtkw+Cwv1CAAxTKSFkzIFAEs9o9P5fAgAPpFA1wU5AACic9YXKLoAAHzm9CcoPgIANBrC4NIzAQCBjyn50k8EAGiqeocFEgEAedWTWJV5BACgZ5swZg0FAO7lvg0t1AIAxvCJthfxBgAwl+5MqLAFAORVcckQHQYAEGoJyJwFBABPAaiNYHoMAA6oueFkoQcAZdL8pOgfAQDMqk83uLwHAE9N7/RaLwUAEI35mEAxBQC9VXVYkasCAInY0A0/kwYAlUJMu4ZDBACMUGIxbcsDAMaicrhoYwIAmyvxaoKiBQAgu6UIRLwCAEJUoN3reAgAIkE1ErH/CgAshvWN7nULAB9uFM9clAoAutZHpMOCAQDy7zblZCkCAFMAVB+CkgEAXI54nvH5AgC1sT7np1QBAIWCKoHx2wMAl5c/uhf6AAAgOJy0nPYGAI2Fsw1aTQMAu7OW5qs6BAC/o06U0FwKAGJNGrhzVgcA1MDRJblQCQATQSnZOD8JAMiDkqa+YQQAsSEyqposBwBN93REd2cCAIWAsumwZAAAySc79U7wAwAx5dLV7dYBAKKzuAHIbQMAMF6T1KfgAAB9DczOt94BACzdIE6pUwAA+aDGsfupBwAcY6imimcGAGWz2Ig36gUAeUKZ1tYbCgDi5BlZ56wHANetONOeSwsAZICdA34hBgBtfjMIpN4GAAaCYhLBegUAcwTjZctHBgDJrR+lBZwEABuvRZC/6AQA1uBFOuMUBQAP/otbPFMHAMkUfntVgwUACLAhIBc8BwDeKoCKhAAPAPblxAVG4AkA+meXG9DABQCLOEKfiNcHANhGJa5aJwQASEOGSQJbBwArJnAQ4S4FAM1a+1SuNwIAtao60NG/AwBcnQKYtYoBAOmJYP3FLAMABZuUXFAmBADSegyIGGoEANrMiBgipAQA31MrUmXcAwBtfwCiIsIIAO1325u3VgsAzRL+HugeBAB9CQe9qSAJAG407H79NAIAk79/MjsBBwANau3tbjMBAK/zu6JltQIAVRlZic5TAgACdtGCeCYAAHijLnMZoQAAbCqOuvE7BgCa35DMlJ8GAEj8m3fRMQQAl6Dab7qXBACg6s8TA8wGAJmkjYQTowkACSMZQlPLBwBg/d7elpUDAN4Sf5EiHgYAC8+MRobNAwCBwBoiU4UEAG4KTktGyQYAAwQYhLpfBwAFjSHUXDsEABa10JsvdgIAs8vd++fGAQC94qzDCVkHAMk+LZcBIQQATa4QEtYRBQBunQ6V73YGAFjyieAauAkAghiVIkk8BgA3MptN1fEKAITbTZIl0w4Ah94gREiGAwACgbZdstYCAMBzKJa0UAYAlBMn/RwIBACCJP7mfxoHAFTIyKW4ggEAjm1A5cs/BwBR9M8wNN4FAEGMrGe5VAUA7lllS2x0BAArmsZtPHsHAG76wj7x7QQAyOp711roDADZe46yotsHAOlP4x2lyQUARxF0ZMhGBQCQJgmZ36EDALvW9MmMygEAAzvNyX9rAwBe25c0ZhkCAGcO8XnP8QAAon4rCss8BABqd//fiVAAAIiL0+GE3QEAIgjGA0WABAC0f6Ms0J4MAIN4lbXCdAQAg2aBjji4BQDka7dUxLYMAAVlUYo5Uw0AddE2OtIhAABtR8ZzM/0EACrQ7h4pDgIAEHIuzy4vBgDkjYWY4HEHAN8eRXjS9QIAQnOZM7EwBwB1aesgVJYGAM8Wpb+jCAMAWv9oHe2lBQCDDhX+KhINADECu2bJrwQAaII8g3jEAQCPFPzDOXgJAPiLfYnLSgQAWXNSWMXgBQBc169zWzkDAHC55KSvcgAAbQ+eMhQiBgD9/jUBthkAAINLE14UaAAAzMOCCYbkAQCZ1xNf+2gAAH5URDcoyQcA0mren8RQAQAlEUcJlfIDAM8xyrTuKQcAvL91tSKcBgAS4rxXCJEMAJi7daC1sg4AaKjcnDyGAQAJF1opDncDABP9IDda2AAABqtxH//gBQBf4JF3bYoHAHa5oEdLcAcAF6sa6YKuAgDNBphC1gsFAOrYjxVVgAYAVa3E/8clBwCymc/RFWcCAIicpkFUIAoAU0vNfUJIBADFvYrokdEJAB7Ld5LMlAcAwJjQHPcrAAAw0mzMq50EALIF+TNlCgQApLgurO9zBQBfhV9iVM0EAFNQrMImxAYAXglLzl6mBQC2a/KGQMQAAIV4GWiVQgcAyPy2V4MABwDuPnc4J2cIAHBhn3m/UgcAIzPj2qa0BgDc0eqWRrUHANAahen3bggANEpYgrufAwADeiWPVnoEAJGtHgmITQEAJM6xGFsUAgBtnWajkjoBAOV9V8AcdwMAUpmLuwbKAwCQA9XFgQsAAOyABzQSNQQAr6L43ZbCAwATpxTZ+RUFANVVIv+RMQcA772kwlxPDQDOixH8V90DAMeQNDmdqQcAQSUfuy5NAwCd/yO3FegAAENU4ha0hgIA6L7ROP69AAB3dADHkqgAAOijvTYk7QIA6pHyAP0qAAAho96Bc74AAJOxstRS6QMALzAoLXaGAgASW+M8CTYIAM7pUnVNtgsAX4QL/uAeBwDlaclgBp0GANmpRqAdLwsAvfUuziuOBQCKb4z36IwGALJhkuMm7gYAnc8LpQo9AwAXbz0qb2gHAGp8WW2mEgUAUXWlcJpgAABMRjyKwCYAAOE57sgfUwQA0pqKXzBhBQC+rpLsjZcMAACifK6taQgAVA8pI+keCQBrkY2JQZYGANQ1PsWuCggA1cCw5yjMAgDkbIrrYHsHAKZ3woUpBAQA69NGe2U2BgB8xfKuoTAAAKrSOgBz9wEAdg/BLGQFAACm/Cz4SDsAAClD7hA8QAIAZUDCwekLAgCmc5Yk2IcDACp8ktyovg0A7w5l1Y69BQDhQM0/Du8IAKvwYTOrUAcAYF4C4krkAAAcBCeXe/kFAOzswHI0aAUAfM6xLoiIAQB+BkXFZJcGADcQ+KKDMgIA0SN++a93BABou7yNlbgAANat6JdbIAAAdXD7s5ZPBQBmkmYpBPIFAPVBSa6vjwgAh3brxINdCQBFQcqeN88JAHS7Upz+1wsAzR6xFsavBQDvIo/sSp8DAC7ZJRaeswMAc4hQ1Fv4BQBd6Ps5aI4HAGuFuDf3LQMABk7xQoNgAAB1QdeJeJYDAFCl+wcZIQEAiAA1jyYPBwBHX4Cxg0UGANAsg68bLAoAFtfUG8AyCQCOW6fD9OwEAIitz0XTwAcAVfPccCARBABk5CKc/9wHACUz4GDaSgUAmnbvjtlcAgCMmwNs5QQEAIozeIxLHwcAIyu8FvwsBgCq2YAS9XwBAFqpIF6uuwMA7KpiR3UNAgBFtzvHb8MHANFLc5fHpgQADpWziiTvCADHPqXJVDEOAO08b+TxuAoAQ/W5NbH+BACuk62S0TsGAPfNEqYuTgQAq4MVmfRwBgC0kIfaiosDAF35Ud+cSgAAuJbV+2PZBQBK5axomy0CAJnFNoiOqQQAoesss65JAAAxefx1C30IAEl1uuRMbwEASb4/wOSsBQCcFSrBDn4KAGYPUxfulQcAfv7cYzx9BgDuGsit8BIBAGVxgkzwPQUA8DC0M1v+AgBijQxeZhwFAIG97FIKWwIAqeT8lQbcBQB9BHXFKLkDAOWGJlHzOwIAVNxJvxnNBgCGw69lIWEGAP8DYqMaFwEAqqggqC5kCgAPPzF7u/MJAOMpdDob4AUAo5wXUpBhBwDQr/CTZcEAACh0XHnEZQIAQlRdUUAcAwAuC7Q9D1IHAKFXk9PjCwUAtqeU0jOrAwCz7Vm6ecQEAG8yTRgNwwQAPO/MyZIQBwC8HQV0rNgDAK3QQ/W2CgkAj9oPrPPQDQDj5XMlHe8FAHoTt1s6FwwAjJFkAz9SAAB7imNt9YcGABPQipKWBwIAM0+lBYTTBQBXAj2wFeoAAIoh+fAxbgUA+ALhiF9jBQC4pWnZxcsCAHo0i8n7MwUA46QUVlb8BQCOmJB35uECABJJ5JqL4wkAU1YHtPtIBgByzUDY8Y0KAGXUCXRMIQMA5XptxA1XBgBt4pEbn4oBAKtCPxi2NgQAmIFPqqxQBQBUxBTEEScGAHAXZQZ0ggEAZcKG8kTRBACBku7wiHQBAAx2XNtsngEAuOxzQKm+BQD40kPzY84IAI02Hn2o4AkA6Z4BvO1FCADQ0CjtmpcOABpPlIUHrQQA5JvIEgm/BQCDjPPKrS8GACzOs5bBXgIAewFP/1V2BwBhjxRczaoDAAGDMcM0OwYAsdAELebgAAABZ3IzonYGAGmXLQSangIAKJAdy/CvAwDyNMX0C0MGAERyUOTDZAIAcJKjGZ9MBwBHvJn3hD8HAJm9Mvf5zAoAXkAgOuvHBQD4MNmqtf0FAEeMO+ZXpwQAViSXkpSOAgDSTG/o5xABAOT1A9ae2AAA+IoBBBYeBQAYIkrc7rgAANCEk4upGwUAk5YLflVcAACwDsKJsLsGAO6eC/tB3wYAb+GH7YcQDQAwp59c2wIJAGAYhPD+iQIAb37JHzHOAQAf27U/PwIGAJj86HWXtAcARVC/rXCtAwCY/njBVOEGAL+a1v42YwEA7PkpuWbwBACTW2ye/+kEALqyS7yJjAEAypUqZL+vBgC5qBP5cFANALsrrJ5hZQcAWXT0JVKrCwBHW6sU7WwHAAG47TwJLAkAwdL1YgzeAAC1T3PPAZYEAPbwY4LDtQYABm219T5iBAADlRuFS9sAAA8ZuAiTfwQAgh9iXCMUBAB2Whr0Xx8DAG25qnNncwYANWaceag6AwCebBX8iPUIAGjwpE1BYwMA6oq22WopBwBDrhYTcdMEAFiNHAzNEgoA8lwIvR71BwDh9eNn+iwBAGrU4/EMgAEAqPBfYTdDBQAhjp7yxjMCAIHHGH8Q1QQAXhql009KBgA3u0gEzfQEAB4VQ4XTcQYAFBmReHfbAQC2GnDdaUcJAGa2tPE5gwIAe+OKSyGrBAD+sKDvCl8KANEXoKgsrgcAb8JrfDlSAwC+eyKgeooBAItf6sGM5gUAXx16Oj7+BgAqbtJ62RoDAGK5IAntFwAA/bZTO+OHAQBjFHqQKVgFAJKn4EjyQQYAImY6xR/tAQAtLQkcpkIGAH/REec3GQsAIUHN7UvcDADePYsMn1YKAKF6pWTWAwUAbvKJTY7pAQCX/vwWrhAFAHwLznIRFwIAgja/7ZFRBQDAi/I2K7EFADcVqZBbOQMAQ1m+/Ob5BgAP6ubqLzoCAAYfAZWMcQQAH5peaAZpAwAdeNhPPL4EAImK/GpxQgoAdjy/5PRsCQBeMveT9dIJAFuABM/cVQMASJ5puNgNAQBjjY/rOkYHADPAkW6FYAcAVeCOACvPAABLRwgnEbEFANt1PMtNmAUAd/nPyv7qBAB72X5YBmYBAFvEWpzYsgcA5Foie1iEBQDDfqZmD8EFAAqJ+DJymQUAha0TLobICgC/6f+nRSoGACqYS7onXggAplcv8WOjAwByxn2Fd2YDAEXXUN1uAQYAVAQMpO13BwARfbiPkdgDAE2GWh59pgYA4McQQsUbBgC2upY/q6AFAHVHiLA17QIApWRNQvP4BwCvhkiyB0gCAGNPvF+I2AsAsyNVPpUVAQA90hip1zIJAA4xoMtV5wcA0U55JDYpBgDaYdEeHu0AAMNvuA/zjgAAZwv/flViAwA1MpwFp8oAACMwGnZSTwQAXxPN3tIEAQBqOJlmZZEHAH4GeiNxGAEAs3DuKmxTBADDucwh8+8LAJsR9yqkjAYA/eJoLlqMBQCH9i8w7tkDAEmkXA9doQYA+redWQKjAQAD3ET4Bf4GAJzTujUGxAEAfyn8Df84AgBHukGA37sHANWovwnx4QUAwRGeOEQ8BwCrk3BjIV4CABvNnJd9vQUAzTVAbSBcBQAldt6QrfoHAERhHDmGwgMARp8ILmcpBQAQru3MhxIOAHDuIjlrzQUANz1EuFmBAwAqLp/s2VoFAG3PCvB7egQABmAKzixcBwDpdM2L/HgCAMfrM9aUqQQAB9739EbPBQBJRISvUDQDAHBPGPopFAIAiKuRUmFoBABv60zVUTgIAIflbK2/WQUAp4i0r+SJAwCMqZBW+kICAIk4NS8+UgUA0u+lVJwJAQA07vLzCh4EABoU1z/vUwcAicdZDO7pBgBOiaVm2zYGAN7U0HtuUwIAX1M8frRsBQCWhD3UMCEHAFk+0XpEzAcAsFlV9owoBQAJiNnwKbYKAPEhzuGqfAoA68fy7+suCQCjxCf3L+kIACNFX8hwLAkAmyiXCsXIBQBS9kclUF0HAK76Y6Uk2gUAB2N56zYKAwBkqVW1AT8GAH92OOWlvQUASI0ZLGH6AABMpoBFzVQDAOq0z0meqgQAYqsWVBY3BACGrf3d+7EFADq88c6WXAcA/ga2fnQDBgDMjAy8tdsIAHG58YXpbwQAmkvmNigKAAAmLE6nkh4CAJPaQNWRzQcAo6eRMkIeAQDdwnLcRuoDAKff4oiFAQUA/lPd66A/AADQ55yV03ECAOxLLwc1pwQAMvR9yrCIAADAbP7+VA4HAAyCsqMcdQIAde46fI/WBAD6EYdP/UkMAO31CnBVxwMAnapUfDNFBADIpPltyM8HADpC22FtRgQASuvQx/a8AQDhEGFUsNUHAJYFx9eWOgcAE28+YF9hBwD546teA4cAAGo0IwuyVgUAdzpLVlyuAQA4WQIDTK0BAEGbcEuNjwIAm+9PkIoXCgAD4HOAojELAJGNGUGmAQoAW41wPobmAACxv1S2FJkAALeWJ0F20QEAD3Q+mAfDAwDxioEez9kFACtZoeI7HQIAe+uDGFdMBQCqbq8sMQkBAG6epLwqkwUA4B82DAqqAwCT9t8I5V8MAIKycfDBbAUASkAfE5XeCQCt7nSTI6ABACCLcA8Z5gMALu9J4SFuBADPIC3OAEoAAASDM8LM4gEAT646VdiUAAAaDSOfMO4GAHe4Z6wyrgAAKSdB2I/qAQCKiOi1JqEDANh7ErqwpQMAHU82mN5MBgDnT2y2grkOAF4IueDDGAIAbNDiPuxUDgDCqzyRlgMIAAJCFMxnlwkAUGQfB+TWBwDh5D7qw/cBANrj9M0+pQAAANJ+ecIYBABTtOWAGsQCAEvFnY7gDwYAt6AJw/GyBgC8u8sROykDAO2nWIZX9AEAHMh3e7yTAwACjM1oqGcLACY22a0ZRwcATxRa0UoXDAAj+1z2PUsDANPDmlm16w4AVUc/t0WGAwA3XWFzB7EBANRyfeoFAwcA4p2K3PsxBwBOytC7zsAHAL1ZYDDaxQQAU0i/zO+sBACvt5lsWrIGAGdoAjMYRgYAlKl2Ea3OBwAi5k3GCB4LAEIMKpJxrw8A66wcIUjABgATDlubbm4FANDkTzcWuAcAg0dWaNtMBgDfZliCzToAAB3KTEyPuwQAkfDJ5b+oAgDXFMTXcy4DAMw/EQTBGwcAUgprThnxAQD08XBRkH4BAOs6zpPHsQAA8JbO42r1BgCmtPaG4aMCAO+oJq9kHgwAfZkF/to0CQAyx+25onQIAKqS/Ja8vAoAc5IejO2WAACnq8vawmgAAK1NfpvcywMAatGbxs2LBgCzr/6pJ/8GACljH2E+9wEAgS3IORDVAADFzsDXsLgBANI6AnCoZgQAhOJtW1orBwDDN6MoRiwJAI3nYPRnbAQAXnJo3uWQDABBjAHSNYQGAOf9pnpaSAMAIOdo7XSXBgAmfpXifSkDACZ043cARQYArpy1KP6zAAC3lw0WoRoGAI4SVX97igQApuSyxbC6BgAtL90wIYIDALR49rlZoQAAje4DBc7GAgAHm0Z25hcHACnRYzwEPAQAszPQDClKBAAB3FRwh9MJADiDN7XC+AgAiShjnLHfAgCwUZ5IJYUDADNbemlI2gMATbZyd/LUAwBJJtnReucAAHVc2/IdMAIA48U7owEVAgCCA3U/tXYCAFx3AXC8+gYAjSXHVB7MBACc4Tpr2OELABIXpxcwjwIAnnoM5E/QCAD+z+EiwzsHAC2jNyJPKQcAjmNDdWbABAB/fh/JiQwHAH2Y0JvtpgIAoFPX5HpyAQAUdc798y4GAP0+ffcXgAAAy21IPg3HAwB2R3t6lwkEAKcb59ReUgEAZlbRh4ySAQApcghm1UcIAEbJGOuyVgEAi6a2bKQ4BwA6MNSqK0oFAJ9J1MEOrgQAMCF+tVqVBABho76eyLIHAP6tv2Wy9AIAhHY6AiEYAwCPRXQXtH0HAKd9vqKbywYAerC6D5wBAwB2rBkS/0IHAMlL0l9XhwMAMdphNBt/AQCGKGwDPWsJADNB85x83AkAdB3rAuwFCQDJc6zj1SYJADxEP8SCigcAUs4DNJsZBADJsRzibE8DAISNstSc2gUAor0Wu2gTAwCprROaudkDAMR1JnASgQMArcDpKI1oBQDnRL//sRIHAHut05wiyAEAu4G9CJK0AABvBw0K+1AFAH/A2h3TLQ4AtCOrI2ACDAA2zMmxYCQKAFAt2mQK5AsAQXIoLbPcAgC3JpiwkrgGAF307DlgowUAeX4J1sOQAgAoHy577lcBAJ9wyp0upQUA/rKX/+d4AwBCi5RU/rgEAHh7160PWgcA+1VcEXeiBQBCTIXlIdkIAGdPNsb7DQcA7PGcuLlICAAmKLex8bkOANItiZHh9AgAzACDMhUwAgBiVfj0sPoHAB37IcPjtgEArL4WnCd3BwDfF6sCm2gEAO0yQewSHAUAd7i3ViQbAwCB0YdTHsIFAC/KSXrDEwMA3Z68LkOyAwDc2MeBl4kIAN8ChTHnDQkAZ62QvhjbCAAbsRUR2mAIAIwyMBP9YQsAWS6Mt8LMBgB3t5IvOAYHANxkN/RYAgcA9gSa/8bcBQDbsiofXMUGAIaZFWWBDAMARZroofguAgDkXOISEegDAGoLtKxYQwIALHuSWoTNAwDMURks1wYNAF2i/gUfvQwAzKjv1zluCAAjUVi1qlYJAH4kx4qZXwwAsNNv360VBwCi49brGs8HAKnIAXEbOQAAaas1q4doBQCR2qDoIWEDAM0+XcUoBwMAgfRmKs2IAQANhVs7M1EBALlqYaP/jQEA1WbwbAg7AgB81b20gGAGAKwxRpfGMAkAj/L15vCyBACAmiJ/ogoDAPEUkKFfbAkAXhkF6hhRAwBtuCAt+EYAAEVRx8o8SgMAloTCGXU6BQDoxohTux4AADv1cuduQQUA6KESnXO5AADjPyZDHFgCAKvhlP5XKAAAc4SB8U6GBAAduNALOqgFAKEZhYYjdwsArTsZ0vtUCACBTZ83cygJALv2164DbAoAs5pjlzLDBwAC33EaDWQFAB4f0TzwiAUAHcQlYC62BwC6TcPAracCAM59HFgvegYAw7ItNQUJBAAleurwkCYGANw9pWxIqgMAHZ6VaVGLBwAtzGlXWsgEACt/ZbrpSgcAVPqb26AaBgAqC8XlDtoIANG8JALsVwwADRhd31SCAQAfoow6nf8AAFQY1H3EOQIApBqVq5OEAwAeN5C8FCMAAIqQJo/+rgAAPW9ap2q/AwDM7lroOxMCAHWbvMXdJAUA8Pw0xXKVBwCXlXTgAEMLAIaGmIAMcgwAl9x8kSYjAgDLVftJCg4FABl/bgsMiQcAby1bozyyBQBzJDeYJVcHADYo7BKoWwYABsSbGYKfBwAOtpiN3w0HAMRd1/23QAEAkn7TAl8LAwAOzI4WEtICAPYYcawVVQAAp4keaWlXBACtQ6Zb3D0GACFnbSM3PQMA+3MhQnaeCQAqCDrXRTwOAMYFa3AP7AIA2y1bNAXjAwCcanNdgL0GADCnHvWFVwUA7veuEQHBBgDBAS8jdAsBANhZj2CUFgIAh5+Pocf3AwC4NyXCUTgBABU3WyjIUwMA9KMlnfrWBQDKpqOy/loMAIS1zAG+8wAAtLOZtnJ+CgAL+2UmA44LAJ18iEH6dA0Au2xu5IVBBwDbSMpH5CUAADCnqRiZ9AUA+vv6vzy9BAD2dfcE50UGAPoeid7aKQUAJRn73EWiBQDP6TxEVDgFABTBrBp5mQQAq8pNVw5CBwAJSyOUP24GAAcfgkNo0wQAh+0hl1IRBwBJ2JmlojoIANs8nPpgugoAPFE0oDihBgDsvnM63+gFAICYP5iSGwUAxoAcV5TpAQAbWCtj9E4EAMlk0yEcSQYAerRESaSMBQDuaBddchwAAODsiHqr5wEAX0vEmUgFBwBZ8bImlJsGAHrdKnZQUAMAUoADwETPAwB3eUDHjHMGAP9txZ1tQAIAo3hZE8pNAwC9bhU7KKgBACnAAWCi5wUAuzygY8Y5BwD/tuLONiAFALCgDkonGwYAnRiP/KXVAABgDL2cXu8HAJ5MgKaVhQcAHfwESDK4AgDqQF2Aqv0AADnTVy5I6wIAWLx0AmEHAAD/yD1hC1EGAP/6XJDIhgcAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL2JhY2tlbmQvc2VyaWFsL3U2NC9zY2FsYXIucnP4HBEAdAAAACEAAAAKAAAA+BwRAHQAAAAnAAAADgAAAPgcEQB0AAAAPAAAAB4AAAD4HBEAdAAAAFIAAAAeAAAAAAAAAO3mIWe9SA8AWuRnrLW6AwAb5TXr//8PAP///////w8A//////8PAAA70VLpZdIJAJ+mvhXHYw0ABHZoy2W+BQB/IT3H7twDAJowfBtBCQAA7dP1XBpjAgCBZc15L+oNAPneFABBpbzEAAuOARAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTEuMi4zL3NyYy9zY2FsYXIucnMAAAAoHhEAYQAAABUBAAAKAAAAAAAAAO3T9VwaYwIAgWXNeS/qDQD53hQAQcW9xAALprAEEAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL3dpbmRvdy5ycwAAAMgeEQBhAAAAhQAAAAkAAADIHhEAYQAAALAAAAAJAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogTB8RAC0AAAB5HxEADAAAAIUfEQADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc6AfEQA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAANwfEQBJAAAAEgAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBkc3QubGVuKCkgPD0gc3JjLmxlbigpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL3Rpbnkta2VjY2FrLTIuMC4xL3NyYy9saWIucnMAAABgIBEAWQAAAFIBAAANAAAAYCARAFkAAABhAQAAKAAAAGAgEQBZAAAAYgEAACoAAAByYXRlIGNhbm5vdCBiZSBlcXVhbCAwAABgIBEAWQAAAIgBAAAJAAAAAAAAAAEAAAAAAAAAgoAAAAAAAACKgAAAAAAAgACAAIAAAACAi4AAAAAAAAABAACAAAAAAIGAAIAAAACACYAAAAAAAICKAAAAAAAAAIgAAAAAAAAACYAAgAAAAAAKAACAAAAAAIuAAIAAAAAAiwAAAAAAAICJgAAAAAAAgAOAAAAAAACAAoAAAAAAAICAAAAAAAAAgAqAAAAAAAAACgAAgAAAAICBgACAAAAAgICAAAAAAACAAQAAgAAAAAAIgACAAAAAgGFzc2VydGlvbiBmYWlsZWQ6IHNyYy5sZW4oKSA8PSBzZWxmLmxlbigpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JsYWtlMi1yZmMtMC4yLjE4L3NyYy9ieXRlcy5ycwEiEQBbAAAAIwAAAAkAAABhc3NlcnRpb24gZmFpbGVkOiBubiA+PSAxICYmIG5uIDw9IDY0ICYmIGtrIDw9IDY0L2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JsYWtlMi1yZmMtMC4yLjE4L3NyYy9ibGFrZTJiLnJzAACdIhEAXQAAACUAAAABAAAAaGFzaCBkYXRhIGxlbmd0aCBvdmVyZmxvdwAAACYAAAAIAAAABAAAACcAAAAoAAAAKQAAAAgAAAAEAAAAKgAAAGludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGU8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAHQjEQAeAAAAAgAAAAIAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgOiCkIxEALQAAANEjEQAMAAAA3SMRAAMAAABkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNsaWNlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhz+CMRADQAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9tYWNyb3MvbW9kLnJzAAAANCQRAEkAAAASAAAADQAAAHI7jPXGkwwA9iXDgXHfCAC2TD4LC/UIADFMpIWTMgUASz2j0/l8CAA+kUDXBTkAAKJz1hcougAAfOb0Jyg+AgA0GsLg0jMBAIGPKfnSTwQAaKp6hwUSAQB51ZNYlXkEAKBnmzBmDQUA7uW+DS3UAgDG8Im2F/EGANdxPJP85wwAQ7K2/kHPAgB2Gn0KHFgHAPAyTVMtFwcA0of6Y8CQBQCo1bRCYKUBAFPRnhXMiQEABK48qt64BQDYtRFP8KoCAJKcZlpZuwYAX3qbpbOoAgB/CO9Zs6sDAK8F28So9QQABULQB6i5BQBQ6hNbrwEHADCX7kyosAUA5FVxyRAdBgAQagnInAUEAE8BqI1gegwADqi54WShBwBl0vyk6B8BAMyqTze4vAcAT03v9FovBQAQjfmYQDEFAL1VdViRqwIAidjQDT+TBgCVQky7hkMEAIxQYjFtywMAxqJyuGhjAgCbK/FqgqIFAJ8J/I65UQMADgWnpL+PBgAbl52VSSoEAP2eRhrlkwMAWB4yEOmABgC/GGgFCgUGAL8yVR/MKgYAJfrJzEGBAgCD5nH0YU0CAFpEx/QzeQIACf92xOn7AwBCSy6Ya68AAOV4ulESrQAAiHzu7a4VBwBTNfbL0PkHACC7pQhEvAIAQlSg3et4CAAiQTUSsf8KACyG9Y3udQsAH24Uz1yUCgC61kekw4IBAPLvNuVkKQIAUwBUH4KSAQBcjnie8fkCALWxPuenVAEAhYIqgfHbAwCXlz+6F/oAACA4nLSc9gYAjYWzDVpNAwC7s5bmqzoEADFxFXfr7gQAQQfxFRkgAQBWnGzanGYJAGw02zLAXgQAwyxqu1ceBQCkjH17tgYAADMp50T6hAAAim9d5U4VAQCQcy6EXUIEABfkGsRkiwMAcUvqAmcyBAC1MGA3NGgAAIDD+RIF7wAAhCVR8qnxAADW8KmRjgsBAL+jTpTQXAoAYk0auHNWBwDUwNEluVAJABNBKdk4PwkAyIOSpr5hBACxITKqmiwHAE33dER3ZwIAhYCy6bBkAADJJzv1TvADADHl0tXt1gEAorO4AchtAwAwXpPUp+AAAH0NzM633gEALN0gTqlTAAD5oMax+6kHAHw+3QRmWQ8ANYsFDlH8DgAMzLKNDGcDAC8zzpnYlwIAzhsGdl6RCADZNJLz7V0HAFQ8H6s2HAAA2vVY7o/wAAA31qATluEAAOAgE0oCqQMAGpGiydn1AQD4/PqUeREHAMWN4sqo2AIAhwwJsrFKBwDE7MLFB2kCAB2cL2MO3QQA2aUiJtHOCgDZQkdh6Y0JANO122+pnAcA7gCa1DfdBgBeUapJVGMDAKtdR9B44QMAEpehEkcLBQCt9A+GwtwCADE98NZ2DQMAx+QGIRdEBACILe2vURIAAFpP7Zv8NAUANFLPOVrYBQBk6BJxaQwBAPLHWIOgKgYAlOFICERvBAAr9ahxt0cEAB3TaTK6dwMAgFD1uvk7CADeX759J8QDAJJM1K81owUAPnWZQBbBAAAj5G8AhwQHAG/WvsphXgIABGZYzCjhAwDix48ui5YFAM9hvdWjSQAA5vYeW1AWAQBuWDSG12YFAL0vWsaFQg0AH3T4zGJeBQBEkLFhuWsMADggcQU0FQkAOnk0X7pPCQA0CMGcn6QHAMYiingTtQIAWznybkv/BQC/B/ZajuwCAMPspbx1OQMA1PeFaRZGBwCa5woAOZkAAHr5ZHlMhAUAPVv54Rc2AQDFP6jOKUgBAKXscU4vCwcAPGT8jhQoBwB2W5kDPnUIAGZnq7Jfvw0A1jVFvMNfCADCld2XhHsDAOj/tNZJFQYAONGxLaIXAgCesC4Gz7kAAFj35XGc/QIA3d6vUq6zAACX5Blmp50BAI5V0lQG+gYA1EFe0hmCBwBRxnV0dnMDAJBlJBTLlQgAZ6ymKtgCCABQSLyD8UIMAEMGChxPRgYABwlzBVm/BgDZrdFA/ZkCAPflBJre8gUAWRzMuu7ABwAKKfixocwEAI+xw1bq+wEAiltB4fF4BwD0we90WPcGAH8CGUBpigIATdxrqTcrBQA1pmfPISUAANFeL3cgZwQAItZZ88AyBgBS4qMrCbICAIAmEXwlYg4A1XyfPXUBCACUUp0KC+4HACfKTOv7gQMAnWM+Oh+EBwBfRMMw6nYGAIIT56cA+gMANNs9li0jAQCNBwvnklYDAB96dxTKRwIA0Pzoa1XbBgCOBPriXysBAJIeb60mfAsA5HsicQlqBABMmy0NL3IEADrgTiBG3AMAbHkgPOn3BgBN4/yWxPsAAD6ufWu+dQUACebOhRWjBAD/MDkC6TcAABL7lm+3SQcABa6mrgT2AgDrI5OT3DcGAEeNBJut/QMA91oE1LCoAAACHvAQ7PwAAEVOJMSd0gIAvkfBG3uSBgA5CKw0hTAIAEA/A2Q2hQQAq/5mkXcTBABEHv5JplgFAInM7641RgQAuvKHSEP/AQBELQ4igfkAAFE8GKcakAQA8PgajFS3AQAWgTZTjIQHAOk9OOdkGwAAj3xYsPsJAQDRJreHuBsEAJuRZnxZTAsAww+ZtlChBwB0IpKd6ysFABqGZHHtDgcAqcZw4HGoCAC+RkN0RH0AAB2oZKW2ggIAayN1+IDtBABQDEUdvvsGANv8Eoxy6wQAiYm8S5m1AQBgBkyoe0sHALiuzfF4VgcADPHWsAYyAgBdaPIAc+4DABh1HoRHeQoAfujaiHMsCwDoG5fTrRQEAPEOL4NQGAgAiPssanzUBwC31n2e5FUCALqe1WMhjAMARVgAKh+GAwDJrstMHuECABJ5KXYVOAEA4NbwjhTQAgD7h+eNKlIDANL5dF4F7gIAEwgx9jhABgCeTNNYz0gBAFp15Jp9LwcASvwPaR5xDwAVDVs1ooINALO2hejP3AgA6erUuv54CgAn8DR59pIEANQoVYHQ3gcAEmYaUWGEBQBEFd5QLuoFANvV66Ev/wMAZjmTjB9oAgA1FpMhBYQDAFKGMErxdAYAkEipiJy9AwDG6S/QTRAEAKVqCdsGTgkAI7DmiZwhCQDaoobUq3gKAB+VYJKyQAoAye9IWlsWCAAqQiQRXr8CAFauVmcUcwYAMOiHmtlKAQD9gLBlyuoBAPX6CrBjyAIAdmqEoHSkAAAyHpjvpZkAAOa/SzyuqAIALIMUrzRcBADs/5t9tpEFAF21GJ9xswkANtODjDFUBwCXl5G3F3wKAGCbCISwRQkAAANn+LSJBAD6m7SAHA0HACVGkX1+1QMAReVlIXLAAwBP4Bk4ueUFAPeofOwC3gMA75LrOi0QAgBGOgzVIowGAE6JhZOoLgQAjPNVv55fBwDLlqS7X58EABtXnB6MYgUAqyLoCLGYBQAaNimuj10FACh7qdHIrQgAdIYobBpqCADUz1uKEJoEABJmfY6MFwYAdQNxczTwAQCYYEphSToHAKa/3IZKYAUAtmQXfNTRAABRLmoxCBwAAEVQyUXbswIADDCNgU9jAQB04p/oiQkCABvs6oWLJwwAzeJ7ZVnvCABvh1hp0S8PAC8LJgWy6QoAWHAPlbkwDwB/zC06/XcHADJJEvuplAUA8BXKgI4fAABpMuw80RQHAGfK0NE+QAAAUsVOhzUtAwApufGNBPMBACObFzvXAAMAC32j5XvmBgADgzBUdL0FACp55xUhkwwAtzC5u7lXBAAmMhmLXY8GAFbUHo9OFgQAfwYjsX27BQDCTLIoldECAPMvMLhmrAQAUa392cgBBwAnN1tcs8EGAAo4B4CnMwEAvmLKxmf0AQAswV0qI8QCAIewE8AdVQcAzTuwEQxpAAAOj9Wm3EAHADxDeARXjAIAY6RzKFDYAQCc1N5+HmQHAHH1TNXt7AEAsMJWUj/AAgBOzs9SB+4AAOn7FoHdYAYA6/8PE2dRBQBclYW4gsYBAOpjqV/SYQEAfaRTe3UYBwAhLw+L4RkGAATsweTf+wUAkrseyJjXBQBr2duLRpkGADUZqWrmPQ0AGptZGvhFCACSQSG9qPcLABkzEqRNHQcAosTmxOGTCgDP/tr0Ri8HAKP33vqPlAIABLzz/c0eAQAl7f6P6cIDAAU5R5ohJQUA4RJRkksTBgDtBrQrlLsGAOLdwEXEcAAAo9fEItgRBAAy8EfEBbYFADnw5/DG/gkAfEcsabzOAwBeqRlqmHcIAA6Ld6Gq6gYAq8VM7y/xCgCJfMQgWYAFACyX+XFHkgEAQMCf372LAwCBspIAAPcBAOuK6tx2SgIAQMfA37IiBQBI4YA0GegHALlBQ6DZPwMAvCCKZ2PIAwBDilGyB+YFAAHPlqUcQwwABBSAfNoVCAC0EI9vmzwIABZAkyJpNAgAVuQ5MfMBCgAYGN9sjx0DABZLFEts+AEAnT7XuHWYAwCzp//Z8PsCAN3Mtsp6BgUAUZ0DCGt/AgCq3wCAL4AEACXFYqCSlgAAF1gHkeq6AQBgJIaoy5cDAOd5E8j7wwUAAi9eJbwbBABQhplW96MOAEF84NR/KQkAGx4sArRxBwCyWVnwkzABABjGLi81vQEAhuqIm3h1AAC5SOoXER0GAOZmBzKdMwIApy86UYbZBQAPG+GZOj8GAG2y1s8OigIAj43hNWg7BQBxmSGJoTEDAJxydZ06LwkAycRT6QANCQCJL28R3wMGAIjg4HbCPQMAmmT/GZasCQDGgE/7RW8GAKL+ue44zAMAH9twcmQHAQDIDXTq8RAHAN87uMZnEQMAaBBLUkI4AwBF/jCd030HANCgQSFDiQEAJcK4Tv6IAACL8EFjQxIGACUmLRrjSQMAbLGmf3oTCADbfneSroEOAFDc+MW/IgIAkI0XoypSCQCNiU6H20EFADMbhPuALQYAl/on8G4+AADoM5aePKAHAO/lCSO+bgQAOElhaVMvAACHBaKt5VYDAAL5a5/IGwEA28gZZHQ2AABDUlAP518EAH4UlcggSQoAXUyUYewHCQAewBfgUicHAHrpot23IgkAoVfb9hlmCQCMCwyWpnUAAEkb5MXh3QYAQaNtUT8uBACe56j9A2oBADkOOmLRKAQA/QijAURKBwAJgVW51G4AAGeIoPbxRgcAISNvXG9jBADTC9aSFdgBANXFhXuftg0A61BWFy16CQCdwb9tPswEAA6+czgdPgcA+Aob1falCwBfrA2mVocGACbsint1XQUAvYBf9D04AwCmlp+MP3gGAM2eeKc0AgIAUrJ4cbYNAgDaDizaozoHANNwHMBFkAcAWRAlFXuzAQD+z1MjaM0HAOD0rGhgzQUAzHR6/JoHCwCzZAtll4AFAJlOnKyrfwQAzbKyUwLvCwC2+ofYW6QBAHzBbQdIVwYAqBGqAIC5BQB0CQjJ7KEEAMC9Y4iMgwIAMFBGSs+wAwAtevWuuCIAAK0l6XcGrQIAekXXZ0EJBACCamCKyx0CALoxd776AA0AUDMRw1PMBwCBDQj+Zc8HAKEbAWbZxQMA9sb220DYBQDIn52MRgQAAIxreVSF2gUAJQCVcL64AwAJpqYtidUGADFKGQg9vAAAi+GfMA04BgAN7rgsPNcEALbAuq2CuAYAvkzd3atuAwAZrDJiJ6QDALh+RNtywQgAfqe3BcX4AwAQP3/5V6gGADrgf1bA/AwAGU6Cngx3CAD6hHCKLEMCAGipqDz3ewQAZygmdpFjAQDOEIBP3+gFAN4W6nwX/wEA/bW1RZrZAQDsmSRPZyMFABMmGCb6+AAAmIwEmHOPBQAAFdRPJp8DAM57Cf6rSgsAMjolA/w7DADyt5H+x5sCABZKhORhpwgAXsNyEmJcDgCc4ufbFzQFAPWUc4JzRQUA3VD2pu5lBQBJx410UCAEAImIRnMtcQEA3ZMxzviJAwDlfBe4JNQCAM1ANA36cwAAl57UDAI5AQDOGasAmC8CAJn9bprdnwoAPygoqZTGBwA6S+TuzfcGAMNcsgcyWgUAjFk4TRoXDADL+J4+ijYCAAus4giqVAQAAKePP5KQBAAvWKSeqnIDAGJH1mxBPwEAjEzJmapYBwBE/wAXAPYFAL0BjEhOaQcA1u5I6f3VAAC9dKVPIQgFAMMD0FO7FQoAwqgseZ4XCQChQMhq6aABALY6u+KTIwoAyoZMinWnCwBL/tY+FWkCAECY+K4jKgcAnGmZUr5SAAAWIxPv5aUDALr6xg6WLwIAdlCuk/YRAQCQypSqv+MDAIe4dpR5RQQAeUhGEglKAgB/3vgV/dkFAAtS1+4qTQQA5KfC0mUIBQBA6jhSW3AKAJY7XbJwbAwAuH6kfxi8CwB/cmNt0wgEAGJgpvb4+gUAa96oLYm7AgDm4sfw1GkHAPv4FFnzMgMADMKG6hUBBwCorSTaiG0BAN8qZiIGmAEAnVoZvOsBBQD7Bukc2FAEAD90rhyW2AQADrp9jMO9BgBjtOGntNMHAPOt4t5LhAgAqmOWJ63LBAB1UiCmobYDAM9t0JEn6AIAhzypynI9AgD0qmirt/AFAEVjutQl3gIAzR/XoCSQAQAaEF8RZV8BAAiXFGeQ6QQAr6XL0dgZAQAHIP7O+9cHAJSQwvPFXQwArnm1IFJFCwCJBh5jwXAIACCbDmPAawoAjM1tGc35BAABKGsmah4HAF3f4nOumgAAo7EZstgNBAAN3hdF+0YFAHV76DVUlwUAaDd7atiXAgAyY0wvWoMEAGBBQ18wcAAArlZOAd2DAQCgh0MI3cwHAIDMYGcYhAQAYTNTZVZDBwABuDZjaC8IADBD9kZUIg0ACxlIqDxZCwAXBCZtLEIGAJS7F0iQEgIA9VS43hmjBQB92mDg1KkHAAwd1g69KAQAp5qEXpoYAwBCslkfu6wGAAxjU0fv9gcAqS0qKUbzAQDWoo0wmHMCAFMkcApMDgkAM9d7o6/aBABhiT7ca58MAOXa7Nz//gEAw5JUlMJyBQAT1F5DKI0DAFgomRlPBgQAzUP1vg9oBwA8jdWD3aoBAMPo63pZaQIAvjDN1kXHBwDveN9Vd3wCAKN/kzNodwEAVRhEFlFABQC8BYxJhfkHAFBjvw9SFQ4Aadp0v+m5CABoESAIg/4MAELeJ2H3cwkAsGnNUyYPCwAX4QufiM4BAAkHUZRqbwMAtBYAckjyBwCRz+HRHoIBAB+jcMQubAcAhQzBqjjJAABBcXntZBsEAG1eGMGxvgEABw9gkFTtAQBHlhU/J/ECAMALp1XXiwgACOZciDqeBADWWhuIhWUJAF1P02h1wgMAX9x+mcGKAwARHuCKfPwBAOfoc1VNCQIA0kn1uzzKBQBDQcXsIPkEALaFrXLl2QUAO7FRpxe1BgDMgLFw088AABr00SV5NwUAoghgVlZOAwCe/svZ/C0CAI7gOxC0WQQA3SotP0uaBQDrjrvINNcHAAlKWb48OQIA3kyCd5j+CADZDA3D4NIDALtxZmiX9QMAmTm2fliqAAAZxpK1x+MAAIxEBWyRsgYAO5G6CtE0AwDbz4G1zUUAADaPOlXg4wUAsv8eBLMLBQAA/wfzA8MEAO1E2Q1YAwQAP2WSffeNDADpSbPjn4oDAOGvCoWJ6ggAaXCrUbEWDACFjLIX1jsCAGFafecu5wYA3k0X/3KpAQAPxnNjY+IDAKuyeI8b1gAAsDbB6e/XAADVCmSJHKsBAJcf9K6CXwUADe0X81dpBAB+J3SvopEBAOgORk9DKw4A+9P6wMaUAgAPTHuTaIMGAFuHECn4yQUARQXg2+c3CgAxFDzFS/cGAMLZu10OxAEAl1yunPvIBgDat+FcXIQEAMy1UOTg4gcAMLQBZ+11BQAmAKJ/4dMEAFNCjIj8kQcAwYoHmbrxAgAVEZtp+hoHAMNQO0ccPAIASB3iHWfnAwDooUdV+iYDANmvX8JNDg0AiI/H+zEHCAAdtlM5m28GALnMPCj0VQUA52AZ+2fdBwDU/q+hB0cBABwrnC4UIQAAgBj4SBjHAACGPCPY2UsEADBY/o5X6AYAtUFwbVsEBAAVfjTz1sQEAF0Zj5j83QQA4WWjPhf2BACIRa752kUOADpi22M31AcA+YgKUPmLCwDJH33Bz+wHAB6DggcoygQA1texfTO4BwD7lTjvbREFAEd+qtr9kwEAb4foNzzJAgD6g8UoGkMDAHnYi9pJkAQAHMF6QKi0BADU8OuZ+6YGAMYj5La1IgkA1d3x31AeCgC/dU4ydj0HAI5BlVRIiAUAXiz0qf02AQDrVQhWu8EGAEitE34SHwcA7FqQBLPGBQDHm4iOa3UDAIkxSpF2XwcA0b0Fo7HfBAApH4EF/7MDAC7ZPChi7QYA4VLsQxVdBgCNvhA1GCIAAGx6MEMBcQIAq/OLtI/YAwB6j8FO60kKAF4p/10RNgkAA9QfRHw4CQAULa1eOGYHAF4JBotPGQAAYjuC9niEAAAIc9OJhgEGAAa4F85xoAYA+IqXh9HDAwC6doLI4a8HAGityIHyHQUAXSSkvQZJBgDt8aomGxcDANFHirLYtw0AwDSeFO7CAgBT/Jpi9XYHAKlJ/FDq9AEAJEQzphTFBgCoTFaXkDEHACU1I7xOhAEA4e79Q0UdAgDSG/+qJ60BAAjPc0j9IQIAQWMVOk8gAgBkpGVAQTcFAIPP7TsMPAQAIKZucH5VBQAkuW9Zqo0EAICXTMhdHQYAnsJAMOh9BADnB2Wy3okJAJlH3Prm1AQAp+igf4OMDQDHnKVcZo4CANkNlBXHZQEAlRyhOl94AABphOPXmHsFAIStzG/ddgYAWJD8loVoAQCfYQPUam8GAO9yd6hZ1wQApL5zYW6FBwBXaiw/98QBAIQ0fPxucAYAbTbsOXiYBgAmf8+VH3MAALzkvI51rgsA9dq3rVkEBwC7oF8wvU8CAM+hdcyYCgQAM3UKIuGMBwCXweEQeiEGAGS/0YCslQcAsyu0kUnbAQByQ5lbYGkEAFiaXHHjMQYAj3LP78/pBwAhzkgoFv4FAPWxfF0thQEAD+Vcvg8NBgB1e+NG4qEFAJDV/wXuGg0A2Xc2BEy0CgAalpThTyEBAMvpqTmu4QAA9/kmtchDBQAd6WeASRkBABfJb0SdeAQAjrdOB6uHBABD44xeO9MBAEYb659BPgEApOZdVh9yAgCau/LuUgwGABFtrnzCxQsABG6VkZRqCwClHRPJuiQJAFwrIN73tgsAZZuNJHcNBwDxi/07vIkFAGtBo2o++QYASK7B1qPABABqWAsmh1UFAPzMEsPJCwEAW6DCPkvoAgBRFTzwop0GAHumYUYXOgIAOPKJorwJAgBvlzq9VTcGALes8ZcYEAcAuAd7tyzYCwD0aXc9CIQGAAfOLUcoKw0AUXxzUTd2AgBTCNEqPqAHAKs2rcbcEwIA1r3VQOKmAQDf/vj8T8IHABa8SBzM2AAAqRm0btMCBABSoBSM9s4HADnRwlsl8QAAahgx1OdzAwAWrafYLQwHAAB+7bh9lgQAOlIv0O5aCQC7lNCRlRQGAAZwwQTycgYAU2qBE4YrCwAO7G+fUJQBAKysMcrYKAUA+rm4c22CBwCz+eCZy0oCAEg5Nsb64AIAZM1I5L73BwA8D9oQD+EEAOkgq7lskwMA0GzqT/ygBwCkNccVkhcEACHNayi5Mw4AlJzburPKDgD5vd9+OE4HANkPisUTQwkAGyRiVqgfCwAq7dzX55QAAI4RjnP6aAAAK+5fCmQbBADUGfCdcLsGAJnNMEo0AAcA9CI2LkJsAgDwtQVqBvMAAKaABI9E4gQAlfDb4M1EAgBSmSoxsksCAFhc+PUqDAgAPojyTJ9gCAASyqG1bugGANHM76JEiw4AtP6fr9LRCADDZ94yF+0AADUWKWnDCAMAUNLySPM+AwC7oaFeRwQAAIjhcejj/gAA3x5iMqGKAgA7Na9MJCsEAIrgwkwGawYA070MAiC7BgAxhXF5zWoBAK22h3jFxgkAKlnXH/KrDQB5hlMS1AsFAFExJ3ELgAsAYIGxNO1kAQA9HZstr3IHAFtOi0SG1AYAqBiN3VjOAgCLPFBnn4QBAAKTa+/gIwEAmuYvGUzZBgAPaaIiUkcFALO4hp14kwYA3Gn7vcP1AQA/B2H8oI0HAIE6DGjxgAcAU9T8PF2jCgD33cfN5QUIACOseICI7gYAOGsxS6pUCABqxivlKF0BAH7LUQMeDgMAjB+xdC8KAwAD3tcMEp0DALFWsu5d0gIAuHwmGY1GAAD5+7Wp3IwDAOKhLFywuwEAM5WOdRWwAwDat2oKYTQBABX10XfnZQoApDkeTPXxCABFJlKVG/ACAG3endvY/QQAzJe6jIdUBgD+sPaNx44DACJqo76uPAEAal9O5cbrBQC4Dj2QBCgDAA2yotsvEAIAoeZcBQXkBgDTMqU1SgIFAJ3y2lSQ9gEA1Yt6DR1dAQDLnrJdcq0AAIVvBZsMvAcA2P/6v/4cBQBJ9U3pu0oMACAx49e77AcAmSMw9XX2BABXJE6DsWcCAIi7eMMZrgYAEtXZXntFBwD7BT14DSgDAAMat//8rgQAHhcVBDY2BQBleAcJMzECALyvNENEUQIA6FY3hcOwAgCGKiq3y7wAAJYS/lBMXg0ADMPvE91fCADt5YDDxsAJAKdi++Md4QMA8wiR1o9nBgDIqbHqL5YGAAujuY+irAYAmJ8byrdtBQDdGHBJWJ8DAGudtQpPAgQAwmNoYzH6BgCwQn6m5QoBADHaH/C7egIAvE/muaeAAwDU6gghLtQCAIB1Uw8NewkALYTJwGNiCQCjOUV+gqsEADrXQ9sNNwYAI7R5Or8gDACb0t+UFRMFAP5SjeknpgMAYVaFQUAVAQCEg5/QdZEBAC2Ni2CydgYARytbHGW6AAAnEHBjI4YFANvGGcLWxAAA3liG/z3wAADPwKn/0kUHAFdO0yFX3wYABgx6di/zBAAgbsfqq9UJAOPhBOHpHAwA28FUvhVuCAC9yMkrHloCAOo3sPPIBAEAmGypb1cFBABvh+OIaugCAM9guc4jrgEASpkyGYddAgBuC1Y71rkGAHLUyBQo3wIA7aQK4r77AADseBKG7Y0FAJXJwraoWwMAv4Uxi6XeCQC9uyPNVbQEAPiDSMAZ7AUA1TG1lqaLCABcxWbykzcHAAI7yamIuQAA2yUjow6bAABefMFxrnwDAF9Ihd45/wIAesXvw+4+BQD9LgLpn/oCAFSBEyzHmQYA+B+9HnUqBwDPR0k7YyABAPcPEklHMQUAV9DA982vBQDtjXgb56kHAIgMO49w7wUAk7M8vjN0CABCAGGReJgEAHIBXX+dnQcAxJ47AZPCAwDKyjlfuMIAAFlNm6kwXQMA9JfpXMBEAQDvfzSKC5YEAPd0XfER2gEArf7AGaxPBQBtr+ftc9gCAG75XU7hAgoAS7U+vALqAgBkNYiydYgDAN3pOlGMKQkA/xWgGDZUCAAJNDdDZDECAK8iO1CV3gUA3+LqGyCZBgB6c/9JWNsDAPoHR2Vz5wIAwSNMl/S9AgC9YdLIubMEACi8qbLoagIAUVwWEIIGAwB50GIzRLEEALicUhzpVAQAz3K/xphMCgCZ2MOUZUgIADv616MTrgcAZq+OQThwCQB6H262x7cEAJjZ74WhvgQA+FUQcbz6BAA4/jZ4n/sBAKYtdUb0ggUA5EwyINN7AQDGmHgRiRQFAAtBoJJNaAEAp8V4D9nkBgAo2rzEocIAADJpvWlIgQQAuF2kkcO3BwBBtjWsFnMFAGoJ6R3jQQYATTEKs6mmDQBHBB9v0McFAEk6C/hw2wcAeJrIPkrLBgB9OYGt6DsEAGRvHL1YxQcAPUaW0yQVBAAdGp5Ea1gBAIrtSpB+8QIAjjwdhtLhBwC6r6BcSkAAAL5vQSobngwAVmwxC2ocDQDbG9eepXUNAB3sHxoCTAcAjn9uUSeVCwDWQ6cKB0AHAIMR3ctkawEAQ+sye0s/AgCzNYKlqxkDANmt3L+VYwQAnJpdGi3bBwAvQoULIJoHABbdcaq/VQMAqnhf6ncLAAAtgp6ieWUHAN80tFITtQQAZyYc0HsyCQCgyGA71zQEALpDlKja4AsAdqKyS1EsCAAXKsBJfo4GALbobzSVVwQARjWPbDCJAAD2iC9rn9gGAFvgyU04OgQARbbxi9rVAwAJbWqp1t4HAE0v7k9JwwYA1GuLnJgsAABIFZYgCRYBALpNmzYWVggARm+shqvsDACxANeFAMYLAOn8DeE+IQgAbR5J1zf2CgCqz9opaRYFAIn2MWuCkAEAfUppZ1X1BAAi5bH39AUHAJhWvCXhUQMAvnv2GkabBACWOixxFVkHAA0MWO9nmgYA/M9w7zhNBQDifG7QgvEHAA91IY5ySwUAKAEbl5CaBgCjY6nyQBoNAL6mEqzpCwkAxEEyBMxKDADsaAGrZI4EAE9vqLi9ogIAKWktazs0BwCj6YyqBNgBAOlDw8hKfQYAd1d6T7trBQCPI3xiMJICAPvXLBIarQUAZONQbqXeAADXKjHI0VYFAA7oG7FWZwgAPbB7fhRiDADfvz50GWUKALQqaFn8ggcAx8iM46uXCACCOY0M40AHAP2CRn+0wgcAHNzHuJHNBQCD5fmQp38HACTY0cbGRgcApC2lfofJAQCJYaiDe7MCAKUNMUmvMwcA+wQcFoFeAgDovjRK4XcFACvXTb2+zgYAnzJC5MFACwA+qdH/RyMDAOC7LCWJSgEACbCPSzAFBwAKO6dhrGgCABy+vjTyBgIA6OvLpwO0BQA1QZ/wYKEHAHj9lu6nDwYAxm4pTTUdBQDHFjum9csHABQMz7ML9QIAWsbKhbP+AQA1FsrgmBMCAO5Vt7T5qggA8kSutZFrAgDIsXqNgN4GALAwVWdppwYA95hOKPu7CQDzMys4igUFAD6RFhipdQEA6Ipruc32BADSgdrJR3MBACNa2dk+qgUAYWXZx+l3BwCszAbwWI4CAEmsLLu7QQUA7EyZgjLmAwCV6OUUfqAEAJukd8TNWAsAgOQC/ojMCwBq4/S3qiEHAFOZRsmMQAgA+UrYrvcKBQCZ+Q2YyxIEANwp7tiN5wUAXVeM9t9xAQBJ7/bSXQECABPTkcO68AMA5Vv2FQHeBwDJTTYhLCQEAJhgpmRbtwYAhcACATwDAAC9rmsxGpIBAIvB89marQoA6pozOBbsBQA7qFllO3AFABLWBU2f+gsAKwbK3kmwBwD8cLjffi8CACixd9buaQUAr6Ww3DcJAwAb6nicA1gHADonHvSNRQYAg0RENXrjAwCZe9K3/WEGAOQh1h12FwMAiWECMDwyBwBQKbzMPQkGAEsDhGC+7gYAe40K9wHPBgAKZ8ZUGrQIANpVu5lLyAYAR7aYDBjjBgBtcOCFhZoDAP5jJud8FgMAl0Lb7BQ9BgC4cPncIb4EAHqChKAefQUAcbAooee2AgDPXXURdbIFAGUFk8KEhQAAWUFv2nuMBgB72d2Z6WMDALOuS+LcSAAA4wXslVe3AgDJbdrFpL8LAB03nmXIqgkAmm+8efkxCgDEH+41wUMAANXyGZkcoQIAzbpdwkwzBgDaALQX2pUCAKCThrfpjgQAxvMqzEveAQCG66MRxB8GAMAuwZrRPgUA4AS4xtsJAgCSh7Cpv3kAADJC1aKA7QkAeF4qx/4OBwAtgirUUSEEAOgx1rbrtQkABUdZsU/vCQD0DTDaUToAAHIcViu1ZwQAkOUQApLVBACFlniedsoAABdIaH/HOAAA7HsWW+ZeBgCpULgZ2lIAAClkZWWGQAAATJpvWTmrBwC/oKSS7nUFAO7XpApFvAYAqAs7d6b0DABHvA4LGyQGABWTHU+cDQwA9ILj56EACgDPLxiKkIAAAJi6txMpUwAAw4XDeM/cAwCpq17dAoAGAD/NEnFOPQQAxTr56me5BQAxCljKrGADAGLyxtVfxgEAq+zCFX8cBwDkUSal7FAAAOpo5mB2OQwA9PKSVqfCBwDvZmx+nrILAJnavFimKwcAGhP6CRwVBgCcDD9F3hoDAGh4cwfu3wMAEdSn9+wRBgD2ZL1sfmMCAI/FIWzusAQAll3w/Q1cBQBeR8+dVgUEALuYdCdcXAAAicNd2YiFAQDwAKhP8v4BAHNrlzD1rwoAWYTASFrYCADfQjaW65YHACa2xFDuCwYAQINs/gWACgCWMaca+1MGAPoGg+z6BwYAVFI+yF7oBAD9hAWQVp8AAIb8kpLURAUAiIZSNJ+6BwBdLbQPooQCAP5vcNksZQMAs+bdrXv9BgAW8zApRy4HABR2KtM19gsA/QDerOzLCAA1qepBEUEDAJTL80IeHAIABv4A8Of+CQBPCIGXjCAFANIk3KFoZAEAqEDFCni/BwABU9fOfqYBADpzwujSqQUA5ffbA9oFAwDKrreZhiIBAMlrk7IjKgEA6eZqpb2hAgBA4B4FlA8AAECXrwe7kwcA/frU7LbnCQBC+2AVeywIALZfzDRnKQoAP90l/X97DACyMNPDI2sFAKbRYOMIdgMALnLI8+AKAQA3thi22YYAAKu+6Md5fQAAEt0IvJz7AwD/cFPYPVwHAKwZKP4GfwQA7RWSqwbbBQBk6jUKUsMBAEbAayFAbwgAtNkPm1eiCwCL7H5AJhwHAAtPtUraKgcAEm22w1CHCwBKo8u8plMCABpwMwQHJwQADof5WI4LAgDMANthyDcDAO7QdVfQwwEAGuUilEDxBgAlLc6+a4UHABwDL6eAMwEAuvOngBA+BAAEM30sHmIAAPPw27CWFwYA9dYynC88DwC9flPRjqoGAPQ4GMmSTgcAAhDKieXYBQCNg1mCzGAAAPOVW/PTOAAAI6lDwnhgBQCyGySTMt4CADq9l2B9AAAAS6lCCJUdBwAX2MflEWsEAA1Py76LRwUAXRwKSwXDBwDLwYN3PVgBAMconcwERwMAAPKxmOXeAwCebXSYHG4BAN+vlXALBQQAVTzoZICVBADheqJd76IGAJ2dLuCsigIA6PBl6VkkAAAzCRXTZLgHANge6PKlUgIADehmUCaUAAClYY2RD6YAAN4P8/dLRAAABjztqQ3EAQA7hL1wwXkAAFbQ1cBQzQ4AuXnnamC3BQCh3WsivQ8HAPkfOVMeZgUAuBdzDYx2BgD/b/pk5OwGAKBgpLxAzAMADI37CqnjBgAoEqG8GoAFAJ+sNF7A3gYAs8FV8eUlBgCWMnJvL/MEAM7vBQGYrAUANu5eFmF6AQDV3E3hRRQFAEKkviurRwEAJjEl8kDyCQCITjGe3sMIAF6k/KSlHgoA/OSGAJkuCQBRSRQ7SysAAOpqlneJaAUA/Z85bheOAQCLk7ReXOQCACk5HvOGMQEALrvff7OWBAAhPl+dQ8IDAE1qfv5gbgEAHWKbiO/XBADp0wU/LnsHAJGw3RKcYwgAsnrNkAQYDgB7RpeCkfMDAKyBF75oRQcAleBSURl6CADexC6cxakHAC1leZ7w6QcAhi3yIuSjBgCLbIM7jq4CADKtx195OwYAyF+eOAKPBgAGdYe88VkAAOwMQQ6ZBAUA4q7+0NebAADwMtCD/ugDACnR7+iNTAgADSHmBnzGCQBpFH+PN4MBAInSrs5SQwYAWGKaiWAtCgCUonAFuRUDAPElqQjhDAYACclTEvbvBgCwcC0O7wMAAMT6l7ejWwcAltHNcMDbAQBHTFOxj20BACr6g4FJAAUAdd4jxFkvBwB5d7gHTZAAALlA+UhmLQIAhj6HoaWXCQC7VBrE5AcKAM/WSzsLNgUAcq/rrAokBgCckbrd1B8GAJlWtZHp2AcAbMc8RzEbBgDWMeYxlgMHAN3B+0MhPgQAoJWiW5x0BAAGX0v6RnkDAPFRWqvFJAcA89OdeDNWBgBA2zjy2msFAJ87ncFs0wgAYSLXcETsBgCuqRhwPYUGAOvIwk0+qgMA5eEHFaM6CADrMzX147kCAMUGqCfXrQIAoxXOyFVpBQAOKQoHT4wBAEE32IZK0gEAH87U/0h2BACdnoORlQoGAKsXgfPVJAQADsESacQsBAC0rskdJjsEAFETlWyLPQkAKWOPfgHABADE+VOeVT4FAOpuiEYBsgwAPykkXk0rCAC7ebuIGR4DAKu8s0YvuAcAQXuCzqj3AAAwcRcWWOEFAHay9VwFJgMA8o3RKMtVAQCUFqGcDcMAABkxqycOCQIAtkl6TmIIAgDT5ZqAbHoCAEFpPcQKJwQApVlW2UztAgD5KHWzDVwPADOSLP28zAIAwtgDNlAhCgCIsQ0fzesGAHQRfUvrTAcAXE/faGHVBwCK0W8Xeb8AAAr2TxdnywIA0OELOfnNBgA9K36cUY4AAIEIpdLDUwIAPTOOREEbAgAPiXNL37EHAIz1+AcYIgYA5Ys6gZL6AwByVY3DmNoGAI9GVFXZHggALTVdJJiGBgAkorKz4PICAJIcLKJqxQAAeLLxOez9BQAG8cf1CskEAMWPZfLOHwYAehgYKoVdAQB2+5q123ACAKuSzwsS2wcAh0BxXaLnAADw2nPE9GwEAC2BSfGnbgQAJ4QKaSUHDwD6efDpOqcIACrGYUSS3QIAzNhQrloGCQD55cSe7SUFAExoYAbSIgAAaHs5cCuXBwBl+dNYOaAHALVO0byHkwIAVw0g3yVFBACFQ+lM+dcCALfscMEADQYA8NjzAwWLAwDO8WSOGZoGAO3Kxdw0RAkAH3xmn5DHCgB1tR+dgxoGAHa7ygA48gwAfia9lyZbAgC8eBrZ4LICAAzyzBIKmQMAIiYf4cJBAQAgM6X6zt8AADpJkmqeNgcAZGiYE/s/BwCsE/e4KygDAO+X8njtnAQA7x1mJ3BpBgDkVNuDBkIBANBazMFvuwYAnWaR1cgyDQAybKhNea8JANIkbdjp4AgABx0WtIMeAwCX0Z0kHr0AAI9WIBjLCwAA1DCIcbHqAgDml2mB/ZYDAIpQv75jCwYATysGnhLHAAD9EltBJuUBAD2SJ/2gYQQAt6Vw9q2LAQBQ1WLr8VwFAD+M9X3jtQ4ADcaGOfO8CwDm6lyDuE8MAKNxjsHemQgAnyumum+lCQBYPcJlEBABAA+LM5ASqgUAIXQunn4VAwCJ1BcgceoAAIlwRVamaQYA7MmdXFBrBgCHUuOG73QHAF6VwETZ0QQAICvXOUwuBQBYnHk2SDwBAIDQi11q+wQAm1gISeOKDQASr3uXTZUDANxBdFnqEwQAW47ch9wLBQC54bNaRl0CAEco7Cf++AAABk/w2+bWAgB2Mhv8jAMDAHtjOsmAbwYAEeHfboM3BQANLHs1Ar4CAPjUyFju3AYAkmEdWDLXAgD9JUdEVt0BAIfIuggA5gcAUhh8OFw9CgCnM/XxXZ4HAM/wxfH55goALzr2UKSjCwB9EmIz+H8EAPSxgq85jgAAq33yLjKIBACkoaI4N5cBAPcZIpFF5gAAJ0Y52DEvBwDxAKKU0nsAAMZ04gC+ZQYAiza28eg9BACaOjnZyBgDAIXTHaspngYArGvHs4UGAwBZSPI3z2UFAPn+jsIqew0AT1kyHKQJDQAZ/v8qA10EAE7ebJvkLwEA8XwyvGMWAgDd8WlMXooBANWhecbHJAIA6SX5ptxuAAC4d+Zjg4wGAM/75CX6DAYATkAJdsHEAQARijIC/1sAAOQSxQ3doAkAD81fv5QICQA2nD8BSSkFAMc1R7oP9QkAGeDefCd2BQAL4MojcBMCAMYm65k1WgEAPCtRIXJoAADpJAg6y1MCAKSiP8y4gAcAXzBPI7yKAwDeA8G7gKIHAP5daTaomAMAGopSQa/QAwAbJyaHQf8FAC2VthPoRwsAujwcwmRoBwCodM3bSeAJAJt0kw/WtAUADArKuE2dCgCd24kXDAgGADGnHu98vgQAgICddg30AgADpkRMfV8DAJZawj2gBgEA0FMzM68KBQA1uzxhmrUEAHaa4cDfIwIAZMWyKx59BwDLUhClOKsEAInA3V/v0QcA2dq56+q+BwD7rKAL01gIAI+uteqSzQUA0k6waxwECwCT1WhnJSsEAE97QlmE6AIAAQdjdjgrAADl6gXUeEgDAIoI3BrdnAIASOFW2fnyAgD+wWWt5rMGAF2et3IJsAUAr11MI409BQBJQIHWuwQBAFDxf9Zfmg0AKjXQ6pipCwCZr6RfyYMIAG4mAfzb+g4AcbAPovIECgBn7fFoMf0AAD5KeOcNuwEAdwSyeMtLAwCCIS5uoqQAAKeScMWMvgUAebDrMD07BAACGcalrFcDAFUk1sVwtQUAxxgenrIPAwCRJ3yxD1cCAEckuAtVqQYAJSMaCvIRBQDumyPXJJMKAMMWdcM8NAsAF+Ad+cVBCgB1FbYsfzYCAN+HTcCawwYAveXXi5XUBgAyFYpj9GYFADAwpV623AMAqmzeQCkXAAAbRWcuWwQGALP8PkYHbAUAkW7+a4tyAADf/NXtIIQAALsQ9AROwwgAaqDQwO1EAwBtTdiGVOQOAPRjOMsuTgwAtx0yT2VNCABK+mKDqyAHAL/ZzUdDnAIAY4RfrZjnAAD+C8uL8f4EAHbB+z6l2QAA1bW93RbBBQDPq6W7tNEGAHpTpUiK0gQAmQsEW45rBQCRiWHypKcEAEsqN6+RsgsAl0T+KDAOBgAJak/KeyYKAEKyQsLuGQcADj4iFGOpBACVX7FfAhgHAJT+cYNrjQYAfNn3SESAAwCAQnj+ZiQEADHdzcRQGwEA1v+kCEQnAADdNNuugtMHAF04zsnPCgQAHlukmbsoBgC85tzkvPQEAG8LncRuYQIAHOZihF35CQDFWZGbPq0JAPhNoHWkmwcAlRVW7iwEAwCEJSTiWs4HAOPUU7Fe0gIAyamb0POoAwCO6wQNafMAAMBxS9HNPwcAQaybRHlwBgBPSCFGnLcFAI1rFfJpEAYArxA7VybrAADOqclA54kDABWsDlf2eAUANzmcM/JEBgAsbJW3R24GANBVH/4ySAsAYmJdXkJcCgDOudw0rrMEAJ+sFRppfAQADEBdbuAYAwCxPvjZIsQDAKZllDdFFQYAbt7X8aYGBgDnB2HEwPEEANjl+9yxKQIAJxN7CsasAwCEVJEImlMGAAZKuxTU2wQAuNvxSQiTDwDvymakxSkDAJvrT1QkyAYAmwHvIFP2CABz99LDdB8CADq9CI24JAAAUUEFz3jmBgB8dC4nMTYEANFcrEpeHAEAxuD9yrHRBgCQOjBqx2IEAJv/PGlOygMA/YZX1CyVAwAww957vMoEAInSeD+PeAcAEfizCSiUDQCbwvh3MpcFAGf+xTv5EAgAsaxlgUnuBwAuCpwIJJYGAHME58hfBwAAEyMdq4Q+AQA7lfbtC8ECAMghAz+5OQYAw6ERkeMIBQB6L5EOEpACAEOurGT0ywEAV2FX6XNTAQBgW8iT9O0AAABBdoTSxAcA7KwGv/7+BwAAQYJ6+5oDAGX950eOtAkA+R1NxQBMCABoWptZWIEEANnVQbx1/QEAPF2pH/zZAgARug7yJ9oHANQZMC65AwQA+FxGi4EvAgC4Cf8dkEIDAM2Dxl1ZHwMAgtZfdFd6AwAXJqsSu1UDABhzjFrH2gEAYDRC1Xm2CwANQLa3/LgGAJ1fvoM3xwYAKgWOr45RBwD0u5N0zGQGAON0GHaUPQMAE/aWF54XAAB9huI1BYkBAOyCIRO4+QAAMmx/G8RZAACRFFMGh54HAIK1PGRHxwYA5JTUCgziAgB1sbtxOHwEALBmUMhQXQYAfB82U3QWBgASs4uBo2sIACF1qpvyrwYASI3OAuqPAABIT+xxl1MEACjKrYsxuQcAxRbgrxkPBwAjjWCxe+4EAGlkV7iJCwAA0OreaHbdBQBJcKQLbQkEABSRIZdZJwYAruZnitqbAgBd93SagnMEAMkCOa06UwkAeuQRa+DdCQB2C5PRvoQHAGfIuZIKyAkATE7UtGjGBgAYxHlGddoCAFoQvjFMFgMAX++YK6wfAQBWknevGloDADyDxISGBwIADIJ4eiHPAABp59LnJFAGACqo3e+1OwIAxtMyttSfAQCk+FRgGkEHALR1sRg95QIA80ogVHI+CwDExKHV17wLAA5d9irCxwQAw1gkh5rsAQBtyJ25Mp0FAKypIl4HrAYAcTMRIJILAwBuljim2X8CABO4T1c2wQcAm1CiANSkBgAcl1YQeUEAAFwHbobVVQYA+E3m8yswAgDWfFyK2K0DAEYwOVnUmAoAt5A9y/4LAwDW+D3quNkDAHkVUZYOkAMAakAaE6EbBgDy3DW2cFcBAHGV94PNngUAvX8LHEbbAgBfNIGpQjoHAHnIzJ+SSQIAKZCVFvGgAAB6NLHXT5cFAK3tCBzM4AEAEx+t+L1zBgCOvcsQA2IFANaF4nf0tQYAyGwy7JHtDAD8owN1U9YOANSIOXbTJgYAzlg2b4TsBwBD1jRJQ5MBAFGqXkSi1AAA4G/ninDQBwDhx8O2R5gDANnZpKJ2dgMAxy6iHT+PBgBrc6I5gO0GAHU8TOB+YgIA0edHppDqBgC5mTNyr9oGAI+Oray/BAMAB4sQfZECBQAP3aZsF0MIAIMdLI8V1QUAO+tYnkS1CgBHvj3rYnUCAOcLF7TXkQIA4ajfZ8rRBQCimPJhgKgCAH1icZ5OMAEA/pzcatIUAAATb6EbafEHAKxu8CgY5wUA/P/wB+1JAwDdwtfijUYEALsHY/jG2AoAcgmFoWsoDgDTRISw3OkFALJiM1RqqQkARjLmJ2TaDQCeRhmUXjUDADeK6rh7hAEAcZvPiGX+AQAia9vSybEGAEu0/8bnzAYAyiKs3ojGBABSA//DdfcGALsZ5D5gZQUARhzGVkRUBgDyef6rKY8FAPbNDnG/ZAoAaoknhcUIBwCUM8Xm6iwMAGkr6CEbOAQAtIVBcpOvBgBoPueNq88GACG91M7v5gMAvg1QCWYFAADfha0keBsHAEF/SpxidwUAiKjGCUUCAABEZi6xamkCANiAS3+izAAAnhEb8cHHAADsyrBb8gEHABPBvnzZ9gAAo5N8+5fODAAaKBFagzkJAFWR2nqQKAcAVQkFvKUgBwDtbGHk+LAAAHW4D7XE0wEAmAHcc5byAgD6D4PxsPQFAEDc+yvJ4AIANVqAm0MJBwCHgX9VSOwGACw6oRtNigAArvkLijR2AADvRLHLuekAANu+sV3VmwYAvTH3R07hBgCsDidHXqMJAI3feFQibwYA08+RQdRmCwCtIFf7j9QCAHffoSF/ewUARQa6/w5VBQAxqZhAauwFADfzs04QIQIAFIy88kMXBADHc4etsJYHAJtou1zunwIANIcXXGYiAQCTxWtOehYEANuPzvhlJgYAV5jFGhCdCgD7n6W7O9kEABc/N5d4ewkA7LcMNzNLCwAAJ/Z2KJ0DAIdsHc3OAQAAdXZ0ERrwBwCQgaGlDTUCAFIl4reLkwcAzNaBhu6RBQC4eeq0sJ0DAEIIOA8iAgIArOBCunbyAgDm3+LGbxcBAKUOd0mJ4gAAcnsUiJ5VBQAw72NuHl4LAG7/p5oQWwMAkCZP5aP2CQCbYZxb0GwHAJUWkLBUlgYAJ3+3EDelBwB1gdKnHpoHANV3xqTDjwAA6jQH05nBBAAUzJrLIsYGABYCA1UKZgUA+xGfGfFoAACQaxHQ+vIEACW2O7cd2QwAxBKBU4JfDQDdFZgnWtgGAPmczbC3QAcATpTylRlFCwBUTq6UQbIGAJeI7f0KIwIAcVB9YRI0AgCbljUP09UDAO9ySUpIRQQAfH3qn9D8AgAq0p5rEpYCALIFKgFxoQQAI1VNx5LbAQCJQmDKiQsBAFvwRVq+QQkApq7si7OtBQC78kHbRv0LADjOtbuI1A4A0/CeHS19CQCcKBiXSUcBAKvH5GeKpAAA469LVLwPAwCK5V8xAccAAHV7V42HCwIAaj4/BxivAgD+JA1C6joDAJT/9IsAmAIAHpbbcZFTAwBcxjz2FCIHALYpO/S5twUAs6PuMepJCQAIFlgTd74EAJheOWB52AoAU6FVyEryCQCTpgdTQH8DAJy28mzm5QIAU5yuZkLYBQC5U+h96+QFABwXWIz0/QUAqgWVjjIIBgCaxB2EgiECAAcjHYmW7AMAAy7y/2PzAgA5ruI5pwsAACa7iOr1JgQAyHV/55IwAwDnGdhAOaUBABOGgU8uEwkAjFF93pciBwDWkIdc3pgGACXrW1S4aAIA3/6Wi2TSBgB8sB2tiHkEANd65qODMgAAObkMvscdBAAECRBmbLEBAG3GyyBMogAAgYbk7+miBABxYoSWEl4AAFBFLCTIuwcAtzU7EAaaDQAyIPNKfiMHAHpTsxpCJgcAjCU4XfKMBwBaSZwts+4CAFCXL3clngcAI787g0fXBgBJ19UW2M0GAJg2wckAnAMAaJ1IMY5rBgC14hB+hXMFAHIUqhboOwEA+Eut02QZBAD/s3YgtQYAAC0IzrkWfgsAuD6FVy+ICQDEH9CsntIHABXntVlq5woA9qlhlS7eBwAceJWd4c8AADxFHGLMEgMAfAfa5qxFAQC46ZzvK5EAAHa8QzR+1QQAy16ltvTUAADOO3O7sOsHAEkFIAVqugcAaSDi5O32BAACpvEKqbIGAArYslsk8wsA/G7zIPflCABswGDPzLkLACV58yPjhAgAwXaCLIFlBACXHuaa/PQDACQt+usHvAMAoNRctUS3AwDzIVeyUyUHANMSnU6P/QUA2WIQKrK+AwCoyYI7BqcGAO2XwV2jpQAA7z2lBgzIAwAWy7HCMlsAAIKB1XospAwA/p55fmbIBQChUMh0Xi4IAJmGTmHb8AMAMGeFpHEXCwD9qE3SzF4AABh58P27gAUAajyHhjXnBwA++Xff7UwHAHG0N2pVtQMAgtRN4STFAABWxpZ0RYMCAEXNts9rrQAAFCSw6NF1AwAzpyedB/wEAA3FhgxEiwwAhTvKnJI5CQAu30zk8vgIALGmexEyhA4AO64rDBdBAgB/L7+JsDgBADnqNP1boAQA9V6STJEDAgA8TuD/f0kHAJiv7HxWJAEAtHPECoarAQD/p4Z8IsAFAHdEwr8SGwcAdTCoc6UGAABwyGYpYfgDAACNBDb6/AgAgrO7M3FuBgB2VqSoQksGAM+Fmk9u6gwAoHjo7ldvCgDeDSp4yQwCALOqcDBOXQYANndUMY68BwCYLUOxv54AADaXZ3eqBAUAse+HVtUsAwCVYS9ej0QEAEUDRp2RaAUAJxqt4MI0AACj29lDGQQEAMqqbKJDdwEAZMn5VpGMBADQmh6NJ+8HAAG9p47lDAgADIApFJMtCQCWzOtDuu4AAHj4lVPdhAMActI1GjPfAQAO90r97AcCAENolx0KQgEAT1k305l3BgAYYI9URxYAAEXxeFXOfwUAcSoUDCIJAACaNRQj+bQBALFmmKQwMAcAeSYL6StECgDOfZTY03sHACggVcFV+wkAoflWHRn/BQBRCRWJnRAEAMtHLS29JQIA6jvngMB8BQDLH3J1ENcGADLxp3K1OQIAaJAtrDPUBgAzcKQw+SsHAK0OovSsTwYAKkC5ovdlAwDzWKcmxSAAAHbMQvBZ7wkAJd12ScKxAwByYrFcZh0LAFbFcORWhgoAK2Cl4M9SDAC829ie+DQAAPOOjZSPOwcAq8oj08GGBwBRbiap1DsEABNTYcSsKgAA33d4ZKD3AADU8JMPzOEEAJAR7yZH7AcA+BL1i9W9AwC4BLPXt88EABLviZfCmQYAULwh4+o7BgA1u61AwyULAPUr5KHhYgUA0zTEy9SxBQD+dZu4bD0EAFYOkFuNMwMAUxpTfTKNAwCfG9VhXLIBAHWQsyJGSwEAJp8KzBUmAwDftpy5EXcFADg86RScpgUAmcWkgInoBgCShSVxj/kCAO6mVE9ErgoAwcX7ejkVBgD7+PODdw0OALmGxF9nqgoAE3aeLgbYCQBWng+1TKcEAJIBZMLRMQUA0n9snT3AAADBEGYVzXwFAGqAnSSupgMAWnyQqYXaAgCvTOwhN7IGAKI6aKTT0gQA7/0Oh8b5BwAl74rOuJgCAN5lIQrqcgoAbtA+73mBBgAerP7AueIMALpjGwsp7gsAfDqAcWK6BgCyDPfvU3kCAFLFDq4iTwUAJCcuqT2fAgAYvSIMykICAM7VBISKSwMANTNpg7XsBgBNuN+/duwDAE+gVs+VyAIAUk3VSVE1BgDhZdS9Yh0HAPVe97HatQUApbm+DNbiCQBW/l0XwicFAB/1jyuKng0AsWISYjPDAQCA33jTKMwDAKaMlvRBIQcADW3ba2kHBAD7/C+ycdIFAHIxfzFfTQcAgcrZZ1TlBwAN9YYxZaUGAPEt5uyIsQYAcUmENm3GBACdflTEvK4EAP21VHOejQAAaMFtC3VrAgDJrAEeiGIBAKUBHfNtlgcAHZrcnb1zCQDJAW0nGwcAAF4CjpHYsAAA6+Kep+5bBwC4TQmEKckDANujlb+P2AUA33JY/h4PAABqJRgjh9oFAGBZY4HrnAUAZMeTdvOMAQDqGTvRHG4AAFMDW55irwsA5OiIoPEECgAtqO6c/A4JAEqjLzyGiQ0ANtiooabzBwAjbxZvUa0AABrIV231YwIAyjhGOCI0AQBQCq/xHzMBABZuUgMGCAMAC4A9XTlEBgD83r49ILkCAFWjVuaMsQQALBi8ZjQ/AAAT5dLeDw0DAD1HuGgelwwAlfN5l8wsBQDIVYKuBOkLADiT80au7AQAWBw1hFBhDACzMxLyGk0BAAucs4kZ3gEAnm9v3GkmBQDHP4yyNDQEAJnAAkIhqQAALqC5rsAZAACS15VpwKIBAEQcV7HLZAYAsoD6Ngf/BgClXInSoLwDAL8BzJ62jggAjPMtkci0DQAN8sKLf+oFAK+vyhblIAkAJ984QIvqBACkYl08vDEAAB4ITA/+2QcALPJnFNU+BAAJ0R4MzOYBAPHo2u0dYwUAAtLK8QpGBQBdZdCdkbQAAEzBGH1pxAcApKK7kMgxAgDKQgWT4EwCAIUL8/1VoQcA+YfU5cbGCQBZ3EsT4UsKADFvMnBZQAkA8yRzipJJBQAGwQb99ZAAAP1DHgKxqwYAoBHX+rwyAgA3fwQ8waUDAG2gKDxOHQQALhruY6cyBgBNXr3/S/oGAJJHuqY1/QUA6J3pHV61BwDPDexttpEEAKFk2tCOSggAvW4JRfzsDQCxiLST7u0NAI68URrBswUAGHALi2vPBACnMurHPbEFAB4Tc9vCjwEA41ePH2XjBwBlqV8FVlYCAO6FDI0zjwAAvXMamSGoAwBwWI9B5jsAAPCerI7B3QEAwo2ZnuBMBQB4sC6o1DAFAIu/mmxFcwkArA0QFSCJBwDL/pVA4T4DAGQJetaVrQYA+8sAfj7bCAAlSPnhMDYEAAlAa2qV0QQA4LX4Lf4TAgDmkRGk41wAAHcB8VOnXgYAY2MJ4j78BgCsZ225NuwHALFYB2rsEAUACSEC34ftAAAaHpLBTioAAEx5z/FiYQgAuF7+yt0kCwAXMkbg1RgIAI1CkpCL5wcAZ8DetRJtCwCiuCQ7miUGAJwLF/S1iAEA613h3sCBBgBFdPNl5t8EAIAnEcVD0QMAV0UVeZEnBQBNQkEHj58DAD2SV7NuXgQAb3TbXpssBACCuoV4Ue8CAFEvWzD7vwYA3RLXshKxBQDi5E+XdFcDAKPjlnr4SggAn7MLKWh5BQDcrliMTpcHAMaINAh+dQcAi7znKsYBBgB0q+zCcFMEADoUq4+38QIAAeEgCkO4AgDj/ogdnqQBAJZNzke7iwMAN9SEuufwAQCqwl3jQ9wHABiXPidcKggATouy38krCwAZ29X49I0EAI8CbJeHTAUAUC3YgftEAADD2X2IZWYGALKwagp2KQYAbD4kx+aBBAB3/EZw45cAAMxYZwFy7wcA2eMHqcUYBwA7OGuMybkDANzMXiXtBgAAWZoiOGWXBgANw/kjmPcHALqH9WjwHwQAU80bGQrACQAkniCcb7UHAL6qzF8eeAsAbMAxBJtKBgDoE7WjOdIEAGYQG/UjlwIAw9kEz/RCBgB6m6BaCdoEAE14PTfgpAAAGSl9W6HWAwDWpUZQpxoEANrTwh51kQYAxCFnqzg2AgCD4azQp3EAADFE4SBSNQQAgTkoKjbhAABUljXYfHUKAI8NsXrN6QoAdBd2z5vGBwALuofIqi0HAGDaXaz0twAApJgELNq9AwBgARiqZ04HAKduFMe8wwIAXynoBOvXAAD+oG8e6qUEAGBsQ1xjXgQAi9HUqPSOAgDKKjKnqfUGAKtE2aPr1AkA5NzzFQ8QCAAkeDYOcBoGACM9q5IikgUA0+gOaLkqCADFxkEvDAABAHRxc9+fIQAA530Sf3IUAwAeuCN9J+UHAHoULhrilAQAmg3l3YWKBAD0PUk098EBAIlohmTbewQA7I6PBH2aBQBrpL5s17UGACIleB4XQQEAH3zaJm2ABgC5mscbHfMDAGhRn0UgnwgA0j3AabhvAQCU2QzsbFUHAApRtwOa6wUAccuR3dEKBQBHirSAV6oBAHdSaD8zrgAAYgm2M5cZBgARZSZ8FZsGAMrxk/hARwYAhPb7CKQ6AAAN97g4HvgDABHIF181fwsAWoE0U+h6CACO5NLdq+MHAOVFH77qHgYA7c00LT6tCAD+r9l+zA8BAPJv6bCMJAQA4nJRERwxBAAlab8c1MkEAFBPEPwQBQUAnSRuM8UPBADhLfs5ZjgDAHh70XH4uwcABIB+a3lfBwChD79YwScBAHS5Ua7EjwoA09vSv4luCgDOZXagIuEMAMIFNCCxygcAfRadR4LtBACieZguQnwBAMP+yEZZigIAdyuRLrM6BQCl4J+gTbQHAPR+0IfvVAMAddnFYCK1AwDcHxc2aJ0HALvUQPGU2QcAVBhWBMS2AQCSUyAt2QIDAGTx4OS2bwQAt2VSrZc0BQD8hhOg2+sJADtqswwvMAgAbELr9cXtCAA9KKS8osEDAAIvu8cwNAIAwou1G+qjAQBhXN5jVyYHAMrxdjtdDgEAZ47aU9a/AwCKKsg+lYQFAHtwp48oXgUAgR2Tw185BQDLYRPFRlsEANHjf4rdTQ0A0hnGQczOCgCQTaxiZToMANi9p6yl7wwAISHzrsDBDQChf08xvyoAACgVip7RkQMAx1+JE/qiBgCRperdjp0AALfcNvp7FwIAj9t5+rwbAADhZjbrS9gDAAQigR2SDAIAzjI7PYTdAgCr2IeTYa4EAIP7W5hEfgkAIcwmxjJODQAXgfMvQZYIAGkkGtZBsg4AQrrlq4VWBwAuo0RTqvYDALsRD2iDlgYAqiP2gTVMAACly3VYrwEHAPN7sZENoAEAsvJh6zMJBgDSTSrpPxkFAD70UKWV2QMAPYg6uW9VAwAOO2KbUjUBAOuDLuK8FgcAuD64MAE9AwCsr9C6KpUIAIkb0072CQMACllRoC6XDQAY1dGt19sAAB4j4iP4GQEA4n1ebtZRBAA4+HCZwwAFAKNcpoFbmwcAEXiP3CCsBAD6AfWpiZUCAEpratIQ2AQAWbKWDeDtBQDzBVnJ6fcEAOuZUjU9RAgAOO5afX2bCwDrNC+aUZIGAHjPJElA5A4ASRRK7C6UCQAuMIFXvEsHAEzsgbs1MQcAPEhhG2fvBwAp18wURiYHADjmkq2TGQMAkkkjrhlTBAC1T9JHnSECAPZssIhE8AQAEkpynqo6BQCc7xRTpqACACd5HDzNGg4A5XmHt0aLBQDyer6smjYLANN0MHSwCQUAod62OdxVCADCJ/n3f5MHALalxhT6wgAAfNBt271WBQAI0XnBrPYGAMJHhiFuzwQAtluNwnwiAQAjdvW/6Y4HADqJHySyjAIAcmc8HlRbAgCiCnEHoyEBAMmDdMc+cQkAyvrVcgX3BgCB/yJO814KAIcRFE+UTQ0A0s6mlLsnBQCXSgOfXl0DAJu8hZcGJgEA8E+Fx05HBQDKSKMCo5YCAA6kx3b8MwMALkhbmSqZBQDHKgAHx40HAEEX0JRjkwUAF+8aKKT7BAB6CrJpkLgGAGTbx7WM+goAD6gqmOYYDwAaGhr4lZ4LAPpsZPOU5wUAOXaKMD1HCAANInBiQaACACXQaYskXwcAJ2plFrzLAQAoZ+LW/7kFAD6nOhDCOwIABZ5YAyZ5BgBdWZKY20gCAAgtrTylBgAAc7r3UAENAgBD4P079wIBAJocUbXg2gwAVdTg/38lBQCAIevRCEENAPmumw/MlggA6aRdcr32AwDGRVd/q7kAAGMd0vjwygUAK+oIpL7eBwAWbYmT254AAMClXtKXZQMArFhgEHuNBQBp7gvS+M0DAF4BZbdMCgAAyXx8MzJoAwANpp3B7LcHAIj6fKdRSgYAtQ3KcPScCgDYmAhuC7YEAMfm/90EXQUAXL9hxu07CAANaVxpPDcCABjPDVLIwAQAuZR0S6+EAwAlIqKOSqsEAEMXYNdaIwQA9XWJBw3LAABLDFM+MZICAAmlJJG7jQMA8RFaZdBQAwAG3wwrzucAAOZwS9nf/gYA1L9Flz84CgAAw8Qnrr4EAD8/akGkWgcAzq44YSUVDgCjhYzEOmQEAJK4NSeMhwYAd9j0IzWlAwCd7ovtBKUDAEb72KXgZgYADctwSE72AwBXZW2xSBUGAPOWNXdhogcAOl0nX01yBwBNUQ2BvPAHAI0TcnOtnQwAdBDT5d5FBwDi239epbEHAKFuF4+YugUAWuzdB6nTCQBvE/QmpGsAACC3Bgb8ygMA2pw1ovAYBQCn7G/k5foFAO2Oz9v40QAA3IHQPjGTBgBCF5Bmo7AFAH7KpCyHDAQAAZ4AlIDxBgC/MUq0EQAAAFynCmppHwYAykKtVwqLCwDI/Qa3muUJAMy/btQIEwgAUCgtipg9BgAMbMY/bKAHAPtHusG6yQEAjgN1xTU5AgATnMVxvfADADXoFtlIrAMALiO9r1MHAgACYNAeux8HADqvpEeunAMAwtk0C3wzAACKNrJSrT8DAOjPIsTQyAQApXFZJ7RgBwA9rRy8ldoLAHVzW/9R8QgAppDLXDXMAwAWHuTFxkkGAICq5u5nBgYAkOErGJ0XBAB5aX5W2VMGAG0lmkIPbAEAMZE+kEOUBgA23fnGSm8BAFOS4hJJ6gIAXdJoPmS0AgDnuib06jEGAOgNcKO5dQEA+0iqAF98BwAXA8qFd5ELAJiTx7KpWggA92X2x/IxBACf/mbaEAQBAH3WtNyCTQIALXUXDv7mAwCPsMse3toEAJHqsUiWWQUAGXuPhURjAgDAWilKPfQFANSsUlynQgIAEA0igESTBQBTEvkVR7AHAMa65sSAwgYAbnZhs6OtCwBOO1wS5S8EACKsSk3YEQkA3XylzwqNBABDrvasKL0FAH2QVo+rbwEA8tUYErGsBwDbtCMg4B8EAGUvXL83mwUAcearfeQmBwDB9kbnRewCAIZGx1MOWAYAdD9nBKHtBQDTNhMZNGIBAECG8x/WnAkAqBu0xMZgCABuNqcM91wHAB4BbPGoGAEAuQOiB1eiBAD2fyb23pkEADx3CIGFbgcAKcvdxcqTBgD0nwrQEQMAAAVdzf79zQIAau32U4pmBwBWJRQuugMDAAkJwYQFiAMAHSYKACD+BADkSNKWGHIFADva0KGRUA0ACgXBx7/2BAC+qS7NTk4OAG++i/KxfggAAkv8WpM8CACuGxj9F1UGAG2Bdix35QMAiolAlhgZAACZdN6EKu0BAMFjT9fteAUAPQwrScZ2AgAuk79A/JsAAAszH/HoiAUAbsJNaW7RAwCMKJC1KuwDALjRMq4JOgEA5LRauB7oCwAerjykrHoIAHNjUtcFLwYAuq3GZr/hCAC5e9jke9IAADS0XSMnbAUANy2mDm4uBwA56G7QTGcFAPwAoiVc3QIAfogseenVAwBVvKtNchkDAAAIaHh8uQIA3eY03d+vBwCIrjWLVDAHADTj1qFLCQMACzDjpybhBgDF+/yuwIkIAIJlgx+h7goAg4d9J6KFBQDuuKjLo1EFAIbY4itCtgMAvImWQeEwBgBVqacHO2UEANsRtEM0BAMAYonUM4JfAgAx9K8Ej70GABJjmv0H+QQAm9I3x9MPBAD5DpV4YmUHAIrPhuqjcwgALZz7q+LgBgDuM+o4Kg4GABj+8ykkCwsAPmFLSL+LCgDAyB/VWc8DABhH3tagoAcAS7dvPjpcBQDVT4hfE1MDAIQbjAoW9AMAfGwTb1wvAQBM3jei2/4AAESrv868eQcACWlNP6muAwCPGFiznOcBAG6B4PXYUwkA/C7buzOFCAAwlBKWlxQJAEKGFjZuegkAHp3TUqt4DADx4/fuwzYEACYAH8LT/wcAqS0K8nvnAwDecoT8vxgEALOjs1F5XQYAWdFSktOkBgDU7ABZ45AHAIZ3l78lBwMAU6A1FlwKAQASohGkh20BAHAFTtXi1QQAdF8/s9flAgC/fog/3qULALY5Yb0k7wYApqV3tZD5CQAVYgZCWn4FAHc2mESLoQEAj28e3lLmAwDr2C7gK1MGADhfFsiHjwIA1vfoG61OBABm9DFPnXUFAEN59EmBNwAAKU8r4zufBgDWNBX+glgEAORvPJQpmQQAFVtUcnA0DADE59fOayILAN6J7UwTOggAXkDOQ/jcBwDWg3l1XTQBAM3MNEL1IgIAtNuKPUp4AQDMK4zuvm4DAG9ij1v+iAYAwDJHSkjWAACSLVPGSrkHAA+FVIcbdwUAyGEU39mNBABxMueHlnMGAMAaDMidzAUAzdSGFGeDBgBzgV4aX28HAErf+fXT1Q4A5tdojwvaBwCmdVY4FCAAAO8dPbVfFQYAfJKJLqN+AwAuqPVoplkAANzUoasVYQQAdtq1w1MZBwCBetMzImQGAL2xdoBlyQIA/xAw5oGlBQB0NuiH+KUFALlDpqDTKAYA0pMMZNgcCAArD9fKsLcIAL1EgalNhgsAG10trjc+BAARPaFwzwEDAOyRGLqhpgIA4Do/+5HyAgBS6kuBexoCANFEbmWbZgMAM+Gm7QY/BgAPB1gnNDMCAHXAnEXgmAAAG3xsrV7fBABe/dRsHqIGANCymWYSKQkA5z1gohHuCAAgTMf1wgoGAAhoGSoZmwUA6AFwsHFTDABf5kYwChcGADiepEYaQAUAqMRhVd0KAgBGnt7ttKsHAF8ZGp+/hgUAC3n4Xo0IAwDbtPwmIYwDAMPjSeG6hQYAMOmkAda8AABSDnkD++oAAB2udQ9egAgAJwqGWcxkDADuC7C35UgKAHSP73WW2QUANVRMNONKBAAvBEg3wVUFAMAyQnVB0AQAB2mGMLQhBQA5nPtAjjADACygdcasCQMA7kOlu7mJAgCeUyguWasDADrYzauCTQYAJ+NywY7HAwBG+bchUi0GACl69zom1AUAsK6JIt0/CgDruX73ZNwHACxAOIPSGwgAITk4pSlPCQBtk9AYnCkEAEmKQYNBkQUA1a4hxxgqBQBtl4K6UbECAFTHS97vwAUA9deyJdx+AQDuGwimNnMDAMPlh4gxtQcA4VsaSW2fBADgvsdlI+cFAD6zCC8GOQsAsc9X5vO7BABnWW7193oOAI7Wnn/W2wwAM7dcVSALBwB/IXFFB/wDAOtqK5vSoAMAneXdzHhkAAD63RsFTV4FAE57xAQRfwcATCwRVcUTAQDKt/kDUVMHAAghmh3tQAEAr8I7MyIlAABkoPSYQ+MAACgZSz4JCwMAEgPIfn7OCQCDj/e9deUMADjtCxl6Hw4AeKNs7a34BgDovc4+2SIFAM/24EXwJAAAoc8mNLZtAQDYD9MfOrkBAGKjaFNA5QUAmrK3/T0SAABoPFJWQzQEAF/uIXlSmgcAfoE+y/xLBwA9jexy3oAHAHIn9ADz6gcA40w1iFFFDQCryz1KytwEAMvrv9AU0wsAVyvTavzeAQC855oIRYUCAFzBoOmP4wEAezfi4EYgAQCFqApWHHIGACgZZ78o6wAAp5VR7xq+AwDrtb1iL/IGAEkwUrholwMAvf37yJQzBADSjb8B0mcEAJbnela99AYAg7cXk8haBgAyif0gO30IABVpMgjyAAgAg6NbWpzvCgCtT+90mpEGAL9SFGHUngUA7wnqBOyRBgCE6QAny8sDADy69cRDHAcAzXSe+vZtBQDfVs/klZwHAOIJxjtkvgcAeOjZKsFJAQBfDDnKWKcFAIHcYR2LkQgAm9EMJlDTCADYtDdOq6IHANcUVHPqHwIAnWN/AjinCACVJEbZECcHAFZ0AKqvWgIAG6PqKB/SAgDQXwDqcXYBALc+SySu2wIAzOH/Vy9KBwABcwhzMLwBADScAfRX7AcAJKUfLghOAwBqEjWmjGkCAA7ZPV4vcAUAx8VwSpocAwAk/HiqpTYJAAB7nzsvmQkAoq/EsATAAwB4urAyiDEFAOx88Z9L8gYAx2DgMH+kAADQyA1UhIMFAK6cxNxD+wEAK7j0BqxGAQBVc57YALUEABKKchweNQMA4y+TaZ8LAQD90RzQP7QGAPMOdj5YQg8AtxYyV8E9BwBKcdf9SK4EAAPhE4pf+AQADf/WsiA0BwBExZdGS10HAPT49//hGwEA4fdXaOEZAQDV9Vw0FIoDAC+1BXGNpgUABh6Fnsv2BADllRhHxHgCAORkPc7N7wcATEtcRW1PBgBLo/4yVtsDAMIlmIKxkAkAyCUyUdPnCACtq7fjK8EJAKWcHnh3hwUA8l1J6peRDQDY2V33K+4GAI2+NOssxwYAx140zMl5BgCkmGj5jYkHAHWd9K0hQwAArlrl5BlgAQCcIF3yxU8HAA3tnZNqVgQAt+AW52NgBgBwTR/cr14EANqxzM8kRgYAwbZygKtXCgAJb2clBxIIAO2OTtAYoAwAbNWl7jz3CwAr10WAhQEEADAtyuDlWQQA6oswGbeIBAC1MhsNSm8FAC02gLzupQUAxo1OCtG/BwD0Nmc2mcgHAAFc+eq7XgUAij+QYLBtBAAhZhKJWGACAC/ldsY8jgkAj6mV2XlgCgCxCHkhfEoIAFll5gN23AEARCQLod/eCAAE/2CDpgQHAD6L3jzMzgMA/2QPR9UcAgCJOZWNwasGABXm5MLQSgUAKlIruNVnAwDHfT249NMAAI3F20x/BgMAN3lp2lIEAgCpd6oryy4GAHQotq82KAcAQLKUIDyvAAB6NX8phcIIAOLWgFYtzAcAY1YH1RMZBgA9KxVhUnkFAL08+rrboQcA1YglxTGtBQBcaGRBOl8EAG2WmpGf5QIA2jEyGjYtBgC4AU4AhFIGAGAd6TtTVgYAn6gAbAGuBgAFHBMqvN0DABS7lieiVwoAdD5E+2DzBgDq6iBy5IAGABgM8aXy/AoAH4ONs3/uBQBLxV7O+Q8EAFuzYeKFcQUAqXAOVFTiAwD44wNAgbUBAEvASjFoiQcAjmpEQcv9BQBxKv8maSgFAPazluIx8gAAk0bIV6OEBgCgvMkzBh0GAN9z/Pi8KAsAs5X/Bt60CwCkEbonpAoLAJtt2r8x7gUAZ4DfwjqyBQBmJdv/NUkEAG5sF20BLwEArvUWD7D7BAAqQJmNt/oDAO16hP1l6QYAe1KA7lO5AgBas7HNW18FAGY8oj8LOgQACoKLOAduBwBd2Z27m5sHAGFzn46ufQkAMtoCYfcZBwCLyoAqfBENADUJXbZmGgwAyqxgFIG6CQDCJjFqQFUDAHZ9chgZDQUADo5JC+rlBgDyFDIGtqMAANKfjBVfBgUAVJlCDPtpAQAQ7uzZ7ZoFAAIYhesWmQMAOMVcVRd5BQBPiuU5H5gDAMtv5m2l3wUACFkHCYgFCACTSoXL2NMGAOOxcOn0sgUAwcvtUkQPCwCTCiNZdYoDAB+ji94cLAUAPVp01PKkAgCKotRCnX4AAM1acIPAjQMAQJd1xYInBQCtkNmXMz8FABVN6Mc5qQMA4Dl+IsQ0AgDyk6Wh2TIGAJSEDO0R/QkA4Fcn7bMhCADFwY/lHT4HAKsWRsgQ0QUAZK8o36elCwCmywe4FWsDANf+Gp6K9wMAH49gLJylAAC3gcuO3SsFANR+hEhPsgAAx+obUb7UAgCbW57ZpL0GAAFOkZZpfgEAgM9/zvCxBwCBVEd0z08DAIWqz3irHQMAt1RebiHjBACJtnM5gkkKAISI5IRJWAoANvtCMJoRCADKZ5d4TOAHADK4zygbZwEAN8Xhon7lBwBBQUTvqvsBAKbfZMG90wMAfRfC6JzYAgD0LBi6Es0GAJd2msGKCgIA2XLMsvo5BQAg3h6PCGwFAO+O8ySsXwsAAquXYVzXBwCnL6TCSz4LAESBtBDNxwkAjzVI6rc4CAAXbqgQET0FAG1GX7ZuQQYAIM5fI6YcBAASu5mK/MMFAAiRucZ0lgAA+G8xmSH4BgDp86nxVF0AAEonvdDFvAMArdXSuISyBQCeliUQ4+UGAA9iBmMO+wQAYOZHl/UwCQAZ1OyPhkEIAMU7koxeEAMAOBg91IoFCwD7k+WH9WIEAC02zqdL2QMAt2cmtfkwAwAK8OBIWtQFAI2aeBRRjwAA0GN25f0PBABHBsLURRQHAHwPF2g+ZQIA1l7F495MBgA9/k76SWUCAG5mP69JhQYAaLvUQSmeAAA8/10fMegCANL7H/meQg4A4iwT/g2hAwDW+WseRloFAIMusPTujgcAzxaMZE/TAQAyUboq6n8AAB5Axh1ukgEAoM4X6opOBwAPvD/4Q8cAAFVUv8QDywcAmH6RqYuKBgDlYdgBHfoBAKuU39EArAwAGie9ASG6AwCvxLmIiVcPAH2f9Im/8ggAn+mO0c4/BwAymFl9lFUAAJAZpCr+RgMAWxl5gEwWAAAnunv7zJkHAFynxjtWcwcAs5wTYwjpAQDWoNkHtPgEAGlPksokjgUAVmTnu0aiBwBkuAG3JvQBAD8loZHINQYAL96O0+tqAgAFrt36yG0GAIY3oEF9HAoAffqzsWu3CAABHJFBTCYBAPm9hEX0AgcA3o7GH1E8BAD5Ne06LEgAABvTcVKv4QQAm5OSf/nBAAAXwW2ViHoBAMed+V4A7gYAzDGycpGqBAAqd+th3bYHAMfSAav5qwgA5QpjhwKIAwDb7VsEyi4LAM8yXzZDfw0A9b9Ztqk/BQCSPfNQ6MEFAPX2uZoR7AEA6WPmbW/xBwDG3hbL1qcHANLx6rzpAwcAVVSIlOnIBACCrZzatcwEAHXpEMZrWQMAXp/bDQyoBwBhTFw+2ZgDAPLj59JgfAcAcDh2URAGBACq0uzgxHsGALlzEx+UuwIAMCwAycmZBgDzSOIzZ9EDAInjS+G34gAASnj22g0sBABQeMYf6okFAJHx3bUJOwUAzPFGWSOnBgBgvi+7nLkGAGJcSNal0wYAwCPpZpSDBADd/MYwrxwFALRUrBia+QoAbu5hlqOYCwDizUAeM4QDAKYZ3sQVzQQAjp8YnOIqCQAK4HR2QqcDAMF0fk8vFAYAFTqMMZPMBADnHiusG9UGAD84kqJKUAUAzwENH8vABgAz1fWeRocBAL9HN4g4cQIA6JA65Sr1AgC6jpX+FP0FAI7Lk79e/goAh+fLitomAgChfvuigwgBAETPQnhwlAgAXHJg+XPdBwAsq0Uo3y0EALt2Mv1PIQYARlIaGI0LAAAg63nVpmgCAEeG5Sb/kwAAKZgFaP4kBQAhtnzkdVsGABnM1aWwXgEAWp2SswlSAABHa8jLm/UCAO7CkbZg1QkAB87j/Lr1BwBsgBQWVs0MAIexcGGLWAwAgRDQ41WqCgBfExeZQn0EAHDweqDP6gMARG60RqveAQDfbKQ7P6UHABrl4kKLRQUAT0QHDOaSAQCqHaJDiK4FADgVC5Eh1wYAfkGmlRoyAwBop6gEkD4BAGyHOxnJAAYAZXcNihscCgChjrN/knkLABrg23l2DQcA6Y2JQGD0DQDbzi+DRYgFAHNuDH/NNQEAW+Po3/s/BQBb5QZeGS8CAM5Lgeg3OQcAjfR7KRZxAwAglwYNnloEAOxEpxr3WgIAo6uKy/AaBABeHYlOis8CAKJr0Bd+SAUAlmUtAyqHCwDfSJPAKF4GAMJAzrJrewoAaR2J8vemBwBnDxEHh/0DALItqRaHbwIAJzB1G6rNAQBhJrVYvgQFAFKC5dabBAIASe+aao39AQChbyG3Z8sHAIK5w1P/egYAKJbaEKYOAgBZVPytGgEGAH34ywLI0AYAe0xV7b9BCQBiQu9nttsGANx+hSYxjwUAQJN3i+GcDgA8+JXPbZIHAOwrDhIlLgQAFfrxbek9BgDM+fNQa/AEAC+2sMFc/AYAy3mYsihVBwA9WhLSj5oHALhqdEuNfAIADCECP4n4AAAQV66zllUBAMokUX4WMQcAP+G76Dh7CQBVkC+UW9ULAD6RvpUUnAgAbPsaJE6qAwCieZE/0jkHAMToudv6MgYASAz+K1LIBwCpWu+DCe0GAPS1h3Yj0gAA9QUzKr84AQCYZdgkXfQBAP5gIa1LJwUAKtFYHQS2AQB6aOSmyi8DAN/MhydzpAcAQAZ/fEIeCQBjjF84WTYIAPprdtnq9AUAACZsM/ZGBwD1mn3FjW4FAHhPvhe+swUASy/4jJK/AwARbwpgVS4FANbr75x+YgQAHJdsq0XzAgDp52NuKFMGAK0jirdhEAUAAUW1rJlJAQBm7QdwkbQHAMqiU90oGwwAheqHX+h7AwBBXqjS40sHAKZsyfqHvgkAzAj+IDbQCQBksISrXPsFALCFgnc+UQIAQ+AlMThXBAA9Im61o70GAE+Ebze6IgEAVOW0os0yAgBA+A+jK0IAAPVDe2bnUQcAPl/aVRcmBgCOtlK/cCwAAOFyjUW/Mg0Am7WW55YPDACinW+d9y4CAHfKvmerAQUAQ+s/fmmwBgC7LwtdS+wHAFBUWRDpAAIAXnEFcQVCBwBgD1MicPACAO8JpPA0YwIAwKNi30rwAADZtou07eAFAAPA+6RKwwcAJKxcTk7XBwCyQTT0N8wBAKauzsnxVgYA7FqtrBwDBwBXbHHQjDABAEIZlHMTHAwAlfFy90ajCwBPMsdcWlYHABFKJNWgHAAAE4dBZ7AWAQCu7VWMfaUAAAM4EJyAxgYAyGra4hJRBQBauj0KPTYGAAz0povJGQMAx26jA0voAgB87/a5EVkAANzqLlHzrAkAaCppOZhjCgAGBYM0omkGANQDBgySiwYAsmQcne9VDQC7Dt/1g5kDACaYlYkl6gEA1s0Dh2POBgAFhYl4FjEGAHCims/OswYACL1zO7pwBwDUhuH3dRQBALwrickbJQAAWsz/m6tOAgAXOBPe9HUGAAqz2jvZ9gcAJdS/pazzAQBglxwcUvoCAM35J86AIQYA0yyIC0UPDgD8ghdrA1IEAMWBdrCVLQAAsgWS+RyQBQC07F5uaJACAEwWcN+ZPQEAysDlIcNeAwApQPQ34zoBAKctP4GOAAQAOgyOLydABgDaXuXpbcABAKppbf9AKwUA+n83CYgbCwArTNFcYjYFANEXLiWvFgUAK9Pn+JaABwDixD6j1noHACHTEdzFFwcA5COYVRShBACx4qFQzgYDANvC/qE4zwQA51z6DWWqAgAVlPGoFkkFAHgS52/JDQAAuD7mhCdfBQCRYKLTynMDAJq73Yn7qAYAN37Z1TWMBwCyLO90Nm4GAI/dU6xHQwMAKhGl7UcVCgB89cmCTWMEAFLWpmiSJAQA9y9/aG0zBgCg2SZOT/4EAEFUlD0PBAAA04ZZ/TnpBQDfmwFHISoBALKc0OdmxAQA3QPSlVv6BgBUojSjUDUGADZ7VHJFWAIAdxMcgVhcBwAbF8w3xtMMAOI0fXQwPQMA16f6upKaCwA3z2m17dYHAKAs3KWUAQYAphBedFmvBQB1SAA+9agHAHivfSym7gMATieT5hPHBACks256G+0GABWOfWnOKgYAdbAqKbhmAgCcXGagNoQGAGkQIOgX0wYAyqMsXYGQCACgmRTr8T8IABjjUPBgOQoAEBbJaTY3DQAnPy8g6DUCAIAXti6fTAQAA3AdW5AwBgDR6nTSyPwEAHiraH9uewEAV1IOmqsUAACli39WOZkAAII8Qip7tAQALcR65deIBgCHj2daS8sBANQHoKJiqgwAbS32OA4eBgCCR8yPiC8IAP8b8oMrVgcA9i7Y0g/cCgBs/Eo5a8AEAMw29ksbkwQAeCMy0GArBwAli4HGJ1ECAEPnjae8MAMATnQZEYT/BgAFk+ToYMUCAHql5e9PJQcA36dgxeJ6BgDxabPhG8MDAHJCy/mTvAgALBhz2/n4AwDE4brqNbIKABlVKYe/3QIA1eeXEOwcBADuipQITYYEAB72jUM30gUAZ3AfYIWyAgBT1+a6vF0CAC0mNBG2MAMAioBtotcZBgDyvq3Cs8MDAFJ/7J58hwYAbbbh67m+AwCH8pHNRGsCAIMDc2KT8gcANpxFUXn9BwDnSS1RTFAHAF/FO37thwgAJcdJAbHeBwB1dDiPR0gAAD6KZ9mXkwYA83bJVoF8BgBsIolVTesCAArBweYJxwIAeu5mh2qvAgBs2aF5qooAALAvm9WSLwQAB5wAQCx1AQDOYv/paI4AAPnyuArVCQ0A5OV7JKu4CQCF5LLmstkNADgTmkel+gwAcI9zvRPLBACtMMFLClAFAJWGk3qhJwEAbeM0+iYqAAAozB4u0YQFAKPrfvjz8QIASrYV5XWMBADwHgdSaVsHAAZUlkJt1AUAn5+YBmF0BwDiCjw1HpoBAL29ltXNcgkAgxaI3x1zCAAUgU/WJgQJANmjqdhPGgcAaiaQOb02BwDDBfq6YHUEAKMvzKvcGAQAgobPzpFZAwBgjEupcUMCAMMgHLFGFQQAtLM0k1AtAwCqcK4sEGwBAEX0G9UNcgEAIZivL2auBQD6hytaKRIEALPqk+JhUg0Ay2WbdSZkCABHahGuZQIEALzlugQjwAYArZXRuAt2CADp1n71iJsBADmjBBm/zQQALE9OzUkrBADZCRl3LhoHANJSuz4VTgEAioHmzRcaBgAniBA0rT0FALZVXMUyKwMAo0eTXxb5AgCsM7zpS7MGAMDycWVlaQwAPkJvzmGqCACgJxvXQPkLAGnRc53xhQkA3OZie5wbCACywHg6ZC8HAHueT8BF3gMAXPowjdYGBwAkL44+9pYGAC2S8BgsAQIAKZ3IWuVVAwABcewUtOgDAJAMUnywnQMA4e93mx70BgC65IS39YoAAEsszInSFAsATbzx4lA0CgDzki85k80IAHxrlGoMNwkAl/1aHTxCBgAzJR+I3JkEAAbFdmTyTgMAlxR00gfRBACz/W69xEYDAKFjEdd5KwMAarP87dn4BQCQOb/c6OYBAArzijRPlwcAfJzxTnLmBgDiE7zvpYAEAAwizkLkTAkAyxYlp4CJCQB2ZrgN+HIIAG1S2h8zAwcAyJF21DFLCgBxIGIBC+cBAGqh+LVj8QEAF9QaNK9qBQD3MNg1lpgHAHvLAHaiegQAw/gVwO0eBABKhe8njc8HAPmTRljjiQIApwmzV3hKAADaTdGFtUUFAOEhs+PQ5AQAQKzS4x9FBwCNqe549mYGAK3+Z4aFOAgAjEzmwy3SBAAPOtSgXicHAPfM130TgQYAOJq3upznAQBqpolEISoCAKUrM5wv9gAAOV871ollBACWP+x5+eoHAKi5chXo6wQASmlhXX8bAgBxY6MB+sABAD1qk4wOKwgAIM22WDu4BgCAJufT2H4DAGIqn9s3oAgAu9KxGVQADAD/PZQitgQGAFgadPaZyAEA+zLy4hkCBgDL+aeSrl8DAMqx8xQ2+gAA8IK+ub3+AwAAFJKVSOcFAAYngjjqUwUAjMjPJHyhBQAK9K4YovsBAJQBez4EVwYA5+nvVRvBBQD7dKDGe3MHAMxV4xzk6ggAdfc/0TXFBgA+9cj6SJQEAGo16MZ0TwMAotsHBnitAAC2PrZ+OiEHAIaMqqzjkgMArzWKPuk0BQCXyQL9EIsAAAUeuKzCagIAeTvOmIydAACsUE3+F14CAKch8Xb1fwcAK3L8sPnlDADHKA2blG8EACbvF13mzQwAl5b4KKi7BgB29gQe15sAAEWh8kHIWgIAcTiCrH6kAQAaWGzDqKgBAPupQhR1VQIAATn+kGa8AQBavFovExQDACjVMlGDEQYAV4q0jkvyBQC39vcE1VkFAP1m0vbnkQgAiHMD72BgAwCGEh3siIcJAK+ORxxEhwIAvVQzauojAQDVVOuzeIMDAO6Uj6eq1AQATad16AKgBAB8sWcThQsBAOMHWC2xGgAAli3jQZAYBQAxAgkrBlsAAI+352YXyQAA7DihVQ+qAACKkSwelqMEAB4/I/NE1gcAZMACnp/GCQCXaCbl5WoDAHmL09rBjwgAQL3Z6s6KBgCgu+b44DsEADtOYfzfjwYA4Dtbqx3pBADwLyHJ1LEDANuxP85rzQIAEMLX8w7JBAAWh4Gg9ZYEALg5woz4nAcA2/hsMJzLAgCPUFsNdpUFAJAnAv3rywIABRHsKoK4CADLvCbSz9EMAL1xSfqyFQUAFUX1XSzLAgCXY6oE4b8BACVsmf+UFAEAAFg+YlFCBgC+RODFn9QAACnL7UP6CQcAyir9Y4xdAgBh/d8pzcUEAAWvSOvALgMAfLf5kZOPAQCBDM+eAg8HALmwEF6qrwoATCVVg+AdBgCNwuN9WOsIANS7fZ+78AQAvXQqWspOBAAzPu0uswcDAMLoPLCKdAYAvBC4mg18BQCM6SSiZCwEABTDptjVtwAAQ9WVezJIBAC6pOOBZhQAAAxOw60UhwMAMI4pDm/yBADexxJFInICAPx1qUKKuwsA7hdrtNXyBgDlcDEiqbYHAOa34z9xUwgAwWt//TWXAQAuNMVJr5IEAFcDWt9cNgIAYLv/pzghAwD+RkbR96ECAMxEivFdGwEAZkLIQtCQAwB13I8q4+8BADgSrudekgYAMujQgZKvBAD4HRkR+f4AAEtleXBhaXJQdWJsaWNLZXlTZWNyZXRLZXlBcnJheUxlbmd0aEVycm9ybmFtZV9hACwAAAAEAAAABAAAAC0AAABsZW5ndGhfYS4AAAAEAAAABAAAAC8AAABuYW1lX2JsZW5ndGhfYm5hbWVfY2xlbmd0aF9jVmVyaWZ5RXJyb3JCeXRlc0xlbmd0aEVycm9ybmFtZWxlbmd0aFNjYWxhckZvcm1hdEVycm9yUG9pbnREZWNvbXByZXNzaW9uRXJyb3JTaWduYXR1cmVFcnJvcgAwAAAABAAAAAQAAAAxAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYA13E8k/znDABDsrb+Qc8CAHYafQocWAcA8DJNUy0XBwDSh/pjwJAFAKjVtEJgpQEAU9GeFcyJAQAErjyq3rgFANi1EU/wqgIAkpxmWlm7BgBfepuls6gCAH8I71mzqwMArwXbxKj1BAAFQtAHqLkFAFDqE1uvAQcAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAnwn8jrlRAwAOBaekv48GABuXnZVJKgQA/Z5GGuWTAwBYHjIQ6YAGAL8YaAUKBQYAvzJVH8wqBgAl+snMQYECAIPmcfRhTQIAWkTH9DN5AgAJ/3bE6fsDAEJLLphrrwAA5Xi6URKtAACIfO7trhUHAFM19svQ+QcAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAMXEVd+vuBABBB/EVGSABAFacbNqcZgkAbDTbMsBeBADDLGq7Vx4FAKSMfXu2BgAAMynnRPqEAACKb13lThUBAJBzLoRdQgQAF+QaxGSLAwBxS+oCZzIEALUwYDc0aAAAgMP5EgXvAACEJVHyqfEAANbwqZGOCwEAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAfD7dBGZZDwA1iwUOUfwOAAzMso0MZwMALzPOmdiXAgDOGwZ2XpEIANk0kvPtXQcAVDwfqzYcAADa9Vjuj/AAADfWoBOW4QAA4CATSgKpAwAakaLJ2fUBAPj8+pR5EQcAxY3iyqjYAgCHDAmysUoHAMTswsUHaQIAHZwvYw7dBADZpSIm0c4KANlCR2HpjQkA07Xbb6mcBwDuAJrUN90GAF5RqklUYwMAq11H0HjhAwASl6ESRwsFAK30D4bC3AIAMT3w1nYNAwDH5AYhF0QEAIgt7a9REgAAWk/tm/w0BQA0Us85WtgFAGToEnFpDAEA8sdYg6AqBgCU4UgIRG8EACv1qHG3RwQAHdNpMrp3AwCAUPW6+TsIAN5fvn0nxAMAkkzUrzWjBQA+dZlAFsEAACPkbwCHBAcAb9a+ymFeAgAEZljMKOEDAOLHjy6LlgUAz2G91aNJAADm9h5bUBYBAG5YNIbXZgUAvS9axoVCDQAfdPjMYl4FAESQsWG5awwAOCBxBTQVCQA6eTRfuk8JADQIwZyfpAcAxiKKeBO1AgBbOfJuS/8FAL8H9lqO7AIAw+ylvHU5AwDU94VpFkYHAJrnCgA5mQAAevlkeUyEBQA9W/nhFzYBAMU/qM4pSAEApexxTi8LBwA8ZPyOFCgHAHZbmQM+dQgAZmersl+/DQDWNUW8w18IAMKV3ZeEewMA6P+01kkVBgA40bEtohcCAJ6wLgbPuQAAWPflcZz9AgDd3q9SrrMAAJfkGWannQEAjlXSVAb6BgDUQV7SGYIHAFHGdXR2cwMAkGUkFMuVCABnrKYq2AIIAFBIvIPxQgwAQwYKHE9GBgAHCXMFWb8GANmt0UD9mQIA9+UEmt7yBQBZHMy67sAHAAop+LGhzAQAj7HDVur7AQCKW0Hh8XgHAPTB73RY9wYAfwIZQGmKAgBN3GupNysFADWmZ88hJQAA0V4vdyBnBAAi1lnzwDIGAFLioysJsgIAgCYRfCViDgDVfJ89dQEIAJRSnQoL7gcAJ8pM6/uBAwCdYz46H4QHAF9EwzDqdgYAghPnpwD6AwA02z2WLSMBAI0HC+eSVgMAH3p3FMpHAgDQ/OhrVdsGAI4E+uJfKwEAkh5vrSZ8CwDkeyJxCWoEAEybLQ0vcgQAOuBOIEbcAwBseSA86fcGAE3j/JbE+wAAPq59a751BQAJ5s6FFaMEAP8wOQLpNwAAEvuWb7dJBwAFrqauBPYCAOsjk5PcNwYAR40Em639AwD3WgTUsKgAAAIe8BDs/AAARU4kxJ3SAgC+R8Ebe5IGADkIrDSFMAgAQD8DZDaFBACr/maRdxMEAEQe/kmmWAUAiczvrjVGBAC68odIQ/8BAEQtDiKB+QAAUTwYpxqQBADw+BqMVLcBABaBNlOMhAcA6T0452QbAACPfFiw+wkBANEmt4e4GwQAm5FmfFlMCwDDD5m2UKEHAHQikp3rKwUAGoZkce0OBwCpxnDgcagIAL5GQ3REfQAAHahkpbaCAgBrI3X4gO0EAFAMRR2++wYA2/wSjHLrBACJibxLmbUBAGAGTKh7SwcAuK7N8XhWBwAM8dawBjICAF1o8gBz7gMAGHUehEd5CgB+6NqIcywLAOgbl9OtFAQA8Q4vg1AYCACI+yxqfNQHALfWfZ7kVQIAup7VYyGMAwBFWAAqH4YDAMmuy0we4QIAEnkpdhU4AQDg1vCOFNACAPuH540qUgMA0vl0XgXuAgATCDH2OEAGAJ5M01jPSAEAWnXkmn0vBwBK/A9pHnEPABUNWzWigg0As7aF6M/cCADp6tS6/ngKACfwNHn2kgQA1ChVgdDeBwASZhpRYYQFAEQV3lAu6gUA29XroS//AwBmOZOMH2gCADUWkyEFhAMAUoYwSvF0BgCQSKmInL0DAMbpL9BNEAQApWoJ2wZOCQAjsOaJnCEJANqihtSreAoAH5VgkrJACgDJ70haWxYIACpCJBFevwIAVq5WZxRzBgAw6Iea2UoBAP2AsGXK6gEA9foKsGPIAgB2aoSgdKQAADIemO+lmQAA5r9LPK6oAgAsgxSvNFwEAOz/m322kQUAXbUYn3GzCQA204OMMVQHAJeXkbcXfAoAYJsIhLBFCQAAA2f4tIkEAPqbtIAcDQcAJUaRfX7VAwBF5WUhcsADAE/gGTi55QUA96h87ALeAwDvkus6LRACAEY6DNUijAYATomFk6guBACM81W/nl8HAMuWpLtfnwQAG1ecHoxiBQCrIugIsZgFABo2Ka6PXQUAKHup0citCAB0hihsGmoIANTPW4oQmgQAEmZ9jowXBgB1A3FzNPABAJhgSmFJOgcApr/chkpgBQC2ZBd81NEAAFEuajEIHAAARVDJRduzAgAMMI2BT2MBAHTin+iJCQIAG+zqhYsnDADN4ntlWe8IAG+HWGnRLw8ALwsmBbLpCgBYcA+VuTAPAH/MLTr9dwcAMkkS+6mUBQDwFcqAjh8AAGky7DzRFAcAZ8rQ0T5AAABSxU6HNS0DACm58Y0E8wEAI5sXO9cAAwALfaPle+YGAAODMFR0vQUAKnnnFSGTDAC3MLm7uVcEACYyGYtdjwYAVtQej04WBAB/BiOxfbsFAMJMsiiV0QIA8y8wuGasBABRrf3ZyAEHACc3W1yzwQYACjgHgKczAQC+YsrGZ/QBACzBXSojxAIAh7ATwB1VBwDNO7ARDGkAAA6P1abcQAcAPEN4BFeMAgBjpHMoUNgBAJzU3n4eZAcAcfVM1e3sAQCwwlZSP8ACAE7Oz1IH7gAA6fsWgd1gBgDr/w8TZ1EFAFyVhbiCxgEA6mOpX9JhAQB9pFN7dRgHACEvD4vhGQYABOzB5N/7BQCSux7ImNcFAGvZ24tGmQYANRmpauY9DQAam1ka+EUIAJJBIb2o9wsAGTMSpE0dBwCixObE4ZMKAM/+2vRGLwcAo/fe+o+UAgAEvPP9zR4BACXt/o/pwgMABTlHmiElBQDhElGSSxMGAO0GtCuUuwYA4t3ARcRwAACj18Qi2BEEADLwR8QFtgUAOfDn8Mb+CQB8RyxpvM4DAF6pGWqYdwgADot3oarqBgCrxUzvL/EKAIl8xCBZgAUALJf5cUeSAQBAwJ/fvYsDAIGykgAA9wEA64rq3HZKAgBAx8DfsiIFAEjhgDQZ6AcAuUFDoNk/AwC8IIpnY8gDAEOKUbIH5gUAAc+WpRxDDAAEFIB82hUIALQQj2+bPAgAFkCTImk0CABW5Dkx8wEKABgY32yPHQMAFksUS2z4AQCdPte4dZgDALOn/9nw+wIA3cy2ynoGBQBRnQMIa38CAKrfAIAvgAQAJcVioJKWAAAXWAeR6roBAGAkhqjLlwMA53kTyPvDBQACL14lvBsEAFCGmVb3ow4AQXzg1H8pCQAbHiwCtHEHALJZWfCTMAEAGMYuLzW9AQCG6oibeHUAALlI6hcRHQYA5mYHMp0zAgCnLzpRhtkFAA8b4Zk6PwYAbbLWzw6KAgCPjeE1aDsFAHGZIYmhMQMAnHJ1nTovCQDJxFPpAA0JAIkvbxHfAwYAiODgdsI9AwCaZP8ZlqwJAMaAT/tFbwYAov657jjMAwAf23ByZAcBAMgNdOrxEAcA3zu4xmcRAwBoEEtSQjgDAEX+MJ3TfQcA0KBBIUOJAQAlwrhO/ogAAIvwQWNDEgYAJSYtGuNJAwBssaZ/ehMIANt+d5KugQ4AUNz4xb8iAgCQjRejKlIJAI2JTofbQQUAMxuE+4AtBgCX+ifwbj4AAOgzlp48oAcA7+UJI75uBAA4SWFpUy8AAIcFoq3lVgMAAvlrn8gbAQDbyBlkdDYAAENSUA/nXwQAfhSVyCBJCgBdTJRh7AcJAB7AF+BSJwcAeumi3bciCQChV9v2GWYJAIwLDJamdQAASRvkxeHdBgBBo21RPy4EAJ7nqP0DagEAOQ46YtEoBAD9CKMBREoHAAmBVbnUbgAAZ4ig9vFGBwAhI29cb2MEANML1pIV2AEA1cWFe5+2DQDrUFYXLXoJAJ3Bv20+zAQADr5zOB0+BwD4ChvV9qULAF+sDaZWhwYAJuyKe3VdBQC9gF/0PTgDAKaWn4w/eAYAzZ54pzQCAgBSsnhxtg0CANoOLNqjOgcA03AcwEWQBwBZECUVe7MBAP7PUyNozQcA4PSsaGDNBQDMdHr8mgcLALNkC2WXgAUAmU6crKt/BADNsrJTAu8LALb6h9hbpAEAfMFtB0hXBgCoEaoAgLkFAHQJCMnsoQQAwL1jiIyDAgAwUEZKz7ADAC169a64IgAArSXpdwatAgB6RddnQQkEAIJqYIrLHQIAujF3vvoADQBQMxHDU8wHAIENCP5lzwcAoRsBZtnFAwD2xvbbQNgFAMifnYxGBAAAjGt5VIXaBQAlAJVwvrgDAAmmpi2J1QYAMUoZCD28AACL4Z8wDTgGAA3uuCw81wQAtsC6rYK4BgC+TN3dq24DABmsMmInpAMAuH5E23LBCAB+p7cFxfgDABA/f/lXqAYAOuB/VsD8DAAZToKeDHcIAPqEcIosQwIAaKmoPPd7BABnKCZ2kWMBAM4QgE/f6AUA3hbqfBf/AQD9tbVFmtkBAOyZJE9nIwUAEyYYJvr4AACYjASYc48FAAAV1E8mnwMAznsJ/qtKCwAyOiUD/DsMAPK3kf7HmwIAFkqE5GGnCABew3ISYlwOAJzi59sXNAUA9ZRzgnNFBQDdUPam7mUFAEnHjXRQIAQAiYhGcy1xAQDdkzHO+IkDAOV8F7gk1AIAzUA0DfpzAACXntQMAjkBAM4ZqwCYLwIAmf1umt2fCgA/KCiplMYHADpL5O7N9wYAw1yyBzJaBQCMWThNGhcMAMv4nj6KNgIAC6ziCKpUBAAAp48/kpAEAC9YpJ6qcgMAYkfWbEE/AQCMTMmZqlgHAET/ABcA9gUAvQGMSE5pBwDW7kjp/dUAAL10pU8hCAUAwwPQU7sVCgDCqCx5nhcJAKFAyGrpoAEAtjq74pMjCgDKhkyKdacLAEv+1j4VaQIAQJj4riMqBwCcaZlSvlIAABYjE+/lpQMAuvrGDpYvAgB2UK6T9hEBAJDKlKq/4wMAh7h2lHlFBAB5SEYSCUoCAH/e+BX92QUAC1LX7ipNBADkp8LSZQgFAEDqOFJbcAoAljtdsnBsDAC4fqR/GLwLAH9yY23TCAQAYmCm9vj6BQBr3qgtibsCAObix/DUaQcA+/gUWfMyAwAMwobqFQEHAKitJNqIbQEA3ypmIgaYAQCdWhm86wEFAPsG6RzYUAQAP3SuHJbYBAAOun2Mw70GAGO04ae00wcA863i3kuECACqY5YnrcsEAHVSIKahtgMAz23QkSfoAgCHPKnKcj0CAPSqaKu38AUARWO61CXeAgDNH9egJJABABoQXxFlXwEACJcUZ5DpBACvpcvR2BkBAAcg/s771wcAlJDC88VdDACuebUgUkULAIkGHmPBcAgAIJsOY8BrCgCMzW0ZzfkEAAEoayZqHgcAXd/ic66aAACjsRmy2A0EAA3eF0X7RgUAdXvoNVSXBQBoN3tq2JcCADJjTC9agwQAYEFDXzBwAACuVk4B3YMBAKCHQwjdzAcAgMxgZxiEBABhM1NlVkMHAAG4NmNoLwgAMEP2RlQiDQALGUioPFkLABcEJm0sQgYAlLsXSJASAgD1VLjeGaMFAH3aYODUqQcADB3WDr0oBACnmoRemhgDAEKyWR+7rAYADGNTR+/2BwCpLSopRvMBANaijTCYcwIAUyRwCkwOCQAz13ujr9oEAGGJPtxrnwwA5drs3P/+AQDDklSUwnIFABPUXkMojQMAWCiZGU8GBADNQ/W+D2gHADyN1YPdqgEAw+jrellpAgC+MM3WRccHAO9431V3fAIAo3+TM2h3AQBVGEQWUUAFALwFjEmF+QcAUGO/D1IVDgBp2nS/6bkIAGgRIAiD/gwAQt4nYfdzCQCwac1TJg8LABfhC5+IzgEACQdRlGpvAwC0FgBySPIHAJHP4dEeggEAH6NwxC5sBwCFDMGqOMkAAEFxee1kGwQAbV4YwbG+AQAHD2CQVO0BAEeWFT8n8QIAwAunVdeLCAAI5lyIOp4EANZaG4iFZQkAXU/TaHXCAwBf3H6ZwYoDABEe4Ip8/AEA5+hzVU0JAgDSSfW7PMoFAENBxewg+QQAtoWtcuXZBQA7sVGnF7UGAMyAsXDTzwAAGvTRJXk3BQCiCGBWVk4DAJ7+y9n8LQIAjuA7ELRZBADdKi0/S5oFAOuOu8g01wcACUpZvjw5AgDeTIJ3mP4IANkMDcPg0gMAu3FmaJf1AwCZObZ+WKoAABnGkrXH4wAAjEQFbJGyBgA7kboK0TQDANvPgbXNRQAANo86VeDjBQCy/x4EswsFAAD/B/MDwwQA7UTZDVgDBAA/ZZJ9940MAOlJs+OfigMA4a8KhYnqCABpcKtRsRYMAIWMshfWOwIAYVp95y7nBgDeTRf/cqkBAA/Gc2Nj4gMAq7J4jxvWAACwNsHp79cAANUKZIkcqwEAlx/0roJfBQAN7RfzV2kEAH4ndK+ikQEA6A5GT0MrDgD70/rAxpQCAA9Me5NogwYAW4cQKfjJBQBFBeDb5zcKADEUPMVL9wYAwtm7XQ7EAQCXXK6c+8gGANq34VxchAQAzLVQ5ODiBwAwtAFn7XUFACYAon/h0wQAU0KMiPyRBwDBigeZuvECABURm2n6GgcAw1A7Rxw8AgBIHeIdZ+cDAOihR1X6JgMA2a9fwk0ODQCIj8f7MQcIAB22UzmbbwYAucw8KPRVBQDnYBn7Z90HANT+r6EHRwEAHCucLhQhAACAGPhIGMcAAIY8I9jZSwQAMFj+jlfoBgC1QXBtWwQEABV+NPPWxAQAXRmPmPzdBADhZaM+F/YEAIhFrvnaRQ4AOmLbYzfUBwD5iApQ+YsLAMkffcHP7AcAHoOCByjKBADW17F9M7gHAPuVOO9tEQUAR36q2v2TAQBvh+g3PMkCAPqDxSgaQwMAediL2kmQBAAcwXpAqLQEANTw65n7pgYAxiPktrUiCQDV3fHfUB4KAL91TjJ2PQcAjkGVVEiIBQBeLPSp/TYBAOtVCFa7wQYASK0TfhIfBwDsWpAEs8YFAMebiI5rdQMAiTFKkXZfBwDRvQWjsd8EACkfgQX/swMALtk8KGLtBgDhUuxDFV0GAI2+EDUYIgAAbHowQwFxAgCr84u0j9gDAHqPwU7rSQoAXin/XRE2CQAD1B9EfDgJABQtrV44ZgcAXgkGi08ZAABiO4L2eIQAAAhz04mGAQYABrgXznGgBgD4ipeH0cMDALp2gsjhrwcAaK3IgfIdBQBdJKS9BkkGAO3xqiYbFwMA0UeKsti3DQDANJ4U7sICAFP8mmL1dgcAqUn8UOr0AQAkRDOmFMUGAKhMVpeQMQcAJTUjvE6EAQDh7v1DRR0CANIb/6onrQEACM9zSP0hAgBBYxU6TyACAGSkZUBBNwUAg8/tOww8BAAgpm5wflUFACS5b1mqjQQAgJdMyF0dBgCewkAw6H0EAOcHZbLeiQkAmUfc+ubUBACn6KB/g4wNAMecpVxmjgIA2Q2UFcdlAQCVHKE6X3gAAGmE49eYewUAhK3Mb912BgBYkPyWhWgBAJ9hA9RqbwYA73J3qFnXBACkvnNhboUHAFdqLD/3xAEAhDR8/G5wBgBtNuw5eJgGACZ/z5UfcwAAvOS8jnWuCwD12retWQQHALugXzC9TwIAz6F1zJgKBAAzdQoi4YwHAJfB4RB6IQYAZL/RgKyVBwCzK7SRSdsBAHJDmVtgaQQAWJpcceMxBgCPcs/vz+kHACHOSCgW/gUA9bF8XS2FAQAP5Vy+Dw0GAHV740bioQUAkNX/Be4aDQDZdzYETLQKABqWlOFPIQEAy+mpOa7hAAD3+Sa1yEMFAB3pZ4BJGQEAF8lvRJ14BACOt04Hq4cEAEPjjF470wEARhvrn0E+AQCk5l1WH3ICAJq78u5SDAYAEW2ufMLFCwAEbpWRlGoLAKUdE8m6JAkAXCsg3ve2CwBlm40kdw0HAPGL/Tu8iQUAa0Gjaj75BgBIrsHWo8AEAGpYCyaHVQUA/MwSw8kLAQBboMI+S+gCAFEVPPCinQYAe6ZhRhc6AgA48omivAkCAG+XOr1VNwYAt6zxlxgQBwC4B3u3LNgLAPRpdz0IhAYAB84tRygrDQBRfHNRN3YCAFMI0So+oAcAqzatxtwTAgDWvdVA4qYBAN/++PxPwgcAFrxIHMzYAACpGbRu0wIEAFKgFIz2zgcAOdHCWyXxAABqGDHU53MDABatp9gtDAcAAH7tuH2WBAA6Ui/Q7loJALuU0JGVFAYABnDBBPJyBgBTaoEThisLAA7sb59QlAEArKwxytgoBQD6ubhzbYIHALP54JnLSgIASDk2xvrgAgBkzUjkvvcHADwP2hAP4QQA6SCruWyTAwDQbOpP/KAHAKQ1xxWSFwQAIc1rKLkzDgCUnNu6s8oOAPm93344TgcA2Q+KxRNDCQAbJGJWqB8LACrt3NfnlAAAjhGOc/poAAAr7l8KZBsEANQZ8J1wuwYAmc0wSjQABwD0IjYuQmwCAPC1BWoG8wAApoAEj0TiBACV8NvgzUQCAFKZKjGySwIAWFz49SoMCAA+iPJMn2AIABLKobVu6AYA0czvokSLDgC0/p+v0tEIAMNn3jIX7QAANRYpacMIAwBQ0vJI8z4DALuhoV5HBAAAiOFx6OP+AADfHmIyoYoCADs1r0wkKwQAiuDCTAZrBgDTvQwCILsGADGFcXnNagEArbaHeMXGCQAqWdcf8qsNAHmGUxLUCwUAUTEncQuACwBggbE07WQBAD0dmy2vcgcAW06LRIbUBgCoGI3dWM4CAIs8UGefhAEAApNr7+AjAQCa5i8ZTNkGAA9poiJSRwUAs7iGnXiTBgDcafu9w/UBAD8HYfygjQcAgToMaPGABwBT1Pw8XaMKAPfdx83lBQgAI6x4gIjuBgA4azFLqlQIAGrGK+UoXQEAfstRAx4OAwCMH7F0LwoDAAPe1wwSnQMAsVay7l3SAgC4fCYZjUYAAPn7tancjAMA4qEsXLC7AQAzlY51FbADANq3agphNAEAFfXRd+dlCgCkOR5M9fEIAEUmUpUb8AIAbd6d29j9BADMl7qMh1QGAP6w9o3HjgMAImqjvq48AQBqX07lxusFALgOPZAEKAMADbKi2y8QAgCh5lwFBeQGANMypTVKAgUAnfLaVJD2AQDVi3oNHV0BAMuesl1yrQAAhW8Fmwy8BwDY//q//hwFAEn1Tem7SgwAIDHj17vsBwCZIzD1dfYEAFckToOxZwIAiLt4wxmuBgAS1dlee0UHAPsFPXgNKAMAAxq3//yuBAAeFxUENjYFAGV4BwkzMQIAvK80Q0RRAgDoVjeFw7ACAIYqKrfLvAAAlhL+UExeDQAMw+8T3V8IAO3lgMPGwAkAp2L74x3hAwDzCJHWj2cGAMipseovlgYAC6O5j6KsBgCYnxvKt20FAN0YcElYnwMAa521Ck8CBADCY2hjMfoGALBCfqblCgEAMdof8Lt6AgC8T+a5p4ADANTqCCEu1AIAgHVTDw17CQAthMnAY2IJAKM5RX6CqwQAOtdD2w03BgAjtHk6vyAMAJvS35QVEwUA/lKN6SemAwBhVoVBQBUBAISDn9B1kQEALY2LYLJ2BgBHK1scZboAACcQcGMjhgUA28YZwtbEAADeWIb/PfAAAM/Aqf/SRQcAV07TIVffBgAGDHp2L/MEACBux+qr1QkA4+EE4ekcDADbwVS+FW4IAL3IySseWgIA6jew88gEAQCYbKlvVwUEAG+H44hq6AIAz2C5ziOuAQBKmTIZh10CAG4LVjvWuQYActTIFCjfAgDtpArivvsAAOx4EobtjQUAlcnCtqhbAwC/hTGLpd4JAL27I81VtAQA+INIwBnsBQDVMbWWposIAFzFZvKTNwcAAjvJqYi5AADbJSOjDpsAAF58wXGufAMAX0iF3jn/AgB6xe/D7j4FAP0uAumf+gIAVIETLMeZBgD4H70edSoHAM9HSTtjIAEA9w8SSUcxBQBX0MD3za8FAO2NeBvnqQcAiAw7j3DvBQCTszy+M3QIAEIAYZF4mAQAcgFdf52dBwDEnjsBk8IDAMrKOV+4wgAAWU2bqTBdAwD0l+lcwEQBAO9/NIoLlgQA93Rd8RHaAQCt/sAZrE8FAG2v5+1z2AIAbvldTuECCgBLtT68AuoCAGQ1iLJ1iAMA3ek6UYwpCQD/FaAYNlQIAAk0N0NkMQIAryI7UJXeBQDf4uobIJkGAHpz/0lY2wMA+gdHZXPnAgDBI0yX9L0CAL1h0si5swQAKLypsuhqAgBRXBYQggYDAHnQYjNEsQQAuJxSHOlUBADPcr/GmEwKAJnYw5RlSAgAO/rXoxOuBwBmr45BOHAJAHofbrbHtwQAmNnvhaG+BAD4VRBxvPoEADj+Nnif+wEApi11RvSCBQDkTDIg03sBAMaYeBGJFAUAC0Ggkk1oAQCnxXgP2eQGACjavMShwgAAMmm9aUiBBAC4XaSRw7cHAEG2NawWcwUAagnpHeNBBgBNMQqzqaYNAEcEH2/QxwUASToL+HDbBwB4msg+SssGAH05ga3oOwQAZG8cvVjFBwA9RpbTJBUEAB0ankRrWAEAiu1KkH7xAgCOPB2G0uEHALqvoFxKQAAAvm9BKhueDABWbDELahwNANsb156ldQ0AHewfGgJMBwCOf25RJ5ULANZDpwoHQAcAgxHdy2RrAQBD6zJ7Sz8CALM1gqWrGQMA2a3cv5VjBACcml0aLdsHAC9ChQsgmgcAFt1xqr9VAwCqeF/qdwsAAC2CnqJ5ZQcA3zS0UhO1BABnJhzQezIJAKDIYDvXNAQAukOUqNrgCwB2orJLUSwIABcqwEl+jgYAtuhvNJVXBABGNY9sMIkAAPaIL2uf2AYAW+DJTTg6BABFtvGL2tUDAAltaqnW3gcATS/uT0nDBgDUa4ucmCwAAEgVliAJFgEAuk2bNhZWCABGb6yGq+wMALEA14UAxgsA6fwN4T4hCABtHknXN/YKAKrP2ilpFgUAifYxa4KQAQB9SmlnVfUEACLlsff0BQcAmFa8JeFRAwC+e/YaRpsEAJY6LHEVWQcADQxY72eaBgD8z3DvOE0FAOJ8btCC8QcAD3UhjnJLBQAoARuXkJoGAKNjqfJAGg0AvqYSrOkLCQDEQTIEzEoMAOxoAatkjgQAT2+ouL2iAgApaS1rOzQHAKPpjKoE2AEA6UPDyEp9BgB3V3pPu2sFAI8jfGIwkgIA+9csEhqtBQBk41Bupd4AANcqMcjRVgUADugbsVZnCAA9sHt+FGIMAN+/PnQZZQoAtCpoWfyCBwDHyIzjq5cIAII5jQzjQAcA/YJGf7TCBwAc3Me4kc0FAIPl+ZCnfwcAJNjRxsZGBwCkLaV+h8kBAIlhqIN7swIApQ0xSa8zBwD7BBwWgV4CAOi+NErhdwUAK9dNvb7OBgCfMkLkwUALAD6p0f9HIwMA4LssJYlKAQAJsI9LMAUHAAo7p2GsaAIAHL6+NPIGAgDo68unA7QFADVBn/BgoQcAeP2W7qcPBgDGbilNNR0FAMcWO6b1ywcAFAzPswv1AgBaxsqFs/4BADUWyuCYEwIA7lW3tPmqCADyRK61kWsCAMixeo2A3gYAsDBVZ2mnBgD3mE4o+7sJAPMzKziKBQUAPpEWGKl1AQDoimu5zfYEANKB2slHcwEAI1rZ2T6qBQBhZdnH6XcHAKzMBvBYjgIASawsu7tBBQDsTJmCMuYDAJXo5RR+oAQAm6R3xM1YCwCA5AL+iMwLAGrj9LeqIQcAU5lGyYxACAD5Stiu9woFAJn5DZjLEgQA3Cnu2I3nBQBdV4z233EBAEnv9tJdAQIAE9ORw7rwAwDlW/YVAd4HAMlNNiEsJAQAmGCmZFu3BgCFwAIBPAMAAL2uazEakgEAi8Hz2ZqtCgDqmjM4FuwFADuoWWU7cAUAEtYFTZ/6CwArBsreSbAHAPxwuN9+LwIAKLF31u5pBQCvpbDcNwkDABvqeJwDWAcAOice9I1FBgCDREQ1euMDAJl70rf9YQYA5CHWHXYXAwCJYQIwPDIHAFApvMw9CQYASwOEYL7uBgB7jQr3Ac8GAApnxlQatAgA2lW7mUvIBgBHtpgMGOMGAG1w4IWFmgMA/mMm53wWAwCXQtvsFD0GALhw+dwhvgQAeoKEoB59BQBxsCih57YCAM9ddRF1sgUAZQWTwoSFAABZQW/ae4wGAHvZ3ZnpYwMAs65L4txIAADjBeyVV7cCAMlt2sWkvwsAHTeeZciqCQCab7x5+TEKAMQf7jXBQwAA1fIZmRyhAgDNul3CTDMGANoAtBfalQIAoJOGt+mOBADG8yrMS94BAIbroxHEHwYAwC7BmtE+BQDgBLjG2wkCAJKHsKm/eQAAMkLVooDtCQB4XirH/g4HAC2CKtRRIQQA6DHWtuu1CQAFR1mxT+8JAPQNMNpROgAAchxWK7VnBACQ5RACktUEAIWWeJ52ygAAF0hof8c4AADsexZb5l4GAKlQuBnaUgAAKWRlZYZAAABMmm9ZOasHAL+gpJLudQUA7tekCkW8BgCoCzt3pvQMAEe8DgsbJAYAFZMdT5wNDAD0guPnoQAKAM8vGIqQgAAAmLq3EylTAADDhcN4z9wDAKmrXt0CgAYAP80ScU49BADFOvnqZ7kFADEKWMqsYAMAYvLG1V/GAQCr7MIVfxwHAORRJqXsUAAA6mjmYHY5DAD08pJWp8IHAO9mbH6esgsAmdq8WKYrBwAaE/oJHBUGAJwMP0XeGgMAaHhzB+7fAwAR1Kf37BEGAPZkvWx+YwIAj8UhbO6wBACWXfD9DVwFAF5Hz51WBQQAu5h0J1xcAACJw13ZiIUBAPAAqE/y/gEAc2uXMPWvCgBZhMBIWtgIAN9CNpbrlgcAJrbEUO4LBgBAg2z+BYAKAJYxpxr7UwYA+gaD7PoHBgBUUj7IXugEAP2EBZBWnwAAhvySktREBQCIhlI0n7oHAF0ttA+ihAIA/m9w2SxlAwCz5t2te/0GABbzMClHLgcAFHYq0zX2CwD9AN6s7MsIADWp6kERQQMAlMvzQh4cAgAG/gDw5/4JAE8IgZeMIAUA0iTcoWhkAQCoQMUKeL8HAAFT185+pgEAOnPC6NKpBQDl99sD2gUDAMqut5mGIgEAyWuTsiMqAQDp5mqlvaECAEDgHgWUDwAAQJevB7uTBwD9+tTstucJAEL7YBV7LAgAtl/MNGcpCgA/3SX9f3sMALIw08MjawUAptFg4wh2AwAucsjz4AoBADe2GLbZhgAAq77ox3l9AAAS3Qi8nPsDAP9wU9g9XAcArBko/gZ/BADtFZKrBtsFAGTqNQpSwwEARsBrIUBvCAC02Q+bV6ILAIvsfkAmHAcAC0+1StoqBwASbbbDUIcLAEqjy7ymUwIAGnAzBAcnBAAOh/lYjgsCAMwA22HINwMA7tB1V9DDAQAa5SKUQPEGACUtzr5rhQcAHAMvp4AzAQC686eAED4EAAQzfSweYgAA8/DbsJYXBgD11jKcLzwPAL1+U9GOqgYA9DgYyZJOBwACEMqJ5dgFAI2DWYLMYAAA85Vb89M4AAAjqUPCeGAFALIbJJMy3gIAOr2XYH0AAABLqUIIlR0HABfYx+URawQADU/LvotHBQBdHApLBcMHAMvBg3c9WAEAxyidzARHAwAA8rGY5d4DAJ5tdJgcbgEA36+VcAsFBABVPOhkgJUEAOF6ol3vogYAnZ0u4KyKAgDo8GXpWSQAADMJFdNkuAcA2B7o8qVSAgAN6GZQJpQAAKVhjZEPpgAA3g/z90tEAAAGPO2pDcQBADuEvXDBeQAAVtDVwFDNDgC5eedqYLcFAKHdayK9DwcA+R85Ux5mBQC4F3MNjHYGAP9v+mTk7AYAoGCkvEDMAwAMjfsKqeMGACgSobwagAUAn6w0XsDeBgCzwVXx5SUGAJYycm8v8wQAzu8FAZisBQA27l4WYXoBANXcTeFFFAUAQqS+K6tHAQAmMSXyQPIJAIhOMZ7ewwgAXqT8pKUeCgD85IYAmS4JAFFJFDtLKwAA6mqWd4loBQD9nzluF44BAIuTtF5c5AIAKTke84YxAQAuu99/s5YEACE+X51DwgMATWp+/mBuAQAdYpuI79cEAOnTBT8uewcAkbDdEpxjCACyes2QBBgOAHtGl4KR8wMArIEXvmhFBwCV4FJRGXoIAN7ELpzFqQcALWV5nvDpBwCGLfIi5KMGAItsgzuOrgIAMq3HX3k7BgDIX544Ao8GAAZ1h7zxWQAA7AxBDpkEBQDirv7Q15sAAPAy0IP+6AMAKdHv6I1MCAANIeYGfMYJAGkUf483gwEAidKuzlJDBgBYYpqJYC0KAJSicAW5FQMA8SWpCOEMBgAJyVMS9u8GALBwLQ7vAwAAxPqXt6NbBwCW0c1wwNsBAEdMU7GPbQEAKvqDgUkABQB13iPEWS8HAHl3uAdNkAAAuUD5SGYtAgCGPoehpZcJALtUGsTkBwoAz9ZLOws2BQByr+usCiQGAJyRut3UHwYAmVa1kenYBwBsxzxHMRsGANYx5jGWAwcA3cH7QyE+BACglaJbnHQEAAZfS/pGeQMA8VFaq8UkBwDz0514M1YGAEDbOPLaawUAnzudwWzTCABhItdwROwGAK6pGHA9hQYA68jCTT6qAwDl4QcVozoIAOszNfXjuQIAxQaoJ9etAgCjFc7IVWkFAA4pCgdPjAEAQTfYhkrSAQAfztT/SHYEAJ2eg5GVCgYAqxeB89UkBAAOwRJpxCwEALSuyR0mOwQAUROVbIs9CQApY49+AcAEAMT5U55VPgUA6m6IRgGyDAA/KSReTSsIALt5u4gZHgMAq7yzRi+4BwBBe4LOqPcAADBxFxZY4QUAdrL1XAUmAwDyjdEoy1UBAJQWoZwNwwAAGTGrJw4JAgC2SXpOYggCANPlmoBsegIAQWk9xAonBAClWVbZTO0CAPkodbMNXA8AM5Is/bzMAgDC2AM2UCEKAIixDR/N6wYAdBF9S+tMBwBcT99oYdUHAIrRbxd5vwAACvZPF2fLAgDQ4Qs5+c0GAD0rfpxRjgAAgQil0sNTAgA9M45EQRsCAA+Jc0vfsQcAjPX4BxgiBgDlizqBkvoDAHJVjcOY2gYAj0ZUVdkeCAAtNV0kmIYGACSisrPg8gIAkhwsomrFAAB4svE57P0FAAbxx/UKyQQAxY9l8s4fBgB6GBgqhV0BAHb7mrXbcAIAq5LPCxLbBwCHQHFdoucAAPDac8T0bAQALYFJ8aduBAAnhAppJQcPAPp58Ok6pwgAKsZhRJLdAgDM2FCuWgYJAPnlxJ7tJQUATGhgBtIiAABoezlwK5cHAGX501g5oAcAtU7RvIeTAgBXDSDfJUUEAIVD6Uz51wIAt+xwwQANBgDw2PMDBYsDAM7xZI4ZmgYA7crF3DRECQAffGafkMcKAHW1H52DGgYAdrvKADjyDAB+Jr2XJlsCALx4GtngsgIADPLMEgqZAwAiJh/hwkEBACAzpfrO3wAAOkmSap42BwBkaJgT+z8HAKwT97grKAMA75fyeO2cBADvHWYncGkGAORU24MGQgEA0FrMwW+7BgCdZpHVyDINADJsqE15rwkA0iRt2OngCAAHHRa0gx4DAJfRnSQevQAAj1YgGMsLAADUMIhxseoCAOaXaYH9lgMAilC/vmMLBgBPKwaeEscAAP0SW0Em5QEAPZIn/aBhBAC3pXD2rYsBAFDVYuvxXAUAP4z1feO1DgANxoY587wLAObqXIO4TwwAo3GOwd6ZCACfK6a6b6UJAFg9wmUQEAEAD4szkBKqBQAhdC6efhUDAInUFyBx6gAAiXBFVqZpBgDsyZ1cUGsGAIdS44bvdAcAXpXARNnRBAAgK9c5TC4FAFiceTZIPAEAgNCLXWr7BACbWAhJ44oNABKve5dNlQMA3EF0WeoTBABbjtyH3AsFALnhs1pGXQIARyjsJ/74AAAGT/Db5tYCAHYyG/yMAwMAe2M6yYBvBgAR4d9ugzcFAA0sezUCvgIA+NTIWO7cBgCSYR1YMtcCAP0lR0RW3QEAh8i6CADmBwBSGHw4XD0KAKcz9fFdngcAz/DF8fnmCgAvOvZQpKMLAH0SYjP4fwQA9LGCrzmOAACrffIuMogEAKShojg3lwEA9xkikUXmAAAnRjnYMS8HAPEAopTSewAAxnTiAL5lBgCLNrbx6D0EAJo6OdnIGAMAhdMdqymeBgCsa8ezhQYDAFlI8jfPZQUA+f6Owip7DQBPWTIcpAkNABn+/yoDXQQATt5sm+QvAQDxfDK8YxYCAN3xaUxeigEA1aF5xsckAgDpJfmm3G4AALh35mODjAYAz/vkJfoMBgBOQAl2wcQBABGKMgL/WwAA5BLFDd2gCQAPzV+/lAgJADacPwFJKQUAxzVHug/1CQAZ4N58J3YFAAvgyiNwEwIAxibrmTVaAQA8K1EhcmgAAOkkCDrLUwIApKI/zLiABwBfME8jvIoDAN4DwbuAogcA/l1pNqiYAwAailJBr9ADABsnJodB/wUALZW2E+hHCwC6PBzCZGgHAKh0zdtJ4AkAm3STD9a0BQAMCsq4TZ0KAJ3biRcMCAYAMace73y+BACAgJ12DfQCAAOmREx9XwMAllrCPaAGAQDQUzMzrwoFADW7PGGatQQAdprhwN8jAgBkxbIrHn0HAMtSEKU4qwQAicDdX+/RBwDZ2rnr6r4HAPusoAvTWAgAj6616pLNBQDSTrBrHAQLAJPVaGclKwQAT3tCWYToAgABB2N2OCsAAOXqBdR4SAMAigjcGt2cAgBI4VbZ+fICAP7BZa3mswYAXZ63cgmwBQCvXUwjjT0FAElAgda7BAEAUPF/1l+aDQAqNdDqmKkLAJmvpF/JgwgAbiYB/Nv6DgBxsA+i8gQKAGft8Wgx/QAAPkp45w27AQB3BLJ4y0sDAIIhLm6ipAAAp5JwxYy+BQB5sOswPTsEAAIZxqWsVwMAVSTWxXC1BQDHGB6esg8DAJEnfLEPVwIARyS4C1WpBgAlIxoK8hEFAO6bI9ckkwoAwxZ1wzw0CwAX4B35xUEKAHUVtix/NgIA34dNwJrDBgC95deLldQGADIVimP0ZgUAMDClXrbcAwCqbN5AKRcAABtFZy5bBAYAs/w+RgdsBQCRbv5ri3IAAN/81e0ghAAAuxD0BE7DCABqoNDA7UQDAG1N2IZU5A4A9GM4yy5ODAC3HTJPZU0IAEr6YoOrIAcAv9nNR0OcAgBjhF+tmOcAAP4Ly4vx/gQAdsH7PqXZAADVtb3dFsEFAM+rpbu00QYAelOlSIrSBACZCwRbjmsFAJGJYfKkpwQASyo3r5GyCwCXRP4oMA4GAAlqT8p7JgoAQrJCwu4ZBwAOPiIUY6kEAJVfsV8CGAcAlP5xg2uNBgB82fdIRIADAIBCeP5mJAQAMd3NxFAbAQDW/6QIRCcAAN00266C0wcAXTjOyc8KBAAeW6SZuygGALzm3OS89AQAbwudxG5hAgAc5mKEXfkJAMVZkZs+rQkA+E2gdaSbBwCVFVbuLAQDAIQlJOJazgcA49RTsV7SAgDJqZvQ86gDAI7rBA1p8wAAwHFL0c0/BwBBrJtEeXAGAE9IIUactwUAjWsV8mkQBgCvEDtXJusAAM6pyUDniQMAFawOV/Z4BQA3OZwz8kQGACxslbdHbgYA0FUf/jJICwBiYl1eQlwKAM653DSuswQAn6wVGml8BAAMQF1u4BgDALE++NkixAMApmWUN0UVBgBu3tfxpgYGAOcHYcTA8QQA2OX73LEpAgAnE3sKxqwDAIRUkQiaUwYABkq7FNTbBAC42/FJCJMPAO/KZqTFKQMAm+tPVCTIBgCbAe8gU/YIAHP30sN0HwIAOr0IjbgkAABRQQXPeOYGAHx0LicxNgQA0VysSl4cAQDG4P3KsdEGAJA6MGrHYgQAm/88aU7KAwD9hlfULJUDADDD3nu8ygQAidJ4P494BwAR+LMJKJQNAJvC+HcylwUAZ/7FO/kQCACxrGWBSe4HAC4KnAgklgYAcwTnyF8HAAATIx2rhD4BADuV9u0LwQIAyCEDP7k5BgDDoRGR4wgFAHovkQ4SkAIAQ66sZPTLAQBXYVfpc1MBAGBbyJP07QAAAEF2hNLEBwDsrAa//v4HAABBgnr7mgMAZf3nR460CQD5HU3FAEwIAGham1lYgQQA2dVBvHX9AQA8Xakf/NkCABG6DvIn2gcA1BkwLrkDBAD4XEaLgS8CALgJ/x2QQgMAzYPGXVkfAwCC1l90V3oDABcmqxK7VQMAGHOMWsfaAQBgNELVebYLAA1Atrf8uAYAnV++gzfHBgAqBY6vjlEHAPS7k3TMZAYA43QYdpQ9AwAT9pYXnhcAAH2G4jUFiQEA7IIhE7j5AAAybH8bxFkAAJEUUwaHngcAgrU8ZEfHBgDklNQKDOICAHWxu3E4fAQAsGZQyFBdBgB8HzZTdBYGABKzi4GjawgAIXWqm/KvBgBIjc4C6o8AAEhP7HGXUwQAKMqtizG5BwDFFuCvGQ8HACONYLF77gQAaWRXuIkLAADQ6t5odt0FAElwpAttCQQAFJEhl1knBgCu5meK2psCAF33dJqCcwQAyQI5rTpTCQB65BFr4N0JAHYLk9G+hAcAZ8i5kgrICQBMTtS0aMYGABjEeUZ12gIAWhC+MUwWAwBf75grrB8BAFaSd68aWgMAPIPEhIYHAgAMgnh6Ic8AAGnn0uckUAYAKqjd77U7AgDG0zK21J8BAKT4VGAaQQcAtHWxGD3lAgDzSiBUcj4LAMTEodXXvAsADl32KsLHBADDWCSHmuwBAG3InbkynQUArKkiXgesBgBxMxEgkgsDAG6WOKbZfwIAE7hPVzbBBwCbUKIA1KQGAByXVhB5QQAAXAduhtVVBgD4TebzKzACANZ8XIrYrQMARjA5WdSYCgC3kD3L/gsDANb4Peq42QMAeRVRlg6QAwBqQBoToRsGAPLcNbZwVwEAcZX3g82eBQC9fwscRtsCAF80galCOgcAecjMn5JJAgApkJUW8aAAAHo0sddPlwUAre0IHMzgAQATH634vXMGAI69yxADYgUA1oXid/S1BgDIbDLske0MAPyjA3VT1g4A1Ig5dtMmBgDOWDZvhOwHAEPWNElDkwEAUapeRKLUAADgb+eKcNAHAOHHw7ZHmAMA2dmkonZ2AwDHLqIdP48GAGtzojmA7QYAdTxM4H5iAgDR50emkOoGALmZM3Kv2gYAj46trL8EAwAHixB9kQIFAA/dpmwXQwgAgx0sjxXVBQA761ieRLUKAEe+PetidQIA5wsXtNeRAgDhqN9nytEFAKKY8mGAqAIAfWJxnk4wAQD+nNxq0hQAABNvoRtp8QcArG7wKBjnBQD8//AH7UkDAN3C1+KNRgQAuwdj+MbYCgByCYWhaygOANNEhLDc6QUAsmIzVGqpCQBGMuYnZNoNAJ5GGZReNQMAN4rquHuEAQBxm8+IZf4BACJr29LJsQYAS7T/xufMBgDKIqzeiMYEAFID/8N19wYAuxnkPmBlBQBGHMZWRFQGAPJ5/qspjwUA9s0Ocb9kCgBqiSeFxQgHAJQzxebqLAwAaSvoIRs4BAC0hUFyk68GAGg+542rzwYAIb3Uzu/mAwC+DVAJZgUAAN+FrSR4GwcAQX9KnGJ3BQCIqMYJRQIAAERmLrFqaQIA2IBLf6LMAACeERvxwccAAOzKsFvyAQcAE8G+fNn2AACjk3z7l84MABooEVqDOQkAVZHaepAoBwBVCQW8pSAHAO1sYeT4sAAAdbgPtcTTAQCYAdxzlvICAPoPg/Gw9AUAQNz7K8ngAgA1WoCbQwkHAIeBf1VI7AYALDqhG02KAACu+QuKNHYAAO9Escu56QAA276xXdWbBgC9MfdHTuEGAKwOJ0deowkAjd94VCJvBgDTz5FB1GYLAK0gV/uP1AIAd9+hIX97BQBFBrr/DlUFADGpmEBq7AUAN/OzThAhAgAUjLzyQxcEAMdzh62wlgcAm2i7XO6fAgA0hxdcZiIBAJPFa056FgQA24/O+GUmBgBXmMUaEJ0KAPufpbs72QQAFz83l3h7CQDstww3M0sLAAAn9nYonQMAh2wdzc4BAAB1dnQRGvAHAJCBoaUNNQIAUiXit4uTBwDM1oGG7pEFALh56rSwnQMAQgg4DyICAgCs4EK6dvICAObf4sZvFwEApQ53SYniAAByexSInlUFADDvY24eXgsAbv+nmhBbAwCQJk/lo/YJAJthnFvQbAcAlRaQsFSWBgAnf7cQN6UHAHWB0qcemgcA1XfGpMOPAADqNAfTmcEEABTMmssixgYAFgIDVQpmBQD7EZ8Z8WgAAJBrEdD68gQAJbY7tx3ZDADEEoFTgl8NAN0VmCda2AYA+ZzNsLdABwBOlPKVGUULAFROrpRBsgYAl4jt/QojAgBxUH1hEjQCAJuWNQ/T1QMA73JJSkhFBAB8feqf0PwCACrSnmsSlgIAsgUqAXGhBAAjVU3HktsBAIlCYMqJCwEAW/BFWr5BCQCmruyLs60FALvyQdtG/QsAOM61u4jUDgDT8J4dLX0JAJwoGJdJRwEAq8fkZ4qkAADjr0tUvA8DAIrlXzEBxwAAdXtXjYcLAgBqPj8HGK8CAP4kDULqOgMAlP/0iwCYAgAelttxkVMDAFzGPPYUIgcAtik79Lm3BQCzo+4x6kkJAAgWWBN3vgQAmF45YHnYCgBToVXISvIJAJOmB1NAfwMAnLbybOblAgBTnK5mQtgFALlT6H3r5AUAHBdYjPT9BQCqBZWOMggGAJrEHYSCIQIAByMdiZbsAwADLvL/Y/MCADmu4jmnCwAAJruI6vUmBADIdX/nkjADAOcZ2EA5pQEAE4aBTy4TCQCMUX3elyIHANaQh1zemAYAJetbVLhoAgDf/paLZNIGAHywHa2IeQQA13rmo4MyAAA5uQy+xx0EAAQJEGZssQEAbcbLIEyiAACBhuTv6aIEAHFihJYSXgAAUEUsJMi7BwC3NTsQBpoNADIg80p+IwcAelOzGkImBwCMJThd8owHAFpJnC2z7gIAUJcvdyWeBwAjvzuDR9cGAEnX1RbYzQYAmDbByQCcAwBonUgxjmsGALXiEH6FcwUAchSqFug7AQD4S63TZBkEAP+zdiC1BgAALQjOuRZ+CwC4PoVXL4gJAMQf0Kye0gcAFee1WWrnCgD2qWGVLt4HABx4lZ3hzwAAPEUcYswSAwB8B9rmrEUBALjpnO8rkQAAdrxDNH7VBADLXqW29NQAAM47c7uw6wcASQUgBWq6BwBpIOLk7fYEAAKm8QqpsgYACtiyWyTzCwD8bvMg9+UIAGzAYM/MuQsAJXnzI+OECADBdoIsgWUEAJce5pr89AMAJC366we8AwCg1Fy1RLcDAPMhV7JTJQcA0xKdTo/9BQDZYhAqsr4DAKjJgjsGpwYA7ZfBXaOlAADvPaUGDMgDABbLscIyWwAAgoHVeiykDAD+nnl+ZsgFAKFQyHReLggAmYZOYdvwAwAwZ4WkcRcLAP2oTdLMXgAAGHnw/buABQBqPIeGNecHAD75d9/tTAcAcbQ3alW1AwCC1E3hJMUAAFbGlnRFgwIARc22z2utAAAUJLDo0XUDADOnJ50H/AQADcWGDESLDACFO8qckjkJAC7fTOTy+AgAsaZ7ETKEDgA7risMF0ECAH8vv4mwOAEAOeo0/VugBAD1XpJMkQMCADxO4P9/SQcAmK/sfFYkAQC0c8QKhqsBAP+nhnwiwAUAd0TCvxIbBwB1MKhzpQYAAHDIZilh+AMAAI0ENvr8CACCs7szcW4GAHZWpKhCSwYAz4WaT27qDACgeOjuV28KAN4NKnjJDAIAs6pwME5dBgA2d1QxjrwHAJgtQ7G/ngAANpdnd6oEBQCx74dW1SwDAJVhL16PRAQARQNGnZFoBQAnGq3gwjQAAKPb2UMZBAQAyqpsokN3AQBkyflWkYwEANCaHo0n7wcAAb2njuUMCAAMgCkUky0JAJbM60O67gAAePiVU92EAwBy0jUaM98BAA73Sv3sBwIAQ2iXHQpCAQBPWTfTmXcGABhgj1RHFgAARfF4Vc5/BQBxKhQMIgkAAJo1FCP5tAEAsWaYpDAwBwB5JgvpK0QKAM59lNjTewcAKCBVwVX7CQCh+VYdGf8FAFEJFYmdEAQAy0ctLb0lAgDqO+eAwHwFAMsfcnUQ1wYAMvGncrU5AgBokC2sM9QGADNwpDD5KwcArQ6i9KxPBgAqQLmi92UDAPNYpybFIAAAdsxC8FnvCQAl3XZJwrEDAHJisVxmHQsAVsVw5FaGCgArYKXgz1IMALzb2J74NAAA846NlI87BwCryiPTwYYHAFFuJqnUOwQAE1NhxKwqAADfd3hkoPcAANTwkw/M4QQAkBHvJkfsBwD4EvWL1b0DALgEs9e3zwQAEu+Jl8KZBgBQvCHj6jsGADW7rUDDJQsA9SvkoeFiBQDTNMTL1LEFAP51m7hsPQQAVg6QW40zAwBTGlN9Mo0DAJ8b1WFcsgEAdZCzIkZLAQAmnwrMFSYDAN+2nLkRdwUAODzpFJymBQCZxaSAiegGAJKFJXGP+QIA7qZUT0SuCgDBxft6ORUGAPv484N3DQ4AuYbEX2eqCgATdp4uBtgJAFaeD7VMpwQAkgFkwtExBQDSf2ydPcAAAMEQZhXNfAUAaoCdJK6mAwBafJCphdoCAK9M7CE3sgYAojpopNPSBADv/Q6HxvkHACXvis64mAIA3mUhCupyCgBu0D7veYEGAB6s/sC54gwAumMbCynuCwB8OoBxYroGALIM9+9TeQIAUsUOriJPBQAkJy6pPZ8CABi9IgzKQgIAztUEhIpLAwA1M2mDtewGAE2437927AMAT6BWz5XIAgBSTdVJUTUGAOFl1L1iHQcA9V73sdq1BQClub4M1uIJAFb+XRfCJwUAH/WPK4qeDQCxYhJiM8MBAIDfeNMozAMApoyW9EEhBwANbdtraQcEAPv8L7Jx0gUAcjF/MV9NBwCBytlnVOUHAA31hjFlpQYA8S3m7IixBgBxSYQ2bcYEAJ1+VMS8rgQA/bVUc56NAABowW0LdWsCAMmsAR6IYgEApQEd822WBwAdmtydvXMJAMkBbScbBwAAXgKOkdiwAADr4p6n7lsHALhNCYQpyQMA26OVv4/YBQDfclj+Hg8AAGolGCOH2gUAYFljgeucBQBkx5N284wBAOoZO9EcbgAAUwNbnmKvCwDk6Iig8QQKAC2o7pz8DgkASqMvPIaJDQA22KihpvMHACNvFm9RrQAAGshXbfVjAgDKOEY4IjQBAFAKr/EfMwEAFm5SAwYIAwALgD1dOUQGAPzevj0guQIAVaNW5oyxBAAsGLxmND8AABPl0t4PDQMAPUe4aB6XDACV83mXzCwFAMhVgq4E6QsAOJPzRq7sBABYHDWEUGEMALMzEvIaTQEAC5yziRneAQCeb2/caSYFAMc/jLI0NAQAmcACQiGpAAAuoLmuwBkAAJLXlWnAogEARBxXsctkBgCygPo2B/8GAKVcidKgvAMAvwHMnraOCACM8y2RyLQNAA3ywot/6gUAr6/KFuUgCQAn3zhAi+oEAKRiXTy8MQAAHghMD/7ZBwAs8mcU1T4EAAnRHgzM5gEA8eja7R1jBQAC0srxCkYFAF1l0J2RtAAATMEYfWnEBwCkoruQyDECAMpCBZPgTAIAhQvz/VWhBwD5h9TlxsYJAFncSxPhSwoAMW8ycFlACQDzJHOKkkkFAAbBBv31kAAA/UMeArGrBgCgEdf6vDICADd/BDzBpQMAbaAoPE4dBAAuGu5jpzIGAE1evf9L+gYAkke6pjX9BQDonekdXrUHAM8N7G22kQQAoWTa0I5KCAC9bglF/OwNALGItJPu7Q0AjrxRGsGzBQAYcAuLa88EAKcy6sc9sQUAHhNz28KPAQDjV48fZeMHAGWpXwVWVgIA7oUMjTOPAAC9cxqZIagDAHBYj0HmOwAA8J6sjsHdAQDCjZme4EwFAHiwLqjUMAUAi7+abEVzCQCsDRAVIIkHAMv+lUDhPgMAZAl61pWtBgD7ywB+PtsIACVI+eEwNgQACUBrapXRBADgtfgt/hMCAOaREaTjXAAAdwHxU6deBgBjYwniPvwGAKxnbbk27AcAsVgHauwQBQAJIQLfh+0AABoeksFOKgAATHnP8WJhCAC4Xv7K3SQLABcyRuDVGAgAjUKSkIvnBwBnwN61Em0LAKK4JDuaJQYAnAsX9LWIAQDrXeHewIEGAEV082Xm3wQAgCcRxUPRAwBXRRV5kScFAE1CQQePnwMAPZJXs25eBABvdNtemywEAIK6hXhR7wIAUS9bMPu/BgDdEteyErEFAOLkT5d0VwMAo+OWevhKCACfswspaHkFANyuWIxOlwcAxog0CH51BwCLvOcqxgEGAHSr7MJwUwQAOhSrj7fxAgAB4SAKQ7gCAOP+iB2epAEAlk3OR7uLAwA31IS65/ABAKrCXeND3AcAGJc+J1wqCABOi7LfySsLABnb1fj0jQQAjwJsl4dMBQBQLdiB+0QAAMPZfYhlZgYAsrBqCnYpBgBsPiTH5oEEAHf8RnDjlwAAzFhnAXLvBwDZ4wepxRgHADs4a4zJuQMA3MxeJe0GAABZmiI4ZZcGAA3D+SOY9wcAuof1aPAfBABTzRsZCsAJACSeIJxvtQcAvqrMXx54CwBswDEEm0oGAOgTtaM50gQAZhAb9SOXAgDD2QTP9EIGAHqboFoJ2gQATXg9N+CkAAAZKX1bodYDANalRlCnGgQA2tPCHnWRBgDEIWerODYCAIPhrNCncQAAMUThIFI1BACBOSgqNuEAAFSWNdh8dQoAjw2xes3pCgB0F3bPm8YHAAu6h8iqLQcAYNpdrPS3AACkmAQs2r0DAGABGKpnTgcAp24Ux7zDAgBfKegE69cAAP6gbx7qpQQAYGxDXGNeBACL0dSo9I4CAMoqMqep9QYAq0TZo+vUCQDk3PMVDxAIACR4Ng5wGgYAIz2rkiKSBQDT6A5ouSoIAMXGQS8MAAEAdHFz358hAADnfRJ/chQDAB64I30n5QcAehQuGuKUBACaDeXdhYoEAPQ9STT3wQEAiWiGZNt7BADsjo8EfZoFAGukvmzXtQYAIiV4HhdBAQAffNombYAGALmaxxsd8wMAaFGfRSCfCADSPcBpuG8BAJTZDOxsVQcAClG3A5rrBQBxy5Hd0QoFAEeKtIBXqgEAd1JoPzOuAABiCbYzlxkGABFlJnwVmwYAyvGT+EBHBgCE9vsIpDoAAA33uDge+AMAEcgXXzV/CwBagTRT6HoIAI7k0t2r4wcA5UUfvuoeBgDtzTQtPq0IAP6v2X7MDwEA8m/psIwkBADiclERHDEEACVpvxzUyQQAUE8Q/BAFBQCdJG4zxQ8EAOEt+zlmOAMAeHvRcfi7BwAEgH5reV8HAKEPv1jBJwEAdLlRrsSPCgDT29K/iW4KAM5ldqAi4QwAwgU0ILHKBwB9Fp1Hgu0EAKJ5mC5CfAEAw/7IRlmKAgB3K5EuszoFAKXgn6BNtAcA9H7Qh+9UAwB12cVgIrUDANwfFzZonQcAu9RA8ZTZBwBUGFYExLYBAJJTIC3ZAgMAZPHg5LZvBAC3ZVKtlzQFAPyGE6Db6wkAO2qzDC8wCABsQuv1xe0IAD0opLyiwQMAAi+7xzA0AgDCi7Ub6qMBAGFc3mNXJgcAyvF2O10OAQBnjtpT1r8DAIoqyD6VhAUAe3CnjyheBQCBHZPDXzkFAMthE8VGWwQA0eN/it1NDQDSGcZBzM4KAJBNrGJlOgwA2L2nrKXvDAAhIfOuwMENAKF/TzG/KgAAKBWKntGRAwDHX4kT+qIGAJGl6t2OnQAAt9w2+nsXAgCP23n6vBsAAOFmNutL2AMABCKBHZIMAgDOMjs9hN0CAKvYh5NhrgQAg/tbmER+CQAhzCbGMk4NABeB8y9BlggAaSQa1kGyDgBCuuWrhVYHAC6jRFOq9gMAuxEPaIOWBgCqI/aBNUwAAKXLdVivAQcA83uxkQ2gAQCy8mHrMwkGANJNKuk/GQUAPvRQpZXZAwA9iDq5b1UDAA47YptSNQEA64Mu4rwWBwC4PrgwAT0DAKyv0LoqlQgAiRvTTvYJAwAKWVGgLpcNABjV0a3X2wAAHiPiI/gZAQDifV5u1lEEADj4cJnDAAUAo1ymgVubBwAReI/cIKwEAPoB9amJlQIASmtq0hDYBABZspYN4O0FAPMFWcnp9wQA65lSNT1ECAA47lp9fZsLAOs0L5pRkgYAeM8kSUDkDgBJFErsLpQJAC4wgVe8SwcATOyBuzUxBwA8SGEbZ+8HACnXzBRGJgcAOOaSrZMZAwCSSSOuGVMEALVP0kedIQIA9mywiETwBAASSnKeqjoFAJzvFFOmoAIAJ3kcPM0aDgDleYe3RosFAPJ6vqyaNgsA03QwdLAJBQCh3rY53FUIAMIn+fd/kwcAtqXGFPrCAAB80G3bvVYFAAjRecGs9gYAwkeGIW7PBAC2W43CfCIBACN29b/pjgcAOokfJLKMAgByZzweVFsCAKIKcQejIQEAyYN0xz5xCQDK+tVyBfcGAIH/Ik7zXgoAhxEUT5RNDQDSzqaUuycFAJdKA59eXQMAm7yFlwYmAQDwT4XHTkcFAMpIowKjlgIADqTHdvwzAwAuSFuZKpkFAMcqAAfHjQcAQRfQlGOTBQAX7xoopPsEAHoKsmmQuAYAZNvHtYz6CgAPqCqY5hgPABoaGviVngsA+mxk85TnBQA5doowPUcIAA0icGJBoAIAJdBpiyRfBwAnamUWvMsBAChn4tb/uQUAPqc6EMI7AgAFnlgDJnkGAF1ZkpjbSAIACC2tPKUGAABzuvdQAQ0CAEPg/Tv3AgEAmhxRteDaDABV1OD/fyUFAIAh69EIQQ0A+a6bD8yWCADppF1yvfYDAMZFV3+ruQAAYx3S+PDKBQAr6gikvt4HABZtiZPbngAAwKVe0pdlAwCsWGAQe40FAGnuC9L4zQMAXgFlt0wKAADJfHwzMmgDAA2mncHstwcAiPp8p1FKBgC1Dcpw9JwKANiYCG4LtgQAx+b/3QRdBQBcv2HG7TsIAA1pXGk8NwIAGM8NUsjABAC5lHRLr4QDACUioo5KqwQAQxdg11ojBAD1dYkHDcsAAEsMUz4xkgIACaUkkbuNAwDxEVpl0FADAAbfDCvO5wAA5nBL2d/+BgDUv0WXPzgKAADDxCeuvgQAPz9qQaRaBwDOrjhhJRUOAKOFjMQ6ZAQAkrg1J4yHBgB32PQjNaUDAJ3ui+0EpQMARvvYpeBmBgANy3BITvYDAFdlbbFIFQYA85Y1d2GiBwA6XSdfTXIHAE1RDYG88AcAjRNyc62dDAB0ENPl3kUHAOLbf16lsQcAoW4Xj5i6BQBa7N0HqdMJAG8T9CakawAAILcGBvzKAwDanDWi8BgFAKfsb+Tl+gUA7Y7P2/jRAADcgdA+MZMGAEIXkGajsAUAfsqkLIcMBAABngCUgPEGAL8xSrQRAAAAXKcKamkfBgDKQq1XCosLAMj9Brea5QkAzL9u1AgTCABQKC2KmD0GAAxsxj9soAcA+0e6wbrJAQCOA3XFNTkCABOcxXG98AMANegW2UisAwAuI72vUwcCAAJg0B67HwcAOq+kR66cAwDC2TQLfDMAAIo2slKtPwMA6M8ixNDIBAClcVkntGAHAD2tHLyV2gsAdXNb/1HxCACmkMtcNcwDABYe5MXGSQYAgKrm7mcGBgCQ4SsYnRcEAHlpflbZUwYAbSWaQg9sAQAxkT6QQ5QGADbd+cZKbwEAU5LiEknqAgBd0mg+ZLQCAOe6JvTqMQYA6A1wo7l1AQD7SKoAX3wHABcDyoV3kQsAmJPHsqlaCAD3ZfbH8jEEAJ/+ZtoQBAEAfda03IJNAgAtdRcO/uYDAI+wyx7e2gQAkeqxSJZZBQAZe4+FRGMCAMBaKUo99AUA1KxSXKdCAgAQDSKARJMFAFMS+RVHsAcAxrrmxIDCBgBudmGzo60LAE47XBLlLwQAIqxKTdgRCQDdfKXPCo0EAEOu9qwovQUAfZBWj6tvAQDy1RgSsawHANu0IyDgHwQAZS9cvzebBQBx5qt95CYHAMH2RudF7AIAhkbHUw5YBgB0P2cEoe0FANM2Exk0YgEAQIbzH9acCQCoG7TExmAIAG42pwz3XAcAHgFs8agYAQC5A6IHV6IEAPZ/JvbemQQAPHcIgYVuBwApy93FypMGAPSfCtARAwAABV3N/v3NAgBq7fZTimYHAFYlFC66AwMACQnBhAWIAwAdJgoAIP4EAORI0pYYcgUAO9rQoZFQDQAKBcHHv/YEAL6pLs1OTg4Ab76L8rF+CAACS/xakzwIAK4bGP0XVQYAbYF2LHflAwCKiUCWGBkAAJl03oQq7QEAwWNP1+14BQA9DCtJxnYCAC6Tv0D8mwAACzMf8eiIBQBuwk1pbtEDAIwokLUq7AMAuNEyrgk6AQDktFq4HugLAB6uPKSseggAc2NS1wUvBgC6rcZmv+EIALl72OR70gAANLRdIydsBQA3LaYObi4HADnobtBMZwUA/ACiJVzdAgB+iCx56dUDAFW8q01yGQMAAAhoeHy5AgDd5jTd368HAIiuNYtUMAcANOPWoUsJAwALMOOnJuEGAMX7/K7AiQgAgmWDH6HuCgCDh30nooUFAO64qMujUQUAhtjiK0K2AwC8iZZB4TAGAFWppwc7ZQQA2xG0QzQEAwBiidQzgl8CADH0rwSPvQYAEmOa/Qf5BACb0jfH0w8EAPkOlXhiZQcAis+G6qNzCAAtnPur4uAGAO4z6jgqDgYAGP7zKSQLCwA+YUtIv4sKAMDIH9VZzwMAGEfe1qCgBwBLt28+OlwFANVPiF8TUwMAhBuMChb0AwB8bBNvXC8BAEzeN6Lb/gAARKu/zrx5BwAJaU0/qa4DAI8YWLOc5wEAboHg9dhTCQD8Ltu7M4UIADCUEpaXFAkAQoYWNm56CQAendNSq3gMAPHj9+7DNgQAJgAfwtP/BwCpLQrye+cDAN5yhPy/GAQAs6OzUXldBgBZ0VKS06QGANTsAFnjkAcAhneXvyUHAwBToDUWXAoBABKiEaSHbQEAcAVO1eLVBAB0Xz+z1+UCAL9+iD/epQsAtjlhvSTvBgCmpXe1kPkJABViBkJafgUAdzaYRIuhAQCPbx7eUuYDAOvYLuArUwYAOF8WyIePAgDW9+gbrU4EAGb0MU+ddQUAQ3n0SYE3AAApTyvjO58GANY0Ff6CWAQA5G88lCmZBAAVW1RycDQMAMTn185rIgsA3ontTBM6CABeQM5D+NwHANaDeXVdNAEAzcw0QvUiAgC024o9SngBAMwrjO6+bgMAb2KPW/6IBgDAMkdKSNYAAJItU8ZKuQcAD4VUhxt3BQDIYRTf2Y0EAHEy54eWcwYAwBoMyJ3MBQDN1IYUZ4MGAHOBXhpfbwcASt/59dPVDgDm12iPC9oHAKZ1VjgUIAAA7x09tV8VBgB8kokuo34DAC6o9WimWQAA3NShqxVhBAB22rXDUxkHAIF60zMiZAYAvbF2gGXJAgD/EDDmgaUFAHQ26If4pQUAuUOmoNMoBgDSkwxk2BwIACsP18qwtwgAvUSBqU2GCwAbXS2uNz4EABE9oXDPAQMA7JEYuqGmAgDgOj/7kfICAFLqS4F7GgIA0URuZZtmAwAz4abtBj8GAA8HWCc0MwIAdcCcReCYAAAbfGytXt8EAF791GweogYA0LKZZhIpCQDnPWCiEe4IACBMx/XCCgYACGgZKhmbBQDoAXCwcVMMAF/mRjAKFwYAOJ6kRhpABQCoxGFV3QoCAEae3u20qwcAXxkan7+GBQALefhejQgDANu0/CYhjAMAw+NJ4bqFBgAw6aQB1rwAAFIOeQP76gAAHa51D16ACAAnCoZZzGQMAO4LsLflSAoAdI/vdZbZBQA1VEw040oEAC8ESDfBVQUAwDJCdUHQBAAHaYYwtCEFADmc+0COMAMALKB1xqwJAwDuQ6W7uYkCAJ5TKC5ZqwMAOtjNq4JNBgAn43LBjscDAEb5tyFSLQYAKXr3OibUBQCwroki3T8KAOu5fvdk3AcALEA4g9IbCAAhOTilKU8JAG2T0BicKQQASYpBg0GRBQDVriHHGCoFAG2XgrpRsQIAVMdL3u/ABQD117Il3H4BAO4bCKY2cwMAw+WHiDG1BwDhWxpJbZ8EAOC+x2Uj5wUAPrMILwY5CwCxz1fm87sEAGdZbvX3eg4Ajtaef9bbDAAzt1xVIAsHAH8hcUUH/AMA62orm9KgAwCd5d3MeGQAAPrdGwVNXgUATnvEBBF/BwBMLBFVxRMBAMq3+QNRUwcACCGaHe1AAQCvwjszIiUAAGSg9JhD4wAAKBlLPgkLAwASA8h+fs4JAIOP97115QwAOO0LGXofDgB4o2ztrfgGAOi9zj7ZIgUAz/bgRfAkAAChzyY0tm0BANgP0x86uQEAYqNoU0DlBQCasrf9PRIAAGg8UlZDNAQAX+4heVKaBwB+gT7L/EsHAD2N7HLegAcAcif0APPqBwDjTDWIUUUNAKvLPUrK3AQAy+u/0BTTCwBXK9Nq/N4BALznmghFhQIAXMGg6Y/jAQB7N+LgRiABAIWoClYccgYAKBlnvyjrAACnlVHvGr4DAOu1vWIv8gYASTBSuGiXAwC9/fvIlDMEANKNvwHSZwQAlud6Vr30BgCDtxeTyFoGADKJ/SA7fQgAFWkyCPIACACDo1tanO8KAK1P73SakQYAv1IUYdSeBQDvCeoE7JEGAITpACfLywMAPLr1xEMcBwDNdJ769m0FAN9Wz+SVnAcA4gnGO2S+BwB46NkqwUkBAF8MOcpYpwUAgdxhHYuRCACb0QwmUNMIANi0N06rogcA1xRUc+ofAgCdY38COKcIAJUkRtkQJwcAVnQAqq9aAgAbo+ooH9ICANBfAOpxdgEAtz5LJK7bAgDM4f9XL0oHAAFzCHMwvAEANJwB9FfsBwAkpR8uCE4DAGoSNaaMaQIADtk9Xi9wBQDHxXBKmhwDACT8eKqlNgkAAHufOy+ZCQCir8SwBMADAHi6sDKIMQUA7Hzxn0vyBgDHYOAwf6QAANDIDVSEgwUArpzE3EP7AQAruPQGrEYBAFVzntgAtQQAEopyHB41AwDjL5NpnwsBAP3RHNA/tAYA8w52PlhCDwC3FjJXwT0HAEpx1/1IrgQAA+ETil/4BAAN/9ayIDQHAETFl0ZLXQcA9Pj3/+EbAQDh91do4RkBANX1XDQUigMAL7UFcY2mBQAGHoWey/YEAOWVGEfEeAIA5GQ9zs3vBwBMS1xFbU8GAEuj/jJW2wMAwiWYgrGQCQDIJTJR0+cIAK2rt+MrwQkApZweeHeHBQDyXUnql5ENANjZXfcr7gYAjb406yzHBgDHXjTMyXkGAKSYaPmNiQcAdZ30rSFDAACuWuXkGWABAJwgXfLFTwcADe2dk2pWBAC34BbnY2AGAHBNH9yvXgQA2rHMzyRGBgDBtnKAq1cKAAlvZyUHEggA7Y5O0BigDABs1aXuPPcLACvXRYCFAQQAMC3K4OVZBADqizAZt4gEALUyGw1KbwUALTaAvO6lBQDGjU4K0b8HAPQ2ZzaZyAcAAVz56rteBQCKP5BgsG0EACFmEolYYAIAL+V2xjyOCQCPqZXZeWAKALEIeSF8SggAWWXmA3bcAQBEJAuh394IAAT/YIOmBAcAPovePMzOAwD/ZA9H1RwCAIk5lY3BqwYAFebkwtBKBQAqUiu41WcDAMd9Pbj00wAAjcXbTH8GAwA3eWnaUgQCAKl3qivLLgYAdCi2rzYoBwBAspQgPK8AAHo1fymFwggA4taAVi3MBwBjVgfVExkGAD0rFWFSeQUAvTz6utuhBwDViCXFMa0FAFxoZEE6XwQAbZaakZ/lAgDaMTIaNi0GALgBTgCEUgYAYB3pO1NWBgCfqABsAa4GAAUcEyq83QMAFLuWJ6JXCgB0PkT7YPMGAOrqIHLkgAYAGAzxpfL8CgAfg42zf+4FAEvFXs75DwQAW7Nh4oVxBQCpcA5UVOIDAPjjA0CBtQEAS8BKMWiJBwCOakRBy/0FAHEq/yZpKAUA9rOW4jHyAACTRshXo4QGAKC8yTMGHQYA33P8+LwoCwCzlf8G3rQLAKQRuiekCgsAm23avzHuBQBngN/COrIFAGYl2/81SQQAbmwXbQEvAQCu9RYPsPsEACpAmY23+gMA7XqE/WXpBgB7UoDuU7kCAFqzsc1bXwUAZjyiPws6BAAKgos4B24HAF3ZnbubmwcAYXOfjq59CQAy2gJh9xkHAIvKgCp8EQ0ANQldtmYaDADKrGAUgboJAMImMWpAVQMAdn1yGBkNBQAOjkkL6uUGAPIUMga2owAA0p+MFV8GBQBUmUIM+2kBABDu7NntmgUAAhiF6xaZAwA4xVxVF3kFAE+K5TkfmAMAy2/mbaXfBQAIWQcJiAUIAJNKhcvY0wYA47Fw6fSyBQDBy+1SRA8LAJMKI1l1igMAH6OL3hwsBQA9WnTU8qQCAIqi1EKdfgAAzVpwg8CNAwBAl3XFgicFAK2Q2ZczPwUAFU3oxzmpAwDgOX4ixDQCAPKTpaHZMgYAlIQM7RH9CQDgVyftsyEIAMXBj+UdPgcAqxZGyBDRBQBkryjfp6ULAKbLB7gVawMA1/4anor3AwAfj2AsnKUAALeBy47dKwUA1H6ESE+yAADH6htRvtQCAJtbntmkvQYAAU6Rlml+AQCAz3/O8LEHAIFUR3TPTwMAharPeKsdAwC3VF5uIeMEAIm2czmCSQoAhIjkhElYCgA2+0IwmhEIAMpnl3hM4AcAMrjPKBtnAQA3xeGifuUHAEFBRO+q+wEApt9kwb3TAwB9F8LonNgCAPQsGLoSzQYAl3aawYoKAgDZcsyy+jkFACDeHo8IbAUA747zJKxfCwACq5dhXNcHAKcvpMJLPgsARIG0EM3HCQCPNUjqtzgIABduqBARPQUAbUZftm5BBgAgzl8jphwEABK7mYr8wwUACJG5xnSWAAD4bzGZIfgGAOnzqfFUXQAASie90MW8AwCt1dK4hLIFAJ6WJRDj5QYAD2IGYw77BABg5keX9TAJABnU7I+GQQgAxTuSjF4QAwA4GD3UigULAPuT5Yf1YgQALTbOp0vZAwC3Zya1+TADAArw4Eha1AUAjZp4FFGPAADQY3bl/Q8EAEcGwtRFFAcAfA8XaD5lAgDWXsXj3kwGAD3+TvpJZQIAbmY/r0mFBgBou9RBKZ4AADz/XR8x6AIA0vsf+Z5CDgDiLBP+DaEDANb5ax5GWgUAgy6w9O6OBwDPFoxkT9MBADJRuirqfwAAHkDGHW6SAQCgzhfqik4HAA+8P/hDxwAAVVS/xAPLBwCYfpGpi4oGAOVh2AEd+gEAq5Tf0QCsDAAaJ70BIboDAK/EuYiJVw8AfZ/0ib/yCACf6Y7Rzj8HADKYWX2UVQAAkBmkKv5GAwBbGXmATBYAACe6e/vMmQcAXKfGO1ZzBwCznBNjCOkBANag2Qe0+AQAaU+SyiSOBQBWZOe7RqIHAGS4Abcm9AEAPyWhkcg1BgAv3o7T62oCAAWu3frIbQYAhjegQX0cCgB9+rOxa7cIAAEckUFMJgEA+b2ERfQCBwDejsYfUTwEAPk17TosSAAAG9NxUq/hBACbk5J/+cEAABfBbZWIegEAx535XgDuBgDMMbJykaoEACp362HdtgcAx9IBq/mrCADlCmOHAogDANvtWwTKLgsAzzJfNkN/DQD1v1m2qT8FAJI981DowQUA9fa5mhHsAQDpY+Ztb/EHAMbeFsvWpwcA0vHqvOkDBwBVVIiU6cgEAIKtnNq1zAQAdekQxmtZAwBen9sNDKgHAGFMXD7ZmAMA8uPn0mB8BwBwOHZREAYEAKrS7ODEewYAuXMTH5S7AgAwLADJyZkGAPNI4jNn0QMAieNL4bfiAABKePbaDSwEAFB4xh/qiQUAkfHdtQk7BQDM8UZZI6cGAGC+L7ucuQYAYlxI1qXTBgDAI+lmlIMEAN38xjCvHAUAtFSsGJr5CgBu7mGWo5gLAOLNQB4zhAMAphnexBXNBACOnxic4ioJAArgdHZCpwMAwXR+Ty8UBgAVOowxk8wEAOceK6wb1QYAPziSokpQBQDPAQ0fy8AGADPV9Z5GhwEAv0c3iDhxAgDokDrlKvUCALqOlf4U/QUAjsuTv17+CgCH58uK2iYCAKF++6KDCAEARM9CeHCUCABccmD5c90HACyrRSjfLQQAu3Yy/U8hBgBGUhoYjQsAACDredWmaAIAR4blJv+TAAApmAVo/iQFACG2fOR1WwYAGczVpbBeAQBanZKzCVIAAEdryMub9QIA7sKRtmDVCQAHzuP8uvUHAGyAFBZWzQwAh7FwYYtYDACBENDjVaoKAF8TF5lCfQQAcPB6oM/qAwBEbrRGq94BAN9spDs/pQcAGuXiQotFBQBPRAcM5pIBAKodokOIrgUAOBULkSHXBgB+QaaVGjIDAGinqASQPgEAbIc7GckABgBldw2KGxwKAKGOs3+SeQsAGuDbeXYNBwDpjYlAYPQNANvOL4NFiAUAc24Mf801AQBb4+jf+z8FAFvlBl4ZLwIAzkuB6Dc5BwCN9HspFnEDACCXBg2eWgQA7ESnGvdaAgCjq4rL8BoEAF4diU6KzwIAomvQF35IBQCWZS0DKocLAN9Ik8AoXgYAwkDOsmt7CgBpHYny96YHAGcPEQeH/QMAsi2pFodvAgAnMHUbqs0BAGEmtVi+BAUAUoLl1psEAgBJ75pqjf0BAKFvIbdnywcAgrnDU/96BgAoltoQpg4CAFlU/K0aAQYAffjLAsjQBgB7TFXtv0EJAGJC72e22wYA3H6FJjGPBQBAk3eL4ZwOADz4lc9tkgcA7CsOEiUuBAAV+vFt6T0GAMz581Br8AQAL7awwVz8BgDLeZiyKFUHAD1aEtKPmgcAuGp0S418AgAMIQI/ifgAABBXrrOWVQEAyiRRfhYxBwA/4bvoOHsJAFWQL5Rb1QsAPpG+lRScCABs+xokTqoDAKJ5kT/SOQcAxOi52/oyBgBIDP4rUsgHAKla74MJ7QYA9LWHdiPSAAD1BTMqvzgBAJhl2CRd9AEA/mAhrUsnBQAq0VgdBLYBAHpo5KbKLwMA38yHJ3OkBwBABn98Qh4JAGOMXzhZNggA+mt22er0BQAAJmwz9kYHAPWafcWNbgUAeE++F76zBQBLL/iMkr8DABFvCmBVLgUA1uvvnH5iBAAcl2yrRfMCAOnnY24oUwYArSOKt2EQBQABRbWsmUkBAGbtB3CRtAcAyqJT3SgbDACF6odf6HsDAEFeqNLjSwcApmzJ+oe+CQDMCP4gNtAJAGSwhKtc+wUAsIWCdz5RAgBD4CUxOFcEAD0ibrWjvQYAT4RvN7oiAQBU5bSizTICAED4D6MrQgAA9UN7ZudRBwA+X9pVFyYGAI62Ur9wLAAA4XKNRb8yDQCbtZbnlg8MAKKdb533LgIAd8q+Z6sBBQBD6z9+abAGALsvC11L7AcAUFRZEOkAAgBecQVxBUIHAGAPUyJw8AIA7wmk8DRjAgDAo2LfSvAAANm2i7Tt4AUAA8D7pErDBwAkrFxOTtcHALJBNPQ3zAEApq7OyfFWBgDsWq2sHAMHAFdscdCMMAEAQhmUcxMcDACV8XL3RqMLAE8yx1xaVgcAEUok1aAcAAATh0FnsBYBAK7tVYx9pQAAAzgQnIDGBgDIatriElEFAFq6PQo9NgYADPSmi8kZAwDHbqMDS+gCAHzv9rkRWQAA3OouUfOsCQBoKmk5mGMKAAYFgzSiaQYA1AMGDJKLBgCyZByd71UNALsO3/WDmQMAJpiViSXqAQDWzQOHY84GAAWFiXgWMQYAcKKaz86zBgAIvXM7unAHANSG4fd1FAEAvCuJyRslAABazP+bq04CABc4E970dQYACrPaO9n2BwAl1L+lrPMBAGCXHBxS+gIAzfknzoAhBgDTLIgLRQ8OAPyCF2sDUgQAxYF2sJUtAACyBZL5HJAFALTsXm5okAIATBZw35k9AQDKwOUhw14DAClA9DfjOgEApy0/gY4ABAA6DI4vJ0AGANpe5eltwAEAqmlt/0ArBQD6fzcJiBsLACtM0VxiNgUA0RcuJa8WBQAr0+f4loAHAOLEPqPWegcAIdMR3MUXBwDkI5hVFKEEALHioVDOBgMA28L+oTjPBADnXPoNZaoCABWU8agWSQUAeBLnb8kNAAC4PuaEJ18FAJFgotPKcwMAmrvdifuoBgA3ftnVNYwHALIs73Q2bgYAj91TrEdDAwAqEaXtRxUKAHz1yYJNYwQAUtamaJIkBAD3L39obTMGAKDZJk5P/gQAQVSUPQ8EAADThln9OekFAN+bAUchKgEAspzQ52bEBADdA9KVW/oGAFSiNKNQNQYANntUckVYAgB3ExyBWFwHABsXzDfG0wwA4jR9dDA9AwDXp/q6kpoLADfPabXt1gcAoCzcpZQBBgCmEF50Wa8FAHVIAD71qAcAeK99LKbuAwBOJ5PmE8cEAKSzbnob7QYAFY59ac4qBgB1sCopuGYCAJxcZqA2hAYAaRAg6BfTBgDKoyxdgZAIAKCZFOvxPwgAGONQ8GA5CgAQFslpNjcNACc/LyDoNQIAgBe2Lp9MBAADcB1bkDAGANHqdNLI/AQAeKtof257AQBXUg6aqxQAAKWLf1Y5mQAAgjxCKnu0BAAtxHrl14gGAIePZ1pLywEA1AegomKqDABtLfY4Dh4GAIJHzI+ILwgA/xvygytWBwD2LtjSD9wKAGz8SjlrwAQAzDb2SxuTBAB4IzLQYCsHACWLgcYnUQIAQ+eNp7wwAwBOdBkRhP8GAAWT5OhgxQIAeqXl708lBwDfp2DF4noGAPFps+EbwwMAckLL+ZO8CAAsGHPb+fgDAMThuuo1sgoAGVUph7/dAgDV55cQ7BwEAO6KlAhNhgQAHvaNQzfSBQBncB9ghbICAFPX5rq8XQIALSY0EbYwAwCKgG2i1xkGAPK+rcKzwwMAUn/snnyHBgBttuHrub4DAIfykc1EawIAgwNzYpPyBwA2nEVRef0HAOdJLVFMUAcAX8U7fu2HCAAlx0kBsd4HAHV0OI9HSAAAPopn2ZeTBgDzdslWgXwGAGwiiVVN6wIACsHB5gnHAgB67maHaq8CAGzZoXmqigAAsC+b1ZIvBAAHnABALHUBAM5i/+lojgAA+fK4CtUJDQDk5Xskq7gJAIXksuay2Q0AOBOaR6X6DABwj3O9E8sEAK0wwUsKUAUAlYaTeqEnAQBt4zT6JioAACjMHi7RhAUAo+t++PPxAgBKthXldYwEAPAeB1JpWwcABlSWQm3UBQCfn5gGYXQHAOIKPDUemgEAvb2W1c1yCQCDFojfHXMIABSBT9YmBAkA2aOp2E8aBwBqJpA5vTYHAMMF+rpgdQQAoy/Mq9wYBACChs/OkVkDAGCMS6lxQwIAwyAcsUYVBAC0szSTUC0DAKpwriwQbAEARfQb1Q1yAQAhmK8vZq4FAPqHK1opEgQAs+qT4mFSDQDLZZt1JmQIAEdqEa5lAgQAvOW6BCPABgCtldG4C3YIAOnWfvWImwEAOaMEGb/NBAAsT07NSSsEANkJGXcuGgcA0lK7PhVOAQCKgebNFxoGACeIEDStPQUAtlVcxTIrAwCjR5NfFvkCAKwzvOlLswYAwPJxZWVpDAA+Qm/OYaoIAKAnG9dA+QsAadFznfGFCQDc5mJ7nBsIALLAeDpkLwcAe55PwEXeAwBc+jCN1gYHACQvjj72lgYALZLwGCwBAgApncha5VUDAAFx7BS06AMAkAxSfLCdAwDh73ebHvQGALrkhLf1igAASyzMidIUCwBNvPHiUDQKAPOSLzmTzQgAfGuUagw3CQCX/VodPEIGADMlH4jcmQQABsV2ZPJOAwCXFHTSB9EEALP9br3ERgMAoWMR13krAwBqs/zt2fgFAJA5v9zo5gEACvOKNE+XBwB8nPFOcuYGAOITvO+lgAQADCLOQuRMCQDLFiWngIkJAHZmuA34cggAbVLaHzMDBwDIkXbUMUsKAHEgYgEL5wEAaqH4tWPxAQAX1Bo0r2oFAPcw2DWWmAcAe8sAdqJ6BADD+BXA7R4EAEqF7yeNzwcA+ZNGWOOJAgCnCbNXeEoAANpN0YW1RQUA4SGz49DkBABArNLjH0UHAI2p7nj2ZgYArf5nhoU4CACMTObDLdIEAA861KBeJwcA98zXfROBBgA4mre6nOcBAGqmiUQhKgIApSsznC/2AAA5XzvWiWUEAJY/7Hn56gcAqLlyFejrBABKaWFdfxsCAHFjowH6wAEAPWqTjA4rCAAgzbZYO7gGAIAm59PYfgMAYiqf2zegCAC70rEZVAAMAP89lCK2BAYAWBp09pnIAQD7MvLiGQIGAMv5p5KuXwMAyrHzFDb6AADwgr65vf4DAAAUkpVI5wUABieCOOpTBQCMyM8kfKEFAAr0rhii+wEAlAF7PgRXBgDn6e9VG8EFAPt0oMZ7cwcAzFXjHOTqCAB19z/RNcUGAD71yPpIlAQAajXoxnRPAwCi2wcGeK0AALY+tn46IQcAhoyqrOOSAwCvNYo+6TQFAJfJAv0QiwAABR64rMJqAgB5O86YjJ0AAKxQTf4XXgIApyHxdvV/BwArcvyw+eUMAMcoDZuUbwQAJu8XXebNDACXlvgoqLsGAHb2BB7XmwAARaHyQchaAgBxOIKsfqQBABpYbMOoqAEA+6lCFHVVAgABOf6QZrwBAFq8Wi8TFAMAKNUyUYMRBgBXirSOS/IFALf29wTVWQUA/WbS9ueRCACIcwPvYGADAIYSHeyIhwkAr45HHESHAgC9VDNq6iMBANVU67N4gwMA7pSPp6rUBABNp3XoAqAEAHyxZxOFCwEA4wdYLbEaAACWLeNBkBgFADECCSsGWwAAj7fnZhfJAADsOKFVD6oAAIqRLB6WowQAHj8j80TWBwBkwAKen8YJAJdoJuXlagMAeYvT2sGPCABAvdnqzooGAKC75vjgOwQAO05h/N+PBgDgO1urHekEAPAvIcnUsQMA27E/zmvNAgAQwtfzDskEABaHgaD1lgQAuDnCjPicBwDb+GwwnMsCAI9QWw12lQUAkCcC/evLAgAFEewqgrgIAMu8JtLP0QwAvXFJ+rIVBQAVRfVdLMsCAJdjqgThvwEAJWyZ/5QUAQAAWD5iUUIGAL5E4MWf1AAAKcvtQ/oJBwDKKv1jjF0CAGH93ynNxQQABa9I68AuAwB8t/mRk48BAIEMz54CDwcAubAQXqqvCgBMJVWD4B0GAI3C431Y6wgA1Lt9n7vwBAC9dCpayk4EADM+7S6zBwMAwug8sIp0BgC8ELiaDXwFAIzpJKJkLAQAFMOm2NW3AABD1ZV7MkgEALqk44FmFAAADE7DrRSHAwAwjikOb/IEAN7HEkUicgIA/HWpQoq7CwDuF2u01fIGAOVwMSKptgcA5rfjP3FTCADBa3/9NZcBAC40xUmvkgQAVwNa31w2AgBgu/+nOCEDAP5GRtH3oQIAzESK8V0bAQBmQshC0JADAHXcjyrj7wEAOBKu516SBgAy6NCBkq8EAPgdGRH5/gAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogcBUSAC0AAACdFRIADAAAAKkVEgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc8QVEgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAAAWEgBJAAAAEgAAAA0AAAAAAAAAsKAOSicbBgCdGI/8pdUAAGAMvZxe7wcAnkyAppWFBwAd/ARIMrgCAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTIuMC4wL3NyYy9iYWNrZW5kL3NlcmlhbC91NjQvZmllbGQucnMAiBYSAHMAAABMAQAAEQAAAIgWEgBzAAAATQEAABEAAACIFhIAcwAAAE4BAAARAAAAiBYSAHMAAABPAQAAEQAAAIgWEgBzAAAAUAEAABEAAACIFhIAcwAAAFEBAAARAAAAiBYSAHMAAABSAQAAEQAAAIgWEgBzAAAAUwEAABEAAAAAAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAHGOopopnBgBls9iIN+oFAHlCmdbWGwoA4uQZWeesBwDXrTjTnksLAGSAnQN+IQYAbX4zCKTeBgAGgmISwXoFAHME42XLRwYAya0fpQWcBAAbr0WQv+gEANbgRTrjFAUAD/6LWzxTBwDJFH57VYMFAAiwISAXPAcA3iqAioQADwD25cQFRuAJAPpnlxvQwAUAizhCn4jXBwDYRiWuWicEAEhDhkkCWwcAKyZwEOEuBQDNWvtUrjcCALWqOtDRvwMAXJ0CmLWKAQDpiWD9xSwDAAWblFxQJgQA0noMiBhqBADazIgYIqQEAN9TK1Jl3AMAbX8AoiLCCADtd9ubt1YLAM0S/h7oHgQAfQkHvakgCQBuNOx+/TQCAJO/fzI7AQcADWrt7W4zAQCv87uiZbUCAFUZWYnOUwIAAnbRgngmAAB4oy5zGaEAAGwqjrrxOwYAmt+QzJSfBgBI/Jt30TEEAJeg2m+6lwQAoOrPEwPMBgCZpI2EE6MJAAkjGUJTywcAYP3e3paVAwDeEn+RIh4GAAvPjEaGzQMAgcAaIlOFBABuCk5LRskGAAMEGIS6XwcABY0h1Fw7BAAWtdCbL3YCALPL3fvnxgEAveKswwlZBwDJPi2XASEEAE2uEBLWEQUAbp0Ole92BgBY8ongGrgJAIIYlSJJPAYANzKbTdXxCgCE202SJdMOAIfeIERIhgMAAoG2XbLWAgDAcyiWtFAGAJQTJ/0cCAQAgiT+5n8aBwBUyMiluIIBAI5tQOXLPwcAUfTPMDTeBQBBjKxnuVQFAO5ZZUtsdAQAK5rGbTx7BwBu+sI+8e0EAMjqe9da6AwA2XuOsqLbBwDpT+MdpckFAEcRdGTIRgUAkCYJmd+hAwC71vTJjMoBAAM7zcl/awMAXtuXNGYZAgBnDvF5z/EAAKJ+KwrLPAQAanf/34lQAACIi9PhhN0BACIIxgNFgAQAtH+jLNCeDACDeJW1wnQEAINmgY44uAUA5Gu3VMS2DAAFZVGKOVMNAHXRNjrSIQAAbUfGczP9BAAq0O4eKQ4CABByLs8uLwYA5I2FmOBxBwDfHkV40vUCAEJzmTOxMAcAdWnrIFSWBgDPFqW/owgDAFr/aB3tpQUAgw4V/ioSDQAxArtmya8EAGiCPIN4xAEAjxT8wzl4CQD4i32Jy0oEAFlzUljF4AUAXNevc1s5AwBwueSkr3IAAG0PnjIUIgYA/f41AbYZAACDSxNeFGgAAMzDggmG5AEAmdcTX/toAAB+VEQ3KMkHANJq3p/EUAEAJRFHCZXyAwDPMcq07ikHALy/dbUinAYAEuK8VwiRDACYu3WgtbIOAGio3Jw8hgEACRdaKQ53AwAT/SA3WtgAAAarcR//4AUAX+CRd22KBwB2uaBHS3AHABerGumCrgIAzQaYQtYLBQDq2I8VVYAGAFWtxP/HJQcAspnP0RVnAgCInKZBVCAKAFNLzX1CSAQAxb2K6JHRCQAey3eSzJQHAMCY0Bz3KwAAMNJszKudBACyBfkzZQoEAKS4LqzvcwUAX4VfYlTNBABTUKzCJsQGAF4JS85epgUAtmvyhkDEAACFeBlolUIHAMj8tleDAAcA7j53OCdnCABwYZ95v1IHACMz49qmtAYA3NHqlka1BwDQGoXp924IADRKWIK7nwMAA3olj1Z6BACRrR4JiE0BACTOsRhbFAIAbZ1mo5I6AQDlfVfAHHcDAFKZi7sGygMAkAPVxYELAADsgAc0EjUEAK+i+N2WwgMAE6cU2fkVBQDVVSL/kTEHAO+9pMJcTw0AzosR/FfdAwDHkDQ5nakHAEElH7suTQMAnf8jtxXoAABDVOIWtIYCAOi+0Tj+vQAAd3QAx5KoAADoo702JO0CAOqR8gD9KgAAIaPegXO+AACTsbLUUukDAC8wKC12hgIAElvjPAk2CADO6VJ1TbYLAF+EC/7gHgcA5WnJYAadBgDZqUagHS8LAL31Ls4rjgUAim+M9+iMBgCyYZLjJu4GAJ3PC6UKPQMAF289Km9oBwBqfFltphIFAFF1pXCaYAAATEY8isAmAADhOe7IH1MEANKail8wYQUAvq6S7I2XDAAAonyurWkIAFQPKSPpHgkAa5GNiUGWBgDUNT7FrgoIANXAsOcozAIA5GyK62B7BwCmd8KFKQQEAOvTRntlNgYAfMXyrqEwAACq0joAc/cBAHYPwSxkBQAApvws+Eg7AAApQ+4QPEACAGVAwsHpCwIApnOWJNiHAwAqfJLcqL4NAO8OZdWOvQUA4UDNPw7vCACr8GEzq1AHAGBeAuJK5AAAHAQnl3v5BQDs7MByNGgFAHzOsS6IiAEAfgZFxWSXBgA3EPiigzICANEjfvmvdwQAaLu8jZW4AADWreiXWyAAAHVw+7OWTwUAZpJmKQTyBQD1QUmur48IAId268SDXQkARUHKnjfPCQB0u1Kc/tcLAM0esRbGrwUA7yKP7EqfAwAu2SUWnrMDAHOIUNRb+AUAXej7OWiOBwBrhbg39y0DAAZO8UKDYAAAdUHXiXiWAwBQpfsHGSEBAIgANY8mDwcAR1+AsYNFBgDQLIOvGywKABbX1BvAMgkAjlunw/TsBACIrc9F08AHAFXz3HAgEQQAZOQinP/cBwAlM+Bg2koFAJp2747ZXAIAjJsDbOUEBACKM3iMSx8HACMrvBb8LAYAqtmAEvV8AQBaqSBerrsDAOyqYkd1DQIARbc7x2/DBwDRS3OXx6YEAA6Vs4ok7wgAxz6lyVQxDgDtPG/k8bgKAEP1uTWx/gQArpOtktE7BgD3zRKmLk4EAKuDFZn0cAYAtJCH2oqLAwBd+VHfnEoAALiW1ftj2QUASuWsaJstAgCZxTaIjqkEAKHrLLOuSQAAMXn8dQt9CABJdbrkTG8BAEm+P8DkrAUAnBUqwQ5+CgBmD1MX7pUHAH7+3GM8fQYA7hrIrfASAQBlcYJM8D0FAPAwtDNb/gIAYo0MXmYcBQCBvexSClsCAKnk/JUG3AUAfQR1xSi5AwDlhiZR8zsCAFTcSb8ZzQYAhsOvZSFhBgD/A2KjGhcBAKqoIKguZAoADz8xe7vzCQDjKXQ6G+AFAKOcF1KQYQcA0K/wk2XBAAAodFx5xGUCAEJUXVFAHAMALgu0PQ9SBwChV5PT4wsFALanlNIzqwMAs+1ZunnEBABvMk0YDcMEADzvzMmSEAcAvB0FdKzYAwCt0EP1tgoJAI/aD6zz0A0A4+VzJR3vBQB6E7dbOhcMAIyRZAM/UgAAe4pjbfWHBgAT0IqSlgcCADNPpQWE0wUAVwI9sBXqAACKIfnwMW4FAPgC4YhfYwUAuKVp2cXLAgB6NIvJ+zMFAOOkFFZW/AUAjpiQd+bhAgASSeSai+MJAFNWB7T7SAYAcs1A2PGNCgBl1Al0TCEDAOV6bcQNVwYAbeKRG5+KAQCrQj8YtjYEAJiBT6qsUAUAVMQUxBEnBgBwF2UGdIIBAGXChvJE0QQAgZLu8Ih0AQAMdlzbbJ4BALjsc0CpvgUA+NJD82POCACNNh59qOAJAOmeAbztRQgA0NAo7ZqXDgAaT5SFB60EAOSbyBIJvwUAg4zzyq0vBgAszrOWwV4CAHsBT/9VdgcAYY8UXM2qAwABgzHDNDsGALHQBC3m4AAAAWdyM6J2BgBply0Emp4CACiQHcvwrwMA8jTF9AtDBgBEclDkw2QCAHCSoxmfTAcAR7yZ94Q/BwCZvTL3+cwKAF5AIDrrxwUA+DDZqrX9BQBHjDvmV6cEAFYkl5KUjgIA0kxv6OcQAQDk9QPWntgAAPiKAQQWHgUAGCJK3O64AADQhJOLqRsFAJOWC35VXAAAsA7CibC7BgDungv7Qd8GAG/hh+2HEA0AMKefXNsCCQBgGITw/okCAG9+yR8xzgEAH9u1Pz8CBgCY/Oh1l7QHAEVQv61wrQMAmP54wVThBgC/mtb+NmMBAOz5Kblm8AQAk1tsnv/pBAC6sku8iYwBAMqVKmS/rwYAuagT+XBQDQC7K6yeYWUHAFl09CVSqwsAR1urFO1sBwABuO08CSwJAMHS9WIM3gAAtU9zzwGWBAD28GOCw7UGAAZttfU+YgQAA5UbhUvbAAAPGbgIk38EAIIfYlwjFAQAdloa9F8fAwBtuapzZ3MGADVmnHmoOgMAnmwV/Ij1CABo8KRNQWMDAOqKttlqKQcAQ64WE3HTBABYjRwMzRIKAPJcCL0e9QcA4fXjZ/osAQBq1OPxDIABAKjwX2E3QwUAIY6e8sYzAgCBxxh/ENUEAF4apdNPSgYAN7tIBM30BAAeFUOF03EGABQZkXh32wEAthpw3WlHCQBmtrTxOYMCAHvjikshqwQA/rCg7wpfCgDRF6CoLK4HAG/Ca3w5UgMAvnsioHqKAQCLX+rBjOYFAF8dejo+/gYAKm7SetkaAwBiuSAJ7RcAAP22UzvjhwEAYxR6kClYBQCSp+BI8kEGACJmOsUf7QEALS0JHKZCBgB/0RHnNxkLACFBze1L3AwA3j2LDJ9WCgCheqVk1gMFAG7yiU2O6QEAl/78Fq4QBQB8C85yERcCAII2v+2RUQUAwIvyNiuxBQA3FamQWzkDAENZvvzm+QYAD+rm6i86AgAGHwGVjHEEAB+aXmgGaQMAHXjYTzy+BACJivxqcUIKAHY8v+T0bAkAXjL3k/XSCQBbgATP3FUDAEieabjYDQEAY42P6zpGBwAzwJFuhWAHAFXgjgArzwAAS0cIJxGxBQDbdTzLTZgFAHf5z8r+6gQAe9l+WAZmAQBbxFqc2LIHAORaIntYhAUAw36mZg/BBQAKifgycpkFAIWtEy6GyAoAv+n/p0UqBgAqmEu6J14IAKZXL/FjowMAcsZ9hXdmAwBF11DdbgEGAFQEDKTtdwcAEX24j5HYAwBNhloefaYGAODHEELFGwYAtrqWP6ugBQB1R4iwNe0CAKVkTULz+AcAr4ZIsgdIAgBjT7xfiNgLALMjVT6VFQEAPdIYqdcyCQAOMaDLVecHANFOeSQ2KQYA2mHRHh7tAADDb7gP844AAGcL/35VYgMANTKcBafKAAAjMBp2Uk8EAF8Tzd7SBAEAajiZZmWRBwB+BnojcRgBALNw7ipsUwQAw7nMIfPvCwCbEfcqpIwGAP3iaC5ajAUAh/YvMO7ZAwBJpFwPXaEGAPq3nVkCowEAA9xE+AX+BgCc07o1BsQBAH8p/A3/OAIAR7pBgN+7BwDVqL8J8eEFAMERnjhEPAcAq5NwYyFeAgAbzZyXfb0FAM01QG0gXAUAJXbekK36BwBEYRw5hsIDAEafCC5nKQUAEK7tzIcSDgBw7iI5a80FADc9RLhZgQMAKi6f7NlaBQBtzwrwe3oEAAZgCs4sXAcA6XTNi/x4AgDH6zPWlKkEAAfe9/RGzwUASUSEr1A0AwBwTxj6KRQCAIirkVJhaAQAb+tM1VE4CACH5Wytv1kFAKeItK/kiQMAjKmQVvpCAgCJODUvPlIFANLvpVScCQEANO7y8woeBAAaFNc/71MHAInHWQzu6QYATomlZts2BgDe1NB7blMCAF9TPH60bAUAloQ91DAhBwBZPtF6RMwHALBZVfaMKAUACYjZ8Cm2CgDxIc7hqnwKAOvH8u/rLgkAo8Qn9y/pCAAjRV/IcCwJAJsolwrFyAUAUvZHJVBdBwCu+mOlJNoFAAdjees2CgMAZKlVtQE/BgB/djjlpb0FAEiNGSxh+gAATKaARc1UAwDqtM9JnqoEAGKrFlQWNwQAhq393fuxBQA6vPHOllwHAP4Gtn50AwYAzIwMvLXbCABxufGF6W8EAJpL5jYoCgAAJixOp5IeAgCT2kDVkc0HAKOnkTJCHgEA3cJy3EbqAwCn3+KIhQEFAP5T3eugPwAA0OecldNxAgDsSy8HNacEADL0fcqwiAAAwGz+/lQOBwAMgrKjHHUCAHXuOnyP1gQA+hGHT/1JDADt9QpwVccDAJ2qVHwzRQQAyKT5bcjPBwA6QtthbUYEAErr0Mf2vAEA4RBhVLDVBwCWBcfXljoHABNvPmBfYQcA+eOrXgOHAABqNCMLslYFAHc6S1ZcrgEAOFkCA0ytAQBBm3BLjY8CAJvvT5CKFwoAA+BzgKIxCwCRjRlBpgEKAFuNcD6G5gAAsb9UthSZAAC3lidBdtEBAA90PpgHwwMA8YqBHs/ZBQArWaHiOx0CAHvrgxhXTAUAqm6vLDEJAQBunqS8KpMFAOAfNgwKqgMAk/bfCOVfDACCsnHwwWwFAEpAHxOV3gkAre50kyOgAQAgi3APGeYDAC7vSeEhbgQAzyAtzgBKAAAEgzPCzOIBAE+uOlXYlAAAGg0jnzDuBgB3uGesMq4AACknQdiP6gEAiojotSahAwDYexK6sKUDAB1PNpjeTAYA509stoK5DgBeCLngwxgCAGzQ4j7sVA4Awqs8kZYDCAACQhTMZ5cJAFBkHwfk1gcA4eQ+6sP3AQDa4/TNPqUAAADSfnnCGAQAU7TlgBrEAgBLxZ2O4A8GALegCcPxsgYAvLvLETspAwDtp1iGV/QBABzId3u8kwMAAozNaKhnCwAmNtmtGUcHAE8UWtFKFwwAI/tc9j1LAwDTw5pZtesOAFVHP7dFhgMAN11hcwexAQDUcn3qBQMHAOKditz7MQcATsrQu87ABwC9WWAw2sUEAFNIv8zvrAQAr7eZbFqyBgBnaAIzGEYGAJSpdhGtzgcAIuZNxggeCwBCDCqSca8PAOusHCFIwAYAEw5bm25uBQDQ5E83FrgHAINHVmjbTAYA32ZYgs06AAAdykxMj7sEAJHwyeW/qAIA1xTE13MuAwDMPxEEwRsHAFIKa04Z8QEA9PFwUZB+AQDrOs6Tx7EAAPCWzuNq9QYAprT2huGjAgDvqCavZB4MAH2ZBf7aNAkAMsftuaJ0CACqkvyWvLwKAHOSHoztlgAAp6vL2sJoAACtTX6b3MsDAGrRm8bNiwYAs6/+qSf/BgApYx9hPvcBAIEtyDkQ1QAAxc7A17C4AQDSOgJwqGYEAITibVtaKwcAwzejKEYsCQCN52D0Z2wEAF5yaN7lkAwAQYwB0jWEBgDn/aZ6WkgDACDnaO10lwYAJn6V4n0pAwAmdON3AEUGAK6ctSj+swAAt5cNFqEaBgCOElV/e4oEAKbkssWwugYALS/dMCGCAwC0ePa5WaEAAI3uAwXOxgIAB5tGduYXBwAp0WM8BDwEALMz0AwpSgQAAdxUcIfTCQA4gze1wvgIAIkoY5yx3wIAsFGeSCWFAwAzW3ppSNoDAE22cnfy1AMASSbZ0XrnAAB1XNvyHTACAOPFO6MBFQIAggN1P7V2AgBcdwFwvPoGAI0lx1QezAQAnOE6a9jhCwASF6cXMI8CAJ56DORP0AgA/s/hIsM7BwAtozciTykHAI5jQ3VmwAQAf34fyYkMBwB9mNCb7aYCAKBT1+R6cgEAFHXO/fMuBgD9Pn33F4AAAMttSD4NxwMAdkd7epcJBACnG+fUXlIBAGZW0YeMkgEAKXIIZtVHCABGyRjrslYBAIumtmykOAcAOjDUqitKBQCfSdTBDq4EADAhfrValQQAYaO+nsiyBwD+rb9lsvQCAIR2OgIhGAMAj0V0F7R9BwCnfb6im8sGAHqwug+cAQMAdqwZEv9CBwDJS9JfV4cDADHaYTQbfwEAhihsAz1rCQAzQfOcfNwJAHQd6wLsBQkAyXOs49UmCQA8RD/EgooHAFLOAzSbGQQAybEc4mxPAwCEjbLUnNoFAKK9FrtoEwMAqa0TmrnZAwDEdSZwEoEDAK3A6SiNaAUA50S//7ESBwB7rdOcIsgBALuBvQiStAAAbwcNCvtQBQB/wNod0y0OALQjqyNgAgwANszJsWAkCgBQLdpkCuQLAEFyKC2z3AIAtyaYsJK4BgBd9Ow5YKMFAHl+CdbDkAIAKB8ue+5XAQCfcMqdLqUFAP6yl//neAMAQouUVP64BAB4e9etD1oHAPtVXBF3ogUAQkyF5SHZCABnTzbG+w0HAOzxnLi5SAgAJii3sfG5DgDSLYmR4fQIAMwAgzIVMAIAYlX49LD6BwAd+yHD47YBAKy+FpwndwcA3xerAptoBADtMkHsEhwFAHe4t1YkGwMAgdGHUx7CBQAvykl6wxMDAN2evC5DsgMA3NjHgZeJCADfAoUx5w0JAGetkL4Y2wgAG7EVEdpgCACMMjAT/WELAFkujLfCzAYAd7eSLzgGBwDcZDf0WAIHAPYEmv/G3AUA27IqH1zFBgCGmRVlgQwDAEWa6KH4LgIA5FziEhHoAwBqC7SsWEMCACx7klqEzQMAzFEZLNcGDQBdov4FH70MAMyo79c5bggAI1FYtapWCQB+JMeKmV8MALDTb9+tFQcAouPW6xrPBwCpyAFxGzkAAGmrNauHaAUAkdqg6CFhAwDNPl3FKAcDAIH0ZirNiAEADYVbOzNRAQC5amGj/40BANVm8GwIOwIAfNW9tIBgBgCsMUaXxjAJAI/y9ebwsgQAgJoif6IKAwDxFJChX2wJAF4ZBeoYUQMAbbggLfhGAABFUcfKPEoDAJaEwhl1OgUA6MaIU7seAAA79XLnbkEFAOihEp1zuQAA4z8mQxxYAgCr4ZT+VygAAHOEgfFOhgQAHbjQCzqoBQChGYWGI3cLAK07GdL7VAgAgU2fN3MoCQC79teuA2wKALOaY5cywwcAAt9xGg1kBQAeH9E88IgFAB3EJWAutgcAuk3DwK2nAgDOfRxYL3oGAMOyLTUFCQQAJXrq8JAmBgDcPaVsSKoDAB2elWlRiwcALcxpV1rIBAArf2W66UoHAFT6m9ugGgYAKgvF5Q7aCADRvCQC7FcMAA0YXd9UggEAH6KMOp3/AABUGNR9xDkCAKQalauThAMAHjeQvBQjAACKkCaP/q4AAD1vWqdqvwMAzO5a6DsTAgB1m7zF3SQFAPD8NMVylQcAl5V04ABDCwCGhpiADHIMAJfcfJEmIwIAy1X7SQoOBQAZf24LDIkHAG8tW6M8sgUAcyQ3mCVXBwA2KOwSqFsGAAbEmxmCnwcADraYjd8NBwDEXdf9t0ABAJJ+0wJfCwMADsyOFhLSAgD2GHGsFVUAAKeJHmlpVwQArUOmW9w9BgAhZ20jNz0DAPtzIUJ2ngkAKgg610U8DgDGBWtwD+wCANstWzQF4wMAnGpzXYC9BgAwpx71hVcFAO73rhEBwQYAwQEvI3QLAQDYWY9glBYCAIefj6HH9wMAuDclwlE4AQAVN1soyFMDAPSjJZ361gUAyqajsv5aDACEtcwBvvMAALSzmbZyfgoAC/tlJgOOCwCdfIhB+nQNALtsbuSFQQcA20jKR+QlAAAwp6kYmfQFAPr7+r88vQQA9nX3BOdFBgD6Hone2ikFACUZ+9xFogUAz+k8RFQ4BQAUwawaeZkEAKvKTVcOQgcACUsjlD9uBgAHH4JDaNMEAIftIZdSEQcASdiZpaI6CADbPJz6YLoKADxRNKA4oQYA7L5zOt/oBQCAmD+YkhsFAMaAHFeU6QEAG1grY/ROBADJZNMhHEkGAHq0REmkjAUA7mgXXXIcAADg7Ih6q+cBAF9LxJlIBQcAo3hZE8pNAwC9bhU7KKgBACnAAWCi5wUAuzygY8Y5BwD/tuLONiAFAFnxsiaUmwYAet0qdlBQAwBSgAPARM8DAHd5QMeMcwYA/23FnW1AAgAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvY3VydmUyNTUxOS1kYWxlay0yLjAuMC9zcmMvYmFja2VuZC9zZXJpYWwvdTY0L3NjYWxhci5yc9A1EgB0AAAAKQAAAAoAAADQNRIAdAAAAC8AAAAOAAAA0DUSAHQAAABEAAAAHgAAANA1EgB0AAAAWgAAAB4AAAAAAAAA7eYhZ71IDwBa5GestboDABvlNev//w8A////////DwD//////w8AADvRUull0gkAn6a+FcdjDQAEdmjLZb4FAH8hPcfu3AMAmjB8G0EJAADt0/VcGmMCAIFlzXkv6g0A+d4UAEH97cgAC44BEAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMi4wLjAvc3JjL3NjYWxhci5ycwAAAAA3EgBhAAAAFwEAAAoAAAAAAAAA7dP1XBpjAgCBZc15L+oNAPneFABBne/IAAu0BBAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTIuMC4wL3NyYy93aW5kb3cucnMAAACgNxIAYQAAAH8AAAAJAAAAoDcSAGEAAACqAAAACQAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL3N0ci9wYXR0ZXJuLnJzAAAkOBIASgAAAIIEAAAUAAAAJDgSAEoAAACCBAAAIQAAACQ4EgBKAAAAjgQAABQAAAAkOBIASgAAAI4EAAAhAAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvc2xpY2UvbW9kLnJzsDgSAEgAAAAmCwAACgAAACAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvaG1hYy0wLjcuMC9zcmMvbGliLnJzAAk5EgBSAAAAdgAAABEAAAAJORIAUgAAAHcAAAARAAAACTkSAFIAAACBAAAAKAAAAAk5EgBSAAAAgQAAABEAAAAJORIAUgAAAIIAAAAeAAAACTkSAFIAAACCAAAAEQAAADIAAAAMAAAABAAAADMAAAA0AAAANQBB5PPIAAu5mwE2AAAANwAAADgAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9zbGljZS9tb2QucnPwORIASAAAACYLAAAKAAAASGFzaCB0YWJsZSBjYXBhY2l0eSBvdmVyZmxvdzw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAZDoSAB4AAAACAAAAAgAAAP////85AAAABAAAAAQAAAA6AAAAOwAAADwAAAAEAAAABAAAAD0AAAA+AAAAY2FsbGVkIGBPcHRpb246OnVud3JhcCgpYCBvbiBhIGBOb25lYCB2YWx1ZS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9vbmNlX2NlbGwtMC4xLjgvc3JjL2ltcF9wbC5ycwAAAOs6EgBaAAAAhwAAAAkAAABhYmFuZG9uCmFiaWxpdHkKYWJsZQphYm91dAphYm92ZQphYnNlbnQKYWJzb3JiCmFic3RyYWN0CmFic3VyZAphYnVzZQphY2Nlc3MKYWNjaWRlbnQKYWNjb3VudAphY2N1c2UKYWNoaWV2ZQphY2lkCmFjb3VzdGljCmFjcXVpcmUKYWNyb3NzCmFjdAphY3Rpb24KYWN0b3IKYWN0cmVzcwphY3R1YWwKYWRhcHQKYWRkCmFkZGljdAphZGRyZXNzCmFkanVzdAphZG1pdAphZHVsdAphZHZhbmNlCmFkdmljZQphZXJvYmljCmFmZmFpcgphZmZvcmQKYWZyYWlkCmFnYWluCmFnZQphZ2VudAphZ3JlZQphaGVhZAphaW0KYWlyCmFpcnBvcnQKYWlzbGUKYWxhcm0KYWxidW0KYWxjb2hvbAphbGVydAphbGllbgphbGwKYWxsZXkKYWxsb3cKYWxtb3N0CmFsb25lCmFscGhhCmFscmVhZHkKYWxzbwphbHRlcgphbHdheXMKYW1hdGV1cgphbWF6aW5nCmFtb25nCmFtb3VudAphbXVzZWQKYW5hbHlzdAphbmNob3IKYW5jaWVudAphbmdlcgphbmdsZQphbmdyeQphbmltYWwKYW5rbGUKYW5ub3VuY2UKYW5udWFsCmFub3RoZXIKYW5zd2VyCmFudGVubmEKYW50aXF1ZQphbnhpZXR5CmFueQphcGFydAphcG9sb2d5CmFwcGVhcgphcHBsZQphcHByb3ZlCmFwcmlsCmFyY2gKYXJjdGljCmFyZWEKYXJlbmEKYXJndWUKYXJtCmFybWVkCmFybW9yCmFybXkKYXJvdW5kCmFycmFuZ2UKYXJyZXN0CmFycml2ZQphcnJvdwphcnQKYXJ0ZWZhY3QKYXJ0aXN0CmFydHdvcmsKYXNrCmFzcGVjdAphc3NhdWx0CmFzc2V0CmFzc2lzdAphc3N1bWUKYXN0aG1hCmF0aGxldGUKYXRvbQphdHRhY2sKYXR0ZW5kCmF0dGl0dWRlCmF0dHJhY3QKYXVjdGlvbgphdWRpdAphdWd1c3QKYXVudAphdXRob3IKYXV0bwphdXR1bW4KYXZlcmFnZQphdm9jYWRvCmF2b2lkCmF3YWtlCmF3YXJlCmF3YXkKYXdlc29tZQphd2Z1bAphd2t3YXJkCmF4aXMKYmFieQpiYWNoZWxvcgpiYWNvbgpiYWRnZQpiYWcKYmFsYW5jZQpiYWxjb255CmJhbGwKYmFtYm9vCmJhbmFuYQpiYW5uZXIKYmFyCmJhcmVseQpiYXJnYWluCmJhcnJlbApiYXNlCmJhc2ljCmJhc2tldApiYXR0bGUKYmVhY2gKYmVhbgpiZWF1dHkKYmVjYXVzZQpiZWNvbWUKYmVlZgpiZWZvcmUKYmVnaW4KYmVoYXZlCmJlaGluZApiZWxpZXZlCmJlbG93CmJlbHQKYmVuY2gKYmVuZWZpdApiZXN0CmJldHJheQpiZXR0ZXIKYmV0d2VlbgpiZXlvbmQKYmljeWNsZQpiaWQKYmlrZQpiaW5kCmJpb2xvZ3kKYmlyZApiaXJ0aApiaXR0ZXIKYmxhY2sKYmxhZGUKYmxhbWUKYmxhbmtldApibGFzdApibGVhawpibGVzcwpibGluZApibG9vZApibG9zc29tCmJsb3VzZQpibHVlCmJsdXIKYmx1c2gKYm9hcmQKYm9hdApib2R5CmJvaWwKYm9tYgpib25lCmJvbnVzCmJvb2sKYm9vc3QKYm9yZGVyCmJvcmluZwpib3Jyb3cKYm9zcwpib3R0b20KYm91bmNlCmJveApib3kKYnJhY2tldApicmFpbgpicmFuZApicmFzcwpicmF2ZQpicmVhZApicmVlemUKYnJpY2sKYnJpZGdlCmJyaWVmCmJyaWdodApicmluZwpicmlzawpicm9jY29saQpicm9rZW4KYnJvbnplCmJyb29tCmJyb3RoZXIKYnJvd24KYnJ1c2gKYnViYmxlCmJ1ZGR5CmJ1ZGdldApidWZmYWxvCmJ1aWxkCmJ1bGIKYnVsawpidWxsZXQKYnVuZGxlCmJ1bmtlcgpidXJkZW4KYnVyZ2VyCmJ1cnN0CmJ1cwpidXNpbmVzcwpidXN5CmJ1dHRlcgpidXllcgpidXp6CmNhYmJhZ2UKY2FiaW4KY2FibGUKY2FjdHVzCmNhZ2UKY2FrZQpjYWxsCmNhbG0KY2FtZXJhCmNhbXAKY2FuCmNhbmFsCmNhbmNlbApjYW5keQpjYW5ub24KY2Fub2UKY2FudmFzCmNhbnlvbgpjYXBhYmxlCmNhcGl0YWwKY2FwdGFpbgpjYXIKY2FyYm9uCmNhcmQKY2FyZ28KY2FycGV0CmNhcnJ5CmNhcnQKY2FzZQpjYXNoCmNhc2lubwpjYXN0bGUKY2FzdWFsCmNhdApjYXRhbG9nCmNhdGNoCmNhdGVnb3J5CmNhdHRsZQpjYXVnaHQKY2F1c2UKY2F1dGlvbgpjYXZlCmNlaWxpbmcKY2VsZXJ5CmNlbWVudApjZW5zdXMKY2VudHVyeQpjZXJlYWwKY2VydGFpbgpjaGFpcgpjaGFsawpjaGFtcGlvbgpjaGFuZ2UKY2hhb3MKY2hhcHRlcgpjaGFyZ2UKY2hhc2UKY2hhdApjaGVhcApjaGVjawpjaGVlc2UKY2hlZgpjaGVycnkKY2hlc3QKY2hpY2tlbgpjaGllZgpjaGlsZApjaGltbmV5CmNob2ljZQpjaG9vc2UKY2hyb25pYwpjaHVja2xlCmNodW5rCmNodXJuCmNpZ2FyCmNpbm5hbW9uCmNpcmNsZQpjaXRpemVuCmNpdHkKY2l2aWwKY2xhaW0KY2xhcApjbGFyaWZ5CmNsYXcKY2xheQpjbGVhbgpjbGVyawpjbGV2ZXIKY2xpY2sKY2xpZW50CmNsaWZmCmNsaW1iCmNsaW5pYwpjbGlwCmNsb2NrCmNsb2cKY2xvc2UKY2xvdGgKY2xvdWQKY2xvd24KY2x1YgpjbHVtcApjbHVzdGVyCmNsdXRjaApjb2FjaApjb2FzdApjb2NvbnV0CmNvZGUKY29mZmVlCmNvaWwKY29pbgpjb2xsZWN0CmNvbG9yCmNvbHVtbgpjb21iaW5lCmNvbWUKY29tZm9ydApjb21pYwpjb21tb24KY29tcGFueQpjb25jZXJ0CmNvbmR1Y3QKY29uZmlybQpjb25ncmVzcwpjb25uZWN0CmNvbnNpZGVyCmNvbnRyb2wKY29udmluY2UKY29vawpjb29sCmNvcHBlcgpjb3B5CmNvcmFsCmNvcmUKY29ybgpjb3JyZWN0CmNvc3QKY290dG9uCmNvdWNoCmNvdW50cnkKY291cGxlCmNvdXJzZQpjb3VzaW4KY292ZXIKY295b3RlCmNyYWNrCmNyYWRsZQpjcmFmdApjcmFtCmNyYW5lCmNyYXNoCmNyYXRlcgpjcmF3bApjcmF6eQpjcmVhbQpjcmVkaXQKY3JlZWsKY3Jldwpjcmlja2V0CmNyaW1lCmNyaXNwCmNyaXRpYwpjcm9wCmNyb3NzCmNyb3VjaApjcm93ZApjcnVjaWFsCmNydWVsCmNydWlzZQpjcnVtYmxlCmNydW5jaApjcnVzaApjcnkKY3J5c3RhbApjdWJlCmN1bHR1cmUKY3VwCmN1cGJvYXJkCmN1cmlvdXMKY3VycmVudApjdXJ0YWluCmN1cnZlCmN1c2hpb24KY3VzdG9tCmN1dGUKY3ljbGUKZGFkCmRhbWFnZQpkYW1wCmRhbmNlCmRhbmdlcgpkYXJpbmcKZGFzaApkYXVnaHRlcgpkYXduCmRheQpkZWFsCmRlYmF0ZQpkZWJyaXMKZGVjYWRlCmRlY2VtYmVyCmRlY2lkZQpkZWNsaW5lCmRlY29yYXRlCmRlY3JlYXNlCmRlZXIKZGVmZW5zZQpkZWZpbmUKZGVmeQpkZWdyZWUKZGVsYXkKZGVsaXZlcgpkZW1hbmQKZGVtaXNlCmRlbmlhbApkZW50aXN0CmRlbnkKZGVwYXJ0CmRlcGVuZApkZXBvc2l0CmRlcHRoCmRlcHV0eQpkZXJpdmUKZGVzY3JpYmUKZGVzZXJ0CmRlc2lnbgpkZXNrCmRlc3BhaXIKZGVzdHJveQpkZXRhaWwKZGV0ZWN0CmRldmVsb3AKZGV2aWNlCmRldm90ZQpkaWFncmFtCmRpYWwKZGlhbW9uZApkaWFyeQpkaWNlCmRpZXNlbApkaWV0CmRpZmZlcgpkaWdpdGFsCmRpZ25pdHkKZGlsZW1tYQpkaW5uZXIKZGlub3NhdXIKZGlyZWN0CmRpcnQKZGlzYWdyZWUKZGlzY292ZXIKZGlzZWFzZQpkaXNoCmRpc21pc3MKZGlzb3JkZXIKZGlzcGxheQpkaXN0YW5jZQpkaXZlcnQKZGl2aWRlCmRpdm9yY2UKZGl6enkKZG9jdG9yCmRvY3VtZW50CmRvZwpkb2xsCmRvbHBoaW4KZG9tYWluCmRvbmF0ZQpkb25rZXkKZG9ub3IKZG9vcgpkb3NlCmRvdWJsZQpkb3ZlCmRyYWZ0CmRyYWdvbgpkcmFtYQpkcmFzdGljCmRyYXcKZHJlYW0KZHJlc3MKZHJpZnQKZHJpbGwKZHJpbmsKZHJpcApkcml2ZQpkcm9wCmRydW0KZHJ5CmR1Y2sKZHVtYgpkdW5lCmR1cmluZwpkdXN0CmR1dGNoCmR1dHkKZHdhcmYKZHluYW1pYwplYWdlcgplYWdsZQplYXJseQplYXJuCmVhcnRoCmVhc2lseQplYXN0CmVhc3kKZWNobwplY29sb2d5CmVjb25vbXkKZWRnZQplZGl0CmVkdWNhdGUKZWZmb3J0CmVnZwplaWdodAplaXRoZXIKZWxib3cKZWxkZXIKZWxlY3RyaWMKZWxlZ2FudAplbGVtZW50CmVsZXBoYW50CmVsZXZhdG9yCmVsaXRlCmVsc2UKZW1iYXJrCmVtYm9keQplbWJyYWNlCmVtZXJnZQplbW90aW9uCmVtcGxveQplbXBvd2VyCmVtcHR5CmVuYWJsZQplbmFjdAplbmQKZW5kbGVzcwplbmRvcnNlCmVuZW15CmVuZXJneQplbmZvcmNlCmVuZ2FnZQplbmdpbmUKZW5oYW5jZQplbmpveQplbmxpc3QKZW5vdWdoCmVucmljaAplbnJvbGwKZW5zdXJlCmVudGVyCmVudGlyZQplbnRyeQplbnZlbG9wZQplcGlzb2RlCmVxdWFsCmVxdWlwCmVyYQplcmFzZQplcm9kZQplcm9zaW9uCmVycm9yCmVydXB0CmVzY2FwZQplc3NheQplc3NlbmNlCmVzdGF0ZQpldGVybmFsCmV0aGljcwpldmlkZW5jZQpldmlsCmV2b2tlCmV2b2x2ZQpleGFjdApleGFtcGxlCmV4Y2VzcwpleGNoYW5nZQpleGNpdGUKZXhjbHVkZQpleGN1c2UKZXhlY3V0ZQpleGVyY2lzZQpleGhhdXN0CmV4aGliaXQKZXhpbGUKZXhpc3QKZXhpdApleG90aWMKZXhwYW5kCmV4cGVjdApleHBpcmUKZXhwbGFpbgpleHBvc2UKZXhwcmVzcwpleHRlbmQKZXh0cmEKZXllCmV5ZWJyb3cKZmFicmljCmZhY2UKZmFjdWx0eQpmYWRlCmZhaW50CmZhaXRoCmZhbGwKZmFsc2UKZmFtZQpmYW1pbHkKZmFtb3VzCmZhbgpmYW5jeQpmYW50YXN5CmZhcm0KZmFzaGlvbgpmYXQKZmF0YWwKZmF0aGVyCmZhdGlndWUKZmF1bHQKZmF2b3JpdGUKZmVhdHVyZQpmZWJydWFyeQpmZWRlcmFsCmZlZQpmZWVkCmZlZWwKZmVtYWxlCmZlbmNlCmZlc3RpdmFsCmZldGNoCmZldmVyCmZldwpmaWJlcgpmaWN0aW9uCmZpZWxkCmZpZ3VyZQpmaWxlCmZpbG0KZmlsdGVyCmZpbmFsCmZpbmQKZmluZQpmaW5nZXIKZmluaXNoCmZpcmUKZmlybQpmaXJzdApmaXNjYWwKZmlzaApmaXQKZml0bmVzcwpmaXgKZmxhZwpmbGFtZQpmbGFzaApmbGF0CmZsYXZvcgpmbGVlCmZsaWdodApmbGlwCmZsb2F0CmZsb2NrCmZsb29yCmZsb3dlcgpmbHVpZApmbHVzaApmbHkKZm9hbQpmb2N1cwpmb2cKZm9pbApmb2xkCmZvbGxvdwpmb29kCmZvb3QKZm9yY2UKZm9yZXN0CmZvcmdldApmb3JrCmZvcnR1bmUKZm9ydW0KZm9yd2FyZApmb3NzaWwKZm9zdGVyCmZvdW5kCmZveApmcmFnaWxlCmZyYW1lCmZyZXF1ZW50CmZyZXNoCmZyaWVuZApmcmluZ2UKZnJvZwpmcm9udApmcm9zdApmcm93bgpmcm96ZW4KZnJ1aXQKZnVlbApmdW4KZnVubnkKZnVybmFjZQpmdXJ5CmZ1dHVyZQpnYWRnZXQKZ2FpbgpnYWxheHkKZ2FsbGVyeQpnYW1lCmdhcApnYXJhZ2UKZ2FyYmFnZQpnYXJkZW4KZ2FybGljCmdhcm1lbnQKZ2FzCmdhc3AKZ2F0ZQpnYXRoZXIKZ2F1Z2UKZ2F6ZQpnZW5lcmFsCmdlbml1cwpnZW5yZQpnZW50bGUKZ2VudWluZQpnZXN0dXJlCmdob3N0CmdpYW50CmdpZnQKZ2lnZ2xlCmdpbmdlcgpnaXJhZmZlCmdpcmwKZ2l2ZQpnbGFkCmdsYW5jZQpnbGFyZQpnbGFzcwpnbGlkZQpnbGltcHNlCmdsb2JlCmdsb29tCmdsb3J5Cmdsb3ZlCmdsb3cKZ2x1ZQpnb2F0CmdvZGRlc3MKZ29sZApnb29kCmdvb3NlCmdvcmlsbGEKZ29zcGVsCmdvc3NpcApnb3Zlcm4KZ293bgpncmFiCmdyYWNlCmdyYWluCmdyYW50CmdyYXBlCmdyYXNzCmdyYXZpdHkKZ3JlYXQKZ3JlZW4KZ3JpZApncmllZgpncml0Cmdyb2NlcnkKZ3JvdXAKZ3JvdwpncnVudApndWFyZApndWVzcwpndWlkZQpndWlsdApndWl0YXIKZ3VuCmd5bQpoYWJpdApoYWlyCmhhbGYKaGFtbWVyCmhhbXN0ZXIKaGFuZApoYXBweQpoYXJib3IKaGFyZApoYXJzaApoYXJ2ZXN0CmhhdApoYXZlCmhhd2sKaGF6YXJkCmhlYWQKaGVhbHRoCmhlYXJ0CmhlYXZ5CmhlZGdlaG9nCmhlaWdodApoZWxsbwpoZWxtZXQKaGVscApoZW4KaGVybwpoaWRkZW4KaGlnaApoaWxsCmhpbnQKaGlwCmhpcmUKaGlzdG9yeQpob2JieQpob2NrZXkKaG9sZApob2xlCmhvbGlkYXkKaG9sbG93CmhvbWUKaG9uZXkKaG9vZApob3BlCmhvcm4KaG9ycm9yCmhvcnNlCmhvc3BpdGFsCmhvc3QKaG90ZWwKaG91cgpob3ZlcgpodWIKaHVnZQpodW1hbgpodW1ibGUKaHVtb3IKaHVuZHJlZApodW5ncnkKaHVudApodXJkbGUKaHVycnkKaHVydApodXNiYW5kCmh5YnJpZAppY2UKaWNvbgppZGVhCmlkZW50aWZ5CmlkbGUKaWdub3JlCmlsbAppbGxlZ2FsCmlsbG5lc3MKaW1hZ2UKaW1pdGF0ZQppbW1lbnNlCmltbXVuZQppbXBhY3QKaW1wb3NlCmltcHJvdmUKaW1wdWxzZQppbmNoCmluY2x1ZGUKaW5jb21lCmluY3JlYXNlCmluZGV4CmluZGljYXRlCmluZG9vcgppbmR1c3RyeQppbmZhbnQKaW5mbGljdAppbmZvcm0KaW5oYWxlCmluaGVyaXQKaW5pdGlhbAppbmplY3QKaW5qdXJ5CmlubWF0ZQppbm5lcgppbm5vY2VudAppbnB1dAppbnF1aXJ5Cmluc2FuZQppbnNlY3QKaW5zaWRlCmluc3BpcmUKaW5zdGFsbAppbnRhY3QKaW50ZXJlc3QKaW50bwppbnZlc3QKaW52aXRlCmludm9sdmUKaXJvbgppc2xhbmQKaXNvbGF0ZQppc3N1ZQppdGVtCml2b3J5CmphY2tldApqYWd1YXIKamFyCmphenoKamVhbG91cwpqZWFucwpqZWxseQpqZXdlbApqb2IKam9pbgpqb2tlCmpvdXJuZXkKam95Cmp1ZGdlCmp1aWNlCmp1bXAKanVuZ2xlCmp1bmlvcgpqdW5rCmp1c3QKa2FuZ2Fyb28Ka2VlbgprZWVwCmtldGNodXAKa2V5CmtpY2sKa2lkCmtpZG5leQpraW5kCmtpbmdkb20Ka2lzcwpraXQKa2l0Y2hlbgpraXRlCmtpdHRlbgpraXdpCmtuZWUKa25pZmUKa25vY2sKa25vdwpsYWIKbGFiZWwKbGFib3IKbGFkZGVyCmxhZHkKbGFrZQpsYW1wCmxhbmd1YWdlCmxhcHRvcApsYXJnZQpsYXRlcgpsYXRpbgpsYXVnaApsYXVuZHJ5CmxhdmEKbGF3Cmxhd24KbGF3c3VpdApsYXllcgpsYXp5CmxlYWRlcgpsZWFmCmxlYXJuCmxlYXZlCmxlY3R1cmUKbGVmdApsZWcKbGVnYWwKbGVnZW5kCmxlaXN1cmUKbGVtb24KbGVuZApsZW5ndGgKbGVucwpsZW9wYXJkCmxlc3NvbgpsZXR0ZXIKbGV2ZWwKbGlhcgpsaWJlcnR5CmxpYnJhcnkKbGljZW5zZQpsaWZlCmxpZnQKbGlnaHQKbGlrZQpsaW1iCmxpbWl0CmxpbmsKbGlvbgpsaXF1aWQKbGlzdApsaXR0bGUKbGl2ZQpsaXphcmQKbG9hZApsb2FuCmxvYnN0ZXIKbG9jYWwKbG9jawpsb2dpYwpsb25lbHkKbG9uZwpsb29wCmxvdHRlcnkKbG91ZApsb3VuZ2UKbG92ZQpsb3lhbApsdWNreQpsdWdnYWdlCmx1bWJlcgpsdW5hcgpsdW5jaApsdXh1cnkKbHlyaWNzCm1hY2hpbmUKbWFkCm1hZ2ljCm1hZ25ldAptYWlkCm1haWwKbWFpbgptYWpvcgptYWtlCm1hbW1hbAptYW4KbWFuYWdlCm1hbmRhdGUKbWFuZ28KbWFuc2lvbgptYW51YWwKbWFwbGUKbWFyYmxlCm1hcmNoCm1hcmdpbgptYXJpbmUKbWFya2V0Cm1hcnJpYWdlCm1hc2sKbWFzcwptYXN0ZXIKbWF0Y2gKbWF0ZXJpYWwKbWF0aAptYXRyaXgKbWF0dGVyCm1heGltdW0KbWF6ZQptZWFkb3cKbWVhbgptZWFzdXJlCm1lYXQKbWVjaGFuaWMKbWVkYWwKbWVkaWEKbWVsb2R5Cm1lbHQKbWVtYmVyCm1lbW9yeQptZW50aW9uCm1lbnUKbWVyY3kKbWVyZ2UKbWVyaXQKbWVycnkKbWVzaAptZXNzYWdlCm1ldGFsCm1ldGhvZAptaWRkbGUKbWlkbmlnaHQKbWlsawptaWxsaW9uCm1pbWljCm1pbmQKbWluaW11bQptaW5vcgptaW51dGUKbWlyYWNsZQptaXJyb3IKbWlzZXJ5Cm1pc3MKbWlzdGFrZQptaXgKbWl4ZWQKbWl4dHVyZQptb2JpbGUKbW9kZWwKbW9kaWZ5Cm1vbQptb21lbnQKbW9uaXRvcgptb25rZXkKbW9uc3Rlcgptb250aAptb29uCm1vcmFsCm1vcmUKbW9ybmluZwptb3NxdWl0bwptb3RoZXIKbW90aW9uCm1vdG9yCm1vdW50YWluCm1vdXNlCm1vdmUKbW92aWUKbXVjaAptdWZmaW4KbXVsZQptdWx0aXBseQptdXNjbGUKbXVzZXVtCm11c2hyb29tCm11c2ljCm11c3QKbXV0dWFsCm15c2VsZgpteXN0ZXJ5Cm15dGgKbmFpdmUKbmFtZQpuYXBraW4KbmFycm93Cm5hc3R5Cm5hdGlvbgpuYXR1cmUKbmVhcgpuZWNrCm5lZWQKbmVnYXRpdmUKbmVnbGVjdApuZWl0aGVyCm5lcGhldwpuZXJ2ZQpuZXN0Cm5ldApuZXR3b3JrCm5ldXRyYWwKbmV2ZXIKbmV3cwpuZXh0Cm5pY2UKbmlnaHQKbm9ibGUKbm9pc2UKbm9taW5lZQpub29kbGUKbm9ybWFsCm5vcnRoCm5vc2UKbm90YWJsZQpub3RlCm5vdGhpbmcKbm90aWNlCm5vdmVsCm5vdwpudWNsZWFyCm51bWJlcgpudXJzZQpudXQKb2FrCm9iZXkKb2JqZWN0Cm9ibGlnZQpvYnNjdXJlCm9ic2VydmUKb2J0YWluCm9idmlvdXMKb2NjdXIKb2NlYW4Kb2N0b2JlcgpvZG9yCm9mZgpvZmZlcgpvZmZpY2UKb2Z0ZW4Kb2lsCm9rYXkKb2xkCm9saXZlCm9seW1waWMKb21pdApvbmNlCm9uZQpvbmlvbgpvbmxpbmUKb25seQpvcGVuCm9wZXJhCm9waW5pb24Kb3Bwb3NlCm9wdGlvbgpvcmFuZ2UKb3JiaXQKb3JjaGFyZApvcmRlcgpvcmRpbmFyeQpvcmdhbgpvcmllbnQKb3JpZ2luYWwKb3JwaGFuCm9zdHJpY2gKb3RoZXIKb3V0ZG9vcgpvdXRlcgpvdXRwdXQKb3V0c2lkZQpvdmFsCm92ZW4Kb3Zlcgpvd24Kb3duZXIKb3h5Z2VuCm95c3Rlcgpvem9uZQpwYWN0CnBhZGRsZQpwYWdlCnBhaXIKcGFsYWNlCnBhbG0KcGFuZGEKcGFuZWwKcGFuaWMKcGFudGhlcgpwYXBlcgpwYXJhZGUKcGFyZW50CnBhcmsKcGFycm90CnBhcnR5CnBhc3MKcGF0Y2gKcGF0aApwYXRpZW50CnBhdHJvbApwYXR0ZXJuCnBhdXNlCnBhdmUKcGF5bWVudApwZWFjZQpwZWFudXQKcGVhcgpwZWFzYW50CnBlbGljYW4KcGVuCnBlbmFsdHkKcGVuY2lsCnBlb3BsZQpwZXBwZXIKcGVyZmVjdApwZXJtaXQKcGVyc29uCnBldApwaG9uZQpwaG90bwpwaHJhc2UKcGh5c2ljYWwKcGlhbm8KcGljbmljCnBpY3R1cmUKcGllY2UKcGlnCnBpZ2VvbgpwaWxsCnBpbG90CnBpbmsKcGlvbmVlcgpwaXBlCnBpc3RvbApwaXRjaApwaXp6YQpwbGFjZQpwbGFuZXQKcGxhc3RpYwpwbGF0ZQpwbGF5CnBsZWFzZQpwbGVkZ2UKcGx1Y2sKcGx1ZwpwbHVuZ2UKcG9lbQpwb2V0CnBvaW50CnBvbGFyCnBvbGUKcG9saWNlCnBvbmQKcG9ueQpwb29sCnBvcHVsYXIKcG9ydGlvbgpwb3NpdGlvbgpwb3NzaWJsZQpwb3N0CnBvdGF0bwpwb3R0ZXJ5CnBvdmVydHkKcG93ZGVyCnBvd2VyCnByYWN0aWNlCnByYWlzZQpwcmVkaWN0CnByZWZlcgpwcmVwYXJlCnByZXNlbnQKcHJldHR5CnByZXZlbnQKcHJpY2UKcHJpZGUKcHJpbWFyeQpwcmludApwcmlvcml0eQpwcmlzb24KcHJpdmF0ZQpwcml6ZQpwcm9ibGVtCnByb2Nlc3MKcHJvZHVjZQpwcm9maXQKcHJvZ3JhbQpwcm9qZWN0CnByb21vdGUKcHJvb2YKcHJvcGVydHkKcHJvc3Blcgpwcm90ZWN0CnByb3VkCnByb3ZpZGUKcHVibGljCnB1ZGRpbmcKcHVsbApwdWxwCnB1bHNlCnB1bXBraW4KcHVuY2gKcHVwaWwKcHVwcHkKcHVyY2hhc2UKcHVyaXR5CnB1cnBvc2UKcHVyc2UKcHVzaApwdXQKcHV6emxlCnB5cmFtaWQKcXVhbGl0eQpxdWFudHVtCnF1YXJ0ZXIKcXVlc3Rpb24KcXVpY2sKcXVpdApxdWl6CnF1b3RlCnJhYmJpdApyYWNjb29uCnJhY2UKcmFjawpyYWRhcgpyYWRpbwpyYWlsCnJhaW4KcmFpc2UKcmFsbHkKcmFtcApyYW5jaApyYW5kb20KcmFuZ2UKcmFwaWQKcmFyZQpyYXRlCnJhdGhlcgpyYXZlbgpyYXcKcmF6b3IKcmVhZHkKcmVhbApyZWFzb24KcmViZWwKcmVidWlsZApyZWNhbGwKcmVjZWl2ZQpyZWNpcGUKcmVjb3JkCnJlY3ljbGUKcmVkdWNlCnJlZmxlY3QKcmVmb3JtCnJlZnVzZQpyZWdpb24KcmVncmV0CnJlZ3VsYXIKcmVqZWN0CnJlbGF4CnJlbGVhc2UKcmVsaWVmCnJlbHkKcmVtYWluCnJlbWVtYmVyCnJlbWluZApyZW1vdmUKcmVuZGVyCnJlbmV3CnJlbnQKcmVvcGVuCnJlcGFpcgpyZXBlYXQKcmVwbGFjZQpyZXBvcnQKcmVxdWlyZQpyZXNjdWUKcmVzZW1ibGUKcmVzaXN0CnJlc291cmNlCnJlc3BvbnNlCnJlc3VsdApyZXRpcmUKcmV0cmVhdApyZXR1cm4KcmV1bmlvbgpyZXZlYWwKcmV2aWV3CnJld2FyZApyaHl0aG0KcmliCnJpYmJvbgpyaWNlCnJpY2gKcmlkZQpyaWRnZQpyaWZsZQpyaWdodApyaWdpZApyaW5nCnJpb3QKcmlwcGxlCnJpc2sKcml0dWFsCnJpdmFsCnJpdmVyCnJvYWQKcm9hc3QKcm9ib3QKcm9idXN0CnJvY2tldApyb21hbmNlCnJvb2YKcm9va2llCnJvb20Kcm9zZQpyb3RhdGUKcm91Z2gKcm91bmQKcm91dGUKcm95YWwKcnViYmVyCnJ1ZGUKcnVnCnJ1bGUKcnVuCnJ1bndheQpydXJhbApzYWQKc2FkZGxlCnNhZG5lc3MKc2FmZQpzYWlsCnNhbGFkCnNhbG1vbgpzYWxvbgpzYWx0CnNhbHV0ZQpzYW1lCnNhbXBsZQpzYW5kCnNhdGlzZnkKc2F0b3NoaQpzYXVjZQpzYXVzYWdlCnNhdmUKc2F5CnNjYWxlCnNjYW4Kc2NhcmUKc2NhdHRlcgpzY2VuZQpzY2hlbWUKc2Nob29sCnNjaWVuY2UKc2Npc3NvcnMKc2NvcnBpb24Kc2NvdXQKc2NyYXAKc2NyZWVuCnNjcmlwdApzY3J1YgpzZWEKc2VhcmNoCnNlYXNvbgpzZWF0CnNlY29uZApzZWNyZXQKc2VjdGlvbgpzZWN1cml0eQpzZWVkCnNlZWsKc2VnbWVudApzZWxlY3QKc2VsbApzZW1pbmFyCnNlbmlvcgpzZW5zZQpzZW50ZW5jZQpzZXJpZXMKc2VydmljZQpzZXNzaW9uCnNldHRsZQpzZXR1cApzZXZlbgpzaGFkb3cKc2hhZnQKc2hhbGxvdwpzaGFyZQpzaGVkCnNoZWxsCnNoZXJpZmYKc2hpZWxkCnNoaWZ0CnNoaW5lCnNoaXAKc2hpdmVyCnNob2NrCnNob2UKc2hvb3QKc2hvcApzaG9ydApzaG91bGRlcgpzaG92ZQpzaHJpbXAKc2hydWcKc2h1ZmZsZQpzaHkKc2libGluZwpzaWNrCnNpZGUKc2llZ2UKc2lnaHQKc2lnbgpzaWxlbnQKc2lsawpzaWxseQpzaWx2ZXIKc2ltaWxhcgpzaW1wbGUKc2luY2UKc2luZwpzaXJlbgpzaXN0ZXIKc2l0dWF0ZQpzaXgKc2l6ZQpza2F0ZQpza2V0Y2gKc2tpCnNraWxsCnNraW4Kc2tpcnQKc2t1bGwKc2xhYgpzbGFtCnNsZWVwCnNsZW5kZXIKc2xpY2UKc2xpZGUKc2xpZ2h0CnNsaW0Kc2xvZ2FuCnNsb3QKc2xvdwpzbHVzaApzbWFsbApzbWFydApzbWlsZQpzbW9rZQpzbW9vdGgKc25hY2sKc25ha2UKc25hcApzbmlmZgpzbm93CnNvYXAKc29jY2VyCnNvY2lhbApzb2NrCnNvZGEKc29mdApzb2xhcgpzb2xkaWVyCnNvbGlkCnNvbHV0aW9uCnNvbHZlCnNvbWVvbmUKc29uZwpzb29uCnNvcnJ5CnNvcnQKc291bApzb3VuZApzb3VwCnNvdXJjZQpzb3V0aApzcGFjZQpzcGFyZQpzcGF0aWFsCnNwYXduCnNwZWFrCnNwZWNpYWwKc3BlZWQKc3BlbGwKc3BlbmQKc3BoZXJlCnNwaWNlCnNwaWRlcgpzcGlrZQpzcGluCnNwaXJpdApzcGxpdApzcG9pbApzcG9uc29yCnNwb29uCnNwb3J0CnNwb3QKc3ByYXkKc3ByZWFkCnNwcmluZwpzcHkKc3F1YXJlCnNxdWVlemUKc3F1aXJyZWwKc3RhYmxlCnN0YWRpdW0Kc3RhZmYKc3RhZ2UKc3RhaXJzCnN0YW1wCnN0YW5kCnN0YXJ0CnN0YXRlCnN0YXkKc3RlYWsKc3RlZWwKc3RlbQpzdGVwCnN0ZXJlbwpzdGljawpzdGlsbApzdGluZwpzdG9jawpzdG9tYWNoCnN0b25lCnN0b29sCnN0b3J5CnN0b3ZlCnN0cmF0ZWd5CnN0cmVldApzdHJpa2UKc3Ryb25nCnN0cnVnZ2xlCnN0dWRlbnQKc3R1ZmYKc3R1bWJsZQpzdHlsZQpzdWJqZWN0CnN1Ym1pdApzdWJ3YXkKc3VjY2VzcwpzdWNoCnN1ZGRlbgpzdWZmZXIKc3VnYXIKc3VnZ2VzdApzdWl0CnN1bW1lcgpzdW4Kc3VubnkKc3Vuc2V0CnN1cGVyCnN1cHBseQpzdXByZW1lCnN1cmUKc3VyZmFjZQpzdXJnZQpzdXJwcmlzZQpzdXJyb3VuZApzdXJ2ZXkKc3VzcGVjdApzdXN0YWluCnN3YWxsb3cKc3dhbXAKc3dhcApzd2FybQpzd2Vhcgpzd2VldApzd2lmdApzd2ltCnN3aW5nCnN3aXRjaApzd29yZApzeW1ib2wKc3ltcHRvbQpzeXJ1cApzeXN0ZW0KdGFibGUKdGFja2xlCnRhZwp0YWlsCnRhbGVudAp0YWxrCnRhbmsKdGFwZQp0YXJnZXQKdGFzawp0YXN0ZQp0YXR0b28KdGF4aQp0ZWFjaAp0ZWFtCnRlbGwKdGVuCnRlbmFudAp0ZW5uaXMKdGVudAp0ZXJtCnRlc3QKdGV4dAp0aGFuawp0aGF0CnRoZW1lCnRoZW4KdGhlb3J5CnRoZXJlCnRoZXkKdGhpbmcKdGhpcwp0aG91Z2h0CnRocmVlCnRocml2ZQp0aHJvdwp0aHVtYgp0aHVuZGVyCnRpY2tldAp0aWRlCnRpZ2VyCnRpbHQKdGltYmVyCnRpbWUKdGlueQp0aXAKdGlyZWQKdGlzc3VlCnRpdGxlCnRvYXN0CnRvYmFjY28KdG9kYXkKdG9kZGxlcgp0b2UKdG9nZXRoZXIKdG9pbGV0CnRva2VuCnRvbWF0bwp0b21vcnJvdwp0b25lCnRvbmd1ZQp0b25pZ2h0CnRvb2wKdG9vdGgKdG9wCnRvcGljCnRvcHBsZQp0b3JjaAp0b3JuYWRvCnRvcnRvaXNlCnRvc3MKdG90YWwKdG91cmlzdAp0b3dhcmQKdG93ZXIKdG93bgp0b3kKdHJhY2sKdHJhZGUKdHJhZmZpYwp0cmFnaWMKdHJhaW4KdHJhbnNmZXIKdHJhcAp0cmFzaAp0cmF2ZWwKdHJheQp0cmVhdAp0cmVlCnRyZW5kCnRyaWFsCnRyaWJlCnRyaWNrCnRyaWdnZXIKdHJpbQp0cmlwCnRyb3BoeQp0cm91YmxlCnRydWNrCnRydWUKdHJ1bHkKdHJ1bXBldAp0cnVzdAp0cnV0aAp0cnkKdHViZQp0dWl0aW9uCnR1bWJsZQp0dW5hCnR1bm5lbAp0dXJrZXkKdHVybgp0dXJ0bGUKdHdlbHZlCnR3ZW50eQp0d2ljZQp0d2luCnR3aXN0CnR3bwp0eXBlCnR5cGljYWwKdWdseQp1bWJyZWxsYQp1bmFibGUKdW5hd2FyZQp1bmNsZQp1bmNvdmVyCnVuZGVyCnVuZG8KdW5mYWlyCnVuZm9sZAp1bmhhcHB5CnVuaWZvcm0KdW5pcXVlCnVuaXQKdW5pdmVyc2UKdW5rbm93bgp1bmxvY2sKdW50aWwKdW51c3VhbAp1bnZlaWwKdXBkYXRlCnVwZ3JhZGUKdXBob2xkCnVwb24KdXBwZXIKdXBzZXQKdXJiYW4KdXJnZQp1c2FnZQp1c2UKdXNlZAp1c2VmdWwKdXNlbGVzcwp1c3VhbAp1dGlsaXR5CnZhY2FudAp2YWN1dW0KdmFndWUKdmFsaWQKdmFsbGV5CnZhbHZlCnZhbgp2YW5pc2gKdmFwb3IKdmFyaW91cwp2YXN0CnZhdWx0CnZlaGljbGUKdmVsdmV0CnZlbmRvcgp2ZW50dXJlCnZlbnVlCnZlcmIKdmVyaWZ5CnZlcnNpb24KdmVyeQp2ZXNzZWwKdmV0ZXJhbgp2aWFibGUKdmlicmFudAp2aWNpb3VzCnZpY3RvcnkKdmlkZW8Kdmlldwp2aWxsYWdlCnZpbnRhZ2UKdmlvbGluCnZpcnR1YWwKdmlydXMKdmlzYQp2aXNpdAp2aXN1YWwKdml0YWwKdml2aWQKdm9jYWwKdm9pY2UKdm9pZAp2b2xjYW5vCnZvbHVtZQp2b3RlCnZveWFnZQp3YWdlCndhZ29uCndhaXQKd2Fsawp3YWxsCndhbG51dAp3YW50CndhcmZhcmUKd2FybQp3YXJyaW9yCndhc2gKd2FzcAp3YXN0ZQp3YXRlcgp3YXZlCndheQp3ZWFsdGgKd2VhcG9uCndlYXIKd2Vhc2VsCndlYXRoZXIKd2ViCndlZGRpbmcKd2Vla2VuZAp3ZWlyZAp3ZWxjb21lCndlc3QKd2V0CndoYWxlCndoYXQKd2hlYXQKd2hlZWwKd2hlbgp3aGVyZQp3aGlwCndoaXNwZXIKd2lkZQp3aWR0aAp3aWZlCndpbGQKd2lsbAp3aW4Kd2luZG93CndpbmUKd2luZwp3aW5rCndpbm5lcgp3aW50ZXIKd2lyZQp3aXNkb20Kd2lzZQp3aXNoCndpdG5lc3MKd29sZgp3b21hbgp3b25kZXIKd29vZAp3b29sCndvcmQKd29yawp3b3JsZAp3b3JyeQp3b3J0aAp3cmFwCndyZWNrCndyZXN0bGUKd3Jpc3QKd3JpdGUKd3JvbmcKeWFyZAp5ZWFyCnllbGxvdwp5b3UKeW91bmcKeW91dGgKemVicmEKemVybwp6b25lCnpvbwptbmVtb25pY5RuEgAIAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZTw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAzG4SAB4AAAACAAAAAgAAAGJpcDM5OjplcnJvcjo6RXJyb3JLaW5kaW52YWxpZCBlbnRyb3B5IGxlbmd0aCBiaXRzIGZvciBtbmVtb25pYyB0eXBlIAAAABNvEgAXAAAAKm8SABcAAABpbnZhbGlkIG51bWJlciBvZiB3b3JkcyBpbiBwaHJhc2U6IABUbxIAIwAAAGludmFsaWQga2V5c2l6ZTogAAAAgG8SABEAAABpbnZhbGlkIHdvcmQgaW4gcGhyYXNlAACcbxIAFgAAAGludmFsaWQgY2hlY2tzdW28bxIAEAAAAEludmFsaWRFbnRyb3B5TGVuZ3RoQwAAAAQAAAAEAAAAIAAAAEQAAAAEAAAABAAAAEIAAABJbnZhbGlkV29yZExlbmd0aEludmFsaWRLZXlzaXplSW52YWxpZFdvcmRJbnZhbGlkQ2hlY2tzdW1Xb3JkczI0V29yZHMyMVdvcmRzMThXb3JkczE1V29yZHMxMi9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL3NsaWNlL21vZC5yc2RwEgBIAAAAQxIAABUAAAAAAAAAYXR0ZW1wdCB0byBkaXZpZGUgYnkgemVyb2Fzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6IAAAANlwEgAtAAAABnESAAwAAAAScRIAAwAAAGRlc3RpbmF0aW9uIGFuZCBzb3VyY2Ugc2xpY2VzIGhhdmUgZGlmZmVyZW50IGxlbmd0aHMwcRIANAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL21hY3Jvcy9tb2QucnMAAABscRIASQAAABIAAAANAAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2Jsb2NrLWJ1ZmZlci0wLjcuMC9zcmMvbGliLnJzAADIcRIAWgAAAF0AAAAJAAAAPDo6c3RkOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAAA0chIAHQAAAAIAAAAEAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYAAAZHISAC0AAACRchIADAAAAJ1yEgABAAAANHISAB0AAAAFAAAABgAAAGFzc2VydGlvbiBmYWlsZWQ6IDQgPD0gYnVmLmxlbigpYXNzZXJ0aW9uIGZhaWxlZDogOCA8PSBidWYubGVuKCkvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvYmxvY2stYnVmZmVyLTAuNy4wL3NyYy9saWIucnMAAAhzEgBaAAAAXQAAAAkAAAA8OjpzdGQ6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAAHRzEgAdAAAAAgAAAAQAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgAACkcxIALQAAANFzEgAMAAAA3XMSAAEAAAB0cxIAHQAAAAUAAAAGAAAAYXNzZXJ0aW9uIGZhaWxlZDogOCA8PSBidWYubGVuKCln5glqha5nu3Lzbjw69U+lf1IOUYxoBZur2YMfGc3gWwjJvPNn5glqO6fKhIWuZ7sr+JT+cvNuPPE2HV869U+l0YLmrX9SDlEfbD4rjGgFm2u9Qfur2YMfeSF+ExnN4FtGAAAACAAAAAQAAABHAAAASAAAAEkAAAAIAAAABAAAAEoAAABHZW5lcmljQXJyYXk6OmZyb21faXRlciByZWNlaXZlZCAgZWxlbWVudHMgYnV0IGV4cGVjdGVkIKx0EgAhAAAAzXQSABcAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvZ2VuZXJpYy1hcnJheS0wLjEyLjAvc3JjL2xpYi5yc/R0EgBcAAAAQAEAAAUAAABMAAAABAAAAAQAAABNAAAATgAAAE8AAAAEAAAABAAAAFAAAABRAAAAUgAAAAQAAAAEAAAAUwAAAFQAAABPbmNlIGluc3RhbmNlIGhhcyBwcmV2aW91c2x5IGJlZW4gcG9pc29uZWQvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcGFya2luZ19sb3QtMC43LjEvc3JjL29uY2UucnPGdRIAWgAAAPIAAAARAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZcZ1EgBaAAAAHgEAACgAAABjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlAFYAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcGFya2luZ19sb3RfY29yZS0wLjQuMC9zcmMvcGFya2luZ19sb3QucnMAAJh2EgBmAAAAugAAAAUAAACYdhIAZgAAABcBAAAQAAAAmHYSAGYAAAAeAQAADQAAAJh2EgBmAAAAQAEAABMAAACYdhIAZgAAAFkBAAATAAAAVHJpZWQgdG8gc2hyaW5rIHRvIGEgbGFyZ2VyIGNhcGFjaXR5PDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+AAB0dxIAHgAAAAIAAAACAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZUZyb21FbnRyb3B5Ojpmcm9tX2VudHJvcHkoKSBmYWlsZWQ6IMx3EgAkAAAAPDo6c3RkOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAAD4dxIAHQAAAAUAAAAGAAAAY2FsbGVkIGBPcHRpb246OnVud3JhcCgpYCBvbiBhIGBOb25lYCB2YWx1ZQBZAAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL3BhcmtpbmdfbG90X2NvcmUtMC40LjAvc3JjL3dvcmRfbG9jay5yc1h4EgBkAAAASQAAAAUAAABhc3NlcnRpb24gZmFpbGVkOiBuZXdfY2FwID49IGxlbjw6OnN0ZDo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+AAAA7HgSAB0AAAACAAAABAAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4L3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC9tYWNyb3MucnM8eRIARAAAAA0AAAAXAAAAUG9pc29uRXJyb3IgeyBpbm5lcjogLi4gfWNhbGxlZCBgUmVzdWx0Ojp1bndyYXAoKWAgb24gYW4gYEVycmAgdmFsdWVaAAAACAAAAAQAAABbAAAAXAAAAAwAAAAEAAAAXQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9wYXJraW5nX2xvdF9jb3JlLTAuNC4wL3NyYy90aHJlYWRfcGFya2VyL2dlbmVyaWMucnP0eRIAcAAAACcAAAAVAAAA9HkSAHAAAAAuAAAAGAAAAPR5EgBwAAAAMAAAABQAAAD0eRIAcAAAADgAAAAYAAAA9HkSAHAAAAA+AAAAIQAAAPR5EgBwAAAASgAAABUAAABfAAAAY291bGQgbm90IGluaXRpYWxpemUgdGhyZWFkX3JuZzogAAAAyHoSACEAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcmFuZC0wLjYuNS9zcmMvcm5ncy90aHJlYWQucnMAAPR6EgBaAAAAUAAAABEAAABjYW5ub3QgYWNjZXNzIGEgVGhyZWFkIExvY2FsIFN0b3JhZ2UgdmFsdWUgZHVyaW5nIG9yIGFmdGVyIGRlc3RydWN0aW9uL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC90aHJlYWQvbG9jYWwucnOmexIASgAAAO8AAAAJAAAAYAAAAAAAAAABAAAAYQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kLTAuNi41L3NyYy9ybmdzL2VudHJvcHkucnNObyBlbnRyb3B5IHNvdXJjZXMgYXZhaWxhYmxlQWxsIGVudHJvcHkgc291cmNlcyBmYWlsZWRpbnRlcm5hbCBlcnJvcjogZW50ZXJlZCB1bnJlYWNoYWJsZSBjb2RlAAAAEHwSAFsAAAC6AAAACQAAAGFzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6INx8EgAtAAAACX0SAAwAAAAVfRIAAwAAAGRlc3RpbmF0aW9uIGFuZCBzb3VyY2Ugc2xpY2VzIGhhdmUgZGlmZmVyZW50IGxlbmd0aHMwfRIANAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL21hY3Jvcy9tb2QucnMAAABsfRIASQAAABIAAAANAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogyH0SAC0AAAD1fRIADAAAAAF+EgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Rocxx+EgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAFh+EgBJAAAAEgAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLmNvdW50ZXIxMDI0ICUgMTYgPT0gMC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kX2hjLTAuMS4wL3NyYy9oYzEyOC5ycwDgfhIAVwAAAH0AAAAJAAAA4H4SAFcAAADhAAAACQAAAOB+EgBXAAAA/AAAAA0AAADgfhIAVwAAAP0AAAANAAAA4H4SAFcAAAD+AAAADQAAAOB+EgBXAAAA/wAAAA0AAADgfhIAVwAAAAABAAANAAAA4H4SAFcAAAABAQAADQAAAOB+EgBXAAAAAgEAAA0AAADgfhIAVwAAAAMBAAANAAAA4H4SAFcAAAAEAQAADQAAAOB+EgBXAAAABQEAAA0AAADgfhIAVwAAAAYBAAANAAAA4H4SAFcAAAAHAQAADQAAAOB+EgBXAAAACAEAAA0AAADgfhIAVwAAAAkBAAANAAAA4H4SAFcAAAAKAQAADQAAAHJldHVybiB0aGlzYXNzZXJ0aW9uIGZhaWxlZDogdGhpcyAhPSBKc1ZhbHVlOjp1bmRlZmluZWQoKS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kX29zLTAuMS4zL3NyYy93YXNtMzJfYmluZGdlbi5ycwAAAIGAEgBgAAAAIQAAAAkAAABjcnlwdG9zZWxmLmNyeXB0byBpcyB1bmRlZmluZWRjcnlwdG8uZ2V0UmFuZG9tVmFsdWVzIGlzIHVuZGVmaW5lZAAAAGMAAAAIAAAABAAAAGQAAABlAAAAZgAAAAgAAAAEAAAAZwAAAGludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGUvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcmFuZF9jb3JlLTAuNC4yL3NyYy9lcnJvci5ycwAAAISBEgBZAAAASgAAACsAAABub3QgcmVhZHkgeWV0dHJhbnNpZW50IGZhaWx1cmV1bmV4cGVjdGVkIGZhaWx1cmVwZXJtYW5lbnRseSB1bmF2YWlsYWJsZSAoKQAAN4ISAAAAAAA3ghIAAgAAADmCEgABAAAAKTsgY2F1c2U6IAAAN4ISAAAAAAA3ghIAAgAAAFSCEgAKAAAAX19Ob25leGhhdXN0aXZlTm90UmVhZHlUcmFuc2llbnRVbmV4cGVjdGVkVW5hdmFpbGFibGVFcnJvcmtpbmQAAGoAAAAEAAAABAAAAGsAAABtc2cAbAAAAAQAAAAEAAAAHgAAAGNhdXNlAAAAbQAAAAQAAAAEAAAAbgAAAFNvbWVvAAAABAAAAAQAAABwAAAATm9uZXEAAAAUAAAABAAAAHIAAABzAAAAdAAAAHUAAAB2AAAAVwAAAHcAAAAKCgAANIMSAAAAAAA0gxIAAgAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4L3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC9tYWNyb3MucnNogxIARAAAAA0AAAAXAAAAY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQB6AAAACAAAAAQAAAB7AAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2ZhaWx1cmUtMC4xLjUvc3JjL2JhY2t0cmFjZS9pbnRlcm5hbC5yc/iDEgBkAAAAOgAAABwAAABSVVNUX0ZBSUxVUkVfQkFDS1RSQUNFMFJVU1RfQkFDS1RSQUNFUG9pc29uRXJyb3IgeyBpbm5lcjogLi4gfWludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGU8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz7ShBIAHgAAAAIAAAACAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogAIUSAC0AAAAthRIADAAAADmFEgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc1SFEgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAJCFEgBJAAAAEgAAAA0AAAB9AAAACAAAAAQAAAB+AAAAfwAAAIAAAAAIAAAABAAAAIEAAACCAAAABAAAAAQAAACDAAAAhAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJzdGQvc3luYy9vbmNlLnJzACSGEgBHAAAACAEAACkAAABjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQAAhQAAAAgAAAAEAAAAhgAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9iYWNrdHJhY2UtMC4zLjM4L3NyYy9saWIucnOHAAAA5IYSAFgAAACUAAAAHAAAAFBvaXNvbkVycm9yIHsgaW5uZXI6IC4uIH1zdGFjayBiYWNrdHJhY2U6CgAAOiAAAHyHEgAAAAAAfIcSAAIAAAAAAAAAIAAAAAAAAAACAEGoj8oAC4ojBAAAAAMAAAAgLSAAfIcSAAAAAACwhxIAAwAAAAoAAAAAAAAAIAAAAAAAAAACAAAAAAAAAAEAAAABAAAAAwAAACAgICAgIAAA6IcSAAYAAAB8hxIAAAAAAA0AAAAAAAAAIAAAAAQAAAACAAAAAAAAAAIAAAAAAAAAAwAAADx1bmtub3duPgAAACSIEgAJAAAACiAgICAgICAgICAgICBhdCAAAAA5iBIAEAAAADoAAABUiBIAAQAAADiIEgABAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9iYWNrdHJhY2UtMC4zLjM4L3NyYy90eXBlcy5ycwAAkIgSAFoAAABKAAAACQAAAIsAAAAUAAAABAAAAIwAAACNAAAA77+9Y2Fubm90IHJlY3Vyc2l2ZWx5IGFjcXVpcmUgbXV0ZXgvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGlic3RkL21hY3Jvcy5ycwAziRIARAAAAA0AAAAXAAAAY2Fubm90IGFjY2VzcyBhIFRocmVhZCBMb2NhbCBTdG9yYWdlIHZhbHVlIGR1cmluZyBvciBhZnRlciBkZXN0cnVjdGlvbi9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJzdGQvdGhyZWFkL2xvY2FsLnJzzokSAEoAAADvAAAACQAAAI8AAAAAAAAAAQAAAGEAAABhc3NlcnRpb24gZmFpbGVkOiBzbG90LmdldCgpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JhY2t0cmFjZS0wLjMuMzgvc3JjL2xpYi5yc1SKEgBYAAAAhAAAABUAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9zdHIvcGF0dGVybi5ycwAAvIoSAEoAAACCBAAAIQAAALyKEgBKAAAAjgQAABQAAAC8ihIASgAAAI4EAAAhAAAAvIoSAEoAAADZBAAAFAAAALyKEgBKAAAA2QQAACEAAAC8ihIASgAAAOUEAAAUAAAAvIoSAEoAAADlBAAAIQAAAGNhbGxlZCBgT3B0aW9uOjp1bndyYXAoKWAgb24gYSBgTm9uZWAgdmFsdWVjYWxsZWQgYFJlc3VsdDo6dW53cmFwKClgIG9uIGFuIGBFcnJgIHZhbHVlAACQAAAAAQAAAAEAAACRAAAALmxsdm0uRS5fWk5aTl9fWk4vaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcnVzdGMtZGVtYW5nbGUtMC4xLjEzL3NyYy9saWIucnMAAPGLEgBdAAAAAgEAABMAAADxixIAXQAAAAUBAAAcAAAAOjpfJC4kU1AkQCRCUCQqJFJGJCYkTFQkPCRHVCQ+JExQJCgkUlAkKSRDJCwkdTdlJH4kdTIwJCAkdTI3JCckdTNkJD0kdTViJFskdTVkJF0kdTdiJHskdTdkJH0kdTNiJDskdTJiJCskdTIxJCEkdTIyJCKUAAAABAAAAAQAAACVAAAAlgAAAJcAAACUAAAABAAAAAQAAACYAAAAYWxyZWFkeSBib3Jyb3dlZC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL2NlbGwucnMAHI0SAEMAAABuAwAACQAAAGFscmVhZHkgbXV0YWJseSBib3Jyb3dlZByNEgBDAAAAHgMAAAkAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgAACYjRIALQAAAMWNEgAMAAAA0Y0SAAEAAACUAAAAAAAAAAEAAACZAAAAYDogAJiNEgAtAAAAxY0SAAwAAAD8jRIAAwAAAGNhbGxlZCBgT3B0aW9uOjp1bndyYXAoKWAgb24gYSBgTm9uZWAgdmFsdWUAlAAAAAAAAAABAAAAmgAAAJsAAAAQAAAABAAAAJwAAACUAAAAAAAAAAEAAACdAAAAY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQCeAAAACAAAAAQAAACfAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZTw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAA2I4SAB4AAAACAAAAAgAAAFRyaWVkIHRvIHNocmluayB0byBhIGxhcmdlciBjYXBhY2l0eZQAAAAEAAAABAAAAJIAAABBY2Nlc3NFcnJvcnNyYy9saWJzdGQvdGhyZWFkL21vZC5ycwBHjxIAGAAAAIYDAAARAAAAaW5jb25zaXN0ZW50IHBhcmsgc3RhdGUAR48SABgAAACUAwAAEwAAAAIAAABwYXJrIHN0YXRlIGNoYW5nZWQgdW5leHBlY3RlZGx5AJyPEgAfAAAAR48SABgAAACRAwAADQAAAGZhaWxlZCB0byBnZW5lcmF0ZSB1bmlxdWUgdGhyZWFkIElEOiBiaXRzcGFjZSBleGhhdXN0ZWQAR48SABgAAAAqBAAAEQAAAEePEgAYAAAAMAQAABYAAAB0aHJlYWQgbmFtZSBtYXkgbm90IGNvbnRhaW4gaW50ZXJpb3IgbnVsbCBieXRlcwBHjxIAGAAAAHMEAAAaAAAAaW5jb25zaXN0ZW50IHN0YXRlIGluIHVucGFya0ePEgAYAAAAqwQAABIAAABHjxIAGAAAALkEAAAOAAAAoAAAAAwAAAAEAAAAoQAAAKIAAACjAAAApAAAAKEAAAClAAAApgAAAC5zcmMvbGlic3RkL3BhdGgucnMuLgAAANGQEgASAAAAiwMAACAAAABhdHRlbXB0ZWQgdG8gdXNlIGEgY29uZGl0aW9uIHZhcmlhYmxlIHdpdGggdHdvIG11dGV4ZXNzcmMvbGlic3RkL3N5bmMvY29uZHZhci5ycy6REgAaAAAAPwIAABIAAABzcmMvbGlic3RkL3N5bmMvb25jZS5yc2Fzc2VydGlvbiBmYWlsZWQ6IHN0YXRlX2FuZF9xdWV1ZSAmIFNUQVRFX01BU0sgPT0gUlVOTklOR1iREgAXAAAApwEAABUAAABPbmNlIGluc3RhbmNlIGhhcyBwcmV2aW91c2x5IGJlZW4gcG9pc29uZWQAAFiREgAXAAAAiwEAABUAAABYkRIAFwAAAOgBAAAJAAAAWJESABcAAAD0AQAAHgAAAHN1cHBsaWVkIGluc3RhbnQgaXMgbGF0ZXIgdGhhbiBzZWxmc3JjL2xpYnN0ZC90aW1lLnJzAAAAN5ISABIAAAAHAQAACQAAAFBvaXNvbkVycm9yIHsgaW5uZXI6IC4uIH1zcmMvbGlic3RkL3Bhbmlja2luZy5yc3WSEgAXAAAAeAEAAA8AAAB1khIAFwAAAHkBAAAPAAAApwAAABAAAAAEAAAAqAAAAKkAAACgAAAADAAAAAQAAACqAAAAlAAAAAgAAAAEAAAAqwAAAKwAAACUAAAACAAAAAQAAACtAAAATnVsRXJyb3KUAAAABAAAAAQAAACuAAAAdGltZSBub3QgaW1wbGVtZW50ZWQgb24gd2FzbTMyLXVua25vd24tdW5rbm93bnNyYy9saWJzdGQvc3lzL3dhc20vdGltZS5ycwAAADqTEgAbAAAADQAAAAkAAABvcGVyYXRpb24gbm90IHN1cHBvcnRlZCBvbiB3YXNtIHlldGNhbid0IGJsb2NrIHdpdGggd2ViIGFzc2VtYmx5c3JjL2xpYnN0ZC9zeXMvd2FzbS9jb25kdmFyLnJzAACokxIAHgAAABUAAAAJAAAAqJMSAB4AAAAZAAAACQAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4c3JjL2xpYnN0ZC9zeXMvd2FzbS9tdXRleC5ycwiUEgAcAAAAFQAAAAkAAACvAAAABAAAAAQAAACwAAAAsQAAALIAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9mbXQvbW9kLnJzAABMlBIARgAAAFgBAAATAAAArwAAAAAAAAABAAAAswAAAGEgZm9ybWF0dGluZyB0cmFpdCBpbXBsZW1lbnRhdGlvbiByZXR1cm5lZCBhbiBlcnJvcnNyYy9saWJhbGxvYy9mbXQucnMAAOeUEgATAAAAOwIAAAUAAABzcmMvbGliYWxsb2MvcmF3X3ZlYy5yc2NhcGFjaXR5IG92ZXJmbG93DJUSABcAAADrAgAABQAAAGAALi5GlRIAAgAAAEJvcnJvd0Vycm9yQm9ycm93TXV0RXJyb3JjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlRJUSAAAAAAA6IAAARJUSAAAAAACclRIAAgAAALkAAAAAAAAAAQAAALoAAABpbmRleCBvdXQgb2YgYm91bmRzOiB0aGUgbGVuIGlzICBidXQgdGhlIGluZGV4IGlzIAAAwJUSACAAAADglRIAEgAAALkAAAAMAAAABAAAALsAAAC8AAAAvQAAACAgICAgewosCiwgIHsgfSB9KAooLCkKW10weDBiMDAwMTAyMDMwNDA1MDYwNzA4MDkxMDExMTIxMzE0MTUxNjE3MTgxOTIwMjEyMjIzMjQyNTI2MjcyODI5MzAzMTMyMzMzNDM1MzYzNzM4Mzk0MDQxNDI0MzQ0NDU0NjQ3NDg0OTUwNTE1MjUzNTQ1NTU2NTc1ODU5NjA2MTYyNjM2NDY1NjY2NzY4Njk3MDcxNzI3Mzc0NzU3Njc3Nzg3OTgwODE4MjgzODQ4NTg2ODc4ODg5OTA5MTkyOTM5NDk1OTY5Nzk4OTkAAAC5AAAABAAAAAQAAAC+AAAAvwAAAMAAAABzcmMvbGliY29yZS9mbXQvbW9kLnJzAAAclxIAFgAAADwEAAARAAAAHJcSABYAAABGBAAAJAAAAHRydWVmYWxzZXNyYy9saWJjb3JlL3NsaWNlL21vZC5yc2luZGV4ICBvdXQgb2YgcmFuZ2UgZm9yIHNsaWNlIG9mIGxlbmd0aCAAAAB1lxIABgAAAHuXEgAiAAAAXZcSABgAAACxCgAABQAAAHNsaWNlIGluZGV4IHN0YXJ0cyBhdCAgYnV0IGVuZHMgYXQgAMCXEgAWAAAA1pcSAA0AAABdlxIAGAAAALcKAAAFAAAAc3JjL2xpYmNvcmUvc3RyL3BhdHRlcm4ucnMAAASYEgAaAAAAEAUAABUAAAAEmBIAGgAAAD4FAAAVAAAABJgSABoAAAA/BQAAFQAAAGFzc2VydGlvbiBmYWlsZWQ6IGJyb2tlbi5pc19lbXB0eSgpc3JjL2xpYmNvcmUvc3RyL2xvc3N5LnJzAHOYEgAYAAAAnQAAABEAAABzcmMvbGliY29yZS9zdHIvbW9kLnJzAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAQfSyygALMwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDAwMDAwMDAwMEBAQEBABBsrPKAAuZDlsuLi5dYnl0ZSBpbmRleCAgaXMgb3V0IG9mIGJvdW5kcyBvZiBgt5kSAAsAAADCmRIAFgAAAESVEgABAAAAnJgSABYAAACSCAAACQAAAGJlZ2luIDw9IGVuZCAoIDw9ICkgd2hlbiBzbGljaW5nIGAAAACaEgAOAAAADpoSAAQAAAASmhIAEAAAAESVEgABAAAAnJgSABYAAACWCAAABQAAAJyYEgAWAAAApwgAAA4AAAAgaXMgbm90IGEgY2hhciBib3VuZGFyeTsgaXQgaXMgaW5zaWRlICAoYnl0ZXMgKSBvZiBgt5kSAAsAAABkmhIAJgAAAIqaEgAIAAAAkpoSAAYAAABElRIAAQAAAJyYEgAWAAAAqQgAAAUAAABzcmMvbGliY29yZS91bmljb2RlL3ByaW50YWJsZS5yc9CaEgAgAAAAGgAAACgAAAAAAQMFBQYGAwcGCAgJEQocCxkMFA0SDg0PBBADEhITCRYBFwUYAhkDGgccAh0BHxYgAysELAItCy4BMAMxAjIBpwKpAqoEqwj6AvsF/QT+A/8JrXh5i42iMFdYi4yQHB3dDg9LTPv8Li8/XF1fteKEjY6RkqmxurvFxsnK3uTl/wAEERIpMTQ3Ojs9SUpdhI6SqbG0urvGys7P5OUABA0OERIpMTQ6O0VGSUpeZGWEkZudyc7PDREpRUlXZGWNkam0urvFyd/k5fAEDRFFSWRlgIGEsry+v9XX8PGDhYukpr6/xcfOz9rbSJi9zcbOz0lOT1dZXl+Jjo+xtre/wcbH1xEWF1tc9vf+/4ANbXHe3w4PH25vHB1ffX6ur7u8+hYXHh9GR05PWFpcXn5/tcXU1dzw8fVyc490dZaXL18mLi+nr7e/x8/X35pAl5gwjx/Awc7/Tk9aWwcIDxAnL+7vbm83PT9CRZCR/v9TZ3XIydDR2Nnn/v8AIF8igt8EgkQIGwQGEYGsDoCrNR4VgOADGQgBBC8ENAQHAwEHBgcRClAPEgdVCAIEHAoJAwgDBwMCAwMDDAQFAwsGAQ4VBToDEQcGBRAHVwcCBxUNUARDAy0DAQQRBg8MOgQdJV8gbQRqJYDIBYKwAxoGgv0DWQcVCxcJFAwUDGoGCgYaBlkHKwVGCiwEDAQBAzELLAQaBgsDgKwGCgYfQUwELQN0CDwDDwM8BzgIKwWC/xEYCC8RLQMgECEPgIwEgpcZCxWIlAUvBTsHAg4YCYCwMHQMgNYaDAWA/wWAtgUkDJvGCtIwEISNAzcJgVwUgLgIgMcwNQQKBjgIRggMBnQLHgNaBFkJgIMYHAoWCUgIgIoGq6QMFwQxoQSB2iYHDAUFgKURgW0QeCgqBkwEgI0EgL4DGwMPDQAGAQEDAQQCCAgJAgoFCwIQAREEEgUTERQCFQIXAhkEHAUdCCQBagNrArwC0QLUDNUJ1gLXAtoB4AXhAugC7iDwBPkG+gIMJzs+Tk+Pnp6fBgcJNj0+VvPQ0QQUGDY3Vle9Nc7P4BKHiY6eBA0OERIpMTQ6RUZJSk5PZGVaXLa3GxyoqdjZCTeQkagHCjs+ZmmPkm9f7u9aYpqbJyhVnaCho6SnqK26vMQGCwwVHTo/RVGmp8zNoAcZGiIlPj/FxgQgIyUmKDM4OkhKTFBTVVZYWlxeYGNlZmtzeH1/iqSqr7DA0Axyo6TLzG5vXiJ7BQMELQNlBAEvLoCCHQMxDxwEJAkeBSsFRAQOKoCqBiQEJAQoCDQLAYCQgTcJFgoIgJg5A2MICTAWBSEDGwUBQDgESwUvBAoHCQdAICcEDAk2AzoFGgcEDAdQSTczDTMHLggKgSYfgIEoCCqAhhcJTgQeD0MOGQcKBkcJJwl1Cz9BKgY7BQoGUQYBBRADBYCLYCBICAqApl4iRQsKBg0TOQcKNiwEEIDAPGRTDAGAoEUbSAhTHTmBB0YKHQNHSTcDDggKBjkHCoE2GYDHMg2Dm2Z1C4DEiryEL4/RgkehuYI5ByoEAmAmCkYKKAUTgrBbZUsEOQcRQAQcl/gIgvOlDYEfMQMRBAiBjIkEawUNAwkHEJNggPYKcwhuF0aAmhQMVwkZgIeBRwOFQg8VhVArgNUtAxoEAoFwOgUBhQCA1ylMBAoEAoMRREw9gMI8BgEEVQUbNAKBDiwEZAxWCg0DXQM9OR0NLAQJBwIOBoCag9YKDQMLBXQMWQcMFAwEOAgKBigIHlJ3AzEDgKYMFAQDBQMNBoVqc3JjL2xpYmNvcmUvdW5pY29kZS9tb2QucnMANaASABoAAAA4AAAADwAAADWgEgAaAAAAOQAAABAAAABraW5kRW1wdHlaZXJvUGFyc2VJbnRFcnJvcgAAuQAAAAQAAAAEAAAAwQAAAFVuZGVyZmxvd092ZXJmbG93SW52YWxpZERpZ2l0RXJyb3IEDxUbGQMSFxEAAA4WAEHnwcoACwIGEwBB/MHKAAsKAgcKAAgMHRwYGgBBmMLKAAsCBQEAQa3CygALDBAAAAAACwAJABQADQBB1sLKAAsCDxIAQeXCygALAR8AQfXCygALBElGZh0AQYXDygALAoo+AEGUw8oACwJLUwBBosPKAAsDZyNCAEGxw8oACwc9AAAAAAAjAEHBw8oACwR1AAAtAEHRw8oACwOCTjwAQeDDygALE2MAAAAlAFoAAAAAAAAAgTYAAAMAQf3DygALAS8AQYbEygALCRAAAAAAABMACABBnMTKAAsFQwByAIkAQavEygALEQcAAAB9BRg/ADeHCUBkAAAhAEHJxMoACwQKAABBAEHZxMoAC0MMADAAXAAAABl3cQBgRzVELgAAdDkRZSxRXn9QAAAANDEAAABTAAAAAAAAOgAAAAA4GgCIXytraV1PXYSAKmgUOwAXAEGpxcoACwhVAABXAAAAgwBBucXKAAsTWQAAAAAAACZuGxYAAAAAAG1KHABB1sXKAAtLJAAAfABSAHsGFQAAAABIAAAAAH4odidsKQAiWw5hDVZwYgSFIHgCAAB6HnkBVAAzAAAAhnNYAE1FbwtqAAAybEwAAImKAACKioo+AEG4xsoAC5wCAQAAAAAAAAANAAAAAAAAABwAAAAAAAAAQAAAAAAAAAC2AAAAAAAAAL8AAAAAAAAA+AMAAAAAAADwBwAAAAAAAP8HAAAAAAAAABAAAAAAAAAAHgAAAAAAAAA4AAAAAAAAAD8AAAAAAACAfwAAAAAAAACAAAAAAAAAwP8BAAAAAACA/wMAAAAAAACABwAAAAAAAAB/AAAAAAABIIAAAAAAAAAAowAAAAAAAPx/AwAAAAAAAAAGAAAAAAAA/wcAAAAAAACACQAAAAAAAAAOAAAAAIAAfg4AAAAAZCAAIAAAAABA/g8gAAAAAAEAADAAAAAAAAAAQAAAAABcAABAAAAAAAAAAGAAAAAAAIRcgAAAAAAAAADAAAAAAAAAAOAAQdzIygALtQYBAAAAAADwDAEAAABEMGAADAAAAME9YAAMAAAAHiCAAAwAAAAeIMAADAAAAP4h/gAMAAAAAAAAACAAAAAAAAAAYAAAAEQIAABgAAAAAAAAAPAAAABgAAAAAAIAAH////nbBwAAAAAAgPgHAAAAAADgvA8AAAAAAAAgIQAAAwAAADw7AADnDwAAADwAAAAAwJ+fPQAAAADA++8+AAAAAAAAwD8AAAAAAAAA8AAAAAAAAAD8AAAQAAD4/v8AAP//AAD//wAA////////AAAA+P//AAABAAAAAADA/wEAAAD/////AQAAAAAAAAADAAAAAAAAgAMAAAAAAECjAwAAAAAAAAAIAAAADAAAAAwABAAAAAD4DwAAAAAAAAAYAAAAHAAAABwAAAAAwwEAHgAAAAAAAAAfAAEAgADAHx8ABwAAAIDvHwD//////x8gAIY5AgAAACMAAgAAAAAwQAAAAAAAAH5mAAAA/P///G0AAAAAAAAAfwAAAAAAACi/AAAAAAAA8M8AAAAAAwAAoAIAAPf//SEQAwMAAAAAAHgGAAAAAACA/wYAAAAAAADABwAAAAAAAPIHAAAAAIcBBA4GAAAAAAAAEAgQAAAAAAAQBwAAAAAAABQPAAAAAADwFwAAAAAAAPIf3+D//v///x8AAAAAAAAAIAAAAAAA+A8gBwAAAAAAyDMAAAAAAACwPwAAAAAAgPc/BAAAAAAAAEAeIIAADAAAQAAAAAAAgNNAAgAAAAAAAFADAAAAAAAAWAAAAAAA4P1m/gcAAAAA+HkDAAAAAADAfwAAAAAAAP5/AAAAAAAA/38AAAAAAAAAgH8AAAAAAACAMAAAAP//A4Bu8AAAAAAAhwIAAAAAAACQAABAf+Uf+J8AAAAAAAD5pQAAAAAAAPinAAAAAACAPLAAAAAAAAB+tAAAAAAAAH+/AAD+/////78RAAAAAAAAwAAAAAAAAJ3BAgAAAAAAANAAAAAAoMMH+P///////3/4//////////u+IQAADAAA/AAAAAAAAAD/AgAAAAAAAP8AAAIAAAD//wAA+P/7////AAAAAP///////////////wMAAAAAAQAABABBq8/KAAsHAQAAAAAAAQBBwc/KAAsDBAADAEHRz8oACwIFAgBB8M/KAAsBAQBB+8/KAAsbgAAAAAAgAAAAAQAAAAA+AAABAAAA/wcAAACDAEGo+soACwE/AEHE+soACwFAAEHY+soACwECAEGA+8oACwECAEGQ+8oACwkCAAAAAAAAAAEAggEJcHJvZHVjZXJzAghsYW5ndWFnZQEEUnVzdAAMcHJvY2Vzc2VkLWJ5AwVydXN0YyUxLjQzLjAtbmlnaHRseSAoMGViODc4ZDJhIDIwMjAtMDItMjgpBndhbHJ1cwUwLjUuMAx3YXNtLWJpbmRnZW4SMC4yLjM5IChlMDc1ZDA0OTIp","base64")}).call(this,A("buffer").Buffer)},{buffer:64}],307:[function(A,e,t){"use strict";const i=(A,e)=>(...t)=>{return`[${A(...t)+e}m`},g=(A,e)=>(...t)=>{const i=A(...t);return`[${38+e};5;${i}m`},r=(A,e)=>(...t)=>{const i=A(...t);return`[${38+e};2;${i[0]};${i[1]};${i[2]}m`},n=A=>A,B=(A,e,t)=>[A,e,t],I=(A,e,t)=>{Object.defineProperty(A,e,{get:()=>{const i=t();return Object.defineProperty(A,e,{value:i,enumerable:!0,configurable:!0}),i},enumerable:!0,configurable:!0})};let o;const a=(e,t,i,g)=>{void 0===o&&(o=A("color-convert"));const r=g?10:0,n={};for(const[A,g]of Object.entries(o)){const B="ansi16"===A?"ansi":A;A===t?n[B]=e(i,r):"object"==typeof g&&(n[B]=e(g[t],r))}return n};Object.defineProperty(e,"exports",{enumerable:!0,get:function(){const A=new Map,e={modifier:{reset:[0,0],bold:[1,22],dim:[2,22],italic:[3,23],underline:[4,24],inverse:[7,27],hidden:[8,28],strikethrough:[9,29]},color:{black:[30,39],red:[31,39],green:[32,39],yellow:[33,39],blue:[34,39],magenta:[35,39],cyan:[36,39],white:[37,39],blackBright:[90,39],redBright:[91,39],greenBright:[92,39],yellowBright:[93,39],blueBright:[94,39],magentaBright:[95,39],cyanBright:[96,39],whiteBright:[97,39]},bgColor:{bgBlack:[40,49],bgRed:[41,49],bgGreen:[42,49],bgYellow:[43,49],bgBlue:[44,49],bgMagenta:[45,49],bgCyan:[46,49],bgWhite:[47,49],bgBlackBright:[100,49],bgRedBright:[101,49],bgGreenBright:[102,49],bgYellowBright:[103,49],bgBlueBright:[104,49],bgMagentaBright:[105,49],bgCyanBright:[106,49],bgWhiteBright:[107,49]}};e.color.gray=e.color.blackBright,e.bgColor.bgGray=e.bgColor.bgBlackBright,e.color.grey=e.color.blackBright,e.bgColor.bgGrey=e.bgColor.bgBlackBright;for(const[t,i]of Object.entries(e)){for(const[t,g]of Object.entries(i))e[t]={open:`[${g[0]}m`,close:`[${g[1]}m`},i[t]=e[t],A.set(g[0],g[1]);Object.defineProperty(e,t,{value:i,enumerable:!1})}return Object.defineProperty(e,"codes",{value:A,enumerable:!1}),e.color.close="",e.bgColor.close="",I(e.color,"ansi",()=>a(i,"ansi16",n,!1)),I(e.color,"ansi256",()=>a(g,"ansi256",n,!1)),I(e.color,"ansi16m",()=>a(r,"rgb",B,!1)),I(e.bgColor,"ansi",()=>a(i,"ansi16",n,!0)),I(e.bgColor,"ansi256",()=>a(g,"ansi256",n,!0)),I(e.bgColor,"ansi16m",()=>a(r,"rgb",B,!0)),e}})},{"color-convert":309}],308:[function(A,e,t){const i=A("color-name"),g={};for(const A of Object.keys(i))g[i[A]]=A;const r={rgb:{channels:3,labels:"rgb"},hsl:{channels:3,labels:"hsl"},hsv:{channels:3,labels:"hsv"},hwb:{channels:3,labels:"hwb"},cmyk:{channels:4,labels:"cmyk"},xyz:{channels:3,labels:"xyz"},lab:{channels:3,labels:"lab"},lch:{channels:3,labels:"lch"},hex:{channels:1,labels:["hex"]},keyword:{channels:1,labels:["keyword"]},ansi16:{channels:1,labels:["ansi16"]},ansi256:{channels:1,labels:["ansi256"]},hcg:{channels:3,labels:["h","c","g"]},apple:{channels:3,labels:["r16","g16","b16"]},gray:{channels:1,labels:["gray"]}};e.exports=r;for(const A of Object.keys(r)){if(!("channels"in r[A]))throw new Error("missing channels property: "+A);if(!("labels"in r[A]))throw new Error("missing channel labels property: "+A);if(r[A].labels.length!==r[A].channels)throw new Error("channel and label counts mismatch: "+A);const{channels:e,labels:t}=r[A];delete r[A].channels,delete r[A].labels,Object.defineProperty(r[A],"channels",{value:e}),Object.defineProperty(r[A],"labels",{value:t})}r.rgb.hsl=function(A){const e=A[0]/255,t=A[1]/255,i=A[2]/255,g=Math.min(e,t,i),r=Math.max(e,t,i),n=r-g;let B,I;r===g?B=0:e===r?B=(t-i)/n:t===r?B=2+(i-e)/n:i===r&&(B=4+(e-t)/n),(B=Math.min(60*B,360))<0&&(B+=360);const o=(g+r)/2;return[B,100*(I=r===g?0:o<=.5?n/(r+g):n/(2-r-g)),100*o]},r.rgb.hsv=function(A){let e,t,i,g,r;const n=A[0]/255,B=A[1]/255,I=A[2]/255,o=Math.max(n,B,I),a=o-Math.min(n,B,I),Q=function(A){return(o-A)/6/a+.5};return 0===a?(g=0,r=0):(r=a/o,e=Q(n),t=Q(B),i=Q(I),n===o?g=i-t:B===o?g=1/3+e-i:I===o&&(g=2/3+t-e),g<0?g+=1:g>1&&(g-=1)),[360*g,100*r,100*o]},r.rgb.hwb=function(A){const e=A[0],t=A[1];let i=A[2];return[r.rgb.hsl(A)[0],100*(1/255*Math.min(e,Math.min(t,i))),100*(i=1-1/255*Math.max(e,Math.max(t,i)))]},r.rgb.cmyk=function(A){const e=A[0]/255,t=A[1]/255,i=A[2]/255,g=Math.min(1-e,1-t,1-i);return[100*((1-e-g)/(1-g)||0),100*((1-t-g)/(1-g)||0),100*((1-i-g)/(1-g)||0),100*g]},r.rgb.keyword=function(A){const e=g[A];if(e)return e;let t,r=1/0;for(const e of Object.keys(i)){const g=i[e],I=(B=g,((n=A)[0]-B[0])**2+(n[1]-B[1])**2+(n[2]-B[2])**2);I.04045?((e+.055)/1.055)**2.4:e/12.92)+.3576*(t=t>.04045?((t+.055)/1.055)**2.4:t/12.92)+.1805*(i=i>.04045?((i+.055)/1.055)**2.4:i/12.92)),100*(.2126*e+.7152*t+.0722*i),100*(.0193*e+.1192*t+.9505*i)]},r.rgb.lab=function(A){const e=r.rgb.xyz(A);let t=e[0],i=e[1],g=e[2];return i/=100,g/=108.883,t=(t/=95.047)>.008856?t**(1/3):7.787*t+16/116,[116*(i=i>.008856?i**(1/3):7.787*i+16/116)-16,500*(t-i),200*(i-(g=g>.008856?g**(1/3):7.787*g+16/116))]},r.hsl.rgb=function(A){const e=A[0]/360,t=A[1]/100,i=A[2]/100;let g,r,n;if(0===t)return[n=255*i,n,n];const B=2*i-(g=i<.5?i*(1+t):i+t-i*t),I=[0,0,0];for(let A=0;A<3;A++)(r=e+1/3*-(A-1))<0&&r++,r>1&&r--,n=6*r<1?B+6*(g-B)*r:2*r<1?g:3*r<2?B+(g-B)*(2/3-r)*6:B,I[A]=255*n;return I},r.hsl.hsv=function(A){const e=A[0];let t=A[1]/100,i=A[2]/100,g=t;const r=Math.max(i,.01);return t*=(i*=2)<=1?i:2-i,g*=r<=1?r:2-r,[e,100*(0===i?2*g/(r+g):2*t/(i+t)),100*((i+t)/2)]},r.hsv.rgb=function(A){const e=A[0]/60,t=A[1]/100;let i=A[2]/100;const g=Math.floor(e)%6,r=e-Math.floor(e),n=255*i*(1-t),B=255*i*(1-t*r),I=255*i*(1-t*(1-r));switch(i*=255,g){case 0:return[i,I,n];case 1:return[B,i,n];case 2:return[n,i,I];case 3:return[n,B,i];case 4:return[I,n,i];case 5:return[i,n,B]}},r.hsv.hsl=function(A){const e=A[0],t=A[1]/100,i=A[2]/100,g=Math.max(i,.01);let r,n;n=(2-t)*i;const B=(2-t)*g;return r=t*g,[e,100*(r=(r/=B<=1?B:2-B)||0),100*(n/=2)]},r.hwb.rgb=function(A){const e=A[0]/360;let t=A[1]/100,i=A[2]/100;const g=t+i;let r;g>1&&(t/=g,i/=g);const n=Math.floor(6*e),B=1-i;r=6*e-n,0!=(1&n)&&(r=1-r);const I=t+r*(B-t);let o,a,Q;switch(n){default:case 6:case 0:o=B,a=I,Q=t;break;case 1:o=I,a=B,Q=t;break;case 2:o=t,a=B,Q=I;break;case 3:o=t,a=I,Q=B;break;case 4:o=I,a=t,Q=B;break;case 5:o=B,a=t,Q=I}return[255*o,255*a,255*Q]},r.cmyk.rgb=function(A){const e=A[0]/100,t=A[1]/100,i=A[2]/100,g=A[3]/100;return[255*(1-Math.min(1,e*(1-g)+g)),255*(1-Math.min(1,t*(1-g)+g)),255*(1-Math.min(1,i*(1-g)+g))]},r.xyz.rgb=function(A){const e=A[0]/100,t=A[1]/100,i=A[2]/100;let g,r,n;return r=-.9689*e+1.8758*t+.0415*i,n=.0557*e+-.204*t+1.057*i,g=(g=3.2406*e+-1.5372*t+-.4986*i)>.0031308?1.055*g**(1/2.4)-.055:12.92*g,r=r>.0031308?1.055*r**(1/2.4)-.055:12.92*r,n=n>.0031308?1.055*n**(1/2.4)-.055:12.92*n,[255*(g=Math.min(Math.max(0,g),1)),255*(r=Math.min(Math.max(0,r),1)),255*(n=Math.min(Math.max(0,n),1))]},r.xyz.lab=function(A){let e=A[0],t=A[1],i=A[2];return t/=100,i/=108.883,e=(e/=95.047)>.008856?e**(1/3):7.787*e+16/116,[116*(t=t>.008856?t**(1/3):7.787*t+16/116)-16,500*(e-t),200*(t-(i=i>.008856?i**(1/3):7.787*i+16/116))]},r.lab.xyz=function(A){const e=A[0],t=A[1],i=A[2];let g,r,n;const B=(r=(e+16)/116)**3,I=(g=t/500+r)**3,o=(n=r-i/200)**3;return r=B>.008856?B:(r-16/116)/7.787,g=I>.008856?I:(g-16/116)/7.787,n=o>.008856?o:(n-16/116)/7.787,[g*=95.047,r*=100,n*=108.883]},r.lab.lch=function(A){const e=A[0],t=A[1],i=A[2];let g;return(g=360*Math.atan2(i,t)/2/Math.PI)<0&&(g+=360),[e,Math.sqrt(t*t+i*i),g]},r.lch.lab=function(A){const e=A[0],t=A[1],i=A[2]/360*2*Math.PI;return[e,t*Math.cos(i),t*Math.sin(i)]},r.rgb.ansi16=function(A,e=null){const[t,i,g]=A;let n=null===e?r.rgb.hsv(A)[2]:e;if(0===(n=Math.round(n/50)))return 30;let B=30+(Math.round(g/255)<<2|Math.round(i/255)<<1|Math.round(t/255));return 2===n&&(B+=60),B},r.hsv.ansi16=function(A){return r.rgb.ansi16(r.hsv.rgb(A),A[2])},r.rgb.ansi256=function(A){const e=A[0],t=A[1],i=A[2];return e===t&&t===i?e<8?16:e>248?231:Math.round((e-8)/247*24)+232:16+36*Math.round(e/255*5)+6*Math.round(t/255*5)+Math.round(i/255*5)},r.ansi16.rgb=function(A){let e=A%10;if(0===e||7===e)return A>50&&(e+=3.5),[e=e/10.5*255,e,e];const t=.5*(1+~~(A>50));return[(1&e)*t*255,(e>>1&1)*t*255,(e>>2&1)*t*255]},r.ansi256.rgb=function(A){if(A>=232){const e=10*(A-232)+8;return[e,e,e]}let e;return A-=16,[Math.floor(A/36)/5*255,Math.floor((e=A%36)/6)/5*255,e%6/5*255]},r.rgb.hex=function(A){const e=(((255&Math.round(A[0]))<<16)+((255&Math.round(A[1]))<<8)+(255&Math.round(A[2]))).toString(16).toUpperCase();return"000000".substring(e.length)+e},r.hex.rgb=function(A){const e=A.toString(16).match(/[a-f0-9]{6}|[a-f0-9]{3}/i);if(!e)return[0,0,0];let t=e[0];3===e[0].length&&(t=t.split("").map(A=>A+A).join(""));const i=parseInt(t,16);return[i>>16&255,i>>8&255,255&i]},r.rgb.hcg=function(A){const e=A[0]/255,t=A[1]/255,i=A[2]/255,g=Math.max(Math.max(e,t),i),r=Math.min(Math.min(e,t),i),n=g-r;let B,I;return B=n<1?r/(1-n):0,I=n<=0?0:g===e?(t-i)/n%6:g===t?2+(i-e)/n:4+(e-t)/n,I/=6,[360*(I%=1),100*n,100*B]},r.hsl.hcg=function(A){const e=A[1]/100,t=A[2]/100,i=t<.5?2*e*t:2*e*(1-t);let g=0;return i<1&&(g=(t-.5*i)/(1-i)),[A[0],100*i,100*g]},r.hsv.hcg=function(A){const e=A[1]/100,t=A[2]/100,i=e*t;let g=0;return i<1&&(g=(t-i)/(1-i)),[A[0],100*i,100*g]},r.hcg.rgb=function(A){const e=A[0]/360,t=A[1]/100,i=A[2]/100;if(0===t)return[255*i,255*i,255*i];const g=[0,0,0],r=e%1*6,n=r%1,B=1-n;let I=0;switch(Math.floor(r)){case 0:g[0]=1,g[1]=n,g[2]=0;break;case 1:g[0]=B,g[1]=1,g[2]=0;break;case 2:g[0]=0,g[1]=1,g[2]=n;break;case 3:g[0]=0,g[1]=B,g[2]=1;break;case 4:g[0]=n,g[1]=0,g[2]=1;break;default:g[0]=1,g[1]=0,g[2]=B}return I=(1-t)*i,[255*(t*g[0]+I),255*(t*g[1]+I),255*(t*g[2]+I)]},r.hcg.hsv=function(A){const e=A[1]/100,t=e+A[2]/100*(1-e);let i=0;return t>0&&(i=e/t),[A[0],100*i,100*t]},r.hcg.hsl=function(A){const e=A[1]/100,t=A[2]/100*(1-e)+.5*e;let i=0;return t>0&&t<.5?i=e/(2*t):t>=.5&&t<1&&(i=e/(2*(1-t))),[A[0],100*i,100*t]},r.hcg.hwb=function(A){const e=A[1]/100,t=e+A[2]/100*(1-e);return[A[0],100*(t-e),100*(1-t)]},r.hwb.hcg=function(A){const e=A[1]/100,t=1-A[2]/100,i=t-e;let g=0;return i<1&&(g=(t-i)/(1-i)),[A[0],100*i,100*g]},r.apple.rgb=function(A){return[A[0]/65535*255,A[1]/65535*255,A[2]/65535*255]},r.rgb.apple=function(A){return[A[0]/255*65535,A[1]/255*65535,A[2]/255*65535]},r.gray.rgb=function(A){return[A[0]/100*255,A[0]/100*255,A[0]/100*255]},r.gray.hsl=function(A){return[0,0,A[0]]},r.gray.hsv=r.gray.hsl,r.gray.hwb=function(A){return[0,100,A[0]]},r.gray.cmyk=function(A){return[0,0,0,A[0]]},r.gray.lab=function(A){return[A[0],0,0]},r.gray.hex=function(A){const e=255&Math.round(A[0]/100*255),t=((e<<16)+(e<<8)+e).toString(16).toUpperCase();return"000000".substring(t.length)+t},r.rgb.gray=function(A){return[(A[0]+A[1]+A[2])/3/255*100]}},{"color-name":319}],309:[function(A,e,t){const i=A("./conversions"),g=A("./route"),r={};Object.keys(i).forEach(A=>{r[A]={},Object.defineProperty(r[A],"channels",{value:i[A].channels}),Object.defineProperty(r[A],"labels",{value:i[A].labels});const e=g(A);Object.keys(e).forEach(t=>{const i=e[t];r[A][t]=function(A){const e=function(...e){const t=e[0];if(void 0===t||null===t)return t;t.length>1&&(e=t);const i=A(e);if("object"==typeof i)for(let A=i.length,e=0;e1&&(e=t),A(e))};return"conversion"in A&&(e.conversion=A.conversion),e}(i)})}),e.exports=r},{"./conversions":308,"./route":310}],310:[function(A,e,t){const i=A("./conversions");function g(A){const e=function(){const A={},e=Object.keys(i);for(let t=e.length,i=0;i=255)throw new TypeError("Alphabet too long");for(var e=new Uint8Array(256),t=0;t>>0,a=new Uint8Array(n);A[t];){var Q=e[A.charCodeAt(t)];if(255===Q)return;for(var C=0,s=n-1;(0!==Q||C>>0,a[s]=Q%256>>>0,Q=Q/256>>>0;if(0!==Q)throw new Error("Non-zero carry");r=C,t++}if(" "!==A[t]){for(var c=n-r;c!==n&&0===a[c];)c++;var h=i.allocUnsafe(g+(n-c));h.fill(0,0,g);for(var f=g;c!==n;)h[f++]=a[c++];return h}}}return{encode:function(e){if((Array.isArray(e)||e instanceof Uint8Array)&&(e=i.from(e)),!i.isBuffer(e))throw new TypeError("Expected Buffer");if(0===e.length)return"";for(var t=0,g=0,r=0,n=e.length;r!==n&&0===e[r];)r++,t++;for(var o=(n-r)*a+1>>>0,Q=new Uint8Array(o);r!==n;){for(var C=e[r],s=0,c=o-1;(0!==C||s>>0,Q[c]=C%B>>>0,C=C/B>>>0;if(0!==C)throw new Error("Non-zero carry");g=s,r++}for(var h=o-g;h!==o&&0===Q[h];)h++;for(var f=I.repeat(t);h=4294967296&&g++,A[e]=i,A[e+1]=g}function r(A,e,t,i){var g=A[e]+t;t<0&&(g+=4294967296);var r=A[e+1]+i;g>=4294967296&&r++,A[e]=g,A[e+1]=r}function n(A,e){return A[e]^A[e+1]<<8^A[e+2]<<16^A[e+3]<<24}function B(A,e,t,i,n,B){var I=Q[n],o=Q[n+1],C=Q[B],s=Q[B+1];g(a,A,e),r(a,A,I,o);var c=a[i]^a[A],h=a[i+1]^a[A+1];a[i]=h,a[i+1]=c,g(a,t,i),c=a[e]^a[t],h=a[e+1]^a[t+1],a[e]=c>>>24^h<<8,a[e+1]=h>>>24^c<<8,g(a,A,e),r(a,A,C,s),c=a[i]^a[A],h=a[i+1]^a[A+1],a[i]=c>>>16^h<<16,a[i+1]=h>>>16^c<<16,g(a,t,i),c=a[e]^a[t],h=a[e+1]^a[t+1],a[e]=h>>>31^c<<1,a[e+1]=c>>>31^h<<1}var I=new Uint32Array([4089235720,1779033703,2227873595,3144134277,4271175723,1013904242,1595750129,2773480762,2917565137,1359893119,725511199,2600822924,4215389547,528734635,327033209,1541459225]),o=new Uint8Array([0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,10,4,8,9,15,13,6,1,12,0,2,11,7,5,3,11,8,12,0,5,2,15,13,10,14,3,6,7,1,9,4,7,9,3,1,13,12,11,14,2,6,5,10,4,0,15,8,9,0,5,7,2,4,10,15,14,1,11,12,6,8,3,13,2,12,6,10,0,11,8,3,4,13,7,5,15,14,1,9,12,5,1,15,14,13,4,10,0,7,6,3,9,2,8,11,13,11,7,14,12,1,3,9,5,0,15,4,8,6,2,10,6,15,14,9,11,3,0,8,12,2,13,7,1,4,10,5,10,2,8,4,7,6,1,5,15,11,9,14,3,12,13,0,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,10,4,8,9,15,13,6,1,12,0,2,11,7,5,3].map(function(A){return 2*A})),a=new Uint32Array(32),Q=new Uint32Array(32);function C(A,e){var t=0;for(t=0;t<16;t++)a[t]=A.h[t],a[t+16]=I[t];for(a[24]=a[24]^A.t,a[25]=a[25]^A.t/4294967296,e&&(a[28]=~a[28],a[29]=~a[29]),t=0;t<32;t++)Q[t]=n(A.b,4*t);for(t=0;t<12;t++)B(0,8,16,24,o[16*t+0],o[16*t+1]),B(2,10,18,26,o[16*t+2],o[16*t+3]),B(4,12,20,28,o[16*t+4],o[16*t+5]),B(6,14,22,30,o[16*t+6],o[16*t+7]),B(0,10,20,30,o[16*t+8],o[16*t+9]),B(2,12,22,24,o[16*t+10],o[16*t+11]),B(4,14,16,26,o[16*t+12],o[16*t+13]),B(6,8,18,28,o[16*t+14],o[16*t+15]);for(t=0;t<16;t++)A.h[t]=A.h[t]^a[t]^a[t+16]}function s(A,e){if(0===A||A>64)throw new Error("Illegal output length, expected 0 < length <= 64");if(e&&e.length>64)throw new Error("Illegal key, expected Uint8Array with 0 < length <= 64");for(var t={b:new Uint8Array(128),h:new Uint32Array(16),t:0,c:0,outlen:A},i=0;i<16;i++)t.h[i]=I[i];var g=e?e.length:0;return t.h[0]^=16842752^g<<8^A,e&&(c(t,e),t.c=128),t}function c(A,e){for(var t=0;t>2]>>8*(3&t);return e}function f(A,e,t){t=t||64,A=i.normalizeInput(A);var g=s(t,e);return c(g,A),h(g)}e.exports={blake2b:f,blake2bHex:function(A,e,t){var g=f(A,e,t);return i.toHex(g)},blake2bInit:s,blake2bUpdate:c,blake2bFinal:h}},{"./util":315}],313:[function(A,e,t){var i=A("./util");function g(A,e){return A[e]^A[e+1]<<8^A[e+2]<<16^A[e+3]<<24}function r(A,e,t,i,g,r){o[A]=o[A]+o[e]+g,o[i]=n(o[i]^o[A],16),o[t]=o[t]+o[i],o[e]=n(o[e]^o[t],12),o[A]=o[A]+o[e]+r,o[i]=n(o[i]^o[A],8),o[t]=o[t]+o[i],o[e]=n(o[e]^o[t],7)}function n(A,e){return A>>>e^A<<32-e}var B=new Uint32Array([1779033703,3144134277,1013904242,2773480762,1359893119,2600822924,528734635,1541459225]),I=new Uint8Array([0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,10,4,8,9,15,13,6,1,12,0,2,11,7,5,3,11,8,12,0,5,2,15,13,10,14,3,6,7,1,9,4,7,9,3,1,13,12,11,14,2,6,5,10,4,0,15,8,9,0,5,7,2,4,10,15,14,1,11,12,6,8,3,13,2,12,6,10,0,11,8,3,4,13,7,5,15,14,1,9,12,5,1,15,14,13,4,10,0,7,6,3,9,2,8,11,13,11,7,14,12,1,3,9,5,0,15,4,8,6,2,10,6,15,14,9,11,3,0,8,12,2,13,7,1,4,10,5,10,2,8,4,7,6,1,5,15,11,9,14,3,12,13,0]),o=new Uint32Array(16),a=new Uint32Array(16);function Q(A,e){var t=0;for(t=0;t<8;t++)o[t]=A.h[t],o[t+8]=B[t];for(o[12]^=A.t,o[13]^=A.t/4294967296,e&&(o[14]=~o[14]),t=0;t<16;t++)a[t]=g(A.b,4*t);for(t=0;t<10;t++)r(0,4,8,12,a[I[16*t+0]],a[I[16*t+1]]),r(1,5,9,13,a[I[16*t+2]],a[I[16*t+3]]),r(2,6,10,14,a[I[16*t+4]],a[I[16*t+5]]),r(3,7,11,15,a[I[16*t+6]],a[I[16*t+7]]),r(0,5,10,15,a[I[16*t+8]],a[I[16*t+9]]),r(1,6,11,12,a[I[16*t+10]],a[I[16*t+11]]),r(2,7,8,13,a[I[16*t+12]],a[I[16*t+13]]),r(3,4,9,14,a[I[16*t+14]],a[I[16*t+15]]);for(t=0;t<8;t++)A.h[t]^=o[t]^o[t+8]}function C(A,e){if(!(A>0&&A<=32))throw new Error("Incorrect output length, should be in [1, 32]");var t=e?e.length:0;if(e&&!(t>0&&t<=32))throw new Error("Incorrect key length, should be in [1, 32]");var i={h:new Uint32Array(B),b:new Uint32Array(64),c:0,t:0,outlen:A};return i.h[0]^=16842752^t<<8^A,t>0&&(s(i,e),i.c=64),i}function s(A,e){for(var t=0;t>2]>>8*(3&t)&255;return e}function h(A,e,t){t=t||32,A=i.normalizeInput(A);var g=C(t,e);return s(g,A),c(g)}e.exports={blake2s:h,blake2sHex:function(A,e,t){var g=h(A,e,t);return i.toHex(g)},blake2sInit:C,blake2sUpdate:s,blake2sFinal:c}},{"./util":315}],314:[function(A,e,t){var i=A("./blake2b"),g=A("./blake2s");e.exports={blake2b:i.blake2b,blake2bHex:i.blake2bHex,blake2bInit:i.blake2bInit,blake2bUpdate:i.blake2bUpdate,blake2bFinal:i.blake2bFinal,blake2s:g.blake2s,blake2sHex:g.blake2sHex,blake2sInit:g.blake2sInit,blake2sUpdate:g.blake2sUpdate,blake2sFinal:g.blake2sFinal}},{"./blake2b":312,"./blake2s":313}],315:[function(A,e,t){(function(A){var t="Input must be an string, Buffer or Uint8Array";function i(A){return(4294967296+A).toString(16).substring(1)}e.exports={normalizeInput:function(e){var i;if(e instanceof Uint8Array)i=e;else if(e instanceof A)i=new Uint8Array(e);else{if("string"!=typeof e)throw new Error(t);i=new Uint8Array(A.from(e,"utf8"))}return i},toHex:function(A){return Array.prototype.map.call(A,function(A){return(A<16?"0":"")+A.toString(16)}).join("")},debugPrint:function(A,e,t){for(var g="\n"+A+" = ",r=0;r=49&&o<=54?o-49+10:o>=17&&o<=22?o-17+10:o,n|=I}return i(!(240&n),"Invalid character in "+A),g}function I(A,e,t,g){for(var r=0,n=0,B=Math.min(A.length,t),I=e;I=49?o-49+10:o>=17?o-17+10:o,i(o>=0&&n"}r.isBN=function(A){return A instanceof r||null!==A&&"object"==typeof A&&A.constructor.wordSize===r.wordSize&&Array.isArray(A.words)},r.max=function(A,e){return A.cmp(e)>0?A:e},r.min=function(A,e){return A.cmp(e)<0?A:e},r.prototype._init=function(A,e,t){if("number"==typeof A)return this._initNumber(A,e,t);if("object"==typeof A)return this._initArray(A,e,t);"hex"===e&&(e=16),i(e===(0|e)&&e>=2&&e<=36);var g=0;"-"===(A=A.toString().replace(/\s+/g,""))[0]&&g++,16===e?this._parseHex(A,g):this._parseBase(A,e,g),"-"===A[0]&&(this.negative=1),this._strip(),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initNumber=function(A,e,t){A<0&&(this.negative=1,A=-A),A<67108864?(this.words=[67108863&A],this.length=1):A<4503599627370496?(this.words=[67108863&A,A/67108864&67108863],this.length=2):(i(A<9007199254740992),this.words=[67108863&A,A/67108864&67108863,1],this.length=3),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initArray=function(A,e,t){if(i("number"==typeof A.length),A.length<=0)return this.words=[0],this.length=1,this;this.length=Math.ceil(A.length/3),this.words=new Array(this.length);for(var g=0;g=0;g-=3)n=A[g]|A[g-1]<<8|A[g-2]<<16,this.words[r]|=n<>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);else if("le"===t)for(g=0,r=0;g>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);return this._strip()},r.prototype._parseHex=function(A,e){this.length=Math.ceil((A.length-e)/6),this.words=new Array(this.length);for(var t=0;t=e;t-=6)g=B(A,t,t+6),this.words[i]|=g<>>26-r&4194303,(r+=24)>=26&&(r-=26,i++);t+6!==e&&(g=B(A,e,t+6),this.words[i]|=g<>>26-r&4194303),this._strip()},r.prototype._parseBase=function(A,e,t){this.words=[0],this.length=1;for(var i=0,g=1;g<=67108863;g*=e)i++;i--,g=g/e|0;for(var r=A.length-t,n=r%i,B=Math.min(r,r-n)+t,o=0,a=t;a1&&0===this.words[this.length-1];)this.length--;return this._normSign()},r.prototype._normSign=function(){return 1===this.length&&0===this.words[0]&&(this.negative=0),this},"undefined"!=typeof Symbol&&"function"==typeof Symbol.for?r.prototype[Symbol.for("nodejs.util.inspect.custom")]=a:r.prototype.inspect=a;var Q=["","0","00","000","0000","00000","000000","0000000","00000000","000000000","0000000000","00000000000","000000000000","0000000000000","00000000000000","000000000000000","0000000000000000","00000000000000000","000000000000000000","0000000000000000000","00000000000000000000","000000000000000000000","0000000000000000000000","00000000000000000000000","000000000000000000000000","0000000000000000000000000"],C=[0,0,25,16,12,11,10,9,8,8,7,7,7,7,6,6,6,6,6,6,6,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5],s=[0,0,33554432,43046721,16777216,48828125,60466176,40353607,16777216,43046721,1e7,19487171,35831808,62748517,7529536,11390625,16777216,24137569,34012224,47045881,64e6,4084101,5153632,6436343,7962624,9765625,11881376,14348907,17210368,20511149,243e5,28629151,33554432,39135393,45435424,52521875,60466176];r.prototype.toString=function(A,e){var t;if(A=A||10,e=0|e||1,16===A||"hex"===A){t="";for(var g=0,r=0,n=0;n>>24-g&16777215)||n!==this.length-1?Q[6-I.length]+I+t:I+t,(g+=2)>=26&&(g-=26,n--)}for(0!==r&&(t=r.toString(16)+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}if(A===(0|A)&&A>=2&&A<=36){var o=C[A],a=s[A];t="";var c=this.clone();for(c.negative=0;!c.isZero();){var h=c.modrn(a).toString(A);t=(c=c.idivn(a)).isZero()?h+t:Q[o-h.length]+h+t}for(this.isZero()&&(t="0"+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}i(!1,"Base should be between 2 and 36")},r.prototype.toNumber=function(){var A=this.words[0];return 2===this.length?A+=67108864*this.words[1]:3===this.length&&1===this.words[2]?A+=4503599627370496+67108864*this.words[1]:this.length>2&&i(!1,"Number can only safely store up to 53 bits"),0!==this.negative?-A:A},r.prototype.toJSON=function(){return this.toString(16,2)},n&&(r.prototype.toBuffer=function(A,e){return this.toArrayLike(n,A,e)}),r.prototype.toArray=function(A,e){return this.toArrayLike(Array,A,e)};function c(A,e,t){t.negative=e.negative^A.negative;var i=A.length+e.length|0;t.length=i,i=i-1|0;var g=0|A.words[0],r=0|e.words[0],n=g*r,B=67108863&n,I=n/67108864|0;t.words[0]=B;for(var o=1;o>>26,Q=67108863&I,C=Math.min(o,e.length-1),s=Math.max(0,o-A.length+1);s<=C;s++){var c=o-s|0;a+=(n=(g=0|A.words[c])*(r=0|e.words[s])+Q)/67108864|0,Q=67108863&n}t.words[o]=0|Q,I=0|a}return 0!==I?t.words[o]=0|I:t.length--,t._strip()}r.prototype.toArrayLike=function(A,e,t){this._strip();var g=this.byteLength(),r=t||Math.max(1,g);i(g<=r,"byte array longer than desired length"),i(r>0,"Requested array length <= 0");var n=function(A,e){return A.allocUnsafe?A.allocUnsafe(e):new A(e)}(A,r);return this["_toArrayLike"+("le"===e?"LE":"BE")](n,g),n},r.prototype._toArrayLikeLE=function(A,e){for(var t=0,i=0,g=0,r=0;g>8&255),t>16&255),6===r?(t>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t=0&&(A[t--]=n>>8&255),t>=0&&(A[t--]=n>>16&255),6===r?(t>=0&&(A[t--]=n>>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t>=0)for(A[t--]=i;t>=0;)A[t--]=0},Math.clz32?r.prototype._countBits=function(A){return 32-Math.clz32(A)}:r.prototype._countBits=function(A){var e=A,t=0;return e>=4096&&(t+=13,e>>>=13),e>=64&&(t+=7,e>>>=7),e>=8&&(t+=4,e>>>=4),e>=2&&(t+=2,e>>>=2),t+e},r.prototype._zeroBits=function(A){if(0===A)return 26;var e=A,t=0;return 0==(8191&e)&&(t+=13,e>>>=13),0==(127&e)&&(t+=7,e>>>=7),0==(15&e)&&(t+=4,e>>>=4),0==(3&e)&&(t+=2,e>>>=2),0==(1&e)&&t++,t},r.prototype.bitLength=function(){var A=this.words[this.length-1],e=this._countBits(A);return 26*(this.length-1)+e},r.prototype.zeroBits=function(){if(this.isZero())return 0;for(var A=0,e=0;eA.length?this.clone().ior(A):A.clone().ior(this)},r.prototype.uor=function(A){return this.length>A.length?this.clone().iuor(A):A.clone().iuor(this)},r.prototype.iuand=function(A){var e;e=this.length>A.length?A:this;for(var t=0;tA.length?this.clone().iand(A):A.clone().iand(this)},r.prototype.uand=function(A){return this.length>A.length?this.clone().iuand(A):A.clone().iuand(this)},r.prototype.iuxor=function(A){var e,t;this.length>A.length?(e=this,t=A):(e=A,t=this);for(var i=0;iA.length?this.clone().ixor(A):A.clone().ixor(this)},r.prototype.uxor=function(A){return this.length>A.length?this.clone().iuxor(A):A.clone().iuxor(this)},r.prototype.inotn=function(A){i("number"==typeof A&&A>=0);var e=0|Math.ceil(A/26),t=A%26;this._expand(e),t>0&&e--;for(var g=0;g0&&(this.words[g]=~this.words[g]&67108863>>26-t),this._strip()},r.prototype.notn=function(A){return this.clone().inotn(A)},r.prototype.setn=function(A,e){i("number"==typeof A&&A>=0);var t=A/26|0,g=A%26;return this._expand(t+1),this.words[t]=e?this.words[t]|1<A.length?(t=this,i=A):(t=A,i=this);for(var g=0,r=0;r>>26;for(;0!==g&&r>>26;if(this.length=t.length,0!==g)this.words[this.length]=g,this.length++;else if(t!==this)for(;rA.length?this.clone().iadd(A):A.clone().iadd(this)},r.prototype.isub=function(A){if(0!==A.negative){A.negative=0;var e=this.iadd(A);return A.negative=1,e._normSign()}if(0!==this.negative)return this.negative=0,this.iadd(A),this.negative=1,this._normSign();var t,i,g=this.cmp(A);if(0===g)return this.negative=0,this.length=1,this.words[0]=0,this;g>0?(t=this,i=A):(t=A,i=this);for(var r=0,n=0;n>26,this.words[n]=67108863&e;for(;0!==r&&n>26,this.words[n]=67108863&e;if(0===r&&n>>13,s=0|n[1],c=8191&s,h=s>>>13,f=0|n[2],E=8191&f,u=f>>>13,d=0|n[3],l=8191&d,w=d>>>13,p=0|n[4],D=8191&p,b=p>>>13,y=0|n[5],M=8191&y,m=y>>>13,G=0|n[6],k=8191&G,F=G>>>13,N=0|n[7],S=8191&N,Y=N>>>13,v=0|n[8],K=8191&v,U=v>>>13,J=0|n[9],H=8191&J,R=J>>>13,q=0|B[0],L=8191&q,x=q>>>13,Z=0|B[1],j=8191&Z,W=Z>>>13,O=0|B[2],P=8191&O,V=O>>>13,X=0|B[3],z=8191&X,T=X>>>13,_=0|B[4],$=8191&_,AA=_>>>13,eA=0|B[5],tA=8191&eA,iA=eA>>>13,gA=0|B[6],rA=8191&gA,nA=gA>>>13,BA=0|B[7],IA=8191&BA,oA=BA>>>13,aA=0|B[8],QA=8191&aA,CA=aA>>>13,sA=0|B[9],cA=8191&sA,hA=sA>>>13;t.negative=A.negative^e.negative,t.length=19;var fA=(o+(i=Math.imul(Q,L))|0)+((8191&(g=(g=Math.imul(Q,x))+Math.imul(C,L)|0))<<13)|0;o=((r=Math.imul(C,x))+(g>>>13)|0)+(fA>>>26)|0,fA&=67108863,i=Math.imul(c,L),g=(g=Math.imul(c,x))+Math.imul(h,L)|0,r=Math.imul(h,x);var EA=(o+(i=i+Math.imul(Q,j)|0)|0)+((8191&(g=(g=g+Math.imul(Q,W)|0)+Math.imul(C,j)|0))<<13)|0;o=((r=r+Math.imul(C,W)|0)+(g>>>13)|0)+(EA>>>26)|0,EA&=67108863,i=Math.imul(E,L),g=(g=Math.imul(E,x))+Math.imul(u,L)|0,r=Math.imul(u,x),i=i+Math.imul(c,j)|0,g=(g=g+Math.imul(c,W)|0)+Math.imul(h,j)|0,r=r+Math.imul(h,W)|0;var uA=(o+(i=i+Math.imul(Q,P)|0)|0)+((8191&(g=(g=g+Math.imul(Q,V)|0)+Math.imul(C,P)|0))<<13)|0;o=((r=r+Math.imul(C,V)|0)+(g>>>13)|0)+(uA>>>26)|0,uA&=67108863,i=Math.imul(l,L),g=(g=Math.imul(l,x))+Math.imul(w,L)|0,r=Math.imul(w,x),i=i+Math.imul(E,j)|0,g=(g=g+Math.imul(E,W)|0)+Math.imul(u,j)|0,r=r+Math.imul(u,W)|0,i=i+Math.imul(c,P)|0,g=(g=g+Math.imul(c,V)|0)+Math.imul(h,P)|0,r=r+Math.imul(h,V)|0;var dA=(o+(i=i+Math.imul(Q,z)|0)|0)+((8191&(g=(g=g+Math.imul(Q,T)|0)+Math.imul(C,z)|0))<<13)|0;o=((r=r+Math.imul(C,T)|0)+(g>>>13)|0)+(dA>>>26)|0,dA&=67108863,i=Math.imul(D,L),g=(g=Math.imul(D,x))+Math.imul(b,L)|0,r=Math.imul(b,x),i=i+Math.imul(l,j)|0,g=(g=g+Math.imul(l,W)|0)+Math.imul(w,j)|0,r=r+Math.imul(w,W)|0,i=i+Math.imul(E,P)|0,g=(g=g+Math.imul(E,V)|0)+Math.imul(u,P)|0,r=r+Math.imul(u,V)|0,i=i+Math.imul(c,z)|0,g=(g=g+Math.imul(c,T)|0)+Math.imul(h,z)|0,r=r+Math.imul(h,T)|0;var lA=(o+(i=i+Math.imul(Q,$)|0)|0)+((8191&(g=(g=g+Math.imul(Q,AA)|0)+Math.imul(C,$)|0))<<13)|0;o=((r=r+Math.imul(C,AA)|0)+(g>>>13)|0)+(lA>>>26)|0,lA&=67108863,i=Math.imul(M,L),g=(g=Math.imul(M,x))+Math.imul(m,L)|0,r=Math.imul(m,x),i=i+Math.imul(D,j)|0,g=(g=g+Math.imul(D,W)|0)+Math.imul(b,j)|0,r=r+Math.imul(b,W)|0,i=i+Math.imul(l,P)|0,g=(g=g+Math.imul(l,V)|0)+Math.imul(w,P)|0,r=r+Math.imul(w,V)|0,i=i+Math.imul(E,z)|0,g=(g=g+Math.imul(E,T)|0)+Math.imul(u,z)|0,r=r+Math.imul(u,T)|0,i=i+Math.imul(c,$)|0,g=(g=g+Math.imul(c,AA)|0)+Math.imul(h,$)|0,r=r+Math.imul(h,AA)|0;var wA=(o+(i=i+Math.imul(Q,tA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,iA)|0)+Math.imul(C,tA)|0))<<13)|0;o=((r=r+Math.imul(C,iA)|0)+(g>>>13)|0)+(wA>>>26)|0,wA&=67108863,i=Math.imul(k,L),g=(g=Math.imul(k,x))+Math.imul(F,L)|0,r=Math.imul(F,x),i=i+Math.imul(M,j)|0,g=(g=g+Math.imul(M,W)|0)+Math.imul(m,j)|0,r=r+Math.imul(m,W)|0,i=i+Math.imul(D,P)|0,g=(g=g+Math.imul(D,V)|0)+Math.imul(b,P)|0,r=r+Math.imul(b,V)|0,i=i+Math.imul(l,z)|0,g=(g=g+Math.imul(l,T)|0)+Math.imul(w,z)|0,r=r+Math.imul(w,T)|0,i=i+Math.imul(E,$)|0,g=(g=g+Math.imul(E,AA)|0)+Math.imul(u,$)|0,r=r+Math.imul(u,AA)|0,i=i+Math.imul(c,tA)|0,g=(g=g+Math.imul(c,iA)|0)+Math.imul(h,tA)|0,r=r+Math.imul(h,iA)|0;var pA=(o+(i=i+Math.imul(Q,rA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,nA)|0)+Math.imul(C,rA)|0))<<13)|0;o=((r=r+Math.imul(C,nA)|0)+(g>>>13)|0)+(pA>>>26)|0,pA&=67108863,i=Math.imul(S,L),g=(g=Math.imul(S,x))+Math.imul(Y,L)|0,r=Math.imul(Y,x),i=i+Math.imul(k,j)|0,g=(g=g+Math.imul(k,W)|0)+Math.imul(F,j)|0,r=r+Math.imul(F,W)|0,i=i+Math.imul(M,P)|0,g=(g=g+Math.imul(M,V)|0)+Math.imul(m,P)|0,r=r+Math.imul(m,V)|0,i=i+Math.imul(D,z)|0,g=(g=g+Math.imul(D,T)|0)+Math.imul(b,z)|0,r=r+Math.imul(b,T)|0,i=i+Math.imul(l,$)|0,g=(g=g+Math.imul(l,AA)|0)+Math.imul(w,$)|0,r=r+Math.imul(w,AA)|0,i=i+Math.imul(E,tA)|0,g=(g=g+Math.imul(E,iA)|0)+Math.imul(u,tA)|0,r=r+Math.imul(u,iA)|0,i=i+Math.imul(c,rA)|0,g=(g=g+Math.imul(c,nA)|0)+Math.imul(h,rA)|0,r=r+Math.imul(h,nA)|0;var DA=(o+(i=i+Math.imul(Q,IA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,oA)|0)+Math.imul(C,IA)|0))<<13)|0;o=((r=r+Math.imul(C,oA)|0)+(g>>>13)|0)+(DA>>>26)|0,DA&=67108863,i=Math.imul(K,L),g=(g=Math.imul(K,x))+Math.imul(U,L)|0,r=Math.imul(U,x),i=i+Math.imul(S,j)|0,g=(g=g+Math.imul(S,W)|0)+Math.imul(Y,j)|0,r=r+Math.imul(Y,W)|0,i=i+Math.imul(k,P)|0,g=(g=g+Math.imul(k,V)|0)+Math.imul(F,P)|0,r=r+Math.imul(F,V)|0,i=i+Math.imul(M,z)|0,g=(g=g+Math.imul(M,T)|0)+Math.imul(m,z)|0,r=r+Math.imul(m,T)|0,i=i+Math.imul(D,$)|0,g=(g=g+Math.imul(D,AA)|0)+Math.imul(b,$)|0,r=r+Math.imul(b,AA)|0,i=i+Math.imul(l,tA)|0,g=(g=g+Math.imul(l,iA)|0)+Math.imul(w,tA)|0,r=r+Math.imul(w,iA)|0,i=i+Math.imul(E,rA)|0,g=(g=g+Math.imul(E,nA)|0)+Math.imul(u,rA)|0,r=r+Math.imul(u,nA)|0,i=i+Math.imul(c,IA)|0,g=(g=g+Math.imul(c,oA)|0)+Math.imul(h,IA)|0,r=r+Math.imul(h,oA)|0;var bA=(o+(i=i+Math.imul(Q,QA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,CA)|0)+Math.imul(C,QA)|0))<<13)|0;o=((r=r+Math.imul(C,CA)|0)+(g>>>13)|0)+(bA>>>26)|0,bA&=67108863,i=Math.imul(H,L),g=(g=Math.imul(H,x))+Math.imul(R,L)|0,r=Math.imul(R,x),i=i+Math.imul(K,j)|0,g=(g=g+Math.imul(K,W)|0)+Math.imul(U,j)|0,r=r+Math.imul(U,W)|0,i=i+Math.imul(S,P)|0,g=(g=g+Math.imul(S,V)|0)+Math.imul(Y,P)|0,r=r+Math.imul(Y,V)|0,i=i+Math.imul(k,z)|0,g=(g=g+Math.imul(k,T)|0)+Math.imul(F,z)|0,r=r+Math.imul(F,T)|0,i=i+Math.imul(M,$)|0,g=(g=g+Math.imul(M,AA)|0)+Math.imul(m,$)|0,r=r+Math.imul(m,AA)|0,i=i+Math.imul(D,tA)|0,g=(g=g+Math.imul(D,iA)|0)+Math.imul(b,tA)|0,r=r+Math.imul(b,iA)|0,i=i+Math.imul(l,rA)|0,g=(g=g+Math.imul(l,nA)|0)+Math.imul(w,rA)|0,r=r+Math.imul(w,nA)|0,i=i+Math.imul(E,IA)|0,g=(g=g+Math.imul(E,oA)|0)+Math.imul(u,IA)|0,r=r+Math.imul(u,oA)|0,i=i+Math.imul(c,QA)|0,g=(g=g+Math.imul(c,CA)|0)+Math.imul(h,QA)|0,r=r+Math.imul(h,CA)|0;var yA=(o+(i=i+Math.imul(Q,cA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,hA)|0)+Math.imul(C,cA)|0))<<13)|0;o=((r=r+Math.imul(C,hA)|0)+(g>>>13)|0)+(yA>>>26)|0,yA&=67108863,i=Math.imul(H,j),g=(g=Math.imul(H,W))+Math.imul(R,j)|0,r=Math.imul(R,W),i=i+Math.imul(K,P)|0,g=(g=g+Math.imul(K,V)|0)+Math.imul(U,P)|0,r=r+Math.imul(U,V)|0,i=i+Math.imul(S,z)|0,g=(g=g+Math.imul(S,T)|0)+Math.imul(Y,z)|0,r=r+Math.imul(Y,T)|0,i=i+Math.imul(k,$)|0,g=(g=g+Math.imul(k,AA)|0)+Math.imul(F,$)|0,r=r+Math.imul(F,AA)|0,i=i+Math.imul(M,tA)|0,g=(g=g+Math.imul(M,iA)|0)+Math.imul(m,tA)|0,r=r+Math.imul(m,iA)|0,i=i+Math.imul(D,rA)|0,g=(g=g+Math.imul(D,nA)|0)+Math.imul(b,rA)|0,r=r+Math.imul(b,nA)|0,i=i+Math.imul(l,IA)|0,g=(g=g+Math.imul(l,oA)|0)+Math.imul(w,IA)|0,r=r+Math.imul(w,oA)|0,i=i+Math.imul(E,QA)|0,g=(g=g+Math.imul(E,CA)|0)+Math.imul(u,QA)|0,r=r+Math.imul(u,CA)|0;var MA=(o+(i=i+Math.imul(c,cA)|0)|0)+((8191&(g=(g=g+Math.imul(c,hA)|0)+Math.imul(h,cA)|0))<<13)|0;o=((r=r+Math.imul(h,hA)|0)+(g>>>13)|0)+(MA>>>26)|0,MA&=67108863,i=Math.imul(H,P),g=(g=Math.imul(H,V))+Math.imul(R,P)|0,r=Math.imul(R,V),i=i+Math.imul(K,z)|0,g=(g=g+Math.imul(K,T)|0)+Math.imul(U,z)|0,r=r+Math.imul(U,T)|0,i=i+Math.imul(S,$)|0,g=(g=g+Math.imul(S,AA)|0)+Math.imul(Y,$)|0,r=r+Math.imul(Y,AA)|0,i=i+Math.imul(k,tA)|0,g=(g=g+Math.imul(k,iA)|0)+Math.imul(F,tA)|0,r=r+Math.imul(F,iA)|0,i=i+Math.imul(M,rA)|0,g=(g=g+Math.imul(M,nA)|0)+Math.imul(m,rA)|0,r=r+Math.imul(m,nA)|0,i=i+Math.imul(D,IA)|0,g=(g=g+Math.imul(D,oA)|0)+Math.imul(b,IA)|0,r=r+Math.imul(b,oA)|0,i=i+Math.imul(l,QA)|0,g=(g=g+Math.imul(l,CA)|0)+Math.imul(w,QA)|0,r=r+Math.imul(w,CA)|0;var mA=(o+(i=i+Math.imul(E,cA)|0)|0)+((8191&(g=(g=g+Math.imul(E,hA)|0)+Math.imul(u,cA)|0))<<13)|0;o=((r=r+Math.imul(u,hA)|0)+(g>>>13)|0)+(mA>>>26)|0,mA&=67108863,i=Math.imul(H,z),g=(g=Math.imul(H,T))+Math.imul(R,z)|0,r=Math.imul(R,T),i=i+Math.imul(K,$)|0,g=(g=g+Math.imul(K,AA)|0)+Math.imul(U,$)|0,r=r+Math.imul(U,AA)|0,i=i+Math.imul(S,tA)|0,g=(g=g+Math.imul(S,iA)|0)+Math.imul(Y,tA)|0,r=r+Math.imul(Y,iA)|0,i=i+Math.imul(k,rA)|0,g=(g=g+Math.imul(k,nA)|0)+Math.imul(F,rA)|0,r=r+Math.imul(F,nA)|0,i=i+Math.imul(M,IA)|0,g=(g=g+Math.imul(M,oA)|0)+Math.imul(m,IA)|0,r=r+Math.imul(m,oA)|0,i=i+Math.imul(D,QA)|0,g=(g=g+Math.imul(D,CA)|0)+Math.imul(b,QA)|0,r=r+Math.imul(b,CA)|0;var GA=(o+(i=i+Math.imul(l,cA)|0)|0)+((8191&(g=(g=g+Math.imul(l,hA)|0)+Math.imul(w,cA)|0))<<13)|0;o=((r=r+Math.imul(w,hA)|0)+(g>>>13)|0)+(GA>>>26)|0,GA&=67108863,i=Math.imul(H,$),g=(g=Math.imul(H,AA))+Math.imul(R,$)|0,r=Math.imul(R,AA),i=i+Math.imul(K,tA)|0,g=(g=g+Math.imul(K,iA)|0)+Math.imul(U,tA)|0,r=r+Math.imul(U,iA)|0,i=i+Math.imul(S,rA)|0,g=(g=g+Math.imul(S,nA)|0)+Math.imul(Y,rA)|0,r=r+Math.imul(Y,nA)|0,i=i+Math.imul(k,IA)|0,g=(g=g+Math.imul(k,oA)|0)+Math.imul(F,IA)|0,r=r+Math.imul(F,oA)|0,i=i+Math.imul(M,QA)|0,g=(g=g+Math.imul(M,CA)|0)+Math.imul(m,QA)|0,r=r+Math.imul(m,CA)|0;var kA=(o+(i=i+Math.imul(D,cA)|0)|0)+((8191&(g=(g=g+Math.imul(D,hA)|0)+Math.imul(b,cA)|0))<<13)|0;o=((r=r+Math.imul(b,hA)|0)+(g>>>13)|0)+(kA>>>26)|0,kA&=67108863,i=Math.imul(H,tA),g=(g=Math.imul(H,iA))+Math.imul(R,tA)|0,r=Math.imul(R,iA),i=i+Math.imul(K,rA)|0,g=(g=g+Math.imul(K,nA)|0)+Math.imul(U,rA)|0,r=r+Math.imul(U,nA)|0,i=i+Math.imul(S,IA)|0,g=(g=g+Math.imul(S,oA)|0)+Math.imul(Y,IA)|0,r=r+Math.imul(Y,oA)|0,i=i+Math.imul(k,QA)|0,g=(g=g+Math.imul(k,CA)|0)+Math.imul(F,QA)|0,r=r+Math.imul(F,CA)|0;var FA=(o+(i=i+Math.imul(M,cA)|0)|0)+((8191&(g=(g=g+Math.imul(M,hA)|0)+Math.imul(m,cA)|0))<<13)|0;o=((r=r+Math.imul(m,hA)|0)+(g>>>13)|0)+(FA>>>26)|0,FA&=67108863,i=Math.imul(H,rA),g=(g=Math.imul(H,nA))+Math.imul(R,rA)|0,r=Math.imul(R,nA),i=i+Math.imul(K,IA)|0,g=(g=g+Math.imul(K,oA)|0)+Math.imul(U,IA)|0,r=r+Math.imul(U,oA)|0,i=i+Math.imul(S,QA)|0,g=(g=g+Math.imul(S,CA)|0)+Math.imul(Y,QA)|0,r=r+Math.imul(Y,CA)|0;var NA=(o+(i=i+Math.imul(k,cA)|0)|0)+((8191&(g=(g=g+Math.imul(k,hA)|0)+Math.imul(F,cA)|0))<<13)|0;o=((r=r+Math.imul(F,hA)|0)+(g>>>13)|0)+(NA>>>26)|0,NA&=67108863,i=Math.imul(H,IA),g=(g=Math.imul(H,oA))+Math.imul(R,IA)|0,r=Math.imul(R,oA),i=i+Math.imul(K,QA)|0,g=(g=g+Math.imul(K,CA)|0)+Math.imul(U,QA)|0,r=r+Math.imul(U,CA)|0;var SA=(o+(i=i+Math.imul(S,cA)|0)|0)+((8191&(g=(g=g+Math.imul(S,hA)|0)+Math.imul(Y,cA)|0))<<13)|0;o=((r=r+Math.imul(Y,hA)|0)+(g>>>13)|0)+(SA>>>26)|0,SA&=67108863,i=Math.imul(H,QA),g=(g=Math.imul(H,CA))+Math.imul(R,QA)|0,r=Math.imul(R,CA);var YA=(o+(i=i+Math.imul(K,cA)|0)|0)+((8191&(g=(g=g+Math.imul(K,hA)|0)+Math.imul(U,cA)|0))<<13)|0;o=((r=r+Math.imul(U,hA)|0)+(g>>>13)|0)+(YA>>>26)|0,YA&=67108863;var vA=(o+(i=Math.imul(H,cA))|0)+((8191&(g=(g=Math.imul(H,hA))+Math.imul(R,cA)|0))<<13)|0;return o=((r=Math.imul(R,hA))+(g>>>13)|0)+(vA>>>26)|0,vA&=67108863,I[0]=fA,I[1]=EA,I[2]=uA,I[3]=dA,I[4]=lA,I[5]=wA,I[6]=pA,I[7]=DA,I[8]=bA,I[9]=yA,I[10]=MA,I[11]=mA,I[12]=GA,I[13]=kA,I[14]=FA,I[15]=NA,I[16]=SA,I[17]=YA,I[18]=vA,0!==o&&(I[19]=o,t.length++),t};function f(A,e,t){t.negative=e.negative^A.negative,t.length=A.length+e.length;for(var i=0,g=0,r=0;r>>26)|0)>>>26,n&=67108863}t.words[r]=B,i=n,n=g}return 0!==i?t.words[r]=i:t.length--,t._strip()}function E(A,e,t){return f(A,e,t)}function u(A,e){this.x=A,this.y=e}Math.imul||(h=c),r.prototype.mulTo=function(A,e){var t=this.length+A.length;return 10===this.length&&10===A.length?h(this,A,e):t<63?c(this,A,e):t<1024?f(this,A,e):E(this,A,e)},u.prototype.makeRBT=function(A){for(var e=new Array(A),t=r.prototype._countBits(A)-1,i=0;i>=1;return i},u.prototype.permute=function(A,e,t,i,g,r){for(var n=0;n>>=1)g++;return 1<>>=13,t[2*n+1]=8191&r,r>>>=13;for(n=2*e;n>=26,t+=r/67108864|0,t+=n>>>26,this.words[g]=67108863&n}return 0!==t&&(this.words[g]=t,this.length++),e?this.ineg():this},r.prototype.muln=function(A){return this.clone().imuln(A)},r.prototype.sqr=function(){return this.mul(this)},r.prototype.isqr=function(){return this.imul(this.clone())},r.prototype.pow=function(A){var e=function(A){for(var e=new Array(A.bitLength()),t=0;t>>g&1}return e}(A);if(0===e.length)return new r(1);for(var t=this,i=0;i=0);var e,t=A%26,g=(A-t)/26,r=67108863>>>26-t<<26-t;if(0!==t){var n=0;for(e=0;e>>26-t}n&&(this.words[e]=n,this.length++)}if(0!==g){for(e=this.length-1;e>=0;e--)this.words[e+g]=this.words[e];for(e=0;e=0),g=e?(e-e%26)/26:0;var r=A%26,n=Math.min((A-r)/26,this.length),B=67108863^67108863>>>r<n)for(this.length-=n,o=0;o=0&&(0!==a||o>=g);o--){var Q=0|this.words[o];this.words[o]=a<<26-r|Q>>>r,a=Q&B}return I&&0!==a&&(I.words[I.length++]=a),0===this.length&&(this.words[0]=0,this.length=1),this._strip()},r.prototype.ishrn=function(A,e,t){return i(0===this.negative),this.iushrn(A,e,t)},r.prototype.shln=function(A){return this.clone().ishln(A)},r.prototype.ushln=function(A){return this.clone().iushln(A)},r.prototype.shrn=function(A){return this.clone().ishrn(A)},r.prototype.ushrn=function(A){return this.clone().iushrn(A)},r.prototype.testn=function(A){i("number"==typeof A&&A>=0);var e=A%26,t=(A-e)/26,g=1<=0);var e=A%26,t=(A-e)/26;if(i(0===this.negative,"imaskn works only with positive numbers"),this.length<=t)return this;if(0!==e&&t++,this.length=Math.min(t,this.length),0!==e){var g=67108863^67108863>>>e<=67108864;e++)this.words[e]-=67108864,e===this.length-1?this.words[e+1]=1:this.words[e+1]++;return this.length=Math.max(this.length,e+1),this},r.prototype.isubn=function(A){if(i("number"==typeof A),i(A<67108864),A<0)return this.iaddn(-A);if(0!==this.negative)return this.negative=0,this.iaddn(A),this.negative=1,this;if(this.words[0]-=A,1===this.length&&this.words[0]<0)this.words[0]=-this.words[0],this.negative=1;else for(var e=0;e>26)-(I/67108864|0),this.words[g+t]=67108863&r}for(;g>26,this.words[g+t]=67108863&r;if(0===B)return this._strip();for(i(-1===B),B=0,g=0;g>26,this.words[g]=67108863&r;return this.negative=1,this._strip()},r.prototype._wordDiv=function(A,e){var t=(this.length,A.length),i=this.clone(),g=A,n=0|g.words[g.length-1];0!==(t=26-this._countBits(n))&&(g=g.ushln(t),i.iushln(t),n=0|g.words[g.length-1]);var B,I=i.length-g.length;if("mod"!==e){(B=new r(null)).length=I+1,B.words=new Array(B.length);for(var o=0;o=0;Q--){var C=67108864*(0|i.words[g.length+Q])+(0|i.words[g.length+Q-1]);for(C=Math.min(C/n|0,67108863),i._ishlnsubmul(g,C,Q);0!==i.negative;)C--,i.negative=0,i._ishlnsubmul(g,1,Q),i.isZero()||(i.negative^=1);B&&(B.words[Q]=C)}return B&&B._strip(),i._strip(),"div"!==e&&0!==t&&i.iushrn(t),{div:B||null,mod:i}},r.prototype.divmod=function(A,e,t){return i(!A.isZero()),this.isZero()?{div:new r(0),mod:new r(0)}:0!==this.negative&&0===A.negative?(B=this.neg().divmod(A,e),"mod"!==e&&(g=B.div.neg()),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.iadd(A)),{div:g,mod:n}):0===this.negative&&0!==A.negative?(B=this.divmod(A.neg(),e),"mod"!==e&&(g=B.div.neg()),{div:g,mod:B.mod}):0!=(this.negative&A.negative)?(B=this.neg().divmod(A.neg(),e),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.isub(A)),{div:B.div,mod:n}):A.length>this.length||this.cmp(A)<0?{div:new r(0),mod:this}:1===A.length?"div"===e?{div:this.divn(A.words[0]),mod:null}:"mod"===e?{div:null,mod:new r(this.modrn(A.words[0]))}:{div:this.divn(A.words[0]),mod:new r(this.modrn(A.words[0]))}:this._wordDiv(A,e);var g,n,B},r.prototype.div=function(A){return this.divmod(A,"div",!1).div},r.prototype.mod=function(A){return this.divmod(A,"mod",!1).mod},r.prototype.umod=function(A){return this.divmod(A,"mod",!0).mod},r.prototype.divRound=function(A){var e=this.divmod(A);if(e.mod.isZero())return e.div;var t=0!==e.div.negative?e.mod.isub(A):e.mod,i=A.ushrn(1),g=A.andln(1),r=t.cmp(i);return r<0||1===g&&0===r?e.div:0!==e.div.negative?e.div.isubn(1):e.div.iaddn(1)},r.prototype.modrn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=(1<<26)%A,g=0,r=this.length-1;r>=0;r--)g=(t*g+(0|this.words[r]))%A;return e?-g:g},r.prototype.modn=function(A){return this.modrn(A)},r.prototype.idivn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=0,g=this.length-1;g>=0;g--){var r=(0|this.words[g])+67108864*t;this.words[g]=r/A|0,t=r%A}return this._strip(),e?this.ineg():this},r.prototype.divn=function(A){return this.clone().idivn(A)},r.prototype.egcd=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g=new r(1),n=new r(0),B=new r(0),I=new r(1),o=0;e.isEven()&&t.isEven();)e.iushrn(1),t.iushrn(1),++o;for(var a=t.clone(),Q=e.clone();!e.isZero();){for(var C=0,s=1;0==(e.words[0]&s)&&C<26;++C,s<<=1);if(C>0)for(e.iushrn(C);C-- >0;)(g.isOdd()||n.isOdd())&&(g.iadd(a),n.isub(Q)),g.iushrn(1),n.iushrn(1);for(var c=0,h=1;0==(t.words[0]&h)&&c<26;++c,h<<=1);if(c>0)for(t.iushrn(c);c-- >0;)(B.isOdd()||I.isOdd())&&(B.iadd(a),I.isub(Q)),B.iushrn(1),I.iushrn(1);e.cmp(t)>=0?(e.isub(t),g.isub(B),n.isub(I)):(t.isub(e),B.isub(g),I.isub(n))}return{a:B,b:I,gcd:t.iushln(o)}},r.prototype._invmp=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g,n=new r(1),B=new r(0),I=t.clone();e.cmpn(1)>0&&t.cmpn(1)>0;){for(var o=0,a=1;0==(e.words[0]&a)&&o<26;++o,a<<=1);if(o>0)for(e.iushrn(o);o-- >0;)n.isOdd()&&n.iadd(I),n.iushrn(1);for(var Q=0,C=1;0==(t.words[0]&C)&&Q<26;++Q,C<<=1);if(Q>0)for(t.iushrn(Q);Q-- >0;)B.isOdd()&&B.iadd(I),B.iushrn(1);e.cmp(t)>=0?(e.isub(t),n.isub(B)):(t.isub(e),B.isub(n))}return(g=0===e.cmpn(1)?n:B).cmpn(0)<0&&g.iadd(A),g},r.prototype.gcd=function(A){if(this.isZero())return A.abs();if(A.isZero())return this.abs();var e=this.clone(),t=A.clone();e.negative=0,t.negative=0;for(var i=0;e.isEven()&&t.isEven();i++)e.iushrn(1),t.iushrn(1);for(;;){for(;e.isEven();)e.iushrn(1);for(;t.isEven();)t.iushrn(1);var g=e.cmp(t);if(g<0){var r=e;e=t,t=r}else if(0===g||0===t.cmpn(1))break;e.isub(t)}return t.iushln(i)},r.prototype.invm=function(A){return this.egcd(A).a.umod(A)},r.prototype.isEven=function(){return 0==(1&this.words[0])},r.prototype.isOdd=function(){return 1==(1&this.words[0])},r.prototype.andln=function(A){return this.words[0]&A},r.prototype.bincn=function(A){i("number"==typeof A);var e=A%26,t=(A-e)/26,g=1<>>26,B&=67108863,this.words[n]=B}return 0!==r&&(this.words[n]=r,this.length++),this},r.prototype.isZero=function(){return 1===this.length&&0===this.words[0]},r.prototype.cmpn=function(A){var e,t=A<0;if(0!==this.negative&&!t)return-1;if(0===this.negative&&t)return 1;if(this._strip(),this.length>1)e=1;else{t&&(A=-A),i(A<=67108863,"Number is too big");var g=0|this.words[0];e=g===A?0:gA.length)return 1;if(this.length=0;t--){var i=0|this.words[t],g=0|A.words[t];if(i!==g){ig&&(e=1);break}}return e},r.prototype.gtn=function(A){return 1===this.cmpn(A)},r.prototype.gt=function(A){return 1===this.cmp(A)},r.prototype.gten=function(A){return this.cmpn(A)>=0},r.prototype.gte=function(A){return this.cmp(A)>=0},r.prototype.ltn=function(A){return-1===this.cmpn(A)},r.prototype.lt=function(A){return-1===this.cmp(A)},r.prototype.lten=function(A){return this.cmpn(A)<=0},r.prototype.lte=function(A){return this.cmp(A)<=0},r.prototype.eqn=function(A){return 0===this.cmpn(A)},r.prototype.eq=function(A){return 0===this.cmp(A)},r.red=function(A){return new y(A)},r.prototype.toRed=function(A){return i(!this.red,"Already a number in reduction context"),i(0===this.negative,"red works only with positives"),A.convertTo(this)._forceRed(A)},r.prototype.fromRed=function(){return i(this.red,"fromRed works only with numbers in reduction context"),this.red.convertFrom(this)},r.prototype._forceRed=function(A){return this.red=A,this},r.prototype.forceRed=function(A){return i(!this.red,"Already a number in reduction context"),this._forceRed(A)},r.prototype.redAdd=function(A){return i(this.red,"redAdd works only with red numbers"),this.red.add(this,A)},r.prototype.redIAdd=function(A){return i(this.red,"redIAdd works only with red numbers"),this.red.iadd(this,A)},r.prototype.redSub=function(A){return i(this.red,"redSub works only with red numbers"),this.red.sub(this,A)},r.prototype.redISub=function(A){return i(this.red,"redISub works only with red numbers"),this.red.isub(this,A)},r.prototype.redShl=function(A){return i(this.red,"redShl works only with red numbers"),this.red.shl(this,A)},r.prototype.redMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.mul(this,A)},r.prototype.redIMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.imul(this,A)},r.prototype.redSqr=function(){return i(this.red,"redSqr works only with red numbers"),this.red._verify1(this),this.red.sqr(this)},r.prototype.redISqr=function(){return i(this.red,"redISqr works only with red numbers"),this.red._verify1(this),this.red.isqr(this)},r.prototype.redSqrt=function(){return i(this.red,"redSqrt works only with red numbers"),this.red._verify1(this),this.red.sqrt(this)},r.prototype.redInvm=function(){return i(this.red,"redInvm works only with red numbers"),this.red._verify1(this),this.red.invm(this)},r.prototype.redNeg=function(){return i(this.red,"redNeg works only with red numbers"),this.red._verify1(this),this.red.neg(this)},r.prototype.redPow=function(A){return i(this.red&&!A.red,"redPow(normalNum)"),this.red._verify1(this),this.red.pow(this,A)};var d={k256:null,p224:null,p192:null,p25519:null};function l(A,e){this.name=A,this.p=new r(e,16),this.n=this.p.bitLength(),this.k=new r(1).iushln(this.n).isub(this.p),this.tmp=this._tmp()}function w(){l.call(this,"k256","ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f")}function p(){l.call(this,"p224","ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001")}function D(){l.call(this,"p192","ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff")}function b(){l.call(this,"25519","7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed")}function y(A){if("string"==typeof A){var e=r._prime(A);this.m=e.p,this.prime=e}else i(A.gtn(1),"modulus must be greater than 1"),this.m=A,this.prime=null}function M(A){y.call(this,A),this.shift=this.m.bitLength(),this.shift%26!=0&&(this.shift+=26-this.shift%26),this.r=new r(1).iushln(this.shift),this.r2=this.imod(this.r.sqr()),this.rinv=this.r._invmp(this.m),this.minv=this.rinv.mul(this.r).isubn(1).div(this.m),this.minv=this.minv.umod(this.r),this.minv=this.r.sub(this.minv)}l.prototype._tmp=function(){var A=new r(null);return A.words=new Array(Math.ceil(this.n/13)),A},l.prototype.ireduce=function(A){var e,t=A;do{this.split(t,this.tmp),e=(t=(t=this.imulK(t)).iadd(this.tmp)).bitLength()}while(e>this.n);var i=e0?t.isub(this.p):void 0!==t.strip?t.strip():t._strip(),t},l.prototype.split=function(A,e){A.iushrn(this.n,0,e)},l.prototype.imulK=function(A){return A.imul(this.k)},g(w,l),w.prototype.split=function(A,e){for(var t=Math.min(A.length,9),i=0;i>>22,g=r}g>>>=22,A.words[i-10]=g,0===g&&A.length>10?A.length-=10:A.length-=9},w.prototype.imulK=function(A){A.words[A.length]=0,A.words[A.length+1]=0,A.length+=2;for(var e=0,t=0;t>>=26,A.words[t]=g,e=i}return 0!==e&&(A.words[A.length++]=e),A},r._prime=function(A){if(d[A])return d[A];var e;if("k256"===A)e=new w;else if("p224"===A)e=new p;else if("p192"===A)e=new D;else{if("p25519"!==A)throw new Error("Unknown prime "+A);e=new b}return d[A]=e,e},y.prototype._verify1=function(A){i(0===A.negative,"red works only with positives"),i(A.red,"red works only with red numbers")},y.prototype._verify2=function(A,e){i(0==(A.negative|e.negative),"red works only with positives"),i(A.red&&A.red===e.red,"red works only with red numbers")},y.prototype.imod=function(A){return this.prime?this.prime.ireduce(A)._forceRed(this):(o(A,A.umod(this.m)._forceRed(this)),A)},y.prototype.neg=function(A){return A.isZero()?A.clone():this.m.sub(A)._forceRed(this)},y.prototype.add=function(A,e){this._verify2(A,e);var t=A.add(e);return t.cmp(this.m)>=0&&t.isub(this.m),t._forceRed(this)},y.prototype.iadd=function(A,e){this._verify2(A,e);var t=A.iadd(e);return t.cmp(this.m)>=0&&t.isub(this.m),t},y.prototype.sub=function(A,e){this._verify2(A,e);var t=A.sub(e);return t.cmpn(0)<0&&t.iadd(this.m),t._forceRed(this)},y.prototype.isub=function(A,e){this._verify2(A,e);var t=A.isub(e);return t.cmpn(0)<0&&t.iadd(this.m),t},y.prototype.shl=function(A,e){return this._verify1(A),this.imod(A.ushln(e))},y.prototype.imul=function(A,e){return this._verify2(A,e),this.imod(A.imul(e))},y.prototype.mul=function(A,e){return this._verify2(A,e),this.imod(A.mul(e))},y.prototype.isqr=function(A){return this.imul(A,A.clone())},y.prototype.sqr=function(A){return this.mul(A,A)},y.prototype.sqrt=function(A){if(A.isZero())return A.clone();var e=this.m.andln(3);if(i(e%2==1),3===e){var t=this.m.add(new r(1)).iushrn(2);return this.pow(A,t)}for(var g=this.m.subn(1),n=0;!g.isZero()&&0===g.andln(1);)n++,g.iushrn(1);i(!g.isZero());var B=new r(1).toRed(this),I=B.redNeg(),o=this.m.subn(1).iushrn(1),a=this.m.bitLength();for(a=new r(2*a*a).toRed(this);0!==this.pow(a,o).cmp(I);)a.redIAdd(I);for(var Q=this.pow(a,g),C=this.pow(A,g.addn(1).iushrn(1)),s=this.pow(A,g),c=n;0!==s.cmp(B);){for(var h=s,f=0;0!==h.cmp(B);f++)h=h.redSqr();i(f=0;i--){for(var o=e.words[i],a=I-1;a>=0;a--){var Q=o>>a&1;g!==t[0]&&(g=this.sqr(g)),0!==Q||0!==n?(n<<=1,n|=Q,(4===++B||0===i&&0===a)&&(g=this.mul(g,t[n]),B=0,n=0)):B=0}I=26}return g},y.prototype.convertTo=function(A){var e=A.umod(this.m);return e===A?e.clone():e},y.prototype.convertFrom=function(A){var e=A.clone();return e.red=null,e},r.mont=function(A){return new M(A)},g(M,y),M.prototype.convertTo=function(A){return this.imod(A.ushln(this.shift))},M.prototype.convertFrom=function(A){var e=this.imod(A.mul(this.rinv));return e.red=null,e},M.prototype.imul=function(A,e){if(A.isZero()||e.isZero())return A.words[0]=0,A.length=1,A;var t=A.imul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),r=g;return g.cmp(this.m)>=0?r=g.isub(this.m):g.cmpn(0)<0&&(r=g.iadd(this.m)),r._forceRed(this)},M.prototype.mul=function(A,e){if(A.isZero()||e.isZero())return new r(0)._forceRed(this);var t=A.mul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),n=g;return g.cmp(this.m)>=0?n=g.isub(this.m):g.cmpn(0)<0&&(n=g.iadd(this.m)),n._forceRed(this)},M.prototype.invm=function(A){return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this)}}(void 0===e||e,this)},{buffer:19}],317:[function(A,e,t){var i=A("base-x");e.exports=i("123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz")},{"base-x":311}],318:[function(A,e,t){"use strict";const i=(A,e)=>{if("string"!=typeof A&&!Array.isArray(A))throw new TypeError("Expected the input to be `string | string[]`");e=Object.assign({pascalCase:!1},e);return 0===(A=Array.isArray(A)?A.map(A=>A.trim()).filter(A=>A.length).join("-"):A.trim()).length?"":1===A.length?e.pascalCase?A.toUpperCase():A.toLowerCase():(A!==A.toLowerCase()&&(A=(A=>{let e=!1,t=!1,i=!1;for(let g=0;ge.pascalCase?A.charAt(0).toUpperCase()+A.slice(1):A)(A=A.replace(/^[_.\- ]+/,"").toLowerCase().replace(/[_.\- ]+(\w|$)/g,(A,e)=>e.toUpperCase()).replace(/\d+(\w|$)/g,A=>A.toUpperCase())))};e.exports=i,e.exports.default=i},{}],319:[function(A,e,t){"use strict";e.exports={aliceblue:[240,248,255],antiquewhite:[250,235,215],aqua:[0,255,255],aquamarine:[127,255,212],azure:[240,255,255],beige:[245,245,220],bisque:[255,228,196],black:[0,0,0],blanchedalmond:[255,235,205],blue:[0,0,255],blueviolet:[138,43,226],brown:[165,42,42],burlywood:[222,184,135],cadetblue:[95,158,160],chartreuse:[127,255,0],chocolate:[210,105,30],coral:[255,127,80],cornflowerblue:[100,149,237],cornsilk:[255,248,220],crimson:[220,20,60],cyan:[0,255,255],darkblue:[0,0,139],darkcyan:[0,139,139],darkgoldenrod:[184,134,11],darkgray:[169,169,169],darkgreen:[0,100,0],darkgrey:[169,169,169],darkkhaki:[189,183,107],darkmagenta:[139,0,139],darkolivegreen:[85,107,47],darkorange:[255,140,0],darkorchid:[153,50,204],darkred:[139,0,0],darksalmon:[233,150,122],darkseagreen:[143,188,143],darkslateblue:[72,61,139],darkslategray:[47,79,79],darkslategrey:[47,79,79],darkturquoise:[0,206,209],darkviolet:[148,0,211],deeppink:[255,20,147],deepskyblue:[0,191,255],dimgray:[105,105,105],dimgrey:[105,105,105],dodgerblue:[30,144,255],firebrick:[178,34,34],floralwhite:[255,250,240],forestgreen:[34,139,34],fuchsia:[255,0,255],gainsboro:[220,220,220],ghostwhite:[248,248,255],gold:[255,215,0],goldenrod:[218,165,32],gray:[128,128,128],green:[0,128,0],greenyellow:[173,255,47],grey:[128,128,128],honeydew:[240,255,240],hotpink:[255,105,180],indianred:[205,92,92],indigo:[75,0,130],ivory:[255,255,240],khaki:[240,230,140],lavender:[230,230,250],lavenderblush:[255,240,245],lawngreen:[124,252,0],lemonchiffon:[255,250,205],lightblue:[173,216,230],lightcoral:[240,128,128],lightcyan:[224,255,255],lightgoldenrodyellow:[250,250,210],lightgray:[211,211,211],lightgreen:[144,238,144],lightgrey:[211,211,211],lightpink:[255,182,193],lightsalmon:[255,160,122],lightseagreen:[32,178,170],lightskyblue:[135,206,250],lightslategray:[119,136,153],lightslategrey:[119,136,153],lightsteelblue:[176,196,222],lightyellow:[255,255,224],lime:[0,255,0],limegreen:[50,205,50],linen:[250,240,230],magenta:[255,0,255],maroon:[128,0,0],mediumaquamarine:[102,205,170],mediumblue:[0,0,205],mediumorchid:[186,85,211],mediumpurple:[147,112,219],mediumseagreen:[60,179,113],mediumslateblue:[123,104,238],mediumspringgreen:[0,250,154],mediumturquoise:[72,209,204],mediumvioletred:[199,21,133],midnightblue:[25,25,112],mintcream:[245,255,250],mistyrose:[255,228,225],moccasin:[255,228,181],navajowhite:[255,222,173],navy:[0,0,128],oldlace:[253,245,230],olive:[128,128,0],olivedrab:[107,142,35],orange:[255,165,0],orangered:[255,69,0],orchid:[218,112,214],palegoldenrod:[238,232,170],palegreen:[152,251,152],paleturquoise:[175,238,238],palevioletred:[219,112,147],papayawhip:[255,239,213],peachpuff:[255,218,185],peru:[205,133,63],pink:[255,192,203],plum:[221,160,221],powderblue:[176,224,230],purple:[128,0,128],rebeccapurple:[102,51,153],red:[255,0,0],rosybrown:[188,143,143],royalblue:[65,105,225],saddlebrown:[139,69,19],salmon:[250,128,114],sandybrown:[244,164,96],seagreen:[46,139,87],seashell:[255,245,238],sienna:[160,82,45],silver:[192,192,192],skyblue:[135,206,235],slateblue:[106,90,205],slategray:[112,128,144],slategrey:[112,128,144],snow:[255,250,250],springgreen:[0,255,127],steelblue:[70,130,180],tan:[210,180,140],teal:[0,128,128],thistle:[216,191,216],tomato:[255,99,71],turquoise:[64,224,208],violet:[238,130,238],wheat:[245,222,179],white:[255,255,255],whitesmoke:[245,245,245],yellow:[255,255,0],yellowgreen:[154,205,50]}},{}],320:[function(A,e,t){"use strict";const i=A=>A&&A.includeBoundaries?"(?:(?<=\\s|^)(?=[a-fA-F\\d:])|(?<=[a-fA-F\\d:])(?=\\s|$))":"",g="(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]\\d|\\d)(?:\\.(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]\\d|\\d)){3}",r="[a-fA-F\\d]{1,4}",n=`\n(\n(?:${r}:){7}(?:${r}|:)| // 1:2:3:4:5:6:7:: 1:2:3:4:5:6:7:8\n(?:${r}:){6}(?:${g}|:${r}|:)| // 1:2:3:4:5:6:: 1:2:3:4:5:6::8 1:2:3:4:5:6::8 1:2:3:4:5:6::1.2.3.4\n(?:${r}:){5}(?::${g}|(:${r}){1,2}|:)| // 1:2:3:4:5:: 1:2:3:4:5::7:8 1:2:3:4:5::8 1:2:3:4:5::7:1.2.3.4\n(?:${r}:){4}(?:(:${r}){0,1}:${g}|(:${r}){1,3}|:)| // 1:2:3:4:: 1:2:3:4::6:7:8 1:2:3:4::8 1:2:3:4::6:7:1.2.3.4\n(?:${r}:){3}(?:(:${r}){0,2}:${g}|(:${r}){1,4}|:)| // 1:2:3:: 1:2:3::5:6:7:8 1:2:3::8 1:2:3::5:6:7:1.2.3.4\n(?:${r}:){2}(?:(:${r}){0,3}:${g}|(:${r}){1,5}|:)| // 1:2:: 1:2::4:5:6:7:8 1:2::8 1:2::4:5:6:7:1.2.3.4\n(?:${r}:){1}(?:(:${r}){0,4}:${g}|(:${r}){1,6}|:)| // 1:: 1::3:4:5:6:7:8 1::8 1::3:4:5:6:7:1.2.3.4\n(?::((?::${r}){0,5}:${g}|(?::${r}){1,7}|:)) // ::2:3:4:5:6:7:8 ::2:3:4:5:6:7:8 ::8 ::1.2.3.4\n)(%[0-9a-zA-Z]{1,})? // %eth0 %1\n`.replace(/\s*\/\/.*$/gm,"").replace(/\n/g,"").trim(),B=A=>A&&A.exact?new RegExp(`(?:^${g}$)|(?:^${n}$)`):new RegExp(`(?:${i(A)}${g}${i(A)})|(?:${i(A)}${n}${i(A)})`,"g");B.v4=(A=>A&&A.exact?new RegExp(`^${g}$`):new RegExp(`${i(A)}${g}${i(A)}`,"g")),B.v6=(A=>A&&A.exact?new RegExp(`^${n}$`):new RegExp(`${i(A)}${n}${i(A)}`,"g")),e.exports=B},{}],321:[function(A,e,t){var i=A("buffer"),g=i.Buffer;function r(A,e){for(var t in A)e[t]=A[t]}function n(A,e,t){return g(A,e,t)}g.from&&g.alloc&&g.allocUnsafe&&g.allocUnsafeSlow?e.exports=i:(r(i,t),t.Buffer=n),n.prototype=Object.create(g.prototype),r(g,n),n.from=function(A,e,t){if("number"==typeof A)throw new TypeError("Argument must not be a number");return g(A,e,t)},n.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError("Argument must be a number");var i=g(A);return void 0!==e?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i},n.allocUnsafe=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return g(A)},n.allocUnsafeSlow=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return i.SlowBuffer(A)}},{buffer:64}],322:[function(A,e,t){"use strict";e.exports={stdout:!1,stderr:!1}},{}],323:[function(A,e,t){const i=A("@polkadot/util-crypto/address/decode").default,g=A("@polkadot/util-crypto/address/encode").default;globalThis.addressChanger=(()=>{const A=document.getElementById("input"),e=document.getElementById("prefix-select"),t=document.getElementById("output"),r=e.options[e.selectedIndex].value;try{const e=i(A.value),n=g(e,r);t.textContent=n.toString()}catch(A){console.log(A)}})},{"@polkadot/util-crypto/address/decode":202,"@polkadot/util-crypto/address/encode":204}]},{},[323]); diff --git a/website/README.md b/website/README.md deleted file mode 100755 index f3da77ff3424..000000000000 --- a/website/README.md +++ /dev/null @@ -1,193 +0,0 @@ -This website was created with [Docusaurus](https://docusaurus.io/). - -# What's In This Document - -* [Get Started in 5 Minutes](#get-started-in-5-minutes) -* [Directory Structure](#directory-structure) -* [Editing Content](#editing-content) -* [Adding Content](#adding-content) -* [Full Documentation](#full-documentation) - -# Get Started in 5 Minutes - -1. Make sure all the dependencies for the website are installed: - -```sh -# Install dependencies -$ yarn -``` -2. Run your dev server: - -```sh -# Start the site -$ yarn start -``` - -## Directory Structure - -Your project file structure should look something like this - -``` -my-docusaurus/ - docs/ - doc-1.md - doc-2.md - doc-3.md - website/ - blog/ - 2016-3-11-oldest-post.md - 2017-10-24-newest-post.md - core/ - node_modules/ - pages/ - static/ - css/ - img/ - package.json - sidebar.json - siteConfig.js -``` - -# Editing Content - -## Editing an existing docs page - -Edit docs by navigating to `docs/` and editing the corresponding document: - -`docs/doc-to-be-edited.md` - -```markdown ---- -id: page-needs-edit -title: This Doc Needs To Be Edited ---- - -Edit me... -``` - -For more information about docs, click [here](https://docusaurus.io/docs/en/navigation) - -## Editing an existing blog post - -Edit blog posts by navigating to `website/blog` and editing the corresponding post: - -`website/blog/post-to-be-edited.md` -```markdown ---- -id: post-needs-edit -title: This Blog Post Needs To Be Edited ---- - -Edit me... -``` - -For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog) - -# Adding Content - -## Adding a new docs page to an existing sidebar - -1. Create the doc as a new markdown file in `/docs`, example `docs/newly-created-doc.md`: - -```md ---- -id: newly-created-doc -title: This Doc Needs To Be Edited ---- - -My new content here.. -``` - -1. Refer to that doc's ID in an existing sidebar in `website/sidebar.json`: - -```javascript -// Add newly-created-doc to the Getting Started category of docs -{ - "docs": { - "Getting Started": [ - "quick-start", - "newly-created-doc" // new doc here - ], - ... - }, - ... -} -``` - -For more information about adding new docs, click [here](https://docusaurus.io/docs/en/navigation) - -## Adding a new blog post - -1. Make sure there is a header link to your blog in `website/siteConfig.js`: - -`website/siteConfig.js` -```javascript -headerLinks: [ - ... - { blog: true, label: 'Blog' }, - ... -] -``` - -2. Create the blog post with the format `YYYY-MM-DD-My-Blog-Post-Title.md` in `website/blog`: - -`website/blog/2018-05-21-New-Blog-Post.md` - -```markdown ---- -author: Frank Li -authorURL: https://twitter.com/foobarbaz -authorFBID: 503283835 -title: New Blog Post ---- - -Lorem Ipsum... -``` - -For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog) - -## Adding items to your site's top navigation bar - -1. Add links to docs, custom pages or external links by editing the headerLinks field of `website/siteConfig.js`: - -`website/siteConfig.js` -```javascript -{ - headerLinks: [ - ... - /* you can add docs */ - { doc: 'my-examples', label: 'Examples' }, - /* you can add custom pages */ - { page: 'help', label: 'Help' }, - /* you can add external links */ - { href: 'https://github.com/facebook/Docusaurus', label: 'GitHub' }, - ... - ], - ... -} -``` - -For more information about the navigation bar, click [here](https://docusaurus.io/docs/en/navigation) - -## Adding custom pages - -1. Docusaurus uses React components to build pages. The components are saved as .js files in `website/pages/en`: -1. If you want your page to show up in your navigation header, you will need to update `website/siteConfig.js` to add to the `headerLinks` element: - -`website/siteConfig.js` -```javascript -{ - headerLinks: [ - ... - { page: 'my-new-custom-page', label: 'My New Custom Page' }, - ... - ], - ... -} -``` - -For more information about custom pages, click [here](https://docusaurus.io/docs/en/custom-pages). - -# Full Documentation - -Full documentation can be found on the [website](https://docusaurus.io/). diff --git a/website/core/Footer.js b/website/core/Footer.js deleted file mode 100755 index e8f550469419..000000000000 --- a/website/core/Footer.js +++ /dev/null @@ -1,210 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require("react"); - -const Container = require("react-bootstrap/Container"); -const Row = require("react-bootstrap/Row"); -const Col = require("react-bootstrap/Col"); -const Button = require("react-bootstrap/Button"); - -class FooterNavColumn extends React.Component { - render() { - return ( - -
    {this.props.headline}
    -
      {this.props.children}
    - - ); - } -} - -class FooterLink extends React.Component { - render() { - return ( -
  • - - {this.props.content} - -
    • - ); - } -} - -class FooterSocialColumn extends React.Component { - render() { - const Social = () => ( - - ); - - const Newsletter = () => ( - <> -

    - Subscribe to the newsletter to hear about Polkadot updates and events. -

    - - - ); - - return ( - - - - - ); - } -} - -class FooterLegalLink extends React.Component { - render() { - return ( -
  • - - {this.props.content} - -
    • - ); - } -} - -class Footer extends React.Component { - docUrl(doc, language) { - const baseUrl = this.props.config.baseUrl; - const docsUrl = this.props.config.docsUrl; - const docsPart = `${docsUrl ? `${docsUrl}/` : ""}`; - const langPart = `${language ? `${language}/` : ""}`; - return `${baseUrl}${docsPart}${langPart}${doc}`; - } - - pageUrl(doc, language) { - const baseUrl = this.props.config.baseUrl; - return baseUrl + (language ? `${language}/` : "") + doc; - } - - render() { - return ( -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - {this.props.config.footerIcon && ( - - - Polkadot Network - - - )} - -
      - - - - - -
    - -     -     -
    - ); - } -} - -module.exports = Footer; diff --git a/website/i18n/ar-SA.json b/website/i18n/ar-SA.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/ar-SA.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ar.json b/website/i18n/ar.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/website/i18n/ar.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/de-DE.json b/website/i18n/de-DE.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/de-DE.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/en.json b/website/i18n/en.json deleted file mode 100644 index 3d8576524428..000000000000 --- a/website/i18n/en.json +++ /dev/null @@ -1,541 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Rococo Parachain Testnet", - "sidebar_label": "Rococo Parachain Test Network" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-legitimate-projects": { - "title": "How to Identify Legitimate Projects", - "sidebar_label": "How to Identify Legitimate Projects" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-stop-validating": { - "title": "How to Stop Validating", - "sidebar_label": "How to Stop Validating" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-build-parachains-rococo": { - "title": "Rococo Parachain Testnet", - "sidebar_label": "Rococo Parachain Test Network" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "mirror-learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "mirror-learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "mirror-learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-stop-validating": { - "title": "How to Stop Validating", - "sidebar_label": "How to Stop Validating" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/es-ES.json b/website/i18n/es-ES.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/es-ES.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/fi-FI.json b/website/i18n/fi-FI.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/fi-FI.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/fil-PH.json b/website/i18n/fil-PH.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/fil-PH.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/fr-FR.json b/website/i18n/fr-FR.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/fr-FR.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/hi-IN.json b/website/i18n/hi-IN.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/hi-IN.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/hr-HR.json b/website/i18n/hr-HR.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/hr-HR.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/id-ID.json b/website/i18n/id-ID.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/id-ID.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/it-IT.json b/website/i18n/it-IT.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/it-IT.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ja-JP.json b/website/i18n/ja-JP.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/ja-JP.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ja.json b/website/i18n/ja.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/website/i18n/ja.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ko-KR.json b/website/i18n/ko-KR.json deleted file mode 100644 index a9835af472de..000000000000 --- a/website/i18n/ko-KR.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "다음", - "previous": "이전", - "tagline": "폴카닷을 배우거나, 만들고, 노드를 돌리는 데 관심있는 사람들을 위한 허브", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "폴카닷 개발자 새내기 가이드", - "sidebar_label": "폴카닷 개발자 새내기 가이드" - }, - "build-cumulus": { - "title": "큐뮬러스(뭉게구름)", - "sidebar_label": "큐뮬러스(뭉게구름)" - }, - "build-hackathon": { - "title": "해커톤", - "sidebar_label": "해커톤" - }, - "build-index": { - "title": "개발자 포탈", - "sidebar_label": "개발자 포탈" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "패러체인 개발 키트", - "sidebar_label": "패러체인 개발 키트" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "스마트 컨트랙트", - "sidebar_label": "스마트 컨트랙트" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "툴 목록", - "sidebar_label": "툴 목록" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "커뮤니티", - "sidebar_label": "커뮤니티" - }, - "contributing": { - "title": "기여하기", - "sidebar_label": "기여하기" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "용어 정리", - "sidebar_label": "용어 정리" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "아키텍쳐", - "sidebar_label": "아키텍쳐" - }, - "learn-auction": { - "title": "패러체인 슬롯 경매", - "sidebar_label": "패러체인 슬롯 경매" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "브릿지들", - "sidebar_label": "브릿지들" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "디피니티" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "코스모스에 비교분석\n" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "다른 체인과의 비교분석" - }, - "learn-consensus": { - "title": "폴카닷의 컨센서스", - "sidebar_label": "폴카닷의 컨센서스" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "암호화체계 부연 설명", - "sidebar_label": "암호화체계 부연 설명" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "거버넌스 (Governance)", - "sidebar_label": "거버넌스 (Governance)" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "폴카닷 구현체들", - "sidebar_label": "폴카닷 구현체들" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "폴카닷 키들", - "sidebar_label": "폴카닷 키들" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "패러체인 (Parachains)", - "sidebar_label": "패러체인 (Parachains)" - }, - "learn-parathreads": { - "title": "패러쓰레드 (parathreads)", - "sidebar_label": "패러쓰레드 (parathreads)" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "무작위 선택", - "sidebar_label": "무작위 선택" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "네트워크의 보안", - "sidebar_label": "네트워크의 보안" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "스프리 (SPREE)", - "sidebar_label": "스프리 (SPREE)" - }, - "learn-staking": { - "title": "스테이킹", - "sidebar_label": "스테이킹" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "재무관리", - "sidebar_label": "재무관리" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "웹어셈블리 (WASM; Web Assembly)", - "sidebar_label": "웹어셈블리 (WASM; Web Assembly)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "의회에 출마하는 법", - "sidebar_label": "의회에 출마하는 법" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "노미네이터가 되어보세요 (쿠사마)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "검증자 노드를 업그레이드하는 방법", - "sidebar_label": "검증자 노드를 업그레이드하는 방법" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "검증자 노드를 돌려보세요 (쿠사마)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "의회원들에 투표하기", - "sidebar_label": "의회원들에 투표하기" - }, - "maintain-guides-secure-validator": { - "title": "안전한 검증자 노드", - "sidebar_label": "안전한 검증자 노드" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "검증자 보상 구조 정리", - "sidebar_label": "검증자 보상 구조 정리" - }, - "maintain-index": { - "title": "네트워크 메인테이너들", - "sidebar_label": "네트워크 메인테이너들" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "연구 자료들", - "sidebar_label": "연구 자료들" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "학습", - "Build": "개발", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "학습", - "Build": "개발", - "Maintain": "유지 및 보수" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "이 사이트의 [문서](/test-site/docs/en/doc1.html)에서 자세한 정보를 얻으세요.", - "Browse Docs|no description given": "문서 찾아보기", - "Ask questions about the documentation and project|no description given": "문서 및 프로젝트에 대해 질문하기", - "Join the community|no description given": "커뮤니티에 가입하세요", - "Find out what's new with this project|no description given": "이 프로젝트의 새로운 소식에 대해 알아봅시다.", - "Stay up to date|no description given": "최신 정보를 놓치지 마세요.", - "Need help?|no description given": "도움이 필요하세요?", - "This project is maintained by a dedicated group of people.|statement made to reader": "이 프로젝트는 이 분야에 집중하는 사람들에 의해서 유지 및 보수가 이루어지고 있습니다.", - "Help Translate|recruit community translators for your project": "번역을 도와주세요", - "Edit this Doc|recruitment message asking to edit the doc source": "편집", - "Translate this Doc|recruitment message asking to translate the docs": "번역" - } -} diff --git a/website/i18n/ko.json b/website/i18n/ko.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/website/i18n/ko.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ms-MY.json b/website/i18n/ms-MY.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/ms-MY.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/pt-BR.json b/website/i18n/pt-BR.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/pt-BR.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/pt-PT.json b/website/i18n/pt-PT.json deleted file mode 100644 index 93637d42b4ef..000000000000 --- a/website/i18n/pt-PT.json +++ /dev/null @@ -1,463 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "guides": { - "title": "Guides", - "sidebar_label": "Guides" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grantees", - "sidebar_label": "Grants" - }, - "index": { - "title": "Wiki Index", - "sidebar_label": "Wiki Index" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-time-periods": { - "title": "Time Period Cheat Sheet", - "sidebar_label": "Parameters" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-nominate-alexander": { - "title": "Be a Nominator (Alexander)", - "sidebar_label": "Be a Nominator (Alexander)" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "Nomination Guide", - "sidebar_label": "Nomination Guide" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Stop Being a Nominator", - "sidebar_label": "Stop Being a Nominator" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "Validator Guide" - }, - "maintain-guides-how-to-validate-alexander": { - "title": "Run a Validator (Alexander)", - "sidebar_label": "Run a Validator (Alexander)" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "Validator Guide" - }, - "news": { - "title": "News Sources", - "sidebar_label": "News Sources" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - } - }, - "links": { - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain", - "Kusama": "Kusama" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ru-RU.json b/website/i18n/ru-RU.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/ru-RU.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ru.json b/website/i18n/ru.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/website/i18n/ru.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/sk-SK.json b/website/i18n/sk-SK.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/sk-SK.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/th-TH.json b/website/i18n/th-TH.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/th-TH.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/tr-TR.json b/website/i18n/tr-TR.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/tr-TR.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/tr.json b/website/i18n/tr.json deleted file mode 100644 index c866828df5ba..000000000000 --- a/website/i18n/tr.json +++ /dev/null @@ -1,277 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on the Polkadot protocol.", - "docs": { - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-deploy-parachains": { - "title": "How to view and deploy parachains", - "sidebar_label": "How to view and deploy parachains" - }, - "build-dev-roadmap": { - "title": "Roadmap For Developers", - "sidebar_label": "Roadmap For Developers" - }, - "build-examples-index": { - "title": "Examples", - "sidebar_label": "Examples" - }, - "build-exchange-integration": { - "title": "Exchange integration", - "sidebar_label": "Exchange integration" - }, - "build-extrinsic-format": { - "title": "Polkadot Extrinsic Format aka Transaction Format", - "sidebar_label": "Polkadot Extrinsic Format aka Transaction Format" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builders Portal", - "sidebar_label": "Builders Portal" - }, - "build-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-rust-style-guide": { - "title": "Style Guide for Rust in Polkadot", - "sidebar_label": "Style Guide for Rust in Polkadot" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-tools-index": { - "title": "Tools", - "sidebar_label": "Tools" - }, - "build-tools-subkey": { - "title": "Subkey", - "sidebar_label": "Subkey" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "glossary": { - "title": "Terms and Definitions", - "sidebar_label": "Terms and Definitions" - }, - "index": { - "title": "Polkadot Wiki", - "sidebar_label": "Polkadot Wiki" - }, - "lang-japanese": { - "title": "Polkadot & Substate (Japanese)", - "sidebar_label": "Polkadot & Substate (Japanese)" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-comparisons-cosmos": { - "title": "Design Comparison", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-interchain": { - "title": "Interchain Message Passing (ICMP)", - "sidebar_label": "Interchain Message Passing (ICMP)" - }, - "learn-introduction": { - "title": "Polkadot", - "sidebar_label": "Polkadot" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "What is Phragmen and what does it mean for node operators?", - "sidebar_label": "What is Phragmen and what does it mean for node operators?" - }, - "learn-PRE": { - "title": "Polkadot Runtime Environment (PRE)", - "sidebar_label": "Polkadot Runtime Environment (PRE)" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-relevant-links": { - "title": "Links", - "sidebar_label": "Links" - }, - "learn-roadmap": { - "title": "Roadmap", - "sidebar_label": "Roadmap" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-UI": { - "title": "Polkadot UI", - "sidebar_label": "Polkadot UI" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "maintain-governance-index": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "maintain-guides-how-to-nominate": { - "title": "How to nominate", - "sidebar_label": "How to nominate" - }, - "maintain-guides-how-to-systemd": { - "title": "How to run your node as a `systemd` process", - "sidebar_label": "How to run your node as a `systemd` process" - }, - "maintain-guides-how-to-validate": { - "title": "How to validate", - "sidebar_label": "How to validate" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-validator": { - "title": "Node Operator / Validator", - "sidebar_label": "Node Operator / Validator" - }, - "maintain-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "news": { - "title": "This Week in Polkadot", - "sidebar_label": "This Week in Polkadot" - }, - "research": { - "title": "Polkadot Research", - "sidebar_label": "Polkadot Research" - } - }, - "links": { - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - }, - "categories": { - "Main": "Main", - "Build": "Build", - "Learn": "Learn", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "A scalable, heterogeneous multichain.|no description given": "A scalable, heterogeneous multichain.", - "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.|no description given": "Polkadot is a platform with low barriers to entry for flexible, autonomous economies acting together within Polkadot’s shared security umbrella. Polkadot is a revolution, not just in blockchain technology but also towards enabling fairer peer-to-peer digital jurisdictions.", - "Learn More|no description given": "Learn More", - "Build|no description given": "Build", - "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.|no description given": "Polkadot empowers builders and developers to create blockchains to suit their needs and to benefit from interoperability and shared security.", - "Builder's Portal|no description given": "Builder's Portal", - "Validators|no description given": "Validators", - "Run a validator and help to secure the Polkadot network while earning rewards.|no description given": "Run a validator and help to secure the Polkadot network while earning rewards.", - "Collators|no description given": "Collators", - "Run a collator to package the parachain blocks and pass them to validators for verification.|no description given": "Run a collator to package the parachain blocks and pass them to validators for verification.", - "Become a Maintainer|no description given": "Become a Maintainer", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ur-IN.json b/website/i18n/ur-IN.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/ur-IN.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/ur-PK.json b/website/i18n/ur-PK.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/ur-PK.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/i18n/zh-CN.json b/website/i18n/zh-CN.json deleted file mode 100644 index 854908f2ae4a..000000000000 --- a/website/i18n/zh-CN.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "下一页", - "previous": "上一页", - "tagline": "這裡是給学习，開發或运行 Polkadot 协议上的节点感兴趣的人的中心", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot 開發者入门指南", - "sidebar_label": "Polkadot 開發者入门指南" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "黑客马拉松", - "sidebar_label": "黑客马拉松" - }, - "build-index": { - "title": "开发者专页", - "sidebar_label": "开发者专页" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "节点互动", - "sidebar_label": "节点互动" - }, - "build-node-management": { - "title": "节点管理", - "sidebar_label": "节点管理" - }, - "build-oracle": { - "title": "预言机", - "sidebar_label": "预言机" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "平行链开发套件 (PDKs)", - "sidebar_label": "平行链开发套件(PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot 协议资料", - "sidebar_label": "Polkadot 协议" - }, - "build-smart-contracts": { - "title": "智能合约", - "sidebar_label": "智能合约" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "工具索引", - "sidebar_label": "工具索引" - }, - "build-transaction-construction": { - "title": "交易创建和签名", - "sidebar_label": "交易创建" - }, - "build-wallets": { - "title": "Polkadot 钱包", - "sidebar_label": "Polkadot 钱包" - }, - "claims": { - "title": "Polkadot 认领", - "sidebar_label": "认领" - }, - "community": { - "title": "社区", - "sidebar_label": "社区" - }, - "contributing": { - "title": "贡献", - "sidebar_label": "贡献" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "常见问题(FAQ)", - "sidebar_label": "常见问题(FAQ)" - }, - "getting-started": { - "title": "入门教程", - "sidebar_label": "入门教程" - }, - "glossary": { - "title": "专业术语", - "sidebar_label": "专业术语" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "奖助金计划" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "漏洞奖励计画", - "sidebar_label": "漏洞奖励计画" - }, - "kusama-claims": { - "title": "Kusama 领取", - "sidebar_label": "领取" - }, - "kusama-coc": { - "title": "Kusama 守则", - "sidebar_label": "守则" - }, - "kusama-community": { - "title": "Kusama 社区", - "sidebar_label": "社区" - }, - "kusama-endpoints": { - "title": "Kusama 终端", - "sidebar_label": "Kusama 终端" - }, - "kusama-faucet": { - "title": "Kusama 水龙头", - "sidebar_label": "水龙头" - }, - "kusama-getting-started": { - "title": "入门教程", - "sidebar_label": "入门教程" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "主页" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social 恢复", - "sidebar_label": "账户恢复" - }, - "kusama-timeline": { - "title": "Kusama 时间线", - "sidebar_label": "时间线" - }, - "learn-account-generation": { - "title": "创建帐户", - "sidebar_label": "创建帐户" - }, - "learn-account-restore": { - "title": "备份和恢复账户", - "sidebar_label": "备份和恢复账户" - }, - "learn-accounts": { - "title": "Polkadot 账户", - "sidebar_label": "Polkadot 账户" - }, - "learn-architecture": { - "title": "Polkadot 架构", - "sidebar_label": "Polkadot 架构" - }, - "learn-auction": { - "title": "平行链插槽拍卖", - "sidebar_label": "平行链插槽拍卖" - }, - "learn-availability": { - "title": "可用性和有效性", - "sidebar_label": "可用性和有效性" - }, - "learn-balance-transfers": { - "title": "转账", - "sidebar_label": "如何转账" - }, - "learn-bridges": { - "title": "桥接", - "sidebar_label": "桥接" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Dfinity 与 Polkadot 区别", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot 和 以太坊 2.0", - "sidebar_label": "以太坊 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot 与 Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "与其它区块链比较", - "sidebar_label": "与其它比较" - }, - "learn-consensus": { - "title": "Polkadot 共识机制", - "sidebar_label": "Polkadot 共识机制" - }, - "learn-crosschain": { - "title": "跨链消息传递 (XCMP)", - "sidebar_label": "跨链消息传递 (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "密码学讲解", - "sidebar_label": "密码学讲解" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "治理", - "sidebar_label": "治理" - }, - "learn-identity": { - "title": "身份", - "sidebar_label": "身份" - }, - "learn-implementations": { - "title": "其它程序语言实现", - "sidebar_label": "其它程序语言实现" - }, - "learn-implementers-guide": { - "title": "平行链构建指南", - "sidebar_label": "平行链构建指南" - }, - "learn-keys": { - "title": "密匙", - "sidebar_label": "密匙" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot 上线流程", - "sidebar_label": "Polkadot 上线流程" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "平行链", - "sidebar_label": "平行链" - }, - "learn-parathreads": { - "title": "平行线程", - "sidebar_label": "平行线程" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot 主机 (PH)", - "sidebar_label": "Polkadot 主机 (PH)" - }, - "learn-proxies": { - "title": "代理账户", - "sidebar_label": "代理账户" - }, - "learn-randomness": { - "title": "随机性", - "sidebar_label": "随机性" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "网络安全", - "sidebar_label": "网络安全" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "抵押", - "sidebar_label": "抵押" - }, - "learn-transaction-fees": { - "title": "交易费用", - "sidebar_label": "交易费用" - }, - "learn-treasury": { - "title": "财政库", - "sidebar_label": "财政库" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "错误和如何解决", - "sidebar_label": "解决错误" - }, - "maintain-guides-democracy": { - "title": "参与民主权利", - "sidebar_label": "参与民主权利" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "加入议会", - "sidebar_label": "加入议会" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "成为提名人 (Kusama)", - "sidebar_label": "成为提名人 (Kusama)" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "设置哨兵节点", - "sidebar_label": "设置哨兵节点" - }, - "maintain-guides-how-to-systemd": { - "title": "如何把节点设定为 `systemd` 进程运行", - "sidebar_label": "如何把节点设定为 `systemd` 进程运行" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "如何升级验证人节点", - "sidebar_label": "如何升级验证人节点" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "如何使用 Polkadot 安全验证人设置", - "sidebar_label": "如何使用 Polkadot 安全验证人设置" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "运行验证人 (Kusama)", - "sidebar_label": "如何在 Kusama 上运行验证节点" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "运行验证人 (Polkadot)", - "sidebar_label": "如何在 Polkadot 上运行验证节点" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "投票选举议员", - "sidebar_label": "投票选举议员" - }, - "maintain-guides-secure-validator": { - "title": "安全验证人节点", - "sidebar_label": "安全验证人节点" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "验证人付款概述", - "sidebar_label": "验证人付款概述" - }, - "maintain-index": { - "title": "网络维护者", - "sidebar_label": "网络维护者" - }, - "maintain-networks": { - "title": "网络", - "sidebar_label": "网络" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "设置全节点", - "sidebar_label": "设置全节点" - }, - "maintain-wss": { - "title": "为远程连接设置安全的 WebSocket", - "sidebar_label": "为远程连接设置安全的 WebSocket" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot 開發者入门指南", - "sidebar_label": "Polkadot 開發者入门指南" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "治理", - "sidebar_label": "治理" - }, - "mirror-learn-identity": { - "title": "身份", - "sidebar_label": "身份" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "国库", - "sidebar_label": "国库" - }, - "mirror-maintain-errors": { - "title": "错误和如何解决", - "sidebar_label": "解决错误" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "成为提名人 (Kusama)", - "sidebar_label": "成为提名人 (Kusama)" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "运行验证人 (Kusama)", - "sidebar_label": "如何在 Kusama 上运行验证节点" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "研究专页", - "sidebar_label": "研究专页" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "入门指南", - "Learn": "学习", - "Build": "建立", - "Maintain ": "参与 ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "概述", - "Learn": "学习", - "Build": "建立", - "Maintain": "参与" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "浏览文档", - "Ask questions about the documentation and project|no description given": "询问有关文档和项目的问题", - "Join the community|no description given": "加入社区", - "Find out what's new with this project|no description given": "了解项目的最新发展", - "Stay up to date|no description given": "保持最新", - "Need help?|no description given": "需要协助?", - "This project is maintained by a dedicated group of people.|statement made to reader": "该项目由一群专职人员维护", - "Help Translate|recruit community translators for your project": "参与翻译", - "Edit this Doc|recruitment message asking to edit the doc source": "修改", - "Translate this Doc|recruitment message asking to translate the docs": "翻译" - } -} diff --git a/website/i18n/zh-TW.json b/website/i18n/zh-TW.json deleted file mode 100644 index 44cb88146ed2..000000000000 --- a/website/i18n/zh-TW.json +++ /dev/null @@ -1,509 +0,0 @@ -{ - "_comment": "This file is auto-generated by write-translations.js", - "localized-strings": { - "next": "Next", - "previous": "Previous", - "tagline": "The hub for those interested in learning, building, or running a node on Polkadot.", - "docs": { - "ambassadors": { - "title": "Polkadot Ambassador Programme", - "sidebar_label": "Polkadot Ambassador Programme" - }, - "build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "build-cumulus": { - "title": "Cumulus", - "sidebar_label": "Cumulus" - }, - "build-hackathon": { - "title": "Hackathon", - "sidebar_label": "Hackathon" - }, - "build-index": { - "title": "Builder's Portal", - "sidebar_label": "Builder's Portal" - }, - "build-integration": { - "title": "Polkadot Integration Guide", - "sidebar_label": "Integration Initiation" - }, - "build-node-interaction": { - "title": "Node Interaction", - "sidebar_label": "Node Interaction" - }, - "build-node-management": { - "title": "Node Management", - "sidebar_label": "Node Management" - }, - "build-oracle": { - "title": "Oracles", - "sidebar_label": "Oracles" - }, - "build-parachains-rococo": { - "title": "Building Parachains on Rococo", - "sidebar_label": "Building Parachains on Rococo" - }, - "build-pdk": { - "title": "Parachain Development Kits (PDKs)", - "sidebar_label": "Parachain Development Kits (PDKs)" - }, - "build-protocol-info": { - "title": "Polkadot Protocol Information", - "sidebar_label": "Polkadot Protocol" - }, - "build-smart-contracts": { - "title": "Smart Contracts", - "sidebar_label": "Smart Contracts" - }, - "build-ss58-registry": { - "title": "SS58 Registry", - "sidebar_label": "SS58 Registry" - }, - "build-tools-index": { - "title": "Tool Index", - "sidebar_label": "Tool Index" - }, - "build-transaction-construction": { - "title": "Transaction Construction and Signing", - "sidebar_label": "Transaction Construction" - }, - "build-wallets": { - "title": "Polkadot Wallets", - "sidebar_label": "Polkadot Wallets" - }, - "claims": { - "title": "Polkadot Claims", - "sidebar_label": "Claims" - }, - "community": { - "title": "Community", - "sidebar_label": "Community" - }, - "contributing": { - "title": "Contributing", - "sidebar_label": "Contributing" - }, - "contributors": { - "title": "Contributors", - "sidebar_label": "Contributors" - }, - "ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "faq": { - "title": "Frequently Asked Questions (FAQs)", - "sidebar_label": "Frequently Asked Questions (FAQs)" - }, - "getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "glossary": { - "title": "Glossary", - "sidebar_label": "Glossary" - }, - "grants": { - "title": "Web3 Foundation Grants", - "sidebar_label": "Grants" - }, - "kusama-adverserial-cheatsheet": { - "title": "Adverserial Cheatsheet", - "sidebar_label": "Adverserial Cheatsheet" - }, - "kusama-bug-bounty": { - "title": "Bug Bounty", - "sidebar_label": "Bug Bounty" - }, - "kusama-claims": { - "title": "Kusama Claims", - "sidebar_label": "Claims" - }, - "kusama-coc": { - "title": "Kusama Code of Conduct", - "sidebar_label": "Code of Conduct" - }, - "kusama-community": { - "title": "Kusama Community", - "sidebar_label": "Community" - }, - "kusama-endpoints": { - "title": "Kusama Endpoints", - "sidebar_label": "Kusama Endpoints" - }, - "kusama-faucet": { - "title": "Kusama Faucet", - "sidebar_label": "Faucet" - }, - "kusama-getting-started": { - "title": "Getting Started", - "sidebar_label": "Getting Started" - }, - "kusama-index": { - "title": "Kusama", - "sidebar_label": "Home" - }, - "kusama-ledger": { - "title": "Using Ledger Devices", - "sidebar_label": "Ledger Devices" - }, - "kusama-parameters": { - "title": "Kusama Parameters", - "sidebar_label": "Parameters" - }, - "kusama-social-recovery": { - "title": "Social Recovery", - "sidebar_label": "Account Recovery" - }, - "kusama-timeline": { - "title": "Kusama Timeline", - "sidebar_label": "Timeline" - }, - "learn-account-generation": { - "title": "Account Generation", - "sidebar_label": "Account Generation" - }, - "learn-account-restore": { - "title": "Backing up and Restoring Accounts", - "sidebar_label": "Backing up and Restoring Accounts" - }, - "learn-accounts": { - "title": "Polkadot Accounts", - "sidebar_label": "Polkadot Accounts" - }, - "learn-architecture": { - "title": "Architecture", - "sidebar_label": "Architecture" - }, - "learn-auction": { - "title": "Parachain Slots Auction", - "sidebar_label": "Parachain Slots Auction" - }, - "learn-availability": { - "title": "Availability and Validity", - "sidebar_label": "Availability and Validity" - }, - "learn-balance-transfers": { - "title": "Balance Transfers", - "sidebar_label": "How to transfer Balances" - }, - "learn-bridges": { - "title": "Bridges", - "sidebar_label": "Bridges" - }, - "learn-collator": { - "title": "Collator", - "sidebar_label": "Collator" - }, - "learn-comparisons-dfinity": { - "title": "Polkadot and Dfinity", - "sidebar_label": "Dfinity" - }, - "learn-comparisons-ethereum-2": { - "title": "Polkadot and Ethereum 2.0", - "sidebar_label": "Ethereum 2.0" - }, - "learn-comparisons-cosmos": { - "title": "Polkadot and Cosmos", - "sidebar_label": "Cosmos" - }, - "learn-comparisons": { - "title": "Polkadot Comparisons", - "sidebar_label": "Other comparisons" - }, - "learn-consensus": { - "title": "Polkadot Consensus", - "sidebar_label": "Polkadot Consensus" - }, - "learn-crosschain": { - "title": "Cross-chain Message Passing (XCMP)", - "sidebar_label": "Cross-chain Message Passing (XCMP)" - }, - "learn-crowdloans": { - "title": "Parachain Crowdloans", - "sidebar_label": "Parachain Crowdloans" - }, - "learn-cryptography": { - "title": "Cryptography Explainer", - "sidebar_label": "Cryptography Explainer" - }, - "learn-DOT": { - "title": "DOT", - "sidebar_label": "DOT" - }, - "learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "learn-implementations": { - "title": "Polkadot Implementations", - "sidebar_label": "Polkadot Implementations" - }, - "learn-implementers-guide": { - "title": "Parachain Implementer's Guide", - "sidebar_label": "Parachain Implementer's Guide" - }, - "learn-keys": { - "title": "Polkadot Keys", - "sidebar_label": "Polkadot Keys" - }, - "learn-kusama-vs-polkadot": { - "title": "What is the difference between Polkadot and Kusama?", - "sidebar_label": "Comparing Polkadot and Kusama" - }, - "learn-launch": { - "title": "Polkadot Launch Phases", - "sidebar_label": "Polkadot Launch Phases" - }, - "learn-ledger": { - "title": "Using the Polkadot Ledger Application", - "sidebar_label": "Ledger Application" - }, - "learn-nominator": { - "title": "Nominator", - "sidebar_label": "Nominator" - }, - "learn-parachains": { - "title": "Parachains", - "sidebar_label": "Parachains" - }, - "learn-parathreads": { - "title": "Parathreads", - "sidebar_label": "Parathreads" - }, - "learn-phragmen": { - "title": "Sequential Phragmén Method", - "sidebar_label": "Sequential Phragmén Method" - }, - "learn-polkadot-host": { - "title": "Polkadot Host (PH)", - "sidebar_label": "Polkadot Host (PH)" - }, - "learn-proxies": { - "title": "Proxy Accounts", - "sidebar_label": "Proxy Accounts" - }, - "learn-randomness": { - "title": "Randomness", - "sidebar_label": "Randomness" - }, - "learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "learn-scams": { - "title": "How to Protect Yourself from Scams", - "sidebar_label": "How to Protect Yourself from Scams" - }, - "learn-security": { - "title": "Security of the network", - "sidebar_label": "Security of the network" - }, - "learn-simple-payouts": { - "title": "Simple Payouts", - "sidebar_label": "Simple Payouts" - }, - "learn-spree": { - "title": "SPREE", - "sidebar_label": "SPREE" - }, - "learn-staking": { - "title": "Staking", - "sidebar_label": "Staking" - }, - "learn-transaction-fees": { - "title": "Transaction Fees", - "sidebar_label": "Transaction Fees" - }, - "learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "learn-validator": { - "title": "Validator", - "sidebar_label": "Validator" - }, - "learn-wasm": { - "title": "WebAssembly (Wasm)", - "sidebar_label": "WebAssembly (Wasm)" - }, - "maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "maintain-guides-democracy": { - "title": "Participate in Democracy", - "sidebar_label": "Participate in Democracy" - }, - "maintain-guides-how-to-chill": { - "title": "How to Chill", - "sidebar_label": "How to Chill" - }, - "maintain-guides-how-to-join-council": { - "title": "Join the Council", - "sidebar_label": "Join the Council" - }, - "maintain-guides-how-to-monitor-your-node": { - "title": "Monitor your node", - "sidebar_label": "Monitor your node" - }, - "maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "maintain-guides-how-to-nominate-polkadot": { - "title": "How to Nominate on Polkadot", - "sidebar_label": "How to Nominate on Polkadot" - }, - "maintain-guides-how-to-setup-sentry-node": { - "title": "Set Up a Sentry Node - Public Node", - "sidebar_label": "Set Up a Sentry Node" - }, - "maintain-guides-how-to-systemd": { - "title": "Using systemd for the Validator Node", - "sidebar_label": "Using systemd for the Validator Node" - }, - "maintain-guides-how-to-unbond": { - "title": "Unbonding and Rebonding", - "sidebar_label": "Unbonding and Rebonding" - }, - "maintain-guides-how-to-upgrade": { - "title": "How to Upgrade Your Validator", - "sidebar_label": "How to Upgrade Your Validator" - }, - "maintain-guides-how-to-use-polkadot-secure-validator": { - "title": "How to use Polkadot Secure Validator Setup", - "sidebar_label": "How to use Polkadot Secure Validator Setup" - }, - "maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "maintain-guides-how-to-validate-polkadot": { - "title": "Run a Validator (Polkadot)", - "sidebar_label": "How to run a Validator on Polkadot" - }, - "maintain-guides-how-to-vote-councillor": { - "title": "Voting for Councillors", - "sidebar_label": "Voting for Councillors" - }, - "maintain-guides-secure-validator": { - "title": "Secure Validator", - "sidebar_label": "Secure Validator" - }, - "maintain-guides-society-kusama": { - "title": "Join Kappa Sigma Mu", - "sidebar_label": "Join Kappa Sigma Mu" - }, - "maintain-guides-validator-payout": { - "title": "Validator Payout Overview", - "sidebar_label": "Validator Payout Overview" - }, - "maintain-index": { - "title": "Network Maintainers", - "sidebar_label": "Network Maintainers" - }, - "maintain-networks": { - "title": "Networks", - "sidebar_label": "Networks" - }, - "maintain-polkadot-parameters": { - "title": "Polkadot Parameters", - "sidebar_label": "Parameters" - }, - "maintain-sync": { - "title": "Set up a Full Node", - "sidebar_label": "Set up a Full Node" - }, - "maintain-wss": { - "title": "Set up Secure WebSocket for Remote Connections", - "sidebar_label": "Set up Secure WebSocket for Remote Connections" - }, - "mirror-build-build-with-polkadot": { - "title": "Polkadot Builders Starter's Guide", - "sidebar_label": "Polkadot Builders Starter's Guide" - }, - "mirror-ens": { - "title": "Adding accounts to an ENS domain", - "sidebar_label": "Using ENS with DOT/KSM accounts" - }, - "mirror-learn-governance": { - "title": "Governance", - "sidebar_label": "Governance" - }, - "mirror-learn-identity": { - "title": "Identity", - "sidebar_label": "Identity" - }, - "mirror-learn-registrar": { - "title": "Using W3F Registrar", - "sidebar_label": "How to use W3F Registrar" - }, - "mirror-learn-treasury": { - "title": "Treasury", - "sidebar_label": "Treasury" - }, - "mirror-maintain-errors": { - "title": "Errors and How to Resolve Them", - "sidebar_label": "Resolving Errors" - }, - "mirror-maintain-guides-how-to-nominate-kusama": { - "title": "Be a Nominator (Kusama)", - "sidebar_label": "Nominator Guide" - }, - "mirror-maintain-guides-how-to-validate-kusama": { - "title": "Run a Validator (Kusama)", - "sidebar_label": "How to run a Validator on Kusama" - }, - "mirror-thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - }, - "redenomination": { - "title": "Redenomination of DOT", - "sidebar_label": "Redenomination of DOT" - }, - "research": { - "title": "Research Pages", - "sidebar_label": "Research Pages" - }, - "thousand-validators": { - "title": "Thousand Validators Programme", - "sidebar_label": "Thousand Validators Programme" - } - }, - "links": { - "Get Started": "Get Started", - "Learn": "Learn", - "Build": "Build", - "Maintain ": "Maintain ", - "Kusama": "Kusama", - "Contribute": "Contribute" - }, - "categories": { - "General": "General", - "Learn": "Learn", - "Build": "Build", - "Maintain": "Maintain" - } - }, - "pages-strings": { - "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)|no description given": "Learn more using the [documentation on this site.](/test-site/docs/en/doc1.html)", - "Browse Docs|no description given": "Browse Docs", - "Ask questions about the documentation and project|no description given": "Ask questions about the documentation and project", - "Join the community|no description given": "Join the community", - "Find out what's new with this project|no description given": "Find out what's new with this project", - "Stay up to date|no description given": "Stay up to date", - "Need help?|no description given": "Need help?", - "This project is maintained by a dedicated group of people.|statement made to reader": "This project is maintained by a dedicated group of people.", - "Help Translate|recruit community translators for your project": "Help Translate", - "Edit this Doc|recruitment message asking to edit the doc source": "Edit", - "Translate this Doc|recruitment message asking to translate the docs": "Translate" - } -} diff --git a/website/languages.js b/website/languages.js deleted file mode 100755 index a5bd346ccf3a..000000000000 --- a/website/languages.js +++ /dev/null @@ -1,186 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const languages = [ - { - enabled: true, - name: 'English', - tag: 'en', - }, - { - enabled: false, - name: '日本語', - tag: 'ja', - }, - { - enabled: false, - name: 'العربية', - tag: 'ar', - }, - { - enabled: false, - name: 'Bosanski', - tag: 'bs-BA', - }, - { - enabled: false, - name: 'Català', - tag: 'ca', - }, - { - enabled: false, - name: 'Čeština', - tag: 'cs', - }, - { - enabled: false, - name: 'Dansk', - tag: 'da', - }, - { - enabled: false, - name: 'Deutsch', - tag: 'de', - }, - { - enabled: false, - name: 'Ελληνικά', - tag: 'el', - }, - { - enabled: false, - name: 'Español', - tag: 'es-ES', - }, - { - enabled: false, - name: 'فارسی', - tag: 'fa-IR', - }, - { - enabled: false, - name: 'Suomi', - tag: 'fi', - }, - { - enabled: false, - name: 'Français', - tag: 'fr', - }, - { - enabled: false, - name: 'עִברִית', - tag: 'he', - }, - { - enabled: false, - name: 'Magyar', - tag: 'hu', - }, - { - enabled: false, - name: 'Bahasa Indonesia', - tag: 'id-ID', - }, - { - enabled: false, - name: 'Italiano', - tag: 'it', - }, - { - enabled: false, - name: 'Afrikaans', - tag: 'af', - }, - { - enabled: false, - name: '한국어', - tag: 'ko', - }, - { - enabled: false, - name: 'मराठी', - tag: 'mr-IN', - }, - { - enabled: false, - name: 'Nederlands', - tag: 'nl', - }, - { - enabled: false, - name: 'Norsk', - tag: 'no-NO', - }, - { - enabled: false, - name: 'Polskie', - tag: 'pl', - }, - { - enabled: false, - name: 'Português', - tag: 'pt-PT', - }, - { - enabled: false, - name: 'Português (Brasil)', - tag: 'pt-BR', - }, - { - enabled: false, - name: 'Română', - tag: 'ro', - }, - { - enabled: true, - name: 'Русский', - tag: 'ru', - }, - { - enabled: false, - name: 'Slovenský', - tag: 'sk-SK', - }, - { - enabled: false, - name: 'Српски језик (Ћирилица)', - tag: 'sr', - }, - { - enabled: false, - name: 'Svenska', - tag: 'sv-SE', - }, - { - enabled: false, - name: 'Türkçe', - tag: 'tr', - }, - { - enabled: false, - name: 'Українська', - tag: 'uk', - }, - { - enabled: false, - name: 'Tiếng Việt', - tag: 'vi', - }, - { - enabled: true, - name: '中文', - tag: 'zh-CN', - }, - { - enabled: false, - name: '繁體中文', - tag: 'zh-TW', - }, -]; - -module.exports = languages; diff --git a/website/pages/en/help-with-translations.js b/website/pages/en/help-with-translations.js deleted file mode 100755 index 19dbc9cc00cd..000000000000 --- a/website/pages/en/help-with-translations.js +++ /dev/null @@ -1,69 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require('react'); - -const CompLibrary = require('../../core/CompLibrary.js'); - -const Container = CompLibrary.Container; -const GridBlock = CompLibrary.GridBlock; - -const translate = require('../../server/translate.js').translate; - -class Help extends React.Component { - render() { - const supportLinks = [ - { - content: ( - - Learn more using the [documentation on this - site.](/test-site/docs/en/doc1.html) - - ), - title: Browse Docs, - }, - { - content: ( - - Ask questions about the documentation and project - - ), - title: Join the community, - }, - { - content: Find out what's new with this project, - title: Stay up to date, - }, - ]; - - return ( -
    - -
    -
    -

    - Need help? -

    -
    -

    - - This project is maintained by a dedicated group of people. - -

    - -
    -     -
    - ); - } -} - -Help.defaultProps = { - language: 'en', -}; - -module.exports = Help; diff --git a/website/pages/en/help.js b/website/pages/en/help.js deleted file mode 100755 index 2b790e46037f..000000000000 --- a/website/pages/en/help.js +++ /dev/null @@ -1,54 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require('react'); - -const CompLibrary = require('../../core/CompLibrary.js'); - -const Container = CompLibrary.Container; -const GridBlock = CompLibrary.GridBlock; - -function Help(props) { - const {config: siteConfig, language = ''} = props; - const {baseUrl, docsUrl} = siteConfig; - const docsPart = `${docsUrl ? `${docsUrl}/` : ''}`; - const langPart = `${language ? `${language}/` : ''}`; - const docUrl = doc => `${baseUrl}${docsPart}${langPart}${doc}`; - - const supportLinks = [ - { - content: `Learn more using the [documentation on this site.](${docUrl( - 'doc1.html', - )})`, - title: 'Browse Docs', - }, - { - content: 'Ask questions about the documentation and project', - title: 'Join the community', - }, - { - content: "Find out what's new with this project", - title: 'Stay up to date', - }, - ]; - - return ( -
    - -
    -
    -

    Need help?

    -
    -

    This project is maintained by a dedicated group of people.

    - -
    -     -
    - ); -} - -module.exports = Help; diff --git a/website/pages/en/index.js b/website/pages/en/index.js deleted file mode 100644 index f87367abdd84..000000000000 --- a/website/pages/en/index.js +++ /dev/null @@ -1,151 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require("react"); - -const Container = require("react-bootstrap/Container"); -const Row = require("react-bootstrap/Row"); -const Col = require("react-bootstrap/Col"); - -class HomeNav extends React.Component { - render() { - // const {siteConfig, language = ''} = this.props; - - const NavContainer = (props) => ( -
    - - {props.children} - -
    - ); - - const NavItem = (props) => ( - - -
    -

    {props.title}

    -

    {props.content}

    -
    -     - - ); - - return ( - - - - - - ); - } -} - -class HomeFooter extends React.Component { - render() { - const FooterContainer = (props) => ( -
    - - {props.children} - -
    - ); - - const LearnKusama = () => ( - - - -

    Learn about Polkadot’s canary network Kusama

    -

    - Kusama is Polkadot’s “canary network”, a scalable, multi-chain network for radical - innovation and early stage Polkadot deployments. For developers, Kusama is a proving - ground for all things Polkadot I.e runtime upgrades, on-chain governance, parachains, - parathreads, etc. -

    - - - - - - - - ); - - const ImproveWiki = () => ( - - - - language - -

    Help improve this wiki

    -

    - This wiki was started by and is maintained by Web3 Foundation. It is an open-source-ish - project and aims to be the most extensive resource of knowledge on Polkadot and the - Polkadot ecosystem. -

    - - - - - - - - - - - ); - - return ( - - - - - ); - } -} - -class Index extends React.Component { - render() { - const { config: siteConfig, language = "" } = this.props; - const { baseUrl, docsUrl } = siteConfig; - const docsPart = `${docsUrl ? `${docsUrl}/` : ""}`; - const langPart = `${language ? `${language}/` : ""}`; - const docUrl = (doc) => `${baseUrl}${docsPart}${langPart}${doc}`; - - return ( -
    - - -
    - ); - } -} - -module.exports = Index; diff --git a/website/pages/en/users.js b/website/pages/en/users.js deleted file mode 100755 index 039dc39ffa50..000000000000 --- a/website/pages/en/users.js +++ /dev/null @@ -1,48 +0,0 @@ -/** - * Copyright (c) 2017-present, Facebook, Inc. - * - * This source code is licensed under the MIT license found in the - * LICENSE file in the root directory of this source tree. - */ - -const React = require('react'); - -const CompLibrary = require('../../core/CompLibrary.js'); - -const Container = CompLibrary.Container; - -class Users extends React.Component { - render() { - const {config: siteConfig} = this.props; - if ((siteConfig.users || []).length === 0) { - return null; - } - - const editUrl = `${siteConfig.repoUrl}/edit/master/website/siteConfig.js`; - const showcase = siteConfig.users.map(user => ( - - {user.caption} - - )); - - return ( -
    - -
    -
    -

    Who is Using This?

    -

    This project is used by many folks

    -
    -
    {showcase}
    -

    Are you using this project?

    - - Add your company - -
    -     -
    - ); - } -} - -module.exports = Users; diff --git a/website/postprocess.js b/website/postprocess.js deleted file mode 100644 index fcf07553c13a..000000000000 --- a/website/postprocess.js +++ /dev/null @@ -1,11 +0,0 @@ -// postprocess.js -'use strict'; - -require('loud-rejection/register'); - -const path = require('path'); -const { postProcess } = require('../scripts/utils'); - -const buildDirectory = path.join(__dirname, 'build/polkadot-wiki'); - -postProcess(buildDirectory); diff --git a/website/sidebars.json b/website/sidebars.json deleted file mode 100644 index 1abeee68be8a..000000000000 --- a/website/sidebars.json +++ /dev/null @@ -1,170 +0,0 @@ -{ - "docs": { - "General": [ - "getting-started", - "claims", - "redenomination", - "grants", - "thousand-validators", - "ambassadors", - "research", - "community", - "contributing", - "contributors", - "glossary", - "ens", - "learn-ledger", - "learn-scams", - "how-to-dyor", - "faq" - ], - "Learn": [ - "learn-launch", - { - "type": "subcategory", - "label": "Basics", - "ids": [ - "learn-architecture", - "learn-accounts", - "learn-account-generation", - "learn-account-restore", - "learn-DOT", - "learn-security", - "learn-consensus", - "learn-nominator", - "learn-validator", - "learn-collator", - "learn-governance", - "learn-identity", - "learn-balance-transfers", - "learn-transaction-fees", - "learn-polkadot-host", - "learn-treasury", - "learn-registrar", - "learn-runtime-upgrades" - ] - }, - { - "type": "subcategory", - "label": "Parachains", - "ids": [ - "learn-parachains", - "learn-parathreads", - "learn-bridges", - "learn-common-goods", - "learn-auction", - "learn-crowdloans" - ] - }, - { - "type": "subcategory", - "label": "Advanced", - "ids": [ - "learn-staking", - "learn-proxies", - "learn-availability", - "learn-randomness", - "learn-crosschain", - "learn-spree", - "learn-wasm", - "learn-phragmen", - "learn-simple-payouts" - ] - }, - { - "type": "subcategory", - "label": "Cryptography", - "ids": ["learn-cryptography", "learn-keys"] - }, - { - "type": "subcategory", - "label": "Polkadot Comparisons", - "ids": [ - "learn-kusama-vs-polkadot", - "learn-comparisons-ethereum-2", - "learn-comparisons-cosmos", - "learn-comparisons" - ] - } - ], - "Build": [ - "build-index", - { - "type": "subcategory", - "label": "Development Guide", - "ids": [ - "build-build-with-polkadot", - "build-pdk", - "learn-implementers-guide", - "build-cumulus", - "build-parachains-rococo", - "build-smart-contracts", - "build-oracle", - "build-ss58-registry", - "build-wallets" - ] - }, - { - "type": "subcategory", - "label": "Integration Guide", - "ids": [ - "build-integration", - "build-protocol-info", - "build-integrate-assets", - "build-node-management", - "build-node-interaction", - "build-transaction-construction" - ] - }, - { - "type": "subcategory", - "label": "Tools", - "ids": ["build-tools-index"] - }, - { - "type": "subcategory", - "label": "Resources", - "ids": ["build-hackathon"] - } - ], - "Maintain": [ - "maintain-index", - "maintain-polkadot-parameters", - { - "type": "subcategory", - "label": "Nodes and Dapps", - "ids": ["maintain-sync", "maintain-networks", "maintain-wss", "maintain-errors"] - }, - { - "type": "subcategory", - "label": "Nominator Guides", - "ids": ["maintain-guides-how-to-nominate-polkadot", "maintain-guides-how-to-unbond"] - }, - { - "type": "subcategory", - "label": "Validator Guides", - "ids": [ - "maintain-guides-how-to-validate-polkadot", - "maintain-guides-validator-payout", - "maintain-guides-how-to-systemd", - "maintain-guides-secure-validator", - "maintain-guides-how-to-use-polkadot-validator-setup", - "maintain-guides-how-to-setup-a-validator-with-reverse-proxy", - "maintain-guides-how-to-upgrade", - "maintain-guides-how-to-monitor-your-node", - "maintain-guides-how-to-chill", - "maintain-guides-how-to-stop-validating" - ] - }, - { - "type": "subcategory", - "label": "Governance Guides", - "ids": [ - "maintain-guides-democracy", - "maintain-guides-how-to-join-council", - "maintain-guides-how-to-vote-councillor" - ] - } - ] - } -} diff --git a/website/siteConfig.js b/website/siteConfig.js deleted file mode 100644 index 18818bd6d5a2..000000000000 --- a/website/siteConfig.js +++ /dev/null @@ -1,119 +0,0 @@ -const { baseUrlPattern } = require("../scripts/utils"); - -const isBuilding = process.env.BUILDING; -const isPub = process.env.PUBLISHING; - -const siteConfig = { - title: "Polkadot Wiki", // Title for your website. - tagline: "The hub for those interested in learning, building, or running a node on Polkadot.", - // url: 'https://wiki.polkadot.network', // Your website URL - baseUrl: isBuilding ? baseUrlPattern : "/", - projectName: "polkadot-wiki", - organizationName: "w3f", - cname: "wiki.polkadot.network", - - // For no header links in the top nav bar -> headerLinks: [], - headerLinks: [ - { doc: "getting-started", label: "Get Started" }, - { doc: "learn-launch", label: "Learn" }, - { doc: "build-index", label: "Build" }, - { doc: "maintain-index", label: "Maintain " }, - { href: "https://guide.kusama.network", label: "Kusama" }, - { search: true }, - { doc: "contributing", label: "Contribute" }, - { languages: true }, - ], - - /* path to images for header/footer */ - headerIcon: "img/logo_polkadot_wiki.svg", - footerIcon: "img/logo-polkadot-light.svg", - favicon: "img/favicon.ico", - - /* Colors for website */ - colors: { - primaryColor: "#e6007a", - secondaryColor: "#172026", - }, - - algolia: { - apiKey: "8bfa06b56bb8f33e5698c7f40b00b38f", - indexName: "polkadot", - algoliaOptions: { - facetFilters: ["language:LANGUAGE"], - }, // Optional, if provided by Algolia - }, - - /* Custom fonts for website */ - fonts: { - myFont: ["Work Sans", "sans-serif"], - }, - - // This copyright info is used in /core/Footer.js and blog RSS/Atom feeds. - copyright: `© ${new Date().getFullYear()} Web3 Foundation`, - - highlight: { - // Highlight.js theme to use for syntax highlighting in code blocks. - theme: "default", - }, - - // Add custom scripts here that would be placed in - Polkadot Wiki - - - If you are not redirected automatically, follow this link. - - diff --git a/website/static/css/copycode.css b/website/static/css/copycode.css deleted file mode 100644 index 37ac260da6fd..000000000000 --- a/website/static/css/copycode.css +++ /dev/null @@ -1,40 +0,0 @@ -/* "Copy" code block button */ -pre { - position: relative; -} - -pre .btnIcon { - position: absolute; - top: 4px; - z-index: 2; - cursor: pointer; - border: 1px solid transparent; - padding: 3px; - color: black; - background-color: rgba(255, 255, 255, 0.7); - height: 30px; - transition: all 0.25s ease-out; -} - -pre .btnIcon:hover { - text-decoration: none; - border: 1px solid silver; -} - -.btnIcon__body { - align-items: center; - display: flex; -} - -.btnIcon svg { - fill: currentColor; - margin-right: 0.4em; -} - -.btnIcon__label { - font-size: 11px; -} - -.btnClipboard { - right: 10px; -} diff --git a/website/static/css/custom.css b/website/static/css/custom.css deleted file mode 100755 index 9e23bf3cef18..000000000000 --- a/website/static/css/custom.css +++ /dev/null @@ -1,1007 +0,0 @@ -:root { - --primaryColor: #e6007a; - --secondaryColor: #172026; - --snowColor: #efefef; - --silverColor: #b7b8bb; - --nickelColor: #6d7278; - --sansFontFamily: "Work Sans", sans-serif !important; -} - -@media only screen and (min-device-width: 360px) and (max-device-width: 736px) { - .mainpage-column { - width: 100% !important; - } -} - -@media only screen and (min-width: 1024px) { -} - -@media only screen and (max-width: 1023px) { -} - -@media only screen and (min-width: 1400px) { -} - -@media only screen and (min-width: 1500px) { -} - -body { - font-family: var(--sansFontFamily); -} - -/* ========================================================================== - Typography - ========================================================================== */ - -.h1, -.h2, -.h3, -.h4, -.h5, -.h6 { - margin-top: 0; -} - -.text-dark { - color: var(--secondaryColor) !important; -} - -/* ========================================================================== - Header - ========================================================================== */ - -.fixedHeaderContainer { - background: white; -} - -.fixedHeaderContainer .headerWrapper { - max-width: 1400px !important; -} - -@media only screen and (min-width: 1024px) { - .fixedHeaderContainer { - /* border-bottom: solid 1px transparent; */ - border-bottom: solid 1px var(--snowColor); - } - body.sideNavVisible.separateOnPageNav .fixedHeaderContainer { - border-bottom: solid 1px var(--snowColor); - } -} - -.fixedHeaderContainer header .headerTitleWithLogo { - display: none; -} - -/* - Navigation - ========================================================================== */ - -.navigationSlider .slidingNav ul li > a { - color: var(--silverColor); -} - -.navigationSlider .slidingNav ul li > a:visited { - color: var(--silverColor); -} - -.navigationSlider .slidingNav ul li > a:hover, -.navigationSlider .slidingNav ul li > a:focus { - background: none; - color: white; - transition: color 0.2s ease-in-out; -} - -.navigationSlider .slidingNav ul li.siteNavGroupActive > a { - background: none; - color: var(--silverColor); -} - -.navigationSlider .slidingNav ul li.siteNavGroupActive > a:hover { - color: white; - transition: color 0.2s ease-in-out; -} - -.navigationSlider .slidingNav ul li.siteNavItemActive > a { - color: white; -} - -@media only screen and (min-width: 1024px) { - .navigationSlider .slidingNav ul li > a { - color: var(--silverColor); - } - - .navigationSlider .slidingNav ul li > a:visited { - color: var(--silverColor); - } - - .navigationSlider .slidingNav ul li > a:hover, - .navigationSlider .slidingNav ul li > a:focus { - color: var(--secondaryColor); - } - - .navigationSlider .slidingNav ul li.siteNavGroupActive > a { - color: var(--silverColor); - } - - .navigationSlider .slidingNav ul li.siteNavGroupActive > a:hover { - color: var(--secondaryColor); - } - - .navigationSlider .slidingNav ul li.siteNavItemActive > a { - color: var(--secondaryColor); - } -} - -/* - Search - ========================================================================== */ - -.navSearchWrapper.reactNavSearchWrapper::before { - border: 3px solid var(--silverColor); - transition: border 0.2s ease-in-out; - width: 13px; - height: 13px; -} - -.navSearchWrapper.reactNavSearchWrapper:hover::before { - border: 3px solid var(--secondaryColor); -} - -.navSearchWrapper.reactNavSearchWrapper::after { - background: var(--silverColor); - transition: background 0.2s ease-in-out; -} - -.navSearchWrapper.reactNavSearchWrapper:hover::after { - background: var(--secondaryColor); -} - -.reactNavSearchWrapper input#search_input_react { - color: var(--secondaryColor); - background: white; - border: solid 1px var(--snowColor); - font-family: var(--sansFontFamily); - height: 35px; - line-height: 35px; - font-size: 14px; - font-weight: bold; -} - -.reactNavSearchWrapper input#search_input_react::placeholder { - color: var(--silverColor); -} - -.reactNavSearchWrapper input#search_input_react:hover::placeholder { - /* color: var(--secondaryColor); */ -} - -.reactNavSearchWrapper input#search_input_react:focus, -.reactNavSearchWrapper input#search_input_react:active { - color: var(--secondaryColor); - border: solid 1px var(--snowColor); - background: var(--snowColor); -} - -/* - Algolia search widget - ========================================================================== */ -/*! docsearch 1.5.0 | © Algolia | github.com/algolia/docsearch */ - -.navSearchWrapper .aa-dropdown-menu { - /* background: var(--snowColor); */ - background: white; - border: none; - color: #393939; - font-size: 14px; - left: auto !important; - line-height: 1.2em; - right: 0 !important; - border-radius: 32px; - padding: 0 32px 22px; - box-shadow: 0 1rem 3rem rgba(0, 0, 0, 0.175); - border-radius: 1.5rem; - margin-top: 15px; -} - -.navSearchWrapper .aa-dropdown-menu[style*="display: block;"] { - -webkit-animation: fade-in-up 0.2s linear forwards; - animation: fade-in-up 0.2s linear forwards; -} - -.algolia-docsearch-suggestion { - color: #333; - cursor: pointer; - overflow: hidden; -} - -.algolia-docsearch-suggestion__secondary { - border-top: none !important; -} - -.algolia-docsearch-suggestion--category-header { - display: none; - background: white !important; - border-bottom: solid 1px var(--snowColor); - color: black !important; - font-weight: 700 !important; - font-size: 24px !important; - padding: 30px 0 15px 0; - margin-bottom: 15px; - text-align: left; -} - -.algolia-docsearch-suggestion__main .algolia-docsearch-suggestion--category-header { - display: block; - color: black !important; -} - -.algolia-docsearch-suggestion--highlight { - padding: 0; - color: #0064e1 !important; - background: none; - font-weight: 700; - background: white !important; -} - -.algolia-docsearch-suggestion--category-header .algolia-docsearch-suggestion--highlight { - color: inherit; - background: white !important; -} - -.aa-cursor .algolia-docsearch-suggestion--content { - color: #0064e1; - background: white !important; -} - -.aa-cursor .algolia-docsearch-suggestion--content { - color: var(--primaryColor) !important; -} - -.aa-cursor .algolia-docsearch-suggestion { - background: white !important; -} - -.algolia-docsearch-suggestion--subcategory-column { - display: none; - cursor: default; - background: white !important; - text-align: left !important; - padding-left: 0 !important; - border-right: solid 1px var(--snowColor) !important; -} - -.algolia-docsearch-suggestion--text { - display: none; -} - -.algolia-docsearch-suggestion--content { - padding: 3px 5px; - width: 100%; - border-top: none !important; - border-bottom: none; -} - -.algolia-docsearch-suggestion__main .algolia-docsearch-suggestion--content, -.algolia-docsearch-suggestion__secondary .algolia-docsearch-suggestion--content { - border-top: 0; -} - -.algolia-docsearch-suggestion--subcategory-inline { - display: inline-block; - font-weight: bold; -} - -.algolia-docsearch-suggestion--subcategory-inline:after { - content: " › "; -} - -.algolia-docsearch-suggestion--title { - display: inline; -} - -.algolia-docsearch-footer { - border-top: none !important; - text-align: right; - font-size: 12px; - padding: 30px 2px 0 0; - color: var(--snowColor) !important; -} - -.algolia-docsearch-footer .algolia-docsearch-footer--logo { - display: inline-block !important; - width: 111px; - height: 15px; - text-indent: 101%; - overflow: hidden; - white-space: nowrap; - background-image: url("data:image/svg+xml;utf8,"); - background-repeat: no-repeat; - background-size: contain; - vertical-align: middle; - padding: 0px !important; -} - -@media (min-width: 568px) { - .aa-dropdown-menu { - min-width: 400px; - } - .algolia-docsearch-suggestion--text { - display: block; - font-size: 0.9em; - padding: 2px 0; - } -} - -@media (min-width: 768px) { - .aa-dropdown-menu { - min-width: 600px; - } - .algolia-docsearch-suggestion { - display: table; - width: 100%; - } - .algolia-docsearch-suggestion__secondary { - border-top: 1px solid #606060; - } - .algolia-docsearch-suggestion--subcategory-column { - border-right: 1px solid #606060; - background: #f1f3f5; - color: #555; - display: table-cell; - overflow: hidden; - padding: 5px 7px 5px 5px; - text-align: right; - text-overflow: ellipsis; - vertical-align: top; - width: 135px; - max-width: 135px; - min-width: 135px; - /* background: black !important; */ - } - .algolia-docsearch-suggestion--subcategory-column-text { - display: none; - } - .algolia-docsearch-suggestion__secondary .algolia-docsearch-suggestion--subcategory-column-text { - display: block; - } - .algolia-docsearch-suggestion--content { - display: table-cell; - padding: 5px 10px; - } - .algolia-docsearch-suggestion--subcategory-inline { - display: none; - } - .algolia-docsearch-suggestion--title { - font-weight: 600; - } - .algolia-docsearch-suggestion--text { - display: block; - font-weight: normal; - padding: 2px; - } -} - -/* - Contribute button - ========================================================================== */ - -@media only screen and (min-width: 1024px) { - .navigationSlider .slidingNav > ul > li a[href*="contributing"] { - background: white; - height: 100%; - border: solid 1px var(--primaryColor); - border-radius: 20px; - color: var(--primaryColor); - height: 35px; - line-height: 35px; - font-size: 14px; - padding: 0 16px; - margin-left: 8px; - font-weight: bold; - } - - .navigationSlider .slidingNav > ul > li a[href*="contributing"]:hover { - background: var(--primaryColor); - color: white; - } -} - -/* - Languages - ========================================================================== */ - -#languages-menu { - margin-left: 5px; - margin-right: 5px; -} - -#languages-menu img { - opacity: 0.7; -} - -#languages-dropdown { - border: none; - background: white; - box-shadow: 0 1rem 3rem rgba(0, 0, 0, 0.175); - border-radius: 1.5rem; - width: auto; - right: 0; - top: 90px; - margin: 0 15px; -} - -#languages-dropdown.visible { - -webkit-animation: fade-in-up 0.2s linear forwards; - animation: fade-in-up 0.2s linear forwards; -} - -#languages-dropdown-items { - margin: 12px 0; - background: transparent; -} - -#languages-dropdown-items > li a { - padding: 12px 24px; - color: var(--secondaryColor); -} - -#languages-dropdown-items > li a:visited { - color: var(--secondaryColor); -} - -#languages-dropdown-items > li a:hover { - color: var(--primaryColor); -} - -@media only screen and (min-width: 1024px) { - #languages-menu { - margin-left: 0; - margin-right: 0; - } - - #languages-menu img { - display: none; - } - - #languages-dropdown { - top: 50px; - margin: 0; - } -} - -/* ========================================================================== - Docs Navigation - ========================================================================== */ - -.docsNavContainer .toggleNav h2 i { - display: none; -} - -/* ========================================================================== - Home - ========================================================================== */ - -.homeContainer { - background: white; -} - -/* - Home Nav - ========================================================================== */ - -.homeNavContainer { - padding: 3rem 0; -} - -.homeNavItem { - -webkit-transition: all 0.15s ease-in-out; - transition: all 0.15s ease-in-out; - padding: 3rem 0; - border-radius: 3.25rem !important; -} - -.homeNavItem p { - max-width: 300px; -} - -@media (min-width: 768px) { -} - -@media (min-width: 992px) { - .homeNavContainer { - height: 90vh; - min-height: 600px; - max-height: 900px; - } - - .homeNavItem { - -webkit-transition: all 0.15s ease-in-out; - transition: all 0.15s ease-in-out; - height: 60vh; - max-height: 500px; - border-radius: 3.25rem !important; - margin-top: -3rem; - } - - .homeNavItem::after { - font-size: 1.5rem; - font-family: "Material Icons"; - content: "arrow_upward"; - -webkit-font-feature-settings: "liga"; - position: absolute; - -webkit-transform: translate(-50%, 0); - transform: translate(-50%, 0); - left: 50%; - bottom: 3rem; - color: var(--snowColor); - opacity: 0; - -webkit-transition: all 0.2s ease-in-out; - transition: all 0.2s ease-in-out; - } - - .homeNavItem:hover { - box-shadow: 0 1rem 3rem rgba(0, 0, 0, 0.04); - transform: translateY(-1rem); - } - - .homeNavItem:hover::after { - opacity: 1; - } - - .homeNavItem h2 { - font-size: 3.5rem; - font-weight: 400; - line-height: 1.2; - } -} - -@media (min-width: 1200px) { - .homeNavItem h2 { - font-size: 4.5rem; - font-weight: 400; - line-height: 1.2; - } -} - -/* - Home Footer - ========================================================================== */ - -.homeFooterContainer { - padding: 6rem 0; - background-image: linear-gradient(217deg, rgba(196, 0, 97, 0.8), rgba(196, 0, 97, 0) 70%), - linear-gradient(127deg, rgba(230, 0, 122, 0.8), rgba(230, 0, 122, 0) 70%), - linear-gradient(336deg, rgba(103, 69, 210, 0.7), rgba(103, 69, 210, 0) 70%); - background-color: #e6007a; -} - -/* ========================================================================== - Mainpage - ========================================================================== */ - -.mainpage-row { - width: 100%; - display: flex; - padding: 10%; - padding-top: 0; - padding-bottom: 0; - flex-flow: row wrap; - justify-content: center; -} - -.mainpage-column { - width: 50%; - display: flex; - align-items: center; - padding: 5%; - text-align: center; - flex-flow: column; -} - -.mainpage-maintain-btn { - background: black; - border: none; - color: white; - font-weight: 500; - padding: 10px; - font-size: 14px; - margin-top: 12px; -} - -.mainpage-maintain-btn:hover { - background: #e6007a; - cursor: pointer; -} - -.mainpage-build-btn { - background: #e6007a; - border: none; - color: white; - font-weight: 500; - padding: 10px; - font-size: 14px; - margin-top: 24px; - margin-bottom: 12px; -} - -.mainpage-build-btn:hover { - background: black; - cursor: pointer; -} - -.mainpage-row-build { - width: 100%; - display: flex; - padding: 0%; - padding-top: 0; - padding-bottom: 0; - flex-flow: row wrap; - justify-content: center; - background-image: linear-gradient(#aaa, #777); - color: white; -} - -.mainpage-row-learn { - width: 100%; - display: flex; - padding: 0%; - padding-top: 0; - padding-bottom: 0; - flex-flow: row wrap; - justify-content: center; - background-image: linear-gradient(#fff, #aaa); - color: black; -} - -.full-width { - width: 100%; - text-align: center; -} - -/* ========================================================================== - Components - ========================================================================== */ - -.myButton { - padding: 10px; - padding-left: 12px; - padding-right: 12px; - background: black; - color: white; - border: none; - font-size: 16px; -} - -.myButton:hover { - background: #e6007a; - cursor: pointer; -} - -.projectTitle { - color: black; -} - -.nav-footer .row { - display: flex; - justify-content: center; -} - -.nav-footer .row .item { - padding-left: 16px; - color: rgba(255, 255, 255, 0.4); -} - -.nav-footer .row .item:hover { - color: #ffffff; -} - -/* - Button - ========================================================================== */ - -.btn { - font-weight: 700; - border-radius: 1.5rem; - font-size: 16px; - padding: 8px 16px; -} -.btn:before { - width: 42px; - left: -42px; - border-radius: 1.5rem; -} -.btn-lg, -.btn-group-lg > .btn { - border-radius: 2rem; - padding: 16px 20px; -} -.btn-lg:before, -.btn-group-lg > .btn:before { - width: 58px; - left: -58px; - border-radius: 2rem; -} -.btn-sm, -.btn-group-sm > .btn { - border-radius: 1.5rem; - font-size: 16px; - padding: 8px 16px; -} -.btn-sm:before, -.btn-group-sm > .btn:before { - width: 42px; - left: -42px; - border-radius: 1.5rem; -} -.btn-primary { - color: var(--primaryColor); - background-color: transparent; - border-color: var(--primaryColor); - position: relative; - z-index: 1; - overflow: hidden; - border: solid 1px var(--primaryColor); - transition: all 0.2s ease, border 1ms ease; - will-change: transform; - transform: scale(0.999); -} -.btn-primary:before { - content: ""; - height: 100%; - position: absolute; - top: 0; - background: var(--primaryColor); - transition: all 0.2s ease; - will-change: transform; - color: transparent; - z-index: -1; - border: solid 1px var(--primaryColor); -} -.btn-primary:hover, -.btn-primary:focus, -.btn-primary:active { - background: none; - color: white; - will-change: transform; - transform: scale(1.05); - border: solid 1px transparent; -} -.btn-primary:focus, -.btn-primary.focus { - box-shadow: 0 0 0.2rem 0.2rem rgba(0, 0, 0, 0.1); -} -.btn-primary:not(:disabled):not(.disabled):active { - background-color: transparent; -} -.btn-primary[type="submit"]:hover, -.btn-primary[type="submit"]:focus, -.btn-primary[type="submit"]:active { - background: var(--primaryColor); -} -.btn-primary:hover:before, -.btn-primary:focus:before, -.btn-primary:active:before { - left: 0; - width: 100%; -} -.btn-bg-primary.btn-primary { - color: white !important; - border-color: white; - border: solid 1px white; -} -.btn-bg-primary.btn-primary:hover, -.btn-bg-primary.btn-primary:focus, -.btn-bg-primary.btn-primary:active { - background: white; - color: var(--primaryColor) !important; -} -.btn-bg-primary.btn-primary:before { - content: none; - height: 100%; - position: absolute; - top: 0; - background: white; - transition: all 0.2s ease; - will-change: transform; - color: transparent; - z-index: -1; - border: solid 1px white; -} -.btn-white { - color: white !important; -} - -/* ========================================================================== - Footer - ========================================================================== */ - -.nav-footer { - background: var(--secondaryColor); - border: none; - color: #202020; - font-size: 16px; - line-height: 24px; - position: relative; -} - -/* - Bootstrap fix - ========================================================================== */ - -.nav-footer.spacer-y-4 { - padding-top: 3rem; - padding-bottom: 3rem; -} - -.nav-footer.pb-4 { - padding-bottom: 2.25rem !important; -} - -.nav-footer .text-small { - font-size: 0.875rem; -} - -@media (min-width: 768px) { - .nav-footer.spacer-y-4 { - padding-top: 6rem; - padding-bottom: 6rem; - } - - .nav-footer .py-md-1 { - padding-bottom: 0.375rem !important; - padding-top: 0.375rem !important; - } -} - -/* - Footer Nav - ========================================================================== */ - -.nav-footer h5 { - font-size: 1.25rem; - font-weight: 400; - letter-spacing: -0.04em; - margin-top: 0; -} - -.nav-footer a.text-white { - color: #b7b8bb !important; -} - -.nav-footer a.text-white:visited { - color: #b7b8bb !important; -} - -.nav-footer a.text-white:hover { - color: white !important; -} - -/* - Footer Social - ========================================================================== */ - -.list-social-links { - padding: 0; - list-style: none; - display: flex; -} - -footer .list-social-links i { - font-size: 1.2rem; -} - -footer .list-social-links a { - padding: 0.25rem 0.9rem; -} - -footer [class^="socicon-"] { - line-height: 2; -} - -footer .list-social-links { - margin-left: 0rem; -} -footer .list-social-links li { - margin-top: 0 !important; -} - -footer .list-social-links a { - background: transparent !important; - border: 1px solid white; - color: white; - padding: 0.25rem 0.9rem; - display: block; - border-radius: 50%; -} - -/* - Footer Legal - ========================================================================== */ - -.footer-legal .navbar-brand { - display: block; - padding-bottom: 0; -} - -.footer-legal ul { - margin-bottom: 0; -} - -.footer-legal li + li { - margin-top: 0; -} - -.footer-legal .list-pipe-separator > li:not(:last-child) > a:after { - content: "|"; - margin: 0 0.375rem; - opacity: 0.5; -} - -.footer-legal .text-white { - color: #b5aeae !important; -} - -.footer-legal .text-white:visited { - color: #b5aeae !important; -} - -.footer-legal .text-white:hover { - color: #fff !important; -} - -/* ========================================================================== - Animations - ========================================================================== */ - -@-webkit-keyframes fade-in-up { - 0% { - opacity: 0; - transform: translateY(1.5rem); - } - 50% { - opacity: 1; - } - 100% { - opacity: 1; - transform: translateY(0); - } -} - -@keyframes fade-in-up { - 0% { - opacity: 0; - transform: translateY(1.5rem); - } - 50% { - opacity: 1; - } - 100% { - opacity: 1; - transform: translateY(0); - } -} - -.address-changer { - width: 100%; - padding: 10px; - border: 2px solid black; -} - -.address-changer-input { - width: 74%; -} - -.address-changer-select { - height: 30px; - width: 25%; - margin-left: auto; - margin-right: auto; -} - -.address-changer-output { - height: 30px; - display: flex; - padding: 10px; - justify-content: center; - align-items: center; -} diff --git a/website/static/css/socicon.css b/website/static/css/socicon.css deleted file mode 100644 index 6337136d15a6..000000000000 --- a/website/static/css/socicon.css +++ /dev/null @@ -1,1058 +0,0 @@ -@font-face { - font-family: "Socicon"; - src: url("../fonts/Socicon.eot?484r1f"); - src: url("../fonts/Socicon.eot?484r1f#iefix") format("embedded-opentype"), - url("../fonts/Socicon.woff2?484r1f") format("woff2"), - url("../fonts/Socicon.ttf?484r1f") format("truetype"), - url("../fonts/Socicon.woff?484r1f") format("woff"), - url("../fonts/Socicon.svg?484r1f#Socicon") format("svg"); - font-weight: normal; - font-style: normal; -} - -[class^="socicon-"], -[class*=" socicon-"] { - /* use !important to prevent issues with browser extensions that change fonts */ - font-family: "Socicon" !important; - speak: none; - font-style: normal; - font-weight: normal; - font-variant: normal; - text-transform: none; - line-height: 1; - /* Better Font Rendering =========== */ - -webkit-font-smoothing: antialiased; - -moz-osx-font-smoothing: grayscale; -} - -.socicon-internet:before { - content: "\e957"; -} - -.socicon-moddb:before { - content: "\e94b"; -} - -.socicon-indiedb:before { - content: "\e94c"; -} - -.socicon-traxsource:before { - content: "\e94d"; -} - -.socicon-gamefor:before { - content: "\e94e"; -} - -.socicon-pixiv:before { - content: "\e94f"; -} - -.socicon-myanimelist:before { - content: "\e950"; -} - -.socicon-blackberry:before { - content: "\e951"; -} - -.socicon-wickr:before { - content: "\e952"; -} - -.socicon-spip:before { - content: "\e953"; -} - -.socicon-napster:before { - content: "\e954"; -} - -.socicon-beatport:before { - content: "\e955"; -} - -.socicon-hackerone:before { - content: "\e956"; -} - -.socicon-hackernews:before { - content: "\e946"; -} - -.socicon-smashwords:before { - content: "\e947"; -} - -.socicon-kobo:before { - content: "\e948"; -} - -.socicon-bookbub:before { - content: "\e949"; -} - -.socicon-mailru:before { - content: "\e94a"; -} - -.socicon-gitlab:before { - content: "\e945"; -} - -.socicon-instructables:before { - content: "\e944"; -} - -.socicon-portfolio:before { - content: "\e943"; -} - -.socicon-codered:before { - content: "\e940"; -} - -.socicon-origin:before { - content: "\e941"; -} - -.socicon-nextdoor:before { - content: "\e942"; -} - -.socicon-udemy:before { - content: "\e93f"; -} - -.socicon-livemaster:before { - content: "\e93e"; -} - -.socicon-crunchbase:before { - content: "\e93b"; -} - -.socicon-homefy:before { - content: "\e93c"; -} - -.socicon-calendly:before { - content: "\e93d"; -} - -.socicon-realtor:before { - content: "\e90f"; -} - -.socicon-tidal:before { - content: "\e910"; -} - -.socicon-qobuz:before { - content: "\e911"; -} - -.socicon-natgeo:before { - content: "\e912"; -} - -.socicon-mastodon:before { - content: "\e913"; -} - -.socicon-unsplash:before { - content: "\e914"; -} - -.socicon-homeadvisor:before { - content: "\e915"; -} - -.socicon-angieslist:before { - content: "\e916"; -} - -.socicon-codepen:before { - content: "\e917"; -} - -.socicon-slack:before { - content: "\e918"; -} - -.socicon-openaigym:before { - content: "\e919"; -} - -.socicon-logmein:before { - content: "\e91a"; -} - -.socicon-fiverr:before { - content: "\e91b"; -} - -.socicon-gotomeeting:before { - content: "\e91c"; -} - -.socicon-aliexpress:before { - content: "\e91d"; -} - -.socicon-guru:before { - content: "\e91e"; -} - -.socicon-appstore:before { - content: "\e91f"; -} - -.socicon-homes:before { - content: "\e920"; -} - -.socicon-zoom:before { - content: "\e921"; -} - -.socicon-alibaba:before { - content: "\e922"; -} - -.socicon-craigslist:before { - content: "\e923"; -} - -.socicon-wix:before { - content: "\e924"; -} - -.socicon-redfin:before { - content: "\e925"; -} - -.socicon-googlecalendar:before { - content: "\e926"; -} - -.socicon-shopify:before { - content: "\e927"; -} - -.socicon-freelancer:before { - content: "\e928"; -} - -.socicon-seedrs:before { - content: "\e929"; -} - -.socicon-bing:before { - content: "\e92a"; -} - -.socicon-doodle:before { - content: "\e92b"; -} - -.socicon-bonanza:before { - content: "\e92c"; -} - -.socicon-squarespace:before { - content: "\e92d"; -} - -.socicon-toptal:before { - content: "\e92e"; -} - -.socicon-gust:before { - content: "\e92f"; -} - -.socicon-ask:before { - content: "\e930"; -} - -.socicon-trulia:before { - content: "\e931"; -} - -.socicon-loomly:before { - content: "\e932"; -} - -.socicon-ghost:before { - content: "\e933"; -} - -.socicon-upwork:before { - content: "\e934"; -} - -.socicon-fundable:before { - content: "\e935"; -} - -.socicon-booking:before { - content: "\e936"; -} - -.socicon-googlemaps:before { - content: "\e937"; -} - -.socicon-zillow:before { - content: "\e938"; -} - -.socicon-niconico:before { - content: "\e939"; -} - -.socicon-toneden:before { - content: "\e93a"; -} - -.socicon-augment:before { - content: "\e908"; -} - -.socicon-bitbucket:before { - content: "\e909"; -} - -.socicon-fyuse:before { - content: "\e90a"; -} - -.socicon-yt-gaming:before { - content: "\e90b"; -} - -.socicon-sketchfab:before { - content: "\e90c"; -} - -.socicon-mobcrush:before { - content: "\e90d"; -} - -.socicon-microsoft:before { - content: "\e90e"; -} - -.socicon-pandora:before { - content: "\e907"; -} - -.socicon-messenger:before { - content: "\e906"; -} - -.socicon-gamewisp:before { - content: "\e905"; -} - -.socicon-bloglovin:before { - content: "\e904"; -} - -.socicon-tunein:before { - content: "\e903"; -} - -.socicon-gamejolt:before { - content: "\e901"; -} - -.socicon-trello:before { - content: "\e902"; -} - -.socicon-spreadshirt:before { - content: "\e900"; -} - -.socicon-500px:before { - content: "\e000"; -} - -.socicon-8tracks:before { - content: "\e001"; -} - -.socicon-airbnb:before { - content: "\e002"; -} - -.socicon-alliance:before { - content: "\e003"; -} - -.socicon-amazon:before { - content: "\e004"; -} - -.socicon-amplement:before { - content: "\e005"; -} - -.socicon-android:before { - content: "\e006"; -} - -.socicon-angellist:before { - content: "\e007"; -} - -.socicon-apple:before { - content: "\e008"; -} - -.socicon-appnet:before { - content: "\e009"; -} - -.socicon-baidu:before { - content: "\e00a"; -} - -.socicon-bandcamp:before { - content: "\e00b"; -} - -.socicon-battlenet:before { - content: "\e00c"; -} - -.socicon-mixer:before { - content: "\e00d"; -} - -.socicon-bebee:before { - content: "\e00e"; -} - -.socicon-bebo:before { - content: "\e00f"; -} - -.socicon-behance:before { - content: "\e010"; -} - -.socicon-blizzard:before { - content: "\e011"; -} - -.socicon-blogger:before { - content: "\e012"; -} - -.socicon-buffer:before { - content: "\e013"; -} - -.socicon-chrome:before { - content: "\e014"; -} - -.socicon-coderwall:before { - content: "\e015"; -} - -.socicon-curse:before { - content: "\e016"; -} - -.socicon-dailymotion:before { - content: "\e017"; -} - -.socicon-deezer:before { - content: "\e018"; -} - -.socicon-delicious:before { - content: "\e019"; -} - -.socicon-deviantart:before { - content: "\e01a"; -} - -.socicon-diablo:before { - content: "\e01b"; -} - -.socicon-digg:before { - content: "\e01c"; -} - -.socicon-discord:before { - content: "\e01d"; -} - -.socicon-disqus:before { - content: "\e01e"; -} - -.socicon-douban:before { - content: "\e01f"; -} - -.socicon-draugiem:before { - content: "\e020"; -} - -.socicon-dribbble:before { - content: "\e021"; -} - -.socicon-drupal:before { - content: "\e022"; -} - -.socicon-ebay:before { - content: "\e023"; -} - -.socicon-ello:before { - content: "\e024"; -} - -.socicon-endomodo:before { - content: "\e025"; -} - -.socicon-envato:before { - content: "\e026"; -} - -.socicon-etsy:before { - content: "\e027"; -} - -.socicon-facebook:before { - content: "\e028"; -} - -.socicon-feedburner:before { - content: "\e029"; -} - -.socicon-filmweb:before { - content: "\e02a"; -} - -.socicon-firefox:before { - content: "\e02b"; -} - -.socicon-flattr:before { - content: "\e02c"; -} - -.socicon-flickr:before { - content: "\e02d"; -} - -.socicon-formulr:before { - content: "\e02e"; -} - -.socicon-forrst:before { - content: "\e02f"; -} - -.socicon-foursquare:before { - content: "\e030"; -} - -.socicon-friendfeed:before { - content: "\e031"; -} - -.socicon-github:before { - content: "\e032"; -} - -.socicon-goodreads:before { - content: "\e033"; -} - -.socicon-google:before { - content: "\e034"; -} - -.socicon-googlescholar:before { - content: "\e035"; -} - -.socicon-googlegroups:before { - content: "\e036"; -} - -.socicon-googlephotos:before { - content: "\e037"; -} - -.socicon-googleplus:before { - content: "\e038"; -} - -.socicon-grooveshark:before { - content: "\e039"; -} - -.socicon-hackerrank:before { - content: "\e03a"; -} - -.socicon-hearthstone:before { - content: "\e03b"; -} - -.socicon-hellocoton:before { - content: "\e03c"; -} - -.socicon-heroes:before { - content: "\e03d"; -} - -.socicon-smashcast:before { - content: "\e03e"; -} - -.socicon-horde:before { - content: "\e03f"; -} - -.socicon-houzz:before { - content: "\e040"; -} - -.socicon-icq:before { - content: "\e041"; -} - -.socicon-identica:before { - content: "\e042"; -} - -.socicon-imdb:before { - content: "\e043"; -} - -.socicon-instagram:before { - content: "\e044"; -} - -.socicon-issuu:before { - content: "\e045"; -} - -.socicon-istock:before { - content: "\e046"; -} - -.socicon-itunes:before { - content: "\e047"; -} - -.socicon-keybase:before { - content: "\e048"; -} - -.socicon-lanyrd:before { - content: "\e049"; -} - -.socicon-lastfm:before { - content: "\e04a"; -} - -.socicon-line:before { - content: "\e04b"; -} - -.socicon-linkedin:before { - content: "\e04c"; -} - -.socicon-livejournal:before { - content: "\e04d"; -} - -.socicon-lyft:before { - content: "\e04e"; -} - -.socicon-macos:before { - content: "\e04f"; -} - -.socicon-mail:before { - content: "\e050"; -} - -.socicon-medium:before { - content: "\e051"; -} - -.socicon-meetup:before { - content: "\e052"; -} - -.socicon-mixcloud:before { - content: "\e053"; -} - -.socicon-modelmayhem:before { - content: "\e054"; -} - -.socicon-mumble:before { - content: "\e055"; -} - -.socicon-myspace:before { - content: "\e056"; -} - -.socicon-newsvine:before { - content: "\e057"; -} - -.socicon-nintendo:before { - content: "\e058"; -} - -.socicon-npm:before { - content: "\e059"; -} - -.socicon-odnoklassniki:before { - content: "\e05a"; -} - -.socicon-openid:before { - content: "\e05b"; -} - -.socicon-opera:before { - content: "\e05c"; -} - -.socicon-outlook:before { - content: "\e05d"; -} - -.socicon-overwatch:before { - content: "\e05e"; -} - -.socicon-patreon:before { - content: "\e05f"; -} - -.socicon-paypal:before { - content: "\e060"; -} - -.socicon-periscope:before { - content: "\e061"; -} - -.socicon-persona:before { - content: "\e062"; -} - -.socicon-pinterest:before { - content: "\e063"; -} - -.socicon-play:before { - content: "\e064"; -} - -.socicon-player:before { - content: "\e065"; -} - -.socicon-playstation:before { - content: "\e066"; -} - -.socicon-pocket:before { - content: "\e067"; -} - -.socicon-qq:before { - content: "\e068"; -} - -.socicon-quora:before { - content: "\e069"; -} - -.socicon-raidcall:before { - content: "\e06a"; -} - -.socicon-ravelry:before { - content: "\e06b"; -} - -.socicon-reddit:before { - content: "\e06c"; -} - -.socicon-renren:before { - content: "\e06d"; -} - -.socicon-researchgate:before { - content: "\e06e"; -} - -.socicon-residentadvisor:before { - content: "\e06f"; -} - -.socicon-reverbnation:before { - content: "\e070"; -} - -.socicon-rss:before { - content: "\e071"; -} - -.socicon-sharethis:before { - content: "\e072"; -} - -.socicon-skype:before { - content: "\e073"; -} - -.socicon-slideshare:before { - content: "\e074"; -} - -.socicon-smugmug:before { - content: "\e075"; -} - -.socicon-snapchat:before { - content: "\e076"; -} - -.socicon-songkick:before { - content: "\e077"; -} - -.socicon-soundcloud:before { - content: "\e078"; -} - -.socicon-spotify:before { - content: "\e079"; -} - -.socicon-stackexchange:before { - content: "\e07a"; -} - -.socicon-stackoverflow:before { - content: "\e07b"; -} - -.socicon-starcraft:before { - content: "\e07c"; -} - -.socicon-stayfriends:before { - content: "\e07d"; -} - -.socicon-steam:before { - content: "\e07e"; -} - -.socicon-storehouse:before { - content: "\e07f"; -} - -.socicon-strava:before { - content: "\e080"; -} - -.socicon-streamjar:before { - content: "\e081"; -} - -.socicon-stumbleupon:before { - content: "\e082"; -} - -.socicon-swarm:before { - content: "\e083"; -} - -.socicon-teamspeak:before { - content: "\e084"; -} - -.socicon-teamviewer:before { - content: "\e085"; -} - -.socicon-technorati:before { - content: "\e086"; -} - -.socicon-telegram:before { - content: "\e087"; -} - -.socicon-tripadvisor:before { - content: "\e088"; -} - -.socicon-tripit:before { - content: "\e089"; -} - -.socicon-triplej:before { - content: "\e08a"; -} - -.socicon-tumblr:before { - content: "\e08b"; -} - -.socicon-twitch:before { - content: "\e08c"; -} - -.socicon-twitter:before { - content: "\e08d"; -} - -.socicon-uber:before { - content: "\e08e"; -} - -.socicon-ventrilo:before { - content: "\e08f"; -} - -.socicon-viadeo:before { - content: "\e090"; -} - -.socicon-viber:before { - content: "\e091"; -} - -.socicon-viewbug:before { - content: "\e092"; -} - -.socicon-vimeo:before { - content: "\e093"; -} - -.socicon-vine:before { - content: "\e094"; -} - -.socicon-vkontakte:before { - content: "\e095"; -} - -.socicon-warcraft:before { - content: "\e096"; -} - -.socicon-wechat:before { - content: "\e097"; -} - -.socicon-weibo:before { - content: "\e098"; -} - -.socicon-whatsapp:before { - content: "\e099"; -} - -.socicon-wikipedia:before { - content: "\e09a"; -} - -.socicon-windows:before { - content: "\e09b"; -} - -.socicon-wordpress:before { - content: "\e09c"; -} - -.socicon-wykop:before { - content: "\e09d"; -} - -.socicon-xbox:before { - content: "\e09e"; -} - -.socicon-xing:before { - content: "\e09f"; -} - -.socicon-yahoo:before { - content: "\e0a0"; -} - -.socicon-yammer:before { - content: "\e0a1"; -} - -.socicon-yandex:before { - content: "\e0a2"; -} - -.socicon-yelp:before { - content: "\e0a3"; -} - -.socicon-younow:before { - content: "\e0a4"; -} - -.socicon-youtube:before { - content: "\e0a5"; -} - -.socicon-zapier:before { - content: "\e0a6"; -} - -.socicon-zerply:before { - content: "\e0a7"; -} - -.socicon-zomato:before { - content: "\e0a8"; -} - -.socicon-zynga:before { - content: "\e0a9"; -} diff --git a/website/static/fonts/Socicon.eot b/website/static/fonts/Socicon.eot deleted file mode 100755 index 0495a9e8a9d2..000000000000 Binary files a/website/static/fonts/Socicon.eot and /dev/null differ diff --git a/website/static/fonts/Socicon.svg b/website/static/fonts/Socicon.svg deleted file mode 100755 index 48ec794c1ceb..000000000000 --- a/website/static/fonts/Socicon.svg +++ /dev/null @@ -1,268 +0,0 @@ - - - -Generated by IcoMoon - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/website/static/fonts/Socicon.ttf b/website/static/fonts/Socicon.ttf deleted file mode 100755 index 6e4c8f47a2b7..000000000000 Binary files a/website/static/fonts/Socicon.ttf and /dev/null differ diff --git a/website/static/fonts/Socicon.woff b/website/static/fonts/Socicon.woff deleted file mode 100755 index 1744c1a0fbd2..000000000000 Binary files a/website/static/fonts/Socicon.woff and /dev/null differ diff --git a/website/static/fonts/Socicon.woff2 b/website/static/fonts/Socicon.woff2 deleted file mode 100755 index 3c65571ce550..000000000000 Binary files a/website/static/fonts/Socicon.woff2 and /dev/null differ diff --git a/website/static/img/GRANDPA/chain-selection.png b/website/static/img/GRANDPA/chain-selection.png deleted file mode 100644 index 84f61a894873..000000000000 Binary files a/website/static/img/GRANDPA/chain-selection.png and /dev/null differ diff --git a/website/static/img/NPoS/article-1.png b/website/static/img/NPoS/article-1.png deleted file mode 100644 index bfb16b86bd91..000000000000 Binary files a/website/static/img/NPoS/article-1.png and /dev/null differ diff --git a/website/static/img/NPoS/article-2.png b/website/static/img/NPoS/article-2.png deleted file mode 100644 index 57290d4e12bc..000000000000 Binary files a/website/static/img/NPoS/article-2.png and /dev/null differ diff --git a/website/static/img/NPoS/article-3.png b/website/static/img/NPoS/article-3.png deleted file mode 100644 index 4a179111097c..000000000000 Binary files a/website/static/img/NPoS/article-3.png and /dev/null differ diff --git a/website/static/img/NPoS/article-4.png b/website/static/img/NPoS/article-4.png deleted file mode 100644 index 7440bf63c4c8..000000000000 Binary files a/website/static/img/NPoS/article-4.png and /dev/null differ diff --git a/website/static/img/NPoS/article-5.png b/website/static/img/NPoS/article-5.png deleted file mode 100644 index 2d5a995c0392..000000000000 Binary files a/website/static/img/NPoS/article-5.png and /dev/null differ diff --git a/website/static/img/NPoS/nominate.png b/website/static/img/NPoS/nominate.png deleted file mode 100644 index 78f069ef3384..000000000000 Binary files a/website/static/img/NPoS/nominate.png and /dev/null differ diff --git a/website/static/img/NPoS/nominate2.png b/website/static/img/NPoS/nominate2.png deleted file mode 100644 index 8d7ff0e7aa79..000000000000 Binary files a/website/static/img/NPoS/nominate2.png and /dev/null differ diff --git a/website/static/img/NPoS/staking-keys.png b/website/static/img/NPoS/staking-keys.png deleted file mode 100644 index d0085a4dc89c..000000000000 Binary files a/website/static/img/NPoS/staking-keys.png and /dev/null differ diff --git a/website/static/img/NPoS/staking-participation-rate.png b/website/static/img/NPoS/staking-participation-rate.png deleted file mode 100644 index 0d7cd1e98f8d..000000000000 Binary files a/website/static/img/NPoS/staking-participation-rate.png and /dev/null differ diff --git a/website/static/img/NPoS/unbond1.png b/website/static/img/NPoS/unbond1.png deleted file mode 100644 index 2dd3e0cce574..000000000000 Binary files a/website/static/img/NPoS/unbond1.png and /dev/null differ diff --git a/website/static/img/NPoS/unbond2.png b/website/static/img/NPoS/unbond2.png deleted file mode 100644 index 6b9591170af1..000000000000 Binary files a/website/static/img/NPoS/unbond2.png and /dev/null differ diff --git a/website/static/img/NPoS/unbond3.png b/website/static/img/NPoS/unbond3.png deleted file mode 100644 index 84a30f91371e..000000000000 Binary files a/website/static/img/NPoS/unbond3.png and /dev/null differ diff --git a/website/static/img/NPoS/unbond4.png b/website/static/img/NPoS/unbond4.png deleted file mode 100644 index 22294f0aa75b..000000000000 Binary files a/website/static/img/NPoS/unbond4.png and /dev/null differ diff --git a/website/static/img/NPoS/unbond5.png b/website/static/img/NPoS/unbond5.png deleted file mode 100644 index 9eb80c16d029..000000000000 Binary files a/website/static/img/NPoS/unbond5.png and /dev/null differ diff --git a/website/static/img/PRE.png b/website/static/img/PRE.png deleted file mode 100644 index 85968c24db35..000000000000 Binary files a/website/static/img/PRE.png and /dev/null differ diff --git a/website/static/img/Polkadot_Logotype_color.png b/website/static/img/Polkadot_Logotype_color.png deleted file mode 100644 index f9bcc3505c6c..000000000000 Binary files a/website/static/img/Polkadot_Logotype_color.png and /dev/null differ diff --git a/website/static/img/Polkadot_Logotype_white.png b/website/static/img/Polkadot_Logotype_white.png deleted file mode 100644 index 82516058d395..000000000000 Binary files a/website/static/img/Polkadot_Logotype_white.png and /dev/null differ diff --git a/website/static/img/Polkadot_logotype_color.svg b/website/static/img/Polkadot_logotype_color.svg deleted file mode 100644 index aaac889947a2..000000000000 --- a/website/static/img/Polkadot_logotype_color.svg +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - - - - - - diff --git a/website/static/img/Polkadot_symbol_color.png b/website/static/img/Polkadot_symbol_color.png deleted file mode 100644 index 5e36153e4df3..000000000000 Binary files a/website/static/img/Polkadot_symbol_color.png and /dev/null differ diff --git a/website/static/img/Polkadot_symbol_white.svg b/website/static/img/Polkadot_symbol_white.svg deleted file mode 100644 index e283b20ee5c9..000000000000 --- a/website/static/img/Polkadot_symbol_white.svg +++ /dev/null @@ -1,18 +0,0 @@ - - - - - - - - - - diff --git a/website/static/img/accounts/create-multisig.png b/website/static/img/accounts/create-multisig.png deleted file mode 100644 index 4901c2b508ba..000000000000 Binary files a/website/static/img/accounts/create-multisig.png and /dev/null differ diff --git a/website/static/img/accounts/send-from-multi.png b/website/static/img/accounts/send-from-multi.png deleted file mode 100644 index 8d4e863e5970..000000000000 Binary files a/website/static/img/accounts/send-from-multi.png and /dev/null differ diff --git a/website/static/img/accounts/sign-from-multi-1.png b/website/static/img/accounts/sign-from-multi-1.png deleted file mode 100644 index fba15c56b496..000000000000 Binary files a/website/static/img/accounts/sign-from-multi-1.png and /dev/null differ diff --git a/website/static/img/build-1.png b/website/static/img/build-1.png deleted file mode 100644 index 88e59b871480..000000000000 Binary files a/website/static/img/build-1.png and /dev/null differ diff --git a/website/static/img/build-2.png b/website/static/img/build-2.png deleted file mode 100644 index baa316c17720..000000000000 Binary files a/website/static/img/build-2.png and /dev/null differ diff --git a/website/static/img/claim/polkadotui-find-the-accounts-page.jpg b/website/static/img/claim/polkadotui-find-the-accounts-page.jpg deleted file mode 100644 index 86ffb293e738..000000000000 Binary files a/website/static/img/claim/polkadotui-find-the-accounts-page.jpg and /dev/null differ diff --git a/website/static/img/claim/polkadotui_claim_copy_address.jpg b/website/static/img/claim/polkadotui_claim_copy_address.jpg deleted file mode 100644 index 8e5aba6c25ce..000000000000 Binary files a/website/static/img/claim/polkadotui_claim_copy_address.jpg and /dev/null differ diff --git a/website/static/img/claim/polkadotui_claim_create_account.jpg b/website/static/img/claim/polkadotui_claim_create_account.jpg deleted file mode 100644 index ef24eed2bc54..000000000000 Binary files a/website/static/img/claim/polkadotui_claim_create_account.jpg and /dev/null differ diff --git a/website/static/img/endpoints/parity.png b/website/static/img/endpoints/parity.png deleted file mode 100644 index b1a01817347d..000000000000 Binary files a/website/static/img/endpoints/parity.png and /dev/null differ diff --git a/website/static/img/endpoints/ryo.png b/website/static/img/endpoints/ryo.png deleted file mode 100644 index 7e32b9e3bf7c..000000000000 Binary files a/website/static/img/endpoints/ryo.png and /dev/null differ diff --git a/website/static/img/endpoints/w3f.png b/website/static/img/endpoints/w3f.png deleted file mode 100644 index 00ffebc5bb04..000000000000 Binary files a/website/static/img/endpoints/w3f.png and /dev/null differ diff --git a/website/static/img/errors/01.jpg b/website/static/img/errors/01.jpg deleted file mode 100644 index 54993f533645..000000000000 Binary files a/website/static/img/errors/01.jpg and /dev/null differ diff --git a/website/static/img/errors/02.jpg b/website/static/img/errors/02.jpg deleted file mode 100644 index 23070458ad47..000000000000 Binary files a/website/static/img/errors/02.jpg and /dev/null differ diff --git a/website/static/img/favicon.ico b/website/static/img/favicon.ico deleted file mode 100644 index 539c922aaae1..000000000000 Binary files a/website/static/img/favicon.ico and /dev/null differ diff --git a/website/static/img/governance/AQB-electorate.png b/website/static/img/governance/AQB-electorate.png deleted file mode 100644 index d46a4e873a2b..000000000000 Binary files a/website/static/img/governance/AQB-electorate.png and /dev/null differ diff --git a/website/static/img/governance/AQB.png b/website/static/img/governance/AQB.png deleted file mode 100644 index 4b97d7a5af5a..000000000000 Binary files a/website/static/img/governance/AQB.png and /dev/null differ diff --git a/website/static/img/governance/Governance-diagram.png b/website/static/img/governance/Governance-diagram.png deleted file mode 100644 index 0af3d47c90db..000000000000 Binary files a/website/static/img/governance/Governance-diagram.png and /dev/null differ diff --git a/website/static/img/governance/adaptive-quorum-biasing.png b/website/static/img/governance/adaptive-quorum-biasing.png deleted file mode 100644 index 1eb06d447101..000000000000 Binary files a/website/static/img/governance/adaptive-quorum-biasing.png and /dev/null differ diff --git a/website/static/img/governance/approval-vote.png b/website/static/img/governance/approval-vote.png deleted file mode 100644 index 0688e1e40e24..000000000000 Binary files a/website/static/img/governance/approval-vote.png and /dev/null differ diff --git a/website/static/img/guides/how-to-nominate/nominating.jpg b/website/static/img/guides/how-to-nominate/nominating.jpg deleted file mode 100644 index 60cd2e110ba9..000000000000 Binary files a/website/static/img/guides/how-to-nominate/nominating.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-nominate/nominating2.jpg b/website/static/img/guides/how-to-nominate/nominating2.jpg deleted file mode 100644 index 79654c6e29a4..000000000000 Binary files a/website/static/img/guides/how-to-nominate/nominating2.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-nominate/polkadot-dashboard-bonding.jpg b/website/static/img/guides/how-to-nominate/polkadot-dashboard-bonding.jpg deleted file mode 100644 index 71864676a117..000000000000 Binary files a/website/static/img/guides/how-to-nominate/polkadot-dashboard-bonding.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-nominate/polkadot-dashboard-create-account.jpg b/website/static/img/guides/how-to-nominate/polkadot-dashboard-create-account.jpg deleted file mode 100644 index 7df13f786e53..000000000000 Binary files a/website/static/img/guides/how-to-nominate/polkadot-dashboard-create-account.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg b/website/static/img/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg deleted file mode 100644 index 224f9138458d..000000000000 Binary files a/website/static/img/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-nominate/validators.png b/website/static/img/guides/how-to-nominate/validators.png deleted file mode 100644 index 97ab8e488eb2..000000000000 Binary files a/website/static/img/guides/how-to-nominate/validators.png and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-dashboard-bonding.jpg b/website/static/img/guides/how-to-validate/polkadot-dashboard-bonding.jpg deleted file mode 100644 index 71864676a117..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-dashboard-bonding.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-dashboard-create-account.jpg b/website/static/img/guides/how-to-validate/polkadot-dashboard-create-account.jpg deleted file mode 100644 index 7df13f786e53..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-dashboard-create-account.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key-modal.jpg b/website/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key-modal.jpg deleted file mode 100644 index eb49f806f0f3..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key-modal.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key.jpg b/website/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key.jpg deleted file mode 100644 index 224f9138458d..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-dashboard-set-session-key.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-dashboard-staking-queue.jpg b/website/static/img/guides/how-to-validate/polkadot-dashboard-staking-queue.jpg deleted file mode 100644 index d720273702ff..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-dashboard-staking-queue.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg b/website/static/img/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg deleted file mode 100644 index d0636b6a9878..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-dashboard-validate.jpg b/website/static/img/guides/how-to-validate/polkadot-dashboard-validate.jpg deleted file mode 100644 index 7526a095e5f8..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-dashboard-validate.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-node-seed.jpg b/website/static/img/guides/how-to-validate/polkadot-node-seed.jpg deleted file mode 100644 index 63c56d72ba1d..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-node-seed.jpg and /dev/null differ diff --git a/website/static/img/guides/how-to-validate/polkadot-overview.jpg b/website/static/img/guides/how-to-validate/polkadot-overview.jpg deleted file mode 100644 index 690c9d7e2cf2..000000000000 Binary files a/website/static/img/guides/how-to-validate/polkadot-overview.jpg and /dev/null differ diff --git a/website/static/img/icon_collator.svg b/website/static/img/icon_collator.svg deleted file mode 100644 index 9d30d2b9c78d..000000000000 --- a/website/static/img/icon_collator.svg +++ /dev/null @@ -1 +0,0 @@ -icon-users \ No newline at end of file diff --git a/website/static/img/icon_validator.svg b/website/static/img/icon_validator.svg deleted file mode 100644 index 4bc832dafd66..000000000000 --- a/website/static/img/icon_validator.svg +++ /dev/null @@ -1 +0,0 @@ -icon-future-proof \ No newline at end of file diff --git a/website/static/img/identity/02.jpg b/website/static/img/identity/02.jpg deleted file mode 100644 index 624d14d9b263..000000000000 Binary files a/website/static/img/identity/02.jpg and /dev/null differ diff --git a/website/static/img/identity/03.jpg b/website/static/img/identity/03.jpg deleted file mode 100644 index d6d7f0e09738..000000000000 Binary files a/website/static/img/identity/03.jpg and /dev/null differ diff --git a/website/static/img/identity/04.jpg b/website/static/img/identity/04.jpg deleted file mode 100644 index aafacb605ea0..000000000000 Binary files a/website/static/img/identity/04.jpg and /dev/null differ diff --git a/website/static/img/identity/05.jpg b/website/static/img/identity/05.jpg deleted file mode 100644 index 32167bd3a681..000000000000 Binary files a/website/static/img/identity/05.jpg and /dev/null differ diff --git a/website/static/img/identity/06.jpg b/website/static/img/identity/06.jpg deleted file mode 100644 index 82444d1103c0..000000000000 Binary files a/website/static/img/identity/06.jpg and /dev/null differ diff --git a/website/static/img/identity/07.jpg b/website/static/img/identity/07.jpg deleted file mode 100644 index 655c57a6ac2a..000000000000 Binary files a/website/static/img/identity/07.jpg and /dev/null differ diff --git a/website/static/img/identity/08.jpg b/website/static/img/identity/08.jpg deleted file mode 100644 index 1f588b50a63e..000000000000 Binary files a/website/static/img/identity/08.jpg and /dev/null differ diff --git a/website/static/img/identity/09.jpg b/website/static/img/identity/09.jpg deleted file mode 100644 index f51250cea566..000000000000 Binary files a/website/static/img/identity/09.jpg and /dev/null differ diff --git a/website/static/img/identity/10.jpg b/website/static/img/identity/10.jpg deleted file mode 100644 index e689a85f23cf..000000000000 Binary files a/website/static/img/identity/10.jpg and /dev/null differ diff --git a/website/static/img/identity/11.jpg b/website/static/img/identity/11.jpg deleted file mode 100644 index 7ea56fc68f84..000000000000 Binary files a/website/static/img/identity/11.jpg and /dev/null differ diff --git a/website/static/img/identity/12.jpg b/website/static/img/identity/12.jpg deleted file mode 100644 index 5111c88ded7f..000000000000 Binary files a/website/static/img/identity/12.jpg and /dev/null differ diff --git a/website/static/img/identity/13.jpg b/website/static/img/identity/13.jpg deleted file mode 100644 index 992551249fe2..000000000000 Binary files a/website/static/img/identity/13.jpg and /dev/null differ diff --git a/website/static/img/identity/14.jpg b/website/static/img/identity/14.jpg deleted file mode 100644 index ba82bee6a756..000000000000 Binary files a/website/static/img/identity/14.jpg and /dev/null differ diff --git a/website/static/img/identity/15.jpg b/website/static/img/identity/15.jpg deleted file mode 100644 index 3a23c9edb551..000000000000 Binary files a/website/static/img/identity/15.jpg and /dev/null differ diff --git a/website/static/img/identity/16.jpg b/website/static/img/identity/16.jpg deleted file mode 100644 index 89541bce4100..000000000000 Binary files a/website/static/img/identity/16.jpg and /dev/null differ diff --git a/website/static/img/identity/clear.gif b/website/static/img/identity/clear.gif deleted file mode 100644 index da24c875f0fb..000000000000 Binary files a/website/static/img/identity/clear.gif and /dev/null differ diff --git a/website/static/img/identity/new1.jpg b/website/static/img/identity/new1.jpg deleted file mode 100644 index 5dc7e329b7ab..000000000000 Binary files a/website/static/img/identity/new1.jpg and /dev/null differ diff --git a/website/static/img/identity/new2.jpg b/website/static/img/identity/new2.jpg deleted file mode 100644 index c2d992983e5b..000000000000 Binary files a/website/static/img/identity/new2.jpg and /dev/null differ diff --git a/website/static/img/kusama/claim/claim-1.png b/website/static/img/kusama/claim/claim-1.png deleted file mode 100644 index 965838661c18..000000000000 Binary files a/website/static/img/kusama/claim/claim-1.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim-2.png b/website/static/img/kusama/claim/claim-2.png deleted file mode 100644 index ddd5843adc6f..000000000000 Binary files a/website/static/img/kusama/claim/claim-2.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim-3.png b/website/static/img/kusama/claim/claim-3.png deleted file mode 100644 index 70693b090351..000000000000 Binary files a/website/static/img/kusama/claim/claim-3.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim-4.png b/website/static/img/kusama/claim/claim-4.png deleted file mode 100644 index bc7fa439fc78..000000000000 Binary files a/website/static/img/kusama/claim/claim-4.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim_1.png b/website/static/img/kusama/claim/claim_1.png deleted file mode 100644 index caa9b4c3645d..000000000000 Binary files a/website/static/img/kusama/claim/claim_1.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim_2.png b/website/static/img/kusama/claim/claim_2.png deleted file mode 100644 index 65a676b48ae2..000000000000 Binary files a/website/static/img/kusama/claim/claim_2.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim_3.png b/website/static/img/kusama/claim/claim_3.png deleted file mode 100644 index b657c46b604d..000000000000 Binary files a/website/static/img/kusama/claim/claim_3.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim_4.png b/website/static/img/kusama/claim/claim_4.png deleted file mode 100644 index a227f4bc1f0b..000000000000 Binary files a/website/static/img/kusama/claim/claim_4.png and /dev/null differ diff --git a/website/static/img/kusama/claim/claim_5.png b/website/static/img/kusama/claim/claim_5.png deleted file mode 100644 index 1bc3c4be6199..000000000000 Binary files a/website/static/img/kusama/claim/claim_5.png and /dev/null differ diff --git a/website/static/img/kusama/create_account.png b/website/static/img/kusama/create_account.png deleted file mode 100644 index 36a7c818ce4b..000000000000 Binary files a/website/static/img/kusama/create_account.png and /dev/null differ diff --git a/website/static/img/kusama/faucet_1.png b/website/static/img/kusama/faucet_1.png deleted file mode 100644 index b701520e8129..000000000000 Binary files a/website/static/img/kusama/faucet_1.png and /dev/null differ diff --git a/website/static/img/kusama/faucet_2.png b/website/static/img/kusama/faucet_2.png deleted file mode 100644 index b5026f160f29..000000000000 Binary files a/website/static/img/kusama/faucet_2.png and /dev/null differ diff --git a/website/static/img/kusama/faucet_3.png b/website/static/img/kusama/faucet_3.png deleted file mode 100644 index 4074f00f938e..000000000000 Binary files a/website/static/img/kusama/faucet_3.png and /dev/null differ diff --git a/website/static/img/kusama/polkadotui-copy-account-address.png b/website/static/img/kusama/polkadotui-copy-account-address.png deleted file mode 100644 index e4944cb7f854..000000000000 Binary files a/website/static/img/kusama/polkadotui-copy-account-address.png and /dev/null differ diff --git a/website/static/img/kusama/polkadotui-create-your-account.png b/website/static/img/kusama/polkadotui-create-your-account.png deleted file mode 100644 index ca2c62d32ab8..000000000000 Binary files a/website/static/img/kusama/polkadotui-create-your-account.png and /dev/null differ diff --git a/website/static/img/kusama/polkadotui-find-the-accounts-page.png b/website/static/img/kusama/polkadotui-find-the-accounts-page.png deleted file mode 100644 index f448e53e80ed..000000000000 Binary files a/website/static/img/kusama/polkadotui-find-the-accounts-page.png and /dev/null differ diff --git a/website/static/img/kusama/polkadotui-select-add-account-on-accounts-page.png b/website/static/img/kusama/polkadotui-select-add-account-on-accounts-page.png deleted file mode 100644 index 6a662784a7d7..000000000000 Binary files a/website/static/img/kusama/polkadotui-select-add-account-on-accounts-page.png and /dev/null differ diff --git a/website/static/img/kusama/polkawallet-accounts-page.jpg b/website/static/img/kusama/polkawallet-accounts-page.jpg deleted file mode 100644 index c629e64bd427..000000000000 Binary files a/website/static/img/kusama/polkawallet-accounts-page.jpg and /dev/null differ diff --git a/website/static/img/kusama/polkawallet-copy-address.jpg b/website/static/img/kusama/polkawallet-copy-address.jpg deleted file mode 100644 index 03ed52c7f112..000000000000 Binary files a/website/static/img/kusama/polkawallet-copy-address.jpg and /dev/null differ diff --git a/website/static/img/kusama/polkawallet-create-account.jpg b/website/static/img/kusama/polkawallet-create-account.jpg deleted file mode 100644 index 28d500ae1a20..000000000000 Binary files a/website/static/img/kusama/polkawallet-create-account.jpg and /dev/null differ diff --git a/website/static/img/kusama/save_backup.png b/website/static/img/kusama/save_backup.png deleted file mode 100644 index 262c63c54faa..000000000000 Binary files a/website/static/img/kusama/save_backup.png and /dev/null differ diff --git a/website/static/img/kusama/save_generated_account.png b/website/static/img/kusama/save_generated_account.png deleted file mode 100644 index da0906b44464..000000000000 Binary files a/website/static/img/kusama/save_generated_account.png and /dev/null differ diff --git a/website/static/img/kusama/select_address.png b/website/static/img/kusama/select_address.png deleted file mode 100644 index ecd8424d36cb..000000000000 Binary files a/website/static/img/kusama/select_address.png and /dev/null differ diff --git a/website/static/img/kusama_canary_white.svg b/website/static/img/kusama_canary_white.svg deleted file mode 100644 index a2dee39c4ed4..000000000000 --- a/website/static/img/kusama_canary_white.svg +++ /dev/null @@ -1,16 +0,0 @@ - - - - - - - - diff --git a/website/static/img/logo-polkadot-light.svg b/website/static/img/logo-polkadot-light.svg deleted file mode 100644 index f67a7dc3938e..000000000000 --- a/website/static/img/logo-polkadot-light.svg +++ /dev/null @@ -1,4 +0,0 @@ - diff --git a/website/static/img/logo.svg b/website/static/img/logo.svg deleted file mode 100644 index b72118a9038b..000000000000 --- a/website/static/img/logo.svg +++ /dev/null @@ -1 +0,0 @@ -Asset 1 \ No newline at end of file diff --git a/website/static/img/logo_polkadot_wiki.svg b/website/static/img/logo_polkadot_wiki.svg deleted file mode 100644 index 80068436358d..000000000000 --- a/website/static/img/logo_polkadot_wiki.svg +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - - - - - - - - - - - diff --git a/website/static/img/network/one_parachain.png b/website/static/img/network/one_parachain.png deleted file mode 100644 index ce31d7644f3a..000000000000 Binary files a/website/static/img/network/one_parachain.png and /dev/null differ diff --git a/website/static/img/oss_logo.png b/website/static/img/oss_logo.png deleted file mode 100755 index 8183e289b139..000000000000 Binary files a/website/static/img/oss_logo.png and /dev/null differ diff --git a/website/static/img/parachain-roadmap.jpg b/website/static/img/parachain-roadmap.jpg deleted file mode 100644 index a2fb6ab9fa02..000000000000 Binary files a/website/static/img/parachain-roadmap.jpg and /dev/null differ diff --git a/website/static/img/parachain/info.png b/website/static/img/parachain/info.png deleted file mode 100644 index 46bdbc046dd4..000000000000 Binary files a/website/static/img/parachain/info.png and /dev/null differ diff --git a/website/static/img/parachain/referendum.png b/website/static/img/parachain/referendum.png deleted file mode 100644 index babc91adeccc..000000000000 Binary files a/website/static/img/parachain/referendum.png and /dev/null differ diff --git a/website/static/img/parachain/register.png b/website/static/img/parachain/register.png deleted file mode 100644 index 7d0aa189eca2..000000000000 Binary files a/website/static/img/parachain/register.png and /dev/null differ diff --git a/website/static/img/polkadot-wechat.jpg b/website/static/img/polkadot-wechat.jpg deleted file mode 100644 index b324eb10568b..000000000000 Binary files a/website/static/img/polkadot-wechat.jpg and /dev/null differ diff --git a/website/static/img/polkadot_overview.svg b/website/static/img/polkadot_overview.svg deleted file mode 100644 index 8e4f599f8a90..000000000000 --- a/website/static/img/polkadot_overview.svg +++ /dev/null @@ -1 +0,0 @@ -Asset 1 \ No newline at end of file diff --git a/website/static/img/polkadot_ui_1.png b/website/static/img/polkadot_ui_1.png deleted file mode 100644 index a8b3168db5e0..000000000000 Binary files a/website/static/img/polkadot_ui_1.png and /dev/null differ diff --git a/website/static/img/polkadot_ui_2.png b/website/static/img/polkadot_ui_2.png deleted file mode 100644 index 2104967172e5..000000000000 Binary files a/website/static/img/polkadot_ui_2.png and /dev/null differ diff --git a/website/static/img/polkadot_ui_3.png b/website/static/img/polkadot_ui_3.png deleted file mode 100644 index 555c7832617c..000000000000 Binary files a/website/static/img/polkadot_ui_3.png and /dev/null differ diff --git a/website/static/img/spree.jpg b/website/static/img/spree.jpg deleted file mode 100644 index 8c2d64fef8bb..000000000000 Binary files a/website/static/img/spree.jpg and /dev/null differ diff --git a/website/static/img/staking/polkadotjs_nominator_account.png b/website/static/img/staking/polkadotjs_nominator_account.png deleted file mode 100644 index 435bb44fdb9a..000000000000 Binary files a/website/static/img/staking/polkadotjs_nominator_account.png and /dev/null differ diff --git a/website/static/img/staking/polkadotjs_nominators_target.png b/website/static/img/staking/polkadotjs_nominators_target.png deleted file mode 100644 index f3766046092b..000000000000 Binary files a/website/static/img/staking/polkadotjs_nominators_target.png and /dev/null differ diff --git a/website/static/img/staking/polkadotjs_validator_stats.png b/website/static/img/staking/polkadotjs_validator_stats.png deleted file mode 100644 index 63f82107b1da..000000000000 Binary files a/website/static/img/staking/polkadotjs_validator_stats.png and /dev/null differ diff --git a/website/static/img/undraw_code_review.svg b/website/static/img/undraw_code_review.svg deleted file mode 100755 index 56433417231c..000000000000 --- a/website/static/img/undraw_code_review.svg +++ /dev/null @@ -1 +0,0 @@ -code review diff --git a/website/static/img/undraw_monitor.svg b/website/static/img/undraw_monitor.svg deleted file mode 100755 index c81d8ab17301..000000000000 --- a/website/static/img/undraw_monitor.svg +++ /dev/null @@ -1 +0,0 @@ -monitor diff --git a/website/static/img/undraw_note_list.svg b/website/static/img/undraw_note_list.svg deleted file mode 100755 index e82c33bfd716..000000000000 --- a/website/static/img/undraw_note_list.svg +++ /dev/null @@ -1 +0,0 @@ -note list diff --git a/website/static/img/undraw_online.svg b/website/static/img/undraw_online.svg deleted file mode 100755 index 7cc31ce006e9..000000000000 --- a/website/static/img/undraw_online.svg +++ /dev/null @@ -1 +0,0 @@ -online diff --git a/website/static/img/undraw_open_source.svg b/website/static/img/undraw_open_source.svg deleted file mode 100755 index dbd7a2db8518..000000000000 --- a/website/static/img/undraw_open_source.svg +++ /dev/null @@ -1 +0,0 @@ -open source diff --git a/website/static/img/undraw_operating_system.svg b/website/static/img/undraw_operating_system.svg deleted file mode 100755 index 60b7c806edb5..000000000000 --- a/website/static/img/undraw_operating_system.svg +++ /dev/null @@ -1 +0,0 @@ -operating system diff --git a/website/static/img/undraw_react.svg b/website/static/img/undraw_react.svg deleted file mode 100755 index e3e60bb52699..000000000000 --- a/website/static/img/undraw_react.svg +++ /dev/null @@ -1 +0,0 @@ -react diff --git a/website/static/img/undraw_tweetstorm.svg b/website/static/img/undraw_tweetstorm.svg deleted file mode 100755 index c957581db712..000000000000 --- a/website/static/img/undraw_tweetstorm.svg +++ /dev/null @@ -1 +0,0 @@ -tweetstorm diff --git a/website/static/img/undraw_youtube_tutorial.svg b/website/static/img/undraw_youtube_tutorial.svg deleted file mode 100755 index 17d3f7776f12..000000000000 --- a/website/static/img/undraw_youtube_tutorial.svg +++ /dev/null @@ -1 +0,0 @@ -youtube tutorial diff --git a/website/static/img/updated_pre.png b/website/static/img/updated_pre.png deleted file mode 100644 index 0e51b326903c..000000000000 Binary files a/website/static/img/updated_pre.png and /dev/null differ diff --git a/website/static/img/wechat_page_account.jpg b/website/static/img/wechat_page_account.jpg deleted file mode 100644 index 4744570e91d0..000000000000 Binary files a/website/static/img/wechat_page_account.jpg and /dev/null differ diff --git a/website/static/img/wss/wss04.png b/website/static/img/wss/wss04.png deleted file mode 100644 index 9cdb86b93f3a..000000000000 Binary files a/website/static/img/wss/wss04.png and /dev/null differ diff --git a/website/static/index.html b/website/static/index.html deleted file mode 100644 index 052d832e5fe9..000000000000 --- a/website/static/index.html +++ /dev/null @@ -1,21 +0,0 @@ - - - - - - - Polkadot Wiki - - - If you are not redirected automatically, follow this link. - - diff --git a/website/static/js/addressChanger.js b/website/static/js/addressChanger.js deleted file mode 100644 index 5a3d8533681d..000000000000 --- a/website/static/js/addressChanger.js +++ /dev/null @@ -1,30 +0,0 @@ -const decodeAddress = require("@polkadot/util-crypto/address/decode").default; -const encodeAddress = require("@polkadot/util-crypto/address/encode").default; - -const addressChanger = () => { - const inEl = document.getElementById('input'); - const prefEl = document.getElementById('prefix-select'); - const outEl = document.getElementById('output'); - - const prefix = prefEl.options[prefEl.selectedIndex].value; - - try { - const decoded = decodeAddress(inEl.value); - const encoded = encodeAddress(decoded, prefix); - outEl.textContent = encoded.toString(); - } catch (err) { - console.log(err); - } -} -globalThis.addressChanger = addressChanger; - -// const test = () => { -// const addr = "5CJK5pSJWjZ7V3tiuo6jJPZKX7hxSPhNQds1g28icsrmUXaT"; -// const decoded = decodeAddress(addr); -// const encoded = encodeAddress(decoded, "2"); -// console.log(encoded.toString()) -// } - -// test(); - -// npx browserify addressChanger.js > addressChanger-browser.js; npx uglify-es --mangle --compress -- addressChanger-browser.js > packaged/addressChanger.js; rm addressChanger-browser.js diff --git a/website/static/js/clipboard.min.js b/website/static/js/clipboard.min.js deleted file mode 100644 index 28650f3cc98a..000000000000 --- a/website/static/js/clipboard.min.js +++ /dev/null @@ -1,7 +0,0 @@ -/*! - * clipboard.js v2.0.6 - * https://clipboardjs.com/ - * - * Licensed MIT © Zeno Rocha - */ -!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.ClipboardJS=e():t.ClipboardJS=e()}(this,function(){return o={},r.m=n=[function(t,e){t.exports=function(t){var e;if("SELECT"===t.nodeName)t.focus(),e=t.value;else if("INPUT"===t.nodeName||"TEXTAREA"===t.nodeName){var n=t.hasAttribute("readonly");n||t.setAttribute("readonly",""),t.select(),t.setSelectionRange(0,t.value.length),n||t.removeAttribute("readonly"),e=t.value}else{t.hasAttribute("contenteditable")&&t.focus();var o=window.getSelection(),r=document.createRange();r.selectNodeContents(t),o.removeAllRanges(),o.addRange(r),e=o.toString()}return e}},function(t,e){function n(){}n.prototype={on:function(t,e,n){var o=this.e||(this.e={});return(o[t]||(o[t]=[])).push({fn:e,ctx:n}),this},once:function(t,e,n){var o=this;function r(){o.off(t,r),e.apply(n,arguments)}return r._=e,this.on(t,r,n)},emit:function(t){for(var e=[].slice.call(arguments,1),n=((this.e||(this.e={}))[t]||[]).slice(),o=0,r=n.length;o' + - icon + - '' + - label + - "" + - "
    "; - return btn; - } - - function addButtons(codeBlockSelector, btn) { - document.querySelectorAll(codeBlockSelector).forEach(function (code) { - code.parentNode.appendChild(btn.cloneNode(true)); - }); - } - - const copyIcon = - ''; - - addButtons(".hljs", button("Copy", "Copy code to clipboard", copyIcon, "btnClipboard")); - - const clipboard = new ClipboardJS(".btnClipboard", { - target: function (trigger) { - return trigger.parentNode.querySelector("code"); - }, - }); - - clipboard.on("success", function (event) { - event.clearSelection(); - const textEl = event.trigger.querySelector(".btnIcon__label"); - textEl.textContent = "Copied"; - setTimeout(function () { - textEl.textContent = "Copy"; - }, 2000); - }); -}); diff --git a/website/static/js/custom.js b/website/static/js/custom.js deleted file mode 100644 index f56ae7139c2d..000000000000 --- a/website/static/js/custom.js +++ /dev/null @@ -1,90 +0,0 @@ -(function (funcName, baseObj) { - // The public function name defaults to window.docReady - // but you can pass in your own object and own function name and those will be used - // if you want to put them in a different namespace - funcName = funcName || "docReady"; - baseObj = baseObj || window; - var readyList = []; - var readyFired = false; - var readyEventHandlersInstalled = false; - - // call this when the document is ready - // this function protects itself against being called more than once - function ready() { - if (!readyFired) { - // this must be set to true before we start calling callbacks - readyFired = true; - for (var i = 0; i < readyList.length; i++) { - // if a callback here happens to add new ready handlers, - // the docReady() function will see that it already fired - // and will schedule the callback to run right after - // this event loop finishes so all handlers will still execute - // in order and no new ones will be added to the readyList - // while we are processing the list - readyList[i].fn.call(window, readyList[i].ctx); - } - // allow any closures held by these functions to free - readyList = []; - } - } - - function readyStateChange() { - if (document.readyState === "complete") { - ready(); - } - } - - // This is the one public interface - // docReady(fn, context); - // the context argument is optional - if present, it will be passed - // as an argument to the callback - baseObj[funcName] = function (callback, context) { - if (typeof callback !== "function") { - throw new TypeError("callback for docReady(fn) must be a function"); - } - // if ready has already fired, then just schedule the callback - // to fire asynchronously, but right away - if (readyFired) { - setTimeout(function () { - callback(context); - }, 1); - return; - } else { - // add the function and context to the list - readyList.push({ - fn: callback, - ctx: context, - }); - } - // if document already ready to go, schedule the ready function to run - if (document.readyState === "complete") { - setTimeout(ready, 1); - } else if (!readyEventHandlersInstalled) { - // otherwise if we don't have event handlers installed, install them - if (document.addEventListener) { - // first choice is DOMContentLoaded event - document.addEventListener("DOMContentLoaded", ready, false); - // backup is window load event - window.addEventListener("load", ready, false); - } else { - // must be IE - document.attachEvent("onreadystatechange", readyStateChange); - window.attachEvent("onload", ready); - } - readyEventHandlersInstalled = true; - } - }; -})("docReady", window); - -docReady(function () { - // Custom logic goes here - - AOS.init(); - - // Add fathom to footer - - let script = document.createElement("script"); - script.setAttribute("src", "https://mammal.polkadot.network/script.js"); - script.setAttribute("site", "YOUKYIQA"); - document.querySelector("body footer").appendChild(script); -}); diff --git a/website/static/js/packaged/addressChanger.js b/website/static/js/packaged/addressChanger.js deleted file mode 100644 index b5a3da4b5349..000000000000 --- a/website/static/js/packaged/addressChanger.js +++ /dev/null @@ -1 +0,0 @@ -!function(){return function A(e,t,i){function g(n,B){if(!t[n]){if(!e[n]){var I="function"==typeof require&&require;if(!B&&I)return I(n,!0);if(r)return r(n,!0);var o=new Error("Cannot find module '"+n+"'");throw o.code="MODULE_NOT_FOUND",o}var a=t[n]={exports:{}};e[n][0].call(a.exports,function(A){return g(e[n][1][A]||A)},a,a.exports,A,e,t,i)}return t[n].exports}for(var r="function"==typeof require&&require,n=0;n>6],g=0==(32&t);if(31==(31&t)){let i=t;for(t=0;128==(128&i);){if(i=A.readUInt8(e),A.isError(i))return i;t<<=7,t|=127&i}}else t&=31;return{cls:i,primitive:g,tag:t,tagStr:B.tag[t]}}function Q(A,e,t){let i=A.readUInt8(t);if(A.isError(i))return i;if(!e&&128===i)return null;if(0==(128&i))return i;const g=127&i;if(g>4)return A.error("length octect is too long");i=0;for(let e=0;e=31)return i.error("Multi-octet tag encoding unsupported");e||(g|=32);return g|=n.tagClassByName[t||"universal"]<<6}(A,e,t,this.reporter);if(i.length<128){const A=g.alloc(2);return A[0]=r,A[1]=i.length,this._createEncoderBuffer([A,i])}let B=1;for(let A=i.length;A>=256;A>>=8)B++;const I=g.alloc(2+B);I[0]=r,I[1]=128|B;for(let A=1+B,e=i.length;e>0;A--,e>>=8)I[A]=255&e;return this._createEncoderBuffer([I,i])},I.prototype._encodeStr=function(A,e){if("bitstr"===e)return this._createEncoderBuffer([0|A.unused,A.data]);if("bmpstr"===e){const e=g.alloc(2*A.length);for(let t=0;t=40)return this.reporter.error("Second objid identifier OOB");A.splice(0,2,40*A[0]+A[1])}let i=0;for(let e=0;e=128;t>>=7)i++}const r=g.alloc(i);let n=r.length-1;for(let e=A.length-1;e>=0;e--){let t=A[e];for(r[n--]=127&t;(t>>=7)>0;)r[n--]=128|127&t}return this._createEncoderBuffer(r)},I.prototype._encodeTime=function(A,e){let t;const i=new Date(A);return"gentime"===e?t=[o(i.getUTCFullYear()),o(i.getUTCMonth()+1),o(i.getUTCDate()),o(i.getUTCHours()),o(i.getUTCMinutes()),o(i.getUTCSeconds()),"Z"].join(""):"utctime"===e?t=[o(i.getUTCFullYear()%100),o(i.getUTCMonth()+1),o(i.getUTCDate()),o(i.getUTCHours()),o(i.getUTCMinutes()),o(i.getUTCSeconds()),"Z"].join(""):this.reporter.error("Encoding "+e+" time is not supported yet"),this._encodeStr(t,"octstr")},I.prototype._encodeNull=function(){return this._createEncoderBuffer("")},I.prototype._encodeInt=function(A,e){if("string"==typeof A){if(!e)return this.reporter.error("String int or enum given, but no values map");if(!e.hasOwnProperty(A))return this.reporter.error("Values map doesn't contain: "+JSON.stringify(A));A=e[A]}if("number"!=typeof A&&!g.isBuffer(A)){const e=A.toArray();!A.sign&&128&e[0]&&e.unshift(0),A=g.from(e)}if(g.isBuffer(A)){let e=A.length;0===A.length&&e++;const t=g.alloc(e);return A.copy(t),0===A.length&&(t[0]=0),this._createEncoderBuffer(t)}if(A<128)return this._createEncoderBuffer(A);if(A<256)return this._createEncoderBuffer([0,A]);let t=1;for(let e=A;e>=256;e>>=8)t++;const i=new Array(t);for(let e=i.length-1;e>=0;e--)i[e]=255&A,A>>=8;return 128&i[0]&&i.unshift(0),this._createEncoderBuffer(g.from(i))},I.prototype._encodeBool=function(A){return this._createEncoderBuffer(A?255:0)},I.prototype._use=function(A,e){return"function"==typeof A&&(A=A(e)),A._getEncoder("der").tree},I.prototype._skipDefault=function(A,e,t){const i=this._baseState;let g;if(null===i.default)return!1;const r=A.join();if(void 0===i.defaultBuffer&&(i.defaultBuffer=this._encodeValue(i.default,e,t).join()),r.length!==i.defaultBuffer.length)return!1;for(g=0;g=49&&n<=54?n-49+10:n>=17&&n<=22?n-17+10:15&n}return i}function I(A,e,t,i){for(var g=0,r=Math.min(A.length,t),n=e;n=49?B-49+10:B>=17?B-17+10:B}return g}r.isBN=function(A){return A instanceof r||null!==A&&"object"==typeof A&&A.constructor.wordSize===r.wordSize&&Array.isArray(A.words)},r.max=function(A,e){return A.cmp(e)>0?A:e},r.min=function(A,e){return A.cmp(e)<0?A:e},r.prototype._init=function(A,e,t){if("number"==typeof A)return this._initNumber(A,e,t);if("object"==typeof A)return this._initArray(A,e,t);"hex"===e&&(e=16),i(e===(0|e)&&e>=2&&e<=36);var g=0;"-"===(A=A.toString().replace(/\s+/g,""))[0]&&g++,16===e?this._parseHex(A,g):this._parseBase(A,e,g),"-"===A[0]&&(this.negative=1),this.strip(),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initNumber=function(A,e,t){A<0&&(this.negative=1,A=-A),A<67108864?(this.words=[67108863&A],this.length=1):A<4503599627370496?(this.words=[67108863&A,A/67108864&67108863],this.length=2):(i(A<9007199254740992),this.words=[67108863&A,A/67108864&67108863,1],this.length=3),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initArray=function(A,e,t){if(i("number"==typeof A.length),A.length<=0)return this.words=[0],this.length=1,this;this.length=Math.ceil(A.length/3),this.words=new Array(this.length);for(var g=0;g=0;g-=3)n=A[g]|A[g-1]<<8|A[g-2]<<16,this.words[r]|=n<>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);else if("le"===t)for(g=0,r=0;g>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);return this.strip()},r.prototype._parseHex=function(A,e){this.length=Math.ceil((A.length-e)/6),this.words=new Array(this.length);for(var t=0;t=e;t-=6)g=B(A,t,t+6),this.words[i]|=g<>>26-r&4194303,(r+=24)>=26&&(r-=26,i++);t+6!==e&&(g=B(A,e,t+6),this.words[i]|=g<>>26-r&4194303),this.strip()},r.prototype._parseBase=function(A,e,t){this.words=[0],this.length=1;for(var i=0,g=1;g<=67108863;g*=e)i++;i--,g=g/e|0;for(var r=A.length-t,n=r%i,B=Math.min(r,r-n)+t,o=0,a=t;a1&&0===this.words[this.length-1];)this.length--;return this._normSign()},r.prototype._normSign=function(){return 1===this.length&&0===this.words[0]&&(this.negative=0),this},r.prototype.inspect=function(){return(this.red?""};var o=["","0","00","000","0000","00000","000000","0000000","00000000","000000000","0000000000","00000000000","000000000000","0000000000000","00000000000000","000000000000000","0000000000000000","00000000000000000","000000000000000000","0000000000000000000","00000000000000000000","000000000000000000000","0000000000000000000000","00000000000000000000000","000000000000000000000000","0000000000000000000000000"],a=[0,0,25,16,12,11,10,9,8,8,7,7,7,7,6,6,6,6,6,6,6,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5],Q=[0,0,33554432,43046721,16777216,48828125,60466176,40353607,16777216,43046721,1e7,19487171,35831808,62748517,7529536,11390625,16777216,24137569,34012224,47045881,64e6,4084101,5153632,6436343,7962624,9765625,11881376,14348907,17210368,20511149,243e5,28629151,33554432,39135393,45435424,52521875,60466176];function C(A,e,t){t.negative=e.negative^A.negative;var i=A.length+e.length|0;t.length=i,i=i-1|0;var g=0|A.words[0],r=0|e.words[0],n=g*r,B=67108863&n,I=n/67108864|0;t.words[0]=B;for(var o=1;o>>26,Q=67108863&I,C=Math.min(o,e.length-1),s=Math.max(0,o-A.length+1);s<=C;s++){var c=o-s|0;a+=(n=(g=0|A.words[c])*(r=0|e.words[s])+Q)/67108864|0,Q=67108863&n}t.words[o]=0|Q,I=0|a}return 0!==I?t.words[o]=0|I:t.length--,t.strip()}r.prototype.toString=function(A,e){var t;if(A=A||10,e=0|e||1,16===A||"hex"===A){t="";for(var g=0,r=0,n=0;n>>24-g&16777215)||n!==this.length-1?o[6-I.length]+I+t:I+t,(g+=2)>=26&&(g-=26,n--)}for(0!==r&&(t=r.toString(16)+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}if(A===(0|A)&&A>=2&&A<=36){var C=a[A],s=Q[A];t="";var c=this.clone();for(c.negative=0;!c.isZero();){var h=c.modn(s).toString(A);t=(c=c.idivn(s)).isZero()?h+t:o[C-h.length]+h+t}for(this.isZero()&&(t="0"+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}i(!1,"Base should be between 2 and 36")},r.prototype.toNumber=function(){var A=this.words[0];return 2===this.length?A+=67108864*this.words[1]:3===this.length&&1===this.words[2]?A+=4503599627370496+67108864*this.words[1]:this.length>2&&i(!1,"Number can only safely store up to 53 bits"),0!==this.negative?-A:A},r.prototype.toJSON=function(){return this.toString(16)},r.prototype.toBuffer=function(A,e){return i(void 0!==n),this.toArrayLike(n,A,e)},r.prototype.toArray=function(A,e){return this.toArrayLike(Array,A,e)},r.prototype.toArrayLike=function(A,e,t){var g=this.byteLength(),r=t||Math.max(1,g);i(g<=r,"byte array longer than desired length"),i(r>0,"Requested array length <= 0"),this.strip();var n,B,I="le"===e,o=new A(r),a=this.clone();if(I){for(B=0;!a.isZero();B++)n=a.andln(255),a.iushrn(8),o[B]=n;for(;B=4096&&(t+=13,e>>>=13),e>=64&&(t+=7,e>>>=7),e>=8&&(t+=4,e>>>=4),e>=2&&(t+=2,e>>>=2),t+e},r.prototype._zeroBits=function(A){if(0===A)return 26;var e=A,t=0;return 0==(8191&e)&&(t+=13,e>>>=13),0==(127&e)&&(t+=7,e>>>=7),0==(15&e)&&(t+=4,e>>>=4),0==(3&e)&&(t+=2,e>>>=2),0==(1&e)&&t++,t},r.prototype.bitLength=function(){var A=this.words[this.length-1],e=this._countBits(A);return 26*(this.length-1)+e},r.prototype.zeroBits=function(){if(this.isZero())return 0;for(var A=0,e=0;eA.length?this.clone().ior(A):A.clone().ior(this)},r.prototype.uor=function(A){return this.length>A.length?this.clone().iuor(A):A.clone().iuor(this)},r.prototype.iuand=function(A){var e;e=this.length>A.length?A:this;for(var t=0;tA.length?this.clone().iand(A):A.clone().iand(this)},r.prototype.uand=function(A){return this.length>A.length?this.clone().iuand(A):A.clone().iuand(this)},r.prototype.iuxor=function(A){var e,t;this.length>A.length?(e=this,t=A):(e=A,t=this);for(var i=0;iA.length?this.clone().ixor(A):A.clone().ixor(this)},r.prototype.uxor=function(A){return this.length>A.length?this.clone().iuxor(A):A.clone().iuxor(this)},r.prototype.inotn=function(A){i("number"==typeof A&&A>=0);var e=0|Math.ceil(A/26),t=A%26;this._expand(e),t>0&&e--;for(var g=0;g0&&(this.words[g]=~this.words[g]&67108863>>26-t),this.strip()},r.prototype.notn=function(A){return this.clone().inotn(A)},r.prototype.setn=function(A,e){i("number"==typeof A&&A>=0);var t=A/26|0,g=A%26;return this._expand(t+1),this.words[t]=e?this.words[t]|1<A.length?(t=this,i=A):(t=A,i=this);for(var g=0,r=0;r>>26;for(;0!==g&&r>>26;if(this.length=t.length,0!==g)this.words[this.length]=g,this.length++;else if(t!==this)for(;rA.length?this.clone().iadd(A):A.clone().iadd(this)},r.prototype.isub=function(A){if(0!==A.negative){A.negative=0;var e=this.iadd(A);return A.negative=1,e._normSign()}if(0!==this.negative)return this.negative=0,this.iadd(A),this.negative=1,this._normSign();var t,i,g=this.cmp(A);if(0===g)return this.negative=0,this.length=1,this.words[0]=0,this;g>0?(t=this,i=A):(t=A,i=this);for(var r=0,n=0;n>26,this.words[n]=67108863&e;for(;0!==r&&n>26,this.words[n]=67108863&e;if(0===r&&n>>13,s=0|n[1],c=8191&s,h=s>>>13,f=0|n[2],E=8191&f,u=f>>>13,d=0|n[3],l=8191&d,w=d>>>13,p=0|n[4],D=8191&p,b=p>>>13,y=0|n[5],M=8191&y,m=y>>>13,G=0|n[6],k=8191&G,F=G>>>13,N=0|n[7],S=8191&N,Y=N>>>13,v=0|n[8],K=8191&v,U=v>>>13,J=0|n[9],H=8191&J,R=J>>>13,q=0|B[0],L=8191&q,x=q>>>13,Z=0|B[1],j=8191&Z,W=Z>>>13,O=0|B[2],P=8191&O,V=O>>>13,X=0|B[3],z=8191&X,T=X>>>13,_=0|B[4],$=8191&_,AA=_>>>13,eA=0|B[5],tA=8191&eA,iA=eA>>>13,gA=0|B[6],rA=8191&gA,nA=gA>>>13,BA=0|B[7],IA=8191&BA,oA=BA>>>13,aA=0|B[8],QA=8191&aA,CA=aA>>>13,sA=0|B[9],cA=8191&sA,hA=sA>>>13;t.negative=A.negative^e.negative,t.length=19;var fA=(o+(i=Math.imul(Q,L))|0)+((8191&(g=(g=Math.imul(Q,x))+Math.imul(C,L)|0))<<13)|0;o=((r=Math.imul(C,x))+(g>>>13)|0)+(fA>>>26)|0,fA&=67108863,i=Math.imul(c,L),g=(g=Math.imul(c,x))+Math.imul(h,L)|0,r=Math.imul(h,x);var EA=(o+(i=i+Math.imul(Q,j)|0)|0)+((8191&(g=(g=g+Math.imul(Q,W)|0)+Math.imul(C,j)|0))<<13)|0;o=((r=r+Math.imul(C,W)|0)+(g>>>13)|0)+(EA>>>26)|0,EA&=67108863,i=Math.imul(E,L),g=(g=Math.imul(E,x))+Math.imul(u,L)|0,r=Math.imul(u,x),i=i+Math.imul(c,j)|0,g=(g=g+Math.imul(c,W)|0)+Math.imul(h,j)|0,r=r+Math.imul(h,W)|0;var uA=(o+(i=i+Math.imul(Q,P)|0)|0)+((8191&(g=(g=g+Math.imul(Q,V)|0)+Math.imul(C,P)|0))<<13)|0;o=((r=r+Math.imul(C,V)|0)+(g>>>13)|0)+(uA>>>26)|0,uA&=67108863,i=Math.imul(l,L),g=(g=Math.imul(l,x))+Math.imul(w,L)|0,r=Math.imul(w,x),i=i+Math.imul(E,j)|0,g=(g=g+Math.imul(E,W)|0)+Math.imul(u,j)|0,r=r+Math.imul(u,W)|0,i=i+Math.imul(c,P)|0,g=(g=g+Math.imul(c,V)|0)+Math.imul(h,P)|0,r=r+Math.imul(h,V)|0;var dA=(o+(i=i+Math.imul(Q,z)|0)|0)+((8191&(g=(g=g+Math.imul(Q,T)|0)+Math.imul(C,z)|0))<<13)|0;o=((r=r+Math.imul(C,T)|0)+(g>>>13)|0)+(dA>>>26)|0,dA&=67108863,i=Math.imul(D,L),g=(g=Math.imul(D,x))+Math.imul(b,L)|0,r=Math.imul(b,x),i=i+Math.imul(l,j)|0,g=(g=g+Math.imul(l,W)|0)+Math.imul(w,j)|0,r=r+Math.imul(w,W)|0,i=i+Math.imul(E,P)|0,g=(g=g+Math.imul(E,V)|0)+Math.imul(u,P)|0,r=r+Math.imul(u,V)|0,i=i+Math.imul(c,z)|0,g=(g=g+Math.imul(c,T)|0)+Math.imul(h,z)|0,r=r+Math.imul(h,T)|0;var lA=(o+(i=i+Math.imul(Q,$)|0)|0)+((8191&(g=(g=g+Math.imul(Q,AA)|0)+Math.imul(C,$)|0))<<13)|0;o=((r=r+Math.imul(C,AA)|0)+(g>>>13)|0)+(lA>>>26)|0,lA&=67108863,i=Math.imul(M,L),g=(g=Math.imul(M,x))+Math.imul(m,L)|0,r=Math.imul(m,x),i=i+Math.imul(D,j)|0,g=(g=g+Math.imul(D,W)|0)+Math.imul(b,j)|0,r=r+Math.imul(b,W)|0,i=i+Math.imul(l,P)|0,g=(g=g+Math.imul(l,V)|0)+Math.imul(w,P)|0,r=r+Math.imul(w,V)|0,i=i+Math.imul(E,z)|0,g=(g=g+Math.imul(E,T)|0)+Math.imul(u,z)|0,r=r+Math.imul(u,T)|0,i=i+Math.imul(c,$)|0,g=(g=g+Math.imul(c,AA)|0)+Math.imul(h,$)|0,r=r+Math.imul(h,AA)|0;var wA=(o+(i=i+Math.imul(Q,tA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,iA)|0)+Math.imul(C,tA)|0))<<13)|0;o=((r=r+Math.imul(C,iA)|0)+(g>>>13)|0)+(wA>>>26)|0,wA&=67108863,i=Math.imul(k,L),g=(g=Math.imul(k,x))+Math.imul(F,L)|0,r=Math.imul(F,x),i=i+Math.imul(M,j)|0,g=(g=g+Math.imul(M,W)|0)+Math.imul(m,j)|0,r=r+Math.imul(m,W)|0,i=i+Math.imul(D,P)|0,g=(g=g+Math.imul(D,V)|0)+Math.imul(b,P)|0,r=r+Math.imul(b,V)|0,i=i+Math.imul(l,z)|0,g=(g=g+Math.imul(l,T)|0)+Math.imul(w,z)|0,r=r+Math.imul(w,T)|0,i=i+Math.imul(E,$)|0,g=(g=g+Math.imul(E,AA)|0)+Math.imul(u,$)|0,r=r+Math.imul(u,AA)|0,i=i+Math.imul(c,tA)|0,g=(g=g+Math.imul(c,iA)|0)+Math.imul(h,tA)|0,r=r+Math.imul(h,iA)|0;var pA=(o+(i=i+Math.imul(Q,rA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,nA)|0)+Math.imul(C,rA)|0))<<13)|0;o=((r=r+Math.imul(C,nA)|0)+(g>>>13)|0)+(pA>>>26)|0,pA&=67108863,i=Math.imul(S,L),g=(g=Math.imul(S,x))+Math.imul(Y,L)|0,r=Math.imul(Y,x),i=i+Math.imul(k,j)|0,g=(g=g+Math.imul(k,W)|0)+Math.imul(F,j)|0,r=r+Math.imul(F,W)|0,i=i+Math.imul(M,P)|0,g=(g=g+Math.imul(M,V)|0)+Math.imul(m,P)|0,r=r+Math.imul(m,V)|0,i=i+Math.imul(D,z)|0,g=(g=g+Math.imul(D,T)|0)+Math.imul(b,z)|0,r=r+Math.imul(b,T)|0,i=i+Math.imul(l,$)|0,g=(g=g+Math.imul(l,AA)|0)+Math.imul(w,$)|0,r=r+Math.imul(w,AA)|0,i=i+Math.imul(E,tA)|0,g=(g=g+Math.imul(E,iA)|0)+Math.imul(u,tA)|0,r=r+Math.imul(u,iA)|0,i=i+Math.imul(c,rA)|0,g=(g=g+Math.imul(c,nA)|0)+Math.imul(h,rA)|0,r=r+Math.imul(h,nA)|0;var DA=(o+(i=i+Math.imul(Q,IA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,oA)|0)+Math.imul(C,IA)|0))<<13)|0;o=((r=r+Math.imul(C,oA)|0)+(g>>>13)|0)+(DA>>>26)|0,DA&=67108863,i=Math.imul(K,L),g=(g=Math.imul(K,x))+Math.imul(U,L)|0,r=Math.imul(U,x),i=i+Math.imul(S,j)|0,g=(g=g+Math.imul(S,W)|0)+Math.imul(Y,j)|0,r=r+Math.imul(Y,W)|0,i=i+Math.imul(k,P)|0,g=(g=g+Math.imul(k,V)|0)+Math.imul(F,P)|0,r=r+Math.imul(F,V)|0,i=i+Math.imul(M,z)|0,g=(g=g+Math.imul(M,T)|0)+Math.imul(m,z)|0,r=r+Math.imul(m,T)|0,i=i+Math.imul(D,$)|0,g=(g=g+Math.imul(D,AA)|0)+Math.imul(b,$)|0,r=r+Math.imul(b,AA)|0,i=i+Math.imul(l,tA)|0,g=(g=g+Math.imul(l,iA)|0)+Math.imul(w,tA)|0,r=r+Math.imul(w,iA)|0,i=i+Math.imul(E,rA)|0,g=(g=g+Math.imul(E,nA)|0)+Math.imul(u,rA)|0,r=r+Math.imul(u,nA)|0,i=i+Math.imul(c,IA)|0,g=(g=g+Math.imul(c,oA)|0)+Math.imul(h,IA)|0,r=r+Math.imul(h,oA)|0;var bA=(o+(i=i+Math.imul(Q,QA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,CA)|0)+Math.imul(C,QA)|0))<<13)|0;o=((r=r+Math.imul(C,CA)|0)+(g>>>13)|0)+(bA>>>26)|0,bA&=67108863,i=Math.imul(H,L),g=(g=Math.imul(H,x))+Math.imul(R,L)|0,r=Math.imul(R,x),i=i+Math.imul(K,j)|0,g=(g=g+Math.imul(K,W)|0)+Math.imul(U,j)|0,r=r+Math.imul(U,W)|0,i=i+Math.imul(S,P)|0,g=(g=g+Math.imul(S,V)|0)+Math.imul(Y,P)|0,r=r+Math.imul(Y,V)|0,i=i+Math.imul(k,z)|0,g=(g=g+Math.imul(k,T)|0)+Math.imul(F,z)|0,r=r+Math.imul(F,T)|0,i=i+Math.imul(M,$)|0,g=(g=g+Math.imul(M,AA)|0)+Math.imul(m,$)|0,r=r+Math.imul(m,AA)|0,i=i+Math.imul(D,tA)|0,g=(g=g+Math.imul(D,iA)|0)+Math.imul(b,tA)|0,r=r+Math.imul(b,iA)|0,i=i+Math.imul(l,rA)|0,g=(g=g+Math.imul(l,nA)|0)+Math.imul(w,rA)|0,r=r+Math.imul(w,nA)|0,i=i+Math.imul(E,IA)|0,g=(g=g+Math.imul(E,oA)|0)+Math.imul(u,IA)|0,r=r+Math.imul(u,oA)|0,i=i+Math.imul(c,QA)|0,g=(g=g+Math.imul(c,CA)|0)+Math.imul(h,QA)|0,r=r+Math.imul(h,CA)|0;var yA=(o+(i=i+Math.imul(Q,cA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,hA)|0)+Math.imul(C,cA)|0))<<13)|0;o=((r=r+Math.imul(C,hA)|0)+(g>>>13)|0)+(yA>>>26)|0,yA&=67108863,i=Math.imul(H,j),g=(g=Math.imul(H,W))+Math.imul(R,j)|0,r=Math.imul(R,W),i=i+Math.imul(K,P)|0,g=(g=g+Math.imul(K,V)|0)+Math.imul(U,P)|0,r=r+Math.imul(U,V)|0,i=i+Math.imul(S,z)|0,g=(g=g+Math.imul(S,T)|0)+Math.imul(Y,z)|0,r=r+Math.imul(Y,T)|0,i=i+Math.imul(k,$)|0,g=(g=g+Math.imul(k,AA)|0)+Math.imul(F,$)|0,r=r+Math.imul(F,AA)|0,i=i+Math.imul(M,tA)|0,g=(g=g+Math.imul(M,iA)|0)+Math.imul(m,tA)|0,r=r+Math.imul(m,iA)|0,i=i+Math.imul(D,rA)|0,g=(g=g+Math.imul(D,nA)|0)+Math.imul(b,rA)|0,r=r+Math.imul(b,nA)|0,i=i+Math.imul(l,IA)|0,g=(g=g+Math.imul(l,oA)|0)+Math.imul(w,IA)|0,r=r+Math.imul(w,oA)|0,i=i+Math.imul(E,QA)|0,g=(g=g+Math.imul(E,CA)|0)+Math.imul(u,QA)|0,r=r+Math.imul(u,CA)|0;var MA=(o+(i=i+Math.imul(c,cA)|0)|0)+((8191&(g=(g=g+Math.imul(c,hA)|0)+Math.imul(h,cA)|0))<<13)|0;o=((r=r+Math.imul(h,hA)|0)+(g>>>13)|0)+(MA>>>26)|0,MA&=67108863,i=Math.imul(H,P),g=(g=Math.imul(H,V))+Math.imul(R,P)|0,r=Math.imul(R,V),i=i+Math.imul(K,z)|0,g=(g=g+Math.imul(K,T)|0)+Math.imul(U,z)|0,r=r+Math.imul(U,T)|0,i=i+Math.imul(S,$)|0,g=(g=g+Math.imul(S,AA)|0)+Math.imul(Y,$)|0,r=r+Math.imul(Y,AA)|0,i=i+Math.imul(k,tA)|0,g=(g=g+Math.imul(k,iA)|0)+Math.imul(F,tA)|0,r=r+Math.imul(F,iA)|0,i=i+Math.imul(M,rA)|0,g=(g=g+Math.imul(M,nA)|0)+Math.imul(m,rA)|0,r=r+Math.imul(m,nA)|0,i=i+Math.imul(D,IA)|0,g=(g=g+Math.imul(D,oA)|0)+Math.imul(b,IA)|0,r=r+Math.imul(b,oA)|0,i=i+Math.imul(l,QA)|0,g=(g=g+Math.imul(l,CA)|0)+Math.imul(w,QA)|0,r=r+Math.imul(w,CA)|0;var mA=(o+(i=i+Math.imul(E,cA)|0)|0)+((8191&(g=(g=g+Math.imul(E,hA)|0)+Math.imul(u,cA)|0))<<13)|0;o=((r=r+Math.imul(u,hA)|0)+(g>>>13)|0)+(mA>>>26)|0,mA&=67108863,i=Math.imul(H,z),g=(g=Math.imul(H,T))+Math.imul(R,z)|0,r=Math.imul(R,T),i=i+Math.imul(K,$)|0,g=(g=g+Math.imul(K,AA)|0)+Math.imul(U,$)|0,r=r+Math.imul(U,AA)|0,i=i+Math.imul(S,tA)|0,g=(g=g+Math.imul(S,iA)|0)+Math.imul(Y,tA)|0,r=r+Math.imul(Y,iA)|0,i=i+Math.imul(k,rA)|0,g=(g=g+Math.imul(k,nA)|0)+Math.imul(F,rA)|0,r=r+Math.imul(F,nA)|0,i=i+Math.imul(M,IA)|0,g=(g=g+Math.imul(M,oA)|0)+Math.imul(m,IA)|0,r=r+Math.imul(m,oA)|0,i=i+Math.imul(D,QA)|0,g=(g=g+Math.imul(D,CA)|0)+Math.imul(b,QA)|0,r=r+Math.imul(b,CA)|0;var GA=(o+(i=i+Math.imul(l,cA)|0)|0)+((8191&(g=(g=g+Math.imul(l,hA)|0)+Math.imul(w,cA)|0))<<13)|0;o=((r=r+Math.imul(w,hA)|0)+(g>>>13)|0)+(GA>>>26)|0,GA&=67108863,i=Math.imul(H,$),g=(g=Math.imul(H,AA))+Math.imul(R,$)|0,r=Math.imul(R,AA),i=i+Math.imul(K,tA)|0,g=(g=g+Math.imul(K,iA)|0)+Math.imul(U,tA)|0,r=r+Math.imul(U,iA)|0,i=i+Math.imul(S,rA)|0,g=(g=g+Math.imul(S,nA)|0)+Math.imul(Y,rA)|0,r=r+Math.imul(Y,nA)|0,i=i+Math.imul(k,IA)|0,g=(g=g+Math.imul(k,oA)|0)+Math.imul(F,IA)|0,r=r+Math.imul(F,oA)|0,i=i+Math.imul(M,QA)|0,g=(g=g+Math.imul(M,CA)|0)+Math.imul(m,QA)|0,r=r+Math.imul(m,CA)|0;var kA=(o+(i=i+Math.imul(D,cA)|0)|0)+((8191&(g=(g=g+Math.imul(D,hA)|0)+Math.imul(b,cA)|0))<<13)|0;o=((r=r+Math.imul(b,hA)|0)+(g>>>13)|0)+(kA>>>26)|0,kA&=67108863,i=Math.imul(H,tA),g=(g=Math.imul(H,iA))+Math.imul(R,tA)|0,r=Math.imul(R,iA),i=i+Math.imul(K,rA)|0,g=(g=g+Math.imul(K,nA)|0)+Math.imul(U,rA)|0,r=r+Math.imul(U,nA)|0,i=i+Math.imul(S,IA)|0,g=(g=g+Math.imul(S,oA)|0)+Math.imul(Y,IA)|0,r=r+Math.imul(Y,oA)|0,i=i+Math.imul(k,QA)|0,g=(g=g+Math.imul(k,CA)|0)+Math.imul(F,QA)|0,r=r+Math.imul(F,CA)|0;var FA=(o+(i=i+Math.imul(M,cA)|0)|0)+((8191&(g=(g=g+Math.imul(M,hA)|0)+Math.imul(m,cA)|0))<<13)|0;o=((r=r+Math.imul(m,hA)|0)+(g>>>13)|0)+(FA>>>26)|0,FA&=67108863,i=Math.imul(H,rA),g=(g=Math.imul(H,nA))+Math.imul(R,rA)|0,r=Math.imul(R,nA),i=i+Math.imul(K,IA)|0,g=(g=g+Math.imul(K,oA)|0)+Math.imul(U,IA)|0,r=r+Math.imul(U,oA)|0,i=i+Math.imul(S,QA)|0,g=(g=g+Math.imul(S,CA)|0)+Math.imul(Y,QA)|0,r=r+Math.imul(Y,CA)|0;var NA=(o+(i=i+Math.imul(k,cA)|0)|0)+((8191&(g=(g=g+Math.imul(k,hA)|0)+Math.imul(F,cA)|0))<<13)|0;o=((r=r+Math.imul(F,hA)|0)+(g>>>13)|0)+(NA>>>26)|0,NA&=67108863,i=Math.imul(H,IA),g=(g=Math.imul(H,oA))+Math.imul(R,IA)|0,r=Math.imul(R,oA),i=i+Math.imul(K,QA)|0,g=(g=g+Math.imul(K,CA)|0)+Math.imul(U,QA)|0,r=r+Math.imul(U,CA)|0;var SA=(o+(i=i+Math.imul(S,cA)|0)|0)+((8191&(g=(g=g+Math.imul(S,hA)|0)+Math.imul(Y,cA)|0))<<13)|0;o=((r=r+Math.imul(Y,hA)|0)+(g>>>13)|0)+(SA>>>26)|0,SA&=67108863,i=Math.imul(H,QA),g=(g=Math.imul(H,CA))+Math.imul(R,QA)|0,r=Math.imul(R,CA);var YA=(o+(i=i+Math.imul(K,cA)|0)|0)+((8191&(g=(g=g+Math.imul(K,hA)|0)+Math.imul(U,cA)|0))<<13)|0;o=((r=r+Math.imul(U,hA)|0)+(g>>>13)|0)+(YA>>>26)|0,YA&=67108863;var vA=(o+(i=Math.imul(H,cA))|0)+((8191&(g=(g=Math.imul(H,hA))+Math.imul(R,cA)|0))<<13)|0;return o=((r=Math.imul(R,hA))+(g>>>13)|0)+(vA>>>26)|0,vA&=67108863,I[0]=fA,I[1]=EA,I[2]=uA,I[3]=dA,I[4]=lA,I[5]=wA,I[6]=pA,I[7]=DA,I[8]=bA,I[9]=yA,I[10]=MA,I[11]=mA,I[12]=GA,I[13]=kA,I[14]=FA,I[15]=NA,I[16]=SA,I[17]=YA,I[18]=vA,0!==o&&(I[19]=o,t.length++),t};function c(A,e,t){return(new h).mulp(A,e,t)}function h(A,e){this.x=A,this.y=e}Math.imul||(s=C),r.prototype.mulTo=function(A,e){var t=this.length+A.length;return 10===this.length&&10===A.length?s(this,A,e):t<63?C(this,A,e):t<1024?function(A,e,t){t.negative=e.negative^A.negative,t.length=A.length+e.length;for(var i=0,g=0,r=0;r>>26)|0)>>>26,n&=67108863}t.words[r]=B,i=n,n=g}return 0!==i?t.words[r]=i:t.length--,t.strip()}(this,A,e):c(this,A,e)},h.prototype.makeRBT=function(A){for(var e=new Array(A),t=r.prototype._countBits(A)-1,i=0;i>=1;return i},h.prototype.permute=function(A,e,t,i,g,r){for(var n=0;n>>=1)g++;return 1<>>=13,t[2*n+1]=8191&r,r>>>=13;for(n=2*e;n>=26,e+=g/67108864|0,e+=r>>>26,this.words[t]=67108863&r}return 0!==e&&(this.words[t]=e,this.length++),this},r.prototype.muln=function(A){return this.clone().imuln(A)},r.prototype.sqr=function(){return this.mul(this)},r.prototype.isqr=function(){return this.imul(this.clone())},r.prototype.pow=function(A){var e=function(A){for(var e=new Array(A.bitLength()),t=0;t>>g}return e}(A);if(0===e.length)return new r(1);for(var t=this,i=0;i=0);var e,t=A%26,g=(A-t)/26,r=67108863>>>26-t<<26-t;if(0!==t){var n=0;for(e=0;e>>26-t}n&&(this.words[e]=n,this.length++)}if(0!==g){for(e=this.length-1;e>=0;e--)this.words[e+g]=this.words[e];for(e=0;e=0),g=e?(e-e%26)/26:0;var r=A%26,n=Math.min((A-r)/26,this.length),B=67108863^67108863>>>r<n)for(this.length-=n,o=0;o=0&&(0!==a||o>=g);o--){var Q=0|this.words[o];this.words[o]=a<<26-r|Q>>>r,a=Q&B}return I&&0!==a&&(I.words[I.length++]=a),0===this.length&&(this.words[0]=0,this.length=1),this.strip()},r.prototype.ishrn=function(A,e,t){return i(0===this.negative),this.iushrn(A,e,t)},r.prototype.shln=function(A){return this.clone().ishln(A)},r.prototype.ushln=function(A){return this.clone().iushln(A)},r.prototype.shrn=function(A){return this.clone().ishrn(A)},r.prototype.ushrn=function(A){return this.clone().iushrn(A)},r.prototype.testn=function(A){i("number"==typeof A&&A>=0);var e=A%26,t=(A-e)/26,g=1<=0);var e=A%26,t=(A-e)/26;if(i(0===this.negative,"imaskn works only with positive numbers"),this.length<=t)return this;if(0!==e&&t++,this.length=Math.min(t,this.length),0!==e){var g=67108863^67108863>>>e<=67108864;e++)this.words[e]-=67108864,e===this.length-1?this.words[e+1]=1:this.words[e+1]++;return this.length=Math.max(this.length,e+1),this},r.prototype.isubn=function(A){if(i("number"==typeof A),i(A<67108864),A<0)return this.iaddn(-A);if(0!==this.negative)return this.negative=0,this.iaddn(A),this.negative=1,this;if(this.words[0]-=A,1===this.length&&this.words[0]<0)this.words[0]=-this.words[0],this.negative=1;else for(var e=0;e>26)-(I/67108864|0),this.words[g+t]=67108863&r}for(;g>26,this.words[g+t]=67108863&r;if(0===B)return this.strip();for(i(-1===B),B=0,g=0;g>26,this.words[g]=67108863&r;return this.negative=1,this.strip()},r.prototype._wordDiv=function(A,e){var t=(this.length,A.length),i=this.clone(),g=A,n=0|g.words[g.length-1];0!==(t=26-this._countBits(n))&&(g=g.ushln(t),i.iushln(t),n=0|g.words[g.length-1]);var B,I=i.length-g.length;if("mod"!==e){(B=new r(null)).length=I+1,B.words=new Array(B.length);for(var o=0;o=0;Q--){var C=67108864*(0|i.words[g.length+Q])+(0|i.words[g.length+Q-1]);for(C=Math.min(C/n|0,67108863),i._ishlnsubmul(g,C,Q);0!==i.negative;)C--,i.negative=0,i._ishlnsubmul(g,1,Q),i.isZero()||(i.negative^=1);B&&(B.words[Q]=C)}return B&&B.strip(),i.strip(),"div"!==e&&0!==t&&i.iushrn(t),{div:B||null,mod:i}},r.prototype.divmod=function(A,e,t){return i(!A.isZero()),this.isZero()?{div:new r(0),mod:new r(0)}:0!==this.negative&&0===A.negative?(B=this.neg().divmod(A,e),"mod"!==e&&(g=B.div.neg()),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.iadd(A)),{div:g,mod:n}):0===this.negative&&0!==A.negative?(B=this.divmod(A.neg(),e),"mod"!==e&&(g=B.div.neg()),{div:g,mod:B.mod}):0!=(this.negative&A.negative)?(B=this.neg().divmod(A.neg(),e),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.isub(A)),{div:B.div,mod:n}):A.length>this.length||this.cmp(A)<0?{div:new r(0),mod:this}:1===A.length?"div"===e?{div:this.divn(A.words[0]),mod:null}:"mod"===e?{div:null,mod:new r(this.modn(A.words[0]))}:{div:this.divn(A.words[0]),mod:new r(this.modn(A.words[0]))}:this._wordDiv(A,e);var g,n,B},r.prototype.div=function(A){return this.divmod(A,"div",!1).div},r.prototype.mod=function(A){return this.divmod(A,"mod",!1).mod},r.prototype.umod=function(A){return this.divmod(A,"mod",!0).mod},r.prototype.divRound=function(A){var e=this.divmod(A);if(e.mod.isZero())return e.div;var t=0!==e.div.negative?e.mod.isub(A):e.mod,i=A.ushrn(1),g=A.andln(1),r=t.cmp(i);return r<0||1===g&&0===r?e.div:0!==e.div.negative?e.div.isubn(1):e.div.iaddn(1)},r.prototype.modn=function(A){i(A<=67108863);for(var e=(1<<26)%A,t=0,g=this.length-1;g>=0;g--)t=(e*t+(0|this.words[g]))%A;return t},r.prototype.idivn=function(A){i(A<=67108863);for(var e=0,t=this.length-1;t>=0;t--){var g=(0|this.words[t])+67108864*e;this.words[t]=g/A|0,e=g%A}return this.strip()},r.prototype.divn=function(A){return this.clone().idivn(A)},r.prototype.egcd=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g=new r(1),n=new r(0),B=new r(0),I=new r(1),o=0;e.isEven()&&t.isEven();)e.iushrn(1),t.iushrn(1),++o;for(var a=t.clone(),Q=e.clone();!e.isZero();){for(var C=0,s=1;0==(e.words[0]&s)&&C<26;++C,s<<=1);if(C>0)for(e.iushrn(C);C-- >0;)(g.isOdd()||n.isOdd())&&(g.iadd(a),n.isub(Q)),g.iushrn(1),n.iushrn(1);for(var c=0,h=1;0==(t.words[0]&h)&&c<26;++c,h<<=1);if(c>0)for(t.iushrn(c);c-- >0;)(B.isOdd()||I.isOdd())&&(B.iadd(a),I.isub(Q)),B.iushrn(1),I.iushrn(1);e.cmp(t)>=0?(e.isub(t),g.isub(B),n.isub(I)):(t.isub(e),B.isub(g),I.isub(n))}return{a:B,b:I,gcd:t.iushln(o)}},r.prototype._invmp=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g,n=new r(1),B=new r(0),I=t.clone();e.cmpn(1)>0&&t.cmpn(1)>0;){for(var o=0,a=1;0==(e.words[0]&a)&&o<26;++o,a<<=1);if(o>0)for(e.iushrn(o);o-- >0;)n.isOdd()&&n.iadd(I),n.iushrn(1);for(var Q=0,C=1;0==(t.words[0]&C)&&Q<26;++Q,C<<=1);if(Q>0)for(t.iushrn(Q);Q-- >0;)B.isOdd()&&B.iadd(I),B.iushrn(1);e.cmp(t)>=0?(e.isub(t),n.isub(B)):(t.isub(e),B.isub(n))}return(g=0===e.cmpn(1)?n:B).cmpn(0)<0&&g.iadd(A),g},r.prototype.gcd=function(A){if(this.isZero())return A.abs();if(A.isZero())return this.abs();var e=this.clone(),t=A.clone();e.negative=0,t.negative=0;for(var i=0;e.isEven()&&t.isEven();i++)e.iushrn(1),t.iushrn(1);for(;;){for(;e.isEven();)e.iushrn(1);for(;t.isEven();)t.iushrn(1);var g=e.cmp(t);if(g<0){var r=e;e=t,t=r}else if(0===g||0===t.cmpn(1))break;e.isub(t)}return t.iushln(i)},r.prototype.invm=function(A){return this.egcd(A).a.umod(A)},r.prototype.isEven=function(){return 0==(1&this.words[0])},r.prototype.isOdd=function(){return 1==(1&this.words[0])},r.prototype.andln=function(A){return this.words[0]&A},r.prototype.bincn=function(A){i("number"==typeof A);var e=A%26,t=(A-e)/26,g=1<>>26,B&=67108863,this.words[n]=B}return 0!==r&&(this.words[n]=r,this.length++),this},r.prototype.isZero=function(){return 1===this.length&&0===this.words[0]},r.prototype.cmpn=function(A){var e,t=A<0;if(0!==this.negative&&!t)return-1;if(0===this.negative&&t)return 1;if(this.strip(),this.length>1)e=1;else{t&&(A=-A),i(A<=67108863,"Number is too big");var g=0|this.words[0];e=g===A?0:gA.length)return 1;if(this.length=0;t--){var i=0|this.words[t],g=0|A.words[t];if(i!==g){ig&&(e=1);break}}return e},r.prototype.gtn=function(A){return 1===this.cmpn(A)},r.prototype.gt=function(A){return 1===this.cmp(A)},r.prototype.gten=function(A){return this.cmpn(A)>=0},r.prototype.gte=function(A){return this.cmp(A)>=0},r.prototype.ltn=function(A){return-1===this.cmpn(A)},r.prototype.lt=function(A){return-1===this.cmp(A)},r.prototype.lten=function(A){return this.cmpn(A)<=0},r.prototype.lte=function(A){return this.cmp(A)<=0},r.prototype.eqn=function(A){return 0===this.cmpn(A)},r.prototype.eq=function(A){return 0===this.cmp(A)},r.red=function(A){return new p(A)},r.prototype.toRed=function(A){return i(!this.red,"Already a number in reduction context"),i(0===this.negative,"red works only with positives"),A.convertTo(this)._forceRed(A)},r.prototype.fromRed=function(){return i(this.red,"fromRed works only with numbers in reduction context"),this.red.convertFrom(this)},r.prototype._forceRed=function(A){return this.red=A,this},r.prototype.forceRed=function(A){return i(!this.red,"Already a number in reduction context"),this._forceRed(A)},r.prototype.redAdd=function(A){return i(this.red,"redAdd works only with red numbers"),this.red.add(this,A)},r.prototype.redIAdd=function(A){return i(this.red,"redIAdd works only with red numbers"),this.red.iadd(this,A)},r.prototype.redSub=function(A){return i(this.red,"redSub works only with red numbers"),this.red.sub(this,A)},r.prototype.redISub=function(A){return i(this.red,"redISub works only with red numbers"),this.red.isub(this,A)},r.prototype.redShl=function(A){return i(this.red,"redShl works only with red numbers"),this.red.shl(this,A)},r.prototype.redMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.mul(this,A)},r.prototype.redIMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.imul(this,A)},r.prototype.redSqr=function(){return i(this.red,"redSqr works only with red numbers"),this.red._verify1(this),this.red.sqr(this)},r.prototype.redISqr=function(){return i(this.red,"redISqr works only with red numbers"),this.red._verify1(this),this.red.isqr(this)},r.prototype.redSqrt=function(){return i(this.red,"redSqrt works only with red numbers"),this.red._verify1(this),this.red.sqrt(this)},r.prototype.redInvm=function(){return i(this.red,"redInvm works only with red numbers"),this.red._verify1(this),this.red.invm(this)},r.prototype.redNeg=function(){return i(this.red,"redNeg works only with red numbers"),this.red._verify1(this),this.red.neg(this)},r.prototype.redPow=function(A){return i(this.red&&!A.red,"redPow(normalNum)"),this.red._verify1(this),this.red.pow(this,A)};var f={k256:null,p224:null,p192:null,p25519:null};function E(A,e){this.name=A,this.p=new r(e,16),this.n=this.p.bitLength(),this.k=new r(1).iushln(this.n).isub(this.p),this.tmp=this._tmp()}function u(){E.call(this,"k256","ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f")}function d(){E.call(this,"p224","ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001")}function l(){E.call(this,"p192","ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff")}function w(){E.call(this,"25519","7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed")}function p(A){if("string"==typeof A){var e=r._prime(A);this.m=e.p,this.prime=e}else i(A.gtn(1),"modulus must be greater than 1"),this.m=A,this.prime=null}function D(A){p.call(this,A),this.shift=this.m.bitLength(),this.shift%26!=0&&(this.shift+=26-this.shift%26),this.r=new r(1).iushln(this.shift),this.r2=this.imod(this.r.sqr()),this.rinv=this.r._invmp(this.m),this.minv=this.rinv.mul(this.r).isubn(1).div(this.m),this.minv=this.minv.umod(this.r),this.minv=this.r.sub(this.minv)}E.prototype._tmp=function(){var A=new r(null);return A.words=new Array(Math.ceil(this.n/13)),A},E.prototype.ireduce=function(A){var e,t=A;do{this.split(t,this.tmp),e=(t=(t=this.imulK(t)).iadd(this.tmp)).bitLength()}while(e>this.n);var i=e0?t.isub(this.p):void 0!==t.strip?t.strip():t._strip(),t},E.prototype.split=function(A,e){A.iushrn(this.n,0,e)},E.prototype.imulK=function(A){return A.imul(this.k)},g(u,E),u.prototype.split=function(A,e){for(var t=Math.min(A.length,9),i=0;i>>22,g=r}g>>>=22,A.words[i-10]=g,0===g&&A.length>10?A.length-=10:A.length-=9},u.prototype.imulK=function(A){A.words[A.length]=0,A.words[A.length+1]=0,A.length+=2;for(var e=0,t=0;t>>=26,A.words[t]=g,e=i}return 0!==e&&(A.words[A.length++]=e),A},r._prime=function(A){if(f[A])return f[A];var e;if("k256"===A)e=new u;else if("p224"===A)e=new d;else if("p192"===A)e=new l;else{if("p25519"!==A)throw new Error("Unknown prime "+A);e=new w}return f[A]=e,e},p.prototype._verify1=function(A){i(0===A.negative,"red works only with positives"),i(A.red,"red works only with red numbers")},p.prototype._verify2=function(A,e){i(0==(A.negative|e.negative),"red works only with positives"),i(A.red&&A.red===e.red,"red works only with red numbers")},p.prototype.imod=function(A){return this.prime?this.prime.ireduce(A)._forceRed(this):A.umod(this.m)._forceRed(this)},p.prototype.neg=function(A){return A.isZero()?A.clone():this.m.sub(A)._forceRed(this)},p.prototype.add=function(A,e){this._verify2(A,e);var t=A.add(e);return t.cmp(this.m)>=0&&t.isub(this.m),t._forceRed(this)},p.prototype.iadd=function(A,e){this._verify2(A,e);var t=A.iadd(e);return t.cmp(this.m)>=0&&t.isub(this.m),t},p.prototype.sub=function(A,e){this._verify2(A,e);var t=A.sub(e);return t.cmpn(0)<0&&t.iadd(this.m),t._forceRed(this)},p.prototype.isub=function(A,e){this._verify2(A,e);var t=A.isub(e);return t.cmpn(0)<0&&t.iadd(this.m),t},p.prototype.shl=function(A,e){return this._verify1(A),this.imod(A.ushln(e))},p.prototype.imul=function(A,e){return this._verify2(A,e),this.imod(A.imul(e))},p.prototype.mul=function(A,e){return this._verify2(A,e),this.imod(A.mul(e))},p.prototype.isqr=function(A){return this.imul(A,A.clone())},p.prototype.sqr=function(A){return this.mul(A,A)},p.prototype.sqrt=function(A){if(A.isZero())return A.clone();var e=this.m.andln(3);if(i(e%2==1),3===e){var t=this.m.add(new r(1)).iushrn(2);return this.pow(A,t)}for(var g=this.m.subn(1),n=0;!g.isZero()&&0===g.andln(1);)n++,g.iushrn(1);i(!g.isZero());var B=new r(1).toRed(this),I=B.redNeg(),o=this.m.subn(1).iushrn(1),a=this.m.bitLength();for(a=new r(2*a*a).toRed(this);0!==this.pow(a,o).cmp(I);)a.redIAdd(I);for(var Q=this.pow(a,g),C=this.pow(A,g.addn(1).iushrn(1)),s=this.pow(A,g),c=n;0!==s.cmp(B);){for(var h=s,f=0;0!==h.cmp(B);f++)h=h.redSqr();i(f=0;i--){for(var o=e.words[i],a=I-1;a>=0;a--){var Q=o>>a&1;g!==t[0]&&(g=this.sqr(g)),0!==Q||0!==n?(n<<=1,n|=Q,(4===++B||0===i&&0===a)&&(g=this.mul(g,t[n]),B=0,n=0)):B=0}I=26}return g},p.prototype.convertTo=function(A){var e=A.umod(this.m);return e===A?e.clone():e},p.prototype.convertFrom=function(A){var e=A.clone();return e.red=null,e},r.mont=function(A){return new D(A)},g(D,p),D.prototype.convertTo=function(A){return this.imod(A.ushln(this.shift))},D.prototype.convertFrom=function(A){var e=this.imod(A.mul(this.rinv));return e.red=null,e},D.prototype.imul=function(A,e){if(A.isZero()||e.isZero())return A.words[0]=0,A.length=1,A;var t=A.imul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),r=g;return g.cmp(this.m)>=0?r=g.isub(this.m):g.cmpn(0)<0&&(r=g.iadd(this.m)),r._forceRed(this)},D.prototype.mul=function(A,e){if(A.isZero()||e.isZero())return new r(0)._forceRed(this);var t=A.mul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),n=g;return g.cmp(this.m)>=0?n=g.isub(this.m):g.cmpn(0)<0&&(n=g.iadd(this.m)),n._forceRed(this)},D.prototype.invm=function(A){return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this)}}(void 0===e||e,this)},{buffer:19}],16:[function(A,e,t){"use strict";t.byteLength=function(A){var e=o(A),t=e[0],i=e[1];return 3*(t+i)/4-i},t.toByteArray=function(A){var e,t,i=o(A),n=i[0],B=i[1],I=new r(function(A,e,t){return 3*(e+t)/4-t}(0,n,B)),a=0,Q=B>0?n-4:n;for(t=0;t>16&255,I[a++]=e>>8&255,I[a++]=255&e;2===B&&(e=g[A.charCodeAt(t)]<<2|g[A.charCodeAt(t+1)]>>4,I[a++]=255&e);1===B&&(e=g[A.charCodeAt(t)]<<10|g[A.charCodeAt(t+1)]<<4|g[A.charCodeAt(t+2)]>>2,I[a++]=e>>8&255,I[a++]=255&e);return I},t.fromByteArray=function(A){for(var e,t=A.length,g=t%3,r=[],n=0,B=t-g;nB?B:n+16383));1===g?(e=A[t-1],r.push(i[e>>2]+i[e<<4&63]+"==")):2===g&&(e=(A[t-2]<<8)+A[t-1],r.push(i[e>>10]+i[e>>4&63]+i[e<<2&63]+"="));return r.join("")};for(var i=[],g=[],r="undefined"!=typeof Uint8Array?Uint8Array:Array,n="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/",B=0,I=n.length;B0)throw new Error("Invalid string. Length must be a multiple of 4");var t=A.indexOf("=");return-1===t&&(t=e),[t,t===e?0:4-t%4]}function a(A,e,t){for(var g,r,n=[],B=e;B>18&63]+i[r>>12&63]+i[r>>6&63]+i[63&r]);return n.join("")}g["-".charCodeAt(0)]=62,g["_".charCodeAt(0)]=63},{}],17:[function(A,e,t){!function(e,t){"use strict";function i(A,e){if(!A)throw new Error(e||"Assertion failed")}function g(A,e){A.super_=e;var t=function(){};t.prototype=e.prototype,A.prototype=new t,A.prototype.constructor=A}function r(A,e,t){if(r.isBN(A))return A;this.negative=0,this.words=null,this.length=0,this.red=null,null!==A&&("le"!==e&&"be"!==e||(t=e,e=10),this._init(A||0,e||10,t||"be"))}var n;"object"==typeof e?e.exports=r:t.BN=r,r.BN=r,r.wordSize=26;try{n=A("buffer").Buffer}catch(A){}function B(A,e,t){for(var g=0,r=Math.min(A.length,t),n=0,B=e;B=49&&o<=54?o-49+10:o>=17&&o<=22?o-17+10:o,n|=I}return i(!(240&n),"Invalid character in "+A),g}function I(A,e,t,g){for(var r=0,n=0,B=Math.min(A.length,t),I=e;I=49?o-49+10:o>=17?o-17+10:o,i(o>=0&&n0?A:e},r.min=function(A,e){return A.cmp(e)<0?A:e},r.prototype._init=function(A,e,t){if("number"==typeof A)return this._initNumber(A,e,t);if("object"==typeof A)return this._initArray(A,e,t);"hex"===e&&(e=16),i(e===(0|e)&&e>=2&&e<=36);var g=0;"-"===(A=A.toString().replace(/\s+/g,""))[0]&&g++,16===e?this._parseHex(A,g):this._parseBase(A,e,g),"-"===A[0]&&(this.negative=1),this._strip(),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initNumber=function(A,e,t){A<0&&(this.negative=1,A=-A),A<67108864?(this.words=[67108863&A],this.length=1):A<4503599627370496?(this.words=[67108863&A,A/67108864&67108863],this.length=2):(i(A<9007199254740992),this.words=[67108863&A,A/67108864&67108863,1],this.length=3),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initArray=function(A,e,t){if(i("number"==typeof A.length),A.length<=0)return this.words=[0],this.length=1,this;this.length=Math.ceil(A.length/3),this.words=new Array(this.length);for(var g=0;g=0;g-=3)n=A[g]|A[g-1]<<8|A[g-2]<<16,this.words[r]|=n<>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);else if("le"===t)for(g=0,r=0;g>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);return this._strip()},r.prototype._parseHex=function(A,e){this.length=Math.ceil((A.length-e)/6),this.words=new Array(this.length);for(var t=0;t=e;t-=6)g=B(A,t,t+6),this.words[i]|=g<>>26-r&4194303,(r+=24)>=26&&(r-=26,i++);t+6!==e&&(g=B(A,e,t+6),this.words[i]|=g<>>26-r&4194303),this._strip()},r.prototype._parseBase=function(A,e,t){this.words=[0],this.length=1;for(var i=0,g=1;g<=67108863;g*=e)i++;i--,g=g/e|0;for(var r=A.length-t,n=r%i,B=Math.min(r,r-n)+t,o=0,a=t;a1&&0===this.words[this.length-1];)this.length--;return this._normSign()},r.prototype._normSign=function(){return 1===this.length&&0===this.words[0]&&(this.negative=0),this},"undefined"!=typeof Symbol&&"function"==typeof Symbol.for)try{r.prototype[Symbol.for("nodejs.util.inspect.custom")]=a}catch(A){r.prototype.inspect=a}else r.prototype.inspect=a;function a(){return(this.red?""}var Q=["","0","00","000","0000","00000","000000","0000000","00000000","000000000","0000000000","00000000000","000000000000","0000000000000","00000000000000","000000000000000","0000000000000000","00000000000000000","000000000000000000","0000000000000000000","00000000000000000000","000000000000000000000","0000000000000000000000","00000000000000000000000","000000000000000000000000","0000000000000000000000000"],C=[0,0,25,16,12,11,10,9,8,8,7,7,7,7,6,6,6,6,6,6,6,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5],s=[0,0,33554432,43046721,16777216,48828125,60466176,40353607,16777216,43046721,1e7,19487171,35831808,62748517,7529536,11390625,16777216,24137569,34012224,47045881,64e6,4084101,5153632,6436343,7962624,9765625,11881376,14348907,17210368,20511149,243e5,28629151,33554432,39135393,45435424,52521875,60466176];r.prototype.toString=function(A,e){var t;if(A=A||10,e=0|e||1,16===A||"hex"===A){t="";for(var g=0,r=0,n=0;n>>24-g&16777215)||n!==this.length-1?Q[6-I.length]+I+t:I+t,(g+=2)>=26&&(g-=26,n--)}for(0!==r&&(t=r.toString(16)+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}if(A===(0|A)&&A>=2&&A<=36){var o=C[A],a=s[A];t="";var c=this.clone();for(c.negative=0;!c.isZero();){var h=c.modrn(a).toString(A);t=(c=c.idivn(a)).isZero()?h+t:Q[o-h.length]+h+t}for(this.isZero()&&(t="0"+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}i(!1,"Base should be between 2 and 36")},r.prototype.toNumber=function(){var A=this.words[0];return 2===this.length?A+=67108864*this.words[1]:3===this.length&&1===this.words[2]?A+=4503599627370496+67108864*this.words[1]:this.length>2&&i(!1,"Number can only safely store up to 53 bits"),0!==this.negative?-A:A},r.prototype.toJSON=function(){return this.toString(16,2)},n&&(r.prototype.toBuffer=function(A,e){return this.toArrayLike(n,A,e)}),r.prototype.toArray=function(A,e){return this.toArrayLike(Array,A,e)};function c(A,e,t){t.negative=e.negative^A.negative;var i=A.length+e.length|0;t.length=i,i=i-1|0;var g=0|A.words[0],r=0|e.words[0],n=g*r,B=67108863&n,I=n/67108864|0;t.words[0]=B;for(var o=1;o>>26,Q=67108863&I,C=Math.min(o,e.length-1),s=Math.max(0,o-A.length+1);s<=C;s++){var c=o-s|0;a+=(n=(g=0|A.words[c])*(r=0|e.words[s])+Q)/67108864|0,Q=67108863&n}t.words[o]=0|Q,I=0|a}return 0!==I?t.words[o]=0|I:t.length--,t._strip()}r.prototype.toArrayLike=function(A,e,t){this._strip();var g=this.byteLength(),r=t||Math.max(1,g);i(g<=r,"byte array longer than desired length"),i(r>0,"Requested array length <= 0");var n=function(A,e){return A.allocUnsafe?A.allocUnsafe(e):new A(e)}(A,r);return this["_toArrayLike"+("le"===e?"LE":"BE")](n,g),n},r.prototype._toArrayLikeLE=function(A,e){for(var t=0,i=0,g=0,r=0;g>8&255),t>16&255),6===r?(t>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t=0&&(A[t--]=n>>8&255),t>=0&&(A[t--]=n>>16&255),6===r?(t>=0&&(A[t--]=n>>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t>=0)for(A[t--]=i;t>=0;)A[t--]=0},Math.clz32?r.prototype._countBits=function(A){return 32-Math.clz32(A)}:r.prototype._countBits=function(A){var e=A,t=0;return e>=4096&&(t+=13,e>>>=13),e>=64&&(t+=7,e>>>=7),e>=8&&(t+=4,e>>>=4),e>=2&&(t+=2,e>>>=2),t+e},r.prototype._zeroBits=function(A){if(0===A)return 26;var e=A,t=0;return 0==(8191&e)&&(t+=13,e>>>=13),0==(127&e)&&(t+=7,e>>>=7),0==(15&e)&&(t+=4,e>>>=4),0==(3&e)&&(t+=2,e>>>=2),0==(1&e)&&t++,t},r.prototype.bitLength=function(){var A=this.words[this.length-1],e=this._countBits(A);return 26*(this.length-1)+e},r.prototype.zeroBits=function(){if(this.isZero())return 0;for(var A=0,e=0;eA.length?this.clone().ior(A):A.clone().ior(this)},r.prototype.uor=function(A){return this.length>A.length?this.clone().iuor(A):A.clone().iuor(this)},r.prototype.iuand=function(A){var e;e=this.length>A.length?A:this;for(var t=0;tA.length?this.clone().iand(A):A.clone().iand(this)},r.prototype.uand=function(A){return this.length>A.length?this.clone().iuand(A):A.clone().iuand(this)},r.prototype.iuxor=function(A){var e,t;this.length>A.length?(e=this,t=A):(e=A,t=this);for(var i=0;iA.length?this.clone().ixor(A):A.clone().ixor(this)},r.prototype.uxor=function(A){return this.length>A.length?this.clone().iuxor(A):A.clone().iuxor(this)},r.prototype.inotn=function(A){i("number"==typeof A&&A>=0);var e=0|Math.ceil(A/26),t=A%26;this._expand(e),t>0&&e--;for(var g=0;g0&&(this.words[g]=~this.words[g]&67108863>>26-t),this._strip()},r.prototype.notn=function(A){return this.clone().inotn(A)},r.prototype.setn=function(A,e){i("number"==typeof A&&A>=0);var t=A/26|0,g=A%26;return this._expand(t+1),this.words[t]=e?this.words[t]|1<A.length?(t=this,i=A):(t=A,i=this);for(var g=0,r=0;r>>26;for(;0!==g&&r>>26;if(this.length=t.length,0!==g)this.words[this.length]=g,this.length++;else if(t!==this)for(;rA.length?this.clone().iadd(A):A.clone().iadd(this)},r.prototype.isub=function(A){if(0!==A.negative){A.negative=0;var e=this.iadd(A);return A.negative=1,e._normSign()}if(0!==this.negative)return this.negative=0,this.iadd(A),this.negative=1,this._normSign();var t,i,g=this.cmp(A);if(0===g)return this.negative=0,this.length=1,this.words[0]=0,this;g>0?(t=this,i=A):(t=A,i=this);for(var r=0,n=0;n>26,this.words[n]=67108863&e;for(;0!==r&&n>26,this.words[n]=67108863&e;if(0===r&&n>>13,s=0|n[1],c=8191&s,h=s>>>13,f=0|n[2],E=8191&f,u=f>>>13,d=0|n[3],l=8191&d,w=d>>>13,p=0|n[4],D=8191&p,b=p>>>13,y=0|n[5],M=8191&y,m=y>>>13,G=0|n[6],k=8191&G,F=G>>>13,N=0|n[7],S=8191&N,Y=N>>>13,v=0|n[8],K=8191&v,U=v>>>13,J=0|n[9],H=8191&J,R=J>>>13,q=0|B[0],L=8191&q,x=q>>>13,Z=0|B[1],j=8191&Z,W=Z>>>13,O=0|B[2],P=8191&O,V=O>>>13,X=0|B[3],z=8191&X,T=X>>>13,_=0|B[4],$=8191&_,AA=_>>>13,eA=0|B[5],tA=8191&eA,iA=eA>>>13,gA=0|B[6],rA=8191&gA,nA=gA>>>13,BA=0|B[7],IA=8191&BA,oA=BA>>>13,aA=0|B[8],QA=8191&aA,CA=aA>>>13,sA=0|B[9],cA=8191&sA,hA=sA>>>13;t.negative=A.negative^e.negative,t.length=19;var fA=(o+(i=Math.imul(Q,L))|0)+((8191&(g=(g=Math.imul(Q,x))+Math.imul(C,L)|0))<<13)|0;o=((r=Math.imul(C,x))+(g>>>13)|0)+(fA>>>26)|0,fA&=67108863,i=Math.imul(c,L),g=(g=Math.imul(c,x))+Math.imul(h,L)|0,r=Math.imul(h,x);var EA=(o+(i=i+Math.imul(Q,j)|0)|0)+((8191&(g=(g=g+Math.imul(Q,W)|0)+Math.imul(C,j)|0))<<13)|0;o=((r=r+Math.imul(C,W)|0)+(g>>>13)|0)+(EA>>>26)|0,EA&=67108863,i=Math.imul(E,L),g=(g=Math.imul(E,x))+Math.imul(u,L)|0,r=Math.imul(u,x),i=i+Math.imul(c,j)|0,g=(g=g+Math.imul(c,W)|0)+Math.imul(h,j)|0,r=r+Math.imul(h,W)|0;var uA=(o+(i=i+Math.imul(Q,P)|0)|0)+((8191&(g=(g=g+Math.imul(Q,V)|0)+Math.imul(C,P)|0))<<13)|0;o=((r=r+Math.imul(C,V)|0)+(g>>>13)|0)+(uA>>>26)|0,uA&=67108863,i=Math.imul(l,L),g=(g=Math.imul(l,x))+Math.imul(w,L)|0,r=Math.imul(w,x),i=i+Math.imul(E,j)|0,g=(g=g+Math.imul(E,W)|0)+Math.imul(u,j)|0,r=r+Math.imul(u,W)|0,i=i+Math.imul(c,P)|0,g=(g=g+Math.imul(c,V)|0)+Math.imul(h,P)|0,r=r+Math.imul(h,V)|0;var dA=(o+(i=i+Math.imul(Q,z)|0)|0)+((8191&(g=(g=g+Math.imul(Q,T)|0)+Math.imul(C,z)|0))<<13)|0;o=((r=r+Math.imul(C,T)|0)+(g>>>13)|0)+(dA>>>26)|0,dA&=67108863,i=Math.imul(D,L),g=(g=Math.imul(D,x))+Math.imul(b,L)|0,r=Math.imul(b,x),i=i+Math.imul(l,j)|0,g=(g=g+Math.imul(l,W)|0)+Math.imul(w,j)|0,r=r+Math.imul(w,W)|0,i=i+Math.imul(E,P)|0,g=(g=g+Math.imul(E,V)|0)+Math.imul(u,P)|0,r=r+Math.imul(u,V)|0,i=i+Math.imul(c,z)|0,g=(g=g+Math.imul(c,T)|0)+Math.imul(h,z)|0,r=r+Math.imul(h,T)|0;var lA=(o+(i=i+Math.imul(Q,$)|0)|0)+((8191&(g=(g=g+Math.imul(Q,AA)|0)+Math.imul(C,$)|0))<<13)|0;o=((r=r+Math.imul(C,AA)|0)+(g>>>13)|0)+(lA>>>26)|0,lA&=67108863,i=Math.imul(M,L),g=(g=Math.imul(M,x))+Math.imul(m,L)|0,r=Math.imul(m,x),i=i+Math.imul(D,j)|0,g=(g=g+Math.imul(D,W)|0)+Math.imul(b,j)|0,r=r+Math.imul(b,W)|0,i=i+Math.imul(l,P)|0,g=(g=g+Math.imul(l,V)|0)+Math.imul(w,P)|0,r=r+Math.imul(w,V)|0,i=i+Math.imul(E,z)|0,g=(g=g+Math.imul(E,T)|0)+Math.imul(u,z)|0,r=r+Math.imul(u,T)|0,i=i+Math.imul(c,$)|0,g=(g=g+Math.imul(c,AA)|0)+Math.imul(h,$)|0,r=r+Math.imul(h,AA)|0;var wA=(o+(i=i+Math.imul(Q,tA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,iA)|0)+Math.imul(C,tA)|0))<<13)|0;o=((r=r+Math.imul(C,iA)|0)+(g>>>13)|0)+(wA>>>26)|0,wA&=67108863,i=Math.imul(k,L),g=(g=Math.imul(k,x))+Math.imul(F,L)|0,r=Math.imul(F,x),i=i+Math.imul(M,j)|0,g=(g=g+Math.imul(M,W)|0)+Math.imul(m,j)|0,r=r+Math.imul(m,W)|0,i=i+Math.imul(D,P)|0,g=(g=g+Math.imul(D,V)|0)+Math.imul(b,P)|0,r=r+Math.imul(b,V)|0,i=i+Math.imul(l,z)|0,g=(g=g+Math.imul(l,T)|0)+Math.imul(w,z)|0,r=r+Math.imul(w,T)|0,i=i+Math.imul(E,$)|0,g=(g=g+Math.imul(E,AA)|0)+Math.imul(u,$)|0,r=r+Math.imul(u,AA)|0,i=i+Math.imul(c,tA)|0,g=(g=g+Math.imul(c,iA)|0)+Math.imul(h,tA)|0,r=r+Math.imul(h,iA)|0;var pA=(o+(i=i+Math.imul(Q,rA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,nA)|0)+Math.imul(C,rA)|0))<<13)|0;o=((r=r+Math.imul(C,nA)|0)+(g>>>13)|0)+(pA>>>26)|0,pA&=67108863,i=Math.imul(S,L),g=(g=Math.imul(S,x))+Math.imul(Y,L)|0,r=Math.imul(Y,x),i=i+Math.imul(k,j)|0,g=(g=g+Math.imul(k,W)|0)+Math.imul(F,j)|0,r=r+Math.imul(F,W)|0,i=i+Math.imul(M,P)|0,g=(g=g+Math.imul(M,V)|0)+Math.imul(m,P)|0,r=r+Math.imul(m,V)|0,i=i+Math.imul(D,z)|0,g=(g=g+Math.imul(D,T)|0)+Math.imul(b,z)|0,r=r+Math.imul(b,T)|0,i=i+Math.imul(l,$)|0,g=(g=g+Math.imul(l,AA)|0)+Math.imul(w,$)|0,r=r+Math.imul(w,AA)|0,i=i+Math.imul(E,tA)|0,g=(g=g+Math.imul(E,iA)|0)+Math.imul(u,tA)|0,r=r+Math.imul(u,iA)|0,i=i+Math.imul(c,rA)|0,g=(g=g+Math.imul(c,nA)|0)+Math.imul(h,rA)|0,r=r+Math.imul(h,nA)|0;var DA=(o+(i=i+Math.imul(Q,IA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,oA)|0)+Math.imul(C,IA)|0))<<13)|0;o=((r=r+Math.imul(C,oA)|0)+(g>>>13)|0)+(DA>>>26)|0,DA&=67108863,i=Math.imul(K,L),g=(g=Math.imul(K,x))+Math.imul(U,L)|0,r=Math.imul(U,x),i=i+Math.imul(S,j)|0,g=(g=g+Math.imul(S,W)|0)+Math.imul(Y,j)|0,r=r+Math.imul(Y,W)|0,i=i+Math.imul(k,P)|0,g=(g=g+Math.imul(k,V)|0)+Math.imul(F,P)|0,r=r+Math.imul(F,V)|0,i=i+Math.imul(M,z)|0,g=(g=g+Math.imul(M,T)|0)+Math.imul(m,z)|0,r=r+Math.imul(m,T)|0,i=i+Math.imul(D,$)|0,g=(g=g+Math.imul(D,AA)|0)+Math.imul(b,$)|0,r=r+Math.imul(b,AA)|0,i=i+Math.imul(l,tA)|0,g=(g=g+Math.imul(l,iA)|0)+Math.imul(w,tA)|0,r=r+Math.imul(w,iA)|0,i=i+Math.imul(E,rA)|0,g=(g=g+Math.imul(E,nA)|0)+Math.imul(u,rA)|0,r=r+Math.imul(u,nA)|0,i=i+Math.imul(c,IA)|0,g=(g=g+Math.imul(c,oA)|0)+Math.imul(h,IA)|0,r=r+Math.imul(h,oA)|0;var bA=(o+(i=i+Math.imul(Q,QA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,CA)|0)+Math.imul(C,QA)|0))<<13)|0;o=((r=r+Math.imul(C,CA)|0)+(g>>>13)|0)+(bA>>>26)|0,bA&=67108863,i=Math.imul(H,L),g=(g=Math.imul(H,x))+Math.imul(R,L)|0,r=Math.imul(R,x),i=i+Math.imul(K,j)|0,g=(g=g+Math.imul(K,W)|0)+Math.imul(U,j)|0,r=r+Math.imul(U,W)|0,i=i+Math.imul(S,P)|0,g=(g=g+Math.imul(S,V)|0)+Math.imul(Y,P)|0,r=r+Math.imul(Y,V)|0,i=i+Math.imul(k,z)|0,g=(g=g+Math.imul(k,T)|0)+Math.imul(F,z)|0,r=r+Math.imul(F,T)|0,i=i+Math.imul(M,$)|0,g=(g=g+Math.imul(M,AA)|0)+Math.imul(m,$)|0,r=r+Math.imul(m,AA)|0,i=i+Math.imul(D,tA)|0,g=(g=g+Math.imul(D,iA)|0)+Math.imul(b,tA)|0,r=r+Math.imul(b,iA)|0,i=i+Math.imul(l,rA)|0,g=(g=g+Math.imul(l,nA)|0)+Math.imul(w,rA)|0,r=r+Math.imul(w,nA)|0,i=i+Math.imul(E,IA)|0,g=(g=g+Math.imul(E,oA)|0)+Math.imul(u,IA)|0,r=r+Math.imul(u,oA)|0,i=i+Math.imul(c,QA)|0,g=(g=g+Math.imul(c,CA)|0)+Math.imul(h,QA)|0,r=r+Math.imul(h,CA)|0;var yA=(o+(i=i+Math.imul(Q,cA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,hA)|0)+Math.imul(C,cA)|0))<<13)|0;o=((r=r+Math.imul(C,hA)|0)+(g>>>13)|0)+(yA>>>26)|0,yA&=67108863,i=Math.imul(H,j),g=(g=Math.imul(H,W))+Math.imul(R,j)|0,r=Math.imul(R,W),i=i+Math.imul(K,P)|0,g=(g=g+Math.imul(K,V)|0)+Math.imul(U,P)|0,r=r+Math.imul(U,V)|0,i=i+Math.imul(S,z)|0,g=(g=g+Math.imul(S,T)|0)+Math.imul(Y,z)|0,r=r+Math.imul(Y,T)|0,i=i+Math.imul(k,$)|0,g=(g=g+Math.imul(k,AA)|0)+Math.imul(F,$)|0,r=r+Math.imul(F,AA)|0,i=i+Math.imul(M,tA)|0,g=(g=g+Math.imul(M,iA)|0)+Math.imul(m,tA)|0,r=r+Math.imul(m,iA)|0,i=i+Math.imul(D,rA)|0,g=(g=g+Math.imul(D,nA)|0)+Math.imul(b,rA)|0,r=r+Math.imul(b,nA)|0,i=i+Math.imul(l,IA)|0,g=(g=g+Math.imul(l,oA)|0)+Math.imul(w,IA)|0,r=r+Math.imul(w,oA)|0,i=i+Math.imul(E,QA)|0,g=(g=g+Math.imul(E,CA)|0)+Math.imul(u,QA)|0,r=r+Math.imul(u,CA)|0;var MA=(o+(i=i+Math.imul(c,cA)|0)|0)+((8191&(g=(g=g+Math.imul(c,hA)|0)+Math.imul(h,cA)|0))<<13)|0;o=((r=r+Math.imul(h,hA)|0)+(g>>>13)|0)+(MA>>>26)|0,MA&=67108863,i=Math.imul(H,P),g=(g=Math.imul(H,V))+Math.imul(R,P)|0,r=Math.imul(R,V),i=i+Math.imul(K,z)|0,g=(g=g+Math.imul(K,T)|0)+Math.imul(U,z)|0,r=r+Math.imul(U,T)|0,i=i+Math.imul(S,$)|0,g=(g=g+Math.imul(S,AA)|0)+Math.imul(Y,$)|0,r=r+Math.imul(Y,AA)|0,i=i+Math.imul(k,tA)|0,g=(g=g+Math.imul(k,iA)|0)+Math.imul(F,tA)|0,r=r+Math.imul(F,iA)|0,i=i+Math.imul(M,rA)|0,g=(g=g+Math.imul(M,nA)|0)+Math.imul(m,rA)|0,r=r+Math.imul(m,nA)|0,i=i+Math.imul(D,IA)|0,g=(g=g+Math.imul(D,oA)|0)+Math.imul(b,IA)|0,r=r+Math.imul(b,oA)|0,i=i+Math.imul(l,QA)|0,g=(g=g+Math.imul(l,CA)|0)+Math.imul(w,QA)|0,r=r+Math.imul(w,CA)|0;var mA=(o+(i=i+Math.imul(E,cA)|0)|0)+((8191&(g=(g=g+Math.imul(E,hA)|0)+Math.imul(u,cA)|0))<<13)|0;o=((r=r+Math.imul(u,hA)|0)+(g>>>13)|0)+(mA>>>26)|0,mA&=67108863,i=Math.imul(H,z),g=(g=Math.imul(H,T))+Math.imul(R,z)|0,r=Math.imul(R,T),i=i+Math.imul(K,$)|0,g=(g=g+Math.imul(K,AA)|0)+Math.imul(U,$)|0,r=r+Math.imul(U,AA)|0,i=i+Math.imul(S,tA)|0,g=(g=g+Math.imul(S,iA)|0)+Math.imul(Y,tA)|0,r=r+Math.imul(Y,iA)|0,i=i+Math.imul(k,rA)|0,g=(g=g+Math.imul(k,nA)|0)+Math.imul(F,rA)|0,r=r+Math.imul(F,nA)|0,i=i+Math.imul(M,IA)|0,g=(g=g+Math.imul(M,oA)|0)+Math.imul(m,IA)|0,r=r+Math.imul(m,oA)|0,i=i+Math.imul(D,QA)|0,g=(g=g+Math.imul(D,CA)|0)+Math.imul(b,QA)|0,r=r+Math.imul(b,CA)|0;var GA=(o+(i=i+Math.imul(l,cA)|0)|0)+((8191&(g=(g=g+Math.imul(l,hA)|0)+Math.imul(w,cA)|0))<<13)|0;o=((r=r+Math.imul(w,hA)|0)+(g>>>13)|0)+(GA>>>26)|0,GA&=67108863,i=Math.imul(H,$),g=(g=Math.imul(H,AA))+Math.imul(R,$)|0,r=Math.imul(R,AA),i=i+Math.imul(K,tA)|0,g=(g=g+Math.imul(K,iA)|0)+Math.imul(U,tA)|0,r=r+Math.imul(U,iA)|0,i=i+Math.imul(S,rA)|0,g=(g=g+Math.imul(S,nA)|0)+Math.imul(Y,rA)|0,r=r+Math.imul(Y,nA)|0,i=i+Math.imul(k,IA)|0,g=(g=g+Math.imul(k,oA)|0)+Math.imul(F,IA)|0,r=r+Math.imul(F,oA)|0,i=i+Math.imul(M,QA)|0,g=(g=g+Math.imul(M,CA)|0)+Math.imul(m,QA)|0,r=r+Math.imul(m,CA)|0;var kA=(o+(i=i+Math.imul(D,cA)|0)|0)+((8191&(g=(g=g+Math.imul(D,hA)|0)+Math.imul(b,cA)|0))<<13)|0;o=((r=r+Math.imul(b,hA)|0)+(g>>>13)|0)+(kA>>>26)|0,kA&=67108863,i=Math.imul(H,tA),g=(g=Math.imul(H,iA))+Math.imul(R,tA)|0,r=Math.imul(R,iA),i=i+Math.imul(K,rA)|0,g=(g=g+Math.imul(K,nA)|0)+Math.imul(U,rA)|0,r=r+Math.imul(U,nA)|0,i=i+Math.imul(S,IA)|0,g=(g=g+Math.imul(S,oA)|0)+Math.imul(Y,IA)|0,r=r+Math.imul(Y,oA)|0,i=i+Math.imul(k,QA)|0,g=(g=g+Math.imul(k,CA)|0)+Math.imul(F,QA)|0,r=r+Math.imul(F,CA)|0;var FA=(o+(i=i+Math.imul(M,cA)|0)|0)+((8191&(g=(g=g+Math.imul(M,hA)|0)+Math.imul(m,cA)|0))<<13)|0;o=((r=r+Math.imul(m,hA)|0)+(g>>>13)|0)+(FA>>>26)|0,FA&=67108863,i=Math.imul(H,rA),g=(g=Math.imul(H,nA))+Math.imul(R,rA)|0,r=Math.imul(R,nA),i=i+Math.imul(K,IA)|0,g=(g=g+Math.imul(K,oA)|0)+Math.imul(U,IA)|0,r=r+Math.imul(U,oA)|0,i=i+Math.imul(S,QA)|0,g=(g=g+Math.imul(S,CA)|0)+Math.imul(Y,QA)|0,r=r+Math.imul(Y,CA)|0;var NA=(o+(i=i+Math.imul(k,cA)|0)|0)+((8191&(g=(g=g+Math.imul(k,hA)|0)+Math.imul(F,cA)|0))<<13)|0;o=((r=r+Math.imul(F,hA)|0)+(g>>>13)|0)+(NA>>>26)|0,NA&=67108863,i=Math.imul(H,IA),g=(g=Math.imul(H,oA))+Math.imul(R,IA)|0,r=Math.imul(R,oA),i=i+Math.imul(K,QA)|0,g=(g=g+Math.imul(K,CA)|0)+Math.imul(U,QA)|0,r=r+Math.imul(U,CA)|0;var SA=(o+(i=i+Math.imul(S,cA)|0)|0)+((8191&(g=(g=g+Math.imul(S,hA)|0)+Math.imul(Y,cA)|0))<<13)|0;o=((r=r+Math.imul(Y,hA)|0)+(g>>>13)|0)+(SA>>>26)|0,SA&=67108863,i=Math.imul(H,QA),g=(g=Math.imul(H,CA))+Math.imul(R,QA)|0,r=Math.imul(R,CA);var YA=(o+(i=i+Math.imul(K,cA)|0)|0)+((8191&(g=(g=g+Math.imul(K,hA)|0)+Math.imul(U,cA)|0))<<13)|0;o=((r=r+Math.imul(U,hA)|0)+(g>>>13)|0)+(YA>>>26)|0,YA&=67108863;var vA=(o+(i=Math.imul(H,cA))|0)+((8191&(g=(g=Math.imul(H,hA))+Math.imul(R,cA)|0))<<13)|0;return o=((r=Math.imul(R,hA))+(g>>>13)|0)+(vA>>>26)|0,vA&=67108863,I[0]=fA,I[1]=EA,I[2]=uA,I[3]=dA,I[4]=lA,I[5]=wA,I[6]=pA,I[7]=DA,I[8]=bA,I[9]=yA,I[10]=MA,I[11]=mA,I[12]=GA,I[13]=kA,I[14]=FA,I[15]=NA,I[16]=SA,I[17]=YA,I[18]=vA,0!==o&&(I[19]=o,t.length++),t};function f(A,e,t){t.negative=e.negative^A.negative,t.length=A.length+e.length;for(var i=0,g=0,r=0;r>>26)|0)>>>26,n&=67108863}t.words[r]=B,i=n,n=g}return 0!==i?t.words[r]=i:t.length--,t._strip()}function E(A,e,t){return f(A,e,t)}function u(A,e){this.x=A,this.y=e}Math.imul||(h=c),r.prototype.mulTo=function(A,e){var t=this.length+A.length;return 10===this.length&&10===A.length?h(this,A,e):t<63?c(this,A,e):t<1024?f(this,A,e):E(this,A,e)},u.prototype.makeRBT=function(A){for(var e=new Array(A),t=r.prototype._countBits(A)-1,i=0;i>=1;return i},u.prototype.permute=function(A,e,t,i,g,r){for(var n=0;n>>=1)g++;return 1<>>=13,t[2*n+1]=8191&r,r>>>=13;for(n=2*e;n>=26,t+=r/67108864|0,t+=n>>>26,this.words[g]=67108863&n}return 0!==t&&(this.words[g]=t,this.length++),e?this.ineg():this},r.prototype.muln=function(A){return this.clone().imuln(A)},r.prototype.sqr=function(){return this.mul(this)},r.prototype.isqr=function(){return this.imul(this.clone())},r.prototype.pow=function(A){var e=function(A){for(var e=new Array(A.bitLength()),t=0;t>>g&1}return e}(A);if(0===e.length)return new r(1);for(var t=this,i=0;i=0);var e,t=A%26,g=(A-t)/26,r=67108863>>>26-t<<26-t;if(0!==t){var n=0;for(e=0;e>>26-t}n&&(this.words[e]=n,this.length++)}if(0!==g){for(e=this.length-1;e>=0;e--)this.words[e+g]=this.words[e];for(e=0;e=0),g=e?(e-e%26)/26:0;var r=A%26,n=Math.min((A-r)/26,this.length),B=67108863^67108863>>>r<n)for(this.length-=n,o=0;o=0&&(0!==a||o>=g);o--){var Q=0|this.words[o];this.words[o]=a<<26-r|Q>>>r,a=Q&B}return I&&0!==a&&(I.words[I.length++]=a),0===this.length&&(this.words[0]=0,this.length=1),this._strip()},r.prototype.ishrn=function(A,e,t){return i(0===this.negative),this.iushrn(A,e,t)},r.prototype.shln=function(A){return this.clone().ishln(A)},r.prototype.ushln=function(A){return this.clone().iushln(A)},r.prototype.shrn=function(A){return this.clone().ishrn(A)},r.prototype.ushrn=function(A){return this.clone().iushrn(A)},r.prototype.testn=function(A){i("number"==typeof A&&A>=0);var e=A%26,t=(A-e)/26,g=1<=0);var e=A%26,t=(A-e)/26;if(i(0===this.negative,"imaskn works only with positive numbers"),this.length<=t)return this;if(0!==e&&t++,this.length=Math.min(t,this.length),0!==e){var g=67108863^67108863>>>e<=67108864;e++)this.words[e]-=67108864,e===this.length-1?this.words[e+1]=1:this.words[e+1]++;return this.length=Math.max(this.length,e+1),this},r.prototype.isubn=function(A){if(i("number"==typeof A),i(A<67108864),A<0)return this.iaddn(-A);if(0!==this.negative)return this.negative=0,this.iaddn(A),this.negative=1,this;if(this.words[0]-=A,1===this.length&&this.words[0]<0)this.words[0]=-this.words[0],this.negative=1;else for(var e=0;e>26)-(I/67108864|0),this.words[g+t]=67108863&r}for(;g>26,this.words[g+t]=67108863&r;if(0===B)return this._strip();for(i(-1===B),B=0,g=0;g>26,this.words[g]=67108863&r;return this.negative=1,this._strip()},r.prototype._wordDiv=function(A,e){var t=(this.length,A.length),i=this.clone(),g=A,n=0|g.words[g.length-1];0!==(t=26-this._countBits(n))&&(g=g.ushln(t),i.iushln(t),n=0|g.words[g.length-1]);var B,I=i.length-g.length;if("mod"!==e){(B=new r(null)).length=I+1,B.words=new Array(B.length);for(var o=0;o=0;Q--){var C=67108864*(0|i.words[g.length+Q])+(0|i.words[g.length+Q-1]);for(C=Math.min(C/n|0,67108863),i._ishlnsubmul(g,C,Q);0!==i.negative;)C--,i.negative=0,i._ishlnsubmul(g,1,Q),i.isZero()||(i.negative^=1);B&&(B.words[Q]=C)}return B&&B._strip(),i._strip(),"div"!==e&&0!==t&&i.iushrn(t),{div:B||null,mod:i}},r.prototype.divmod=function(A,e,t){return i(!A.isZero()),this.isZero()?{div:new r(0),mod:new r(0)}:0!==this.negative&&0===A.negative?(B=this.neg().divmod(A,e),"mod"!==e&&(g=B.div.neg()),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.iadd(A)),{div:g,mod:n}):0===this.negative&&0!==A.negative?(B=this.divmod(A.neg(),e),"mod"!==e&&(g=B.div.neg()),{div:g,mod:B.mod}):0!=(this.negative&A.negative)?(B=this.neg().divmod(A.neg(),e),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.isub(A)),{div:B.div,mod:n}):A.length>this.length||this.cmp(A)<0?{div:new r(0),mod:this}:1===A.length?"div"===e?{div:this.divn(A.words[0]),mod:null}:"mod"===e?{div:null,mod:new r(this.modrn(A.words[0]))}:{div:this.divn(A.words[0]),mod:new r(this.modrn(A.words[0]))}:this._wordDiv(A,e);var g,n,B},r.prototype.div=function(A){return this.divmod(A,"div",!1).div},r.prototype.mod=function(A){return this.divmod(A,"mod",!1).mod},r.prototype.umod=function(A){return this.divmod(A,"mod",!0).mod},r.prototype.divRound=function(A){var e=this.divmod(A);if(e.mod.isZero())return e.div;var t=0!==e.div.negative?e.mod.isub(A):e.mod,i=A.ushrn(1),g=A.andln(1),r=t.cmp(i);return r<0||1===g&&0===r?e.div:0!==e.div.negative?e.div.isubn(1):e.div.iaddn(1)},r.prototype.modrn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=(1<<26)%A,g=0,r=this.length-1;r>=0;r--)g=(t*g+(0|this.words[r]))%A;return e?-g:g},r.prototype.modn=function(A){return this.modrn(A)},r.prototype.idivn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=0,g=this.length-1;g>=0;g--){var r=(0|this.words[g])+67108864*t;this.words[g]=r/A|0,t=r%A}return this._strip(),e?this.ineg():this},r.prototype.divn=function(A){return this.clone().idivn(A)},r.prototype.egcd=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g=new r(1),n=new r(0),B=new r(0),I=new r(1),o=0;e.isEven()&&t.isEven();)e.iushrn(1),t.iushrn(1),++o;for(var a=t.clone(),Q=e.clone();!e.isZero();){for(var C=0,s=1;0==(e.words[0]&s)&&C<26;++C,s<<=1);if(C>0)for(e.iushrn(C);C-- >0;)(g.isOdd()||n.isOdd())&&(g.iadd(a),n.isub(Q)),g.iushrn(1),n.iushrn(1);for(var c=0,h=1;0==(t.words[0]&h)&&c<26;++c,h<<=1);if(c>0)for(t.iushrn(c);c-- >0;)(B.isOdd()||I.isOdd())&&(B.iadd(a),I.isub(Q)),B.iushrn(1),I.iushrn(1);e.cmp(t)>=0?(e.isub(t),g.isub(B),n.isub(I)):(t.isub(e),B.isub(g),I.isub(n))}return{a:B,b:I,gcd:t.iushln(o)}},r.prototype._invmp=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g,n=new r(1),B=new r(0),I=t.clone();e.cmpn(1)>0&&t.cmpn(1)>0;){for(var o=0,a=1;0==(e.words[0]&a)&&o<26;++o,a<<=1);if(o>0)for(e.iushrn(o);o-- >0;)n.isOdd()&&n.iadd(I),n.iushrn(1);for(var Q=0,C=1;0==(t.words[0]&C)&&Q<26;++Q,C<<=1);if(Q>0)for(t.iushrn(Q);Q-- >0;)B.isOdd()&&B.iadd(I),B.iushrn(1);e.cmp(t)>=0?(e.isub(t),n.isub(B)):(t.isub(e),B.isub(n))}return(g=0===e.cmpn(1)?n:B).cmpn(0)<0&&g.iadd(A),g},r.prototype.gcd=function(A){if(this.isZero())return A.abs();if(A.isZero())return this.abs();var e=this.clone(),t=A.clone();e.negative=0,t.negative=0;for(var i=0;e.isEven()&&t.isEven();i++)e.iushrn(1),t.iushrn(1);for(;;){for(;e.isEven();)e.iushrn(1);for(;t.isEven();)t.iushrn(1);var g=e.cmp(t);if(g<0){var r=e;e=t,t=r}else if(0===g||0===t.cmpn(1))break;e.isub(t)}return t.iushln(i)},r.prototype.invm=function(A){return this.egcd(A).a.umod(A)},r.prototype.isEven=function(){return 0==(1&this.words[0])},r.prototype.isOdd=function(){return 1==(1&this.words[0])},r.prototype.andln=function(A){return this.words[0]&A},r.prototype.bincn=function(A){i("number"==typeof A);var e=A%26,t=(A-e)/26,g=1<>>26,B&=67108863,this.words[n]=B}return 0!==r&&(this.words[n]=r,this.length++),this},r.prototype.isZero=function(){return 1===this.length&&0===this.words[0]},r.prototype.cmpn=function(A){var e,t=A<0;if(0!==this.negative&&!t)return-1;if(0===this.negative&&t)return 1;if(this._strip(),this.length>1)e=1;else{t&&(A=-A),i(A<=67108863,"Number is too big");var g=0|this.words[0];e=g===A?0:gA.length)return 1;if(this.length=0;t--){var i=0|this.words[t],g=0|A.words[t];if(i!==g){ig&&(e=1);break}}return e},r.prototype.gtn=function(A){return 1===this.cmpn(A)},r.prototype.gt=function(A){return 1===this.cmp(A)},r.prototype.gten=function(A){return this.cmpn(A)>=0},r.prototype.gte=function(A){return this.cmp(A)>=0},r.prototype.ltn=function(A){return-1===this.cmpn(A)},r.prototype.lt=function(A){return-1===this.cmp(A)},r.prototype.lten=function(A){return this.cmpn(A)<=0},r.prototype.lte=function(A){return this.cmp(A)<=0},r.prototype.eqn=function(A){return 0===this.cmpn(A)},r.prototype.eq=function(A){return 0===this.cmp(A)},r.red=function(A){return new y(A)},r.prototype.toRed=function(A){return i(!this.red,"Already a number in reduction context"),i(0===this.negative,"red works only with positives"),A.convertTo(this)._forceRed(A)},r.prototype.fromRed=function(){return i(this.red,"fromRed works only with numbers in reduction context"),this.red.convertFrom(this)},r.prototype._forceRed=function(A){return this.red=A,this},r.prototype.forceRed=function(A){return i(!this.red,"Already a number in reduction context"),this._forceRed(A)},r.prototype.redAdd=function(A){return i(this.red,"redAdd works only with red numbers"),this.red.add(this,A)},r.prototype.redIAdd=function(A){return i(this.red,"redIAdd works only with red numbers"),this.red.iadd(this,A)},r.prototype.redSub=function(A){return i(this.red,"redSub works only with red numbers"),this.red.sub(this,A)},r.prototype.redISub=function(A){return i(this.red,"redISub works only with red numbers"),this.red.isub(this,A)},r.prototype.redShl=function(A){return i(this.red,"redShl works only with red numbers"),this.red.shl(this,A)},r.prototype.redMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.mul(this,A)},r.prototype.redIMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.imul(this,A)},r.prototype.redSqr=function(){return i(this.red,"redSqr works only with red numbers"),this.red._verify1(this),this.red.sqr(this)},r.prototype.redISqr=function(){return i(this.red,"redISqr works only with red numbers"),this.red._verify1(this),this.red.isqr(this)},r.prototype.redSqrt=function(){return i(this.red,"redSqrt works only with red numbers"),this.red._verify1(this),this.red.sqrt(this)},r.prototype.redInvm=function(){return i(this.red,"redInvm works only with red numbers"),this.red._verify1(this),this.red.invm(this)},r.prototype.redNeg=function(){return i(this.red,"redNeg works only with red numbers"),this.red._verify1(this),this.red.neg(this)},r.prototype.redPow=function(A){return i(this.red&&!A.red,"redPow(normalNum)"),this.red._verify1(this),this.red.pow(this,A)};var d={k256:null,p224:null,p192:null,p25519:null};function l(A,e){this.name=A,this.p=new r(e,16),this.n=this.p.bitLength(),this.k=new r(1).iushln(this.n).isub(this.p),this.tmp=this._tmp()}function w(){l.call(this,"k256","ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f")}function p(){l.call(this,"p224","ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001")}function D(){l.call(this,"p192","ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff")}function b(){l.call(this,"25519","7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed")}function y(A){if("string"==typeof A){var e=r._prime(A);this.m=e.p,this.prime=e}else i(A.gtn(1),"modulus must be greater than 1"),this.m=A,this.prime=null}function M(A){y.call(this,A),this.shift=this.m.bitLength(),this.shift%26!=0&&(this.shift+=26-this.shift%26),this.r=new r(1).iushln(this.shift),this.r2=this.imod(this.r.sqr()),this.rinv=this.r._invmp(this.m),this.minv=this.rinv.mul(this.r).isubn(1).div(this.m),this.minv=this.minv.umod(this.r),this.minv=this.r.sub(this.minv)}l.prototype._tmp=function(){var A=new r(null);return A.words=new Array(Math.ceil(this.n/13)),A},l.prototype.ireduce=function(A){var e,t=A;do{this.split(t,this.tmp),e=(t=(t=this.imulK(t)).iadd(this.tmp)).bitLength()}while(e>this.n);var i=e0?t.isub(this.p):void 0!==t.strip?t.strip():t._strip(),t},l.prototype.split=function(A,e){A.iushrn(this.n,0,e)},l.prototype.imulK=function(A){return A.imul(this.k)},g(w,l),w.prototype.split=function(A,e){for(var t=Math.min(A.length,9),i=0;i>>22,g=r}g>>>=22,A.words[i-10]=g,0===g&&A.length>10?A.length-=10:A.length-=9},w.prototype.imulK=function(A){A.words[A.length]=0,A.words[A.length+1]=0,A.length+=2;for(var e=0,t=0;t>>=26,A.words[t]=g,e=i}return 0!==e&&(A.words[A.length++]=e),A},r._prime=function(A){if(d[A])return d[A];var e;if("k256"===A)e=new w;else if("p224"===A)e=new p;else if("p192"===A)e=new D;else{if("p25519"!==A)throw new Error("Unknown prime "+A);e=new b}return d[A]=e,e},y.prototype._verify1=function(A){i(0===A.negative,"red works only with positives"),i(A.red,"red works only with red numbers")},y.prototype._verify2=function(A,e){i(0==(A.negative|e.negative),"red works only with positives"),i(A.red&&A.red===e.red,"red works only with red numbers")},y.prototype.imod=function(A){return this.prime?this.prime.ireduce(A)._forceRed(this):(o(A,A.umod(this.m)._forceRed(this)),A)},y.prototype.neg=function(A){return A.isZero()?A.clone():this.m.sub(A)._forceRed(this)},y.prototype.add=function(A,e){this._verify2(A,e);var t=A.add(e);return t.cmp(this.m)>=0&&t.isub(this.m),t._forceRed(this)},y.prototype.iadd=function(A,e){this._verify2(A,e);var t=A.iadd(e);return t.cmp(this.m)>=0&&t.isub(this.m),t},y.prototype.sub=function(A,e){this._verify2(A,e);var t=A.sub(e);return t.cmpn(0)<0&&t.iadd(this.m),t._forceRed(this)},y.prototype.isub=function(A,e){this._verify2(A,e);var t=A.isub(e);return t.cmpn(0)<0&&t.iadd(this.m),t},y.prototype.shl=function(A,e){return this._verify1(A),this.imod(A.ushln(e))},y.prototype.imul=function(A,e){return this._verify2(A,e),this.imod(A.imul(e))},y.prototype.mul=function(A,e){return this._verify2(A,e),this.imod(A.mul(e))},y.prototype.isqr=function(A){return this.imul(A,A.clone())},y.prototype.sqr=function(A){return this.mul(A,A)},y.prototype.sqrt=function(A){if(A.isZero())return A.clone();var e=this.m.andln(3);if(i(e%2==1),3===e){var t=this.m.add(new r(1)).iushrn(2);return this.pow(A,t)}for(var g=this.m.subn(1),n=0;!g.isZero()&&0===g.andln(1);)n++,g.iushrn(1);i(!g.isZero());var B=new r(1).toRed(this),I=B.redNeg(),o=this.m.subn(1).iushrn(1),a=this.m.bitLength();for(a=new r(2*a*a).toRed(this);0!==this.pow(a,o).cmp(I);)a.redIAdd(I);for(var Q=this.pow(a,g),C=this.pow(A,g.addn(1).iushrn(1)),s=this.pow(A,g),c=n;0!==s.cmp(B);){for(var h=s,f=0;0!==h.cmp(B);f++)h=h.redSqr();i(f=0;i--){for(var o=e.words[i],a=I-1;a>=0;a--){var Q=o>>a&1;g!==t[0]&&(g=this.sqr(g)),0!==Q||0!==n?(n<<=1,n|=Q,(4===++B||0===i&&0===a)&&(g=this.mul(g,t[n]),B=0,n=0)):B=0}I=26}return g},y.prototype.convertTo=function(A){var e=A.umod(this.m);return e===A?e.clone():e},y.prototype.convertFrom=function(A){var e=A.clone();return e.red=null,e},r.mont=function(A){return new M(A)},g(M,y),M.prototype.convertTo=function(A){return this.imod(A.ushln(this.shift))},M.prototype.convertFrom=function(A){var e=this.imod(A.mul(this.rinv));return e.red=null,e},M.prototype.imul=function(A,e){if(A.isZero()||e.isZero())return A.words[0]=0,A.length=1,A;var t=A.imul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),r=g;return g.cmp(this.m)>=0?r=g.isub(this.m):g.cmpn(0)<0&&(r=g.iadd(this.m)),r._forceRed(this)},M.prototype.mul=function(A,e){if(A.isZero()||e.isZero())return new r(0)._forceRed(this);var t=A.mul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),n=g;return g.cmp(this.m)>=0?n=g.isub(this.m):g.cmpn(0)<0&&(n=g.iadd(this.m)),n._forceRed(this)},M.prototype.invm=function(A){return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this)}}(void 0===e||e,this)},{buffer:19}],18:[function(A,e,t){var i;function g(A){this.rand=A}if(e.exports=function(A){return i||(i=new g(null)),i.generate(A)},e.exports.Rand=g,g.prototype.generate=function(A){return this._rand(A)},g.prototype._rand=function(A){if(this.rand.getBytes)return this.rand.getBytes(A);for(var e=new Uint8Array(A),t=0;t>>24]^a[c>>>16&255]^Q[h>>>8&255]^C[255&f]^e[E++],n=o[c>>>24]^a[h>>>16&255]^Q[f>>>8&255]^C[255&s]^e[E++],B=o[h>>>24]^a[f>>>16&255]^Q[s>>>8&255]^C[255&c]^e[E++],I=o[f>>>24]^a[s>>>16&255]^Q[c>>>8&255]^C[255&h]^e[E++],s=r,c=n,h=B,f=I;return r=(i[s>>>24]<<24|i[c>>>16&255]<<16|i[h>>>8&255]<<8|i[255&f])^e[E++],n=(i[c>>>24]<<24|i[h>>>16&255]<<16|i[f>>>8&255]<<8|i[255&s])^e[E++],B=(i[h>>>24]<<24|i[f>>>16&255]<<16|i[s>>>8&255]<<8|i[255&c])^e[E++],I=(i[f>>>24]<<24|i[s>>>16&255]<<16|i[c>>>8&255]<<8|i[255&h])^e[E++],[r>>>=0,n>>>=0,B>>>=0,I>>>=0]}var B=[0,1,2,4,8,16,32,64,128,27,54],I=function(){for(var A=new Array(256),e=0;e<256;e++)A[e]=e<128?e<<1:e<<1^283;for(var t=[],i=[],g=[[],[],[],[]],r=[[],[],[],[]],n=0,B=0,I=0;I<256;++I){var o=B^B<<1^B<<2^B<<3^B<<4;o=o>>>8^255&o^99,t[n]=o,i[o]=n;var a=A[n],Q=A[a],C=A[Q],s=257*A[o]^16843008*o;g[0][n]=s<<24|s>>>8,g[1][n]=s<<16|s>>>16,g[2][n]=s<<8|s>>>24,g[3][n]=s,s=16843009*C^65537*Q^257*a^16843008*n,r[0][o]=s<<24|s>>>8,r[1][o]=s<<16|s>>>16,r[2][o]=s<<8|s>>>24,r[3][o]=s,0===n?n=B=1:(n=a^A[A[A[C^a]]],B^=A[A[B]])}return{SBOX:t,INV_SBOX:i,SUB_MIX:g,INV_SUB_MIX:r}}();function o(A){this._key=g(A),this._reset()}o.blockSize=16,o.keySize=32,o.prototype.blockSize=o.blockSize,o.prototype.keySize=o.keySize,o.prototype._reset=function(){for(var A=this._key,e=A.length,t=e+6,i=4*(t+1),g=[],r=0;r>>24,n=I.SBOX[n>>>24]<<24|I.SBOX[n>>>16&255]<<16|I.SBOX[n>>>8&255]<<8|I.SBOX[255&n],n^=B[r/e|0]<<24):e>6&&r%e==4&&(n=I.SBOX[n>>>24]<<24|I.SBOX[n>>>16&255]<<16|I.SBOX[n>>>8&255]<<8|I.SBOX[255&n]),g[r]=g[r-e]^n}for(var o=[],a=0;a>>24]]^I.INV_SUB_MIX[1][I.SBOX[C>>>16&255]]^I.INV_SUB_MIX[2][I.SBOX[C>>>8&255]]^I.INV_SUB_MIX[3][I.SBOX[255&C]]}this._nRounds=t,this._keySchedule=g,this._invKeySchedule=o},o.prototype.encryptBlockRaw=function(A){return n(A=g(A),this._keySchedule,I.SUB_MIX,I.SBOX,this._nRounds)},o.prototype.encryptBlock=function(A){var e=this.encryptBlockRaw(A),t=i.allocUnsafe(16);return t.writeUInt32BE(e[0],0),t.writeUInt32BE(e[1],4),t.writeUInt32BE(e[2],8),t.writeUInt32BE(e[3],12),t},o.prototype.decryptBlock=function(A){var e=(A=g(A))[1];A[1]=A[3],A[3]=e;var t=n(A,this._invKeySchedule,I.INV_SUB_MIX,I.INV_SBOX,this._nRounds),r=i.allocUnsafe(16);return r.writeUInt32BE(t[0],0),r.writeUInt32BE(t[3],4),r.writeUInt32BE(t[2],8),r.writeUInt32BE(t[1],12),r},o.prototype.scrub=function(){r(this._keySchedule),r(this._invKeySchedule),r(this._key)},e.exports.AES=o},{"safe-buffer":180}],21:[function(A,e,t){var i=A("./aes"),g=A("safe-buffer").Buffer,r=A("cipher-base"),n=A("inherits"),B=A("./ghash"),I=A("buffer-xor"),o=A("./incr32");function a(A,e,t,n){r.call(this);var I=g.alloc(4,0);this._cipher=new i.AES(e);var a=this._cipher.encryptBlock(I);this._ghash=new B(a),t=function(A,e,t){if(12===e.length)return A._finID=g.concat([e,g.from([0,0,0,1])]),g.concat([e,g.from([0,0,0,2])]);var i=new B(t),r=e.length,n=r%16;i.update(e),n&&(n=16-n,i.update(g.alloc(n,0))),i.update(g.alloc(8,0));var I=8*r,a=g.alloc(8);a.writeUIntBE(I,0,8),i.update(a),A._finID=i.state;var Q=g.from(A._finID);return o(Q),Q}(this,t,a),this._prev=g.from(t),this._cache=g.allocUnsafe(0),this._secCache=g.allocUnsafe(0),this._decrypt=n,this._alen=0,this._len=0,this._mode=A,this._authTag=null,this._called=!1}n(a,r),a.prototype._update=function(A){if(!this._called&&this._alen){var e=16-this._alen%16;e<16&&(e=g.alloc(e,0),this._ghash.update(e))}this._called=!0;var t=this._mode.encrypt(this,A);return this._decrypt?this._ghash.update(A):this._ghash.update(t),this._len+=A.length,t},a.prototype._final=function(){if(this._decrypt&&!this._authTag)throw new Error("Unsupported state or unable to authenticate data");var A=I(this._ghash.final(8*this._alen,8*this._len),this._cipher.encryptBlock(this._finID));if(this._decrypt&&function(A,e){var t=0;A.length!==e.length&&t++;for(var i=Math.min(A.length,e.length),g=0;g16)throw new Error("unable to decrypt data");var t=-1;for(;++t16)return e=this.cache.slice(0,16),this.cache=this.cache.slice(16),e}else if(this.cache.length>=16)return e=this.cache.slice(0,16),this.cache=this.cache.slice(16),e;return null},Q.prototype.flush=function(){if(this.cache.length)return this.cache},t.createDecipher=function(A,e){var t=r[A.toLowerCase()];if(!t)throw new TypeError("invalid suite type");var i=o(e,!1,t.key,t.iv);return C(A,i.key,i.iv)},t.createDecipheriv=C},{"./aes":20,"./authCipher":21,"./modes":33,"./streamCipher":36,"cipher-base":65,evp_bytestokey:103,inherits:134,"safe-buffer":180}],24:[function(A,e,t){var i=A("./modes"),g=A("./authCipher"),r=A("safe-buffer").Buffer,n=A("./streamCipher"),B=A("cipher-base"),I=A("./aes"),o=A("evp_bytestokey");function a(A,e,t){B.call(this),this._cache=new C,this._cipher=new I.AES(e),this._prev=r.from(t),this._mode=A,this._autopadding=!0}A("inherits")(a,B),a.prototype._update=function(A){var e,t;this._cache.add(A);for(var i=[];e=this._cache.get();)t=this._mode.encrypt(this,e),i.push(t);return r.concat(i)};var Q=r.alloc(16,16);function C(){this.cache=r.allocUnsafe(0)}function s(A,e,t){var B=i[A.toLowerCase()];if(!B)throw new TypeError("invalid suite type");if("string"==typeof e&&(e=r.from(e)),e.length!==B.key/8)throw new TypeError("invalid key length "+e.length);if("string"==typeof t&&(t=r.from(t)),"GCM"!==B.mode&&t.length!==B.iv)throw new TypeError("invalid iv length "+t.length);return"stream"===B.type?new n(B.module,e,t):"auth"===B.type?new g(B.module,e,t):new a(B.module,e,t)}a.prototype._final=function(){var A=this._cache.flush();if(this._autopadding)return A=this._mode.encrypt(this,A),this._cipher.scrub(),A;if(!A.equals(Q))throw this._cipher.scrub(),new Error("data not multiple of block length")},a.prototype.setAutoPadding=function(A){return this._autopadding=!!A,this},C.prototype.add=function(A){this.cache=r.concat([this.cache,A])},C.prototype.get=function(){if(this.cache.length>15){var A=this.cache.slice(0,16);return this.cache=this.cache.slice(16),A}return null},C.prototype.flush=function(){for(var A=16-this.cache.length,e=r.allocUnsafe(A),t=-1;++t>>0,0),e.writeUInt32BE(A[1]>>>0,4),e.writeUInt32BE(A[2]>>>0,8),e.writeUInt32BE(A[3]>>>0,12),e}function n(A){this.h=A,this.state=i.alloc(16,0),this.cache=i.allocUnsafe(0)}n.prototype.ghash=function(A){for(var e=-1;++e0;e--)i[e]=i[e]>>>1|(1&i[e-1])<<31;i[0]=i[0]>>>1,t&&(i[0]=i[0]^225<<24)}this.state=r(g)},n.prototype.update=function(A){var e;for(this.cache=i.concat([this.cache,A]);this.cache.length>=16;)e=this.cache.slice(0,16),this.cache=this.cache.slice(16),this.ghash(e)},n.prototype.final=function(A,e){return this.cache.length&&this.ghash(i.concat([this.cache,g],16)),this.ghash(r([0,A,0,e])),this.state},e.exports=n},{"safe-buffer":180}],26:[function(A,e,t){e.exports=function(A){for(var e,t=A.length;t--;){if(255!==(e=A.readUInt8(t))){e++,A.writeUInt8(e,t);break}A.writeUInt8(0,t)}}},{}],27:[function(A,e,t){var i=A("buffer-xor");t.encrypt=function(A,e){var t=i(e,A._prev);return A._prev=A._cipher.encryptBlock(t),A._prev},t.decrypt=function(A,e){var t=A._prev;A._prev=e;var g=A._cipher.decryptBlock(e);return i(g,t)}},{"buffer-xor":63}],28:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("buffer-xor");function r(A,e,t){var r=e.length,n=g(e,A._cache);return A._cache=A._cache.slice(r),A._prev=i.concat([A._prev,t?e:n]),n}t.encrypt=function(A,e,t){for(var g,n=i.allocUnsafe(0);e.length;){if(0===A._cache.length&&(A._cache=A._cipher.encryptBlock(A._prev),A._prev=i.allocUnsafe(0)),!(A._cache.length<=e.length)){n=i.concat([n,r(A,e,t)]);break}g=A._cache.length,n=i.concat([n,r(A,e.slice(0,g),t)]),e=e.slice(g)}return n}},{"buffer-xor":63,"safe-buffer":180}],29:[function(A,e,t){var i=A("safe-buffer").Buffer;function g(A,e,t){for(var i,g,n,B=-1,I=0;++B<8;)i=A._cipher.encryptBlock(A._prev),g=e&1<<7-B?128:0,I+=(128&(n=i[0]^g))>>B%8,A._prev=r(A._prev,t?g:n);return I}function r(A,e){var t=A.length,g=-1,r=i.allocUnsafe(A.length);for(A=i.concat([A,i.from([e])]);++g>7;return r}t.encrypt=function(A,e,t){for(var r=e.length,n=i.allocUnsafe(r),B=-1;++B=0||!t.umod(A.prime1)||!t.umod(A.prime2);)t=new i(g(e));return t}e.exports=r,r.getr=n}).call(this,A("buffer").Buffer)},{"bn.js":41,buffer:64,randombytes:162}],41:[function(A,e,t){arguments[4][15][0].apply(t,arguments)},{buffer:19,dup:15}],42:[function(A,e,t){e.exports=A("./browser/algorithms.json")},{"./browser/algorithms.json":43}],43:[function(A,e,t){e.exports={sha224WithRSAEncryption:{sign:"rsa",hash:"sha224",id:"302d300d06096086480165030402040500041c"},"RSA-SHA224":{sign:"ecdsa/rsa",hash:"sha224",id:"302d300d06096086480165030402040500041c"},sha256WithRSAEncryption:{sign:"rsa",hash:"sha256",id:"3031300d060960864801650304020105000420"},"RSA-SHA256":{sign:"ecdsa/rsa",hash:"sha256",id:"3031300d060960864801650304020105000420"},sha384WithRSAEncryption:{sign:"rsa",hash:"sha384",id:"3041300d060960864801650304020205000430"},"RSA-SHA384":{sign:"ecdsa/rsa",hash:"sha384",id:"3041300d060960864801650304020205000430"},sha512WithRSAEncryption:{sign:"rsa",hash:"sha512",id:"3051300d060960864801650304020305000440"},"RSA-SHA512":{sign:"ecdsa/rsa",hash:"sha512",id:"3051300d060960864801650304020305000440"},"RSA-SHA1":{sign:"rsa",hash:"sha1",id:"3021300906052b0e03021a05000414"},"ecdsa-with-SHA1":{sign:"ecdsa",hash:"sha1",id:""},sha256:{sign:"ecdsa",hash:"sha256",id:""},sha224:{sign:"ecdsa",hash:"sha224",id:""},sha384:{sign:"ecdsa",hash:"sha384",id:""},sha512:{sign:"ecdsa",hash:"sha512",id:""},"DSA-SHA":{sign:"dsa",hash:"sha1",id:""},"DSA-SHA1":{sign:"dsa",hash:"sha1",id:""},DSA:{sign:"dsa",hash:"sha1",id:""},"DSA-WITH-SHA224":{sign:"dsa",hash:"sha224",id:""},"DSA-SHA224":{sign:"dsa",hash:"sha224",id:""},"DSA-WITH-SHA256":{sign:"dsa",hash:"sha256",id:""},"DSA-SHA256":{sign:"dsa",hash:"sha256",id:""},"DSA-WITH-SHA384":{sign:"dsa",hash:"sha384",id:""},"DSA-SHA384":{sign:"dsa",hash:"sha384",id:""},"DSA-WITH-SHA512":{sign:"dsa",hash:"sha512",id:""},"DSA-SHA512":{sign:"dsa",hash:"sha512",id:""},"DSA-RIPEMD160":{sign:"dsa",hash:"rmd160",id:""},ripemd160WithRSA:{sign:"rsa",hash:"rmd160",id:"3021300906052b2403020105000414"},"RSA-RIPEMD160":{sign:"rsa",hash:"rmd160",id:"3021300906052b2403020105000414"},md5WithRSAEncryption:{sign:"rsa",hash:"md5",id:"3020300c06082a864886f70d020505000410"},"RSA-MD5":{sign:"rsa",hash:"md5",id:"3020300c06082a864886f70d020505000410"}}},{}],44:[function(A,e,t){e.exports={"1.3.132.0.10":"secp256k1","1.3.132.0.33":"p224","1.2.840.10045.3.1.1":"p192","1.2.840.10045.3.1.7":"p256","1.3.132.0.34":"p384","1.3.132.0.35":"p521"}},{}],45:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("create-hash"),r=A("readable-stream"),n=A("inherits"),B=A("./sign"),I=A("./verify"),o=A("./algorithms.json");function a(A){r.Writable.call(this);var e=o[A];if(!e)throw new Error("Unknown message digest");this._hashType=e.hash,this._hash=g(e.hash),this._tag=e.id,this._signType=e.sign}function Q(A){r.Writable.call(this);var e=o[A];if(!e)throw new Error("Unknown message digest");this._hash=g(e.hash),this._tag=e.id,this._signType=e.sign}function C(A){return new a(A)}function s(A){return new Q(A)}Object.keys(o).forEach(function(A){o[A].id=i.from(o[A].id,"hex"),o[A.toLowerCase()]=o[A]}),n(a,r.Writable),a.prototype._write=function(A,e,t){this._hash.update(A),t()},a.prototype.update=function(A,e){return"string"==typeof A&&(A=i.from(A,e)),this._hash.update(A),this},a.prototype.sign=function(A,e){this.end();var t=this._hash.digest(),i=B(t,A,this._hashType,this._signType,this._tag);return e?i.toString(e):i},n(Q,r.Writable),Q.prototype._write=function(A,e,t){this._hash.update(A),t()},Q.prototype.update=function(A,e){return"string"==typeof A&&(A=i.from(A,e)),this._hash.update(A),this},Q.prototype.verify=function(A,e,t){"string"==typeof e&&(e=i.from(e,t)),this.end();var g=this._hash.digest();return I(e,g,A,this._signType,this._tag)},e.exports={Sign:C,Verify:s,createSign:C,createVerify:s}},{"./algorithms.json":43,"./sign":46,"./verify":47,"create-hash":69,inherits:134,"readable-stream":62,"safe-buffer":180}],46:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("create-hmac"),r=A("browserify-rsa"),n=A("elliptic").ec,B=A("bn.js"),I=A("parse-asn1"),o=A("./curves.json");function a(A,e,t,r){if((A=i.from(A.toArray())).length0&&t.ishrn(i),t}function C(A,e,t){var r,n;do{for(r=i.alloc(0);8*r.length=e)throw new Error("invalid sig")}e.exports=function(A,e,t,o,a){var Q=n(t);if("ec"===Q.type){if("ecdsa"!==o&&"ecdsa/rsa"!==o)throw new Error("wrong public key type");return function(A,e,t){var i=B[t.data.algorithm.curve.join(".")];if(!i)throw new Error("unknown curve "+t.data.algorithm.curve.join("."));var g=new r(i),n=t.data.subjectPrivateKey.data;return g.verify(e,A,n)}(A,e,Q)}if("dsa"===Q.type){if("dsa"!==o)throw new Error("wrong public key type");return function(A,e,t){var i=t.data.p,r=t.data.q,B=t.data.g,o=t.data.pub_key,a=n.signature.decode(A,"der"),Q=a.s,C=a.r;I(Q,r),I(C,r);var s=g.mont(i),c=Q.invm(r);return 0===B.toRed(s).redPow(new g(e).mul(c).mod(r)).fromRed().mul(o.toRed(s).redPow(C.mul(c).mod(r)).fromRed()).mod(i).mod(r).cmp(C)}(A,e,Q)}if("rsa"!==o&&"ecdsa/rsa"!==o)throw new Error("wrong public key type");e=i.concat([a,e]);for(var C=Q.modulus.byteLength(),s=[1],c=0;e.length+s.length+22?"one of ".concat(e," ").concat(A.slice(0,t-1).join(", "),", or ")+A[t-1]:2===t?"one of ".concat(e," ").concat(A[0]," or ").concat(A[1]):"of ".concat(e," ").concat(A[0])}return"of ".concat(e," ").concat(String(A))}g("ERR_INVALID_OPT_VALUE",function(A,e){return'The value "'+e+'" is invalid for option "'+A+'"'},TypeError),g("ERR_INVALID_ARG_TYPE",function(A,e,t){var i,g,n,B;if("string"==typeof e&&(g="not ",e.substr(!n||n<0?0:+n,g.length)===g)?(i="must not be",e=e.replace(/^not /,"")):i="must be",function(A,e,t){return(void 0===t||t>A.length)&&(t=A.length),A.substring(t-e.length,t)===e}(A," argument"))B="The ".concat(A," ").concat(i," ").concat(r(e,"type"));else{var I=function(A,e,t){return"number"!=typeof t&&(t=0),!(t+e.length>A.length)&&-1!==A.indexOf(e,t)}(A,".")?"property":"argument";B='The "'.concat(A,'" ').concat(I," ").concat(i," ").concat(r(e,"type"))}return B+=". Received type ".concat(typeof t)},TypeError),g("ERR_STREAM_PUSH_AFTER_EOF","stream.push() after EOF"),g("ERR_METHOD_NOT_IMPLEMENTED",function(A){return"The "+A+" method is not implemented"}),g("ERR_STREAM_PREMATURE_CLOSE","Premature close"),g("ERR_STREAM_DESTROYED",function(A){return"Cannot call "+A+" after a stream was destroyed"}),g("ERR_MULTIPLE_CALLBACK","Callback called multiple times"),g("ERR_STREAM_CANNOT_PIPE","Cannot pipe, not readable"),g("ERR_STREAM_WRITE_AFTER_END","write after end"),g("ERR_STREAM_NULL_VALUES","May not write null values to stream",TypeError),g("ERR_UNKNOWN_ENCODING",function(A){return"Unknown encoding: "+A},TypeError),g("ERR_STREAM_UNSHIFT_AFTER_END_EVENT","stream.unshift() after end event"),e.exports.codes=i},{}],49:[function(A,e,t){(function(t){"use strict";var i=Object.keys||function(A){var e=[];for(var t in A)e.push(t);return e};e.exports=o;var g=A("./_stream_readable"),r=A("./_stream_writable");A("inherits")(o,g);for(var n=i(r.prototype),B=0;B0)if("string"==typeof e||n.objectMode||Object.getPrototypeOf(e)===B.prototype||(e=function(A){return B.from(A)}(e)),i)n.endEmitted?p(A,new w):m(A,n,e,!0);else if(n.ended)p(A,new d);else{if(n.destroyed)return!1;n.reading=!1,n.decoder&&!t?(e=n.decoder.write(e),n.objectMode||0!==e.length?m(A,n,e,!1):S(A,n)):m(A,n,e,!1)}else i||(n.reading=!1,S(A,n));return!n.ended&&(n.lengthe.highWaterMark&&(e.highWaterMark=function(A){return A>=G?A=G:(A--,A|=A>>>1,A|=A>>>2,A|=A>>>4,A|=A>>>8,A|=A>>>16,A++),A}(A)),A<=e.length?A:e.ended?e.length:(e.needReadable=!0,0))}function F(A){var e=A._readableState;o("emitReadable",e.needReadable,e.emittedReadable),e.needReadable=!1,e.emittedReadable||(o("emitReadable",e.flowing),e.emittedReadable=!0,t.nextTick(N,A))}function N(A){var e=A._readableState;o("emitReadable_",e.destroyed,e.length,e.ended),e.destroyed||!e.length&&!e.ended||(A.emit("readable"),e.emittedReadable=!1),e.needReadable=!e.flowing&&!e.ended&&e.length<=e.highWaterMark,J(A)}function S(A,e){e.readingMore||(e.readingMore=!0,t.nextTick(Y,A,e))}function Y(A,e){for(;!e.reading&&!e.ended&&(e.length0,e.resumeScheduled&&!e.paused?e.flowing=!0:A.listenerCount("data")>0&&A.resume()}function K(A){o("readable nexttick read 0"),A.read(0)}function U(A,e){o("resume",e.reading),e.reading||A.read(0),e.resumeScheduled=!1,A.emit("resume"),J(A),e.flowing&&!e.reading&&A.read(0)}function J(A){var e=A._readableState;for(o("flow",e.flowing);e.flowing&&null!==A.read(););}function H(A,e){return 0===e.length?null:(e.objectMode?t=e.buffer.shift():!A||A>=e.length?(t=e.decoder?e.buffer.join(""):1===e.buffer.length?e.buffer.first():e.buffer.concat(e.length),e.buffer.clear()):t=e.buffer.consume(A,e.decoder),t);var t}function R(A){var e=A._readableState;o("endReadable",e.endEmitted),e.endEmitted||(e.ended=!0,t.nextTick(q,e,A))}function q(A,e){if(o("endReadableNT",A.endEmitted,A.length),!A.endEmitted&&0===A.length&&(A.endEmitted=!0,e.readable=!1,e.emit("end"),A.autoDestroy)){var t=e._writableState;(!t||t.autoDestroy&&t.finished)&&e.destroy()}}function L(A,e){for(var t=0,i=A.length;t=e.highWaterMark:e.length>0)||e.ended))return o("read: emitReadable",e.length,e.ended),0===e.length&&e.ended?R(this):F(this),null;if(0===(A=k(A,e))&&e.ended)return 0===e.length&&R(this),null;var i,g=e.needReadable;return o("need readable",g),(0===e.length||e.length-A0?H(A,e):null)?(e.needReadable=e.length<=e.highWaterMark,A=0):(e.length-=A,e.awaitDrain=0),0===e.length&&(e.ended||(e.needReadable=!0),t!==A&&e.ended&&R(this)),null!==i&&this.emit("data",i),i},y.prototype._read=function(A){p(this,new l("_read()"))},y.prototype.pipe=function(A,e){var i=this,g=this._readableState;switch(g.pipesCount){case 0:g.pipes=A;break;case 1:g.pipes=[g.pipes,A];break;default:g.pipes.push(A)}g.pipesCount+=1,o("pipe count=%d opts=%j",g.pipesCount,e);var n=(!e||!1!==e.end)&&A!==t.stdout&&A!==t.stderr?I:f;function B(e,t){o("onunpipe"),e===i&&t&&!1===t.hasUnpiped&&(t.hasUnpiped=!0,o("cleanup"),A.removeListener("close",c),A.removeListener("finish",h),A.removeListener("drain",a),A.removeListener("error",s),A.removeListener("unpipe",B),i.removeListener("end",I),i.removeListener("end",f),i.removeListener("data",C),Q=!0,!g.awaitDrain||A._writableState&&!A._writableState.needDrain||a())}function I(){o("onend"),A.end()}g.endEmitted?t.nextTick(n):i.once("end",n),A.on("unpipe",B);var a=function(A){return function(){var e=A._readableState;o("pipeOnDrain",e.awaitDrain),e.awaitDrain&&e.awaitDrain--,0===e.awaitDrain&&r(A,"data")&&(e.flowing=!0,J(A))}}(i);A.on("drain",a);var Q=!1;function C(e){o("ondata");var t=A.write(e);o("dest.write",t),!1===t&&((1===g.pipesCount&&g.pipes===A||g.pipesCount>1&&-1!==L(g.pipes,A))&&!Q&&(o("false write response, pause",g.awaitDrain),g.awaitDrain++),i.pause())}function s(e){o("onerror",e),f(),A.removeListener("error",s),0===r(A,"error")&&p(A,e)}function c(){A.removeListener("finish",h),f()}function h(){o("onfinish"),A.removeListener("close",c),f()}function f(){o("unpipe"),i.unpipe(A)}return i.on("data",C),function(A,e,t){if("function"==typeof A.prependListener)return A.prependListener(e,t);A._events&&A._events[e]?Array.isArray(A._events[e])?A._events[e].unshift(t):A._events[e]=[t,A._events[e]]:A.on(e,t)}(A,"error",s),A.once("close",c),A.once("finish",h),A.emit("pipe",i),g.flowing||(o("pipe resume"),i.resume()),A},y.prototype.unpipe=function(A){var e=this._readableState,t={hasUnpiped:!1};if(0===e.pipesCount)return this;if(1===e.pipesCount)return A&&A!==e.pipes?this:(A||(A=e.pipes),e.pipes=null,e.pipesCount=0,e.flowing=!1,A&&A.emit("unpipe",this,t),this);if(!A){var i=e.pipes,g=e.pipesCount;e.pipes=null,e.pipesCount=0,e.flowing=!1;for(var r=0;r0,!1!==g.flowing&&this.resume()):"readable"===A&&(g.endEmitted||g.readableListening||(g.readableListening=g.needReadable=!0,g.flowing=!1,g.emittedReadable=!1,o("on readable",g.length,g.reading),g.length?F(this):g.reading||t.nextTick(K,this))),i},y.prototype.addListener=y.prototype.on,y.prototype.removeListener=function(A,e){var i=n.prototype.removeListener.call(this,A,e);return"readable"===A&&t.nextTick(v,this),i},y.prototype.removeAllListeners=function(A){var e=n.prototype.removeAllListeners.apply(this,arguments);return"readable"!==A&&void 0!==A||t.nextTick(v,this),e},y.prototype.resume=function(){var A=this._readableState;return A.flowing||(o("resume"),A.flowing=!A.readableListening,function(A,e){e.resumeScheduled||(e.resumeScheduled=!0,t.nextTick(U,A,e))}(this,A)),A.paused=!1,this},y.prototype.pause=function(){return o("call pause flowing=%j",this._readableState.flowing),!1!==this._readableState.flowing&&(o("pause"),this._readableState.flowing=!1,this.emit("pause")),this._readableState.paused=!0,this},y.prototype.wrap=function(A){var e=this,t=this._readableState,i=!1;for(var g in A.on("end",function(){if(o("wrapped end"),t.decoder&&!t.ended){var A=t.decoder.end();A&&A.length&&e.push(A)}e.push(null)}),A.on("data",function(g){(o("wrapped data"),t.decoder&&(g=t.decoder.write(g)),!t.objectMode||null!==g&&void 0!==g)&&((t.objectMode||g&&g.length)&&(e.push(g)||(i=!0,A.pause())))}),A)void 0===this[g]&&"function"==typeof A[g]&&(this[g]=function(e){return function(){return A[e].apply(A,arguments)}}(g));for(var r=0;r-1))throw new w(A);return this._writableState.defaultEncoding=A,this},Object.defineProperty(y.prototype,"writableBuffer",{enumerable:!1,get:function(){return this._writableState&&this._writableState.getBuffer()}}),Object.defineProperty(y.prototype,"writableHighWaterMark",{enumerable:!1,get:function(){return this._writableState.highWaterMark}}),y.prototype._write=function(A,e,t){t(new h("_write()"))},y.prototype._writev=null,y.prototype.end=function(A,e,i){var g=this._writableState;return"function"==typeof A?(i=A,A=null,e=null):"function"==typeof e&&(i=e,e=null),null!==A&&void 0!==A&&this.write(A,e),g.corked&&(g.corked=1,this.uncork()),g.ending||function(A,e,i){e.ending=!0,N(A,e),i&&(e.finished?t.nextTick(i):A.once("finish",i));e.ended=!0,A.writable=!1}(this,g,i),this},Object.defineProperty(y.prototype,"writableLength",{enumerable:!1,get:function(){return this._writableState.length}}),Object.defineProperty(y.prototype,"destroyed",{enumerable:!1,get:function(){return void 0!==this._writableState&&this._writableState.destroyed},set:function(A){this._writableState&&(this._writableState.destroyed=A)}}),y.prototype.destroy=Q.destroy,y.prototype._undestroy=Q.undestroy,y.prototype._destroy=function(A,e){e(A)}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"../errors":48,"./_stream_duplex":49,"./internal/streams/destroy":56,"./internal/streams/state":60,"./internal/streams/stream":61,_process:154,buffer:64,inherits:134,"util-deprecate":193}],54:[function(A,e,t){(function(t){"use strict";var i;function g(A,e,t){return e in A?Object.defineProperty(A,e,{value:t,enumerable:!0,configurable:!0,writable:!0}):A[e]=t,A}var r=A("./end-of-stream"),n=Symbol("lastResolve"),B=Symbol("lastReject"),I=Symbol("error"),o=Symbol("ended"),a=Symbol("lastPromise"),Q=Symbol("handlePromise"),C=Symbol("stream");function s(A,e){return{value:A,done:e}}function c(A){var e=A[n];if(null!==e){var t=A[C].read();null!==t&&(A[a]=null,A[n]=null,A[B]=null,e(s(t,!1)))}}var h=Object.getPrototypeOf(function(){}),f=Object.setPrototypeOf((g(i={get stream(){return this[C]},next:function(){var A=this,e=this[I];if(null!==e)return Promise.reject(e);if(this[o])return Promise.resolve(s(void 0,!0));if(this[C].destroyed)return new Promise(function(e,i){t.nextTick(function(){A[I]?i(A[I]):e(s(void 0,!0))})});var i,g=this[a];if(g)i=new Promise(function(A,e){return function(t,i){A.then(function(){e[o]?t(s(void 0,!0)):e[Q](t,i)},i)}}(g,this));else{var r=this[C].read();if(null!==r)return Promise.resolve(s(r,!1));i=new Promise(this[Q])}return this[a]=i,i}},Symbol.asyncIterator,function(){return this}),g(i,"return",function(){var A=this;return new Promise(function(e,t){A[C].destroy(null,function(A){A?t(A):e(s(void 0,!0))})})}),i),h);e.exports=function(A){var e,i=Object.create(f,(g(e={},C,{value:A,writable:!0}),g(e,n,{value:null,writable:!0}),g(e,B,{value:null,writable:!0}),g(e,I,{value:null,writable:!0}),g(e,o,{value:A._readableState.endEmitted,writable:!0}),g(e,Q,{value:function(A,e){var t=i[C].read();t?(i[a]=null,i[n]=null,i[B]=null,A(s(t,!1))):(i[n]=A,i[B]=e)},writable:!0}),e));return i[a]=null,r(A,function(A){if(A&&"ERR_STREAM_PREMATURE_CLOSE"!==A.code){var e=i[B];return null!==e&&(i[a]=null,i[n]=null,i[B]=null,e(A)),void(i[I]=A)}var t=i[n];null!==t&&(i[a]=null,i[n]=null,i[B]=null,t(s(void 0,!0))),i[o]=!0}),A.on("readable",function(A){t.nextTick(c,A)}.bind(null,i)),i}}).call(this,A("_process"))},{"./end-of-stream":57,_process:154}],55:[function(A,e,t){"use strict";function i(A,e){var t=Object.keys(A);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(A);e&&(i=i.filter(function(e){return Object.getOwnPropertyDescriptor(A,e).enumerable})),t.push.apply(t,i)}return t}function g(A,e,t){return e in A?Object.defineProperty(A,e,{value:t,enumerable:!0,configurable:!0,writable:!0}):A[e]=t,A}function r(A,e){for(var t=0;t0?this.tail.next=e:this.head=e,this.tail=e,++this.length}},{key:"unshift",value:function(A){var e={data:A,next:this.head};0===this.length&&(this.tail=e),this.head=e,++this.length}},{key:"shift",value:function(){if(0!==this.length){var A=this.head.data;return 1===this.length?this.head=this.tail=null:this.head=this.head.next,--this.length,A}}},{key:"clear",value:function(){this.head=this.tail=null,this.length=0}},{key:"join",value:function(A){if(0===this.length)return"";for(var e=this.head,t=""+e.data;e=e.next;)t+=A+e.data;return t}},{key:"concat",value:function(A){if(0===this.length)return n.alloc(0);for(var e,t,i,g=n.allocUnsafe(A>>>0),r=this.head,B=0;r;)e=r.data,t=g,i=B,n.prototype.copy.call(e,t,i),B+=r.data.length,r=r.next;return g}},{key:"consume",value:function(A,e){var t;return Ag.length?g.length:A;if(r===g.length?i+=g:i+=g.slice(0,A),0===(A-=r)){r===g.length?(++t,e.next?this.head=e.next:this.head=this.tail=null):(this.head=e,e.data=g.slice(r));break}++t}return this.length-=t,i}},{key:"_getBuffer",value:function(A){var e=n.allocUnsafe(A),t=this.head,i=1;for(t.data.copy(e),A-=t.data.length;t=t.next;){var g=t.data,r=A>g.length?g.length:A;if(g.copy(e,e.length-A,0,r),0===(A-=r)){r===g.length?(++i,t.next?this.head=t.next:this.head=this.tail=null):(this.head=t,t.data=g.slice(r));break}++i}return this.length-=i,e}},{key:I,value:function(A,e){return B(this,function(A){for(var e=1;e0,function(A){a||(a=A),A&&C.forEach(I),r||(C.forEach(I),Q(a))})});return t.reduce(o)}},{"../../../errors":48,"./end-of-stream":57}],60:[function(A,e,t){"use strict";var i=A("../../../errors").codes.ERR_INVALID_OPT_VALUE;e.exports={getHighWaterMark:function(A,e,t,g){var r=function(A,e,t){return null!=A.highWaterMark?A.highWaterMark:e?A[t]:null}(e,g,t);if(null!=r){if(!isFinite(r)||Math.floor(r)!==r||r<0)throw new i(g?t:"highWaterMark",r);return Math.floor(r)}return A.objectMode?16:16384}}},{"../../../errors":48}],61:[function(A,e,t){e.exports=A("events").EventEmitter},{events:102}],62:[function(A,e,t){(t=e.exports=A("./lib/_stream_readable.js")).Stream=t,t.Readable=t,t.Writable=A("./lib/_stream_writable.js"),t.Duplex=A("./lib/_stream_duplex.js"),t.Transform=A("./lib/_stream_transform.js"),t.PassThrough=A("./lib/_stream_passthrough.js"),t.finished=A("./lib/internal/streams/end-of-stream.js"),t.pipeline=A("./lib/internal/streams/pipeline.js")},{"./lib/_stream_duplex.js":49,"./lib/_stream_passthrough.js":50,"./lib/_stream_readable.js":51,"./lib/_stream_transform.js":52,"./lib/_stream_writable.js":53,"./lib/internal/streams/end-of-stream.js":57,"./lib/internal/streams/pipeline.js":59}],63:[function(A,e,t){(function(A){e.exports=function(e,t){for(var i=Math.min(e.length,t.length),g=new A(i),r=0;rr)throw new RangeError('The value "'+A+'" is invalid for option "size"');var t=new Uint8Array(A);return t.__proto__=e.prototype,t}function e(A,e,t){if("number"==typeof A){if("string"==typeof e)throw new TypeError('The "string" argument must be of type string. Received type number');return o(A)}return B(A,e,t)}function B(A,t,i){if("string"==typeof A)return function(A,t){"string"==typeof t&&""!==t||(t="utf8");if(!e.isEncoding(t))throw new TypeError("Unknown encoding: "+t);var i=0|C(A,t),g=n(i),r=g.write(A,t);r!==i&&(g=g.slice(0,r));return g}(A,t);if(ArrayBuffer.isView(A))return a(A);if(null==A)throw TypeError("The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type "+typeof A);if(R(A,ArrayBuffer)||A&&R(A.buffer,ArrayBuffer))return function(A,t,i){if(t<0||A.byteLength=r)throw new RangeError("Attempt to allocate Buffer larger than maximum size: 0x"+r.toString(16)+" bytes");return 0|A}function C(A,t){if(e.isBuffer(A))return A.length;if(ArrayBuffer.isView(A)||R(A,ArrayBuffer))return A.byteLength;if("string"!=typeof A)throw new TypeError('The "string" argument must be one of type string, Buffer, or ArrayBuffer. Received type '+typeof A);var i=A.length,g=arguments.length>2&&!0===arguments[2];if(!g&&0===i)return 0;for(var r=!1;;)switch(t){case"ascii":case"latin1":case"binary":return i;case"utf8":case"utf-8":return U(A).length;case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return 2*i;case"hex":return i>>>1;case"base64":return J(A).length;default:if(r)return g?-1:U(A).length;t=(""+t).toLowerCase(),r=!0}}function s(A,e,t){var i=A[e];A[e]=A[t],A[t]=i}function c(A,t,i,g,r){if(0===A.length)return-1;if("string"==typeof i?(g=i,i=0):i>2147483647?i=2147483647:i<-2147483648&&(i=-2147483648),q(i=+i)&&(i=r?0:A.length-1),i<0&&(i=A.length+i),i>=A.length){if(r)return-1;i=A.length-1}else if(i<0){if(!r)return-1;i=0}if("string"==typeof t&&(t=e.from(t,g)),e.isBuffer(t))return 0===t.length?-1:h(A,t,i,g,r);if("number"==typeof t)return t&=255,"function"==typeof Uint8Array.prototype.indexOf?r?Uint8Array.prototype.indexOf.call(A,t,i):Uint8Array.prototype.lastIndexOf.call(A,t,i):h(A,[t],i,g,r);throw new TypeError("val must be string, number or Buffer")}function h(A,e,t,i,g){var r,n=1,B=A.length,I=e.length;if(void 0!==i&&("ucs2"===(i=String(i).toLowerCase())||"ucs-2"===i||"utf16le"===i||"utf-16le"===i)){if(A.length<2||e.length<2)return-1;n=2,B/=2,I/=2,t/=2}function o(A,e){return 1===n?A[e]:A.readUInt16BE(e*n)}if(g){var a=-1;for(r=t;rB&&(t=B-I),r=t;r>=0;r--){for(var Q=!0,C=0;Cg&&(i=g):i=g;var r=e.length;i>r/2&&(i=r/2);for(var n=0;n>8,g=t%256,r.push(g),r.push(i);return r}(e,A.length-t),A,t,i)}function p(A,e,t){return 0===e&&t===A.length?i.fromByteArray(A):i.fromByteArray(A.slice(e,t))}function D(A,e,t){t=Math.min(A.length,t);for(var i=[],g=e;g239?4:o>223?3:o>191?2:1;if(g+Q<=t)switch(Q){case 1:o<128&&(a=o);break;case 2:128==(192&(r=A[g+1]))&&(I=(31&o)<<6|63&r)>127&&(a=I);break;case 3:r=A[g+1],n=A[g+2],128==(192&r)&&128==(192&n)&&(I=(15&o)<<12|(63&r)<<6|63&n)>2047&&(I<55296||I>57343)&&(a=I);break;case 4:r=A[g+1],n=A[g+2],B=A[g+3],128==(192&r)&&128==(192&n)&&128==(192&B)&&(I=(15&o)<<18|(63&r)<<12|(63&n)<<6|63&B)>65535&&I<1114112&&(a=I)}null===a?(a=65533,Q=1):a>65535&&(a-=65536,i.push(a>>>10&1023|55296),a=56320|1023&a),i.push(a),g+=Q}return function(A){var e=A.length;if(e<=b)return String.fromCharCode.apply(String,A);var t="",i=0;for(;ithis.length)return"";if((void 0===t||t>this.length)&&(t=this.length),t<=0)return"";if((t>>>=0)<=(e>>>=0))return"";for(A||(A="utf8");;)switch(A){case"hex":return m(this,e,t);case"utf8":case"utf-8":return D(this,e,t);case"ascii":return y(this,e,t);case"latin1":case"binary":return M(this,e,t);case"base64":return p(this,e,t);case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return G(this,e,t);default:if(i)throw new TypeError("Unknown encoding: "+A);A=(A+"").toLowerCase(),i=!0}}.apply(this,arguments)},e.prototype.toLocaleString=e.prototype.toString,e.prototype.equals=function(A){if(!e.isBuffer(A))throw new TypeError("Argument must be a Buffer");return this===A||0===e.compare(this,A)},e.prototype.inspect=function(){var A="",e=t.INSPECT_MAX_BYTES;return A=this.toString("hex",0,e).replace(/(.{2})/g,"$1 ").trim(),this.length>e&&(A+=" ... "),""},e.prototype.compare=function(A,t,i,g,r){if(R(A,Uint8Array)&&(A=e.from(A,A.offset,A.byteLength)),!e.isBuffer(A))throw new TypeError('The "target" argument must be one of type Buffer or Uint8Array. Received type '+typeof A);if(void 0===t&&(t=0),void 0===i&&(i=A?A.length:0),void 0===g&&(g=0),void 0===r&&(r=this.length),t<0||i>A.length||g<0||r>this.length)throw new RangeError("out of range index");if(g>=r&&t>=i)return 0;if(g>=r)return-1;if(t>=i)return 1;if(t>>>=0,i>>>=0,g>>>=0,r>>>=0,this===A)return 0;for(var n=r-g,B=i-t,I=Math.min(n,B),o=this.slice(g,r),a=A.slice(t,i),Q=0;Q>>=0,isFinite(t)?(t>>>=0,void 0===i&&(i="utf8")):(i=t,t=void 0)}var g=this.length-e;if((void 0===t||t>g)&&(t=g),A.length>0&&(t<0||e<0)||e>this.length)throw new RangeError("Attempt to write outside buffer bounds");i||(i="utf8");for(var r=!1;;)switch(i){case"hex":return f(this,A,e,t);case"utf8":case"utf-8":return E(this,A,e,t);case"ascii":return u(this,A,e,t);case"latin1":case"binary":return d(this,A,e,t);case"base64":return l(this,A,e,t);case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return w(this,A,e,t);default:if(r)throw new TypeError("Unknown encoding: "+i);i=(""+i).toLowerCase(),r=!0}},e.prototype.toJSON=function(){return{type:"Buffer",data:Array.prototype.slice.call(this._arr||this,0)}};var b=4096;function y(A,e,t){var i="";t=Math.min(A.length,t);for(var g=e;gi)&&(t=i);for(var g="",r=e;rt)throw new RangeError("Trying to access beyond buffer length")}function F(A,t,i,g,r,n){if(!e.isBuffer(A))throw new TypeError('"buffer" argument must be a Buffer instance');if(t>r||tA.length)throw new RangeError("Index out of range")}function N(A,e,t,i,g,r){if(t+i>A.length)throw new RangeError("Index out of range");if(t<0)throw new RangeError("Index out of range")}function S(A,e,t,i,r){return e=+e,t>>>=0,r||N(A,0,t,4),g.write(A,e,t,i,23,4),t+4}function Y(A,e,t,i,r){return e=+e,t>>>=0,r||N(A,0,t,8),g.write(A,e,t,i,52,8),t+8}e.prototype.slice=function(A,t){var i=this.length;A=~~A,t=void 0===t?i:~~t,A<0?(A+=i)<0&&(A=0):A>i&&(A=i),t<0?(t+=i)<0&&(t=0):t>i&&(t=i),t>>=0,e>>>=0,t||k(A,e,this.length);for(var i=this[A],g=1,r=0;++r>>=0,e>>>=0,t||k(A,e,this.length);for(var i=this[A+--e],g=1;e>0&&(g*=256);)i+=this[A+--e]*g;return i},e.prototype.readUInt8=function(A,e){return A>>>=0,e||k(A,1,this.length),this[A]},e.prototype.readUInt16LE=function(A,e){return A>>>=0,e||k(A,2,this.length),this[A]|this[A+1]<<8},e.prototype.readUInt16BE=function(A,e){return A>>>=0,e||k(A,2,this.length),this[A]<<8|this[A+1]},e.prototype.readUInt32LE=function(A,e){return A>>>=0,e||k(A,4,this.length),(this[A]|this[A+1]<<8|this[A+2]<<16)+16777216*this[A+3]},e.prototype.readUInt32BE=function(A,e){return A>>>=0,e||k(A,4,this.length),16777216*this[A]+(this[A+1]<<16|this[A+2]<<8|this[A+3])},e.prototype.readIntLE=function(A,e,t){A>>>=0,e>>>=0,t||k(A,e,this.length);for(var i=this[A],g=1,r=0;++r=(g*=128)&&(i-=Math.pow(2,8*e)),i},e.prototype.readIntBE=function(A,e,t){A>>>=0,e>>>=0,t||k(A,e,this.length);for(var i=e,g=1,r=this[A+--i];i>0&&(g*=256);)r+=this[A+--i]*g;return r>=(g*=128)&&(r-=Math.pow(2,8*e)),r},e.prototype.readInt8=function(A,e){return A>>>=0,e||k(A,1,this.length),128&this[A]?-1*(255-this[A]+1):this[A]},e.prototype.readInt16LE=function(A,e){A>>>=0,e||k(A,2,this.length);var t=this[A]|this[A+1]<<8;return 32768&t?4294901760|t:t},e.prototype.readInt16BE=function(A,e){A>>>=0,e||k(A,2,this.length);var t=this[A+1]|this[A]<<8;return 32768&t?4294901760|t:t},e.prototype.readInt32LE=function(A,e){return A>>>=0,e||k(A,4,this.length),this[A]|this[A+1]<<8|this[A+2]<<16|this[A+3]<<24},e.prototype.readInt32BE=function(A,e){return A>>>=0,e||k(A,4,this.length),this[A]<<24|this[A+1]<<16|this[A+2]<<8|this[A+3]},e.prototype.readFloatLE=function(A,e){return A>>>=0,e||k(A,4,this.length),g.read(this,A,!0,23,4)},e.prototype.readFloatBE=function(A,e){return A>>>=0,e||k(A,4,this.length),g.read(this,A,!1,23,4)},e.prototype.readDoubleLE=function(A,e){return A>>>=0,e||k(A,8,this.length),g.read(this,A,!0,52,8)},e.prototype.readDoubleBE=function(A,e){return A>>>=0,e||k(A,8,this.length),g.read(this,A,!1,52,8)},e.prototype.writeUIntLE=function(A,e,t,i){(A=+A,e>>>=0,t>>>=0,i)||F(this,A,e,t,Math.pow(2,8*t)-1,0);var g=1,r=0;for(this[e]=255&A;++r>>=0,t>>>=0,i)||F(this,A,e,t,Math.pow(2,8*t)-1,0);var g=t-1,r=1;for(this[e+g]=255&A;--g>=0&&(r*=256);)this[e+g]=A/r&255;return e+t},e.prototype.writeUInt8=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,1,255,0),this[e]=255&A,e+1},e.prototype.writeUInt16LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,65535,0),this[e]=255&A,this[e+1]=A>>>8,e+2},e.prototype.writeUInt16BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,65535,0),this[e]=A>>>8,this[e+1]=255&A,e+2},e.prototype.writeUInt32LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,4294967295,0),this[e+3]=A>>>24,this[e+2]=A>>>16,this[e+1]=A>>>8,this[e]=255&A,e+4},e.prototype.writeUInt32BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,4294967295,0),this[e]=A>>>24,this[e+1]=A>>>16,this[e+2]=A>>>8,this[e+3]=255&A,e+4},e.prototype.writeIntLE=function(A,e,t,i){if(A=+A,e>>>=0,!i){var g=Math.pow(2,8*t-1);F(this,A,e,t,g-1,-g)}var r=0,n=1,B=0;for(this[e]=255&A;++r>0)-B&255;return e+t},e.prototype.writeIntBE=function(A,e,t,i){if(A=+A,e>>>=0,!i){var g=Math.pow(2,8*t-1);F(this,A,e,t,g-1,-g)}var r=t-1,n=1,B=0;for(this[e+r]=255&A;--r>=0&&(n*=256);)A<0&&0===B&&0!==this[e+r+1]&&(B=1),this[e+r]=(A/n>>0)-B&255;return e+t},e.prototype.writeInt8=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,1,127,-128),A<0&&(A=255+A+1),this[e]=255&A,e+1},e.prototype.writeInt16LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,32767,-32768),this[e]=255&A,this[e+1]=A>>>8,e+2},e.prototype.writeInt16BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,2,32767,-32768),this[e]=A>>>8,this[e+1]=255&A,e+2},e.prototype.writeInt32LE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,2147483647,-2147483648),this[e]=255&A,this[e+1]=A>>>8,this[e+2]=A>>>16,this[e+3]=A>>>24,e+4},e.prototype.writeInt32BE=function(A,e,t){return A=+A,e>>>=0,t||F(this,A,e,4,2147483647,-2147483648),A<0&&(A=4294967295+A+1),this[e]=A>>>24,this[e+1]=A>>>16,this[e+2]=A>>>8,this[e+3]=255&A,e+4},e.prototype.writeFloatLE=function(A,e,t){return S(this,A,e,!0,t)},e.prototype.writeFloatBE=function(A,e,t){return S(this,A,e,!1,t)},e.prototype.writeDoubleLE=function(A,e,t){return Y(this,A,e,!0,t)},e.prototype.writeDoubleBE=function(A,e,t){return Y(this,A,e,!1,t)},e.prototype.copy=function(A,t,i,g){if(!e.isBuffer(A))throw new TypeError("argument should be a Buffer");if(i||(i=0),g||0===g||(g=this.length),t>=A.length&&(t=A.length),t||(t=0),g>0&&g=this.length)throw new RangeError("Index out of range");if(g<0)throw new RangeError("sourceEnd out of bounds");g>this.length&&(g=this.length),A.length-t=0;--n)A[n+t]=this[n+i];else Uint8Array.prototype.set.call(A,this.subarray(i,g),t);return r},e.prototype.fill=function(A,t,i,g){if("string"==typeof A){if("string"==typeof t?(g=t,t=0,i=this.length):"string"==typeof i&&(g=i,i=this.length),void 0!==g&&"string"!=typeof g)throw new TypeError("encoding must be a string");if("string"==typeof g&&!e.isEncoding(g))throw new TypeError("Unknown encoding: "+g);if(1===A.length){var r=A.charCodeAt(0);("utf8"===g&&r<128||"latin1"===g)&&(A=r)}}else"number"==typeof A&&(A&=255);if(t<0||this.length>>=0,i=void 0===i?this.length:i>>>0,A||(A=0),"number"==typeof A)for(n=t;n55295&&t<57344){if(!g){if(t>56319){(e-=3)>-1&&r.push(239,191,189);continue}if(n+1===i){(e-=3)>-1&&r.push(239,191,189);continue}g=t;continue}if(t<56320){(e-=3)>-1&&r.push(239,191,189),g=t;continue}t=65536+(g-55296<<10|t-56320)}else g&&(e-=3)>-1&&r.push(239,191,189);if(g=null,t<128){if((e-=1)<0)break;r.push(t)}else if(t<2048){if((e-=2)<0)break;r.push(t>>6|192,63&t|128)}else if(t<65536){if((e-=3)<0)break;r.push(t>>12|224,t>>6&63|128,63&t|128)}else{if(!(t<1114112))throw new Error("Invalid code point");if((e-=4)<0)break;r.push(t>>18|240,t>>12&63|128,t>>6&63|128,63&t|128)}}return r}function J(A){return i.toByteArray(function(A){if((A=(A=A.split("=")[0]).trim().replace(v,"")).length<2)return"";for(;A.length%4!=0;)A+="=";return A}(A))}function H(A,e,t,i){for(var g=0;g=e.length||g>=A.length);++g)e[g+t]=A[g];return g}function R(A,e){return A instanceof e||null!=A&&null!=A.constructor&&null!=A.constructor.name&&A.constructor.name===e.name}function q(A){return A!=A}}).call(this,A("buffer").Buffer)},{"base64-js":16,buffer:64,ieee754:133}],65:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("stream").Transform,r=A("string_decoder").StringDecoder;function n(A){g.call(this),this.hashMode="string"==typeof A,this.hashMode?this[A]=this._finalOrDigest:this.final=this._finalOrDigest,this._final&&(this.__final=this._final,this._final=null),this._decoder=null,this._encoding=null}A("inherits")(n,g),n.prototype.update=function(A,e,t){"string"==typeof A&&(A=i.from(A,e));var g=this._update(A);return this.hashMode?this:(t&&(g=this._toString(g,t)),g)},n.prototype.setAutoPadding=function(){},n.prototype.getAuthTag=function(){throw new Error("trying to get auth tag in unsupported state")},n.prototype.setAuthTag=function(){throw new Error("trying to set auth tag in unsupported state")},n.prototype.setAAD=function(){throw new Error("trying to set aad in unsupported state")},n.prototype._transform=function(A,e,t){var i;try{this.hashMode?this._update(A):this.push(this._update(A))}catch(A){i=A}finally{t(i)}},n.prototype._flush=function(A){var e;try{this.push(this.__final())}catch(A){e=A}A(e)},n.prototype._finalOrDigest=function(A){var e=this.__final()||i.alloc(0);return A&&(e=this._toString(e,A,!0)),e},n.prototype._toString=function(A,e,t){if(this._decoder||(this._decoder=new r(e),this._encoding=e),this._encoding!==e)throw new Error("can't switch encodings");var i=this._decoder.write(A);return t&&(i+=this._decoder.end()),i},e.exports=n},{inherits:134,"safe-buffer":180,stream:190,string_decoder:191}],66:[function(A,e,t){(function(A){function e(A){return Object.prototype.toString.call(A)}t.isArray=function(A){return Array.isArray?Array.isArray(A):"[object Array]"===e(A)},t.isBoolean=function(A){return"boolean"==typeof A},t.isNull=function(A){return null===A},t.isNullOrUndefined=function(A){return null==A},t.isNumber=function(A){return"number"==typeof A},t.isString=function(A){return"string"==typeof A},t.isSymbol=function(A){return"symbol"==typeof A},t.isUndefined=function(A){return void 0===A},t.isRegExp=function(A){return"[object RegExp]"===e(A)},t.isObject=function(A){return"object"==typeof A&&null!==A},t.isDate=function(A){return"[object Date]"===e(A)},t.isError=function(A){return"[object Error]"===e(A)||A instanceof Error},t.isFunction=function(A){return"function"==typeof A},t.isPrimitive=function(A){return null===A||"boolean"==typeof A||"number"==typeof A||"string"==typeof A||"symbol"==typeof A||void 0===A},t.isBuffer=A.isBuffer}).call(this,{isBuffer:A("../../is-buffer/index.js")})},{"../../is-buffer/index.js":135}],67:[function(A,e,t){(function(t){var i=A("elliptic"),g=A("bn.js");e.exports=function(A){return new n(A)};var r={secp256k1:{name:"secp256k1",byteLength:32},secp224r1:{name:"p224",byteLength:28},prime256v1:{name:"p256",byteLength:32},prime192v1:{name:"p192",byteLength:24},ed25519:{name:"ed25519",byteLength:32},secp384r1:{name:"p384",byteLength:48},secp521r1:{name:"p521",byteLength:66}};function n(A){this.curveType=r[A],this.curveType||(this.curveType={name:A}),this.curve=new i.ec(this.curveType.name),this.keys=void 0}function B(A,e,i){Array.isArray(A)||(A=A.toArray());var g=new t(A);if(i&&g.lengtht)?e=("rmd160"===A?new I:o(A)).update(e).digest():e.lengthB?e=A(e):e.length0;i--)e+=this._buffer(A,e),t+=this._flushBuffer(g,t);return e+=this._buffer(A,e),g},g.prototype.final=function(A){var e,t;return A&&(e=this.update(A)),t="encrypt"===this.type?this._finalEncrypt():this._finalDecrypt(),e?e.concat(t):t},g.prototype._pad=function(A,e){if(0===e)return!1;for(;e>>1];t=r.r28shl(t,B),g=r.r28shl(g,B),r.pc2(t,g,A.keys,n)}},B.prototype._update=function(A,e,t,i){var g=this._desState,n=r.readUInt32BE(A,e),B=r.readUInt32BE(A,e+4);r.ip(n,B,g.tmp,0),n=g.tmp[0],B=g.tmp[1],"encrypt"===this.type?this._encrypt(g,n,B,g.tmp,0):this._decrypt(g,n,B,g.tmp,0),n=g.tmp[0],B=g.tmp[1],r.writeUInt32BE(t,n,i),r.writeUInt32BE(t,B,i+4)},B.prototype._pad=function(A,e){for(var t=A.length-e,i=e;i>>0,n=C}r.rip(B,n,i,g)},B.prototype._decrypt=function(A,e,t,i,g){for(var n=t,B=e,I=A.keys.length-2;I>=0;I-=2){var o=A.keys[I],a=A.keys[I+1];r.expand(n,A.tmp,0),o^=A.tmp[0],a^=A.tmp[1];var Q=r.substitute(o,a),C=n;n=(B^r.permute(Q))>>>0,B=C}r.rip(n,B,i,g)}},{"./cipher":76,"./utils":79,inherits:134,"minimalistic-assert":140}],78:[function(A,e,t){"use strict";var i=A("minimalistic-assert"),g=A("inherits"),r=A("./cipher"),n=A("./des");function B(A){r.call(this,A);var e=new function(A,e){i.equal(e.length,24,"Invalid key length");var t=e.slice(0,8),g=e.slice(8,16),r=e.slice(16,24);this.ciphers="encrypt"===A?[n.create({type:"encrypt",key:t}),n.create({type:"decrypt",key:g}),n.create({type:"encrypt",key:r})]:[n.create({type:"decrypt",key:r}),n.create({type:"encrypt",key:g}),n.create({type:"decrypt",key:t})]}(this.type,this.options.key);this._edeState=e}g(B,r),e.exports=B,B.create=function(A){return new B(A)},B.prototype._update=function(A,e,t,i){var g=this._edeState;g.ciphers[0]._update(A,e,t,i),g.ciphers[1]._update(t,i,t,i),g.ciphers[2]._update(t,i,t,i)},B.prototype._pad=n.prototype._pad,B.prototype._unpad=n.prototype._unpad},{"./cipher":76,"./des":77,inherits:134,"minimalistic-assert":140}],79:[function(A,e,t){"use strict";t.readUInt32BE=function(A,e){return(A[0+e]<<24|A[1+e]<<16|A[2+e]<<8|A[3+e])>>>0},t.writeUInt32BE=function(A,e,t){A[0+t]=e>>>24,A[1+t]=e>>>16&255,A[2+t]=e>>>8&255,A[3+t]=255&e},t.ip=function(A,e,t,i){for(var g=0,r=0,n=6;n>=0;n-=2){for(var B=0;B<=24;B+=8)g<<=1,g|=e>>>B+n&1;for(B=0;B<=24;B+=8)g<<=1,g|=A>>>B+n&1}for(n=6;n>=0;n-=2){for(B=1;B<=25;B+=8)r<<=1,r|=e>>>B+n&1;for(B=1;B<=25;B+=8)r<<=1,r|=A>>>B+n&1}t[i+0]=g>>>0,t[i+1]=r>>>0},t.rip=function(A,e,t,i){for(var g=0,r=0,n=0;n<4;n++)for(var B=24;B>=0;B-=8)g<<=1,g|=e>>>B+n&1,g<<=1,g|=A>>>B+n&1;for(n=4;n<8;n++)for(B=24;B>=0;B-=8)r<<=1,r|=e>>>B+n&1,r<<=1,r|=A>>>B+n&1;t[i+0]=g>>>0,t[i+1]=r>>>0},t.pc1=function(A,e,t,i){for(var g=0,r=0,n=7;n>=5;n--){for(var B=0;B<=24;B+=8)g<<=1,g|=e>>B+n&1;for(B=0;B<=24;B+=8)g<<=1,g|=A>>B+n&1}for(B=0;B<=24;B+=8)g<<=1,g|=e>>B+n&1;for(n=1;n<=3;n++){for(B=0;B<=24;B+=8)r<<=1,r|=e>>B+n&1;for(B=0;B<=24;B+=8)r<<=1,r|=A>>B+n&1}for(B=0;B<=24;B+=8)r<<=1,r|=A>>B+n&1;t[i+0]=g>>>0,t[i+1]=r>>>0},t.r28shl=function(A,e){return A<>>28-e};var i=[14,11,17,4,27,23,25,0,13,22,7,18,5,9,16,24,2,20,12,21,1,8,15,26,15,4,25,19,9,1,26,16,5,11,23,8,12,7,17,0,22,3,10,14,6,20,27,24];t.pc2=function(A,e,t,g){for(var r=0,n=0,B=i.length>>>1,I=0;I>>i[I]&1;for(I=B;I>>i[I]&1;t[g+0]=r>>>0,t[g+1]=n>>>0},t.expand=function(A,e,t){var i=0,g=0;i=(1&A)<<5|A>>>27;for(var r=23;r>=15;r-=4)i<<=6,i|=A>>>r&63;for(r=11;r>=3;r-=4)g|=A>>>r&63,g<<=6;g|=(31&A)<<1|A>>>31,e[t+0]=i>>>0,e[t+1]=g>>>0};var g=[14,0,4,15,13,7,1,4,2,14,15,2,11,13,8,1,3,10,10,6,6,12,12,11,5,9,9,5,0,3,7,8,4,15,1,12,14,8,8,2,13,4,6,9,2,1,11,7,15,5,12,11,9,3,7,14,3,10,10,0,5,6,0,13,15,3,1,13,8,4,14,7,6,15,11,2,3,8,4,14,9,12,7,0,2,1,13,10,12,6,0,9,5,11,10,5,0,13,14,8,7,10,11,1,10,3,4,15,13,4,1,2,5,11,8,6,12,7,6,12,9,0,3,5,2,14,15,9,10,13,0,7,9,0,14,9,6,3,3,4,15,6,5,10,1,2,13,8,12,5,7,14,11,12,4,11,2,15,8,1,13,1,6,10,4,13,9,0,8,6,15,9,3,8,0,7,11,4,1,15,2,14,12,3,5,11,10,5,14,2,7,12,7,13,13,8,14,11,3,5,0,6,6,15,9,0,10,3,1,4,2,7,8,2,5,12,11,1,12,10,4,14,15,9,10,3,6,15,9,0,0,6,12,10,11,1,7,13,13,8,15,9,1,4,3,5,14,11,5,12,2,7,8,2,4,14,2,14,12,11,4,2,1,12,7,4,10,7,11,13,6,1,8,5,5,0,3,15,15,10,13,3,0,9,14,8,9,6,4,11,2,8,1,12,11,7,10,1,13,14,7,2,8,13,15,6,9,15,12,0,5,9,6,10,3,4,0,5,14,3,12,10,1,15,10,4,15,2,9,7,2,12,6,9,8,5,0,6,13,1,3,13,4,14,14,0,7,11,5,3,11,8,9,4,14,3,15,2,5,12,2,9,8,5,12,15,3,10,7,11,0,14,4,1,10,7,1,6,13,0,11,8,6,13,4,13,11,0,2,11,14,7,15,4,0,9,8,1,13,10,3,14,12,3,9,5,7,12,5,2,10,15,6,8,1,6,1,6,4,11,11,13,13,8,12,1,3,4,7,10,14,7,10,9,15,5,6,0,8,15,0,14,5,2,9,3,2,12,13,1,2,15,8,13,4,8,6,10,15,3,11,7,1,4,10,12,9,5,3,6,14,11,5,0,0,14,12,9,7,2,7,2,11,1,4,14,1,7,9,4,12,10,14,8,2,13,0,15,6,12,10,9,13,0,15,3,3,5,5,6,8,11];t.substitute=function(A,e){for(var t=0,i=0;i<4;i++){t<<=4,t|=g[64*i+(A>>>18-6*i&63)]}for(i=0;i<4;i++){t<<=4,t|=g[256+64*i+(e>>>18-6*i&63)]}return t>>>0};var r=[16,25,12,11,3,20,4,15,31,17,9,6,27,14,1,22,30,24,8,18,0,5,29,23,13,19,2,26,10,21,28,7];t.permute=function(A){for(var e=0,t=0;t>>r[t]&1;return e>>>0},t.padSplit=function(A,e,t){for(var i=A.toString(2);i.lengthA;)t.ishrn(1);if(t.isEven()&&t.iadd(B),t.testn(1)||t.iadd(I),e.cmp(I)){if(!e.cmp(o))for(;t.mod(a).cmp(Q);)t.iadd(s)}else for(;t.mod(r).cmp(C);)t.iadd(s);if(f(c=t.shrn(1))&&f(t)&&E(c)&&E(t)&&n.test(c)&&n.test(t))return t}}},{"bn.js":84,"miller-rabin":138,randombytes:162}],83:[function(A,e,t){e.exports={modp1:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a63a3620ffffffffffffffff"},modp2:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece65381ffffffffffffffff"},modp5:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca237327ffffffffffffffff"},modp14:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aacaa68ffffffffffffffff"},modp15:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a93ad2caffffffffffffffff"},modp16:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c934063199ffffffffffffffff"},modp17:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dcc4024ffffffffffffffff"},modp18:{gen:"02",prime:"ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d670c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb850458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fbecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c08f4df435c93402849236c3fab4d27c7026c1d4dcb2602646dec9751e763dba37bdf8ff9406ad9e530ee5db382f413001aeb06a53ed9027d831179727b0865a8918da3edbebcf9b14ed44ce6cbaced4bb1bdb7f1447e6cc254b332051512bd7af426fb8f401378cd2bf5983ca01c64b92ecf032ea15d1721d03f482d7ce6e74fef6d55e702f46980c82b5a84031900b1c9e59e7c97fbec7e8f323a97a7e36cc88be0f1d45b7ff585ac54bd407b22b4154aacc8f6d7ebf48e1d814cc5ed20f8037e0a79715eef29be32806a1d58bb7c5da76f550aa3d8a1fbff0eb19ccb1a313d55cda56c9ec2ef29632387fe8d76e3c0468043e8f663f4860ee12bf2d5b0b7474d6e694f91e6dbe115974a3926f12fee5e438777cb6a932df8cd8bec4d073b931ba3bc832b68d9dd300741fa7bf8afc47ed2576f6936ba424663aab639c5ae4f5683423b4742bf1c978238f16cbe39d652de3fdb8befc848ad922222e04a4037c0713eb57a81a23f0c73473fc646cea306b4bcbc8862f8385ddfa9d4b7fa2c087e879683303ed5bdd3a062b3cf5b3a278a66d2a13f83f44f82ddf310ee074ab6a364597e899a0255dc164f31cc50846851df9ab48195ded7ea1b1d510bd7ee74d73faf36bc31ecfa268359046f4eb879f924009438b481c6cd7889a002ed5ee382bc9190da6fc026e479558e4475677e9aa9e3050e2765694dfc81f56e880b96e7160c980dd98edd3dfffffffffffffffff"}}},{}],84:[function(A,e,t){arguments[4][15][0].apply(t,arguments)},{buffer:19,dup:15}],85:[function(A,e,t){"use strict";var i=t;i.version=A("../package.json").version,i.utils=A("./elliptic/utils"),i.rand=A("brorand"),i.curve=A("./elliptic/curve"),i.curves=A("./elliptic/curves"),i.ec=A("./elliptic/ec"),i.eddsa=A("./elliptic/eddsa")},{"../package.json":101,"./elliptic/curve":88,"./elliptic/curves":91,"./elliptic/ec":92,"./elliptic/eddsa":95,"./elliptic/utils":99,brorand:18}],86:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("../utils"),r=g.getNAF,n=g.getJSF,B=g.assert;function I(A,e){this.type=A,this.p=new i(e.p,16),this.red=e.prime?i.red(e.prime):i.mont(this.p),this.zero=new i(0).toRed(this.red),this.one=new i(1).toRed(this.red),this.two=new i(2).toRed(this.red),this.n=e.n&&new i(e.n,16),this.g=e.g&&this.pointFromJSON(e.g,e.gRed),this._wnafT1=new Array(4),this._wnafT2=new Array(4),this._wnafT3=new Array(4),this._wnafT4=new Array(4),this._bitLength=this.n?this.n.bitLength():0;var t=this.n&&this.p.div(this.n);!t||t.cmpn(100)>0?this.redN=null:(this._maxwellTrick=!0,this.redN=this.n.toRed(this.red))}function o(A,e){this.curve=A,this.type=e,this.precomputed=null}e.exports=I,I.prototype.point=function(){throw new Error("Not implemented")},I.prototype.validate=function(){throw new Error("Not implemented")},I.prototype._fixedNafMul=function(A,e){B(A.precomputed);var t=A._getDoubles(),i=r(e,1,this._bitLength),g=(1<=I;e--)o=(o<<1)+i[e];n.push(o)}for(var a=this.jpoint(null,null,null),Q=this.jpoint(null,null,null),C=g;C>0;C--){for(I=0;I=0;o--){for(e=0;o>=0&&0===n[o];o--)e++;if(o>=0&&e++,I=I.dblp(e),o<0)break;var a=n[o];B(0!==a),I="affine"===A.type?a>0?I.mixedAdd(g[a-1>>1]):I.mixedAdd(g[-a-1>>1].neg()):a>0?I.add(g[a-1>>1]):I.add(g[-a-1>>1].neg())}return"affine"===A.type?I.toP():I},I.prototype._wnafMulAdd=function(A,e,t,i,g){for(var B=this._wnafT1,I=this._wnafT2,o=this._wnafT3,a=0,Q=0;Q=1;Q-=2){var s=Q-1,c=Q;if(1===B[s]&&1===B[c]){var h=[e[s],null,null,e[c]];0===e[s].y.cmp(e[c].y)?(h[1]=e[s].add(e[c]),h[2]=e[s].toJ().mixedAdd(e[c].neg())):0===e[s].y.cmp(e[c].y.redNeg())?(h[1]=e[s].toJ().mixedAdd(e[c]),h[2]=e[s].add(e[c].neg())):(h[1]=e[s].toJ().mixedAdd(e[c]),h[2]=e[s].toJ().mixedAdd(e[c].neg()));var f=[-3,-1,-5,-7,0,7,5,1,3],E=n(t[s],t[c]);a=Math.max(E[0].length,a),o[s]=new Array(a),o[c]=new Array(a);for(var u=0;u=0;Q--){for(var D=0;Q>=0;){var b=!0;for(u=0;u=0&&D++,w=w.dblp(D),Q<0)break;for(u=0;u0?y=I[u][M-1>>1]:M<0&&(y=I[u][-M-1>>1].neg()),w="affine"===y.type?w.mixedAdd(y):w.add(y))}}for(Q=0;Q=Math.ceil((A.bitLength()+1)/e.step)},o.prototype._getDoubles=function(A,e){if(this.precomputed&&this.precomputed.doubles)return this.precomputed.doubles;for(var t=[this],i=this,g=0;g":""},o.prototype.isInfinity=function(){return 0===this.x.cmpn(0)&&(0===this.y.cmp(this.z)||this.zOne&&0===this.y.cmp(this.curve.c))},o.prototype._extDbl=function(){var A=this.x.redSqr(),e=this.y.redSqr(),t=this.z.redSqr();t=t.redIAdd(t);var i=this.curve._mulA(A),g=this.x.redAdd(this.y).redSqr().redISub(A).redISub(e),r=i.redAdd(e),n=r.redSub(t),B=i.redSub(e),I=g.redMul(n),o=r.redMul(B),a=g.redMul(B),Q=n.redMul(r);return this.curve.point(I,o,Q,a)},o.prototype._projDbl=function(){var A,e,t,i=this.x.redAdd(this.y).redSqr(),g=this.x.redSqr(),r=this.y.redSqr();if(this.curve.twisted){var n=(o=this.curve._mulA(g)).redAdd(r);if(this.zOne)A=i.redSub(g).redSub(r).redMul(n.redSub(this.curve.two)),e=n.redMul(o.redSub(r)),t=n.redSqr().redSub(n).redSub(n);else{var B=this.z.redSqr(),I=n.redSub(B).redISub(B);A=i.redSub(g).redISub(r).redMul(I),e=n.redMul(o.redSub(r)),t=n.redMul(I)}}else{var o=g.redAdd(r);B=this.curve._mulC(this.z).redSqr(),I=o.redSub(B).redSub(B);A=this.curve._mulC(i.redISub(o)).redMul(I),e=this.curve._mulC(o).redMul(g.redISub(r)),t=o.redMul(I)}return this.curve.point(A,e,t)},o.prototype.dbl=function(){return this.isInfinity()?this:this.curve.extended?this._extDbl():this._projDbl()},o.prototype._extAdd=function(A){var e=this.y.redSub(this.x).redMul(A.y.redSub(A.x)),t=this.y.redAdd(this.x).redMul(A.y.redAdd(A.x)),i=this.t.redMul(this.curve.dd).redMul(A.t),g=this.z.redMul(A.z.redAdd(A.z)),r=t.redSub(e),n=g.redSub(i),B=g.redAdd(i),I=t.redAdd(e),o=r.redMul(n),a=B.redMul(I),Q=r.redMul(I),C=n.redMul(B);return this.curve.point(o,a,C,Q)},o.prototype._projAdd=function(A){var e,t,i=this.z.redMul(A.z),g=i.redSqr(),r=this.x.redMul(A.x),n=this.y.redMul(A.y),B=this.curve.d.redMul(r).redMul(n),I=g.redSub(B),o=g.redAdd(B),a=this.x.redAdd(this.y).redMul(A.x.redAdd(A.y)).redISub(r).redISub(n),Q=i.redMul(I).redMul(a);return this.curve.twisted?(e=i.redMul(o).redMul(n.redSub(this.curve._mulA(r))),t=I.redMul(o)):(e=i.redMul(o).redMul(n.redSub(r)),t=this.curve._mulC(I).redMul(o)),this.curve.point(Q,e,t)},o.prototype.add=function(A){return this.isInfinity()?A:A.isInfinity()?this:this.curve.extended?this._extAdd(A):this._projAdd(A)},o.prototype.mul=function(A){return this._hasDoubles(A)?this.curve._fixedNafMul(this,A):this.curve._wnafMul(this,A)},o.prototype.mulAdd=function(A,e,t){return this.curve._wnafMulAdd(1,[this,e],[A,t],2,!1)},o.prototype.jmulAdd=function(A,e,t){return this.curve._wnafMulAdd(1,[this,e],[A,t],2,!0)},o.prototype.normalize=function(){if(this.zOne)return this;var A=this.z.redInvm();return this.x=this.x.redMul(A),this.y=this.y.redMul(A),this.t&&(this.t=this.t.redMul(A)),this.z=this.curve.one,this.zOne=!0,this},o.prototype.neg=function(){return this.curve.point(this.x.redNeg(),this.y,this.z,this.t&&this.t.redNeg())},o.prototype.getX=function(){return this.normalize(),this.x.fromRed()},o.prototype.getY=function(){return this.normalize(),this.y.fromRed()},o.prototype.eq=function(A){return this===A||0===this.getX().cmp(A.getX())&&0===this.getY().cmp(A.getY())},o.prototype.eqXToP=function(A){var e=A.toRed(this.curve.red).redMul(this.z);if(0===this.x.cmp(e))return!0;for(var t=A.clone(),i=this.curve.redN.redMul(this.z);;){if(t.iadd(this.curve.n),t.cmp(this.curve.p)>=0)return!1;if(e.redIAdd(i),0===this.x.cmp(e))return!0}},o.prototype.toP=o.prototype.normalize,o.prototype.mixedAdd=o.prototype.add},{"../utils":99,"./base":86,"bn.js":100,inherits:134}],88:[function(A,e,t){"use strict";var i=t;i.base=A("./base"),i.short=A("./short"),i.mont=A("./mont"),i.edwards=A("./edwards")},{"./base":86,"./edwards":87,"./mont":89,"./short":90}],89:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("inherits"),r=A("./base"),n=A("../utils");function B(A){r.call(this,"mont",A),this.a=new i(A.a,16).toRed(this.red),this.b=new i(A.b,16).toRed(this.red),this.i4=new i(4).toRed(this.red).redInvm(),this.two=new i(2).toRed(this.red),this.a24=this.i4.redMul(this.a.redAdd(this.two))}function I(A,e,t){r.BasePoint.call(this,A,"projective"),null===e&&null===t?(this.x=this.curve.one,this.z=this.curve.zero):(this.x=new i(e,16),this.z=new i(t,16),this.x.red||(this.x=this.x.toRed(this.curve.red)),this.z.red||(this.z=this.z.toRed(this.curve.red)))}g(B,r),e.exports=B,B.prototype.validate=function(A){var e=A.normalize().x,t=e.redSqr(),i=t.redMul(e).redAdd(t.redMul(this.a)).redAdd(e);return 0===i.redSqrt().redSqr().cmp(i)},g(I,r.BasePoint),B.prototype.decodePoint=function(A,e){return this.point(n.toArray(A,e),1)},B.prototype.point=function(A,e){return new I(this,A,e)},B.prototype.pointFromJSON=function(A){return I.fromJSON(this,A)},I.prototype.precompute=function(){},I.prototype._encode=function(){return this.getX().toArray("be",this.curve.p.byteLength())},I.fromJSON=function(A,e){return new I(A,e[0],e[1]||A.one)},I.prototype.inspect=function(){return this.isInfinity()?"":""},I.prototype.isInfinity=function(){return 0===this.z.cmpn(0)},I.prototype.dbl=function(){var A=this.x.redAdd(this.z).redSqr(),e=this.x.redSub(this.z).redSqr(),t=A.redSub(e),i=A.redMul(e),g=t.redMul(e.redAdd(this.curve.a24.redMul(t)));return this.curve.point(i,g)},I.prototype.add=function(){throw new Error("Not supported on Montgomery curve")},I.prototype.diffAdd=function(A,e){var t=this.x.redAdd(this.z),i=this.x.redSub(this.z),g=A.x.redAdd(A.z),r=A.x.redSub(A.z).redMul(t),n=g.redMul(i),B=e.z.redMul(r.redAdd(n).redSqr()),I=e.x.redMul(r.redISub(n).redSqr());return this.curve.point(B,I)},I.prototype.mul=function(A){for(var e=A.clone(),t=this,i=this.curve.point(null,null),g=[];0!==e.cmpn(0);e.iushrn(1))g.push(e.andln(1));for(var r=g.length-1;r>=0;r--)0===g[r]?(t=t.diffAdd(i,this),i=i.dbl()):(i=t.diffAdd(i,this),t=t.dbl());return i},I.prototype.mulAdd=function(){throw new Error("Not supported on Montgomery curve")},I.prototype.jumlAdd=function(){throw new Error("Not supported on Montgomery curve")},I.prototype.eq=function(A){return 0===this.getX().cmp(A.getX())},I.prototype.normalize=function(){return this.x=this.x.redMul(this.z.redInvm()),this.z=this.curve.one,this},I.prototype.getX=function(){return this.normalize(),this.x.fromRed()}},{"../utils":99,"./base":86,"bn.js":100,inherits:134}],90:[function(A,e,t){"use strict";var i=A("../utils"),g=A("bn.js"),r=A("inherits"),n=A("./base"),B=i.assert;function I(A){n.call(this,"short",A),this.a=new g(A.a,16).toRed(this.red),this.b=new g(A.b,16).toRed(this.red),this.tinv=this.two.redInvm(),this.zeroA=0===this.a.fromRed().cmpn(0),this.threeA=0===this.a.fromRed().sub(this.p).cmpn(-3),this.endo=this._getEndomorphism(A),this._endoWnafT1=new Array(4),this._endoWnafT2=new Array(4)}function o(A,e,t,i){n.BasePoint.call(this,A,"affine"),null===e&&null===t?(this.x=null,this.y=null,this.inf=!0):(this.x=new g(e,16),this.y=new g(t,16),i&&(this.x.forceRed(this.curve.red),this.y.forceRed(this.curve.red)),this.x.red||(this.x=this.x.toRed(this.curve.red)),this.y.red||(this.y=this.y.toRed(this.curve.red)),this.inf=!1)}function a(A,e,t,i){n.BasePoint.call(this,A,"jacobian"),null===e&&null===t&&null===i?(this.x=this.curve.one,this.y=this.curve.one,this.z=new g(0)):(this.x=new g(e,16),this.y=new g(t,16),this.z=new g(i,16)),this.x.red||(this.x=this.x.toRed(this.curve.red)),this.y.red||(this.y=this.y.toRed(this.curve.red)),this.z.red||(this.z=this.z.toRed(this.curve.red)),this.zOne=this.z===this.curve.one}r(I,n),e.exports=I,I.prototype._getEndomorphism=function(A){if(this.zeroA&&this.g&&this.n&&1===this.p.modn(3)){var e,t;if(A.beta)e=new g(A.beta,16).toRed(this.red);else{var i=this._getEndoRoots(this.p);e=(e=i[0].cmp(i[1])<0?i[0]:i[1]).toRed(this.red)}if(A.lambda)t=new g(A.lambda,16);else{var r=this._getEndoRoots(this.n);0===this.g.mul(r[0]).x.cmp(this.g.x.redMul(e))?t=r[0]:(t=r[1],B(0===this.g.mul(t).x.cmp(this.g.x.redMul(e))))}return{beta:e,lambda:t,basis:A.basis?A.basis.map(function(A){return{a:new g(A.a,16),b:new g(A.b,16)}}):this._getEndoBasis(t)}}},I.prototype._getEndoRoots=function(A){var e=A===this.p?this.red:g.mont(A),t=new g(2).toRed(e).redInvm(),i=t.redNeg(),r=new g(3).toRed(e).redNeg().redSqrt().redMul(t);return[i.redAdd(r).fromRed(),i.redSub(r).fromRed()]},I.prototype._getEndoBasis=function(A){for(var e,t,i,r,n,B,I,o,a,Q=this.n.ushrn(Math.floor(this.n.bitLength()/2)),C=A,s=this.n.clone(),c=new g(1),h=new g(0),f=new g(0),E=new g(1),u=0;0!==C.cmpn(0);){var d=s.div(C);o=s.sub(d.mul(C)),a=f.sub(d.mul(c));var l=E.sub(d.mul(h));if(!i&&o.cmp(Q)<0)e=I.neg(),t=c,i=o.neg(),r=a;else if(i&&2==++u)break;I=o,s=C,C=o,f=c,c=a,E=h,h=l}n=o.neg(),B=a;var w=i.sqr().add(r.sqr());return n.sqr().add(B.sqr()).cmp(w)>=0&&(n=e,B=t),i.negative&&(i=i.neg(),r=r.neg()),n.negative&&(n=n.neg(),B=B.neg()),[{a:i,b:r},{a:n,b:B}]},I.prototype._endoSplit=function(A){var e=this.endo.basis,t=e[0],i=e[1],g=i.b.mul(A).divRound(this.n),r=t.b.neg().mul(A).divRound(this.n),n=g.mul(t.a),B=r.mul(i.a),I=g.mul(t.b),o=r.mul(i.b);return{k1:A.sub(n).sub(B),k2:I.add(o).neg()}},I.prototype.pointFromX=function(A,e){(A=new g(A,16)).red||(A=A.toRed(this.red));var t=A.redSqr().redMul(A).redIAdd(A.redMul(this.a)).redIAdd(this.b),i=t.redSqrt();if(0!==i.redSqr().redSub(t).cmp(this.zero))throw new Error("invalid point");var r=i.fromRed().isOdd();return(e&&!r||!e&&r)&&(i=i.redNeg()),this.point(A,i)},I.prototype.validate=function(A){if(A.inf)return!0;var e=A.x,t=A.y,i=this.a.redMul(e),g=e.redSqr().redMul(e).redIAdd(i).redIAdd(this.b);return 0===t.redSqr().redISub(g).cmpn(0)},I.prototype._endoWnafMulAdd=function(A,e,t){for(var i=this._endoWnafT1,g=this._endoWnafT2,r=0;r":""},o.prototype.isInfinity=function(){return this.inf},o.prototype.add=function(A){if(this.inf)return A;if(A.inf)return this;if(this.eq(A))return this.dbl();if(this.neg().eq(A))return this.curve.point(null,null);if(0===this.x.cmp(A.x))return this.curve.point(null,null);var e=this.y.redSub(A.y);0!==e.cmpn(0)&&(e=e.redMul(this.x.redSub(A.x).redInvm()));var t=e.redSqr().redISub(this.x).redISub(A.x),i=e.redMul(this.x.redSub(t)).redISub(this.y);return this.curve.point(t,i)},o.prototype.dbl=function(){if(this.inf)return this;var A=this.y.redAdd(this.y);if(0===A.cmpn(0))return this.curve.point(null,null);var e=this.curve.a,t=this.x.redSqr(),i=A.redInvm(),g=t.redAdd(t).redIAdd(t).redIAdd(e).redMul(i),r=g.redSqr().redISub(this.x.redAdd(this.x)),n=g.redMul(this.x.redSub(r)).redISub(this.y);return this.curve.point(r,n)},o.prototype.getX=function(){return this.x.fromRed()},o.prototype.getY=function(){return this.y.fromRed()},o.prototype.mul=function(A){return A=new g(A,16),this.isInfinity()?this:this._hasDoubles(A)?this.curve._fixedNafMul(this,A):this.curve.endo?this.curve._endoWnafMulAdd([this],[A]):this.curve._wnafMul(this,A)},o.prototype.mulAdd=function(A,e,t){var i=[this,e],g=[A,t];return this.curve.endo?this.curve._endoWnafMulAdd(i,g):this.curve._wnafMulAdd(1,i,g,2)},o.prototype.jmulAdd=function(A,e,t){var i=[this,e],g=[A,t];return this.curve.endo?this.curve._endoWnafMulAdd(i,g,!0):this.curve._wnafMulAdd(1,i,g,2,!0)},o.prototype.eq=function(A){return this===A||this.inf===A.inf&&(this.inf||0===this.x.cmp(A.x)&&0===this.y.cmp(A.y))},o.prototype.neg=function(A){if(this.inf)return this;var e=this.curve.point(this.x,this.y.redNeg());if(A&&this.precomputed){var t=this.precomputed,i=function(A){return A.neg()};e.precomputed={naf:t.naf&&{wnd:t.naf.wnd,points:t.naf.points.map(i)},doubles:t.doubles&&{step:t.doubles.step,points:t.doubles.points.map(i)}}}return e},o.prototype.toJ=function(){return this.inf?this.curve.jpoint(null,null,null):this.curve.jpoint(this.x,this.y,this.curve.one)},r(a,n.BasePoint),I.prototype.jpoint=function(A,e,t){return new a(this,A,e,t)},a.prototype.toP=function(){if(this.isInfinity())return this.curve.point(null,null);var A=this.z.redInvm(),e=A.redSqr(),t=this.x.redMul(e),i=this.y.redMul(e).redMul(A);return this.curve.point(t,i)},a.prototype.neg=function(){return this.curve.jpoint(this.x,this.y.redNeg(),this.z)},a.prototype.add=function(A){if(this.isInfinity())return A;if(A.isInfinity())return this;var e=A.z.redSqr(),t=this.z.redSqr(),i=this.x.redMul(e),g=A.x.redMul(t),r=this.y.redMul(e.redMul(A.z)),n=A.y.redMul(t.redMul(this.z)),B=i.redSub(g),I=r.redSub(n);if(0===B.cmpn(0))return 0!==I.cmpn(0)?this.curve.jpoint(null,null,null):this.dbl();var o=B.redSqr(),a=o.redMul(B),Q=i.redMul(o),C=I.redSqr().redIAdd(a).redISub(Q).redISub(Q),s=I.redMul(Q.redISub(C)).redISub(r.redMul(a)),c=this.z.redMul(A.z).redMul(B);return this.curve.jpoint(C,s,c)},a.prototype.mixedAdd=function(A){if(this.isInfinity())return A.toJ();if(A.isInfinity())return this;var e=this.z.redSqr(),t=this.x,i=A.x.redMul(e),g=this.y,r=A.y.redMul(e).redMul(this.z),n=t.redSub(i),B=g.redSub(r);if(0===n.cmpn(0))return 0!==B.cmpn(0)?this.curve.jpoint(null,null,null):this.dbl();var I=n.redSqr(),o=I.redMul(n),a=t.redMul(I),Q=B.redSqr().redIAdd(o).redISub(a).redISub(a),C=B.redMul(a.redISub(Q)).redISub(g.redMul(o)),s=this.z.redMul(n);return this.curve.jpoint(Q,C,s)},a.prototype.dblp=function(A){if(0===A)return this;if(this.isInfinity())return this;if(!A)return this.dbl();if(this.curve.zeroA||this.curve.threeA){for(var e=this,t=0;t=0)return!1;if(t.redIAdd(g),0===this.x.cmp(t))return!0}},a.prototype.inspect=function(){return this.isInfinity()?"":""},a.prototype.isInfinity=function(){return 0===this.z.cmpn(0)}},{"../utils":99,"./base":86,"bn.js":100,inherits:134}],91:[function(A,e,t){"use strict";var i,g=t,r=A("hash.js"),n=A("./curve"),B=A("./utils").assert;function I(A){"short"===A.type?this.curve=new n.short(A):"edwards"===A.type?this.curve=new n.edwards(A):this.curve=new n.mont(A),this.g=this.curve.g,this.n=this.curve.n,this.hash=A.hash,B(this.g.validate(),"Invalid curve"),B(this.g.mul(this.n).isInfinity(),"Invalid curve, G*N != O")}function o(A,e){Object.defineProperty(g,A,{configurable:!0,enumerable:!0,get:function(){var t=new I(e);return Object.defineProperty(g,A,{configurable:!0,enumerable:!0,value:t}),t}})}g.PresetCurve=I,o("p192",{type:"short",prime:"p192",p:"ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff",a:"ffffffff ffffffff ffffffff fffffffe ffffffff fffffffc",b:"64210519 e59c80e7 0fa7e9ab 72243049 feb8deec c146b9b1",n:"ffffffff ffffffff ffffffff 99def836 146bc9b1 b4d22831",hash:r.sha256,gRed:!1,g:["188da80e b03090f6 7cbf20eb 43a18800 f4ff0afd 82ff1012","07192b95 ffc8da78 631011ed 6b24cdd5 73f977a1 1e794811"]}),o("p224",{type:"short",prime:"p224",p:"ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001",a:"ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff fffffffe",b:"b4050a85 0c04b3ab f5413256 5044b0b7 d7bfd8ba 270b3943 2355ffb4",n:"ffffffff ffffffff ffffffff ffff16a2 e0b8f03e 13dd2945 5c5c2a3d",hash:r.sha256,gRed:!1,g:["b70e0cbd 6bb4bf7f 321390b9 4a03c1d3 56c21122 343280d6 115c1d21","bd376388 b5f723fb 4c22dfe6 cd4375a0 5a074764 44d58199 85007e34"]}),o("p256",{type:"short",prime:null,p:"ffffffff 00000001 00000000 00000000 00000000 ffffffff ffffffff ffffffff",a:"ffffffff 00000001 00000000 00000000 00000000 ffffffff ffffffff fffffffc",b:"5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f6 3bce3c3e 27d2604b",n:"ffffffff 00000000 ffffffff ffffffff bce6faad a7179e84 f3b9cac2 fc632551",hash:r.sha256,gRed:!1,g:["6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0 f4a13945 d898c296","4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ece cbb64068 37bf51f5"]}),o("p384",{type:"short",prime:null,p:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe ffffffff 00000000 00000000 ffffffff",a:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe ffffffff 00000000 00000000 fffffffc",b:"b3312fa7 e23ee7e4 988e056b e3f82d19 181d9c6e fe814112 0314088f 5013875a c656398d 8a2ed19d 2a85c8ed d3ec2aef",n:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff c7634d81 f4372ddf 581a0db2 48b0a77a ecec196a ccc52973",hash:r.sha384,gRed:!1,g:["aa87ca22 be8b0537 8eb1c71e f320ad74 6e1d3b62 8ba79b98 59f741e0 82542a38 5502f25d bf55296c 3a545e38 72760ab7","3617de4a 96262c6f 5d9e98bf 9292dc29 f8f41dbd 289a147c e9da3113 b5f0b8c0 0a60b1ce 1d7e819d 7a431d7c 90ea0e5f"]}),o("p521",{type:"short",prime:null,p:"000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff",a:"000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffc",b:"00000051 953eb961 8e1c9a1f 929a21a0 b68540ee a2da725b 99b315f3 b8b48991 8ef109e1 56193951 ec7e937b 1652c0bd 3bb1bf07 3573df88 3d2c34f1 ef451fd4 6b503f00",n:"000001ff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffa 51868783 bf2f966b 7fcc0148 f709a5d0 3bb5c9b8 899c47ae bb6fb71e 91386409",hash:r.sha512,gRed:!1,g:["000000c6 858e06b7 0404e9cd 9e3ecb66 2395b442 9c648139 053fb521 f828af60 6b4d3dba a14b5e77 efe75928 fe1dc127 a2ffa8de 3348b3c1 856a429b f97e7e31 c2e5bd66","00000118 39296a78 9a3bc004 5c8a5fb4 2c7d1bd9 98f54449 579b4468 17afbd17 273e662c 97ee7299 5ef42640 c550b901 3fad0761 353c7086 a272c240 88be9476 9fd16650"]}),o("curve25519",{type:"mont",prime:"p25519",p:"7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed",a:"76d06",b:"1",n:"1000000000000000 0000000000000000 14def9dea2f79cd6 5812631a5cf5d3ed",hash:r.sha256,gRed:!1,g:["9"]}),o("ed25519",{type:"edwards",prime:"p25519",p:"7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed",a:"-1",c:"1",d:"52036cee2b6ffe73 8cc740797779e898 00700a4d4141d8ab 75eb4dca135978a3",n:"1000000000000000 0000000000000000 14def9dea2f79cd6 5812631a5cf5d3ed",hash:r.sha256,gRed:!1,g:["216936d3cd6e53fec0a4e231fdd6dc5c692cc7609525a7b2c9562d608f25d51a","6666666666666666666666666666666666666666666666666666666666666658"]});try{i=A("./precomputed/secp256k1")}catch(A){i=void 0}o("secp256k1",{type:"short",prime:"k256",p:"ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f",a:"0",b:"7",n:"ffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141",h:"1",hash:r.sha256,beta:"7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee",lambda:"5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72",basis:[{a:"3086d221a7d46bcde86c90e49284eb15",b:"-e4437ed6010e88286f547fa90abfe4c3"},{a:"114ca50f7a8e2f3f657c1108d9d44cfd8",b:"3086d221a7d46bcde86c90e49284eb15"}],gRed:!1,g:["79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8",i]})},{"./curve":88,"./precomputed/secp256k1":98,"./utils":99,"hash.js":120}],92:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("hmac-drbg"),r=A("../utils"),n=A("../curves"),B=A("brorand"),I=r.assert,o=A("./key"),a=A("./signature");function Q(A){if(!(this instanceof Q))return new Q(A);"string"==typeof A&&(I(n.hasOwnProperty(A),"Unknown curve "+A),A=n[A]),A instanceof n.PresetCurve&&(A={curve:A}),this.curve=A.curve.curve,this.n=this.curve.n,this.nh=this.n.ushrn(1),this.g=this.curve.g,this.g=A.curve.g,this.g.precompute(A.curve.n.bitLength()+1),this.hash=A.hash||A.curve.hash}e.exports=Q,Q.prototype.keyPair=function(A){return new o(this,A)},Q.prototype.keyFromPrivate=function(A,e){return o.fromPrivate(this,A,e)},Q.prototype.keyFromPublic=function(A,e){return o.fromPublic(this,A,e)},Q.prototype.genKeyPair=function(A){A||(A={});for(var e=new g({hash:this.hash,pers:A.pers,persEnc:A.persEnc||"utf8",entropy:A.entropy||B(this.hash.hmacStrength),entropyEnc:A.entropy&&A.entropyEnc||"utf8",nonce:this.n.toArray()}),t=this.n.byteLength(),r=this.n.sub(new i(2));;){var n=new i(e.generate(t));if(!(n.cmp(r)>0))return n.iaddn(1),this.keyFromPrivate(n)}},Q.prototype._truncateToN=function(A,e){var t=8*A.byteLength()-this.n.bitLength();return t>0&&(A=A.ushrn(t)),!e&&A.cmp(this.n)>=0?A.sub(this.n):A},Q.prototype.sign=function(A,e,t,r){"object"==typeof t&&(r=t,t=null),r||(r={}),e=this.keyFromPrivate(e,t),A=this._truncateToN(new i(A,16));for(var n=this.n.byteLength(),B=e.getPrivate().toArray("be",n),I=A.toArray("be",n),o=new g({hash:this.hash,entropy:B,nonce:I,pers:r.pers,persEnc:r.persEnc||"utf8"}),Q=this.n.sub(new i(1)),C=0;;C++){var s=r.k?r.k(C):new i(o.generate(this.n.byteLength()));if(!((s=this._truncateToN(s,!0)).cmpn(1)<=0||s.cmp(Q)>=0)){var c=this.g.mul(s);if(!c.isInfinity()){var h=c.getX(),f=h.umod(this.n);if(0!==f.cmpn(0)){var E=s.invm(this.n).mul(f.mul(e.getPrivate()).iadd(A));if(0!==(E=E.umod(this.n)).cmpn(0)){var u=(c.getY().isOdd()?1:0)|(0!==h.cmp(f)?2:0);return r.canonical&&E.cmp(this.nh)>0&&(E=this.n.sub(E),u^=1),new a({r:f,s:E,recoveryParam:u})}}}}}},Q.prototype.verify=function(A,e,t,g){A=this._truncateToN(new i(A,16)),t=this.keyFromPublic(t,g);var r=(e=new a(e,"hex")).r,n=e.s;if(r.cmpn(1)<0||r.cmp(this.n)>=0)return!1;if(n.cmpn(1)<0||n.cmp(this.n)>=0)return!1;var B,I=n.invm(this.n),o=I.mul(A).umod(this.n),Q=I.mul(r).umod(this.n);return this.curve._maxwellTrick?!(B=this.g.jmulAdd(o,t.getPublic(),Q)).isInfinity()&&B.eqXToP(r):!(B=this.g.mulAdd(o,t.getPublic(),Q)).isInfinity()&&0===B.getX().umod(this.n).cmp(r)},Q.prototype.recoverPubKey=function(A,e,t,g){I((3&t)===t,"The recovery param is more than two bits"),e=new a(e,g);var r=this.n,n=new i(A),B=e.r,o=e.s,Q=1&t,C=t>>1;if(B.cmp(this.curve.p.umod(this.curve.n))>=0&&C)throw new Error("Unable to find sencond key candinate");B=C?this.curve.pointFromX(B.add(this.curve.n),Q):this.curve.pointFromX(B,Q);var s=e.r.invm(r),c=r.sub(n).mul(s).umod(r),h=o.mul(s).umod(r);return this.g.mulAdd(c,B,h)},Q.prototype.getKeyRecoveryParam=function(A,e,t,i){if(null!==(e=new a(e,i)).recoveryParam)return e.recoveryParam;for(var g=0;g<4;g++){var r;try{r=this.recoverPubKey(A,e,g)}catch(A){continue}if(r.eq(t))return g}throw new Error("Unable to find valid recovery factor")}},{"../curves":91,"../utils":99,"./key":93,"./signature":94,"bn.js":100,brorand:18,"hmac-drbg":132}],93:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("../utils").assert;function r(A,e){this.ec=A,this.priv=null,this.pub=null,e.priv&&this._importPrivate(e.priv,e.privEnc),e.pub&&this._importPublic(e.pub,e.pubEnc)}e.exports=r,r.fromPublic=function(A,e,t){return e instanceof r?e:new r(A,{pub:e,pubEnc:t})},r.fromPrivate=function(A,e,t){return e instanceof r?e:new r(A,{priv:e,privEnc:t})},r.prototype.validate=function(){var A=this.getPublic();return A.isInfinity()?{result:!1,reason:"Invalid public key"}:A.validate()?A.mul(this.ec.curve.n).isInfinity()?{result:!0,reason:null}:{result:!1,reason:"Public key * N != O"}:{result:!1,reason:"Public key is not a point"}},r.prototype.getPublic=function(A,e){return"string"==typeof A&&(e=A,A=null),this.pub||(this.pub=this.ec.g.mul(this.priv)),e?this.pub.encode(e,A):this.pub},r.prototype.getPrivate=function(A){return"hex"===A?this.priv.toString(16,2):this.priv},r.prototype._importPrivate=function(A,e){this.priv=new i(A,e||16),this.priv=this.priv.umod(this.ec.curve.n)},r.prototype._importPublic=function(A,e){if(A.x||A.y)return"mont"===this.ec.curve.type?g(A.x,"Need x coordinate"):"short"!==this.ec.curve.type&&"edwards"!==this.ec.curve.type||g(A.x&&A.y,"Need both x and y coordinate"),void(this.pub=this.ec.curve.point(A.x,A.y));this.pub=this.ec.curve.decodePoint(A,e)},r.prototype.derive=function(A){return A.mul(this.priv).getX()},r.prototype.sign=function(A,e,t){return this.ec.sign(A,this,e,t)},r.prototype.verify=function(A,e){return this.ec.verify(A,e,this)},r.prototype.inspect=function(){return""}},{"../utils":99,"bn.js":100}],94:[function(A,e,t){"use strict";var i=A("bn.js"),g=A("../utils"),r=g.assert;function n(A,e){if(A instanceof n)return A;this._importDER(A,e)||(r(A.r&&A.s,"Signature without r or s"),this.r=new i(A.r,16),this.s=new i(A.s,16),void 0===A.recoveryParam?this.recoveryParam=null:this.recoveryParam=A.recoveryParam)}function B(A,e){var t=A[e.place++];if(!(128&t))return t;var i=15&t;if(0===i||i>4)return!1;for(var g=0,r=0,n=e.place;r>>=0;return!(g<=127)&&(e.place=n,g)}function I(A){for(var e=0,t=A.length-1;!A[e]&&!(128&A[e+1])&&e>>3);for(A.push(128|t);--t;)A.push(e>>>(t<<3)&255);A.push(e)}}e.exports=n,n.prototype._importDER=function(A,e){A=g.toArray(A,e);var t=new function(){this.place=0};if(48!==A[t.place++])return!1;var r=B(A,t);if(!1===r)return!1;if(r+t.place!==A.length)return!1;if(2!==A[t.place++])return!1;var n=B(A,t);if(!1===n)return!1;var I=A.slice(t.place,n+t.place);if(t.place+=n,2!==A[t.place++])return!1;var o=B(A,t);if(!1===o)return!1;if(A.length!==o+t.place)return!1;var a=A.slice(t.place,o+t.place);if(0===I[0]){if(!(128&I[1]))return!1;I=I.slice(1)}if(0===a[0]){if(!(128&a[1]))return!1;a=a.slice(1)}return this.r=new i(I),this.s=new i(a),this.recoveryParam=null,!0},n.prototype.toDER=function(A){var e=this.r.toArray(),t=this.s.toArray();for(128&e[0]&&(e=[0].concat(e)),128&t[0]&&(t=[0].concat(t)),e=I(e),t=I(t);!(t[0]||128&t[1]);)t=t.slice(1);var i=[2];o(i,e.length),(i=i.concat(e)).push(2),o(i,t.length);var r=i.concat(t),n=[48];return o(n,r.length),n=n.concat(r),g.encode(n,A)}},{"../utils":99,"bn.js":100}],95:[function(A,e,t){"use strict";var i=A("hash.js"),g=A("../curves"),r=A("../utils"),n=r.assert,B=r.parseBytes,I=A("./key"),o=A("./signature");function a(A){if(n("ed25519"===A,"only tested with ed25519 so far"),!(this instanceof a))return new a(A);A=g[A].curve;this.curve=A,this.g=A.g,this.g.precompute(A.n.bitLength()+1),this.pointClass=A.point().constructor,this.encodingLength=Math.ceil(A.n.bitLength()/8),this.hash=i.sha512}e.exports=a,a.prototype.sign=function(A,e){A=B(A);var t=this.keyFromSecret(e),i=this.hashInt(t.messagePrefix(),A),g=this.g.mul(i),r=this.encodePoint(g),n=this.hashInt(r,t.pubBytes(),A).mul(t.priv()),I=i.add(n).umod(this.curve.n);return this.makeSignature({R:g,S:I,Rencoded:r})},a.prototype.verify=function(A,e,t){A=B(A),e=this.makeSignature(e);var i=this.keyFromPublic(t),g=this.hashInt(e.Rencoded(),i.pubBytes(),A),r=this.g.mul(e.S());return e.R().add(i.pub().mul(g)).eq(r)},a.prototype.hashInt=function(){for(var A=this.hash(),e=0;e(g>>1)-1?(g>>1)-I:I,r.isubn(B)):B=0,i[n]=B,r.iushrn(1)}return i},i.getJSF=function(A,e){var t=[[],[]];A=A.clone(),e=e.clone();for(var i=0,g=0;A.cmpn(-i)>0||e.cmpn(-g)>0;){var r,n,B,I=A.andln(3)+i&3,o=e.andln(3)+g&3;3===I&&(I=-1),3===o&&(o=-1),r=0==(1&I)?0:3!=(B=A.andln(7)+i&7)&&5!==B||2!==o?I:-I,t[0].push(r),n=0==(1&o)?0:3!=(B=e.andln(7)+g&7)&&5!==B||2!==I?o:-o,t[1].push(n),2*i===r+1&&(i=1-i),2*g===n+1&&(g=1-g),A.iushrn(1),e.iushrn(1)}return t},i.cachedProperty=function(A,e,t){var i="_"+e;A.prototype[e]=function(){return void 0!==this[i]?this[i]:this[i]=t.call(this)}},i.parseBytes=function(A){return"string"==typeof A?i.toArray(A,"hex"):A},i.intFromLE=function(A){return new g(A,"hex","le")}},{"bn.js":100,"minimalistic-assert":140,"minimalistic-crypto-utils":141}],100:[function(A,e,t){arguments[4][15][0].apply(t,arguments)},{buffer:19,dup:15}],101:[function(A,e,t){e.exports={_from:"elliptic@^6.5.3",_id:"elliptic@6.5.3",_inBundle:!1,_integrity:"sha512-IMqzv5wNQf+E6aHeIqATs0tOLeOTwj1QKbRcS3jBbYkl5oLAserA8yJTT7/VyHUYG91PRmPyeQDObKLPpeS4dw==",_location:"/browserify/elliptic",_phantomChildren:{},_requested:{type:"range",registry:!0,raw:"elliptic@^6.5.3",name:"elliptic",escapedName:"elliptic",rawSpec:"^6.5.3",saveSpec:null,fetchSpec:"^6.5.3"},_requiredBy:["/browserify/browserify-sign","/browserify/create-ecdh"],_resolved:"https://registry.npmjs.org/elliptic/-/elliptic-6.5.3.tgz",_shasum:"cb59eb2efdaf73a0bd78ccd7015a62ad6e0f93d6",_spec:"elliptic@^6.5.3",_where:"/home/volt/.npm/_npx/29682/lib/node_modules/browserify/node_modules/browserify-sign",author:{name:"Fedor Indutny",email:"fedor@indutny.com"},bugs:{url:"https://github.com/indutny/elliptic/issues"},bundleDependencies:!1,dependencies:{"bn.js":"^4.4.0",brorand:"^1.0.1","hash.js":"^1.0.0","hmac-drbg":"^1.0.0",inherits:"^2.0.1","minimalistic-assert":"^1.0.0","minimalistic-crypto-utils":"^1.0.0"},deprecated:!1,description:"EC cryptography",devDependencies:{brfs:"^1.4.3",coveralls:"^3.0.8",grunt:"^1.0.4","grunt-browserify":"^5.0.0","grunt-cli":"^1.2.0","grunt-contrib-connect":"^1.0.0","grunt-contrib-copy":"^1.0.0","grunt-contrib-uglify":"^1.0.1","grunt-mocha-istanbul":"^3.0.1","grunt-saucelabs":"^9.0.1",istanbul:"^0.4.2",jscs:"^3.0.7",jshint:"^2.10.3",mocha:"^6.2.2"},files:["lib"],homepage:"https://github.com/indutny/elliptic",keywords:["EC","Elliptic","curve","Cryptography"],license:"MIT",main:"lib/elliptic.js",name:"elliptic",repository:{type:"git",url:"git+ssh://git@github.com/indutny/elliptic.git"},scripts:{jscs:"jscs benchmarks/*.js lib/*.js lib/**/*.js lib/**/**/*.js test/index.js",jshint:"jscs benchmarks/*.js lib/*.js lib/**/*.js lib/**/**/*.js test/index.js",lint:"npm run jscs && npm run jshint",test:"npm run lint && npm run unit",unit:"istanbul test _mocha --reporter=spec test/index.js",version:"grunt dist && git add dist/"},version:"6.5.3"}},{}],102:[function(A,e,t){var i=Object.create||function(A){var e=function(){};return e.prototype=A,new e},g=Object.keys||function(A){var e=[];for(var t in A)Object.prototype.hasOwnProperty.call(A,t)&&e.push(t);return t},r=Function.prototype.bind||function(A){var e=this;return function(){return e.apply(A,arguments)}};function n(){this._events&&Object.prototype.hasOwnProperty.call(this,"_events")||(this._events=i(null),this._eventsCount=0),this._maxListeners=this._maxListeners||void 0}e.exports=n,n.EventEmitter=n,n.prototype._events=void 0,n.prototype._maxListeners=void 0;var B,I=10;try{var o={};Object.defineProperty&&Object.defineProperty(o,"x",{value:0}),B=0===o.x}catch(A){B=!1}function a(A){return void 0===A._maxListeners?n.defaultMaxListeners:A._maxListeners}function Q(A,e,t,g){var r,n,B;if("function"!=typeof t)throw new TypeError('"listener" argument must be a function');if((n=A._events)?(n.newListener&&(A.emit("newListener",e,t.listener?t.listener:t),n=A._events),B=n[e]):(n=A._events=i(null),A._eventsCount=0),B){if("function"==typeof B?B=n[e]=g?[t,B]:[B,t]:g?B.unshift(t):B.push(t),!B.warned&&(r=a(A))&&r>0&&B.length>r){B.warned=!0;var I=new Error("Possible EventEmitter memory leak detected. "+B.length+' "'+String(e)+'" listeners added. Use emitter.setMaxListeners() to increase limit.');I.name="MaxListenersExceededWarning",I.emitter=A,I.type=e,I.count=B.length,"object"==typeof console&&console.warn&&console.warn("%s: %s",I.name,I.message)}}else B=n[e]=t,++A._eventsCount;return A}function C(){if(!this.fired)switch(this.target.removeListener(this.type,this.wrapFn),this.fired=!0,arguments.length){case 0:return this.listener.call(this.target);case 1:return this.listener.call(this.target,arguments[0]);case 2:return this.listener.call(this.target,arguments[0],arguments[1]);case 3:return this.listener.call(this.target,arguments[0],arguments[1],arguments[2]);default:for(var A=new Array(arguments.length),e=0;e1&&(e=arguments[1]),e instanceof Error)throw e;var I=new Error('Unhandled "error" event. ('+e+")");throw I.context=e,I}if(!(t=n[A]))return!1;var o="function"==typeof t;switch(i=arguments.length){case 1:!function(A,e,t){if(e)A.call(t);else for(var i=A.length,g=f(A,i),r=0;r=0;n--)if(t[n]===e||t[n].listener===e){B=t[n].listener,r=n;break}if(r<0)return this;0===r?t.shift():function(A,e){for(var t=e,i=t+1,g=A.length;i=0;r--)this.removeListener(A,e[r]);return this},n.prototype.listeners=function(A){return c(this,A,!0)},n.prototype.rawListeners=function(A){return c(this,A,!1)},n.listenerCount=function(A,e){return"function"==typeof A.listenerCount?A.listenerCount(e):h.call(A,e)},n.prototype.listenerCount=h,n.prototype.eventNames=function(){return this._eventsCount>0?Reflect.ownKeys(this._events):[]}},{}],103:[function(A,e,t){var i=A("safe-buffer").Buffer,g=A("md5.js");e.exports=function(A,e,t,r){if(i.isBuffer(A)||(A=i.from(A,"binary")),e&&(i.isBuffer(e)||(e=i.from(e,"binary")),8!==e.length))throw new RangeError("salt should be Buffer with 8 byte length");for(var n=t/8,B=i.alloc(n),I=i.alloc(r||0),o=i.alloc(0);n>0||r>0;){var a=new g;a.update(o),a.update(A),e&&a.update(e),o=a.digest();var Q=0;if(n>0){var C=B.length-n;Q=Math.min(n,o.length),o.copy(B,C,0,Q),n-=Q}if(Q0){var s=I.length-r,c=Math.min(r,o.length-Q);o.copy(I,s,Q,Q+c),r-=c}}return o.fill(0),{key:B,iv:I}}},{"md5.js":137,"safe-buffer":180}],104:[function(A,e,t){"use strict";var i=A("safe-buffer").Buffer,g=A("readable-stream").Transform;function r(A){g.call(this),this._block=i.allocUnsafe(A),this._blockSize=A,this._blockOffset=0,this._length=[0,0,0,0],this._finalized=!1}A("inherits")(r,g),r.prototype._transform=function(A,e,t){var i=null;try{this.update(A,e)}catch(A){i=A}t(i)},r.prototype._flush=function(A){var e=null;try{this.push(this.digest())}catch(A){e=A}A(e)},r.prototype.update=function(A,e){if(function(A,e){if(!i.isBuffer(A)&&"string"!=typeof A)throw new TypeError(e+" must be a string or a buffer")}(A,"Data"),this._finalized)throw new Error("Digest already called");i.isBuffer(A)||(A=i.from(A,e));for(var t=this._block,g=0;this._blockOffset+A.length-g>=this._blockSize;){for(var r=this._blockOffset;r0;++n)this._length[n]+=B,(B=this._length[n]/4294967296|0)>0&&(this._length[n]-=4294967296*B);return this},r.prototype._update=function(){throw new Error("_update is not implemented")},r.prototype.digest=function(A){if(this._finalized)throw new Error("Digest already called");this._finalized=!0;var e=this._digest();void 0!==A&&(e=e.toString(A)),this._block.fill(0),this._blockOffset=0;for(var t=0;t<4;++t)this._length[t]=0;return e},r.prototype._digest=function(){throw new Error("_digest is not implemented")},e.exports=r},{inherits:134,"readable-stream":119,"safe-buffer":180}],105:[function(A,e,t){arguments[4][48][0].apply(t,arguments)},{dup:48}],106:[function(A,e,t){arguments[4][49][0].apply(t,arguments)},{"./_stream_readable":108,"./_stream_writable":110,_process:154,dup:49,inherits:134}],107:[function(A,e,t){arguments[4][50][0].apply(t,arguments)},{"./_stream_transform":109,dup:50,inherits:134}],108:[function(A,e,t){arguments[4][51][0].apply(t,arguments)},{"../errors":105,"./_stream_duplex":106,"./internal/streams/async_iterator":111,"./internal/streams/buffer_list":112,"./internal/streams/destroy":113,"./internal/streams/from":115,"./internal/streams/state":117,"./internal/streams/stream":118,_process:154,buffer:64,dup:51,events:102,inherits:134,"string_decoder/":191,util:19}],109:[function(A,e,t){arguments[4][52][0].apply(t,arguments)},{"../errors":105,"./_stream_duplex":106,dup:52,inherits:134}],110:[function(A,e,t){arguments[4][53][0].apply(t,arguments)},{"../errors":105,"./_stream_duplex":106,"./internal/streams/destroy":113,"./internal/streams/state":117,"./internal/streams/stream":118,_process:154,buffer:64,dup:53,inherits:134,"util-deprecate":193}],111:[function(A,e,t){arguments[4][54][0].apply(t,arguments)},{"./end-of-stream":114,_process:154,dup:54}],112:[function(A,e,t){arguments[4][55][0].apply(t,arguments)},{buffer:64,dup:55,util:19}],113:[function(A,e,t){arguments[4][56][0].apply(t,arguments)},{_process:154,dup:56}],114:[function(A,e,t){arguments[4][57][0].apply(t,arguments)},{"../../../errors":105,dup:57}],115:[function(A,e,t){arguments[4][58][0].apply(t,arguments)},{dup:58}],116:[function(A,e,t){arguments[4][59][0].apply(t,arguments)},{"../../../errors":105,"./end-of-stream":114,dup:59}],117:[function(A,e,t){arguments[4][60][0].apply(t,arguments)},{"../../../errors":105,dup:60}],118:[function(A,e,t){arguments[4][61][0].apply(t,arguments)},{dup:61,events:102}],119:[function(A,e,t){arguments[4][62][0].apply(t,arguments)},{"./lib/_stream_duplex.js":106,"./lib/_stream_passthrough.js":107,"./lib/_stream_readable.js":108,"./lib/_stream_transform.js":109,"./lib/_stream_writable.js":110,"./lib/internal/streams/end-of-stream.js":114,"./lib/internal/streams/pipeline.js":116,dup:62}],120:[function(A,e,t){var i=t;i.utils=A("./hash/utils"),i.common=A("./hash/common"),i.sha=A("./hash/sha"),i.ripemd=A("./hash/ripemd"),i.hmac=A("./hash/hmac"),i.sha1=i.sha.sha1,i.sha256=i.sha.sha256,i.sha224=i.sha.sha224,i.sha384=i.sha.sha384,i.sha512=i.sha.sha512,i.ripemd160=i.ripemd.ripemd160},{"./hash/common":121,"./hash/hmac":122,"./hash/ripemd":123,"./hash/sha":124,"./hash/utils":131}],121:[function(A,e,t){"use strict";var i=A("./utils"),g=A("minimalistic-assert");function r(){this.pending=null,this.pendingTotal=0,this.blockSize=this.constructor.blockSize,this.outSize=this.constructor.outSize,this.hmacStrength=this.constructor.hmacStrength,this.padLength=this.constructor.padLength/8,this.endian="big",this._delta8=this.blockSize/8,this._delta32=this.blockSize/32}t.BlockHash=r,r.prototype.update=function(A,e){if(A=i.toArray(A,e),this.pending?this.pending=this.pending.concat(A):this.pending=A,this.pendingTotal+=A.length,this.pending.length>=this._delta8){var t=(A=this.pending).length%this._delta8;this.pending=A.slice(A.length-t,A.length),0===this.pending.length&&(this.pending=null),A=i.join32(A,0,A.length-t,this.endian);for(var g=0;g>>24&255,i[g++]=A>>>16&255,i[g++]=A>>>8&255,i[g++]=255&A}else for(i[g++]=255&A,i[g++]=A>>>8&255,i[g++]=A>>>16&255,i[g++]=A>>>24&255,i[g++]=0,i[g++]=0,i[g++]=0,i[g++]=0,r=8;rthis.blockSize&&(A=(new this.Hash).update(A).digest()),g(A.length<=this.blockSize);for(var e=A.length;e>>3},t.g1_256=function(A){return i(A,17)^i(A,19)^A>>>10}},{"../utils":131}],131:[function(A,e,t){"use strict";var i=A("minimalistic-assert"),g=A("inherits");function r(A,e){return 55296==(64512&A.charCodeAt(e))&&(!(e<0||e+1>=A.length)&&56320==(64512&A.charCodeAt(e+1)))}function n(A){return(A>>>24|A>>>8&65280|A<<8&16711680|(255&A)<<24)>>>0}function B(A){return 1===A.length?"0"+A:A}function I(A){return 7===A.length?"0"+A:6===A.length?"00"+A:5===A.length?"000"+A:4===A.length?"0000"+A:3===A.length?"00000"+A:2===A.length?"000000"+A:1===A.length?"0000000"+A:A}t.inherits=g,t.toArray=function(A,e){if(Array.isArray(A))return A.slice();if(!A)return[];var t=[];if("string"==typeof A)if(e){if("hex"===e)for((A=A.replace(/[^a-z0-9]+/gi,"")).length%2!=0&&(A="0"+A),g=0;g>6|192,t[i++]=63&n|128):r(A,g)?(n=65536+((1023&n)<<10)+(1023&A.charCodeAt(++g)),t[i++]=n>>18|240,t[i++]=n>>12&63|128,t[i++]=n>>6&63|128,t[i++]=63&n|128):(t[i++]=n>>12|224,t[i++]=n>>6&63|128,t[i++]=63&n|128)}else for(g=0;g>>0}return n},t.split32=function(A,e){for(var t=new Array(4*A.length),i=0,g=0;i>>24,t[g+1]=r>>>16&255,t[g+2]=r>>>8&255,t[g+3]=255&r):(t[g+3]=r>>>24,t[g+2]=r>>>16&255,t[g+1]=r>>>8&255,t[g]=255&r)}return t},t.rotr32=function(A,e){return A>>>e|A<<32-e},t.rotl32=function(A,e){return A<>>32-e},t.sum32=function(A,e){return A+e>>>0},t.sum32_3=function(A,e,t){return A+e+t>>>0},t.sum32_4=function(A,e,t,i){return A+e+t+i>>>0},t.sum32_5=function(A,e,t,i,g){return A+e+t+i+g>>>0},t.sum64=function(A,e,t,i){var g=A[e],r=i+A[e+1]>>>0,n=(r>>0,A[e+1]=r},t.sum64_hi=function(A,e,t,i){return(e+i>>>0>>0},t.sum64_lo=function(A,e,t,i){return e+i>>>0},t.sum64_4_hi=function(A,e,t,i,g,r,n,B){var I=0,o=e;return I+=(o=o+i>>>0)>>0)>>0)>>0},t.sum64_4_lo=function(A,e,t,i,g,r,n,B){return e+i+r+B>>>0},t.sum64_5_hi=function(A,e,t,i,g,r,n,B,I,o){var a=0,Q=e;return a+=(Q=Q+i>>>0)>>0)>>0)>>0)>>0},t.sum64_5_lo=function(A,e,t,i,g,r,n,B,I,o){return e+i+r+B+o>>>0},t.rotr64_hi=function(A,e,t){return(e<<32-t|A>>>t)>>>0},t.rotr64_lo=function(A,e,t){return(A<<32-t|e>>>t)>>>0},t.shr64_hi=function(A,e,t){return A>>>t},t.shr64_lo=function(A,e,t){return(A<<32-t|e>>>t)>>>0}},{inherits:134,"minimalistic-assert":140}],132:[function(A,e,t){"use strict";var i=A("hash.js"),g=A("minimalistic-crypto-utils"),r=A("minimalistic-assert");function n(A){if(!(this instanceof n))return new n(A);this.hash=A.hash,this.predResist=!!A.predResist,this.outLen=this.hash.outSize,this.minEntropy=A.minEntropy||this.hash.hmacStrength,this._reseed=null,this.reseedInterval=null,this.K=null,this.V=null;var e=g.toArray(A.entropy,A.entropyEnc||"hex"),t=g.toArray(A.nonce,A.nonceEnc||"hex"),i=g.toArray(A.pers,A.persEnc||"hex");r(e.length>=this.minEntropy/8,"Not enough entropy. Minimum is: "+this.minEntropy+" bits"),this._init(e,t,i)}e.exports=n,n.prototype._init=function(A,e,t){var i=A.concat(e).concat(t);this.K=new Array(this.outLen/8),this.V=new Array(this.outLen/8);for(var g=0;g=this.minEntropy/8,"Not enough entropy. Minimum is: "+this.minEntropy+" bits"),this._update(A.concat(t||[])),this._reseed=1},n.prototype.generate=function(A,e,t,i){if(this._reseed>this.reseedInterval)throw new Error("Reseed is required");"string"!=typeof e&&(i=t,t=e,e=null),t&&(t=g.toArray(t,i||"hex"),this._update(t));for(var r=[];r.length>1,a=-7,Q=t?g-1:0,C=t?-1:1,s=A[e+Q];for(Q+=C,r=s&(1<<-a)-1,s>>=-a,a+=B;a>0;r=256*r+A[e+Q],Q+=C,a-=8);for(n=r&(1<<-a)-1,r>>=-a,a+=i;a>0;n=256*n+A[e+Q],Q+=C,a-=8);if(0===r)r=1-o;else{if(r===I)return n?NaN:1/0*(s?-1:1);n+=Math.pow(2,i),r-=o}return(s?-1:1)*n*Math.pow(2,r-i)},t.write=function(A,e,t,i,g,r){var n,B,I,o=8*r-g-1,a=(1<>1,C=23===g?Math.pow(2,-24)-Math.pow(2,-77):0,s=i?0:r-1,c=i?1:-1,h=e<0||0===e&&1/e<0?1:0;for(e=Math.abs(e),isNaN(e)||e===1/0?(B=isNaN(e)?1:0,n=a):(n=Math.floor(Math.log(e)/Math.LN2),e*(I=Math.pow(2,-n))<1&&(n--,I*=2),(e+=n+Q>=1?C/I:C*Math.pow(2,1-Q))*I>=2&&(n++,I/=2),n+Q>=a?(B=0,n=a):n+Q>=1?(B=(e*I-1)*Math.pow(2,g),n+=Q):(B=e*Math.pow(2,Q-1)*Math.pow(2,g),n=0));g>=8;A[t+s]=255&B,s+=c,B/=256,g-=8);for(n=n<0;A[t+s]=255&n,s+=c,n/=256,o-=8);A[t+s-c]|=128*h}},{}],134:[function(A,e,t){"function"==typeof Object.create?e.exports=function(A,e){e&&(A.super_=e,A.prototype=Object.create(e.prototype,{constructor:{value:A,enumerable:!1,writable:!0,configurable:!0}}))}:e.exports=function(A,e){if(e){A.super_=e;var t=function(){};t.prototype=e.prototype,A.prototype=new t,A.prototype.constructor=A}}},{}],135:[function(A,e,t){function i(A){return!!A.constructor&&"function"==typeof A.constructor.isBuffer&&A.constructor.isBuffer(A)}e.exports=function(A){return null!=A&&(i(A)||function(A){return"function"==typeof A.readFloatLE&&"function"==typeof A.slice&&i(A.slice(0,0))}(A)||!!A._isBuffer)}},{}],136:[function(A,e,t){var i={}.toString;e.exports=Array.isArray||function(A){return"[object Array]"==i.call(A)}},{}],137:[function(A,e,t){"use strict";var i=A("inherits"),g=A("hash-base"),r=A("safe-buffer").Buffer,n=new Array(16);function B(){g.call(this,64),this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878}function I(A,e){return A<>>32-e}function o(A,e,t,i,g,r,n){return I(A+(e&t|~e&i)+g+r|0,n)+e|0}function a(A,e,t,i,g,r,n){return I(A+(e&i|t&~i)+g+r|0,n)+e|0}function Q(A,e,t,i,g,r,n){return I(A+(e^t^i)+g+r|0,n)+e|0}function C(A,e,t,i,g,r,n){return I(A+(t^(e|~i))+g+r|0,n)+e|0}i(B,g),B.prototype._update=function(){for(var A=n,e=0;e<16;++e)A[e]=this._block.readInt32LE(4*e);var t=this._a,i=this._b,g=this._c,r=this._d;i=C(i=C(i=C(i=C(i=Q(i=Q(i=Q(i=Q(i=a(i=a(i=a(i=a(i=o(i=o(i=o(i=o(i,g=o(g,r=o(r,t=o(t,i,g,r,A[0],3614090360,7),i,g,A[1],3905402710,12),t,i,A[2],606105819,17),r,t,A[3],3250441966,22),g=o(g,r=o(r,t=o(t,i,g,r,A[4],4118548399,7),i,g,A[5],1200080426,12),t,i,A[6],2821735955,17),r,t,A[7],4249261313,22),g=o(g,r=o(r,t=o(t,i,g,r,A[8],1770035416,7),i,g,A[9],2336552879,12),t,i,A[10],4294925233,17),r,t,A[11],2304563134,22),g=o(g,r=o(r,t=o(t,i,g,r,A[12],1804603682,7),i,g,A[13],4254626195,12),t,i,A[14],2792965006,17),r,t,A[15],1236535329,22),g=a(g,r=a(r,t=a(t,i,g,r,A[1],4129170786,5),i,g,A[6],3225465664,9),t,i,A[11],643717713,14),r,t,A[0],3921069994,20),g=a(g,r=a(r,t=a(t,i,g,r,A[5],3593408605,5),i,g,A[10],38016083,9),t,i,A[15],3634488961,14),r,t,A[4],3889429448,20),g=a(g,r=a(r,t=a(t,i,g,r,A[9],568446438,5),i,g,A[14],3275163606,9),t,i,A[3],4107603335,14),r,t,A[8],1163531501,20),g=a(g,r=a(r,t=a(t,i,g,r,A[13],2850285829,5),i,g,A[2],4243563512,9),t,i,A[7],1735328473,14),r,t,A[12],2368359562,20),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[5],4294588738,4),i,g,A[8],2272392833,11),t,i,A[11],1839030562,16),r,t,A[14],4259657740,23),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[1],2763975236,4),i,g,A[4],1272893353,11),t,i,A[7],4139469664,16),r,t,A[10],3200236656,23),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[13],681279174,4),i,g,A[0],3936430074,11),t,i,A[3],3572445317,16),r,t,A[6],76029189,23),g=Q(g,r=Q(r,t=Q(t,i,g,r,A[9],3654602809,4),i,g,A[12],3873151461,11),t,i,A[15],530742520,16),r,t,A[2],3299628645,23),g=C(g,r=C(r,t=C(t,i,g,r,A[0],4096336452,6),i,g,A[7],1126891415,10),t,i,A[14],2878612391,15),r,t,A[5],4237533241,21),g=C(g,r=C(r,t=C(t,i,g,r,A[12],1700485571,6),i,g,A[3],2399980690,10),t,i,A[10],4293915773,15),r,t,A[1],2240044497,21),g=C(g,r=C(r,t=C(t,i,g,r,A[8],1873313359,6),i,g,A[15],4264355552,10),t,i,A[6],2734768916,15),r,t,A[13],1309151649,21),g=C(g,r=C(r,t=C(t,i,g,r,A[4],4149444226,6),i,g,A[11],3174756917,10),t,i,A[2],718787259,15),r,t,A[9],3951481745,21),this._a=this._a+t|0,this._b=this._b+i|0,this._c=this._c+g|0,this._d=this._d+r|0},B.prototype._digest=function(){this._block[this._blockOffset++]=128,this._blockOffset>56&&(this._block.fill(0,this._blockOffset,64),this._update(),this._blockOffset=0),this._block.fill(0,this._blockOffset,56),this._block.writeUInt32LE(this._length[0],56),this._block.writeUInt32LE(this._length[1],60),this._update();var A=r.allocUnsafe(16);return A.writeInt32LE(this._a,0),A.writeInt32LE(this._b,4),A.writeInt32LE(this._c,8),A.writeInt32LE(this._d,12),A},e.exports=B},{"hash-base":104,inherits:134,"safe-buffer":180}],138:[function(A,e,t){var i=A("bn.js"),g=A("brorand");function r(A){this.rand=A||new g.Rand}e.exports=r,r.create=function(A){return new r(A)},r.prototype._randbelow=function(A){var e=A.bitLength(),t=Math.ceil(e/8);do{var g=new i(this.rand.generate(t))}while(g.cmp(A)>=0);return g},r.prototype._randrange=function(A,e){var t=e.sub(A);return A.add(this._randbelow(t))},r.prototype.test=function(A,e,t){var g=A.bitLength(),r=i.mont(A),n=new i(1).toRed(r);e||(e=Math.max(1,g/48|0));for(var B=A.subn(1),I=0;!B.testn(I);I++);for(var o=A.shrn(I),a=B.toRed(r);e>0;e--){var Q=this._randrange(new i(2),B);t&&t(Q);var C=Q.toRed(r).redPow(o);if(0!==C.cmp(n)&&0!==C.cmp(a)){for(var s=1;s0;e--){var a=this._randrange(new i(2),n),Q=A.gcd(a);if(0!==Q.cmpn(1))return Q;var C=a.toRed(g).redPow(I);if(0!==C.cmp(r)&&0!==C.cmp(o)){for(var s=1;s>8,n=255&g;r?t.push(r,n):t.push(n)}return t},i.zero2=g,i.toHex=r,i.encode=function(A,e){return"hex"===e?r(A):A}},{}],142:[function(A,e,t){e.exports={"2.16.840.1.101.3.4.1.1":"aes-128-ecb","2.16.840.1.101.3.4.1.2":"aes-128-cbc","2.16.840.1.101.3.4.1.3":"aes-128-ofb","2.16.840.1.101.3.4.1.4":"aes-128-cfb","2.16.840.1.101.3.4.1.21":"aes-192-ecb","2.16.840.1.101.3.4.1.22":"aes-192-cbc","2.16.840.1.101.3.4.1.23":"aes-192-ofb","2.16.840.1.101.3.4.1.24":"aes-192-cfb","2.16.840.1.101.3.4.1.41":"aes-256-ecb","2.16.840.1.101.3.4.1.42":"aes-256-cbc","2.16.840.1.101.3.4.1.43":"aes-256-ofb","2.16.840.1.101.3.4.1.44":"aes-256-cfb"}},{}],143:[function(A,e,t){"use strict";var i=A("asn1.js");t.certificate=A("./certificate");var g=i.define("RSAPrivateKey",function(){this.seq().obj(this.key("version").int(),this.key("modulus").int(),this.key("publicExponent").int(),this.key("privateExponent").int(),this.key("prime1").int(),this.key("prime2").int(),this.key("exponent1").int(),this.key("exponent2").int(),this.key("coefficient").int())});t.RSAPrivateKey=g;var r=i.define("RSAPublicKey",function(){this.seq().obj(this.key("modulus").int(),this.key("publicExponent").int())});t.RSAPublicKey=r;var n=i.define("SubjectPublicKeyInfo",function(){this.seq().obj(this.key("algorithm").use(B),this.key("subjectPublicKey").bitstr())});t.PublicKey=n;var B=i.define("AlgorithmIdentifier",function(){this.seq().obj(this.key("algorithm").objid(),this.key("none").null_().optional(),this.key("curve").objid().optional(),this.key("params").seq().obj(this.key("p").int(),this.key("q").int(),this.key("g").int()).optional())}),I=i.define("PrivateKeyInfo",function(){this.seq().obj(this.key("version").int(),this.key("algorithm").use(B),this.key("subjectPrivateKey").octstr())});t.PrivateKey=I;var o=i.define("EncryptedPrivateKeyInfo",function(){this.seq().obj(this.key("algorithm").seq().obj(this.key("id").objid(),this.key("decrypt").seq().obj(this.key("kde").seq().obj(this.key("id").objid(),this.key("kdeparams").seq().obj(this.key("salt").octstr(),this.key("iters").int())),this.key("cipher").seq().obj(this.key("algo").objid(),this.key("iv").octstr()))),this.key("subjectPrivateKey").octstr())});t.EncryptedPrivateKey=o;var a=i.define("DSAPrivateKey",function(){this.seq().obj(this.key("version").int(),this.key("p").int(),this.key("q").int(),this.key("g").int(),this.key("pub_key").int(),this.key("priv_key").int())});t.DSAPrivateKey=a,t.DSAparam=i.define("DSAparam",function(){this.int()});var Q=i.define("ECPrivateKey",function(){this.seq().obj(this.key("version").int(),this.key("privateKey").octstr(),this.key("parameters").optional().explicit(0).use(C),this.key("publicKey").optional().explicit(1).bitstr())});t.ECPrivateKey=Q;var C=i.define("ECParameters",function(){this.choice({namedCurve:this.objid()})});t.signature=i.define("signature",function(){this.seq().obj(this.key("r").int(),this.key("s").int())})},{"./certificate":144,"asn1.js":1}],144:[function(A,e,t){"use strict";var i=A("asn1.js"),g=i.define("Time",function(){this.choice({utcTime:this.utctime(),generalTime:this.gentime()})}),r=i.define("AttributeTypeValue",function(){this.seq().obj(this.key("type").objid(),this.key("value").any())}),n=i.define("AlgorithmIdentifier",function(){this.seq().obj(this.key("algorithm").objid(),this.key("parameters").optional(),this.key("curve").objid().optional())}),B=i.define("SubjectPublicKeyInfo",function(){this.seq().obj(this.key("algorithm").use(n),this.key("subjectPublicKey").bitstr())}),I=i.define("RelativeDistinguishedName",function(){this.setof(r)}),o=i.define("RDNSequence",function(){this.seqof(I)}),a=i.define("Name",function(){this.choice({rdnSequence:this.use(o)})}),Q=i.define("Validity",function(){this.seq().obj(this.key("notBefore").use(g),this.key("notAfter").use(g))}),C=i.define("Extension",function(){this.seq().obj(this.key("extnID").objid(),this.key("critical").bool().def(!1),this.key("extnValue").octstr())}),s=i.define("TBSCertificate",function(){this.seq().obj(this.key("version").explicit(0).int().optional(),this.key("serialNumber").int(),this.key("signature").use(n),this.key("issuer").use(a),this.key("validity").use(Q),this.key("subject").use(a),this.key("subjectPublicKeyInfo").use(B),this.key("issuerUniqueID").implicit(1).bitstr().optional(),this.key("subjectUniqueID").implicit(2).bitstr().optional(),this.key("extensions").explicit(3).seqof(C).optional())}),c=i.define("X509Certificate",function(){this.seq().obj(this.key("tbsCertificate").use(s),this.key("signatureAlgorithm").use(n),this.key("signatureValue").bitstr())});e.exports=c},{"asn1.js":1}],145:[function(A,e,t){var i=/Proc-Type: 4,ENCRYPTED[\n\r]+DEK-Info: AES-((?:128)|(?:192)|(?:256))-CBC,([0-9A-H]+)[\n\r]+([0-9A-z\n\r+/=]+)[\n\r]+/m,g=/^-----BEGIN ((?:.*? KEY)|CERTIFICATE)-----/m,r=/^-----BEGIN ((?:.*? KEY)|CERTIFICATE)-----([0-9A-z\n\r+/=]+)-----END \1-----$/m,n=A("evp_bytestokey"),B=A("browserify-aes"),I=A("safe-buffer").Buffer;e.exports=function(A,e){var t,o=A.toString(),a=o.match(i);if(a){var Q="aes"+a[1],C=I.from(a[2],"hex"),s=I.from(a[3].replace(/[\r\n]/g,""),"base64"),c=n(e,C.slice(0,8),parseInt(a[1],10)).key,h=[],f=B.createDecipheriv(Q,c,C);h.push(f.update(s)),h.push(f.final()),t=I.concat(h)}else{var E=o.match(r);t=I.from(E[2].replace(/[\r\n]/g,""),"base64")}return{tag:o.match(g)[1],data:t}}},{"browserify-aes":22,evp_bytestokey:103,"safe-buffer":180}],146:[function(A,e,t){var i=A("./asn1"),g=A("./aesid.json"),r=A("./fixProc"),n=A("browserify-aes"),B=A("pbkdf2"),I=A("safe-buffer").Buffer;function o(A){var e;"object"!=typeof A||I.isBuffer(A)||(e=A.passphrase,A=A.key),"string"==typeof A&&(A=I.from(A));var t,o,a=r(A,e),Q=a.tag,C=a.data;switch(Q){case"CERTIFICATE":o=i.certificate.decode(C,"der").tbsCertificate.subjectPublicKeyInfo;case"PUBLIC KEY":switch(o||(o=i.PublicKey.decode(C,"der")),t=o.algorithm.algorithm.join(".")){case"1.2.840.113549.1.1.1":return i.RSAPublicKey.decode(o.subjectPublicKey.data,"der");case"1.2.840.10045.2.1":return o.subjectPrivateKey=o.subjectPublicKey,{type:"ec",data:o};case"1.2.840.10040.4.1":return o.algorithm.params.pub_key=i.DSAparam.decode(o.subjectPublicKey.data,"der"),{type:"dsa",data:o.algorithm.params};default:throw new Error("unknown key id "+t)}case"ENCRYPTED PRIVATE KEY":C=function(A,e){var t=A.algorithm.decrypt.kde.kdeparams.salt,i=parseInt(A.algorithm.decrypt.kde.kdeparams.iters.toString(),10),r=g[A.algorithm.decrypt.cipher.algo.join(".")],o=A.algorithm.decrypt.cipher.iv,a=A.subjectPrivateKey,Q=parseInt(r.split("-")[1],10)/8,C=B.pbkdf2Sync(e,t,i,Q,"sha1"),s=n.createDecipheriv(r,C,o),c=[];return c.push(s.update(a)),c.push(s.final()),I.concat(c)}(C=i.EncryptedPrivateKey.decode(C,"der"),e);case"PRIVATE KEY":switch(t=(o=i.PrivateKey.decode(C,"der")).algorithm.algorithm.join(".")){case"1.2.840.113549.1.1.1":return i.RSAPrivateKey.decode(o.subjectPrivateKey,"der");case"1.2.840.10045.2.1":return{curve:o.algorithm.curve,privateKey:i.ECPrivateKey.decode(o.subjectPrivateKey,"der").privateKey};case"1.2.840.10040.4.1":return o.algorithm.params.priv_key=i.DSAparam.decode(o.subjectPrivateKey,"der"),{type:"dsa",params:o.algorithm.params};default:throw new Error("unknown key id "+t)}case"RSA PUBLIC KEY":return i.RSAPublicKey.decode(C,"der");case"RSA PRIVATE KEY":return i.RSAPrivateKey.decode(C,"der");case"DSA PRIVATE KEY":return{type:"dsa",params:i.DSAPrivateKey.decode(C,"der")};case"EC PRIVATE KEY":return{curve:(C=i.ECPrivateKey.decode(C,"der")).parameters.value,privateKey:C.privateKey};default:throw new Error("unknown key type "+Q)}}e.exports=o,o.signature=i.signature},{"./aesid.json":142,"./asn1":143,"./fixProc":145,"browserify-aes":22,pbkdf2:147,"safe-buffer":180}],147:[function(A,e,t){t.pbkdf2=A("./lib/async"),t.pbkdf2Sync=A("./lib/sync")},{"./lib/async":148,"./lib/sync":151}],148:[function(A,e,t){(function(t,i){var g,r=A("safe-buffer").Buffer,n=A("./precondition"),B=A("./default-encoding"),I=A("./sync"),o=A("./to-buffer"),a=i.crypto&&i.crypto.subtle,Q={sha:"SHA-1","sha-1":"SHA-1",sha1:"SHA-1",sha256:"SHA-256","sha-256":"SHA-256",sha384:"SHA-384","sha-384":"SHA-384","sha-512":"SHA-512",sha512:"SHA-512"},C=[];function s(A,e,t,i,g){return a.importKey("raw",A,{name:"PBKDF2"},!1,["deriveBits"]).then(function(A){return a.deriveBits({name:"PBKDF2",salt:e,iterations:t,hash:{name:g}},A,i<<3)}).then(function(A){return r.from(A)})}e.exports=function(A,e,c,h,f,E){"function"==typeof f&&(E=f,f=void 0);var u=Q[(f=f||"sha1").toLowerCase()];if(!u||"function"!=typeof i.Promise)return t.nextTick(function(){var t;try{t=I(A,e,c,h,f)}catch(A){return E(A)}E(null,t)});if(n(c,h),A=o(A,B,"Password"),e=o(e,B,"Salt"),"function"!=typeof E)throw new Error("No callback provided to pbkdf2");!function(A,e){A.then(function(A){t.nextTick(function(){e(null,A)})},function(A){t.nextTick(function(){e(A)})})}(function(A){if(i.process&&!i.process.browser)return Promise.resolve(!1);if(!a||!a.importKey||!a.deriveBits)return Promise.resolve(!1);if(void 0!==C[A])return C[A];var e=s(g=g||r.alloc(8),g,10,128,A).then(function(){return!0}).catch(function(){return!1});return C[A]=e,e}(u).then(function(t){return t?s(A,e,c,h,u):I(A,e,c,h,f)}),E)}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"./default-encoding":149,"./precondition":150,"./sync":151,"./to-buffer":152,_process:154,"safe-buffer":180}],149:[function(A,e,t){(function(A){var t;if(A.browser)t="utf-8";else if(A.version){t=parseInt(A.version.split(".")[0].slice(1),10)>=6?"utf-8":"binary"}else t="utf-8";e.exports=t}).call(this,A("_process"))},{_process:154}],150:[function(A,e,t){var i=Math.pow(2,30)-1;e.exports=function(A,e){if("number"!=typeof A)throw new TypeError("Iterations not a number");if(A<0)throw new TypeError("Bad iterations");if("number"!=typeof e)throw new TypeError("Key length not a number");if(e<0||e>i||e!=e)throw new TypeError("Bad key length")}},{}],151:[function(A,e,t){var i=A("create-hash/md5"),g=A("ripemd160"),r=A("sha.js"),n=A("safe-buffer").Buffer,B=A("./precondition"),I=A("./default-encoding"),o=A("./to-buffer"),a=n.alloc(128),Q={md5:16,sha1:20,sha224:28,sha256:32,sha384:48,sha512:64,rmd160:20,ripemd160:20};function C(A,e,t){var B=function(A){return"rmd160"===A||"ripemd160"===A?function(A){return(new g).update(A).digest()}:"md5"===A?i:function(e){return r(A).update(e).digest()}}(A),I="sha512"===A||"sha384"===A?128:64;e.length>I?e=B(e):e.length1)for(var t=1;tc||new n(e).cmp(s.modulus)>=0)throw new Error("decryption error");C=t?o(new n(e),s):B(e,s);var h=a.alloc(c-C.length);if(C=a.concat([h,C],c),4===Q)return function(A,e){var t=A.modulus.byteLength(),i=I("sha1").update(a.alloc(0)).digest(),n=i.length;if(0!==e[0])throw new Error("decryption error");var B=e.slice(1,n+1),o=e.slice(n+1),Q=r(B,g(o,n)),C=r(o,g(Q,t-n-1));if(function(A,e){A=a.from(A),e=a.from(e);var t=0,i=A.length;A.length!==e.length&&(t++,i=Math.min(A.length,e.length));var g=-1;for(;++g=e.length){r++;break}var n=e.slice(2,g-1);("0002"!==i.toString("hex")&&!t||"0001"!==i.toString("hex")&&t)&&r++;n.length<8&&r++;if(r)throw new Error("decryption error");return e.slice(g)}(0,C,t);if(3===Q)return C;throw new Error("unknown padding")}},{"./mgf":156,"./withPublic":160,"./xor":161,"bn.js":157,"browserify-rsa":40,"create-hash":69,"parse-asn1":146,"safe-buffer":180}],159:[function(A,e,t){var i=A("parse-asn1"),g=A("randombytes"),r=A("create-hash"),n=A("./mgf"),B=A("./xor"),I=A("bn.js"),o=A("./withPublic"),a=A("browserify-rsa"),Q=A("safe-buffer").Buffer;e.exports=function(A,e,t){var C;C=A.padding?A.padding:t?1:4;var s,c=i(A);if(4===C)s=function(A,e){var t=A.modulus.byteLength(),i=e.length,o=r("sha1").update(Q.alloc(0)).digest(),a=o.length,C=2*a;if(i>t-C-2)throw new Error("message too long");var s=Q.alloc(t-i-C-2),c=t-a-1,h=g(a),f=B(Q.concat([o,s,Q.alloc(1,1),e],c),n(h,c)),E=B(h,n(f,a));return new I(Q.concat([Q.alloc(1),E,f],t))}(c,e);else if(1===C)s=function(A,e,t){var i,r=e.length,n=A.modulus.byteLength();if(r>n-11)throw new Error("message too long");i=t?Q.alloc(n-r-3,255):function(A){var e,t=Q.allocUnsafe(A),i=0,r=g(2*A),n=0;for(;i=0)throw new Error("data too long for modulus")}return t?a(s,c):o(s,c)}},{"./mgf":156,"./withPublic":160,"./xor":161,"bn.js":157,"browserify-rsa":40,"create-hash":69,"parse-asn1":146,randombytes:162,"safe-buffer":180}],160:[function(A,e,t){var i=A("bn.js"),g=A("safe-buffer").Buffer;e.exports=function(A,e){return g.from(A.toRed(i.mont(e.modulus)).redPow(new i(e.publicExponent)).fromRed().toArray())}},{"bn.js":157,"safe-buffer":180}],161:[function(A,e,t){e.exports=function(A,e){for(var t=A.length,i=-1;++ir)throw new RangeError("requested too many random bytes");var i=n.allocUnsafe(A);if(A>0)if(A>g)for(var I=0;Ia||A<0)throw new TypeError("offset must be a uint32");if(A>I||A>e)throw new RangeError("offset out of range")}function C(A,e,t){if("number"!=typeof A||A!=A)throw new TypeError("size must be a number");if(A>a||A<0)throw new TypeError("size must be a uint32");if(A+e>t||A>I)throw new RangeError("buffer too small")}function s(A,t,i,g){if(e.browser){var r=A.buffer,B=new Uint8Array(r,t,i);return o.getRandomValues(B),g?void e.nextTick(function(){g(null,A)}):A}if(!g)return n(i).copy(A,t),A;n(i,function(e,i){if(e)return g(e);i.copy(A,t),g(null,A)})}o&&o.getRandomValues||!e.browser?(t.randomFill=function(A,e,t,g){if(!(B.isBuffer(A)||A instanceof i.Uint8Array))throw new TypeError('"buf" argument must be a Buffer or Uint8Array');if("function"==typeof e)g=e,e=0,t=A.length;else if("function"==typeof t)g=t,t=A.length-e;else if("function"!=typeof g)throw new TypeError('"cb" argument must be a function');return Q(e,A.length),C(t,e,A.length),s(A,e,t,g)},t.randomFillSync=function(A,e,t){void 0===e&&(e=0);if(!(B.isBuffer(A)||A instanceof i.Uint8Array))throw new TypeError('"buf" argument must be a Buffer or Uint8Array');Q(e,A.length),void 0===t&&(t=A.length-e);return C(t,e,A.length),s(A,e,t)}):(t.randomFill=g,t.randomFillSync=g)}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{_process:154,randombytes:162,"safe-buffer":180}],164:[function(A,e,t){e.exports=A("./lib/_stream_duplex.js")},{"./lib/_stream_duplex.js":165}],165:[function(A,e,t){"use strict";var i=A("process-nextick-args"),g=Object.keys||function(A){var e=[];for(var t in A)e.push(t);return e};e.exports=Q;var r=Object.create(A("core-util-is"));r.inherits=A("inherits");var n=A("./_stream_readable"),B=A("./_stream_writable");r.inherits(Q,n);for(var I=g(B.prototype),o=0;o0?("string"==typeof e||n.objectMode||Object.getPrototypeOf(e)===o.prototype||(e=function(A){return o.from(A)}(e)),i?n.endEmitted?A.emit("error",new Error("stream.unshift() after end event")):w(A,n,e,!0):n.ended?A.emit("error",new Error("stream.push() after EOF")):(n.reading=!1,n.decoder&&!t?(e=n.decoder.write(e),n.objectMode||0!==e.length?w(A,n,e,!1):M(A,n)):w(A,n,e,!1))):i||(n.reading=!1));return function(A){return!A.ended&&(A.needReadable||A.lengthe.highWaterMark&&(e.highWaterMark=function(A){return A>=p?A=p:(A--,A|=A>>>1,A|=A>>>2,A|=A>>>4,A|=A>>>8,A|=A>>>16,A++),A}(A)),A<=e.length?A:e.ended?e.length:(e.needReadable=!0,0))}function b(A){var e=A._readableState;e.needReadable=!1,e.emittedReadable||(s("emitReadable",e.flowing),e.emittedReadable=!0,e.sync?g.nextTick(y,A):y(A))}function y(A){s("emit readable"),A.emit("readable"),F(A)}function M(A,e){e.readingMore||(e.readingMore=!0,g.nextTick(m,A,e))}function m(A,e){for(var t=e.length;!e.reading&&!e.flowing&&!e.ended&&e.length=e.length?(t=e.decoder?e.buffer.join(""):1===e.buffer.length?e.buffer.head.data:e.buffer.concat(e.length),e.buffer.clear()):t=function(A,e,t){var i;Ar.length?r.length:A;if(n===r.length?g+=r:g+=r.slice(0,A),0===(A-=n)){n===r.length?(++i,t.next?e.head=t.next:e.head=e.tail=null):(e.head=t,t.data=r.slice(n));break}++i}return e.length-=i,g}(A,e):function(A,e){var t=o.allocUnsafe(A),i=e.head,g=1;i.data.copy(t),A-=i.data.length;for(;i=i.next;){var r=i.data,n=A>r.length?r.length:A;if(r.copy(t,t.length-A,0,n),0===(A-=n)){n===r.length?(++g,i.next?e.head=i.next:e.head=e.tail=null):(e.head=i,i.data=r.slice(n));break}++g}return e.length-=g,t}(A,e);return i}(A,e.buffer,e.decoder),t);var t}function S(A){var e=A._readableState;if(e.length>0)throw new Error('"endReadable()" called on non-empty stream');e.endEmitted||(e.ended=!0,g.nextTick(Y,e,A))}function Y(A,e){A.endEmitted||0!==A.length||(A.endEmitted=!0,e.readable=!1,e.emit("end"))}function v(A,e){for(var t=0,i=A.length;t=e.highWaterMark||e.ended))return s("read: emitReadable",e.length,e.ended),0===e.length&&e.ended?S(this):b(this),null;if(0===(A=D(A,e))&&e.ended)return 0===e.length&&S(this),null;var i,g=e.needReadable;return s("need readable",g),(0===e.length||e.length-A0?N(A,e):null)?(e.needReadable=!0,A=0):e.length-=A,0===e.length&&(e.ended||(e.needReadable=!0),t!==A&&e.ended&&S(this)),null!==i&&this.emit("data",i),i},d.prototype._read=function(A){this.emit("error",new Error("_read() is not implemented"))},d.prototype.pipe=function(A,e){var i=this,r=this._readableState;switch(r.pipesCount){case 0:r.pipes=A;break;case 1:r.pipes=[r.pipes,A];break;default:r.pipes.push(A)}r.pipesCount+=1,s("pipe count=%d opts=%j",r.pipesCount,e);var I=(!e||!1!==e.end)&&A!==t.stdout&&A!==t.stderr?a:d;function o(e,t){s("onunpipe"),e===i&&t&&!1===t.hasUnpiped&&(t.hasUnpiped=!0,s("cleanup"),A.removeListener("close",E),A.removeListener("finish",u),A.removeListener("drain",Q),A.removeListener("error",f),A.removeListener("unpipe",o),i.removeListener("end",a),i.removeListener("end",d),i.removeListener("data",h),C=!0,!r.awaitDrain||A._writableState&&!A._writableState.needDrain||Q())}function a(){s("onend"),A.end()}r.endEmitted?g.nextTick(I):i.once("end",I),A.on("unpipe",o);var Q=function(A){return function(){var e=A._readableState;s("pipeOnDrain",e.awaitDrain),e.awaitDrain&&e.awaitDrain--,0===e.awaitDrain&&B(A,"data")&&(e.flowing=!0,F(A))}}(i);A.on("drain",Q);var C=!1;var c=!1;function h(e){s("ondata"),c=!1,!1!==A.write(e)||c||((1===r.pipesCount&&r.pipes===A||r.pipesCount>1&&-1!==v(r.pipes,A))&&!C&&(s("false write response, pause",i._readableState.awaitDrain),i._readableState.awaitDrain++,c=!0),i.pause())}function f(e){s("onerror",e),d(),A.removeListener("error",f),0===B(A,"error")&&A.emit("error",e)}function E(){A.removeListener("finish",u),d()}function u(){s("onfinish"),A.removeListener("close",E),d()}function d(){s("unpipe"),i.unpipe(A)}return i.on("data",h),function(A,e,t){if("function"==typeof A.prependListener)return A.prependListener(e,t);A._events&&A._events[e]?n(A._events[e])?A._events[e].unshift(t):A._events[e]=[t,A._events[e]]:A.on(e,t)}(A,"error",f),A.once("close",E),A.once("finish",u),A.emit("pipe",i),r.flowing||(s("pipe resume"),i.resume()),A},d.prototype.unpipe=function(A){var e=this._readableState,t={hasUnpiped:!1};if(0===e.pipesCount)return this;if(1===e.pipesCount)return A&&A!==e.pipes?this:(A||(A=e.pipes),e.pipes=null,e.pipesCount=0,e.flowing=!1,A&&A.emit("unpipe",this,t),this);if(!A){var i=e.pipes,g=e.pipesCount;e.pipes=null,e.pipesCount=0,e.flowing=!1;for(var r=0;r-1?g:r.nextTick;u.WritableState=E;var o=Object.create(A("core-util-is"));o.inherits=A("inherits");var a={deprecate:A("util-deprecate")},Q=A("./internal/streams/stream"),C=A("safe-buffer").Buffer,s=i.Uint8Array||function(){};var c,h=A("./internal/streams/destroy");function f(){}function E(e,t){B=B||A("./_stream_duplex"),e=e||{};var i=t instanceof B;this.objectMode=!!e.objectMode,i&&(this.objectMode=this.objectMode||!!e.writableObjectMode);var g=e.highWaterMark,o=e.writableHighWaterMark,a=this.objectMode?16:16384;this.highWaterMark=g||0===g?g:i&&(o||0===o)?o:a,this.highWaterMark=Math.floor(this.highWaterMark),this.finalCalled=!1,this.needDrain=!1,this.ending=!1,this.ended=!1,this.finished=!1,this.destroyed=!1;var Q=!1===e.decodeStrings;this.decodeStrings=!Q,this.defaultEncoding=e.defaultEncoding||"utf8",this.length=0,this.writing=!1,this.corked=0,this.sync=!0,this.bufferProcessing=!1,this.onwrite=function(A){!function(A,e){var t=A._writableState,i=t.sync,g=t.writecb;if(function(A){A.writing=!1,A.writecb=null,A.length-=A.writelen,A.writelen=0}(t),e)!function(A,e,t,i,g){--e.pendingcb,t?(r.nextTick(g,i),r.nextTick(b,A,e),A._writableState.errorEmitted=!0,A.emit("error",i)):(g(i),A._writableState.errorEmitted=!0,A.emit("error",i),b(A,e))}(A,t,i,e,g);else{var n=p(t);n||t.corked||t.bufferProcessing||!t.bufferedRequest||w(A,t),i?I(l,A,t,n,g):l(A,t,n,g)}}(t,A)},this.writecb=null,this.writelen=0,this.bufferedRequest=null,this.lastBufferedRequest=null,this.pendingcb=0,this.prefinished=!1,this.errorEmitted=!1,this.bufferedRequestCount=0,this.corkedRequestsFree=new n(this)}function u(e){if(B=B||A("./_stream_duplex"),!(c.call(u,this)||this instanceof B))return new u(e);this._writableState=new E(e,this),this.writable=!0,e&&("function"==typeof e.write&&(this._write=e.write),"function"==typeof e.writev&&(this._writev=e.writev),"function"==typeof e.destroy&&(this._destroy=e.destroy),"function"==typeof e.final&&(this._final=e.final)),Q.call(this)}function d(A,e,t,i,g,r,n){e.writelen=i,e.writecb=n,e.writing=!0,e.sync=!0,t?A._writev(g,e.onwrite):A._write(g,r,e.onwrite),e.sync=!1}function l(A,e,t,i){t||function(A,e){0===e.length&&e.needDrain&&(e.needDrain=!1,A.emit("drain"))}(A,e),e.pendingcb--,i(),b(A,e)}function w(A,e){e.bufferProcessing=!0;var t=e.bufferedRequest;if(A._writev&&t&&t.next){var i=e.bufferedRequestCount,g=new Array(i),r=e.corkedRequestsFree;r.entry=t;for(var B=0,I=!0;t;)g[B]=t,t.isBuf||(I=!1),t=t.next,B+=1;g.allBuffers=I,d(A,e,!0,e.length,g,"",r.finish),e.pendingcb++,e.lastBufferedRequest=null,r.next?(e.corkedRequestsFree=r.next,r.next=null):e.corkedRequestsFree=new n(e),e.bufferedRequestCount=0}else{for(;t;){var o=t.chunk,a=t.encoding,Q=t.callback;if(d(A,e,!1,e.objectMode?1:o.length,o,a,Q),t=t.next,e.bufferedRequestCount--,e.writing)break}null===t&&(e.lastBufferedRequest=null)}e.bufferedRequest=t,e.bufferProcessing=!1}function p(A){return A.ending&&0===A.length&&null===A.bufferedRequest&&!A.finished&&!A.writing}function D(A,e){A._final(function(t){e.pendingcb--,t&&A.emit("error",t),e.prefinished=!0,A.emit("prefinish"),b(A,e)})}function b(A,e){var t=p(e);return t&&(!function(A,e){e.prefinished||e.finalCalled||("function"==typeof A._final?(e.pendingcb++,e.finalCalled=!0,r.nextTick(D,A,e)):(e.prefinished=!0,A.emit("prefinish")))}(A,e),0===e.pendingcb&&(e.finished=!0,A.emit("finish"))),t}o.inherits(u,Q),E.prototype.getBuffer=function(){for(var A=this.bufferedRequest,e=[];A;)e.push(A),A=A.next;return e},function(){try{Object.defineProperty(E.prototype,"buffer",{get:a.deprecate(function(){return this.getBuffer()},"_writableState.buffer is deprecated. Use _writableState.getBuffer instead.","DEP0003")})}catch(A){}}(),"function"==typeof Symbol&&Symbol.hasInstance&&"function"==typeof Function.prototype[Symbol.hasInstance]?(c=Function.prototype[Symbol.hasInstance],Object.defineProperty(u,Symbol.hasInstance,{value:function(A){return!!c.call(this,A)||this===u&&(A&&A._writableState instanceof E)}})):c=function(A){return A instanceof this},u.prototype.pipe=function(){this.emit("error",new Error("Cannot pipe, not readable"))},u.prototype.write=function(A,e,t){var i,g=this._writableState,n=!1,B=!g.objectMode&&(i=A,C.isBuffer(i)||i instanceof s);return B&&!C.isBuffer(A)&&(A=function(A){return C.from(A)}(A)),"function"==typeof e&&(t=e,e=null),B?e="buffer":e||(e=g.defaultEncoding),"function"!=typeof t&&(t=f),g.ended?function(A,e){var t=new Error("write after end");A.emit("error",t),r.nextTick(e,t)}(this,t):(B||function(A,e,t,i){var g=!0,n=!1;return null===t?n=new TypeError("May not write null values to stream"):"string"==typeof t||void 0===t||e.objectMode||(n=new TypeError("Invalid non-string/buffer chunk")),n&&(A.emit("error",n),r.nextTick(i,n),g=!1),g}(this,g,A,t))&&(g.pendingcb++,n=function(A,e,t,i,g,r){if(!t){var n=function(A,e,t){A.objectMode||!1===A.decodeStrings||"string"!=typeof e||(e=C.from(e,t));return e}(e,i,g);i!==n&&(t=!0,g="buffer",i=n)}var B=e.objectMode?1:i.length;e.length+=B;var I=e.length-1))throw new TypeError("Unknown encoding: "+A);return this._writableState.defaultEncoding=A,this},Object.defineProperty(u.prototype,"writableHighWaterMark",{enumerable:!1,get:function(){return this._writableState.highWaterMark}}),u.prototype._write=function(A,e,t){t(new Error("_write() is not implemented"))},u.prototype._writev=null,u.prototype.end=function(A,e,t){var i=this._writableState;"function"==typeof A?(t=A,A=null,e=null):"function"==typeof e&&(t=e,e=null),null!==A&&void 0!==A&&this.write(A,e),i.corked&&(i.corked=1,this.uncork()),i.ending||i.finished||function(A,e,t){e.ending=!0,b(A,e),t&&(e.finished?r.nextTick(t):A.once("finish",t));e.ended=!0,A.writable=!1}(this,i,t)},Object.defineProperty(u.prototype,"destroyed",{get:function(){return void 0!==this._writableState&&this._writableState.destroyed},set:function(A){this._writableState&&(this._writableState.destroyed=A)}}),u.prototype.destroy=h.destroy,u.prototype._undestroy=h.undestroy,u.prototype._destroy=function(A,e){this.end(),e(A)}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{},A("timers").setImmediate)},{"./_stream_duplex":165,"./internal/streams/destroy":171,"./internal/streams/stream":172,_process:154,"core-util-is":66,inherits:134,"process-nextick-args":153,"safe-buffer":173,timers:192,"util-deprecate":193}],170:[function(A,e,t){"use strict";var i=A("safe-buffer").Buffer,g=A("util");e.exports=function(){function A(){!function(A,e){if(!(A instanceof e))throw new TypeError("Cannot call a class as a function")}(this,A),this.head=null,this.tail=null,this.length=0}return A.prototype.push=function(A){var e={data:A,next:null};this.length>0?this.tail.next=e:this.head=e,this.tail=e,++this.length},A.prototype.unshift=function(A){var e={data:A,next:this.head};0===this.length&&(this.tail=e),this.head=e,++this.length},A.prototype.shift=function(){if(0!==this.length){var A=this.head.data;return 1===this.length?this.head=this.tail=null:this.head=this.head.next,--this.length,A}},A.prototype.clear=function(){this.head=this.tail=null,this.length=0},A.prototype.join=function(A){if(0===this.length)return"";for(var e=this.head,t=""+e.data;e=e.next;)t+=A+e.data;return t},A.prototype.concat=function(A){if(0===this.length)return i.alloc(0);if(1===this.length)return this.head.data;for(var e,t,g,r=i.allocUnsafe(A>>>0),n=this.head,B=0;n;)e=n.data,t=r,g=B,e.copy(t,g),B+=n.data.length,n=n.next;return r},A}(),g&&g.inspect&&g.inspect.custom&&(e.exports.prototype[g.inspect.custom]=function(){var A=g.inspect({length:this.length});return this.constructor.name+" "+A})},{"safe-buffer":173,util:19}],171:[function(A,e,t){"use strict";var i=A("process-nextick-args");function g(A,e){A.emit("error",e)}e.exports={destroy:function(A,e){var t=this,r=this._readableState&&this._readableState.destroyed,n=this._writableState&&this._writableState.destroyed;return r||n?(e?e(A):!A||this._writableState&&this._writableState.errorEmitted||i.nextTick(g,this,A),this):(this._readableState&&(this._readableState.destroyed=!0),this._writableState&&(this._writableState.destroyed=!0),this._destroy(A||null,function(A){!e&&A?(i.nextTick(g,t,A),t._writableState&&(t._writableState.errorEmitted=!0)):e&&e(A)}),this)},undestroy:function(){this._readableState&&(this._readableState.destroyed=!1,this._readableState.reading=!1,this._readableState.ended=!1,this._readableState.endEmitted=!1),this._writableState&&(this._writableState.destroyed=!1,this._writableState.ended=!1,this._writableState.ending=!1,this._writableState.finished=!1,this._writableState.errorEmitted=!1)}}},{"process-nextick-args":153}],172:[function(A,e,t){arguments[4][61][0].apply(t,arguments)},{dup:61,events:102}],173:[function(A,e,t){var i=A("buffer"),g=i.Buffer;function r(A,e){for(var t in A)e[t]=A[t]}function n(A,e,t){return g(A,e,t)}g.from&&g.alloc&&g.allocUnsafe&&g.allocUnsafeSlow?e.exports=i:(r(i,t),t.Buffer=n),r(g,n),n.from=function(A,e,t){if("number"==typeof A)throw new TypeError("Argument must not be a number");return g(A,e,t)},n.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError("Argument must be a number");var i=g(A);return void 0!==e?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i},n.allocUnsafe=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return g(A)},n.allocUnsafeSlow=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return i.SlowBuffer(A)}},{buffer:64}],174:[function(A,e,t){"use strict";var i=A("safe-buffer").Buffer,g=i.isEncoding||function(A){switch((A=""+A)&&A.toLowerCase()){case"hex":case"utf8":case"utf-8":case"ascii":case"binary":case"base64":case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":case"raw":return!0;default:return!1}};function r(A){var e;switch(this.encoding=function(A){var e=function(A){if(!A)return"utf8";for(var e;;)switch(A){case"utf8":case"utf-8":return"utf8";case"ucs2":case"ucs-2":case"utf16le":case"utf-16le":return"utf16le";case"latin1":case"binary":return"latin1";case"base64":case"ascii":case"hex":return A;default:if(e)return;A=(""+A).toLowerCase(),e=!0}}(A);if("string"!=typeof e&&(i.isEncoding===g||!g(A)))throw new Error("Unknown encoding: "+A);return e||A}(A),this.encoding){case"utf16le":this.text=I,this.end=o,e=4;break;case"utf8":this.fillLast=B,e=4;break;case"base64":this.text=a,this.end=Q,e=3;break;default:return this.write=C,void(this.end=s)}this.lastNeed=0,this.lastTotal=0,this.lastChar=i.allocUnsafe(e)}function n(A){return A<=127?0:A>>5==6?2:A>>4==14?3:A>>3==30?4:A>>6==2?-1:-2}function B(A){var e=this.lastTotal-this.lastNeed,t=function(A,e,t){if(128!=(192&e[0]))return A.lastNeed=0,"�";if(A.lastNeed>1&&e.length>1){if(128!=(192&e[1]))return A.lastNeed=1,"�";if(A.lastNeed>2&&e.length>2&&128!=(192&e[2]))return A.lastNeed=2,"�"}}(this,A);return void 0!==t?t:this.lastNeed<=A.length?(A.copy(this.lastChar,e,0,this.lastNeed),this.lastChar.toString(this.encoding,0,this.lastTotal)):(A.copy(this.lastChar,e,0,A.length),void(this.lastNeed-=A.length))}function I(A,e){if((A.length-e)%2==0){var t=A.toString("utf16le",e);if(t){var i=t.charCodeAt(t.length-1);if(i>=55296&&i<=56319)return this.lastNeed=2,this.lastTotal=4,this.lastChar[0]=A[A.length-2],this.lastChar[1]=A[A.length-1],t.slice(0,-1)}return t}return this.lastNeed=1,this.lastTotal=2,this.lastChar[0]=A[A.length-1],A.toString("utf16le",e,A.length-1)}function o(A){var e=A&&A.length?this.write(A):"";if(this.lastNeed){var t=this.lastTotal-this.lastNeed;return e+this.lastChar.toString("utf16le",0,t)}return e}function a(A,e){var t=(A.length-e)%3;return 0===t?A.toString("base64",e):(this.lastNeed=3-t,this.lastTotal=3,1===t?this.lastChar[0]=A[A.length-1]:(this.lastChar[0]=A[A.length-2],this.lastChar[1]=A[A.length-1]),A.toString("base64",e,A.length-t))}function Q(A){var e=A&&A.length?this.write(A):"";return this.lastNeed?e+this.lastChar.toString("base64",0,3-this.lastNeed):e}function C(A){return A.toString(this.encoding)}function s(A){return A&&A.length?this.write(A):""}t.StringDecoder=r,r.prototype.write=function(A){if(0===A.length)return"";var e,t;if(this.lastNeed){if(void 0===(e=this.fillLast(A)))return"";t=this.lastNeed,this.lastNeed=0}else t=0;return t=0)return g>0&&(A.lastNeed=g-1),g;if(--i=0)return g>0&&(A.lastNeed=g-2),g;if(--i=0)return g>0&&(2===g?g=0:A.lastNeed=g-3),g;return 0}(this,A,e);if(!this.lastNeed)return A.toString("utf8",e);this.lastTotal=t;var i=A.length-(t-this.lastNeed);return A.copy(this.lastChar,0,i),A.toString("utf8",e,i)},r.prototype.fillLast=function(A){if(this.lastNeed<=A.length)return A.copy(this.lastChar,this.lastTotal-this.lastNeed,0,this.lastNeed),this.lastChar.toString(this.encoding,0,this.lastTotal);A.copy(this.lastChar,this.lastTotal-this.lastNeed,0,A.length),this.lastNeed-=A.length}},{"safe-buffer":173}],175:[function(A,e,t){e.exports=A("./readable").PassThrough},{"./readable":176}],176:[function(A,e,t){(t=e.exports=A("./lib/_stream_readable.js")).Stream=t,t.Readable=t,t.Writable=A("./lib/_stream_writable.js"),t.Duplex=A("./lib/_stream_duplex.js"),t.Transform=A("./lib/_stream_transform.js"),t.PassThrough=A("./lib/_stream_passthrough.js")},{"./lib/_stream_duplex.js":165,"./lib/_stream_passthrough.js":166,"./lib/_stream_readable.js":167,"./lib/_stream_transform.js":168,"./lib/_stream_writable.js":169}],177:[function(A,e,t){e.exports=A("./readable").Transform},{"./readable":176}],178:[function(A,e,t){e.exports=A("./lib/_stream_writable.js")},{"./lib/_stream_writable.js":169}],179:[function(A,e,t){"use strict";var i=A("buffer").Buffer,g=A("inherits"),r=A("hash-base"),n=new Array(16),B=[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,7,4,13,1,10,6,15,3,12,0,9,5,2,14,11,8,3,10,14,4,9,15,8,1,2,7,0,6,13,11,5,12,1,9,11,10,0,8,12,4,13,3,7,15,14,5,6,2,4,0,5,9,7,12,2,10,14,1,3,8,11,6,15,13],I=[5,14,7,0,9,2,11,4,13,6,15,8,1,10,3,12,6,11,3,7,0,13,5,10,14,15,8,12,4,9,1,2,15,5,1,3,7,14,6,9,11,8,12,2,10,0,4,13,8,6,4,1,3,11,15,0,5,12,2,13,9,7,10,14,12,15,10,4,1,5,8,7,6,2,13,14,0,3,9,11],o=[11,14,15,12,5,8,7,9,11,13,14,15,6,7,9,8,7,6,8,13,11,9,7,15,7,12,15,9,11,7,13,12,11,13,6,7,14,9,13,15,14,8,13,6,5,12,7,5,11,12,14,15,14,15,9,8,9,14,5,6,8,6,5,12,9,15,5,11,6,8,13,12,5,12,13,14,11,8,5,6],a=[8,9,9,11,13,15,15,5,7,7,8,11,14,14,12,6,9,13,15,7,12,8,9,11,7,7,12,7,6,15,13,11,9,7,15,11,8,6,6,14,12,13,5,14,13,13,7,5,15,5,8,11,14,14,6,14,6,9,12,9,12,5,15,8,8,5,12,9,12,5,14,6,8,13,6,5,15,13,11,11],Q=[0,1518500249,1859775393,2400959708,2840853838],C=[1352829926,1548603684,1836072691,2053994217,0];function s(){r.call(this,64),this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878,this._e=3285377520}function c(A,e){return A<>>32-e}function h(A,e,t,i,g,r,n,B){return c(A+(e^t^i)+r+n|0,B)+g|0}function f(A,e,t,i,g,r,n,B){return c(A+(e&t|~e&i)+r+n|0,B)+g|0}function E(A,e,t,i,g,r,n,B){return c(A+((e|~t)^i)+r+n|0,B)+g|0}function u(A,e,t,i,g,r,n,B){return c(A+(e&i|t&~i)+r+n|0,B)+g|0}function d(A,e,t,i,g,r,n,B){return c(A+(e^(t|~i))+r+n|0,B)+g|0}g(s,r),s.prototype._update=function(){for(var A=n,e=0;e<16;++e)A[e]=this._block.readInt32LE(4*e);for(var t=0|this._a,i=0|this._b,g=0|this._c,r=0|this._d,s=0|this._e,l=0|this._a,w=0|this._b,p=0|this._c,D=0|this._d,b=0|this._e,y=0;y<80;y+=1){var M,m;y<16?(M=h(t,i,g,r,s,A[B[y]],Q[0],o[y]),m=d(l,w,p,D,b,A[I[y]],C[0],a[y])):y<32?(M=f(t,i,g,r,s,A[B[y]],Q[1],o[y]),m=u(l,w,p,D,b,A[I[y]],C[1],a[y])):y<48?(M=E(t,i,g,r,s,A[B[y]],Q[2],o[y]),m=E(l,w,p,D,b,A[I[y]],C[2],a[y])):y<64?(M=u(t,i,g,r,s,A[B[y]],Q[3],o[y]),m=f(l,w,p,D,b,A[I[y]],C[3],a[y])):(M=d(t,i,g,r,s,A[B[y]],Q[4],o[y]),m=h(l,w,p,D,b,A[I[y]],C[4],a[y])),t=s,s=r,r=c(g,10),g=i,i=M,l=b,b=D,D=c(p,10),p=w,w=m}var G=this._b+g+D|0;this._b=this._c+r+b|0,this._c=this._d+s+l|0,this._d=this._e+t+w|0,this._e=this._a+i+p|0,this._a=G},s.prototype._digest=function(){this._block[this._blockOffset++]=128,this._blockOffset>56&&(this._block.fill(0,this._blockOffset,64),this._update(),this._blockOffset=0),this._block.fill(0,this._blockOffset,56),this._block.writeUInt32LE(this._length[0],56),this._block.writeUInt32LE(this._length[1],60),this._update();var A=i.alloc?i.alloc(20):new i(20);return A.writeInt32LE(this._a,0),A.writeInt32LE(this._b,4),A.writeInt32LE(this._c,8),A.writeInt32LE(this._d,12),A.writeInt32LE(this._e,16),A},e.exports=s},{buffer:64,"hash-base":104,inherits:134}],180:[function(A,e,t){var i=A("buffer"),g=i.Buffer;function r(A,e){for(var t in A)e[t]=A[t]}function n(A,e,t){return g(A,e,t)}g.from&&g.alloc&&g.allocUnsafe&&g.allocUnsafeSlow?e.exports=i:(r(i,t),t.Buffer=n),n.prototype=Object.create(g.prototype),r(g,n),n.from=function(A,e,t){if("number"==typeof A)throw new TypeError("Argument must not be a number");return g(A,e,t)},n.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError("Argument must be a number");var i=g(A);return void 0!==e?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i},n.allocUnsafe=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return g(A)},n.allocUnsafeSlow=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return i.SlowBuffer(A)}},{buffer:64}],181:[function(A,e,t){(function(t){"use strict";var i,g=A("buffer"),r=g.Buffer,n={};for(i in g)g.hasOwnProperty(i)&&"SlowBuffer"!==i&&"Buffer"!==i&&(n[i]=g[i]);var B=n.Buffer={};for(i in r)r.hasOwnProperty(i)&&"allocUnsafe"!==i&&"allocUnsafeSlow"!==i&&(B[i]=r[i]);if(n.Buffer.prototype=r.prototype,B.from&&B.from!==Uint8Array.from||(B.from=function(A,e,t){if("number"==typeof A)throw new TypeError('The "value" argument must not be of type number. Received type '+typeof A);if(A&&void 0===A.length)throw new TypeError("The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type "+typeof A);return r(A,e,t)}),B.alloc||(B.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError('The "size" argument must be of type number. Received type '+typeof A);if(A<0||A>=2*(1<<30))throw new RangeError('The value "'+A+'" is invalid for option "size"');var i=r(A);return e&&0!==e.length?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i}),!n.kStringMaxLength)try{n.kStringMaxLength=t.binding("buffer").kStringMaxLength}catch(A){}n.constants||(n.constants={MAX_LENGTH:n.kMaxLength},n.kStringMaxLength&&(n.constants.MAX_STRING_LENGTH=n.kStringMaxLength)),e.exports=n}).call(this,A("_process"))},{_process:154,buffer:64}],182:[function(A,e,t){var i=A("safe-buffer").Buffer;function g(A,e){this._block=i.alloc(A),this._finalSize=e,this._blockSize=A,this._len=0}g.prototype.update=function(A,e){"string"==typeof A&&(e=e||"utf8",A=i.from(A,e));for(var t=this._block,g=this._blockSize,r=A.length,n=this._len,B=0;B=this._finalSize&&(this._update(this._block),this._block.fill(0));var t=8*this._len;if(t<=4294967295)this._block.writeUInt32BE(t,this._blockSize-4);else{var i=(4294967295&t)>>>0,g=(t-i)/4294967296;this._block.writeUInt32BE(g,this._blockSize-8),this._block.writeUInt32BE(i,this._blockSize-4)}this._update(this._block);var r=this._hash();return A?r.toString(A):r},g.prototype._update=function(){throw new Error("_update must be implemented by subclass")},e.exports=g},{"safe-buffer":180}],183:[function(A,e,t){(t=e.exports=function(A){A=A.toLowerCase();var e=t[A];if(!e)throw new Error(A+" is not supported (we accept pull requests)");return new e}).sha=A("./sha"),t.sha1=A("./sha1"),t.sha224=A("./sha224"),t.sha256=A("./sha256"),t.sha384=A("./sha384"),t.sha512=A("./sha512")},{"./sha":184,"./sha1":185,"./sha224":186,"./sha256":187,"./sha384":188,"./sha512":189}],184:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1518500249,1859775393,-1894007588,-899497514],B=new Array(80);function I(){this.init(),this._w=B,g.call(this,64,56)}function o(A){return A<<30|A>>>2}function a(A,e,t,i){return 0===A?e&t|~e&i:2===A?e&t|e&i|t&i:e^t^i}i(I,g),I.prototype.init=function(){return this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878,this._e=3285377520,this},I.prototype._update=function(A){for(var e,t=this._w,i=0|this._a,g=0|this._b,r=0|this._c,B=0|this._d,I=0|this._e,Q=0;Q<16;++Q)t[Q]=A.readInt32BE(4*Q);for(;Q<80;++Q)t[Q]=t[Q-3]^t[Q-8]^t[Q-14]^t[Q-16];for(var C=0;C<80;++C){var s=~~(C/20),c=0|((e=i)<<5|e>>>27)+a(s,g,r,B)+I+t[C]+n[s];I=B,B=r,r=o(g),g=i,i=c}this._a=i+this._a|0,this._b=g+this._b|0,this._c=r+this._c|0,this._d=B+this._d|0,this._e=I+this._e|0},I.prototype._hash=function(){var A=r.allocUnsafe(20);return A.writeInt32BE(0|this._a,0),A.writeInt32BE(0|this._b,4),A.writeInt32BE(0|this._c,8),A.writeInt32BE(0|this._d,12),A.writeInt32BE(0|this._e,16),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],185:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1518500249,1859775393,-1894007588,-899497514],B=new Array(80);function I(){this.init(),this._w=B,g.call(this,64,56)}function o(A){return A<<5|A>>>27}function a(A){return A<<30|A>>>2}function Q(A,e,t,i){return 0===A?e&t|~e&i:2===A?e&t|e&i|t&i:e^t^i}i(I,g),I.prototype.init=function(){return this._a=1732584193,this._b=4023233417,this._c=2562383102,this._d=271733878,this._e=3285377520,this},I.prototype._update=function(A){for(var e,t=this._w,i=0|this._a,g=0|this._b,r=0|this._c,B=0|this._d,I=0|this._e,C=0;C<16;++C)t[C]=A.readInt32BE(4*C);for(;C<80;++C)t[C]=(e=t[C-3]^t[C-8]^t[C-14]^t[C-16])<<1|e>>>31;for(var s=0;s<80;++s){var c=~~(s/20),h=o(i)+Q(c,g,r,B)+I+t[s]+n[c]|0;I=B,B=r,r=a(g),g=i,i=h}this._a=i+this._a|0,this._b=g+this._b|0,this._c=r+this._c|0,this._d=B+this._d|0,this._e=I+this._e|0},I.prototype._hash=function(){var A=r.allocUnsafe(20);return A.writeInt32BE(0|this._a,0),A.writeInt32BE(0|this._b,4),A.writeInt32BE(0|this._c,8),A.writeInt32BE(0|this._d,12),A.writeInt32BE(0|this._e,16),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],186:[function(A,e,t){var i=A("inherits"),g=A("./sha256"),r=A("./hash"),n=A("safe-buffer").Buffer,B=new Array(64);function I(){this.init(),this._w=B,r.call(this,64,56)}i(I,g),I.prototype.init=function(){return this._a=3238371032,this._b=914150663,this._c=812702999,this._d=4144912697,this._e=4290775857,this._f=1750603025,this._g=1694076839,this._h=3204075428,this},I.prototype._hash=function(){var A=n.allocUnsafe(28);return A.writeInt32BE(this._a,0),A.writeInt32BE(this._b,4),A.writeInt32BE(this._c,8),A.writeInt32BE(this._d,12),A.writeInt32BE(this._e,16),A.writeInt32BE(this._f,20),A.writeInt32BE(this._g,24),A},e.exports=I},{"./hash":182,"./sha256":187,inherits:134,"safe-buffer":180}],187:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1116352408,1899447441,3049323471,3921009573,961987163,1508970993,2453635748,2870763221,3624381080,310598401,607225278,1426881987,1925078388,2162078206,2614888103,3248222580,3835390401,4022224774,264347078,604807628,770255983,1249150122,1555081692,1996064986,2554220882,2821834349,2952996808,3210313671,3336571891,3584528711,113926993,338241895,666307205,773529912,1294757372,1396182291,1695183700,1986661051,2177026350,2456956037,2730485921,2820302411,3259730800,3345764771,3516065817,3600352804,4094571909,275423344,430227734,506948616,659060556,883997877,958139571,1322822218,1537002063,1747873779,1955562222,2024104815,2227730452,2361852424,2428436474,2756734187,3204031479,3329325298],B=new Array(64);function I(){this.init(),this._w=B,g.call(this,64,56)}function o(A,e,t){return t^A&(e^t)}function a(A,e,t){return A&e|t&(A|e)}function Q(A){return(A>>>2|A<<30)^(A>>>13|A<<19)^(A>>>22|A<<10)}function C(A){return(A>>>6|A<<26)^(A>>>11|A<<21)^(A>>>25|A<<7)}function s(A){return(A>>>7|A<<25)^(A>>>18|A<<14)^A>>>3}i(I,g),I.prototype.init=function(){return this._a=1779033703,this._b=3144134277,this._c=1013904242,this._d=2773480762,this._e=1359893119,this._f=2600822924,this._g=528734635,this._h=1541459225,this},I.prototype._update=function(A){for(var e,t=this._w,i=0|this._a,g=0|this._b,r=0|this._c,B=0|this._d,I=0|this._e,c=0|this._f,h=0|this._g,f=0|this._h,E=0;E<16;++E)t[E]=A.readInt32BE(4*E);for(;E<64;++E)t[E]=0|(((e=t[E-2])>>>17|e<<15)^(e>>>19|e<<13)^e>>>10)+t[E-7]+s(t[E-15])+t[E-16];for(var u=0;u<64;++u){var d=f+C(I)+o(I,c,h)+n[u]+t[u]|0,l=Q(i)+a(i,g,r)|0;f=h,h=c,c=I,I=B+d|0,B=r,r=g,g=i,i=d+l|0}this._a=i+this._a|0,this._b=g+this._b|0,this._c=r+this._c|0,this._d=B+this._d|0,this._e=I+this._e|0,this._f=c+this._f|0,this._g=h+this._g|0,this._h=f+this._h|0},I.prototype._hash=function(){var A=r.allocUnsafe(32);return A.writeInt32BE(this._a,0),A.writeInt32BE(this._b,4),A.writeInt32BE(this._c,8),A.writeInt32BE(this._d,12),A.writeInt32BE(this._e,16),A.writeInt32BE(this._f,20),A.writeInt32BE(this._g,24),A.writeInt32BE(this._h,28),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],188:[function(A,e,t){var i=A("inherits"),g=A("./sha512"),r=A("./hash"),n=A("safe-buffer").Buffer,B=new Array(160);function I(){this.init(),this._w=B,r.call(this,128,112)}i(I,g),I.prototype.init=function(){return this._ah=3418070365,this._bh=1654270250,this._ch=2438529370,this._dh=355462360,this._eh=1731405415,this._fh=2394180231,this._gh=3675008525,this._hh=1203062813,this._al=3238371032,this._bl=914150663,this._cl=812702999,this._dl=4144912697,this._el=4290775857,this._fl=1750603025,this._gl=1694076839,this._hl=3204075428,this},I.prototype._hash=function(){var A=n.allocUnsafe(48);function e(e,t,i){A.writeInt32BE(e,i),A.writeInt32BE(t,i+4)}return e(this._ah,this._al,0),e(this._bh,this._bl,8),e(this._ch,this._cl,16),e(this._dh,this._dl,24),e(this._eh,this._el,32),e(this._fh,this._fl,40),A},e.exports=I},{"./hash":182,"./sha512":189,inherits:134,"safe-buffer":180}],189:[function(A,e,t){var i=A("inherits"),g=A("./hash"),r=A("safe-buffer").Buffer,n=[1116352408,3609767458,1899447441,602891725,3049323471,3964484399,3921009573,2173295548,961987163,4081628472,1508970993,3053834265,2453635748,2937671579,2870763221,3664609560,3624381080,2734883394,310598401,1164996542,607225278,1323610764,1426881987,3590304994,1925078388,4068182383,2162078206,991336113,2614888103,633803317,3248222580,3479774868,3835390401,2666613458,4022224774,944711139,264347078,2341262773,604807628,2007800933,770255983,1495990901,1249150122,1856431235,1555081692,3175218132,1996064986,2198950837,2554220882,3999719339,2821834349,766784016,2952996808,2566594879,3210313671,3203337956,3336571891,1034457026,3584528711,2466948901,113926993,3758326383,338241895,168717936,666307205,1188179964,773529912,1546045734,1294757372,1522805485,1396182291,2643833823,1695183700,2343527390,1986661051,1014477480,2177026350,1206759142,2456956037,344077627,2730485921,1290863460,2820302411,3158454273,3259730800,3505952657,3345764771,106217008,3516065817,3606008344,3600352804,1432725776,4094571909,1467031594,275423344,851169720,430227734,3100823752,506948616,1363258195,659060556,3750685593,883997877,3785050280,958139571,3318307427,1322822218,3812723403,1537002063,2003034995,1747873779,3602036899,1955562222,1575990012,2024104815,1125592928,2227730452,2716904306,2361852424,442776044,2428436474,593698344,2756734187,3733110249,3204031479,2999351573,3329325298,3815920427,3391569614,3928383900,3515267271,566280711,3940187606,3454069534,4118630271,4000239992,116418474,1914138554,174292421,2731055270,289380356,3203993006,460393269,320620315,685471733,587496836,852142971,1086792851,1017036298,365543100,1126000580,2618297676,1288033470,3409855158,1501505948,4234509866,1607167915,987167468,1816402316,1246189591],B=new Array(160);function I(){this.init(),this._w=B,g.call(this,128,112)}function o(A,e,t){return t^A&(e^t)}function a(A,e,t){return A&e|t&(A|e)}function Q(A,e){return(A>>>28|e<<4)^(e>>>2|A<<30)^(e>>>7|A<<25)}function C(A,e){return(A>>>14|e<<18)^(A>>>18|e<<14)^(e>>>9|A<<23)}function s(A,e){return(A>>>1|e<<31)^(A>>>8|e<<24)^A>>>7}function c(A,e){return(A>>>1|e<<31)^(A>>>8|e<<24)^(A>>>7|e<<25)}function h(A,e){return(A>>>19|e<<13)^(e>>>29|A<<3)^A>>>6}function f(A,e){return(A>>>19|e<<13)^(e>>>29|A<<3)^(A>>>6|e<<26)}function E(A,e){return A>>>0>>0?1:0}i(I,g),I.prototype.init=function(){return this._ah=1779033703,this._bh=3144134277,this._ch=1013904242,this._dh=2773480762,this._eh=1359893119,this._fh=2600822924,this._gh=528734635,this._hh=1541459225,this._al=4089235720,this._bl=2227873595,this._cl=4271175723,this._dl=1595750129,this._el=2917565137,this._fl=725511199,this._gl=4215389547,this._hl=327033209,this},I.prototype._update=function(A){for(var e=this._w,t=0|this._ah,i=0|this._bh,g=0|this._ch,r=0|this._dh,B=0|this._eh,I=0|this._fh,u=0|this._gh,d=0|this._hh,l=0|this._al,w=0|this._bl,p=0|this._cl,D=0|this._dl,b=0|this._el,y=0|this._fl,M=0|this._gl,m=0|this._hl,G=0;G<32;G+=2)e[G]=A.readInt32BE(4*G),e[G+1]=A.readInt32BE(4*G+4);for(;G<160;G+=2){var k=e[G-30],F=e[G-30+1],N=s(k,F),S=c(F,k),Y=h(k=e[G-4],F=e[G-4+1]),v=f(F,k),K=e[G-14],U=e[G-14+1],J=e[G-32],H=e[G-32+1],R=S+U|0,q=N+K+E(R,S)|0;q=(q=q+Y+E(R=R+v|0,v)|0)+J+E(R=R+H|0,H)|0,e[G]=q,e[G+1]=R}for(var L=0;L<160;L+=2){q=e[L],R=e[L+1];var x=a(t,i,g),Z=a(l,w,p),j=Q(t,l),W=Q(l,t),O=C(B,b),P=C(b,B),V=n[L],X=n[L+1],z=o(B,I,u),T=o(b,y,M),_=m+P|0,$=d+O+E(_,m)|0;$=($=($=$+z+E(_=_+T|0,T)|0)+V+E(_=_+X|0,X)|0)+q+E(_=_+R|0,R)|0;var AA=W+Z|0,eA=j+x+E(AA,W)|0;d=u,m=M,u=I,M=y,I=B,y=b,B=r+$+E(b=D+_|0,D)|0,r=g,D=p,g=i,p=w,i=t,w=l,t=$+eA+E(l=_+AA|0,_)|0}this._al=this._al+l|0,this._bl=this._bl+w|0,this._cl=this._cl+p|0,this._dl=this._dl+D|0,this._el=this._el+b|0,this._fl=this._fl+y|0,this._gl=this._gl+M|0,this._hl=this._hl+m|0,this._ah=this._ah+t+E(this._al,l)|0,this._bh=this._bh+i+E(this._bl,w)|0,this._ch=this._ch+g+E(this._cl,p)|0,this._dh=this._dh+r+E(this._dl,D)|0,this._eh=this._eh+B+E(this._el,b)|0,this._fh=this._fh+I+E(this._fl,y)|0,this._gh=this._gh+u+E(this._gl,M)|0,this._hh=this._hh+d+E(this._hl,m)|0},I.prototype._hash=function(){var A=r.allocUnsafe(64);function e(e,t,i){A.writeInt32BE(e,i),A.writeInt32BE(t,i+4)}return e(this._ah,this._al,0),e(this._bh,this._bl,8),e(this._ch,this._cl,16),e(this._dh,this._dl,24),e(this._eh,this._el,32),e(this._fh,this._fl,40),e(this._gh,this._gl,48),e(this._hh,this._hl,56),A},e.exports=I},{"./hash":182,inherits:134,"safe-buffer":180}],190:[function(A,e,t){e.exports=g;var i=A("events").EventEmitter;function g(){i.call(this)}A("inherits")(g,i),g.Readable=A("readable-stream/readable.js"),g.Writable=A("readable-stream/writable.js"),g.Duplex=A("readable-stream/duplex.js"),g.Transform=A("readable-stream/transform.js"),g.PassThrough=A("readable-stream/passthrough.js"),g.Stream=g,g.prototype.pipe=function(A,e){var t=this;function g(e){A.writable&&!1===A.write(e)&&t.pause&&t.pause()}function r(){t.readable&&t.resume&&t.resume()}t.on("data",g),A.on("drain",r),A._isStdio||e&&!1===e.end||(t.on("end",B),t.on("close",I));var n=!1;function B(){n||(n=!0,A.end())}function I(){n||(n=!0,"function"==typeof A.destroy&&A.destroy())}function o(A){if(a(),0===i.listenerCount(this,"error"))throw A}function a(){t.removeListener("data",g),A.removeListener("drain",r),t.removeListener("end",B),t.removeListener("close",I),t.removeListener("error",o),A.removeListener("error",o),t.removeListener("end",a),t.removeListener("close",a),A.removeListener("close",a)}return t.on("error",o),A.on("error",o),t.on("end",a),t.on("close",a),A.on("close",a),A.emit("pipe",t),A}},{events:102,inherits:134,"readable-stream/duplex.js":164,"readable-stream/passthrough.js":175,"readable-stream/readable.js":176,"readable-stream/transform.js":177,"readable-stream/writable.js":178}],191:[function(A,e,t){arguments[4][174][0].apply(t,arguments)},{dup:174,"safe-buffer":180}],192:[function(A,e,t){(function(e,i){var g=A("process/browser.js").nextTick,r=Function.prototype.apply,n=Array.prototype.slice,B={},I=0;function o(A,e){this._id=A,this._clearFn=e}t.setTimeout=function(){return new o(r.call(setTimeout,window,arguments),clearTimeout)},t.setInterval=function(){return new o(r.call(setInterval,window,arguments),clearInterval)},t.clearTimeout=t.clearInterval=function(A){A.close()},o.prototype.unref=o.prototype.ref=function(){},o.prototype.close=function(){this._clearFn.call(window,this._id)},t.enroll=function(A,e){clearTimeout(A._idleTimeoutId),A._idleTimeout=e},t.unenroll=function(A){clearTimeout(A._idleTimeoutId),A._idleTimeout=-1},t._unrefActive=t.active=function(A){clearTimeout(A._idleTimeoutId);var e=A._idleTimeout;e>=0&&(A._idleTimeoutId=setTimeout(function(){A._onTimeout&&A._onTimeout()},e))},t.setImmediate="function"==typeof e?e:function(A){var e=I++,i=!(arguments.length<2)&&n.call(arguments,1);return B[e]=!0,g(function(){B[e]&&(i?A.apply(null,i):A.call(null),t.clearImmediate(e))}),e},t.clearImmediate="function"==typeof i?i:function(A){delete B[A]}}).call(this,A("timers").setImmediate,A("timers").clearImmediate)},{"process/browser.js":154,timers:192}],193:[function(A,e,t){(function(A){function t(e){try{if(!A.localStorage)return!1}catch(A){return!1}var t=A.localStorage[e];return null!=t&&"true"===String(t).toLowerCase()}e.exports=function(A,e){if(t("noDeprecation"))return A;var i=!1;return function(){if(!i){if(t("throwDeprecation"))throw new Error(e);t("traceDeprecation")?console.trace(e):console.warn(e),i=!0}return A.apply(this,arguments)}}}).call(this,"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{}],194:[function(A,e,t){"function"==typeof Object.create?e.exports=function(A,e){A.super_=e,A.prototype=Object.create(e.prototype,{constructor:{value:A,enumerable:!1,writable:!0,configurable:!0}})}:e.exports=function(A,e){A.super_=e;var t=function(){};t.prototype=e.prototype,A.prototype=new t,A.prototype.constructor=A}},{}],195:[function(A,e,t){e.exports=function(A){return A&&"object"==typeof A&&"function"==typeof A.copy&&"function"==typeof A.fill&&"function"==typeof A.readUInt8}},{}],196:[function(A,e,t){(function(e,i){var g=/%[sdj%]/g;t.format=function(A){if(!E(A)){for(var e=[],t=0;t=r)return A;switch(A){case"%s":return String(i[t++]);case"%d":return Number(i[t++]);case"%j":try{return JSON.stringify(i[t++])}catch(A){return"[Circular]"}default:return A}}),I=i[t];t=3&&(i.depth=arguments[2]),arguments.length>=4&&(i.colors=arguments[3]),c(e)?i.showHidden=e:e&&t._extend(i,e),u(i.showHidden)&&(i.showHidden=!1),u(i.depth)&&(i.depth=2),u(i.colors)&&(i.colors=!1),u(i.customInspect)&&(i.customInspect=!0),i.colors&&(i.stylize=I),a(i,A,i.depth)}function I(A,e){var t=B.styles[e];return t?"["+B.colors[t][0]+"m"+A+"["+B.colors[t][1]+"m":A}function o(A,e){return A}function a(A,e,i){if(A.customInspect&&e&&D(e.inspect)&&e.inspect!==t.inspect&&(!e.constructor||e.constructor.prototype!==e)){var g=e.inspect(i,A);return E(g)||(g=a(A,g,i)),g}var r=function(A,e){if(u(e))return A.stylize("undefined","undefined");if(E(e)){var t="'"+JSON.stringify(e).replace(/^"|"$/g,"").replace(/'/g,"\\'").replace(/\\"/g,'"')+"'";return A.stylize(t,"string")}if(f(e))return A.stylize(""+e,"number");if(c(e))return A.stylize(""+e,"boolean");if(h(e))return A.stylize("null","null")}(A,e);if(r)return r;var n=Object.keys(e),B=function(A){var e={};return A.forEach(function(A,t){e[A]=!0}),e}(n);if(A.showHidden&&(n=Object.getOwnPropertyNames(e)),p(e)&&(n.indexOf("message")>=0||n.indexOf("description")>=0))return Q(e);if(0===n.length){if(D(e)){var I=e.name?": "+e.name:"";return A.stylize("[Function"+I+"]","special")}if(d(e))return A.stylize(RegExp.prototype.toString.call(e),"regexp");if(w(e))return A.stylize(Date.prototype.toString.call(e),"date");if(p(e))return Q(e)}var o,l="",b=!1,y=["{","}"];(s(e)&&(b=!0,y=["[","]"]),D(e))&&(l=" [Function"+(e.name?": "+e.name:"")+"]");return d(e)&&(l=" "+RegExp.prototype.toString.call(e)),w(e)&&(l=" "+Date.prototype.toUTCString.call(e)),p(e)&&(l=" "+Q(e)),0!==n.length||b&&0!=e.length?i<0?d(e)?A.stylize(RegExp.prototype.toString.call(e),"regexp"):A.stylize("[Object]","special"):(A.seen.push(e),o=b?function(A,e,t,i,g){for(var r=[],n=0,B=e.length;n=0&&0,A+e.replace(/\u001b\[\d\d?m/g,"").length+1},0)>60)return t[0]+(""===e?"":e+"\n ")+" "+A.join(",\n ")+" "+t[1];return t[0]+e+" "+A.join(", ")+" "+t[1]}(o,l,y)):y[0]+l+y[1]}function Q(A){return"["+Error.prototype.toString.call(A)+"]"}function C(A,e,t,i,g,r){var n,B,I;if((I=Object.getOwnPropertyDescriptor(e,g)||{value:e[g]}).get?B=I.set?A.stylize("[Getter/Setter]","special"):A.stylize("[Getter]","special"):I.set&&(B=A.stylize("[Setter]","special")),m(i,g)||(n="["+g+"]"),B||(A.seen.indexOf(I.value)<0?(B=h(t)?a(A,I.value,null):a(A,I.value,t-1)).indexOf("\n")>-1&&(B=r?B.split("\n").map(function(A){return" "+A}).join("\n").substr(2):"\n"+B.split("\n").map(function(A){return" "+A}).join("\n")):B=A.stylize("[Circular]","special")),u(n)){if(r&&g.match(/^\d+$/))return B;(n=JSON.stringify(""+g)).match(/^"([a-zA-Z_][a-zA-Z_0-9]*)"$/)?(n=n.substr(1,n.length-2),n=A.stylize(n,"name")):(n=n.replace(/'/g,"\\'").replace(/\\"/g,'"').replace(/(^"|"$)/g,"'"),n=A.stylize(n,"string"))}return n+": "+B}function s(A){return Array.isArray(A)}function c(A){return"boolean"==typeof A}function h(A){return null===A}function f(A){return"number"==typeof A}function E(A){return"string"==typeof A}function u(A){return void 0===A}function d(A){return l(A)&&"[object RegExp]"===b(A)}function l(A){return"object"==typeof A&&null!==A}function w(A){return l(A)&&"[object Date]"===b(A)}function p(A){return l(A)&&("[object Error]"===b(A)||A instanceof Error)}function D(A){return"function"==typeof A}function b(A){return Object.prototype.toString.call(A)}function y(A){return A<10?"0"+A.toString(10):A.toString(10)}t.debuglog=function(A){if(u(r)&&(r=e.env.NODE_DEBUG||""),A=A.toUpperCase(),!n[A])if(new RegExp("\\b"+A+"\\b","i").test(r)){var i=e.pid;n[A]=function(){var e=t.format.apply(t,arguments);console.error("%s %d: %s",A,i,e)}}else n[A]=function(){};return n[A]},t.inspect=B,B.colors={bold:[1,22],italic:[3,23],underline:[4,24],inverse:[7,27],white:[37,39],grey:[90,39],black:[30,39],blue:[34,39],cyan:[36,39],green:[32,39],magenta:[35,39],red:[31,39],yellow:[33,39]},B.styles={special:"cyan",number:"yellow",boolean:"yellow",undefined:"grey",null:"bold",string:"green",date:"magenta",regexp:"red"},t.isArray=s,t.isBoolean=c,t.isNull=h,t.isNullOrUndefined=function(A){return null==A},t.isNumber=f,t.isString=E,t.isSymbol=function(A){return"symbol"==typeof A},t.isUndefined=u,t.isRegExp=d,t.isObject=l,t.isDate=w,t.isError=p,t.isFunction=D,t.isPrimitive=function(A){return null===A||"boolean"==typeof A||"number"==typeof A||"string"==typeof A||"symbol"==typeof A||void 0===A},t.isBuffer=A("./support/isBuffer");var M=["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"];function m(A,e){return Object.prototype.hasOwnProperty.call(A,e)}t.log=function(){var A,e;console.log("%s - %s",(A=new Date,e=[y(A.getHours()),y(A.getMinutes()),y(A.getSeconds())].join(":"),[A.getDate(),M[A.getMonth()],e].join(" ")),t.format.apply(t,arguments))},t.inherits=A("inherits"),t._extend=function(A,e){if(!e||!l(e))return A;for(var t=Object.keys(e),i=t.length;i--;)A[t[i]]=e[t[i]];return A}}).call(this,A("_process"),"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"./support/isBuffer":195,_process:154,inherits:194}],197:[function(A,e,t){e.exports=function(A,e){if(!Object.prototype.hasOwnProperty.call(A,e))throw new TypeError("attempted to use private field on non-instance");return A}},{}],198:[function(A,e,t){var i=0;e.exports=function(A){return"__private_"+i+++"_"+A}},{}],199:[function(A,e,t){e.exports=function(A,e,t){return e in A?Object.defineProperty(A,e,{value:t,enumerable:!0,configurable:!0,writable:!0}):A[e]=t,A}},{}],200:[function(A,e,t){e.exports=function(A){return A&&A.__esModule?A:{default:A}}},{}],201:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){const e=35===A.length,t=A.length-(e?2:1),i=(0,g.default)(A.subarray(0,t));return[e?A[A.length-2]===i[0]&&A[A.length-1]===i[1]:A[A.length-1]===i[0],t]};var g=i(A("./sshash"))},{"./sshash":206,"@babel/runtime/helpers/interopRequireDefault":200}],202:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e,t=99){if((0,r.isU8a)(A)||(0,r.isHex)(A))return(0,r.u8aToU8a)(A);const i=(0,r.bufferToU8a)(g.default.decode(A)),I=e=>`Decoding ${A}: ${e}`;(0,r.assert)(B.default.allowedEncodedLengths.includes(i.length),I("Invalid decoded address length"));const[o,a]=(0,n.default)(i);return(0,r.assert)(e||o,I("Invalid decoded address checksum")),i.slice(1,a)};var g=i(A("bs58")),r=A("@polkadot/util"),n=i(A("./checkChecksum")),B=i(A("./defaults"))},{"./checkChecksum":201,"./defaults":203,"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246,bs58:317}],203:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var i={allowedDecodedLengths:[1,2,4,8,32],allowedEncodedLengths:[3,4,6,10,35],allowedPrefix:A("./ss58").allowedSS58,prefix:42};t.default=i},{"./ss58":205}],204:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=B.default.prefix){const t=(0,n.default)(A);(0,r.assert)(B.default.allowedDecodedLengths.includes(t.length),`Expected a valid key to convert, with length ${B.default.allowedDecodedLengths.join(", ")}`);const i=32===t.length,o=(0,r.u8aConcat)(new Uint8Array([e]),t),a=(0,I.default)(o);return g.default.encode((0,r.u8aToBuffer)((0,r.u8aConcat)(o,a.subarray(0,i?2:1))))};var g=i(A("bs58")),r=A("@polkadot/util"),n=i(A("./decode")),B=i(A("./defaults")),I=i(A("./sshash"))},{"./decode":202,"./defaults":203,"./sshash":206,"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246,bs58:317}],205:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.allowedSS58=void 0;t.allowedSS58=[0,1,2,3,16,17,20,42,43,68,69]},{}],206:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,r.default)((0,g.u8aConcat)(n,A),512)};var g=A("@polkadot/util"),r=i(A("../blake2/asU8a"));const n=(0,g.stringToU8a)("SS58PRE")},{"../blake2/asU8a":207,"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246}],207:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=256,t=null,i=!1){const B=Math.ceil(e/8);return(0,n.isReady)()&&!i?(0,n.blake2b)((0,r.u8aToU8a)(A),(0,r.u8aToU8a)(t),B):g.default.blake2b((0,r.u8aToU8a)(A),t,B)};var g=i(A("blakejs")),r=A("@polkadot/util"),n=A("@polkadot/wasm-crypto")},{"@babel/runtime/helpers/interopRequireDefault":200,"@polkadot/util":246,"@polkadot/wasm-crypto":301,blakejs:314}],208:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=!0){return A.filter(A=>!(0,r.default)(A)&&(e||!(0,g.default)(A)))};var g=i(A("../is/null")),r=i(A("../is/undefined"))},{"../is/null":259,"../is/undefined":267,"@babel/runtime/helpers/interopRequireDefault":200}],209:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"arrayFilter",{enumerable:!0,get:function(){return g.default}});var g=i(A("./filter"))},{"./filter":208,"@babel/runtime/helpers/interopRequireDefault":200}],210:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e){if(!A)throw new Error((0,g.default)(e)?e():e)};var g=i(A("./is/function"))},{"./is/function":253,"@babel/runtime/helpers/interopRequireDefault":200}],211:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.BN_THOUSAND=t.BN_HUNDRED=t.BN_TEN=t.BN_ONE=t.BN_ZERO=void 0;var g=i(A("bn.js"));const r=new g.default(0);t.BN_ZERO=r;const n=new g.default(1);t.BN_ONE=n;const B=new g.default(10);t.BN_TEN=B;const I=new g.default(100);t.BN_HUNDRED=I;const o=new g.default(1e3);t.BN_THOUSAND=o},{"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],212:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var g=i(A("../hex/toBn")).default;t.default=g},{"../hex/toBn":242,"@babel/runtime/helpers/interopRequireDefault":200}],213:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0});var g={bnFromHex:!0,bnMax:!0,bnMin:!0,bnSqrt:!0,bnToBn:!0,bnToHex:!0,bnToU8a:!0};Object.defineProperty(t,"bnFromHex",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"bnMax",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"bnMin",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"bnSqrt",{enumerable:!0,get:function(){return o.default}}),Object.defineProperty(t,"bnToBn",{enumerable:!0,get:function(){return a.default}}),Object.defineProperty(t,"bnToHex",{enumerable:!0,get:function(){return Q.default}}),Object.defineProperty(t,"bnToU8a",{enumerable:!0,get:function(){return C.default}});var r=A("./consts");Object.keys(r).forEach(function(A){"default"!==A&&"__esModule"!==A&&(Object.prototype.hasOwnProperty.call(g,A)||Object.defineProperty(t,A,{enumerable:!0,get:function(){return r[A]}}))});var n=i(A("./fromHex")),B=i(A("./max")),I=i(A("./min")),o=i(A("./sqrt")),a=i(A("./toBn")),Q=i(A("./toHex")),C=i(A("./toU8a"))},{"./consts":211,"./fromHex":212,"./max":214,"./min":215,"./sqrt":216,"./toBn":217,"./toHex":218,"./toU8a":219,"@babel/runtime/helpers/interopRequireDefault":200}],214:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(...A){return(0,r.default)(A&&A.length>=1,"Must provide one or more BN arguments"),A.reduce((A,e)=>g.default.max(A,e),A[0])};var g=i(A("bn.js")),r=i(A("../assert"))},{"../assert":210,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],215:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(...A){return(0,r.default)(A&&A.length>=1,"Must provide one or more BN arguments"),A.reduce((A,e)=>g.default.min(A,e),A[0])};var g=i(A("bn.js")),r=i(A("../assert"))},{"../assert":210,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],216:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,r.default)(A.gten(0),"square root of negative numbers is not supported"),A.ltn(2)?A:function A(e,t){const i=e.div(t).add(t).shrn(1);return t.eq(i)||t.eq(i.subn(1))?t:A(e,i)}(A,new g.default(1))};var g=i(A("bn.js")),r=i(A("../assert"))},{"../assert":210,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],217:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){if(!A)return new g.default(0);if((0,B.default)(A))return(0,I.default)(A.toString());if((0,r.default)(A))return new g.default(A.toString());return g.default.isBN(A)?A:(0,n.default)(A)?A.toBn():new g.default(A)};var g=i(A("bn.js")),r=i(A("../is/bigInt")),n=i(A("../is/toBn")),B=i(A("../is/hex")),I=i(A("../hex/toBn"))},{"../hex/toBn":242,"../is/bigInt":247,"../is/hex":254,"../is/toBn":265,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],218:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var g=i(A("@babel/runtime/helpers/defineProperty")),r=i(A("../is/number")),n=i(A("./toU8a")),B=A("../u8a");function I(A,e){var t=Object.keys(A);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(A);e&&(i=i.filter(function(e){return Object.getOwnPropertyDescriptor(A,e).enumerable})),t.push.apply(t,i)}return t}const o="0x00";var a=function(A,e={bitLength:-1,isLe:!1,isNegative:!1},t){if(!A)return o;const i=function(A){for(var e=1;e=4,"Previous tests match anyting less than 2^30; qed"),(0,B.u8aConcat)(new Uint8Array([3+(i-4<<2)]),t.subarray(0,i))};var g=i(A("bn.js")),r=i(A("../assert")),n=A("../bn"),B=A("../u8a");const I=new g.default(2).pow(new g.default(6)).subn(1),o=new g.default(2).pow(new g.default(14)).subn(1),a=new g.default(2).pow(new g.default(30)).subn(1)},{"../assert":210,"../bn":213,"../u8a":293,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],228:[function(A,e,t){(function(e){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function({name:A,version:t},i){const n="undefined"!=typeof window?window:e;n.__polkadotjs||(n.__polkadotjs={});if((0,g.default)(A.startsWith("@polkadot"),`Invalid package descriptor ${A}`),n.__polkadotjs[A]=[...n.__polkadotjs[A]||[],{path:i||"",version:t}],1!==n.__polkadotjs[A].length){const e=function(A){const e=A.map(A=>(0,r.default)(A)?{version:A}:A),t=e.reduce((A,{version:e})=>Math.max(A,e.length),0);return e.map(({path:A,version:e})=>`\t${e.padEnd(t)}\t${A=A,!A||A.length<5?"":A}`).join("\n");var i}(n.__polkadotjs[A]);console.warn(`Multiple instances of ${A} detected, ensure that there is only one package in your dependency tree.\n${e}`)}};var g=i(A("./assert")),r=i(A("./is/string"))}).call(this,"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{"./assert":210,"./is/string":263,"@babel/runtime/helpers/interopRequireDefault":200}],229:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function A(e){if(!e)return a;if(e<1e3)return n(n({},a),{},{milliseconds:e});const t=e/1e3;if(t<60){const i=Math.floor(t);return o(n(n({},a),{},{seconds:i}),A(e-1e3*i))}const i=t/60;if(i<60){const t=Math.floor(i);return o(n(n({},a),{},{minutes:t}),A(e-60*t*1e3))}const g=i/60;if(g<24){const t=Math.floor(g);return o(n(n({},a),{},{hours:t}),A(e-t*B*1e3))}const r=Math.floor(g/24);return o(n(n({},a),{},{days:r}),A(e-r*I*1e3))};var g=i(A("@babel/runtime/helpers/defineProperty"));function r(A,e){var t=Object.keys(A);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(A);e&&(i=i.filter(function(e){return Object.getOwnPropertyDescriptor(A,e).enumerable})),t.push.apply(t,i)}return t}function n(A){for(var e=1;e(0,I.calcSi)(A,e)),Q.findSi=I.findSi,Q.getDefaults=(()=>({decimals:o,unit:a})),Q.getOptions=((A=o)=>I.SI.filter(({power:e})=>!(e<0)||A+e>=0)),Q.setDefaults=(({decimals:A,unit:e})=>{o=(0,n.default)(A)?o:A,a=(0,n.default)(e)?a:e,I.SI[I.SI_MID].text=a});var C=Q;t.default=C},{"../bn/toBn":217,"../is/boolean":249,"../is/undefined":267,"./formatDecimal":232,"./si":236,"@babel/runtime/helpers/interopRequireDefault":200}],231:[function(A,e,t){"use strict";function i(A){return A.toString().padStart(2,"0")}Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){const e=A.getFullYear().toString(),t=i(A.getMonth()+1),g=i(A.getDate()),r=i(A.getHours()),n=i(A.getMinutes()),B=i(A.getSeconds());return`${e}-${t}-${g} ${r}:${n}:${B}`}},{}],232:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){const e=A[0].startsWith("-"),t=e?A.substr(1).match(i):A.match(i);return t?`${e?"-":""}${t.join(",")}`:A};const i=new RegExp("(\\d+?)(?=(\\d{3})+(?!\\d)|$)","g")},{}],233:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e){const t=A&&A.getTime()||0,i=function A(e){if(e){if((0,r.default)(e))return A(e.toBn());if(e instanceof Date)return A(e.getTime());if(e instanceof g.default)return A(e.toNumber())}return e||0}(e);let n="0.0s";if(t&&i){const A=Math.max(Math.abs(t-i),0)/1e3;n=A<15?`${A.toFixed(1)}s`:A<60?`${0|A}s`:A<3600?`${A/60|0}m`:`${A/3600|0}h`}return n};var g=i(A("bn.js")),r=i(A("../is/toBn"))},{"../is/toBn":265,"@babel/runtime/helpers/interopRequireDefault":200,"bn.js":316}],234:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,r.default)((0,g.default)(A).toString())};var g=i(A("../bn/toBn")),r=i(A("./formatDecimal"))},{"../bn/toBn":217,"./formatDecimal":232,"@babel/runtime/helpers/interopRequireDefault":200}],235:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"formatBalance",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"formatDate",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"formatDecimal",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"formatElapsed",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"formatNumber",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"calcSi",{enumerable:!0,get:function(){return o.calcSi}}),Object.defineProperty(t,"findSi",{enumerable:!0,get:function(){return o.findSi}});var g=i(A("./formatBalance")),r=i(A("./formatDate")),n=i(A("./formatDecimal")),B=i(A("./formatElapsed")),I=i(A("./formatNumber")),o=A("./si")},{"./formatBalance":230,"./formatDate":231,"./formatDecimal":232,"./formatElapsed":233,"./formatNumber":234,"./si":236,"@babel/runtime/helpers/interopRequireDefault":200}],236:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.findSi=r,t.calcSi=function(A,e,t){if(t)return r(t);const n=i-1+Math.ceil((A.length-e)/3);return g[n]||g[n<0?0:g.length-1]},t.SI=t.SI_MID=void 0;const i=8;t.SI_MID=i;const g=[{power:-24,text:"yocto",value:"y"},{power:-21,text:"zepto",value:"z"},{power:-18,text:"atto",value:"a"},{power:-15,text:"femto",value:"f"},{power:-12,text:"pico",value:"p"},{power:-9,text:"nano",value:"n"},{power:-6,text:"micro",value:"µ"},{power:-3,text:"milli",value:"m"},{power:0,text:"Unit",value:"-"},{power:3,text:"Kilo",value:"k"},{power:6,text:"Mega",value:"M"},{power:9,text:"Giga",value:"G"},{power:12,text:"Tera",value:"T"},{power:15,text:"Peta",value:"P"},{power:18,text:"Exa",value:"E"},{power:21,text:"Zeta",value:"Z"},{power:24,text:"Yotta",value:"Y"}];function r(A){for(let e=0;en?(0,r.default)(A).slice(-1*i):`${"0".repeat(i)}${(0,r.default)(A)}`.slice(-1*i))};var g=i(A("./addPrefix")),r=i(A("./stripPrefix"))},{"./addPrefix":237,"./stripPrefix":241,"@babel/runtime/helpers/interopRequireDefault":200}],239:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return!(!A||!(0,g.default)(A,-1,!0)||"0x"!==A.substr(0,2))};var g=i(A("../is/hex"))},{"../is/hex":254,"@babel/runtime/helpers/interopRequireDefault":200}],240:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"hexAddPrefix",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"hexFixLength",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"hexHasPrefix",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"hexStripPrefix",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"hexToBn",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"hexToNumber",{enumerable:!0,get:function(){return o.default}}),Object.defineProperty(t,"hexToString",{enumerable:!0,get:function(){return a.default}}),Object.defineProperty(t,"hexToU8a",{enumerable:!0,get:function(){return Q.default}});var g=i(A("./addPrefix")),r=i(A("./fixLength")),n=i(A("./hasPrefix")),B=i(A("./stripPrefix")),I=i(A("./toBn")),o=i(A("./toNumber")),a=i(A("./toString")),Q=i(A("./toU8a"))},{"./addPrefix":237,"./fixLength":238,"./hasPrefix":239,"./stripPrefix":241,"./toBn":242,"./toNumber":243,"./toString":244,"./toU8a":245,"@babel/runtime/helpers/interopRequireDefault":200}],241:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){if(!A)return"";if((0,g.default)(A))return A.substr(2);if(r.test(A))return A;throw new Error(`Invalid hex ${A} passed to hexStripPrefix`)};var g=i(A("./hasPrefix"));const r=/^[a-fA-F0-9]+$/},{"./hasPrefix":239,"@babel/runtime/helpers/interopRequireDefault":200}],242:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e={isLe:!1,isNegative:!1}){if(!A)return new r.default(0);const t=function(A){for(var e=1;eA.startsWith(e))}catch(A){i=!1}return{debug:i?(...A)=>h("debug",t,A):f,error:(...A)=>h("error",t,A),log:(...A)=>h("log",t,A),noop:f,warn:(...A)=>h("warn",t,A)}};var g=i(A("chalk")),r=i(A("./format/formatDate")),n=i(A("./is/bn")),B=i(A("./is/buffer")),I=i(A("./is/function")),o=i(A("./is/object")),a=i(A("./is/u8a")),Q=i(A("./u8a/toHex"));const C={debug:"log",error:"error",log:"log",warn:"warn"},s={debug:g.default.gray,error:g.default.red,log:g.default.reset,warn:g.default.yellow};function c(A){return Array.isArray(A)?A.map(c):(0,n.default)(A)?A.toString():(0,B.default)(A)?`0x${A.toString("hex")}`:(0,a.default)(A)?(0,Q.default)(A):A&&(0,o.default)(A)&&A.constructor===Object?function(A){return Object.keys(A).reduce((e,t)=>(e[t]=c(A[t]),e),{})}(A):A}function h(A,e,t){if(1===t.length&&(0,I.default)(t[0])){const i=t[0]();return h(A,e,Array.isArray(i)?i:[i])}const i=e=>s[A](e);console[C[A]](i((0,r.default)(new Date)),i(e),...t.map(c))}function f(){}}).call(this,A("_process"))},{"./format/formatDate":231,"./is/bn":248,"./is/buffer":250,"./is/function":253,"./is/object":261,"./is/u8a":266,"./u8a/toHex":297,"@babel/runtime/helpers/interopRequireDefault":200,_process:154,chalk:269}],269:[function(A,e,t){"use strict";const i=A("ansi-styles"),{stdout:g,stderr:r}=A("supports-color"),{stringReplaceAll:n,stringEncaseCRLFWithFirstIndex:B}=A("./util"),{isArray:I}=Array,o=["ansi","ansi","ansi256","ansi16m"],a=Object.create(null);class Q{constructor(A){return C(A)}}const C=A=>{const e={};return((A,e={})=>{if(e.level&&!(Number.isInteger(e.level)&&e.level>=0&&e.level<=3))throw new Error("The `level` option should be an integer from 0 to 3");const t=g?g.level:0;A.level=void 0===e.level?t:e.level})(e,A),e.template=((...A)=>l(e.template,...A)),Object.setPrototypeOf(e,s.prototype),Object.setPrototypeOf(e.template,e),e.template.constructor=(()=>{throw new Error("`chalk.constructor()` is deprecated. Use `new chalk.Instance()` instead.")}),e.template.Instance=Q,e.template};function s(A){return C(A)}for(const[A,e]of Object.entries(i))a[A]={get(){const t=E(this,f(e.open,e.close,this._styler),this._isEmpty);return Object.defineProperty(this,A,{value:t}),t}};a.visible={get(){const A=E(this,this._styler,!0);return Object.defineProperty(this,"visible",{value:A}),A}};const c=["rgb","hex","keyword","hsl","hsv","hwb","ansi","ansi256"];for(const A of c)a[A]={get(){const{level:e}=this;return function(...t){const g=f(i.color[o[e]][A](...t),i.color.close,this._styler);return E(this,g,this._isEmpty)}}};for(const A of c){a["bg"+A[0].toUpperCase()+A.slice(1)]={get(){const{level:e}=this;return function(...t){const g=f(i.bgColor[o[e]][A](...t),i.bgColor.close,this._styler);return E(this,g,this._isEmpty)}}}}const h=Object.defineProperties(()=>{},{...a,level:{enumerable:!0,get(){return this._generator.level},set(A){this._generator.level=A}}}),f=(A,e,t)=>{let i,g;return void 0===t?(i=A,g=e):(i=t.openAll+A,g=e+t.closeAll),{open:A,close:e,openAll:i,closeAll:g,parent:t}},E=(A,e,t)=>{const i=(...A)=>I(A[0])&&I(A[0].raw)?u(i,l(i,...A)):u(i,1===A.length?""+A[0]:A.join(" "));return Object.setPrototypeOf(i,h),i._generator=A,i._styler=e,i._isEmpty=t,i},u=(A,e)=>{if(A.level<=0||!e)return A._isEmpty?"":e;let t=A._styler;if(void 0===t)return e;const{openAll:i,closeAll:g}=t;if(-1!==e.indexOf(""))for(;void 0!==t;)e=n(e,t.close,t.open),t=t.parent;const r=e.indexOf("\n");return-1!==r&&(e=B(e,g,i,r)),i+e+g};let d;const l=(e,...t)=>{const[i]=t;if(!I(i)||!I(i.raw))return t.join(" ");const g=t.slice(1),r=[i.raw[0]];for(let A=1;Ae?I(e):t))}else t.push(i)}return t}function a(A,e){const t={};for(const A of e)for(const e of A.styles)t[e[0]]=A.inverse?null:e.slice(1);let i=A;for(const[A,e]of Object.entries(t))if(Array.isArray(e)){if(!(A in i))throw new Error(`Unknown Chalk style: ${A}`);i=e.length>0?i[A](...e):i[A]}return i}e.exports=((A,e)=>{const t=[],r=[];let n=[];if(e.replace(i,(e,i,B,Q,C,s)=>{if(i)n.push(I(i));else if(Q){const e=n.join("");n=[],r.push(0===t.length?e:a(A,t)(e)),t.push({inverse:B,styles:function(A){g.lastIndex=0;const e=[];let t;for(;null!==(t=g.exec(A));){const A=t[1];if(t[2]){const i=o(A,t[2]);e.push([A].concat(i))}else e.push([A])}return e}(Q)})}else if(C){if(0===t.length)throw new Error("Found extraneous } in Chalk template literal");r.push(a(A,t)(n.join(""))),n=[],t.pop()}else n.push(s)}),r.push(n.join("")),t.length>0){const A=`Chalk template literal is missing ${t.length} closing bracket${1===t.length?"":"s"} (\`}\`)`;throw new Error(A)}return r.join("")})},{}],271:[function(A,e,t){"use strict";e.exports={stringReplaceAll:(A,e,t)=>{let i=A.indexOf(e);if(-1===i)return A;const g=e.length;let r=0,n="";do{n+=A.substr(r,i-r)+e+t,r=i+g,i=A.indexOf(e,r)}while(-1!==i);return n+=A.substr(r)},stringEncaseCRLFWithFirstIndex:(A,e,t,i)=>{let g=0,r="";do{const n="\r"===A[i-1];r+=A.substr(g,(n?i-1:i)-g)+e+(n?"\r\n":"\n")+t,g=i+1,i=A.indexOf("\n",g)}while(-1!==i);return r+=A.substr(g)}}},{}],272:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"numberToHex",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"numberToU8a",{enumerable:!0,get:function(){return r.default}});var g=i(A("./toHex")),r=i(A("./toU8a"))},{"./toHex":273,"./toU8a":274,"@babel/runtime/helpers/interopRequireDefault":200}],273:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=-1){if((0,n.default)(A)||(0,r.default)(A)||isNaN(A))return"0x";return(0,g.default)(A.toString(16),e,!0)};var g=i(A("../hex/fixLength")),r=i(A("../is/null")),n=i(A("../is/undefined"))},{"../hex/fixLength":238,"../is/null":259,"../is/undefined":267,"@babel/runtime/helpers/interopRequireDefault":200}],274:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=-1){if(!A||isNaN(A))return new Uint8Array;return(0,g.default)((0,r.default)(A,e))};var g=i(A("../hex/toU8a")),r=i(A("./toHex"))},{"../hex/toU8a":245,"./toHex":273,"@babel/runtime/helpers/interopRequireDefault":200}],275:[function(A,e,t){"use strict";Array.prototype.fill||(Array.prototype.fill=function(A,e=0,t){if(!this)throw new TypeError("this is null or not defined");const i=Object(this),g=i.length>>>0,r=e>>0;let n=r<0?Math.max(g+r,0):Math.min(r,g);const B=void 0===t?g:t>>0,I=B<0?Math.max(g+B,0):Math.min(B,g);for(;n{e.apply(A,t.concat((A,e)=>{A?g(A):i(e)}))})}},{}],283:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=void 0;var g=i(A("camelcase")).default;t.default=g},{"@babel/runtime/helpers/interopRequireDefault":200,camelcase:318}],284:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"stringCamelCase",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"stringLowerFirst",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"stringShorten",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"stringToHex",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"stringToU8a",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"stringUpperFirst",{enumerable:!0,get:function(){return o.default}});var g=i(A("./camelCase")),r=i(A("./lowerFirst")),n=i(A("./shorten")),B=i(A("./toHex")),I=i(A("./toU8a")),o=i(A("./upperFirst"))},{"./camelCase":283,"./lowerFirst":285,"./shorten":286,"./toHex":287,"./toU8a":288,"./upperFirst":289,"@babel/runtime/helpers/interopRequireDefault":200}],285:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return A?A.charAt(0).toLowerCase()+A.slice(1):""}},{}],286:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e=6){if(A.length<=2+2*e)return A;return`${A.substr(0,e)}…${A.slice(-e)}`}},{}],287:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return(0,g.default)((0,r.default)(A))};var g=i(A("../u8a/toHex")),r=i(A("./toU8a"))},{"../u8a/toHex":297,"./toU8a":288,"@babel/runtime/helpers/interopRequireDefault":200}],288:[function(A,e,t){"use strict";let i;Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return A?i.encode(A):new Uint8Array};try{i=new TextEncoder}catch(A){i={encode:function(A){const e=new Uint8Array(A.length);for(let t=0;ti)return A.subarray(0,i);const g=new Uint8Array(i);t?g.set(A,0):g.set(A,i-A.length);return g}},{}],293:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),Object.defineProperty(t,"u8aConcat",{enumerable:!0,get:function(){return g.default}}),Object.defineProperty(t,"u8aEq",{enumerable:!0,get:function(){return r.default}}),Object.defineProperty(t,"u8aFixLength",{enumerable:!0,get:function(){return n.default}}),Object.defineProperty(t,"u8aSorted",{enumerable:!0,get:function(){return B.default}}),Object.defineProperty(t,"u8aToBn",{enumerable:!0,get:function(){return I.default}}),Object.defineProperty(t,"u8aToBuffer",{enumerable:!0,get:function(){return o.default}}),Object.defineProperty(t,"u8aToHex",{enumerable:!0,get:function(){return a.default}}),Object.defineProperty(t,"u8aToString",{enumerable:!0,get:function(){return Q.default}}),Object.defineProperty(t,"u8aToU8a",{enumerable:!0,get:function(){return C.default}});var g=i(A("./concat")),r=i(A("./eq")),n=i(A("./fixLength")),B=i(A("./sorted")),I=i(A("./toBn")),o=i(A("./toBuffer")),a=i(A("./toHex")),Q=i(A("./toString")),C=i(A("./toU8a"))},{"./concat":290,"./eq":291,"./fixLength":292,"./sorted":294,"./toBn":295,"./toBuffer":296,"./toHex":297,"./toString":298,"./toU8a":299,"@babel/runtime/helpers/interopRequireDefault":200}],294:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){return A.sort((A,e)=>{let t=0;for(;;){if((0,g.default)(A[t])&&(0,g.default)(e[t]))return 0;if((0,g.default)(A[t]))return-1;if((0,g.default)(e[t]))return 1;const i=A[t]-e[t];if(0!==i)return i;t++}})};var g=i(A("../is/undefined"))},{"../is/undefined":267,"@babel/runtime/helpers/interopRequireDefault":200}],295:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A,e={isLe:!0,isNegative:!1}){return(0,g.default)((0,r.default)(A),e)};var g=i(A("../hex/toBn")),r=i(A("./toHex"))},{"../hex/toBn":242,"./toHex":297,"@babel/runtime/helpers/interopRequireDefault":200}],296:[function(A,e,t){(function(A){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(e){return e?A.from(e):A.from([])}}).call(this,A("buffer").Buffer)},{buffer:64}],297:[function(A,e,t){"use strict";Object.defineProperty(t,"__esModule",{value:!0}),t.default=function A(e,t=-1,g=!0){const r=g?"0x":"";if(!(null===e||void 0===e?void 0:e.length))return r;const n=Math.ceil(t/8);if(n>0&&e.length>n){const t=Math.ceil(n/2);return`${A(e.subarray(0,t),-1,g)}…${A(e.subarray(e.length-t),-1,!1)}`}const B=new Array(e.length);for(let A=0;AA+String.fromCharCode(e),"")}}}},{}],299:[function(A,e,t){"use strict";var i=A("@babel/runtime/helpers/interopRequireDefault");Object.defineProperty(t,"__esModule",{value:!0}),t.default=function(A){if(!A)return new Uint8Array;if((0,g.default)(A))return(0,B.default)(A);if((0,n.default)(A))return(0,r.default)(A)?(0,I.default)(A):(0,o.default)(A);return Array.isArray(A)?Uint8Array.from(A):A};var g=i(A("../is/buffer")),r=i(A("../is/hex")),n=i(A("../is/string")),B=i(A("../buffer/toU8a")),I=i(A("../hex/toU8a")),o=i(A("../string/toU8a"))},{"../buffer/toU8a":221,"../hex/toU8a":245,"../is/buffer":250,"../is/hex":254,"../is/string":263,"../string/toU8a":288,"@babel/runtime/helpers/interopRequireDefault":200}],300:[function(A,e,t){const{assert:i}=A("@polkadot/util");e.exports=function(A){const e=e=>(...t)=>(i(A.isReady(),"@polkadot/wasm-crypto has not been initialized"),e(...t));return{bip39Generate:e(A.ext_bip39_generate),bip39ToEntropy:e(A.ext_bip39_to_entropy),bip39ToMiniSecret:e(A.ext_bip39_to_mini_secret),bip39ToSeed:e(A.ext_bip39_to_seed),bip39Validate:e(A.ext_bip39_validate),ed25519KeypairFromSeed:e(A.ext_ed_from_seed),ed25519Sign:e(A.ext_ed_sign),ed25519Verify:e(A.ext_ed_verify),sr25519DeriveKeypairHard:e(A.ext_sr_derive_keypair_hard),sr25519DeriveKeypairSoft:e(A.ext_sr_derive_keypair_soft),sr25519DerivePublicSoft:e(A.ext_sr_derive_public_soft),sr25519KeypairFromSeed:e(A.ext_sr_from_seed),sr25519Sign:e(A.ext_sr_sign),sr25519Verify:e(A.ext_sr_verify),blake2b:e(A.ext_blake2b),keccak256:e(A.ext_keccak256),pbkdf2:e(A.ext_pbkdf2),sha512:e(A.ext_sha512),twox:e(A.ext_twox),isReady:A.isReady,waitReady:A.waitReady}}},{"@polkadot/util":246}],301:[function(A,e,t){const i=A("./wasm");e.exports=A("./exports")(i)},{"./exports":300,"./wasm":303}],302:[function(A,e,t){e.exports={name:"@polkadot/wasm-crypto",version:"1.2.1",author:"Jaco Greeff ",files:["crypto-polyfill.js","exports.js","index.d.ts","index.js","wasm.d.ts","wasm.js","wasm_asm.js","wasm_asm_stub.js","wasm_promise.js","wasm_wasm.js"],"react-native":{"./wasm_asm_stub.js":"./wasm_asm.js"},main:"index.js",types:"index.d.ts",devDependencies:{"@polkadot/dev":"^0.50.8"},peerDependencies:{"@polkadot/util":"*"}}},{}],303:[function(A,e,t){let i;const g={crypto:A("crypto")};let r=null;function n(){return null!==r&&r.buffer===i.memory.buffer||(r=new Uint8Array(i.memory.buffer)),r}let B=0;function I(A){const e=i.__wbindgen_malloc(1*A.length);return n().set(A,e/1),B=A.length,e}function o(A,e){return n().subarray(A/1,A/1+e)}let a=null;function Q(){return null===a&&(a=i.__wbindgen_global_argument_ptr()),a}let C=null;function s(){return null!==C&&C.buffer===i.memory.buffer||(C=new Uint32Array(i.memory.buffer)),C}e.exports.ext_sr_derive_keypair_hard=function(A,e){const t=I(A),g=B,r=I(e),n=B,a=Q();try{i.ext_sr_derive_keypair_hard(a,t,g,r,n);const A=s(),e=A[a/4],B=A[a/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_sr_derive_keypair_soft=function(A,e){const t=I(A),g=B,r=I(e),n=B,a=Q();try{i.ext_sr_derive_keypair_soft(a,t,g,r,n);const A=s(),e=A[a/4],B=A[a/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_sr_derive_public_soft=function(A,e){const t=I(A),g=B,r=I(e),n=B,a=Q();try{i.ext_sr_derive_public_soft(a,t,g,r,n);const A=s(),e=A[a/4],B=A[a/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_sr_from_seed=function(A){const e=I(A),t=B,g=Q();try{i.ext_sr_from_seed(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_sr_sign=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=I(t),c=B,h=Q();try{i.ext_sr_sign(h,g,r,n,a,C,c);const A=s(),e=A[h/4],t=A[h/4+1],B=o(e,t).slice();return i.__wbindgen_free(e,1*t),B}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a),i.__wbindgen_free(C,1*c)}},e.exports.ext_sr_verify=function(A,e,t){const g=I(A),r=B,n=I(e),o=B,a=I(t),Q=B;try{return 0!==i.ext_sr_verify(g,r,n,o,a,Q)}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*o),i.__wbindgen_free(a,1*Q)}},e.exports.ext_blake2b=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=Q();try{i.ext_blake2b(C,g,r,n,a,t);const A=s(),e=A[C/4],B=A[C/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a)}},e.exports.ext_keccak256=function(A){const e=I(A),t=B,g=Q();try{i.ext_keccak256(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_pbkdf2=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=Q();try{i.ext_pbkdf2(C,g,r,n,a,t);const A=s(),e=A[C/4],B=A[C/4+1],I=o(e,B).slice();return i.__wbindgen_free(e,1*B),I}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a)}},e.exports.ext_sha512=function(A){const e=I(A),t=B,g=Q();try{i.ext_sha512(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_twox=function(A,e){const t=I(A),g=B,r=Q();try{i.ext_twox(r,t,g,e);const A=s(),n=A[r/4],B=A[r/4+1],I=o(n,B).slice();return i.__wbindgen_free(n,1*B),I}finally{i.__wbindgen_free(t,1*g)}};const{u8aToString:c}=A("@polkadot/util");function h(A,e){return c(n().subarray(A,A+e))}e.exports.ext_bip39_generate=function(A){const e=Q();i.ext_bip39_generate(e,A);const t=s(),g=t[e/4],r=t[e/4+1],n=h(g,r).slice();return i.__wbindgen_free(g,1*r),n};const{stringToU8a:f}=A("@polkadot/util");let E;E="function"==typeof stringToU8aInto?function(A){let e=A.length,t=i.__wbindgen_malloc(e),g=0;for(;;){const r=n().subarray(t+g,t+e),{read:B,written:I}=stringToU8aInto(A,r);if(g+=I,0===(A=A.substring(B)).length)break;t=i.__wbindgen_realloc(t,e,2*e),e*=2}return B=g,t}:function(A){const e=f(A),t=i.__wbindgen_malloc(e.length);return n().set(e,t),B=e.length,t},e.exports.ext_bip39_to_entropy=function(A){const e=E(A),t=B,g=Q();try{i.ext_bip39_to_entropy(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_bip39_to_mini_secret=function(A,e){const t=E(A),g=B,r=E(e),n=B,I=Q();try{i.ext_bip39_to_mini_secret(I,t,g,r,n);const A=s(),e=A[I/4],B=A[I/4+1],a=o(e,B).slice();return i.__wbindgen_free(e,1*B),a}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_bip39_to_seed=function(A,e){const t=E(A),g=B,r=E(e),n=B,I=Q();try{i.ext_bip39_to_seed(I,t,g,r,n);const A=s(),e=A[I/4],B=A[I/4+1],a=o(e,B).slice();return i.__wbindgen_free(e,1*B),a}finally{i.__wbindgen_free(t,1*g),i.__wbindgen_free(r,1*n)}},e.exports.ext_bip39_validate=function(A){const e=E(A),t=B;try{return 0!==i.ext_bip39_validate(e,t)}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_ed_from_seed=function(A){const e=I(A),t=B,g=Q();try{i.ext_ed_from_seed(g,e,t);const A=s(),r=A[g/4],n=A[g/4+1],B=o(r,n).slice();return i.__wbindgen_free(r,1*n),B}finally{i.__wbindgen_free(e,1*t)}},e.exports.ext_ed_sign=function(A,e,t){const g=I(A),r=B,n=I(e),a=B,C=I(t),c=B,h=Q();try{i.ext_ed_sign(h,g,r,n,a,C,c);const A=s(),e=A[h/4],t=A[h/4+1],B=o(e,t).slice();return i.__wbindgen_free(e,1*t),B}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*a),i.__wbindgen_free(C,1*c)}},e.exports.ext_ed_verify=function(A,e,t){const g=I(A),r=B,n=I(e),o=B,a=I(t),Q=B;try{return 0!==i.ext_ed_verify(g,r,n,o,a,Q)}finally{i.__wbindgen_free(g,1*r),i.__wbindgen_free(n,1*o),i.__wbindgen_free(a,1*Q)}};const u=new Array(32);u.fill(void 0),u.push(void 0,null,!0,!1);let d=u.length;function l(A){d===u.length&&u.push(u.length+1);const e=d;return d=u[e],u[e]=A,e}function w(A){return u[A]}e.exports.__wbg_new_3a746f2619705add=function(A,e){let t=h(A,e);return l(new Function(t))},e.exports.__wbg_call_f54d3a6dadb199ca=function(A,e){return l(w(A).call(w(e)))},e.exports.__wbg_self_ac379e780a0d8b94=function(A){return l(w(A).self)},e.exports.__wbg_crypto_1e4302b85d4f64a2=function(A){return l(w(A).crypto)},e.exports.__wbg_getRandomValues_1b4ba144162a5c9e=function(A){return l(w(A).getRandomValues)},e.exports.__wbg_getRandomValues_1ef11e888e5228e9=function(A,e,t){let i=o(e,t);w(A).getRandomValues(i)},e.exports.__wbg_require_6461b1e9a0d7c34a=function(A,e){let t=h(A,e);return l(g[t])},e.exports.__wbg_randomFillSync_1b52c8482374c55b=function(A,e,t){let i=o(e,t);w(A).randomFillSync(i)},e.exports.__wbindgen_is_undefined=function(A){return void 0===w(A)?1:0},e.exports.__wbindgen_jsval_eq=function(A,e){return w(A)===w(e)?1:0},e.exports.__wbindgen_object_drop_ref=function(A){var e;(e=A)<36||(u[e]=d,d=e)},e.exports.abort=function(){throw new Error("abort")};const p=A("./wasm_promise")().catch(()=>null);e.exports.isReady=function(){return!!i},e.exports.waitReady=function(){return p.then(()=>!!i)},p.then(A=>{i=A})},{"./wasm_promise":305,"@polkadot/util":246,crypto:73}],304:[function(A,e,t){e.exports={}},{}],305:[function(A,e,t){const i=A("./package.json"),g=A("./wasm_asm_stub"),r=A("./wasm_wasm"),n=A("./wasm");e.exports=async function(){try{const{instance:A}=await WebAssembly.instantiate(r,{"./wasm":n});return A.exports}catch(A){return g&&g.ext_blake2b?g:(console.error(`ERROR: Unable to initialize ${i.name} ${i.version}`),console.error(A),null)}}},{"./package.json":302,"./wasm":303,"./wasm_asm_stub":304,"./wasm_wasm":306}],306:[function(A,e,t){(function(A){e.exports=A.from("AGFzbQEAAAABywEdYAJ/fwBgA39/fwBgAn9/AX9gAX8AYAN/f38Bf2AEf39/fwBgAX8Bf2AFf39/f38AYAABf2AHf39/f39/fwBgAX8BfmAGf39/f39/AGAEf39/fwF/YAAAYAZ/f39/f38Bf2AFf39/f38Bf2ACf34AYAJ/fwF+YAF+AX5gCH9/f39/f39/AGADf39+AGAFf35/fn8AYAN/fn4AYAh/fn5+fn5+fgBgCn9+fn5+fn5+fn4AYAJ/fgF/YAN/fn8Bf2ACfn8Bf2ACfn4BfgKvAwsGLi93YXNtGl9fd2JpbmRnZW5fb2JqZWN0X2Ryb3BfcmVmAAMGLi93YXNtF19fd2JpbmRnZW5faXNfdW5kZWZpbmVkAAYGLi93YXNtE19fd2JpbmRnZW5fanN2YWxfZXEAAgYuL3dhc20aX193YmdfbmV3XzNhNzQ2ZjI2MTk3MDVhZGQAAgYuL3dhc20bX193YmdfY2FsbF9mNTRkM2E2ZGFkYjE5OWNhAAIGLi93YXNtG19fd2JnX3NlbGZfYWMzNzllNzgwYTBkOGI5NAAGBi4vd2FzbR1fX3diZ19jcnlwdG9fMWU0MzAyYjg1ZDRmNjRhMgAGBi4vd2FzbSZfX3diZ19nZXRSYW5kb21WYWx1ZXNfMWI0YmExNDQxNjJhNWM5ZQAGBi4vd2FzbR5fX3diZ19yZXF1aXJlXzY0NjFiMWU5YTBkN2MzNGEAAgYuL3dhc20mX193YmdfZ2V0UmFuZG9tVmFsdWVzXzFlZjExZTg4OGU1MjI4ZTkAAQYuL3dhc20lX193YmdfcmFuZG9tRmlsbFN5bmNfMWI1MmM4NDgyMzc0YzU1YgABA/UF8wUQAAEBAAAAAQEAAAEBAgEHCwAOAQcHAAMOAQABAwQFAQEOAAQBBwMGBAAPAwkFBQUFAAEDAAsCAAABDQQAAAMJBAkAAAICCg8FCQMDAQMBAQABAQEHAAEAAAIFAAEBAQcGAAMABQAAAgEIBQEbAgEFAAAFAQAGAwIBAQAAAAIABRoBAQEABgABAQMCAAMCAQEIBQIFAwEBAQABAAAFAAABAAEFBQUFBQUFAAMBAAcAAwQHBQIEBQAABAgAAgAAAQIHAAAEAAUBAAABBAITAAMDAAMCAQEREQUHBwYDAQEFAQMDBQEAAgIJAwECAgYBAQMBAQIFAwYFAwAAGQAHAQAAAwUCAAEABwEAAAIABQIHAAADAxYDAwIDAgEFAwMHFAAAAwEQBQgGAQMDAAAHCQkAABgAAAsLAQEDBgMDAQEHBwcHBwAAAgADBQAABgYDAwUBAQEBAQEPAAEBAAACAgABAQAAAAwCAAABAQICAgcAAwwCAAcAAAAAAAABDQACAQAVAgABAAgDAgECBgAAAwAAAAEAAQABAAADAAIBAAMFBQEDAwEAAAMDBgQLAAUMAAsAAQAAAAEAAQQABgECAwMDBwYBAQsDDQcHBwEAAggAAQAABAIDAwAAAAAABQUDAwADAQAACAACBAwBAQECAQABAAEAAwMDBQYHAwEGAAEGAAAFBQMIBQICAAUGFwMDAwIIBQUFAAEAAQwBCgIBAAAAAAEBAAEAAAAAAQMAAAABAQIBAAYFAAQGAAEABQYICAADAAAAAAMAAwAAAAYCAAYCAQQDAAAAAAICBQICAAMAAAAGAgIDAQMGAwMDAwAAAAAAAQADEhIDABwDCAICBAIJAQMDAwICAgMCDAUGAwMAAwAODgUCBgIDAwIDAQAAAAABAgIBAgICAAYGBgEDAwAAAAEGAAwDAg0CBAIAAgABAgICAQICAAEGAwMCAgACAgICAgACBAIGAAAACAgIAwIDDQMDAw0CBgIGCgoICgoKCgIDAAQHAXABwgHCAQUDAQATBgkBfwFBgIDAAAsH6AMYBm1lbW9yeQIAHl9fd2JpbmRnZW5fZ2xvYmFsX2FyZ3VtZW50X3B0cgD2BRpleHRfc3JfZGVyaXZlX2tleXBhaXJfaGFyZADJAhpleHRfc3JfZGVyaXZlX2tleXBhaXJfc29mdADKAhlleHRfc3JfZGVyaXZlX3B1YmxpY19zb2Z0AMsCEGV4dF9zcl9mcm9tX3NlZWQA3AILZXh0X3NyX3NpZ24AuAINZXh0X3NyX3ZlcmlmeQCcBQtleHRfYmxha2UyYgC/Ag1leHRfa2VjY2FrMjU2AN0CCmV4dF9wYmtkZjIAwAIKZXh0X3NoYTUxMgDeAghleHRfdHdveADTAhJleHRfYmlwMzlfZ2VuZXJhdGUA7AIUZXh0X2JpcDM5X3RvX2VudHJvcHkA3wIYZXh0X2JpcDM5X3RvX21pbmlfc2VjcmV0AMwCEWV4dF9iaXAzOV90b19zZWVkAM0CEmV4dF9iaXAzOV92YWxpZGF0ZQDgBRBleHRfZWRfZnJvbV9zZWVkAOACC2V4dF9lZF9zaWduALkCDWV4dF9lZF92ZXJpZnkAnQURX193YmluZGdlbl9tYWxsb2MAggQSX193YmluZGdlbl9yZWFsbG9jANwED19fd2JpbmRnZW5fZnJlZQCZBQmDAwEAQQELwQH8BXj8BeED/AXiA60F+gHWAfwF4wP8BdcD/AXkA/wFpQLyBfMF/AX8BYEC8AXxBfwFxwX8BcUF/AXKBfwFkgTnApEElQKSBJIE/AWWA/cE/AX0BZIE/AXKBfwFkgT8BcsF/AWoBeMF8QX1BWS+AfwFlgHOBPwFkwLNBLEDNs4FzwX8BfwFkgT8BZcD+gT8BfQFwwX8BfIE8gT8BdMF0wX8BasFqwXsBeUFmAHtBeYF7gXVBe4F1QXcAecF/AWaBJIE/AWaA/sE/AX0Ba0FkAX8BdYF/AX8BdgF/AWPBdAD4wX3BfEF0AXXBaEC2QWRBe4F2gWSBPwFmwP9BPwF9AX8BdEC1ATSBNsFhQXpBaYE6AX6Ar8BwwPfBfwF/AXGAZIE/QX8BcMBQfUCkQT4BYcF9gSUA4YF3wPcBfUE4wX6BfEFmwWvBbAF3QSFAagB+QWkA4IF9AXwAvwFwwHBBfYCiQWxBaMCUPsFoQX8BfgFRpUB/ALEBd4F9wKYAgr46grzBZouAgZ/Kn4gAEGQAWoiAiAAKQM4IiMgACkDMCIkIABBuAFqIgMpAwAiKyAAQZgBaiIEKQMAIi98fCIffCAfQvnC+JuRo7Pw2wCFQiCJIh9C8e30+KWn/aelf3wiJSArhUIoiSIcfCImIB+FQjCJIg0gJXwiGyAchUIBiSIdIAApA2AiHyAAKQMoIiUgACkDICIcIABBsAFqIgUpAwAiLCACKQMAIip8fCIofCABICiFQuv6htq/tfbBH4VCIIkiJ0Kr8NP0r+68tzx8IiAgLIVCKIkiHnwiCnx8IiEgACkDaCIBfCAdICEgACkDGCIoIAApAxAiKSAAQagBaiICKQMAIi0gAEGIAWoiBikDACIwfHwiInwgIkKf2PnZwpHagpt/hUIgiSIiQrvOqqbY0Ouzu398Ig4gLYVCKIkiCHwiDyAihUIwiSIJhUIgiSITIAApAwgiISAAKQMAIiIgAEGgAWoiBykDACIuIAApA4ABIjF8fCIMfCAAKQPAASAMhULRhZrv+s+Uh9EAhUIgiSIMQoiS853/zPmE6gB8IgsgLoVCKIkiEXwiFCAMhUIwiSIMIAt8Igt8IhWFQiiJIhB8IhIgACkDSCIdfCAeIAogJ4VCMIkiCiAgfCIWhUIBiSIeIAApA1AiJyAPfHwiDyAAKQNYIiB8IB4gGyAMIA+FQiCJIg98IhuFQiiJIh58IgwgD4VCMIkiDyAbfCIXIB6FQgGJIhh8IhkgACkDeCIbfCAYIBkgGyALIBGFQgGJIgsgJiAAKQNwIh58fCImfCAKICaFQiCJIiYgCSAOfCIKfCIOIAuFQiiJIgl8IgsgJoVCMIkiEYVCIIkiGSAIIAqFQgGJIgogACkDQCImIBR8fCIIIB18IAogCCANhUIgiSINIBZ8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIWhUIoiSIYfCIaICB8IBIgE4VCMIkiEyAVfCIVIBCFQgGJIhAgASALfHwiCyAkfCALIA2FQiCJIg0gF3wiCyAQhUIoiSIQfCISIA2FQjCJIg0gC3wiCyAQhUIBiSIQfCIXICN8IBAgFyAIIAqFQgGJIgogDCAcfHwiCCAmfCAKIAggE4VCIIkiCCAOIBF8Ig58IhOFQiiJIgp8IgwgCIVCMIkiCIVCIIkiESAJIA6FQgGJIg4gFCAefHwiCSAnfCAOIAkgD4VCIIkiDyAVfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiFYVCKIkiEHwiFyAlfCAYIBYgGSAahUIwiSIZfCIWhUIBiSIYIAwgInx8IgwgKXwgDCAPhUIgiSIPIAt8IgwgGIVCKIkiC3wiGCAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiApfCALIBogCSAOhUIBiSIOIBIgJXx8IgkgKHwgDiAJIBmFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhkgCCAKhUIBiSIKIBQgIXx8IgggH3wgCiAIIA2FQiCJIg0gFnwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhaFQiiJIgt8IhogI3wgECARIBeFQjCJIhEgFXwiFYVCAYkiECASIBt8fCISIAF8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhcgIXwgECAXIAggCoVCAYkiCiAYIB98fCIIICJ8IAogCCARhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIXIAkgDoVCAYkiDiAUICB8fCIJICZ8IA4gCSAPhUIgiSIPIBV8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIVhUIoiSIQfCIYIAF8IAsgFiAZIBqFQjCJIhZ8IhmFQgGJIgsgESAofHwiESAkfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaIB98IAsgGiAJIA6FQgGJIg4gEiAdfHwiCSAcfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAnfHwiCCAefCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAcfCAQIBUgFyAYhUIwiSIVfCIXhUIBiSIQIBIgIHx8IhIgHnwgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCAifCAQIBggCCAKhUIBiSIKIBEgKHx8IgggIXwgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgI3x8IgkgHXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggKXwgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARICV8fCIRICd8IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogHHwgCyAaIAkgDoVCAYkiDiASIBt8fCIJICZ8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUICl8fCIIICR8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaICR8IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAnfHwiEiAbfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYICZ8IBAgGCAIIAqFQgGJIgogESAlfHwiCCAjfCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gFCAdfHwiCSAifCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAifCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgIHx8IhEgH3wgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAgfCALIBogCSAOhUIBiSIOIBIgKHx8IgkgAXwgDiAJIBaFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhYgCCAKhUIBiSIKIBQgHnx8IgggIXwgCiAIIA2FQiCJIg0gGXwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhmFQiiJIgt8IhogG3wgECAVIBiFQjCJIhUgF3wiF4VCAYkiECASICZ8fCISICh8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhggHnwgECAYIAggCoVCAYkiCiARICR8fCIIICd8IAogCCAVhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIVIAkgDoVCAYkiDiAUICl8fCIJIB98IA4gCSAPhUIgiSIPIBd8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIXhUIoiSIQfCIYIB58IAsgFiAahUIwiSIWIBl8IhmFQgGJIgsgESAjfHwiESAlfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaIAF8IAsgGiAJIA6FQgGJIg4gEiAhfHwiCSAdfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAcfHwiCCABfCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAdfCAQIBUgGIVCMIkiFSAXfCIXhUIBiSIQIBIgHHx8IhIgJ3wgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCApfCAQIBggCCAKhUIBiSIKIBEgIXx8IgggG3wgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgH3x8IgkgJXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggH3wgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARICR8fCIRICh8IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogIXwgCyAaIAkgDoVCAYkiDiASICZ8fCIJICB8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUICJ8fCIIICN8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaICZ8IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAofHwiEiAdfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYICR8IBAgGCAIIAqFQgGJIgogESAjfHwiCCAefCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gASAUfHwiCSAgfCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAgfCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgG3x8IhEgHHwgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAofCALIBogCSAOhUIBiSIOIBIgKXx8IgkgJ3wgDiAJIBaFQiCJIgkgCCATfCIIfCIThUIoiSIOfCISIAmFQjCJIgmFQiCJIhYgCCAKhUIBiSIKIBQgJXx8IgggInwgCiAIIA2FQiCJIg0gGXwiCIVCKIkiCnwiFCANhUIwiSINIAh8Igh8IhmFQiiJIgt8IhogIXwgECAVIBiFQjCJIhUgF3wiF4VCAYkiECASICJ8fCISICZ8IA0gEoVCIIkiDSAMfCIMIBCFQiiJIhB8IhIgDYVCMIkiDSAMfCIMIBCFQgGJIhB8IhggHHwgECAYIAggCoVCAYkiCiARIB58fCIIIB18IAogCCAVhUIgiSIIIAkgE3wiCXwiE4VCKIkiCnwiESAIhUIwiSIIhUIgiSIVIAkgDoVCAYkiDiAUICR8fCIJIBt8IA4gCSAPhUIgiSIPIBd8IgmFQiiJIg58IhQgD4VCMIkiDyAJfCIJfCIXhUIoiSIQfCIYICN8IAsgFiAahUIwiSIWIBl8IhmFQgGJIgsgASARfHwiESAjfCAPIBGFQiCJIg8gDHwiDCALhUIoiSILfCIRIA+FQjCJIg8gDHwiDCALhUIBiSILfCIaICR8IAsgGiAJIA6FQgGJIg4gEiAnfHwiCSAlfCAOIAkgFoVCIIkiCSAIIBN8Igh8IhOFQiiJIg58IhIgCYVCMIkiCYVCIIkiFiAIIAqFQgGJIgogFCAffHwiCCApfCAKIAggDYVCIIkiDSAZfCIIhUIoiSIKfCIUIA2FQjCJIg0gCHwiCHwiGYVCKIkiC3wiGiAofCAQIBUgGIVCMIkiFSAXfCIXhUIBiSIQIBIgIXx8IhIgJXwgDSAShUIgiSINIAx8IgwgEIVCKIkiEHwiEiANhUIwiSINIAx8IgwgEIVCAYkiEHwiGCAffCAQIBggCCAKhUIBiSIKIBEgJnx8IgggHHwgCiAIIBWFQiCJIgggCSATfCIJfCIThUIoiSIKfCIRIAiFQjCJIgiFQiCJIhUgCSAOhUIBiSIOIBQgJ3x8IgkgKXwgDiAJIA+FQiCJIg8gF3wiCYVCKIkiDnwiFCAPhUIwiSIPIAl8Igl8IheFQiiJIhB8IhggHHwgCyAWIBqFQjCJIhYgGXwiGYVCAYkiCyARIB18fCIRIB58IA8gEYVCIIkiDyAMfCIMIAuFQiiJIgt8IhEgD4VCMIkiDyAMfCIMIAuFQgGJIgt8IhogJXwgCyAaIAkgDoVCAYkiDiABIBJ8fCIJICJ8IA4gCSAWhUIgiSIJIAggE3wiCHwiE4VCKIkiDnwiEiAJhUIwiSIJhUIgiSIWIAggCoVCAYkiCiAUIBt8fCIIICB8IAogCCANhUIgiSINIBl8IgiFQiiJIgp8IhQgDYVCMIkiDSAIfCIIfCIZhUIoiSILfCIaIB98IBAgFSAYhUIwiSIVIBd8IheFQgGJIhAgEiAkfHwiEiAjfCANIBKFQiCJIg0gDHwiDCAQhUIoiSIQfCISIA2FQjCJIg0gDHwiDCAQhUIBiSIQfCIYIAF8IBAgGCAIIAqFQgGJIgogESApfHwiCCAofCAKIAggFYVCIIkiCCAJIBN8Igl8IhOFQiiJIgp8IhEgCIVCMIkiCIVCIIkiFSAJIA6FQgGJIg4gFCAifHwiCSAhfCAOIAkgD4VCIIkiDyAXfCIJhUIoiSIOfCIUIA+FQjCJIg8gCXwiCXwiF4VCKIkiEHwiGCAdfCALIBYgGoVCMIkiFiAZfCIZhUIBiSILIBEgJ3x8IhEgIHwgDyARhUIgiSIPIAx8IgwgC4VCKIkiC3wiESAPhUIwiSIPIAx8IgwgC4VCAYkiC3wiGiAbfCALIBogGyAJIA6FQgGJIg4gEiAefHwiCXwgDiAJIBaFQiCJIhsgCCATfCIIfCIJhUIoiSIOfCITIBuFQjCJIhuFQiCJIhIgHSAIIAqFQgGJIgogFCAmfHwiCHwgCiAIIA2FQiCJIh0gGXwiDYVCKIkiCnwiCCAdhUIwiSIdIA18Ig18IhSFQiiJIgt8IhYgIHwgJCAQIBUgGIVCMIkiICAXfCIVhUIBiSIQIAEgE3x8IgF8IAEgHYVCIIkiASAMfCIkIBCFQiiJIh18IhMgAYVCMIkiASAkfCIkIB2FQgGJIh18IgwgI3wgHSAMIAogDYVCAYkiIyARIBx8fCIcICZ8ICMgHCAghUIgiSIcIAkgG3wiIHwiG4VCKIkiI3wiJiAchUIwiSIchUIgiSINICcgDiAghUIBiSIgIAggHnx8Ih58ICAgDyAehUIgiSInIBV8Ih6FQiiJIiB8IgogJ4VCMIkiJyAefCIefCIOhUIoiSIdfCIIICqFIB8gIyAbIBx8IhyFQgGJIiMgCiAhfHwiIXwgIyABICGFQiCJIgEgEiAWhUIwiSIfIBR8IiF8IhuFQiiJIiN8IiogAYVCMIkiASAbfCIbhTcDACAEICkgCyAhhUIBiSIhICIgJnx8IiJ8ICEgJCAiICeFQiCJIil8IiSFQiiJIiF8IiIgKYVCMIkiKSAkfCIkIC8gKCAeICCFQgGJIicgEyAlfHwiJXwgHCAfICWFQiCJIh98IiUgJ4VCKIkiHHwiKIWFNwMAIAYgJSAfICiFQjCJIh98IiUgIiAwhYU3AwAgACAIIA2FQjCJIiggDnwiIiAqIDGFhTcDgAEgAiAoIC2FIBsgI4VCAYmFNwMAIAMgASArhSAdICKFQgGJhTcDACAFIB8gLIUgISAkhUIBiYU3AwAgByApIC6FIBwgJYVCAYmFNwMAC6g+Ah5/AX4jAEGQAWsiBSQAIAUgAUHAABDyAyEBQQAhBQNAIAVBwABHBEAgASAFaiIGIAYoAgAiBkEYdCAGQQh0QYCA/AdxciAGQQh2QYD+A3EgBkEYdnJyNgIAIAVBBGohBQwBCwsgACgCACEFIAAoAgQhBiAAKAIQIQsgACgCFCEMIAApAgghICABKAIMIRIgASgCCCETIAEoAgQhFCABKAIAIQ0gASAAKQIYNwNoIAEgIDcDYCABIAw2AnwgASALNgJ4IAEgBjYCdCABIAU2AnAgASANQZjfqJQEaiIPNgKMASABIBRBkYndiQdqIhA2AogBIAEgE0HP94Oue2oiETYChAEgASASQaW3181+aiIYNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIRUgASgCVCEWIAEoAlghFyABKAJcIRkgASAMNgJsIAEgCzYCaCABIAY2AmQgASAFNgJgIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIBE2AowBIAEgGDYCiAEgASAPNgKEASABIBA2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhBSABKAJUIQYgASgCWCELIAEoAlwhDCABKAIcIQ8gASgCGCEQIAEoAhQhESABKAIQIRggASAZNgJsIAEgFzYCaCABIBY2AmQgASAVNgJgIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIBhB24TbygNqIhU2AowBIAEgEUHxo8TPBWoiFjYCiAEgASAQQaSF/pF5aiIXNgKEASABIA9B1b3x2HpqIhk2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhGiABKAJUIQIgASgCWCEDIAEoAlwhBCABIAw2AmwgASALNgJoIAEgBjYCZCABIAU2AmAgASAENgJ8IAEgAzYCeCABIAI2AnQgASAaNgJwIAEgFzYCjAEgASAZNgKIASABIBU2AoQBIAEgFjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEFIAEoAlQhBiABKAJYIQsgASgCXCEMIAEoAiwhFSABKAIoIRYgASgCJCEXIAEoAiAhGSABIAQ2AmwgASADNgJoIAEgAjYCZCABIBo2AmAgASAMNgJ8IAEgCzYCeCABIAY2AnQgASAFNgJwIAEgGUGY1Z7AfWoiBzYCjAEgASAXQYG2jZQBaiIINgKIASABIBZBvovGoQJqIgk2AoQBIAEgFUHD+7GoBWoiCjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEaIAEoAlQhAiABKAJYIQMgASgCXCEEIAEgDDYCbCABIAs2AmggASAGNgJkIAEgBTYCYCABIAQ2AnwgASADNgJ4IAEgAjYCdCABIBo2AnAgASAJNgKMASABIAo2AogBIAEgBzYChAEgASAINgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQcgASgCVCEIIAEoAlghCSABKAJcIQogASgCPCEFIAEoAjghBiABKAI0IQsgASgCMCEMIAEgBDYCbCABIAM2AmggASACNgJkIAEgGjYCYCABIAo2AnwgASAJNgJ4IAEgCDYCdCABIAc2AnAgASAMQfS6+ZUHaiIONgKMASABIAtB/uP6hnhqIh02AogBIAEgBkGnjfDeeWoiGzYChAEgASAFQfTi74x8aiIcNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIRogASgCVCECIAEoAlghAyABKAJcIQQgASAKNgJsIAEgCTYCaCABIAg2AmQgASAHNgJgIAEgBDYCfCABIAM2AnggASACNgJ0IAEgGjYCcCABIBs2AowBIAEgHDYCiAEgASAONgKEASABIB02AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhByABKAJUIQggASgCWCEJIAEoAlwhCiABIA02AnwgASAUNgJ4IAEgEzYCdCABIBI2AnAgASAYNgKMASABIBE2AogBIAEgEDYChAEgASAPNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIBcgASgCbGo2AlwgASAWIAEoAmhqNgJYIAEgFSABKAJkajYCVCABIAwgASgCYGo2AlAgASAMNgKMASABIAs2AogBIAEgBjYChAEgASAFNgKAASABQUBrIAFB0ABqIAFBgAFqEPQBIAEgBDYCbCABIAM2AmggASACNgJkIAEgGjYCYCABIAo2AnwgASAJNgJ4IAEgCDYCdCABIAc2AnAgASABKAJMIhpBwdPtpH5qIgI2AowBIAEgASgCSEGGj/n9fmoiAzYCiAEgASABKAJEQca7hv4AaiIENgKEASABIAEoAkBBzMOyoAJqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhEiABKAJUIRMgASgCWCEUIAEoAlwhDSABIAo2AmwgASAJNgJoIAEgCDYCZCABIAc2AmAgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIAEgBDYCjAEgASAONgKIASABIAI2AoQBIAEgAzYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGDYCfCABIBE2AnggASAQNgJ0IAEgDzYCcCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgCyABKAJsajYCXCABIAYgASgCaGo2AlggASAFIAEoAmRqNgJUIAEgGiABKAJgajYCUCABQYgBaiIaIAEpA0g3AwAgASABKQNANwOAASABQfAAaiABQdAAaiABQYABahD0ASABKAJwIQ8gASgCdCEQIAEoAnghESABKAJ8IRggASANNgJsIAEgFDYCaCABIBM2AmQgASASNgJgIAEgBzYCfCABIAQ2AnggASADNgJ0IAEgAjYCcCABIBhB79ik7wJqIgg2AowBIAEgEUGqidLTBGoiCTYCiAEgASAQQdzTwuUFaiIKNgKEASABIA9B2pHmtwdqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhEiABKAJUIRMgASgCWCEUIAEoAlwhDSABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIAEgCjYCjAEgASAONgKIASABIAg2AoQBIAEgCTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgASgCbCABKAJIajYCXCABIAEoAmggASgCRGo2AlggASABKAJkIAEoAkBqNgJUIAEgGCABKAJgajYCUCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhFSABKAJ0IRYgASgCeCEXIAEoAnwhGSABIA02AmwgASAUNgJoIAEgEzYCZCABIBI2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgGUHSovnBeWoiCDYCjAEgASAXQe2Mx8F6aiIJNgKIASABIBZByM+MgHtqIgo2AoQBIAEgFUHH/+X6e2oiDjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCESIAEoAlQhEyABKAJYIRQgASgCXCENIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA02AnwgASAUNgJ4IAEgEzYCdCABIBI2AnAgASAKNgKMASABIA42AogBIAEgCDYChAEgASAJNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASAMNgJ8IAEgCzYCeCABIAY2AnQgASAFNgJwIBogASkDSDcDACABIAEpA0A3A4ABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgESABKAJsajYCXCABIBAgASgCaGo2AlggASAPIAEoAmRqNgJUIAEgGSABKAJgajYCUCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhBSABKAJ0IQYgASgCeCELIAEoAnwhDCABIA02AmwgASAUNgJoIAEgEzYCZCABIBI2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDEHzl4C3fGoiEjYCjAEgASALQceinq19aiITNgKIASABIAZB0capNmoiFDYChAEgASAFQefSpKEBaiINNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQggASgCVCEJIAEoAlghCiABKAJcIQ4gASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgDjYCfCABIAo2AnggASAJNgJ0IAEgCDYCcCABIBQ2AowBIAEgDTYCiAEgASASNgKEASABIBM2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhAiABKAJUIQMgASgCWCEEIAEoAlwhByABQfgAaiIdIAEpA0g3AwAgASABKQNANwNwIAEgGDYCjAEgASARNgKIASABIBA2AoQBIAEgDzYCgAEgAUHgAGogAUHwAGogAUGAAWoQ/AEgASAXIAEoAmxqNgJcIAEgFiABKAJoajYCWCABIBUgASgCZGo2AlQgASAMIAEoAmBqNgJQIAEgDDYCjAEgASALNgKIASABIAY2AoQBIAEgBTYCgAEgAUHwAGogAUHQAGogAUGAAWoQ9AEgASgCcCESIAEoAnQhEyABKAJ4IRQgASgCfCENIAEgDjYCbCABIAo2AmggASAJNgJkIAEgCDYCYCABIAc2AnwgASAENgJ4IAEgAzYCdCABIAI2AnAgASANQYWV3L0CaiIbNgKMASABIBRBuMLs8AJqIhw2AogBIAEgE0H827HpBGoiHjYChAEgASASQZOa4JkFaiIfNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQggASgCVCEJIAEoAlghCiABKAJcIQ4gASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgDjYCfCABIAo2AnggASAJNgJ0IAEgCDYCcCABIB42AowBIAEgHzYCiAEgASAbNgKEASABIBw2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhAiABKAJUIQMgASgCWCEEIAEoAlwhByABIBg2AnwgASARNgJ4IAEgEDYCdCABIA82AnAgASAZNgKMASABIBc2AogBIAEgFjYChAEgASAVNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIAsgASgCbGo2AlwgASAGIAEoAmhqNgJYIAEgBSABKAJkajYCVCABIA0gASgCYGo2AlAgASANNgKMASABIBQ2AogBIAEgEzYChAEgASASNgKAASABQUBrIAFB0ABqIAFBgAFqEPQBIAEgDjYCbCABIAo2AmggASAJNgJkIAEgCDYCYCABIAc2AnwgASAENgJ4IAEgAzYCdCABIAI2AnAgASABKAJMIg9B1OapqAZqIhA2AowBIAEgASgCSCIbQbuVqLMHaiIRNgKIASABIAEoAkQiHEGukouOeGoiGDYChAEgASABKAJAIh5BhdnIk3lqIh82AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhCCABKAJUIQkgASgCWCEKIAEoAlwhDiABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASAONgJ8IAEgCjYCeCABIAk2AnQgASAINgJwIAEgGDYCjAEgASAfNgKIASABIBA2AoQBIAEgETYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgGTYCfCABIBc2AnggASAWNgJ0IAEgFTYCcCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgFCABKAJsajYCXCABIBMgASgCaGo2AlggASASIAEoAmRqNgJUIAEgDyABKAJgajYCUCAaIAEpA0g3AwAgASABKQNANwOAASABQfAAaiABQdAAaiABQYABahD0ASABKAJwIQ8gASgCdCEQIAEoAnghESABKAJ8IRggASAONgJsIAEgCjYCaCABIAk2AmQgASAINgJgIAEgBzYCfCABIAQ2AnggASADNgJ0IAEgAjYCcCABIBhBodH/lXpqIgg2AowBIAEgEUHLzOnAemoiCTYCiAEgASAQQfCWrpJ8aiIKNgKEASABIA9Bo6Oxu3xqIg42AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhFSABKAJUIRYgASgCWCEXIAEoAlwhGSABIAc2AmwgASAENgJoIAEgAzYCZCABIAI2AmAgASAZNgJ8IAEgFzYCeCABIBY2AnQgASAVNgJwIAEgCjYCjAEgASAONgKIASABIAg2AoQBIAEgCTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCECIAEoAlQhAyABKAJYIQQgASgCXCEHIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIA02AowBIAEgFDYCiAEgASATNgKEASABIBI2AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgGyABKAJsajYCXCABIBwgASgCaGo2AlggASAeIAEoAmRqNgJUIAEgGCABKAJgajYCUCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhBSABKAJ0IQYgASgCeCELIAEoAnwhDCABIBk2AmwgASAXNgJoIAEgFjYCZCABIBU2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDEGZ0MuMfWoiFTYCjAEgASALQaSM5LR9aiIWNgKIASABIAZBheu4oH9qIhc2AoQBIAEgBUHwwKqDAWoiGTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAXNgKMASABIBk2AogBIAEgFTYChAEgASAWNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASANNgJ8IAEgFDYCeCABIBM2AnQgASASNgJwIBogASkDSDcDACABIAEpA0A3A4ABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgESABKAJsajYCXCABIBAgASgCaGo2AlggASAPIAEoAmRqNgJUIAEgDCABKAJgajYCUCABIAw2AowBIAEgCzYCiAEgASAGNgKEASABIAU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhFSABKAJ0IRYgASgCeCEXIAEoAnwhGSABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgGUGWgpPNAWoiEjYCjAEgASAXQYjY3fEBaiITNgKIASABIBZBzO6hugJqIhQ2AoQBIAEgFUG1+cKlA2oiDTYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAUNgKMASABIA02AogBIAEgEjYChAEgASATNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgHSABKQNINwMAIAEgASkDQDcDcCABIBg2AowBIAEgETYCiAEgASAQNgKEASABIA82AoABIAFB4ABqIAFB8ABqIAFBgAFqEPwBIAEgCyABKAJsajYCXCABIAYgASgCaGo2AlggASAFIAEoAmRqNgJUIAEgGSABKAJgajYCUCABIBk2AowBIAEgFzYCiAEgASAWNgKEASABIBU2AoABIAFB8ABqIAFB0ABqIAFBgAFqEPQBIAEoAnAhEiABKAJ0IRMgASgCeCEUIAEoAnwhDSABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgDUGzmfDIA2oiHTYCjAEgASAUQcrU4vYEaiIbNgKIASABIBNBz5Tz3AVqIhw2AoQBIAEgEkHz37nBBmoiHjYCgAEgAUHQAGogAUHgAGogAUHwAGogAUGAAWoQnAEgASgCUCEIIAEoAlQhCSABKAJYIQogASgCXCEOIAEgBzYCbCABIAQ2AmggASADNgJkIAEgAjYCYCABIA42AnwgASAKNgJ4IAEgCTYCdCABIAg2AnAgASAcNgKMASABIB42AogBIAEgHTYChAEgASAbNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQIgASgCVCEDIAEoAlghBCABKAJcIQcgASAYNgJ8IAEgETYCeCABIBA2AnQgASAPNgJwIAEgDDYCjAEgASALNgKIASABIAY2AoQBIAEgBTYCgAEgAUHgAGogAUHwAGogAUGAAWoQ/AEgASAXIAEoAmxqNgJcIAEgFiABKAJoajYCWCABIBUgASgCZGo2AlQgASANIAEoAmBqNgJQIAEgDTYCjAEgASAUNgKIASABIBM2AoQBIAEgEjYCgAEgAUFAayABQdAAaiABQYABahD0ASABIA42AmwgASAKNgJoIAEgCTYCZCABIAg2AmAgASAHNgJ8IAEgBDYCeCABIAM2AnQgASACNgJwIAEgASgCTCIIQe6FvqQHaiINNgKMASABIAEoAkhB78aVxQdqIgk2AogBIAEgASgCREGU8KGmeGoiCjYChAEgASABKAJAQYiEnOZ4aiIONgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQ8gASgCVCEQIAEoAlghESABKAJcIRggASAHNgJsIAEgBDYCaCABIAM2AmQgASACNgJgIAEgGDYCfCABIBE2AnggASAQNgJ0IAEgDzYCcCABIAo2AowBIAEgDjYCiAEgASANNgKEASABIAk2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlAhDSABKAJUIQIgASgCWCEDIAEoAlwhBCABIAw2AnwgASALNgJ4IAEgBjYCdCABIAU2AnAgASAZNgKMASABIBc2AogBIAEgFjYChAEgASAVNgKAASABQeAAaiABQfAAaiABQYABahD8ASABIBQgASgCbGo2AlwgASATIAEoAmhqNgJYIAEgEiABKAJkajYCVCABIAggASgCYGo2AlAgGiABKQNINwMAIAEgASkDQDcDgAEgAUHwAGogAUHQAGogAUGAAWoQ9AEgASgCcCEFIAEoAnQhBiABKAJ4IQsgASgCfCEMIAEgGDYCbCABIBE2AmggASAQNgJkIAEgDzYCYCABIAQ2AnwgASADNgJ4IAEgAjYCdCABIA02AnAgASAMQfr/+4V5aiIPNgKMASABIAtB69nBonpqIhA2AogBIAEgBkH3x+b3e2oiETYChAEgASAFQfLxxbN8aiIYNgKAASABQdAAaiABQeAAaiABQfAAaiABQYABahCcASABKAJQIQUgASgCVCEGIAEoAlghCyABKAJcIQwgASAENgJsIAEgAzYCaCABIAI2AmQgASANNgJgIAEgDDYCfCABIAs2AnggASAGNgJ0IAEgBTYCcCABIBE2AowBIAEgGDYCiAEgASAPNgKEASABIBA2AoABIAFB0ABqIAFB4ABqIAFB8ABqIAFBgAFqEJwBIAEoAlwhDyABKAJYIRAgASgCVCERIAAgACgCACABKAJQajYCACAAIBEgACgCBGo2AgQgACAFIAAoAghqNgIIIAAgBiAAKAIMajYCDCAAIBAgACgCEGo2AhAgACAPIAAoAhRqNgIUIAAgCyAAKAIYajYCGCAAIAwgACgCHGo2AhwgAUGQAWokAAvWIgIBfx5+IwBB0AprIgMkACADQfAGaiACKQMAIgUgASkDACIEEJ4CIANB4AZqIAMpA/AGIgxCm/zRkrG0xwJ+Qv////////8HgyIJQu2n1+el45gBEJ4CIANBgAdqIAIpAwgiBiAEEJ4CIANBwAdqIAEpAwgiByAFEJ4CIANB0AZqIAlCgcu1zvfF+gYQngIgA0HABmogAykDwAciECADKQOAB3wiESADKQPQBnwiDiAMIAMpA+AGIgh8IgxCNIggDCAIVK0gA0HoBmopAwAgA0H4BmopAwB8fCIUQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GACGogByAGEJ4CIANBkAdqIAIpAxAiCCAEEJ4CIANB0AdqIAEpAxAiDSAFEJ4CIANBkAZqIAlC+b3TABCeAiADQbAGaiAMQoHLtc73xfoGEJ4CIANBgAZqIAMpA5AHIhcgAykDgAh8IhIgAykD0Ad8IgogAykDkAZ8Ig8gAykDsAZ8IhMgAykDwAYiFSALfCIWQjSIIBYgFVStIANByAZqKQMAIAsgDlStIA4gEVStIANB2AZqKQMAIBEgEFStIANByAdqKQMAIANBiAdqKQMAfHx8fCAUQjSIfHx8fCIYQgyGhHwiEEKb/NGSsbTHAn5C/////////weDIhFC7afX56XjmAEQngIgA0HACGogCCAHEJ4CIANBkAhqIA0gBhCeAiADQaAHaiACKQMYIg4gBBCeAiADQeAHaiABKQMYIgsgBRCeAiADQaAGaiAMQvm90wAQngIgA0HwBWogEUKBy7XO98X6BhCeAiADQeAFaiADKQOQCCIeIAMpA8AIfCIUIAMpA6AHfCIVIAMpA+AHfCIWIAMpA6AGfCIZIAMpA/AFfCIaIAMpA4AGIhsgEHwiHEI0iCAcIBtUrSADQYgGaikDACAQIBNUrSATIA9UrSADQbgGaikDACAPIApUrSADQZgGaikDACAKIBJUrSADQdgHaikDACASIBdUrSADQZgHaikDACADQYgIaikDAHx8fHx8fHx8IBhCNIh8fHx8Ih9CDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiEkLtp9fnpeOYARCeAiADQfAIaiANIAgQngIgA0HQCGogDiAHEJ4CIANBoAhqIAsgBhCeAiADQbAHaiACKQMgIgogBBCeAiADQfAHaiABKQMgIgQgBRCeAiADQbAFaiARQvm90wAQngIgA0HQBWogEkKBy7XO98X6BhCeAiADQaAFaiADKQPQCCIgIAMpA/AIfCITIAlCLIZ8IhAgAykDoAh8IhcgAykDsAd8IhggAykD8Ad8IhsgAykDsAV8IhwgAykD0AV8Ih0gAykD4AUiBSAPfCIhQjSIICEgBVStIANB6AVqKQMAIA8gGlStIBogGVStIANB+AVqKQMAIBkgFlStIANBqAZqKQMAIBYgFVStIANB6AdqKQMAIBUgFFStIANBqAdqKQMAIBQgHlStIANBmAhqKQMAIANByAhqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIUQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GgCWogDiANEJ4CIANBgAlqIAsgCBCeAiADQeAIaiAKIAcQngIgA0GwCGogBCAGEJ4CIANBwAVqIBJC+b3TABCeAiADQZAFaiAFQoHLtc73xfoGEJ4CIANBwAlqIAsgDhCeAiADQbAJaiAKIA0QngIgA0GQCWogBCAIEJ4CIANBgAVqIAVC+b3TABCeAiADQeAJaiAKIAsQngIgA0HQCWogBCAOEJ4CIANB8AlqIAQgChCeAiADIAMpA4AJIhUgAykDoAl8IgQgAykD4Ah8IgYgAykDsAh8IgcgDEIshnwiCCADKQPABXwiDSADKQOQBXwiDiADKQOgBSILIA98IgpCNIggCiALVK0gA0GoBWopAwAgDyAdVK0gHSAcVK0gA0HYBWopAwAgHCAbVK0gA0G4BWopAwAgGyAYVK0gA0H4B2opAwAgGCAXVK0gA0G4B2opAwAgFyAQVK0gA0GoCGopAwAgECATVK0gEyAgVK0gA0HYCGopAwAgA0H4CGopAwB8fCAJQhSIfHx8fHx8fHx8fHx8IBRCNIh8fHx8IhBCDIaEfCIJQv////////8HgzcDqAogAyADKQOwCSIUIAMpA8AJfCILIAMpA5AJfCIKIBFCLIZ8Ig8gAykDgAV8IhMgCSAOVK0gDiANVK0gA0GYBWopAwAgDSAIVK0gA0HIBWopAwAgCCAHVK0gByAGVK0gA0G4CGopAwAgBiAEVK0gA0HoCGopAwAgBCAVVK0gA0GICWopAwAgA0GoCWopAwB8fHx8fHwgDEIUiHx8fHx8fCAQQjSIfHwiB0IMhiAJQjSIhHwiBEL/////////B4M3A7AKIAMgAykD0AkiDCADKQPgCXwiCSASQiyGfCIGIAQgE1StIBMgD1StIANBiAVqKQMAIA8gClStIAogC1StIANBmAlqKQMAIAsgFFStIANBuAlqKQMAIANByAlqKQMAfHx8fCARQhSIfHx8fCAHQjSIfHwiCEIMhiAEQjSIhHwiBEL/////////B4M3A7gKIAMgBUIshiINIAMpA/AJfCIHIAQgBlStIAYgCVStIAkgDFStIANB2AlqKQMAIANB6AlqKQMAfHwgEkIUiHx8IAhCNIh8fCIJQgyGIARCNIiEfCIEQv////////8HgzcDwAogAyAEIAdUrSAHIA1UrSADQfgJaikDACAFQhSIfHwgCUI0iHx8QgyGIARCNIiENwPICiADQYAKaiADQagKakGAvMQAEKABIANBsAJqIAMpA4AKIgVCu6LLyt7M9AQQngIgA0HgAWogAykDsAIiBkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgA0GgAmogBUKfzfqt8fjYBhCeAiADQYADaiADKQOICiIJQruiy8rezPQEEJ4CIANB0AFqIARCgcu1zvfF+gYQngIgA0GwAWogAykDgAMiCiADKQOgAnwiDCADKQPQAXwiCCAGIAMpA+ABIgd8IgZCNIggBiAHVK0gA0HoAWopAwAgA0G4AmopAwB8fCIPQgyGhHwiDUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GQAmogBUKE7KHb3MzvAhCeAiADQfACaiAJQp/N+q3x+NgGEJ4CIANB0ANqIAMpA5AKIgdCu6LLyt7M9AQQngIgA0HAAWogBEL5vdMAEJ4CIANBoAFqIAZCgcu1zvfF+gYQngIgA0GAAWogAykD8AIiFSADKQOQAnwiESADKQPQA3wiDiADKQPAAXwiCyADKQOgAXwiEiADKQOwASITIA18IhBCNIggECATVK0gA0G4AWopAwAgDSAIVK0gCCAMVK0gA0HYAWopAwAgDCAKVK0gA0GIA2opAwAgA0GoAmopAwB8fHx8IA9CNIh8fHx8IhZCDIaEfCINQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYACaiAFQv/C9LnsnfcBEJ4CIANB4AJqIAlChOyh29zM7wIQngIgA0HAA2ogB0Kfzfqt8fjYBhCeAiADQaAEaiADKQOYCiIIQruiy8rezPQEEJ4CIANBkAFqIAZC+b3TABCeAiADQfAAaiAMQoHLtc73xfoGEJ4CIANB0ABqIAMpA+ACIhcgAykDgAJ8IgogAykDwAN8Ig8gAykDoAR8IhMgAykDkAF8IhAgAykDcHwiFCADKQOAASIZIA18IhpCNIggGiAZVK0gA0GIAWopAwAgDSASVK0gEiALVK0gA0GoAWopAwAgCyAOVK0gA0HIAWopAwAgDiARVK0gA0HYA2opAwAgESAVVK0gA0H4AmopAwAgA0GYAmopAwB8fHx8fHx8fCAWQjSIfHx8fCIYQgyGhHwiEUKb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0HwAWogBUKa4fDbkagCEJ4CIANB0AJqIAlC/8L0ueyd9wEQngIgA0GwA2ogB0KE7KHb3MzvAhCeAiADQZAEaiAIQp/N+q3x+NgGEJ4CIANB8ARqIAMpA6AKIgVCu6LLyt7M9AQQngIgA0HgAGogDEL5vdMAEJ4CIANBQGsgDUKBy7XO98X6BhCeAiADQSBqIAMpA9ACIhsgAykD8AF8Ig4gAykDsAN8IgsgAykDkAR8IhIgAykD8AR8IhUgBEIshnwiFiADKQNgfCIZIAMpA0B8IhogAykDUCIcIBF8Ih1CNIggHSAcVK0gA0HYAGopAwAgESAUVK0gFCAQVK0gA0H4AGopAwAgECATVK0gA0GYAWopAwAgEyAPVK0gA0GoBGopAwAgDyAKVK0gA0HIA2opAwAgCiAXVK0gA0HoAmopAwAgA0GIAmopAwB8fHx8fHx8fHx8IBhCNIh8fHx8IhBCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiEULtp9fnpeOYARCeAiADQcACaiAJQprh8NuRqAIQngIgA0GgA2ogB0L/wvS57J33ARCeAiADQYAEaiAIQoTsodvczO8CEJ4CIANB4ARqIAVCn836rfH42AYQngIgA0EwaiANQvm90wAQngIgA0EQaiARQoHLtc73xfoGEJ4CIANBkANqIAdCmuHw25GoAhCeAiADQfADaiAIQv/C9LnsnfcBEJ4CIANB0ARqIAVChOyh29zM7wIQngIgAyARQvm90wAQngIgA0HgA2ogCEKa4fDbkagCEJ4CIANBwARqIAVC/8L0ueyd9wEQngIgA0GwBGogBUKa4fDbkagCEJ4CIAMgAykDoAMiFCADKQPAAnwiBSADKQOABHwiCSADKQPgBHwiByAGQiyGfCIIIAMpAzB8Ig8gAykDEHwiEyADKQMgIhcgCnwiGEI0iCAYIBdUrSADQShqKQMAIAogGlStIBogGVStIANByABqKQMAIBkgFlStIANB6ABqKQMAIBYgFVStIBUgElStIANB+ARqKQMAIBIgC1StIANBmARqKQMAIAsgDlStIANBuANqKQMAIA4gG1StIANB2AJqKQMAIANB+AFqKQMAfHx8fHx8fHwgBEIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBEL/////////B4M3A6gKIAMgAykD8AMiFSADKQOQA3wiDiADKQPQBHwiCyAMQiyGfCISIAMpAwB8IgogBCATVK0gEyAPVK0gA0EYaikDACAPIAhUrSADQThqKQMAIAggB1StIAcgCVStIANB6ARqKQMAIAkgBVStIANBiARqKQMAIAUgFFStIANBqANqKQMAIANByAJqKQMAfHx8fHx8IAZCFIh8fHx8fHwgEEI0iHx8IgZCDIYgBEI0iIR8IgVC/////////weDNwOwCiADIAMpA8AEIgcgAykD4AN8IgQgDUIshnwiCSAFIApUrSAKIBJUrSADQQhqKQMAIBIgC1StIAsgDlStIANB2ARqKQMAIA4gFVStIANB+ANqKQMAIANBmANqKQMAfHx8fCAMQhSIfHx8fCAGQjSIfHwiDEIMhiAFQjSIhHwiBUL/////////B4M3A7gKIAMgEUIshiIIIAMpA7AEfCIGIAUgCVStIAkgBFStIAQgB1StIANByARqKQMAIANB6ANqKQMAfHwgDUIUiHx8IAxCNIh8fCIEQgyGIAVCNIiEfCIFQv////////8HgzcDwAogAyAFIAZUrSAGIAhUrSADQbgEaikDACARQhSIfHwgBEI0iHx8QgyGIAVCNIiENwPICiAAIANBqApqQYC8xAAQoAEgA0HQCmokAAvWIgIBfx5+IwBB0AprIgMkACADQfAGaiACKQMAIgUgASkDACIEEJ4CIANB4AZqIAMpA/AGIgxCm/zRkrG0xwJ+Qv////////8HgyIJQu2n1+el45gBEJ4CIANBgAdqIAIpAwgiBiAEEJ4CIANBwAdqIAEpAwgiByAFEJ4CIANB0AZqIAlCgcu1zvfF+gYQngIgA0HABmogAykDwAciECADKQOAB3wiESADKQPQBnwiDiAMIAMpA+AGIgh8IgxCNIggDCAIVK0gA0HoBmopAwAgA0H4BmopAwB8fCIUQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GACGogByAGEJ4CIANBkAdqIAIpAxAiCCAEEJ4CIANB0AdqIAEpAxAiDSAFEJ4CIANBkAZqIAlC+b3TABCeAiADQbAGaiAMQoHLtc73xfoGEJ4CIANBgAZqIAMpA5AHIhcgAykDgAh8IhIgAykD0Ad8IgogAykDkAZ8Ig8gAykDsAZ8IhMgAykDwAYiFSALfCIWQjSIIBYgFVStIANByAZqKQMAIAsgDlStIA4gEVStIANB2AZqKQMAIBEgEFStIANByAdqKQMAIANBiAdqKQMAfHx8fCAUQjSIfHx8fCIYQgyGhHwiEEKb/NGSsbTHAn5C/////////weDIhFC7afX56XjmAEQngIgA0HACGogCCAHEJ4CIANBkAhqIA0gBhCeAiADQaAHaiACKQMYIg4gBBCeAiADQeAHaiABKQMYIgsgBRCeAiADQaAGaiAMQvm90wAQngIgA0HwBWogEUKBy7XO98X6BhCeAiADQeAFaiADKQOQCCIeIAMpA8AIfCIUIAMpA6AHfCIVIAMpA+AHfCIWIAMpA6AGfCIZIAMpA/AFfCIaIAMpA4AGIhsgEHwiHEI0iCAcIBtUrSADQYgGaikDACAQIBNUrSATIA9UrSADQbgGaikDACAPIApUrSADQZgGaikDACAKIBJUrSADQdgHaikDACASIBdUrSADQZgHaikDACADQYgIaikDAHx8fHx8fHx8IBhCNIh8fHx8Ih9CDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiEkLtp9fnpeOYARCeAiADQfAIaiANIAgQngIgA0HQCGogDiAHEJ4CIANBoAhqIAsgBhCeAiADQbAHaiACKQMgIgogBBCeAiADQfAHaiABKQMgIgQgBRCeAiADQbAFaiARQvm90wAQngIgA0HQBWogEkKBy7XO98X6BhCeAiADQaAFaiADKQPQCCIgIAMpA/AIfCITIAlCLIZ8IhAgAykDoAh8IhcgAykDsAd8IhggAykD8Ad8IhsgAykDsAV8IhwgAykD0AV8Ih0gAykD4AUiBSAPfCIhQjSIICEgBVStIANB6AVqKQMAIA8gGlStIBogGVStIANB+AVqKQMAIBkgFlStIANBqAZqKQMAIBYgFVStIANB6AdqKQMAIBUgFFStIANBqAdqKQMAIBQgHlStIANBmAhqKQMAIANByAhqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIUQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GgCWogDiANEJ4CIANBgAlqIAsgCBCeAiADQeAIaiAKIAcQngIgA0GwCGogBCAGEJ4CIANBwAVqIBJC+b3TABCeAiADQZAFaiAFQoHLtc73xfoGEJ4CIANBwAlqIAsgDhCeAiADQbAJaiAKIA0QngIgA0GQCWogBCAIEJ4CIANBgAVqIAVC+b3TABCeAiADQeAJaiAKIAsQngIgA0HQCWogBCAOEJ4CIANB8AlqIAQgChCeAiADIAMpA4AJIhUgAykDoAl8IgQgAykD4Ah8IgYgAykDsAh8IgcgDEIshnwiCCADKQPABXwiDSADKQOQBXwiDiADKQOgBSILIA98IgpCNIggCiALVK0gA0GoBWopAwAgDyAdVK0gHSAcVK0gA0HYBWopAwAgHCAbVK0gA0G4BWopAwAgGyAYVK0gA0H4B2opAwAgGCAXVK0gA0G4B2opAwAgFyAQVK0gA0GoCGopAwAgECATVK0gEyAgVK0gA0HYCGopAwAgA0H4CGopAwB8fCAJQhSIfHx8fHx8fHx8fHx8IBRCNIh8fHx8IhBCDIaEfCIJQv////////8HgzcDqAogAyADKQOwCSIUIAMpA8AJfCILIAMpA5AJfCIKIBFCLIZ8Ig8gAykDgAV8IhMgCSAOVK0gDiANVK0gA0GYBWopAwAgDSAIVK0gA0HIBWopAwAgCCAHVK0gByAGVK0gA0G4CGopAwAgBiAEVK0gA0HoCGopAwAgBCAVVK0gA0GICWopAwAgA0GoCWopAwB8fHx8fHwgDEIUiHx8fHx8fCAQQjSIfHwiB0IMhiAJQjSIhHwiBEL/////////B4M3A7AKIAMgAykD0AkiDCADKQPgCXwiCSASQiyGfCIGIAQgE1StIBMgD1StIANBiAVqKQMAIA8gClStIAogC1StIANBmAlqKQMAIAsgFFStIANBuAlqKQMAIANByAlqKQMAfHx8fCARQhSIfHx8fCAHQjSIfHwiCEIMhiAEQjSIhHwiBEL/////////B4M3A7gKIAMgBUIshiINIAMpA/AJfCIHIAQgBlStIAYgCVStIAkgDFStIANB2AlqKQMAIANB6AlqKQMAfHwgEkIUiHx8IAhCNIh8fCIJQgyGIARCNIiEfCIEQv////////8HgzcDwAogAyAEIAdUrSAHIA1UrSADQfgJaikDACAFQhSIfHwgCUI0iHx8QgyGIARCNIiENwPICiADQYAKaiADQagKakHY7cgAEKEBIANBsAJqIAMpA4AKIgVCu6LLyt7M9AQQngIgA0HgAWogAykDsAIiBkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgA0GgAmogBUKfzfqt8fjYBhCeAiADQYADaiADKQOICiIJQruiy8rezPQEEJ4CIANB0AFqIARCgcu1zvfF+gYQngIgA0GwAWogAykDgAMiCiADKQOgAnwiDCADKQPQAXwiCCAGIAMpA+ABIgd8IgZCNIggBiAHVK0gA0HoAWopAwAgA0G4AmopAwB8fCIPQgyGhHwiDUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GQAmogBUKE7KHb3MzvAhCeAiADQfACaiAJQp/N+q3x+NgGEJ4CIANB0ANqIAMpA5AKIgdCu6LLyt7M9AQQngIgA0HAAWogBEL5vdMAEJ4CIANBoAFqIAZCgcu1zvfF+gYQngIgA0GAAWogAykD8AIiFSADKQOQAnwiESADKQPQA3wiDiADKQPAAXwiCyADKQOgAXwiEiADKQOwASITIA18IhBCNIggECATVK0gA0G4AWopAwAgDSAIVK0gCCAMVK0gA0HYAWopAwAgDCAKVK0gA0GIA2opAwAgA0GoAmopAwB8fHx8IA9CNIh8fHx8IhZCDIaEfCINQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYACaiAFQv/C9LnsnfcBEJ4CIANB4AJqIAlChOyh29zM7wIQngIgA0HAA2ogB0Kfzfqt8fjYBhCeAiADQaAEaiADKQOYCiIIQruiy8rezPQEEJ4CIANBkAFqIAZC+b3TABCeAiADQfAAaiAMQoHLtc73xfoGEJ4CIANB0ABqIAMpA+ACIhcgAykDgAJ8IgogAykDwAN8Ig8gAykDoAR8IhMgAykDkAF8IhAgAykDcHwiFCADKQOAASIZIA18IhpCNIggGiAZVK0gA0GIAWopAwAgDSASVK0gEiALVK0gA0GoAWopAwAgCyAOVK0gA0HIAWopAwAgDiARVK0gA0HYA2opAwAgESAVVK0gA0H4AmopAwAgA0GYAmopAwB8fHx8fHx8fCAWQjSIfHx8fCIYQgyGhHwiEUKb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0HwAWogBUKa4fDbkagCEJ4CIANB0AJqIAlC/8L0ueyd9wEQngIgA0GwA2ogB0KE7KHb3MzvAhCeAiADQZAEaiAIQp/N+q3x+NgGEJ4CIANB8ARqIAMpA6AKIgVCu6LLyt7M9AQQngIgA0HgAGogDEL5vdMAEJ4CIANBQGsgDUKBy7XO98X6BhCeAiADQSBqIAMpA9ACIhsgAykD8AF8Ig4gAykDsAN8IgsgAykDkAR8IhIgAykD8AR8IhUgBEIshnwiFiADKQNgfCIZIAMpA0B8IhogAykDUCIcIBF8Ih1CNIggHSAcVK0gA0HYAGopAwAgESAUVK0gFCAQVK0gA0H4AGopAwAgECATVK0gA0GYAWopAwAgEyAPVK0gA0GoBGopAwAgDyAKVK0gA0HIA2opAwAgCiAXVK0gA0HoAmopAwAgA0GIAmopAwB8fHx8fHx8fHx8IBhCNIh8fHx8IhBCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiEULtp9fnpeOYARCeAiADQcACaiAJQprh8NuRqAIQngIgA0GgA2ogB0L/wvS57J33ARCeAiADQYAEaiAIQoTsodvczO8CEJ4CIANB4ARqIAVCn836rfH42AYQngIgA0EwaiANQvm90wAQngIgA0EQaiARQoHLtc73xfoGEJ4CIANBkANqIAdCmuHw25GoAhCeAiADQfADaiAIQv/C9LnsnfcBEJ4CIANB0ARqIAVChOyh29zM7wIQngIgAyARQvm90wAQngIgA0HgA2ogCEKa4fDbkagCEJ4CIANBwARqIAVC/8L0ueyd9wEQngIgA0GwBGogBUKa4fDbkagCEJ4CIAMgAykDoAMiFCADKQPAAnwiBSADKQOABHwiCSADKQPgBHwiByAGQiyGfCIIIAMpAzB8Ig8gAykDEHwiEyADKQMgIhcgCnwiGEI0iCAYIBdUrSADQShqKQMAIAogGlStIBogGVStIANByABqKQMAIBkgFlStIANB6ABqKQMAIBYgFVStIBUgElStIANB+ARqKQMAIBIgC1StIANBmARqKQMAIAsgDlStIANBuANqKQMAIA4gG1StIANB2AJqKQMAIANB+AFqKQMAfHx8fHx8fHwgBEIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBEL/////////B4M3A6gKIAMgAykD8AMiFSADKQOQA3wiDiADKQPQBHwiCyAMQiyGfCISIAMpAwB8IgogBCATVK0gEyAPVK0gA0EYaikDACAPIAhUrSADQThqKQMAIAggB1StIAcgCVStIANB6ARqKQMAIAkgBVStIANBiARqKQMAIAUgFFStIANBqANqKQMAIANByAJqKQMAfHx8fHx8IAZCFIh8fHx8fHwgEEI0iHx8IgZCDIYgBEI0iIR8IgVC/////////weDNwOwCiADIAMpA8AEIgcgAykD4AN8IgQgDUIshnwiCSAFIApUrSAKIBJUrSADQQhqKQMAIBIgC1StIAsgDlStIANB2ARqKQMAIA4gFVStIANB+ANqKQMAIANBmANqKQMAfHx8fCAMQhSIfHx8fCAGQjSIfHwiDEIMhiAFQjSIhHwiBUL/////////B4M3A7gKIAMgEUIshiIIIAMpA7AEfCIGIAUgCVStIAkgBFStIAQgB1StIANByARqKQMAIANB6ANqKQMAfHwgDUIUiHx8IAxCNIh8fCIEQgyGIAVCNIiEfCIFQv////////8HgzcDwAogAyAFIAZUrSAGIAhUrSADQbgEaikDACARQhSIfHwgBEI0iHx8QgyGIAVCNIiENwPICiAAIANBqApqQdjtyAAQoQEgA0HQCmokAAucIgEVfyMAQbDAAGsiAiQAIAJBIGogAUEYaikAADcDAEEQIQQgAkEYaiIDIAFBEGopAAA3AwAgAkEQaiIKIAFBCGoiDykAADcDACACIAEpAAA3AwggAkHIAGpBAEHgHxDBBCACQTBqIA8pAAA3AwAgAkFAayAKKQMANwMAIAIgASkAADcDKCACIAIpAwg3AzggAxCpASACQdgAaiADEKkBA0AgBUGACEYEQCACQShqIAJBqAhqQcAAEPIDGkEAIQVBkAIhBANAIAVBwB9GBEACQCACQaggaiACQShqQYAgEPIDGkEAIQUgAkEANgKoQCACQagwaiEBQcAAIRUDQCAVBEAgBUEPcQ0CIAVB/wNxIgNBAWohBCAFQRBqQf8DcSEWIAVB8ANqQf8DcSIKQQRqIQ8gCkEGaiEJIApBDWohBwJ/IAVBgARPBEAgASADQQJ0aiIFIAUoAgAgASAJQQJ0aiIMKAIAQQh3aiABIAdBAnRqIg0oAgBBCncgASAEQQJ0aiIJKAIAIgdBF3dzaiIRNgIAIAJBqCBqIANBgARyIgRBAnRqIAJBqCBqIAEgD0ECdGooAgAiA0EOdkH8B3FBgAhyaigCACACQaggaiADQf8BcUECdGooAgBqIBFzIg82AgAgCSAHIApBAnQgAWoiA0EcaiIOKAIAQQh3aiADQThqIhEoAgBBCncgBUEIaiIJKAIAIgdBF3dzaiIUNgIAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQCAEQQFqIgpBgAhJBEAgAkGoIGogCkECdGogAkGoIGogA0EUaigCACIKQf8BcUECdGooAgAgAkGoIGogCkEOdkH8B3FBgAhyaigCAGogFHMiCjYCACAJIANBIGoiBigCAEEIdyAHaiADQTxqIhQoAgBBCncgBUEMaiIHKAIAIgtBF3dzaiIINgIAIARBAmoiCUH/B0sNASACQaggaiAJQQJ0aiACQaggaiAMKAIAIglB/wFxQQJ0aigCACACQaggaiAJQQ52QfwHcUGACHJqKAIAaiAIcyIJNgIAIAcgCyADQSRqIggoAgBBCHdqIAVBEGoiDCgCACILQRd3IA9BCndzaiISNgIAIARBA2oiB0H/B0sNAiACQaggaiAHQQJ0aiACQaggaiAOKAIAIgdB/wFxQQJ0aigCACACQaggaiAHQQ52QfwHcUGACHJqKAIAaiAScyIHNgIAIAwgCyADQShqIhIoAgBBCHdqIAVBFGoiDigCACILQRd3IApBCndzaiIQNgIAIARBBGoiDEH/B0sNAyACQaggaiAMQQJ0aiACQaggaiAGKAIAIgxB/wFxQQJ0aigCACACQaggaiAMQQ52QfwHcUGACHJqKAIAaiAQcyIMNgIAIA4gA0EsaiIGKAIAQQh3IAtqIAVBGGoiCygCACIQQRd3IAlBCndzaiITNgIAIARBBWoiDkH/B0sNBCACQaggaiAOQQJ0aiACQaggaiAIKAIAIg5B/wFxQQJ0aigCACACQaggaiAOQQ52QfwHcUGACHJqKAIAaiATcyIONgIAIAsgA0EwaiILKAIAQQh3IBBqIAVBHGoiCCgCACIQQRd3IAdBCndzaiITNgIAIARBBmoiA0H/B0sNBSACQaggaiADQQJ0aiACQaggaiASKAIAIgNB/wFxQQJ0aigCACACQaggaiADQQ52QfwHcUGACHJqKAIAaiATcyISNgIAIAggDSgCAEEIdyAQaiAFQSBqIggoAgAiEEEXdyAMQQp3c2oiEzYCACAEQQdqIgNB/wdLDQYgAkGoIGogA0ECdGogAkGoIGogBigCACIDQf8BcUECdGooAgAgAkGoIGogA0EOdkH8B3FBgAhyaigCAGogE3MiBjYCACAIIBEoAgBBCHcgEGogBUEkaiIIKAIAIhBBF3cgDkEKd3NqIhM2AgAgBEEIaiIDQf8HSw0HIAJBqCBqIANBAnRqIAJBqCBqIAsoAgAiA0H/AXFBAnRqKAIAIAJBqCBqIANBDnZB/AdxQYAIcmooAgBqIBNzIgs2AgAgCCAUKAIAQQh3IBBqIAVBKGoiCCgCACIQQRd3IBJBCndzaiISNgIAIARBCWoiA0H/B0sNCCACQaggaiADQQJ0aiACQaggaiANKAIAIgNB/wFxQQJ0aigCACACQaggaiADQQ52QfwHcUGACHJqKAIAaiAScyINNgIAIAggECAPQQh3aiAFQSxqIggoAgAiEkEXdyAGQQp3c2oiBjYCACAEQQpqIgNB/wdLDQkgAkGoIGogA0ECdGogAkGoIGogESgCACIDQf8BcUECdGooAgAgAkGoIGogA0EOdkH8B3FBgAhyaigCAGogBnMiETYCACAIIBIgCkEId2ogBUEwaiIGKAIAIghBF3cgC0EKd3NqIgs2AgAgBEELaiIDQf8HSw0KIAJBqCBqIANBAnRqIAJBqCBqIBQoAgAiA0H/AXFBAnRqKAIAIAJBqCBqIANBDnZB/AdxQYAIcmooAgBqIAtzIhQ2AgAgBiAIIAlBCHdqIAVBNGoiBigCACILQRd3IA1BCndzaiINNgIAIARBDGoiA0H/B0sNCyACQaggaiADQQJ0aiACQaggaiAPQf8BcUECdGooAgAgAkGoIGogD0EOdkH8B3FBgAhyaigCAGogDXMiDzYCACAGIAsgB0EId2ogBUE4aiINKAIAIgZBF3cgEUEKd3NqIhE2AgAgBEENaiIDQf8HSw0MIAJBqCBqIANBAnRqIAJBqCBqIApB/wFxQQJ0aigCACACQaggaiAKQQ52QfwHcUGACHJqKAIAaiARczYCACANIAYgDEEId2ogBUE8aiIDKAIAIgpBF3cgFEEKd3NqIg02AgAgBEEOaiIFQf8HSw0NIAJBqCBqIAVBAnRqIAJBqCBqIAlB/wFxQQJ0aigCACACQaggaiAJQQ52QfwHcUGACHJqKAIAaiANczYCACADIAogDkEId2ogASAWQQJ0aigCAEEXdyAPQQp3c2oiBTYCACAEQQ9qIgRB/wdLDQ4gAkGoIGogB0EOdkH8B3FBgAhyaiEDIAJBqCBqIAdB/wFxQQJ0agwQC0HY/skAIApBgAgQ5AIAC0Ho/skAIAlBgAgQ5AIAC0H4/skAIAdBgAgQ5AIAC0GI/8kAIAxBgAgQ5AIAC0GY/8kAIA5BgAgQ5AIAC0Go/8kAIANBgAgQ5AIAC0G4/8kAIANBgAgQ5AIAC0HI/8kAIANBgAgQ5AIAC0HY/8kAIANBgAgQ5AIAC0Ho/8kAIANBgAgQ5AIAC0H4/8kAIANBgAgQ5AIAC0GIgMoAIANBgAgQ5AIAC0GYgMoAIANBgAgQ5AIAC0GogMoAIAVBgAgQ5AIAC0G4gMoAIARBgAgQ5AIACyACQaggaiADQQJ0aiIFIAUoAgAgAkGoIGogCUECdGoiDigCAEEYd2ogAkGoIGogB0ECdGoiDSgCAEEWdyACQaggaiAEQQJ0aiIJKAIAIgdBCXdzaiIENgIAIAUgBCABIAJBqCBqIA9BAnRqKAIAIg9BDnZB/AdxQYAIcmooAgAgASAPQf8BcUECdGooAgBqcyIPNgIAIAkgByACQaggaiAKQQJ0aiIEQRxqIgYoAgBBGHdqIARBOGoiESgCAEEWdyAFQQhqIgcoAgAiFEEJd3NqIgo2AgAgCSAKIAEgBEEUaigCACIJQQ52QfwHcUGACHJqKAIAIAEgCUH/AXFBAnRqKAIAanMiCjYCACAHIBQgBEEgaiILKAIAQRh3aiAEQTxqIhQoAgBBFncgBUEMaiIMKAIAIghBCXdzaiIJNgIAIAcgCSABIA4oAgAiB0EOdkH8B3FBgAhyaigCACABIAdB/wFxQQJ0aigCAGpzIgk2AgAgDCAIIARBJGoiEigCAEEYd2ogBUEQaiIOKAIAIghBCXcgD0EWd3NqIgc2AgAgDCAHIAEgBigCACIMQQ52QfwHcUGACHJqKAIAIAEgDEH/AXFBAnRqKAIAanMiBzYCACAOIAggBEEoaiIQKAIAQRh3aiAFQRRqIgwoAgAiBkEJdyAKQRZ3c2oiCDYCACAOIAEgCygCACIOQQ52QfwHcUGACHJqKAIAIAEgDkH/AXFBAnRqKAIAaiAIcyIONgIAIAwgBiAEQSxqIgsoAgBBGHdqIAVBGGoiBigCACIIQQl3IAlBFndzaiITNgIAIAwgASASKAIAIgxBDnZB/AdxQYAIcmooAgAgASAMQf8BcUECdGooAgBqIBNzIgw2AgAgBiAIIARBMGoiEigCAEEYd2ogBUEcaiIEKAIAIghBCXcgB0EWd3NqIhM2AgAgBiABIBAoAgAiBkEOdkH8B3FBgAhyaigCACABIAZB/wFxQQJ0aigCAGogE3MiEDYCACAEIAggDSgCAEEYd2ogBUEgaiIGKAIAIghBCXcgDkEWd3NqIhM2AgAgBCABIAsoAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogE3MiCzYCACAGIAggESgCAEEYd2ogBUEkaiIEKAIAIghBCXcgDEEWd3NqIhM2AgAgBiABIBIoAgAiBkEOdkH8B3FBgAhyaigCACABIAZB/wFxQQJ0aigCAGogE3MiEjYCACAEIAggFCgCAEEYd2ogBUEoaiIGKAIAIghBCXcgEEEWd3NqIhA2AgAgBCABIA0oAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogEHMiEDYCACAGIAggD0EYd2ogBUEsaiIEKAIAIg1BCXcgC0EWd3NqIgs2AgAgBiABIBEoAgAiEUEOdkH8B3FBgAhyaigCACABIBFB/wFxQQJ0aigCAGogC3MiETYCACAEIA0gCkEYd2ogBUEwaiINKAIAIgZBCXcgEkEWd3NqIgs2AgAgBCABIBQoAgAiBEEOdkH8B3FBgAhyaigCACABIARB/wFxQQJ0aigCAGogC3MiFDYCACANIAYgCUEYd2ogBUE0aiIEKAIAIgZBCXcgEEEWd3NqIgs2AgAgDSABIA9BDnZB/AdxQYAIcmooAgAgASAPQf8BcUECdGooAgBqIAtzIg82AgAgBCAGIAdBGHdqIAVBOGoiBSgCACINQQl3IBFBFndzaiIRNgIAIAQgASAKQQ52QfwHcUGACHJqKAIAIAEgCkH/AXFBAnRqKAIAaiARczYCACAFIA0gDkEYd2ogAkGoIGogA0EPaiIEQQJ0aiIDKAIAIgpBCXcgFEEWd3NqIg02AgAgBSABIAlBDnZB/AdxQYAIcmooAgAgASAJQf8BcUECdGooAgBqIA1zNgIAIAMgCiAMQRh3aiACQaggaiAWQQJ0aigCAEEJdyAPQRZ3c2oiBTYCACABIAdB/wFxQQJ0aiEDIAEgB0EOdkH8B3FBgAhyagshCiACQaggaiAEQQJ0aiAKKAIAIAMoAgBqIAVzNgIAIAIgAigCqEBBEGoiBTYCqEAgFUF/aiEVDAELCyACQQA2AqhAIAAgAkGoIGpBhCAQ8gMaIAJBsMAAaiQADwsFIAJBKGogBWoiAUFAayAEIAEoAgAgAUEkaigCAGogAUE4aigCACIDQQ93IANBDXdzIANBCnZzaiABQQRqKAIAIgFBGXcgAUEOd3MgAUEDdnNqajYCACAEQQFqIQQgBUEEaiEFDAELC0G0/ckAQSxByP7JABDOAwAFIAJBKGogBWoiAUFAayAEIAEoAgAgAUEkaigCAGogAUE4aigCACIDQQ93IANBDXdzIANBCnZzaiABQQRqKAIAIgFBGXcgAUEOd3MgAUEDdnNqajYCACAFQQRqIQUgBEEBaiEEDAELAAsAC5grAgJ/IH4jAEGAD2siAiQAIAJBgA5qIAFBgAEQ8gMaQQAhAQNAIAFBgAFHBEAgAkGADmogAWoiAyADKQMAIhtCOIYgG0IohkKAgICAgIDA/wCDhCAbQhiGQoCAgICA4D+DIBtCCIZCgICAgPAfg4SEIBtCCIhCgICA+A+DIBtCGIhCgID8B4OEIBtCKIhCgP4DgyAbQjiIhISENwMAIAFBCGohAQwBCwsgAkHwDWogACkDACIbIAApAyAiHCAAKQMIIh4gACkDKCIfIAApAxAiICAAKQMwIiEgACkDGCIiIAApAzgiIyACKQOADiISQqLcormN84vFwgB8ELwCIAJB4A1qIAIpA/ANIg8gAikD+A0iECAbIBwgHiAfICAgISACKQOIDiIHQs3LvZ+SktGb8QB8ELwCIAJB0A1qIAIpA+ANIgkgAikD6A0iDCAPIBAgGyAcIB4gHyACKQOQDiIXQq/2tOL++b7gtX98ELwCIAJBwA1qIAIpA9ANIgsgAikD2A0iEyAJIAwgDyAQIBsgHCACKQOYDiIIQry3p4zY9PbaaXwQvAIgAkGwDWogAikDwA0iDSACKQPIDSIRIAsgEyAJIAwgDyAQIAIpA6AOIhhCuOqimr/LsKs5fBC8AiACQaANaiACKQOwDSIPIAIpA7gNIhAgDSARIAsgEyAJIAwgAikDqA4iCkKZoJewm77E+NkAfBC8AiACQZANaiACKQOgDSIJIAIpA6gNIgwgDyAQIA0gESALIBMgAikDsA4iFEKbn+X4ytTgn5J/fBC8AiACQYANaiACKQOQDSILIAIpA5gNIhMgCSAMIA8gECANIBEgAikDuA4iHUKYgrbT3dqXjqt/fBC8AiACQfAMaiACKQOADSINIAIpA4gNIhEgCyATIAkgDCAPIBAgAikDwA4iGkLChIyYitPqg1h8ELwCIAJB4AxqIAIpA/AMIg8gAikD+AwiECANIBEgCyATIAkgDCACKQPIDiIWQr7fwauU4NbBEnwQvAIgAkHQDGogAikD4AwiCSACKQPoDCIMIA8gECANIBEgCyATIAIpA9AOIhNCjOWS9+S34ZgkfBC8AiACQcAMaiACKQPQDCILIAIpA9gMIgQgCSAMIA8gECANIBEgAikD2A4iFULi6f6vvbifhtUAfBC8AiACQbAMaiACKQPADCINIAIpA8gMIhEgCyAEIAkgDCAPIBAgAikD4A4iGULvku6Tz66X3/IAfBC8AiACQaAMaiACKQOwDCIFIAIpA7gMIgYgDSARIAsgBCAJIAwgAikD6A4iDkKxrdrY47+s74B/fBC8AiACQZAMaiACKQOgDCIJIAIpA6gMIgwgBSAGIA0gESALIAQgAikD8A4iD0K1pJyu8tSB7pt/fBC8AiACQYAMaiACKQOQDCILIAIpA5gMIgQgCSAMIAUgBiANIBEgAikD+A4iEUKUzaT7zK78zUF8ELwCIAJB8AtqIAcgEiAXIBMgFiARIA8QlgQgAkHgC2ogCCAXIBggGSAVIAIpA/ALIhcgAikD+AsiEBCWBCACQdALaiACKQOADCINIAIpA4gMIhIgCyAEIAkgDCAFIAYgEELSlcX3mbjazWR8ELwCIAJBwAtqIAIpA9ALIgUgAikD2AsiBiANIBIgCyAEIAkgDCAXQuPLvMLj8JHfb3wQvAIgAkGwC2ogAikDwAsiByACKQPICyIIIAUgBiANIBIgCyAEIAIpA+gLIglCtauz3Oi45+APfBC8AiACQaALaiACKQOwCyILIAIpA7gLIgQgByAIIAUgBiANIBIgAikD4AsiEkLluLK9x7mohiR8ELwCIAJBkAtqIAogGCAUIA8gDiASIAkQlgQgAkGAC2ogHSAUIBogECARIAIpA5ALIhggAikDmAsiDBCWBCACQfAKaiACKQOgCyINIAIpA6gLIhQgCyAEIAcgCCAFIAYgDEL1hKzJ9Y3L9C18ELwCIAJB4ApqIAIpA/AKIgUgAikD+AoiBiANIBQgCyAEIAcgCCAYQoPJm/WmlaG6ygB8ELwCIAJB0ApqIAIpA+AKIgcgAikD6AoiCCAFIAYgDSAUIAsgBCACKQOICyILQtT3h+rLu6rY3AB8ELwCIAJBwApqIAIpA9AKIgQgAikD2AoiCiAHIAggBSAGIA0gFCACKQOACyIUQrWnxZiom+L89gB8ELwCIAJBsApqIBYgGiATIAkgFyAUIAsQlgQgAkGgCmogFSATIBkgDCASIAIpA7AKIhogAikDuAoiExCWBCACQZAKaiACKQPACiIWIAIpA8gKIhUgBCAKIAcgCCAFIAYgE0Krv5vzrqqUn5h/fBC8AiACQYAKaiACKQOQCiIFIAIpA5gKIgYgFiAVIAQgCiAHIAggGkKQ5NDt0s3xmKh/fBC8AiACQfAJaiACKQOACiIHIAIpA4gKIgggBSAGIBYgFSAEIAogAikDqAoiDUK/wuzHifnJgbB/fBC8AiACQeAJaiACKQPwCSIEIAIpA/gJIgogByAIIAUgBiAWIBUgAikDoAoiFkLknbz3+/jfrL9/fBC8AiACQdAJaiAOIBkgDyALIBggFiANEJYEIAJBwAlqIBEgDyAQIBMgFCACKQPQCSIZIAIpA9gJIg8QlgQgAkGwCWogAikD4AkiFSACKQPoCSIOIAQgCiAHIAggBSAGIA9Cwp+i7bP+gvBGfBC8AiACQaAJaiACKQOwCSIFIAIpA7gJIgYgFSAOIAQgCiAHIAggGUKlzqqY+ajk01V8ELwCIAJBkAlqIAIpA6AJIgcgAikDqAkiCCAFIAYgFSAOIAQgCiACKQPICSIRQu+EjoCe6pjlBnwQvAIgAkGACWogAikDkAkiBCACKQOYCSIKIAcgCCAFIAYgFSAOIAIpA8AJIhVC8Ny50PCsypQUfBC8AiACQfAIaiAXIBAgCSANIBogFSAREJYEIAJB4AhqIBIgCSAMIA8gFiACKQPwCCIXIAIpA/gIIhAQlgQgAkHQCGogAikDgAkiEiACKQOICSIOIAQgCiAHIAggBSAGIBBC/N/IttTQwtsnfBC8AiACQcAIaiACKQPQCCIFIAIpA9gIIgYgEiAOIAQgCiAHIAggF0KmkpvhhafIjS58ELwCIAJBsAhqIAIpA8AIIgcgAikDyAgiCCAFIAYgEiAOIAQgCiACKQPoCCIJQu3VkNbFv5uWzQB8ELwCIAJBoAhqIAIpA7AIIgQgAikDuAgiCiAHIAggBSAGIBIgDiACKQPgCCISQt/n1uy5ooOc0wB8ELwCIAJBkAhqIBggDCALIBEgGSASIAkQlgQgAkGACGogFCALIBMgECAVIAIpA5AIIhggAikDmAgiDBCWBCACQfAHaiACKQOgCCIUIAIpA6gIIg4gBCAKIAcgCCAFIAYgDELex73dyOqcheUAfBC8AiACQeAHaiACKQPwByIFIAIpA/gHIgYgFCAOIAQgCiAHIAggGEKo5d7js9eCtfYAfBC8AiACQdAHaiACKQPgByIHIAIpA+gHIgggBSAGIBQgDiAEIAogAikDiAgiC0Lm3ba/5KWy4YF/fBC8AiACQcAHaiACKQPQByIEIAIpA9gHIgogByAIIAUgBiAUIA4gAikDgAgiFEK76oik0ZCLuZJ/fBC8AiACQbAHaiAaIBMgDSAJIBcgFCALEJYEIAJBoAdqIBYgDSAPIAwgEiACKQOwByIaIAIpA7gHIhMQlgQgAkGQB2ogAikDwAciFiACKQPIByIOIAQgCiAHIAggBSAGIBNC5IbE55SU+t+if3wQvAIgAkGAB2ogAikDkAciBSACKQOYByIGIBYgDiAEIAogByAIIBpCgeCI4rvJmY2of3wQvAIgAkHwBmogAikDgAciByACKQOIByIIIAUgBiAWIA4gBCAKIAIpA6gHIg1Cka/ih43u4qVCfBC8AiACQeAGaiACKQPwBiIEIAIpA/gGIgogByAIIAUgBiAWIA4gAikDoAciFkKw/NKysLSUtkd8ELwCIAJB0AZqIBkgDyARIAsgGCAWIA0QlgQgAkHABmogFSARIBAgEyAUIAIpA9AGIhkgAikD2AYiDxCWBCACQbAGaiACKQPgBiIVIAIpA+gGIg4gBCAKIAcgCCAFIAYgD0KYpL23nYO6yVF8ELwCIAJBoAZqIAIpA7AGIgUgAikDuAYiBiAVIA4gBCAKIAcgCCAZQpDSlqvFxMHMVnwQvAIgAkGQBmogAikDoAYiByACKQOoBiIIIAUgBiAVIA4gBCAKIAIpA8gGIhFCqsDEu9WwjYd0fBC8AiACQYAGaiACKQOQBiIEIAIpA5gGIgogByAIIAUgBiAVIA4gAikDwAYiFUK4o++Vg46otRB8ELwCIAJB8AVqIBcgECAJIA0gGiAVIBEQlgQgAkHgBWogEiAJIAwgDyAWIAIpA/AFIhcgAikD+AUiEBCWBCACQdAFaiACKQOABiISIAIpA4gGIg4gBCAKIAcgCCAFIAYgEELIocvG66Kw0hl8ELwCIAJBwAVqIAIpA9AFIgUgAikD2AUiBiASIA4gBCAKIAcgCCAXQtPWhoqFgdubHnwQvAIgAkGwBWogAikDwAUiByACKQPIBSIIIAUgBiASIA4gBCAKIAIpA+gFIglCmde7/M3pnaQnfBC8AiACQaAFaiACKQOwBSIEIAIpA7gFIgogByAIIAUgBiASIA4gAikD4AUiEkKoke2M3pav2DR8ELwCIAJBkAVqIBggDCALIBEgGSASIAkQlgQgAkGABWogFCALIBMgECAVIAIpA5AFIhggAikDmAUiDBCWBCACQfAEaiACKQOgBSIUIAIpA6gFIg4gBCAKIAcgCCAFIAYgDELjtKWuvJaDjjl8ELwCIAJB4ARqIAIpA/AEIgUgAikD+AQiBiAUIA4gBCAKIAcgCCAYQsuVhpquyarszgB8ELwCIAJB0ARqIAIpA+AEIgcgAikD6AQiCCAFIAYgFCAOIAQgCiACKQOIBSILQvPGj7v3ybLO2wB8ELwCIAJBwARqIAIpA9AEIgQgAikD2AQiCiAHIAggBSAGIBQgDiACKQOABSIUQqPxyrW9/puX6AB8ELwCIAJBsARqIBogEyANIAkgFyAUIAsQlgQgAkGgBGogFiANIA8gDCASIAIpA7AEIhogAikDuAQiExCWBCACQZAEaiACKQPABCIWIAIpA8gEIg4gBCAKIAcgCCAFIAYgE0L85b7v5d3gx/QAfBC8AiACQYAEaiACKQOQBCIFIAIpA5gEIgYgFiAOIAQgCiAHIAggGkLg3tyY9O3Y0vgAfBC8AiACQfADaiACKQOABCIHIAIpA4gEIgggBSAGIBYgDiAEIAogAikDqAQiDULy1sKPyoKe5IR/fBC8AiACQeADaiACKQPwAyIEIAIpA/gDIgogByAIIAUgBiAWIA4gAikDoAQiFkLs85DTgcHA44x/fBC8AiACQdADaiAZIA8gESALIBggFiANEJYEIAJBwANqIBUgESAQIBMgFCACKQPQAyIZIAIpA9gDIg8QlgQgAkGwA2ogAikD4AMiFSACKQPoAyIOIAQgCiAHIAggBSAGIA9CqLyMm6L/v9+Qf3wQvAIgAkGgA2ogAikDsAMiBSACKQO4AyIGIBUgDiAEIAogByAIIBlC6fuK9L2dm6ikf3wQvAIgAkGQA2ogAikDoAMiByACKQOoAyIIIAUgBiAVIA4gBCAKIAIpA8gDIhFClfKZlvv+6Py+f3wQvAIgAkGAA2ogAikDkAMiBCACKQOYAyIKIAcgCCAFIAYgFSAOIAIpA8ADIhVCq6bJm66e3rhGfBC8AiACQfACaiAXIBAgCSANIBogFSAREJYEIAJB4AJqIBIgCSAMIA8gFiACKQPwAiIOIAIpA/gCIhAQlgQgAkHQAmogAikDgAMiCSACKQOIAyIXIAQgCiAHIAggBSAGIBBCnMOZ0e7Zz5NKfBC8AiACQcACaiACKQPQAiIFIAIpA9gCIgYgCSAXIAQgCiAHIAggDkKHhIOO8piuw1F8ELwCIAJBsAJqIAIpA8ACIhIgAikDyAIiByAFIAYgCSAXIAQgCiACKQPoAiIKQp7Wg+/sup/tanwQvAIgAkGgAmogAikDsAIiBCACKQO4AiIIIBIgByAFIAYgCSAXIAIpA+ACIh1C+KK78/7v0751fBC8AiACQZACaiAYIAwgCyARIBkgHSAKEJYEIAJBgAJqIBQgCyATIBAgFSACKQOQAiIYIAIpA5gCIhQQlgQgAkHwAWogAikDoAIiCSACKQOoAiIMIAQgCCASIAcgBSAGIBRCut/dkKf1mfgGfBC8AiACQeABaiACKQPwASILIAIpA/gBIgUgCSAMIAQgCCASIAcgGEKmsaKW2rjfsQp8ELwCIAJB0AFqIAIpA+ABIgYgAikD6AEiFyALIAUgCSAMIAQgCCACKQOIAiIHQq6b5PfLgOafEXwQvAIgAkHAAWogAikD0AEiBCACKQPYASISIAYgFyALIAUgCSAMIAIpA4ACIghCm47xmNHmwrgbfBC8AiACQbABaiAaIBMgDSAKIA4gCCAHEJYEIAJBoAFqIBYgDSAPIBQgHSACKQOwASINIAIpA7gBIhQQlgQgAkGQAWogAikDwAEiCSACKQPIASIMIAQgEiAGIBcgCyAFIBRChPuRmNL+3e0ofBC8AiACQYABaiACKQOQASILIAIpA5gBIhMgCSAMIAQgEiAGIBcgDUKTyZyGtO+q5TJ8ELwCIAJB8ABqIAIpA4ABIg0gAikDiAEiBSALIBMgCSAMIAQgEiACKQOoASIXQrz9pq6hwa/PPHwQvAIgAkHgAGogAikDcCIEIAIpA3giBiANIAUgCyATIAkgDCACKQOgASIJQsyawODJ+NmOwwB8ELwCIAJB0ABqIBkgDyARIAcgGCAJIBcQlgQgAkFAayAVIBEgECAUIAggAikDUCIRIAIpA1giCRCWBCACQTBqIAIpA2AiDyACKQNoIhAgBCAGIA0gBSALIBMgCUK2hfnZ7Jf14swAfBC8AiACQSBqIAIpAzAiCSACKQM4IgwgDyAQIAQgBiANIAUgEUKq/JXjz7PKv9kAfBC8AiACQRBqIAIpAyAiCyACKQMoIhMgCSAMIA8gECAEIAYgAikDSELs9dvWs/Xb5d8AfBC8AiACIAIpAxAiDSACKQMYIhEgCyATIAkgDCAPIBAgAikDQEKXsJ3SxLGGouwAfBC8AiACKQMAIQ8gAikDCCEQIAAgDCAjfDcDOCAAIBMgIXw3AzAgACARIB98NwMoIAAgCSAifDcDGCAAIAsgIHw3AxAgACANIB58NwMIIAAgECAcfDcDICAAIA8gG3w3AwAgAkGAD2okAAulGQERfyAAKAKAICICQQ9xRQRAIABBgBBqIQQgAkH/A3EiCEEBaiEOIAJBEGpB/wNxIRIgAkHwA2pB/wNxIgNBBGohCSADQQZqIQsgA0ENaiEMAn8gAkGABHEEQCAEIAhBAnRqIgIgAigCACAEIAtBAnRqIgsoAgBBCHdqIAQgDEECdGoiCigCAEEKdyAEIA5BAnRqIggoAgBBF3dzaiIONgIAIAEgDiAAIAQgCUECdGooAgAiCUEOdkH8B3FBgAhyaigCACAAIAlB/wFxQQJ0aigCAGpzNgIAIAggCCgCACADQQJ0IARqIgNBHGoiDCgCAEEId2ogA0E4aiIPKAIAQQp3IAJBCGoiDigCAEEXd3NqIgk2AgAgASAJIAAgA0EUaigCACIFQQ52QfwHcUGACHJqKAIAIAAgBUH/AXFBAnRqKAIAanM2AgQgDiAOKAIAIANBIGoiBSgCAEEId2ogA0E8aiIRKAIAQQp3IAJBDGoiCSgCAEEXd3NqIgc2AgAgASAAIAsoAgAiC0EOdkH8B3FBgAhyaigCACAAIAtB/wFxQQJ0aigCAGogB3M2AgggCSAJKAIAIANBJGoiBygCAEEId2ogAigCAEEKdyACQRBqIgsoAgBBF3dzaiIGNgIAIAEgACAMKAIAIgxBDnZB/AdxQYAIcmooAgAgACAMQf8BcUECdGooAgBqIAZzNgIMIAsgCygCACADQShqIgYoAgBBCHdqIAgoAgBBCncgAkEUaiIMKAIAQRd3c2oiDTYCACABIAAgBSgCACIFQQ52QfwHcUGACHJqKAIAIAAgBUH/AXFBAnRqKAIAaiANczYCECAMIAwoAgAgA0EsaiINKAIAQQh3aiAOKAIAQQp3IAJBGGoiBSgCAEEXd3NqIhA2AgAgASAAIAcoAgAiB0EOdkH8B3FBgAhyaigCACAAIAdB/wFxQQJ0aigCAGogEHM2AhQgBSAFKAIAIANBMGoiECgCAEEId2ogCSgCAEEKdyACQRxqIgMoAgBBF3dzaiIHNgIAIAEgByAAIAYoAgAiBkEOdkH8B3FBgAhyaigCACAAIAZB/wFxQQJ0aigCAGpzNgIYIAMgAygCACAKKAIAQQh3aiALKAIAQQp3IAJBIGoiBygCAEEXd3NqIgY2AgAgASAGIAAgDSgCACINQQ52QfwHcUGACHJqKAIAIAAgDUH/AXFBAnRqKAIAanM2AhwgByAHKAIAIA8oAgBBCHdqIAwoAgBBCncgAkEkaiIGKAIAQRd3c2oiDTYCACABIA0gACAQKAIAIhBBDnZB/AdxQYAIcmooAgAgACAQQf8BcUECdGooAgBqczYCICAGIAYoAgAgESgCAEEId2ogBSgCAEEKdyACQShqIgUoAgBBF3dzaiINNgIAIAEgACAKKAIAIgpBDnZB/AdxQYAIcmooAgAgACAKQf8BcUECdGooAgBqIA1zNgIkIAUgBSgCACACKAIAQQh3aiADKAIAQQp3IAJBLGoiAygCAEEXd3NqIgo2AgAgASAKIAAgDygCACIPQQ52QfwHcUGACHJqKAIAIAAgD0H/AXFBAnRqKAIAanM2AiggAyADKAIAIAgoAgBBCHdqIAcoAgBBCncgAkEwaiIHKAIAQRd3c2oiCjYCACABIAogACARKAIAIg9BDnZB/AdxQYAIcmooAgAgACAPQf8BcUECdGooAgBqczYCLCAHIAcoAgAgDigCAEEId2ogBigCAEEKdyACQTRqIgYoAgBBF3dzaiIKNgIAIAEgCiAAIAIoAgAiD0EOdkH8B3FBgAhyaigCACAAIA9B/wFxQQJ0aigCAGpzNgIwIAYgBigCACAJKAIAQQh3aiAFKAIAQQp3IAJBOGoiBSgCAEEXd3NqIgY2AgAgASAAIAgoAgAiCEEOdkH8B3FBgAhyaigCACAAIAhB/wFxQQJ0aigCAGogBnM2AjQgBSAFKAIAIAsoAgBBCHdqIAMoAgBBCncgAkE8aiICKAIAQRd3c2oiAzYCACABIAMgACAOKAIAIghBDnZB/AdxQYAIcmooAgAgACAIQf8BcUECdGooAgBqczYCOCACIAIoAgAgDCgCAEEId2ogBygCAEEKdyAEIBJBAnRqKAIAQRd3c2oiAjYCACAAIAkoAgAiBEH/AXFBAnRqIQMgACAEQQ52QfwHcUGACHJqDAELIAAgCEECdGoiAiACKAIAIAAgC0ECdGoiCygCAEEYd2ogACAMQQJ0aiIKKAIAQRZ3IAAgDkECdGoiCCgCAEEJd3NqIg42AgAgASAOIAQgACAJQQJ0aigCACIJQQ52QfwHcUGACHJqKAIAIAQgCUH/AXFBAnRqKAIAanM2AgAgCCAIKAIAIANBAnQgAGoiA0EcaiIMKAIAQRh3aiADQThqIg8oAgBBFncgAkEIaiIOKAIAQQl3c2oiCTYCACABIAkgBCADQRRqKAIAIgVBDnZB/AdxQYAIcmooAgAgBCAFQf8BcUECdGooAgBqczYCBCAOIA4oAgAgA0EgaiIFKAIAQRh3aiADQTxqIhEoAgBBFncgAkEMaiIJKAIAQQl3c2oiBzYCACABIAQgCygCACILQQ52QfwHcUGACHJqKAIAIAQgC0H/AXFBAnRqKAIAaiAHczYCCCAJIAkoAgAgA0EkaiIHKAIAQRh3aiACKAIAQRZ3IAJBEGoiCygCAEEJd3NqIgY2AgAgASAEIAwoAgAiDEEOdkH8B3FBgAhyaigCACAEIAxB/wFxQQJ0aigCAGogBnM2AgwgCyALKAIAIANBKGoiBigCAEEYd2ogCCgCAEEWdyACQRRqIgwoAgBBCXdzaiINNgIAIAEgBCAFKAIAIgVBDnZB/AdxQYAIcmooAgAgBCAFQf8BcUECdGooAgBqIA1zNgIQIAwgDCgCACADQSxqIg0oAgBBGHdqIA4oAgBBFncgAkEYaiIFKAIAQQl3c2oiEDYCACABIAQgBygCACIHQQ52QfwHcUGACHJqKAIAIAQgB0H/AXFBAnRqKAIAaiAQczYCFCAFIAUoAgAgA0EwaiIQKAIAQRh3aiAJKAIAQRZ3IAJBHGoiAygCAEEJd3NqIgc2AgAgASAHIAQgBigCACIGQQ52QfwHcUGACHJqKAIAIAQgBkH/AXFBAnRqKAIAanM2AhggAyADKAIAIAooAgBBGHdqIAsoAgBBFncgAkEgaiIHKAIAQQl3c2oiBjYCACABIAYgBCANKAIAIg1BDnZB/AdxQYAIcmooAgAgBCANQf8BcUECdGooAgBqczYCHCAHIAcoAgAgDygCAEEYd2ogDCgCAEEWdyACQSRqIgYoAgBBCXdzaiINNgIAIAEgDSAEIBAoAgAiEEEOdkH8B3FBgAhyaigCACAEIBBB/wFxQQJ0aigCAGpzNgIgIAYgBigCACARKAIAQRh3aiAFKAIAQRZ3IAJBKGoiBSgCAEEJd3NqIg02AgAgASAEIAooAgAiCkEOdkH8B3FBgAhyaigCACAEIApB/wFxQQJ0aigCAGogDXM2AiQgBSAFKAIAIAIoAgBBGHdqIAMoAgBBFncgAkEsaiIDKAIAQQl3c2oiCjYCACABIAogBCAPKAIAIg9BDnZB/AdxQYAIcmooAgAgBCAPQf8BcUECdGooAgBqczYCKCADIAMoAgAgCCgCAEEYd2ogBygCAEEWdyACQTBqIgcoAgBBCXdzaiIKNgIAIAEgCiAEIBEoAgAiD0EOdkH8B3FBgAhyaigCACAEIA9B/wFxQQJ0aigCAGpzNgIsIAcgBygCACAOKAIAQRh3aiAGKAIAQRZ3IAJBNGoiBigCAEEJd3NqIgo2AgAgASAKIAQgAigCACIPQQ52QfwHcUGACHJqKAIAIAQgD0H/AXFBAnRqKAIAanM2AjAgBiAGKAIAIAkoAgBBGHdqIAUoAgBBFncgAkE4aiIFKAIAQQl3c2oiBjYCACABIAQgCCgCACIIQQ52QfwHcUGACHJqKAIAIAQgCEH/AXFBAnRqKAIAaiAGczYCNCAFIAUoAgAgCygCAEEYd2ogAygCAEEWdyACQTxqIgIoAgBBCXdzaiIDNgIAIAEgAyAEIA4oAgAiCEEOdkH8B3FBgAhyaigCACAEIAhB/wFxQQJ0aigCAGpzNgI4IAIgAigCACAMKAIAQRh3aiAHKAIAQRZ3IAAgEkECdGooAgBBCXdzaiICNgIAIAQgCSgCACIIQf8BcUECdGohAyAEIAhBDnZB/AdxQYAIcmoLIQQgASAEKAIAIAMoAgBqIAJzNgI8IAAgACgCgCBBEGo2AoAgDwtBtP3JAEEsQbj+yQAQzgMAC7MSAgF/Gn4jAEGABmsiAyQAIANBsAVqIAEQhgEgA0HYBWogAhCGASADQYgFaiADQbAFaiADQdgFahCPAiADQbgCaiADKQOIBSIEQu3Nh7nWl9IHEJ4CIANB6AFqIAMpA7gCIgVCm/zRkrG0xwJ+Qv////////8HgyIGQu2n1+el45gBEJ4CIANBqAJqIARC2sif49rW7gEQngIgA0GIA2ogAykDkAUiCULtzYe51pfSBxCeAiADQdgBaiAGQoHLtc73xfoGEJ4CIANBuAFqIAMpA4gDIgogAykDqAJ8Ig0gAykD2AF8IgcgBSADKQPoASIIfCIFQjSIIAUgCFStIANB8AFqKQMAIANBwAJqKQMAfHwiEkIMhoR8IgtCm/zRkrG0xwJ+Qv////////8HgyIFQu2n1+el45gBEJ4CIANBmAJqIARCm8rX2f7//wcQngIgA0H4AmogCULayJ/j2tbuARCeAiADQdgDaiADKQOYBSIIQu3Nh7nWl9IHEJ4CIANByAFqIAZC+b3TABCeAiADQagBaiAFQoHLtc73xfoGEJ4CIANBiAFqIAMpA/gCIhQgAykDmAJ8IgwgAykD2AN8Ig4gAykDyAF8Ig8gAykDqAF8IhAgAykDuAEiEyALfCIRQjSIIBEgE1StIANBwAFqKQMAIAsgB1StIAcgDVStIANB4AFqKQMAIA0gClStIANBkANqKQMAIANBsAJqKQMAfHx8fCASQjSIfHx8fCIVQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIg1C7afX56XjmAEQngIgA0GIAmogBEL/////////BxCeAiADQegCaiAJQpvK19n+//8HEJ4CIANByANqIAhC2sif49rW7gEQngIgA0GoBGogAykDoAUiB0LtzYe51pfSBxCeAiADQZgBaiAFQvm90wAQngIgA0H4AGogDUKBy7XO98X6BhCeAiADQdgAaiADKQPoAiIZIAMpA4gCfCIKIAMpA8gDfCISIAMpA6gEfCITIAMpA5gBfCIRIAMpA3h8IhYgAykDiAEiFyALfCIYQjSIIBggF1StIANBkAFqKQMAIAsgEFStIBAgD1StIANBsAFqKQMAIA8gDlStIANB0AFqKQMAIA4gDFStIANB4ANqKQMAIAwgFFStIANBgANqKQMAIANBoAJqKQMAfHx8fHx8fHwgFUI0iHx8fHwiGkIMhoR8IgxCm/zRkrG0xwJ+Qv////////8HgyILQu2n1+el45gBEJ4CIANB+AFqIARC////////AxCeAiADQdgCaiAJQv////////8HEJ4CIANBuANqIAhCm8rX2f7//wcQngIgA0GYBGogB0LayJ/j2tbuARCeAiADQfgEaiADKQOoBSIEQu3Nh7nWl9IHEJ4CIANB6ABqIA1C+b3TABCeAiADQcgAaiALQoHLtc73xfoGEJ4CIANBKGogAykD2AIiGyADKQP4AXwiDiADKQO4A3wiDyADKQOYBHwiECADKQP4BHwiFCAGQiyGfCIVIAMpA2h8IhcgAykDSHwiGCADKQNYIhwgDHwiHUI0iCAdIBxUrSADQeAAaikDACAMIBZUrSAWIBFUrSADQYABaikDACARIBNUrSADQaABaikDACATIBJUrSADQbAEaikDACASIApUrSADQdADaikDACAKIBlUrSADQfACaikDACADQZACaikDAHx8fHx8fHx8fHwgGkI0iHx8fHwiEUIMhoR8IgpCm/zRkrG0xwJ+Qv////////8HgyIMQu2n1+el45gBEJ4CIANByAJqIAlC////////AxCeAiADQagDaiAIQv////////8HEJ4CIANBiARqIAdCm8rX2f7//wcQngIgA0HoBGogBELayJ/j2tbuARCeAiADQThqIAtC+b3TABCeAiADQRhqIAxCgcu1zvfF+gYQngIgA0GYA2ogCEL///////8DEJ4CIANB+ANqIAdC/////////wcQngIgA0HYBGogBEKbytfZ/v//BxCeAiADQQhqIAxC+b3TABCeAiADQegDaiAHQv///////wMQngIgA0HIBGogBEL/////////BxCeAiADQbgEaiAEQv///////wMQngIgAyADKQOoAyIWIAMpA8gCfCIEIAMpA4gEfCIJIAMpA+gEfCIIIAVCLIZ8IgcgAykDOHwiEiADKQMYfCITIAMpAygiGSAKfCIaQjSIIBogGVStIANBMGopAwAgCiAYVK0gGCAXVK0gA0HQAGopAwAgFyAVVK0gA0HwAGopAwAgFSAUVK0gFCAQVK0gA0GABWopAwAgECAPVK0gA0GgBGopAwAgDyAOVK0gA0HAA2opAwAgDiAbVK0gA0HgAmopAwAgA0GAAmopAwB8fHx8fHx8fCAGQhSIfHx8fHx8IBFCNIh8fHx8IhFCDIaEfCIGQv////////8HgzcD2AUgAyADKQP4AyIUIAMpA5gDfCIOIAMpA9gEfCIPIA1CLIZ8IhAgAykDCHwiCiAGIBNUrSATIBJUrSADQSBqKQMAIBIgB1StIANBQGspAwAgByAIVK0gCCAJVK0gA0HwBGopAwAgCSAEVK0gA0GQBGopAwAgBCAWVK0gA0GwA2opAwAgA0HQAmopAwB8fHx8fHwgBUIUiHx8fHx8fCARQjSIfHwiBUIMhiAGQjSIhHwiBEL/////////B4M3A+AFIAMgAykDyAQiCCADKQPoA3wiBiALQiyGfCIJIAQgClStIAogEFStIANBEGopAwAgECAPVK0gDyAOVK0gA0HgBGopAwAgDiAUVK0gA0GABGopAwAgA0GgA2opAwB8fHx8IA1CFIh8fHx8IAVCNIh8fCINQgyGIARCNIiEfCIEQv////////8HgzcD6AUgAyAMQiyGIgcgAykDuAR8IgUgBCAJVK0gCSAGVK0gBiAIVK0gA0HQBGopAwAgA0HwA2opAwB8fCALQhSIfHwgDUI0iHx8IgZCDIYgBEI0iIR8IgRC/////////weDNwPwBSADIAQgBVStIAUgB1StIANBwARqKQMAIAxCFIh8fCAGQjSIfHxCDIYgBEI0iIQ3A/gFIANBsAVqIANB2AVqQaC9xAAQoAEgACADQbAFahBxIANBgAZqJAALsxICAX8afiMAQYAGayIDJAAgA0GwBWogARCHASADQdgFaiACEIcBIANBiAVqIANBsAVqIANB2AVqEJICIANBuAJqIAMpA4gFIgRC7c2HudaX0gcQngIgA0HoAWogAykDuAIiBUKb/NGSsbTHAn5C/////////weDIgZC7afX56XjmAEQngIgA0GoAmogBELayJ/j2tbuARCeAiADQYgDaiADKQOQBSIJQu3Nh7nWl9IHEJ4CIANB2AFqIAZCgcu1zvfF+gYQngIgA0G4AWogAykDiAMiCiADKQOoAnwiDSADKQPYAXwiByAFIAMpA+gBIgh8IgVCNIggBSAIVK0gA0HwAWopAwAgA0HAAmopAwB8fCISQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GYAmogBEKbytfZ/v//BxCeAiADQfgCaiAJQtrIn+Pa1u4BEJ4CIANB2ANqIAMpA5gFIghC7c2HudaX0gcQngIgA0HIAWogBkL5vdMAEJ4CIANBqAFqIAVCgcu1zvfF+gYQngIgA0GIAWogAykD+AIiFCADKQOYAnwiDCADKQPYA3wiDiADKQPIAXwiDyADKQOoAXwiECADKQO4ASITIAt8IhFCNIggESATVK0gA0HAAWopAwAgCyAHVK0gByANVK0gA0HgAWopAwAgDSAKVK0gA0GQA2opAwAgA0GwAmopAwB8fHx8IBJCNIh8fHx8IhVCDIaEfCILQpv80ZKxtMcCfkL/////////B4MiDULtp9fnpeOYARCeAiADQYgCaiAEQv////////8HEJ4CIANB6AJqIAlCm8rX2f7//wcQngIgA0HIA2ogCELayJ/j2tbuARCeAiADQagEaiADKQOgBSIHQu3Nh7nWl9IHEJ4CIANBmAFqIAVC+b3TABCeAiADQfgAaiANQoHLtc73xfoGEJ4CIANB2ABqIAMpA+gCIhkgAykDiAJ8IgogAykDyAN8IhIgAykDqAR8IhMgAykDmAF8IhEgAykDeHwiFiADKQOIASIXIAt8IhhCNIggGCAXVK0gA0GQAWopAwAgCyAQVK0gECAPVK0gA0GwAWopAwAgDyAOVK0gA0HQAWopAwAgDiAMVK0gA0HgA2opAwAgDCAUVK0gA0GAA2opAwAgA0GgAmopAwB8fHx8fHx8fCAVQjSIfHx8fCIaQgyGhHwiDEKb/NGSsbTHAn5C/////////weDIgtC7afX56XjmAEQngIgA0H4AWogBEL///////8DEJ4CIANB2AJqIAlC/////////wcQngIgA0G4A2ogCEKbytfZ/v//BxCeAiADQZgEaiAHQtrIn+Pa1u4BEJ4CIANB+ARqIAMpA6gFIgRC7c2HudaX0gcQngIgA0HoAGogDUL5vdMAEJ4CIANByABqIAtCgcu1zvfF+gYQngIgA0EoaiADKQPYAiIbIAMpA/gBfCIOIAMpA7gDfCIPIAMpA5gEfCIQIAMpA/gEfCIUIAZCLIZ8IhUgAykDaHwiFyADKQNIfCIYIAMpA1giHCAMfCIdQjSIIB0gHFStIANB4ABqKQMAIAwgFlStIBYgEVStIANBgAFqKQMAIBEgE1StIANBoAFqKQMAIBMgElStIANBsARqKQMAIBIgClStIANB0ANqKQMAIAogGVStIANB8AJqKQMAIANBkAJqKQMAfHx8fHx8fHx8fCAaQjSIfHx8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0HIAmogCUL///////8DEJ4CIANBqANqIAhC/////////wcQngIgA0GIBGogB0KbytfZ/v//BxCeAiADQegEaiAEQtrIn+Pa1u4BEJ4CIANBOGogC0L5vdMAEJ4CIANBGGogDEKBy7XO98X6BhCeAiADQZgDaiAIQv///////wMQngIgA0H4A2ogB0L/////////BxCeAiADQdgEaiAEQpvK19n+//8HEJ4CIANBCGogDEL5vdMAEJ4CIANB6ANqIAdC////////AxCeAiADQcgEaiAEQv////////8HEJ4CIANBuARqIARC////////AxCeAiADIAMpA6gDIhYgAykDyAJ8IgQgAykDiAR8IgkgAykD6AR8IgggBUIshnwiByADKQM4fCISIAMpAxh8IhMgAykDKCIZIAp8IhpCNIggGiAZVK0gA0EwaikDACAKIBhUrSAYIBdUrSADQdAAaikDACAXIBVUrSADQfAAaikDACAVIBRUrSAUIBBUrSADQYAFaikDACAQIA9UrSADQaAEaikDACAPIA5UrSADQcADaikDACAOIBtUrSADQeACaikDACADQYACaikDAHx8fHx8fHx8IAZCFIh8fHx8fHwgEUI0iHx8fHwiEUIMhoR8IgZC/////////weDNwPYBSADIAMpA/gDIhQgAykDmAN8Ig4gAykD2AR8Ig8gDUIshnwiECADKQMIfCIKIAYgE1StIBMgElStIANBIGopAwAgEiAHVK0gA0FAaykDACAHIAhUrSAIIAlUrSADQfAEaikDACAJIARUrSADQZAEaikDACAEIBZUrSADQbADaikDACADQdACaikDAHx8fHx8fCAFQhSIfHx8fHx8IBFCNIh8fCIFQgyGIAZCNIiEfCIEQv////////8HgzcD4AUgAyADKQPIBCIIIAMpA+gDfCIGIAtCLIZ8IgkgBCAKVK0gCiAQVK0gA0EQaikDACAQIA9UrSAPIA5UrSADQeAEaikDACAOIBRUrSADQYAEaikDACADQaADaikDAHx8fHwgDUIUiHx8fHwgBUI0iHx8Ig1CDIYgBEI0iIR8IgRC/////////weDNwPoBSADIAxCLIYiByADKQO4BHwiBSAEIAlUrSAJIAZUrSAGIAhUrSADQdAEaikDACADQfADaikDAHx8IAtCFIh8fCANQjSIfHwiBkIMhiAEQjSIhHwiBEL/////////B4M3A/AFIAMgBCAFVK0gBSAHVK0gA0HABGopAwAgDEIUiHx8IAZCNIh8fEIMhiAEQjSIhDcD+AUgA0GwBWogA0HYBWpB+O7IABChASAAIANBsAVqEHEgA0GABmokAAuTEgIBfxp+IwBBgAZrIgIkACACQYgFaiABEIYBIAJB+AFqIAIpA4gFIgNC7c2HudaX0gcQngIgAkHoAWogAikD+AEiBEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgAkGIAmogA0LayJ/j2tbuARCeAiACQcgCaiACKQOQBSIIQu3Nh7nWl9IHEJ4CIAJB2AFqIAVCgcu1zvfF+gYQngIgAkHIAWogAikDyAIiCSACKQOIAnwiDCACKQPYAXwiBiAEIAIpA+gBIgd8IgRCNIggBCAHVK0gAkHwAWopAwAgAkGAAmopAwB8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgAkGYAmogA0KbytfZ/v//BxCeAiACQdgCaiAIQtrIn+Pa1u4BEJ4CIAJBmANqIAIpA5gFIgdC7c2HudaX0gcQngIgAkGYAWogBUL5vdMAEJ4CIAJBuAFqIARCgcu1zvfF+gYQngIgAkGIAWogAikD2AIiEyACKQOYAnwiCyACKQOYA3wiDSACKQOYAXwiDiACKQO4AXwiDyACKQPIASISIAp8IhBCNIggECASVK0gAkHQAWopAwAgCiAGVK0gBiAMVK0gAkHgAWopAwAgDCAJVK0gAkHQAmopAwAgAkGQAmopAwB8fHx8IBFCNIh8fHx8IhRCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiACQagCaiADQv////////8HEJ4CIAJB6AJqIAhCm8rX2f7//wcQngIgAkGoA2ogB0LayJ/j2tbuARCeAiACQegDaiACKQOgBSIGQu3Nh7nWl9IHEJ4CIAJBqAFqIARC+b3TABCeAiACQfgAaiAMQoHLtc73xfoGEJ4CIAJB6ABqIAIpA+gCIhggAikDqAJ8IgkgAikDqAN8IhEgAikD6AN8IhIgAikDqAF8IhAgAikDeHwiFSACKQOIASIWIAp8IhdCNIggFyAWVK0gAkGQAWopAwAgCiAPVK0gDyAOVK0gAkHAAWopAwAgDiANVK0gAkGgAWopAwAgDSALVK0gAkGgA2opAwAgCyATVK0gAkHgAmopAwAgAkGgAmopAwB8fHx8fHx8fCAUQjSIfHx8fCIZQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgpC7afX56XjmAEQngIgAkG4AmogA0L///////8DEJ4CIAJB+AJqIAhC/////////wcQngIgAkG4A2ogB0KbytfZ/v//BxCeAiACQfgDaiAGQtrIn+Pa1u4BEJ4CIAJBuARqIAIpA6gFIgNC7c2HudaX0gcQngIgAkE4aiAMQvm90wAQngIgAkHYAGogCkKBy7XO98X6BhCeAiACQShqIAIpA/gCIhogAikDuAJ8Ig0gAikDuAN8Ig4gAikD+AN8Ig8gAikDuAR8IhMgBUIshnwiFCACKQM4fCIWIAIpA1h8IhcgAikDaCIbIAt8IhxCNIggHCAbVK0gAkHwAGopAwAgCyAVVK0gFSAQVK0gAkGAAWopAwAgECASVK0gAkGwAWopAwAgEiARVK0gAkHwA2opAwAgESAJVK0gAkGwA2opAwAgCSAYVK0gAkHwAmopAwAgAkGwAmopAwB8fHx8fHx8fHx8IBlCNIh8fHx8IhBCDIaEfCIJQpv80ZKxtMcCfkL/////////B4MiC0Ltp9fnpeOYARCeAiACQYgDaiAIQv///////wMQngIgAkHIA2ogB0L/////////BxCeAiACQYgEaiAGQpvK19n+//8HEJ4CIAJByARqIANC2sif49rW7gEQngIgAkHIAGogCkL5vdMAEJ4CIAJBGGogC0KBy7XO98X6BhCeAiACQdgDaiAHQv///////wMQngIgAkGYBGogBkL/////////BxCeAiACQdgEaiADQpvK19n+//8HEJ4CIAJBCGogC0L5vdMAEJ4CIAJBqARqIAZC////////AxCeAiACQegEaiADQv////////8HEJ4CIAJB+ARqIANC////////AxCeAiACIAIpA8gDIhUgAikDiAN8IgMgAikDiAR8IgggAikDyAR8IgcgBEIshnwiBiACKQNIfCIRIAIpAxh8IhIgAikDKCIYIAl8IhlCNIggGSAYVK0gAkEwaikDACAJIBdUrSAXIBZUrSACQeAAaikDACAWIBRUrSACQUBrKQMAIBQgE1StIBMgD1StIAJBwARqKQMAIA8gDlStIAJBgARqKQMAIA4gDVStIAJBwANqKQMAIA0gGlStIAJBgANqKQMAIAJBwAJqKQMAfHx8fHx8fHwgBUIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBUL/////////B4M3A9gFIAIgAikDmAQiEyACKQPYA3wiDSACKQPYBHwiDiAMQiyGfCIPIAIpAwh8IgkgBSASVK0gEiARVK0gAkEgaikDACARIAZUrSACQdAAaikDACAGIAdUrSAHIAhUrSACQdAEaikDACAIIANUrSACQZAEaikDACADIBVUrSACQdADaikDACACQZADaikDAHx8fHx8fCAEQhSIfHx8fHx8IBBCNIh8fCIEQgyGIAVCNIiEfCIDQv////////8HgzcD4AUgAiACKQPoBCIHIAIpA6gEfCIFIApCLIZ8IgggAyAJVK0gCSAPVK0gAkEQaikDACAPIA5UrSAOIA1UrSACQeAEaikDACANIBNUrSACQaAEaikDACACQeADaikDAHx8fHwgDEIUiHx8fHwgBEI0iHx8IgxCDIYgA0I0iIR8IgNC/////////weDNwPoBSACIAtCLIYiBiACKQP4BHwiBCADIAhUrSAIIAVUrSAFIAdUrSACQfAEaikDACACQbAEaikDAHx8IApCFIh8fCAMQjSIfHwiBUIMhiADQjSIhHwiA0L/////////B4M3A/AFIAIgAyAEVK0gBCAGVK0gAkGABWopAwAgC0IUiHx8IAVCNIh8fEIMhiADQjSIhDcD+AUgAkGwBWogAkHYBWpBoL3EABCgASAAIAJBsAVqEHEgAkGABmokAAuTEgIBfxp+IwBBgAZrIgIkACACQYgFaiABEIcBIAJB+AFqIAIpA4gFIgNC7c2HudaX0gcQngIgAkHoAWogAikD+AEiBEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgAkGIAmogA0LayJ/j2tbuARCeAiACQcgCaiACKQOQBSIIQu3Nh7nWl9IHEJ4CIAJB2AFqIAVCgcu1zvfF+gYQngIgAkHIAWogAikDyAIiCSACKQOIAnwiDCACKQPYAXwiBiAEIAIpA+gBIgd8IgRCNIggBCAHVK0gAkHwAWopAwAgAkGAAmopAwB8fCIRQgyGhHwiCkKb/NGSsbTHAn5C/////////weDIgRC7afX56XjmAEQngIgAkGYAmogA0KbytfZ/v//BxCeAiACQdgCaiAIQtrIn+Pa1u4BEJ4CIAJBmANqIAIpA5gFIgdC7c2HudaX0gcQngIgAkGYAWogBUL5vdMAEJ4CIAJBuAFqIARCgcu1zvfF+gYQngIgAkGIAWogAikD2AIiEyACKQOYAnwiCyACKQOYA3wiDSACKQOYAXwiDiACKQO4AXwiDyACKQPIASISIAp8IhBCNIggECASVK0gAkHQAWopAwAgCiAGVK0gBiAMVK0gAkHgAWopAwAgDCAJVK0gAkHQAmopAwAgAkGQAmopAwB8fHx8IBFCNIh8fHx8IhRCDIaEfCIKQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiACQagCaiADQv////////8HEJ4CIAJB6AJqIAhCm8rX2f7//wcQngIgAkGoA2ogB0LayJ/j2tbuARCeAiACQegDaiACKQOgBSIGQu3Nh7nWl9IHEJ4CIAJBqAFqIARC+b3TABCeAiACQfgAaiAMQoHLtc73xfoGEJ4CIAJB6ABqIAIpA+gCIhggAikDqAJ8IgkgAikDqAN8IhEgAikD6AN8IhIgAikDqAF8IhAgAikDeHwiFSACKQOIASIWIAp8IhdCNIggFyAWVK0gAkGQAWopAwAgCiAPVK0gDyAOVK0gAkHAAWopAwAgDiANVK0gAkGgAWopAwAgDSALVK0gAkGgA2opAwAgCyATVK0gAkHgAmopAwAgAkGgAmopAwB8fHx8fHx8fCAUQjSIfHx8fCIZQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIgpC7afX56XjmAEQngIgAkG4AmogA0L///////8DEJ4CIAJB+AJqIAhC/////////wcQngIgAkG4A2ogB0KbytfZ/v//BxCeAiACQfgDaiAGQtrIn+Pa1u4BEJ4CIAJBuARqIAIpA6gFIgNC7c2HudaX0gcQngIgAkE4aiAMQvm90wAQngIgAkHYAGogCkKBy7XO98X6BhCeAiACQShqIAIpA/gCIhogAikDuAJ8Ig0gAikDuAN8Ig4gAikD+AN8Ig8gAikDuAR8IhMgBUIshnwiFCACKQM4fCIWIAIpA1h8IhcgAikDaCIbIAt8IhxCNIggHCAbVK0gAkHwAGopAwAgCyAVVK0gFSAQVK0gAkGAAWopAwAgECASVK0gAkGwAWopAwAgEiARVK0gAkHwA2opAwAgESAJVK0gAkGwA2opAwAgCSAYVK0gAkHwAmopAwAgAkGwAmopAwB8fHx8fHx8fHx8IBlCNIh8fHx8IhBCDIaEfCIJQpv80ZKxtMcCfkL/////////B4MiC0Ltp9fnpeOYARCeAiACQYgDaiAIQv///////wMQngIgAkHIA2ogB0L/////////BxCeAiACQYgEaiAGQpvK19n+//8HEJ4CIAJByARqIANC2sif49rW7gEQngIgAkHIAGogCkL5vdMAEJ4CIAJBGGogC0KBy7XO98X6BhCeAiACQdgDaiAHQv///////wMQngIgAkGYBGogBkL/////////BxCeAiACQdgEaiADQpvK19n+//8HEJ4CIAJBCGogC0L5vdMAEJ4CIAJBqARqIAZC////////AxCeAiACQegEaiADQv////////8HEJ4CIAJB+ARqIANC////////AxCeAiACIAIpA8gDIhUgAikDiAN8IgMgAikDiAR8IgggAikDyAR8IgcgBEIshnwiBiACKQNIfCIRIAIpAxh8IhIgAikDKCIYIAl8IhlCNIggGSAYVK0gAkEwaikDACAJIBdUrSAXIBZUrSACQeAAaikDACAWIBRUrSACQUBrKQMAIBQgE1StIBMgD1StIAJBwARqKQMAIA8gDlStIAJBgARqKQMAIA4gDVStIAJBwANqKQMAIA0gGlStIAJBgANqKQMAIAJBwAJqKQMAfHx8fHx8fHwgBUIUiHx8fHx8fCAQQjSIfHx8fCIQQgyGhHwiBUL/////////B4M3A9gFIAIgAikDmAQiEyACKQPYA3wiDSACKQPYBHwiDiAMQiyGfCIPIAIpAwh8IgkgBSASVK0gEiARVK0gAkEgaikDACARIAZUrSACQdAAaikDACAGIAdUrSAHIAhUrSACQdAEaikDACAIIANUrSACQZAEaikDACADIBVUrSACQdADaikDACACQZADaikDAHx8fHx8fCAEQhSIfHx8fHx8IBBCNIh8fCIEQgyGIAVCNIiEfCIDQv////////8HgzcD4AUgAiACKQPoBCIHIAIpA6gEfCIFIApCLIZ8IgggAyAJVK0gCSAPVK0gAkEQaikDACAPIA5UrSAOIA1UrSACQeAEaikDACANIBNUrSACQaAEaikDACACQeADaikDAHx8fHwgDEIUiHx8fHwgBEI0iHx8IgxCDIYgA0I0iIR8IgNC/////////weDNwPoBSACIAtCLIYiBiACKQP4BHwiBCADIAhUrSAIIAVUrSAFIAdUrSACQfAEaikDACACQbAEaikDAHx8IApCFIh8fCAMQjSIfHwiBUIMhiADQjSIhHwiA0L/////////B4M3A/AFIAIgAyAEVK0gBCAGVK0gAkGABWopAwAgC0IUiHx8IAVCNIh8fEIMhiADQjSIhDcD+AUgAkGwBWogAkHYBWpB+O7IABChASAAIAJBsAVqEHEgAkGABmokAAvkEAIBfx5+IwBBsAVrIgMkACADQfgBaiACKQMAIgkgASkDACIEEJ4CIANB6AFqIAMpA/gBIgxCm/zRkrG0xwJ+Qv////////8HgyIFQu2n1+el45gBEJ4CIANBiAJqIAIpAwgiDSAEEJ4CIANByAJqIAEpAwgiBiAJEJ4CIANB2AFqIAVCgcu1zvfF+gYQngIgA0HIAWogAykDyAIiDyADKQOIAnwiEyADKQPYAXwiDiAMIAMpA+gBIgp8IgxCNIggDCAKVK0gA0HwAWopAwAgA0GAAmopAwB8fCIRQgyGhHwiB0Kb/NGSsbTHAn5C/////////weDIgxC7afX56XjmAEQngIgA0GIA2ogBiANEJ4CIANBmAJqIAIpAxAiCiAEEJ4CIANB2AJqIAEpAxAiECAJEJ4CIANBmAFqIAVC+b3TABCeAiADQbgBaiAMQoHLtc73xfoGEJ4CIANBiAFqIAMpA5gCIhYgAykDiAN8IhQgAykD2AJ8IgggAykDmAF8IgsgAykDuAF8IhIgAykDyAEiFSAHfCIXQjSIIBcgFVStIANB0AFqKQMAIAcgDlStIA4gE1StIANB4AFqKQMAIBMgD1StIANB0AJqKQMAIANBkAJqKQMAfHx8fCARQjSIfHx8fCIYQgyGhHwiD0Kb/NGSsbTHAn5C/////////weDIhNC7afX56XjmAEQngIgA0HIA2ogCiAGEJ4CIANBmANqIBAgDRCeAiADQagCaiACKQMYIg4gBBCeAiADQegCaiABKQMYIgcgCRCeAiADQagBaiAMQvm90wAQngIgA0H4AGogE0KBy7XO98X6BhCeAiADQegAaiADKQOYAyIeIAMpA8gDfCIRIAMpA6gCfCIVIAMpA+gCfCIXIAMpA6gBfCIbIAMpA3h8IhwgAykDiAEiGSAPfCIaQjSIIBogGVStIANBkAFqKQMAIA8gElStIBIgC1StIANBwAFqKQMAIAsgCFStIANBoAFqKQMAIAggFFStIANB4AJqKQMAIBQgFlStIANBoAJqKQMAIANBkANqKQMAfHx8fHx8fHwgGEI0iHx8fHwiH0IMhoR8IgtCm/zRkrG0xwJ+Qv////////8HgyIUQu2n1+el45gBEJ4CIANB+ANqIBAgChCeAiADQdgDaiAOIAYQngIgA0GoA2ogByANEJ4CIANBuAJqIAIpAyAiCCAEEJ4CIANB+AJqIAEpAyAiBCAJEJ4CIANBOGogE0L5vdMAEJ4CIANB2ABqIBRCgcu1zvfF+gYQngIgA0EoaiADKQPYAyIgIAMpA/gDfCISIAVCLIZ8Ig8gAykDqAN8IhYgAykDuAJ8IhggAykD+AJ8IhkgAykDOHwiGiADKQNYfCIdIAMpA2giCSALfCIhQjSIICEgCVStIANB8ABqKQMAIAsgHFStIBwgG1StIANBgAFqKQMAIBsgF1StIANBsAFqKQMAIBcgFVStIANB8AJqKQMAIBUgEVStIANBsAJqKQMAIBEgHlStIANBoANqKQMAIANB0ANqKQMAfHx8fHx8fHx8fCAfQjSIfHx8fCIRQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIglC7afX56XjmAEQngIgA0GoBGogDiAQEJ4CIANBiARqIAcgChCeAiADQegDaiAIIAYQngIgA0G4A2ogBCANEJ4CIANByABqIBRC+b3TABCeAiADQRhqIAlCgcu1zvfF+gYQngIgA0HIBGogByAOEJ4CIANBuARqIAggEBCeAiADQZgEaiAEIAoQngIgA0EIaiAJQvm90wAQngIgA0HoBGogCCAHEJ4CIANB2ARqIAQgDhCeAiADQfgEaiAEIAgQngIgAyADKQOIBCIVIAMpA6gEfCIEIAMpA+gDfCINIAMpA7gDfCIGIAxCLIZ8IgogAykDSHwiECADKQMYfCIOIAMpAygiByALfCIIQjSIIAggB1StIANBMGopAwAgCyAdVK0gHSAaVK0gA0HgAGopAwAgGiAZVK0gA0FAaykDACAZIBhUrSADQYADaikDACAYIBZUrSADQcACaikDACAWIA9UrSADQbADaikDACAPIBJUrSASICBUrSADQeADaikDACADQYAEaikDAHx8IAVCFIh8fHx8fHx8fHx8fHwgEUI0iHx8fHwiD0IMhoR8IgVC/////////weDNwOIBSADIAMpA7gEIhEgAykDyAR8IgcgAykDmAR8IgggE0IshnwiCyADKQMIfCISIAUgDlStIA4gEFStIANBIGopAwAgECAKVK0gA0HQAGopAwAgCiAGVK0gBiANVK0gA0HAA2opAwAgDSAEVK0gA0HwA2opAwAgBCAVVK0gA0GQBGopAwAgA0GwBGopAwB8fHx8fHwgDEIUiHx8fHx8fCAPQjSIfHwiBkIMhiAFQjSIhHwiBEL/////////B4M3A5AFIAMgAykD2AQiDCADKQPoBHwiBSAUQiyGfCINIAQgElStIBIgC1StIANBEGopAwAgCyAIVK0gCCAHVK0gA0GgBGopAwAgByARVK0gA0HABGopAwAgA0HQBGopAwB8fHx8IBNCFIh8fHx8IAZCNIh8fCIKQgyGIARCNIiEfCIEQv////////8HgzcDmAUgAyAJQiyGIhAgAykD+AR8IgYgBCANVK0gDSAFVK0gBSAMVK0gA0HgBGopAwAgA0HwBGopAwB8fCAUQhSIfHwgCkI0iHx8IgVCDIYgBEI0iIR8IgRC/////////weDNwOgBSADIAQgBlStIAYgEFStIANBgAVqKQMAIAlCFIh8fCAFQjSIfHxCDIYgBEI0iIQ3A6gFIAAgA0GIBWpBgLzEABCgASADQbAFaiQAC+QQAgF/Hn4jAEGwBWsiAyQAIANB+AFqIAIpAwAiCSABKQMAIgQQngIgA0HoAWogAykD+AEiDEKb/NGSsbTHAn5C/////////weDIgVC7afX56XjmAEQngIgA0GIAmogAikDCCINIAQQngIgA0HIAmogASkDCCIGIAkQngIgA0HYAWogBUKBy7XO98X6BhCeAiADQcgBaiADKQPIAiIPIAMpA4gCfCITIAMpA9gBfCIOIAwgAykD6AEiCnwiDEI0iCAMIApUrSADQfABaikDACADQYACaikDAHx8IhFCDIaEfCIHQpv80ZKxtMcCfkL/////////B4MiDELtp9fnpeOYARCeAiADQYgDaiAGIA0QngIgA0GYAmogAikDECIKIAQQngIgA0HYAmogASkDECIQIAkQngIgA0GYAWogBUL5vdMAEJ4CIANBuAFqIAxCgcu1zvfF+gYQngIgA0GIAWogAykDmAIiFiADKQOIA3wiFCADKQPYAnwiCCADKQOYAXwiCyADKQO4AXwiEiADKQPIASIVIAd8IhdCNIggFyAVVK0gA0HQAWopAwAgByAOVK0gDiATVK0gA0HgAWopAwAgEyAPVK0gA0HQAmopAwAgA0GQAmopAwB8fHx8IBFCNIh8fHx8IhhCDIaEfCIPQpv80ZKxtMcCfkL/////////B4MiE0Ltp9fnpeOYARCeAiADQcgDaiAKIAYQngIgA0GYA2ogECANEJ4CIANBqAJqIAIpAxgiDiAEEJ4CIANB6AJqIAEpAxgiByAJEJ4CIANBqAFqIAxC+b3TABCeAiADQfgAaiATQoHLtc73xfoGEJ4CIANB6ABqIAMpA5gDIh4gAykDyAN8IhEgAykDqAJ8IhUgAykD6AJ8IhcgAykDqAF8IhsgAykDeHwiHCADKQOIASIZIA98IhpCNIggGiAZVK0gA0GQAWopAwAgDyASVK0gEiALVK0gA0HAAWopAwAgCyAIVK0gA0GgAWopAwAgCCAUVK0gA0HgAmopAwAgFCAWVK0gA0GgAmopAwAgA0GQA2opAwB8fHx8fHx8fCAYQjSIfHx8fCIfQgyGhHwiC0Kb/NGSsbTHAn5C/////////weDIhRC7afX56XjmAEQngIgA0H4A2ogECAKEJ4CIANB2ANqIA4gBhCeAiADQagDaiAHIA0QngIgA0G4AmogAikDICIIIAQQngIgA0H4AmogASkDICIEIAkQngIgA0E4aiATQvm90wAQngIgA0HYAGogFEKBy7XO98X6BhCeAiADQShqIAMpA9gDIiAgAykD+AN8IhIgBUIshnwiDyADKQOoA3wiFiADKQO4AnwiGCADKQP4AnwiGSADKQM4fCIaIAMpA1h8Ih0gAykDaCIJIAt8IiFCNIggISAJVK0gA0HwAGopAwAgCyAcVK0gHCAbVK0gA0GAAWopAwAgGyAXVK0gA0GwAWopAwAgFyAVVK0gA0HwAmopAwAgFSARVK0gA0GwAmopAwAgESAeVK0gA0GgA2opAwAgA0HQA2opAwB8fHx8fHx8fHx8IB9CNIh8fHx8IhFCDIaEfCILQpv80ZKxtMcCfkL/////////B4MiCULtp9fnpeOYARCeAiADQagEaiAOIBAQngIgA0GIBGogByAKEJ4CIANB6ANqIAggBhCeAiADQbgDaiAEIA0QngIgA0HIAGogFEL5vdMAEJ4CIANBGGogCUKBy7XO98X6BhCeAiADQcgEaiAHIA4QngIgA0G4BGogCCAQEJ4CIANBmARqIAQgChCeAiADQQhqIAlC+b3TABCeAiADQegEaiAIIAcQngIgA0HYBGogBCAOEJ4CIANB+ARqIAQgCBCeAiADIAMpA4gEIhUgAykDqAR8IgQgAykD6AN8Ig0gAykDuAN8IgYgDEIshnwiCiADKQNIfCIQIAMpAxh8Ig4gAykDKCIHIAt8IghCNIggCCAHVK0gA0EwaikDACALIB1UrSAdIBpUrSADQeAAaikDACAaIBlUrSADQUBrKQMAIBkgGFStIANBgANqKQMAIBggFlStIANBwAJqKQMAIBYgD1StIANBsANqKQMAIA8gElStIBIgIFStIANB4ANqKQMAIANBgARqKQMAfHwgBUIUiHx8fHx8fHx8fHx8fCARQjSIfHx8fCIPQgyGhHwiBUL/////////B4M3A4gFIAMgAykDuAQiESADKQPIBHwiByADKQOYBHwiCCATQiyGfCILIAMpAwh8IhIgBSAOVK0gDiAQVK0gA0EgaikDACAQIApUrSADQdAAaikDACAKIAZUrSAGIA1UrSADQcADaikDACANIARUrSADQfADaikDACAEIBVUrSADQZAEaikDACADQbAEaikDAHx8fHx8fCAMQhSIfHx8fHx8IA9CNIh8fCIGQgyGIAVCNIiEfCIEQv////////8HgzcDkAUgAyADKQPYBCIMIAMpA+gEfCIFIBRCLIZ8Ig0gBCASVK0gEiALVK0gA0EQaikDACALIAhUrSAIIAdUrSADQaAEaikDACAHIBFUrSADQcAEaikDACADQdAEaikDAHx8fHwgE0IUiHx8fHwgBkI0iHx8IgpCDIYgBEI0iIR8IgRC/////////weDNwOYBSADIAlCLIYiECADKQP4BHwiBiAEIA1UrSANIAVUrSAFIAxUrSADQeAEaikDACADQfAEaikDAHx8IBRCFIh8fCAKQjSIfHwiBUIMhiAEQjSIhHwiBEL/////////B4M3A6AFIAMgBCAGVK0gBiAQVK0gA0GABWopAwAgCUIUiHx8IAVCNIh8fEIMhiAEQjSIhDcDqAUgACADQYgFakHY7cgAEKEBIANBsAVqJAALphIBDH8jAEGAAmsiAiQAAn8gAC0AHARAIABBDGooAgAhCCACQfABakEEciENIAAoAhghCyAAKAIIIQkDQAJAAkAgByALRg0AIAdBAWohCiAJIQUgCCEGAkADQCACIAU2AvABIAIgBSAGajYC9AEgAkHwAWoQkAEiA0GAgMQARg0BIANBUGpBCkkEQCACIAUgBkEBEP4BIAIoAgQhBiACKAIAIQUMAQsLIAJB6AFqIAkgCCAIIAZrENoCIAJB8AFqIAIoAugBIAIoAuwBELYBIAItAPABQQFHBEAgAkHgAWogBSAGIAIoAvQBIgMQ/gEgAigC5AEhCCACKALgASEJIAJB2AFqIAUgBiADENoCIAIoAtwBIQMgAigC2AEhBCABELMFRSAKIAtHcg0DIAQgA0HoABDdA0UNAyACQdABaiAEIANBARD+ASACIAIoAtABIgU2AvABIAIgBSACKALUAWo2AvQBA0AgAkHwAWoQkAEiBUGAgMQARg0DAkAgBUFQaiIGQQpJDQAgBUGff2pBGk8EQCAFQb9/akEaTw0GIAVBSWohBgwBCyAFQal/aiEGCyAGQRBJDQALDAMLIAIgAi0A8QE6AP8BQaOXygBBKyACQf8BakHQl8oAQeCYygAQqAIAC0H4lsoAQStB0JjKABDOAwALIAEgACgCECAAQRRqKAIAEIgFIAJBgAJqJAAPCwJAIAcEQCABQfCYygBBAhCIBQ0BCyAEIANB8pjKAEECEPsCBEAgAkHIAWogBCADQQEQ/gEgAigCyAEhBCACKALMASEDCwNAIANFBEAgCiEHDAMLIAQgA0EuEN0DRQRAIAQgA0EkEN0DRQRAIAIgBDYC9AEgAkEANgLwASACIAMgBGoiBjYC+AEgBCEFA0ACQCANEJABIgxBgIDEAEYEQCADIQcMAQsgAiACKALwASIHIAYgBWtqIAIoAvQBIgVqIAIoAvgBIgZrNgLwASAMQSRGDQAgDEEuRw0BCwsgAkHAAWogBCADIAcQ2gIgASACKALAASACKALEARCIBQ0DIAJBuAFqIAQgAyAHEP4BIAIoArwBIQMgAigCuAEhBAwCCwJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAAkACQAJAIAQgA0H1mMoAQQQQ+wJFBEAgBCADQfqYygBBBBD7Ag0BIAQgA0H/mMoAQQQQ+wINAiAEIANBhJnKAEEEEPsCDQMgBCADQYmZygBBBBD7Ag0EIAQgA0GOmcoAQQQQ+wINBSAEIANBk5nKAEEEEPsCDQYgBCADQZiZygBBAxD7Ag0HIAQgA0GcmcoAQQUQ+wINCCAEIANBopnKAEEFEPsCDQkgBCADQaiZygBBBRD7Ag0KIAQgA0GumcoAQQUQ+wINCyAEIANBtJnKAEEFEPsCDQwgBCADQbqZygBBBRD7Ag0NIAQgA0HAmcoAQQUQ+wINDiAEIANBxpnKAEEFEPsCDQ8gBCADQcyZygBBBRD7Ag0QIAQgA0HSmcoAQQUQ+wINESAEIANB2JnKAEEFEPsCDRIgBCADQd6ZygBBBRD7Ag0TIAohByABIAQgAxCIBUUNFwwWC0EBIAFB+ZjKAEEBEIgFDRgaIAJBGGogBCADQQQQ/gEgAigCHCEDIAIoAhghBAwUC0EBIAFB/pjKAEEBEIgFDRcaIAJBIGogBCADQQQQ/gEgAigCJCEDIAIoAiAhBAwTC0EBIAFBg5nKAEEBEIgFDRYaIAJBKGogBCADQQQQ/gEgAigCLCEDIAIoAighBAwSC0EBIAFBiJnKAEEBEIgFDRUaIAJBMGogBCADQQQQ/gEgAigCNCEDIAIoAjAhBAwRC0EBIAFBjZnKAEEBEIgFDRQaIAJBOGogBCADQQQQ/gEgAigCPCEDIAIoAjghBAwQC0EBIAFBkpnKAEEBEIgFDRMaIAJBQGsgBCADQQQQ/gEgAigCRCEDIAIoAkAhBAwPC0EBIAFBl5nKAEEBEIgFDRIaIAJByABqIAQgA0EEEP4BIAIoAkwhAyACKAJIIQQMDgtBASABQZuZygBBARCIBQ0RGiACQdAAaiAEIANBAxD+ASACKAJUIQMgAigCUCEEDA0LQQEgAUGhmcoAQQEQiAUNEBogAkHYAGogBCADQQUQ/gEgAigCXCEDIAIoAlghBAwMC0EBIAFBp5nKAEEBEIgFDQ8aIAJB4ABqIAQgA0EFEP4BIAIoAmQhAyACKAJgIQQMCwtBASABQa2ZygBBARCIBQ0OGiACQegAaiAEIANBBRD+ASACKAJsIQMgAigCaCEEDAoLQQEgAUGzmcoAQQEQiAUNDRogAkHwAGogBCADQQUQ/gEgAigCdCEDIAIoAnAhBAwJC0EBIAFBuZnKAEEBEIgFDQwaIAJB+ABqIAQgA0EFEP4BIAIoAnwhAyACKAJ4IQQMCAtBASABQb+ZygBBARCIBQ0LGiACQYABaiAEIANBBRD+ASACKAKEASEDIAIoAoABIQQMBwtBASABQcWZygBBARCIBQ0KGiACQYgBaiAEIANBBRD+ASACKAKMASEDIAIoAogBIQQMBgtBASABQcuZygBBARCIBQ0JGiACQZABaiAEIANBBRD+ASACKAKUASEDIAIoApABIQQMBQtBASABQdGZygBBARCIBQ0IGiACQZgBaiAEIANBBRD+ASACKAKcASEDIAIoApgBIQQMBAtBASABQdeZygBBARCIBQ0HGiACQaABaiAEIANBBRD+ASACKAKkASEDIAIoAqABIQQMAwtBASABQd2ZygBBARCIBQ0GGiACQagBaiAEIANBBRD+ASACKAKsASEDIAIoAqgBIQQMAgtBASABQeOZygBBARCIBQ0FGiACQbABaiAEIANBBRD+ASACKAK0ASEDIAIoArABIQQMAQsgAkEQaiAEIANBARD+ASACIAIoAhAiBzYC8AEgAiAHIAIoAhRqNgL0AQJAIAJB8AFqEJABQS5HBEBBASEFIAFB9JjKAEEBEIgFDQMMAQtBAiEFIAFB8JjKAEECEIgFDQILIAJBCGogBCADIAUQ/gEgAigCDCEDIAIoAgghBAwACwALC0EBDAELIAEgACgCACAAKAIEEIgFCyACQYACaiQAC9wOAgt/AX4jAEGQAWsiAyQAIANB0ABqIAEgAkHgl8oAQQYQIAJAIAMoAlBBAUcEQCADQdwAai0AACEGIANBhAFqKAIAIQggAygCVCEHIAMoAoABIQkCQANAAkAgA0EwaiAJIAggBxD+ASADIAMoAjAiBTYCOCADIAUgAygCNGo2AjwgBiIFRSEGIANBOGoQkAEhBCAFDQAgBEGAgMQARg0CAn9BASAEQYABSQ0AGkECIARBgBBJDQAaQQNBBCAEQYCABEkbCyAHaiEHDAELCyADQcgAaiAHNgIAIAMgBzYCVCADIAY6AFwgAyAHNgJEIANBATYCQAwCCyADIAc2AlQgAyAGOgBcIANBADYCQAwBCyADQdgAaiEFIANBjAFqKAIAIQYgA0GEAWooAgAhBCADKAKIASEIIAMoAoABIQcgA0H0AGooAgBBf0YEQCADQUBrIAUgByAEIAggBkEBEFQMAQsgA0FAayAFIAcgBCAIIAZBABBUCwJAIAMoAkBBAUcNACADQShqIAEgAiADKAJEIgZBBmoQ/gEgAyADKAIoIgUgAygCLGo2AlQgAyAFNgJQA0AgA0HQAGoQkAEiBUGAgMQARwRAIAVBwABGIAVBv39qQQZJciAFQVBqQQpJcg0BDAILCyADQSBqIAEgAiAGENoCIAMoAiQhAiADKAIgIQELIANB0ABqIAEgAkHml8oAQQIQIAJAIAMoAlBBAUcEQCADQYQBaigCACELIANB2ABqKAIAIQcgA0HdAGotAAAhBiADKAKAASEMAkADQCADIAYiBUUiBjoAXSADQRhqIAwgCyAHENoCQYCAxAAhBAJAIAMoAhwiCUUNACAJIAMoAhgiCGoiCUF/aiIKLQAAIgRBGHRBGHUiDUEATg0AIA1BP3ECf0EAIAggCkYNABogCUF+aiIKLQAAIgRBwAFxQYABRwRAIARBH3EMAQsgBEE/cQJ/QQAgCCAKRg0AGiAJQX1qIgotAAAiBEHAAXFBgAFHBEAgBEEPcQwBCyAIIApGBH9BAAUgCUF8ai0AAEEHcUEGdAsgBEE/cXILQQZ0cgtBBnRyIQQLIAVFBEAgBEGAgMQARg0CIAMgBwJ/QQEgBEGAAUkNABpBAiAEQYAQSQ0AGkEDQQQgBEGAgARJGwtrIgc2AlgMAQsLIANByABqIAc2AgAgAyAHNgJEIANBATYCQAwCCyADQQA2AkAMAQsgA0HYAGohBSADQYwBaigCACEGIANBhAFqKAIAIQQgAygCiAEhCCADKAKAASEHIANB9ABqKAIAQX9GBEAgA0FAayAFIAcgBCAIIAZBARBMDAELIANBQGsgBSAHIAQgCCAGQQAQTAsgAwJ/AkACQAJAIAMoAkBBAUYEQCADKAJEIgZBAWoiBSAGSSACIAVGckUEQCACIAVNDQMgASAFaiwAAEG/f0wNAwsgAyABIAJqNgJUIAMgASAFaiIMNgJQIAIgBWshCgNAIANB0ABqEJABIgZBgIDEAEYEQCAFIQIMAwsgBkFfakEPSSAGQVBqQQpJciAGQd///wBxQb9/akEaSSAGQUZqQQdJcnIgBkGlf2pBBkkgBkGFf2pBBElycg0ACwtB5pfKACEMQQAhCgsCQCACQQRLBEAgASACQeiXygBBAxD7AkUNASABIAIQ3gNFDQEgAyABIAJBAyACQX9qEMsBQQEhBCADKAIEIQUgAygCAAwEC0EAIQQgAiEFIAEgAkEERw0DGgsgASACQeuXygBBAhD7AkUNASABIAIQ3gNFDQEgA0EIaiABIAJBAiACQX9qEMsBQQEhBCADKAIMIQUgAygCCAwCCyABIAJBACAFECkAC0EAIQQCQCACQQVNDQAgASACQe2XygBBBBD7AkUNACACIQUgASABIAIQ3gNFDQEaIANBEGogASACQQQgAkF/ahDLAUEBIQQgAygCFCEFIAMoAhAMAQsgAiEFIAELIgs2AlAgAyAFIAtqIgY2AlQgA0HQAGoQxQMhCEEAIQ0CQCAERQRAQQAhCQwBC0EAIQkgCA0AIANBgYDEADYCWCADIAY2AlQgAyALNgJQQQEhBANAIARBAXFFDQFBACEEAkACQAJAA0AgBCEIIAMoAlgiBEGBgMQARgRAIAMgA0HQAGoQkAEiBDYCWAtBASEGIARBgIDEAEYNASAEQVBqIgRBCUsNASADQdAAahDsBBogCK1CCn4iDkIgiKcEQEEAIQYMAwsgDqciBiAEaiIEIAZPDQALQQAhBgsgCEUNAQsgAyAINgJEIAhBf2ohBCADIANB0ABqNgJAQQAhBwNAIANBQGsQgAFBgIDEAEcEQCAHQQFqIQcgAyAENgJEIARBf2oiBEF/Rw0BCwsgCSAHIAhGIgRqIQkgBCAGcSEEDAELCyADQdAAahDsBEGAgMQARiENCyAAIA06ABwgACAMNgIQIAAgCzYCCCAAIAI2AgQgACABNgIAIAAgCTYCGCAAQRRqIAo2AgAgAEEMaiAFNgIAIANBkAFqJAALiA8BCX8jAEGQEWsiBSQAIAUgBDYCvAEgBSADNgK4ASAFQbABaiAFQbgBakEHEKYFIAVBtAtqQQE2AgAgBUIBNwKkCyAFQcD6wQA2AqALIAUgBSkDsAE3A/AGIAUgBUHwBmo2ArALIAVBwAFqIAVBoAtqEGYgBUGgC2ogASACEKwBIAVB0AFqIAVBoAtqQcj6wQAQ6wIgBUHoAWpBAEHAABDBBBogBUGoAWogBUHQAWoQsAQgBSgCqAEhASAFKAKsASECIAVBoAFqIAVBwAFqEJsFIAUoAqQBIQsgBSgCoAEhDCAFQagCahCyAyAFQdAPahDaASAFQfAGahCyAyAFQaALaiAFQagCakHYARDyAxogBUHQDmogBUHQD2pBgAEQ8gMhAyAFQfgMaiAFQfAGakHYARDyAyAFQdAPahDZASAFQZgBaiADEKoFAkACQAJAAkACQCAFKAKcASACSQRAIAVBqAJqELIDIAVBqAJqIAEgAhDRBSAFQfAGaiAFQagCakHYARDyAxogBUHQEGogBUHwBmoQ7gMgBUGAAWogBUHQEGoQqQUgBSgChAEhASAFQfgAaiADEKoFIAVB8ABqQQAgBSgCfCICIAEgASACSxsQpgUgBSAFKQNwNwPwBgNAIAVB6ABqIAVB8AZqELkDIAUoAmhFDQYgBSgCbCEBIAVB4ABqIAVB0BBqEKkFIAEgBSgCZCICTw0CIAUoAmAgAWotAAAhAiAFQdgAaiADEKoFIAEgBSgCXCIGTw0DIAUoAlggAWoiBiAGLQAAIAJzOgAAIAVB0ABqIAVB0BBqEKkFIAEgBSgCVCICTw0EIAUoAlAgAWotAAAhAiAFQcgAaiAFQdAPahCqBSABIAUoAkwiBk8NBSAFKAJIIAFqIgEgAS0AACACczoAAAwACwALIAVB8AZqIAEgASACahCLBSAFQagCaiAFQfAGahD5BCAFKAKwAiEBIAUoAqwCIQYgBSgCqAIhAgJAA0AgAiAGRg0GIAItAAAhCCAFQZABaiADEKoFIAEgBSgClAEiB0kEQCAFKAKQASABaiIHIActAAAgCHM6AAAgAi0AACEIIAVBiAFqIAVB0A9qEKoFIAEgBSgCjAEiB08NAiACQQFqIQIgBSgCiAEgAWoiByAHLQAAIAhzOgAAIAFBAWohAQwBCwtBwPjBACABIAcQ5AIAC0HQ+MEAIAEgBxDkAgALQeD4wQAgASACEOQCAAtB8PjBACABIAYQ5AIAC0GA+cEAIAEgAhDkAgALQZD5wQAgASAGEOQCAAsgBUGgC2ogAxCxBCAFQdAPahCxBCAFQagCaiAFQaALakGwBBDyAxogBULAgICAgAg3AvQGIAUgBUHoAWo2AvAGIAVBoAtqIAVB8AZqEOsEIAVB2AZqIAVBoAtqEPgEIAVBqAtqIQcgBUHYD2ohCCAFKALkBiEEIAUoAuAGIQogBSgC3AYhBiAFKALYBiECA0ACQCAGRSACRXJFBEAgBEEBaiEEIAYgCiAGIAYgCksbIgFrIQYgBUFAayACIAEgAmoiAxCmBSAFKAJEIQkgBSgCQCEBA0AgASAJRgRAIAVB8AZqIAVBqAJqEIIDIAVB8AZqIAwgCxDRBSAFIARBCHRBgID8B3EgBEEYdHIgBEEIdkGA/gNxIARBGHZycjYC6AYgBUHwBmogBUHoBmpBBBDRBSAFQaALaiAFQfAGakGwBBDyAxogBUHQD2ogBUGgC2oQvgIgBUGgC2ogBUHQD2oQuQUgBUE4aiAFQaALahCpBSAFQTBqIAUoAjgiASABIAUoAjxqEKYFIAVB0BBqIAIgAyAFKAIwIAUoAjQQywMgBUHgD2oiDSAFQeAQaikDADcDACAIIAVB2BBqKQMANwMAIAUgBSkD0BA3A9APA0AgBSgC4A8iASAFKALkD08EQCAFQdAQaiAFQaALakHAABDyAxogBUEoakEBQYAQEKYFIAUgBSkDKDcD6AYDQCAFQSBqIAVB6AZqELkDIAUoAiBFDQYgBUHwBmogBUGoAmoQggMgBUEYaiAFQdAQahCpBSAFQfAGaiAFKAIYIAUoAhwQ0QUgBUGgC2ogBUHwBmpBsAQQ8gMaIAVB0A9qIAVBoAtqEL4CIAVBoAtqIAVB0A9qELkFIAVB0BBqIAVBoAtqQcAAEPIDGiAFQRBqIAVB0BBqEKkFIAVBCGogBSgCECIBIAEgBSgCFGoQpgUgBUHQD2ogAiADIAUoAgggBSgCDBDLAyAFQbALaiANKQMANwMAIAcgCCkDADcDACAFIAUpA9APNwOgCwNAIAUoArALIgEgBSgCtAtPBEAMAgUgBSABQQFqNgKwCyAFQaALaiABEMwFIQkgByABEMwFIQEgCSAJLQAAIAEtAABzOgAADAELAAsACwAFIAUgAUEBajYC4A8gBUHQD2ogARDMBSEJIAggARDMBSEBIAkgCS0AACABLQAAczoAAAwBCwALAAUgAUEAOgAAIAFBAWohAQwBCwALAAsgACAFQegBakEgEJwDIAVB0AFqEKMFIAVBwAFqEIEFIAVBkBFqJAAPCyADIQIMAAsAC60NAQl/IwBBwBBrIgYkACAGQZgBakEAQcAAEMEEGiAGQdgBahCyAyAGQYAPahDaASAGQaAGahCyAyAGQdAKaiAGQdgBakHYARDyAxogBkGADmogBkGAD2pBgAEQ8gMhCSAGQagMaiAGQaAGakHYARDyAyAGQYAPahDZASAGQZABaiAJEKoFAkACQAJAAkACQCAGKAKUASACSQRAIAZB2AFqELIDIAZB2AFqIAEgAhDRBSAGQaAGaiAGQdgBakHYARDyAxogBkGAEGogBkGgBmoQ7gMgBkH4AGogBkGAEGoQqQUgBigCfCEBIAZB8ABqIAkQqgUgBkHoAGpBACAGKAJ0IgIgASABIAJLGxCmBSAGIAYpA2g3A6AGA0AgBkHgAGogBkGgBmoQuQMgBigCYEUNBiAGKAJkIQEgBkHYAGogBkGAEGoQqQUgASAGKAJcIgJPDQIgBigCWCABai0AACECIAZB0ABqIAkQqgUgASAGKAJUIgdPDQMgBigCUCABaiIHIActAAAgAnM6AAAgBkHIAGogBkGAEGoQqQUgASAGKAJMIgJPDQQgBigCSCABai0AACECIAZBQGsgBkGAD2oQqgUgASAGKAJEIgdPDQUgBigCQCABaiIBIAEtAAAgAnM6AAAMAAsACyAGQaAGaiABIAEgAmoQiwUgBkHYAWogBkGgBmoQ+QQgBigC4AEhAiAGKALcASEHIAYoAtgBIQECQANAIAEgB0YNBiABLQAAIQsgBkGIAWogCRCqBSACIAYoAowBIghJBEAgBigCiAEgAmoiCCAILQAAIAtzOgAAIAEtAAAhCyAGQYABaiAGQYAPahCqBSACIAYoAoQBIghPDQIgAUEBaiEBIAYoAoABIAJqIgggCC0AACALczoAACACQQFqIQIMAQsLQfyEwAAgAiAIEOQCAAtBjIXAACACIAgQ5AIAC0GchcAAIAEgAhDkAgALQayFwAAgASAHEOQCAAtBvIXAACABIAIQ5AIAC0HMhcAAIAEgBxDkAgALIAZB0ApqIAkQsQQgBkGAD2oQsQQgBkHYAWogBkHQCmpBsAQQ8gMaIAZCwICAgIAINwKkBiAGIAZBmAFqNgKgBiAGQdAKaiAGQaAGahDrBCAGQYgGaiAGQdAKahD4BCAGQdgKaiEIIAZBiA9qIQsgBigClAYhCiAGKAKQBiENIAYoAowGIQcgBigCiAYhAQNAAkAgB0UgAUVyRQRAIApBAWohCiAHIA0gByAHIA1LGyICayEHIAZBOGogASABIAJqIgkQpgUgBigCPCEMIAYoAjghAgNAIAIgDEYEQCAGQaAGaiAGQdgBahCCAyAGQaAGaiADIAQQ0QUgBiAKQQh0QYCA/AdxIApBGHRyIApBCHZBgP4DcSAKQRh2cnI2ApgGIAZBoAZqIAZBmAZqQQQQ0QUgBkHQCmogBkGgBmpBsAQQ8gMaIAZBgA9qIAZB0ApqEL4CIAZB0ApqIAZBgA9qELkFIAZBMGogBkHQCmoQqQUgBkEoaiAGKAIwIgIgAiAGKAI0ahCmBSAGQYAQaiABIAkgBigCKCAGKAIsEMsDIAZBkA9qIg4gBkGQEGopAwA3AwAgCyAGQYgQaikDADcDACAGIAYpA4AQNwOADwNAIAYoApAPIgIgBigClA9PBEAgBkGAEGogBkHQCmpBwAAQ8gMaIAZBIGpBASAFEKYFIAYgBikDIDcDmAYDQCAGQRhqIAZBmAZqELkDIAYoAhhFDQYgBkGgBmogBkHYAWoQggMgBkEQaiAGQYAQahCpBSAGQaAGaiAGKAIQIAYoAhQQ0QUgBkHQCmogBkGgBmpBsAQQ8gMaIAZBgA9qIAZB0ApqEL4CIAZB0ApqIAZBgA9qELkFIAZBgBBqIAZB0ApqQcAAEPIDGiAGQQhqIAZBgBBqEKkFIAYgBigCCCICIAIgBigCDGoQpgUgBkGAD2ogASAJIAYoAgAgBigCBBDLAyAGQeAKaiAOKQMANwMAIAggCykDADcDACAGIAYpA4APNwPQCgNAIAYoAuAKIgIgBigC5ApPBEAMAgUgBiACQQFqNgLgCiAGQdAKaiACEMwFIQwgCCACEMwFIQIgDCAMLQAAIAItAABzOgAADAELAAsACwAFIAYgAkEBajYCkA8gBkGAD2ogAhDMBSEMIAsgAhDMBSECIAwgDC0AACACLQAAczoAAAwBCwALAAUgAkEAOgAAIAJBAWohAgwBCwALAAsgACAGQZgBakHAABCcAyAGQcAQaiQADwsgCSEBDAALAAvHCwINfwJ+IwBBMGsiBiQAAkACQAJAAkAgAUEdai0AACIEIAFBHmotAAAiC0sgBEEDRnIgC0EDRnINACABQQhqIQwgAUEdaiEJAkACQAJAAkADQAJAAkACQAJAAkACQAJAIARBAWsOAwIDAAELQbCdygBBKEHoocoAELwEAAsgDC0AACIHQQZGBEBBASEEIAlBAToAAAwECwJAAn8CQAJAAkACQAJAQQAgDCAHQQZGGyIDLQAAIghBAWsOBQADAgEDBAsgAygCCCADKAIQIgRBAWpBACAEG2pBCGoMBAsgAygCCCADKAIQIgRBAWpBACAEG2pBAmoMAwsgAygCCEEEagwCCyABQR1qQQE6AAAMAgsgAygCCEEEagtBASEEIAlBAToAAEUNBAsgASgCBCEFIAEoAgAhCUECIQQCQAJAAkACQAJAAkAgCEEBaw4FAQIEAwUACyADKAIIQQRqIQQMBAsgAygCCCADKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAygCCCADKAIQIgRBAWpBACAEG2pBAmohBAwBCyADKAIIQQRqIQQLIAUgBEkNBEECIQICQAJAAkACQAJAAkAgCEEBaw4FAQIEAwUACyADKAIIQQRqIQIMBAsgAygCCCADKAIQIgJBAWpBACACG2pBCGohAgwDC0EGIQIMAgsgAygCCCADKAIQIgJBAWpBACACG2pBAmohAgwBCyADKAIIQQRqIQILIAUgAkkNBiABIAUgAms2AgQgASACIAlqNgIAIAZBJ2oiAiABQRhqKAAANgAAIAZBIGoiAyABQRFqKQAANwMAIAZBD2oiBSACKAAANgAAIAZBCGoiAiADKQMANwMAIAYgAUEJaikAACIPNwMAIABBDGogBzoAACAAQQhqIAQ2AgAgACAJNgIEIABBADYCACAAIA83AA0gAEEVaiACKQMANwAAIABBHGogBSgAADYAAAwNCyAJQQI6AAACQAJAIAEtABxFBEAgAS0ACCIEQQZHDQJBAiEEIAEoAgQiAkUNBSABKAIAIgMtAAAhBSADQQFqIgggAyACGyIHIAIgA2oiA0YgBUEuR3INASAHLQAAQS9HDQUMDgsgASgCBCIERQ0IIABBATYCACABIARBf2o2AgQgASABKAIAQQFqNgIADA4LIAMgB0cNAyAFQS5GDQwMAwsgBEEDakEHcSICQQZJDQEMCgsgASgCBCIDBEAgASgCACEHQQAhCEEAIQUCQANAIAMgBUYEQCADIQIMAgsgBSAHaiAFQQFqIQUtAAAiCkEvRw0AC0EBIQggAyAKQS9GQQFqQQFxIAVqQX9qIgJJDQgLIAIgCGohCEEEIQUCQCACQQJLDQACQAJAAkAgAkEBaw4CAAECCyAHQdChygBHBEAgBy0AAEEuRw0DC0ECQQVBAiABLQAIIgVBA0kgBUEGRhsiBUEBcRtBBSAFQQJHGyEFDAILIAdB46HKAEcEQCAHLwAAQa7cAEcNAgtBAyEFDAELQQUhBQsgBkEQaiAGQShqIgooAgAiDTYCACAGQQhqIAZBIGoiDikCACIPNwMAIAYgBikCGCIQNwMAIAogDTYCACAOIA83AwAgBiAQNwMYIAMgCEkNCCABIAMgCGs2AgQgASAHIAhqNgIAIAVBBUYNAiAAIAc2AgQgACAFNgIAIABBCGogAjYCACAAQQxqIAYpAxg3AgAgAEEUaiAGQSBqKQMANwIAIABBHGogBkEoaigCADYCAAwMCyABQR1qQQM6AAAMCAtBAiEEQTkgAnZBAXFFDQgLIAQiAiALSw0GIAJBA0cNAQwGCwsgBCAFEOUCAAsgAiAFEOYCAAtBAUEAEOYCAAsgCkEvRkEBakEBcSAFakF/aiADEOUCAAsgCCADEOYCAAsgAEEFNgIADAILIABBATYCAAwBCyABIAg2AgAgAEECNgIAIAEgAkF/ajYCBAsgBkEwaiQAC9ELAgR/An4jAEGQCGsiBiQAAn8CfwJAIAFBwABGBEAgBkHYBWpCADcDACAGQdAFakIANwMAIAZByAVqQgA3AwAgBkIANwPABSAGQegCakIANwMAIAZB4AJqIgdCADcDACAGQdgCaiIIQgA3AwAgBkIANwPQAiAGQcAFakEgIABBIBCuASAGQdACakEgIABBIGpBIBCuASAGQb8EaiIAIAZB5wJqKQAANwAAIAZBuARqIgEgBykDADcDACAGQbAEaiIHIAgpAwA3AwAgBiAGKQPQAjcDqAQgBi0A7wIiCEEQSQ0BIAZBxwJqIAApAAA3AAAgBkHAAmogASkDADcDACAGQbgCaiAHKQMANwMAIAYgBikDqAQ3A7ACIAYgCDoAzwIgBkHoAGogBkGwAmoQzQEgBi0AaEEBRgRAIAZBrgJqIAYtAGs6AAAgBiAGLwBpOwGsAiAGIAZB/ABqKQIANwOIBCAGIAZBgQFqKQAANwCNBCAGQfQAaigCACEBIAZB+ABqKAIAIQAgBigCbCEHIAZB8ABqKAIADAMLIAZB4ABqIAZBkARqKQIANwMAIAYgBikCiAQ3A1gLQQAMAgsgBkH/AGogACkAADcAACAGQfgAaiABKQMANwMAIAZB8ABqIAcpAwA3AwAgBiAGKQOoBDcDaCAGIAg6AIcBIAZB2AZqIAZB6ABqELsDIAZBrgJqIAYtANoGOgAAIAYgBi8B2AY7AawCIAYgBikA6wY3A4gEIAYgBkHwBmopAAA3AI0EIAYoANsGIQcgBigA4wYhASAGKADnBiEAIAYoAN8GCyEIIAZBqgJqIgkgBkGuAmotAAA6AAAgBiAGLwGsAjsBqAIgBiAGKQOIBDcDSCAGIAYpAI0ENwBNIAYgBi8BwAU7AQggBiAGLQDCBToACiAGKQDDBSEKIAYpAMsFIQsgBiAGQdgFaikAADcAbSAGIAYpANMFNwNoIAZB9wBqIAktAAA6AAAgBiAGLwGoAjsAdSAGQeAAaiIJIAZB8ABqKQMANwMAIAYgBikDaDcDWCAGIAs3ABMgBiAKNwALIAZBI2ogCSkDADcAACAGIAYpA1g3ABsgBkE3aiAANgAAIAZBM2ogATYAACAGQS9qIAg2AAAgBkEraiAHNgAAIAZBQGsgBikATTcAACAGQTtqIAYpA0g3AAACQCAFQSBGBEAgBkHIAmoiAEIANwMAIAZBwAJqIgFCADcDACAGQbgCaiIFQgA3AwAgBkIANwOwAiAGQbACakEgIARBIBCuASAGQaAEaiAAKQMANwMAIAZBmARqIgAgASkDADcDACAGQZAEaiAFKQMANwMAIAYgBikDsAI3A4gEIAZB6ABqIAZBiARqEGwgBikDaEIBUQ0BIAZB6AZqIgAgBkHgAmoiASkCADcDACAGQeAGaiAGQdgCaiICKQIANwMAIAYgBikC0AI3A9gGIAZBwAVqIAZB2AZqQZQBEPIDGiAGQfgAaiAGKQLABTcDACAGQYABaiAGQcgFaikCADcDACAGQYgBaiAGQdAFaikCADcDACAGQQA2AmggBkHYBmogBkHoAGpBKBDyAxogAiAGQfAGaikDADcDACABIAZB+AZqKQMANwMAIAYgACkDADcD0AILQdD8wQBBH0Hw/MEAELQEAAsgBkH4AGooAgAhASAGKQNwIQogBkHYBmogBkH8AGpBlAEQ8gMaIAZBwAVqIAZB2AZqQZQBEPIDGiAGQagEaiAGQcAFakGUARDyAxogBkHYBmogBkGoBGpBlAEQ8gMaIAZBhAhqIAZBoARqKQMANwIAIAZB/AdqIAApAwA3AgAgBkH0B2ogBkGQBGopAwA3AgAgBiAGKQOIBDcC7AcgBkHQAmogBkHYBmpBtAEQ8gMaIAYgATYCcCAGIAo3A2ggBkH0AGogBkHQAmpBtAEQ8gMaIAZB2AZqIAZB6ABqIAIgAyAGQQhqELwBIAYoAtgGQQVGCyAGQZAIaiQAC6AJAgF/D34jAEGQA2siAyQAIANBEGogASkDACIEIAIpAwgiBhCeAiADQaABaiABKQMgIgcgAikDECILQhN+IhAQngIgA0HgAWogASkDGCIIIAIpAxgiDUITfiIOEJ4CIANBoAJqIAEpAxAiBSACKQMgIg9CE34iDBCeAiADQdAAaiABKQMIIgkgAikDACIKEJ4CIAMgCiAEEJ4CIANBkAFqIAcgBkITfhCeAiADQdABaiAIIBAQngIgA0GQAmogBSAOEJ4CIANB0AJqIAkgDBCeAiADQSBqIAQgCxCeAiADQbABaiAHIA4QngIgA0HwAWogCCAMEJ4CIANB4ABqIAUgChCeAiADQeACaiAJIAYQngIgA0EwaiAEIA0QngIgA0HAAWogByAMEJ4CIANB8ABqIAggChCeAiADQbACaiAFIAYQngIgA0HwAmogCSALEJ4CIANBQGsgBCAPEJ4CIANBgAFqIAcgChCeAiADQYACaiAIIAYQngIgA0HAAmogBSALEJ4CIANBgANqIAkgDRCeAiAAIAMpA7ABIg8gAykDIHwiBCADKQPwAXwiBiADKQNgfCIHIAMpA+ACfCIIIAMpA6ABIhEgAykDEHwiBSADKQPgAXwiCSADKQOgAnwiCiADKQNQfCILIAMpA5ABIhIgAykDAHwiDCADKQPQAXwiDSADKQOQAnwiDiADKQPQAnwiEEIziCAQIA5UrSADQdgCaikDACAOIA1UrSADQZgCaikDACANIAxUrSADQdgBaikDACAMIBJUrSADQZgBaikDACADQQhqKQMAfHx8fHx8fHxCDYaEfCIMQjOIIAwgC1StIAsgClStIANB2ABqKQMAIAogCVStIANBqAJqKQMAIAkgBVStIANB6AFqKQMAIAUgEVStIANBqAFqKQMAIANBGGopAwB8fHx8fHx8fHxCDYaEfCIFQv////////8DgzcDECAAIAMpA8ABIg4gAykDMHwiCSADKQNwfCIKIAMpA7ACfCILIAMpA/ACfCINIAUgCFStIAggB1StIANB6AJqKQMAIAcgBlStIANB6ABqKQMAIAYgBFStIANB+AFqKQMAIAQgD1StIANBuAFqKQMAIANBKGopAwB8fHx8fHx8fHxCDYYgBUIziIR8IgRC/////////wODNwMYIAAgAykDgAEiDyADKQNAfCIGIAMpA4ACfCIHIAMpA8ACfCIIIAMpA4ADfCIFIAQgDVStIA0gC1StIANB+AJqKQMAIAsgClStIANBuAJqKQMAIAogCVStIANB+ABqKQMAIAkgDlStIANByAFqKQMAIANBOGopAwB8fHx8fHx8fHxCDYYgBEIziIR8IgRC/////////wODNwMgIAAgBCAFVK0gBSAIVK0gA0GIA2opAwAgCCAHVK0gA0HIAmopAwAgByAGVK0gA0GIAmopAwAgBiAPVK0gA0GIAWopAwAgA0HIAGopAwB8fHx8fHx8fHxCDYYgBEIziIRCE34gEEL/////////A4N8IgRC/////////wODNwMAIAAgDEL/////////A4MgBEIziHw3AwggA0GQA2okAAugCwEJfyMAQYAQayIFJAAgBUGYAWpBwAAQtQIgBUGQAWogBUGYAWoQmwUgBSgClAEhCyAFKAKQASEJIAVBqAFqELIDIAVBwA5qENoBIAVB4AVqELIDIAVBkApqIAVBqAFqQdgBEPIDGiAFQcANaiAFQcAOakGAARDyAyEHIAVB6AtqIAVB4AVqQdgBEPIDIAVBwA5qENkBIAVBiAFqIAcQqgUCQAJAAkACQAJAIAUoAowBIAJJBEAgBUGoAWoQsgMgBUGoAWogASACENEFIAVB4AVqIAVBqAFqQdgBEPIDGiAFQcAPaiAFQeAFahDuAyAFQfAAaiAFQcAPahCpBSAFKAJ0IQEgBUHoAGogBxCqBSAFQeAAakEAIAUoAmwiAiABIAEgAksbEKYFIAUgBSkDYDcD4AUDQCAFQdgAaiAFQeAFahC5AyAFKAJYRQ0GIAUoAlwhASAFQdAAaiAFQcAPahCpBSABIAUoAlQiAk8NAiAFKAJQIAFqLQAAIQIgBUHIAGogBxCqBSABIAUoAkwiBk8NAyAFKAJIIAFqIgYgBi0AACACczoAACAFQUBrIAVBwA9qEKkFIAEgBSgCRCICTw0EIAUoAkAgAWotAAAhAiAFQThqIAVBwA5qEKoFIAEgBSgCPCIGTw0FIAUoAjggAWoiASABLQAAIAJzOgAADAALAAsCQANAIAIgBkYNBiABIAZqIgotAAAhCCAFQYABaiAHEKoFIAYgBSgChAEiDUkEQCAFKAKAASAGaiINIA0tAAAgCHM6AAAgCi0AACEKIAVB+ABqIAVBwA5qEKoFIAYgBSgCfCIITw0CIAUoAnggBmoiCCAILQAAIApzOgAAIAZBAWohBgwBCwtB3PLIACAGIA0Q5AIAC0Hs8sgAIAYgCBDkAgALQfzyyAAgASACEOQCAAtBjPPIACABIAYQ5AIAC0Gc88gAIAEgAhDkAgALQazzyAAgASAGEOQCAAsgBUGQCmogBxCxBCAFQcAOahCxBCAFQagBaiAFQZAKakGwBBDyAxpBACECA0ACQCALRSAJRXJFBEAgAkEBaiECIAsgC0HAACALQcAASRsiBmshCyAGIAlqIQEgCSEHA0AgBgRAIAdBADoAACAGQX9qIQYgB0EBaiEHDAEFAkAgBUHgBWogBUGoAWoQhAMgBUHgBWogAyAEENEFIAUgAkEIdEGAgPwHcSACQRh0ciACQQh2QYD+A3EgAkEYdnJyNgLYBSAFQeAFaiAFQdgFakEEENEFIAVBkApqIAVB4AVqQbAEEPIDGiAFQcAOaiAFQZAKahCAAyAFQZAKaiAFQcAOakHAABDyAxogBUEwaiAFQZAKahCpBSAFQShqIAUoAjAiByAHIAUoAjRqEKYFIAUoAiwgBSgCKCIMayIGIAEgCWsiByAHIAZLGyEKQQAhBgNAIAYgCk8NASAGIAlqIgggCC0AACAGIAxqLQAAczoAACAGQQFqIQYMAAsACwsLIAVBwA9qIAVBkApqQcAAEPIDGiAFQSBqQQFBgBAQpgUgBSAFKQMgNwPYBQNAIAVBGGogBUHYBWoQuQMgBSgCGEUNAiAFQeAFaiAFQagBahCEAyAFQRBqIAVBwA9qEKkFIAVB4AVqIAUoAhAgBSgCFBDRBSAFQZAKaiAFQeAFakGwBBDyAxogBUHADmogBUGQCmoQgAMgBUHAD2ogBUHADmpBwAAQ8gMaIAVBCGogBUHAD2oQqQUgBSAFKAIIIgYgBiAFKAIMahCmBSAFKAIEIAUoAgAiDGsiBiAHIAcgBksbIQpBACEGA0AgBiAKTw0BIAYgCWoiCCAILQAAIAYgDGotAABzOgAAIAZBAWohBgwACwALAAsgACAFKQOYATcCACAAQQhqIAVBoAFqKAIANgIAIAVBgBBqJAAPCyABIQkMAAsAC/QJAgp/AX4CQAJAAkACfwJAAkACQCAEQQFNBEAgBCENIAQhCCAEQQFrDQIMAQtBASEFQQEhBkEBIQ0DQCAGIQkCQCAHIApqIgggBEkEQCADIAVqLQAAIgYgAyAIai0AACIFTwRAIAUgBkcEQEEBIQ0gCUEBaiEGQQAhByAJIQoMAwtBACAHQQFqIgYgBiANRiIFGyEHIAZBACAFGyAJaiEGDAILIAcgCWpBAWoiBiAKayENQQAhBwwBC0GgsMoAIAggBBDkAgALIAYgB2oiBSAESQ0AC0EBIQVBASEGQQAhB0EBIQgDQCAGIQkCQCAHIAtqIgwgBEkEQCADIAVqLQAAIgYgAyAMai0AACIFTQRAIAUgBkcEQEEBIQggCUEBaiEGQQAhByAJIQsMAwtBACAHQQFqIgYgBiAIRiIFGyEHIAZBACAFGyAJaiEGDAILIAcgCWpBAWoiBiALayEIQQAhBwwBC0GgsMoAIAwgBBDkAgALIAYgB2oiBSAESQ0ACwsCQAJAIAogCyAKIAtLIgUbIgsgBE0EQCANIAggBRsiBiALaiIFIAZJDQEgBSAESw0CIAZFDQQgAyADIAZqIAsQtANFDQQgCyAEIAtrIgUgCyAFSxsgBCEGIAMhBwNAQgEgBzEAAEI/g4YgD4QhDyAHQQFqIQcgBkF/aiIGDQALQQFqIQZBfyEIIAshBUF/DAULIAsgBBDlAgALIAYgBRDmAgALIAUgBBDlAgALIAAgAzYCOCAAIAE2AjAgAEIANwMAIABBPGpBADYCACAAQTRqIAI2AgAgAEEMakGBAjsBACAAQQhqIAI2AgAPC0EBIQpBACEHQQEhBUEAIQ0DQCAFIgkgB2oiDCAESQRAIAQgB2sgCUF/c2oiCCAETw0FIAdBf3MgBGogDWsiBSAETw0EAkACQCADIAhqLQAAIgggAyAFai0AACIFTwRAIAUgCEYNASAJQQFqIQVBACEHQQEhCiAJIQ0MAgsgDEEBaiIFIA1rIQpBACEHDAELQQAgB0EBaiIIIAggCkYiBRshByAIQQAgBRsgCWohBQsgBiAKRw0BCwtBASEKQQAhB0EBIQVBACEIAkACQAJAAkADQCAFIgkgB2oiDiAESQRAIAQgB2sgCUF/c2oiDCAETw0CIAdBf3MgBGogCGsiBSAETw0DAkACQCADIAxqLQAAIgwgAyAFai0AACIFTQRAIAUgDEYNASAJQQFqIQVBACEHQQEhCiAJIQgMAgsgDkEBaiIFIAhrIQpBACEHDAELQQAgB0EBaiIMIAogDEYiBRshByAMQQAgBRsgCWohBQsgBiAKRw0BCwsgBiAESw0FIAQgDSAIIA0gCEsbayEFIAYNAkEAIQZBACEIDAMLQbCwygAgDCAEEOQCAAtBwLDKACAFIAQQ5AIAC0EAIQhBACEHA0BCASADIAdqMQAAQj+DhiAPhCEPIAYgB0EBaiIHRw0ACwsgBAshCSAAIAM2AjggACABNgIwIABBATYCACAAQTxqIAQ2AgAgAEE0aiACNgIAIABBKGogCTYCACAAQSRqIAg2AgAgAEEgaiACNgIAIABBHGpBADYCACAAQRhqIAY2AgAgAEEUaiAFNgIAIABBEGogCzYCACAAQQhqIA83AgAPCyAGIAQQ5QIAC0HAsMoAIAUgBBDkAgALQbCwygAgCCAEEOQCAAuUCAEJfwJAAkACQAJAAkACQCABKAIEIgIEQCABKAIAIQcCQAJAAkACQAJAAkADQAJ/IANBAWoiBiADIAdqIgotAAAiCEEYdEEYdSIJQX9KDQAaAkACQAJAIAhBsrHKAGotAABBfmoiBUECTQRAIAVBAWsOAgIDAQsgAiADSQ0JIAIgA00NCiAAIAM2AgQgACAHNgIAIAEgAiAGazYCBCABIAYgB2o2AgAMDwsgA0ECaiAGIAdqIgVBACACIAZLGyIEQcWqygAgBBstAABBwAFxQYABRg0CGiACIANJDQggAiADTQ0JDA0LIAYgB2oiBUEAIAIgBksbIgRBxarKACAEGy0AACEEAkACQCAIQaB+aiIIQQ1LDQACQAJAIAhBAWsODQICAgICAgICAgICAgEACyAEQeABcUGgAUYNAgwJCyAEQRh0QRh1QX9KIARBoAFPcg0IDAELIAlBH2pB/wFxQQtNBEAgBEEYdEEYdUF/SiAEQcABT3INCAwBCyAJQf4BcUHuAUcgBEG/AUtyIARBGHRBGHVBf0pyDQcLIANBA2ogByADQQJqIgVqIgZBACACIAVLGyIEQcWqygAgBBstAABBwAFxQYABRg0BGiACIANJDQcgA0F9Sw0KIAIgBUkNCwwOCyAGIAdqIgVBACACIAZLGyIEQcWqygAgBBstAAAhBAJAAkAgCEGQfmoiCEEESw0AAkACQCAIQQFrDgQCAgIBAAsgBEHwAGpB/wFxQTBJDQIMBwsgBEEYdEEYdUF/SiAEQZABT3INBgwBCyAEQb8BSyAJQQ9qQf8BcUECS3IgBEEYdEEYdUF/SnINBQsgByADQQJqIgVqIgZBACACIAVLGyIEQcWqygAgBBstAABBwAFxQYABRw0CIAcgA0EDaiIFaiIGQQAgAiAFSxsiBEHFqsoAIAQbLQAAQcABcUGAAUcNAyADQQRqCyIDIAJJDQALIAFBADYCBCABQcSqygA2AgAgACACNgIEIAAgBzYCACAAQQxqQQA2AgAgAEEIakHEqsoANgIADwsgAiADSQ0DIANBfUsNBiACIAVJDQcMCgsgAiADSQ0CIANBfEsNBSACIAVJDQYgASAGNgIAIAAgAzYCBCAAIAc2AgAgASACIAVrNgIEIABBDGpBAzYCAAwKCyACIANJDQEgAiADTQ0CDAYLIAIgA0kNACACIANNDQEMBQsgAyACEOUCAAsgBiACEOUCAAsgAEEANgIADwsgAyAFEOYCAAsgBSACEOUCAAsgASAFNgIAIAAgAzYCBCAAIAc2AgAgASACIAZrNgIECyAAQQxqQQE2AgAMAQsgASAGNgIAIAAgAzYCBCAAIAc2AgAgASACIAVrNgIEIABBDGpBAjYCAAsgAEEIaiAKNgIAC6MJAgR/LH4jAEHwB2siAiQAIAJByAdqQQBBKBDBBBoDQCABQcAHRgRAAkAgACkDwAEhEyAAKQOYASEFIAApA3AhDSAAKQNIIRQgACkDICEGIAApA7gBIQcgACkDkAEhCiAAKQNoIQggACkDQCEJIAApAxghCyAAKQOwASEVIAApA4gBIRYgACkDYCEXIAApAzghGCAAKQMQIQ4gACkDqAEhGSAAKQOAASEaIAApA1ghGyAAKQMwIRwgACkDCCEdIAApA6ABIQwgACkDeCEeIAApA1AhHyAAKQMoISAgACkDACEhQQAhAUGI98MAIQQDQCABQcAHRg0BIAJBCGogAWoiA0EIaiAOIBiFIBeFIBaFIBWFIg8gBiAUhSANhSAFhSAThSIQQgGJhSIiIAmFQjeJIiM3AwAgA0EQaiANIAkgC4UgCIUgCoUgB4UiESAgICGFIB+FIB6FIAyFIhJCAYmFIgmFQieJIiQ3AwAgA0EgaiAPQgGJIBKFIg8gGYVCAokiEjcDACADQRhqIBAgHCAdhSAbhSAahSAZhSINQgGJhSIQIB6FQimJIiU3AwAgAyAOIBFCAYkgDYUiEYVCPokiJjcDACAPIByFIAkgE4UhDiAjICZCf4WDIBKFIRMgIyAlICRCf4WDhSEZIA8gG4VCCokiJyAHICKFQjiJIiggESAWhUIPiSIpQn+Fg4UhFiAGIAmFQhuJIiogJyAQICCFQiSJIitCf4WDhSEeIAwgEIVCEokiDCARIBiFQgaJIiwgDyAdhUIBiSItQn+Fg4UhDSAFIAmFQgiJIi4gCCAihUIZiSIvQn+FgyAshSEbIBEgFYVCPYkiBSAJIBSFQhSJIgYgCyAihUIciSIHQn+Fg4UhFCAPIBqFQi2JIgggByAFQn+Fg4UhCSAQIB+FQgOJIgsgBSAIQn+Fg4UhGCAIIAtCf4WDIAaFIRwgByALIAZCf4WDhSEgIAogIoVCFYkiBSAQICGFIgYgDkIOiSIHQn+Fg4UhCyARIBeFQiuJIgogByAFQn+Fg4UhDkIsiSIIIAUgCkJ/hYOFIR0gBCkDACAGIAogCEJ/hYOFhSEhIARBCGohBCABQShqIQEgKCArICpCf4WDhSEFIAggBkJ/hYMgB4UhBiAlICYgEkJ/hYOFIQcgKiAoQn+FgyAphSEKIC0gDEJ/hYMgLoUhCCASICVCf4WDICSFIRUgLyAMIC5Cf4WDhSEXICsgKSAnQn+Fg4UhGiAkICNCf4WDICaFIQwgLyAsQn+FgyAthSEfDAALAAsFIAJBCGogAWogAkHIB2pBKBDyAxogAUEoaiEBDAELCyAAIAw3A6ABIAAgHjcDeCAAIB83A1AgACAgNwMoIAAgITcDACAAIBk3A6gBIAAgGjcDgAEgACAbNwNYIAAgHDcDMCAAIB03AwggACAVNwOwASAAIBY3A4gBIAAgFzcDYCAAIBg3AzggACAONwMQIAAgBzcDuAEgACAKNwOQASAAIAg3A2ggACAJNwNAIAAgCzcDGCAAIBM3A8ABIAAgBTcDmAEgACANNwNwIAAgFDcDSCAAIAY3AyAgAkHwB2okAAukCwICfwF+IwBB0AFrIgYkACAGQTRqIAJBJBDyAxogBkEyaiACQSdqLQAAOgAAIAYgAi8AJTsBMCACLQAkIQIgAygCACEHIAMpAgQhCCAGIAE2AlggACgCACEDAn8CQCABRQRAIAMtABBFDQELIAMoAgAhAQJAAkAgACgCBARAIAZBnAFqQQA2AgAgBkH8jsoANgKYASAGQgE3AowBIAZB8I/KADYCiAEgASAGQYgBahDoAg0CIAAoAgAiAS0AEEEBRw0BIAEoAgAgBkEoakGAkMoAELIFIAZBnAFqQQI2AgAgBkGUAWpBATYCACAGQQc2AmQgBkH4j8oANgJgIAZByI/KADYCkAEgBkEBNgKMASAGQfiPygA2AogBIAYgBikDKDcDaCAGIAZB4ABqNgKYASAGQYgBahDoAkUNAQwCCyAGQSBqIANBBGpBywAQpgUgBkGcAWpBATYCACAGQZQBakEBNgIAIAZBkI/KADYCkAEgBkECNgKMASAGQYCPygA2AogBIAYgBikDIDcDYCAGIAZB4ABqNgKYASABIAZBiAFqEOgCDQEgACgCACIBLQAQQQFHDQAgASgCACAGQRhqQcSPygAQsgUgBkGcAWpBAjYCACAGQZQBakEBNgIAIAZBiAE2AmQgBkHIj8oANgKQASAGQQI2AowBIAZBtI/KADYCiAEgBiAGKQMYNwNoIAYgBkHYAGo2AmAgBiAGQeAAajYCmAEgBkGIAWoQ6AINAQsgBkHgAGogBkE0akEkEPIDGiAGQd4AaiAGQTJqLQAAOgAAIAYgBi8BMDsBXCAAKAIAIQECQAJAIAJBA0YNACABLQAQIgNBAUsNACADQQFrBEAgBkGIAWogBkHgAGpBJBDyAxogBkGtAWogBi8BXDsAACAGQawBaiACOgAAIAZBrwFqIAZB3gBqLQAAOgAAIAEoAgAgBkHEAWpBATYCACAGQbwBakEBNgIAIAZBhJDKADYCuAEgBkEBNgK0ASAGQfiPygA2ArABIAZBiQE2AswBIAYgBkHIAWo2AsABIAYgBkGIAWo2AsgBIAZBsAFqEOgCRQ0CDAMLIAZBiAFqIAZB4ABqQSQQ8gMaIAZBrQFqIAYvAVw7AAAgBkGsAWogAjoAACAGQa8BaiAGQd4Aai0AADoAACABKAIAIAZBxAFqQQE2AgAgBkIBNwK0ASAGQfiPygA2ArABIAZBiQE2AswBIAYgBkHIAWo2AsABIAYgBkGIAWo2AsgBIAZBsAFqEOgCRQ0BDAILIAEoAgAgBkGcAWpBADYCACAGQfyOygA2ApgBIAZCATcCjAEgBkGwkMoANgKIASAGQYgBahDoAg0BCyAAKAIAKAIAQbiQygBBARCIBQ0AIAdBAkYgBEEBR3INASAGIAU2ArABAkAgACgCACIBLQAQQQFGBH8gASgCACAGQRBqQcSPygAQsgUgBkGcAWpBAjYCACAGQZQBakEBNgIAIAZBBzYCZCAGQfiPygA2AmAgBkHIj8oANgKQASAGQQE2AowBIAZB+I/KADYCiAEgBiAGKQMQNwNoIAYgBkHgAGo2ApgBIAZBiAFqEOgCDQEgACgCAAUgAQsoAgAgBkGcAWpBADYCACAGQfyOygA2ApgBIAZCATcCjAEgBkHMkMoANgKIASAGQYgBahDoAg0AIAAoAgAiAUEMaigCACECIAEoAgggBkGQAWogCDcDACAGIAc2AowBIAYgASgCACIBNgKIASABIAZBiAFqQQRyIAIoAgwRBAANACAAKAIAKAIAIAZBCGogBkGwAWpBywAQpgUgBkGcAWpBATYCACAGQgI3AowBIAZB2JDKADYCiAEgBiAGKQMINwNgIAYgBkHgAGo2ApgBIAZBiAFqEOgCRQ0CCwtBAQwBCyAAIAAoAgRBAWo2AgRBAAsgBkHQAWokAAv6CQELfyMAQYACayIDJAAQyQQhCyADQRhqEKgDIANBgAFqIAEgAkGI8sgAQQEQICADQQE7AcgBIAMgAjYCxAEgA0EANgLAASADQTBqIANBgAFqQdAAEPIDGiADQYABaiADQTBqQdAAEPIDGiADQYgBaiEMAkACQAJAAkACQANAIAMtAMkBDQEgAygCsAEhBiADQfABaiALAn8CfwJAAkAgAygCgAFBAUcEQCAGIAMoArQBIgdqIQEgAy0AjAEhBCADKAKEASECA0AgAyAHNgLkASADIAY2AuABIAMgAjYC6AEgAyAHNgLsASACRSACIAdGckUEQCAHIAJNDQkgAiAGaiwAAEG/f0wNCQsgBCEJAn8gAiAHRwRAIAIgBmoiCCwAACIFQX9KBEAgBUH/AXEMAgsCfyABIAhBAWpGBEAgASEEQQAMAQsgCEECaiEEIAgtAAFBP3ELIg0gBUEfcSIKQQZ0ciAFQf8BcSIIQd8BTQ0BGgJ/IAEgBEYEQCABIQVBAAwBCyAEQQFqIQUgBC0AAEE/cQsgDUEGdHIiBCAKQQx0ciAIQfABSQ0BGiABIAVGBH9BAAUgBS0AAEE/cQsgCkESdEGAgPAAcSAEQQZ0cnIMAQtBgIDEAAshBSAJRSEEIAkNAyAFQYCAxABHBEACf0EBIAVBgAFJDQAaQQIgBUGAEEkNABpBA0EEIAVBgIAESRsLIAJqIQIMAQsLIAMgAjYChAEgAyAEOgCMASADQQA2AtABDAELIANB0AFqIAwgBiADKAK0ASADKAK4ASADKAK8ASADKAKkAUF/RhBKIAMoAtABQQFGBEAgAygC2AEhAiADKALUAQwDCyADLQDJAQ0FCwJAIAMtAMgBBEAgAygCxAEhAiADKALAASEBDAELIAMoAsQBIgIgAygCwAEiAUYNBQsgA0EBOgDJASACIAFrIQIgAygCsAEgAWoMAgsgAyACNgKEASADIAQ6AIwBIAMgAjYC2AEgAyACNgLUASADQQE2AtABIAILIAMoAsABIQQgAyACNgLAASAEayECIAQgBmoLIAIQfSADLwHwAUEBRwRAIANBGGogAy8B8gEQzgIMAQsLIAAgAykC9AE3AgQgAEEBNgIADAILIANBgAFqIAMoAhggA0EoaiICKAIAQQN0akELbhDvASADKAKEASEEIAMoAoABQQFHDQIgACAENgIEIABBATYCACAAQQhqIANBiAFqKAIANgIADAELIAMgA0HsAWo2AvgBIAMgA0HoAWo2AvQBIAMgA0HgAWo2AvABIANB8AFqEO8EAAsgA0EgahCBBQwBCyADQYABaiIBKAIABEAgAUEEahD6AQsgA0GQAWogAigCADYCACADQYgBaiADQSBqKQMANwMAIAMgAykDGDcDgAEgA0EwaiADQYABahDtAyADQRBqIANBMGoQmwUgAygCFCIBIARBC3YiAksEQCADKAIQIAJqLQAAIANBMGogAhCLBCADQQhqIANBMGoQmwVBACAEa0EHcSIBdkH/AXEgAygCCCADKAIMENoEQf8BcSABdkH/AXFHBEAgA0EANgKAASADIANBgAFqEMEDIAAgAykDADcCBCAAQQE2AgAgA0EwahCBBQwCCyAAIAMpAzA3AgQgAEEANgIAIABBDGogA0E4aigCADYCAAwBC0H48cgAIAIgARDkAgALIANBgAJqJAALigkBCX8jAEHQAGsiAyQAIAFBBGooAgAhBSABKAIAIQIgAS0ACCIGQQZHBEAgA0E3aiABQRhqKAAANgAAIANBMGogAUERaikAADcDACADIAFBCWopAAA3AygLIANBEWogAykDKDcAACADQRlqIANBMGopAwA3AAAgA0EgaiADQTdqKAAANgAAIAMgBjoAECADIAU2AgwgAyACNgIIIAMgAS0AHiIJOgAmIAMgAS0AHSIEOgAlIAMgAS0AHEEARzoAJAJAAkAgBUUgBEH/AXFBAkdyDQACQAJAIAZBAk0EQANAQQAhB0EAIQECQANAIAEgBUYEQCAFIQYMAgsgASACaiABQQFqIQEtAAAiCEEvRw0AC0EBIQcgBSAIQS9GQQFqQQFxIAFqQX9qIgZJDQYLIAYNBCAFIAYgB2oiAUkNAiADIAUgAWsiBTYCDCADIAEgAmoiAjYCCCAFDQAMAwsACwNAQQAhB0EAIQECQAJAA0AgASAFRgRAIAUhBgwCCyABIAJqIAFBAWohAS0AACIIQS9HDQALQQEhByAFIAhBL0ZBAWpBAXEgAWpBf2oiBkkNAQsgBkEBSw0EIAZBAWsgAkHQocoARnJFBEAgAi0AAEEuRw0FCyAFIAYgB2oiAUkNAiADIAUgAWsiBTYCDCADIAEgAmoiAjYCCCAFRQ0DDAELCwwDCyABIAUQ5gIAC0EAIQULAkAgCUECRw0AIANBEGohBwJAA0ACQEEAIQFBACEGAkBBAEEBQX8gBEH/AXEiCBsgCEEBRhtBAWpBAUsiBA0AIAQgAy0AJCIBcg0AIAMtABAiAkF7akH/AXFBAUsNAEEAIQQgAkEGRiICRQRAQQIhBAJAAkACQAJAAkACQEEAIAcgAhsiAi0AAEEBaw4FAQIEAwUACyACKAIIQQRqIQQMBAsgAigCCCACKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAigCCCACKAIQIgRBAWpBACAEG2pBAmohBAwBCyACKAIIQQRqIQQLIAUgBEkNAgsgBCAFRiIJDQAgAygCCCIGIARqIgIgAkEBaiAJGyAFIAZqRiIJIAItAAAiCkEuRnEhBiAJIApBLkdyDQAgAiAEIAVHai0AAEEvRiEGC0EAIQQCQCAIDQAgAy0AEEEGRiICDQBBAiEEAkACQAJAAkACQEEAIAcgAhsiAi0AAEEBaw4FAQIEAwUACyACKAIIQQRqIQQMBAsgAigCCCACKAIQIgRBAWpBACAEG2pBCGohBAwDC0EGIQQMAgsgAigCCCACKAIQIgRBAWpBACAEG2pBAmohBAwBCyACKAIIQQRqIQQLAkAgBSABIAZqIARqSwRAIANBKGogA0EIahAtIAMoAgwhASADKAIsQQVGDQEgASEFCyADKAIIIQIMBAsgASADKAIoIgZrIQUgASAGSQ0CIAMgBTYCDCADLQAlIQQMAQsLIAQgBRDmAgALIAUgARDlAgALIAAgBTYCBCAAIAI2AgAgA0HQAGokAA8LIAhBL0ZBAWpBAXEgAWpBf2ogBRDlAgAL2AkCBX8BfiMAQbAKayIDJAACQAJAIAJBwABGBEAgA0EYaiABQcAAEKIEQSAhAgJ/IAMoAhxBIEcEQEGgucYAIQRBCSEFQQIhBkEBDAELIAMoAhghAiADQfgEaiIEQgA3AwAgA0HwBGpCADcDACADQegEakIANwMAIANCADcD4AQgA0EQaiACQSAQogQgA0HgBGpBICADKAIQIAMoAhQQsAEgA0H2AWogAy0A4gQ6AAAgAyADLwHgBDsB9AEgAyADKQDzBDcDqAMgAyAEKQAANwCtAyADKADjBCEGIAMoAOcEIQQgAygA6wQhBSADKADvBCECQQALIQcgA0GICWogAjYCACADQYQJaiAFNgIAIANBgAlqIAQ2AgAgA0GMCWogAykDqAM3AgAgA0GUCWogA0GwA2opAwA3AgAgA0GcCWogA0G4A2opAwA3AgAgAyAHOgD4CCADIAMvAfQBOwD5CCADIAY2AvwIIAMgA0H2AWotAAA6APsIIAdFDQEgAEEEaiADQfgIakEEckEoEPIDGiAAQQE2AgAMAgsgAEKBgICAIDcDACAAQQxqQoeAgICACDcCACAAQQhqQZC5xgA2AgAMAQsgA0E4aiIEIANB+AhqQQFyIgJBGGopAAA3AwAgA0EwaiACQRBqKQAANwMAIANBKGogAkEIaikAADcDACADIAIpAAA3AyAgA0H4BGoiAkIANwMAIANB8ARqIgVCADcDACADQegEaiIGQgA3AwAgA0IANwPgBCADQQhqIAFBIGpBIBCiBCADQeAEakEgIAMoAgggAygCDBCwASADQZgFaiIBIAIpAwA3AwAgA0GQBWogBSkDADcDACADQYgFaiAGKQMANwMAIAMgAykD4AQ3A4AFIANB+AhqIANBgAVqEGwgAykD+AhCAVEEQCADQYgJaigCACECIAMpA4AJIQggA0HIB2ogA0GMCWpBlAEQ8gMaIANBtAZqIANByAdqQZQBEPIDGiADQaAFaiADQbQGakGUARDyAxogA0H4CGogA0GgBWpBlAEQ8gMaIANBpApqIAEpAwA3AgAgA0GcCmogA0GQBWopAwA3AgAgA0GUCmogA0GIBWopAwA3AgAgAyADKQOABTcCjAogA0GoA2ogA0H4CGpBtAEQ8gMaIANB9AFqIANBqANqQbQBEPIDGiADQUBrIANB9AFqQbQBEPIDGiAAQRBqIAI2AgAgAEEIaiAINwMAIABBFGogA0FAa0G0ARDyAxogAEEANgIAIABB4AFqIAQpAwA3AAAgAEHYAWogA0EwaikDADcAACAAQdABaiADQShqKQMANwAAIABByAFqIAMpAyA3AAAMAQsgA0HYB2ogA0HwCGopAgA3AwAgA0HQB2ogA0HoCGopAgA3AwAgAyADKQLgCDcDyAcgA0G0BmogA0HIB2pBlAEQ8gMaIANBsANqIANBvAZqKQIANwMAIANBuANqIANBxAZqKQIANwMAIAMgAykCtAY3A6gDIANB9AFqIANBqANqQbQBEPIDGiAAQQxqQomAgICABDcCACAAQQhqQZe5xgA2AgAgAEEUaiADKQL0ATcCACAAQRxqIANB/AFqKQIANwIAIABBJGogA0GEAmopAgA3AgAgAEIBNwMAIANBIGoQswILIANBsApqJAALlQgCAX8tfiAAKQPAASEOIAApA5gBIQIgACkDcCEPIAApA0ghECAAKQMgIQMgACkDuAEhBCAAKQOQASEHIAApA2ghBSAAKQNAIQogACkDGCEIIAApA7ABIREgACkDiAEhEiAAKQNgIRMgACkDOCEUIAApAxAhBiAAKQOoASEVIAApA4ABIRYgACkDWCEXIAApAzAhGCAAKQMIIRkgACkDoAEhCSAAKQN4IRogACkDUCEbIAApAyghHCAAKQMAIR1BwH4hAQNAIAEEQCAcIB2FIBuFIBqFIAmFIgsgBiAUhSAThSAShSARhSIMQgGJhSIeIBiFIA4gCCAKhSAFhSAHhSAEhSINIAtCAYmFIguFIS4gFSAehUICiSIgIAogAyAQhSAPhSAChSAOhSIfQgGJIAyFIgyFQjeJIiEgBiAYIBmFIBeFIBaFIBWFIgogDUIBiYUiDYVCPokiIkJ/hYOFIQ4gISAfIApCAYmFIgYgGoVCKYkiHyALIA+FQieJIiNCf4WDhSEVIBcgHoVCCokiJCAEIAyFQjiJIiUgDSAShUIPiSImQn+Fg4UhEiADIAuFQhuJIicgJCAGIByFQiSJIihCf4WDhSEaIAYgCYVCEokiCSANIBSFQgaJIikgGSAehUIBiSIqQn+Fg4UhDyACIAuFQgiJIisgBSAMhUIZiSIsQn+FgyAphSEXIA0gEYVCPYkiAiALIBCFQhSJIgMgCCAMhUIciSIEQn+Fg4UhECAWIB6FQi2JIgUgBCACQn+Fg4UhCiAGIBuFQgOJIgggAiAFQn+Fg4UhFCAFIAhCf4WDIAOFIRggBCAIIANCf4WDhSEcIAcgDIVCFYkiAiAGIB2FIgMgLkIOiSIEQn+Fg4UhCCANIBOFQiuJIgcgBCACQn+Fg4UhBkIsiSIFIAIgB0J/hYOFIRkgAUHYw8QAaikDACADIAcgBUJ/hYOFhSEdIAFBCGohASAlICggJ0J/hYOFIQIgBSADQn+FgyAEhSEDIB8gIiAgQn+Fg4UhBCAnICVCf4WDICaFIQcgKiAJQn+FgyArhSEFICAgH0J/hYMgI4UhESAsIAkgK0J/hYOFIRMgKCAmICRCf4WDhSEWICMgIUJ/hYMgIoUhCSAsIClCf4WDICqFIRsMAQUgACAJNwOgASAAIBo3A3ggACAbNwNQIAAgHDcDKCAAIB03AwAgACAVNwOoASAAIBY3A4ABIAAgFzcDWCAAIBg3AzAgACAZNwMIIAAgETcDsAEgACASNwOIASAAIBM3A2AgACAUNwM4IAAgBjcDECAAIAQ3A7gBIAAgBzcDkAEgACAFNwNoIAAgCjcDQCAAIAg3AxggACAONwPAASAAIAI3A5gBIAAgDzcDcCAAIBA3A0ggACADNwMgCwsLyAgBDX8jAEEwayIEJABBASEOAkACQCACKAIYQSIgAkEcaigCACgCEBECAA0AAkAgAUUNACAAIAFqIQwgACEIAkACQANAIAghDyAIQQFqIQkCQAJ/IAgsAAAiBUF/TARAAn8gCSAMRgRAQQAhBiAMDAELIAgtAAFBP3EhBiAIQQJqIgkLIQggBiAFQR9xIg1BBnRyIAVB/wFxIgdB3wFNDQEaAn8gCCAMRgRAIAwhBUEADAELIAhBAWoiCSEFIAgtAABBP3ELIAZBBnRyIgYgDUEMdHIgB0HwAUkNARoCfyAFIAxGBEBBACELIAkMAQsgBS0AAEE/cSELIAVBAWoLIQggDUESdEGAgPAAcSAGQQZ0ciALciILQYCAxABHDQIMBQsgBUH/AXELIQsgCSEICyAEIAsQfwJAAkACQAJAIAQoAgAiCUEBaw4DAgEAAQsgBCgCCCAELQAMakEBRg0BCyAEIAE2AhQgBCAANgIQIAQgAzYCGCAEIAo2AhwgCiADSQ0DIANFIAEgA0ZyRQRAIAMgAU8NBCAAIANqLAAAQb9/TA0ECyAKRSABIApGckUEQCAKIAFPDQQgACAKaiwAAEG/f0wNBAsgAigCGCAAIANqIAogA2sgAigCHCgCDBEEAA0BIAQtAAwhByAEKAIIIQUCQCAEKAIEIgZBgIDEAEYEQANAIAkhA0EBIQlB3AAhBgJAAkAgA0ECaw4CAQAECyAHQf8BcSEDQQMhCUEEIQcCQAJAAkACQCADQQFrDgUDAgEABAcLQQMhB0H1ACEGDAMLQQIhB0H7ACEGDAILQQJBASAFGyEHQYCAxAAgBUECdEEccXZBD3FBMHIhBiAFQX9qQQAgBRshBQwBC0EAIQdB/QAhBgsgAigCGCAGIAIoAhwoAhARAgBFDQAMBAsACwNAIAkhDUEBIQlB3AAhAwJAAkACQAJAIA1BAWsOAwEDAAULIAdB/wFxIQ1BAyEJQQQhBwJAAkACQCANQQFrDgUCAQAEBQcLQQIhB0H7ACEDDAQLIAYgBUECdEEccXZBD3EiA0EwciADQdcAaiADQQpJGyEDQQJBASAFGyEHIAVBf2pBACAFGyEFDAMLQQAhB0H9ACEDDAILQQAhCSAGIQMMAQtBAyEHQfUAIQMLIAIoAhggAyACKAIcKAIQEQIARQ0ACwwCCwJ/QQEgC0GAAUkNABpBAiALQYAQSQ0AGkEDQQQgC0GAgARJGwsgCmohAwsgCiAPayAIaiEKIAggDEcNAQwDCwsMAwsgBCAEQRxqNgIoIAQgBEEYajYCJCAEIARBEGo2AiAgBEEgahDvBAALIANFIAEgA0ZyDQAgAyABTw0CIAAgA2osAABBv39MDQILIAIoAhggACADaiABIANrIAIoAhwoAgwRBAANACACKAIYQSIgAigCHCgCEBECACEOCyAEQTBqJAAgDg8LIAAgASADIAEQKQALuAgBBn8jAEHwAGsiBCQAIAQgAzYCDCAEIAI2AghBASEHIAEhBgJAIAFBgQJJDQBBACABayEIQYACIQUDQAJAIAUgAU8NACAAIAVqLAAAQb9/TA0AQQAhByAFIQYMAgsgBUF/aiEGQQAhByAFQQFGDQEgBSAIaiAGIQVBAUcNAAsLIAQgBjYCFCAEIAA2AhAgBEEAQQUgBxs2AhwgBEHEqsoAQbKzygAgBxs2AhgCQAJAAkAgAiABSyIFIAMgAUtyRQRAIAIgA0sNAQJAIAJFIAEgAkZyRQRAIAEgAk0NASAAIAJqLAAAQUBIDQELIAMhAgsgBCACNgIgIAJFIAEgAkZyDQIgAUEBaiEDA0AgAiABSQRAIAAgAmosAABBQE4NBAsgAkF/aiEFIAJBAUYNBCACIANGIAUhAkUNAAsMAwsgBCACIAMgBRs2AiggBEHEAGpBAzYCACAEQdwAakG0ATYCACAEQdQAakG0ATYCACAEQgM3AjQgBEHYs8oANgIwIARBywA2AkwgBCAEQcgAajYCQCAEIARBGGo2AlggBCAEQRBqNgJQIAQgBEEoajYCSCAEQTBqQfCzygAQvQQACyAEQeQAakG0ATYCACAEQdwAakG0ATYCACAEQdQAakHLADYCACAEQcQAakEENgIAIARCBDcCNCAEQaS0ygA2AjAgBEHLADYCTCAEIARByABqNgJAIAQgBEEYajYCYCAEIARBEGo2AlggBCAEQQxqNgJQIAQgBEEIajYCSCAEQTBqQcS0ygAQvQQACyACIQULAkAgASAFRg0AQQEhBgJAAkACQCAAIAVqIgMsAAAiAkF/TARAQQAhByAAIAFqIgAhASAAIANBAWpHBEAgAy0AAUE/cSEHIANBAmohAQsgAkEfcSEDIAJB/wFxQd8BSw0BIAcgA0EGdHIhAQwCCyAEIAJB/wFxNgIkIARBKGohAgwCC0EAIQggACIGIAFHBH8gAUEBaiEGIAEtAABBP3EFIAgLIAdBBnRyIQEgAkH/AXFB8AFJBEAgASADQQx0ciEBDAELQQAhAiAAIAZHBH8gBi0AAEE/cQUgAgsgA0ESdEGAgPAAcSABQQZ0cnIiAUGAgMQARg0CCyAEIAE2AiRBASEGIARBKGohAiABQYABSQ0AQQIhBiABQYAQSQ0AQQNBBCABQYCABEkbIQYLIAQgBTYCKCAEIAUgBmo2AiwgBEHEAGpBBTYCACAEQewAakG0ATYCACAEQeQAakG0ATYCACAEQdwAakG1ATYCACAEQdQAakG2ATYCACAEQgU3AjQgBEGYtcoANgIwIAQgAjYCWCAEQcsANgJMIAQgBEHIAGo2AkAgBCAEQRhqNgJoIAQgBEEQajYCYCAEIARBJGo2AlAgBCAEQSBqNgJIIARBMGpBwLXKABC9BAALQemqygBBK0HUtMoAEM4DAAvpBgIBfxR+IwBB8AFrIgMkACABKQMgIQUgASkDGCEGIAEpAxAhBCABKQMIIQcgASkDACEIA0AgA0HwAGogCCAHEJ4CIANBMGogBCAFQhN+IgoQngIgA0HgAWogBkITfiIJIAYQngIgA0FAayAJIAQQngIgA0GAAWogByAKEJ4CIANBIGogCCAEEJ4CIANB0AFqIAkgBRCeAiADQRBqIAcgBBCeAiADQaABaiAIIAYQngIgA0HAAWogCiAFEJ4CIANB0ABqIAcgBhCeAiADQZABaiAIIAUQngIgA0GwAWogCCAIEJ4CIANB4ABqIAcgBxCeAiADIAQgBBCeAiADKQOQASIOIAMpA1B8IgRCAYYiDyADKQMAfCIHIAMpA6ABIhAgAykDEHwiCEIBhiIRIAMpA8ABfCIFIAMpAyAiEiADKQPQAXwiBkIBhiITIAMpA2B8IgogAykDcCIUIAMpAzB8IglCAYYiFSADKQPgAXwiDCADKQOAASIWIAMpA0B8IgtCAYYiFyADKQOwAXwiDUIziCANIBdUrSADQbgBaikDACALIBZUrSADQYgBaikDACADQcgAaikDAHx8QgGGIAtCP4iEfHxCDYaEfCILQjOIIAsgDFStIAwgFVStIANB6AFqKQMAIAkgFFStIANB+ABqKQMAIANBOGopAwB8fEIBhiAJQj+IhHx8fEINhoR8IglCM4ggCSAKVK0gCiATVK0gA0HoAGopAwAgBiASVK0gA0EoaikDACADQdgBaikDAHx8QgGGIAZCP4iEfHx8Qg2GhHwiBkIziCAGIAVUrSAFIBFUrSADQcgBaikDACAIIBBUrSADQagBaikDACADQRhqKQMAfHxCAYYgCEI/iIR8fHxCDYaEfCIFQjOIIAUgB1StIAcgD1StIANBCGopAwAgBCAOVK0gA0GYAWopAwAgA0HYAGopAwB8fEIBhiAEQj+IhHx8fEINhoRCE34gDUL/////////A4N8IgRC/////////wODIQggC0L/////////A4MgBEIziHwhByAFQv////////8DgyEFIAZC/////////wODIQYgCUL/////////A4MhBCACQX9qIgINAAsgACAFNwMgIAAgBjcDGCAAIAQ3AxAgACAHNwMIIAAgCDcDACADQfABaiQAC5AIAQl/IwBBwAZrIgMkAAJAAkAgAkHgAEYEQEHAACECIANBCGogAUHgAEHAABCeBAJ/IAMoAgxBwABHBEBBAyEEQdH+wQAhBUEJIQZB2v7BACEIQckAIQlBAQwBCyADKAIIIQIgA0H4BWoiBEIANwMAIANB8AVqIgVCADcDACADQegFaiIGQgA3AwAgA0IANwPgBSADQeAFakEgIAJBIBCtASADQeAFahDIAyADQbACaiAEKQMANwMAIANBqAJqIAUpAwA3AwAgA0GgAmogBikDADcDACADIAMpA+AFNwOYAiADQYAGaiADQZgCahC7AyADQbgGaiIHQgA3AwAgA0GwBmoiCkIANwMAIANBqAZqIgtCADcDACADQgA3A6AGIANBoAZqQSAgAkEgakEgEK0BIANB1gBqIAMtAIIGOgAAIANB0gBqIAMtAIYGOgAAIANB3ABqIANBnwZqLQAAOgAAIAMgAy8BgAY7AVQgAyADLwGEBjsBUCADIAMoAJsGNgJYIAMtAIMGIQQgAygAhwYhBSADKACLBiEGIAMoAI8GIQggAygAkwYhCSADKACXBiECIANB9QBqIAcpAwA3AAAgA0HtAGogCikDADcAACADQeUAaiALKQMANwAAIAMgAykDoAY3AF0gA0GYAmogA0HYAGpBJRDyAxpBAAshByADQfgDaiACNgIAIANB9ANqIAk2AgAgA0HwA2ogCDYCACADQewDaiAGNgIAIANB6ANqIAU2AgAgAyAHOgDgAyADIAMvAVQ7AOEDIAMgBDoA5AMgAyADLwFQOwDlAyADIANB1gBqLQAAOgDjAyADIANB0gBqLQAAOgDnAyADQfwDaiADQZgCakEoEPIDGiADQeADakEEciECIAdFDQEgAEEBNgIAIAAgAikCADcCBCAAQRRqIAJBEGopAgA3AgAgAEEMaiACQQhqKQIANwIAIANB4ANqIgAtAABFBEAgAEEBahCfAQsMAgsgAEEDOgAEIABBATYCACAAQRRqQqSAgICADDcCACAAQRBqQYrwwwA2AgAgAEEMakEHNgIAIABBCGpBg/DDADYCAAwBCyADQRBqIANB4ANqQQFyQcAAEPIDGiADIAFB4ABBwAAQnQQgA0HgA2ogAygCACADKAIEEGkgAygC4AMgA0GYAmogAkHEARDyAxpBAUcEQCADQdgAaiADQZwCakHAARDyAxogA0HgA2ogA0HYAGpBwAEQ8gMaIANBoAVqIANBEGpBwAAQ8gMaIABBCGogA0HgA2pBgAIQ8gMaIABBADYCAAwBCyAAIAMpApgCNwIEIABBATYCACAAQRRqIANBqAJqKQIANwIAIABBDGogA0GgAmopAgA3AgAgA0EQahCfAQsgA0HABmokAAvoBwIJfwR+IwBBsARrIgYkAAJAIAFBwABHDQAgBkHoA2pCADcDACAGQeADakIANwMAIAZB2ANqQgA3AwAgBkIANwPQAyAGQSBqIgFCADcDACAGQRhqIgdCADcDACAGQRBqIghCADcDACAGQgA3AwggBkHQA2pBICAAQSAQrgEgBkEIakEgIABBIGpBIBCuASAGLAAnIgBBf0oNACAGIABB/wBxOgAnIAZB4ABqIAEpAwA3AwAgBkHYAGogBykDADcDACAGQdAAaiAIKQMANwMAIAYgBikDCDcDSCAGQYgCaiAGQcgAahDMAUEBIQECfyAGLQCIAkEBRwRAIAZBpwRqIAZB1wBqKQAANwAAIAZBoARqIAZB0ABqKQAANwMAIAYgBikASDcDmARBAgwBCyAGQaAEaiAGQZUCaikAADcDACAGQacEaiAGQZwCaikAADcAACAGQZQEaiAGQagCai0AADoAACAGIAYpAI0CNwOYBCAGIAZBpAJqKAIANgKQBCAGLwCJAiAGLQCLAkEQdHIhDUEAIQEgBi0AjAILIQAgBkGABGoiByAGQaAEaiIIKQMANwMAIAZBhwRqIgkgBkGnBGoiCykAADcAACAGQfQDaiIKIAZBlARqIgwtAAA6AAAgBiAGKQOYBDcD+AMgBiAGKAKQBDYC8AMgAQRAIAZBkQJqIAcpAwA3AAAgBkGYAmogCSkAADcAACAGIAA6AIgCIAYgBikD+AM3AIkCIAZByABqIAZBiAJqEKoEIAZBAmogBi0ASzoAACAGIAYvAEk7AQAMAQsgCyAJKQAANwAAIAggBykDADcDACAMIAotAAA6AAAgBkEGaiIBIAYtANIDOgAAIAYgBikD+AM3A5gEIAYgBigC8AM2ApAEIAYgBi8B0AM7AQQgBi0A0wMhByAGQQJqIgkgBi0A1gM6AAAgBiAGLwHUAzsBACAGQe8DajEAACEPIAYpANcDIRAgBikA3wMhESAGKADnAyEKIAY1AOsDIRIgBkEraiAAOgAAIAYgBzoACyAGIAEtAAA6AAogBiAGLwEEOwEIIAYgEiAPQiCGhCANrUIohoQ3ACMgBiAKNgAfIAYgETcAFyAGIBA3AA8gBiAGLwEAOwEMIAYgCS0AADoADiAGQSxqIAYpA5gENwIAIAZBNGogCCkDADcCACAGQTtqIAspAAA3AAAgBkHHAGogDC0AADoAACAGQcMAaiAGKAKQBDYAACAGQYgCaiAEIAUQXiAGQcgAaiAGQYgCakGYhMAAEMcCIAZBiAJqIAZByABqIAIgAyAGQQhqEOQBIAYtAIgCQQdGIQ4LIAZBsARqJAAgDgvUBgENfyMAQSBrIgokAAJAAkACQEEAQQFBfyABLQAdIggbIAhBAUYbQQFqQQFLIgINACACIAEtABwiBnINACABLQAIIgNBe2pB/wFxQQFLDQAgASgCBCEHQQAhAiADQQZGIgNFBEBBAiECAkACQAJAAkACQAJAQQAgAUEIaiADGyIDLQAAQQFrDgUBAgQDBQALIAMoAghBBGohAgwECyADKAIIIAMoAhAiAkEBakEAIAIbakEIaiECDAMLQQYhAgwCCyADKAIIIAMoAhAiAkEBakEAIAIbakECaiECDAELIAMoAghBBGohAgsgByACSQ0CCyACIAdGIgkNACABKAIAIgQgAmoiAyADQQFqIAkbIAQgB2pGIgkgAy0AACILQS5GcSEEIAkgC0EuR3INACADIAIgB0dqLQAAQS9GIQQLAkAgCA0AIAEtAAhBBkYiAg0AQQIhBQJAAkACQAJAAkBBACABQQhqIAIbIgItAABBAWsOBQECBAMFAAsgAigCCEEEaiEFDAQLIAIoAgggAigCECICQQFqQQAgAhtqQQhqIQUMAwtBBiEFDAILIAIoAgggAigCECICQQFqQQAgAhtqQQJqIQUMAQsgAigCCEEEaiEFCyABKAIEIgMgBCAGaiAFaiIHSQ0BIAEoAgAiCCAHaiECIAMgCGoiCUF/aiELIAUgBmogBGoiDCADayENQQAhBEEAIQYCQANAIAYgDUYNASAGIAtqIAZBf2oiBSEGLQAAQS9HDQALQQEhBCADIAkgDGogAmsiAiAFakEBaiIHSQ0CIAIgCGogBWpBAWohAgsgBCADIAdrIgZqIQVBBCEEAkAgBkECSw0AAkACQAJAIAZBAWsOAgABAgsgAkHQocoARwRAIAItAABBLkcNAwtBAkEFQQIgAS0ACCIBQQNJIAFBBkYbIgFBAXEbQQUgAUECRxshBAwCCyACQeOhygBHBEAgAi8AAEGu3ABHDQILQQMhBAwBC0EFIQQLIAAgBDYCBCAAIAU2AgAgAEEMaiAGNgIAIABBCGogAjYCACAAQRBqIAopAgw3AgAgAEEYaiAKQRRqKQIANwIAIABBIGogCkEcaigCADYCACAKQSBqJAAPCyACIAcQ5gIACyAHIAMQ5gIAC8QGAQt/IABBEGooAgAhAwJAAkACQAJAIABBCGooAgAiDUEBRwRAIANBAUYNASAAKAIYIAEgAiAAQRxqKAIAKAIMEQQAIQMMAwsgA0EBRw0BCwJAIAJFBEBBACECDAELIAEgAmohCCAAQRRqKAIAQQFqIQsgASIDIQkDQCADQQFqIQUCQAJ/IAMsAAAiBEF/TARAAn8gBSAIRgRAQQAhCiAIDAELIAMtAAFBP3EhCiADQQJqIgULIQcgCiAEQR9xIgxBBnRyIARB/wFxIgNB3wFNDQEaAn8gByAIRgRAQQAhBCAIDAELIActAABBP3EhBCAHQQFqIgULIQcgBCAKQQZ0ciIEIAxBDHRyIANB8AFJDQEaAn8gByAIRgRAIAUhA0EADAELIAdBAWohAyAHLQAAQT9xCyAMQRJ0QYCA8ABxIARBBnRyciIEQYCAxABHDQIMBAsgBEH/AXELIQQgBSEDCyALQX9qIgsEQCAGIAlrIANqIQYgAyEJIAMgCEcNAQwCCwsgBEGAgMQARg0AAkAgBkUgAiAGRnJFBEBBACEDIAYgAk8NASABIAZqLAAAQUBIDQELIAEhAwsgBiACIAMbIQIgAyABIAMbIQELIA1BAUYNAAwCC0EAIQUgAgRAIAIhBCABIQMDQCAFIAMtAABBwAFxQYABRmohBSADQQFqIQMgBEF/aiIEDQALCyACIAVrIAAoAgwiCU8NAUEAIQZBACEFIAIEQCACIQQgASEDA0AgBSADLQAAQcABcUGAAUZqIQUgA0EBaiEDIARBf2oiBA0ACwsgBSACayAJaiIDIQQCQAJAAkBBACAALQAgIgUgBUEDRhtBAWsOAwEAAQILIANBAXYhBiADQQFqQQF2IQQMAQtBACEEIAMhBgsgBkEBaiEDAkADQCADQX9qIgNFDQEgACgCGCAAKAIEIAAoAhwoAhARAgBFDQALQQEPCyAAKAIEIQVBASEDIAAoAhggASACIAAoAhwoAgwRBAANACAEQQFqIQMgACgCHCEBIAAoAhghAANAIANBf2oiA0UEQEEADwsgACAFIAEoAhARAgBFDQALQQEPCyADDwsgACgCGCABIAIgAEEcaigCACgCDBEEAAvDBwIGfwJ+AkACQAJAAkAgAkUNAEEAIAFrQQAgAUEDcRshCCACQXlqQQAgAkEHSxshBwNAAkAgASAEai0AACIFQRh0QRh1IgZBf0wEQEKAgICAgCAhCiAFQbKxygBqLQAAQX5qIgNBAksEQEKAgICAECEJDAcLAkACQAJAAkACQCADQQFrDgIBAgALIARBAWoiAyACSQ0CQgAhCQwJC0IAIQkgBEEBaiIDIAJPDQggASADai0AACEDAkACQCAFQaB+aiIFQQ1LDQACQAJAIAVBAWsODQICAgICAgICAgICAgEACyADQeABcUGgAUYNAkKAgICAECEJDAwLIANBGHRBGHVBf0oEQEKAgICAECEJDAwLIANBoAFJDQFCgICAgBAhCQwLCyAGQR9qQf8BcUELTQRAIANBGHRBGHVBf0oEQEKAgICAECEJDAwLIANBwAFJDQFCgICAgBAhCQwLCyADQb8BSwRAQoCAgIAQIQkMCwsgBkH+AXFB7gFHBEBCgICAgBAhCQwLCyADQRh0QRh1QX9MDQBCgICAgBAhCQwKC0IAIQogBEECaiIDIAJPDQkgASADai0AAEHAAXFBgAFGDQIMBwtCACEJIARBAWoiAyACTw0HIAEgA2otAAAhAwJAAkAgBUGQfmoiBUEESw0AAkACQCAFQQFrDgQCAgIBAAsgA0HwAGpB/wFxQTBJDQJCgICAgBAhCQwLCyADQRh0QRh1QX9KBEBCgICAgBAhCQwLCyADQZABSQ0BQoCAgIAQIQkMCgsgA0G/AUsEQEKAgICAECEJDAoLIAZBD2pB/wFxQQJLBEBCgICAgBAhCQwKCyADQRh0QRh1QX9MDQBCgICAgBAhCQwJCyAEQQJqIgMgAk8NByABIANqLQAAQcABcUGAAUcNBkIAIQogBEEDaiIDIAJPDQggASADai0AAEHAAXFBgAFGDQFCgICAgIDgACEKQoCAgIAQIQkMCAtCgICAgBAhCSABIANqLQAAQcABcUGAAUcNBwsgA0EBaiEEDAELIAggBGtBA3FFBEACQCAEIAdPDQADQCABIARqIgNBBGooAgAgAygCAHJBgIGChHhxDQEgBEEIaiIEIAdJDQALCyAEIAJPDQEDQCABIARqLAAAQQBIDQIgAiAEQQFqIgRHDQALDAMLIARBAWohBAsgBCACSQ0ACwsgACABNgIEIABBCGogAjYCACAAQQA2AgAPC0KAgICAgMAAIQpCgICAgBAhCQwBC0IAIQoLIAAgCSAErYQgCoQ3AgQgAEEBNgIAC9cGAQx/IwBBwAFrIgUkAAJ/IAIEQEEBIAEtAABBL0YNARoLQQALIQYgBSAFKABgNgIIIAUgBUHjAGooAAA2AAsCfyAEBEBBASADLQAAQS9GDQEaC0EACyEHIAVBKWogBSgAYDYAACAFQSxqIAVB4wBqKAAANgAAIAVBBjoAKCAFIAQ2AiQgBSADNgIgIAVBgAQ7AD0gBSAHOgA8IAVBhAFqIQwgBUHgAGpBBHIhDSAFQckAaiEDIAVBgAFqIQRBAiEIQQYhBwJ/AkADQCAHQQZHBEAgBUHvAGogBUEXaigAADYAACAFQegAaiAFQRBqKQIANwMAIAUgBSkCCDcDYAsgAyAFKQNgNwAAIANBCGoiDiAFQegAaikDADcAACADQQ9qIg8gBUHvAGooAAA2AAAgBSAHOgBIIAUgAjYCRCAFIAE2AkAgBSAIOgBeIAUgCzoAXSAFIAZBAEc6AFwgBUHgAGogBUFAaxAcIAVBoAFqIAVBIGoQHCAEQRhqIAVBuAFqKQMANwIAIARBEGogBUGwAWopAwA3AgAgBEEIaiAFQagBaikDADcCACAEIAUpA6ABNwIAIAUoAoABIQkCQCAFKAJgIgpBBUYEQCAJQQVHDQMMAQsgCUEFRg0AIAkgCkcNAgJAIApBBEsNAAJAAkAgCkEBaw4EAgICAAELIAUoAmgiASAFKAKIAUcNBCAFKAJkIgIgBSgChAEiBkYNASACIAYgARC0Aw0EDAELIA0gDBBPRQ0DCyAFQRBqIA4pAAA3AwAgBUEXaiAPKAAANgAAIAUgAykAADcDCCAFKAJAIQEgBSgCRCECIAUtAEghByAFLQBcIQYgBS0AXSELIAUtAF4hCCAFLQBfIRAMAQsLIAVBrwFqIgQgBUEXaigAADYAACAFQagBaiIDIAVBEGopAwA3AwAgBSAFKQMINwOgASAGQQJGDQAgBUHpAGogBSkDoAE3AAAgBUHxAGogAykDADcAACAFQfgAaiAEKAAANgAAIAUgBzoAaCAFIAI2AmQgBSABNgJgIAUgEDoAfyAFIAg6AH4gBSALOgB9IAUgBjoAfCAFIAVB4ABqECUgBSgCBCEEIAUoAgAMAQtBAAshASAAIAQ2AgQgACABNgIAIAVBwAFqJAALogYCC38BfiMAQeACayIBJAAgABDEAiIGKAIkIQIgAUIANwMQIAZBJGohCSABQRhqIQcgAUEcaiELA0ACQCACRQRAIAZBIGoQ0AQgASgCFCEDIAECfyABKAIQIgRBCE0EQCABKAIcDAELIAEoAhwLIgA2AsACIAEgBDYC0AIgASgCGCEIIAFB0AFqIAFBIGpB2AAQ8gMaQQAhAiABQcACaiABQdACaiAEQQhLIgcbQQA2AgAgASgC0AIhBiABKALAAiEFIAFB+ABqIAFB0AFqQdgAEPIDGiABQdwBaiAFNgIAIAFB2AFqIgUgCDYCACABIAM2AtQBIAEgBjYC0AEgAUHgAWogAUH4AGpB2AAQ8gMaIAEgACAEIAcbIgM2ArwCIAFBADYCuAIMAQsgAigCGCEEIAAgAigCFEcEQCACQRhqIQkgAiEIIAQhAgwCCyAJIAQ2AgAgAiAGKAIoRgRAIAYgCDYCKAsgAkEANgIcIAFB0AFqIAIQmQMCQAJ/IAEoAhAiA0EISyIFRQRAQQghAiADDAELIAMhAiABKAIcCyIKIAJHDQACfyAFRQRAQQghAiADDAELIAMhAiABKAIcCyEFIAIgBUcNACABQQhqIAVBAWoiAiAFTyACEMIDIAFBEGogASgCDEF/IAEoAggbEKUBIAEoAhAhAwsCfyADQQhNBEAgByECIAFBEGoMAQsgASgCGCECIAsLIApBAWo2AgAgAiAKQQxsaiICIAEpA9ABNwIAIAJBCGogAUHYAWooAgA2AgAgBCECDAELCwNAAkAgAiADRgRAIAFBAjoA2AIMAQsgASACQQFqNgK4AiABQdgCaiIAAn8gBSABKALQAUEITQ0AGiABKALYAQsgAkEMbGoiAkEIaigCACIENgIAIAEgAikCADcD0AIgBEH/AXFBAkYNACABQcgCaiAAKAIAIgI2AgAgASABKQPQAiIMNwPAAiAAIAI2AgAgASAMNwPQAiABQdACahDzBCABKAK8AiEDIAEoArgCIQIMAQsLIAFB0AJqEP8DIAFB0AFqEMUCIAFB0AFqEJ0CIAFB4AJqJAALlQYBB38CQAJAAkACQAJAAkACQAJAAkAgAEGAgARPBEAgAEGAgAhJDQEgAEHii3RqQeKNLEkgAEGfqHRqQZ8YSXIgAEH+//8AcUGe8ApGIABB3uJ0akEOSXJyIABBqbJ1akEpSSAAQcuRdWpBC0lycg0IIABBkPxHakGP/AtLDwsgAEGA/gNxQQh2IQZBgLbKACEBIABB/wFxIQcDQCABQQJqIQUgAiABLQABIgRqIQMgBiABLQAAIgFHBEAgASAGSw0IIAMhAiAFIgFB0rbKAEcNAQwICyADIAJJDQIgA0GlAksNAyACQdK2ygBqIQECQANAIARFDQEgBEF/aiEEIAEtAAAgAUEBaiEBIAdHDQALQQAhBAwJCyADIQIgBSIBQdK2ygBHDQALDAYLIABBgP4DcUEIdiEGQbG7ygAhASAAQf8BcSEHA0AgAUECaiEFIAIgAS0AASIEaiEDIAYgAS0AACIBRwRAIAEgBksNBiADIQIgBSIBQfe7ygBHDQEMBgsgAyACSQ0DIANBpgFLDQQgAkH3u8oAaiEBAkADQCAERQ0BIARBf2ohBCABLQAAIAFBAWohASAHRw0AC0EAIQQMCAsgAyECIAUiAUH3u8oARw0ACwwECyACIAMQ5gIACyADQaUCEOUCAAsgAiADEOYCAAsgA0GmARDlAgALIABB//8DcSEAQZ29ygAhAUEBIQQDQAJAAn8gAUEBaiIDIAEtAAAiAkEYdEEYdSIFQQBODQAaIANBtcDKAEYNASABLQABIAVB/wBxQQh0ciECIAFBAmoLIQEgACACayIAQQBIDQMgBEEBcyEEIAFBtcDKAEcNAQwDCwtB6arKAEErQfC1ygAQzgMACyAAQf//A3EhAEH3uMoAIQFBASEEA0ACfyABQQFqIgMgAS0AACICQRh0QRh1IgVBAE4NABogA0Gxu8oARg0DIAEtAAEgBUH/AHFBCHRyIQIgAUECagshASAAIAJrIgBBAEgNASAEQQFzIQQgAUGxu8oARw0ACwsgBEEBcQ8LQemqygBBK0HwtcoAEM4DAAuhBgEKfyMAQTBrIgMkACADQSRqIAE2AgAgA0EDOgAoIANCgICAgIAENwMIIAMgADYCICADQQA2AhggA0EANgIQAkACQAJAIAIoAggiBQRAIAIoAgAhByACKAIEIgkgAkEMaigCACIEIAQgCUsbIgtFDQEgAkEUaigCACEIIAIoAhAhCkEBIQQgACAHKAIAIAcoAgQgASgCDBEEAA0DIAdBDGohAkEBIQYCQAJAA0AgAyAFQQRqKAIANgIMIAMgBUEcai0AADoAKCADIAVBCGooAgA2AgggBUEYaigCACEEQQAhAUEAIQACQAJAAkAgBUEUaigCAEEBaw4CAAIBCyAEIAhPDQMgBEEDdCAKaiIMKAIEQbcBRw0BIAwoAgAoAgAhBAtBASEACyADIAQ2AhQgAyAANgIQIAVBEGooAgAhBAJAAkACQCAFQQxqKAIAQQFrDgIAAgELIAQgCE8NBCAEQQN0IApqIgAoAgRBtwFHDQEgACgCACgCACEEC0EBIQELIAMgBDYCHCADIAE2AhggBSgCACIAIAhJBEAgCiAAQQN0aiIAKAIAIANBCGogACgCBBECAA0GIAYgC08NBSACQXxqIQAgAigCACEBIAJBCGohAiAFQSBqIQVBASEEIAZBAWohBiADKAIgIAAoAgAgASADKAIkKAIMEQQARQ0BDAcLC0G0rsoAIAAgCBDkAgALQcSuygAgBCAIEOQCAAtBxK7KACAEIAgQ5AIACyACKAIAIQcgAigCBCIJIAJBFGooAgAiBCAEIAlLGyIIRQ0AIAIoAhAhBUEBIQQgACAHKAIAIAcoAgQgASgCDBEEAA0CIAdBDGohAkEBIQYDQCAFKAIAIANBCGogBUEEaigCABECAA0CIAYgCE8NASACQXxqIQAgAigCACEBIAJBCGohAiAFQQhqIQUgBkEBaiEGIAMoAiAgACgCACABIAMoAiQoAgwRBABFDQALDAILIAkgBksEQEEBIQQgAygCICAHIAZBA3RqIgAoAgAgACgCBCADKAIkKAIMEQQADQILQQAhBAwBC0EBIQQLIANBMGokACAEC/sFAgh/AX4jAEHQAGsiAiQAIAIgATYCLCAAKAIEIQEgAkEBOgA8IAJBAzYCOCACIAFBAWo2AjQgAkEANgIwQQEhAQNAAkAgAUH/AXFFBEAgAkEYaiACQTBqIAIoAjgQ8AQgAgJ/IAIoAhhBAUcEQEEAIQMgAigCNAwBCyACKAIcIgFBAWogAigCNCIDIAEgA0kiAxsLNgIwDAELIAJBADoAPCACQSBqIAJBMGoQ+QIgAigCJCEBIAIoAiAhAwsgAwRAIAAoAgAgAWoiASABKAIAIgFBB3ZBf3NBgYKECHEgAUH//v37B3JqNgIAIAItADwhAQwBBSAAKAIAIQECQCAAKAIEQQFqIgNBBE8EQCABIANqIAEoAAA2AAAMAQsgAUEEaiABIAMQrQIgACgCBCIBIAAoAgBqQQFqQYABQQMgAWsQwQQaCyACQRBqQQAgACgCBEEBahCmBSACIAIpAxA3AzADQCACQQhqIAJBMGoQ+QIgAigCCEUEQCAAIAAoAgQiAUEITwR/IAFBAWpBA3ZBB2wFIAELIAAoAgxrNgIQIAJB0ABqJAAPCyACKAIMIgEgACgCAGotAABBgAFHDQACQANAIAAgACgCCCABQQxsaiIDEKUEIgoQhQIhBCABIAAoAgQiBSAKpyIGcSIHayAEIAdrcyAFcUEESQ0BIAAoAgAiByAEaiIILQAAIAggBkEZdiIGOgAAIAcgBSAEQXxqcWpBBGogBjoAAEH/AUcEQCAAKAIIIARBDGxqIgQpAgAhCiAEIAMpAgA3AgAgBEEIaiIEKAIAIQUgBCADQQhqIgQoAgA2AgAgAyAKNwIAIAQgBTYCAAwBCwsgACgCACIFIAFqQf8BOgAAIAUgACgCBCABQXxqcWpBBGpB/wE6AAAgA0EIaigCACEBIAAoAgggBEEMbGoiBCADKQIANwIAIARBCGogATYCAAwBCyAAKAIAIgMgAWogBkEZdiIEOgAAIAMgBSABQXxqcWpBBGogBDoAAAwACwALAAsAC9AFAQd/QStBgIDEACAAKAIAIglBAXEiBRshCiAEIAVqIQgCQCAJQQRxRQRAQQAhAQwBCyACBEAgAiEGIAEhBQNAIAcgBS0AAEHAAXFBgAFGaiEHIAVBAWohBSAGQX9qIgYNAAsLIAIgCGogB2shCAtBASEFAkAgACgCCEEBRwRAIAAgCiABIAIQuAMNASAAKAIYIAMgBCAAQRxqKAIAKAIMEQQAIQUMAQsgAEEMaigCACIGIAhNBEAgACAKIAEgAhC4Aw0BIAAoAhggAyAEIABBHGooAgAoAgwRBAAPCwJAIAlBCHFFBEBBACEFIAYgCGsiBiEIAkACQAJAQQEgAC0AICIHIAdBA0YbQQFrDgMBAAECCyAGQQF2IQUgBkEBakEBdiEIDAELQQAhCCAGIQULIAVBAWohBQNAIAVBf2oiBUUNAiAAKAIYIAAoAgQgACgCHCgCEBECAEUNAAtBAQ8LIAAoAgQhCSAAQTA2AgQgAC0AICELIABBAToAICAAIAogASACELgDDQFBACEFIAYgCGsiASECAkACQAJAQQEgAC0AICIGIAZBA0YbQQFrDgMBAAECCyABQQF2IQUgAUEBakEBdiECDAELQQAhAiABIQULIAVBAWohBQJAA0AgBUF/aiIFRQ0BIAAoAhggACgCBCAAKAIcKAIQEQIARQ0AC0EBDwsgACgCBCEBQQEhBSAAKAIYIAMgBCAAKAIcKAIMEQQADQEgAkEBaiEHIAAoAhwhAiAAKAIYIQMDQCAHQX9qIgcEQCADIAEgAigCEBECAEUNAQwDCwsgACALOgAgIAAgCTYCBEEADwsgACgCBCEGQQEhBSAAIAogASACELgDDQAgACgCGCADIAQgACgCHCgCDBEEAA0AIAhBAWohByAAKAIcIQEgACgCGCEAA0AgB0F/aiIHRQRAQQAPCyAAIAYgASgCEBECAEUNAAsLIAULuQUCE38CfiMAQUBqIgEkABDIBCIEKAIAIQcgAUEoaiAEKAIIIgQQtgMgByAEQQN0aiEQQQAhBANAIAcgEEcEQCAHKAIAIQogASAHKAIEIgw2AhQgASAKNgIQQQAhCCABQQA2AjwgAUEQaiABQTxqEKcFIAEoAjwiDUEZdiILQQh0IAtyIglBEHQgCXIhESAEQQFqIQkgB0EIaiEHIAEoAiwiDiANcSEDIAEoAjAhEiABKAIoIRMCQAJAA0AgAyATaigAACIPIBFzIgZBf3MgBkH//ft3anFBgIGChHhxIQIgCEEEaiIIIANqIA5xIQYDQCABQQhqIAIQzAQgASgCCEUEQCAGIQMgDyAPQQF0cUGAgYKEeHFFDQIMAwsgAkF/aiACcSECIAogDCASIAEoAgwgA2ogDnFBDGxqIgUoAgAgBSgCBBC/BUUNAAsLIAUNAQsgASABQShqNgI8IAEoAjhFBEAgAUEoaiABQTxqEIQCCyABKAIsIgggDXEhA0EEIQIgASgCKCEFA0AgASAFIAMiBmooAABBgIGChHhxEMwEIAIgA2ogCHEhAyACQQRqIQIgASgCAEEBRw0ACyAFIAEoAgQgBmogCHEiAmosAABBAE4EQCAFKAIAQYCBgoR4cRDSBSECCyABIAEoAjggASgCKCIDIAJqIgYtAABBAXFrNgI4IAEoAjAhBSAGIAs6AAAgAyABKAIsIAJBfGpxakEEaiALOgAAIAJBDGwgBWoiAyAEOwEIIAMgDDYCBCADIAo2AgAgASABKAI0QQFqNgI0IAkhBAwCCyAFIAQ7AQggCSEEDAELCyABQSBqIAFBOGooAgAiBDYCACABQRhqIAFBMGopAwAiFDcDACABIAEpAygiFTcDECAAQRBqIAQ2AgAgAEEIaiAUNwIAIAAgFTcCACABQUBrJAAL8AUCA38CfiMAQfAEayIHJAAgBEHAAEcEQCAHQZgDakLJgICAgAg3AwAgB0GUA2pBqoHAADYCACAHQZADakEJNgIAIAdBAzoAiAMgByAHLwDEATsAiQMgB0GhgcAANgKMAyAHIAdBxgFqLQAAOgCLA0HzgcAAQSsgB0GIA2pBoILAAEHsg8AAEKgCAAsgB0HoBGoiBEIANwMAIAdB4ARqIghCADcDACAHQdgEaiIJQgA3AwAgB0IANwPQBCAHQdAEakEgIANBIBCuASAHQdAEahDIAyAHQaADaiAEKQMANwMAIAdBmANqIAgpAwA3AwAgB0GQA2ogCSkDADcDACAHIAcpA9AENwOIAyAHIAdBiANqELsDIAdB2ABqIgRCADcDACAHQdAAaiIIQgA3AwAgB0HIAGoiCUIANwMAIAdCADcDQCAHQUBrQSAgA0EgakEgEK4BIAdBxgFqIgMgBy0ABjoAACAHQcwBaiAHQR9qLQAAOgAAIAdB1QFqIAkpAwA3AAAgB0HdAWogCCkDADcAACAHQeUBaiAEKQMANwAAIAcgBy8BADsBgAEgByAHLQACOgCCASAHIAcvAQQ7AcQBIAcgBygAGzYCyAEgByAHKQNANwDNASAHKQAHIQogBykADyELIAcoABchBCAHLQADIQggB0GIA2ogB0HIAWpBJRDyAxogByAIOgCDASAHIAQ2AJcBIAcgCzcAjwEgByAKNwCHASAHIAcvAcQBOwGEASAHIAMtAAA6AIYBIAdBmwFqIAdBiANqQSUQ8gMaIAdBiANqIAEgAhBeIAdByAFqIAdBiANqQYiEwAAQxwIgB0FAayAHQYABaiAFIAYgB0HIAWoQ4wEgB0GIA2pBAEHAABDBBBogB0GIA2pBICAHQUBrQSAQrgEgB0GoA2pBICAHQeAAakEgEK4BIAcgBy0AxwNBgAFyOgDHAyAAIAcgB0GIA2pBwAAQ8gMiAEHAABCcAyAAQYABahCfASAAQfAEaiQAC7IFARB/IwBBgAJrIgQkACAEQfgAaiIFIANBGGopAAA3AwAgBEHwAGoiBiADQRBqKQAANwMAIARB6ABqIgcgA0EIaikAADcDACAEIAMpAAA3A2AgBEHAAWogASACIARB4ABqEO0BIARBGGoiAyAEQdgBaikDADcDACAEQRBqIgggBEHQAWopAwA3AwAgBEEIaiIJIARByAFqKQMANwMAIAQgBCkDwAE3AwAgBEE4aiIKIARB+AFqIgspAwA3AwAgBEEwaiIMIARB8AFqIg0pAwA3AwAgBEEoaiIOIARB6AFqIg8pAwA3AwAgBCAEKQPgATcDICAEQdgAaiIQQgA3AwAgBEHQAGoiEUIANwMAIARByABqIhJCADcDACAEQgA3A0AgBEHAAWpBAEHAABDBBBogBEHgAGogAUHAAWoQ1gMgBEHAAWpBICAEQeAAakEgEK4BIARB4AFqQSAgAUHgAWoiE0EgEK4BIARB4ABqIARBwAFqQcAAEPIDGiAEQawBakHAADYCACAEQSA2AqQBIAQgEzYCoAEgBCAEQeAAajYCqAEgAkHmhsAAQQogBEFAa0EgIARBoAFqQQIQigUgBEG4AWogAUHYAWopAAA3AwAgBEGwAWogAUHQAWopAAA3AwAgBEGoAWogAUHIAWopAAA3AwAgBCABKQDAATcDoAEgBSADKQMANwMAIAYgCCkDADcDACAHIAkpAwA3AwAgBCAEKQMANwNgIARBwAFqIARBoAFqIARB4ABqEBIgDyASKQMANwMAIA0gESkDADcDACALIBApAwA3AwAgBCAEKQNANwPgASAAIARBwAFqQcAAEPIDIgBB2ABqIAopAwA3AAAgAEHQAGogDCkDADcAACAAQcgAaiAOKQMANwAAIAAgBCkDIDcAQCACELcFIARBgAJqJAALpQUBBH8jAEGAFGsiBCQAIARBCGogAUEFEGcgBEGIAmogA0EIEGdBgAIhBUH/ASEGQf8BIQcDQAJAIAchAyAGIgFBf0YNACAEQQhqIAFqLQAABEAgASEDDAELIAFBf2ohBiABIQcgBUF/aiIFIQMgBEGIAmogAWotAABFDQELCyAEQYgEaiACEMcBIARBiA5qQQBBKBDBBBogBEG4DmpCADcDACAEQcAOakIANwMAIARByA5qQgA3AwAgBEHQDmpCADcDACAEQeAOakIANwMAIARB6A5qQgA3AwAgBEHwDmpCADcDACAEQfgOakIANwMAIARCATcDsA4gBEIBNwPYDgNAIARBgA9qIARBiA5qEKMBAkAgBEGAD2oCfyAEQQhqIANqLAAAIgFBAU4EQCAEQcARaiAEQYAPahCDAiAEQeASaiAEQYgEaiABEPgDIARBoBBqIARBwBFqIARB4BJqEJIBIARBoBBqDAELIAFBf0oNASAEQcARaiAEQYAPahCDAiAEQeASaiAEQYgEakEAIAFrQRh0QRh1EPgDIARBoBBqIARBwBFqIARB4BJqEJMBIARBoBBqC0GgARDyAxoLAkAgBEGAD2oCfyAEQYgCaiADaiwAACIBQQFOBEAgBEHgEmogBEGAD2oQgwIgBEGgEGogARD5AyAEQcARaiAEQeASaiAEQaAQahCZASAEQcARagwBCyABQX9KDQEgBEHgEmogBEGAD2oQgwIgBEGgEGpBACABa0EYdEEYdRD5AyAEQcARaiAEQeASaiAEQaAQahCaASAEQcARagtBoAEQ8gMaCyAEQeASaiAEQYAPahDyAiAEQYgOaiAEQeASakH4ABDyAxogAwRAIANBf2ohAwwBCwsgACAEQYgOahCWAiAEQYAUaiQAC6UFAQR/IwBBgBRrIgQkACAEQQhqIAFBBRBnIARBiAJqIANBCBBnQYACIQVB/wEhBkH/ASEHA0ACQCAHIQMgBiIBQX9GDQAgBEEIaiABai0AAARAIAEhAwwBCyABQX9qIQYgASEHIAVBf2oiBSEDIARBiAJqIAFqLQAARQ0BCwsgBEGIBGogAhDIASAEQYgOakEAQSgQwQQaIARBuA5qQgA3AwAgBEHADmpCADcDACAEQcgOakIANwMAIARB0A5qQgA3AwAgBEHgDmpCADcDACAEQegOakIANwMAIARB8A5qQgA3AwAgBEH4DmpCADcDACAEQgE3A7AOIARCATcD2A4DQCAEQYAPaiAEQYgOahCjAQJAIARBgA9qAn8gBEEIaiADaiwAACIBQQFOBEAgBEHAEWogBEGAD2oQgwIgBEHgEmogBEGIBGogARD6AyAEQaAQaiAEQcARaiAEQeASahCSASAEQaAQagwBCyABQX9KDQEgBEHAEWogBEGAD2oQgwIgBEHgEmogBEGIBGpBACABa0EYdEEYdRD6AyAEQaAQaiAEQcARaiAEQeASahCTASAEQaAQagtBoAEQ8gMaCwJAIARBgA9qAn8gBEGIAmogA2osAAAiAUEBTgRAIARB4BJqIARBgA9qEIMCIARBoBBqIAEQ+wMgBEHAEWogBEHgEmogBEGgEGoQmQEgBEHAEWoMAQsgAUF/Sg0BIARB4BJqIARBgA9qEIMCIARBoBBqQQAgAWtBGHRBGHUQ+wMgBEHAEWogBEHgEmogBEGgEGoQmgEgBEHAEWoLQaABEPIDGgsgBEHgEmogBEGAD2oQ8gIgBEGIDmogBEHgEmpB+AAQ8gMaIAMEQCADQX9qIQMMAQsLIAAgBEGIDmoQlgIgBEGAFGokAAv/BAEFfyMAQYABayIEJAAgBEEFOgAYAkACQAJAAkACQCABKAIAIgVBAUYgBUF+akECS3JFBEAgBEEgaiACIAMQYSAEKAIgQQFHDQEgBEHgAGogBEEYaiIDKAIAIgI2AgAgBEHYAGogBEEQaiIFKQMANwMAIAQgBCkDCDcDUCAEQfgAaiAEQTRqKAIANgIAIARB8ABqIARBLGopAgA3AwAgBCAEKQIkNwNoIARBQGsiBiAEQegAaiAEQdAAaiACQf8BcUEFRiIHGyICQQhqKQIANwMAIARByABqIgggAkEQaigCADYCACAEIAIpAgA3AzggBEHQAGogBEHoAGogBxsQmAUgBSAGKQMANwMAIAMgCCgCADYCACAEIAQpAzg3AwgMBAsgBEEgaiABIAIgAxCnASAELQAwQQVHDQEgAEEFOgAQIARBIGoQmAUMAgsgBEEoaigCACECIAQoAiQhAyABKAIAIgVBAUdBACAFQX5qQQNJG0UEQCABEIwFCyABIAI2AgQgASADNgIAIABBBToAEAwBCyAEQQhqEJgFIARBGGogBEEwaigCADYCACAEQRBqIARBKGopAwA3AwAgBCAEKQMgNwMIDAELIARBCGoQmAUMAQsgASgCACIBQX5qIQIgAUECRyACQQJLckUEQEGh+ckAQShBzPnJABC5BAALIAFBA0ZBACACQQJNG0UEQCAELQAYQQVHBEAgBEEwaiAEQRhqKAIANgIAIARBKGogBEEQaikDADcDACAEIAQpAwg3AyAgACAEQSBqEM8CDAILIABB6/jJAEEcEPwEIARBCGoQmAUMAQtBofnJAEEoQcz5yQAQuQQACyAEQYABaiQAC5sFAQF/IwBB8AZrIgIkACACQQhqIAEQmgIgAkEwaiACQQhqEEMCQAJAAkAgAkEwaiABEIwDQf8BcUUgAkEIahDCBEH/AXFBAUZyRQRAIAJB4ABqQgA3AwAgAkHoAGpCADcDACACQfAAakIANwMAIAJCADcDWCACQgE3A1AgAkH4AGogAkEIahDIBSACQaABaiACQdAAaiACQfgAahDfASACQcgBaiACQdAAaiACQfgAahDVAyACQfABaiACQcgBahDIBSACQbAEakGAucQAENkDIAJB0AVqIAJBoAFqEMgFIAJBiARqIAJBsARqIAJB0AVqEB4gAkGYAmogAkGIBGogAkHwAWoQ3wEgAkGwBGogAkGYAmogAkHwAWoQHiACQdAFaiACQbAEahCwAyACLQDQBSACQcACaiACQdgFakEoEPIDGiACQegCaiACQcACaiACQcgBahAeIAJB0AVqIAJB6AJqIAJBmAJqEB4gAkGQA2ogAkHAAmogAkHQBWoQHiACQdAFaiACQQhqIAJBCGoQ1QMgAkG4A2ogAkHQBWogAkHoAmoQHiACQbgDaiACQbgDahDCBBCrBCACQeADaiACQaABaiACQZADahAeIAJBiARqIAJBuANqIAJB4ANqEB5FDQIgAkGIBGoQwgRB/wFxQQFHDQEMAgsgAEIANwMADAILIAJB4ANqEJUDQf8BcUEBRg0AIAJB0AVqIAJBuANqQSgQ8gMaIAJB+AVqIAJB4ANqQSgQ8gMaIAJBoAZqIAJB0ABqQSgQ8gMaIAJByAZqIAJBiARqQSgQ8gMaIAJBsARqIAJB0AVqQaABEPIDGiAAQQhqIAJBsARqQaABEPIDGiAAQgE3AwAMAQsgAEIANwMACyACQfAGaiQAC5UGAgZ/BH4jAEHgAGsiAyQAIABBMGohBgJAIABB0ABqKAIAIgRFBEAgAiEEDAELIANBKGogASACIAJBICAEayIEIAQgAksbIgUQngQgAygCLCEHIAMoAighCCADQSBqIAUgAiABIAIQ1AMgAygCJCEEIAMoAiAhASADQRhqIAAoAlBBICAGQSAQ1AMgA0EQaiADKAIYIAMoAhwgBRCeBCADKAIQIAMoAhQgCCAHELIBIAAgACgCUCAFaiIFNgJQIAVBIEcNACADQQhqIAYQnwQgAyADKQMINwMwIABBKGopAwAhCSAAQSBqKQMAIQogAEEYaikDACELIAApAxAhDANAIANBOGogA0EwahCQAiADKQM4QgFRBEAgAykDWELP1tO+0ser2UJ+IAl8Qh+JQoeVr6+Ytt6bnn9+IQkgAykDUELP1tO+0ser2UJ+IAp8Qh+JQoeVr6+Ytt6bnn9+IQogAykDSELP1tO+0ser2UJ+IAt8Qh+JQoeVr6+Ytt6bnn9+IQsgAykDQELP1tO+0ser2UJ+IAx8Qh+JQoeVr6+Ytt6bnn9+IQwMAQsLIABBADYCUCAAIAk3AyggACAKNwMgIAAgCzcDGCAAIAw3AxALIAQEQCADIAQ2AjQgAyABNgIwIABBKGopAwAhCSAAQSBqKQMAIQogAEEYaikDACELIAApAxAhDANAIANBOGogA0EwahCQAiADKQM4QgFRBEAgAykDWELP1tO+0ser2UJ+IAl8Qh+JQoeVr6+Ytt6bnn9+IQkgAykDUELP1tO+0ser2UJ+IAp8Qh+JQoeVr6+Ytt6bnn9+IQogAykDSELP1tO+0ser2UJ+IAt8Qh+JQoeVr6+Ytt6bnn9+IQsgAykDQELP1tO+0ser2UJ+IAx8Qh+JQoeVr6+Ytt6bnn9+IQwMAQsLIAAgCTcDKCAAIAo3AyAgACALNwMYIAAgDDcDECADKAIwIQQgAyAGQSAgAygCNCIBEJ4EIAMoAgAgAygCBCAEIAEQsgEgACABNgJQCyAAIAApAwAgAq18NwMAIANB4ABqJAALsQMBBX8jAEEQayICJAAgAkECciEEQeT5ygAoAgAhAQJAAkADQAJAAkAgAUEDSw0AAkACQCABQQFrDgMAAgUBC0G4o8oAQSpB5KPKABC8BAALQeT5ygBB5PnKACgCACIBQQIgARs2AgAgAQ0CDAELIAFBA3FBAkcNAwJAAkADQEH4+coAKAIAQQFHBEBB+PnKAEIBNwIAQYD6ygBBADYCAAsgASEDEJsBIQVB5PnKACAEQeT5ygAoAgAiASABIANGGzYCACACQQA6AAggAiAFNgIAIAIgA0F8cTYCBAJAIAEgA0YEQCACLQAIRQ0BDAMLAkAgAigCACIDRQ0AIAMgAygCACIDQX9qNgIAIANBAUcNACACENICCyABQQNxQQJGDQEMAwsLA0AQRSACLQAIRQ0ACwsgAigCACIBRQ0AIAEgASgCACIBQX9qNgIAIAFBAUcNACACENICQeT5ygAoAgAhAQwCC0Hk+coAKAIAIQEMAQsLIAJB5PnKADYCACAAQQBBnIzKACgCABEAACACQQM2AgQgAhBVCyACQRBqJAAPC0HvosoAQTlBqKPKABC8BAALtgMBA38jAEHQBGsiAiQAIAJBIGoQsgMgAkEgaiABEMYFIAJBuAJqIAJBIGpB2AEQ8gMaIAJB+AFqIAJBuAJqEO4DIAJBqARqIgFCADcDACACQaAEaiIDQgA3AwAgAkGYBGoiBEIANwMAIAJCADcDkAQgAkEYaiACQfgBahCpBSACQRBqQQBBICACKAIYIAIoAhwQ1AMgAkGQBGpBICACKAIQIAIoAhQQrQEgAiACLQCQBEH4AXE6AJAEIAIgAi0ArwRBP3FBwAByOgCvBCACQZAEahDIAyACQdACaiABKQMANwMAIAJByAJqIAMpAwA3AwAgAkHAAmogBCkDADcDACACIAIpA5AENwO4AiAAIAJBuAJqELsDIAJByARqIgFCADcDACACQcAEaiIDQgA3AwAgAkG4BGoiBEIANwMAIAJCADcDsAQgAkEIaiACQfgBahCpBSACQSBBwAAgAigCCCACKAIMENQDIAJBsARqQSAgAigCACACKAIEEK0BIABBOGogASkDADcAACAAQTBqIAMpAwA3AAAgAEEoaiAEKQMANwAAIAAgAikDsAQ3ACAgAkHQBGokAAuUBQIGfwF+IwBB4ABrIggkACAIQQI6ACAgCEEIakGU7ckAELcEAn8gCCgCCARAIAhBOGoQSSAIQRBqEJcEIAhBEGogCEE4akEoEPIDGiAIQRBqIAgtACBBAkcNARpB6OzJAEErQYDuyQAQzgMACyAIKAIMCyEGIAEQxAIhBwJ/AkACQCACQezqyQAoAgARBgAEQCAFKQMAIQwgBkEANgIYIAYgDDwAJCAGQQA2AiAgBiABNgIUIAZBAToAECAHKAIoQRhqIAdBJGogBygCJBsgBjYCACAHIAY2AiggB0EgahDQBCADQYDryQAoAgARAwAgBSkDAEIBUQ0BIAYQ5gEMAgsgB0EgahDQBEEBDAILIAYgBSkDCCAFQRBqKAIAEIsBDQACQANAAkAQkAMhASAGKAIUIgtBufPd8XlsQQAgASgCCGtBH3F2IgkgASgCBCICTw0AIAEoAgAiCiAJQfAAbGpBIGoiAhDxBCABQaDYygAoAgBGBEAgBigCFCALRg0DCyACENAEDAELC0HA7skAIAkgAhDkAgALAkAgBCALAn8CQCAGELMDBEAgCiAJQfAAbGoiAUEkaiEDIAEoAiQhBUEAIQcDQCADIQEgByECIAUiB0UNBCAHQRhqIQMgBygCGCEFIAYgB0cNAAsgASAFNgIAIAYgCiAJQfAAbGoiASgCKEYEQCABQShqIAI2AgAMAgsDQCAFRQ0CIAsgBSgCFEcEQCAFKAIYIQUMAQsLQQAMAgsgCiAJQfAAbGpBIGoQ0AQMAwtBAQsiB0GU68kAKAIAEQEACyAKIAlB8ABsakEgahDQBEECDAELIAYoAhwhB0EACyEBIAhBEGoQlwQgACAHNgIEIAAgATYCACAIQeAAaiQAC8oEAQV/IwBBEGsiBCQAIAAoAgAhAAJAAkACQAJAAkACQCABQYABTwRAIARBADYCDCABQYAQSQ0BIARBDGohBSABQYCABEkEQCAEIAFBP3FBgAFyOgAOIAQgAUEGdkE/cUGAAXI6AA0gBCABQQx2QQ9xQeABcjoADEEDIQEMBAsgBCABQT9xQYABcjoADyAEIAFBEnZB8AFyOgAMIAQgAUEGdkE/cUGAAXI6AA4gBCABQQx2QT9xQYABcjoADUEEIQEMAwsgACgCCCICIABBBGooAgBHBEAgACgCACEDDAILIAJBAWoiAyACSQ0DIAJBAXQiBSADIAUgA0sbIgVBAEgNAwJ/IAJFBEAgBUEBEKQFDAELIAAoAgAgAkEBIAUQlAULIgMEQCAAIAM2AgAgAEEEaiAFNgIAIAAoAgghAgwCCyAFQQEQ3QUACyAEIAFBP3FBgAFyOgANIAQgAUEGdkEfcUHAAXI6AAwgBEEMaiEFQQIhAQwBCyACIANqIAE6AAAgACAAKAIIQQFqNgIIDAMLIABBBGooAgAiAyAAQQhqKAIAIgJrIAFPBEAgACgCACEDDAILIAEgAmoiBiACSQ0AIANBAXQiAiAGIAIgBksbIgJBAEgNAAJ/IANFBEAgAkEBEKQFDAELIAAoAgAgA0EBIAIQlAULIgMEQCAAIAM2AgAgAEEEaiACNgIAIABBCGooAgAhAgwCCyACQQEQ3QUACxDCBQALIABBCGogASACajYCACACIANqIAUgARDyAxoLIARBEGokAEEAC8EEAQV/IwBBEGsiBCQAAkACQAJAAkACQAJAIAFBgAFPBEAgBEEANgIMIAFBgBBJDQEgBEEMaiEFIAFBgIAESQRAIAQgAUE/cUGAAXI6AA4gBCABQQZ2QT9xQYABcjoADSAEIAFBDHZBD3FB4AFyOgAMQQMhAQwECyAEIAFBP3FBgAFyOgAPIAQgAUESdkHwAXI6AAwgBCABQQZ2QT9xQYABcjoADiAEIAFBDHZBP3FBgAFyOgANQQQhAQwDCyAAKAIIIgIgAEEEaigCAEcEQCAAKAIAIQMMAgsgAkEBaiIDIAJJDQMgAkEBdCIFIAMgBSADSxsiBUEASA0DAn8gAkUEQCAFQQEQpAUMAQsgACgCACACQQEgBRCUBQsiAwRAIAAgAzYCACAAQQRqIAU2AgAgACgCCCECDAILIAVBARDdBQALIAQgAUE/cUGAAXI6AA0gBCABQQZ2QR9xQcABcjoADCAEQQxqIQVBAiEBDAELIAIgA2ogAToAACAAIAAoAghBAWo2AggMAwsgAEEEaigCACIDIABBCGooAgAiAmsgAU8EQCAAKAIAIQMMAgsgASACaiIGIAJJDQAgA0EBdCICIAYgAiAGSxsiAkEASA0AAn8gA0UEQCACQQEQpAUMAQsgACgCACADQQEgAhCUBQsiAwRAIAAgAzYCACAAQQRqIAI2AgAgAEEIaigCACECDAILIAJBARDdBQALEMIFAAsgAEEIaiABIAJqNgIAIAIgA2ogBSABEPIDGgsgBEEQaiQAC8gEAQZ+IAAgASkDICIDQjOIQhN+IAEpAwAiAkL/////////A4N8IgRCE3xCM4ggASkDCCIFQv////////8DgyACQjOIfCICfEIziCABKQMQIgZC/////////wODIAVCM4h8IgV8QjOIIAEpAxgiB0L/////////A4MgBkIziHwiBnxCM4ggA0L/////////A4MgB0IziHwiB3xCM4hCE34gBHwiAzwAACAAIANCKIg8AAUgACADQiCIPAAEIAAgA0IYiDwAAyAAIANCEIg8AAIgACADQgiIPAABIAAgA0IziCACfCIEQiWIPAALIAAgBEIdiDwACiAAIARCFYg8AAkgACAEQg2IPAAIIAAgBEIFiDwAByAAIARCM4ggBXwiAkIqiDwAEiAAIAJCIog8ABEgACACQhqIPAAQIAAgAkISiDwADyAAIAJCCog8AA4gACACQgKIPAANIAAgA0IwiEIHgyAEQv////////8DgyIEQgOGhDwABiAAIAJCM4ggBnwiA0IniDwAGCAAIANCH4g8ABcgACADQheIPAAWIAAgA0IPiDwAFSAAIANCB4g8ABQgACACQv////////8DgyIFQgaGIARCLYiEPAAMIAAgA0IziCAHfCICQiSIPAAeIAAgAkIciDwAHSAAIAJCFIg8ABwgACACQgyIPAAbIAAgAkIEiDwAGiAAIANC/////////wODIgNCAYYgBUIyiIQ8ABMgACACQv////////8DgyICQiyIPAAfIAAgAkIEhiADQi+IhDwAGQuvBAEBfyMAQfAAayIDJAAgAyABOgALAkACQAJAIAJFBEAgAyABQQhxIgI6AAwgAg0CIAAgAToAygEgAC0AyQEhAiAAIAAtAMgBQQFqOgDJASADIAE6AFkgAyACOgBYIAAgA0HYAGpBAhDBAiADLQALQSRxRQ0BIAAtAMgBRQ0BIAAQnAIMAQsgAC0AygEgAUH/AXFHDQILIANB8ABqJAAPCyADQcwAakEhNgIAIANBxABqQSI2AgAgA0E0akEDNgIAIAMgA0EMajYCVCADQbD2wwA2AhAgA0HsAGpBADYCACADQgM3AiQgA0GI9cMANgIgIANBIjYCPCADQYDzwwA2AmggA0IBNwJcIANB8PbDADYCWCADIANBOGo2AjAgAyADQdgAajYCSCADIANBEGo2AkAgAyADQdQAajYCOCADQSBqQfj2wwAQvQQACyADQcwAakEhNgIAIANBxABqQSI2AgAgAyAAQcoBaiIANgIMIAMgA0ELajYCVCADQewAakECNgIAIANB5ABqQQI2AgAgA0EcakEjNgIAIANBIjYCPCADQeD1wwA2AmAgA0ECNgJcIANB0PXDADYCWCADQSM2AhQgAyAANgIQIAMgA0HYAGo2AkggAyADQdQAajYCQCADIANBDGo2AjggAyADQRBqNgJoIAMgA0ELajYCGCADQTRqQQM2AgAgA0IDNwIkIANBiPXDADYCICADIANBOGo2AjAgA0EgakGg9sMAEL0EAAvxBAEGfyMAQeAAayIAJABB+PnKACgCAEEBRwRAQfj5ygBCATcCAEGA+soAQQA2AgALEJsBIgFBACABKAIYIgIgAkECRiICGzYCGCAAIAE2AggCQCACDQACQAJAAkAgACgCCCIBQRxqIgQoAgAiAi0AAEUEQCACQQE6AABBACECAkBBiPrKACgCAEEBRgRAQYz6ygAoAgAhAgwBC0GI+soAQgE3AwALQYz6ygAgAjYCACABLQAgDQEgASABKAIYIgNBASADGzYCGCADRQRAIAAoAghBJGogBCgCABCoBEEAEMAFAAsgA0ECRw0CIAAoAggiBSgCGCEDIAVBADYCGCAAIAM2AgwgA0ECRw0DAkAgAg0AQYj6ygAoAgBBAUcEQEGI+soAQgE3AwAMAQtBjPrKACgCAEUNACABQQE6ACALIAQoAgBBADoAAAwEC0Hop8oAQSBBpKjKABC8BAALIAAgBDYCSCAAIAJBAEc6AExB9JzKAEErIABByABqQaCdygBB4J7KABCoAgALQfCeygBBF0GIn8oAELwEAAsgAEE8akEhNgIAIABBNGpBkgE2AgAgAEEkakEDNgIAIAAgAEEMajYCQCAAQZifygA2AkQgAEHcAGpBADYCACAAQgM3AhQgAEGAnMoANgIQIABBkgE2AiwgAEHsm8oANgJYIABCATcCTCAAQbyfygA2AkggACAAQShqNgIgIAAgAEHIAGo2AjggACAAQcQAajYCMCAAIABBQGs2AiggAEEQakHEn8oAEKkEAAsgACgCCCIBIAEoAgAiAUF/ajYCACABQQFGBEAgAEEIahDSAgsgAEHgAGokAAuFBAEHfyMAQTBrIgMkAAJ/QQAgAkUNABogA0EoaiEIAkACQAJAAkADQCAAKAIILQAABEAgACgCAEGcrMoAQQQgACgCBCgCDBEEAA0FCyADQQo2AiggA0KKgICAEDcDICADIAI2AhwgA0EANgIYIAMgAjYCFCADIAE2AhAgA0EIakEKIAEgAhBlAn8CQAJAIAMoAghBAUYEQCADKAIMIQQDQCADIAQgAygCGGpBAWoiBDYCGAJAIAQgAygCJCIFSQRAIAMoAhQhBwwBCyADKAIUIgcgBEkNACAFQQVPDQcgBCAFayIGIAMoAhBqIgkgCEYNBCAJIAggBRC0A0UNBAsgAygCHCIGIARJIAcgBklyDQIgAyADIAVqQSdqLQAAIAMoAhAgBGogBiAEaxBlIAMoAgQhBCADKAIAQQFGDQALCyADIAMoAhw2AhgLIAAoAghBADoAACACDAELIAAoAghBAToAACAGQQFqCyEEIAAoAgQhBSAAKAIAIARFIAIgBEZyIgZFBEAgAiAETQ0DIAEgBGosAABBv39MDQMLIAEgBCAFKAIMEQQADQQgBkUEQCACIARNDQQgASAEaiwAAEG/f0wNBAsgASAEaiEBIAIgBGsiAg0AC0EADAQLIAVBBBDlAgALIAEgAkEAIAQQKQALIAEgAiAEIAIQKQALQQELIANBMGokAAvsAwEKfwNAAkBBACEIIAEtAB0NACABKAIIIQoCfwJAA0AgASgCGCICIAEoAhQiBEYNASABIARBAWoiAzYCFAJAAkAgBCwAACIFQX9MBEACfyACIANGBEBBACEGIAIMAQsgASAEQQJqIgM2AhQgBC0AAUE/cSEGIAMLIQcgBUEfcSEJIAVB/wFxIgtB3wFLDQEgBiAJQQZ0ciECDAILIAVB/wFxIQIMAQsCfyACIAdGBEBBACEHIAIMAQsgASAHQQFqIgM2AhQgBy0AAEE/cSEHIAMLIQUgByAGQQZ0ciEGIAtB8AFJBEAgBiAJQQx0ciECDAELIAIgBUYEf0EABSABIAVBAWoiAzYCFCAFLQAAQT9xCyAJQRJ0QYCA8ABxIAZBBnRyciICQYCAxABGDQILIAEgASgCECIFIAMgBGtqIgQ2AhAgAkF3aiIDQRdNQQBBASADdEGfgIAEcRtFBEAgAkGAAUkNASACEPcBRQ0BCwsgASgCACEDIAEgBDYCACADIApqIQggBSADawwBCyABLQAdDQECQCABLQAcBEAgASgCBCEDIAEoAgAhAgwBCyABKAIEIgMgASgCACICRg0CCyABQQE6AB0gASgCCCACaiEIIAMgAmsLIgRFDQELCyAAIAQ2AgQgACAINgIAC4wEAQJ/IwBBwARrIgIkACACQQhqIAFBKBDyAxogAkEwaiABQShqQSgQ8gMaIAJBmARqIAFB0ABqIgMgAkEwahDVAyACQdABaiADIAJBMGoQ3wEgAkHYAGogAkGYBGogAkHQAWoQHiACQYABaiACQQhqIAJBMGoQHiACQZgEaiACQYABahDIBSACQfADaiACQdgAaiACQZgEahAeIAJB0AFqIAJB8ANqELADIAJBqAFqIAJB2AFqQSgQ8gMaIAJBgAJqIAJBqAFqIAJB2ABqEB4gAkGoAmogAkGoAWogAkGAAWoQHiACQdABaiACQagCaiABQfgAaiIBEB4gAkHQAmogAkGAAmogAkHQAWoQHiACQfgCaiACQagCakEoEPIDGiACQaADaiACQQhqQai5xAAQHiACQcgDaiACQTBqQai5xAAQHiACQfADaiACQYACakHQucQAEB4gAkHQAWogASACQdACahAeIAJBCGogAkHIA2ogAkHQAWoQwgQiARCIAiACQTBqIAJBoANqIAEQiAIgAkH4AmogAkHwA2ogARCIAiACQdABaiACQQhqIAJB0AJqEB4gAkEwaiACQdABahDCBBCrBCACQdABaiADIAJBMGoQ3wEgAkGYBGogAkH4AmogAkHQAWoQHiACQZgEaiACQZgEahDCBBCrBCAAIAJBmARqEEMgAkHABGokAAu5BAELfyMAQRBrIggkAEGc2MoAQZzYygAoAgBBAWoiBjYCAAJAQaDYygAoAgBFBEAgBkEAEJ0BIQFBoNjKAEGg2MoAKAIAIgIgASACGzYCACACRQ0BIAggATYCDCAIQQxqEP4DCyAGQQNsIQQDQEGg2MoAKAIAIgMoAgQiAiAETw0BIAJB8ABsIQEgAygCACECA0AgAQRAIAJBIGoQ8QQgAUGQf2ohASACQfAAaiECDAEFIANBoNjKACgCAEcEQCADKAIEQfAAbCEBIAMoAgAhAgNAIAFFDQQgAkEgahDQBCABQZB/aiEBIAJB8ABqIQIMAAsACyAGIAMQnQEhBSADKAIAIgEgAygCBEHwAGxqIQkCQAJAA0AgASAJRwRAIAFB8ABqIQIgASgCJCEBA0AgAUUEQCACIQEMAwsgASgCFEG5893xeWxBACAFKAIIa0EfcXYiByAFKAIEIgRPDQMgASgCGCAHQfAAbCILIAUoAgBqIgYoAigiBEEYaiAGQSRqIAQbIAE2AgAgByAFKAIEIgRPDQQgBSgCACALaiABNgIoIAFBADYCGCEBDAALAAsLQaDYygAgBTYCACADKAIEQfAAbCEBIAMoAgAhAgNAIAFFDQYgAkEgahDQBCABQZB/aiEBIAJB8ABqIQIMAAsAC0GQ7skAIAcgBBDkAgALQaDuyQAgByAEEOQCAAsACwALAAsgABDoAyAAQSRqQQA6AAAgAEEcakIANwIAIABCADcCFCAIQRBqJAALhgQBBn8jAEEgayIIJAAgASgCFCEHA0ACQCAFIAdqIgdBf2oiCSADTwRAIAEgAzYCFEEAIQcMAQsCQCABKQMAQgEgAiAJajEAAEI/g4aDUA0AIAEoAgghByAIQRhqIAYEfyAHBSAHIAEoAhwiCSAHIAlLGwsgBRCmBSAIKAIcIQogCCgCGCEHAkACQANAAkAgByAKSQRAIAdBAWoiCSAHTw0BCyAIQRBqQQAgASgCHCAGGyABKAIIEKYFIAhBCGogCCgCECAIKAIUEKYFIAEoAhQhCiAIKAIMIQcgCCgCCCEJAkACQANAIAkgB08EQCABIAUgCmoiAjYCFCAGRQRAIAFBADYCHAsgACAKNgIEIABBCGogAjYCAEEBIQcMCQsgB0F/aiIHIAVPDQEgByAKaiILIANPDQIgBCAHai0AACACIAtqLQAARg0ACyABIAEoAhAiCSAKaiIHNgIUIAYNCCABIAUgCWs2AhwMCAtBkPHIACAHIAUQ5AIAC0Gg8cgAIAsgAxDkAgALIAcgBU8NASABKAIUIAdqIgwgA08NAiAEIAdqIAkhBy0AACACIAxqLQAARg0ACyAMIAEoAghrQQFqIQcMAgtB8PDIACAHIAUQ5AIAC0GA8cgAIAwgAxDkAgALIAEgBzYCFCAGDQEgAUEANgIcDAELCyAAIAc2AgAgCEEgaiQAC/MDAgd/An4jAEHgAGsiAyQAIAMgAjYCDCADQTBqIAEQWyADIAMpATI3AyAgAyADQThqIgIpAQA3ASYCfwJAIAMtADBBAUcEQCADQcQAaigCACEEIANBGGogA0EqaigBACIFNgIAIAMgAykBIiIKNwMQIAAoAgwhASACIAU2AgAgAyAKNwMwIAMgBCABazYCQCADIAE2AjwgACgCACICIAAoAgRqQQFqIQggAigCAEF/c0GAgYKEeHEhASAAKAIIIQQMAQsgAy0AMUEARwwBCwNAIAMgARDMBCADKAIAQQFGBEAgA0EwaiAEIAMoAgRBDGxqIgUQpQQiChCFAiIGIAMoAjAiB2ogCqdBGXYiCToAACAHIAMoAjQgBkF8anFqQQRqIAk6AAAgBUEIaigCACEHIAMoAjggBkEMbGoiBiAFKQIANwIAIAZBCGogBzYCACABQX9qIAFxIQEMAQsgAkEEaiICIAhJBEAgBEEwaiEEIAIoAgBBf3NBgIGChHhxIQEMAQsLIAApAgAhCiAAIAMpAzA3AgAgA0E4aiIBKQMAIQsgASAAQQhqIgEpAgA3AwAgASALNwIAIANBQGsiASgCACECIAEgAEEQaiIAKAIANgIAIAAgAjYCACADIAo3AzAgA0EwahDYAkECCyADQeAAaiQAC+UDAgx/AX4gAiAFayEPQQAgBWshECABKAIQIQ0gASgCDCEKIAEpAwAhEyABKAIYIQgCQAJAA0AgCCAFayIJIANPBEBBACEHIAFBADYCGAwDC0IBIAIgCWoxAABCP4OGIBODUARAIAEgCTYCGCAJIQggBg0BIAEgBTYCIAwBCyAKIQcgCCAPaiEOIAYEfyAHBSABKAIgIgcgCiAKIAdLGwtBf2ohBwJAA0AgB0F/RgRAIAUgASgCICAGGyELIAggEGohDCAKIQcCQAJAA0AgByALTwRAIAEgCTYCGCAGRQRAIAEgBTYCIAsgACAJNgIEIABBCGogCDYCAEEBIQcMCQsgByAFTw0BIAcgDGogA08NAiAHIA5qIREgBCAHaiAHQQFqIQctAAAgES0AAEYNAAsgASAIIA1rIgg2AhggBg0FIAEgDTYCIAwFC0HYlsoAIAcgBRDkAgALQeiWygAgCCAFayAHaiADEOQCAAsgByAFTw0BIAcgCWogA08NAyAHIA5qIQsgBCAHaiAHQX9qIQctAAAgCy0AAEYNAAsgASAIIAprIAdqQQFqIgg2AhggBg0BIAEgBTYCIAwBCwtBuJbKACAHIAUQ5AIAC0HIlsoAIAggBWsgB2ogAxDkAgALIAAgBzYCAAuWBAIGfwR+IwBBwAFrIgIkACACQQhqQQBBwAAQwQQaA0ACQCADQQhHBEAgA0EBaiEHIAJBCGogA0EDdGohBUEAIQMgBiEEA0AgA0HAAEYNAiAEQcAARwRAIAUgBSkDACABIARqMQAAIANBOHGthoQ3AwAgA0EIaiEDIARBAWohBAwBCwtBnLvEACAEQcAAEOQCAAsgAiACKQMIIghC/////////weDNwNIIAIgAikDQCILQhSINwOQASACIAIpAygiCUIEiEL/////////B4M3A3AgAiACKQMQIgpCDIZCgOD//////weDIAhCNIiENwNQIAIgAikDGCIIQhiGQoCAgPj///8HgyAKQiiIhDcDWCACIAIpAyAiCkIkhkKAgICAgP7/B4MgCEIciIQ3A2AgAiAJQjCGQoCAgICAgMAHgyAKQhCIhDcDaCACIAIpAzAiCEIIhkKA/v//////B4MgCUI4iIQ3A3ggAiACKQM4IglCFIZCgIDA/////weDIAhCLIiENwOAASACIAtCIIZCgICAgPD//weDIAlCIIiENwOIASACQZgBaiACQcgAakGwu8QAEBYgAkHIAGogAkGYAWpBKBDyAxogAkGYAWogAkHwAGpB2LvEABAWIAJB8ABqIAJBmAFqQSgQ8gMaIAAgAkHwAGogAkHIAGoQjwIgAkHAAWokAA8LIAZBCGohBiAHIQMMAAsAC5YEAgZ/BH4jAEHAAWsiAiQAIAJBCGpBAEHAABDBBBoDQAJAIANBCEcEQCADQQFqIQcgAkEIaiADQQN0aiEFQQAhAyAGIQQDQCADQcAARg0CIARBwABHBEAgBSAFKQMAIAEgBGoxAAAgA0E4ca2GhDcDACADQQhqIQMgBEEBaiEEDAELC0H07MgAIARBwAAQ5AIACyACIAIpAwgiCEL/////////B4M3A0ggAiACKQNAIgtCFIg3A5ABIAIgAikDKCIJQgSIQv////////8HgzcDcCACIAIpAxAiCkIMhkKA4P//////B4MgCEI0iIQ3A1AgAiACKQMYIghCGIZCgICA+P///weDIApCKIiENwNYIAIgAikDICIKQiSGQoCAgICA/v8HgyAIQhyIhDcDYCACIAlCMIZCgICAgICAwAeDIApCEIiENwNoIAIgAikDMCIIQgiGQoD+//////8HgyAJQjiIhDcDeCACIAIpAzgiCUIUhkKAgMD/////B4MgCEIsiIQ3A4ABIAIgC0IghkKAgICA8P//B4MgCUIgiIQ3A4gBIAJBmAFqIAJByABqQYjtyAAQFyACQcgAaiACQZgBakEoEPIDGiACQZgBaiACQfAAakGw7cgAEBcgAkHwAGogAkGYAWpBKBDyAxogACACQfAAaiACQcgAahCSAiACQcABaiQADwsgBkEIaiEGIAchAwwACwALmwMBA38CQAJAAkACQAJAIAAtAAgiAiABLQAIRw0AAkACQAJAAkACQAJAIAJBAWsOBQEKAgMKAAsgAEEQaigCACICIAFBEGooAgBHDQUMCAsgAEEQaigCACICIAFBEGooAgBHDQYgAEEMaigCACIDIAFBDGooAgAiBEYNAiADIAQgAhC0A0UNAgwGCyAAQRBqKAIAIgIgAUEQaigCAEcNAwwGCyAAQRBqKAIAIgIgAUEQaigCAEcNAyAAQQxqKAIAIgMgAUEMaigCACIERg0BIAMgBCACELQDRQ0BDAMLIABBGGooAgAiAiABQRhqKAIARw0DQQEhAyAAQRRqKAIAIgAgAUEUaigCACIBRg0BIAAgASACELQDDQMMAQsgAEEYaigCACICIAFBGGooAgBHDQFBASEDIABBFGooAgAiACABQRRqKAIAIgFGDQAgACABIAIQtAMNAQsgAw8LQQAPC0EADwsgAEEMaigCACIAIAFBDGooAgAiAUYEQEEBDwsgACABIAIQtANFDwsgAEEJai0AACABQQlqLQAARgvxAwEHfyMAQRBrIgYkAEEBIQgCQCABKAIYQScgAUEcaigCACgCEBECAA0AIAYgACgCABB/IAZBDGotAAAhAyAGQQhqKAIAIQQgBigCACEAAkAgBigCBCIFQYCAxABGBEADQCAAIQJB3AAhBUEBIQACQAJAIAJBAmsOAgEABAsgA0H/AXEhAkEEIQNBAyEAAkACQAJAAkAgAkEBaw4FAwIBAAQHC0H1ACEFQQMhAwwDC0ECIQNB+wAhBQwCC0ECQQEgBBshA0GAgMQAIARBAnRBHHF2QQ9xQTByIQUgBEF/akEAIAQbIQQMAQtBACEDQf0AIQULIAEoAhggBSABKAIcKAIQEQIARQ0ADAMLAAsDQCAAIQdB3AAhAkEBIQACQAJAAkACQCAHQQFrDgMBAwAFCyADQf8BcSEHQQQhA0EDIQACQAJAAkAgB0EBaw4FAgEABAUHC0ECIQNB+wAhAgwECyAFIARBAnRBHHF2QQ9xIgJBMHIgAkHXAGogAkEKSRshAkECQQEgBBshAyAEQX9qQQAgBBshBAwDC0EAIQNB/QAhAgwCC0EAIQAgBSECDAELQfUAIQJBAyEDCyABKAIYIAIgASgCHCgCEBECAEUNAAsMAQsgASgCGEEnIAEoAhwoAhARAgAhCAsgBkEQaiQAIAgLhQUCAn8FfiMAQTBrIgEkAAJ+IAApAwAiA0IfWARAIAApAwhCxc/ZsvHluuonfAwBCyAAQRhqKQMAIgRCB4kgACkDECIFQgGJfCAAQSBqKQMAIgZCDIl8IABBKGopAwAiB0ISiXwgBULP1tO+0ser2UJ+Qh+JQoeVr6+Ytt6bnn9+hUKHla+vmLbem55/fkLj3MqV/M7y9YV/fCAEQs/W077Sx6vZQn5CH4lCh5Wvr5i23puef36FQoeVr6+Ytt6bnn9+QuPcypX8zvL1hX98IAZCz9bTvtLHq9lCfkIfiUKHla+vmLbem55/foVCh5Wvr5i23puef35C49zKlfzO8vWFf3wgB0LP1tO+0ser2UJ+Qh+JQoeVr6+Ytt6bnn9+hUKHla+vmLbem55/fkLj3MqV/M7y9YV/fAshBCABQRhqIABBMGoQnwQgASABKQMYNwMgIAMgBHwhAwN+IAFBCGogAUEgahC9AyABKQMIpwR+IAEpAxBCz9bTvtLHq9lCfkIfiUKHla+vmLbem55/fiADhUIbiUKHla+vmLbem55/fkLj3MqV/M7y9YV/fCEDDAEFIAEgASkDIDcDKAN+IAEgAUEoahC+AyABKAIABH4gASgCBK1Ch5Wvr5i23puef34gA4VCF4lCz9bTvtLHq9lCfkL5893xmfaZqxZ8IQMMAQUgASgCKCECIAEoAiwhAANAIAAEQCAAQX9qIQAgAjEAAELFz9my8eW66id+IAOFQguJQoeVr6+Ytt6bnn9+IQMgAkEBaiECDAELCyABQTBqJAAgA0IhiCADhULP1tO+0ser2UJ+IgNCHYggA4VC+fPd8Zn2masWfiIDQiCIIAOFCwsLCwuxAwEHfyABQX9qIQggAEECdCEHQQAgAWshCSACKAIAIQUCQAJAA0AgBUUNAiAFIQEDQAJAIAEoAggiBUEBcUUEQAJAIAEoAgBBfHEiCiABQQhqIgZrIAdPBEAgBiADIAAgBCgCEBECAEECdGpBCGogCiAHayAJcSIFTQ0BIAYgCHFFDQMgBigCACEFCyACIAU2AgAMBAsgBUEANgIAIAVBeGoiBUIANwIAIAUgASgCAEF8cTYCACABKAIAIgJBfHEiAEUgAkECcXJFBEAgACAAKAIEQQNxIAVyNgIECyAFIAUoAgRBA3EgAXI2AgQgASABKAIIQX5xNgIIIAEgASgCACIAQQNxIAVyIgI2AgAgAEECcUUNBCABIAJBfXE2AgAgBSAFKAIAQQJyNgIADAQLIAEgBUF+cTYCCAJ/QQAgASgCBEF8cSIFRQ0AGkEAIAUgBS0AAEEBcRsLIQUgARCfAiABLQAAQQJxBEAgBSAFKAIAQQJyNgIACyACIAU2AgAgBSEBDAELCwsgAiABKAIIQXxxNgIAIAEhBQsgBSAFKAIAQQFyNgIAIAVBCGohCwsgCwulAwECfyMAQcACayIEJAAgAhClBSACQdHwwwBBByADQaABahCeBSAEQSA2AkQgBCABQSBqNgJAIAQgAiAEQUBrEPQDIARBQGsgBEGo/8EAEMkFIARBIGogBEFAaxBIIAJB3/DDAEEGIARBIGoQngUgBEHgAWogAkHl8MMAQQYQkAQgBEFAayAEQeABaiABELwDIARBgAJqIARBQGsgBBASIARBoAJqEMsEIARByABqIgEgBEGoAmopAwA3AwAgBEHQAGoiAyAEQbACaikDADcDACAEQdgAaiIFIARBuAJqKQMANwMAIARBCGogASkDADcDACAEQRBqIAMpAwA3AwAgBEEYaiAFKQMANwMAIAQgBCkDoAI3A0AgBCAEKQNANwMAIABBGGogBEE4aikDADcAACAAQRBqIARBMGopAwA3AAAgAEEIaiAEQShqKQMANwAAIAAgBCkDIDcAACAAIAQpA4ACNwAgIABBKGogBEGIAmopAwA3AAAgAEEwaiAEQZACaikDADcAACAAQThqIARBmAJqKQMANwAAIAIQtwUgBEHAAmokAAuyAwIKfwF+QQAgASgCCCIKayENIAUgASgCECIOayEPIAEpAwAhESABKAIUIQgCQANAIAUgCGoiC0F/aiIHIANPBEAgASADNgIUQQAhBwwCC0IBIAIgB2oxAABCP4OGIBGDUARAIAEgCzYCFCALIQggBg0BIAFBADYCHAwBCyAKIQcgBkUEQCAKIAEoAhwiByAKIAdLGyEHCyACIAhqIRACQANAIAcgBU8EQEEAIAEoAhwgBhshCSAKIQcCQAJAA0AgCSAHTwRAIAEgCzYCFCAGRQRAIAFBADYCHAsgACAINgIEIABBCGogCzYCAEEBIQcMCAsgB0F/aiIHIAVPDQEgByAIaiIMIANPDQIgBCAHai0AACACIAxqLQAARg0ACyABIAggDmoiCDYCFCAGDQUgASAPNgIcDAULQZiWygAgByAFEOQCAAtBqJbKACAMIAMQ5AIACyAHIAhqIgkgA08NASAHIBBqIQwgBCAHaiAHQQFqIQctAAAgDC0AAEYNAAsgASAIIA1qIAdqIgg2AhQgBg0BIAFBADYCHAwBCwtBiJbKACAJIAMQ5AIACyAAIAc2AgAL8AMBBH8jAEFAaiIBJAAgACgCACIDKAIAIQIgAyAAKAIENgIAIAEgAkEDcSIANgIMIABBAkYEQAJAAkACQCACQXxxIgAEQANAIAAoAgQgACgCACECIABBADYCACACRQ0CIABBAToACCACKAIYIQAgAkECNgIYIAEgAjYCKAJAAkAgAEECTQRAIABBAWsNAgwBC0HsoMoAQRxBiKHKABC8BAALIAEoAigiAkEcaiIAKAIAIgQtAAANBCAEQQE6AABBjPrKAAJ/QYj6ygAoAgBBAUYEQEGM+soAKAIADAELQYj6ygBCATcDAEEACyIENgIAIAItACANBSAAKAIAQQA6AAALIAEoAigiACAAKAIAIgBBf2o2AgAgAEEBRgRAIAFBKGoQ0gILIgANAAsLIAFBQGskAA8LQZicygBBK0GEpMoAEM4DAAtB6KfKAEEgQaSoygAQvAQACyABIAA2AhAgASAEQQBHOgAUQfScygBBKyABQRBqQaCdygBBmKHKABCoAgALIAFBNGpBkgE2AgAgAUEkakECNgIAIAFCAzcCFCABQdSbygA2AhAgAUGSATYCLCABIAFBDGo2AjggAUGYn8oANgI8IAEgAUEoajYCICABIAFBPGo2AjAgASABQThqNgIoIAFBEGpB9KPKABCpBAALmAMCBX8BfiMAQdAAayIBJAAgACgCACECA0BBACEFA0ACQAJAAkACQAJAIAJBAXEEQCACQXxxIgMgBUEJS3INASAFQQFqIgVBBEkNAgwDCyAAIAJBAXIgACgCACIDIAIgA0YbNgIAIAIgA0cgAyECDQUgAUHQAGokAA8LIAFBAjoAICABQdTwyQAQtwQCfyABKAIABEAgAUEwahCXBSABQRBqEOgEIAFBKGogAUHIAGopAwA3AwAgAUEgaiABQUBrKQMAIgY3AwAgAUEYaiABQThqKQMANwMAIAEgASkDMDcDECABQRBqIAanQf8BcUECRw0BGkGo8MkAQStBvPHJABDOAwALIAEoAgQLIgRBAToAECADRQ0CIAQgAzYCHCAEQgA3AhQMAwsgAUEIakEAQQEgBUEfcXQQpgULIAAoAgAhAgwCCyAEQQA2AhggBCAENgIUCyAAIAJBA3EgBHIgACgCACIDIAIgA0YbNgIAIAIgA0YEQCAEEOYBIAFBEGoQ6AQMAgUgAUEQahDoBCADIQIMAQsACwALAAuFAwEFfyMAQUBqIgMkACADIAA2AhAgACgCACEAA0ACQCAAQQFxDQACQCAAQQJxIgZBAXZFBEACQAJAAkACQCAAQQRxBEAgAEEIcQ0DIAVBCUsNAiAFQQFqIgVBBEkNAQwGCyADKAIQIgQgAEF5cUEEciAEKAIAIgQgACAERhs2AgAgACAERyAEIQANByABIAZBAXYgAigCDBEAACADKAIQIgAoAgAgAEEBNgIAQQhxDQMMBgsgA0EIakEAQQEgBUEfcXQQpgUMBAsgAygCECIEIABBCHIgBCgCACIEIAAgBEYbNgIAIAAgBEcgBCEADQULIAMoAhAhACADIANBEGo2AhQgA0EBOgAaIANBAToAGyADIANBFGo2AhwgAyADQRpqNgIgIAMgA0EbajYCJCADQgA3AyhBACEFIAMgACADQRxqIANBIGogA0EkaiADQShqEEAMAgsgAygCEBAxDAILQZzryQBBKkGg7MkAELkEAAsgAygCECgCACEADAELCyADQUBrJAALwwMBA38jAEEwayIBJAAgAUHIgMoAQQsQAyICNgIUIAFBIDYCGCABIAJBIBAEIgI2AgggAUEYahCNBSABQRRqEI0FIAFBIDYCGCABQQhqIAFBGGoQrAUhAyABQRhqEI0FAkAgAwRAIAEgAjYCDCABIAIQBTYCFCABQSA2AhggAUEUaiABQRhqEKwFIQMgAUEYahCNBSABQRRqEI0FAkACQCADBEAgASACEAYiAjYCECABQRBqEL0FDQEgASACNgIUIAEgAhAHNgIYIAFBGGoQvQUgAUEYahCNBQ0CIABCgICAgBA3AgAgAEEIaiACNgIADAQLIABBCGpB9IHKAEEGEAg2AgAgAEIANwIADAMLIAFBGGpB+oHKAEEYEPwEIABBATYCACAAQRRqIAFBKGooAgA2AgAgAEEMaiABQSBqKQMANwIAIAAgASkDGDcCBCABQRBqEI0FDAILIAFBGGpBkoLKAEEjEPwEIABBATYCACAAQRRqIAFBKGooAgA2AgAgAEEMaiABQSBqKQMANwIAIAAgASkDGDcCBCABQRRqEI0FDAELQdOAygBBLkHkgcoAELkEAAsgAUEMahCNBSABQTBqJAALrQMBAn8jAEHwAmsiAyQAIANBoAJqIAIQyAUgA0EIaiADQaACaiACEB4gA0GgAmogA0EIahDIBSADQTBqIANBoAJqIAIQHiADQYABaiABIANBCGoQHiADQdABaiABIANBMGoQHiADQaACaiADQdABahBjIANB+AFqIANBoAJqQSgQ8gMaIANBoAJqIANB+AFqQQIQKiADQagBaiADQdABaiADQaACahAeIANB2ABqIANBgAFqIANBqAFqEB4gA0GgAmogA0HYAGoQyAUgA0HQAWogAiADQaACahAeIANB0AFqIAEQ9wMhBCADQaACaiABENkDIANB0AFqIANBoAJqEPcDIQIgA0GgAmogARDZAyADQfgBaiADQaACakG4+sMAEB4gA0HQAWogA0H4AWoQ9wMhASADQfgBakG4+sMAIANB2ABqEB4gA0HYAGogA0H4AWogASACchCWBRCIAiADQdgAahDCBCEBIANBoAJqIANB2ABqENkDIANB2ABqIANBoAJqIAEQiAIgACACIARyEJYFOgAAIABBCGogA0HYAGpBKBDyAxogA0HwAmokAAutAwECfyMAQfACayIDJAAgA0GgAmogAhDIBSADQQhqIANBoAJqIAIQHiADQaACaiADQQhqEMgFIANBMGogA0GgAmogAhAeIANBgAFqIAEgA0EIahAeIANB0AFqIAEgA0EwahAeIANBoAJqIANB0AFqEGMgA0H4AWogA0GgAmpBKBDyAxogA0GgAmogA0H4AWpBAhAqIANBqAFqIANB0AFqIANBoAJqEB4gA0HYAGogA0GAAWogA0GoAWoQHiADQaACaiADQdgAahDIBSADQdABaiACIANBoAJqEB4gA0HQAWogARD3AyEEIANBoAJqIAEQ2QMgA0HQAWogA0GgAmoQ9wMhAiADQaACaiABENkDIANB+AFqIANBoAJqQeCsyAAQHiADQdABaiADQfgBahD3AyEBIANB+AFqQeCsyAAgA0HYAGoQHiADQdgAaiADQfgBaiABIAJyEJYFEIgCIANB2ABqEMIEIQEgA0GgAmogA0HYAGoQ2QMgA0HYAGogA0GgAmogARCIAiAAIAIgBHIQlgU6AAAgAEEIaiADQdgAakEoEPIDGiADQfACaiQAC/ACAgZ/AX4jAEEQayIDJAAgA0EBOgAOIAACfwJAAkACQAJAAn8CQCABBEAgAUEISQ0BIAFB/////wFxIAFHDQMgAUEDdEEHbgwCCyAAQRBqQgA3AgAgAEEIakKAgICAwAA3AgAgAEEEakGU9cgANgIAQQAMBgsgAUEBagshASADQQE6AA9BfyABQX9qZ3YiAUEIaiICIAFBBWoiBkkNASABQQFqIgWtQgx+IghCIIinDQEgAkF8cSICIAinaiIEIAJJDQEgBEEEEKQFIgcNAiAEQQQQ3QUACyADQQ5qEP4EDAILIANBD2oQ/gQMAQsgAiAHQf8BIAYQwQQiBGohAiAFQQRJBEAgBCAFakGAAUEDIAFrEMEEGgsgAEEUaiABIAVBA3ZBB2wgAUEISRs2AgAgAEEQakEANgIAIABBDGogAjYCACAAQQhqIAE2AgAgAEEEaiAENgIAQQAMAQsgAEEAOgABQQELOgAAIANBEGokAAuZAwECfyMAQaAFayIDJAAgA0EIaiACEMEBQQAhAiADQcgAakEAQSgQwQQaIANB+ABqQgA3AwAgA0GAAWpCADcDACADQYgBakIANwMAIANBkAFqQgA3AwAgA0IBNwNwIANCATcDmAEgA0GgAWpBAEHIABDBBBoDQCACIgRBP00EQCAEQQFqIQIgBEEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgA0GIA2ogA0HIAGoQxQEgA0HIAGogA0GIA2pBoAEQ8gMaQQAhAgNAIAIiBEE/TQRAIARBAWoiAkEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgACADQcgAakGgARDyAxogA0GgBWokAAuZAwECfyMAQaAFayIDJAAgA0EIaiACEMIBQQAhAiADQcgAakEAQSgQwQQaIANB+ABqQgA3AwAgA0GAAWpCADcDACADQYgBakIANwMAIANBkAFqQgA3AwAgA0IBNwNwIANCATcDmAEgA0GgAWpBAEHIABDBBBoDQCACIgRBP00EQCAEQQFqIQIgBEEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgA0GIA2ogA0HIAGoQxQEgA0HIAGogA0GIA2pBoAEQ8gMaQQAhAgNAIAIiBEE/TQRAIARBAWoiAkEBcUUNASADQagEaiABIARBAXZBwAdsaiADQQhqIARqLQAAEKQBIANBiANqIANByABqIANBqARqEJkBIANB6AFqIANBiANqEIMCIANByABqIANB6AFqQaABEPIDGgwBCwsgACADQcgAakGgARDyAxogA0GgBWokAAudAwEDfyMAQbADayIDJAAgAAJ/AkAgAkEgRwRAIANB3AFqQtKAgICABDcCACADQdgBakHPgMAANgIAIANB1AFqQQk2AgAgA0HQAWpBxoDAADYCACADQQM6AMwBIANBATYCyAEgAyADQcgBakEEckHEARDyAxoMAQsgA0GoA2oiAkIANwMAIANBoANqIgRCADcDACADQZgDaiIFQgA3AwAgA0IANwOQAyADQZADakEgIAFBIBCuASADQRhqIAIpAwA3AwAgA0EQaiAEKQMANwMAIANBCGogBSkDADcDACADIAMpA5ADNwMAIANByAFqIAMQiQEgAygCyAEgAyADQcgBakEEckHEARDyAyECQQFGDQAgAEEIaiACQQRqQcABEPIDGkEADAELIANB2AFqIANBEGopAgA3AwAgA0HQAWogA0EIaikCADcDACADIAMpAgA3A8gBIANBkANqIANByAFqEKoEIABBFGogA0GgA2opAwA3AgAgAEEMaiADQZgDaikDADcCACAAIAMpA5ADNwIEQQELNgIAIANBsANqJAALkAMBAX8jAEHABGsiBSQAIAUgAzYCDCAFIAI2AgggBUEQahCyAyAFQRBqIAFBIGoQxgUgBUEQaiAFQQhqEK4EIAVB6AJqIAVBEGpB2AEQ8gMaIAVBiAJqIAVB6AJqEOICIAVB6AJqIAVBiAJqQZDJxAAQzQUgBUHoAWogBUHoAmoQ2AEgBUHoAmoQsgMgBUEQaiAFQegCakHYARDyAxogBUEQaiAFQegBahDGBSAFQRBqIARBoAFqEMYFIAVBEGogBUEIahCuBCAFQegCaiAFQRBqQdgBEPIDGiAFQcgCaiAFQegCahDiAiAFQegCaiAFQcgCaiABEMADIAVBqAJqIAVB6AJqIAVBiAJqEBMgAEEYaiAFQYACaikDADcAACAAQRBqIAVB+AFqKQMANwAAIABBCGogBUHwAWopAwA3AAAgACAFKQPoATcAACAAIAUpAKgCNwAgIABBKGogBUGwAmopAAA3AAAgAEEwaiAFQbgCaikAADcAACAAQThqIAVBwAJqKQAANwAAIAVBwARqJAALlgMBB38jAEGABWsiAiQAIAJBEGoQsgMgAkHoAWpBAEHAABDBBBogAkHAAmoiA0IANwMAIAJBuAJqIgRCADcDACACQbACaiIFQgA3AwAgAkIANwOoAiACQeACaiIGQgA3AwAgAkHYAmoiB0IANwMAIAJB0AJqIghCADcDACACQgA3A8gCIAJBEGogARDGBSACQagDaiACQRBqQdgBEPIDGiACQegCaiACQagDahChBCACQQhqIAJB6AJqEKkFIAJB6AFqQcAAIAIoAgggAigCDBCwASACQagCakEgIAJB6AFqQSAQsAEgAkHIAmpBICACQYgCakEgELABIAIgAi0AqAJB+AFxOgCoAiACIAItAMcCQT9xQcAAcjoAxwIgAkHAA2ogAykDADcDACACQbgDaiAEKQMANwMAIAJBsANqIAUpAwA3AwAgAiACKQOoAjcDqAMgACACQagDahC7AyAAQThqIAYpAwA3AAAgAEEwaiAHKQMANwAAIABBKGogCCkDADcAACAAIAIpA8gCNwAgIAJBgAVqJAAL9AIBBH8jAEHQAGsiAyQAIANBCGoQrAIgA0EoaiIGIANBHGooAgA2AgAgAyADQRRqKQIANwMgIANBEGooAgAhBCADKAIMIQUCQAJAIAMoAghBAUcEQCADIAQ2AgQgAyAFNgIAIANBIGogAyABIAIQpwEgAy0AMEEFRw0BIANBIGoQmAUgACADKQMANwIEIABBADYCAAwCCyADQRhqIAYoAgA2AgAgAyAENgIMIAMgBTYCCCADIAMpAyA3AxAgA0E4aiADQQhqELgEIABBFGogA0HIAGooAgA2AgAgAEEMaiADQUBrKQMANwIAIAAgAykDODcCBCAAQQE2AgAMAQsgA0EYaiADQTBqKAIANgIAIANBEGogA0EoaikDADcDACADIAMpAyA3AwggA0E4aiADQQhqELgEIABBFGogA0HIAGooAgA2AgAgAEEMaiADQUBrKQMANwIAIAAgAykDODcCBCAAQQE2AgAgAxCMBQsgA0HQAGokAAuRAgECfyMAQeAAayICJAAgAkEgNgIQIAJBIDYCFCACQQQ2AkggAkEgNgJEIAIgATYCQCACQSBqIAAgAEEgaiACQUBrEOYDIAJB2ABqIAJBOGooAgA2AgAgAkHQAGogAkEwaikDADcDACACQcgAaiIBIAJBKGopAwA3AwAgAiACKQMgNwNAAkADQCACKAJUIgAgAigCWEkEQCACIABBAWo2AlQgAigCQCEDIAJBCGogASAAEM0DIAIoAgxBA00NAiACKAIIIAMgAEECdGooAgAiAEEYdCAAQQh0QYCA/AdxciAAQQh2QYD+A3EgAEEYdnJyNgAADAELCyACQeAAaiQADwtByOXJAEEgQdTkyQAQtAQAC4sDAQF/IwBBgAZrIgIkACACQQhqIAEQyAUgAkHYBWogAkEIahDIBSACQTBqIAJB2AVqEMgFIAJB2ABqIAEgAkEwahAeIAJBgAFqIAJBCGogAkHYAGoQHiACQagBaiACQYABahDIBSACQdABaiACQdgAaiACQagBahAeIAJB+AFqIAJB0AFqQQUQKiACQaACaiACQfgBaiACQdABahAeIAJByAJqIAJBoAJqQQoQKiACQfACaiACQcgCaiACQaACahAeIAJBmANqIAJB8AJqQRQQKiACQcADaiACQZgDaiACQfACahAeIAJB6ANqIAJBwANqQQoQKiACQZAEaiACQegDaiACQaACahAeIAJBuARqIAJBkARqQTIQKiACQeAEaiACQbgEaiACQZAEahAeIAJBiAVqIAJB4ARqQeQAECogAkGwBWogAkGIBWogAkHgBGoQHiACQdgFaiACQbAFakEyECogACACQdgFaiACQZAEahAeIABBKGogAkGAAWpBKBDyAxogAkGABmokAAu2AwEBfyMAQdAAayICJAACfwJAAkACQAJAAkAgACgCAEEBaw4EAgMEAAELIAIgAEEEajYCICACIABBCGo2AiQgAkEYaiACQSBqQcEAEKYFIAJBzABqQcIANgIAIAJBPGpBAjYCACACQgI3AiwgAkHE3skANgIoIAIgAikDGDcDQCACIAJBJGo2AkggAiACQUBrNgI4IAEgAkEoahDoAgwECyACQTxqQQA2AgAgAkG838kANgI4IAJCATcCLCACQczfyQA2AiggASACQShqEOgCDAMLIAJBPGpBADYCACACQbzfyQA2AjggAkIBNwIsIAJBtN/JADYCKCABIAJBKGoQ6AIMAgsgAiAAQQRqNgIkIAJBCGogAkEkakHBABCmBSACQTxqQQE2AgAgAkIBNwIsIAJBlN/JADYCKCACIAIpAwg3A0AgAiACQUBrNgI4IAEgAkEoahDoAgwBCyACIABBBGo2AiQgAkEQaiACQSRqQcEAEKYFIAJBPGpBATYCACACQgE3AiwgAkH43skANgIoIAIgAikDEDcDQCACIAJBQGs2AjggASACQShqEOgCCyACQdAAaiQAC+cCAQZ/AkACQCACQQNxIgRFDQBBBCAEayIERQ0AIAMgBCAEIANLGyEFQQAhBCABQf8BcSEIA0AgBCAFRg0BIAIgBGogBEEBaiEELQAAIgYgCEcNAAtBASEDIAYgAUH/AXFGQQFqQQFxIARqQX9qIQQMAQsgAUH/AXEhCAJAAkAgA0EISQ0AIAUgA0F4aiIGSw0AIAhBgYKECGwhBANAIAIgBWoiB0EEaigCACAEcyIJQX9zIAlB//37d2pxIAcoAgAgBHMiB0F/cyAHQf/9+3dqcXJBgIGChHhxRQRAIAVBCGoiBSAGTQ0BCwsgBSADSw0BCyACIAVqIQIgAyAFayEGQQAhA0EAIQQCQANAIAQgBkYNASACIARqIARBAWohBC0AACIHIAhHDQALQQEhAyAHIAFB/wFxRkEBakEBcSAEakF/aiEECyAEIAVqIQQMAQsgBSADEOYCAAsgACAENgIEIAAgAzYCAAv8AgEGfyMAQTBrIgIkACABKAIAIQYgASgCBCIHQQN0IgUEQCAGQQRqIQMDQCADKAIAIARqIQQgA0EIaiEDIAVBeGoiBQ0ACwsCQAJAAkACQAJAIAFBFGooAgBFBEAgBCEDDAELIAdFBEBBlKnKAEEAQQAQ5AIACwJAIARBD00EQCAGQQRqKAIARQ0BCyAEIARqIgMgBE8NAQtBASEFQQAhAyACQQhqIQQMAQsgA0F/TA0BIAJBCGohBCADRQRAQQEhBUEAIQMMAQsgA0EBEKQFIgVFDQILIAJBADYCECACIAM2AgwgAiAFNgIIIAIgAkEIajYCFCACQShqIAFBEGopAgA3AwAgAkEgaiABQQhqKQIANwMAIAIgASkCADcDGCACQRRqQbSoygAgAkEYahAzDQIgACAEKQIANwIAIABBCGogBEEIaigCADYCACACQTBqJAAPCxDrBQALIANBARDdBQALQbSpygBBMyACQRhqQaSpygBB/KnKABCoAgAL1AICBn8EfiMAQbACayIDJAAgA0EIakEAQYACEMEEGiADQZACaiABQQhqKQAANwMAIANBmAJqIAFBEGopAAA3AwAgA0GgAmogAUEYaikAADcDACADQgA3A6gCIAMgASkAADcDiAJBwAAgAmshB0IBIAJBP3GthiIJQgGIIQogCUJ/fCELIAmnIQhBACEBA0BBACABayEEA0AgAUGAAkkEQCABQQZ2IQUCfiABQT9xIgYgB0kEQCADQYgCaiAFQQN0aikDACAGrYgMAQsgA0GIAmogBUEDdGoiBUEIaikDACAEQT9xrYYgBSkDACAGrYiECyALgyAMfCIJQgGDUARAIARBf2ohBCABQQFqIQEMAgUgA0EIaiABaiAJp0EAIAggCSAKVBtrOgAAIAIgBGshASAJIAparSEMDAMLAAsLCyAAIANBCGpBgAIQ8gMaIANBsAJqJAALnQMBBX8jAEGQAmsiAyQAIANByIbAAEEUEPUDIANB3IbAAEEKQayDwABBABDSAyACLQAABEAgA0GIAmogAkEZaikAADcDACADQYACaiACQRFqKQAANwMAIANB+AFqIAJBCWopAAA3AwAgAyACKQABNwPwASADQfCGwABBCiADQfABakEgENIDCyADQfABaiABENYDIANBnYfAAEEKIANB8AFqQSAQ0gMgA0HoAWoiAUIANwMAIANB4AFqIgJCADcDACADQdgBaiIEQgA3AwAgA0IANwPQASADQaeHwABBCSADQdABakEgENMDIANBiAJqIgVCADcDACADQYACaiIGQgA3AwAgA0H4AWoiB0IANwMAIANCADcD8AEgA0GPh8AAQQ4gA0HwAWpBIBDTAyAAQRhqIAEpAwA3AAAgAEEQaiACKQMANwAAIABBCGogBCkDADcAACAAIAMpA9ABNwAAIAAgAykD8AE3ACAgAEEoaiAHKQMANwAAIABBMGogBikDADcAACAAQThqIAUpAwA3AAAgAxC3BSADQZACaiQAC/oCAQN/IwBBwANrIgMkACAAAn8CQCACQSBHBEAgA0HsAWpC0oCAgIAENwIAIANB6AFqQbHvwwA2AgAgA0HkAWpBCTYCACADQeABakGo78MANgIAIANBAzoA3AEgA0EBNgLYASADQRBqIANB2AFqQQRyQcQBEPIDGgwBCyADQbgDaiICQgA3AwAgA0GwA2oiBEIANwMAIANBqANqIgVCADcDACADQgA3A6ADIANBCGogAUEgQSAQngQgA0GgA2pBICADKAIIIAMoAgwQrQEgA0EoaiACKQMANwMAIANBIGogBCkDADcDACADQRhqIAUpAwA3AwAgAyADKQOgAzcDECADQdgBaiADQRBqEIkBIAMoAtgBIANBEGogA0HYAWpBBHJBxAEQ8gMaQQFGDQAgAEEIaiADQRRqQcABEPIDGkEADAELIAAgAykCEDcCBCAAQRRqIANBIGopAgA3AgAgAEEMaiADQRhqKQIANwIAQQELNgIAIANBwANqJAALlwMCBH8CfiMAQUBqIgUkAEEBIQcCQCAALQAEDQAgAC0ABSEIIAAoAgAiBi0AAEEEcUUEQCAGKAIYQaWsygBBp6zKACAIG0ECQQMgCBsgBkEcaigCACgCDBEEAA0BIAAoAgAiBigCGCABIAIgBkEcaigCACgCDBEEAA0BIAAoAgAiASgCGEGcq8oAQQIgAUEcaigCACgCDBEEAA0BIAMgACgCACAEKAIMEQIAIQcMAQsgCEUEQCAGKAIYQaCsygBBAyAGQRxqKAIAKAIMEQQADQEgACgCACEGCyAFQQE6ABcgBUE0akGErMoANgIAIAUgBikCGDcDCCAFIAVBF2o2AhAgBikCCCEJIAYpAhAhCiAFIAYtACA6ADggBSAKNwMoIAUgCTcDICAFIAYpAgA3AxggBSAFQQhqNgIwIAVBCGogASACEEYNACAFQQhqQZyrygBBAhBGDQAgAyAFQRhqIAQoAgwRAgANACAFKAIwQaOsygBBAiAFKAI0KAIMEQQAIQcLIABBAToABSAAIAc6AAQgBUFAayQAC7YDAgR/AX4jAEEwayIBJAACQAJAAkACQAJ/QQAgACgCACICRQ0AGiABIAApAgQ3AiQgASACNgIgIAFBEGogAUEgahD5BCABQQhqQQAgASgCECIAIAEoAhgQZSABKAIIDQEgAUEoaiABQRhqKAIANgIAIAEgASkDEDcDICABIAFBIGoQbiABKAIEIQMgASgCAAshBEGQ+soALQAADQFBkPrKAEEBOgAAAkBBmPvKACkDACIFQn9SBEBBmPvKACAFQgF8NwMAIAVCAFINAUGYnMoAQStBnKDKABDOAwALQdSfygBBN0GMoMoAELwEAAtBkPrKAEEAOgAAQQFBARCkBSICRQ0CIAJBADoAAEEwQQgQpAUiAEUNAyAAQgE3AiQgAEEANgIYIAAgAzYCFCAAIAQ2AhAgACAFNwMIIABCgYCAgBA3AwAgACACrTcCHCABQTBqJAAgAA8LIAEoAgwhAiABQShqIAEpAhQ3AwAgASAANgIkIAEgAjYCIEGsoMoAQS8gAUEgakHUnMoAQdygygAQqAIAC0Hop8oAQSBBpKjKABC8BAALQQFBARDdBQALQTBBCBDdBQAL9AIBAn8jAEHgA2siAiQAIAIgARCbAiACQThqQgA3AwAgAkFAa0IANwMAIAJByABqQgA3AwAgAkIANwMwIAJCATcDKCACQdAAaiACEMgFIAJB+ABqIAJB0ABqIAJBKGoQ3wEgAkHwAWogAkHQAGpBgOvIABAeIAJBoAFqIAJB8AFqIAJBKGoQ1QMgAkHwAWogAkH4AGogAkGgAWoQWiACLQDwASEDIAJByAFqIAJB+AFqQSgQ8gMaIAAgA0EBRgR+IAEtAB9BB3YQlgUhASACQfABaiACQcgBahDZAyACQcgBaiACQfABaiABEIgCIAJB8AFqIAJByAFqQSgQ8gMaIAJBkANqIAJBKBDyAxogAkG4A2ogAkHIAWogAhAeIAJBmAJqIAJBkANqQSgQ8gMaIAJBwAJqIAJBKGpBKBDyAxogAkHoAmogAkG4A2pBKBDyAxogAEEIaiACQfABakGgARDyAxpCAQVCAAs3AwAgAkHgA2okAAuWAwIEfwF+IwBBIGsiASQAIAEgAEHMAGo2AhggAEEMaiEDIAApAwAhBSAAKAIIIQIgASABQRhqNgIcAkACQAJAIAJBwABGBEAgAUEcaiADELoFQQAhAiAAQQA2AggMAQsgAkE/Sw0BCyACIABBDGoiBGpBgAE6AAAgACAAKAIIQQFqIgI2AgggAUEQaiAEQcAAIAIQnQQgASgCEEEAIAEoAhQQwQQaQcAAIAAoAghrQQdNBEAgAUEcaiADELoFIAFBCGpBACAAKAIIIARBwAAQ1AMgASgCCEEAIAEoAgwQwQQaCyABIARBwABBOBCdBCABKAIEQQdNDQEgASgCACAFQiiGQoCAgICAgMD/AIMgBUI4hoQgBUIYhkKAgICAgOA/gyAFQgiGQoCAgIDwH4OEhCAFQgiIQoCAgPgPgyAFQhiIQoCA/AeDhCAFQiiIQoD+A4MgBUI4iISEhDcAACABQRxqIAMQugUgAEEANgIIIAFBIGokAA8LQaTkyQAgAkHAABDkAgALQejlyQBBIEHU5MkAELQEAAvwAgEEfwJAAkACQCABQQRqKAIAIgIgASgCCCIDRgRAIANBAWoiAiADSSACQQBIcg0BAn8gA0UEQCACQQEQpAUMAQsgASgCACADQQEgAhCUBQsiBEUNAiABIAQ2AgAgAUEEaiACNgIACyACIANHBEAgA0EBaiEEIAEoAgAhBQwDCyADQQFqIgQgA0kNACADQQF0IgIgBCACIARLGyICQQBIDQACfyADRQRAIAJBARCkBQwBCyABKAIAIANBASACEJQFCyIFBEAgASAFNgIAIAFBBGogAjYCAAwDCyACQQEQ3QUACxDCBQALIAJBARDdBQALIAMgBWpBADoAACABIAQ2AggCQAJAAkAgAiAERg0AIAIgBEkNASAERQRAIAJFBEBBASEFDAILIAUgAkEBELYFQQEhBQwBCyAFIAJBASAEEJQFIgVFDQILIAAgBDYCBCAAIAU2AgAPC0GInsoAQSRB+J3KABDOAwALIARBARDdBQAL3gIBA38jAEGAA2siBCQAIARB2ABqIANBGGopAAA3AwAgBEHQAGogA0EQaikAADcDACAEQcgAaiADQQhqKQAANwMAIAQgAykAADcDQCAEQeABaiABIAIgBEFAaxDtASAEQRhqIARB+AFqKQMANwMAIARBEGogBEHwAWopAwA3AwAgBEEIaiAEQegBaikDADcDACAEIAQpA+ABNwMAIARBOGoiAyAEQZgCaikDADcDACAEQTBqIgUgBEGQAmopAwA3AwAgBEEoaiIGIARBiAJqKQMANwMAIAQgBCkDgAI3AyAgBEHgAWogBEGwh8AAEMkFIARBQGsgASAEQeABahCIBCAEQeABaiAEQUBrQaABEPIDGiAAIARB4AFqEOEEIABB2AFqIAMpAwA3AAAgAEHQAWogBSkDADcAACAAQcgBaiAGKQMANwAAIAAgBCkDIDcAwAEgAhC3BSAEQYADaiQAC+UBAQR/IwBB4ABrIgIkACACQcAANgIQIAJBwAA2AhQgAkHAADYCRCACIAE2AkAgAkEINgJIIAJBIGogACAAQUBrIAJBQGsQ5wMgAkHQAGogAkEwaikDADcDACACQdgAaiACQThqKAIAIgM2AgAgAkHIAGoiBCACQShqKQMANwMAIAIgAikDIDcDQCACKAJUIgFBA3QhAANAIAEgA0kEQCACIAFBAWoiBTYCVCACQQhqIAQgARDNAyACKAIIIAIoAgwgAigCQCAAaikDABCpAiAAQQhqIQAgBSEBDAELCyACQeAAaiQAC+ACAQR+IAAgASkDICICPAAaIAAgASkDECIDPAANIAAgASkDACIEPAAAIAAgAkIoiDwAHyAAIAJCIIg8AB4gACACQhiIPAAdIAAgAkIQiDwAHCAAIAJCCIg8ABsgACABKQMYIgJCLIg8ABkgACACQiSIPAAYIAAgAkIciDwAFyAAIAJCFIg8ABYgACACQgyIPAAVIAAgAkIEiDwAFCAAIANCKIg8ABIgACADQiCIPAARIAAgA0IYiDwAECAAIANCEIg8AA8gACADQgiIPAAOIAAgASkDCCIFQiyIPAAMIAAgBUIkiDwACyAAIAVCHIg8AAogACAFQhSIPAAJIAAgBUIMiDwACCAAIAVCBIg8AAcgACAEQiiIPAAFIAAgBEIgiDwABCAAIARCGIg8AAMgACAEQhCIPAACIAAgBEIIiDwAASAAIAJCBIYgA0IwiIQ8ABMgACAFQgSGIARCMIiEPAAGC40DAQF/IwBBEGsiAiQAAn8CQAJAAkACQAJAAkAgACgCAEEBaw4EAgMEAAELIAIgAUGpucYAQRAQvwQgAiAAQQRqNgIMIAJBubnGAEEGIAJBDGpBwLnGABBqIAIgAEEMajYCDCACQdC5xgBBCCACQQxqQdi5xgAQaiACIABBEGo2AgwgAkHoucYAQQYgAkEMakHAucYAEGogAiAAQRhqNgIMIAJB7rnGAEEIIAJBDGpB2LnGABBqIAIgAEEcajYCDCACQfa5xgBBBiACQQxqQcC5xgAQaiACIABBJGo2AgwgAkH8ucYAQQggAkEMakHYucYAEGogAhCxAgwFCyACIAFBurrGAEEXEJwEDAMLIAIgAUGpusYAQREQnAQMAgsgAiABQY+6xgBBEBC/BCACIABBBGo2AgwgAkGfusYAQQQgAkEMakHAucYAEGogAiAAQQxqNgIMIAJBo7rGAEEGIAJBDGpB2LnGABBqIAIQsQIMAgsgAiABQYS6xgBBCxCcBAsgAhCAAgsgAkEQaiQAC9kCAgR/An4jAEEwayIDJAAgACkDwAEiB6dB/wBxIQRBACAHUEUgBBtFBEAgA0EoaiABIAIgAkGAASAEayIFIAUgAksbEJ4EIAMoAighBiADQSBqIAEgAiADKAIsIgUQnQQgAygCJCECIAMoAiAhASADQRhqIAAgBBDEBCADKAIYIAMoAhwgBiAFEOQEIAAgACkDwAEiByAFrXwiCCAHWq0gCBCDBTcDwAELA0AgAkH/AE0EQCACBEAgAEIAEAsgAEGAASABIAIQ5AQgACAAKQPAASIHIAKtfCIIIAdarSAIEIMFNwPAAQsgA0EwaiQABSAAQgAQCyADQRBqIAEgAkGAARCeBCADKAIQIQUgA0EIaiABIAIgAygCFCIEEJ0EIAMoAgwhAiADKAIIIQEgAEGAASAFIAQQ5AQgACAAKQPAASIHIAStfCIIIAdarSAIEIMFNwPAAQwBCwsL1QICBn8DfiMAQYDCAGsiASQAIAFBCGoQ3AEgAUH4IGogAUEIakHoIBDyAxogAUIBNwPwIANAIABBIGoiA0HwIE0EQCAAQajYygBqIgIpAwAhBiACIAFB8CBqIABqIgApAwA3AwAgACAGNwMAIAJBCGoiBCkDACEGIAQgAEEIaiIEKQMANwMAIAJBEGoiBSkDACEHIAUgAEEQaiIFKQMANwMAIAJBGGoiAikDACEIIAIgAEEYaiIAKQMANwMAIAAgCDcDACAFIAc3AwAgBCAGNwMAIAMhAAwBCwsgAUHQwQBqIgApAwAhBiAAQYj5ygApAwA3AwBBiPnKACAGNwMAQZD5ygAoAgAhAEGQ+coAIAFB2MEAaikDADcDAAJAIAEpA/AgUCAAQSRJcg0AIAEoAtRBIgNBAUYgA0F+akECS3JFDQAgABAACyABQYDCAGokAEGw2MoAC4wCAgJ/AX4jAEEwayIEJAACQCABKAIEIAJrIANPDQAgBEEgaiABIAIgAxCvAkEBIQUgBCgCJCECIAQoAiBBAUYEQCAEIAIgBEEoaigCABCmBSAAIAQpAwA3AgQMAQsCQAJAAkAgAq1C8AB+IgZCIIinRQRAIAanIgNBAEgNAQJ/IAEoAgQiBUUEQCADQQgQpAUMAQsgASgCACAFQfAAbEEIIAMQlAULIgUEQCABIAI2AgQgASAFNgIAQQAhBQwFCwwCCyAEQQhqIARBABCmBSAAIAQpAwg3AgQMAgsgBEEQaiAEQQAQpgUgACAEKQMQNwIEDAELIANBCBDdBQALCyAAIAU2AgAgBEEwaiQAC4kCAQN/IwBBMGsiAyQAAkAgASgCBCACa0EBTw0AIANBIGogASACQQEQrwJBASEEIAMoAiQhAiADKAIgQQFGBEAgAyACIANBKGooAgAQpgUgACADKQMANwIEDAELAkACQAJAIAIgAkH/////AXFGBEAgAkEDdCIFQQBIDQECfyABKAIEIgRFBEAgBUEEEKQFDAELIAEoAgAgBEEDdEEEIAUQlAULIgQEQCABIAI2AgQgASAENgIAQQAhBAwFCwwCCyADQQhqIANBABCmBSAAIAMpAwg3AgQMAgsgA0EQaiADQQAQpgUgACADKQMQNwIEDAELIAVBBBDdBQALCyAAIAQ2AgAgA0EwaiQAC74CAgV/AX4jAEEwayIEJABBJyECAkAgAEKQzgBUBEAgACEHDAELA0AgBEEJaiACaiIDQXxqIAAgAEKQzgCAIgdCkM4Afn2nIgVB//8DcUHkAG4iBkEBdEG5rMoAai8AADsAACADQX5qIAUgBkHkAGxrQf//A3FBAXRBuazKAGovAAA7AAAgAkF8aiECIABC/8HXL1YgByEADQALCyAHpyIDQeMASgRAIAJBfmoiAiAEQQlqaiAHpyIDIANB//8DcUHkAG4iA0HkAGxrQf//A3FBAXRBuazKAGovAAA7AAALAkAgA0EKTgRAIAJBfmoiAiAEQQlqaiADQQF0QbmsygBqLwAAOwAADAELIAJBf2oiAiAEQQlqaiADQTBqOgAACyABQcSqygBBACAEQQlqIAJqQScgAmsQNSAEQTBqJAALgQMBAX8jAEEQayICJAACfwJAAkACQAJAAkACQAJAAkAgAC0AAEEBaw4GAgMEBQYAAQsgAiABQYbxwwBBERC/BCACIABBAWo2AgwgAkGX8cMAQQsgAkEMakGk8cMAEGogAiAAQQJqNgIMIAJBtPHDAEEJIAJBDGpBwPHDABBqDAYLIAIgAUHg8sMAQQ0QnAQgAhCAAgwGCyACIAFByfLDAEEXEJwEIAIQgAIMBQsgAiABQbjywwBBERCcBCACEIACDAQLIAIgAUHu8cMAQRAQvwQgAiAAQQRqNgIMIAJB/vHDAEEEIAJBDGpBhPLDABBqIAIgAEEMajYCDCACQZTywwBBCyACQQxqQYTywwAQaiACIABBFGo2AgwgAkGf8sMAQQYgAkEMakGo8sMAEGoMAgsgAiABQdvxwwBBExCcBCACEIACDAILIAIgAUHQ8cMAQQsQvwQgAiAAQQFqNgIMIAJBl/HDAEELIAJBDGpBpPHDABBqCyACELECCyACQRBqJAALqAIBAn8jAEHQAGsiAyQAIANBMGogASACEC8Cf0ECIAMoAjBBAUYNABpBAiADKAI0IgRFDQAaIANBMGogBCADQThqKAIAENsCQQIgAy0ATCIEQQJGDQAaIANBKGogA0HIAGooAgA2AgAgA0EgaiADQUBrKQMANwMAIANBGGogA0E4aikDADcDACADQQ5qIANBzwBqLQAAOgAAIAMgAykDMDcDECADIAMvAE07AQwgBAshBCAAIAI2AgQgACABNgIAIAAgAykDEDcCCCAAQSRqIAQ6AAAgAEElaiADLwEMOwAAIABBEGogA0EYaikDADcCACAAQRhqIANBIGopAwA3AgAgAEEgaiADQShqKAIANgIAIABBJ2ogA0EOai0AADoAACADQdAAaiQAC+0BAQJ/IwBBIGsiBCQAIAACf0EAIAEoAgQiBSACayADTw0AGgJAAkAgAiADaiIDIAJPBEAgBUEBdCICIAMgAiADSxshAwwBCyAAIAM2AgQMAQsgBEKBgICAEDcDGCAEQQhqIARBGGogAxD0AiAEKAIIIQICQCAEKAIMIgUEQCACQQBIDQICfyABKAIEIgBFBEAgAiAFEKQFDAELIAEoAgAgAEEBIAIQlAULIgAEQCABIAM2AgQgASAANgIAQQAMBAsMAQsgACACNgIEDAELIAIgBRDdBQALIABBCGpBADYCAEEBCzYCACAEQSBqJAAL3wIBB38jAEEwayICJAACQAJAIAAtANEBRQRAIABBAToA0QEgAC0A0AEhAyAAKALMASEEIAJBKGogAEHIASAAKALIARCdBCACQSBqIAIoAiggAigCLEEBEJ4EIAIoAiRFDQEgAigCICIFIAUtAAAgA3M6AAAgAkEYaiAAQcgBIARBf2oQnQQgAkEQaiACKAIYIAIoAhxBARCeBCACKAIURQ0CIAIoAhAiAyADLQAAQYABczoAACAAELgFCyAAKALMASAAKALIASIFayEDQSAhBANAIAJBCGogAUEgIAYQnQQgAigCDCEHIAIoAgghCCAEIANPBEAgACAIIAcgBSADEP4CIAAQJyAEIANrIQQgAyAGaiEGIAAoAswBIQNBACEFDAELCyAAIAggByAFIAQQ/gIgACAEIAVqNgLIASACQTBqJAAPC0HMwcQAQQBBABDkAgALQdzBxABBAEEAEOQCAAuoAgEEfyMAQeAgayICJAAgAkEYaiIDQgA3AwAgAkEQaiIEQgA3AwAgAkEIaiIFQgA3AwAgAkIANwMAIAJBIGogASACQSAQOyAAAn8gAi0AMEEFRgRAIAJBIGoQygMgAkHYIGogAykDADcDACACQdAgaiAEKQMANwMAIAJByCBqIAUpAwA3AwAgAiACKQMANwPAICACQThqIAJBwCBqEA8gAEEEaiACQThqQYQgEPIDGkEADAELIAJByABqIAJBMGooAgA2AgAgAkFAayACQShqKQMANwMAIAIgAikDIDcDOCACQcAgaiACQThqELgEIABBFGogAkHQIGooAgA2AgAgAEEMaiACQcggaikDADcCACAAIAIpA8AgNwIEQQELNgIAIAJB4CBqJAALsAIBC38jAEEgayIEJAAgBEEANgIQIAIgAyAEQRBqEMkBIAQoAhAiBUEZdiIGQQh0IAZyIgZBEHQgBnIhCyABKAIEIgggBXEhBSABKAIIIQkgASgCACEMIAACfwJAA0AgBSAMaigAACIKIAtzIgFBf3MgAUH//ft3anFBgIGChHhxIQEgDUEEaiINIAVqIAhxIQYDQCABRQRAIAYhBSAKIApBAXRxQYCBgoR4cUUNAgwDCyABENIFIQcgAUF/aiABcSEBIAIgAyAJIAUgB2ogCHEiDkEMbGoiBygCACAHKAIEEL8FRQ0ACwsgB0UNACAAIAkgDkEMbGovAQg7AQJBAAwBCyAEQQE2AhAgBEEIaiAEQRBqEMEDIABBBGogBCkDCDcCAEEBCzsBACAEQSBqJAALygICBH8CfiMAQTBrIgMkACAAIAApAwgiByACrUIDhnwiCDcDCCAIIAdUBEAgACAAKQMAQgF8NwMACyADIABBEGo2AhggACgCUCEEIAMgA0EYajYCHAJAIARFDQBBgAEgBGsiBCACSw0AIANBIGogASACIAQQtwMgA0EsaigCACECIAMoAighASADKAIkIQQgAygCICEFIANBEGogAEHUAGoiBkGAASAAKAJQEJ0EIAMoAhAgAygCFCAFIAQQsQEgAEEANgJQIANBHGogBhC7BQsDQCACQYABTwRAIANBIGogASACQYABELcDIAMoAiwhAiADKAIoIQEgA0EcaiADKAIgELsFDAELCyADQQhqIAAoAlAiBCACIARqIABB1ABqQYABENQDIAMoAgggAygCDCABIAIQsQEgACAAKAJQIAJqNgJQIANBMGokAAvcAgIDfwF+QQIhAwJAAkACQCABQXdqIgRBHksEQCABQdwARw0BDAILQfQAIQICQAJAIARBAWsOHgECAgACAgICAgICAgICAgICAgICAgICAgMCAgICAwQLQfIAIQIMAwtB7gAhAgwCCyABQQp2IQICQAJAAkACQCABQYDYB08EQEEeIQMgAkGAB0cNBAwBCyACQb7BygBqLQAAIgNBHksNAQsgAUEGdkEPcSADQQR0ckG5wsoAai0AACICQYsBTw0BQQMhAyACQQN0QbDGygBqKQMAQgEgAUE/ca2Gg1ANAiABQQFyZ0ECdkEHc61CgICAgNAAhCEFDAMLQdDAygAgA0EfEOQCAAtB4MDKACACQYsBEOQCAAsgARAyBEBBASEDDAELIAFBAXJnQQJ2QQdzrUKAgICA0ACEIQVBAyEDCyABIQILIAAgAjYCBCAAIAM2AgAgAEEIaiAFNwIAC5oCAQZ/IAAoAgAiAygCCCEAIANBgYDEADYCCCAAQYGAxABGBH8gAygCACIBIAMoAgQiAEYEQEGAgMQADwsgAyABQQFqIgI2AgAgASwAACIEQX9KBEAgBEH/AXEPCwJ/IAAgAkYEQCAAIQJBAAwBCyADIAFBAmoiAjYCACABLQABQT9xCyEGIARBH3EhBSAEQf8BcUHfAU0EQCAGIAVBBnRyDwsCfyAAIAJGBEAgACEBQQAMAQsgAyACQQFqIgE2AgAgAi0AAEE/cQsgBkEGdHIhAiAEQf8BcUHwAUkEQCACIAVBDHRyDwsgACABRgR/QQAFIAMgAUEBajYCACABLQAAQT9xCyAFQRJ0QYCA8ABxIAJBBnRycgUgAAsL0AICBH8CfiMAQTBrIgEkACABIABBEGo2AiggAEHUAGohBCAAKQMAIQUgACkDCCEGIAAoAlAhAiABIAFBKGo2AiwCQAJAIAJBgAFGBEAgAUEsaiAEELsFQQAhAiAAQQA2AlAMAQsgAkH/AEsNAQsgAiAAQdQAaiIDakGAAToAACAAIAAoAlBBAWoiAjYCUCABQSBqIANBgAEgAhCdBCABKAIgQQAgASgCJBDBBBpBgAEgACgCUGtBD00EQCABQSxqIAQQuwUgAUEYaiADQYABIAAoAlAQngQgASgCGEEAIAEoAhwQwQQaCyABQRBqQfAAQfgAIANBgAEQ1AMgASgCECABKAIUIAUQqQIgAUEIaiADQYABQfgAEJ0EIAEoAgggASgCDCAGEKkCIAFBLGogBBC7BSAAQQA2AlAgAUEwaiQADwtB5ObJACACQYABEOQCAAuiAgEDfyMAQYABayIEJAACQAJAAn8CQCABKAIAIgNBEHFFBEAgACgCACECIANBIHENASACrSABEHcMAgsgACgCACECQQAhAANAIAAgBGpB/wBqIAJBD3EiA0EwciADQdcAaiADQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPDQIgAUG1rMoAQQIgACAEakGAAWpBACAAaxA1DAELQQAhAANAIAAgBGpB/wBqIAJBD3EiA0EwciADQTdqIANBCkkbOgAAIABBf2ohACACQQR2IgINAAsgAEGAAWoiAkGBAU8NAiABQbWsygBBAiAAIARqQYABakEAIABrEDULIARBgAFqJAAPCyACQYABEOYCAAsgAkGAARDmAgAL3AIBAX8jAEHAA2siAyQAIAJBIEcEQCADQQhqQomAgICABDcDACADQRBqIAMpAoACNwMAIANBGGogA0GIAmopAgA3AwAgA0EgaiADQZACaikCADcDACADQej6wQA2AgQgA0ECNgIAQfH6wQBBKyADQZz7wQBBwPzBABCoAgALIANBGGoiAkIANwMAIANBEGpCADcDACADQQhqQgA3AwAgA0IANwMAIANBICABQSAQrgEgAyACKQAANwCFAiADIAMpABM3A4ACIANB+AFqIAMpAIUCNwAAIAMgAy0AAjoA4gEgAyADLwEAOwHgASADIAMpAAs3AOsBIAMgAykAAzcA4wEgAyADKQOAAjcA8wEgA0GAAmogA0HgAWoQ0gEgAyADQaADakEgIAFBIBCHAiADQeABahCzAiADQYACaiADEL8DIAAgA0GAAmoQnwMgA0HAAWoQswIgA0HAA2okAAugAgIBfwF+IwBB8ABrIgMkACADIAI2AhQgAyABNgIQIANBIGoiAUIANwMAIANCADcDGCADQShqIANBEGogA0EYakEQEDsCfyADLQA4QQVGBEAgA0EoahDKAyADQeAAaiABKQMANwMAIAMgAykDGDcDWCADIANB2ABqEPADIAMpAwAhBCAAQRBqIAMpAwg3AwAgAEEIaiAENwMAQQAMAQsgA0HoAGogA0E4aigCADYCACADQeAAaiADQTBqKQMANwMAIAMgAykDKDcDWCADQUBrIANB2ABqELgEIABBFGogA0HQAGooAgA2AgAgAEEMaiADQcgAaikDADcCACAAIAMpA0A3AgRBAQshASADQRBqEJgEIAAgATYCACADQfAAaiQAC7oCAQV/IwBBQGoiAiQAIAEoAgQiA0UEQCABQQRqIQMgASgCACEEIAJBADYCICACQgE3AxggAiACQRhqNgIkIAJBOGogBEEQaikCADcDACACQTBqIARBCGopAgA3AwAgAiAEKQIANwMoIAJBJGpB5JnKACACQShqEDMaIAJBEGoiBCACKAIgNgIAIAIgAikDGDcDCAJAIAEoAgQiBUUNACABQQhqKAIAIgZFDQAgBSAGQQEQtgULIAMgAikDCDcCACADQQhqIAQoAgA2AgAgAygCACEDCyABQQE2AgQgAUEMaigCACEEIAFBCGoiASgCACEFIAFCADcCAEEMQQQQpAUiAUUEQEEMQQQQ3QUACyABIAQ2AgggASAFNgIEIAEgAzYCACAAQcClygA2AgQgACABNgIAIAJBQGskAAu4AgIGfwJ+IwBBIGsiAiQAIAJBGGpCADcDACACQRBqQgA3AwAgAkEIakIANwMAIAJCADcDAANAAkAgA0EERwRAIANBAWohByACIANBA3RqIQVBACEDIAYhBANAIANBwABGDQIgBEEgRwRAIAUgBSkDACABIARqMQAAIANBOHGthoQ3AwAgA0EIaiEDIARBAWohBAwBCwtBjLvEACAEQSAQ5AIACyAAIAIpAxgiCEIQiDcDICAAIAIpAwAiCUL/////////B4M3AwAgACAIQiSGQoCAgICA/v8HgyACKQMQIghCHIiENwMYIAAgCEIYhkKAgID4////B4MgAikDCCIIQiiIhDcDECAAIAhCDIZCgOD//////weDIAlCNIiENwMIIAJBIGokAA8LIAZBCGohBiAHIQMMAAsAC7gCAgZ/An4jAEEgayICJAAgAkEYakIANwMAIAJBEGpCADcDACACQQhqQgA3AwAgAkIANwMAA0ACQCADQQRHBEAgA0EBaiEHIAIgA0EDdGohBUEAIQMgBiEEA0AgA0HAAEYNAiAEQSBHBEAgBSAFKQMAIAEgBGoxAAAgA0E4ca2GhDcDACADQQhqIQMgBEEBaiEEDAELC0Hk7MgAIARBIBDkAgALIAAgAikDGCIIQhCINwMgIAAgAikDACIJQv////////8HgzcDACAAIAhCJIZCgICAgID+/weDIAIpAxAiCEIciIQ3AxggACAIQhiGQoCAgPj///8HgyACKQMIIghCKIiENwMQIAAgCEIMhkKA4P//////B4MgCUI0iIQ3AwggAkEgaiQADwsgBkEIaiEGIAchAwwACwALugIBBH8jAEHQAGsiAiQAAn8gARCzBSIERQRAIAIgACAAKAIMEIUEIAIoAgQhAyACKAIADAELIAAoAgghA0EBIQUgACgCAAshACACQQhqELUBIAJBIGogAkEQaikDADcDACACIAQ6ACggAiACKQMINwMYIAJBPGpB/JHKADYCACACIAU6AEAgAkEANgI0IAIgATYCMCACIAJBGGo2AjgCfyACQTBqKAIAQemOygBBERCIBQR/QQEFQQALRQRAIANBGGwhAQNAQQAgAUUNAhogAkEANgJMIAIgAkEwajYCSCACQcgAaiAAEMoBRQRAIAIoAkgiAyADKAIEQQFqNgIEIAFBaGohASAAQRhqIQAMAQsLIAIoAkgiACAAKAIEQQFqNgIEQQEMAQtBAQsgAkEYahD6AiACQdAAaiQAC6oCAQJ/IwBBkARrIgIkACACIAEQPCAAAn8gAikDAEIBUgRAIAJB9wJqIAJB1AFqIgEpAAA3AAAgAkHwAmogAkHNAWoiAykAADcDACACIAIpAMUBNwPoAiACQcUBaiACQegCakGjARDyAxogAEEBOgAEIAAgAikAxQE3AAUgAEENaiADKQAANwAAIABBFGogASkAADcAAEEBDAELIAJB6AJqQQNyIAJBCGpBoAEQ8gMaIAJBxQFqIAJB6AJqQaMBEPIDGiACIAJByAFqQaABEPIDIgNBuAFqIAFBGGopAAA3AwAgA0GwAWogAUEQaikAADcDACADQagBaiABQQhqKQAANwMAIAMgASkAADcDoAEgAEEIaiADQcABEPIDGkEACzYCACACQZAEaiQAC7YCAQF/IwBBoARrIgQkACAEQaACaiACQdABEPIDGiAEQRhqIANBGGopAAA3AwAgBEEQaiADQRBqKQAANwMAIARBCGogA0EIaikAADcDACAEIAMpAAA3AwAgBEHgAGogASAEQaACaiAEEDggBCAEQeAAakHAABDyAyIBQdgAaiICIAFBuAFqKQMANwMAIAFB0ABqIgMgAUGwAWopAwA3AwAgAUHIAGoiBCABQagBaikDADcDACABIAEpA6ABNwNAIAFB4ABqIAEQ4AQgAUGgAmogAUHgAGpBwAEQ8gMaIAFB4ANqIAFBwAAQ8gMaIAAgAUGgAmpBgAIQ8gMiAEGYAmogAikDADcAACAAQZACaiADKQMANwAAIABBiAJqIAQpAwA3AAAgACABKQNANwCAAiABQaAEaiQAC/ABAgV/AX4jAEHQAGsiAyQAIANBMGogABDRBCADQSBqIANBMGpBlPXJABCFAyADIAMtACQiBzoALCADIAMoAiAiBTYCKCAAQQhqIQZBASEEAkAgAC0AEARAEO8FIAMoAhghAAJAQX8gAykDECIIIAFSIAggAVYbIgQEfyAEBSAAIAJLDQEgACACRwtBAUYNAgtBACEECyADIAc6ACwgAyAFNgIoIANBKGoQ0gQgA0HQAGokACAEDwsgAyABIAIgCCAAEIsDIAMpAwAaIAMoAggaIAYgBSgCABCoBCAGKAIAGkGLp8oAQR1B2KfKABC8BAAL1wIBAX8jAEGAA2siAyQAIAJBIEcEQCADQfAAakK5gICAgAQ3AwAgA0HsAGpBjYDAADYCACADQegAakENNgIAIANBAzoAYCADIAMvAAA7AGEgA0GAgMAANgJkIAMgA0ECai0AADoAY0HzgcAAQSsgA0HgAGpBoILAAEHcg8AAEKgCAAsgA0H4AGpCADcDACADQfAAakIANwMAIANB6ABqQgA3AwAgA0IANwNgIANB4ABqQSAgAUEgEK4BIANBAmogAy0AZiIBOgAAIANB/wJqIANB/wBqMQAAPAAAIAMgAygCYDYC4AIgAyADLwFkOwHkAiADIAE6AOYCIAMgAykAdzcA9wIgAyADKQBnNwDnAiADIAMpAG83AO8CIANB4ABqIANB4AJqEN8EIAMgA0HgAGoQkQEgACADQeAAEJwDIANB4ABqEKIFIANB4AJqEPMBIANBgANqJAALrgIBBH8jAEEwayIDJAAgACAAKQMAIAKtQgOGfDcDACADIABBzABqNgIYIAAoAgghBCADIANBGGo2AhwCQCAERQ0AQcAAIARrIgQgAksNACADQSBqIAEgAiAEELcDIANBLGooAgAhAiADKAIoIQEgAygCJCEEIAMoAiAhBSADQRBqIABBDGoiBkHAACAAKAIIEJ0EIAMoAhAgAygCFCAFIAQQsQEgAEEANgIIIANBHGogBhC6BQsDQCACQcAATwRAIANBIGogASACQcAAELcDIAMoAiwhAiADKAIoIQEgA0EcaiADKAIgELoFDAELCyADQQhqIAAoAggiBCACIARqIABBDGpBwAAQ1AMgAygCCCADKAIMIAEgAhCxASAAIAAoAgggAmo2AgggA0EwaiQAC8MCAgN/An4jAEFAaiIDJAAgAAJ/QQEgAC0ACA0AGiAAKAIEIQUgACgCACIELQAAQQRxRQRAQQEgBCgCGEGlrMoAQa+sygAgBRtBAkEBIAUbIARBHGooAgAoAgwRBAANARogASAAKAIAIAIoAgwRAgAMAQsgBUUEQEEBIAQoAhhBrazKAEECIARBHGooAgAoAgwRBAANARogACgCACEECyADQQE6ABcgA0E0akGErMoANgIAIAMgBCkCGDcDCCADIANBF2o2AhAgBCkCCCEGIAQpAhAhByADIAQtACA6ADggAyAHNwMoIAMgBjcDICADIAQpAgA3AxggAyADQQhqNgIwQQEgASADQRhqIAIoAgwRAgANABogAygCMEGjrMoAQQIgAygCNCgCDBEEAAs6AAggACAAKAIEQQFqNgIEIANBQGskAAvCAgIDfwJ+IwBBQGoiAiQAAn9BASAALQAEDQAaIAAtAAUhBCAAKAIAIgMtAABBBHFFBEAgASAEBH9BASADKAIYQaWsygBBAiADQRxqKAIAKAIMEQQADQIaIAAoAgAFIAMLQYiaygAoAgARAgAMAQsgBEUEQEEBIAMoAhhBsqzKAEEBIANBHGooAgAoAgwRBAANARogACgCACEDCyACQQE6ABcgAkE0akGErMoANgIAIAIgAykCGDcDCCACIAJBF2o2AhAgAykCCCEFIAMpAhAhBiACIAMtACA6ADggAiAGNwMoIAIgBTcDICACIAMpAgA3AxggAiACQQhqNgIwQQEgASACQRhqQYiaygAoAgARAgANABogAigCMEGjrMoAQQIgAigCNCgCDBEEAAshASAAQQE6AAUgACABOgAEIAJBQGskAAv2AQEGfyAAKAIAIgEgACgCBCIDRgRAQYCAxAAPCyAAIAFBAWoiAjYCACABLAAAIgRBf0oEQCAEQf8BcQ8LAn8gAiADRgRAIAMhAkEADAELIAAgAUECaiICNgIAIAEtAAFBP3ELIQYgBEEfcSEFIARB/wFxQd8BTQRAIAYgBUEGdHIPCwJ/IAIgA0YEQCADIQFBAAwBCyAAIAJBAWoiATYCACACLQAAQT9xCyAGQQZ0ciECIARB/wFxQfABSQRAIAIgBUEMdHIPCyABIANGBH9BAAUgACABQQFqNgIAIAEtAABBP3ELIAVBEnRBgIDwAHEgAkEGdHJyC6ECAQN/IwBBoAJrIgIkACACQSBqQQBB4AAQwQQaIAJBGGogAkEgakHgAEHAABCeBCACKAIcIQMgAigCGCACQcABakEAQcAAEMEEGiACQYACaiABQcABahDWAyACQYACahDJAyACQRBqIAJBwAFqQcAAQSAQngQgAigCECACKAIUIAJBgAJqQSAQrQEgAkEIaiACQcABakHAAEEgEJ0EIAIoAgggAigCDCABQeABakEgEK0BIAJBgAFqIAJBwAFqQcAAEPIDGiADIAJBgAFqQcAAEK0BIAIgAkEgakHgAEHAABCdBCACKAIEIQMgAigCACACQcABaiABQaABahDWAyADIAJBwAFqQSAQrQEgACACQSBqQeAAEPIDGiACQaACaiQAC5ACAQJ/IwBBkANrIgMkACADIAFBKGoiBCABENUDIANBKGogBCABEN8BIANB0ABqIAMgAhAeIANB+ABqIANBKGogAkEoahAeIANBoAFqIAFB+ABqIAJB+ABqEB4gA0HIAWogAUHQAGogAkHQAGoQHiADQfABaiADQcgBaiADQcgBahDVAyAAIANB0ABqIANB+ABqEN8BIANBmAJqIANB0ABqIANB+ABqENUDIANBwAJqIANB8AFqIANBoAFqENUDIANB6AJqIANB8AFqIANBoAFqEN8BIABBKGogA0GYAmpBKBDyAxogAEHQAGogA0HAAmpBKBDyAxogAEH4AGogA0HoAmpBKBDyAxogA0GQA2okAAuQAgECfyMAQZADayIDJAAgAyABQShqIgQgARDVAyADQShqIAQgARDfASADQdAAaiADIAJBKGoQHiADQfgAaiADQShqIAIQHiADQaABaiABQfgAaiACQfgAahAeIANByAFqIAFB0ABqIAJB0ABqEB4gA0HwAWogA0HIAWogA0HIAWoQ1QMgACADQdAAaiADQfgAahDfASADQZgCaiADQdAAaiADQfgAahDVAyADQcACaiADQfABaiADQaABahDfASADQegCaiADQfABaiADQaABahDVAyAAQShqIANBmAJqQSgQ8gMaIABB0ABqIANBwAJqQSgQ8gMaIABB+ABqIANB6AJqQSgQ8gMaIANBkANqJAALkQIBBX8jAEEQayIEJAAgACgCACEBAkADQCABIgJBBEkgAkECcXINASAAIAJBAnIgACgCACIBIAEgAkYbNgIAIAEgAkcNAAsDQCACQXxxIgUhAQNAIAEoAhQiA0UEQCABKAIcIgMgATYCGCADIQEMAQsLIAUgAzYCFAJAAkAgAkEBcUUEQCACIQEgAygCGCICRQ0BIAUgAjYCFCAAIAAoAgBBfXE2AgAMAgsgACACQX1xIAAoAgAiASABIAJGIgMbNgIAIAEhAiADRQ0CDAMLA0AgACABQQFxIAAoAgAiAiABIAJGIgEbNgIAIAENASACIQEgAkEESQ0ACwwBCwsgBCADEJkDIAQQ8wQLIARBEGokAAv/AQECfyMAQRBrIgIkACACQQA2AgwCfwJAAkAgAUGAAU8EQCABQYAQSQ0BIAJBDGohAyABQYCABE8NAiACIAFBP3FBgAFyOgAOIAIgAUEGdkE/cUGAAXI6AA0gAiABQQx2QQ9xQeABcjoADEEDDAMLIAIgAToADCACQQxqIQNBAQwCCyACIAFBP3FBgAFyOgANIAIgAUEGdkEfcUHAAXI6AAwgAkEMaiEDQQIMAQsgAiABQT9xQYABcjoADyACIAFBEnZB8AFyOgAMIAIgAUEGdkE/cUGAAXI6AA4gAiABQQx2QT9xQYABcjoADUEECyEBIAAgAyABEEYgAkEQaiQAC/0BAgR/AX4jAEEwayIBJAAgACgCACIAKAIAIQIgAEEANgIAIAAoAgQgASACKAIAKAIYEQMAKAIAIQAgAUEoaiIEIAFBEGooAgA2AgAgAUEgaiIFIAFBCGopAwA3AwAgASABKQMANwMYIABBBGohAgJAIAAoAgRFDQAgAEEIaigCACIARQ0AAn8CQCAAQQhqIgMgAEEFakkNACAAQQFqrUIMfiIGQiCIpw0AIANBfHEiAyAGp2oiACADSQ0AQQQMAQtBAAshAyACKAIAIAAgAxC2BQsgAiABKQMYNwIAIAJBEGogBCgCADYCACACQQhqIAUpAwA3AgAgAUEwaiQAC4oCAQJ/IwBBIGsiASQAAkACQAJAAkBB3PnKACgCACICQQFNBEACQAJAIAJBAWsEQCABQRBqEOoFIAEoAhBFDQEgASABQRBqNgIAIAEQoAUEQCABQRBqEJIFDAMLIAFBEGoQhgRFDQEMBQsgAEEANgIADAYLIAEQ6gUgASgCAEUNAiABIAE2AhwgAUEcahCgBSABEJIFIAFBEGoQkgVFDQQLQdz5ygBBAjYCAAsgAUEQahCEBCABEKICIAAgASkDEDcCACAAQQhqIAEpAwA3AgAgAEEQaiABQQhqKQMANwIADAMLIAEQkgULIAFBEGoQkgULIABBADYCAEHc+coAQQE2AgALIAFBIGokAAuYAgEBfyMAQdAAayICJAACfyAAKAIIRQRAIAIgAC0AEBChAyACQSRqQegANgIAIAJBxABqQQI2AgAgAkHoADYCHCACIAA2AhggAkIDNwI0IAJBvITKADYCMCACIAIpAwA3A0ggAiACQcgAajYCICACIAJBGGo2AkAgASACQTBqEOgCDAELIAIgAEEIajYCFCACQQhqIAAtABAQoQMgAkHEAGpB6QA2AgAgAkE8akHoADYCACACQSxqQQM2AgAgAkHoADYCNCACIAA2AjAgAkIDNwIcIAJB4ITKADYCGCACIAIpAwg3A0ggAiACQRRqNgJAIAIgAkHIAGo2AjggAiACQTBqNgIoIAEgAkEYahDoAgsgAkHQAGokAAuAAgECfyMAQfACayIDJAAgA0EIaiABQShqIgQgARDVAyADQTBqIAQgARDfASADQdgAaiADQQhqIAIQHiADQYABaiADQTBqIAJBKGoQHiADQagBaiABQfgAaiACQdAAahAeIANB0AFqIAFB0ABqIgEgARDVAyAAIANB2ABqIANBgAFqEN8BIANB+AFqIANB2ABqIANBgAFqENUDIANBoAJqIANB0AFqIANBqAFqENUDIANByAJqIANB0AFqIANBqAFqEN8BIABBKGogA0H4AWpBKBDyAxogAEHQAGogA0GgAmpBKBDyAxogAEH4AGogA0HIAmpBKBDyAxogA0HwAmokAAuAAgECfyMAQfACayIDJAAgA0EIaiABQShqIgQgARDVAyADQTBqIAQgARDfASADQdgAaiADQQhqIAJBKGoQHiADQYABaiADQTBqIAIQHiADQagBaiABQfgAaiACQdAAahAeIANB0AFqIAFB0ABqIgEgARDVAyAAIANB2ABqIANBgAFqEN8BIANB+AFqIANB2ABqIANBgAFqENUDIANBoAJqIANB0AFqIANBqAFqEN8BIANByAJqIANB0AFqIANBqAFqENUDIABBKGogA0H4AWpBKBDyAxogAEHQAGogA0GgAmpBKBDyAxogAEH4AGogA0HIAmpBKBDyAxogA0HwAmokAAulAgEDfyMAQSBrIgEkAAJAAkBB/PnKACgCACIAQQFqQQBKBEBB/PnKACAANgIAQYD6ygAoAgAiAkUEQCABQQA2AgggAUEIahBrIQJB/PnKACgCAA0DQfz5ygBBfzYCAAJAQYD6ygAoAgAiAEUNACAAIAAoAgAiAEF/ajYCACAAQQFHDQBBgPrKABDSAgtBgPrKACACNgIAQfz5ygBB/PnKACgCAEEBaiIANgIACyAADQJB/PnKAEF/NgIAIAIgAigCACIAQQFqNgIAIABBf0wNAUH8+coAQfz5ygAoAgBBAWo2AgAgAUEgaiQAIAIPC0HwmsoAQRggAUEYakHknMoAQYibygAQqAIACwALQYyaygBBECABQRhqQcScygBB4JrKABCoAgAL3gEBCH8gACABKAIMIAMoAgwgAigCCCIEQRp3IARBFXdzIARBB3dzamogASgCCCIGIAIoAgwiB3MgBHEgBnNqIgogASgCBGoiBTYCDCAAIAogASgCACIIIAIoAgAiAXEgAigCBCIJIAFxIgtzIAggCXFzIAFBHncgAUETd3MgAUEKd3NqaiICNgIEIAAgCCAGIAMoAghqIAcgBSAEIAdzcXNqIAVBGncgBUEVd3MgBUEHd3NqIgNqNgIIIAAgAkEedyACQRN3cyACQQp3cyACIAEgCXNxIAtzaiADajYCAAuHAgEEfyMAQbABayICJABBASEDIAJBEGoQmAMgAkHYAGogAkEoaikDADcDACACQdAAaiACQSBqKQMANwMAIAJByABqIAJBGGopAwA3AwAgAiACKQMQNwNAIAJBADYCaCACQgA3A2AgAkEwaiACQUBrIABBA2wiAEECTwRAQX8gAEF/amd2QQFqIQMLIAMQ2wQgAkEwaiIEIgAoAggiBSAAKAIERwRAIAAgBRC2AgsgAkEIaiAEKQIANwIAIAIoAgwhBCACKAIIIQVBEEEEEKQFIgBFBEBBEEEEEN0FAAsgACABNgIMIAAgBTYCACAAIAQ2AgQgAEEfIANnazYCCCACQbABaiQAIAALpwEBAX8gAAJ/QQAgASgCBCIEIAJrIANPDQAaAkACQCACIANqIgMgAk8EQCAEQQF0IgIgAyACIANLGyECDAELIAAgAzYCBAwBCwJAIAJBAE4EQAJ/IARFBEAgAkEBEKQFDAELIAEoAgAgBEEBIAIQlAULIgAEQCABIAI2AgQgASAANgIAQQAMBAsMAQsMAQsgAkEBEN0FAAsgAEEIakEANgIAQQELNgIAC/QBAQd/IwBBQGoiASQAIAFBIGoQywQgAUEIaiICIAFBKGoiBSkDADcDACABQRBqIgMgAUEwaiIGKQMANwMAIAFBGGoiBCABQThqIgcpAwA3AwAgASABKQMgNwMAIAAgASkDADcAACAAQQhqIAIpAwA3AAAgAEEQaiADKQMANwAAIABBGGogBCkDADcAACABQSBqEMsEIAIgBSkAADcDACADIAYpAAA3AwAgBCAHKQAANwMAIAEgASkAIDcDACAAIAEpAwA3ACAgAEEoaiACKQMANwAAIABBMGogAykDADcAACAAQThqIAQpAwA3AAAgAUFAayQAC/MBAgJ/BH4jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAAkBCACEFQgAgBkIBg30hBkEAIQMDQCADQQVGDQEgBEEIaiADEOIEKQMAIQdBgLzEACADEOIEKQMAIQggBEEIaiADEOMEIAcgBUI0iHwgBiAIg3wiBUL/////////B4M3AwAgA0EBaiEDDAALAAsFIAEgAxDiBCkDACEFIAIgAxDiBCkDACEHIARBCGogAxDjBCAFIAZ9IAd9IgVC/////////weDNwMAIAVCP4ghBiADQQFqIQMMAQsLIAAgBEEIakEoEPIDGiAEQTBqJAAL8wECAn8EfiMAQTBrIgQkACAEQQhqQQBBKBDBBBoDQCADQQVGBEACQEIAIQVCACAGQgGDfSEGQQAhAwNAIANBBUYNASAEQQhqIAMQ5QQpAwAhB0HY7cgAIAMQ5QQpAwAhCCAEQQhqIAMQ5gQgByAFQjSIfCAGIAiDfCIFQv////////8HgzcDACADQQFqIQMMAAsACwUgASADEOUEKQMAIQUgAiADEOUEKQMAIQcgBEEIaiADEOYEIAUgBn0gB30iBUL/////////B4M3AwAgBUI/iCEGIANBAWohAwwBCwsgACAEQQhqQSgQ8gMaIARBMGokAAvrAQIHfwR+IwBBIGsiByQAA0AgA0EgaiIEIAJLBEAgAyACSQRAIAcgACADaiIAIAIgA2siBBDyAyECIAAgASADaiIAIAQQ8gMaIAAgAiAEEPIDGgsgB0EgaiQABSAAIANqIgUpAAAhCiAFIAEgA2oiBikAADcAACAFQRhqIgMpAAAhCyADIAZBGGoiCCkAADcAACAFQRBqIgMpAAAhDCADIAZBEGoiCSkAADcAACAFQQhqIgMpAAAhDSADIAZBCGoiAykAADcAACADIA03AAAgCSAMNwAAIAggCzcAACAGIAo3AAAgBCEDDAELCwvtAQECfyMAQfACayICJAAgAkEIaiABEMgFIAJBMGogAUEoaiIDEMgFIAJB2ABqIAFB0ABqEPECIAJBgAFqIAEgAxDVAyACQagBaiACQYABahDIBSACQdABaiACQTBqIAJBCGoQ1QMgAkH4AWogAkEwaiACQQhqEN8BIAAgAkGoAWogAkHQAWoQ3wEgAkGgAmogAkH4AWpBKBDyAxogAkHIAmogAkHYAGogAkH4AWoQ3wEgAEEoaiACQdABakEoEPIDGiAAQdAAaiACQaACakEoEPIDGiAAQfgAaiACQcgCakEoEPIDGiACQfACaiQAC+kBAQN/IwBBgAJrIgMkACADQRhqQgA3AwAgA0EgakIANwMAIANBKGpCADcDACADQgA3AxAgA0IBNwMIIANCATcDMCADQThqQQBByAAQwQQaIAJBGHRBH3UiBCACaiAEcyEFQQEhAgNAIAJBCUYEQCAEQQFxEJYFIQEgA0GIAWogA0EIahCHAyADQQhqIANBiAFqIAEQrAQgACADQQhqQfgAEPIDGiADQYACaiQABSADIAU6AIcBIAMgAjoAiAEgA0EIaiABIANBhwFqIANBiAFqENcEEKwEIAFB+ABqIQEgAkEBaiECDAELCwviAQEGfyMAQRBrIgQkAEEIIQUCfyAAKAIAIgJBCE0EQCAAQQhqIQMgAgwBCyAAQQhqKAIAIQMgAiEFIABBDGooAgALIgYgAU0EQAJAAkAgAUEISwRAIAEgBUYNASAEQQhqIAEQqgIgBCgCCCADIAZBDGwQ8gMhByAAQQxqIAY2AgAgAEEIaiAHNgIAIABBATYCBCAAIAE2AgAgAkEJTw0BDAILIAJBCUkNASAAQQA2AgQgAEEIaiADIAZBDGwQ8gMaCyADIAUQtgQLIARBEGokAA8LQczxyQBBIEGM8skAELkEAAvfAQECfyMAQeAAayICJAAgAkEQaiABQQt2EIEDIAJBKGoiASACQRhqKAIANgIAIAIgAikDEDcDICACEMgENgIwIAJBCGogAkEgahCbBSACIAIoAgggAigCDBDaBDoANyACIAJBIGoQmwUgAkHMAGpBADoAACACQcQAaiACKAIAIgMgAigCBGo2AgAgAkEANgJQIAJByABqIAJBN2o2AgAgAkIANwM4IAIgAzYCQCACIAJBMGo2AlggACACQThqEM8BIABBFGogASgCADYCACAAIAIpAyA3AgwgAkHgAGokAAvoAQEDfyMAQSBrIgQkAAJAIANFBEAgAEEFOgAQDAELIARCADcDCCAEQQhqIgUoAgAEQCAFQQRqENADCyAEIAIgA0EAEMYEQYCABEF/IAEoAgBBAUYbIQUgBCgCACECIAQoAgQhAwNAIANBACACG0UEQCAAQQU6ABAMAgsgBEEIaiABIAIgBSADIAMgBUsbIgYQjAQgBC0AGEEFRgRAIAMgBmshAyACIAZqIQIgBEEIahCYBQwBCwsgACAEKQMINwIAIABBEGogBEEYaigCADYCACAAQQhqIARBEGopAwA3AgALIARBIGokAAvjAQEEfyMAQUBqIgIkACABQQRqIQQgASgCBEUEQCABKAIAIQMgAkEANgIgIAJCATcDGCACIAJBGGo2AiQgAkE4aiADQRBqKQIANwMAIAJBMGogA0EIaikCADcDACACIAMpAgA3AyggAkEkakHkmcoAIAJBKGoQMxogAkEQaiIDIAIoAiA2AgAgAiACKQMYNwMIAkAgASgCBCIFRQ0AIAFBCGooAgAiAUUNACAFIAFBARC2BQsgBCACKQMINwIAIARBCGogAygCADYCAAsgAEHApcoANgIEIAAgBDYCACACQUBrJAALLgEBfyMAQeAAayICJAAgAkEENgIIIAJBBDYCDCAAIAFBEBDyAxogAkHgAGokAAvTAQAgAAJ/AkACQCABQYABTwRAIAFBgBBJDQEgAUGAgARPDQIgAiABQT9xQYABcjoAAiACIAFBBnZBP3FBgAFyOgABIAIgAUEMdkEPcUHgAXI6AABBAwwDCyACIAE6AABBAQwCCyACIAFBP3FBgAFyOgABIAIgAUEGdkEfcUHAAXI6AABBAgwBCyACIAFBP3FBgAFyOgADIAIgAUESdkHwAXI6AAAgAiABQQZ2QT9xQYABcjoAAiACIAFBDHZBP3FBgAFyOgABQQQLNgIEIAAgAjYCAAvrAQIDfwF+QTggASgCGCIDayEEA0ACQAJAAn8gA0ELTwRAIAEgA0F1ajYCGCABIAEpAwAiBUILhjcDACAFQjWIpyEBQQEMAQsCQAJAAkACQCABLQAUQQFrDgICAQALIAEoAggiAiABKAIMRw0EIAFBAjoAFAsgASgCECECIAFBADYCECACDQQMAQsgASgCCCICIAEoAgxHDQILQQALIQIgACABOwECIAAgAjsBAA8LIAEgAkEBajYCCAsgAjEAACEFIAEgA0EIaiIDNgIYIAEgASkDACAFIARBP3GthoQ3AwAgBEF4aiEEDAALAAvLAQECfyMAQTBrIgMkACADQRBqIAEgAhCgAyADQQhqIANBEGoQmwUgA0EgaiADKAIIIAMoAgwQJEEBIQEgA0EoaigCACECIAMoAiQhBAJAIAMoAiBBAUcEQCADQSxqKAIAIQEgACADKQMQNwIEIABBGGogATYCACAAQRRqIAI2AgAgAEEQaiAENgIAIABBDGogA0EYaigCADYCAEEAIQEMAQsgAyAEIAIQpgUgACADKQMANwIEIANBEGoQgQULIAAgATYCACADQTBqJAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBJDYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQYT5wwA2AhAgBEEkNgIsIARB2PnDADYCWCAEQgE3AkwgBEHQ+cMANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBpPrDABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBJTYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQYi/xAA2AhAgBEElNgIsIARB3L/EADYCWCAEQgE3AkwgBEHUv8QANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBqMDEABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBKzYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQeDHxAA2AhAgBEErNgIsIARBtMjEADYCWCAEQgE3AkwgBEGsyMQANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBgMnEABC9BAAL3wEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBLzYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQayryAA2AhAgBEEvNgIsIARBgKzIADYCWCAEQgE3AkwgBEH4q8gANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpBzKzIABC9BAAL4QEBAX8jAEHgAGsiBCQAIAQgATYCCCAEIAM2AgwgASADRgRAIAAgAiABEPIDGiAEQeAAaiQADwsgBEE8akEhNgIAIARBNGpBxQA2AgAgBEEkakEDNgIAIAQgBEEIajYCQCAEIARBDGo2AkQgBEHcAGpBADYCACAEQgM3AhQgBEGY4skANgIQIARBxQA2AiwgBEHs4skANgJYIARCATcCTCAEQeTiyQA2AkggBCAEQShqNgIgIAQgBEHIAGo2AjggBCAEQcQAajYCMCAEIARBQGs2AiggBEEQakG448kAEL0EAAvhAQEBfyMAQeAAayIEJAAgBCABNgIIIAQgAzYCDCABIANGBEAgACACIAEQ8gMaIARB4ABqJAAPCyAEQTxqQSE2AgAgBEE0akHiADYCACAEQSRqQQM2AgAgBCAEQQhqNgJAIAQgBEEMajYCRCAEQdwAakEANgIAIARCAzcCFCAEQZj6yQA2AhAgBEHiADYCLCAEQez6yQA2AlggBEIBNwJMIARB5PrJADYCSCAEIARBKGo2AiAgBCAEQcgAajYCOCAEIARBxABqNgIwIAQgBEFAazYCKCAEQRBqQbj7yQAQvQQAC+EBAQF/IwBB4ABrIgQkACAEIAE2AgggBCADNgIMIAEgA0YEQCAAIAIgARDyAxogBEHgAGokAA8LIARBPGpBITYCACAEQTRqQfwANgIAIARBJGpBAzYCACAEIARBCGo2AkAgBCAEQQxqNgJEIARB3ABqQQA2AgAgBEIDNwIUIARBvIrKADYCECAEQfwANgIsIARBkIvKADYCWCAEQgE3AkwgBEGIi8oANgJIIAQgBEEoajYCICAEIARByABqNgI4IAQgBEHEAGo2AjAgBCAEQUBrNgIoIARBEGpB3IvKABC9BAAL0wEBBX8jAEFAaiICJAAgAkEIaiABEEcCQCACKAIIIgQEQCACKAIMIQUgAhC0AiACKAIEIQYgAigCACIDIAU2AgQgAyAENgIAIAJBATYCGCACIAY2AhQgAiADNgIQIAJBOGogAUEYaikCADcDACACQTBqIAFBEGopAgA3AwAgAkEoaiABQQhqKQIANwMAIAIgASkCADcDICACQRBqIAJBIGoQjwMgAEEIaiACKAIYNgIAIAAgAikDEDcCAAwBCyAAQQA2AgggAEIENwIACyACQUBrJAAL/gEBA38jAEEQayICJAACQAJAQSNBARCkBSIBBEAgAUEfakGHp8oAKAAANgAAIAFBGGpBgKfKACkAADcAACABQRBqQfimygApAAA3AAAgAUEIakHwpsoAKQAANwAAIAFB6KbKACkAADcAAEEMQQQQpAUiA0UNASADQqOAgICwBDcCBCADIAE2AgBBDEEEEKQFIgFFDQIgAUEQOgAIIAFBqKHKADYCBCABIAM2AgAgASACLwANOwAJIAFBC2ogAkEPai0AADoAACAAQQhqIAE2AgAgAEKBgICAIDcCACACQRBqJAAPC0EjQQEQ3QUAC0EMQQQQ3QUAC0EMQQQQ3QUAC7wBAgN/AX4CQCACRQRAIABBADoAAQwBCwJAAkAgAS0AAEErRgRAIAJBf2oiAkUNASABQQFqIQELAkACQANAIAJFDQIgAS0AAEFQaiIEQQlLDQEgA61CCn4iBkIgiKcNBCABQQFqIQEgAkF/aiECIAQgBqciBWoiAyAFTw0ACwwDCyAAQQE6AAEMAwsgAEEEaiADNgIAIABBADoAAA8LIABBADoAASAAQQE6AAAPCyAAQQI6AAELIABBAToAAAvhAQEBfyMAQcABayICJAAgASABLQAAQfgBcToAACABIAEtAB9BP3FBwAByOgAfIAJBGGogAUEYaikAADcDACACQRBqIAFBEGopAAA3AwAgAkEIaiABQQhqKQAANwMAIAIgASkAADcDACACQaABaiACELsDIAIgAkGgAWpB8LrGABDNBSACQaABaiACENgBIAAgAkGgARDyAyIAQbgBaiACQbgBaikDADcAACAAQbABaiACQbABaikDADcAACAAQagBaiACQagBaikDADcAACAAIAIpA6ABNwCgASACQcABaiQAC+EBAQF/IwBBsAVrIgUkACAFQagDaiABIAIQKyAFQagBaiAFQagDakGcg8AAEMgCIAVBCGogAyAEEKQCIAVBwQNqIAVBIGopAwA3AAAgBUG5A2ogBUEYaikDADcAACAFQbEDaiAFQRBqKQMANwAAIAVBAToAqAMgBSAFKQMINwCpAyAFQegAaiAFQegCaiAFQagDahBoIAVBqANqIAVB6ABqEN8EIAVBCGogBUGoA2oQkQEgACAFQQhqQeAAEJwDIAVBqANqEKIFIAVB6ABqEPMBIAVBqAFqEKIFIAVBsAVqJAAL4QEBAn8jAEHQAGsiAiQAIAEoAsABQf8AcSIDBEAgAkEIaiABIAMQxAQgAigCCEEAIAIoAgwQwQQaCyABQn8QCyACQShqIAFBmAFqKQMANwMAIAJBIGogAUGQAWopAwA3AwAgAkEYaiABQYgBaikDADcDACACQThqIAFBqAFqKQMANwMAIAJBQGsgAUGwAWopAwA3AwAgAkHIAGogAUG4AWopAwA3AwAgAiABKQOAATcDECACIAFBoAFqKQMANwMwIAEoAsgBIQEgACACQRBqQcAAEPIDIAE2AkAgAkHQAGokAAvLAQEDfyMAQSBrIgEkACAAKAIIQRhsIQIgACgCAEEMaiEAA0ACQAJAIAIEQCAAKAIARQ0BDAILIAFBIGokAA8LIAFBADYCCCABQgQ3AwACQCAAQXRqKAIAQQFGBEAgAEF4aigCABCOBAwBCyAAQXhqEI4ECyABQRhqIgMgAUEIaigCADYCACABIAEpAwA3AxAgACgCAARAIAAQowMgABD0BAsgACABKQMQNwIAIABBCGogAygCADYCAAsgAkFoaiECIABBGGohAAwACwAL3AEBBH8jAEEgayIDJAACQAJAIAEEQCADIAE2AgwgAyAANgIIIANBEGogA0EIahAhIAMoAhAiAARAA0AgAygCHCEFIAMoAhQiBiABRg0DQQEhBCACKAIYIAAgBiACKAIcKAIMEQQADQQgBQRAIAIoAhhB/f8DIAIoAhwoAhARAgANBQsgA0EQaiADQQhqECEgAygCECIADQALC0EAIQQMAgsgAkHEqsoAQQAQLiEEDAELIAVFBEAgAiAAIAEQLiEEDAELQdCwygBBI0GMscoAEM4DAAsgA0EgaiQAIAQL0QEBAX8jAEGgBWsiBSQAIAUgAzYCDCAFIAI2AgggBUEQahCyAyAFQagDaiABQaABEPIDGiAFQYgCaiAFQagDahDiBSAFQRBqIAQQxgUgBUEQaiABQaABahDGBSAFQRBqIAVBCGoQrgQgBUGoA2ogBUEQakHYARDyAxogBUHoAWogBUGoA2oQ4gIgBUGoA2ogBUHoAWogBUGIAmogBEEgahA6IAVBgAVqIAVBqANqENgBIABBBUEDIAVBgAVqQSAgBEEgEKMEGzYCACAFQaAFaiQAC58CAQF/IwBB0AFrIgQkACABQX9qQT9LIANBwQBPckUEQCAEQQBBgAEQwQQiBEG4AWpC+cL4m5Gjs/DbADcDACAEQbABakLr+obav7X2wR83AwAgBEGoAWpCn9j52cKR2oKbfzcDACAEQaABakLRhZrv+s+Uh9EANwMAIARBmAFqQvHt9Pilp/2npX83AwAgBEGQAWpCq/DT9K/uvLc8NwMAIARBiAFqQrvOqqbY0Ouzu383AwAgBEIANwPAASAEIAE2AsgBIAQgAa0gA61CCIaFQoiS95X/zPmE6gCFNwOAASADBEAgBEGAASACIAMQ5AQgBEKAATcDwAELIAAgBEHQARDyAxogBEHQAWokAA8LQezExABBMUH8xcQAEK0EAAvsAQEBfyMAQRBrIgIkAAJAAkACQAJAAkACQCAAKAIAQQFrDgQCAwQAAQsgAiABQdTfyQBBFBCcBCACIABBBGo2AgwgAiACQQxqQejfyQAQjgEgAiAAQQhqNgIMIAIgAkEMakH438kAEI4BDAQLIAIgAUGy4MkAQQ8QnAQMAwsgAiABQafgyQBBCxCcBAwCCyACIAFBmeDJAEEOEJwEIAIgAEEEajYCDCACIAJBDGpB6N/JABCOAQwBCyACIAFBiODJAEEREJwEIAIgAEEEajYCDCACIAJBDGpB6N/JABCOAQsgAhCAAiACQRBqJAALuQEBAX8jAEFAaiIDJAAgA0E4aiACQQhqKAIANgIAIAMgAikCADcDMCADQSBqIANBMGoQogMCQAJAIAAtABANACAAKAIADQAgA0EYaiADKAIgIAMoAiggAEEEahCNBCADKAIYIgBFDQAgA0EQaiAAIAMoAhwQpgUgAyADKQMQNwMwDAELIANBCGogAygCICADKAIoEKYFIAMgAykDCDcDMAsgA0EwaiABEPEDIANBIGoQgQUgA0FAayQAC4UCAQJ/IwBBIGsiBCQAQQEhBQJAAkACQEGI+soAKAIAQQFHBEBBiPrKAEKBgICAEDcDAAwBC0GM+soAQYz6ygAoAgBBAWoiBTYCACAFQQJLDQELIAQgAzYCHCAEIAI2AhggBEHsm8oANgIUIARB7JvKADYCEEHs+coAKAIAIgJBf0wNAEHs+coAIAJBAWoiAjYCAEHs+coAQfT5ygAoAgAiAwR/QfD5ygAoAgAgBEEIaiAAIAEoAhARAAAgBCAEKQMINwMQIARBEGogAygCDBEAAEHs+coAKAIABSACC0F/ajYCACAFQQFNDQELAAsjAEEQayICJAAgAiABNgIMIAIgADYCCAALwwEBA38jAEFAaiICJAAgAkEAQcAAEMEEIgQhAgNAIANBIEYEQAJAQQAhAwNAIANBP0YNASADIARqIgEgAS0AACICIAJBCGoiAkHwAXFrOgAAIAFBAWoiASABLQAAIAJBGHRBGHVBBHZqOgAAIANBAWohAwwACwALBSACIAEgAxDtBC0AAEEPcToAACACQQFqIAEgAxDtBC0AAEEEdjoAACACQQJqIQIgA0EBaiEDDAELCyAAIARBwAAQ8gMaIARBQGskAAvDAQEDfyMAQUBqIgIkACACQQBBwAAQwQQiBCECA0AgA0EgRgRAAkBBACEDA0AgA0E/Rg0BIAMgBGoiASABLQAAIgIgAkEIaiICQfABcWs6AAAgAUEBaiIBIAEtAAAgAkEYdEEYdUEEdmo6AAAgA0EBaiEDDAALAAsFIAIgASADEO4ELQAAQQ9xOgAAIAJBAWogASADEO4ELQAAQQR2OgAAIAJBAmohAiADQQFqIQMMAQsLIAAgBEHAABDyAxogBEFAayQAC78BAQN/AkAgACgCACIAQQRqKAIAIgQgAEEIaigCACIDayACTwRAIAAoAgAhBAwBCwJAIAIgA2oiBSADSQ0AIARBAXQiAyAFIAMgBUsbIgNBAEgNAAJ/IARFBEAgA0EBEKQFDAELIAAoAgAgBEEBIAMQlAULIgQEQCAAIAQ2AgAgAEEEaiADNgIAIABBCGooAgAhAwwCCyADQQEQ3QUACxDCBQALIABBCGogAiADajYCACADIARqIAEgAhDyAxpBAAu8AQIEfwF+IwBB4ABrIgAkACAAEJcFIABB2ABqIgEgAEEYaikDADcDACAAQdAAaiICIABBEGopAwA3AwAgAEHIAGoiAyAAQQhqKQMANwMAIAAgACkDADcDQEHw+soAIABBQGtBIBCiASAAQThqIAEpAwA3AwAgAEEwaiACKQMAIgQ3AwAgAEEoaiADKQMANwMAIAAgACkDQDcDICAEp0H/AXFBAkcEQCAAQSBqEIQFCyAAQeAAaiQAQfD6ygALuQEBAX8jAEHAA2siAiQAIAJBqAFqIAFBKBDyAxogAkHQAWogAUEoakEoEPIDGiACQfgBaiABQdAAakEoEPIDGkEDIQEDQCABBEAgAkGgAmogAkGoAWoQowEgAkEIaiACQaACakGgARDyAxogAkGgAmogAkEIahDyAiACQagBaiACQaACakH4ABDyAxogAUF/aiEBDAEFIAJBoAJqIAJBqAFqEKMBIAAgAkGgAmoQgwIgAkHAA2okAAsLC9EBAQJ/IwBBEGsiAiQAIAEoAhhB/cDKAEENIAFBHGooAgAoAgwRBAAhAyACQQA6AAUgAiADOgAEIAIgATYCACACIAA2AgwgAkHwwMoAQQQgAkEMakGMwcoAEGogAi0ABCEBIAItAAUEQCACAn9BASABQf8BcQ0AGiACKAIAIgBBHGooAgAoAgwhASAAKAIYIQMgAC0AAEEEcUUEQCADQausygBBAiABEQQADAELIANBqqzKAEEBIAERBAALIgE6AAQLIAJBEGokACABQf8BcUEARwvEAQECfyMAQYAPayICJAAgAkHgDWogARCJAgNAIANBgApGBEACQCACQYAKaiABENUCQQAhAwNAIANB4AhGDQEgAkHgDWogAkGACmogAiADaiIBEJIBIAJBwAxqIAJB4A1qEIMCIAJBoAtqIAJBwAxqEIkCIAFBoAFqIAJBoAtqQaABEPIDGiADQaABaiEDDAALAAsFIAIgA2ogAkHgDWpBoAEQ8gMaIANBoAFqIQMMAQsLIAAgAkGAChDyAxogAkGAD2okAAvEAQECfyMAQYAPayICJAAgAkHgDWogARCKAgNAIANBgApGBEACQCACQYAKaiABENUCQQAhAwNAIANB4AhGDQEgAkHgDWogAkGACmogAiADaiIBEJIBIAJBwAxqIAJB4A1qEIMCIAJBoAtqIAJBwAxqEIoCIAFBoAFqIAJBoAtqQaABEPIDGiADQaABaiEDDAALAAsFIAIgA2ogAkHgDWpBoAEQ8gMaIANBoAFqIQMMAQsLIAAgAkGAChDyAxogAkGAD2okAAvDAQEDfyMAQRBrIgMkACACKAIAIQQDQCABQQNNBEAgAUEBSwRAIAAvAAAhBSADQQhqIAAgAUECEMYEIARBBXcgBXNBufPd8XlsIQQgAygCDCEBIAMoAgghAAsgAiABBH8gAC0AACAEQQV3c0G5893xeWwFIAQLQQV3Qf8Bc0G5893xeWw2AgAgA0EQaiQABSAAKAAAIQUgAyAAIAFBBBDGBCAEQQV3IAVzQbnz3fF5bCEEIAMoAgQhASADKAIAIQAMAQsLC7MBAQV/IwBBQGoiBCQAIAEoAgwiA0H8kcoAIAMbIQIgAUEUaigCAEEAIAMbIgVBKGwhAwJAA0ACQCADQQAgAhtFBEBBACECIAUNAyABKAIEIQIgASgCACEBIARBAzoALCAEQQI2AjAgACACQQAgAUEBRhsgBEEIaiAEQTBqQQBBACICECMNAQwDCyAAIAEgAhDVASADQVhqIQMgAkEoaiECRQ0BCwtBASECCyAEQUBrJAAgAgu3AQEBfyMAQSBrIgUkACAFIAI2AgQgBSABNgIAIAUgAzYCCCAFIAQ2AgwCQCAEIANJDQAgA0UgAiADRnJFBEAgAiADTQ0BIAEgA2osAABBv39MDQELIARFIAIgBEZyRQRAIAIgBE0NASABIARqLAAAQb9/TA0BCyAAIAQgA2s2AgQgACABIANqNgIAIAVBIGokAA8LIAUgBUEMajYCGCAFIAVBCGo2AhQgBSAFNgIQIAVBEGoQ7wQAC7wBAQR/IwBBIGsiAiQAAkAgASwAHyIDQQBOBEAgAkEXaiABQRdqKQAANwAAIAJBEGoiBCABQRBqKQAANwMAIAJBCGoiBSABQQhqKQAANwMAIAIgASkAADcDACACIANB/wBxOgAfIAAgAhDWBAR/IAAgAikDADcAASAAQRlqIAJBGGopAwA3AAAgAEERaiAEKQMANwAAIABBCWogBSkDADcAAEEBBUEACzoAAAwBCyAAQQA6AAALIAJBIGokAAu8AQEEfyMAQSBrIgIkAAJAIAEsAB8iA0EATgRAIAJBF2ogAUEXaikAADcAACACQRBqIgQgAUEQaikAADcDACACQQhqIgUgAUEIaikAADcDACACIAEpAAA3AwAgAiADQf8AcToAHyAAIAIQ2QQEfyAAIAIpAwA3AAEgAEEZaiACQRhqKQMANwAAIABBEWogBCkDADcAACAAQQlqIAUpAwA3AABBAQVBAAs6AAAMAQsgAEEAOgAACyACQSBqJAALxQEBAn8jAEEgayIDJAACfwNAAkAgAUUNACADQQhqIAAgARAvAkACQCADKAIIQQFGBEAgAyADKQIMNwMYQZCSygBBAyACEN8FDQEgAyADQRhqIgRBBWotAAA2AgQgAyAELQAENgIAIAMoAgBFDQMgASADQRhqKAIAIAMoAgRqIgRPDQIgBCABEOYCAAtBACADKAIMIANBEGooAgAgAhDfBUUNBBoLQQEMAwsgACAEaiEAIAEgBGshAQwBCwtBAAsgA0EgaiQAC7sBAQN/IwBBIGsiAiQAIAJBCGogARCNAwJAIAIoAggiA0UEQCAAQQA2AgggAEIBNwIADAELIAIoAgwhBCACQRBqIAEQ0wEgAkEQaiACKAIQQQtsEP0DIAJBEGogAyAEEK4FA0AgAiABEI0DIAIoAgAiAwRAIAIoAgQhBCACQRBqQYjyyABBARCuBSACQRBqIAMgBBCuBQwBCwsgACACKQMQNwIAIABBCGogAkEYaigCADYCAAsgAkEgaiQAC7YBAQF/IAAoAgAiBEEANgIAIARBeGoiACAAKAIAQX5xNgIAAkAgAiADKAIUEQYARQ0AAkAgBEF8aigCAEF8cSICBEAgAi0AAEEBcUUNAQsgACgCACIDQXxxIgJFIANBAnFyDQEgAi0AAEEBcQ0BIAQgAigCCEF8cTYCACACIABBAXI2AggPCyAAEJ8CIAAtAABBAnEEQCACIAIoAgBBAnI2AgALDwsgBCABKAIANgIAIAEgADYCAAu3AQEEfyMAQZACayIDJAAgA0EANgIAIANBiAFqIAMQxAMgAygCjAEgAygCiAEiBmsiBSACIAFrIgIgAiAFSxshBSADKAKQASECA0AgBCAFTwRAIAMoAgAiAUGAAUkEQCABENkCAAsFIAQgBmogASAEai0AADoAACACIAIoAgBBAWo2AgAgBEEBaiEEDAELCyADQYgBaiADQYQBEPIDGiAAIANBiAFqQQRyQYABEPIDGiADQZACaiQAC8MBAQF/IwBB4ARrIgIkACACQRBqELIDIAJB6AFqQQBBwAAQwQQaIAJBwAJqQgA3AwAgAkG4AmpCADcDACACQbACakIANwMAIAJCADcDqAIgAkEQaiABEMYFIAJBiANqIAJBEGpB2AEQ8gMaIAJByAJqIAJBiANqEKEEIAJBCGogAkHIAmoQqQUgAkHoAWpBwAAgAigCCCACKAIMELABIAJBqAJqQSAgAkHoAWpBIBCwASAAIAJBqAJqELcBIAJB4ARqJAALpQEBAn8gAAJ/AkACfwJAAkAgAUEUai0AAEEBaw4CAQADCyABQRBqKAIAQQBHDAELIAFBDGooAgAgASgCCGsLQQN0QQtuIgIhAUEBDAELQX8gAUEMaigCACABKAIIayICIAFBEGooAgBBAEdqIgEgASACSSIDG0EDdEELbiECQQAgAw0AGiABQQN0QQtuIQFBAQs2AgQgACACNgIAIABBCGogATYCAAvFAQEGfyMAQYABayIEJAAgACAAKAIIIAEQqwMgACgCACEDIAAoAgghBSAEQQhqQQEgARCmBSAFQfAAbCADaiEGIAQoAgwhByAEKAIIIQMDQAJAIAMgB0kEQCADQQFqIgggA08NAQsgACABBH8gBiACQfAAEK0CIAVBAWoFIAULNgIIIARBgAFqJAAPCyAEQRBqIgMQmAMgA0EANgIoIANCADcDICAFQQFqIQUgBiAEQRBqQfAAEPIDQfAAaiEGIAghAwwACwALpgEBBX8jAEFAaiIDJAAgASgCBCEGIAEoAgAhByADQQhqIAIQ6gRBACEBQQIhBSADIAIoAhQiBAR/IAMgBCACQRxqKAIAEMYDIAMoAgAiBAR/IANBOGogAygCBDYCACADIAQ2AjRBAAUgBQsFIAULNgIwIAAgBkEAIAdBAUYbIANBCGogA0EwaiACKAIgIAJBJGooAgAQIwRAQQEhAQsgA0FAayQAIAELvgEBAn8jAEHQAGsiAiQAIAIgACgCACIDNgIUAn8gAygCAARAIAJBCGogABDKBCACQTxqQfgANgIAIAJBLGpBAjYCACACQfkANgI0IAJCAjcCHCACQbiGygA2AhggAiACKQMINwNIIAIgAkHIAGo2AkQgAiACQRRqNgI4IAIgAkHEAGo2AjAgAiACQTBqNgIoIAEgAkEYahDoAgwBCyACIAAQygQgAigCACABIAIoAgQoAjARAgALIAJB0ABqJAALzAEBAX8jAEGABWsiCCQAIAggBzYCDCAIQRBqIABByAEQ8gMiByAALQDKAToAygEgByAALwHIATsByAEgBkEDdCEGA0AgBgRAIAhBsANqIAhBEGpB0AEQ8gMaIAhBEGogCEGwA2ogASACIAUoAgAgBSgCBBC6AyAGQXhqIQYgBUEIaiEFDAEFIAhBsANqIAhBEGpB0AEQ8gMaIAhB4AFqIAhBsANqIAhBDGoQ5wEgCEHgAWogAyAEEPYDIAhB4AFqELcFIAhBgAVqJAALCwunAQEBfyMAQaABayICJAAgAkEIaiABQdAAahD/AiACQTBqIAEgAkEIahAeIAJB2ABqIAFBKGogAkEIahAeIAJBgAFqIAJB2ABqEEMgAEEXaiACQZcBaikAADcAACAAQRBqIAJBkAFqKQAANwAAIABBCGogAkGIAWopAAA3AAAgACACKQCAATcAACAAIAItAJ8BIAJBMGoQwgRBB3RzOgAfIAJBoAFqJAALvAEBA38jAEGgAmsiASQAIAFBADYCACABQZgBaiABEMQDIAEoAqABIQIgAUGYAWogASgCmAEgASgCnAEQiwUgAUGIAWogAUGYAWoQ+QQgAUGgAWogAUGQAWooAgA2AgAgASABKQOIATcDmAEDQCABQZgBahCJBCIDBEAgA0HcADoAACACIAIoAgBBAWo2AgAMAQUgAUGYAWogAUGEARDyAxogACABQZgBakEEckGAARDyAxogAUGgAmokAAsLC7sBAQN/IwBBoAJrIgEkACABQQA2AgAgAUGYAWogARDEAyABKAKgASECIAFBmAFqIAEoApgBIAEoApwBEIsFIAFBiAFqIAFBmAFqEPkEIAFBoAFqIAFBkAFqKAIANgIAIAEgASkDiAE3A5gBA0AgAUGYAWoQiQQiAwRAIANBNjoAACACIAIoAgBBAWo2AgAMAQUgAUGYAWogAUGEARDyAxogACABQZgBakEEckGAARDyAxogAUGgAmokAAsLC6gBAgR/AX4jAEEgayICJAAgAkEIaiAAEJQCAkAgAi0AGCIDQQVHBEAgAkEUaigCACEEQsAAIQYgAigCECEFIANBAkcEQCAAKQMAIgZCCIcgBiADGyEGCyAFRQ0BIAUgBCgCABEDACAEKAIEIgNFDQEgBSADIAQoAggQtgUMAQsgAEEANgKcICAAKQMAIQYLIAAgBkJAfDcDCCAAQRBqIAEQESACQSBqJAALqwEBAn8jAEGgwABrIgEkACABQQQ2AgggAUGYIGogAUEIahB8IAFBmCBqQQRyIQIgASgCmCBBAUYEQCABQSBqIAJBEGooAgA2AgAgAUEYaiACQQhqKQIANwMAIAEgAikCADcDECABQRBqEK0DAAsgAUEQaiACQYQgEPIDGiABQZggaiABQRBqQYQgEPIDGiAAIAFBmCBqIAEoAgggASgCDBCXAiABQaDAAGokAAu9AQECfyMAQRBrIgIkACABQQEgARshAQJAIABFDQAgAEEDakECdiEAAkAgAUEESw0AIABBf2oiA0H/AUsNACACQZjQygA2AgQgAiADQQJ0QZzQygBqIgMoAgA2AgwgACABIAJBDGogAkEEakGU/sEAEOECIQEgAyACKAIMNgIADAELIAJBmNDKACgCADYCCCAAIAEgAkEIakH8/cEAQfz9wQAQ4QIhAUGY0MoAIAIoAgg2AgALIAJBEGokACABC7gBAQF/IwBBEGsiAyQAAkAgAEUNACADIAA2AgQgAUUNAAJAIAJBBEsNACABQQNqQQJ2QX9qIgBB/wFLDQAgA0GY0MoANgIIIAMgAEECdEGc0MoAaiIAKAIANgIMIANBBGogA0EMaiADQQhqQZT+wQAQ0AEgACADKAIMNgIADAELIANBmNDKACgCADYCDCADQQRqIANBDGpB/P3BAEH8/cEAENABQZjQygAgAygCDDYCAAsgA0EQaiQAC+MBAQJ+IAAgASkDICACKQMgfULw////////P3wiBEL/////////A4MgASkDGCACKQMYfULw////////P3wiA0IziHw3AyAgACADQv////////8DgyABKQMQIAIpAxB9QvD///////8/fCIDQjOIfDcDGCAAIANC/////////wODIAEpAwggAikDCH1C8P///////z98IgNCM4h8NwMQIAAgA0L/////////A4MgASkDACACKQMAfULQ/f//////P3wiA0IziHw3AwggACAEQjOIQhN+IANC/////////wODfDcDAAvDAQACQAJAAkACQAJAAkACQAJAIAFBAU0EQCABQQFrDQEMAgsgAUEDSQ0CIAFBA0YNAyABQQVJDQQgAUEFRg0FIAFBB0kNBiABQQdGDQcgACkAAA8LQdT7wwBBAEEAEOQCAAtB5PvDAEEBQQEQ5AIAC0H0+8MAQQIgARDkAgALQYT8wwBBA0EDEOQCAAtBlPzDAEEEIAEQ5AIAC0Gk/MMAQQVBBRDkAgALQbT8wwBBBiABEOQCAAtBxPzDAEEHQQcQ5AIAC8MBAAJAAkACQAJAAkACQAJAAkAgAUEBTQRAIAFBAWsNAQwCCyABQQNJDQIgAUEDRg0DIAFBBUkNBCABQQVGDQUgAUEHSQ0GIAFBB0YNByAAKQAADwtB/K3IAEEAQQAQ5AIAC0GMrsgAQQFBARDkAgALQZyuyABBAiABEOQCAAtBrK7IAEEDQQMQ5AIAC0G8rsgAQQQgARDkAgALQcyuyABBBUEFEOQCAAtB3K7IAEEGIAEQ5AIAC0HsrsgAQQdBBxDkAgALrAEBAX8jAEHQAGsiBCQAIAQgAzYCHCAEIAI2AhggBEEQaiAEQRhqQQcQpgUgBEHEAGpBATYCACAEQgE3AjQgBEGc3ckANgIwIAQgBCkDEDcDSCAEIARByABqNgJAIARBIGogBEEwahBmIARBCGogARCbBSAEKAIMIQEgBCgCCCECIAQgBEEgahCbBSAAIAIgASAEKAIAIAQoAgQQHyAEQSBqEIEFIARB0ABqJAALwwEBAX8jAEHwBGsiBSQAIAVBoANqQa7wwwBBDhD1AyAFQaADakG88MMAQQBB/IPAAEEJENIDIAVB0AFqIAVBoANqQdABEPIDGiAFQaADaiAFQdABakHIARDyAxogBSAFLQCaAzoA6gQgBSAFLwGYAzsB6AQgBUGgA2pBvPDDAEEKIAIgAxDSAyAFIAVBoANqQdABEPIDIgJB0AFqELcFIAJBoANqIAJB0AEQ8gMaIAAgASACQaADaiAEEFMgAkHwBGokAAvEAQEBfyMAQfAEayIFJAAgBUGgA2pBrvDDAEEOEPUDIAVBoANqQbzwwwBBAEH8g8AAQQkQ0gMgBUHQAWogBUGgA2pB0AEQ8gMaIAVBoANqIAVB0AFqQcgBEPIDGiAFIAUtAJoDOgDqBCAFIAUvAZgDOwHoBCAFQaADakG88MMAQQogAiADENIDIAUgBUGgA2pB0AEQ8gMiAkHQAWoQtwUgAkGgA2ogAkHQARDyAxogACABIAJBoANqIAQQjAIgAkHwBGokAAupAQECfyMAQSBrIgEkAAJAAn9BACAAKAIARQ0AGiABQQhqIAAQ0wQgASgCCEEBRg0BIAEgASgCDCICNgIYIAEgAUEQai0AADoAHCACLQAFRQRAIABBCGoQugEgAkEBOgAFCyABQRhqENIEIABBCGoLIAFBIGokAA8LIAEgASgCDDYCGCABIAFBEGotAAA6ABxBvIfKAEErIAFBGGpB6IfKAEHciMoAEKgCAAunAQEEfyMAQTBrIgEkACABQSBqIAAQ0QQgAUEQaiABQSBqQfT0yQAQhQMgASABLQAUIgI6ABwgASABKAIQIgM2AhggAEEIaiEEA0AgAC0AEARAIAFBIGogBCADIAJBAEcQgQQgAUEIaiABQSBqQYT1yQAQhQMgAS0ADEEBcSECIAEoAgghAwwBBSABIAI6ABwgASADNgIYIAFBGGoQ0gQgAUEwaiQACwsLngEBBH8jAEFAaiIDJAAgA0E4aiIEQgA3AwAgA0EwaiIFQgA3AwAgA0EoaiIGQgA3AwAgA0IANwMgIAIgA0EgakEgELwFIANBGGogBCkDADcDACADQRBqIAUpAwA3AwAgA0EIaiAGKQMANwMAIAMgAykDIDcDACABQaz+wQBBA0EAEJUFIAEgA0EgEMICIAAgAUHQARDyAxogA0FAayQAC5gBAQR/IwBBEGsiBSQAIABByABqIQYCQANAIAMgAkkEQCAAKAJAIgRBEE8EQCAGIAAQ3AMgAEEANgJAQQAhBAsgAyACSw0CIAVBCGogACAEQQJ0akEQIARrIAEgA2ogAiADaxCDBCAFKAIMIQQgACAAKAJAIAUoAghqNgJAIAMgBGohAwwBCwsgBUEQaiQADwsgAyACEOYCAAuZAQIBfwJ+IwBBgAFrIgQkACAEQRBqEI4FIARBCGpBACADEKYFIAQ1AgwhBiAENQIIIQUDQCAFIAZaBEAgACAEKQMQNwIAIABBCGogBEEYaigCADYCACAEQYABaiQABSAEQShqIAUQrgIgBEEoaiABIAIQPSAEIARBKGoQUTcDICAEQRBqIARBIGpBCBCuBSAFQgF8IQUMAQsLC58BAQZ/IAAtANEBBEAgAEEAOgDRASAAELgFCyAAKALMASAAKALIASIGayEDIAIhBAJAA0AgBSACTQRAIAIgBWshByABIAVqIQggBCADSQ0CIAAgCCAHIAYgAxCRAiAAECcgBCADayEEIAMgBWohBSAAKALMASEDQQAhBgwBCwsgBSACEOYCAAsgACAIIAcgBiAEEJECIAAgBCAGajYCyAELvQEBAX8jAEGgA2siASQAIAFB4gFqQQBBtgEQwQQaIAFB3gFqQY7zwwAoAAA2AQAgAUGE88MALwAAOwHUASABQYDzwwAoAAA2AtABIAFBhvPDACkAADcB1gEgAUHQAWoQIiABQQhqIAFB0AFqQcgBEPIDGiABQdABaiABQQhqQcgBEPIDGiABQQA6AJoDIAFBADsBmAMgAUHQAWpB7fLDAEELQQAQlQUgACABQdABakHQARDyAxogAUGgA2okAAuYAQEDfyMAQdAAayIBJAAgAUEANgIAIAFBBHIhAwNAIAJBIEYEQCABQShqIAFBJBDyAxogAEEYaiABQcQAaikCADcAACAAQRBqIAFBPGopAgA3AAAgAEEIaiABQTRqKQIANwAAIAAgASkCLDcAACABQdAAaiQABSACIANqQQA6AAAgASABKAIAQQFqNgIAIAJBAWohAgwBCwsLrwEBAn8jAEEgayIEJAAgAkHwhsAAQQogA0EgENIDIAJB+obAAEEKIAEQ4QUQngUgACACQYSHwABBCxCQBCAEQRhqIgFCADcDACAEQRBqIgNCADcDACAEQQhqIgVCADcDACAEQgA3AwAgAkGPh8AAQQ4gBEEgENMDIABBOGogASkDADcAACAAQTBqIAMpAwA3AAAgAEEoaiAFKQMANwAAIAAgBCkDADcAICAEQSBqJAALiQEBAX8jAEEgayIDJAAgA0EIaiABIAIQhAFBASEBAkAgAygCCEEBRgRAIAAgAykCDDcCBCAAQRRqIANBHGooAgA2AgAgAEEMaiADQRRqKQIANwIADAELIABBEGogA0EYaikDADcDACAAQQhqIANBEGopAwA3AwBBACEBCyAAIAE2AgAgA0EgaiQAC6EBAQJ/IwBBIGsiAiQAIAACfwJAIAACfyABQXFqIgNBCUsEQEGEgAIgAUEMRg0BGgwCCwJAAkACQAJAIANBAWsOCQUFAAUFAQUFAgMLQYaAAwwDC0GHwAMMAgtBiIAEDAELQYXAAgs2AgRBAAwBCyACQQM2AhAgAiABrTcCFCACQQhqIAJBEGoQwQMgACACKQMINwIEQQELNgIAIAJBIGokAAuHAQEDfyMAQYABayIDJAAgAC0AACECQQAhAANAIAAgA2pB/wBqIAJBD3EiBEEwciAEQdcAaiAEQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPBEAgAkGAARDmAgALIAFBtazKAEECIAAgA2pBgAFqQQAgAGsQNSADQYABaiQAC4YBAQN/IwBBgAFrIgMkACAALQAAIQJBACEAA0AgACADakH/AGogAkEPcSIEQTByIARBN2ogBEEKSRs6AAAgAEF/aiEAIAJBBHYiAg0ACyAAQYABaiICQYEBTwRAIAJBgAEQ5gIACyABQbWsygBBAiAAIANqQYABakEAIABrEDUgA0GAAWokAAuLAQEBfyMAQaADayIHJAAgB0GAAWogASACIAMgBBCHAiAHQUBrIAdBgAFqIAUgBhCUBCAHQeACakEAQcAAEMEEGiAHQeACakEgIAdBQGtBIBCuASAHQYADakEgIAdB4ABqQSAQrgEgACAHIAdB4AJqQcAAEPIDIgAQnwMgAEHAAmoQswIgAEGgA2okAAuKAQEEfyMAQUBqIgEkACABEMsEIAFBKGoiAiABQQhqKQMANwMAIAFBMGoiAyABQRBqKQMANwMAIAFBOGoiBCABQRhqKQMANwMAIAEgASkDADcDICAAIAEpAyA3AAAgAEEIaiACKQMANwAAIABBEGogAykDADcAACAAQRhqIAQpAwA3AAAgAUFAayQAC4IBAQF/IAAgASgCDCACKAIEIgNBD3cgA0ENd3MgA0EKdnNqIgM2AgwgACABKAIIIAIoAgAiAkEPdyACQQ13cyACQQp2c2oiAjYCCCAAIAEoAgQgA0EPdyADQQ13cyADQQp2c2o2AgQgACABKAIAIAJBD3cgAkENd3MgAkEKdnNqNgIAC4cBAQN/IwBBgAFrIgMkACAAKAIAIQJBACEAA0AgACADakH/AGogAkEPcSIEQTByIARB1wBqIARBCkkbOgAAIABBf2ohACACQQR2IgINAAsgAEGAAWoiAkGBAU8EQCACQYABEOYCAAsgAUG1rMoAQQIgACADakGAAWpBACAAaxA1IANBgAFqJAALhgEBA38jAEGAAWsiAyQAIAAoAgAhAkEAIQADQCAAIANqQf8AaiACQQ9xIgRBMHIgBEE3aiAEQQpJGzoAACAAQX9qIQAgAkEEdiICDQALIABBgAFqIgJBgQFPBEAgAkGAARDmAgALIAFBtazKAEECIAAgA2pBgAFqQQAgAGsQNSADQYABaiQAC5IBAQJ/IABBCnYhAgJAAkACQCAAQYDIAE8EQEECIQEgAkEMRg0BQQAPCyACQYjPygBqLQAAIgFBBEsNAQsgAEEGdkEPcSABQQR0ckGRz8oAai0AACIBQQVLDQEgAUEDdEHoz8oAaikDAEIBIABBP3GthoNCAFIPC0HQwMoAIAFBBRDkAgALQeDAygAgAUEGEOQCAAuUAQEBfyMAQcADayIDJAAgA0HIhsAAQRQQ9QMgA0HchsAAQQpBrIPAAEEAENIDIANB0AFqIANB0AEQ8gMaIANBuANqIAJBGGopAAA3AwAgA0GwA2ogAkEQaikAADcDACADQagDaiACQQhqKQAANwMAIAMgAikAADcDoAMgACABIANB0AFqIANBoANqEG8gA0HAA2okAAuVAQEBfyMAQcADayIDJAAgA0HIhsAAQRQQ9QMgA0HchsAAQQpBrIPAAEEAENIDIANB0AFqIANB0AEQ8gMaIANBuANqIAJBGGopAAA3AwAgA0GwA2ogAkEQaikAADcDACADQagDaiACQQhqKQAANwMAIAMgAikAADcDoAMgACABIANB0AFqIANBoANqEIoBIANBwANqJAALhAEBA38gACgCBCECIAAoAgAiASgCAARAIAEoAgBBAUEBELYFIAFBCGoiAxDGAiADEOkDCyABIAIoAggiA0EXakEAIANrcWogAigCABEDACAAKAIEIgEoAgQgASgCCCIBQQQgAUEESxsiAWpBF2pBACABa3EiAgRAIAAoAgAgAiABELYFCwudAQEBfyAAQQdBABBEAkACQANAIAJFDQIgAC0AyAEiA0HHAU0EQCABIAAgA2otAAA6AAAgAC0AyAEiA0HHAUsNAiAAIANqQQA6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0Gs9MMAIANByAEQ5AIAC0G89MMAIANByAEQ5AIACwt/AQJ/IAAgASgCDCABKAIIIgNBGXcgA0EDdnMgA0EOd3NqNgIMIAAgAyABKAIEIgRBGXcgBEEDdnMgBEEOd3NqNgIIIAAgBCABKAIAIgFBGXcgAUEDdnMgAUEOd3NqNgIEIAAgASACKAIMIgBBGXcgAEEDdnMgAEEOd3NqNgIAC5cBAQZ/IwBBEGsiAiQAIAFBDGooAgAhBCABKAIAIQUgASgCCCEGIAEQswUhByABKAIAIQMCQCAHRQ0AIAEgA0EIciIDNgIAIAEoAghBAUYNACABQoGAgICgATcCCAsgASADQQRyNgIAIAIgACgCADYCDCACQQxqIAEQ9QEgASAENgIMIAEgBjYCCCABIAU2AgAgAkEQaiQAC4wBAQF/IwBBIGsiBCQAIAQgAjYCBCAEIAE2AgAgBCADNgIIIAQgAjYCDAJAIANFIAIgA0ZyDQAgAiADSwRAIAEgA2osAABBv39KDQELIAQgBEEMajYCGCAEIARBCGo2AhQgBCAENgIQIARBEGoQ7wQACyAAIAIgA2s2AgQgACABIANqNgIAIARBIGokAAuuAQECfyMAQSBrIgEkAAJAIAACf0ECENgDDQAaAn9BAUG8jsoAKAIAEQgAIgJFDQAaIAJBAToAAEEACxCZBBDRAyABQQhqQeD5ygAoAgAQ1QQgASgCCEEBRg0BIAEoAgwhAiABQRBqLQAACzoABCAAIAI2AgAgAUEgaiQADwsgASABKAIMNgIYIAEgAUEQai0AADoAHEGnjcoAQSsgAUEYakHUjcoAQcCOygAQqAIAC5IBAQJ/IAAtAAghASAAKAIEIgIEQCAAAn9BASABQf8BcQ0AGgJAIAJBAUcNACAALQAJRQ0AIAAoAgAiAS0AAEEEcQ0AQQEgASgCGEGwrMoAQQEgAUEcaigCACgCDBEEAA0BGgsgACgCACIAKAIYQbGsygBBASAAQRxqKAIAKAIMEQQACyIBOgAICyABQf8BcUEARwuMAQEBfyMAQRBrIgMkACADIAEoAgAiBCgCADYCDCACQQJqIgEgAWwiAUGAECABQYAQSxsiAkEEIANBDGpB5P3BAEHk/cEAEOECIQEgBCADKAIMNgIAIAEEfyABQgA3AgQgASABIAJBAnRqQQJyNgIAQQAFQQELIQIgACABNgIEIAAgAjYCACADQRBqJAALxQEBAn4gAELw////////PyAAKQMgfSICQv////////8Dg0Lw////////PyAAKQMYfSIBQjOIfDcDICAAIAFC/////////wODQvD///////8/IAApAxB9IgFCM4h8NwMYIAAgAUL/////////A4NC8P///////z8gACkDCH0iAUIziHw3AxAgACABQv////////8Dg0LQ/f//////PyAAKQMAfSIBQjOIfDcDCCAAIAJCM4hCE34gAUL/////////A4N8NwMAC4QBAQR/IwBBgAFrIgIkACAAIAEgAUH4AGoiAxAeIAJBCGogAUEoaiIEIAFB0ABqIgUQHiACQTBqIAUgAxAeIAJB2ABqIAEgBBAeIABBKGogAkEIakEoEPIDGiAAQdAAaiACQTBqQSgQ8gMaIABB+ABqIAJB2ABqQSgQ8gMaIAJBgAFqJAALdwEDfyMAQRBrIgMkACADQQE6AA8CfyAAKAIMIgJBAWoiBCACSQRAIANBD2oQ/gRBAAwBCyAEIAAoAgQiAkEITwR/IAJBAWpBA3ZBB2wFIAILQQF2TwRAIAAgBCABEEtB/wFxDAELIAAgARA0QQALGiADQRBqJAALjAEBBX8jAEEQayIDJAAgACgCACEEIAGnIQIgACgCBCEFQQAhAANAIANBCGogBCACIAVxIgZqKAAAQYCBgoR4cRDMBCAAQQRqIgAgBmohAiADKAIIQQFHDQALIAQgAygCDCAGaiAFcSICaiwAAEEATgRAIAQoAgBBgIGChHhxENIFIQILIANBEGokACACC4wBAQN/IwBBIGsiAiQAIAJBGGoiAyABQRBqKAIANgIAIAJBEGoiBCABQQhqKQIANwMAIAIgASkCADcDCEEUQQQQpAUiAUUEQEEUQQQQ3QUACyABIAIpAwg3AgAgAUEQaiADKAIANgIAIAFBCGogBCkDADcCACAAQYyGygA2AgQgACABNgIAIAJBIGokAAuCAQEBfyMAQYACayIFJAAgBUEIahCOBSAFQQhqIAMgBBCuBSAFQQhqIAEgAhCuBSAFIAVBCGoQmwUgBUEYaiAFKAIAIAUoAgQQJiAFKAIYQQFGBEBBiPzBAEEZQbD8wQAQtAQACyAAIAVBIGpB4AEQ8gMaIAVBCGoQgQUgBUGAAmokAAuGAQECfiAAQgAgAq1C/wGDfSIEIAApAwAiAyABKQMAhYMgA4U3AwAgACAAKQMIIgMgASkDCIUgBIMgA4U3AwggACAAKQMQIgMgASkDEIUgBIMgA4U3AxAgACAAKQMYIgMgASkDGIUgBIMgA4U3AxggACAEIAApAyAiAyABKQMghYMgA4U3AyALhwEBAn8jAEGAAWsiAiQAIAAgAUEoaiIDIAEQ1QMgAkEIaiADIAEQ3wEgAkEwaiABQdAAakEoEPIDGiACQdgAaiABQfgAakHYuMQAEB4gAEEoaiACQQhqQSgQ8gMaIABB0ABqIAJBMGpBKBDyAxogAEH4AGogAkHYAGpBKBDyAxogAkGAAWokAAuHAQECfyMAQYABayICJAAgACABQShqIgMgARDVAyACQQhqIAMgARDfASACQTBqIAFB0ABqQSgQ8gMaIAJB2ABqIAFB+ABqQajryAAQHiAAQShqIAJBCGpBKBDyAxogAEHQAGogAkEwakEoEPIDGiAAQfgAaiACQdgAakEoEPIDGiACQYABaiQAC44BAgF/AX4jAEFAaiIBJAAgAUEIakEENgIAIAFBEGogASgCCCABKAIMEO4BIAEoAhBBAUYEQCABQThqIAFBJGooAgA2AgAgAUEwaiABQRxqKQIANwMAIAEgASkCFDcDKCABQShqEKwDAAsgAUEYaikDACECIAAgAUEgaikDADcDCCAAIAI3AwAgAUFAayQAC5MBAQF/IwBB4AJrIgQkACACEKUFIAJB0fDDAEEHIAFBoAFqEJ4FIAJB3/DDAEEGIAMQngUgBCACQeXwwwBBBhCQBCAEQcABaiABEOIFIARBIGogBCAEQcABaiADQSBqEDkgBEHAAWogBEEgahBIIABBB0EAIARBwAFqQSAgA0EgEL8FGzoAACACELcFIARB4AJqJAALnQEBAX8jAEEQayICJAACQAJAAkACQCAAKAIAIgBBhIACRwRAIABBhcACRg0BIABBhoADRg0CIABBh8ADRg0DIAIgAUHB4MkAQQcQnAQMBAsgAiABQd3gyQBBBxCcBAwDCyACIAFB1uDJAEEHEJwEDAILIAIgAUHP4MkAQQcQnAQMAQsgAiABQcjgyQBBBxCcBAsgAhCAAiACQRBqJAALgAEBAX8jAEGAAWsiAiQAIAAgARDZAyACQQhqIAFBKGpBKBDyAxogAkEwaiABQdAAakEoEPIDGiACQdgAaiABQfgAahDZAyAAQShqIAJBCGpBKBDyAxogAEHQAGogAkEwakEoEPIDGiAAQfgAaiACQdgAakEoEPIDGiACQYABaiQAC4MBAgJ/A34jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAIAAgBEEIakGAvMQAEKABIARBMGokAAUgASADEOIEKQMAIQUgAiADEOIEKQMAIQYgBEEIaiADEOMEIAYgBSAHQjSIfHwiB0L/////////B4M3AwAgA0EBaiEDDAELCwt8AgJ/A34gACABKAIEIgNBIE8EfiAAIAEoAgAiAikAADcDCCACQRhqKQAAIQQgAkEQaikAACEFIAJBCGopAAAhBiABIANBYGo2AgQgASACQSBqNgIAIABBEGogBjcDACAAQRhqIAU3AwAgAEEgaiAENwMAQgEFQgALNwMAC4gBAQF/IwBBEGsiBSQAIAVBCGogAEHIASADEJ0EIAUgBSgCCCAFKAIMIAQQngQgBSgCBCIEIAJNBEAgBSgCACECA0AgBARAIAIgAi0AACABLQAAczoAACAEQX9qIQQgAkEBaiECIAFBAWohAQwBCwsgBUEQaiQADwtBuMDEAEEoQbzBxAAQzgMAC4MBAgJ/A34jAEEwayIEJAAgBEEIakEAQSgQwQQaA0AgA0EFRgRAIAAgBEEIakHY7cgAEKEBIARBMGokAAUgASADEOUEKQMAIQUgAiADEOUEKQMAIQYgBEEIaiADEOYEIAYgBSAHQjSIfHwiB0L/////////B4M3AwAgA0EBaiEDDAELCwubAQEDfyMAQSBrIgEkACAAKAIAIgAoAgAhAiAAQQA2AgAgACgCBCABIAIoAgAoAhARAwAoAgAhAiABQRhqIgMgAUEIaigCADYCACABIAEpAwA3AxAgAkEEaiEAIAIoAgQEQCAAIgIoAgQiBARAIAIoAgAgBEEDdEEEELYFCwsgACABKQMQNwIAIABBCGogAygCADYCACABQSBqJAALhgEBAn8jAEGQIGsiAiQAIAJBCGogAUGUIGoQfCACQQhqQQRyIQMCQCACKAIIQQFGBEAgACADKQIANwIAIABBEGogA0EQaigCADYCACAAQQhqIANBCGopAgA3AgAMAQsgASABKQMANwMIIAFBEGogA0GEIBDyAxogAEEFOgAQCyACQZAgaiQAC3kBAn8jAEGAAWsiAyQAIAAtAAAhAkEAIQADQCAAIANqQf8AaiACQQFxQTByOgAAIABBf2ohACACQQF2IgINAAsgAEGAAWoiAkGBAU8EQCACQYABEOYCAAsgAUG3rMoAQQIgACADakGAAWpBACAAaxA1IANBgAFqJAALfQEDfyMAQYABayICJAAgACABIAFB0ABqIgMQHiACQQhqIAFBKGoiBCADEB4gAkEwaiADEMgFIAJB2ABqIAEgBBAeIABBKGogAkEIakEoEPIDGiAAQdAAaiACQTBqQSgQ8gMaIABB+ABqIAJB2ABqQSgQ8gMaIAJBgAFqJAALgQEBAX8jAEHwIGsiBCQAIARBCGpBAEHAABDBBBogBEHYAGpCgICAEDcDACAEQRA2AkggBEKAgIAQNwNQIARB4ABqIAFBhCAQ8gMaIARB7CBqQQA2AgAgBEHoIGogAzYCACAEQeQgaiACNgIAIAAgBEEIakHoIBDyAxogBEHwIGokAAupAQACQAJAAkACQAJAIAAoAgAtAABBAWsOBAIDBAABCyABKAIYQfnAygBBBCABQRxqKAIAKAIMEQQADwsgASgCGEH0wMoAQQUgAUEcaigCACgCDBEEAA8LIAEoAhhBrcHKAEEMIAFBHGooAgAoAgwRBAAPCyABKAIYQaXBygBBCCABQRxqKAIAKAIMEQQADwsgASgCGEGcwcoAQQkgAUEcaigCACgCDBEEAAt+AQF/IwBBQGoiBSQAIAVBIGogASACEKwBIAVBCGogBUEgakHY+sEAEOsCIAVBIGogBUEIaiADIAQQ4gEgBSAFQSBqEM8EIAUoAgQiAUEfTQRAQSAgARDlAgALIAAgBSgCAEEgEJwDIAVBCGoQowUgBUEgahCBBSAFQUBrJAALngEBBX4gAUEgEOABIQIgAUEGakEaEOABIQMgAUEMakEUEOABIQQgAUETakENEOABIQUgAUEYakEIEOABIQYgACAEQgaIQv////////8DgzcDECAAIANCA4hC/////////wODNwMIIAAgAkL/////////A4M3AwAgACAFQgGIQv////////8DgzcDGCAAIAZCDIhC/////////wODNwMgC54BAQV+IAFBIBDhASECIAFBBmpBGhDhASEDIAFBDGpBFBDhASEEIAFBE2pBDRDhASEFIAFBGGpBCBDhASEGIAAgBEIGiEL/////////A4M3AxAgACADQgOIQv////////8DgzcDCCAAIAJC/////////wODNwMAIAAgBUIBiEL/////////A4M3AxggACAGQgyIQv////////8DgzcDIAuMAQEBfwJAIAAtAMgBIgFBxwFNBEAgACABaiIBIAEtAAAgAC0AyQFzOgAAIAAtAMgBQQFqQf8BcSIBQccBSw0BIAAgAWoiASABLQAAQQRzOgAAIAAgAC0ApwFBgAFzOgCnASAAECIgAEEAOwHIAQ8LQezzwwAgAUHIARDkAgALQfzzwwAgAUHIARDkAgALegEDfyMAQRBrIgIkAAJAIAAoAgAiAUEITQRAIAFBDGwhASAAQQhqIQADQCABRQ0CIAFBdGohASAAELUEIABBDGohAAwACwALIABBCGooAgAhAyACIABBDGooAgA2AgggAiABNgIEIAIgAzYCACACENQFCyACQRBqJAALbwEDfiAAIAJCIIgiAyABQiCIIgR+QgB8QgB8IAJC/////w+DIgIgAUL/////D4MiAX4iBUIgiCACIAR+fCICQiCIfCABIAN+IAJC/////w+DfCIBQiCIfDcDCCAAIAVC/////w+DIAFCIIaENwMAC3MBAn8gACgCACICQXxxIgFFIAJBAnFyRQRAIAEgASgCBEEDcSAAKAIEQXxxcjYCBAsgACAAKAIEIgJBfHEiAQR/IAEgASgCAEEDcSAAKAIAQXxxcjYCACAAKAIEBSACC0EDcTYCBCAAIAAoAgBBA3E2AgALfQEEfyMAQSBrIgEkACAAQgA3AAAgAEEYaiICQgA3AAAgAEEQaiIDQgA3AAAgAEEIaiIEQgA3AAAgARDLBCACIAFBGGopAwA3AAAgAyABQRBqKQMANwAAIAQgAUEIaikDADcAACAAIAEpAwA3AAAgAEEgahCzAiABQSBqJAALgQEBAX8jAEEQayICJAAgAiABQa2FygBBBRC/BCACIABBEGo2AgwgAkGyhcoAQQQgAkEMakG4hcoAEGogAiAANgIMIAJByIXKAEEDIAJBDGpBzIXKABBqIAIgAEEIajYCDCACQdyFygBBBSACQQxqQeSFygAQaiACELECIAJBEGokAAt7AQF/IwBBMGsiASQAIAFBigE2AgQgAUEANgIQIAFCBDcDCCABQQA2AhggASABQRhqNgIoIAEgAUEEajYCJCABIAFBCGo2AiAQhgMgAEEIaiABKAIQNgIAIAAgASkDCDcCACAAIAEoAhxBACABKAIYGzYCDCABQTBqJAALdgEDfyMAQSBrIgIkAAJAIAAgARCCAUUEQCABQRxqKAIAIQMgASgCGCACQRxqQQA2AgAgAkHEqsoANgIYIAJCATcCDCACQciqygA2AgggAyACQQhqEDNFDQELIAJBIGokAEEBDwsgAEEEaiABEIIBIAJBIGokAAt7AQR/IwBBIGsiAyQAIANBGGoiBEIANwMAIANBEGoiBUIANwMAIANBCGoiBkIANwMAIANCADcDACADQSAgASACEK4BIABBGGogBCkDADcAACAAQRBqIAUpAwA3AAAgAEEIaiAGKQMANwAAIAAgAykDADcAACADQSBqJAALcQACfyACQQJ0IgEgA0EDdEGAgAFqIgIgASACSxtBh4AEaiIBQRB2QAAiAkF/RgRAQQAhA0EBDAELIAJBEHQiA0IANwMAIANBADYCCCADIAMgAUGAgHxxakECcjYCAEEACyEBIAAgAzYCBCAAIAE2AgALcgEDfyMAQZABayIBJAAgAUEANgIAIAFBBHIhAwNAIAJBwABGBEAgAUHIAGogAUHEABDyAxogACABQcgAakEEckHAABDyAxogAUGQAWokAAUgAiADakEAOgAAIAEgASgCAEEBajYCACACQQFqIQIMAQsLC3IBA38jAEGQAmsiASQAIAFBADYCACABQQRyIQMDQCACQYABRgRAIAFBiAFqIAFBhAEQ8gMaIAAgAUGIAWpBBHJBgAEQ8gMaIAFBkAJqJAAFIAIgA2pBADoAACABIAEoAgBBAWo2AgAgAkEBaiECDAELCwuAAQEBfyMAQUBqIgUkACAFIAE2AgwgBSAANgIIIAUgAzYCFCAFIAI2AhAgBUEsakECNgIAIAVBPGpBuAE2AgAgBUICNwIcIAVBoKvKADYCGCAFQbQBNgI0IAUgBUEwajYCKCAFIAVBEGo2AjggBSAFQQhqNgIwIAVBGGogBBC9BAALfQAgAUEITwRAIAAgAkIohkKAgICAgIDA/wCDIAJCOIaEIAJCGIZCgICAgIDgP4MgAkIIhkKAgICA8B+DhIQgAkIIiEKAgID4D4MgAkIYiEKAgPwHg4QgAkIoiEKA/gODIAJCOIiEhIQ3AAAPC0GI6MkAQSBBlOfJABC0BAALYAICfwF+AkACQCABrUIMfiIEQiCIp0UEQCAEpyICQX9MDQECQCACRQRAQQQhAwwBCyACQQQQpAUiA0UNAwsgACABNgIEIAAgAzYCAA8LEOsFAAsQ6wUACyACQQQQ3QUAC2ECAn8BfgJAAkAgAa1C8AB+IgRCIIinRQRAIASnIgJBf0wNAQJAIAJFBEBBCCEDDAELIAJBCBCkBSIDRQ0DCyAAIAE2AgQgACADNgIADwsQ6wUACxDrBQALIAJBCBDdBQALbgECfyMAQSBrIgEkACABQQhqEFhBASECAkAgASgCCEEBRgRAIAAgASkCDDcCBCAAQRRqIAFBHGooAgA2AgAgAEEMaiABQRRqKQIANwIADAELIAAgASkCDDcCBEEAIQILIAAgAjYCACABQSBqJAALZwACQCABIABPBEAgAkUNAQNAIAAgAS0AADoAACABQQFqIQEgAEEBaiEAIAJBf2oiAg0ACwwBCyACRQ0AIAFBf2ohASAAQX9qIQADQCAAIAJqIAEgAmotAAA6AAAgAkF/aiICDQALCwuJAQEBfyMAQTBrIgIkACACQQhqEMsEIABBKGogAUL56tDQ58mh5OEAfDcDACAAQSBqIAE3AwAgAEEYaiABQs/W077Sx6vZQnw3AwAgACABQtbrgu7q/Yn14AB8NwMQIAAgATcDCCAAQgA3AwAgAkEANgIoIABBMGogAkEIakEoEPIDGiACQTBqJAALagEBfyMAQRBrIgQkACAAAn8gAiADaiIDIAJPBEAgASgCBEEBdCIBIAMgASADSxshAkEADAELIARBCGogA0EAEKYFIAQoAgghAiAAQQhqIAQoAgw2AgBBAQs2AgAgACACNgIEIARBEGokAAt6AQF/IwBBgAFrIgAkACAAQQhqEEkgAEHYAGogAEEIakEoEPIDGkHI+soAIABB2ABqQSgQogEgAEEwaiAAQdgAakEoEPIDGiAALQBAQQJHBEBBnNjKAEGc2MoAKAIAQX9qNgIAIABBMGoQhAULIABBgAFqJABByPrKAAt0AQJ/IAAtAAQhASAALQAFBEAgAAJ/QQEgAUH/AXENABogACgCACIAQRxqKAIAKAIMIQEgACgCGCECIAAtAABBBHFFBEAgAkGrrMoAQQIgAREEAAwBCyACQaqsygBBASABEQQACyIBOgAECyABQf8BcUEARwuWAQECfyMAQdADayIDJAAgA0EAQcwBEMEEIgRBADoA0QEgBEEBOgDQASAEQYgBNgLMASADQfABakIANwMAIANB6AFqQgA3AwAgA0HgAWpCADcDACADQgA3A9gBIAMgASACEOoBIANB+AFqIANB2AEQ8gMaIANB+AFqIANB2AFqEJMEIAAgA0HYAWpBIBCcAyADQdADaiQAC3UBBH8jAEEgayIBJAAgAEIANwAAIABBGGoiAkIANwAAIABBEGoiA0IANwAAIABBCGoiBEIANwAAIAEQywQgAiABQRhqKQAANwAAIAMgAUEQaikAADcAACAEIAFBCGopAAA3AAAgACABKQAANwAAIAFBIGokAAsnAQF/QQhBBBCkBSIBBEAgAEEBNgIEIAAgATYCAA8LQQhBBBDdBQALNwIBfwF+IwBBIGsiAiQAIAJBCGogAUEBEIkDIAIpAwghAyAAIAE2AgggACADNwIAIAJBIGokAAuRAQECfwJAAkACQCAAKAIEIgIgAU8EQCABBEAgASACRg0EIAAoAgAgAkHwAGxBCCABQfAAbCICEJQFIgMNAiACQQgQ3QUACyAAIgEoAgQiAgRAIAEoAgAgAkHwAGxBCBC2BQsgAEEINgIAQQAhAQwCC0HQ7skAQSRBlO/JABDOAwALIAAgAzYCAAsgACABNgIECwt3AQF/IwBBgAVrIgUkACAFQeAAaiABIAIQKyAFQYADaiAFQeAAakG8g8AAEMgCIAUgAyAEEKQCIAVB4ABqIAVBgANqIAUQ+QEgBSAFQeAAahCRASAAIAVB4AAQnAMgBUHgAGoQogUgBUGAA2oQogUgBUGABWokAAtfAQF/IwBBMGsiByQAIAdBEGogASACIAMgBCAFIAYQNyAHQShqIAdBGGooAgA2AgAgByAHKQMQNwMgIAdBADYCLCAHQQhqIAdBIGoQrwMgACAHKQMINwIAIAdBMGokAAtgAQF/IwBBMGsiByQAIAdBEGogASACIAMgBCAFIAYQ8gEgB0EoaiAHQRhqKAIANgIAIAcgBykDEDcDICAHQQA2AiwgB0EIaiAHQSBqEK8DIAAgBykDCDcCACAHQTBqJAALdgEBfyMAQdAAayICJAAgAhCXASACQSBqIAFBCGooAgA2AgAgAiABKQIANwMYIAJBKGogAkEkEPIDGkEkQQQQpAUiAUUEQEEkQQQQ3QUACyABIAJBKGpBJBDyAyEBIABBvPPIADYCBCAAIAE2AgAgAkHQAGokAAtzAQV/IwBBEGsiAiQAA0ACQCACQQhqIAEQRyACKAIIIgRFDQAgAigCDCEFIAAoAggiAyAAKAIERgRAIAAgACgCCBCnAwsgACgCACADQQN0aiIGIAU2AgQgBiAENgIAIAAgA0EBajYCCAwBCwsgAkEQaiQAC1cAIAAgAkIyiSACQi6JhSACQheJhSAIfCAEIAaFIAKDIAaFfCAJfCICIAd8NwMIIAAgAyAFhSABgyADIAWDhSABQiSJIAFCHomFIAFCGYmFfCACfDcDAAtmAQF/IAEoAgAiASgCaCICIAEoAmxHBEAgASACQQFqNgJoIAACfyABQQhqIAEoAgBBCE0NABogAUEIaigCAAsgAkEMbGoiASkCADcCACAAQQhqIAFBCGooAgA2AgAPCyAAQQI6AAgLcwEBfyMAQbAEayICJAAgAiABQdgBahDpAiACQdgCaiABQdgBEPIDGiACQdgBaiACQdgCahDuAyACIAJB2AFqELIEIAJB2AJqIAJB2AEQ8gMaIAJBmAJqIAJB2AJqEO4DIAAgAkGYAmoQuQUgAkGwBGokAAteAQF/IwBBMGsiBiQAIAZBEGogASACIAMgBCAFELUDIAZBKGogBkEYaigCADYCACAGIAYpAxA3AyAgBkEANgIsIAZBCGogBkEgahCvAyAAIAYpAwg3AgAgBkEwaiQAC10BAX8jAEEwayIGJAAgBkEQaiABIAIgAyAEIAUQGyAGQShqIAZBGGooAgA2AgAgBiAGKQMQNwMgIAZBADYCLCAGQQhqIAZBIGoQrwMgACAGKQMINwIAIAZBMGokAAt0AQF/AkADQCACRQ0BIAAtAMgBIgNBxwFNBEAgACADaiIDIAMtAAAgAS0AAHM6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0GM9MMAIANByAEQ5AIACwt0AQF/IABBBkEAEEQCQANAIAJFDQEgAC0AyAEiA0HHAU0EQCAAIANqIAEtAAA6AAAgACAALQDIAUEBaiIDOgDIASADQf8BcUGmAUYEQCAAEJwCCyABQQFqIQEgAkF/aiECDAELC0Gc9MMAIANByAEQ5AIACwt1AQF/IwBBQGoiASQAIAEQpgIgAEEANgIIIABCADcDACAAQQxqIAFBwAAQ8gMaIABB5ABqQcDoyQApAgA3AgAgAEHcAGpBuOjJACkCADcCACAAQdQAakGw6MkAKQIANwIAIABBqOjJACkCADcCTCABQUBrJAALdAEEfyAAQbnz3fF5bCEDAkADQCADQQAQkAMiACgCCGtBH3F2IgEgACgCBCICTw0BIAAoAgAiAiABQfAAbGpBIGoiBBDxBCAAQaDYygAoAgBHBEAgBBDQBAwBCwsgAiABQfAAbGoPC0Gw7skAIAEgAhDkAgALcAEBfyMAQTBrIgEkACABIAA2AgwDQCABQSBqIAFBDGoQvQIgAS0AKEECRgRAIAFBIGoiAC0ACEECRwRAIAAQtQQLIAFBMGokAAUgAUEYaiABQShqKAIANgIAIAEgASkDIDcDECABQRBqELUEDAELCwtlAQN/IwBBEGsiASQAIAFBCGogABCbBSABKAIMQRhsIQIgASgCCCIDQQxqIQADQCACBEAgAygCDARAIAAQowMgABD0BAsgA0EYaiEDIAJBaGohAiAAQRhqIQAMAQsLIAFBEGokAAtuAQF/IwBBIGsiAyQAIAEoAgBBAUYEQCADQRhqIAFBFGopAgA3AwAgA0EQaiABQQxqKQIANwMAIAMgASkCBDcDCEHzgcAAQSsgA0EIakGggsAAIAIQqAIACyAAIAFBCGpBwAEQ8gMaIANBIGokAAtuAQF/IwBBIGsiAyQAIAEoAgBBAUYEQCADQRhqIAFBFGopAgA3AwAgA0EQaiABQQxqKQIANwMAIAMgASkCBDcDCEHzgcAAQSsgA0EIakGggsAAIAIQqAIACyAAIAFBCGpBgAIQ8gMaIANBIGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBC4ASAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBC3AiAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtcAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBD4AiAFQShqIAVBGGooAgA2AgAgBSAFKQMQNwMgIAVBADYCLCAFQQhqIAVBIGoQrwMgACAFKQMINwIAIAVBMGokAAtbAQF/IwBBMGsiBSQAIAVBEGogASACIAMgBBAaIAVBKGogBUEYaigCADYCACAFIAUpAxA3AyAgBUEANgIsIAVBCGogBUEgahCvAyAAIAUpAwg3AgAgBUEwaiQAC1wBAX8jAEEwayIFJAAgBUEQaiABIAIgAyAEEJkCIAVBKGogBUEYaigCADYCACAFIAUpAxA3AyAgBUEANgIsIAVBCGogBUEgahCvAyAAIAUpAwg3AgAgBUEwaiQAC2YBAn8gACAAKAIEIAFBFXQgACgCACIBQR9xdnIiAjYCBCAAQQhqIQMgAUELaiEBA0AgACABNgIAIAFBB0sEQCADIAJBGHYQigQgACAAKAIEQQh0IgI2AgQgACgCAEF4aiEBDAELCwtqAQF/IwBBIGsiAiQAIAJBGGogAUEQaigCADYCACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAIgAkEIahCKAyAAIAIpAwA3AgggAEEaNgIEIABBh/nJADYCACAAQQA6ABAgAkEgaiQAC4gBAQF/IwBBEGsiAiQAAkACQAJAAkACQAJAIAAtAABBAWsOBAIDBAABCyACIAFB+ITKAEEPEJwEDAQLIAIgAUGihcoAQQsQnAQMAwsgAiABQZiFygBBChCcBAwCCyACIAFBj4XKAEEJEJwEDAELIAIgAUGHhcoAQQgQnAQLIAIQgAIgAkEQaiQAC3MBAX8jAEEQayIBJAAgACgCACIALQAAIQIgAEEAOgAAAkAgAkEBcQRAIAFBCGoQkQNBCEEEEKQFIgBFDQEgACABKQMINwIAQeD5ygAgADYCACABQRBqJAAPC0H8jMoAQStB7IzKABDOAwALQQhBBBDdBQALcAECfwJAIAAoAgAiAUEQaigCACICRQ0AIAJBADoAACABQRRqKAIAIgJFDQAgASgCECACQQEQtgULIAFBHGooAgBBAUEBELYFIAAoAgAiASABKAIEIgFBf2o2AgQgAUEBRgRAIAAoAgBBMEEIELYFCwtaAQF/IwBBMGsiBCQAIARBEGogASACIAMQ6QEgBEEoaiAEQRhqKAIANgIAIAQgBCkDEDcDICAEQQA2AiwgBEEIaiAEQSBqEK8DIAAgBCkDCDcCACAEQTBqJAALcAEBfwJAAkACQCAAKAIEIgIgAU8EQCABBEAgASACRg0EIAAoAgAgAkEBIAEQlAUiAg0CIAFBARDdBQALIAAQgQUgAEEBNgIAQQAhAQwCC0GQ/cEAQSRB1P3BABDOAwALIAAgAjYCAAsgACABNgIECwtfAQF/IwBBoAJrIgIkACACQagBaiABQSgQ8gMaIAJB0AFqIAFBKGpBKBDyAxogAkH4AWogAUHQAGpBKBDyAxogAkEIaiACQagBahCjASAAIAJBCGoQgwIgAkGgAmokAAt4AQF/IwBBIGsiASQAIAFBrPrKADYCDEGs+soAKAIAQQFHBEAgASAANgIQIAEgAUEMajYCFCABIAFBEGo2AhxBrPrKACABQRxqQZj1yAAQVwsgASgCDBDHBCIARQRAQcD1yABBK0HI9sgAEM4DAAsgAUEgaiQAIAALeAEBfyMAQSBrIgEkACABQZj6ygA2AgxBmPrKACgCAEEBRwRAIAEgADYCECABIAFBDGo2AhQgASABQRBqNgIcQZj6ygAgAUEcakGs9cgAEFcLIAEoAgwQxwQiAEUEQEHA9cgAQStByPbIABDOAwALIAFBIGokACAAC1wCAn8BfiAAKAIEIgEEQAJ/AkAgAUEIaiICIAFBBWpJDQAgAUEBaq1CDH4iA0IgiKcNACACQXxxIgIgA6dqIgEgAkkNAEEEDAELQQALIQIgACgCACABIAIQtgULC3MBAX8jAEEwayIBJAAgAUGAATYCBCABIAA2AgAgAUEcakECNgIAIAFBLGpBywA2AgAgAUICNwIMIAFB5OnJADYCCCABQcsANgIkIAEgAUEgajYCGCABIAFBBGo2AiggASABNgIgIAFBCGpB0OrJABC9BAALcgEBfyMAQRBrIgQkACAEIAI2AgQgBCABNgIAIAQgAzYCDAJAIANFIAIgA0ZyDQAgAiADSwRAIAEgA2osAABBv39KDQELIAQoAgAgBCgCBEEAIARBDGooAgAQKQALIAAgAzYCBCAAIAE2AgAgBEEQaiQAC2sBAX8jAEEgayIDJAAgAyABIAIQGQJAIAMtABxFBEAgAEECOgAcDAELIAAgAykDADcCACAAQRhqIANBGGopAwA3AgAgAEEQaiADQRBqKQMANwIAIABBCGogA0EIaikDADcCAAsgA0EgaiQAC1gBAX8jAEEwayIDJAAgA0EQaiABIAIQjAEgA0EoaiADQRhqKAIANgIAIAMgAykDEDcDICADQQA2AiwgA0EIaiADQSBqEK8DIAAgAykDCDcCACADQTBqJAALWAEBfyMAQTBrIgMkACADQRBqIAEgAhCyAiADQShqIANBGGooAgA2AgAgAyADKQMQNwMgIANBADYCLCADQQhqIANBIGoQrwMgACADKQMINwIAIANBMGokAAtYAQF/IwBBMGsiAyQAIANBEGogASACEOoCIANBKGogA0EYaigCADYCACADIAMpAxA3AyAgA0EANgIsIANBCGogA0EgahCvAyAAIAMpAwg3AgAgA0EwaiQAC1gBAX8jAEEwayIDJAAgA0EQaiABIAIQngMgA0EoaiADQRhqKAIANgIAIAMgAykDEDcDICADQQA2AiwgA0EIaiADQSBqEK8DIAAgAykDCDcCACADQTBqJAALWAEBfyMAQTBrIgMkACADQRBqIAEgAhCDASADQShqIANBGGooAgA2AgAgAyADKQMQNwMgIANBADYCLCADQQhqIANBIGoQrwMgACADKQMINwIAIANBMGokAAtrAQJ/IwBBEGsiBiQAAkAgACABIAIgAyAEEFIiBQ0AIAZBCGogAyAAIAEgBCgCDBEFAEEAIQUgBigCCA0AIAYoAgwiBSACKAIANgIIIAIgBTYCACAAIAEgAiADIAQQUiEFCyAGQRBqJAAgBQtsAQF/IwBB4AJrIgIkACACQQhqQQBBwAAQwQQaIAJBiAFqIAFB2AEQ8gMaIAJByABqIAJBiAFqEKEEIAIgAkHIAGoQqQUgAkEIakHAACACKAIAIAIoAgQQsAEgACACQQhqEMUEIAJB4AJqJAALagEBfyMAQRBrIgMkACADIAEgAhAkIANBCGooAgAhASADKAIEIQIgAygCAEEBRwRAIAMgA0EMaigCADYCCCADIAE2AgQgAyACNgIAIAMQgQVBACECCyAAIAE2AgQgACACNgIAIANBEGokAAtvAQF/IwBBMGsiAyQAIAMgAjYCBCADIAE2AgAgA0EcakECNgIAIANBLGpBywA2AgAgA0ICNwIMIANB9KvKADYCCCADQcsANgIkIAMgA0EgajYCGCADIAM2AiggAyADQQRqNgIgIANBCGogABC9BAALcgEBfyMAQTBrIgIkACACIAE2AgQgAiAANgIAIAJBHGpBAjYCACACQSxqQcsANgIAIAJCAjcCDCACQaCvygA2AgggAkHLADYCJCACIAJBIGo2AhggAiACQQRqNgIoIAIgAjYCICACQQhqQbCvygAQvQQAC3IBAX8jAEEwayICJAAgAiABNgIEIAIgADYCACACQRxqQQI2AgAgAkEsakHLADYCACACQgI3AgwgAkHkr8oANgIIIAJBywA2AiQgAiACQSBqNgIYIAIgAkEEajYCKCACIAI2AiAgAkEIakH0r8oAEL0EAAtWAQJ/IwBBIGsiAiQAIAFBHGooAgAhAyABKAIYIAJBGGogAEEQaikCADcDACACQRBqIABBCGopAgA3AwAgAiAAKQIANwMIIAMgAkEIahAzIAJBIGokAAtWAQJ/IwBBIGsiAiQAIABBHGooAgAhAyAAKAIYIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAMgAkEIahAzIAJBIGokAAttAgJ/An4jAEGAAWsiAiQAIAEpAwAhBCABKQMIIQUgAiABQdQAahDkBSAAIAU3AwggACAENwMAIAEoAlAhAyAAQRBqIAFBEGpBwAAQ8gMaIAAgAzYCUCAAQdQAaiACQYABEPIDGiACQYABaiQAC2gBAX8jAEGABGsiAyQAIANBEGoQsgMgA0EQaiABIAIQ0QUgA0GoAmogA0EQakHYARDyAxogA0HoAWogA0GoAmoQoQQgA0EIaiADQegBahCpBSAAIAMoAgggAygCDBCcAyADQYAEaiQAC2oBAX8jAEEQayIDJAAgASgCAEEBRgRAIAMgASkCBDcDCEGw98EAQSsgA0EIakHc98EAIAIQqAIACyAAIAEpAgQ3AgAgAEEQaiABQRRqKQIANwIAIABBCGogAUEMaikCADcCACADQRBqJAALVgEBfyMAQTBrIgIkACACQRBqIAEQnQMgAkEoaiACQRhqKAIANgIAIAIgAikDEDcDICACQQA2AiwgAkEIaiACQSBqEK8DIAAgAikDCDcCACACQTBqJAALbQICfwJ+IwBBgAFrIgIkACABKQMAIQQgASkDCCEFIAIgAUHUAGoQswQgACAFNwMIIAAgBDcDACABKAJQIQMgAEEQaiABQRBqQcAAEPIDGiAAIAM2AlAgAEHUAGogAkGAARDyAxogAkGAAWokAAthAQF/IwBBIGsiAiQAIAEQbSACEOwBIAFBzABqIAIQYiAAQRhqIAJBGGopAwA3AAAgAEEQaiACQRBqKQMANwAAIABBCGogAkEIaikDADcAACAAIAIpAwA3AAAgAkEgaiQAC14BAX8jAEEgayIEJAAgBCADNgIUIAQgAjYCEAJ/IAEgA08EQCAEQQhqIAEgA2sgASAAIAEQ1AMgBCAEKQMINwMYQQEgBEEQaiAEQRhqEJMFDQEaC0EACyAEQSBqJAALXAECfyMAQRBrIgIkACAAKAIAIgAoAgghAyAAKAIAIQAgAiABEMAEIAMEQANAIAIgADYCDCACIAJBDGoQjwEgAEEBaiEAIANBf2oiAw0ACwsgAhC+BCACQRBqJAALWgECfyMAQTBrIgIkACACQQhqIAFBARAqQQAhAQNAIAFBKEYEQCAAIAJBCGpBKBDyAxogAkEwaiQABSACQQhqIAFqIgMgAykDAEIBhjcDACABQQhqIQEMAQsLC14BAn8jAEHQAGsiAiQAIAAgASABQfgAaiIDEB4gAiABQShqIAFB0ABqIgEQHiACQShqIAEgAxAeIABBKGogAkEoEPIDGiAAQdAAaiACQShqQSgQ8gMaIAJB0ABqJAALZQEBfyMAQZABayIDJAAgA0EIaiACEKsCIANBADYCGCADIAMpAwg3AxAgA0EgaiABQfAAEPIDGiADQRBqIAIgA0EgahDUASAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBkAFqJAALXQICfwF+AkAgASgCACIEIAEoAgQiAWpBf2pBACABa3EiAyAETwRAIAOtIAKtfiIFQiCIpw0BIAAgAzYCCCAAIAE2AgQgACAFPgIADwsgAEEANgIEDwsgAEEANgIEC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpB5JnKACACQQhqEDMgAkEgaiQAC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpBtKjKACACQQhqEDMgAkEgaiQAC1kBAX8jAEEgayICJAAgAiAAKAIANgIEIAJBGGogAUEQaikCADcDACACQRBqIAFBCGopAgA3AwAgAiABKQIANwMIIAJBBGpBhK7KACACQQhqEDMgAkEgaiQAC2cBAX8jAEHAA2siBSQAIAUgASACEF4gBUHgAWogBUHMg8AAEMcCIAVBoANqIAMgBBCkAiAFIAVB4AFqIAVBoANqEPgBIAVBoANqIAUQ4QUQ1gMgACAFQaADakEgEJwDIAVBwANqJAALXQEDfyMAQRBrIgIkAAJAIAEoAgAgASgCBE8NACACQQhqIAFBARDwBCACKAIIQQFHDQAgASgCACEDIAEgAigCDDYCAEEBIQQLIAAgAzYCBCAAIAQ2AgAgAkEQaiQAC2cBA38gAEEEaiEBIAAoAgBFBEAgARCBBQ8LIAEtAABBAk8EQCAAQQhqKAIAIgEoAgAgASgCBCgCABEDACABKAIEIgIoAgQiAwRAIAEoAgAgAyACKAIIELYFCyAAKAIIQQxBBBC2BQsLWwEBfyMAQSBrIgQkACAEIAM2AhQgBCACNgIQAn8gASADTwRAIARBCGpBACADIAAgARDUAyAEIAQpAwg3AxhBASAEQRBqIARBGGoQkwUNARoLQQALIARBIGokAAtWAQF/IwBBIGsiAiQAIAIgADYCBCACQRhqIAFBEGopAgA3AwAgAkEQaiABQQhqKQIANwMAIAIgASkCADcDCCACQQRqQYSuygAgAkEIahAzIAJBIGokAAtTAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqEIcEIAIoAgghASAAIAIoAgw2AgQgACABNgIAIAJBIGokAAtkAQF/IwBBIGsiBSQAIAVBGGogAEHIASADEJ0EIAVBEGogBSgCGCAFKAIcIAQQngQgBSgCFCEAIAUoAhAhAyAFQQhqIAEgAiAEEJ4EIAUoAgggBSgCDCADIAAQrgEgBUEgaiQAC1kBAX8jAEGgAWsiAiQAIAJB0ABqIAEQYyACIAJB0ABqQSgQ8gMiAUEoaiABQfgAakEoEPIDGiABQdAAaiABQQUQKiAAIAFB0ABqIAFBKGoQHiABQaABaiQAC2QBAX8jAEHwA2siAiQAIAIgAUHYAWoQ7QIgAkGYAmogAUHYARDyAxogAkHYAWogAkGYAmoQ7gMgAiACQdgBahCyBCACQZgCaiACQdgBEPIDGiAAIAJBmAJqEO4DIAJB8ANqJAALXAEBfyMAQSBrIgIkACACEO8DNgIMIAJBEGogARC1AiACIAJBEGoQmwUgAkEMaiACKAIAIAIoAgQQvAUgAEEIaiACQRhqKAIANgIAIAAgAikDEDcCACACQSBqJAALXwEBfyMAQeACayICJAAgACABEOkCIAJBCGogAUGwA2oQ5AUgAkGIAWogAUHYAWoQ6QIgAEGwA2ogAkEIakGAARDyAxogAEHYAWogAkGIAWpB2AEQ8gMaIAJB4AJqJAALYgEBfyMAQSBrIgIkACACIAEQSCAAIAFBoAEQ8gMiAEG4AWogAkEYaikDADcAACAAQbABaiACQRBqKQMANwAAIABBqAFqIAJBCGopAwA3AAAgACACKQMANwCgASACQSBqJAALXwEBfyMAQeACayICJAAgACABEO0CIAJBCGogAUGwA2oQswQgAkGIAWogAUHYAWoQ7QIgAEGwA2ogAkEIakGAARDyAxogAEHYAWogAkGIAWpB2AEQ8gMaIAJB4AJqJAALZAEBfyMAQRBrIgMkACABKAIAQQFGBEAgAyABKAIENgIIIAMgAUEIai0AADoADEGp88kAQSsgA0EIakHU88kAIAIQqAIACyAAIAEoAgQ2AgAgACABQQhqLQAAOgAEIANBEGokAAtqAQN/IwBBEGsiACQAIAAQ/wEgACAALQAEIgE6AAwgACAAKAIAIgI2AgggAEEIahCaBQJAAkAgAUECSw0AAkAgAUEBaw4CAQIACxCbBEUNACACQQE6AAQLIAIoAgBBADoAAAsgAEEQaiQAC1kBAX8jAEHQAGsiAiQAIAAgAUEoakEoEPIDIQAgAiABQSgQ8gMiAkEoaiABQdAAahDZAyAAQShqIAJBKBDyAxogAEHQAGogAkEoakEoEPIDGiACQdAAaiQAC00BA39BASEDA38gAkEgRgR/IAMQlgUFIAEgAmotAAAgACACai0AAHMiBEEAIARrckF/c0GAAXFBB3YQlgUgA3EhAyACQQFqIQIMAQsLC2oBAX8CQCABQX9KBEACQCABRQRAQQEhAgwBCwJ/IAJFBEAgAUEBEKQFDAELIAEiAkEBEN0BIgMEQCADQQAgAhDBBBoLIAMLIgJFDQILIAAgATYCBCAAIAI2AgAPCxDrBQALIAFBARDdBQALUgEBfyMAQSBrIgIkACACQRhqIAFBEGooAgA2AgAgAkEQaiABQQhqKQIANwMAIAIgASkCADcDCCACIAJBCGoQhgIgACACKQMANwIAIAJBIGokAAtbAAJAIAEgA30iAyABVg0AAkAgAiAETwRAIAMhAQwBCyADQn98IgEgA1YNASACQYCU69wDaiECCyAAIAE3AwAgACACIARrNgIIDwtBlKTKAEEjQcykygAQjgMAC0wBA39BASEDA0AgAkEgRwRAIAEgAmotAAAgACACai0AAHMiBEEAIARrckF/c0GAAXFBB3YQlgUgA3EhAyACQQFqIQIMAQsLIAMQlgULVwECfyMAQRBrIgIkACACQQhqIAEQqwECf0EAIAIvAQhFDQAaIAIgAUEgaiACLwEKEKQEIAIoAgQhAyACKAIACyEBIAAgAzYCBCAAIAE2AgAgAkEQaiQAC10BAX8jAEEwayIDJAAgAyABNgIMIAMgADYCCCADQSRqQQE2AgAgA0IBNwIUIANBlKvKADYCECADQbQBNgIsIAMgA0EoajYCICADIANBCGo2AiggA0EQaiACEL0EAAtVAQF/IwBBIGsiAiQAIAJBGGogAUEYaikCADcDACACQRBqIAFBEGopAgA3AwAgAkEIaiABQQhqKQIANwMAIAIgASkCADcDACAAIAIQuwIgAkEgaiQAC2ABA38jAEEQayIBJAACQEGg2MoAKAIAIgANAEEDQQAQnQEhAkGg2MoAQaDYygAoAgAiACACIAAbNgIAIABFBEAgAiEADAELIAEgAjYCDCABQQxqEP4DCyABQRBqJAAgAAtYAQJ/IwBBEGsiASQAQQFBARCkBSICRQRAQQFBARDdBQALIAJBADoAACAAQQA6AAQgACACNgIAIAAgAS8ADTsABSAAQQdqIAFBD2otAAA6AAAgAUEQaiQAC1gBAX8jAEEQayICJAACQCAAKAIABEAgAiABQfSFygBBBBCcBCACIAA2AgwgAiACQQxqQfiFygAQjgEMAQsgAiABQYiGygBBBBCcBAsgAhCAAiACQRBqJAALVwEBfwJAIAJBf0oEQAJAIAJFBEBBASEDDAELIAJBARCkBSIDRQ0CCyADIAEgAhDyAyEBIAAgAjYCCCAAIAI2AgQgACABNgIADwsQ6wUACyACQQEQ3QUAC1YBAX8jAEEQayICJAAgAiABQfSlygBBCBCcBCACIAA2AgwgAiACQQxqQayeygAQjgEgAiAAQQRqNgIMIAIgAkEMakH8pcoAEI4BIAIQgAIgAkEQaiQAC0wBAX8jAEFAaiIBJAAgAUEYakIANwMAIAFBEGpCADcDACABQQhqQgA3AwAgAUIANwMAIAFBIGogABBDIAFBIGogARCIAyABQUBrJAALVgECfyABKAIAIQIgAUEANgIAAkAgAgRAIAEoAgQhA0EIQQQQpAUiAUUNASABIAM2AgQgASACNgIAIABBvMbEADYCBCAAIAE2AgAPCwALQQhBBBDdBQALVgECfyABKAIAIQIgAUEANgIAAkAgAgRAIAEoAgQhA0EIQQQQpAUiAUUNASABIAM2AgQgASACNgIAIABBnOnJADYCBCAAIAE2AgAPCwALQQhBBBDdBQALVQICfwJ+IwBBIGsiASQAEO8FIAEpAxAhAyABKAIYIQIgARCLAiABKQMAIQQgAEEYaiABKQMINwMAIAAgBDcDECAAIAI2AgggACADNwMAIAFBIGokAAtVAQJ/IwBBIGsiAiQAIAJBEGogARDRBCACQQhqIAJBEGpBtPXJABCFAyACKAIIIQMgAEEIaiACLQAMQQFxOgAAIAAgAzYCBCAAIAE2AgAgAkEgaiQAC1YBAn8gASgCACECIAFBADYCAAJAIAIEQCABKAIEIQNBCEEEEKQFIgFFDQEgASADNgIEIAEgAjYCACAAQcyCygA2AgQgACABNgIADwsAC0EIQQQQ3QUAC1YBAn8gASgCACECIAFBADYCAAJAIAIEQCABKAIEIQNBCEEEEKQFIgFFDQEgASADNgIEIAEgAjYCACAAQYCMygA2AgQgACABNgIADwsAC0EIQQQQ3QUAC1QBAX8jAEEgayIDJAAgA0EIaiACQQAQiQMgA0EANgIYIAMgAykDCDcDECADQRBqIAEgAhCuBSAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBIGokAAtbAQF/IwBBIGsiAiQAIAIgARDvASACKAIAQQFGBEAgAiACKQIENwMYQbD3wQBBKyACQRhqQdz3wQBBiPrBABCoAgALIAIgAigCBBCmASAAIAIQ5wQgAkEgaiQAC1MBAX8jAEFAaiIDJAAgA0EgaiABIAIQrAEgA0EIaiADQSBqQaj6wQAQ6wIgAyADQQhqELAEIAAgAygCACADKAIEEJwDIANBCGoQowUgA0FAayQAC1YBAX8jAEEgayICJAAgAkEIakHAAEEAEIkDIAJBADYCGCACIAIpAwg3AxAgAkEQaiABQcAAEK4FIABBCGogAigCGDYCACAAIAIpAxA3AgAgAkEgaiQAC1cBAX8jAEEgayIDJAAgA0EIaiACQQAQiQMgA0EANgIYIAMgAykDCDcDECADQRBqIAEgASACahCgBCAAQQhqIAMoAhg2AgAgACADKQMQNwIAIANBIGokAAtxAQJ/QRchAkGghMoAIQMCQAJAAkACQAJAIAFB/wFxQQFrDgQBAgMABAtB3ILKAEEoQeCDygAQuQQAC0ESIQJBjoTKACEDDAILQREhAkH9g8oAIQMMAQtBDSECQfCDygAhAwsgACACNgIEIAAgAzYCAAtZAQF/IwBBEGsiAiQAAkAgASgCAA0AIAIgASgCBCABQQhqKAIAEC8gAigCAA0AIAAgAigCBCACQQhqKAIAEJMDIAJBEGokAA8LQeiQygBBKEHskcoAELoEAAtKAQF/IAAoAghBKGwhASAAKAIAIQADQCABBEAgACgCAARAIAAQgQULIAAoAhQEQCAAQRRqEIEFCyAAQShqIQAgAUFYaiEBDAELCwtWAQJ/IAEoAgAhAiABQQA2AgACQCACBEAgASgCBCEDQQhBBBCkBSIBRQ0BIAEgAzYCBCABIAI2AgAgAEHkpcoANgIEIAAgATYCAA8LAAtBCEEEEN0FAAtgAQF/IwBBEGsiAiQAAkACQAJAAkAgAC0AAEEBaw4CAgABCyACIAFB6/DDAEELEJwEDAILIAIgAUH88MMAQQoQnAQMAQsgAiABQfbwwwBBBhCcBAsgAhCAAiACQRBqJAALTQEBfyMAQRBrIgMkACADIAAgASACEJ4BAkAgAygCAEEBRgRAIANBCGooAgBFDQFBzMbEAEEoQZTHxAAQzgMACyADQRBqJAAPCxDCBQALSgEBfyMAQRBrIgIkACACIAAgARB2AkAgAigCAEEBRgRAIAJBCGooAgBFDQFBpN3JAEEoQezdyQAQzgMACyACQRBqJAAPCxDCBQALQQIBfwF+IwBBEGsiASQAIAFBCGpBIUEAEIkDIAEpAwghAiAAQRBqQQA2AgAgAEIANwIAIAAgAjcCCCABQRBqJAALUQEBfyADEMwDIQQgACACNgIEIAAgATYCACAAQQA2AhQgACADKQIANwIIIABBEGogA0EIaigCADYCACAAIAQgAiABa0EDdiIAIAAgBEsbNgIYC1EBAX8gAxDMAyEEIAAgAjYCBCAAIAE2AgAgAEEANgIUIAAgAykCADcCCCAAQRBqIANBCGooAgA2AgAgACAEIAIgAWtBAnYiACAAIARLGzYCGAtMAQF/IwBBEGsiAyQAIAMgACABIAIQdQJAIAMoAgBBAUYEQCADQQhqKAIARQ0BQaTvyQBBKEGU78kAEM4DAAsgA0EQaiQADwsQwgUAC1cBAX8jAEEwayIBJAAgAUEIaiAAQdcAEKYFIAFBJGpBATYCACABQgE3AhQgAUHw78kANgIQIAEgASkDCDcDKCABIAFBKGo2AiAgAUEQakGY8MkAEKkEAAtXAQF/IwBBMGsiASQAIAFBCGogAEHXABCmBSABQSRqQQE2AgAgAUIBNwIUIAFB7PXJADYCECABIAEpAwg3AyggASABQShqNgIgIAFBEGpB0PbJABCpBAALTAEBfyMAQRBrIgMkACADIAAgASACEHoCQCADKAIAQQFGBEAgA0EIaigCAEUNAUGqicoAQShB8InKABDOAwALIANBEGokAA8LEMIFAAtFAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqEP0CIAAgAikDCDcCACACQSBqJAALSwEBfyMAQTBrIgIkACACQRhqQgA3AwAgAkEgakIANwMAIAJBKGpCADcDACACQgA3AxAgAkIBNwMIIAAgAkEIaiABEFkgAkEwaiQAC18BAX8jAEEgayIBJAAgAUEYakGU3ckANgIAIAFBFGpB2PbIADYCACABQQxqQrzmADcCACABQQE7ARwgAUHY9sgANgIIIAFCgICAgMDnDDcDACAAIAEQtAEgAUEgaiQAC1MBAX8jAEGAAWsiASQAIAEQpwIgAEIANwMAIABBADYCUCAAQQhqQgA3AwAgAEHUAGogAUGAARDyAxogAEEQakHI6MkAQcAAEPIDGiABQYABaiQAC04BAX8jAEEgayIBJAAgAUEQaiAAENEEIAEgAUEQakHk9MkAEIUDIAEgAS0ABDoADCABIAEoAgA2AgggAC0AECABQQhqENIEIAFBIGokAAtDAQN/AkAgAkUNAANAIAAtAAAiAyABLQAAIgRGBEAgAEEBaiEAIAFBAWohASACQX9qIgINAQwCCwsgAyAEayEFCyAFC0sBAX8jAEHQAGsiBiQAIAZBCGogBSADIAQgASACEM8DIAYoAkgiAUHBAE8EQCABQcAAEOUCAAsgACAGQQhqIAEQnAMgBkHQAGokAAtHAQF/IwBBIGsiAiQAIAJBCGogARBbIAAgAikCDDcCACAAQQhqIAJBFGopAgA3AgAgAEEQaiACQRxqKAIANgIAIAJBIGokAAtPAgF/An4jAEEQayIEJAAgBEEIakEAIAMgASACENQDIAQpAwghBSAEIAMgAiABIAIQ1AMgBCkDACEGIAAgBTcCACAAIAY3AgggBEEQaiQAC0oAAn8gAUGAgMQARwRAQQEgACgCGCABIABBHGooAgAoAhARAgANARoLIAJFBEBBAA8LIAAoAhggAiADIABBHGooAgAoAgwRBAALC0IBBH8CQCABKAIAIgIgASgCBE8NACACQQFqIgMgAkkNACABKAIAIQQgASADNgIAQQEhBQsgACAENgIEIAAgBTYCAAtIAQF/IwBBEGsiBiQAIAYgBTYCDCABIAIgA0EAEJUFIAEgBkEMakEEQQEQlQUgASAEIAUQwgIgACABQdABEPIDGiAGQRBqJAALSgAgACABKQAANwAAIABBF2ogAUEXaikAADcAACAAQRBqIAFBEGopAAA3AAAgAEEIaiABQQhqKQAANwAAIAAgAS0AH0H/AHE6AB8LRgEBfyMAQYABayIDJAAgA0EwaiABEIYBIANB2ABqIAIQhgEgA0EIaiADQTBqIANB2ABqEA0gACADQQhqEHEgA0GAAWokAAtKAgJ/An4CfkIAIAEoAgQiAkEISQ0AGiABKAIAIgMpAAAhBCABIAJBeGo2AgQgASADQQhqNgIAQgELIQUgACAENwMIIAAgBTcDAAtIAQN/An9BACABKAIEIgJBBEkNABogASgCACIDKAAAIQQgASACQXxqNgIEIAEgA0EEajYCAEEBCyEBIAAgBDYCBCAAIAE2AgALSgEBfyMAQUBqIgIkACACQQBBwAAQwQQiAkEgIAFBwAFqQSAQsAEgAkEgakEgIAFBoAFqQSAQsAEgACACQcAAEPIDGiACQUBrJAALRgEBfyMAQYABayIDJAAgA0EwaiABEIcBIANB2ABqIAIQhwEgA0EIaiADQTBqIANB2ABqEA4gACADQQhqEHEgA0GAAWokAAtFAQF/IwBBIGsiAiQAIAJBGGogAUEIaigCADYCACACIAEpAgA3AxAgAkEIaiACQRBqELoCIAAgAikDCDcCACACQSBqJAALNQAgAQR/QX8gAkF/amd2QQAgAkECTxsiAUEBaiICIAFPBUEACyEBIAAgAjYCBCAAIAE2AgALRgEBfyMAQRBrIgMkACADQQxqIAJBCGooAgA2AgAgAyACKQIANwIEIAMgATYCACAAIAEgA0EEchC/ASAAEPoCIANBEGokAAtHAQN/IwBBEGsiAiQAIAJBCGogAUEEahCqBSACKAIMIQQgAigCCCEDIAAgATYCCCAAIAM2AgAgACADIARqNgIEIAJBEGokAAtCAQR/IAAoAgQgACgCACIBayECA0AgAkUEQEEADwsgACABQQFqIgM2AgAgAkF/aiECIAEsAAAgAyEBQX9KDQALQQELRgEBfyMAQRBrIgMkACADIAEgAhAvIAMoAgQhASADKAIAIQIgACADQQhqKAIANgIEIABBACABIAJBAUYbNgIAIANBEGokAAtDAQF/IwBBEGsiAiQAIAIgACABEOMCIAIgAigCBDYCDCACIAIoAgAiADYCCCAABEAgAkEIahD6AQsgAkEQaiQAIABFCzoBA39BHyEBA0AgAUF/RwRAIAAgAWoiAiADIAItAAAiAkEDdnI6AAAgAUF/aiEBIAJBBXQhAwwBCwsLNgEDfwNAIAFBIEcEQCAAIAFqIgIgAyACLQAAIgJBA3RyOgAAIAFBAWohASACQQV2IQMMAQsLC0YBAn8CQCAALQAQQQVGDQAgACgCCCIBRQ0AIAEgACgCDCgCABEDACAAKAIMIgEoAgQiAkUNACAAKAIIIAIgASgCCBC2BQsLQQAgAEEANgIQIAAgAzYCCCAAIAI2AgQgACABNgIAIABBDGogBDYCACAAIAQgA2siACACIAFrIgEgASAASxs2AhQLQAECfyAAKAIEIgFFBEBBAA8LIAAoAggiAARAIAEgAG4iAiABIAAgAmxrQQBHag8LQcDhyQBBGUGs4ckAEM4DAAs/AQF/IAAgASgCCCIDIAJsIgIgASgCAGo2AgAgACABKAIEIgAgACACIANqIgEgASAASxsgASACSRsgAms2AgQLSAEBfyMAQSBrIgMkACADQRRqQQA2AgAgA0HEqsoANgIQIANCATcCBCADIAE2AhwgAyAANgIYIAMgA0EYajYCACADIAIQvQQAC0MBAX8jAEGgA2siBiQAIAYgASACIAMQvQEgBiAEIAUQcyAGQdABaiAGQdABEPIDGiAAIAZB0AFqENgEIAZBoANqJAALQQECfwJAIAAoAggiAUUNACABIABBDGoiASgCACgCABEDACABKAIAIgEoAgQiAkUNACAAKAIIIAIgASgCCBC2BQsLOgEBfyMAQRBrIgAkAEHk+coAKAIAQQNHBEAgAEEBOgALIAAgAEELajYCDCAAQQxqED4LIABBEGokAAtFAQF/IwBBEGsiBSQAIAUgBDYCDCAAIAEgAkEAEJUFIAAgBUEMakEEQQEQlQUgAEECQQAQRCAAIAMgBBDBAiAFQRBqJAALPQEBfyMAQRBrIgUkACAFIAQ2AgwgACABIAJBABCVBSAAIAVBDGpBBEEBEJUFIAAgAyAEEPsBIAVBEGokAAs4AAJAIAIgAU8EQCAEIAJPDQEgAiAEEOUCAAsgASACEOYCAAsgACACIAFrNgIEIAAgASADajYCAAs4AQF/IwBBMGsiAyQAIANBCGogAUEoEPIDGiADQQhqIAIQ5QMgACADQQhqQSgQ8gMaIANBMGokAAs8ACAAIAEpAAA3AAAgAEEYaiABQRhqKQAANwAAIABBEGogAUEQaikAADcAACAAQQhqIAFBCGopAAA3AAALPQEBfyMAQRBrIgIkACACIAFB0brGAEEOEJwEIAIgADYCDCACIAJBDGpB4LrGABCOASACEIACIAJBEGokAAtFAQJ/IwBBEGsiASQAQbyOygAoAgARCAAiAEUEQEGIk8oAQcYAIAFBCGpBqJTKAEGYlMoAEKgCAAsgAC0AACABQRBqJAALNgEBfyMAQTBrIgIkACACQQhqIAFBKBDyAxogAkEIahCCAiAAIAJBCGpBKBDyAxogAkEwaiQACz4BAX8jAEHgAWsiAyQAIAMQwwIgAyABIAIQjQEgA0HwAGogA0HwABDyAxogACADQfAAahDuAiADQeABaiQACzsBAn8jAEEQayICJAAgAkEIaiABEKoFIAIoAgwhASAAIAIoAggiAzYCACAAIAEgA2o2AgQgAkEQaiQACzkBAX4CQCAAKQMIIgJCAVMNACAAKAKcIEEASA0AIAAgAkJAfDcDCCAAQRBqIAEQEQ8LIAAgARDbAQs4AQF/IwBBEGsiAyQAIANBADYCDCADIAIgA0EMahCqASAAIAEgAygCACADKAIEEPsCIANBEGokAAs5AQF/IwBBEGsiAiQAIAJBADYCDCACQcUAIAJBDGoQqgEgACABIAIoAgAgAigCBBDvAiACQRBqJAALSAACQCAALQAEDQBBiPrKACgCAEEBRwRAQYj6ygBCATcDAAwBC0GM+soAKAIARQ0AIAAoAgBBAToABAsgACgCACgCAEEAOgAAC2MBA38jAEEQayIBJAAgACgCDCICRQRAQZicygBBK0GMpcoAEM4DAAsgACgCCCIDRQRAQZicygBBK0GcpcoAEM4DAAsgAUEANgIEIAEgAzYCACABQaylygAgACgCCCACEMABAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQbCCwABBLkH8gsAAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQdyFwABBLkGohsAAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQaD5wQBBLkHs+cEAEM4DAAs+ACAAKAIAQQ9NBEAgACgCAEECdEGY+coAaiABNgIAIAAgACgCAEEBajYCAA8LQaz7wQBBLkH4+8EAEM4DAAswAQJ/A0AgAkEoRwRAIAAgAmoiAyADKQMAIAEgAmopAwB8NwMAIAJBCGohAgwBCwsLOQEBfyMAQRBrIgQkACAEQQhqIANBCGooAgA2AgAgBCADKQIANwMAIAAgASACIAQQqgMgBEEQaiQACzkBAX8jAEEQayIEJAAgBEEIaiADQQhqKAIANgIAIAQgAykCADcDACAAIAEgAiAEEKkDIARBEGokAAs+AQF/IwBBEGsiASQAIAEQkQMgAUEIakIBNwIAIABBADoAECAAIAEpAwA3AgAgACABKQMINwIIIAFBEGokAAtOAQN/IwBBEGsiASQAIAFBCGoiAiAAKAIEIgNBGGw2AgAgAiADQQBHQQJ0NgIEIAEoAgwiAgRAIAAoAgAgASgCCCACELYFCyABQRBqJAALMwECfxCbBCECAn9BACABLQAERQ0AGkEBCyEDIAAgATYCBCAAIAM2AgAgAEEIaiACOgAACzoBAX8gABCaBSAALQAEIgFBAkcEQAJAIAENACAAKAIAEJsERQ0AQQE6AAQLIAAoAgAoAgBBADoAAAsLOQEBfyMAQRBrIgMkACADIAI2AgwgAyABNgIIIAAgA0EIaigCADYCACAAIAMoAgw2AgQgA0EQaiQACzQAIAEoAgAEQCABQQhqIAFBB2otAAAQigQLIAAgASkCCDcCACAAQQhqIAFBEGooAgA2AgALMgEBfyMAQUBqIgIkACABEIEBIAIQpgIgAUEQaiACEHAgACACQcAAEPIDGiACQUBrJAALQgECfyMAQRBrIgAkAEHE9ckAKAIAEQgAIgFFBEBB4PbJAEHGACAAQQhqQYD4yQBB8PfJABCoAgALIABBEGokACABCzYBAn4gASkAACEDIAAgAUEIaikAAEIBhCICNwMIIAAgAiADfEKt/tXk1IX9qNgAfiACfDcDAAs1AQF/IwBBEGsiAiQAIAJBCGogACgCACAAKAIEEKYFIAIoAgggAigCDCABELsBIAJBEGokAAszAQF/IAIEQCAAIQMDQCADIAEtAAA6AAAgA0EBaiEDIAFBAWohASACQX9qIgINAAsLIAALLQEBfyADIAIQ3QEiBARAIAQgACADIAEgASADSxsQ8gMaIAAgASACEN4BCyAECzoBAX8jAEFAaiIDJAAgAUHY8MMAQQcgA0EAQcAAEMEEIgFBwAAgAkEBEIoFIAAgARDDBCABQUBrJAALNgEBfyMAQdABayIDJAAgAxDrASADQfjywwBBByABIAIQ0gMgACADQdABEPIDGiADQdABaiQACzIBAX8jAEEQayIDJAAgAyACNgIMIAAgA0EMakEEQQAQlQUgACABIAIQ+wEgA0EQaiQACy0BAX8jAEFAaiICJAAgAiAAEEMgAkEgaiABEEMgAiACQSBqEIgDIAJBQGskAAszAQF/IAJBAXYhAyACQQ9NBEAgACABIANBoAFsakGgARDyAxoPC0GsvsQAIANBCBDkAgALOAEBfyABQQF2IQIgAUH/AE0EQCAAIAJB+ABsQdj8wwBqQfgAEPIDGg8LQby+xAAgAkHAABDkAgALMwEBfyACQQF2IQMgAkEPTQRAIAAgASADQaABbGpBoAEQ8gMaDwtBhPDIACADQQgQ5AIACzgBAX8gAUEBdiECIAFB/wBNBEAgACACQfgAbEGAr8gAakH4ABDyAxoPC0GU8MgAIAJBwAAQ5AIACzgBAX8gASgCCCIDIAJB//8DcSICTQRAQbj0yAAgAiADEOQCAAsgACABKAIAIAJBA3RqKQIANwIACzcCAX8BfiMAQRBrIgIkACACQQhqIAFBABCJAyACKQMIIQMgAEEANgIIIAAgAzcCACACQRBqJAALMgECfyAAKAIAIgEoAgRB8ABsIgIEfyABKAIAIAJBCBC2BSAAKAIABSABC0EQQQQQtgULNQEBfyAALQAIIgFBAkcEQAJAIAENACAAKAIEEJsERQ0AQQE6AAQLIAAoAgQoAgBBADoAAAsLMgEBfyAAKAIIQQxsIQEgACgCACEAA0AgAQRAIAFBdGohASAAELUEIABBDGohAAwBCwsLNgEBfyABIAIoAgAiBBCoBCABKAIAEMAFIABBCGogAzoAACAAIAI2AgQgACACLQAEQQBHNgIACysAAkAgAEF8Sw0AIABFBEBBBA8LIAAgAEF9SUECdBCkBSIARQ0AIAAPCwALLwAgAyABIAQgAkECdCIBIAEgBEsbIgEQ8gMaIAAgATYCBCAAIAFBA2pBAnY2AgALNQEBf0EBQQEQpAUiAUUEQEEBQQEQ3QUACyABQQA6AAAgAEEAOgAFIABBADoABCAAIAE2AgALMwEBfyABKAIIIgMgAkkEQCACIAMQ5gIACyAAIAMgAms2AgQgACABKAIAIAJBGGxqNgIACzAAIAAoAghBAUYEfyAAKAIAIgBBgonKAEYEQEEBDwsgAEGCicoAQQEQtANFBUEACwtJAQN/IwBBEGsiAiQAIAEiAygCCCIEIAEoAgRHBEAgAyAEENQCCyACQQhqIAEoAgAgASgCBBDsAyAAIAIpAwg3AgAgAkEQaiQACzUBAX8jAEHAAmsiAyQAIANBoAFqIAIQiQIgAyABIANBoAFqEJIBIAAgAxCDAiADQcACaiQACzABAX8gACgCACIBIAAoAgRHBEAgACABQQFqNgIAIAAgACgCCEEBajYCCCABDwtBAAs0ACAAKAIIIAAoAgRGBEAgAEEBEL4FCyAAKAIAIAAoAghqIAE6AAAgACAAKAIIQQFqNgIICzABAX8jAEEQayICJAAgACgCCCABTwRAIAJBCGogABCbBSAAIAE2AggLIAJBEGokAAs4AQF/IAFBBGohBAJAIAEoAgBBAUYEQCAEKAIAIAIgAxAJDAELIAQoAgAgAiADEAoLIABBBToAEAszAQF/IwBBEGsiBCQAIARBCGogASACIAMoAgAgAygCCBAwIAAgBCkDCDcCACAEQRBqJAALMwAjAEEQayIAJAAgABD/ASAAIAAtAAQ6AAwgACAAKAIANgIIIABBCGoQ6wMgAEEQaiQACzoBAX9BvI7KACgCABEIACIARQRAQQEPCyAALQAABEAgAEEAOgAAQQAPC0G4lMoAQRxBrJXKABC6BAALMwEBfyMAQUBqIgQkACABIAIgAyAEQQBBwAAQwQQiAUHAABDTAyAAIAEQwwQgAUFAayQACzQAIAAoAgAhACABELQFRQRAIAEQtQVFBEAgADEAACABEHcPCyAAIAEQ8QEPCyAAIAEQ8AELMgAgACgCACEAIAEQtAVFBEAgARC1BUUEQCAAIAEQwwUPCyAAIAEQ9gEPCyAAIAEQ9QELLQEBfyMAQeABayICJAAgAkEIaiAAQdgBEPIDGiACQQhqIAEQeyACQeABaiQACy8BAX8jAEFAaiIEJAAgBCABQcABahBgIAAgBCACIAMgARBfIAQQoAIgBEFAayQACyYAAn9BAyAAKAIAIgBBAXENABpBAiAAQQRxDQAaIABBAXZBAXELCy4AIAAgBxD/BCACIAV8fCABEIAFfDcDCCAAIAYQ/wQgASAEfHwgAxCABXw3AwALLAAgAC0AEEECRwRAQZzYygBBnNjKACgCAEF/ajYCACAAKAIAQQFBARC2BQsLLgEBfwJAIAAoAgAiAUEBR0EAIAFBfmpBA0kbDQAgACgCBCIAQSRJDQAgABAACws0AQF/IwBBEGsiASQAIAAEQEGIk8oAQcYAIAFBCGpBqJTKAEGYlMoAEKgCAAsgAUEQaiQACysAIwBBEGsiACQAIABBCGogAUG8nsoAQQsQvwQgAEEIahCxAiAAQRBqJAALOgEBfwJAQYj6ygAoAgBBAUYEQEGM+soAKAIAIQAMAQtBiPrKAEIBNwMAC0GM+soAIAA2AgAgAEEARws0ACAAIAEoAhggAiADIAFBHGooAgAoAgwRBAA6AAggACABNgIAIAAgA0U6AAkgAEEANgIECy4BAX8jAEEQayIEJAAgBEEIaiADIAIgASACENQDIAAgBCkDCDcCACAEQRBqJAALLgEBfyMAQRBrIgQkACAEQQhqQQAgAyABIAIQ1AMgACAEKQMINwIAIARBEGokAAsvAQF/IwBBEGsiAiQAIAJBCGogAUEgIAEoAiAQngQgACACKQMINwIAIAJBEGokAAs1AQF/IAAgACgCCCACIAFrIgIQpgMgACAAKAIIIgMgAmo2AgggAyAAKAIAaiACIAEgAhCvAQsuAQF/IwBB4AFrIgIkACACQQhqIAFB2AEQ8gMaIAAgAkEIahDuAyACQeABaiQACyoBAX8jAEEQayIDJAAgA0EIaiABIAIQrwQgACADKQMINwIAIANBEGokAAskAAJAIAEgA0YEfyAAIAJHDQFBAQVBAAsPCyAAIAIgARC0A0ULMAEBfyMAQRBrIgMkACADQQhqIAEoAgAoAgAgAhD8AyAAIAMpAwg3AgAgA0EQaiQACywCAX8BfiMAQRBrIgEkACABQQA2AgwgACABQQxqEKcFIAE1AgwgAUEQaiQACykAIABBJGotAABBAkYEQCAAKAIAIAAoAgQgARDOAQ8LIABBCGogARAYCzABAX8gACACIAFrIgIQvgUgACAAKAIIIgMgAmo2AgggAyAAKAIAaiACIAEgAhCzAQswACAAIAAoAgQiACABIAAbNgIEIABFIAAgAUZyRQRAQfihygBBNkHIosoAELwEAAsLNQEBfyMAQRBrIgIkACACIAE2AgwgAiAANgIIIAJB7JvKADYCBCACQeybygA2AgAgAhDgAwALLAAgACABKQIANwIAIABBEGogAUEQaikCADcCACAAQQhqIAFBCGopAgA3AgALKgEBfyMAQTBrIgIkACACQQhqIAAQ2QMgACACQQhqIAEQiAIgAkEwaiQACysAIAAgASACEIgCIABBKGogAUEoaiACEIgCIABB0ABqIAFB0ABqIAIQiAILLQEBfyMAQRBrIgMkACADIAE2AgwgAyAANgIIIANBCGpBqMbEAEEAIAIQwAEACywBAX8jAEEQayICJAAgAkEIaiABENAFIAAgAigCCCACKAIMEH4gAkEQaiQACyEAIAJBIE8EQCAAQSA2AgQgACABNgIADwtBICACEOUCAAsrAQF/IwBBEGsiAiQAIAJBCGogAUEMahCbBSAAIAIpAwg3AgAgAkEQaiQACywBAX8jAEEQayICJAAgAkEIaiABEKoFIAAgAigCCCACKAIMEH4gAkEQaiQACywBAX8jAEEQayICJAAgAkEIaiABEKkFIAAgAigCCCACKAIMEH4gAkEQaiQACy0BAX8jAEEQayICJAAgAkEIaiABENsDIAAgAigCCCACKAIMENEBIAJBEGokAAstAQF/IwBBEGsiAyQAIAMgATYCDCADIAA2AgggA0EIakGI6ckAQQAgAhDAAQALLgEBfwJAIABBCGotAAANACAAKAIEEJsERQ0AQQE6AAQLIAAoAgQoAgBBADoAAAsuAQF/IwBBEGsiAiQAIAJBADYCCCACIAE2AgQgAiAANgIAIAIQ1AUgAkEQaiQACygBAX8Cf0EAIAEoAgARCAAiAQ0AGkEBCyECIAAgATYCBCAAIAI2AgALLAAgACABKQIANwIAIABBEGogAUEQaigCADYCACAAQQhqIAFBCGopAgA3AgALLQEBfyMAQRBrIgMkACADIAE2AgwgAyAANgIIIANBCGpBuILKAEEAIAIQwAEACy0BAX8jAEEQayIDJAAgAyABNgIMIAMgADYCCCADQQhqQeyLygBBACACEMABAAsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQ/QEgAkEQaiQACy0BAX8jAEEQayIDJAAgAyABNgIMIAMgADYCCCADQQhqQdClygBBACACEMABAAs1AQF/IwBBEGsiAiQAIAIgATYCDCACIAA2AgggAkGwq8oANgIEIAJBxKrKADYCACACEOADAAsyAQF/QQEhASAALQAEBH8gAQUgACgCACIAKAIYQbSsygBBASAAQRxqKAIAKAIMEQQACwswACABKAIYIAIgAyABQRxqKAIAKAIMEQQAIQIgAEEAOgAFIAAgAjoABCAAIAE2AgALNQEBfyABKAIYQbOsygBBASABQRxqKAIAKAIMEQQAIQIgAEEAOgAFIAAgAjoABCAAIAE2AgALKQEBfyACBEAgACEDA0AgAyABOgAAIANBAWohAyACQX9qIgINAAsLIAALJQEBfyMAQSBrIgEkACABIAAQQyABLQAAQQFxEJYFIAFBIGokAAsmAQF/IwBBMGsiAiQAIAJBCGogARBNIAAgAkEIahBxIAJBMGokAAspACACQYEBTwRAIAJBgAEQ5gIACyAAQYABIAJrNgIEIAAgASACajYCAAsmAQF/IwBBMGsiAiQAIAJBCGogARBOIAAgAkEIahBxIAJBMGokAAsmACACIANJBEAgAyACEOYCAAsgACACIANrNgIEIAAgASADajYCAAshACAAEJUEQf8BcUEDRgR/IABBBGpBACAAKAIEGwVBAAsLJgECfyMAQRBrIgAkACAAQZj6ygA2AgwgAEEMahDXAiAAQRBqJAALJgECfyMAQRBrIgAkACAAQaz6ygA2AgwgAEEMahDWAiAAQRBqJAALKwEBfyAAIAEoAgQiAjYCBCAAIAEoAgAgAigCCCIAQRdqQQAgAGtxajYCAAsnACAAQgA3AAAgAEEYakIANwAAIABBEGpCADcAACAAQQhqQgA3AAALJQEBfyABBH8gARDSBSECQQEFQQALIQEgACACNgIEIAAgATYCAAsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQkwIgAkEQaiQACygBAX8jAEEQayICJAAgAiAAKAIANgIMIAJBDGogARCWASACQRBqJAALKAEBfyMAQRBrIgIkACACQQhqIAEQmwUgACACKQMINwIAIAJBEGokAAsnAQF/IAAgACgCACIBQX9qNgIAIAFBAnEgAUEESXJFBEAgABCUAQsLLwEBfyABKAIAIgItAAAEQEGc8skAQSBBgPPJABC5BAALIAJBAToAACAAIAEQ6QQLKwEBfwJAIAAtAAQNACAAKAIAEJsERQ0AQQE6AAQLIAAoAgAoAgBBADoAAAsvAQF/IAEoAgAiAi0AAARAQciGygBBIEGsh8oAELoEAAsgAkEBOgAAIAAgARDqAwsoAQF/IwBBEGsiAiQAIAIgACgCADYCDCACQQxqIAEQ0QIgAkEQaiQACy8BAX8gASgCACICLQAABEBBk5LKAEEgQfiSygAQugQACyACQQE6AAAgACABEOkECyEBAX8jAEEgayIBJAAgASAAEBQgACABEJ8FIAFBIGokAAsiACABLQAAIAAtAABzIgBBACAAa3JBf3NBgAFxQQd2EJYFCycBAX8jAEHQAWsiAiQAIAAgAiABQdABEPIDIgAQuQEgAEHQAWokAAshAQF/IwBBIGsiASQAIAEgABAVIAAgARCfBSABQSBqJAALIgEBfyMAQSBrIgIkACACIAAgARDaAyACLQAAIAJBIGokAAspAQF/IwBB8ABrIgMkACAAIAMgAUHwABDyAyIAIAIQ8wIgAEHwAGokAAsgAAJAIAFBfEsNACAAIAFBBCACEJQFIgBFDQAgAA8LAAsnAQF/AkAgACgCBCIBRQ0AIABBCGooAgAiAEUNACABIABBARC2BQsLNgEBfyMAQUBqIgIkACAAIAIgAUHAABDyAyIBIgIQ4AQgAEHAAWogAkHAABDyAxogAUFAayQACyEBAX8jAEFAaiICJAAgAiABED8gACACEN4EIAJBQGskAAspAQF/IwBBoAFrIgIkACACIAFBqP/BABDJBSAAIAIQ4QQgAkGgAWokAAsnAQF/IwBBoAFrIgIkACAAIAIgAUGgARDyAyIAEIMDIABBoAFqJAALIAAgAUEETQRAIAAgAUEDdGoPC0HsusQAIAFBBRDkAgALIAAgAUEETQRAIAAgAUEDdGoPC0H8usQAIAFBBRDkAgALJQAgAyABTQRAIAAgAiADEPIDGg8LQdjDxABBKUHcxMQAEK0EAAsgACABQQRNBEAgACABQQN0ag8LQcTsyAAgAUEFEOQCAAsgACABQQRNBEAgACABQQN0ag8LQdTsyAAgAUEFEOQCAAskACAAIAEpAgA3AgAgAEEIaiABQQhqKAIANgIAIAFBDGoQgQULGQAgAC0AEEECRwRAIAAoAgBBAUEBELYFCwsnAQF/EJsEIQIgACABNgIEIABBCGogAjoAACAAIAEtAARBAEc2AgALJQEBfyABKAIAIgJFBEAgAEEDOgAkDwsgACACIAFBCGooAgAQeQsjACAAQQA2AgwgACABKQIANwIAIABBCGogAUEIaigCADYCAAsoAQF/IAAoAgghASAAQYGAxAA2AgggAUGBgMQARgR/IAAQkAEFIAELCx0AIAFBH00EQCAAIAFqDwtBjL3EACABQSAQ5AIACx0AIAFBH00EQCAAIAFqDwtB5O7IACABQSAQ5AIACyYBAX8gACgCACIBKAIAIAEoAgQgACgCBCgCACAAKAIIKAIAECkACx0AIAAgASgCACIBIAJqIgI2AgQgACACIAFPNgIACx4BAX8gACAAKAIAIgFBASABGzYCACABBEAgABBWCwseAQF/IAAoAgAiACgCACAAQQA2AgAoAgAoAgBBDEYLFAAgACgCAEEAOgAQIABBBGoQ0gQLHQEBfyAAKAIEIgEEQCAAKAIAIAFBKGxBBBC2BQsLHQEBfyAAQQRqKAIAIgEEQCAAKAIAIAFBARC2BQsLHQEBfyAAQQhqKAIAIgEEQCAAKAIEIAFBARC2BQsLHQAgASgCAEUEQAALIABBvMbEADYCBCAAIAE2AgALHAAgACABKQIANwIAIABBCGogAUEIaikCADcCAAscACAAIAEpAgA3AgAgAEEIaiABQQhqKAIANgIACx0AIAEoAgBFBEAACyAAQZzpyQA2AgQgACABNgIACx0AIAEoAgBFBEAACyAAQcyCygA2AgQgACABNgIACx4AIABBADYCCCAAIAI2AgQgACABNgIAIABBADoAEAsdACABKAIARQRAAAsgAEGAjMoANgIEIAAgATYCAAsdACAALQAAQQFGBEBByPTIAEEcQYT1yAAQzgMACwsTACAAQgaIIABCA4mFIABCLYmFCxMAIABCB4ggAEI4iYUgAEI/iYULGgEBfyAAKAIEIgEEQCAAKAIAIAFBARC2BQsLHQAgASgCAEUEQAALIABB5KXKADYCBCAAIAE2AgALGwAgAKdFBEBBjMbEAEEZQfzFxAAQjgMACyABCw4AIAAoAgBBAUEBELYFCx8AQZD7ygAtAABBAkYEQEGQ+8oAQQA6AAALQZD7ygALHAAgASgCGEHQqsoAQQsgAUEcaigCACgCDBEEAAscACABKAIYQduqygBBDiABQRxqKAIAKAIMEQQACxkAIAAoAhggASACIABBHGooAgAoAgwRBAALHAAgASgCGEG5wcoAQQUgAUEcaigCACgCDBEEAAsWACAAIAEgAiADIAQgBSAGEO8DENcBCxcAIABBADYCCCAAIAI2AgQgACABNgIACxMAIAAoAgQiAEEkTwRAIAAQAAsLEwAgACgCACIAQSRPBEAgABAACwsXACAAQQA2AgggAEEANgIEIABBATYCAAsZACAAKAIAIgAoAgAgASAAKAIEKAIkEQIACxkAIAAoAgAiACgCACABIAAoAgQoAiARAgALGQAgACgCACIAKAIAIAEgACgCBCgCMBECAAsPACAAKAIABEAgABCBBQsLGQAgACgCACAAKAIEIAEoAgAgASgCBBCjBAsNACAAIAEgAiADEPMDCxMAIABBEiADEEQgACABIAIQwQILFQEBfyMAQRBrIgEgADoADyABLQAPCxUAIAAQ6AMgAEEANgIcIABCADcCFAsSACAALQAQQQVHBEAgABDQAwsLEAAgAQRAIAAgAUEEELYFCwsTACAALQAEQQJHBEAQjwQQmQQLCxYAIAAgASgCCDYCBCAAIAEoAgA2AgALEAAgACABIAIgAyAEIAUQLAsQACAAIAEgAiADIAQgBRAdCw8AIAAgASACIANBIBDSAwsQACAAIAEQjANB/wFxQQFGCw0AIAAoAgAQhgRBAXMLFAAgACgCACABIAAoAgQoAgwRAgALFAAgAEHAAWoQnwEgAEHAAWoQnwELDwAgABCBBSAAQQxqEIEFCwkAIAAgARDdAQsVACAAQa/+wQBBCkHG8MMAQQsQ0gMLEAAgACACNgIEIAAgATYCAAsRACAAKAIAIAAoAgQgARDJAQsTACAAQRc2AgQgAEH83ckANgIACxEAIABBwAA2AgQgACABNgIACxEAIABBgAE2AgQgACABNgIACxwAIAAoAgBBADoAAEGw7MkAQShB2OzJABC5BAALDwAgACgCACABKAIAEAJFCxEAIAAoAgAgACgCBCABEN8FCw4AIAAgASABIAJqEKcECxEAIAAoAgAgACgCCCABEN8FCxAAIAAoAgAgACgCCCABECgLEAAgASAAKAIAIAAoAgQQLgsRACAAQbcBNgIEIAAgATYCAAsNACAALQAAQQRxQQJ2Cw0AIAAtAABBEHFBBHYLDQAgAC0AAEEgcUEFdgsLACAAIAEgAhDeAQsNACAAQQBByAEQwQQaCw4AIAAQJyAAQQA2AsgBCw0AIAAgAUHAABDyAxoLDgAgACgCACgCACABEAwLDgAgACgCACgCACABEBALDgAgACgCACABIAIQ6AELDAAgACgCABABQQFGCw4AIAAgACgCCCABEK4DCw0AIAAgASACIAMQowQLEgBBi6fKAEEdQcinygAQvAQACw0AIAAoAgAgARBCQQALEgBBo6rKAEERQbSqygAQzgMACwsAIAA1AgAgARB3Cw0AIAAoAgAgASACEEYLKQACfyAAKAIALQAARQRAIAFB2K7KAEEFEC4MAQsgAUHUrsoAQQQQLgsLCgAgACABQSAQfgsMACAAKAIAIAEQpQMLCgAgACABQQEQKgsKACAAIAIgARBcCxUAIAAoAgAiACgCACAAKAIEIAEQKAsLACAAKAIAIAEQcgsKACAAKAIAIAFqCwoAIAAgAiABEF0LDAAgACgCACABEMMFCwwAIAAoAgAgARCNAgsMACAAIAEpAgA3AgALCgAgACABIAIQfgsIACAAaEEDdgsMACAAKAIAQQA6AAALIgEBfyAAEIAEIAAoAgQiAQRAIAAoAgAgAUEMbEEEELYFCwsNAEGQ88kAQRkgARAoCwwAIAAoAgAgARDQAgsMACAAIAEpAgg3AgALDAAgACgCACABEJIDCxwAAn9BACAAKAIAEOUBIgBFDQAaIAAgARCIAQsLDQBBkYnKAEEZIAEQKAsNAEHQjsoAQRkgARAoCw0AQdykygBBGSABECgLGgAgACABQej5ygAoAgAiAEGTASAAGxEAAAALDAAgACgCACABEJUBCwoAIAIgACABEC4LCQAgACABEMcDCwgAIABBoAFqCwkAIAAgARCOAgsJACAAQQA2AgALCQAgACABELMECxkAQdj6ygAtAABBAkYEfxCwAgVByPrKAAsLGQBBgPvKAC0AAEECRgR/EMQBBUHw+soACwscAAJ/QajYygApAwBCAVIEQBB0DAELQbDYygALCwcAIAAQogILCQAgACABELsECwkAIABBADYCAAsGABDCBQALBgAgABBJCwcAIAAQlwULBwAgABDSBAsSAEGMpsoAQS5B2KbKABC8BAALBAAgAQsEAEEACwUAQYAECwQAQQELDABC5K7ChZebpYgRCwwAQrOPmIHv8ID7VwsHAEGY+coACw0AQp2ezqyTrKLEgH8LDQBCxfbN6sGgwvaHfwsNAELl0Iz4nPvoupx/CwwAQpv/8avd9Y2acQsDAAALAwABCwMAAQsLos4KLABBgIDAAAuTvARNaW5pU2VjcmV0S2V5QW5hbG9nb3VzIHRvIGVkMjU1MTkgc2VjcmV0IGtleSBhcyAzMiBieXRlcywgc2VlIFJGQzgwMzIuUHVibGljS2V5QSBSaXN0cmV0dG8gU2Nobm9yciBwdWJsaWMga2V5IHJlcHJlc2VudGVkIGFzIGEgMzItYnl0ZSBSaXN0cmV0dG8gY29tcHJlc3NlZCBwb2ludFNlY3JldEtleUFuIGVkMjU1MTktbGlrZSBleHBhbmRlZCBzZWNyZXQga2V5IGFzIDY0IGJ5dGVzLCBhcyBzcGVjaWZpZWQgaW4gUkZDODAzMi5jYWxsZWQgYFJlc3VsdDo6dW53cmFwKClgIG9uIGFuIGBFcnJgIHZhbHVlAAABAAAAGAAAAAQAAAACAAAAYXNzZXJ0aW9uIGZhaWxlZDogc2VsZi5uZXh0IDwgR0xPQkFMX1NUQUNLX0NBUDw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPl4BEAAeAAAAAgAAAAIAAABzcmMvc3IyNTUxOS5ycwAAjAEQAA4AAAAkAAAABQAAAAMAAAAEAAAABAAAAAQAAACMARAADgAAADUAAAAFAAAAjAEQAA4AAABEAAAABQAAAIwBEAAOAAAAUwAAAAUAAACMARAADgAAAHMAAAAFAAAAc3Vic3RyYXRlAAAAjAEQAA4AAAB1AAAALQAAAIwBEAAOAAAAggAAABoAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvaG1hYy0wLjcuMC9zcmMvbGliLnJzAAAoAhAAUgAAAHYAAAARAAAAKAIQAFIAAAB3AAAAEQAAACgCEABSAAAAgQAAACgAAAAoAhAAUgAAAIEAAAARAAAAKAIQAFIAAACCAAAAHgAAACgCEABSAAAAggAAABEAAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLm5leHQgPCBHTE9CQUxfU1RBQ0tfQ0FQPDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+CgMQAB4AAAACAAAAAgAAAAUAAAAEAAAABAAAAAYAAABTY2hub3JyUmlzdHJldHRvSERLRHNpZ24tYnl0ZXNIREtELW5vbmNlY2hhaW4tY29kZXB1YmxpYy1rZXlIREtELXNjYWxhckhES0QtY2hhaW5jb2Rlc2VjcmV0LWtleUhES0QtaGFyZHI7jPXGkwwA9iXDgXHfCAC2TD4LC/UIADFMpIWTMgUASz2j0/l8CAA+kUDXBTkAAKJz1hcougAAfOb0Jyg+AgA0GsLg0jMBAIGPKfnSTwQAaKp6hwUSAQB51ZNYlXkEAKBnmzBmDQUA7uW+DS3UAgDG8Im2F/EGANdxPJP85wwAQ7K2/kHPAgB2Gn0KHFgHAPAyTVMtFwcA0of6Y8CQBQCo1bRCYKUBAFPRnhXMiQEABK48qt64BQDYtRFP8KoCAJKcZlpZuwYAX3qbpbOoAgB/CO9Zs6sDAK8F28So9QQABULQB6i5BQBQ6hNbrwEHADCX7kyosAUA5FVxyRAdBgAQagnInAUEAE8BqI1gegwADqi54WShBwBl0vyk6B8BAMyqTze4vAcAT03v9FovBQAQjfmYQDEFAL1VdViRqwIAidjQDT+TBgCVQky7hkMEAIxQYjFtywMAxqJyuGhjAgCbK/FqgqIFAJ8J/I65UQMADgWnpL+PBgAbl52VSSoEAP2eRhrlkwMAWB4yEOmABgC/GGgFCgUGAL8yVR/MKgYAJfrJzEGBAgCD5nH0YU0CAFpEx/QzeQIACf92xOn7AwBCSy6Ya68AAOV4ulESrQAAiHzu7a4VBwBTNfbL0PkHACC7pQhEvAIAQlSg3et4CAAiQTUSsf8KACyG9Y3udQsAH24Uz1yUCgC61kekw4IBAPLvNuVkKQIAUwBUH4KSAQBcjnie8fkCALWxPuenVAEAhYIqgfHbAwCXlz+6F/oAACA4nLSc9gYAjYWzDVpNAwC7s5bmqzoEADFxFXfr7gQAQQfxFRkgAQBWnGzanGYJAGw02zLAXgQAwyxqu1ceBQCkjH17tgYAADMp50T6hAAAim9d5U4VAQCQcy6EXUIEABfkGsRkiwMAcUvqAmcyBAC1MGA3NGgAAIDD+RIF7wAAhCVR8qnxAADW8KmRjgsBAL+jTpTQXAoAYk0auHNWBwDUwNEluVAJABNBKdk4PwkAyIOSpr5hBACxITKqmiwHAE33dER3ZwIAhYCy6bBkAADJJzv1TvADADHl0tXt1gEAorO4AchtAwAwXpPUp+AAAH0NzM633gEALN0gTqlTAAD5oMax+6kHAHw+3QRmWQ8ANYsFDlH8DgAMzLKNDGcDAC8zzpnYlwIAzhsGdl6RCADZNJLz7V0HAFQ8H6s2HAAA2vVY7o/wAAA31qATluEAAOAgE0oCqQMAGpGiydn1AQD4/PqUeREHAMWN4sqo2AIAhwwJsrFKBwDE7MLFB2kCAB2cL2MO3QQA2aUiJtHOCgDZQkdh6Y0JANO122+pnAcA7gCa1DfdBgBeUapJVGMDAKtdR9B44QMAEpehEkcLBQCt9A+GwtwCADE98NZ2DQMAx+QGIRdEBACILe2vURIAAFpP7Zv8NAUANFLPOVrYBQBk6BJxaQwBAPLHWIOgKgYAlOFICERvBAAr9ahxt0cEAB3TaTK6dwMAgFD1uvk7CADeX759J8QDAJJM1K81owUAPnWZQBbBAAAj5G8AhwQHAG/WvsphXgIABGZYzCjhAwDix48ui5YFAM9hvdWjSQAA5vYeW1AWAQBuWDSG12YFAL0vWsaFQg0AH3T4zGJeBQBEkLFhuWsMADggcQU0FQkAOnk0X7pPCQA0CMGcn6QHAMYiingTtQIAWznybkv/BQC/B/ZajuwCAMPspbx1OQMA1PeFaRZGBwCa5woAOZkAAHr5ZHlMhAUAPVv54Rc2AQDFP6jOKUgBAKXscU4vCwcAPGT8jhQoBwB2W5kDPnUIAGZnq7Jfvw0A1jVFvMNfCADCld2XhHsDAOj/tNZJFQYAONGxLaIXAgCesC4Gz7kAAFj35XGc/QIA3d6vUq6zAACX5Blmp50BAI5V0lQG+gYA1EFe0hmCBwBRxnV0dnMDAJBlJBTLlQgAZ6ymKtgCCABQSLyD8UIMAEMGChxPRgYABwlzBVm/BgDZrdFA/ZkCAPflBJre8gUAWRzMuu7ABwAKKfixocwEAI+xw1bq+wEAiltB4fF4BwD0we90WPcGAH8CGUBpigIATdxrqTcrBQA1pmfPISUAANFeL3cgZwQAItZZ88AyBgBS4qMrCbICAIAmEXwlYg4A1XyfPXUBCACUUp0KC+4HACfKTOv7gQMAnWM+Oh+EBwBfRMMw6nYGAIIT56cA+gMANNs9li0jAQCNBwvnklYDAB96dxTKRwIA0Pzoa1XbBgCOBPriXysBAJIeb60mfAsA5HsicQlqBABMmy0NL3IEADrgTiBG3AMAbHkgPOn3BgBN4/yWxPsAAD6ufWu+dQUACebOhRWjBAD/MDkC6TcAABL7lm+3SQcABa6mrgT2AgDrI5OT3DcGAEeNBJut/QMA91oE1LCoAAACHvAQ7PwAAEVOJMSd0gIAvkfBG3uSBgA5CKw0hTAIAEA/A2Q2hQQAq/5mkXcTBABEHv5JplgFAInM7641RgQAuvKHSEP/AQBELQ4igfkAAFE8GKcakAQA8PgajFS3AQAWgTZTjIQHAOk9OOdkGwAAj3xYsPsJAQDRJreHuBsEAJuRZnxZTAsAww+ZtlChBwB0IpKd6ysFABqGZHHtDgcAqcZw4HGoCAC+RkN0RH0AAB2oZKW2ggIAayN1+IDtBABQDEUdvvsGANv8Eoxy6wQAiYm8S5m1AQBgBkyoe0sHALiuzfF4VgcADPHWsAYyAgBdaPIAc+4DABh1HoRHeQoAfujaiHMsCwDoG5fTrRQEAPEOL4NQGAgAiPssanzUBwC31n2e5FUCALqe1WMhjAMARVgAKh+GAwDJrstMHuECABJ5KXYVOAEA4NbwjhTQAgD7h+eNKlIDANL5dF4F7gIAEwgx9jhABgCeTNNYz0gBAFp15Jp9LwcASvwPaR5xDwAVDVs1ooINALO2hejP3AgA6erUuv54CgAn8DR59pIEANQoVYHQ3gcAEmYaUWGEBQBEFd5QLuoFANvV66Ev/wMAZjmTjB9oAgA1FpMhBYQDAFKGMErxdAYAkEipiJy9AwDG6S/QTRAEAKVqCdsGTgkAI7DmiZwhCQDaoobUq3gKAB+VYJKyQAoAye9IWlsWCAAqQiQRXr8CAFauVmcUcwYAMOiHmtlKAQD9gLBlyuoBAPX6CrBjyAIAdmqEoHSkAAAyHpjvpZkAAOa/SzyuqAIALIMUrzRcBADs/5t9tpEFAF21GJ9xswkANtODjDFUBwCXl5G3F3wKAGCbCISwRQkAAANn+LSJBAD6m7SAHA0HACVGkX1+1QMAReVlIXLAAwBP4Bk4ueUFAPeofOwC3gMA75LrOi0QAgBGOgzVIowGAE6JhZOoLgQAjPNVv55fBwDLlqS7X58EABtXnB6MYgUAqyLoCLGYBQAaNimuj10FACh7qdHIrQgAdIYobBpqCADUz1uKEJoEABJmfY6MFwYAdQNxczTwAQCYYEphSToHAKa/3IZKYAUAtmQXfNTRAABRLmoxCBwAAEVQyUXbswIADDCNgU9jAQB04p/oiQkCABvs6oWLJwwAzeJ7ZVnvCABvh1hp0S8PAC8LJgWy6QoAWHAPlbkwDwB/zC06/XcHADJJEvuplAUA8BXKgI4fAABpMuw80RQHAGfK0NE+QAAAUsVOhzUtAwApufGNBPMBACObFzvXAAMAC32j5XvmBgADgzBUdL0FACp55xUhkwwAtzC5u7lXBAAmMhmLXY8GAFbUHo9OFgQAfwYjsX27BQDCTLIoldECAPMvMLhmrAQAUa392cgBBwAnN1tcs8EGAAo4B4CnMwEAvmLKxmf0AQAswV0qI8QCAIewE8AdVQcAzTuwEQxpAAAOj9Wm3EAHADxDeARXjAIAY6RzKFDYAQCc1N5+HmQHAHH1TNXt7AEAsMJWUj/AAgBOzs9SB+4AAOn7FoHdYAYA6/8PE2dRBQBclYW4gsYBAOpjqV/SYQEAfaRTe3UYBwAhLw+L4RkGAATsweTf+wUAkrseyJjXBQBr2duLRpkGADUZqWrmPQ0AGptZGvhFCACSQSG9qPcLABkzEqRNHQcAosTmxOGTCgDP/tr0Ri8HAKP33vqPlAIABLzz/c0eAQAl7f6P6cIDAAU5R5ohJQUA4RJRkksTBgDtBrQrlLsGAOLdwEXEcAAAo9fEItgRBAAy8EfEBbYFADnw5/DG/gkAfEcsabzOAwBeqRlqmHcIAA6Ld6Gq6gYAq8VM7y/xCgCJfMQgWYAFACyX+XFHkgEAQMCf372LAwCBspIAAPcBAOuK6tx2SgIAQMfA37IiBQBI4YA0GegHALlBQ6DZPwMAvCCKZ2PIAwBDilGyB+YFAAHPlqUcQwwABBSAfNoVCAC0EI9vmzwIABZAkyJpNAgAVuQ5MfMBCgAYGN9sjx0DABZLFEts+AEAnT7XuHWYAwCzp//Z8PsCAN3Mtsp6BgUAUZ0DCGt/AgCq3wCAL4AEACXFYqCSlgAAF1gHkeq6AQBgJIaoy5cDAOd5E8j7wwUAAi9eJbwbBABQhplW96MOAEF84NR/KQkAGx4sArRxBwCyWVnwkzABABjGLi81vQEAhuqIm3h1AAC5SOoXER0GAOZmBzKdMwIApy86UYbZBQAPG+GZOj8GAG2y1s8OigIAj43hNWg7BQBxmSGJoTEDAJxydZ06LwkAycRT6QANCQCJL28R3wMGAIjg4HbCPQMAmmT/GZasCQDGgE/7RW8GAKL+ue44zAMAH9twcmQHAQDIDXTq8RAHAN87uMZnEQMAaBBLUkI4AwBF/jCd030HANCgQSFDiQEAJcK4Tv6IAACL8EFjQxIGACUmLRrjSQMAbLGmf3oTCADbfneSroEOAFDc+MW/IgIAkI0XoypSCQCNiU6H20EFADMbhPuALQYAl/on8G4+AADoM5aePKAHAO/lCSO+bgQAOElhaVMvAACHBaKt5VYDAAL5a5/IGwEA28gZZHQ2AABDUlAP518EAH4UlcggSQoAXUyUYewHCQAewBfgUicHAHrpot23IgkAoVfb9hlmCQCMCwyWpnUAAEkb5MXh3QYAQaNtUT8uBACe56j9A2oBADkOOmLRKAQA/QijAURKBwAJgVW51G4AAGeIoPbxRgcAISNvXG9jBADTC9aSFdgBANXFhXuftg0A61BWFy16CQCdwb9tPswEAA6+czgdPgcA+Aob1falCwBfrA2mVocGACbsint1XQUAvYBf9D04AwCmlp+MP3gGAM2eeKc0AgIAUrJ4cbYNAgDaDizaozoHANNwHMBFkAcAWRAlFXuzAQD+z1MjaM0HAOD0rGhgzQUAzHR6/JoHCwCzZAtll4AFAJlOnKyrfwQAzbKyUwLvCwC2+ofYW6QBAHzBbQdIVwYAqBGqAIC5BQB0CQjJ7KEEAMC9Y4iMgwIAMFBGSs+wAwAtevWuuCIAAK0l6XcGrQIAekXXZ0EJBACCamCKyx0CALoxd776AA0AUDMRw1PMBwCBDQj+Zc8HAKEbAWbZxQMA9sb220DYBQDIn52MRgQAAIxreVSF2gUAJQCVcL64AwAJpqYtidUGADFKGQg9vAAAi+GfMA04BgAN7rgsPNcEALbAuq2CuAYAvkzd3atuAwAZrDJiJ6QDALh+RNtywQgAfqe3BcX4AwAQP3/5V6gGADrgf1bA/AwAGU6Cngx3CAD6hHCKLEMCAGipqDz3ewQAZygmdpFjAQDOEIBP3+gFAN4W6nwX/wEA/bW1RZrZAQDsmSRPZyMFABMmGCb6+AAAmIwEmHOPBQAAFdRPJp8DAM57Cf6rSgsAMjolA/w7DADyt5H+x5sCABZKhORhpwgAXsNyEmJcDgCc4ufbFzQFAPWUc4JzRQUA3VD2pu5lBQBJx410UCAEAImIRnMtcQEA3ZMxzviJAwDlfBe4JNQCAM1ANA36cwAAl57UDAI5AQDOGasAmC8CAJn9bprdnwoAPygoqZTGBwA6S+TuzfcGAMNcsgcyWgUAjFk4TRoXDADL+J4+ijYCAAus4giqVAQAAKePP5KQBAAvWKSeqnIDAGJH1mxBPwEAjEzJmapYBwBE/wAXAPYFAL0BjEhOaQcA1u5I6f3VAAC9dKVPIQgFAMMD0FO7FQoAwqgseZ4XCQChQMhq6aABALY6u+KTIwoAyoZMinWnCwBL/tY+FWkCAECY+K4jKgcAnGmZUr5SAAAWIxPv5aUDALr6xg6WLwIAdlCuk/YRAQCQypSqv+MDAIe4dpR5RQQAeUhGEglKAgB/3vgV/dkFAAtS1+4qTQQA5KfC0mUIBQBA6jhSW3AKAJY7XbJwbAwAuH6kfxi8CwB/cmNt0wgEAGJgpvb4+gUAa96oLYm7AgDm4sfw1GkHAPv4FFnzMgMADMKG6hUBBwCorSTaiG0BAN8qZiIGmAEAnVoZvOsBBQD7Bukc2FAEAD90rhyW2AQADrp9jMO9BgBjtOGntNMHAPOt4t5LhAgAqmOWJ63LBAB1UiCmobYDAM9t0JEn6AIAhzypynI9AgD0qmirt/AFAEVjutQl3gIAzR/XoCSQAQAaEF8RZV8BAAiXFGeQ6QQAr6XL0dgZAQAHIP7O+9cHAJSQwvPFXQwArnm1IFJFCwCJBh5jwXAIACCbDmPAawoAjM1tGc35BAABKGsmah4HAF3f4nOumgAAo7EZstgNBAAN3hdF+0YFAHV76DVUlwUAaDd7atiXAgAyY0wvWoMEAGBBQ18wcAAArlZOAd2DAQCgh0MI3cwHAIDMYGcYhAQAYTNTZVZDBwABuDZjaC8IADBD9kZUIg0ACxlIqDxZCwAXBCZtLEIGAJS7F0iQEgIA9VS43hmjBQB92mDg1KkHAAwd1g69KAQAp5qEXpoYAwBCslkfu6wGAAxjU0fv9gcAqS0qKUbzAQDWoo0wmHMCAFMkcApMDgkAM9d7o6/aBABhiT7ca58MAOXa7Nz//gEAw5JUlMJyBQAT1F5DKI0DAFgomRlPBgQAzUP1vg9oBwA8jdWD3aoBAMPo63pZaQIAvjDN1kXHBwDveN9Vd3wCAKN/kzNodwEAVRhEFlFABQC8BYxJhfkHAFBjvw9SFQ4Aadp0v+m5CABoESAIg/4MAELeJ2H3cwkAsGnNUyYPCwAX4QufiM4BAAkHUZRqbwMAtBYAckjyBwCRz+HRHoIBAB+jcMQubAcAhQzBqjjJAABBcXntZBsEAG1eGMGxvgEABw9gkFTtAQBHlhU/J/ECAMALp1XXiwgACOZciDqeBADWWhuIhWUJAF1P02h1wgMAX9x+mcGKAwARHuCKfPwBAOfoc1VNCQIA0kn1uzzKBQBDQcXsIPkEALaFrXLl2QUAO7FRpxe1BgDMgLFw088AABr00SV5NwUAoghgVlZOAwCe/svZ/C0CAI7gOxC0WQQA3SotP0uaBQDrjrvINNcHAAlKWb48OQIA3kyCd5j+CADZDA3D4NIDALtxZmiX9QMAmTm2fliqAAAZxpK1x+MAAIxEBWyRsgYAO5G6CtE0AwDbz4G1zUUAADaPOlXg4wUAsv8eBLMLBQAA/wfzA8MEAO1E2Q1YAwQAP2WSffeNDADpSbPjn4oDAOGvCoWJ6ggAaXCrUbEWDACFjLIX1jsCAGFafecu5wYA3k0X/3KpAQAPxnNjY+IDAKuyeI8b1gAAsDbB6e/XAADVCmSJHKsBAJcf9K6CXwUADe0X81dpBAB+J3SvopEBAOgORk9DKw4A+9P6wMaUAgAPTHuTaIMGAFuHECn4yQUARQXg2+c3CgAxFDzFS/cGAMLZu10OxAEAl1yunPvIBgDat+FcXIQEAMy1UOTg4gcAMLQBZ+11BQAmAKJ/4dMEAFNCjIj8kQcAwYoHmbrxAgAVEZtp+hoHAMNQO0ccPAIASB3iHWfnAwDooUdV+iYDANmvX8JNDg0AiI/H+zEHCAAdtlM5m28GALnMPCj0VQUA52AZ+2fdBwDU/q+hB0cBABwrnC4UIQAAgBj4SBjHAACGPCPY2UsEADBY/o5X6AYAtUFwbVsEBAAVfjTz1sQEAF0Zj5j83QQA4WWjPhf2BACIRa752kUOADpi22M31AcA+YgKUPmLCwDJH33Bz+wHAB6DggcoygQA1texfTO4BwD7lTjvbREFAEd+qtr9kwEAb4foNzzJAgD6g8UoGkMDAHnYi9pJkAQAHMF6QKi0BADU8OuZ+6YGAMYj5La1IgkA1d3x31AeCgC/dU4ydj0HAI5BlVRIiAUAXiz0qf02AQDrVQhWu8EGAEitE34SHwcA7FqQBLPGBQDHm4iOa3UDAIkxSpF2XwcA0b0Fo7HfBAApH4EF/7MDAC7ZPChi7QYA4VLsQxVdBgCNvhA1GCIAAGx6MEMBcQIAq/OLtI/YAwB6j8FO60kKAF4p/10RNgkAA9QfRHw4CQAULa1eOGYHAF4JBotPGQAAYjuC9niEAAAIc9OJhgEGAAa4F85xoAYA+IqXh9HDAwC6doLI4a8HAGityIHyHQUAXSSkvQZJBgDt8aomGxcDANFHirLYtw0AwDSeFO7CAgBT/Jpi9XYHAKlJ/FDq9AEAJEQzphTFBgCoTFaXkDEHACU1I7xOhAEA4e79Q0UdAgDSG/+qJ60BAAjPc0j9IQIAQWMVOk8gAgBkpGVAQTcFAIPP7TsMPAQAIKZucH5VBQAkuW9Zqo0EAICXTMhdHQYAnsJAMOh9BADnB2Wy3okJAJlH3Prm1AQAp+igf4OMDQDHnKVcZo4CANkNlBXHZQEAlRyhOl94AABphOPXmHsFAIStzG/ddgYAWJD8loVoAQCfYQPUam8GAO9yd6hZ1wQApL5zYW6FBwBXaiw/98QBAIQ0fPxucAYAbTbsOXiYBgAmf8+VH3MAALzkvI51rgsA9dq3rVkEBwC7oF8wvU8CAM+hdcyYCgQAM3UKIuGMBwCXweEQeiEGAGS/0YCslQcAsyu0kUnbAQByQ5lbYGkEAFiaXHHjMQYAj3LP78/pBwAhzkgoFv4FAPWxfF0thQEAD+Vcvg8NBgB1e+NG4qEFAJDV/wXuGg0A2Xc2BEy0CgAalpThTyEBAMvpqTmu4QAA9/kmtchDBQAd6WeASRkBABfJb0SdeAQAjrdOB6uHBABD44xeO9MBAEYb659BPgEApOZdVh9yAgCau/LuUgwGABFtrnzCxQsABG6VkZRqCwClHRPJuiQJAFwrIN73tgsAZZuNJHcNBwDxi/07vIkFAGtBo2o++QYASK7B1qPABABqWAsmh1UFAPzMEsPJCwEAW6DCPkvoAgBRFTzwop0GAHumYUYXOgIAOPKJorwJAgBvlzq9VTcGALes8ZcYEAcAuAd7tyzYCwD0aXc9CIQGAAfOLUcoKw0AUXxzUTd2AgBTCNEqPqAHAKs2rcbcEwIA1r3VQOKmAQDf/vj8T8IHABa8SBzM2AAAqRm0btMCBABSoBSM9s4HADnRwlsl8QAAahgx1OdzAwAWrafYLQwHAAB+7bh9lgQAOlIv0O5aCQC7lNCRlRQGAAZwwQTycgYAU2qBE4YrCwAO7G+fUJQBAKysMcrYKAUA+rm4c22CBwCz+eCZy0oCAEg5Nsb64AIAZM1I5L73BwA8D9oQD+EEAOkgq7lskwMA0GzqT/ygBwCkNccVkhcEACHNayi5Mw4AlJzburPKDgD5vd9+OE4HANkPisUTQwkAGyRiVqgfCwAq7dzX55QAAI4RjnP6aAAAK+5fCmQbBADUGfCdcLsGAJnNMEo0AAcA9CI2LkJsAgDwtQVqBvMAAKaABI9E4gQAlfDb4M1EAgBSmSoxsksCAFhc+PUqDAgAPojyTJ9gCAASyqG1bugGANHM76JEiw4AtP6fr9LRCADDZ94yF+0AADUWKWnDCAMAUNLySPM+AwC7oaFeRwQAAIjhcejj/gAA3x5iMqGKAgA7Na9MJCsEAIrgwkwGawYA070MAiC7BgAxhXF5zWoBAK22h3jFxgkAKlnXH/KrDQB5hlMS1AsFAFExJ3ELgAsAYIGxNO1kAQA9HZstr3IHAFtOi0SG1AYAqBiN3VjOAgCLPFBnn4QBAAKTa+/gIwEAmuYvGUzZBgAPaaIiUkcFALO4hp14kwYA3Gn7vcP1AQA/B2H8oI0HAIE6DGjxgAcAU9T8PF2jCgD33cfN5QUIACOseICI7gYAOGsxS6pUCABqxivlKF0BAH7LUQMeDgMAjB+xdC8KAwAD3tcMEp0DALFWsu5d0gIAuHwmGY1GAAD5+7Wp3IwDAOKhLFywuwEAM5WOdRWwAwDat2oKYTQBABX10XfnZQoApDkeTPXxCABFJlKVG/ACAG3endvY/QQAzJe6jIdUBgD+sPaNx44DACJqo76uPAEAal9O5cbrBQC4Dj2QBCgDAA2yotsvEAIAoeZcBQXkBgDTMqU1SgIFAJ3y2lSQ9gEA1Yt6DR1dAQDLnrJdcq0AAIVvBZsMvAcA2P/6v/4cBQBJ9U3pu0oMACAx49e77AcAmSMw9XX2BABXJE6DsWcCAIi7eMMZrgYAEtXZXntFBwD7BT14DSgDAAMat//8rgQAHhcVBDY2BQBleAcJMzECALyvNENEUQIA6FY3hcOwAgCGKiq3y7wAAJYS/lBMXg0ADMPvE91fCADt5YDDxsAJAKdi++Md4QMA8wiR1o9nBgDIqbHqL5YGAAujuY+irAYAmJ8byrdtBQDdGHBJWJ8DAGudtQpPAgQAwmNoYzH6BgCwQn6m5QoBADHaH/C7egIAvE/muaeAAwDU6gghLtQCAIB1Uw8NewkALYTJwGNiCQCjOUV+gqsEADrXQ9sNNwYAI7R5Or8gDACb0t+UFRMFAP5SjeknpgMAYVaFQUAVAQCEg5/QdZEBAC2Ni2CydgYARytbHGW6AAAnEHBjI4YFANvGGcLWxAAA3liG/z3wAADPwKn/0kUHAFdO0yFX3wYABgx6di/zBAAgbsfqq9UJAOPhBOHpHAwA28FUvhVuCAC9yMkrHloCAOo3sPPIBAEAmGypb1cFBABvh+OIaugCAM9guc4jrgEASpkyGYddAgBuC1Y71rkGAHLUyBQo3wIA7aQK4r77AADseBKG7Y0FAJXJwraoWwMAv4Uxi6XeCQC9uyPNVbQEAPiDSMAZ7AUA1TG1lqaLCABcxWbykzcHAAI7yamIuQAA2yUjow6bAABefMFxrnwDAF9Ihd45/wIAesXvw+4+BQD9LgLpn/oCAFSBEyzHmQYA+B+9HnUqBwDPR0k7YyABAPcPEklHMQUAV9DA982vBQDtjXgb56kHAIgMO49w7wUAk7M8vjN0CABCAGGReJgEAHIBXX+dnQcAxJ47AZPCAwDKyjlfuMIAAFlNm6kwXQMA9JfpXMBEAQDvfzSKC5YEAPd0XfER2gEArf7AGaxPBQBtr+ftc9gCAG75XU7hAgoAS7U+vALqAgBkNYiydYgDAN3pOlGMKQkA/xWgGDZUCAAJNDdDZDECAK8iO1CV3gUA3+LqGyCZBgB6c/9JWNsDAPoHR2Vz5wIAwSNMl/S9AgC9YdLIubMEACi8qbLoagIAUVwWEIIGAwB50GIzRLEEALicUhzpVAQAz3K/xphMCgCZ2MOUZUgIADv616MTrgcAZq+OQThwCQB6H262x7cEAJjZ74WhvgQA+FUQcbz6BAA4/jZ4n/sBAKYtdUb0ggUA5EwyINN7AQDGmHgRiRQFAAtBoJJNaAEAp8V4D9nkBgAo2rzEocIAADJpvWlIgQQAuF2kkcO3BwBBtjWsFnMFAGoJ6R3jQQYATTEKs6mmDQBHBB9v0McFAEk6C/hw2wcAeJrIPkrLBgB9OYGt6DsEAGRvHL1YxQcAPUaW0yQVBAAdGp5Ea1gBAIrtSpB+8QIAjjwdhtLhBwC6r6BcSkAAAL5vQSobngwAVmwxC2ocDQDbG9eepXUNAB3sHxoCTAcAjn9uUSeVCwDWQ6cKB0AHAIMR3ctkawEAQ+sye0s/AgCzNYKlqxkDANmt3L+VYwQAnJpdGi3bBwAvQoULIJoHABbdcaq/VQMAqnhf6ncLAAAtgp6ieWUHAN80tFITtQQAZyYc0HsyCQCgyGA71zQEALpDlKja4AsAdqKyS1EsCAAXKsBJfo4GALbobzSVVwQARjWPbDCJAAD2iC9rn9gGAFvgyU04OgQARbbxi9rVAwAJbWqp1t4HAE0v7k9JwwYA1GuLnJgsAABIFZYgCRYBALpNmzYWVggARm+shqvsDACxANeFAMYLAOn8DeE+IQgAbR5J1zf2CgCqz9opaRYFAIn2MWuCkAEAfUppZ1X1BAAi5bH39AUHAJhWvCXhUQMAvnv2GkabBACWOixxFVkHAA0MWO9nmgYA/M9w7zhNBQDifG7QgvEHAA91IY5ySwUAKAEbl5CaBgCjY6nyQBoNAL6mEqzpCwkAxEEyBMxKDADsaAGrZI4EAE9vqLi9ogIAKWktazs0BwCj6YyqBNgBAOlDw8hKfQYAd1d6T7trBQCPI3xiMJICAPvXLBIarQUAZONQbqXeAADXKjHI0VYFAA7oG7FWZwgAPbB7fhRiDADfvz50GWUKALQqaFn8ggcAx8iM46uXCACCOY0M40AHAP2CRn+0wgcAHNzHuJHNBQCD5fmQp38HACTY0cbGRgcApC2lfofJAQCJYaiDe7MCAKUNMUmvMwcA+wQcFoFeAgDovjRK4XcFACvXTb2+zgYAnzJC5MFACwA+qdH/RyMDAOC7LCWJSgEACbCPSzAFBwAKO6dhrGgCABy+vjTyBgIA6OvLpwO0BQA1QZ/wYKEHAHj9lu6nDwYAxm4pTTUdBQDHFjum9csHABQMz7ML9QIAWsbKhbP+AQA1FsrgmBMCAO5Vt7T5qggA8kSutZFrAgDIsXqNgN4GALAwVWdppwYA95hOKPu7CQDzMys4igUFAD6RFhipdQEA6Ipruc32BADSgdrJR3MBACNa2dk+qgUAYWXZx+l3BwCszAbwWI4CAEmsLLu7QQUA7EyZgjLmAwCV6OUUfqAEAJukd8TNWAsAgOQC/ojMCwBq4/S3qiEHAFOZRsmMQAgA+UrYrvcKBQCZ+Q2YyxIEANwp7tiN5wUAXVeM9t9xAQBJ7/bSXQECABPTkcO68AMA5Vv2FQHeBwDJTTYhLCQEAJhgpmRbtwYAhcACATwDAAC9rmsxGpIBAIvB89marQoA6pozOBbsBQA7qFllO3AFABLWBU2f+gsAKwbK3kmwBwD8cLjffi8CACixd9buaQUAr6Ww3DcJAwAb6nicA1gHADonHvSNRQYAg0RENXrjAwCZe9K3/WEGAOQh1h12FwMAiWECMDwyBwBQKbzMPQkGAEsDhGC+7gYAe40K9wHPBgAKZ8ZUGrQIANpVu5lLyAYAR7aYDBjjBgBtcOCFhZoDAP5jJud8FgMAl0Lb7BQ9BgC4cPncIb4EAHqChKAefQUAcbAooee2AgDPXXURdbIFAGUFk8KEhQAAWUFv2nuMBgB72d2Z6WMDALOuS+LcSAAA4wXslVe3AgDJbdrFpL8LAB03nmXIqgkAmm+8efkxCgDEH+41wUMAANXyGZkcoQIAzbpdwkwzBgDaALQX2pUCAKCThrfpjgQAxvMqzEveAQCG66MRxB8GAMAuwZrRPgUA4AS4xtsJAgCSh7Cpv3kAADJC1aKA7QkAeF4qx/4OBwAtgirUUSEEAOgx1rbrtQkABUdZsU/vCQD0DTDaUToAAHIcViu1ZwQAkOUQApLVBACFlniedsoAABdIaH/HOAAA7HsWW+ZeBgCpULgZ2lIAAClkZWWGQAAATJpvWTmrBwC/oKSS7nUFAO7XpApFvAYAqAs7d6b0DABHvA4LGyQGABWTHU+cDQwA9ILj56EACgDPLxiKkIAAAJi6txMpUwAAw4XDeM/cAwCpq17dAoAGAD/NEnFOPQQAxTr56me5BQAxCljKrGADAGLyxtVfxgEAq+zCFX8cBwDkUSal7FAAAOpo5mB2OQwA9PKSVqfCBwDvZmx+nrILAJnavFimKwcAGhP6CRwVBgCcDD9F3hoDAGh4cwfu3wMAEdSn9+wRBgD2ZL1sfmMCAI/FIWzusAQAll3w/Q1cBQBeR8+dVgUEALuYdCdcXAAAicNd2YiFAQDwAKhP8v4BAHNrlzD1rwoAWYTASFrYCADfQjaW65YHACa2xFDuCwYAQINs/gWACgCWMaca+1MGAPoGg+z6BwYAVFI+yF7oBAD9hAWQVp8AAIb8kpLURAUAiIZSNJ+6BwBdLbQPooQCAP5vcNksZQMAs+bdrXv9BgAW8zApRy4HABR2KtM19gsA/QDerOzLCAA1qepBEUEDAJTL80IeHAIABv4A8Of+CQBPCIGXjCAFANIk3KFoZAEAqEDFCni/BwABU9fOfqYBADpzwujSqQUA5ffbA9oFAwDKrreZhiIBAMlrk7IjKgEA6eZqpb2hAgBA4B4FlA8AAECXrwe7kwcA/frU7LbnCQBC+2AVeywIALZfzDRnKQoAP90l/X97DACyMNPDI2sFAKbRYOMIdgMALnLI8+AKAQA3thi22YYAAKu+6Md5fQAAEt0IvJz7AwD/cFPYPVwHAKwZKP4GfwQA7RWSqwbbBQBk6jUKUsMBAEbAayFAbwgAtNkPm1eiCwCL7H5AJhwHAAtPtUraKgcAEm22w1CHCwBKo8u8plMCABpwMwQHJwQADof5WI4LAgDMANthyDcDAO7QdVfQwwEAGuUilEDxBgAlLc6+a4UHABwDL6eAMwEAuvOngBA+BAAEM30sHmIAAPPw27CWFwYA9dYynC88DwC9flPRjqoGAPQ4GMmSTgcAAhDKieXYBQCNg1mCzGAAAPOVW/PTOAAAI6lDwnhgBQCyGySTMt4CADq9l2B9AAAAS6lCCJUdBwAX2MflEWsEAA1Py76LRwUAXRwKSwXDBwDLwYN3PVgBAMconcwERwMAAPKxmOXeAwCebXSYHG4BAN+vlXALBQQAVTzoZICVBADheqJd76IGAJ2dLuCsigIA6PBl6VkkAAAzCRXTZLgHANge6PKlUgIADehmUCaUAAClYY2RD6YAAN4P8/dLRAAABjztqQ3EAQA7hL1wwXkAAFbQ1cBQzQ4AuXnnamC3BQCh3WsivQ8HAPkfOVMeZgUAuBdzDYx2BgD/b/pk5OwGAKBgpLxAzAMADI37CqnjBgAoEqG8GoAFAJ+sNF7A3gYAs8FV8eUlBgCWMnJvL/MEAM7vBQGYrAUANu5eFmF6AQDV3E3hRRQFAEKkviurRwEAJjEl8kDyCQCITjGe3sMIAF6k/KSlHgoA/OSGAJkuCQBRSRQ7SysAAOpqlneJaAUA/Z85bheOAQCLk7ReXOQCACk5HvOGMQEALrvff7OWBAAhPl+dQ8IDAE1qfv5gbgEAHWKbiO/XBADp0wU/LnsHAJGw3RKcYwgAsnrNkAQYDgB7RpeCkfMDAKyBF75oRQcAleBSURl6CADexC6cxakHAC1leZ7w6QcAhi3yIuSjBgCLbIM7jq4CADKtx195OwYAyF+eOAKPBgAGdYe88VkAAOwMQQ6ZBAUA4q7+0NebAADwMtCD/ugDACnR7+iNTAgADSHmBnzGCQBpFH+PN4MBAInSrs5SQwYAWGKaiWAtCgCUonAFuRUDAPElqQjhDAYACclTEvbvBgCwcC0O7wMAAMT6l7ejWwcAltHNcMDbAQBHTFOxj20BACr6g4FJAAUAdd4jxFkvBwB5d7gHTZAAALlA+UhmLQIAhj6HoaWXCQC7VBrE5AcKAM/WSzsLNgUAcq/rrAokBgCckbrd1B8GAJlWtZHp2AcAbMc8RzEbBgDWMeYxlgMHAN3B+0MhPgQAoJWiW5x0BAAGX0v6RnkDAPFRWqvFJAcA89OdeDNWBgBA2zjy2msFAJ87ncFs0wgAYSLXcETsBgCuqRhwPYUGAOvIwk0+qgMA5eEHFaM6CADrMzX147kCAMUGqCfXrQIAoxXOyFVpBQAOKQoHT4wBAEE32IZK0gEAH87U/0h2BACdnoORlQoGAKsXgfPVJAQADsESacQsBAC0rskdJjsEAFETlWyLPQkAKWOPfgHABADE+VOeVT4FAOpuiEYBsgwAPykkXk0rCAC7ebuIGR4DAKu8s0YvuAcAQXuCzqj3AAAwcRcWWOEFAHay9VwFJgMA8o3RKMtVAQCUFqGcDcMAABkxqycOCQIAtkl6TmIIAgDT5ZqAbHoCAEFpPcQKJwQApVlW2UztAgD5KHWzDVwPADOSLP28zAIAwtgDNlAhCgCIsQ0fzesGAHQRfUvrTAcAXE/faGHVBwCK0W8Xeb8AAAr2TxdnywIA0OELOfnNBgA9K36cUY4AAIEIpdLDUwIAPTOOREEbAgAPiXNL37EHAIz1+AcYIgYA5Ys6gZL6AwByVY3DmNoGAI9GVFXZHggALTVdJJiGBgAkorKz4PICAJIcLKJqxQAAeLLxOez9BQAG8cf1CskEAMWPZfLOHwYAehgYKoVdAQB2+5q123ACAKuSzwsS2wcAh0BxXaLnAADw2nPE9GwEAC2BSfGnbgQAJ4QKaSUHDwD6efDpOqcIACrGYUSS3QIAzNhQrloGCQD55cSe7SUFAExoYAbSIgAAaHs5cCuXBwBl+dNYOaAHALVO0byHkwIAVw0g3yVFBACFQ+lM+dcCALfscMEADQYA8NjzAwWLAwDO8WSOGZoGAO3Kxdw0RAkAH3xmn5DHCgB1tR+dgxoGAHa7ygA48gwAfia9lyZbAgC8eBrZ4LICAAzyzBIKmQMAIiYf4cJBAQAgM6X6zt8AADpJkmqeNgcAZGiYE/s/BwCsE/e4KygDAO+X8njtnAQA7x1mJ3BpBgDkVNuDBkIBANBazMFvuwYAnWaR1cgyDQAybKhNea8JANIkbdjp4AgABx0WtIMeAwCX0Z0kHr0AAI9WIBjLCwAA1DCIcbHqAgDml2mB/ZYDAIpQv75jCwYATysGnhLHAAD9EltBJuUBAD2SJ/2gYQQAt6Vw9q2LAQBQ1WLr8VwFAD+M9X3jtQ4ADcaGOfO8CwDm6lyDuE8MAKNxjsHemQgAnyumum+lCQBYPcJlEBABAA+LM5ASqgUAIXQunn4VAwCJ1BcgceoAAIlwRVamaQYA7MmdXFBrBgCHUuOG73QHAF6VwETZ0QQAICvXOUwuBQBYnHk2SDwBAIDQi11q+wQAm1gISeOKDQASr3uXTZUDANxBdFnqEwQAW47ch9wLBQC54bNaRl0CAEco7Cf++AAABk/w2+bWAgB2Mhv8jAMDAHtjOsmAbwYAEeHfboM3BQANLHs1Ar4CAPjUyFju3AYAkmEdWDLXAgD9JUdEVt0BAIfIuggA5gcAUhh8OFw9CgCnM/XxXZ4HAM/wxfH55goALzr2UKSjCwB9EmIz+H8EAPSxgq85jgAAq33yLjKIBACkoaI4N5cBAPcZIpFF5gAAJ0Y52DEvBwDxAKKU0nsAAMZ04gC+ZQYAiza28eg9BACaOjnZyBgDAIXTHaspngYArGvHs4UGAwBZSPI3z2UFAPn+jsIqew0AT1kyHKQJDQAZ/v8qA10EAE7ebJvkLwEA8XwyvGMWAgDd8WlMXooBANWhecbHJAIA6SX5ptxuAAC4d+Zjg4wGAM/75CX6DAYATkAJdsHEAQARijIC/1sAAOQSxQ3doAkAD81fv5QICQA2nD8BSSkFAMc1R7oP9QkAGeDefCd2BQAL4MojcBMCAMYm65k1WgEAPCtRIXJoAADpJAg6y1MCAKSiP8y4gAcAXzBPI7yKAwDeA8G7gKIHAP5daTaomAMAGopSQa/QAwAbJyaHQf8FAC2VthPoRwsAujwcwmRoBwCodM3bSeAJAJt0kw/WtAUADArKuE2dCgCd24kXDAgGADGnHu98vgQAgICddg30AgADpkRMfV8DAJZawj2gBgEA0FMzM68KBQA1uzxhmrUEAHaa4cDfIwIAZMWyKx59BwDLUhClOKsEAInA3V/v0QcA2dq56+q+BwD7rKAL01gIAI+uteqSzQUA0k6waxwECwCT1WhnJSsEAE97QlmE6AIAAQdjdjgrAADl6gXUeEgDAIoI3BrdnAIASOFW2fnyAgD+wWWt5rMGAF2et3IJsAUAr11MI409BQBJQIHWuwQBAFDxf9Zfmg0AKjXQ6pipCwCZr6RfyYMIAG4mAfzb+g4AcbAPovIECgBn7fFoMf0AAD5KeOcNuwEAdwSyeMtLAwCCIS5uoqQAAKeScMWMvgUAebDrMD07BAACGcalrFcDAFUk1sVwtQUAxxgenrIPAwCRJ3yxD1cCAEckuAtVqQYAJSMaCvIRBQDumyPXJJMKAMMWdcM8NAsAF+Ad+cVBCgB1FbYsfzYCAN+HTcCawwYAveXXi5XUBgAyFYpj9GYFADAwpV623AMAqmzeQCkXAAAbRWcuWwQGALP8PkYHbAUAkW7+a4tyAADf/NXtIIQAALsQ9AROwwgAaqDQwO1EAwBtTdiGVOQOAPRjOMsuTgwAtx0yT2VNCABK+mKDqyAHAL/ZzUdDnAIAY4RfrZjnAAD+C8uL8f4EAHbB+z6l2QAA1bW93RbBBQDPq6W7tNEGAHpTpUiK0gQAmQsEW45rBQCRiWHypKcEAEsqN6+RsgsAl0T+KDAOBgAJak/KeyYKAEKyQsLuGQcADj4iFGOpBACVX7FfAhgHAJT+cYNrjQYAfNn3SESAAwCAQnj+ZiQEADHdzcRQGwEA1v+kCEQnAADdNNuugtMHAF04zsnPCgQAHlukmbsoBgC85tzkvPQEAG8LncRuYQIAHOZihF35CQDFWZGbPq0JAPhNoHWkmwcAlRVW7iwEAwCEJSTiWs4HAOPUU7Fe0gIAyamb0POoAwCO6wQNafMAAMBxS9HNPwcAQaybRHlwBgBPSCFGnLcFAI1rFfJpEAYArxA7VybrAADOqclA54kDABWsDlf2eAUANzmcM/JEBgAsbJW3R24GANBVH/4ySAsAYmJdXkJcCgDOudw0rrMEAJ+sFRppfAQADEBdbuAYAwCxPvjZIsQDAKZllDdFFQYAbt7X8aYGBgDnB2HEwPEEANjl+9yxKQIAJxN7CsasAwCEVJEImlMGAAZKuxTU2wQAuNvxSQiTDwDvymakxSkDAJvrT1QkyAYAmwHvIFP2CABz99LDdB8CADq9CI24JAAAUUEFz3jmBgB8dC4nMTYEANFcrEpeHAEAxuD9yrHRBgCQOjBqx2IEAJv/PGlOygMA/YZX1CyVAwAww957vMoEAInSeD+PeAcAEfizCSiUDQCbwvh3MpcFAGf+xTv5EAgAsaxlgUnuBwAuCpwIJJYGAHME58hfBwAAEyMdq4Q+AQA7lfbtC8ECAMghAz+5OQYAw6ERkeMIBQB6L5EOEpACAEOurGT0ywEAV2FX6XNTAQBgW8iT9O0AAABBdoTSxAcA7KwGv/7+BwAAQYJ6+5oDAGX950eOtAkA+R1NxQBMCABoWptZWIEEANnVQbx1/QEAPF2pH/zZAgARug7yJ9oHANQZMC65AwQA+FxGi4EvAgC4Cf8dkEIDAM2Dxl1ZHwMAgtZfdFd6AwAXJqsSu1UDABhzjFrH2gEAYDRC1Xm2CwANQLa3/LgGAJ1fvoM3xwYAKgWOr45RBwD0u5N0zGQGAON0GHaUPQMAE/aWF54XAAB9huI1BYkBAOyCIRO4+QAAMmx/G8RZAACRFFMGh54HAIK1PGRHxwYA5JTUCgziAgB1sbtxOHwEALBmUMhQXQYAfB82U3QWBgASs4uBo2sIACF1qpvyrwYASI3OAuqPAABIT+xxl1MEACjKrYsxuQcAxRbgrxkPBwAjjWCxe+4EAGlkV7iJCwAA0OreaHbdBQBJcKQLbQkEABSRIZdZJwYAruZnitqbAgBd93SagnMEAMkCOa06UwkAeuQRa+DdCQB2C5PRvoQHAGfIuZIKyAkATE7UtGjGBgAYxHlGddoCAFoQvjFMFgMAX++YK6wfAQBWknevGloDADyDxISGBwIADIJ4eiHPAABp59LnJFAGACqo3e+1OwIAxtMyttSfAQCk+FRgGkEHALR1sRg95QIA80ogVHI+CwDExKHV17wLAA5d9irCxwQAw1gkh5rsAQBtyJ25Mp0FAKypIl4HrAYAcTMRIJILAwBuljim2X8CABO4T1c2wQcAm1CiANSkBgAcl1YQeUEAAFwHbobVVQYA+E3m8yswAgDWfFyK2K0DAEYwOVnUmAoAt5A9y/4LAwDW+D3quNkDAHkVUZYOkAMAakAaE6EbBgDy3DW2cFcBAHGV94PNngUAvX8LHEbbAgBfNIGpQjoHAHnIzJ+SSQIAKZCVFvGgAAB6NLHXT5cFAK3tCBzM4AEAEx+t+L1zBgCOvcsQA2IFANaF4nf0tQYAyGwy7JHtDAD8owN1U9YOANSIOXbTJgYAzlg2b4TsBwBD1jRJQ5MBAFGqXkSi1AAA4G/ninDQBwDhx8O2R5gDANnZpKJ2dgMAxy6iHT+PBgBrc6I5gO0GAHU8TOB+YgIA0edHppDqBgC5mTNyr9oGAI+Oray/BAMAB4sQfZECBQAP3aZsF0MIAIMdLI8V1QUAO+tYnkS1CgBHvj3rYnUCAOcLF7TXkQIA4ajfZ8rRBQCimPJhgKgCAH1icZ5OMAEA/pzcatIUAAATb6EbafEHAKxu8CgY5wUA/P/wB+1JAwDdwtfijUYEALsHY/jG2AoAcgmFoWsoDgDTRISw3OkFALJiM1RqqQkARjLmJ2TaDQCeRhmUXjUDADeK6rh7hAEAcZvPiGX+AQAia9vSybEGAEu0/8bnzAYAyiKs3ojGBABSA//DdfcGALsZ5D5gZQUARhzGVkRUBgDyef6rKY8FAPbNDnG/ZAoAaoknhcUIBwCUM8Xm6iwMAGkr6CEbOAQAtIVBcpOvBgBoPueNq88GACG91M7v5gMAvg1QCWYFAADfha0keBsHAEF/SpxidwUAiKjGCUUCAABEZi6xamkCANiAS3+izAAAnhEb8cHHAADsyrBb8gEHABPBvnzZ9gAAo5N8+5fODAAaKBFagzkJAFWR2nqQKAcAVQkFvKUgBwDtbGHk+LAAAHW4D7XE0wEAmAHcc5byAgD6D4PxsPQFAEDc+yvJ4AIANVqAm0MJBwCHgX9VSOwGACw6oRtNigAArvkLijR2AADvRLHLuekAANu+sV3VmwYAvTH3R07hBgCsDidHXqMJAI3feFQibwYA08+RQdRmCwCtIFf7j9QCAHffoSF/ewUARQa6/w5VBQAxqZhAauwFADfzs04QIQIAFIy88kMXBADHc4etsJYHAJtou1zunwIANIcXXGYiAQCTxWtOehYEANuPzvhlJgYAV5jFGhCdCgD7n6W7O9kEABc/N5d4ewkA7LcMNzNLCwAAJ/Z2KJ0DAIdsHc3OAQAAdXZ0ERrwBwCQgaGlDTUCAFIl4reLkwcAzNaBhu6RBQC4eeq0sJ0DAEIIOA8iAgIArOBCunbyAgDm3+LGbxcBAKUOd0mJ4gAAcnsUiJ5VBQAw72NuHl4LAG7/p5oQWwMAkCZP5aP2CQCbYZxb0GwHAJUWkLBUlgYAJ3+3EDelBwB1gdKnHpoHANV3xqTDjwAA6jQH05nBBAAUzJrLIsYGABYCA1UKZgUA+xGfGfFoAACQaxHQ+vIEACW2O7cd2QwAxBKBU4JfDQDdFZgnWtgGAPmczbC3QAcATpTylRlFCwBUTq6UQbIGAJeI7f0KIwIAcVB9YRI0AgCbljUP09UDAO9ySUpIRQQAfH3qn9D8AgAq0p5rEpYCALIFKgFxoQQAI1VNx5LbAQCJQmDKiQsBAFvwRVq+QQkApq7si7OtBQC78kHbRv0LADjOtbuI1A4A0/CeHS19CQCcKBiXSUcBAKvH5GeKpAAA469LVLwPAwCK5V8xAccAAHV7V42HCwIAaj4/BxivAgD+JA1C6joDAJT/9IsAmAIAHpbbcZFTAwBcxjz2FCIHALYpO/S5twUAs6PuMepJCQAIFlgTd74EAJheOWB52AoAU6FVyEryCQCTpgdTQH8DAJy28mzm5QIAU5yuZkLYBQC5U+h96+QFABwXWIz0/QUAqgWVjjIIBgCaxB2EgiECAAcjHYmW7AMAAy7y/2PzAgA5ruI5pwsAACa7iOr1JgQAyHV/55IwAwDnGdhAOaUBABOGgU8uEwkAjFF93pciBwDWkIdc3pgGACXrW1S4aAIA3/6Wi2TSBgB8sB2tiHkEANd65qODMgAAObkMvscdBAAECRBmbLEBAG3GyyBMogAAgYbk7+miBABxYoSWEl4AAFBFLCTIuwcAtzU7EAaaDQAyIPNKfiMHAHpTsxpCJgcAjCU4XfKMBwBaSZwts+4CAFCXL3clngcAI787g0fXBgBJ19UW2M0GAJg2wckAnAMAaJ1IMY5rBgC14hB+hXMFAHIUqhboOwEA+Eut02QZBAD/s3YgtQYAAC0IzrkWfgsAuD6FVy+ICQDEH9CsntIHABXntVlq5woA9qlhlS7eBwAceJWd4c8AADxFHGLMEgMAfAfa5qxFAQC46ZzvK5EAAHa8QzR+1QQAy16ltvTUAADOO3O7sOsHAEkFIAVqugcAaSDi5O32BAACpvEKqbIGAArYslsk8wsA/G7zIPflCABswGDPzLkLACV58yPjhAgAwXaCLIFlBACXHuaa/PQDACQt+usHvAMAoNRctUS3AwDzIVeyUyUHANMSnU6P/QUA2WIQKrK+AwCoyYI7BqcGAO2XwV2jpQAA7z2lBgzIAwAWy7HCMlsAAIKB1XospAwA/p55fmbIBQChUMh0Xi4IAJmGTmHb8AMAMGeFpHEXCwD9qE3SzF4AABh58P27gAUAajyHhjXnBwA++Xff7UwHAHG0N2pVtQMAgtRN4STFAABWxpZ0RYMCAEXNts9rrQAAFCSw6NF1AwAzpyedB/wEAA3FhgxEiwwAhTvKnJI5CQAu30zk8vgIALGmexEyhA4AO64rDBdBAgB/L7+JsDgBADnqNP1boAQA9V6STJEDAgA8TuD/f0kHAJiv7HxWJAEAtHPECoarAQD/p4Z8IsAFAHdEwr8SGwcAdTCoc6UGAABwyGYpYfgDAACNBDb6/AgAgrO7M3FuBgB2VqSoQksGAM+Fmk9u6gwAoHjo7ldvCgDeDSp4yQwCALOqcDBOXQYANndUMY68BwCYLUOxv54AADaXZ3eqBAUAse+HVtUsAwCVYS9ej0QEAEUDRp2RaAUAJxqt4MI0AACj29lDGQQEAMqqbKJDdwEAZMn5VpGMBADQmh6NJ+8HAAG9p47lDAgADIApFJMtCQCWzOtDuu4AAHj4lVPdhAMActI1GjPfAQAO90r97AcCAENolx0KQgEAT1k305l3BgAYYI9URxYAAEXxeFXOfwUAcSoUDCIJAACaNRQj+bQBALFmmKQwMAcAeSYL6StECgDOfZTY03sHACggVcFV+wkAoflWHRn/BQBRCRWJnRAEAMtHLS29JQIA6jvngMB8BQDLH3J1ENcGADLxp3K1OQIAaJAtrDPUBgAzcKQw+SsHAK0OovSsTwYAKkC5ovdlAwDzWKcmxSAAAHbMQvBZ7wkAJd12ScKxAwByYrFcZh0LAFbFcORWhgoAK2Cl4M9SDAC829ie+DQAAPOOjZSPOwcAq8oj08GGBwBRbiap1DsEABNTYcSsKgAA33d4ZKD3AADU8JMPzOEEAJAR7yZH7AcA+BL1i9W9AwC4BLPXt88EABLviZfCmQYAULwh4+o7BgA1u61AwyULAPUr5KHhYgUA0zTEy9SxBQD+dZu4bD0EAFYOkFuNMwMAUxpTfTKNAwCfG9VhXLIBAHWQsyJGSwEAJp8KzBUmAwDftpy5EXcFADg86RScpgUAmcWkgInoBgCShSVxj/kCAO6mVE9ErgoAwcX7ejkVBgD7+PODdw0OALmGxF9nqgoAE3aeLgbYCQBWng+1TKcEAJIBZMLRMQUA0n9snT3AAADBEGYVzXwFAGqAnSSupgMAWnyQqYXaAgCvTOwhN7IGAKI6aKTT0gQA7/0Oh8b5BwAl74rOuJgCAN5lIQrqcgoAbtA+73mBBgAerP7AueIMALpjGwsp7gsAfDqAcWK6BgCyDPfvU3kCAFLFDq4iTwUAJCcuqT2fAgAYvSIMykICAM7VBISKSwMANTNpg7XsBgBNuN+/duwDAE+gVs+VyAIAUk3VSVE1BgDhZdS9Yh0HAPVe97HatQUApbm+DNbiCQBW/l0XwicFAB/1jyuKng0AsWISYjPDAQCA33jTKMwDAKaMlvRBIQcADW3ba2kHBAD7/C+ycdIFAHIxfzFfTQcAgcrZZ1TlBwAN9YYxZaUGAPEt5uyIsQYAcUmENm3GBACdflTEvK4EAP21VHOejQAAaMFtC3VrAgDJrAEeiGIBAKUBHfNtlgcAHZrcnb1zCQDJAW0nGwcAAF4CjpHYsAAA6+Kep+5bBwC4TQmEKckDANujlb+P2AUA33JY/h4PAABqJRgjh9oFAGBZY4HrnAUAZMeTdvOMAQDqGTvRHG4AAFMDW55irwsA5OiIoPEECgAtqO6c/A4JAEqjLzyGiQ0ANtiooabzBwAjbxZvUa0AABrIV231YwIAyjhGOCI0AQBQCq/xHzMBABZuUgMGCAMAC4A9XTlEBgD83r49ILkCAFWjVuaMsQQALBi8ZjQ/AAAT5dLeDw0DAD1HuGgelwwAlfN5l8wsBQDIVYKuBOkLADiT80au7AQAWBw1hFBhDACzMxLyGk0BAAucs4kZ3gEAnm9v3GkmBQDHP4yyNDQEAJnAAkIhqQAALqC5rsAZAACS15VpwKIBAEQcV7HLZAYAsoD6Ngf/BgClXInSoLwDAL8BzJ62jggAjPMtkci0DQAN8sKLf+oFAK+vyhblIAkAJ984QIvqBACkYl08vDEAAB4ITA/+2QcALPJnFNU+BAAJ0R4MzOYBAPHo2u0dYwUAAtLK8QpGBQBdZdCdkbQAAEzBGH1pxAcApKK7kMgxAgDKQgWT4EwCAIUL8/1VoQcA+YfU5cbGCQBZ3EsT4UsKADFvMnBZQAkA8yRzipJJBQAGwQb99ZAAAP1DHgKxqwYAoBHX+rwyAgA3fwQ8waUDAG2gKDxOHQQALhruY6cyBgBNXr3/S/oGAJJHuqY1/QUA6J3pHV61BwDPDexttpEEAKFk2tCOSggAvW4JRfzsDQCxiLST7u0NAI68URrBswUAGHALi2vPBACnMurHPbEFAB4Tc9vCjwEA41ePH2XjBwBlqV8FVlYCAO6FDI0zjwAAvXMamSGoAwBwWI9B5jsAAPCerI7B3QEAwo2ZnuBMBQB4sC6o1DAFAIu/mmxFcwkArA0QFSCJBwDL/pVA4T4DAGQJetaVrQYA+8sAfj7bCAAlSPnhMDYEAAlAa2qV0QQA4LX4Lf4TAgDmkRGk41wAAHcB8VOnXgYAY2MJ4j78BgCsZ225NuwHALFYB2rsEAUACSEC34ftAAAaHpLBTioAAEx5z/FiYQgAuF7+yt0kCwAXMkbg1RgIAI1CkpCL5wcAZ8DetRJtCwCiuCQ7miUGAJwLF/S1iAEA613h3sCBBgBFdPNl5t8EAIAnEcVD0QMAV0UVeZEnBQBNQkEHj58DAD2SV7NuXgQAb3TbXpssBACCuoV4Ue8CAFEvWzD7vwYA3RLXshKxBQDi5E+XdFcDAKPjlnr4SggAn7MLKWh5BQDcrliMTpcHAMaINAh+dQcAi7znKsYBBgB0q+zCcFMEADoUq4+38QIAAeEgCkO4AgDj/ogdnqQBAJZNzke7iwMAN9SEuufwAQCqwl3jQ9wHABiXPidcKggATouy38krCwAZ29X49I0EAI8CbJeHTAUAUC3YgftEAADD2X2IZWYGALKwagp2KQYAbD4kx+aBBAB3/EZw45cAAMxYZwFy7wcA2eMHqcUYBwA7OGuMybkDANzMXiXtBgAAWZoiOGWXBgANw/kjmPcHALqH9WjwHwQAU80bGQrACQAkniCcb7UHAL6qzF8eeAsAbMAxBJtKBgDoE7WjOdIEAGYQG/UjlwIAw9kEz/RCBgB6m6BaCdoEAE14PTfgpAAAGSl9W6HWAwDWpUZQpxoEANrTwh51kQYAxCFnqzg2AgCD4azQp3EAADFE4SBSNQQAgTkoKjbhAABUljXYfHUKAI8NsXrN6QoAdBd2z5vGBwALuofIqi0HAGDaXaz0twAApJgELNq9AwBgARiqZ04HAKduFMe8wwIAXynoBOvXAAD+oG8e6qUEAGBsQ1xjXgQAi9HUqPSOAgDKKjKnqfUGAKtE2aPr1AkA5NzzFQ8QCAAkeDYOcBoGACM9q5IikgUA0+gOaLkqCADFxkEvDAABAHRxc9+fIQAA530Sf3IUAwAeuCN9J+UHAHoULhrilAQAmg3l3YWKBAD0PUk098EBAIlohmTbewQA7I6PBH2aBQBrpL5s17UGACIleB4XQQEAH3zaJm2ABgC5mscbHfMDAGhRn0UgnwgA0j3AabhvAQCU2QzsbFUHAApRtwOa6wUAccuR3dEKBQBHirSAV6oBAHdSaD8zrgAAYgm2M5cZBgARZSZ8FZsGAMrxk/hARwYAhPb7CKQ6AAAN97g4HvgDABHIF181fwsAWoE0U+h6CACO5NLdq+MHAOVFH77qHgYA7c00LT6tCAD+r9l+zA8BAPJv6bCMJAQA4nJRERwxBAAlab8c1MkEAFBPEPwQBQUAnSRuM8UPBADhLfs5ZjgDAHh70XH4uwcABIB+a3lfBwChD79YwScBAHS5Ua7EjwoA09vSv4luCgDOZXagIuEMAMIFNCCxygcAfRadR4LtBACieZguQnwBAMP+yEZZigIAdyuRLrM6BQCl4J+gTbQHAPR+0IfvVAMAddnFYCK1AwDcHxc2aJ0HALvUQPGU2QcAVBhWBMS2AQCSUyAt2QIDAGTx4OS2bwQAt2VSrZc0BQD8hhOg2+sJADtqswwvMAgAbELr9cXtCAA9KKS8osEDAAIvu8cwNAIAwou1G+qjAQBhXN5jVyYHAMrxdjtdDgEAZ47aU9a/AwCKKsg+lYQFAHtwp48oXgUAgR2Tw185BQDLYRPFRlsEANHjf4rdTQ0A0hnGQczOCgCQTaxiZToMANi9p6yl7wwAISHzrsDBDQChf08xvyoAACgVip7RkQMAx1+JE/qiBgCRperdjp0AALfcNvp7FwIAj9t5+rwbAADhZjbrS9gDAAQigR2SDAIAzjI7PYTdAgCr2IeTYa4EAIP7W5hEfgkAIcwmxjJODQAXgfMvQZYIAGkkGtZBsg4AQrrlq4VWBwAuo0RTqvYDALsRD2iDlgYAqiP2gTVMAACly3VYrwEHAPN7sZENoAEAsvJh6zMJBgDSTSrpPxkFAD70UKWV2QMAPYg6uW9VAwAOO2KbUjUBAOuDLuK8FgcAuD64MAE9AwCsr9C6KpUIAIkb0072CQMACllRoC6XDQAY1dGt19sAAB4j4iP4GQEA4n1ebtZRBAA4+HCZwwAFAKNcpoFbmwcAEXiP3CCsBAD6AfWpiZUCAEpratIQ2AQAWbKWDeDtBQDzBVnJ6fcEAOuZUjU9RAgAOO5afX2bCwDrNC+aUZIGAHjPJElA5A4ASRRK7C6UCQAuMIFXvEsHAEzsgbs1MQcAPEhhG2fvBwAp18wURiYHADjmkq2TGQMAkkkjrhlTBAC1T9JHnSECAPZssIhE8AQAEkpynqo6BQCc7xRTpqACACd5HDzNGg4A5XmHt0aLBQDyer6smjYLANN0MHSwCQUAod62OdxVCADCJ/n3f5MHALalxhT6wgAAfNBt271WBQAI0XnBrPYGAMJHhiFuzwQAtluNwnwiAQAjdvW/6Y4HADqJHySyjAIAcmc8HlRbAgCiCnEHoyEBAMmDdMc+cQkAyvrVcgX3BgCB/yJO814KAIcRFE+UTQ0A0s6mlLsnBQCXSgOfXl0DAJu8hZcGJgEA8E+Fx05HBQDKSKMCo5YCAA6kx3b8MwMALkhbmSqZBQDHKgAHx40HAEEX0JRjkwUAF+8aKKT7BAB6CrJpkLgGAGTbx7WM+goAD6gqmOYYDwAaGhr4lZ4LAPpsZPOU5wUAOXaKMD1HCAANInBiQaACACXQaYskXwcAJ2plFrzLAQAoZ+LW/7kFAD6nOhDCOwIABZ5YAyZ5BgBdWZKY20gCAAgtrTylBgAAc7r3UAENAgBD4P079wIBAJocUbXg2gwAVdTg/38lBQCAIevRCEENAPmumw/MlggA6aRdcr32AwDGRVd/q7kAAGMd0vjwygUAK+oIpL7eBwAWbYmT254AAMClXtKXZQMArFhgEHuNBQBp7gvS+M0DAF4BZbdMCgAAyXx8MzJoAwANpp3B7LcHAIj6fKdRSgYAtQ3KcPScCgDYmAhuC7YEAMfm/90EXQUAXL9hxu07CAANaVxpPDcCABjPDVLIwAQAuZR0S6+EAwAlIqKOSqsEAEMXYNdaIwQA9XWJBw3LAABLDFM+MZICAAmlJJG7jQMA8RFaZdBQAwAG3wwrzucAAOZwS9nf/gYA1L9Flz84CgAAw8Qnrr4EAD8/akGkWgcAzq44YSUVDgCjhYzEOmQEAJK4NSeMhwYAd9j0IzWlAwCd7ovtBKUDAEb72KXgZgYADctwSE72AwBXZW2xSBUGAPOWNXdhogcAOl0nX01yBwBNUQ2BvPAHAI0TcnOtnQwAdBDT5d5FBwDi239epbEHAKFuF4+YugUAWuzdB6nTCQBvE/QmpGsAACC3Bgb8ygMA2pw1ovAYBQCn7G/k5foFAO2Oz9v40QAA3IHQPjGTBgBCF5Bmo7AFAH7KpCyHDAQAAZ4AlIDxBgC/MUq0EQAAAFynCmppHwYAykKtVwqLCwDI/Qa3muUJAMy/btQIEwgAUCgtipg9BgAMbMY/bKAHAPtHusG6yQEAjgN1xTU5AgATnMVxvfADADXoFtlIrAMALiO9r1MHAgACYNAeux8HADqvpEeunAMAwtk0C3wzAACKNrJSrT8DAOjPIsTQyAQApXFZJ7RgBwA9rRy8ldoLAHVzW/9R8QgAppDLXDXMAwAWHuTFxkkGAICq5u5nBgYAkOErGJ0XBAB5aX5W2VMGAG0lmkIPbAEAMZE+kEOUBgA23fnGSm8BAFOS4hJJ6gIAXdJoPmS0AgDnuib06jEGAOgNcKO5dQEA+0iqAF98BwAXA8qFd5ELAJiTx7KpWggA92X2x/IxBACf/mbaEAQBAH3WtNyCTQIALXUXDv7mAwCPsMse3toEAJHqsUiWWQUAGXuPhURjAgDAWilKPfQFANSsUlynQgIAEA0igESTBQBTEvkVR7AHAMa65sSAwgYAbnZhs6OtCwBOO1wS5S8EACKsSk3YEQkA3XylzwqNBABDrvasKL0FAH2QVo+rbwEA8tUYErGsBwDbtCMg4B8EAGUvXL83mwUAcearfeQmBwDB9kbnRewCAIZGx1MOWAYAdD9nBKHtBQDTNhMZNGIBAECG8x/WnAkAqBu0xMZgCABuNqcM91wHAB4BbPGoGAEAuQOiB1eiBAD2fyb23pkEADx3CIGFbgcAKcvdxcqTBgD0nwrQEQMAAAVdzf79zQIAau32U4pmBwBWJRQuugMDAAkJwYQFiAMAHSYKACD+BADkSNKWGHIFADva0KGRUA0ACgXBx7/2BAC+qS7NTk4OAG++i/KxfggAAkv8WpM8CACuGxj9F1UGAG2Bdix35QMAiolAlhgZAACZdN6EKu0BAMFjT9fteAUAPQwrScZ2AgAuk79A/JsAAAszH/HoiAUAbsJNaW7RAwCMKJC1KuwDALjRMq4JOgEA5LRauB7oCwAerjykrHoIAHNjUtcFLwYAuq3GZr/hCAC5e9jke9IAADS0XSMnbAUANy2mDm4uBwA56G7QTGcFAPwAoiVc3QIAfogseenVAwBVvKtNchkDAAAIaHh8uQIA3eY03d+vBwCIrjWLVDAHADTj1qFLCQMACzDjpybhBgDF+/yuwIkIAIJlgx+h7goAg4d9J6KFBQDuuKjLo1EFAIbY4itCtgMAvImWQeEwBgBVqacHO2UEANsRtEM0BAMAYonUM4JfAgAx9K8Ej70GABJjmv0H+QQAm9I3x9MPBAD5DpV4YmUHAIrPhuqjcwgALZz7q+LgBgDuM+o4Kg4GABj+8ykkCwsAPmFLSL+LCgDAyB/VWc8DABhH3tagoAcAS7dvPjpcBQDVT4hfE1MDAIQbjAoW9AMAfGwTb1wvAQBM3jei2/4AAESrv868eQcACWlNP6muAwCPGFiznOcBAG6B4PXYUwkA/C7buzOFCAAwlBKWlxQJAEKGFjZuegkAHp3TUqt4DADx4/fuwzYEACYAH8LT/wcAqS0K8nvnAwDecoT8vxgEALOjs1F5XQYAWdFSktOkBgDU7ABZ45AHAIZ3l78lBwMAU6A1FlwKAQASohGkh20BAHAFTtXi1QQAdF8/s9flAgC/fog/3qULALY5Yb0k7wYApqV3tZD5CQAVYgZCWn4FAHc2mESLoQEAj28e3lLmAwDr2C7gK1MGADhfFsiHjwIA1vfoG61OBABm9DFPnXUFAEN59EmBNwAAKU8r4zufBgDWNBX+glgEAORvPJQpmQQAFVtUcnA0DADE59fOayILAN6J7UwTOggAXkDOQ/jcBwDWg3l1XTQBAM3MNEL1IgIAtNuKPUp4AQDMK4zuvm4DAG9ij1v+iAYAwDJHSkjWAACSLVPGSrkHAA+FVIcbdwUAyGEU39mNBABxMueHlnMGAMAaDMidzAUAzdSGFGeDBgBzgV4aX28HAErf+fXT1Q4A5tdojwvaBwCmdVY4FCAAAO8dPbVfFQYAfJKJLqN+AwAuqPVoplkAANzUoasVYQQAdtq1w1MZBwCBetMzImQGAL2xdoBlyQIA/xAw5oGlBQB0NuiH+KUFALlDpqDTKAYA0pMMZNgcCAArD9fKsLcIAL1EgalNhgsAG10trjc+BAARPaFwzwEDAOyRGLqhpgIA4Do/+5HyAgBS6kuBexoCANFEbmWbZgMAM+Gm7QY/BgAPB1gnNDMCAHXAnEXgmAAAG3xsrV7fBABe/dRsHqIGANCymWYSKQkA5z1gohHuCAAgTMf1wgoGAAhoGSoZmwUA6AFwsHFTDABf5kYwChcGADiepEYaQAUAqMRhVd0KAgBGnt7ttKsHAF8ZGp+/hgUAC3n4Xo0IAwDbtPwmIYwDAMPjSeG6hQYAMOmkAda8AABSDnkD++oAAB2udQ9egAgAJwqGWcxkDADuC7C35UgKAHSP73WW2QUANVRMNONKBAAvBEg3wVUFAMAyQnVB0AQAB2mGMLQhBQA5nPtAjjADACygdcasCQMA7kOlu7mJAgCeUyguWasDADrYzauCTQYAJ+NywY7HAwBG+bchUi0GACl69zom1AUAsK6JIt0/CgDruX73ZNwHACxAOIPSGwgAITk4pSlPCQBtk9AYnCkEAEmKQYNBkQUA1a4hxxgqBQBtl4K6UbECAFTHS97vwAUA9deyJdx+AQDuGwimNnMDAMPlh4gxtQcA4VsaSW2fBADgvsdlI+cFAD6zCC8GOQsAsc9X5vO7BABnWW7193oOAI7Wnn/W2wwAM7dcVSALBwB/IXFFB/wDAOtqK5vSoAMAneXdzHhkAAD63RsFTV4FAE57xAQRfwcATCwRVcUTAQDKt/kDUVMHAAghmh3tQAEAr8I7MyIlAABkoPSYQ+MAACgZSz4JCwMAEgPIfn7OCQCDj/e9deUMADjtCxl6Hw4AeKNs7a34BgDovc4+2SIFAM/24EXwJAAAoc8mNLZtAQDYD9MfOrkBAGKjaFNA5QUAmrK3/T0SAABoPFJWQzQEAF/uIXlSmgcAfoE+y/xLBwA9jexy3oAHAHIn9ADz6gcA40w1iFFFDQCryz1KytwEAMvrv9AU0wsAVyvTavzeAQC855oIRYUCAFzBoOmP4wEAezfi4EYgAQCFqApWHHIGACgZZ78o6wAAp5VR7xq+AwDrtb1iL/IGAEkwUrholwMAvf37yJQzBADSjb8B0mcEAJbnela99AYAg7cXk8haBgAyif0gO30IABVpMgjyAAgAg6NbWpzvCgCtT+90mpEGAL9SFGHUngUA7wnqBOyRBgCE6QAny8sDADy69cRDHAcAzXSe+vZtBQDfVs/klZwHAOIJxjtkvgcAeOjZKsFJAQBfDDnKWKcFAIHcYR2LkQgAm9EMJlDTCADYtDdOq6IHANcUVHPqHwIAnWN/AjinCACVJEbZECcHAFZ0AKqvWgIAG6PqKB/SAgDQXwDqcXYBALc+SySu2wIAzOH/Vy9KBwABcwhzMLwBADScAfRX7AcAJKUfLghOAwBqEjWmjGkCAA7ZPV4vcAUAx8VwSpocAwAk/HiqpTYJAAB7nzsvmQkAoq/EsATAAwB4urAyiDEFAOx88Z9L8gYAx2DgMH+kAADQyA1UhIMFAK6cxNxD+wEAK7j0BqxGAQBVc57YALUEABKKchweNQMA4y+TaZ8LAQD90RzQP7QGAPMOdj5YQg8AtxYyV8E9BwBKcdf9SK4EAAPhE4pf+AQADf/WsiA0BwBExZdGS10HAPT49//hGwEA4fdXaOEZAQDV9Vw0FIoDAC+1BXGNpgUABh6Fnsv2BADllRhHxHgCAORkPc7N7wcATEtcRW1PBgBLo/4yVtsDAMIlmIKxkAkAyCUyUdPnCACtq7fjK8EJAKWcHnh3hwUA8l1J6peRDQDY2V33K+4GAI2+NOssxwYAx140zMl5BgCkmGj5jYkHAHWd9K0hQwAArlrl5BlgAQCcIF3yxU8HAA3tnZNqVgQAt+AW52NgBgBwTR/cr14EANqxzM8kRgYAwbZygKtXCgAJb2clBxIIAO2OTtAYoAwAbNWl7jz3CwAr10WAhQEEADAtyuDlWQQA6oswGbeIBAC1MhsNSm8FAC02gLzupQUAxo1OCtG/BwD0Nmc2mcgHAAFc+eq7XgUAij+QYLBtBAAhZhKJWGACAC/ldsY8jgkAj6mV2XlgCgCxCHkhfEoIAFll5gN23AEARCQLod/eCAAE/2CDpgQHAD6L3jzMzgMA/2QPR9UcAgCJOZWNwasGABXm5MLQSgUAKlIruNVnAwDHfT249NMAAI3F20x/BgMAN3lp2lIEAgCpd6oryy4GAHQotq82KAcAQLKUIDyvAAB6NX8phcIIAOLWgFYtzAcAY1YH1RMZBgA9KxVhUnkFAL08+rrboQcA1YglxTGtBQBcaGRBOl8EAG2WmpGf5QIA2jEyGjYtBgC4AU4AhFIGAGAd6TtTVgYAn6gAbAGuBgAFHBMqvN0DABS7lieiVwoAdD5E+2DzBgDq6iBy5IAGABgM8aXy/AoAH4ONs3/uBQBLxV7O+Q8EAFuzYeKFcQUAqXAOVFTiAwD44wNAgbUBAEvASjFoiQcAjmpEQcv9BQBxKv8maSgFAPazluIx8gAAk0bIV6OEBgCgvMkzBh0GAN9z/Pi8KAsAs5X/Bt60CwCkEbonpAoLAJtt2r8x7gUAZ4DfwjqyBQBmJdv/NUkEAG5sF20BLwEArvUWD7D7BAAqQJmNt/oDAO16hP1l6QYAe1KA7lO5AgBas7HNW18FAGY8oj8LOgQACoKLOAduBwBd2Z27m5sHAGFzn46ufQkAMtoCYfcZBwCLyoAqfBENADUJXbZmGgwAyqxgFIG6CQDCJjFqQFUDAHZ9chgZDQUADo5JC+rlBgDyFDIGtqMAANKfjBVfBgUAVJlCDPtpAQAQ7uzZ7ZoFAAIYhesWmQMAOMVcVRd5BQBPiuU5H5gDAMtv5m2l3wUACFkHCYgFCACTSoXL2NMGAOOxcOn0sgUAwcvtUkQPCwCTCiNZdYoDAB+ji94cLAUAPVp01PKkAgCKotRCnX4AAM1acIPAjQMAQJd1xYInBQCtkNmXMz8FABVN6Mc5qQMA4Dl+IsQ0AgDyk6Wh2TIGAJSEDO0R/QkA4Fcn7bMhCADFwY/lHT4HAKsWRsgQ0QUAZK8o36elCwCmywe4FWsDANf+Gp6K9wMAH49gLJylAAC3gcuO3SsFANR+hEhPsgAAx+obUb7UAgCbW57ZpL0GAAFOkZZpfgEAgM9/zvCxBwCBVEd0z08DAIWqz3irHQMAt1RebiHjBACJtnM5gkkKAISI5IRJWAoANvtCMJoRCADKZ5d4TOAHADK4zygbZwEAN8Xhon7lBwBBQUTvqvsBAKbfZMG90wMAfRfC6JzYAgD0LBi6Es0GAJd2msGKCgIA2XLMsvo5BQAg3h6PCGwFAO+O8ySsXwsAAquXYVzXBwCnL6TCSz4LAESBtBDNxwkAjzVI6rc4CAAXbqgQET0FAG1GX7ZuQQYAIM5fI6YcBAASu5mK/MMFAAiRucZ0lgAA+G8xmSH4BgDp86nxVF0AAEonvdDFvAMArdXSuISyBQCeliUQ4+UGAA9iBmMO+wQAYOZHl/UwCQAZ1OyPhkEIAMU7koxeEAMAOBg91IoFCwD7k+WH9WIEAC02zqdL2QMAt2cmtfkwAwAK8OBIWtQFAI2aeBRRjwAA0GN25f0PBABHBsLURRQHAHwPF2g+ZQIA1l7F495MBgA9/k76SWUCAG5mP69JhQYAaLvUQSmeAAA8/10fMegCANL7H/meQg4A4iwT/g2hAwDW+WseRloFAIMusPTujgcAzxaMZE/TAQAyUboq6n8AAB5Axh1ukgEAoM4X6opOBwAPvD/4Q8cAAFVUv8QDywcAmH6RqYuKBgDlYdgBHfoBAKuU39EArAwAGie9ASG6AwCvxLmIiVcPAH2f9Im/8ggAn+mO0c4/BwAymFl9lFUAAJAZpCr+RgMAWxl5gEwWAAAnunv7zJkHAFynxjtWcwcAs5wTYwjpAQDWoNkHtPgEAGlPksokjgUAVmTnu0aiBwBkuAG3JvQBAD8loZHINQYAL96O0+tqAgAFrt36yG0GAIY3oEF9HAoAffqzsWu3CAABHJFBTCYBAPm9hEX0AgcA3o7GH1E8BAD5Ne06LEgAABvTcVKv4QQAm5OSf/nBAAAXwW2ViHoBAMed+V4A7gYAzDGycpGqBAAqd+th3bYHAMfSAav5qwgA5QpjhwKIAwDb7VsEyi4LAM8yXzZDfw0A9b9Ztqk/BQCSPfNQ6MEFAPX2uZoR7AEA6WPmbW/xBwDG3hbL1qcHANLx6rzpAwcAVVSIlOnIBACCrZzatcwEAHXpEMZrWQMAXp/bDQyoBwBhTFw+2ZgDAPLj59JgfAcAcDh2URAGBACq0uzgxHsGALlzEx+UuwIAMCwAycmZBgDzSOIzZ9EDAInjS+G34gAASnj22g0sBABQeMYf6okFAJHx3bUJOwUAzPFGWSOnBgBgvi+7nLkGAGJcSNal0wYAwCPpZpSDBADd/MYwrxwFALRUrBia+QoAbu5hlqOYCwDizUAeM4QDAKYZ3sQVzQQAjp8YnOIqCQAK4HR2QqcDAMF0fk8vFAYAFTqMMZPMBADnHiusG9UGAD84kqJKUAUAzwENH8vABgAz1fWeRocBAL9HN4g4cQIA6JA65Sr1AgC6jpX+FP0FAI7Lk79e/goAh+fLitomAgChfvuigwgBAETPQnhwlAgAXHJg+XPdBwAsq0Uo3y0EALt2Mv1PIQYARlIaGI0LAAAg63nVpmgCAEeG5Sb/kwAAKZgFaP4kBQAhtnzkdVsGABnM1aWwXgEAWp2SswlSAABHa8jLm/UCAO7CkbZg1QkAB87j/Lr1BwBsgBQWVs0MAIexcGGLWAwAgRDQ41WqCgBfExeZQn0EAHDweqDP6gMARG60RqveAQDfbKQ7P6UHABrl4kKLRQUAT0QHDOaSAQCqHaJDiK4FADgVC5Eh1wYAfkGmlRoyAwBop6gEkD4BAGyHOxnJAAYAZXcNihscCgChjrN/knkLABrg23l2DQcA6Y2JQGD0DQDbzi+DRYgFAHNuDH/NNQEAW+Po3/s/BQBb5QZeGS8CAM5Lgeg3OQcAjfR7KRZxAwAglwYNnloEAOxEpxr3WgIAo6uKy/AaBABeHYlOis8CAKJr0Bd+SAUAlmUtAyqHCwDfSJPAKF4GAMJAzrJrewoAaR2J8vemBwBnDxEHh/0DALItqRaHbwIAJzB1G6rNAQBhJrVYvgQFAFKC5dabBAIASe+aao39AQChbyG3Z8sHAIK5w1P/egYAKJbaEKYOAgBZVPytGgEGAH34ywLI0AYAe0xV7b9BCQBiQu9nttsGANx+hSYxjwUAQJN3i+GcDgA8+JXPbZIHAOwrDhIlLgQAFfrxbek9BgDM+fNQa/AEAC+2sMFc/AYAy3mYsihVBwA9WhLSj5oHALhqdEuNfAIADCECP4n4AAAQV66zllUBAMokUX4WMQcAP+G76Dh7CQBVkC+UW9ULAD6RvpUUnAgAbPsaJE6qAwCieZE/0jkHAMToudv6MgYASAz+K1LIBwCpWu+DCe0GAPS1h3Yj0gAA9QUzKr84AQCYZdgkXfQBAP5gIa1LJwUAKtFYHQS2AQB6aOSmyi8DAN/MhydzpAcAQAZ/fEIeCQBjjF84WTYIAPprdtnq9AUAACZsM/ZGBwD1mn3FjW4FAHhPvhe+swUASy/4jJK/AwARbwpgVS4FANbr75x+YgQAHJdsq0XzAgDp52NuKFMGAK0jirdhEAUAAUW1rJlJAQBm7QdwkbQHAMqiU90oGwwAheqHX+h7AwBBXqjS40sHAKZsyfqHvgkAzAj+IDbQCQBksISrXPsFALCFgnc+UQIAQ+AlMThXBAA9Im61o70GAE+Ebze6IgEAVOW0os0yAgBA+A+jK0IAAPVDe2bnUQcAPl/aVRcmBgCOtlK/cCwAAOFyjUW/Mg0Am7WW55YPDACinW+d9y4CAHfKvmerAQUAQ+s/fmmwBgC7LwtdS+wHAFBUWRDpAAIAXnEFcQVCBwBgD1MicPACAO8JpPA0YwIAwKNi30rwAADZtou07eAFAAPA+6RKwwcAJKxcTk7XBwCyQTT0N8wBAKauzsnxVgYA7FqtrBwDBwBXbHHQjDABAEIZlHMTHAwAlfFy90ajCwBPMsdcWlYHABFKJNWgHAAAE4dBZ7AWAQCu7VWMfaUAAAM4EJyAxgYAyGra4hJRBQBauj0KPTYGAAz0povJGQMAx26jA0voAgB87/a5EVkAANzqLlHzrAkAaCppOZhjCgAGBYM0omkGANQDBgySiwYAsmQcne9VDQC7Dt/1g5kDACaYlYkl6gEA1s0Dh2POBgAFhYl4FjEGAHCims/OswYACL1zO7pwBwDUhuH3dRQBALwrickbJQAAWsz/m6tOAgAXOBPe9HUGAAqz2jvZ9gcAJdS/pazzAQBglxwcUvoCAM35J86AIQYA0yyIC0UPDgD8ghdrA1IEAMWBdrCVLQAAsgWS+RyQBQC07F5uaJACAEwWcN+ZPQEAysDlIcNeAwApQPQ34zoBAKctP4GOAAQAOgyOLydABgDaXuXpbcABAKppbf9AKwUA+n83CYgbCwArTNFcYjYFANEXLiWvFgUAK9Pn+JaABwDixD6j1noHACHTEdzFFwcA5COYVRShBACx4qFQzgYDANvC/qE4zwQA51z6DWWqAgAVlPGoFkkFAHgS52/JDQAAuD7mhCdfBQCRYKLTynMDAJq73Yn7qAYAN37Z1TWMBwCyLO90Nm4GAI/dU6xHQwMAKhGl7UcVCgB89cmCTWMEAFLWpmiSJAQA9y9/aG0zBgCg2SZOT/4EAEFUlD0PBAAA04ZZ/TnpBQDfmwFHISoBALKc0OdmxAQA3QPSlVv6BgBUojSjUDUGADZ7VHJFWAIAdxMcgVhcBwAbF8w3xtMMAOI0fXQwPQMA16f6upKaCwA3z2m17dYHAKAs3KWUAQYAphBedFmvBQB1SAA+9agHAHivfSym7gMATieT5hPHBACks256G+0GABWOfWnOKgYAdbAqKbhmAgCcXGagNoQGAGkQIOgX0wYAyqMsXYGQCACgmRTr8T8IABjjUPBgOQoAEBbJaTY3DQAnPy8g6DUCAIAXti6fTAQAA3AdW5AwBgDR6nTSyPwEAHiraH9uewEAV1IOmqsUAACli39WOZkAAII8Qip7tAQALcR65deIBgCHj2daS8sBANQHoKJiqgwAbS32OA4eBgCCR8yPiC8IAP8b8oMrVgcA9i7Y0g/cCgBs/Eo5a8AEAMw29ksbkwQAeCMy0GArBwAli4HGJ1ECAEPnjae8MAMATnQZEYT/BgAFk+ToYMUCAHql5e9PJQcA36dgxeJ6BgDxabPhG8MDAHJCy/mTvAgALBhz2/n4AwDE4brqNbIKABlVKYe/3QIA1eeXEOwcBADuipQITYYEAB72jUM30gUAZ3AfYIWyAgBT1+a6vF0CAC0mNBG2MAMAioBtotcZBgDyvq3Cs8MDAFJ/7J58hwYAbbbh67m+AwCH8pHNRGsCAIMDc2KT8gcANpxFUXn9BwDnSS1RTFAHAF/FO37thwgAJcdJAbHeBwB1dDiPR0gAAD6KZ9mXkwYA83bJVoF8BgBsIolVTesCAArBweYJxwIAeu5mh2qvAgBs2aF5qooAALAvm9WSLwQAB5wAQCx1AQDOYv/paI4AAPnyuArVCQ0A5OV7JKu4CQCF5LLmstkNADgTmkel+gwAcI9zvRPLBACtMMFLClAFAJWGk3qhJwEAbeM0+iYqAAAozB4u0YQFAKPrfvjz8QIASrYV5XWMBADwHgdSaVsHAAZUlkJt1AUAn5+YBmF0BwDiCjw1HpoBAL29ltXNcgkAgxaI3x1zCAAUgU/WJgQJANmjqdhPGgcAaiaQOb02BwDDBfq6YHUEAKMvzKvcGAQAgobPzpFZAwBgjEupcUMCAMMgHLFGFQQAtLM0k1AtAwCqcK4sEGwBAEX0G9UNcgEAIZivL2auBQD6hytaKRIEALPqk+JhUg0Ay2WbdSZkCABHahGuZQIEALzlugQjwAYArZXRuAt2CADp1n71iJsBADmjBBm/zQQALE9OzUkrBADZCRl3LhoHANJSuz4VTgEAioHmzRcaBgAniBA0rT0FALZVXMUyKwMAo0eTXxb5AgCsM7zpS7MGAMDycWVlaQwAPkJvzmGqCACgJxvXQPkLAGnRc53xhQkA3OZie5wbCACywHg6ZC8HAHueT8BF3gMAXPowjdYGBwAkL44+9pYGAC2S8BgsAQIAKZ3IWuVVAwABcewUtOgDAJAMUnywnQMA4e93mx70BgC65IS39YoAAEsszInSFAsATbzx4lA0CgDzki85k80IAHxrlGoMNwkAl/1aHTxCBgAzJR+I3JkEAAbFdmTyTgMAlxR00gfRBACz/W69xEYDAKFjEdd5KwMAarP87dn4BQCQOb/c6OYBAArzijRPlwcAfJzxTnLmBgDiE7zvpYAEAAwizkLkTAkAyxYlp4CJCQB2ZrgN+HIIAG1S2h8zAwcAyJF21DFLCgBxIGIBC+cBAGqh+LVj8QEAF9QaNK9qBQD3MNg1lpgHAHvLAHaiegQAw/gVwO0eBABKhe8njc8HAPmTRljjiQIApwmzV3hKAADaTdGFtUUFAOEhs+PQ5AQAQKzS4x9FBwCNqe549mYGAK3+Z4aFOAgAjEzmwy3SBAAPOtSgXicHAPfM130TgQYAOJq3upznAQBqpolEISoCAKUrM5wv9gAAOV871ollBACWP+x5+eoHAKi5chXo6wQASmlhXX8bAgBxY6MB+sABAD1qk4wOKwgAIM22WDu4BgCAJufT2H4DAGIqn9s3oAgAu9KxGVQADAD/PZQitgQGAFgadPaZyAEA+zLy4hkCBgDL+aeSrl8DAMqx8xQ2+gAA8IK+ub3+AwAAFJKVSOcFAAYngjjqUwUAjMjPJHyhBQAK9K4YovsBAJQBez4EVwYA5+nvVRvBBQD7dKDGe3MHAMxV4xzk6ggAdfc/0TXFBgA+9cj6SJQEAGo16MZ0TwMAotsHBnitAAC2PrZ+OiEHAIaMqqzjkgMArzWKPuk0BQCXyQL9EIsAAAUeuKzCagIAeTvOmIydAACsUE3+F14CAKch8Xb1fwcAK3L8sPnlDADHKA2blG8EACbvF13mzQwAl5b4KKi7BgB29gQe15sAAEWh8kHIWgIAcTiCrH6kAQAaWGzDqKgBAPupQhR1VQIAATn+kGa8AQBavFovExQDACjVMlGDEQYAV4q0jkvyBQC39vcE1VkFAP1m0vbnkQgAiHMD72BgAwCGEh3siIcJAK+ORxxEhwIAvVQzauojAQDVVOuzeIMDAO6Uj6eq1AQATad16AKgBAB8sWcThQsBAOMHWC2xGgAAli3jQZAYBQAxAgkrBlsAAI+352YXyQAA7DihVQ+qAACKkSwelqMEAB4/I/NE1gcAZMACnp/GCQCXaCbl5WoDAHmL09rBjwgAQL3Z6s6KBgCgu+b44DsEADtOYfzfjwYA4Dtbqx3pBADwLyHJ1LEDANuxP85rzQIAEMLX8w7JBAAWh4Gg9ZYEALg5woz4nAcA2/hsMJzLAgCPUFsNdpUFAJAnAv3rywIABRHsKoK4CADLvCbSz9EMAL1xSfqyFQUAFUX1XSzLAgCXY6oE4b8BACVsmf+UFAEAAFg+YlFCBgC+RODFn9QAACnL7UP6CQcAyir9Y4xdAgBh/d8pzcUEAAWvSOvALgMAfLf5kZOPAQCBDM+eAg8HALmwEF6qrwoATCVVg+AdBgCNwuN9WOsIANS7fZ+78AQAvXQqWspOBAAzPu0uswcDAMLoPLCKdAYAvBC4mg18BQCM6SSiZCwEABTDptjVtwAAQ9WVezJIBAC6pOOBZhQAAAxOw60UhwMAMI4pDm/yBADexxJFInICAPx1qUKKuwsA7hdrtNXyBgDlcDEiqbYHAOa34z9xUwgAwWt//TWXAQAuNMVJr5IEAFcDWt9cNgIAYLv/pzghAwD+RkbR96ECAMxEivFdGwEAZkLIQtCQAwB13I8q4+8BADgSrudekgYAMujQgZKvBAD4HRkR+f4AAGNhbGxlZCBgUmVzdWx0Ojp1bndyYXAoKWAgb24gYW4gYEVycmAgdmFsdWUACAAAAAgAAAAEAAAACQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9obWFjLTAuNy4wL3NyYy9saWIucnMAAOx7EABSAAAAdgAAABEAAADsexAAUgAAAHcAAAARAAAA7HsQAFIAAACBAAAAKAAAAOx7EABSAAAAgQAAABEAAADsexAAUgAAAIIAAAAeAAAA7HsQAFIAAACCAAAAEQAAAGFzc2VydGlvbiBmYWlsZWQ6IHNlbGYubmV4dCA8IEdMT0JBTF9TVEFDS19DQVA8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz7OfBAAHgAAAAIAAAACAAAAc3JjL2JpcDM5LnJz/HwQAAwAAAASAAAAEwAAAAoAAAAEAAAABAAAAAsAAAD8fBAADAAAAB0AAAAFAAAAbW5lbW9uaWM4fRAACAAAAPx8EAAMAAAAKwAAABQAAAD8fBAADAAAADoAAAAUAAAAU2VjcmV0S2V5Y2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQwAAAAoAAAABAAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLm5leHQgPCBHTE9CQUxfU1RBQ0tfQ0FQPDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+2n0QAB4AAAACAAAAAgAAAFByb3ZpZGVkIHBhaXIgaXMgaW52YWxpZC5zcmMvZWQyNTUxOS5ycwAhfhAADgAAAAwAAAATAAAAIX4QAA4AAAAcAAAAEgAAAFByb3ZpZGVkIHB1YmxpYyBrZXkgaXMgaW52YWxpZC4AIX4QAA4AAAAmAAAAEwAAAA4AAAAEAAAABAAAAA8AAABUcmllZCB0byBzaHJpbmsgdG8gYSBsYXJnZXIgY2FwYWNpdHk8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AALR+EAAeAAAAAgAAAAIAAAAQAAAAAAAAAAEAAAARAAAAEgAAABMAAAAUAAAAAAAAAAEAAAARAAAAEgAAABMAAAAVAAAABAAAAAQAAAAWAAAAFwAAABgAAABybmdwcm90by1uYW1lRXhwYW5kU2VjcmV0S2V5c21pbmlza25vU2VjcmV0S2V5QW4gZWQyNTUxOS1saWtlIGV4cGFuZGVkIHNlY3JldCBrZXkgYXMgNjQgYnl0ZXMsIGFzIHNwZWNpZmllZCBpbiBSRkM4MDMyLgAAAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYA13E8k/znDABDsrb+Qc8CAHYafQocWAcA8DJNUy0XBwDSh/pjwJAFAKjVtEJgpQEAU9GeFcyJAQAErjyq3rgFANi1EU/wqgIAkpxmWlm7BgBfepuls6gCAH8I71mzqwMArwXbxKj1BAAFQtAHqLkFAFDqE1uvAQcAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAnwn8jrlRAwAOBaekv48GABuXnZVJKgQA/Z5GGuWTAwBYHjIQ6YAGAL8YaAUKBQYAvzJVH8wqBgAl+snMQYECAIPmcfRhTQIAWkTH9DN5AgAJ/3bE6fsDAEJLLphrrwAA5Xi6URKtAACIfO7trhUHAFM19svQ+QcAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAMXEVd+vuBABBB/EVGSABAFacbNqcZgkAbDTbMsBeBADDLGq7Vx4FAKSMfXu2BgAAMynnRPqEAACKb13lThUBAJBzLoRdQgQAF+QaxGSLAwBxS+oCZzIEALUwYDc0aAAAgMP5EgXvAACEJVHyqfEAANbwqZGOCwEAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAfD7dBGZZDwA1iwUOUfwOAAzMso0MZwMALzPOmdiXAgDOGwZ2XpEIANk0kvPtXQcAVDwfqzYcAADa9Vjuj/AAADfWoBOW4QAA4CATSgKpAwAakaLJ2fUBAPj8+pR5EQcAxY3iyqjYAgCHDAmysUoHAMTswsUHaQIAHZwvYw7dBADZpSIm0c4KANlCR2HpjQkA07Xbb6mcBwDuAJrUN90GAF5RqklUYwMAq11H0HjhAwASl6ESRwsFAK30D4bC3AIAMT3w1nYNAwDH5AYhF0QEAIgt7a9REgAAWk/tm/w0BQA0Us85WtgFAGToEnFpDAEA8sdYg6AqBgCU4UgIRG8EACv1qHG3RwQAHdNpMrp3AwCAUPW6+TsIAN5fvn0nxAMAkkzUrzWjBQA+dZlAFsEAACPkbwCHBAcAb9a+ymFeAgAEZljMKOEDAOLHjy6LlgUAz2G91aNJAADm9h5bUBYBAG5YNIbXZgUAvS9axoVCDQAfdPjMYl4FAESQsWG5awwAOCBxBTQVCQA6eTRfuk8JADQIwZyfpAcAxiKKeBO1AgBbOfJuS/8FAL8H9lqO7AIAw+ylvHU5AwDU94VpFkYHAJrnCgA5mQAAevlkeUyEBQA9W/nhFzYBAMU/qM4pSAEApexxTi8LBwA8ZPyOFCgHAHZbmQM+dQgAZmersl+/DQDWNUW8w18IAMKV3ZeEewMA6P+01kkVBgA40bEtohcCAJ6wLgbPuQAAWPflcZz9AgDd3q9SrrMAAJfkGWannQEAjlXSVAb6BgDUQV7SGYIHAFHGdXR2cwMAkGUkFMuVCABnrKYq2AIIAFBIvIPxQgwAQwYKHE9GBgAHCXMFWb8GANmt0UD9mQIA9+UEmt7yBQBZHMy67sAHAAop+LGhzAQAj7HDVur7AQCKW0Hh8XgHAPTB73RY9wYAfwIZQGmKAgBN3GupNysFADWmZ88hJQAA0V4vdyBnBAAi1lnzwDIGAFLioysJsgIAgCYRfCViDgDVfJ89dQEIAJRSnQoL7gcAJ8pM6/uBAwCdYz46H4QHAF9EwzDqdgYAghPnpwD6AwA02z2WLSMBAI0HC+eSVgMAH3p3FMpHAgDQ/OhrVdsGAI4E+uJfKwEAkh5vrSZ8CwDkeyJxCWoEAEybLQ0vcgQAOuBOIEbcAwBseSA86fcGAE3j/JbE+wAAPq59a751BQAJ5s6FFaMEAP8wOQLpNwAAEvuWb7dJBwAFrqauBPYCAOsjk5PcNwYAR40Em639AwD3WgTUsKgAAAIe8BDs/AAARU4kxJ3SAgC+R8Ebe5IGADkIrDSFMAgAQD8DZDaFBACr/maRdxMEAEQe/kmmWAUAiczvrjVGBAC68odIQ/8BAEQtDiKB+QAAUTwYpxqQBADw+BqMVLcBABaBNlOMhAcA6T0452QbAACPfFiw+wkBANEmt4e4GwQAm5FmfFlMCwDDD5m2UKEHAHQikp3rKwUAGoZkce0OBwCpxnDgcagIAL5GQ3REfQAAHahkpbaCAgBrI3X4gO0EAFAMRR2++wYA2/wSjHLrBACJibxLmbUBAGAGTKh7SwcAuK7N8XhWBwAM8dawBjICAF1o8gBz7gMAGHUehEd5CgB+6NqIcywLAOgbl9OtFAQA8Q4vg1AYCACI+yxqfNQHALfWfZ7kVQIAup7VYyGMAwBFWAAqH4YDAMmuy0we4QIAEnkpdhU4AQDg1vCOFNACAPuH540qUgMA0vl0XgXuAgATCDH2OEAGAJ5M01jPSAEAWnXkmn0vBwBK/A9pHnEPABUNWzWigg0As7aF6M/cCADp6tS6/ngKACfwNHn2kgQA1ChVgdDeBwASZhpRYYQFAEQV3lAu6gUA29XroS//AwBmOZOMH2gCADUWkyEFhAMAUoYwSvF0BgCQSKmInL0DAMbpL9BNEAQApWoJ2wZOCQAjsOaJnCEJANqihtSreAoAH5VgkrJACgDJ70haWxYIACpCJBFevwIAVq5WZxRzBgAw6Iea2UoBAP2AsGXK6gEA9foKsGPIAgB2aoSgdKQAADIemO+lmQAA5r9LPK6oAgAsgxSvNFwEAOz/m322kQUAXbUYn3GzCQA204OMMVQHAJeXkbcXfAoAYJsIhLBFCQAAA2f4tIkEAPqbtIAcDQcAJUaRfX7VAwBF5WUhcsADAE/gGTi55QUA96h87ALeAwDvkus6LRACAEY6DNUijAYATomFk6guBACM81W/nl8HAMuWpLtfnwQAG1ecHoxiBQCrIugIsZgFABo2Ka6PXQUAKHup0citCAB0hihsGmoIANTPW4oQmgQAEmZ9jowXBgB1A3FzNPABAJhgSmFJOgcApr/chkpgBQC2ZBd81NEAAFEuajEIHAAARVDJRduzAgAMMI2BT2MBAHTin+iJCQIAG+zqhYsnDADN4ntlWe8IAG+HWGnRLw8ALwsmBbLpCgBYcA+VuTAPAH/MLTr9dwcAMkkS+6mUBQDwFcqAjh8AAGky7DzRFAcAZ8rQ0T5AAABSxU6HNS0DACm58Y0E8wEAI5sXO9cAAwALfaPle+YGAAODMFR0vQUAKnnnFSGTDAC3MLm7uVcEACYyGYtdjwYAVtQej04WBAB/BiOxfbsFAMJMsiiV0QIA8y8wuGasBABRrf3ZyAEHACc3W1yzwQYACjgHgKczAQC+YsrGZ/QBACzBXSojxAIAh7ATwB1VBwDNO7ARDGkAAA6P1abcQAcAPEN4BFeMAgBjpHMoUNgBAJzU3n4eZAcAcfVM1e3sAQCwwlZSP8ACAE7Oz1IH7gAA6fsWgd1gBgDr/w8TZ1EFAFyVhbiCxgEA6mOpX9JhAQB9pFN7dRgHACEvD4vhGQYABOzB5N/7BQCSux7ImNcFAGvZ24tGmQYANRmpauY9DQAam1ka+EUIAJJBIb2o9wsAGTMSpE0dBwCixObE4ZMKAM/+2vRGLwcAo/fe+o+UAgAEvPP9zR4BACXt/o/pwgMABTlHmiElBQDhElGSSxMGAO0GtCuUuwYA4t3ARcRwAACj18Qi2BEEADLwR8QFtgUAOfDn8Mb+CQB8RyxpvM4DAF6pGWqYdwgADot3oarqBgCrxUzvL/EKAIl8xCBZgAUALJf5cUeSAQBAwJ/fvYsDAIGykgAA9wEA64rq3HZKAgBAx8DfsiIFAEjhgDQZ6AcAuUFDoNk/AwC8IIpnY8gDAEOKUbIH5gUAAc+WpRxDDAAEFIB82hUIALQQj2+bPAgAFkCTImk0CABW5Dkx8wEKABgY32yPHQMAFksUS2z4AQCdPte4dZgDALOn/9nw+wIA3cy2ynoGBQBRnQMIa38CAKrfAIAvgAQAJcVioJKWAAAXWAeR6roBAGAkhqjLlwMA53kTyPvDBQACL14lvBsEAFCGmVb3ow4AQXzg1H8pCQAbHiwCtHEHALJZWfCTMAEAGMYuLzW9AQCG6oibeHUAALlI6hcRHQYA5mYHMp0zAgCnLzpRhtkFAA8b4Zk6PwYAbbLWzw6KAgCPjeE1aDsFAHGZIYmhMQMAnHJ1nTovCQDJxFPpAA0JAIkvbxHfAwYAiODgdsI9AwCaZP8ZlqwJAMaAT/tFbwYAov657jjMAwAf23ByZAcBAMgNdOrxEAcA3zu4xmcRAwBoEEtSQjgDAEX+MJ3TfQcA0KBBIUOJAQAlwrhO/ogAAIvwQWNDEgYAJSYtGuNJAwBssaZ/ehMIANt+d5KugQ4AUNz4xb8iAgCQjRejKlIJAI2JTofbQQUAMxuE+4AtBgCX+ifwbj4AAOgzlp48oAcA7+UJI75uBAA4SWFpUy8AAIcFoq3lVgMAAvlrn8gbAQDbyBlkdDYAAENSUA/nXwQAfhSVyCBJCgBdTJRh7AcJAB7AF+BSJwcAeumi3bciCQChV9v2GWYJAIwLDJamdQAASRvkxeHdBgBBo21RPy4EAJ7nqP0DagEAOQ46YtEoBAD9CKMBREoHAAmBVbnUbgAAZ4ig9vFGBwAhI29cb2MEANML1pIV2AEA1cWFe5+2DQDrUFYXLXoJAJ3Bv20+zAQADr5zOB0+BwD4ChvV9qULAF+sDaZWhwYAJuyKe3VdBQC9gF/0PTgDAKaWn4w/eAYAzZ54pzQCAgBSsnhxtg0CANoOLNqjOgcA03AcwEWQBwBZECUVe7MBAP7PUyNozQcA4PSsaGDNBQDMdHr8mgcLALNkC2WXgAUAmU6crKt/BADNsrJTAu8LALb6h9hbpAEAfMFtB0hXBgCoEaoAgLkFAHQJCMnsoQQAwL1jiIyDAgAwUEZKz7ADAC169a64IgAArSXpdwatAgB6RddnQQkEAIJqYIrLHQIAujF3vvoADQBQMxHDU8wHAIENCP5lzwcAoRsBZtnFAwD2xvbbQNgFAMifnYxGBAAAjGt5VIXaBQAlAJVwvrgDAAmmpi2J1QYAMUoZCD28AACL4Z8wDTgGAA3uuCw81wQAtsC6rYK4BgC+TN3dq24DABmsMmInpAMAuH5E23LBCAB+p7cFxfgDABA/f/lXqAYAOuB/VsD8DAAZToKeDHcIAPqEcIosQwIAaKmoPPd7BABnKCZ2kWMBAM4QgE/f6AUA3hbqfBf/AQD9tbVFmtkBAOyZJE9nIwUAEyYYJvr4AACYjASYc48FAAAV1E8mnwMAznsJ/qtKCwAyOiUD/DsMAPK3kf7HmwIAFkqE5GGnCABew3ISYlwOAJzi59sXNAUA9ZRzgnNFBQDdUPam7mUFAEnHjXRQIAQAiYhGcy1xAQDdkzHO+IkDAOV8F7gk1AIAzUA0DfpzAACXntQMAjkBAM4ZqwCYLwIAmf1umt2fCgA/KCiplMYHADpL5O7N9wYAw1yyBzJaBQCMWThNGhcMAMv4nj6KNgIAC6ziCKpUBAAAp48/kpAEAC9YpJ6qcgMAYkfWbEE/AQCMTMmZqlgHAET/ABcA9gUAvQGMSE5pBwDW7kjp/dUAAL10pU8hCAUAwwPQU7sVCgDCqCx5nhcJAKFAyGrpoAEAtjq74pMjCgDKhkyKdacLAEv+1j4VaQIAQJj4riMqBwCcaZlSvlIAABYjE+/lpQMAuvrGDpYvAgB2UK6T9hEBAJDKlKq/4wMAh7h2lHlFBAB5SEYSCUoCAH/e+BX92QUAC1LX7ipNBADkp8LSZQgFAEDqOFJbcAoAljtdsnBsDAC4fqR/GLwLAH9yY23TCAQAYmCm9vj6BQBr3qgtibsCAObix/DUaQcA+/gUWfMyAwAMwobqFQEHAKitJNqIbQEA3ypmIgaYAQCdWhm86wEFAPsG6RzYUAQAP3SuHJbYBAAOun2Mw70GAGO04ae00wcA863i3kuECACqY5YnrcsEAHVSIKahtgMAz23QkSfoAgCHPKnKcj0CAPSqaKu38AUARWO61CXeAgDNH9egJJABABoQXxFlXwEACJcUZ5DpBACvpcvR2BkBAAcg/s771wcAlJDC88VdDACuebUgUkULAIkGHmPBcAgAIJsOY8BrCgCMzW0ZzfkEAAEoayZqHgcAXd/ic66aAACjsRmy2A0EAA3eF0X7RgUAdXvoNVSXBQBoN3tq2JcCADJjTC9agwQAYEFDXzBwAACuVk4B3YMBAKCHQwjdzAcAgMxgZxiEBABhM1NlVkMHAAG4NmNoLwgAMEP2RlQiDQALGUioPFkLABcEJm0sQgYAlLsXSJASAgD1VLjeGaMFAH3aYODUqQcADB3WDr0oBACnmoRemhgDAEKyWR+7rAYADGNTR+/2BwCpLSopRvMBANaijTCYcwIAUyRwCkwOCQAz13ujr9oEAGGJPtxrnwwA5drs3P/+AQDDklSUwnIFABPUXkMojQMAWCiZGU8GBADNQ/W+D2gHADyN1YPdqgEAw+jrellpAgC+MM3WRccHAO9431V3fAIAo3+TM2h3AQBVGEQWUUAFALwFjEmF+QcAUGO/D1IVDgBp2nS/6bkIAGgRIAiD/gwAQt4nYfdzCQCwac1TJg8LABfhC5+IzgEACQdRlGpvAwC0FgBySPIHAJHP4dEeggEAH6NwxC5sBwCFDMGqOMkAAEFxee1kGwQAbV4YwbG+AQAHD2CQVO0BAEeWFT8n8QIAwAunVdeLCAAI5lyIOp4EANZaG4iFZQkAXU/TaHXCAwBf3H6ZwYoDABEe4Ip8/AEA5+hzVU0JAgDSSfW7PMoFAENBxewg+QQAtoWtcuXZBQA7sVGnF7UGAMyAsXDTzwAAGvTRJXk3BQCiCGBWVk4DAJ7+y9n8LQIAjuA7ELRZBADdKi0/S5oFAOuOu8g01wcACUpZvjw5AgDeTIJ3mP4IANkMDcPg0gMAu3FmaJf1AwCZObZ+WKoAABnGkrXH4wAAjEQFbJGyBgA7kboK0TQDANvPgbXNRQAANo86VeDjBQCy/x4EswsFAAD/B/MDwwQA7UTZDVgDBAA/ZZJ9940MAOlJs+OfigMA4a8KhYnqCABpcKtRsRYMAIWMshfWOwIAYVp95y7nBgDeTRf/cqkBAA/Gc2Nj4gMAq7J4jxvWAACwNsHp79cAANUKZIkcqwEAlx/0roJfBQAN7RfzV2kEAH4ndK+ikQEA6A5GT0MrDgD70/rAxpQCAA9Me5NogwYAW4cQKfjJBQBFBeDb5zcKADEUPMVL9wYAwtm7XQ7EAQCXXK6c+8gGANq34VxchAQAzLVQ5ODiBwAwtAFn7XUFACYAon/h0wQAU0KMiPyRBwDBigeZuvECABURm2n6GgcAw1A7Rxw8AgBIHeIdZ+cDAOihR1X6JgMA2a9fwk0ODQCIj8f7MQcIAB22UzmbbwYAucw8KPRVBQDnYBn7Z90HANT+r6EHRwEAHCucLhQhAACAGPhIGMcAAIY8I9jZSwQAMFj+jlfoBgC1QXBtWwQEABV+NPPWxAQAXRmPmPzdBADhZaM+F/YEAIhFrvnaRQ4AOmLbYzfUBwD5iApQ+YsLAMkffcHP7AcAHoOCByjKBADW17F9M7gHAPuVOO9tEQUAR36q2v2TAQBvh+g3PMkCAPqDxSgaQwMAediL2kmQBAAcwXpAqLQEANTw65n7pgYAxiPktrUiCQDV3fHfUB4KAL91TjJ2PQcAjkGVVEiIBQBeLPSp/TYBAOtVCFa7wQYASK0TfhIfBwDsWpAEs8YFAMebiI5rdQMAiTFKkXZfBwDRvQWjsd8EACkfgQX/swMALtk8KGLtBgDhUuxDFV0GAI2+EDUYIgAAbHowQwFxAgCr84u0j9gDAHqPwU7rSQoAXin/XRE2CQAD1B9EfDgJABQtrV44ZgcAXgkGi08ZAABiO4L2eIQAAAhz04mGAQYABrgXznGgBgD4ipeH0cMDALp2gsjhrwcAaK3IgfIdBQBdJKS9BkkGAO3xqiYbFwMA0UeKsti3DQDANJ4U7sICAFP8mmL1dgcAqUn8UOr0AQAkRDOmFMUGAKhMVpeQMQcAJTUjvE6EAQDh7v1DRR0CANIb/6onrQEACM9zSP0hAgBBYxU6TyACAGSkZUBBNwUAg8/tOww8BAAgpm5wflUFACS5b1mqjQQAgJdMyF0dBgCewkAw6H0EAOcHZbLeiQkAmUfc+ubUBACn6KB/g4wNAMecpVxmjgIA2Q2UFcdlAQCVHKE6X3gAAGmE49eYewUAhK3Mb912BgBYkPyWhWgBAJ9hA9RqbwYA73J3qFnXBACkvnNhboUHAFdqLD/3xAEAhDR8/G5wBgBtNuw5eJgGACZ/z5UfcwAAvOS8jnWuCwD12retWQQHALugXzC9TwIAz6F1zJgKBAAzdQoi4YwHAJfB4RB6IQYAZL/RgKyVBwCzK7SRSdsBAHJDmVtgaQQAWJpcceMxBgCPcs/vz+kHACHOSCgW/gUA9bF8XS2FAQAP5Vy+Dw0GAHV740bioQUAkNX/Be4aDQDZdzYETLQKABqWlOFPIQEAy+mpOa7hAAD3+Sa1yEMFAB3pZ4BJGQEAF8lvRJ14BACOt04Hq4cEAEPjjF470wEARhvrn0E+AQCk5l1WH3ICAJq78u5SDAYAEW2ufMLFCwAEbpWRlGoLAKUdE8m6JAkAXCsg3ve2CwBlm40kdw0HAPGL/Tu8iQUAa0Gjaj75BgBIrsHWo8AEAGpYCyaHVQUA/MwSw8kLAQBboMI+S+gCAFEVPPCinQYAe6ZhRhc6AgA48omivAkCAG+XOr1VNwYAt6zxlxgQBwC4B3u3LNgLAPRpdz0IhAYAB84tRygrDQBRfHNRN3YCAFMI0So+oAcAqzatxtwTAgDWvdVA4qYBAN/++PxPwgcAFrxIHMzYAACpGbRu0wIEAFKgFIz2zgcAOdHCWyXxAABqGDHU53MDABatp9gtDAcAAH7tuH2WBAA6Ui/Q7loJALuU0JGVFAYABnDBBPJyBgBTaoEThisLAA7sb59QlAEArKwxytgoBQD6ubhzbYIHALP54JnLSgIASDk2xvrgAgBkzUjkvvcHADwP2hAP4QQA6SCruWyTAwDQbOpP/KAHAKQ1xxWSFwQAIc1rKLkzDgCUnNu6s8oOAPm93344TgcA2Q+KxRNDCQAbJGJWqB8LACrt3NfnlAAAjhGOc/poAAAr7l8KZBsEANQZ8J1wuwYAmc0wSjQABwD0IjYuQmwCAPC1BWoG8wAApoAEj0TiBACV8NvgzUQCAFKZKjGySwIAWFz49SoMCAA+iPJMn2AIABLKobVu6AYA0czvokSLDgC0/p+v0tEIAMNn3jIX7QAANRYpacMIAwBQ0vJI8z4DALuhoV5HBAAAiOFx6OP+AADfHmIyoYoCADs1r0wkKwQAiuDCTAZrBgDTvQwCILsGADGFcXnNagEArbaHeMXGCQAqWdcf8qsNAHmGUxLUCwUAUTEncQuACwBggbE07WQBAD0dmy2vcgcAW06LRIbUBgCoGI3dWM4CAIs8UGefhAEAApNr7+AjAQCa5i8ZTNkGAA9poiJSRwUAs7iGnXiTBgDcafu9w/UBAD8HYfygjQcAgToMaPGABwBT1Pw8XaMKAPfdx83lBQgAI6x4gIjuBgA4azFLqlQIAGrGK+UoXQEAfstRAx4OAwCMH7F0LwoDAAPe1wwSnQMAsVay7l3SAgC4fCYZjUYAAPn7tancjAMA4qEsXLC7AQAzlY51FbADANq3agphNAEAFfXRd+dlCgCkOR5M9fEIAEUmUpUb8AIAbd6d29j9BADMl7qMh1QGAP6w9o3HjgMAImqjvq48AQBqX07lxusFALgOPZAEKAMADbKi2y8QAgCh5lwFBeQGANMypTVKAgUAnfLaVJD2AQDVi3oNHV0BAMuesl1yrQAAhW8Fmwy8BwDY//q//hwFAEn1Tem7SgwAIDHj17vsBwCZIzD1dfYEAFckToOxZwIAiLt4wxmuBgAS1dlee0UHAPsFPXgNKAMAAxq3//yuBAAeFxUENjYFAGV4BwkzMQIAvK80Q0RRAgDoVjeFw7ACAIYqKrfLvAAAlhL+UExeDQAMw+8T3V8IAO3lgMPGwAkAp2L74x3hAwDzCJHWj2cGAMipseovlgYAC6O5j6KsBgCYnxvKt20FAN0YcElYnwMAa521Ck8CBADCY2hjMfoGALBCfqblCgEAMdof8Lt6AgC8T+a5p4ADANTqCCEu1AIAgHVTDw17CQAthMnAY2IJAKM5RX6CqwQAOtdD2w03BgAjtHk6vyAMAJvS35QVEwUA/lKN6SemAwBhVoVBQBUBAISDn9B1kQEALY2LYLJ2BgBHK1scZboAACcQcGMjhgUA28YZwtbEAADeWIb/PfAAAM/Aqf/SRQcAV07TIVffBgAGDHp2L/MEACBux+qr1QkA4+EE4ekcDADbwVS+FW4IAL3IySseWgIA6jew88gEAQCYbKlvVwUEAG+H44hq6AIAz2C5ziOuAQBKmTIZh10CAG4LVjvWuQYActTIFCjfAgDtpArivvsAAOx4EobtjQUAlcnCtqhbAwC/hTGLpd4JAL27I81VtAQA+INIwBnsBQDVMbWWposIAFzFZvKTNwcAAjvJqYi5AADbJSOjDpsAAF58wXGufAMAX0iF3jn/AgB6xe/D7j4FAP0uAumf+gIAVIETLMeZBgD4H70edSoHAM9HSTtjIAEA9w8SSUcxBQBX0MD3za8FAO2NeBvnqQcAiAw7j3DvBQCTszy+M3QIAEIAYZF4mAQAcgFdf52dBwDEnjsBk8IDAMrKOV+4wgAAWU2bqTBdAwD0l+lcwEQBAO9/NIoLlgQA93Rd8RHaAQCt/sAZrE8FAG2v5+1z2AIAbvldTuECCgBLtT68AuoCAGQ1iLJ1iAMA3ek6UYwpCQD/FaAYNlQIAAk0N0NkMQIAryI7UJXeBQDf4uobIJkGAHpz/0lY2wMA+gdHZXPnAgDBI0yX9L0CAL1h0si5swQAKLypsuhqAgBRXBYQggYDAHnQYjNEsQQAuJxSHOlUBADPcr/GmEwKAJnYw5RlSAgAO/rXoxOuBwBmr45BOHAJAHofbrbHtwQAmNnvhaG+BAD4VRBxvPoEADj+Nnif+wEApi11RvSCBQDkTDIg03sBAMaYeBGJFAUAC0Ggkk1oAQCnxXgP2eQGACjavMShwgAAMmm9aUiBBAC4XaSRw7cHAEG2NawWcwUAagnpHeNBBgBNMQqzqaYNAEcEH2/QxwUASToL+HDbBwB4msg+SssGAH05ga3oOwQAZG8cvVjFBwA9RpbTJBUEAB0ankRrWAEAiu1KkH7xAgCOPB2G0uEHALqvoFxKQAAAvm9BKhueDABWbDELahwNANsb156ldQ0AHewfGgJMBwCOf25RJ5ULANZDpwoHQAcAgxHdy2RrAQBD6zJ7Sz8CALM1gqWrGQMA2a3cv5VjBACcml0aLdsHAC9ChQsgmgcAFt1xqr9VAwCqeF/qdwsAAC2CnqJ5ZQcA3zS0UhO1BABnJhzQezIJAKDIYDvXNAQAukOUqNrgCwB2orJLUSwIABcqwEl+jgYAtuhvNJVXBABGNY9sMIkAAPaIL2uf2AYAW+DJTTg6BABFtvGL2tUDAAltaqnW3gcATS/uT0nDBgDUa4ucmCwAAEgVliAJFgEAuk2bNhZWCABGb6yGq+wMALEA14UAxgsA6fwN4T4hCABtHknXN/YKAKrP2ilpFgUAifYxa4KQAQB9SmlnVfUEACLlsff0BQcAmFa8JeFRAwC+e/YaRpsEAJY6LHEVWQcADQxY72eaBgD8z3DvOE0FAOJ8btCC8QcAD3UhjnJLBQAoARuXkJoGAKNjqfJAGg0AvqYSrOkLCQDEQTIEzEoMAOxoAatkjgQAT2+ouL2iAgApaS1rOzQHAKPpjKoE2AEA6UPDyEp9BgB3V3pPu2sFAI8jfGIwkgIA+9csEhqtBQBk41Bupd4AANcqMcjRVgUADugbsVZnCAA9sHt+FGIMAN+/PnQZZQoAtCpoWfyCBwDHyIzjq5cIAII5jQzjQAcA/YJGf7TCBwAc3Me4kc0FAIPl+ZCnfwcAJNjRxsZGBwCkLaV+h8kBAIlhqIN7swIApQ0xSa8zBwD7BBwWgV4CAOi+NErhdwUAK9dNvb7OBgCfMkLkwUALAD6p0f9HIwMA4LssJYlKAQAJsI9LMAUHAAo7p2GsaAIAHL6+NPIGAgDo68unA7QFADVBn/BgoQcAeP2W7qcPBgDGbilNNR0FAMcWO6b1ywcAFAzPswv1AgBaxsqFs/4BADUWyuCYEwIA7lW3tPmqCADyRK61kWsCAMixeo2A3gYAsDBVZ2mnBgD3mE4o+7sJAPMzKziKBQUAPpEWGKl1AQDoimu5zfYEANKB2slHcwEAI1rZ2T6qBQBhZdnH6XcHAKzMBvBYjgIASawsu7tBBQDsTJmCMuYDAJXo5RR+oAQAm6R3xM1YCwCA5AL+iMwLAGrj9LeqIQcAU5lGyYxACAD5Stiu9woFAJn5DZjLEgQA3Cnu2I3nBQBdV4z233EBAEnv9tJdAQIAE9ORw7rwAwDlW/YVAd4HAMlNNiEsJAQAmGCmZFu3BgCFwAIBPAMAAL2uazEakgEAi8Hz2ZqtCgDqmjM4FuwFADuoWWU7cAUAEtYFTZ/6CwArBsreSbAHAPxwuN9+LwIAKLF31u5pBQCvpbDcNwkDABvqeJwDWAcAOice9I1FBgCDREQ1euMDAJl70rf9YQYA5CHWHXYXAwCJYQIwPDIHAFApvMw9CQYASwOEYL7uBgB7jQr3Ac8GAApnxlQatAgA2lW7mUvIBgBHtpgMGOMGAG1w4IWFmgMA/mMm53wWAwCXQtvsFD0GALhw+dwhvgQAeoKEoB59BQBxsCih57YCAM9ddRF1sgUAZQWTwoSFAABZQW/ae4wGAHvZ3ZnpYwMAs65L4txIAADjBeyVV7cCAMlt2sWkvwsAHTeeZciqCQCab7x5+TEKAMQf7jXBQwAA1fIZmRyhAgDNul3CTDMGANoAtBfalQIAoJOGt+mOBADG8yrMS94BAIbroxHEHwYAwC7BmtE+BQDgBLjG2wkCAJKHsKm/eQAAMkLVooDtCQB4XirH/g4HAC2CKtRRIQQA6DHWtuu1CQAFR1mxT+8JAPQNMNpROgAAchxWK7VnBACQ5RACktUEAIWWeJ52ygAAF0hof8c4AADsexZb5l4GAKlQuBnaUgAAKWRlZYZAAABMmm9ZOasHAL+gpJLudQUA7tekCkW8BgCoCzt3pvQMAEe8DgsbJAYAFZMdT5wNDAD0guPnoQAKAM8vGIqQgAAAmLq3EylTAADDhcN4z9wDAKmrXt0CgAYAP80ScU49BADFOvnqZ7kFADEKWMqsYAMAYvLG1V/GAQCr7MIVfxwHAORRJqXsUAAA6mjmYHY5DAD08pJWp8IHAO9mbH6esgsAmdq8WKYrBwAaE/oJHBUGAJwMP0XeGgMAaHhzB+7fAwAR1Kf37BEGAPZkvWx+YwIAj8UhbO6wBACWXfD9DVwFAF5Hz51WBQQAu5h0J1xcAACJw13ZiIUBAPAAqE/y/gEAc2uXMPWvCgBZhMBIWtgIAN9CNpbrlgcAJrbEUO4LBgBAg2z+BYAKAJYxpxr7UwYA+gaD7PoHBgBUUj7IXugEAP2EBZBWnwAAhvySktREBQCIhlI0n7oHAF0ttA+ihAIA/m9w2SxlAwCz5t2te/0GABbzMClHLgcAFHYq0zX2CwD9AN6s7MsIADWp6kERQQMAlMvzQh4cAgAG/gDw5/4JAE8IgZeMIAUA0iTcoWhkAQCoQMUKeL8HAAFT185+pgEAOnPC6NKpBQDl99sD2gUDAMqut5mGIgEAyWuTsiMqAQDp5mqlvaECAEDgHgWUDwAAQJevB7uTBwD9+tTstucJAEL7YBV7LAgAtl/MNGcpCgA/3SX9f3sMALIw08MjawUAptFg4wh2AwAucsjz4AoBADe2GLbZhgAAq77ox3l9AAAS3Qi8nPsDAP9wU9g9XAcArBko/gZ/BADtFZKrBtsFAGTqNQpSwwEARsBrIUBvCAC02Q+bV6ILAIvsfkAmHAcAC0+1StoqBwASbbbDUIcLAEqjy7ymUwIAGnAzBAcnBAAOh/lYjgsCAMwA22HINwMA7tB1V9DDAQAa5SKUQPEGACUtzr5rhQcAHAMvp4AzAQC686eAED4EAAQzfSweYgAA8/DbsJYXBgD11jKcLzwPAL1+U9GOqgYA9DgYyZJOBwACEMqJ5dgFAI2DWYLMYAAA85Vb89M4AAAjqUPCeGAFALIbJJMy3gIAOr2XYH0AAABLqUIIlR0HABfYx+URawQADU/LvotHBQBdHApLBcMHAMvBg3c9WAEAxyidzARHAwAA8rGY5d4DAJ5tdJgcbgEA36+VcAsFBABVPOhkgJUEAOF6ol3vogYAnZ0u4KyKAgDo8GXpWSQAADMJFdNkuAcA2B7o8qVSAgAN6GZQJpQAAKVhjZEPpgAA3g/z90tEAAAGPO2pDcQBADuEvXDBeQAAVtDVwFDNDgC5eedqYLcFAKHdayK9DwcA+R85Ux5mBQC4F3MNjHYGAP9v+mTk7AYAoGCkvEDMAwAMjfsKqeMGACgSobwagAUAn6w0XsDeBgCzwVXx5SUGAJYycm8v8wQAzu8FAZisBQA27l4WYXoBANXcTeFFFAUAQqS+K6tHAQAmMSXyQPIJAIhOMZ7ewwgAXqT8pKUeCgD85IYAmS4JAFFJFDtLKwAA6mqWd4loBQD9nzluF44BAIuTtF5c5AIAKTke84YxAQAuu99/s5YEACE+X51DwgMATWp+/mBuAQAdYpuI79cEAOnTBT8uewcAkbDdEpxjCACyes2QBBgOAHtGl4KR8wMArIEXvmhFBwCV4FJRGXoIAN7ELpzFqQcALWV5nvDpBwCGLfIi5KMGAItsgzuOrgIAMq3HX3k7BgDIX544Ao8GAAZ1h7zxWQAA7AxBDpkEBQDirv7Q15sAAPAy0IP+6AMAKdHv6I1MCAANIeYGfMYJAGkUf483gwEAidKuzlJDBgBYYpqJYC0KAJSicAW5FQMA8SWpCOEMBgAJyVMS9u8GALBwLQ7vAwAAxPqXt6NbBwCW0c1wwNsBAEdMU7GPbQEAKvqDgUkABQB13iPEWS8HAHl3uAdNkAAAuUD5SGYtAgCGPoehpZcJALtUGsTkBwoAz9ZLOws2BQByr+usCiQGAJyRut3UHwYAmVa1kenYBwBsxzxHMRsGANYx5jGWAwcA3cH7QyE+BACglaJbnHQEAAZfS/pGeQMA8VFaq8UkBwDz0514M1YGAEDbOPLaawUAnzudwWzTCABhItdwROwGAK6pGHA9hQYA68jCTT6qAwDl4QcVozoIAOszNfXjuQIAxQaoJ9etAgCjFc7IVWkFAA4pCgdPjAEAQTfYhkrSAQAfztT/SHYEAJ2eg5GVCgYAqxeB89UkBAAOwRJpxCwEALSuyR0mOwQAUROVbIs9CQApY49+AcAEAMT5U55VPgUA6m6IRgGyDAA/KSReTSsIALt5u4gZHgMAq7yzRi+4BwBBe4LOqPcAADBxFxZY4QUAdrL1XAUmAwDyjdEoy1UBAJQWoZwNwwAAGTGrJw4JAgC2SXpOYggCANPlmoBsegIAQWk9xAonBAClWVbZTO0CAPkodbMNXA8AM5Is/bzMAgDC2AM2UCEKAIixDR/N6wYAdBF9S+tMBwBcT99oYdUHAIrRbxd5vwAACvZPF2fLAgDQ4Qs5+c0GAD0rfpxRjgAAgQil0sNTAgA9M45EQRsCAA+Jc0vfsQcAjPX4BxgiBgDlizqBkvoDAHJVjcOY2gYAj0ZUVdkeCAAtNV0kmIYGACSisrPg8gIAkhwsomrFAAB4svE57P0FAAbxx/UKyQQAxY9l8s4fBgB6GBgqhV0BAHb7mrXbcAIAq5LPCxLbBwCHQHFdoucAAPDac8T0bAQALYFJ8aduBAAnhAppJQcPAPp58Ok6pwgAKsZhRJLdAgDM2FCuWgYJAPnlxJ7tJQUATGhgBtIiAABoezlwK5cHAGX501g5oAcAtU7RvIeTAgBXDSDfJUUEAIVD6Uz51wIAt+xwwQANBgDw2PMDBYsDAM7xZI4ZmgYA7crF3DRECQAffGafkMcKAHW1H52DGgYAdrvKADjyDAB+Jr2XJlsCALx4GtngsgIADPLMEgqZAwAiJh/hwkEBACAzpfrO3wAAOkmSap42BwBkaJgT+z8HAKwT97grKAMA75fyeO2cBADvHWYncGkGAORU24MGQgEA0FrMwW+7BgCdZpHVyDINADJsqE15rwkA0iRt2OngCAAHHRa0gx4DAJfRnSQevQAAj1YgGMsLAADUMIhxseoCAOaXaYH9lgMAilC/vmMLBgBPKwaeEscAAP0SW0Em5QEAPZIn/aBhBAC3pXD2rYsBAFDVYuvxXAUAP4z1feO1DgANxoY587wLAObqXIO4TwwAo3GOwd6ZCACfK6a6b6UJAFg9wmUQEAEAD4szkBKqBQAhdC6efhUDAInUFyBx6gAAiXBFVqZpBgDsyZ1cUGsGAIdS44bvdAcAXpXARNnRBAAgK9c5TC4FAFiceTZIPAEAgNCLXWr7BACbWAhJ44oNABKve5dNlQMA3EF0WeoTBABbjtyH3AsFALnhs1pGXQIARyjsJ/74AAAGT/Db5tYCAHYyG/yMAwMAe2M6yYBvBgAR4d9ugzcFAA0sezUCvgIA+NTIWO7cBgCSYR1YMtcCAP0lR0RW3QEAh8i6CADmBwBSGHw4XD0KAKcz9fFdngcAz/DF8fnmCgAvOvZQpKMLAH0SYjP4fwQA9LGCrzmOAACrffIuMogEAKShojg3lwEA9xkikUXmAAAnRjnYMS8HAPEAopTSewAAxnTiAL5lBgCLNrbx6D0EAJo6OdnIGAMAhdMdqymeBgCsa8ezhQYDAFlI8jfPZQUA+f6Owip7DQBPWTIcpAkNABn+/yoDXQQATt5sm+QvAQDxfDK8YxYCAN3xaUxeigEA1aF5xsckAgDpJfmm3G4AALh35mODjAYAz/vkJfoMBgBOQAl2wcQBABGKMgL/WwAA5BLFDd2gCQAPzV+/lAgJADacPwFJKQUAxzVHug/1CQAZ4N58J3YFAAvgyiNwEwIAxibrmTVaAQA8K1EhcmgAAOkkCDrLUwIApKI/zLiABwBfME8jvIoDAN4DwbuAogcA/l1pNqiYAwAailJBr9ADABsnJodB/wUALZW2E+hHCwC6PBzCZGgHAKh0zdtJ4AkAm3STD9a0BQAMCsq4TZ0KAJ3biRcMCAYAMace73y+BACAgJ12DfQCAAOmREx9XwMAllrCPaAGAQDQUzMzrwoFADW7PGGatQQAdprhwN8jAgBkxbIrHn0HAMtSEKU4qwQAicDdX+/RBwDZ2rnr6r4HAPusoAvTWAgAj6616pLNBQDSTrBrHAQLAJPVaGclKwQAT3tCWYToAgABB2N2OCsAAOXqBdR4SAMAigjcGt2cAgBI4VbZ+fICAP7BZa3mswYAXZ63cgmwBQCvXUwjjT0FAElAgda7BAEAUPF/1l+aDQAqNdDqmKkLAJmvpF/JgwgAbiYB/Nv6DgBxsA+i8gQKAGft8Wgx/QAAPkp45w27AQB3BLJ4y0sDAIIhLm6ipAAAp5JwxYy+BQB5sOswPTsEAAIZxqWsVwMAVSTWxXC1BQDHGB6esg8DAJEnfLEPVwIARyS4C1WpBgAlIxoK8hEFAO6bI9ckkwoAwxZ1wzw0CwAX4B35xUEKAHUVtix/NgIA34dNwJrDBgC95deLldQGADIVimP0ZgUAMDClXrbcAwCqbN5AKRcAABtFZy5bBAYAs/w+RgdsBQCRbv5ri3IAAN/81e0ghAAAuxD0BE7DCABqoNDA7UQDAG1N2IZU5A4A9GM4yy5ODAC3HTJPZU0IAEr6YoOrIAcAv9nNR0OcAgBjhF+tmOcAAP4Ly4vx/gQAdsH7PqXZAADVtb3dFsEFAM+rpbu00QYAelOlSIrSBACZCwRbjmsFAJGJYfKkpwQASyo3r5GyCwCXRP4oMA4GAAlqT8p7JgoAQrJCwu4ZBwAOPiIUY6kEAJVfsV8CGAcAlP5xg2uNBgB82fdIRIADAIBCeP5mJAQAMd3NxFAbAQDW/6QIRCcAAN00266C0wcAXTjOyc8KBAAeW6SZuygGALzm3OS89AQAbwudxG5hAgAc5mKEXfkJAMVZkZs+rQkA+E2gdaSbBwCVFVbuLAQDAIQlJOJazgcA49RTsV7SAgDJqZvQ86gDAI7rBA1p8wAAwHFL0c0/BwBBrJtEeXAGAE9IIUactwUAjWsV8mkQBgCvEDtXJusAAM6pyUDniQMAFawOV/Z4BQA3OZwz8kQGACxslbdHbgYA0FUf/jJICwBiYl1eQlwKAM653DSuswQAn6wVGml8BAAMQF1u4BgDALE++NkixAMApmWUN0UVBgBu3tfxpgYGAOcHYcTA8QQA2OX73LEpAgAnE3sKxqwDAIRUkQiaUwYABkq7FNTbBAC42/FJCJMPAO/KZqTFKQMAm+tPVCTIBgCbAe8gU/YIAHP30sN0HwIAOr0IjbgkAABRQQXPeOYGAHx0LicxNgQA0VysSl4cAQDG4P3KsdEGAJA6MGrHYgQAm/88aU7KAwD9hlfULJUDADDD3nu8ygQAidJ4P494BwAR+LMJKJQNAJvC+HcylwUAZ/7FO/kQCACxrGWBSe4HAC4KnAgklgYAcwTnyF8HAAATIx2rhD4BADuV9u0LwQIAyCEDP7k5BgDDoRGR4wgFAHovkQ4SkAIAQ66sZPTLAQBXYVfpc1MBAGBbyJP07QAAAEF2hNLEBwDsrAa//v4HAABBgnr7mgMAZf3nR460CQD5HU3FAEwIAGham1lYgQQA2dVBvHX9AQA8Xakf/NkCABG6DvIn2gcA1BkwLrkDBAD4XEaLgS8CALgJ/x2QQgMAzYPGXVkfAwCC1l90V3oDABcmqxK7VQMAGHOMWsfaAQBgNELVebYLAA1Atrf8uAYAnV++gzfHBgAqBY6vjlEHAPS7k3TMZAYA43QYdpQ9AwAT9pYXnhcAAH2G4jUFiQEA7IIhE7j5AAAybH8bxFkAAJEUUwaHngcAgrU8ZEfHBgDklNQKDOICAHWxu3E4fAQAsGZQyFBdBgB8HzZTdBYGABKzi4GjawgAIXWqm/KvBgBIjc4C6o8AAEhP7HGXUwQAKMqtizG5BwDFFuCvGQ8HACONYLF77gQAaWRXuIkLAADQ6t5odt0FAElwpAttCQQAFJEhl1knBgCu5meK2psCAF33dJqCcwQAyQI5rTpTCQB65BFr4N0JAHYLk9G+hAcAZ8i5kgrICQBMTtS0aMYGABjEeUZ12gIAWhC+MUwWAwBf75grrB8BAFaSd68aWgMAPIPEhIYHAgAMgnh6Ic8AAGnn0uckUAYAKqjd77U7AgDG0zK21J8BAKT4VGAaQQcAtHWxGD3lAgDzSiBUcj4LAMTEodXXvAsADl32KsLHBADDWCSHmuwBAG3InbkynQUArKkiXgesBgBxMxEgkgsDAG6WOKbZfwIAE7hPVzbBBwCbUKIA1KQGAByXVhB5QQAAXAduhtVVBgD4TebzKzACANZ8XIrYrQMARjA5WdSYCgC3kD3L/gsDANb4Peq42QMAeRVRlg6QAwBqQBoToRsGAPLcNbZwVwEAcZX3g82eBQC9fwscRtsCAF80galCOgcAecjMn5JJAgApkJUW8aAAAHo0sddPlwUAre0IHMzgAQATH634vXMGAI69yxADYgUA1oXid/S1BgDIbDLske0MAPyjA3VT1g4A1Ig5dtMmBgDOWDZvhOwHAEPWNElDkwEAUapeRKLUAADgb+eKcNAHAOHHw7ZHmAMA2dmkonZ2AwDHLqIdP48GAGtzojmA7QYAdTxM4H5iAgDR50emkOoGALmZM3Kv2gYAj46trL8EAwAHixB9kQIFAA/dpmwXQwgAgx0sjxXVBQA761ieRLUKAEe+PetidQIA5wsXtNeRAgDhqN9nytEFAKKY8mGAqAIAfWJxnk4wAQD+nNxq0hQAABNvoRtp8QcArG7wKBjnBQD8//AH7UkDAN3C1+KNRgQAuwdj+MbYCgByCYWhaygOANNEhLDc6QUAsmIzVGqpCQBGMuYnZNoNAJ5GGZReNQMAN4rquHuEAQBxm8+IZf4BACJr29LJsQYAS7T/xufMBgDKIqzeiMYEAFID/8N19wYAuxnkPmBlBQBGHMZWRFQGAPJ5/qspjwUA9s0Ocb9kCgBqiSeFxQgHAJQzxebqLAwAaSvoIRs4BAC0hUFyk68GAGg+542rzwYAIb3Uzu/mAwC+DVAJZgUAAN+FrSR4GwcAQX9KnGJ3BQCIqMYJRQIAAERmLrFqaQIA2IBLf6LMAACeERvxwccAAOzKsFvyAQcAE8G+fNn2AACjk3z7l84MABooEVqDOQkAVZHaepAoBwBVCQW8pSAHAO1sYeT4sAAAdbgPtcTTAQCYAdxzlvICAPoPg/Gw9AUAQNz7K8ngAgA1WoCbQwkHAIeBf1VI7AYALDqhG02KAACu+QuKNHYAAO9Escu56QAA276xXdWbBgC9MfdHTuEGAKwOJ0deowkAjd94VCJvBgDTz5FB1GYLAK0gV/uP1AIAd9+hIX97BQBFBrr/DlUFADGpmEBq7AUAN/OzThAhAgAUjLzyQxcEAMdzh62wlgcAm2i7XO6fAgA0hxdcZiIBAJPFa056FgQA24/O+GUmBgBXmMUaEJ0KAPufpbs72QQAFz83l3h7CQDstww3M0sLAAAn9nYonQMAh2wdzc4BAAB1dnQRGvAHAJCBoaUNNQIAUiXit4uTBwDM1oGG7pEFALh56rSwnQMAQgg4DyICAgCs4EK6dvICAObf4sZvFwEApQ53SYniAAByexSInlUFADDvY24eXgsAbv+nmhBbAwCQJk/lo/YJAJthnFvQbAcAlRaQsFSWBgAnf7cQN6UHAHWB0qcemgcA1XfGpMOPAADqNAfTmcEEABTMmssixgYAFgIDVQpmBQD7EZ8Z8WgAAJBrEdD68gQAJbY7tx3ZDADEEoFTgl8NAN0VmCda2AYA+ZzNsLdABwBOlPKVGUULAFROrpRBsgYAl4jt/QojAgBxUH1hEjQCAJuWNQ/T1QMA73JJSkhFBAB8feqf0PwCACrSnmsSlgIAsgUqAXGhBAAjVU3HktsBAIlCYMqJCwEAW/BFWr5BCQCmruyLs60FALvyQdtG/QsAOM61u4jUDgDT8J4dLX0JAJwoGJdJRwEAq8fkZ4qkAADjr0tUvA8DAIrlXzEBxwAAdXtXjYcLAgBqPj8HGK8CAP4kDULqOgMAlP/0iwCYAgAelttxkVMDAFzGPPYUIgcAtik79Lm3BQCzo+4x6kkJAAgWWBN3vgQAmF45YHnYCgBToVXISvIJAJOmB1NAfwMAnLbybOblAgBTnK5mQtgFALlT6H3r5AUAHBdYjPT9BQCqBZWOMggGAJrEHYSCIQIAByMdiZbsAwADLvL/Y/MCADmu4jmnCwAAJruI6vUmBADIdX/nkjADAOcZ2EA5pQEAE4aBTy4TCQCMUX3elyIHANaQh1zemAYAJetbVLhoAgDf/paLZNIGAHywHa2IeQQA13rmo4MyAAA5uQy+xx0EAAQJEGZssQEAbcbLIEyiAACBhuTv6aIEAHFihJYSXgAAUEUsJMi7BwC3NTsQBpoNADIg80p+IwcAelOzGkImBwCMJThd8owHAFpJnC2z7gIAUJcvdyWeBwAjvzuDR9cGAEnX1RbYzQYAmDbByQCcAwBonUgxjmsGALXiEH6FcwUAchSqFug7AQD4S63TZBkEAP+zdiC1BgAALQjOuRZ+CwC4PoVXL4gJAMQf0Kye0gcAFee1WWrnCgD2qWGVLt4HABx4lZ3hzwAAPEUcYswSAwB8B9rmrEUBALjpnO8rkQAAdrxDNH7VBADLXqW29NQAAM47c7uw6wcASQUgBWq6BwBpIOLk7fYEAAKm8QqpsgYACtiyWyTzCwD8bvMg9+UIAGzAYM/MuQsAJXnzI+OECADBdoIsgWUEAJce5pr89AMAJC366we8AwCg1Fy1RLcDAPMhV7JTJQcA0xKdTo/9BQDZYhAqsr4DAKjJgjsGpwYA7ZfBXaOlAADvPaUGDMgDABbLscIyWwAAgoHVeiykDAD+nnl+ZsgFAKFQyHReLggAmYZOYdvwAwAwZ4WkcRcLAP2oTdLMXgAAGHnw/buABQBqPIeGNecHAD75d9/tTAcAcbQ3alW1AwCC1E3hJMUAAFbGlnRFgwIARc22z2utAAAUJLDo0XUDADOnJ50H/AQADcWGDESLDACFO8qckjkJAC7fTOTy+AgAsaZ7ETKEDgA7risMF0ECAH8vv4mwOAEAOeo0/VugBAD1XpJMkQMCADxO4P9/SQcAmK/sfFYkAQC0c8QKhqsBAP+nhnwiwAUAd0TCvxIbBwB1MKhzpQYAAHDIZilh+AMAAI0ENvr8CACCs7szcW4GAHZWpKhCSwYAz4WaT27qDACgeOjuV28KAN4NKnjJDAIAs6pwME5dBgA2d1QxjrwHAJgtQ7G/ngAANpdnd6oEBQCx74dW1SwDAJVhL16PRAQARQNGnZFoBQAnGq3gwjQAAKPb2UMZBAQAyqpsokN3AQBkyflWkYwEANCaHo0n7wcAAb2njuUMCAAMgCkUky0JAJbM60O67gAAePiVU92EAwBy0jUaM98BAA73Sv3sBwIAQ2iXHQpCAQBPWTfTmXcGABhgj1RHFgAARfF4Vc5/BQBxKhQMIgkAAJo1FCP5tAEAsWaYpDAwBwB5JgvpK0QKAM59lNjTewcAKCBVwVX7CQCh+VYdGf8FAFEJFYmdEAQAy0ctLb0lAgDqO+eAwHwFAMsfcnUQ1wYAMvGncrU5AgBokC2sM9QGADNwpDD5KwcArQ6i9KxPBgAqQLmi92UDAPNYpybFIAAAdsxC8FnvCQAl3XZJwrEDAHJisVxmHQsAVsVw5FaGCgArYKXgz1IMALzb2J74NAAA846NlI87BwCryiPTwYYHAFFuJqnUOwQAE1NhxKwqAADfd3hkoPcAANTwkw/M4QQAkBHvJkfsBwD4EvWL1b0DALgEs9e3zwQAEu+Jl8KZBgBQvCHj6jsGADW7rUDDJQsA9SvkoeFiBQDTNMTL1LEFAP51m7hsPQQAVg6QW40zAwBTGlN9Mo0DAJ8b1WFcsgEAdZCzIkZLAQAmnwrMFSYDAN+2nLkRdwUAODzpFJymBQCZxaSAiegGAJKFJXGP+QIA7qZUT0SuCgDBxft6ORUGAPv484N3DQ4AuYbEX2eqCgATdp4uBtgJAFaeD7VMpwQAkgFkwtExBQDSf2ydPcAAAMEQZhXNfAUAaoCdJK6mAwBafJCphdoCAK9M7CE3sgYAojpopNPSBADv/Q6HxvkHACXvis64mAIA3mUhCupyCgBu0D7veYEGAB6s/sC54gwAumMbCynuCwB8OoBxYroGALIM9+9TeQIAUsUOriJPBQAkJy6pPZ8CABi9IgzKQgIAztUEhIpLAwA1M2mDtewGAE2437927AMAT6BWz5XIAgBSTdVJUTUGAOFl1L1iHQcA9V73sdq1BQClub4M1uIJAFb+XRfCJwUAH/WPK4qeDQCxYhJiM8MBAIDfeNMozAMApoyW9EEhBwANbdtraQcEAPv8L7Jx0gUAcjF/MV9NBwCBytlnVOUHAA31hjFlpQYA8S3m7IixBgBxSYQ2bcYEAJ1+VMS8rgQA/bVUc56NAABowW0LdWsCAMmsAR6IYgEApQEd822WBwAdmtydvXMJAMkBbScbBwAAXgKOkdiwAADr4p6n7lsHALhNCYQpyQMA26OVv4/YBQDfclj+Hg8AAGolGCOH2gUAYFljgeucBQBkx5N284wBAOoZO9EcbgAAUwNbnmKvCwDk6Iig8QQKAC2o7pz8DgkASqMvPIaJDQA22KihpvMHACNvFm9RrQAAGshXbfVjAgDKOEY4IjQBAFAKr/EfMwEAFm5SAwYIAwALgD1dOUQGAPzevj0guQIAVaNW5oyxBAAsGLxmND8AABPl0t4PDQMAPUe4aB6XDACV83mXzCwFAMhVgq4E6QsAOJPzRq7sBABYHDWEUGEMALMzEvIaTQEAC5yziRneAQCeb2/caSYFAMc/jLI0NAQAmcACQiGpAAAuoLmuwBkAAJLXlWnAogEARBxXsctkBgCygPo2B/8GAKVcidKgvAMAvwHMnraOCACM8y2RyLQNAA3ywot/6gUAr6/KFuUgCQAn3zhAi+oEAKRiXTy8MQAAHghMD/7ZBwAs8mcU1T4EAAnRHgzM5gEA8eja7R1jBQAC0srxCkYFAF1l0J2RtAAATMEYfWnEBwCkoruQyDECAMpCBZPgTAIAhQvz/VWhBwD5h9TlxsYJAFncSxPhSwoAMW8ycFlACQDzJHOKkkkFAAbBBv31kAAA/UMeArGrBgCgEdf6vDICADd/BDzBpQMAbaAoPE4dBAAuGu5jpzIGAE1evf9L+gYAkke6pjX9BQDonekdXrUHAM8N7G22kQQAoWTa0I5KCAC9bglF/OwNALGItJPu7Q0AjrxRGsGzBQAYcAuLa88EAKcy6sc9sQUAHhNz28KPAQDjV48fZeMHAGWpXwVWVgIA7oUMjTOPAAC9cxqZIagDAHBYj0HmOwAA8J6sjsHdAQDCjZme4EwFAHiwLqjUMAUAi7+abEVzCQCsDRAVIIkHAMv+lUDhPgMAZAl61pWtBgD7ywB+PtsIACVI+eEwNgQACUBrapXRBADgtfgt/hMCAOaREaTjXAAAdwHxU6deBgBjYwniPvwGAKxnbbk27AcAsVgHauwQBQAJIQLfh+0AABoeksFOKgAATHnP8WJhCAC4Xv7K3SQLABcyRuDVGAgAjUKSkIvnBwBnwN61Em0LAKK4JDuaJQYAnAsX9LWIAQDrXeHewIEGAEV082Xm3wQAgCcRxUPRAwBXRRV5kScFAE1CQQePnwMAPZJXs25eBABvdNtemywEAIK6hXhR7wIAUS9bMPu/BgDdEteyErEFAOLkT5d0VwMAo+OWevhKCACfswspaHkFANyuWIxOlwcAxog0CH51BwCLvOcqxgEGAHSr7MJwUwQAOhSrj7fxAgAB4SAKQ7gCAOP+iB2epAEAlk3OR7uLAwA31IS65/ABAKrCXeND3AcAGJc+J1wqCABOi7LfySsLABnb1fj0jQQAjwJsl4dMBQBQLdiB+0QAAMPZfYhlZgYAsrBqCnYpBgBsPiTH5oEEAHf8RnDjlwAAzFhnAXLvBwDZ4wepxRgHADs4a4zJuQMA3MxeJe0GAABZmiI4ZZcGAA3D+SOY9wcAuof1aPAfBABTzRsZCsAJACSeIJxvtQcAvqrMXx54CwBswDEEm0oGAOgTtaM50gQAZhAb9SOXAgDD2QTP9EIGAHqboFoJ2gQATXg9N+CkAAAZKX1bodYDANalRlCnGgQA2tPCHnWRBgDEIWerODYCAIPhrNCncQAAMUThIFI1BACBOSgqNuEAAFSWNdh8dQoAjw2xes3pCgB0F3bPm8YHAAu6h8iqLQcAYNpdrPS3AACkmAQs2r0DAGABGKpnTgcAp24Ux7zDAgBfKegE69cAAP6gbx7qpQQAYGxDXGNeBACL0dSo9I4CAMoqMqep9QYAq0TZo+vUCQDk3PMVDxAIACR4Ng5wGgYAIz2rkiKSBQDT6A5ouSoIAMXGQS8MAAEAdHFz358hAADnfRJ/chQDAB64I30n5QcAehQuGuKUBACaDeXdhYoEAPQ9STT3wQEAiWiGZNt7BADsjo8EfZoFAGukvmzXtQYAIiV4HhdBAQAffNombYAGALmaxxsd8wMAaFGfRSCfCADSPcBpuG8BAJTZDOxsVQcAClG3A5rrBQBxy5Hd0QoFAEeKtIBXqgEAd1JoPzOuAABiCbYzlxkGABFlJnwVmwYAyvGT+EBHBgCE9vsIpDoAAA33uDge+AMAEcgXXzV/CwBagTRT6HoIAI7k0t2r4wcA5UUfvuoeBgDtzTQtPq0IAP6v2X7MDwEA8m/psIwkBADiclERHDEEACVpvxzUyQQAUE8Q/BAFBQCdJG4zxQ8EAOEt+zlmOAMAeHvRcfi7BwAEgH5reV8HAKEPv1jBJwEAdLlRrsSPCgDT29K/iW4KAM5ldqAi4QwAwgU0ILHKBwB9Fp1Hgu0EAKJ5mC5CfAEAw/7IRlmKAgB3K5EuszoFAKXgn6BNtAcA9H7Qh+9UAwB12cVgIrUDANwfFzZonQcAu9RA8ZTZBwBUGFYExLYBAJJTIC3ZAgMAZPHg5LZvBAC3ZVKtlzQFAPyGE6Db6wkAO2qzDC8wCABsQuv1xe0IAD0opLyiwQMAAi+7xzA0AgDCi7Ub6qMBAGFc3mNXJgcAyvF2O10OAQBnjtpT1r8DAIoqyD6VhAUAe3CnjyheBQCBHZPDXzkFAMthE8VGWwQA0eN/it1NDQDSGcZBzM4KAJBNrGJlOgwA2L2nrKXvDAAhIfOuwMENAKF/TzG/KgAAKBWKntGRAwDHX4kT+qIGAJGl6t2OnQAAt9w2+nsXAgCP23n6vBsAAOFmNutL2AMABCKBHZIMAgDOMjs9hN0CAKvYh5NhrgQAg/tbmER+CQAhzCbGMk4NABeB8y9BlggAaSQa1kGyDgBCuuWrhVYHAC6jRFOq9gMAuxEPaIOWBgCqI/aBNUwAAKXLdVivAQcA83uxkQ2gAQCy8mHrMwkGANJNKuk/GQUAPvRQpZXZAwA9iDq5b1UDAA47YptSNQEA64Mu4rwWBwC4PrgwAT0DAKyv0LoqlQgAiRvTTvYJAwAKWVGgLpcNABjV0a3X2wAAHiPiI/gZAQDifV5u1lEEADj4cJnDAAUAo1ymgVubBwAReI/cIKwEAPoB9amJlQIASmtq0hDYBABZspYN4O0FAPMFWcnp9wQA65lSNT1ECAA47lp9fZsLAOs0L5pRkgYAeM8kSUDkDgBJFErsLpQJAC4wgVe8SwcATOyBuzUxBwA8SGEbZ+8HACnXzBRGJgcAOOaSrZMZAwCSSSOuGVMEALVP0kedIQIA9mywiETwBAASSnKeqjoFAJzvFFOmoAIAJ3kcPM0aDgDleYe3RosFAPJ6vqyaNgsA03QwdLAJBQCh3rY53FUIAMIn+fd/kwcAtqXGFPrCAAB80G3bvVYFAAjRecGs9gYAwkeGIW7PBAC2W43CfCIBACN29b/pjgcAOokfJLKMAgByZzweVFsCAKIKcQejIQEAyYN0xz5xCQDK+tVyBfcGAIH/Ik7zXgoAhxEUT5RNDQDSzqaUuycFAJdKA59eXQMAm7yFlwYmAQDwT4XHTkcFAMpIowKjlgIADqTHdvwzAwAuSFuZKpkFAMcqAAfHjQcAQRfQlGOTBQAX7xoopPsEAHoKsmmQuAYAZNvHtYz6CgAPqCqY5hgPABoaGviVngsA+mxk85TnBQA5doowPUcIAA0icGJBoAIAJdBpiyRfBwAnamUWvMsBAChn4tb/uQUAPqc6EMI7AgAFnlgDJnkGAF1ZkpjbSAIACC2tPKUGAABzuvdQAQ0CAEPg/Tv3AgEAmhxRteDaDABV1OD/fyUFAIAh69EIQQ0A+a6bD8yWCADppF1yvfYDAMZFV3+ruQAAYx3S+PDKBQAr6gikvt4HABZtiZPbngAAwKVe0pdlAwCsWGAQe40FAGnuC9L4zQMAXgFlt0wKAADJfHwzMmgDAA2mncHstwcAiPp8p1FKBgC1Dcpw9JwKANiYCG4LtgQAx+b/3QRdBQBcv2HG7TsIAA1pXGk8NwIAGM8NUsjABAC5lHRLr4QDACUioo5KqwQAQxdg11ojBAD1dYkHDcsAAEsMUz4xkgIACaUkkbuNAwDxEVpl0FADAAbfDCvO5wAA5nBL2d/+BgDUv0WXPzgKAADDxCeuvgQAPz9qQaRaBwDOrjhhJRUOAKOFjMQ6ZAQAkrg1J4yHBgB32PQjNaUDAJ3ui+0EpQMARvvYpeBmBgANy3BITvYDAFdlbbFIFQYA85Y1d2GiBwA6XSdfTXIHAE1RDYG88AcAjRNyc62dDAB0ENPl3kUHAOLbf16lsQcAoW4Xj5i6BQBa7N0HqdMJAG8T9CakawAAILcGBvzKAwDanDWi8BgFAKfsb+Tl+gUA7Y7P2/jRAADcgdA+MZMGAEIXkGajsAUAfsqkLIcMBAABngCUgPEGAL8xSrQRAAAAXKcKamkfBgDKQq1XCosLAMj9Brea5QkAzL9u1AgTCABQKC2KmD0GAAxsxj9soAcA+0e6wbrJAQCOA3XFNTkCABOcxXG98AMANegW2UisAwAuI72vUwcCAAJg0B67HwcAOq+kR66cAwDC2TQLfDMAAIo2slKtPwMA6M8ixNDIBAClcVkntGAHAD2tHLyV2gsAdXNb/1HxCACmkMtcNcwDABYe5MXGSQYAgKrm7mcGBgCQ4SsYnRcEAHlpflbZUwYAbSWaQg9sAQAxkT6QQ5QGADbd+cZKbwEAU5LiEknqAgBd0mg+ZLQCAOe6JvTqMQYA6A1wo7l1AQD7SKoAX3wHABcDyoV3kQsAmJPHsqlaCAD3ZfbH8jEEAJ/+ZtoQBAEAfda03IJNAgAtdRcO/uYDAI+wyx7e2gQAkeqxSJZZBQAZe4+FRGMCAMBaKUo99AUA1KxSXKdCAgAQDSKARJMFAFMS+RVHsAcAxrrmxIDCBgBudmGzo60LAE47XBLlLwQAIqxKTdgRCQDdfKXPCo0EAEOu9qwovQUAfZBWj6tvAQDy1RgSsawHANu0IyDgHwQAZS9cvzebBQBx5qt95CYHAMH2RudF7AIAhkbHUw5YBgB0P2cEoe0FANM2Exk0YgEAQIbzH9acCQCoG7TExmAIAG42pwz3XAcAHgFs8agYAQC5A6IHV6IEAPZ/JvbemQQAPHcIgYVuBwApy93FypMGAPSfCtARAwAABV3N/v3NAgBq7fZTimYHAFYlFC66AwMACQnBhAWIAwAdJgoAIP4EAORI0pYYcgUAO9rQoZFQDQAKBcHHv/YEAL6pLs1OTg4Ab76L8rF+CAACS/xakzwIAK4bGP0XVQYAbYF2LHflAwCKiUCWGBkAAJl03oQq7QEAwWNP1+14BQA9DCtJxnYCAC6Tv0D8mwAACzMf8eiIBQBuwk1pbtEDAIwokLUq7AMAuNEyrgk6AQDktFq4HugLAB6uPKSseggAc2NS1wUvBgC6rcZmv+EIALl72OR70gAANLRdIydsBQA3LaYObi4HADnobtBMZwUA/ACiJVzdAgB+iCx56dUDAFW8q01yGQMAAAhoeHy5AgDd5jTd368HAIiuNYtUMAcANOPWoUsJAwALMOOnJuEGAMX7/K7AiQgAgmWDH6HuCgCDh30nooUFAO64qMujUQUAhtjiK0K2AwC8iZZB4TAGAFWppwc7ZQQA2xG0QzQEAwBiidQzgl8CADH0rwSPvQYAEmOa/Qf5BACb0jfH0w8EAPkOlXhiZQcAis+G6qNzCAAtnPur4uAGAO4z6jgqDgYAGP7zKSQLCwA+YUtIv4sKAMDIH9VZzwMAGEfe1qCgBwBLt28+OlwFANVPiF8TUwMAhBuMChb0AwB8bBNvXC8BAEzeN6Lb/gAARKu/zrx5BwAJaU0/qa4DAI8YWLOc5wEAboHg9dhTCQD8Ltu7M4UIADCUEpaXFAkAQoYWNm56CQAendNSq3gMAPHj9+7DNgQAJgAfwtP/BwCpLQrye+cDAN5yhPy/GAQAs6OzUXldBgBZ0VKS06QGANTsAFnjkAcAhneXvyUHAwBToDUWXAoBABKiEaSHbQEAcAVO1eLVBAB0Xz+z1+UCAL9+iD/epQsAtjlhvSTvBgCmpXe1kPkJABViBkJafgUAdzaYRIuhAQCPbx7eUuYDAOvYLuArUwYAOF8WyIePAgDW9+gbrU4EAGb0MU+ddQUAQ3n0SYE3AAApTyvjO58GANY0Ff6CWAQA5G88lCmZBAAVW1RycDQMAMTn185rIgsA3ontTBM6CABeQM5D+NwHANaDeXVdNAEAzcw0QvUiAgC024o9SngBAMwrjO6+bgMAb2KPW/6IBgDAMkdKSNYAAJItU8ZKuQcAD4VUhxt3BQDIYRTf2Y0EAHEy54eWcwYAwBoMyJ3MBQDN1IYUZ4MGAHOBXhpfbwcASt/59dPVDgDm12iPC9oHAKZ1VjgUIAAA7x09tV8VBgB8kokuo34DAC6o9WimWQAA3NShqxVhBAB22rXDUxkHAIF60zMiZAYAvbF2gGXJAgD/EDDmgaUFAHQ26If4pQUAuUOmoNMoBgDSkwxk2BwIACsP18qwtwgAvUSBqU2GCwAbXS2uNz4EABE9oXDPAQMA7JEYuqGmAgDgOj/7kfICAFLqS4F7GgIA0URuZZtmAwAz4abtBj8GAA8HWCc0MwIAdcCcReCYAAAbfGytXt8EAF791GweogYA0LKZZhIpCQDnPWCiEe4IACBMx/XCCgYACGgZKhmbBQDoAXCwcVMMAF/mRjAKFwYAOJ6kRhpABQCoxGFV3QoCAEae3u20qwcAXxkan7+GBQALefhejQgDANu0/CYhjAMAw+NJ4bqFBgAw6aQB1rwAAFIOeQP76gAAHa51D16ACAAnCoZZzGQMAO4LsLflSAoAdI/vdZbZBQA1VEw040oEAC8ESDfBVQUAwDJCdUHQBAAHaYYwtCEFADmc+0COMAMALKB1xqwJAwDuQ6W7uYkCAJ5TKC5ZqwMAOtjNq4JNBgAn43LBjscDAEb5tyFSLQYAKXr3OibUBQCwroki3T8KAOu5fvdk3AcALEA4g9IbCAAhOTilKU8JAG2T0BicKQQASYpBg0GRBQDVriHHGCoFAG2XgrpRsQIAVMdL3u/ABQD117Il3H4BAO4bCKY2cwMAw+WHiDG1BwDhWxpJbZ8EAOC+x2Uj5wUAPrMILwY5CwCxz1fm87sEAGdZbvX3eg4Ajtaef9bbDAAzt1xVIAsHAH8hcUUH/AMA62orm9KgAwCd5d3MeGQAAPrdGwVNXgUATnvEBBF/BwBMLBFVxRMBAMq3+QNRUwcACCGaHe1AAQCvwjszIiUAAGSg9JhD4wAAKBlLPgkLAwASA8h+fs4JAIOP97115QwAOO0LGXofDgB4o2ztrfgGAOi9zj7ZIgUAz/bgRfAkAAChzyY0tm0BANgP0x86uQEAYqNoU0DlBQCasrf9PRIAAGg8UlZDNAQAX+4heVKaBwB+gT7L/EsHAD2N7HLegAcAcif0APPqBwDjTDWIUUUNAKvLPUrK3AQAy+u/0BTTCwBXK9Nq/N4BALznmghFhQIAXMGg6Y/jAQB7N+LgRiABAIWoClYccgYAKBlnvyjrAACnlVHvGr4DAOu1vWIv8gYASTBSuGiXAwC9/fvIlDMEANKNvwHSZwQAlud6Vr30BgCDtxeTyFoGADKJ/SA7fQgAFWkyCPIACACDo1tanO8KAK1P73SakQYAv1IUYdSeBQDvCeoE7JEGAITpACfLywMAPLr1xEMcBwDNdJ769m0FAN9Wz+SVnAcA4gnGO2S+BwB46NkqwUkBAF8MOcpYpwUAgdxhHYuRCACb0QwmUNMIANi0N06rogcA1xRUc+ofAgCdY38COKcIAJUkRtkQJwcAVnQAqq9aAgAbo+ooH9ICANBfAOpxdgEAtz5LJK7bAgDM4f9XL0oHAAFzCHMwvAEANJwB9FfsBwAkpR8uCE4DAGoSNaaMaQIADtk9Xi9wBQDHxXBKmhwDACT8eKqlNgkAAHufOy+ZCQCir8SwBMADAHi6sDKIMQUA7Hzxn0vyBgDHYOAwf6QAANDIDVSEgwUArpzE3EP7AQAruPQGrEYBAFVzntgAtQQAEopyHB41AwDjL5NpnwsBAP3RHNA/tAYA8w52PlhCDwC3FjJXwT0HAEpx1/1IrgQAA+ETil/4BAAN/9ayIDQHAETFl0ZLXQcA9Pj3/+EbAQDh91do4RkBANX1XDQUigMAL7UFcY2mBQAGHoWey/YEAOWVGEfEeAIA5GQ9zs3vBwBMS1xFbU8GAEuj/jJW2wMAwiWYgrGQCQDIJTJR0+cIAK2rt+MrwQkApZweeHeHBQDyXUnql5ENANjZXfcr7gYAjb406yzHBgDHXjTMyXkGAKSYaPmNiQcAdZ30rSFDAACuWuXkGWABAJwgXfLFTwcADe2dk2pWBAC34BbnY2AGAHBNH9yvXgQA2rHMzyRGBgDBtnKAq1cKAAlvZyUHEggA7Y5O0BigDABs1aXuPPcLACvXRYCFAQQAMC3K4OVZBADqizAZt4gEALUyGw1KbwUALTaAvO6lBQDGjU4K0b8HAPQ2ZzaZyAcAAVz56rteBQCKP5BgsG0EACFmEolYYAIAL+V2xjyOCQCPqZXZeWAKALEIeSF8SggAWWXmA3bcAQBEJAuh394IAAT/YIOmBAcAPovePMzOAwD/ZA9H1RwCAIk5lY3BqwYAFebkwtBKBQAqUiu41WcDAMd9Pbj00wAAjcXbTH8GAwA3eWnaUgQCAKl3qivLLgYAdCi2rzYoBwBAspQgPK8AAHo1fymFwggA4taAVi3MBwBjVgfVExkGAD0rFWFSeQUAvTz6utuhBwDViCXFMa0FAFxoZEE6XwQAbZaakZ/lAgDaMTIaNi0GALgBTgCEUgYAYB3pO1NWBgCfqABsAa4GAAUcEyq83QMAFLuWJ6JXCgB0PkT7YPMGAOrqIHLkgAYAGAzxpfL8CgAfg42zf+4FAEvFXs75DwQAW7Nh4oVxBQCpcA5UVOIDAPjjA0CBtQEAS8BKMWiJBwCOakRBy/0FAHEq/yZpKAUA9rOW4jHyAACTRshXo4QGAKC8yTMGHQYA33P8+LwoCwCzlf8G3rQLAKQRuiekCgsAm23avzHuBQBngN/COrIFAGYl2/81SQQAbmwXbQEvAQCu9RYPsPsEACpAmY23+gMA7XqE/WXpBgB7UoDuU7kCAFqzsc1bXwUAZjyiPws6BAAKgos4B24HAF3ZnbubmwcAYXOfjq59CQAy2gJh9xkHAIvKgCp8EQ0ANQldtmYaDADKrGAUgboJAMImMWpAVQMAdn1yGBkNBQAOjkkL6uUGAPIUMga2owAA0p+MFV8GBQBUmUIM+2kBABDu7NntmgUAAhiF6xaZAwA4xVxVF3kFAE+K5TkfmAMAy2/mbaXfBQAIWQcJiAUIAJNKhcvY0wYA47Fw6fSyBQDBy+1SRA8LAJMKI1l1igMAH6OL3hwsBQA9WnTU8qQCAIqi1EKdfgAAzVpwg8CNAwBAl3XFgicFAK2Q2ZczPwUAFU3oxzmpAwDgOX4ixDQCAPKTpaHZMgYAlIQM7RH9CQDgVyftsyEIAMXBj+UdPgcAqxZGyBDRBQBkryjfp6ULAKbLB7gVawMA1/4anor3AwAfj2AsnKUAALeBy47dKwUA1H6ESE+yAADH6htRvtQCAJtbntmkvQYAAU6Rlml+AQCAz3/O8LEHAIFUR3TPTwMAharPeKsdAwC3VF5uIeMEAIm2czmCSQoAhIjkhElYCgA2+0IwmhEIAMpnl3hM4AcAMrjPKBtnAQA3xeGifuUHAEFBRO+q+wEApt9kwb3TAwB9F8LonNgCAPQsGLoSzQYAl3aawYoKAgDZcsyy+jkFACDeHo8IbAUA747zJKxfCwACq5dhXNcHAKcvpMJLPgsARIG0EM3HCQCPNUjqtzgIABduqBARPQUAbUZftm5BBgAgzl8jphwEABK7mYr8wwUACJG5xnSWAAD4bzGZIfgGAOnzqfFUXQAASie90MW8AwCt1dK4hLIFAJ6WJRDj5QYAD2IGYw77BABg5keX9TAJABnU7I+GQQgAxTuSjF4QAwA4GD3UigULAPuT5Yf1YgQALTbOp0vZAwC3Zya1+TADAArw4Eha1AUAjZp4FFGPAADQY3bl/Q8EAEcGwtRFFAcAfA8XaD5lAgDWXsXj3kwGAD3+TvpJZQIAbmY/r0mFBgBou9RBKZ4AADz/XR8x6AIA0vsf+Z5CDgDiLBP+DaEDANb5ax5GWgUAgy6w9O6OBwDPFoxkT9MBADJRuirqfwAAHkDGHW6SAQCgzhfqik4HAA+8P/hDxwAAVVS/xAPLBwCYfpGpi4oGAOVh2AEd+gEAq5Tf0QCsDAAaJ70BIboDAK/EuYiJVw8AfZ/0ib/yCACf6Y7Rzj8HADKYWX2UVQAAkBmkKv5GAwBbGXmATBYAACe6e/vMmQcAXKfGO1ZzBwCznBNjCOkBANag2Qe0+AQAaU+SyiSOBQBWZOe7RqIHAGS4Abcm9AEAPyWhkcg1BgAv3o7T62oCAAWu3frIbQYAhjegQX0cCgB9+rOxa7cIAAEckUFMJgEA+b2ERfQCBwDejsYfUTwEAPk17TosSAAAG9NxUq/hBACbk5J/+cEAABfBbZWIegEAx535XgDuBgDMMbJykaoEACp362HdtgcAx9IBq/mrCADlCmOHAogDANvtWwTKLgsAzzJfNkN/DQD1v1m2qT8FAJI981DowQUA9fa5mhHsAQDpY+Ztb/EHAMbeFsvWpwcA0vHqvOkDBwBVVIiU6cgEAIKtnNq1zAQAdekQxmtZAwBen9sNDKgHAGFMXD7ZmAMA8uPn0mB8BwBwOHZREAYEAKrS7ODEewYAuXMTH5S7AgAwLADJyZkGAPNI4jNn0QMAieNL4bfiAABKePbaDSwEAFB4xh/qiQUAkfHdtQk7BQDM8UZZI6cGAGC+L7ucuQYAYlxI1qXTBgDAI+lmlIMEAN38xjCvHAUAtFSsGJr5CgBu7mGWo5gLAOLNQB4zhAMAphnexBXNBACOnxic4ioJAArgdHZCpwMAwXR+Ty8UBgAVOowxk8wEAOceK6wb1QYAPziSokpQBQDPAQ0fy8AGADPV9Z5GhwEAv0c3iDhxAgDokDrlKvUCALqOlf4U/QUAjsuTv17+CgCH58uK2iYCAKF++6KDCAEARM9CeHCUCABccmD5c90HACyrRSjfLQQAu3Yy/U8hBgBGUhoYjQsAACDredWmaAIAR4blJv+TAAApmAVo/iQFACG2fOR1WwYAGczVpbBeAQBanZKzCVIAAEdryMub9QIA7sKRtmDVCQAHzuP8uvUHAGyAFBZWzQwAh7FwYYtYDACBENDjVaoKAF8TF5lCfQQAcPB6oM/qAwBEbrRGq94BAN9spDs/pQcAGuXiQotFBQBPRAcM5pIBAKodokOIrgUAOBULkSHXBgB+QaaVGjIDAGinqASQPgEAbIc7GckABgBldw2KGxwKAKGOs3+SeQsAGuDbeXYNBwDpjYlAYPQNANvOL4NFiAUAc24Mf801AQBb4+jf+z8FAFvlBl4ZLwIAzkuB6Dc5BwCN9HspFnEDACCXBg2eWgQA7ESnGvdaAgCjq4rL8BoEAF4diU6KzwIAomvQF35IBQCWZS0DKocLAN9Ik8AoXgYAwkDOsmt7CgBpHYny96YHAGcPEQeH/QMAsi2pFodvAgAnMHUbqs0BAGEmtVi+BAUAUoLl1psEAgBJ75pqjf0BAKFvIbdnywcAgrnDU/96BgAoltoQpg4CAFlU/K0aAQYAffjLAsjQBgB7TFXtv0EJAGJC72e22wYA3H6FJjGPBQBAk3eL4ZwOADz4lc9tkgcA7CsOEiUuBAAV+vFt6T0GAMz581Br8AQAL7awwVz8BgDLeZiyKFUHAD1aEtKPmgcAuGp0S418AgAMIQI/ifgAABBXrrOWVQEAyiRRfhYxBwA/4bvoOHsJAFWQL5Rb1QsAPpG+lRScCABs+xokTqoDAKJ5kT/SOQcAxOi52/oyBgBIDP4rUsgHAKla74MJ7QYA9LWHdiPSAAD1BTMqvzgBAJhl2CRd9AEA/mAhrUsnBQAq0VgdBLYBAHpo5KbKLwMA38yHJ3OkBwBABn98Qh4JAGOMXzhZNggA+mt22er0BQAAJmwz9kYHAPWafcWNbgUAeE++F76zBQBLL/iMkr8DABFvCmBVLgUA1uvvnH5iBAAcl2yrRfMCAOnnY24oUwYArSOKt2EQBQABRbWsmUkBAGbtB3CRtAcAyqJT3SgbDACF6odf6HsDAEFeqNLjSwcApmzJ+oe+CQDMCP4gNtAJAGSwhKtc+wUAsIWCdz5RAgBD4CUxOFcEAD0ibrWjvQYAT4RvN7oiAQBU5bSizTICAED4D6MrQgAA9UN7ZudRBwA+X9pVFyYGAI62Ur9wLAAA4XKNRb8yDQCbtZbnlg8MAKKdb533LgIAd8q+Z6sBBQBD6z9+abAGALsvC11L7AcAUFRZEOkAAgBecQVxBUIHAGAPUyJw8AIA7wmk8DRjAgDAo2LfSvAAANm2i7Tt4AUAA8D7pErDBwAkrFxOTtcHALJBNPQ3zAEApq7OyfFWBgDsWq2sHAMHAFdscdCMMAEAQhmUcxMcDACV8XL3RqMLAE8yx1xaVgcAEUok1aAcAAATh0FnsBYBAK7tVYx9pQAAAzgQnIDGBgDIatriElEFAFq6PQo9NgYADPSmi8kZAwDHbqMDS+gCAHzv9rkRWQAA3OouUfOsCQBoKmk5mGMKAAYFgzSiaQYA1AMGDJKLBgCyZByd71UNALsO3/WDmQMAJpiViSXqAQDWzQOHY84GAAWFiXgWMQYAcKKaz86zBgAIvXM7unAHANSG4fd1FAEAvCuJyRslAABazP+bq04CABc4E970dQYACrPaO9n2BwAl1L+lrPMBAGCXHBxS+gIAzfknzoAhBgDTLIgLRQ8OAPyCF2sDUgQAxYF2sJUtAACyBZL5HJAFALTsXm5okAIATBZw35k9AQDKwOUhw14DAClA9DfjOgEApy0/gY4ABAA6DI4vJ0AGANpe5eltwAEAqmlt/0ArBQD6fzcJiBsLACtM0VxiNgUA0RcuJa8WBQAr0+f4loAHAOLEPqPWegcAIdMR3MUXBwDkI5hVFKEEALHioVDOBgMA28L+oTjPBADnXPoNZaoCABWU8agWSQUAeBLnb8kNAAC4PuaEJ18FAJFgotPKcwMAmrvdifuoBgA3ftnVNYwHALIs73Q2bgYAj91TrEdDAwAqEaXtRxUKAHz1yYJNYwQAUtamaJIkBAD3L39obTMGAKDZJk5P/gQAQVSUPQ8EAADThln9OekFAN+bAUchKgEAspzQ52bEBADdA9KVW/oGAFSiNKNQNQYANntUckVYAgB3ExyBWFwHABsXzDfG0wwA4jR9dDA9AwDXp/q6kpoLADfPabXt1gcAoCzcpZQBBgCmEF50Wa8FAHVIAD71qAcAeK99LKbuAwBOJ5PmE8cEAKSzbnob7QYAFY59ac4qBgB1sCopuGYCAJxcZqA2hAYAaRAg6BfTBgDKoyxdgZAIAKCZFOvxPwgAGONQ8GA5CgAQFslpNjcNACc/LyDoNQIAgBe2Lp9MBAADcB1bkDAGANHqdNLI/AQAeKtof257AQBXUg6aqxQAAKWLf1Y5mQAAgjxCKnu0BAAtxHrl14gGAIePZ1pLywEA1AegomKqDABtLfY4Dh4GAIJHzI+ILwgA/xvygytWBwD2LtjSD9wKAGz8SjlrwAQAzDb2SxuTBAB4IzLQYCsHACWLgcYnUQIAQ+eNp7wwAwBOdBkRhP8GAAWT5OhgxQIAeqXl708lBwDfp2DF4noGAPFps+EbwwMAckLL+ZO8CAAsGHPb+fgDAMThuuo1sgoAGVUph7/dAgDV55cQ7BwEAO6KlAhNhgQAHvaNQzfSBQBncB9ghbICAFPX5rq8XQIALSY0EbYwAwCKgG2i1xkGAPK+rcKzwwMAUn/snnyHBgBttuHrub4DAIfykc1EawIAgwNzYpPyBwA2nEVRef0HAOdJLVFMUAcAX8U7fu2HCAAlx0kBsd4HAHV0OI9HSAAAPopn2ZeTBgDzdslWgXwGAGwiiVVN6wIACsHB5gnHAgB67maHaq8CAGzZoXmqigAAsC+b1ZIvBAAHnABALHUBAM5i/+lojgAA+fK4CtUJDQDk5Xskq7gJAIXksuay2Q0AOBOaR6X6DABwj3O9E8sEAK0wwUsKUAUAlYaTeqEnAQBt4zT6JioAACjMHi7RhAUAo+t++PPxAgBKthXldYwEAPAeB1JpWwcABlSWQm3UBQCfn5gGYXQHAOIKPDUemgEAvb2W1c1yCQCDFojfHXMIABSBT9YmBAkA2aOp2E8aBwBqJpA5vTYHAMMF+rpgdQQAoy/Mq9wYBACChs/OkVkDAGCMS6lxQwIAwyAcsUYVBAC0szSTUC0DAKpwriwQbAEARfQb1Q1yAQAhmK8vZq4FAPqHK1opEgQAs+qT4mFSDQDLZZt1JmQIAEdqEa5lAgQAvOW6BCPABgCtldG4C3YIAOnWfvWImwEAOaMEGb/NBAAsT07NSSsEANkJGXcuGgcA0lK7PhVOAQCKgebNFxoGACeIEDStPQUAtlVcxTIrAwCjR5NfFvkCAKwzvOlLswYAwPJxZWVpDAA+Qm/OYaoIAKAnG9dA+QsAadFznfGFCQDc5mJ7nBsIALLAeDpkLwcAe55PwEXeAwBc+jCN1gYHACQvjj72lgYALZLwGCwBAgApncha5VUDAAFx7BS06AMAkAxSfLCdAwDh73ebHvQGALrkhLf1igAASyzMidIUCwBNvPHiUDQKAPOSLzmTzQgAfGuUagw3CQCX/VodPEIGADMlH4jcmQQABsV2ZPJOAwCXFHTSB9EEALP9br3ERgMAoWMR13krAwBqs/zt2fgFAJA5v9zo5gEACvOKNE+XBwB8nPFOcuYGAOITvO+lgAQADCLOQuRMCQDLFiWngIkJAHZmuA34cggAbVLaHzMDBwDIkXbUMUsKAHEgYgEL5wEAaqH4tWPxAQAX1Bo0r2oFAPcw2DWWmAcAe8sAdqJ6BADD+BXA7R4EAEqF7yeNzwcA+ZNGWOOJAgCnCbNXeEoAANpN0YW1RQUA4SGz49DkBABArNLjH0UHAI2p7nj2ZgYArf5nhoU4CACMTObDLdIEAA861KBeJwcA98zXfROBBgA4mre6nOcBAGqmiUQhKgIApSsznC/2AAA5XzvWiWUEAJY/7Hn56gcAqLlyFejrBABKaWFdfxsCAHFjowH6wAEAPWqTjA4rCAAgzbZYO7gGAIAm59PYfgMAYiqf2zegCAC70rEZVAAMAP89lCK2BAYAWBp09pnIAQD7MvLiGQIGAMv5p5KuXwMAyrHzFDb6AADwgr65vf4DAAAUkpVI5wUABieCOOpTBQCMyM8kfKEFAAr0rhii+wEAlAF7PgRXBgDn6e9VG8EFAPt0oMZ7cwcAzFXjHOTqCAB19z/RNcUGAD71yPpIlAQAajXoxnRPAwCi2wcGeK0AALY+tn46IQcAhoyqrOOSAwCvNYo+6TQFAJfJAv0QiwAABR64rMJqAgB5O86YjJ0AAKxQTf4XXgIApyHxdvV/BwArcvyw+eUMAMcoDZuUbwQAJu8XXebNDACXlvgoqLsGAHb2BB7XmwAARaHyQchaAgBxOIKsfqQBABpYbMOoqAEA+6lCFHVVAgABOf6QZrwBAFq8Wi8TFAMAKNUyUYMRBgBXirSOS/IFALf29wTVWQUA/WbS9ueRCACIcwPvYGADAIYSHeyIhwkAr45HHESHAgC9VDNq6iMBANVU67N4gwMA7pSPp6rUBABNp3XoAqAEAHyxZxOFCwEA4wdYLbEaAACWLeNBkBgFADECCSsGWwAAj7fnZhfJAADsOKFVD6oAAIqRLB6WowQAHj8j80TWBwBkwAKen8YJAJdoJuXlagMAeYvT2sGPCABAvdnqzooGAKC75vjgOwQAO05h/N+PBgDgO1urHekEAPAvIcnUsQMA27E/zmvNAgAQwtfzDskEABaHgaD1lgQAuDnCjPicBwDb+GwwnMsCAI9QWw12lQUAkCcC/evLAgAFEewqgrgIAMu8JtLP0QwAvXFJ+rIVBQAVRfVdLMsCAJdjqgThvwEAJWyZ/5QUAQAAWD5iUUIGAL5E4MWf1AAAKcvtQ/oJBwDKKv1jjF0CAGH93ynNxQQABa9I68AuAwB8t/mRk48BAIEMz54CDwcAubAQXqqvCgBMJVWD4B0GAI3C431Y6wgA1Lt9n7vwBAC9dCpayk4EADM+7S6zBwMAwug8sIp0BgC8ELiaDXwFAIzpJKJkLAQAFMOm2NW3AABD1ZV7MkgEALqk44FmFAAADE7DrRSHAwAwjikOb/IEAN7HEkUicgIA/HWpQoq7CwDuF2u01fIGAOVwMSKptgcA5rfjP3FTCADBa3/9NZcBAC40xUmvkgQAVwNa31w2AgBgu/+nOCEDAP5GRtH3oQIAzESK8V0bAQBmQshC0JADAHXcjyrj7wEAOBKu516SBgAy6NCBkq8EAPgdGRH5/gAAUHVibGljS2V5QSBSaXN0cmV0dG8gU2Nobm9yciBwdWJsaWMga2V5IHJlcHJlc2VudGVkIGFzIGEgMzItYnl0ZSBSaXN0cmV0dG8gY29tcHJlc3NlZCBwb2ludEtleXBhaXJBIDk2IGJ5dGVzIFJpc3RyZXR0byBTY2hub3JyIGtleXBhaXJTaWduaW5nQ29udGV4dHNpZ24tYnl0ZXNTY2hub3JyLXNpZ3NpZ246cGtzaWduaW5nc2lnbjpSc2lnbjpjQ29zaWduYXR1cmVSZXZlYWxDb21taXRtZW50TXVTaWdJbmNvbnNpc3RlbnRtdXNpZ19zdGFnZQAAGQAAAAQAAAAEAAAAGgAAAGR1cGxpY2F0ZQAAABsAAAAEAAAABAAAABwAAABNdVNpZ0Fic2VudE5vdE1hcmtlZFNjaG5vcnJrZWxCeXRlc0xlbmd0aEVycm9ybmFtZQAAHQAAAAQAAAAEAAAAHgAAAGRlc2NyaXB0aW9ubGVuZ3RoAAAAHwAAAAQAAAAEAAAAIAAAAFNjYWxhckZvcm1hdEVycm9yUG9pbnREZWNvbXByZXNzaW9uRXJyb3JFcXVhdGlvbkZhbHNlTWVybGluIHYxLjBkb20tc2VwAAGoAQABYFNUUk9CRXYxLjAuMi9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9tZXJsaW4tMS4yLjAvc3JjL3N0cm9iZS5ycwAAAJL5EABXAAAAYwAAAAkAAACS+RAAVwAAAGQAAAAJAAAAkvkQAFcAAABtAAAADQAAAJL5EABXAAAAdwAAAA0AAACS+RAAVwAAAIEAAAAVAAAAkvkQAFcAAACCAAAADQAAAGFzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6IEz6EAAtAAAAefoQAAwAAACF+hAAAwAAAFlvdSB0cmllZCB0byBjb250aW51ZSBvcCAgYnV0IGNoYW5nZWQgZmxhZ3MgdG8gAKD6EAAZAAAAufoQABYAAAAAAAAAIAAAAAQAAAACAAAAAAAAAAIAAAAAAAAAAwAAAAEAAAAgAAAABAAAAAIAAAAAAAAAAgAAAAAAAAADAAAAkvkQAFcAAACNAAAADQAAAABZb3UgdXNlZCB0aGUgVCBmbGFnLCB3aGljaCB0aGlzIGltcGxlbWVudGF0aW9uIGRvZXNuJ3Qgc3VwcG9ydAAx+xAAPgAAAJL5EABXAAAAlgAAAAkAAAABAAAAAAAAAIKAAAAAAAAAioAAAAAAAIAAgACAAAAAgIuAAAAAAAAAAQAAgAAAAACBgACAAAAAgAmAAAAAAACAigAAAAAAAACIAAAAAAAAAAmAAIAAAAAACgAAgAAAAACLgACAAAAAAIsAAAAAAACAiYAAAAAAAIADgAAAAAAAgAKAAAAAAACAgAAAAAAAAIAKgAAAAAAAAAoAAIAAAACAgYAAgAAAAICAgAAAAAAAgAEAAIAAAAAACIAAgAAAAIBhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgOiBI/BAALQAAAHX8EAAMAAAAgfwQAAMAAABkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNsaWNlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhznPwQADQAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9tYWNyb3MvbW9kLnJzAAAA2PwQAEkAAAASAAAADQAAAAAAAACwoA5KJxsGAJ0Yj/yl1QAAYAy9nF7vBwCeTICmlYUHAB38BEgyuAIAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL2JhY2tlbmQvc2VyaWFsL3U2NC9maWVsZC5ycwBg/RAAcwAAAEQBAAARAAAAYP0QAHMAAABFAQAAEQAAAGD9EABzAAAARgEAABEAAABg/RAAcwAAAEcBAAARAAAAYP0QAHMAAABIAQAAEQAAAGD9EABzAAAASQEAABEAAABg/RAAcwAAAEoBAAARAAAAYP0QAHMAAABLAQAAEQAAAAAAAAByO4z1xpMMAPYlw4Fx3wgAtkw+Cwv1CAAxTKSFkzIFAEs9o9P5fAgAPpFA1wU5AACic9YXKLoAAHzm9CcoPgIANBrC4NIzAQCBjyn50k8EAGiqeocFEgEAedWTWJV5BACgZ5swZg0FAO7lvg0t1AIAxvCJthfxBgAwl+5MqLAFAORVcckQHQYAEGoJyJwFBABPAaiNYHoMAA6oueFkoQcAZdL8pOgfAQDMqk83uLwHAE9N7/RaLwUAEI35mEAxBQC9VXVYkasCAInY0A0/kwYAlUJMu4ZDBACMUGIxbcsDAMaicrhoYwIAmyvxaoKiBQAgu6UIRLwCAEJUoN3reAgAIkE1ErH/CgAshvWN7nULAB9uFM9clAoAutZHpMOCAQDy7zblZCkCAFMAVB+CkgEAXI54nvH5AgC1sT7np1QBAIWCKoHx2wMAl5c/uhf6AAAgOJy0nPYGAI2Fsw1aTQMAu7OW5qs6BAC/o06U0FwKAGJNGrhzVgcA1MDRJblQCQATQSnZOD8JAMiDkqa+YQQAsSEyqposBwBN93REd2cCAIWAsumwZAAAySc79U7wAwAx5dLV7dYBAKKzuAHIbQMAMF6T1KfgAAB9DczOt94BACzdIE6pUwAA+aDGsfupBwAcY6imimcGAGWz2Ig36gUAeUKZ1tYbCgDi5BlZ56wHANetONOeSwsAZICdA34hBgBtfjMIpN4GAAaCYhLBegUAcwTjZctHBgDJrR+lBZwEABuvRZC/6AQA1uBFOuMUBQAP/otbPFMHAMkUfntVgwUACLAhIBc8BwDeKoCKhAAPAPblxAVG4AkA+meXG9DABQCLOEKfiNcHANhGJa5aJwQASEOGSQJbBwArJnAQ4S4FAM1a+1SuNwIAtao60NG/AwBcnQKYtYoBAOmJYP3FLAMABZuUXFAmBADSegyIGGoEANrMiBgipAQA31MrUmXcAwBtfwCiIsIIAO1325u3VgsAzRL+HugeBAB9CQe9qSAJAG407H79NAIAk79/MjsBBwANau3tbjMBAK/zu6JltQIAVRlZic5TAgACdtGCeCYAAHijLnMZoQAAbCqOuvE7BgCa35DMlJ8GAEj8m3fRMQQAl6Dab7qXBACg6s8TA8wGAJmkjYQTowkACSMZQlPLBwBg/d7elpUDAN4Sf5EiHgYAC8+MRobNAwCBwBoiU4UEAG4KTktGyQYAAwQYhLpfBwAFjSHUXDsEABa10JsvdgIAs8vd++fGAQC94qzDCVkHAMk+LZcBIQQATa4QEtYRBQBunQ6V73YGAFjyieAauAkAghiVIkk8BgA3MptN1fEKAITbTZIl0w4Ah94gREiGAwACgbZdstYCAMBzKJa0UAYAlBMn/RwIBACCJP7mfxoHAFTIyKW4ggEAjm1A5cs/BwBR9M8wNN4FAEGMrGe5VAUA7lllS2x0BAArmsZtPHsHAG76wj7x7QQAyOp711roDADZe46yotsHAOlP4x2lyQUARxF0ZMhGBQCQJgmZ36EDALvW9MmMygEAAzvNyX9rAwBe25c0ZhkCAGcO8XnP8QAAon4rCss8BABqd//fiVAAAIiL0+GE3QEAIgjGA0WABAC0f6Ms0J4MAIN4lbXCdAQAg2aBjji4BQDka7dUxLYMAAVlUYo5Uw0AddE2OtIhAABtR8ZzM/0EACrQ7h4pDgIAEHIuzy4vBgDkjYWY4HEHAN8eRXjS9QIAQnOZM7EwBwB1aesgVJYGAM8Wpb+jCAMAWv9oHe2lBQCDDhX+KhINADECu2bJrwQAaII8g3jEAQCPFPzDOXgJAPiLfYnLSgQAWXNSWMXgBQBc169zWzkDAHC55KSvcgAAbQ+eMhQiBgD9/jUBthkAAINLE14UaAAAzMOCCYbkAQCZ1xNf+2gAAH5URDcoyQcA0mren8RQAQAlEUcJlfIDAM8xyrTuKQcAvL91tSKcBgAS4rxXCJEMAJi7daC1sg4AaKjcnDyGAQAJF1opDncDABP9IDda2AAABqtxH//gBQBf4JF3bYoHAHa5oEdLcAcAF6sa6YKuAgDNBphC1gsFAOrYjxVVgAYAVa3E/8clBwCymc/RFWcCAIicpkFUIAoAU0vNfUJIBADFvYrokdEJAB7Ld5LMlAcAwJjQHPcrAAAw0mzMq50EALIF+TNlCgQApLgurO9zBQBfhV9iVM0EAFNQrMImxAYAXglLzl6mBQC2a/KGQMQAAIV4GWiVQgcAyPy2V4MABwDuPnc4J2cIAHBhn3m/UgcAIzPj2qa0BgDc0eqWRrUHANAahen3bggANEpYgrufAwADeiWPVnoEAJGtHgmITQEAJM6xGFsUAgBtnWajkjoBAOV9V8AcdwMAUpmLuwbKAwCQA9XFgQsAAOyABzQSNQQAr6L43ZbCAwATpxTZ+RUFANVVIv+RMQcA772kwlxPDQDOixH8V90DAMeQNDmdqQcAQSUfuy5NAwCd/yO3FegAAENU4ha0hgIA6L7ROP69AAB3dADHkqgAAOijvTYk7QIA6pHyAP0qAAAho96Bc74AAJOxstRS6QMALzAoLXaGAgASW+M8CTYIAM7pUnVNtgsAX4QL/uAeBwDlaclgBp0GANmpRqAdLwsAvfUuziuOBQCKb4z36IwGALJhkuMm7gYAnc8LpQo9AwAXbz0qb2gHAGp8WW2mEgUAUXWlcJpgAABMRjyKwCYAAOE57sgfUwQA0pqKXzBhBQC+rpLsjZcMAACifK6taQgAVA8pI+keCQBrkY2JQZYGANQ1PsWuCggA1cCw5yjMAgDkbIrrYHsHAKZ3woUpBAQA69NGe2U2BgB8xfKuoTAAAKrSOgBz9wEAdg/BLGQFAACm/Cz4SDsAAClD7hA8QAIAZUDCwekLAgCmc5Yk2IcDACp8ktyovg0A7w5l1Y69BQDhQM0/Du8IAKvwYTOrUAcAYF4C4krkAAAcBCeXe/kFAOzswHI0aAUAfM6xLoiIAQB+BkXFZJcGADcQ+KKDMgIA0SN++a93BABou7yNlbgAANat6JdbIAAAdXD7s5ZPBQBmkmYpBPIFAPVBSa6vjwgAh3brxINdCQBFQcqeN88JAHS7Upz+1wsAzR6xFsavBQDvIo/sSp8DAC7ZJRaeswMAc4hQ1Fv4BQBd6Ps5aI4HAGuFuDf3LQMABk7xQoNgAAB1QdeJeJYDAFCl+wcZIQEAiAA1jyYPBwBHX4Cxg0UGANAsg68bLAoAFtfUG8AyCQCOW6fD9OwEAIitz0XTwAcAVfPccCARBABk5CKc/9wHACUz4GDaSgUAmnbvjtlcAgCMmwNs5QQEAIozeIxLHwcAIyu8FvwsBgCq2YAS9XwBAFqpIF6uuwMA7KpiR3UNAgBFtzvHb8MHANFLc5fHpgQADpWziiTvCADHPqXJVDEOAO08b+TxuAoAQ/W5NbH+BACuk62S0TsGAPfNEqYuTgQAq4MVmfRwBgC0kIfaiosDAF35Ud+cSgAAuJbV+2PZBQBK5axomy0CAJnFNoiOqQQAoesss65JAAAxefx1C30IAEl1uuRMbwEASb4/wOSsBQCcFSrBDn4KAGYPUxfulQcAfv7cYzx9BgDuGsit8BIBAGVxgkzwPQUA8DC0M1v+AgBijQxeZhwFAIG97FIKWwIAqeT8lQbcBQB9BHXFKLkDAOWGJlHzOwIAVNxJvxnNBgCGw69lIWEGAP8DYqMaFwEAqqggqC5kCgAPPzF7u/MJAOMpdDob4AUAo5wXUpBhBwDQr/CTZcEAACh0XHnEZQIAQlRdUUAcAwAuC7Q9D1IHAKFXk9PjCwUAtqeU0jOrAwCz7Vm6ecQEAG8yTRgNwwQAPO/MyZIQBwC8HQV0rNgDAK3QQ/W2CgkAj9oPrPPQDQDj5XMlHe8FAHoTt1s6FwwAjJFkAz9SAAB7imNt9YcGABPQipKWBwIAM0+lBYTTBQBXAj2wFeoAAIoh+fAxbgUA+ALhiF9jBQC4pWnZxcsCAHo0i8n7MwUA46QUVlb8BQCOmJB35uECABJJ5JqL4wkAU1YHtPtIBgByzUDY8Y0KAGXUCXRMIQMA5XptxA1XBgBt4pEbn4oBAKtCPxi2NgQAmIFPqqxQBQBUxBTEEScGAHAXZQZ0ggEAZcKG8kTRBACBku7wiHQBAAx2XNtsngEAuOxzQKm+BQD40kPzY84IAI02Hn2o4AkA6Z4BvO1FCADQ0CjtmpcOABpPlIUHrQQA5JvIEgm/BQCDjPPKrS8GACzOs5bBXgIAewFP/1V2BwBhjxRczaoDAAGDMcM0OwYAsdAELebgAAABZ3IzonYGAGmXLQSangIAKJAdy/CvAwDyNMX0C0MGAERyUOTDZAIAcJKjGZ9MBwBHvJn3hD8HAJm9Mvf5zAoAXkAgOuvHBQD4MNmqtf0FAEeMO+ZXpwQAViSXkpSOAgDSTG/o5xABAOT1A9ae2AAA+IoBBBYeBQAYIkrc7rgAANCEk4upGwUAk5YLflVcAACwDsKJsLsGAO6eC/tB3wYAb+GH7YcQDQAwp59c2wIJAGAYhPD+iQIAb37JHzHOAQAf27U/PwIGAJj86HWXtAcARVC/rXCtAwCY/njBVOEGAL+a1v42YwEA7PkpuWbwBACTW2ye/+kEALqyS7yJjAEAypUqZL+vBgC5qBP5cFANALsrrJ5hZQcAWXT0JVKrCwBHW6sU7WwHAAG47TwJLAkAwdL1YgzeAAC1T3PPAZYEAPbwY4LDtQYABm219T5iBAADlRuFS9sAAA8ZuAiTfwQAgh9iXCMUBAB2Whr0Xx8DAG25qnNncwYANWaceag6AwCebBX8iPUIAGjwpE1BYwMA6oq22WopBwBDrhYTcdMEAFiNHAzNEgoA8lwIvR71BwDh9eNn+iwBAGrU4/EMgAEAqPBfYTdDBQAhjp7yxjMCAIHHGH8Q1QQAXhql009KBgA3u0gEzfQEAB4VQ4XTcQYAFBmReHfbAQC2GnDdaUcJAGa2tPE5gwIAe+OKSyGrBAD+sKDvCl8KANEXoKgsrgcAb8JrfDlSAwC+eyKgeooBAItf6sGM5gUAXx16Oj7+BgAqbtJ62RoDAGK5IAntFwAA/bZTO+OHAQBjFHqQKVgFAJKn4EjyQQYAImY6xR/tAQAtLQkcpkIGAH/REec3GQsAIUHN7UvcDADePYsMn1YKAKF6pWTWAwUAbvKJTY7pAQCX/vwWrhAFAHwLznIRFwIAgja/7ZFRBQDAi/I2K7EFADcVqZBbOQMAQ1m+/Ob5BgAP6ubqLzoCAAYfAZWMcQQAH5peaAZpAwAdeNhPPL4EAImK/GpxQgoAdjy/5PRsCQBeMveT9dIJAFuABM/cVQMASJ5puNgNAQBjjY/rOkYHADPAkW6FYAcAVeCOACvPAABLRwgnEbEFANt1PMtNmAUAd/nPyv7qBAB72X5YBmYBAFvEWpzYsgcA5Foie1iEBQDDfqZmD8EFAAqJ+DJymQUAha0TLobICgC/6f+nRSoGACqYS7onXggAplcv8WOjAwByxn2Fd2YDAEXXUN1uAQYAVAQMpO13BwARfbiPkdgDAE2GWh59pgYA4McQQsUbBgC2upY/q6AFAHVHiLA17QIApWRNQvP4BwCvhkiyB0gCAGNPvF+I2AsAsyNVPpUVAQA90hip1zIJAA4xoMtV5wcA0U55JDYpBgDaYdEeHu0AAMNvuA/zjgAAZwv/flViAwA1MpwFp8oAACMwGnZSTwQAXxPN3tIEAQBqOJlmZZEHAH4GeiNxGAEAs3DuKmxTBADDucwh8+8LAJsR9yqkjAYA/eJoLlqMBQCH9i8w7tkDAEmkXA9doQYA+redWQKjAQAD3ET4Bf4GAJzTujUGxAEAfyn8Df84AgBHukGA37sHANWovwnx4QUAwRGeOEQ8BwCrk3BjIV4CABvNnJd9vQUAzTVAbSBcBQAldt6QrfoHAERhHDmGwgMARp8ILmcpBQAQru3MhxIOAHDuIjlrzQUANz1EuFmBAwAqLp/s2VoFAG3PCvB7egQABmAKzixcBwDpdM2L/HgCAMfrM9aUqQQAB9739EbPBQBJRISvUDQDAHBPGPopFAIAiKuRUmFoBABv60zVUTgIAIflbK2/WQUAp4i0r+SJAwCMqZBW+kICAIk4NS8+UgUA0u+lVJwJAQA07vLzCh4EABoU1z/vUwcAicdZDO7pBgBOiaVm2zYGAN7U0HtuUwIAX1M8frRsBQCWhD3UMCEHAFk+0XpEzAcAsFlV9owoBQAJiNnwKbYKAPEhzuGqfAoA68fy7+suCQCjxCf3L+kIACNFX8hwLAkAmyiXCsXIBQBS9kclUF0HAK76Y6Uk2gUAB2N56zYKAwBkqVW1AT8GAH92OOWlvQUASI0ZLGH6AABMpoBFzVQDAOq0z0meqgQAYqsWVBY3BACGrf3d+7EFADq88c6WXAcA/ga2fnQDBgDMjAy8tdsIAHG58YXpbwQAmkvmNigKAAAmLE6nkh4CAJPaQNWRzQcAo6eRMkIeAQDdwnLcRuoDAKff4oiFAQUA/lPd66A/AADQ55yV03ECAOxLLwc1pwQAMvR9yrCIAADAbP7+VA4HAAyCsqMcdQIAde46fI/WBAD6EYdP/UkMAO31CnBVxwMAnapUfDNFBADIpPltyM8HADpC22FtRgQASuvQx/a8AQDhEGFUsNUHAJYFx9eWOgcAE28+YF9hBwD546teA4cAAGo0IwuyVgUAdzpLVlyuAQA4WQIDTK0BAEGbcEuNjwIAm+9PkIoXCgAD4HOAojELAJGNGUGmAQoAW41wPobmAACxv1S2FJkAALeWJ0F20QEAD3Q+mAfDAwDxioEez9kFACtZoeI7HQIAe+uDGFdMBQCqbq8sMQkBAG6epLwqkwUA4B82DAqqAwCT9t8I5V8MAIKycfDBbAUASkAfE5XeCQCt7nSTI6ABACCLcA8Z5gMALu9J4SFuBADPIC3OAEoAAASDM8LM4gEAT646VdiUAAAaDSOfMO4GAHe4Z6wyrgAAKSdB2I/qAQCKiOi1JqEDANh7ErqwpQMAHU82mN5MBgDnT2y2grkOAF4IueDDGAIAbNDiPuxUDgDCqzyRlgMIAAJCFMxnlwkAUGQfB+TWBwDh5D7qw/cBANrj9M0+pQAAANJ+ecIYBABTtOWAGsQCAEvFnY7gDwYAt6AJw/GyBgC8u8sROykDAO2nWIZX9AEAHMh3e7yTAwACjM1oqGcLACY22a0ZRwcATxRa0UoXDAAj+1z2PUsDANPDmlm16w4AVUc/t0WGAwA3XWFzB7EBANRyfeoFAwcA4p2K3PsxBwBOytC7zsAHAL1ZYDDaxQQAU0i/zO+sBACvt5lsWrIGAGdoAjMYRgYAlKl2Ea3OBwAi5k3GCB4LAEIMKpJxrw8A66wcIUjABgATDlubbm4FANDkTzcWuAcAg0dWaNtMBgDfZliCzToAAB3KTEyPuwQAkfDJ5b+oAgDXFMTXcy4DAMw/EQTBGwcAUgprThnxAQD08XBRkH4BAOs6zpPHsQAA8JbO42r1BgCmtPaG4aMCAO+oJq9kHgwAfZkF/to0CQAyx+25onQIAKqS/Ja8vAoAc5IejO2WAACnq8vawmgAAK1NfpvcywMAatGbxs2LBgCzr/6pJ/8GACljH2E+9wEAgS3IORDVAADFzsDXsLgBANI6AnCoZgQAhOJtW1orBwDDN6MoRiwJAI3nYPRnbAQAXnJo3uWQDABBjAHSNYQGAOf9pnpaSAMAIOdo7XSXBgAmfpXifSkDACZ043cARQYArpy1KP6zAAC3lw0WoRoGAI4SVX97igQApuSyxbC6BgAtL90wIYIDALR49rlZoQAAje4DBc7GAgAHm0Z25hcHACnRYzwEPAQAszPQDClKBAAB3FRwh9MJADiDN7XC+AgAiShjnLHfAgCwUZ5IJYUDADNbemlI2gMATbZyd/LUAwBJJtnReucAAHVc2/IdMAIA48U7owEVAgCCA3U/tXYCAFx3AXC8+gYAjSXHVB7MBACc4Tpr2OELABIXpxcwjwIAnnoM5E/QCAD+z+EiwzsHAC2jNyJPKQcAjmNDdWbABAB/fh/JiQwHAH2Y0JvtpgIAoFPX5HpyAQAUdc798y4GAP0+ffcXgAAAy21IPg3HAwB2R3t6lwkEAKcb59ReUgEAZlbRh4ySAQApcghm1UcIAEbJGOuyVgEAi6a2bKQ4BwA6MNSqK0oFAJ9J1MEOrgQAMCF+tVqVBABho76eyLIHAP6tv2Wy9AIAhHY6AiEYAwCPRXQXtH0HAKd9vqKbywYAerC6D5wBAwB2rBkS/0IHAMlL0l9XhwMAMdphNBt/AQCGKGwDPWsJADNB85x83AkAdB3rAuwFCQDJc6zj1SYJADxEP8SCigcAUs4DNJsZBADJsRzibE8DAISNstSc2gUAor0Wu2gTAwCprROaudkDAMR1JnASgQMArcDpKI1oBQDnRL//sRIHAHut05wiyAEAu4G9CJK0AABvBw0K+1AFAH/A2h3TLQ4AtCOrI2ACDAA2zMmxYCQKAFAt2mQK5AsAQXIoLbPcAgC3JpiwkrgGAF307DlgowUAeX4J1sOQAgAoHy577lcBAJ9wyp0upQUA/rKX/+d4AwBCi5RU/rgEAHh7160PWgcA+1VcEXeiBQBCTIXlIdkIAGdPNsb7DQcA7PGcuLlICAAmKLex8bkOANItiZHh9AgAzACDMhUwAgBiVfj0sPoHAB37IcPjtgEArL4WnCd3BwDfF6sCm2gEAO0yQewSHAUAd7i3ViQbAwCB0YdTHsIFAC/KSXrDEwMA3Z68LkOyAwDc2MeBl4kIAN8ChTHnDQkAZ62QvhjbCAAbsRUR2mAIAIwyMBP9YQsAWS6Mt8LMBgB3t5IvOAYHANxkN/RYAgcA9gSa/8bcBQDbsiofXMUGAIaZFWWBDAMARZroofguAgDkXOISEegDAGoLtKxYQwIALHuSWoTNAwDMURks1wYNAF2i/gUfvQwAzKjv1zluCAAjUVi1qlYJAH4kx4qZXwwAsNNv360VBwCi49brGs8HAKnIAXEbOQAAaas1q4doBQCR2qDoIWEDAM0+XcUoBwMAgfRmKs2IAQANhVs7M1EBALlqYaP/jQEA1WbwbAg7AgB81b20gGAGAKwxRpfGMAkAj/L15vCyBACAmiJ/ogoDAPEUkKFfbAkAXhkF6hhRAwBtuCAt+EYAAEVRx8o8SgMAloTCGXU6BQDoxohTux4AADv1cuduQQUA6KESnXO5AADjPyZDHFgCAKvhlP5XKAAAc4SB8U6GBAAduNALOqgFAKEZhYYjdwsArTsZ0vtUCACBTZ83cygJALv2164DbAoAs5pjlzLDBwAC33EaDWQFAB4f0TzwiAUAHcQlYC62BwC6TcPAracCAM59HFgvegYAw7ItNQUJBAAleurwkCYGANw9pWxIqgMAHZ6VaVGLBwAtzGlXWsgEACt/ZbrpSgcAVPqb26AaBgAqC8XlDtoIANG8JALsVwwADRhd31SCAQAfoow6nf8AAFQY1H3EOQIApBqVq5OEAwAeN5C8FCMAAIqQJo/+rgAAPW9ap2q/AwDM7lroOxMCAHWbvMXdJAUA8Pw0xXKVBwCXlXTgAEMLAIaGmIAMcgwAl9x8kSYjAgDLVftJCg4FABl/bgsMiQcAby1bozyyBQBzJDeYJVcHADYo7BKoWwYABsSbGYKfBwAOtpiN3w0HAMRd1/23QAEAkn7TAl8LAwAOzI4WEtICAPYYcawVVQAAp4keaWlXBACtQ6Zb3D0GACFnbSM3PQMA+3MhQnaeCQAqCDrXRTwOAMYFa3AP7AIA2y1bNAXjAwCcanNdgL0GADCnHvWFVwUA7veuEQHBBgDBAS8jdAsBANhZj2CUFgIAh5+Pocf3AwC4NyXCUTgBABU3WyjIUwMA9KMlnfrWBQDKpqOy/loMAIS1zAG+8wAAtLOZtnJ+CgAL+2UmA44LAJ18iEH6dA0Au2xu5IVBBwDbSMpH5CUAADCnqRiZ9AUA+vv6vzy9BAD2dfcE50UGAPoeid7aKQUAJRn73EWiBQDP6TxEVDgFABTBrBp5mQQAq8pNVw5CBwAJSyOUP24GAAcfgkNo0wQAh+0hl1IRBwBJ2JmlojoIANs8nPpgugoAPFE0oDihBgDsvnM63+gFAICYP5iSGwUAxoAcV5TpAQAbWCtj9E4EAMlk0yEcSQYAerRESaSMBQDuaBddchwAAODsiHqr5wEAX0vEmUgFBwBZ8bImlJsGAHrdKnZQUAMAUoADwETPAwB3eUDHjHMGAP9txZ1tQAIAo3hZE8pNAwC9bhU7KKgBACnAAWCi5wUAuzygY8Y5BwD/tuLONiAFALCgDkonGwYAnRiP/KXVAABgDL2cXu8HAJ5MgKaVhQcAHfwESDK4AgDqQF2Aqv0AADnTVy5I6wIAWLx0AmEHAAD/yD1hC1EGAP/6XJDIhgcAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL2JhY2tlbmQvc2VyaWFsL3U2NC9zY2FsYXIucnP4HBEAdAAAACEAAAAKAAAA+BwRAHQAAAAnAAAADgAAAPgcEQB0AAAAPAAAAB4AAAD4HBEAdAAAAFIAAAAeAAAAAAAAAO3mIWe9SA8AWuRnrLW6AwAb5TXr//8PAP///////w8A//////8PAAA70VLpZdIJAJ+mvhXHYw0ABHZoy2W+BQB/IT3H7twDAJowfBtBCQAA7dP1XBpjAgCBZc15L+oNAPneFABBpbzEAAuOARAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTEuMi4zL3NyYy9zY2FsYXIucnMAAAAoHhEAYQAAABUBAAAKAAAAAAAAAO3T9VwaYwIAgWXNeS/qDQD53hQAQcW9xAALprAEEAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMS4yLjMvc3JjL3dpbmRvdy5ycwAAAMgeEQBhAAAAhQAAAAkAAADIHhEAYQAAALAAAAAJAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogTB8RAC0AAAB5HxEADAAAAIUfEQADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc6AfEQA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAANwfEQBJAAAAEgAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBkc3QubGVuKCkgPD0gc3JjLmxlbigpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL3Rpbnkta2VjY2FrLTIuMC4xL3NyYy9saWIucnMAAABgIBEAWQAAAFIBAAANAAAAYCARAFkAAABhAQAAKAAAAGAgEQBZAAAAYgEAACoAAAByYXRlIGNhbm5vdCBiZSBlcXVhbCAwAABgIBEAWQAAAIgBAAAJAAAAAAAAAAEAAAAAAAAAgoAAAAAAAACKgAAAAAAAgACAAIAAAACAi4AAAAAAAAABAACAAAAAAIGAAIAAAACACYAAAAAAAICKAAAAAAAAAIgAAAAAAAAACYAAgAAAAAAKAACAAAAAAIuAAIAAAAAAiwAAAAAAAICJgAAAAAAAgAOAAAAAAACAAoAAAAAAAICAAAAAAAAAgAqAAAAAAAAACgAAgAAAAICBgACAAAAAgICAAAAAAACAAQAAgAAAAAAIgACAAAAAgGFzc2VydGlvbiBmYWlsZWQ6IHNyYy5sZW4oKSA8PSBzZWxmLmxlbigpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JsYWtlMi1yZmMtMC4yLjE4L3NyYy9ieXRlcy5ycwEiEQBbAAAAIwAAAAkAAABhc3NlcnRpb24gZmFpbGVkOiBubiA+PSAxICYmIG5uIDw9IDY0ICYmIGtrIDw9IDY0L2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JsYWtlMi1yZmMtMC4yLjE4L3NyYy9ibGFrZTJiLnJzAACdIhEAXQAAACUAAAABAAAAaGFzaCBkYXRhIGxlbmd0aCBvdmVyZmxvdwAAACYAAAAIAAAABAAAACcAAAAoAAAAKQAAAAgAAAAEAAAAKgAAAGludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGU8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAHQjEQAeAAAAAgAAAAIAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgOiCkIxEALQAAANEjEQAMAAAA3SMRAAMAAABkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNsaWNlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhz+CMRADQAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9tYWNyb3MvbW9kLnJzAAAANCQRAEkAAAASAAAADQAAAHI7jPXGkwwA9iXDgXHfCAC2TD4LC/UIADFMpIWTMgUASz2j0/l8CAA+kUDXBTkAAKJz1hcougAAfOb0Jyg+AgA0GsLg0jMBAIGPKfnSTwQAaKp6hwUSAQB51ZNYlXkEAKBnmzBmDQUA7uW+DS3UAgDG8Im2F/EGANdxPJP85wwAQ7K2/kHPAgB2Gn0KHFgHAPAyTVMtFwcA0of6Y8CQBQCo1bRCYKUBAFPRnhXMiQEABK48qt64BQDYtRFP8KoCAJKcZlpZuwYAX3qbpbOoAgB/CO9Zs6sDAK8F28So9QQABULQB6i5BQBQ6hNbrwEHADCX7kyosAUA5FVxyRAdBgAQagnInAUEAE8BqI1gegwADqi54WShBwBl0vyk6B8BAMyqTze4vAcAT03v9FovBQAQjfmYQDEFAL1VdViRqwIAidjQDT+TBgCVQky7hkMEAIxQYjFtywMAxqJyuGhjAgCbK/FqgqIFAJ8J/I65UQMADgWnpL+PBgAbl52VSSoEAP2eRhrlkwMAWB4yEOmABgC/GGgFCgUGAL8yVR/MKgYAJfrJzEGBAgCD5nH0YU0CAFpEx/QzeQIACf92xOn7AwBCSy6Ya68AAOV4ulESrQAAiHzu7a4VBwBTNfbL0PkHACC7pQhEvAIAQlSg3et4CAAiQTUSsf8KACyG9Y3udQsAH24Uz1yUCgC61kekw4IBAPLvNuVkKQIAUwBUH4KSAQBcjnie8fkCALWxPuenVAEAhYIqgfHbAwCXlz+6F/oAACA4nLSc9gYAjYWzDVpNAwC7s5bmqzoEADFxFXfr7gQAQQfxFRkgAQBWnGzanGYJAGw02zLAXgQAwyxqu1ceBQCkjH17tgYAADMp50T6hAAAim9d5U4VAQCQcy6EXUIEABfkGsRkiwMAcUvqAmcyBAC1MGA3NGgAAIDD+RIF7wAAhCVR8qnxAADW8KmRjgsBAL+jTpTQXAoAYk0auHNWBwDUwNEluVAJABNBKdk4PwkAyIOSpr5hBACxITKqmiwHAE33dER3ZwIAhYCy6bBkAADJJzv1TvADADHl0tXt1gEAorO4AchtAwAwXpPUp+AAAH0NzM633gEALN0gTqlTAAD5oMax+6kHAHw+3QRmWQ8ANYsFDlH8DgAMzLKNDGcDAC8zzpnYlwIAzhsGdl6RCADZNJLz7V0HAFQ8H6s2HAAA2vVY7o/wAAA31qATluEAAOAgE0oCqQMAGpGiydn1AQD4/PqUeREHAMWN4sqo2AIAhwwJsrFKBwDE7MLFB2kCAB2cL2MO3QQA2aUiJtHOCgDZQkdh6Y0JANO122+pnAcA7gCa1DfdBgBeUapJVGMDAKtdR9B44QMAEpehEkcLBQCt9A+GwtwCADE98NZ2DQMAx+QGIRdEBACILe2vURIAAFpP7Zv8NAUANFLPOVrYBQBk6BJxaQwBAPLHWIOgKgYAlOFICERvBAAr9ahxt0cEAB3TaTK6dwMAgFD1uvk7CADeX759J8QDAJJM1K81owUAPnWZQBbBAAAj5G8AhwQHAG/WvsphXgIABGZYzCjhAwDix48ui5YFAM9hvdWjSQAA5vYeW1AWAQBuWDSG12YFAL0vWsaFQg0AH3T4zGJeBQBEkLFhuWsMADggcQU0FQkAOnk0X7pPCQA0CMGcn6QHAMYiingTtQIAWznybkv/BQC/B/ZajuwCAMPspbx1OQMA1PeFaRZGBwCa5woAOZkAAHr5ZHlMhAUAPVv54Rc2AQDFP6jOKUgBAKXscU4vCwcAPGT8jhQoBwB2W5kDPnUIAGZnq7Jfvw0A1jVFvMNfCADCld2XhHsDAOj/tNZJFQYAONGxLaIXAgCesC4Gz7kAAFj35XGc/QIA3d6vUq6zAACX5Blmp50BAI5V0lQG+gYA1EFe0hmCBwBRxnV0dnMDAJBlJBTLlQgAZ6ymKtgCCABQSLyD8UIMAEMGChxPRgYABwlzBVm/BgDZrdFA/ZkCAPflBJre8gUAWRzMuu7ABwAKKfixocwEAI+xw1bq+wEAiltB4fF4BwD0we90WPcGAH8CGUBpigIATdxrqTcrBQA1pmfPISUAANFeL3cgZwQAItZZ88AyBgBS4qMrCbICAIAmEXwlYg4A1XyfPXUBCACUUp0KC+4HACfKTOv7gQMAnWM+Oh+EBwBfRMMw6nYGAIIT56cA+gMANNs9li0jAQCNBwvnklYDAB96dxTKRwIA0Pzoa1XbBgCOBPriXysBAJIeb60mfAsA5HsicQlqBABMmy0NL3IEADrgTiBG3AMAbHkgPOn3BgBN4/yWxPsAAD6ufWu+dQUACebOhRWjBAD/MDkC6TcAABL7lm+3SQcABa6mrgT2AgDrI5OT3DcGAEeNBJut/QMA91oE1LCoAAACHvAQ7PwAAEVOJMSd0gIAvkfBG3uSBgA5CKw0hTAIAEA/A2Q2hQQAq/5mkXcTBABEHv5JplgFAInM7641RgQAuvKHSEP/AQBELQ4igfkAAFE8GKcakAQA8PgajFS3AQAWgTZTjIQHAOk9OOdkGwAAj3xYsPsJAQDRJreHuBsEAJuRZnxZTAsAww+ZtlChBwB0IpKd6ysFABqGZHHtDgcAqcZw4HGoCAC+RkN0RH0AAB2oZKW2ggIAayN1+IDtBABQDEUdvvsGANv8Eoxy6wQAiYm8S5m1AQBgBkyoe0sHALiuzfF4VgcADPHWsAYyAgBdaPIAc+4DABh1HoRHeQoAfujaiHMsCwDoG5fTrRQEAPEOL4NQGAgAiPssanzUBwC31n2e5FUCALqe1WMhjAMARVgAKh+GAwDJrstMHuECABJ5KXYVOAEA4NbwjhTQAgD7h+eNKlIDANL5dF4F7gIAEwgx9jhABgCeTNNYz0gBAFp15Jp9LwcASvwPaR5xDwAVDVs1ooINALO2hejP3AgA6erUuv54CgAn8DR59pIEANQoVYHQ3gcAEmYaUWGEBQBEFd5QLuoFANvV66Ev/wMAZjmTjB9oAgA1FpMhBYQDAFKGMErxdAYAkEipiJy9AwDG6S/QTRAEAKVqCdsGTgkAI7DmiZwhCQDaoobUq3gKAB+VYJKyQAoAye9IWlsWCAAqQiQRXr8CAFauVmcUcwYAMOiHmtlKAQD9gLBlyuoBAPX6CrBjyAIAdmqEoHSkAAAyHpjvpZkAAOa/SzyuqAIALIMUrzRcBADs/5t9tpEFAF21GJ9xswkANtODjDFUBwCXl5G3F3wKAGCbCISwRQkAAANn+LSJBAD6m7SAHA0HACVGkX1+1QMAReVlIXLAAwBP4Bk4ueUFAPeofOwC3gMA75LrOi0QAgBGOgzVIowGAE6JhZOoLgQAjPNVv55fBwDLlqS7X58EABtXnB6MYgUAqyLoCLGYBQAaNimuj10FACh7qdHIrQgAdIYobBpqCADUz1uKEJoEABJmfY6MFwYAdQNxczTwAQCYYEphSToHAKa/3IZKYAUAtmQXfNTRAABRLmoxCBwAAEVQyUXbswIADDCNgU9jAQB04p/oiQkCABvs6oWLJwwAzeJ7ZVnvCABvh1hp0S8PAC8LJgWy6QoAWHAPlbkwDwB/zC06/XcHADJJEvuplAUA8BXKgI4fAABpMuw80RQHAGfK0NE+QAAAUsVOhzUtAwApufGNBPMBACObFzvXAAMAC32j5XvmBgADgzBUdL0FACp55xUhkwwAtzC5u7lXBAAmMhmLXY8GAFbUHo9OFgQAfwYjsX27BQDCTLIoldECAPMvMLhmrAQAUa392cgBBwAnN1tcs8EGAAo4B4CnMwEAvmLKxmf0AQAswV0qI8QCAIewE8AdVQcAzTuwEQxpAAAOj9Wm3EAHADxDeARXjAIAY6RzKFDYAQCc1N5+HmQHAHH1TNXt7AEAsMJWUj/AAgBOzs9SB+4AAOn7FoHdYAYA6/8PE2dRBQBclYW4gsYBAOpjqV/SYQEAfaRTe3UYBwAhLw+L4RkGAATsweTf+wUAkrseyJjXBQBr2duLRpkGADUZqWrmPQ0AGptZGvhFCACSQSG9qPcLABkzEqRNHQcAosTmxOGTCgDP/tr0Ri8HAKP33vqPlAIABLzz/c0eAQAl7f6P6cIDAAU5R5ohJQUA4RJRkksTBgDtBrQrlLsGAOLdwEXEcAAAo9fEItgRBAAy8EfEBbYFADnw5/DG/gkAfEcsabzOAwBeqRlqmHcIAA6Ld6Gq6gYAq8VM7y/xCgCJfMQgWYAFACyX+XFHkgEAQMCf372LAwCBspIAAPcBAOuK6tx2SgIAQMfA37IiBQBI4YA0GegHALlBQ6DZPwMAvCCKZ2PIAwBDilGyB+YFAAHPlqUcQwwABBSAfNoVCAC0EI9vmzwIABZAkyJpNAgAVuQ5MfMBCgAYGN9sjx0DABZLFEts+AEAnT7XuHWYAwCzp//Z8PsCAN3Mtsp6BgUAUZ0DCGt/AgCq3wCAL4AEACXFYqCSlgAAF1gHkeq6AQBgJIaoy5cDAOd5E8j7wwUAAi9eJbwbBABQhplW96MOAEF84NR/KQkAGx4sArRxBwCyWVnwkzABABjGLi81vQEAhuqIm3h1AAC5SOoXER0GAOZmBzKdMwIApy86UYbZBQAPG+GZOj8GAG2y1s8OigIAj43hNWg7BQBxmSGJoTEDAJxydZ06LwkAycRT6QANCQCJL28R3wMGAIjg4HbCPQMAmmT/GZasCQDGgE/7RW8GAKL+ue44zAMAH9twcmQHAQDIDXTq8RAHAN87uMZnEQMAaBBLUkI4AwBF/jCd030HANCgQSFDiQEAJcK4Tv6IAACL8EFjQxIGACUmLRrjSQMAbLGmf3oTCADbfneSroEOAFDc+MW/IgIAkI0XoypSCQCNiU6H20EFADMbhPuALQYAl/on8G4+AADoM5aePKAHAO/lCSO+bgQAOElhaVMvAACHBaKt5VYDAAL5a5/IGwEA28gZZHQ2AABDUlAP518EAH4UlcggSQoAXUyUYewHCQAewBfgUicHAHrpot23IgkAoVfb9hlmCQCMCwyWpnUAAEkb5MXh3QYAQaNtUT8uBACe56j9A2oBADkOOmLRKAQA/QijAURKBwAJgVW51G4AAGeIoPbxRgcAISNvXG9jBADTC9aSFdgBANXFhXuftg0A61BWFy16CQCdwb9tPswEAA6+czgdPgcA+Aob1falCwBfrA2mVocGACbsint1XQUAvYBf9D04AwCmlp+MP3gGAM2eeKc0AgIAUrJ4cbYNAgDaDizaozoHANNwHMBFkAcAWRAlFXuzAQD+z1MjaM0HAOD0rGhgzQUAzHR6/JoHCwCzZAtll4AFAJlOnKyrfwQAzbKyUwLvCwC2+ofYW6QBAHzBbQdIVwYAqBGqAIC5BQB0CQjJ7KEEAMC9Y4iMgwIAMFBGSs+wAwAtevWuuCIAAK0l6XcGrQIAekXXZ0EJBACCamCKyx0CALoxd776AA0AUDMRw1PMBwCBDQj+Zc8HAKEbAWbZxQMA9sb220DYBQDIn52MRgQAAIxreVSF2gUAJQCVcL64AwAJpqYtidUGADFKGQg9vAAAi+GfMA04BgAN7rgsPNcEALbAuq2CuAYAvkzd3atuAwAZrDJiJ6QDALh+RNtywQgAfqe3BcX4AwAQP3/5V6gGADrgf1bA/AwAGU6Cngx3CAD6hHCKLEMCAGipqDz3ewQAZygmdpFjAQDOEIBP3+gFAN4W6nwX/wEA/bW1RZrZAQDsmSRPZyMFABMmGCb6+AAAmIwEmHOPBQAAFdRPJp8DAM57Cf6rSgsAMjolA/w7DADyt5H+x5sCABZKhORhpwgAXsNyEmJcDgCc4ufbFzQFAPWUc4JzRQUA3VD2pu5lBQBJx410UCAEAImIRnMtcQEA3ZMxzviJAwDlfBe4JNQCAM1ANA36cwAAl57UDAI5AQDOGasAmC8CAJn9bprdnwoAPygoqZTGBwA6S+TuzfcGAMNcsgcyWgUAjFk4TRoXDADL+J4+ijYCAAus4giqVAQAAKePP5KQBAAvWKSeqnIDAGJH1mxBPwEAjEzJmapYBwBE/wAXAPYFAL0BjEhOaQcA1u5I6f3VAAC9dKVPIQgFAMMD0FO7FQoAwqgseZ4XCQChQMhq6aABALY6u+KTIwoAyoZMinWnCwBL/tY+FWkCAECY+K4jKgcAnGmZUr5SAAAWIxPv5aUDALr6xg6WLwIAdlCuk/YRAQCQypSqv+MDAIe4dpR5RQQAeUhGEglKAgB/3vgV/dkFAAtS1+4qTQQA5KfC0mUIBQBA6jhSW3AKAJY7XbJwbAwAuH6kfxi8CwB/cmNt0wgEAGJgpvb4+gUAa96oLYm7AgDm4sfw1GkHAPv4FFnzMgMADMKG6hUBBwCorSTaiG0BAN8qZiIGmAEAnVoZvOsBBQD7Bukc2FAEAD90rhyW2AQADrp9jMO9BgBjtOGntNMHAPOt4t5LhAgAqmOWJ63LBAB1UiCmobYDAM9t0JEn6AIAhzypynI9AgD0qmirt/AFAEVjutQl3gIAzR/XoCSQAQAaEF8RZV8BAAiXFGeQ6QQAr6XL0dgZAQAHIP7O+9cHAJSQwvPFXQwArnm1IFJFCwCJBh5jwXAIACCbDmPAawoAjM1tGc35BAABKGsmah4HAF3f4nOumgAAo7EZstgNBAAN3hdF+0YFAHV76DVUlwUAaDd7atiXAgAyY0wvWoMEAGBBQ18wcAAArlZOAd2DAQCgh0MI3cwHAIDMYGcYhAQAYTNTZVZDBwABuDZjaC8IADBD9kZUIg0ACxlIqDxZCwAXBCZtLEIGAJS7F0iQEgIA9VS43hmjBQB92mDg1KkHAAwd1g69KAQAp5qEXpoYAwBCslkfu6wGAAxjU0fv9gcAqS0qKUbzAQDWoo0wmHMCAFMkcApMDgkAM9d7o6/aBABhiT7ca58MAOXa7Nz//gEAw5JUlMJyBQAT1F5DKI0DAFgomRlPBgQAzUP1vg9oBwA8jdWD3aoBAMPo63pZaQIAvjDN1kXHBwDveN9Vd3wCAKN/kzNodwEAVRhEFlFABQC8BYxJhfkHAFBjvw9SFQ4Aadp0v+m5CABoESAIg/4MAELeJ2H3cwkAsGnNUyYPCwAX4QufiM4BAAkHUZRqbwMAtBYAckjyBwCRz+HRHoIBAB+jcMQubAcAhQzBqjjJAABBcXntZBsEAG1eGMGxvgEABw9gkFTtAQBHlhU/J/ECAMALp1XXiwgACOZciDqeBADWWhuIhWUJAF1P02h1wgMAX9x+mcGKAwARHuCKfPwBAOfoc1VNCQIA0kn1uzzKBQBDQcXsIPkEALaFrXLl2QUAO7FRpxe1BgDMgLFw088AABr00SV5NwUAoghgVlZOAwCe/svZ/C0CAI7gOxC0WQQA3SotP0uaBQDrjrvINNcHAAlKWb48OQIA3kyCd5j+CADZDA3D4NIDALtxZmiX9QMAmTm2fliqAAAZxpK1x+MAAIxEBWyRsgYAO5G6CtE0AwDbz4G1zUUAADaPOlXg4wUAsv8eBLMLBQAA/wfzA8MEAO1E2Q1YAwQAP2WSffeNDADpSbPjn4oDAOGvCoWJ6ggAaXCrUbEWDACFjLIX1jsCAGFafecu5wYA3k0X/3KpAQAPxnNjY+IDAKuyeI8b1gAAsDbB6e/XAADVCmSJHKsBAJcf9K6CXwUADe0X81dpBAB+J3SvopEBAOgORk9DKw4A+9P6wMaUAgAPTHuTaIMGAFuHECn4yQUARQXg2+c3CgAxFDzFS/cGAMLZu10OxAEAl1yunPvIBgDat+FcXIQEAMy1UOTg4gcAMLQBZ+11BQAmAKJ/4dMEAFNCjIj8kQcAwYoHmbrxAgAVEZtp+hoHAMNQO0ccPAIASB3iHWfnAwDooUdV+iYDANmvX8JNDg0AiI/H+zEHCAAdtlM5m28GALnMPCj0VQUA52AZ+2fdBwDU/q+hB0cBABwrnC4UIQAAgBj4SBjHAACGPCPY2UsEADBY/o5X6AYAtUFwbVsEBAAVfjTz1sQEAF0Zj5j83QQA4WWjPhf2BACIRa752kUOADpi22M31AcA+YgKUPmLCwDJH33Bz+wHAB6DggcoygQA1texfTO4BwD7lTjvbREFAEd+qtr9kwEAb4foNzzJAgD6g8UoGkMDAHnYi9pJkAQAHMF6QKi0BADU8OuZ+6YGAMYj5La1IgkA1d3x31AeCgC/dU4ydj0HAI5BlVRIiAUAXiz0qf02AQDrVQhWu8EGAEitE34SHwcA7FqQBLPGBQDHm4iOa3UDAIkxSpF2XwcA0b0Fo7HfBAApH4EF/7MDAC7ZPChi7QYA4VLsQxVdBgCNvhA1GCIAAGx6MEMBcQIAq/OLtI/YAwB6j8FO60kKAF4p/10RNgkAA9QfRHw4CQAULa1eOGYHAF4JBotPGQAAYjuC9niEAAAIc9OJhgEGAAa4F85xoAYA+IqXh9HDAwC6doLI4a8HAGityIHyHQUAXSSkvQZJBgDt8aomGxcDANFHirLYtw0AwDSeFO7CAgBT/Jpi9XYHAKlJ/FDq9AEAJEQzphTFBgCoTFaXkDEHACU1I7xOhAEA4e79Q0UdAgDSG/+qJ60BAAjPc0j9IQIAQWMVOk8gAgBkpGVAQTcFAIPP7TsMPAQAIKZucH5VBQAkuW9Zqo0EAICXTMhdHQYAnsJAMOh9BADnB2Wy3okJAJlH3Prm1AQAp+igf4OMDQDHnKVcZo4CANkNlBXHZQEAlRyhOl94AABphOPXmHsFAIStzG/ddgYAWJD8loVoAQCfYQPUam8GAO9yd6hZ1wQApL5zYW6FBwBXaiw/98QBAIQ0fPxucAYAbTbsOXiYBgAmf8+VH3MAALzkvI51rgsA9dq3rVkEBwC7oF8wvU8CAM+hdcyYCgQAM3UKIuGMBwCXweEQeiEGAGS/0YCslQcAsyu0kUnbAQByQ5lbYGkEAFiaXHHjMQYAj3LP78/pBwAhzkgoFv4FAPWxfF0thQEAD+Vcvg8NBgB1e+NG4qEFAJDV/wXuGg0A2Xc2BEy0CgAalpThTyEBAMvpqTmu4QAA9/kmtchDBQAd6WeASRkBABfJb0SdeAQAjrdOB6uHBABD44xeO9MBAEYb659BPgEApOZdVh9yAgCau/LuUgwGABFtrnzCxQsABG6VkZRqCwClHRPJuiQJAFwrIN73tgsAZZuNJHcNBwDxi/07vIkFAGtBo2o++QYASK7B1qPABABqWAsmh1UFAPzMEsPJCwEAW6DCPkvoAgBRFTzwop0GAHumYUYXOgIAOPKJorwJAgBvlzq9VTcGALes8ZcYEAcAuAd7tyzYCwD0aXc9CIQGAAfOLUcoKw0AUXxzUTd2AgBTCNEqPqAHAKs2rcbcEwIA1r3VQOKmAQDf/vj8T8IHABa8SBzM2AAAqRm0btMCBABSoBSM9s4HADnRwlsl8QAAahgx1OdzAwAWrafYLQwHAAB+7bh9lgQAOlIv0O5aCQC7lNCRlRQGAAZwwQTycgYAU2qBE4YrCwAO7G+fUJQBAKysMcrYKAUA+rm4c22CBwCz+eCZy0oCAEg5Nsb64AIAZM1I5L73BwA8D9oQD+EEAOkgq7lskwMA0GzqT/ygBwCkNccVkhcEACHNayi5Mw4AlJzburPKDgD5vd9+OE4HANkPisUTQwkAGyRiVqgfCwAq7dzX55QAAI4RjnP6aAAAK+5fCmQbBADUGfCdcLsGAJnNMEo0AAcA9CI2LkJsAgDwtQVqBvMAAKaABI9E4gQAlfDb4M1EAgBSmSoxsksCAFhc+PUqDAgAPojyTJ9gCAASyqG1bugGANHM76JEiw4AtP6fr9LRCADDZ94yF+0AADUWKWnDCAMAUNLySPM+AwC7oaFeRwQAAIjhcejj/gAA3x5iMqGKAgA7Na9MJCsEAIrgwkwGawYA070MAiC7BgAxhXF5zWoBAK22h3jFxgkAKlnXH/KrDQB5hlMS1AsFAFExJ3ELgAsAYIGxNO1kAQA9HZstr3IHAFtOi0SG1AYAqBiN3VjOAgCLPFBnn4QBAAKTa+/gIwEAmuYvGUzZBgAPaaIiUkcFALO4hp14kwYA3Gn7vcP1AQA/B2H8oI0HAIE6DGjxgAcAU9T8PF2jCgD33cfN5QUIACOseICI7gYAOGsxS6pUCABqxivlKF0BAH7LUQMeDgMAjB+xdC8KAwAD3tcMEp0DALFWsu5d0gIAuHwmGY1GAAD5+7Wp3IwDAOKhLFywuwEAM5WOdRWwAwDat2oKYTQBABX10XfnZQoApDkeTPXxCABFJlKVG/ACAG3endvY/QQAzJe6jIdUBgD+sPaNx44DACJqo76uPAEAal9O5cbrBQC4Dj2QBCgDAA2yotsvEAIAoeZcBQXkBgDTMqU1SgIFAJ3y2lSQ9gEA1Yt6DR1dAQDLnrJdcq0AAIVvBZsMvAcA2P/6v/4cBQBJ9U3pu0oMACAx49e77AcAmSMw9XX2BABXJE6DsWcCAIi7eMMZrgYAEtXZXntFBwD7BT14DSgDAAMat//8rgQAHhcVBDY2BQBleAcJMzECALyvNENEUQIA6FY3hcOwAgCGKiq3y7wAAJYS/lBMXg0ADMPvE91fCADt5YDDxsAJAKdi++Md4QMA8wiR1o9nBgDIqbHqL5YGAAujuY+irAYAmJ8byrdtBQDdGHBJWJ8DAGudtQpPAgQAwmNoYzH6BgCwQn6m5QoBADHaH/C7egIAvE/muaeAAwDU6gghLtQCAIB1Uw8NewkALYTJwGNiCQCjOUV+gqsEADrXQ9sNNwYAI7R5Or8gDACb0t+UFRMFAP5SjeknpgMAYVaFQUAVAQCEg5/QdZEBAC2Ni2CydgYARytbHGW6AAAnEHBjI4YFANvGGcLWxAAA3liG/z3wAADPwKn/0kUHAFdO0yFX3wYABgx6di/zBAAgbsfqq9UJAOPhBOHpHAwA28FUvhVuCAC9yMkrHloCAOo3sPPIBAEAmGypb1cFBABvh+OIaugCAM9guc4jrgEASpkyGYddAgBuC1Y71rkGAHLUyBQo3wIA7aQK4r77AADseBKG7Y0FAJXJwraoWwMAv4Uxi6XeCQC9uyPNVbQEAPiDSMAZ7AUA1TG1lqaLCABcxWbykzcHAAI7yamIuQAA2yUjow6bAABefMFxrnwDAF9Ihd45/wIAesXvw+4+BQD9LgLpn/oCAFSBEyzHmQYA+B+9HnUqBwDPR0k7YyABAPcPEklHMQUAV9DA982vBQDtjXgb56kHAIgMO49w7wUAk7M8vjN0CABCAGGReJgEAHIBXX+dnQcAxJ47AZPCAwDKyjlfuMIAAFlNm6kwXQMA9JfpXMBEAQDvfzSKC5YEAPd0XfER2gEArf7AGaxPBQBtr+ftc9gCAG75XU7hAgoAS7U+vALqAgBkNYiydYgDAN3pOlGMKQkA/xWgGDZUCAAJNDdDZDECAK8iO1CV3gUA3+LqGyCZBgB6c/9JWNsDAPoHR2Vz5wIAwSNMl/S9AgC9YdLIubMEACi8qbLoagIAUVwWEIIGAwB50GIzRLEEALicUhzpVAQAz3K/xphMCgCZ2MOUZUgIADv616MTrgcAZq+OQThwCQB6H262x7cEAJjZ74WhvgQA+FUQcbz6BAA4/jZ4n/sBAKYtdUb0ggUA5EwyINN7AQDGmHgRiRQFAAtBoJJNaAEAp8V4D9nkBgAo2rzEocIAADJpvWlIgQQAuF2kkcO3BwBBtjWsFnMFAGoJ6R3jQQYATTEKs6mmDQBHBB9v0McFAEk6C/hw2wcAeJrIPkrLBgB9OYGt6DsEAGRvHL1YxQcAPUaW0yQVBAAdGp5Ea1gBAIrtSpB+8QIAjjwdhtLhBwC6r6BcSkAAAL5vQSobngwAVmwxC2ocDQDbG9eepXUNAB3sHxoCTAcAjn9uUSeVCwDWQ6cKB0AHAIMR3ctkawEAQ+sye0s/AgCzNYKlqxkDANmt3L+VYwQAnJpdGi3bBwAvQoULIJoHABbdcaq/VQMAqnhf6ncLAAAtgp6ieWUHAN80tFITtQQAZyYc0HsyCQCgyGA71zQEALpDlKja4AsAdqKyS1EsCAAXKsBJfo4GALbobzSVVwQARjWPbDCJAAD2iC9rn9gGAFvgyU04OgQARbbxi9rVAwAJbWqp1t4HAE0v7k9JwwYA1GuLnJgsAABIFZYgCRYBALpNmzYWVggARm+shqvsDACxANeFAMYLAOn8DeE+IQgAbR5J1zf2CgCqz9opaRYFAIn2MWuCkAEAfUppZ1X1BAAi5bH39AUHAJhWvCXhUQMAvnv2GkabBACWOixxFVkHAA0MWO9nmgYA/M9w7zhNBQDifG7QgvEHAA91IY5ySwUAKAEbl5CaBgCjY6nyQBoNAL6mEqzpCwkAxEEyBMxKDADsaAGrZI4EAE9vqLi9ogIAKWktazs0BwCj6YyqBNgBAOlDw8hKfQYAd1d6T7trBQCPI3xiMJICAPvXLBIarQUAZONQbqXeAADXKjHI0VYFAA7oG7FWZwgAPbB7fhRiDADfvz50GWUKALQqaFn8ggcAx8iM46uXCACCOY0M40AHAP2CRn+0wgcAHNzHuJHNBQCD5fmQp38HACTY0cbGRgcApC2lfofJAQCJYaiDe7MCAKUNMUmvMwcA+wQcFoFeAgDovjRK4XcFACvXTb2+zgYAnzJC5MFACwA+qdH/RyMDAOC7LCWJSgEACbCPSzAFBwAKO6dhrGgCABy+vjTyBgIA6OvLpwO0BQA1QZ/wYKEHAHj9lu6nDwYAxm4pTTUdBQDHFjum9csHABQMz7ML9QIAWsbKhbP+AQA1FsrgmBMCAO5Vt7T5qggA8kSutZFrAgDIsXqNgN4GALAwVWdppwYA95hOKPu7CQDzMys4igUFAD6RFhipdQEA6Ipruc32BADSgdrJR3MBACNa2dk+qgUAYWXZx+l3BwCszAbwWI4CAEmsLLu7QQUA7EyZgjLmAwCV6OUUfqAEAJukd8TNWAsAgOQC/ojMCwBq4/S3qiEHAFOZRsmMQAgA+UrYrvcKBQCZ+Q2YyxIEANwp7tiN5wUAXVeM9t9xAQBJ7/bSXQECABPTkcO68AMA5Vv2FQHeBwDJTTYhLCQEAJhgpmRbtwYAhcACATwDAAC9rmsxGpIBAIvB89marQoA6pozOBbsBQA7qFllO3AFABLWBU2f+gsAKwbK3kmwBwD8cLjffi8CACixd9buaQUAr6Ww3DcJAwAb6nicA1gHADonHvSNRQYAg0RENXrjAwCZe9K3/WEGAOQh1h12FwMAiWECMDwyBwBQKbzMPQkGAEsDhGC+7gYAe40K9wHPBgAKZ8ZUGrQIANpVu5lLyAYAR7aYDBjjBgBtcOCFhZoDAP5jJud8FgMAl0Lb7BQ9BgC4cPncIb4EAHqChKAefQUAcbAooee2AgDPXXURdbIFAGUFk8KEhQAAWUFv2nuMBgB72d2Z6WMDALOuS+LcSAAA4wXslVe3AgDJbdrFpL8LAB03nmXIqgkAmm+8efkxCgDEH+41wUMAANXyGZkcoQIAzbpdwkwzBgDaALQX2pUCAKCThrfpjgQAxvMqzEveAQCG66MRxB8GAMAuwZrRPgUA4AS4xtsJAgCSh7Cpv3kAADJC1aKA7QkAeF4qx/4OBwAtgirUUSEEAOgx1rbrtQkABUdZsU/vCQD0DTDaUToAAHIcViu1ZwQAkOUQApLVBACFlniedsoAABdIaH/HOAAA7HsWW+ZeBgCpULgZ2lIAAClkZWWGQAAATJpvWTmrBwC/oKSS7nUFAO7XpApFvAYAqAs7d6b0DABHvA4LGyQGABWTHU+cDQwA9ILj56EACgDPLxiKkIAAAJi6txMpUwAAw4XDeM/cAwCpq17dAoAGAD/NEnFOPQQAxTr56me5BQAxCljKrGADAGLyxtVfxgEAq+zCFX8cBwDkUSal7FAAAOpo5mB2OQwA9PKSVqfCBwDvZmx+nrILAJnavFimKwcAGhP6CRwVBgCcDD9F3hoDAGh4cwfu3wMAEdSn9+wRBgD2ZL1sfmMCAI/FIWzusAQAll3w/Q1cBQBeR8+dVgUEALuYdCdcXAAAicNd2YiFAQDwAKhP8v4BAHNrlzD1rwoAWYTASFrYCADfQjaW65YHACa2xFDuCwYAQINs/gWACgCWMaca+1MGAPoGg+z6BwYAVFI+yF7oBAD9hAWQVp8AAIb8kpLURAUAiIZSNJ+6BwBdLbQPooQCAP5vcNksZQMAs+bdrXv9BgAW8zApRy4HABR2KtM19gsA/QDerOzLCAA1qepBEUEDAJTL80IeHAIABv4A8Of+CQBPCIGXjCAFANIk3KFoZAEAqEDFCni/BwABU9fOfqYBADpzwujSqQUA5ffbA9oFAwDKrreZhiIBAMlrk7IjKgEA6eZqpb2hAgBA4B4FlA8AAECXrwe7kwcA/frU7LbnCQBC+2AVeywIALZfzDRnKQoAP90l/X97DACyMNPDI2sFAKbRYOMIdgMALnLI8+AKAQA3thi22YYAAKu+6Md5fQAAEt0IvJz7AwD/cFPYPVwHAKwZKP4GfwQA7RWSqwbbBQBk6jUKUsMBAEbAayFAbwgAtNkPm1eiCwCL7H5AJhwHAAtPtUraKgcAEm22w1CHCwBKo8u8plMCABpwMwQHJwQADof5WI4LAgDMANthyDcDAO7QdVfQwwEAGuUilEDxBgAlLc6+a4UHABwDL6eAMwEAuvOngBA+BAAEM30sHmIAAPPw27CWFwYA9dYynC88DwC9flPRjqoGAPQ4GMmSTgcAAhDKieXYBQCNg1mCzGAAAPOVW/PTOAAAI6lDwnhgBQCyGySTMt4CADq9l2B9AAAAS6lCCJUdBwAX2MflEWsEAA1Py76LRwUAXRwKSwXDBwDLwYN3PVgBAMconcwERwMAAPKxmOXeAwCebXSYHG4BAN+vlXALBQQAVTzoZICVBADheqJd76IGAJ2dLuCsigIA6PBl6VkkAAAzCRXTZLgHANge6PKlUgIADehmUCaUAAClYY2RD6YAAN4P8/dLRAAABjztqQ3EAQA7hL1wwXkAAFbQ1cBQzQ4AuXnnamC3BQCh3WsivQ8HAPkfOVMeZgUAuBdzDYx2BgD/b/pk5OwGAKBgpLxAzAMADI37CqnjBgAoEqG8GoAFAJ+sNF7A3gYAs8FV8eUlBgCWMnJvL/MEAM7vBQGYrAUANu5eFmF6AQDV3E3hRRQFAEKkviurRwEAJjEl8kDyCQCITjGe3sMIAF6k/KSlHgoA/OSGAJkuCQBRSRQ7SysAAOpqlneJaAUA/Z85bheOAQCLk7ReXOQCACk5HvOGMQEALrvff7OWBAAhPl+dQ8IDAE1qfv5gbgEAHWKbiO/XBADp0wU/LnsHAJGw3RKcYwgAsnrNkAQYDgB7RpeCkfMDAKyBF75oRQcAleBSURl6CADexC6cxakHAC1leZ7w6QcAhi3yIuSjBgCLbIM7jq4CADKtx195OwYAyF+eOAKPBgAGdYe88VkAAOwMQQ6ZBAUA4q7+0NebAADwMtCD/ugDACnR7+iNTAgADSHmBnzGCQBpFH+PN4MBAInSrs5SQwYAWGKaiWAtCgCUonAFuRUDAPElqQjhDAYACclTEvbvBgCwcC0O7wMAAMT6l7ejWwcAltHNcMDbAQBHTFOxj20BACr6g4FJAAUAdd4jxFkvBwB5d7gHTZAAALlA+UhmLQIAhj6HoaWXCQC7VBrE5AcKAM/WSzsLNgUAcq/rrAokBgCckbrd1B8GAJlWtZHp2AcAbMc8RzEbBgDWMeYxlgMHAN3B+0MhPgQAoJWiW5x0BAAGX0v6RnkDAPFRWqvFJAcA89OdeDNWBgBA2zjy2msFAJ87ncFs0wgAYSLXcETsBgCuqRhwPYUGAOvIwk0+qgMA5eEHFaM6CADrMzX147kCAMUGqCfXrQIAoxXOyFVpBQAOKQoHT4wBAEE32IZK0gEAH87U/0h2BACdnoORlQoGAKsXgfPVJAQADsESacQsBAC0rskdJjsEAFETlWyLPQkAKWOPfgHABADE+VOeVT4FAOpuiEYBsgwAPykkXk0rCAC7ebuIGR4DAKu8s0YvuAcAQXuCzqj3AAAwcRcWWOEFAHay9VwFJgMA8o3RKMtVAQCUFqGcDcMAABkxqycOCQIAtkl6TmIIAgDT5ZqAbHoCAEFpPcQKJwQApVlW2UztAgD5KHWzDVwPADOSLP28zAIAwtgDNlAhCgCIsQ0fzesGAHQRfUvrTAcAXE/faGHVBwCK0W8Xeb8AAAr2TxdnywIA0OELOfnNBgA9K36cUY4AAIEIpdLDUwIAPTOOREEbAgAPiXNL37EHAIz1+AcYIgYA5Ys6gZL6AwByVY3DmNoGAI9GVFXZHggALTVdJJiGBgAkorKz4PICAJIcLKJqxQAAeLLxOez9BQAG8cf1CskEAMWPZfLOHwYAehgYKoVdAQB2+5q123ACAKuSzwsS2wcAh0BxXaLnAADw2nPE9GwEAC2BSfGnbgQAJ4QKaSUHDwD6efDpOqcIACrGYUSS3QIAzNhQrloGCQD55cSe7SUFAExoYAbSIgAAaHs5cCuXBwBl+dNYOaAHALVO0byHkwIAVw0g3yVFBACFQ+lM+dcCALfscMEADQYA8NjzAwWLAwDO8WSOGZoGAO3Kxdw0RAkAH3xmn5DHCgB1tR+dgxoGAHa7ygA48gwAfia9lyZbAgC8eBrZ4LICAAzyzBIKmQMAIiYf4cJBAQAgM6X6zt8AADpJkmqeNgcAZGiYE/s/BwCsE/e4KygDAO+X8njtnAQA7x1mJ3BpBgDkVNuDBkIBANBazMFvuwYAnWaR1cgyDQAybKhNea8JANIkbdjp4AgABx0WtIMeAwCX0Z0kHr0AAI9WIBjLCwAA1DCIcbHqAgDml2mB/ZYDAIpQv75jCwYATysGnhLHAAD9EltBJuUBAD2SJ/2gYQQAt6Vw9q2LAQBQ1WLr8VwFAD+M9X3jtQ4ADcaGOfO8CwDm6lyDuE8MAKNxjsHemQgAnyumum+lCQBYPcJlEBABAA+LM5ASqgUAIXQunn4VAwCJ1BcgceoAAIlwRVamaQYA7MmdXFBrBgCHUuOG73QHAF6VwETZ0QQAICvXOUwuBQBYnHk2SDwBAIDQi11q+wQAm1gISeOKDQASr3uXTZUDANxBdFnqEwQAW47ch9wLBQC54bNaRl0CAEco7Cf++AAABk/w2+bWAgB2Mhv8jAMDAHtjOsmAbwYAEeHfboM3BQANLHs1Ar4CAPjUyFju3AYAkmEdWDLXAgD9JUdEVt0BAIfIuggA5gcAUhh8OFw9CgCnM/XxXZ4HAM/wxfH55goALzr2UKSjCwB9EmIz+H8EAPSxgq85jgAAq33yLjKIBACkoaI4N5cBAPcZIpFF5gAAJ0Y52DEvBwDxAKKU0nsAAMZ04gC+ZQYAiza28eg9BACaOjnZyBgDAIXTHaspngYArGvHs4UGAwBZSPI3z2UFAPn+jsIqew0AT1kyHKQJDQAZ/v8qA10EAE7ebJvkLwEA8XwyvGMWAgDd8WlMXooBANWhecbHJAIA6SX5ptxuAAC4d+Zjg4wGAM/75CX6DAYATkAJdsHEAQARijIC/1sAAOQSxQ3doAkAD81fv5QICQA2nD8BSSkFAMc1R7oP9QkAGeDefCd2BQAL4MojcBMCAMYm65k1WgEAPCtRIXJoAADpJAg6y1MCAKSiP8y4gAcAXzBPI7yKAwDeA8G7gKIHAP5daTaomAMAGopSQa/QAwAbJyaHQf8FAC2VthPoRwsAujwcwmRoBwCodM3bSeAJAJt0kw/WtAUADArKuE2dCgCd24kXDAgGADGnHu98vgQAgICddg30AgADpkRMfV8DAJZawj2gBgEA0FMzM68KBQA1uzxhmrUEAHaa4cDfIwIAZMWyKx59BwDLUhClOKsEAInA3V/v0QcA2dq56+q+BwD7rKAL01gIAI+uteqSzQUA0k6waxwECwCT1WhnJSsEAE97QlmE6AIAAQdjdjgrAADl6gXUeEgDAIoI3BrdnAIASOFW2fnyAgD+wWWt5rMGAF2et3IJsAUAr11MI409BQBJQIHWuwQBAFDxf9Zfmg0AKjXQ6pipCwCZr6RfyYMIAG4mAfzb+g4AcbAPovIECgBn7fFoMf0AAD5KeOcNuwEAdwSyeMtLAwCCIS5uoqQAAKeScMWMvgUAebDrMD07BAACGcalrFcDAFUk1sVwtQUAxxgenrIPAwCRJ3yxD1cCAEckuAtVqQYAJSMaCvIRBQDumyPXJJMKAMMWdcM8NAsAF+Ad+cVBCgB1FbYsfzYCAN+HTcCawwYAveXXi5XUBgAyFYpj9GYFADAwpV623AMAqmzeQCkXAAAbRWcuWwQGALP8PkYHbAUAkW7+a4tyAADf/NXtIIQAALsQ9AROwwgAaqDQwO1EAwBtTdiGVOQOAPRjOMsuTgwAtx0yT2VNCABK+mKDqyAHAL/ZzUdDnAIAY4RfrZjnAAD+C8uL8f4EAHbB+z6l2QAA1bW93RbBBQDPq6W7tNEGAHpTpUiK0gQAmQsEW45rBQCRiWHypKcEAEsqN6+RsgsAl0T+KDAOBgAJak/KeyYKAEKyQsLuGQcADj4iFGOpBACVX7FfAhgHAJT+cYNrjQYAfNn3SESAAwCAQnj+ZiQEADHdzcRQGwEA1v+kCEQnAADdNNuugtMHAF04zsnPCgQAHlukmbsoBgC85tzkvPQEAG8LncRuYQIAHOZihF35CQDFWZGbPq0JAPhNoHWkmwcAlRVW7iwEAwCEJSTiWs4HAOPUU7Fe0gIAyamb0POoAwCO6wQNafMAAMBxS9HNPwcAQaybRHlwBgBPSCFGnLcFAI1rFfJpEAYArxA7VybrAADOqclA54kDABWsDlf2eAUANzmcM/JEBgAsbJW3R24GANBVH/4ySAsAYmJdXkJcCgDOudw0rrMEAJ+sFRppfAQADEBdbuAYAwCxPvjZIsQDAKZllDdFFQYAbt7X8aYGBgDnB2HEwPEEANjl+9yxKQIAJxN7CsasAwCEVJEImlMGAAZKuxTU2wQAuNvxSQiTDwDvymakxSkDAJvrT1QkyAYAmwHvIFP2CABz99LDdB8CADq9CI24JAAAUUEFz3jmBgB8dC4nMTYEANFcrEpeHAEAxuD9yrHRBgCQOjBqx2IEAJv/PGlOygMA/YZX1CyVAwAww957vMoEAInSeD+PeAcAEfizCSiUDQCbwvh3MpcFAGf+xTv5EAgAsaxlgUnuBwAuCpwIJJYGAHME58hfBwAAEyMdq4Q+AQA7lfbtC8ECAMghAz+5OQYAw6ERkeMIBQB6L5EOEpACAEOurGT0ywEAV2FX6XNTAQBgW8iT9O0AAABBdoTSxAcA7KwGv/7+BwAAQYJ6+5oDAGX950eOtAkA+R1NxQBMCABoWptZWIEEANnVQbx1/QEAPF2pH/zZAgARug7yJ9oHANQZMC65AwQA+FxGi4EvAgC4Cf8dkEIDAM2Dxl1ZHwMAgtZfdFd6AwAXJqsSu1UDABhzjFrH2gEAYDRC1Xm2CwANQLa3/LgGAJ1fvoM3xwYAKgWOr45RBwD0u5N0zGQGAON0GHaUPQMAE/aWF54XAAB9huI1BYkBAOyCIRO4+QAAMmx/G8RZAACRFFMGh54HAIK1PGRHxwYA5JTUCgziAgB1sbtxOHwEALBmUMhQXQYAfB82U3QWBgASs4uBo2sIACF1qpvyrwYASI3OAuqPAABIT+xxl1MEACjKrYsxuQcAxRbgrxkPBwAjjWCxe+4EAGlkV7iJCwAA0OreaHbdBQBJcKQLbQkEABSRIZdZJwYAruZnitqbAgBd93SagnMEAMkCOa06UwkAeuQRa+DdCQB2C5PRvoQHAGfIuZIKyAkATE7UtGjGBgAYxHlGddoCAFoQvjFMFgMAX++YK6wfAQBWknevGloDADyDxISGBwIADIJ4eiHPAABp59LnJFAGACqo3e+1OwIAxtMyttSfAQCk+FRgGkEHALR1sRg95QIA80ogVHI+CwDExKHV17wLAA5d9irCxwQAw1gkh5rsAQBtyJ25Mp0FAKypIl4HrAYAcTMRIJILAwBuljim2X8CABO4T1c2wQcAm1CiANSkBgAcl1YQeUEAAFwHbobVVQYA+E3m8yswAgDWfFyK2K0DAEYwOVnUmAoAt5A9y/4LAwDW+D3quNkDAHkVUZYOkAMAakAaE6EbBgDy3DW2cFcBAHGV94PNngUAvX8LHEbbAgBfNIGpQjoHAHnIzJ+SSQIAKZCVFvGgAAB6NLHXT5cFAK3tCBzM4AEAEx+t+L1zBgCOvcsQA2IFANaF4nf0tQYAyGwy7JHtDAD8owN1U9YOANSIOXbTJgYAzlg2b4TsBwBD1jRJQ5MBAFGqXkSi1AAA4G/ninDQBwDhx8O2R5gDANnZpKJ2dgMAxy6iHT+PBgBrc6I5gO0GAHU8TOB+YgIA0edHppDqBgC5mTNyr9oGAI+Oray/BAMAB4sQfZECBQAP3aZsF0MIAIMdLI8V1QUAO+tYnkS1CgBHvj3rYnUCAOcLF7TXkQIA4ajfZ8rRBQCimPJhgKgCAH1icZ5OMAEA/pzcatIUAAATb6EbafEHAKxu8CgY5wUA/P/wB+1JAwDdwtfijUYEALsHY/jG2AoAcgmFoWsoDgDTRISw3OkFALJiM1RqqQkARjLmJ2TaDQCeRhmUXjUDADeK6rh7hAEAcZvPiGX+AQAia9vSybEGAEu0/8bnzAYAyiKs3ojGBABSA//DdfcGALsZ5D5gZQUARhzGVkRUBgDyef6rKY8FAPbNDnG/ZAoAaoknhcUIBwCUM8Xm6iwMAGkr6CEbOAQAtIVBcpOvBgBoPueNq88GACG91M7v5gMAvg1QCWYFAADfha0keBsHAEF/SpxidwUAiKjGCUUCAABEZi6xamkCANiAS3+izAAAnhEb8cHHAADsyrBb8gEHABPBvnzZ9gAAo5N8+5fODAAaKBFagzkJAFWR2nqQKAcAVQkFvKUgBwDtbGHk+LAAAHW4D7XE0wEAmAHcc5byAgD6D4PxsPQFAEDc+yvJ4AIANVqAm0MJBwCHgX9VSOwGACw6oRtNigAArvkLijR2AADvRLHLuekAANu+sV3VmwYAvTH3R07hBgCsDidHXqMJAI3feFQibwYA08+RQdRmCwCtIFf7j9QCAHffoSF/ewUARQa6/w5VBQAxqZhAauwFADfzs04QIQIAFIy88kMXBADHc4etsJYHAJtou1zunwIANIcXXGYiAQCTxWtOehYEANuPzvhlJgYAV5jFGhCdCgD7n6W7O9kEABc/N5d4ewkA7LcMNzNLCwAAJ/Z2KJ0DAIdsHc3OAQAAdXZ0ERrwBwCQgaGlDTUCAFIl4reLkwcAzNaBhu6RBQC4eeq0sJ0DAEIIOA8iAgIArOBCunbyAgDm3+LGbxcBAKUOd0mJ4gAAcnsUiJ5VBQAw72NuHl4LAG7/p5oQWwMAkCZP5aP2CQCbYZxb0GwHAJUWkLBUlgYAJ3+3EDelBwB1gdKnHpoHANV3xqTDjwAA6jQH05nBBAAUzJrLIsYGABYCA1UKZgUA+xGfGfFoAACQaxHQ+vIEACW2O7cd2QwAxBKBU4JfDQDdFZgnWtgGAPmczbC3QAcATpTylRlFCwBUTq6UQbIGAJeI7f0KIwIAcVB9YRI0AgCbljUP09UDAO9ySUpIRQQAfH3qn9D8AgAq0p5rEpYCALIFKgFxoQQAI1VNx5LbAQCJQmDKiQsBAFvwRVq+QQkApq7si7OtBQC78kHbRv0LADjOtbuI1A4A0/CeHS19CQCcKBiXSUcBAKvH5GeKpAAA469LVLwPAwCK5V8xAccAAHV7V42HCwIAaj4/BxivAgD+JA1C6joDAJT/9IsAmAIAHpbbcZFTAwBcxjz2FCIHALYpO/S5twUAs6PuMepJCQAIFlgTd74EAJheOWB52AoAU6FVyEryCQCTpgdTQH8DAJy28mzm5QIAU5yuZkLYBQC5U+h96+QFABwXWIz0/QUAqgWVjjIIBgCaxB2EgiECAAcjHYmW7AMAAy7y/2PzAgA5ruI5pwsAACa7iOr1JgQAyHV/55IwAwDnGdhAOaUBABOGgU8uEwkAjFF93pciBwDWkIdc3pgGACXrW1S4aAIA3/6Wi2TSBgB8sB2tiHkEANd65qODMgAAObkMvscdBAAECRBmbLEBAG3GyyBMogAAgYbk7+miBABxYoSWEl4AAFBFLCTIuwcAtzU7EAaaDQAyIPNKfiMHAHpTsxpCJgcAjCU4XfKMBwBaSZwts+4CAFCXL3clngcAI787g0fXBgBJ19UW2M0GAJg2wckAnAMAaJ1IMY5rBgC14hB+hXMFAHIUqhboOwEA+Eut02QZBAD/s3YgtQYAAC0IzrkWfgsAuD6FVy+ICQDEH9CsntIHABXntVlq5woA9qlhlS7eBwAceJWd4c8AADxFHGLMEgMAfAfa5qxFAQC46ZzvK5EAAHa8QzR+1QQAy16ltvTUAADOO3O7sOsHAEkFIAVqugcAaSDi5O32BAACpvEKqbIGAArYslsk8wsA/G7zIPflCABswGDPzLkLACV58yPjhAgAwXaCLIFlBACXHuaa/PQDACQt+usHvAMAoNRctUS3AwDzIVeyUyUHANMSnU6P/QUA2WIQKrK+AwCoyYI7BqcGAO2XwV2jpQAA7z2lBgzIAwAWy7HCMlsAAIKB1XospAwA/p55fmbIBQChUMh0Xi4IAJmGTmHb8AMAMGeFpHEXCwD9qE3SzF4AABh58P27gAUAajyHhjXnBwA++Xff7UwHAHG0N2pVtQMAgtRN4STFAABWxpZ0RYMCAEXNts9rrQAAFCSw6NF1AwAzpyedB/wEAA3FhgxEiwwAhTvKnJI5CQAu30zk8vgIALGmexEyhA4AO64rDBdBAgB/L7+JsDgBADnqNP1boAQA9V6STJEDAgA8TuD/f0kHAJiv7HxWJAEAtHPECoarAQD/p4Z8IsAFAHdEwr8SGwcAdTCoc6UGAABwyGYpYfgDAACNBDb6/AgAgrO7M3FuBgB2VqSoQksGAM+Fmk9u6gwAoHjo7ldvCgDeDSp4yQwCALOqcDBOXQYANndUMY68BwCYLUOxv54AADaXZ3eqBAUAse+HVtUsAwCVYS9ej0QEAEUDRp2RaAUAJxqt4MI0AACj29lDGQQEAMqqbKJDdwEAZMn5VpGMBADQmh6NJ+8HAAG9p47lDAgADIApFJMtCQCWzOtDuu4AAHj4lVPdhAMActI1GjPfAQAO90r97AcCAENolx0KQgEAT1k305l3BgAYYI9URxYAAEXxeFXOfwUAcSoUDCIJAACaNRQj+bQBALFmmKQwMAcAeSYL6StECgDOfZTY03sHACggVcFV+wkAoflWHRn/BQBRCRWJnRAEAMtHLS29JQIA6jvngMB8BQDLH3J1ENcGADLxp3K1OQIAaJAtrDPUBgAzcKQw+SsHAK0OovSsTwYAKkC5ovdlAwDzWKcmxSAAAHbMQvBZ7wkAJd12ScKxAwByYrFcZh0LAFbFcORWhgoAK2Cl4M9SDAC829ie+DQAAPOOjZSPOwcAq8oj08GGBwBRbiap1DsEABNTYcSsKgAA33d4ZKD3AADU8JMPzOEEAJAR7yZH7AcA+BL1i9W9AwC4BLPXt88EABLviZfCmQYAULwh4+o7BgA1u61AwyULAPUr5KHhYgUA0zTEy9SxBQD+dZu4bD0EAFYOkFuNMwMAUxpTfTKNAwCfG9VhXLIBAHWQsyJGSwEAJp8KzBUmAwDftpy5EXcFADg86RScpgUAmcWkgInoBgCShSVxj/kCAO6mVE9ErgoAwcX7ejkVBgD7+PODdw0OALmGxF9nqgoAE3aeLgbYCQBWng+1TKcEAJIBZMLRMQUA0n9snT3AAADBEGYVzXwFAGqAnSSupgMAWnyQqYXaAgCvTOwhN7IGAKI6aKTT0gQA7/0Oh8b5BwAl74rOuJgCAN5lIQrqcgoAbtA+73mBBgAerP7AueIMALpjGwsp7gsAfDqAcWK6BgCyDPfvU3kCAFLFDq4iTwUAJCcuqT2fAgAYvSIMykICAM7VBISKSwMANTNpg7XsBgBNuN+/duwDAE+gVs+VyAIAUk3VSVE1BgDhZdS9Yh0HAPVe97HatQUApbm+DNbiCQBW/l0XwicFAB/1jyuKng0AsWISYjPDAQCA33jTKMwDAKaMlvRBIQcADW3ba2kHBAD7/C+ycdIFAHIxfzFfTQcAgcrZZ1TlBwAN9YYxZaUGAPEt5uyIsQYAcUmENm3GBACdflTEvK4EAP21VHOejQAAaMFtC3VrAgDJrAEeiGIBAKUBHfNtlgcAHZrcnb1zCQDJAW0nGwcAAF4CjpHYsAAA6+Kep+5bBwC4TQmEKckDANujlb+P2AUA33JY/h4PAABqJRgjh9oFAGBZY4HrnAUAZMeTdvOMAQDqGTvRHG4AAFMDW55irwsA5OiIoPEECgAtqO6c/A4JAEqjLzyGiQ0ANtiooabzBwAjbxZvUa0AABrIV231YwIAyjhGOCI0AQBQCq/xHzMBABZuUgMGCAMAC4A9XTlEBgD83r49ILkCAFWjVuaMsQQALBi8ZjQ/AAAT5dLeDw0DAD1HuGgelwwAlfN5l8wsBQDIVYKuBOkLADiT80au7AQAWBw1hFBhDACzMxLyGk0BAAucs4kZ3gEAnm9v3GkmBQDHP4yyNDQEAJnAAkIhqQAALqC5rsAZAACS15VpwKIBAEQcV7HLZAYAsoD6Ngf/BgClXInSoLwDAL8BzJ62jggAjPMtkci0DQAN8sKLf+oFAK+vyhblIAkAJ984QIvqBACkYl08vDEAAB4ITA/+2QcALPJnFNU+BAAJ0R4MzOYBAPHo2u0dYwUAAtLK8QpGBQBdZdCdkbQAAEzBGH1pxAcApKK7kMgxAgDKQgWT4EwCAIUL8/1VoQcA+YfU5cbGCQBZ3EsT4UsKADFvMnBZQAkA8yRzipJJBQAGwQb99ZAAAP1DHgKxqwYAoBHX+rwyAgA3fwQ8waUDAG2gKDxOHQQALhruY6cyBgBNXr3/S/oGAJJHuqY1/QUA6J3pHV61BwDPDexttpEEAKFk2tCOSggAvW4JRfzsDQCxiLST7u0NAI68URrBswUAGHALi2vPBACnMurHPbEFAB4Tc9vCjwEA41ePH2XjBwBlqV8FVlYCAO6FDI0zjwAAvXMamSGoAwBwWI9B5jsAAPCerI7B3QEAwo2ZnuBMBQB4sC6o1DAFAIu/mmxFcwkArA0QFSCJBwDL/pVA4T4DAGQJetaVrQYA+8sAfj7bCAAlSPnhMDYEAAlAa2qV0QQA4LX4Lf4TAgDmkRGk41wAAHcB8VOnXgYAY2MJ4j78BgCsZ225NuwHALFYB2rsEAUACSEC34ftAAAaHpLBTioAAEx5z/FiYQgAuF7+yt0kCwAXMkbg1RgIAI1CkpCL5wcAZ8DetRJtCwCiuCQ7miUGAJwLF/S1iAEA613h3sCBBgBFdPNl5t8EAIAnEcVD0QMAV0UVeZEnBQBNQkEHj58DAD2SV7NuXgQAb3TbXpssBACCuoV4Ue8CAFEvWzD7vwYA3RLXshKxBQDi5E+XdFcDAKPjlnr4SggAn7MLKWh5BQDcrliMTpcHAMaINAh+dQcAi7znKsYBBgB0q+zCcFMEADoUq4+38QIAAeEgCkO4AgDj/ogdnqQBAJZNzke7iwMAN9SEuufwAQCqwl3jQ9wHABiXPidcKggATouy38krCwAZ29X49I0EAI8CbJeHTAUAUC3YgftEAADD2X2IZWYGALKwagp2KQYAbD4kx+aBBAB3/EZw45cAAMxYZwFy7wcA2eMHqcUYBwA7OGuMybkDANzMXiXtBgAAWZoiOGWXBgANw/kjmPcHALqH9WjwHwQAU80bGQrACQAkniCcb7UHAL6qzF8eeAsAbMAxBJtKBgDoE7WjOdIEAGYQG/UjlwIAw9kEz/RCBgB6m6BaCdoEAE14PTfgpAAAGSl9W6HWAwDWpUZQpxoEANrTwh51kQYAxCFnqzg2AgCD4azQp3EAADFE4SBSNQQAgTkoKjbhAABUljXYfHUKAI8NsXrN6QoAdBd2z5vGBwALuofIqi0HAGDaXaz0twAApJgELNq9AwBgARiqZ04HAKduFMe8wwIAXynoBOvXAAD+oG8e6qUEAGBsQ1xjXgQAi9HUqPSOAgDKKjKnqfUGAKtE2aPr1AkA5NzzFQ8QCAAkeDYOcBoGACM9q5IikgUA0+gOaLkqCADFxkEvDAABAHRxc9+fIQAA530Sf3IUAwAeuCN9J+UHAHoULhrilAQAmg3l3YWKBAD0PUk098EBAIlohmTbewQA7I6PBH2aBQBrpL5s17UGACIleB4XQQEAH3zaJm2ABgC5mscbHfMDAGhRn0UgnwgA0j3AabhvAQCU2QzsbFUHAApRtwOa6wUAccuR3dEKBQBHirSAV6oBAHdSaD8zrgAAYgm2M5cZBgARZSZ8FZsGAMrxk/hARwYAhPb7CKQ6AAAN97g4HvgDABHIF181fwsAWoE0U+h6CACO5NLdq+MHAOVFH77qHgYA7c00LT6tCAD+r9l+zA8BAPJv6bCMJAQA4nJRERwxBAAlab8c1MkEAFBPEPwQBQUAnSRuM8UPBADhLfs5ZjgDAHh70XH4uwcABIB+a3lfBwChD79YwScBAHS5Ua7EjwoA09vSv4luCgDOZXagIuEMAMIFNCCxygcAfRadR4LtBACieZguQnwBAMP+yEZZigIAdyuRLrM6BQCl4J+gTbQHAPR+0IfvVAMAddnFYCK1AwDcHxc2aJ0HALvUQPGU2QcAVBhWBMS2AQCSUyAt2QIDAGTx4OS2bwQAt2VSrZc0BQD8hhOg2+sJADtqswwvMAgAbELr9cXtCAA9KKS8osEDAAIvu8cwNAIAwou1G+qjAQBhXN5jVyYHAMrxdjtdDgEAZ47aU9a/AwCKKsg+lYQFAHtwp48oXgUAgR2Tw185BQDLYRPFRlsEANHjf4rdTQ0A0hnGQczOCgCQTaxiZToMANi9p6yl7wwAISHzrsDBDQChf08xvyoAACgVip7RkQMAx1+JE/qiBgCRperdjp0AALfcNvp7FwIAj9t5+rwbAADhZjbrS9gDAAQigR2SDAIAzjI7PYTdAgCr2IeTYa4EAIP7W5hEfgkAIcwmxjJODQAXgfMvQZYIAGkkGtZBsg4AQrrlq4VWBwAuo0RTqvYDALsRD2iDlgYAqiP2gTVMAACly3VYrwEHAPN7sZENoAEAsvJh6zMJBgDSTSrpPxkFAD70UKWV2QMAPYg6uW9VAwAOO2KbUjUBAOuDLuK8FgcAuD64MAE9AwCsr9C6KpUIAIkb0072CQMACllRoC6XDQAY1dGt19sAAB4j4iP4GQEA4n1ebtZRBAA4+HCZwwAFAKNcpoFbmwcAEXiP3CCsBAD6AfWpiZUCAEpratIQ2AQAWbKWDeDtBQDzBVnJ6fcEAOuZUjU9RAgAOO5afX2bCwDrNC+aUZIGAHjPJElA5A4ASRRK7C6UCQAuMIFXvEsHAEzsgbs1MQcAPEhhG2fvBwAp18wURiYHADjmkq2TGQMAkkkjrhlTBAC1T9JHnSECAPZssIhE8AQAEkpynqo6BQCc7xRTpqACACd5HDzNGg4A5XmHt0aLBQDyer6smjYLANN0MHSwCQUAod62OdxVCADCJ/n3f5MHALalxhT6wgAAfNBt271WBQAI0XnBrPYGAMJHhiFuzwQAtluNwnwiAQAjdvW/6Y4HADqJHySyjAIAcmc8HlRbAgCiCnEHoyEBAMmDdMc+cQkAyvrVcgX3BgCB/yJO814KAIcRFE+UTQ0A0s6mlLsnBQCXSgOfXl0DAJu8hZcGJgEA8E+Fx05HBQDKSKMCo5YCAA6kx3b8MwMALkhbmSqZBQDHKgAHx40HAEEX0JRjkwUAF+8aKKT7BAB6CrJpkLgGAGTbx7WM+goAD6gqmOYYDwAaGhr4lZ4LAPpsZPOU5wUAOXaKMD1HCAANInBiQaACACXQaYskXwcAJ2plFrzLAQAoZ+LW/7kFAD6nOhDCOwIABZ5YAyZ5BgBdWZKY20gCAAgtrTylBgAAc7r3UAENAgBD4P079wIBAJocUbXg2gwAVdTg/38lBQCAIevRCEENAPmumw/MlggA6aRdcr32AwDGRVd/q7kAAGMd0vjwygUAK+oIpL7eBwAWbYmT254AAMClXtKXZQMArFhgEHuNBQBp7gvS+M0DAF4BZbdMCgAAyXx8MzJoAwANpp3B7LcHAIj6fKdRSgYAtQ3KcPScCgDYmAhuC7YEAMfm/90EXQUAXL9hxu07CAANaVxpPDcCABjPDVLIwAQAuZR0S6+EAwAlIqKOSqsEAEMXYNdaIwQA9XWJBw3LAABLDFM+MZICAAmlJJG7jQMA8RFaZdBQAwAG3wwrzucAAOZwS9nf/gYA1L9Flz84CgAAw8Qnrr4EAD8/akGkWgcAzq44YSUVDgCjhYzEOmQEAJK4NSeMhwYAd9j0IzWlAwCd7ovtBKUDAEb72KXgZgYADctwSE72AwBXZW2xSBUGAPOWNXdhogcAOl0nX01yBwBNUQ2BvPAHAI0TcnOtnQwAdBDT5d5FBwDi239epbEHAKFuF4+YugUAWuzdB6nTCQBvE/QmpGsAACC3Bgb8ygMA2pw1ovAYBQCn7G/k5foFAO2Oz9v40QAA3IHQPjGTBgBCF5Bmo7AFAH7KpCyHDAQAAZ4AlIDxBgC/MUq0EQAAAFynCmppHwYAykKtVwqLCwDI/Qa3muUJAMy/btQIEwgAUCgtipg9BgAMbMY/bKAHAPtHusG6yQEAjgN1xTU5AgATnMVxvfADADXoFtlIrAMALiO9r1MHAgACYNAeux8HADqvpEeunAMAwtk0C3wzAACKNrJSrT8DAOjPIsTQyAQApXFZJ7RgBwA9rRy8ldoLAHVzW/9R8QgAppDLXDXMAwAWHuTFxkkGAICq5u5nBgYAkOErGJ0XBAB5aX5W2VMGAG0lmkIPbAEAMZE+kEOUBgA23fnGSm8BAFOS4hJJ6gIAXdJoPmS0AgDnuib06jEGAOgNcKO5dQEA+0iqAF98BwAXA8qFd5ELAJiTx7KpWggA92X2x/IxBACf/mbaEAQBAH3WtNyCTQIALXUXDv7mAwCPsMse3toEAJHqsUiWWQUAGXuPhURjAgDAWilKPfQFANSsUlynQgIAEA0igESTBQBTEvkVR7AHAMa65sSAwgYAbnZhs6OtCwBOO1wS5S8EACKsSk3YEQkA3XylzwqNBABDrvasKL0FAH2QVo+rbwEA8tUYErGsBwDbtCMg4B8EAGUvXL83mwUAcearfeQmBwDB9kbnRewCAIZGx1MOWAYAdD9nBKHtBQDTNhMZNGIBAECG8x/WnAkAqBu0xMZgCABuNqcM91wHAB4BbPGoGAEAuQOiB1eiBAD2fyb23pkEADx3CIGFbgcAKcvdxcqTBgD0nwrQEQMAAAVdzf79zQIAau32U4pmBwBWJRQuugMDAAkJwYQFiAMAHSYKACD+BADkSNKWGHIFADva0KGRUA0ACgXBx7/2BAC+qS7NTk4OAG++i/KxfggAAkv8WpM8CACuGxj9F1UGAG2Bdix35QMAiolAlhgZAACZdN6EKu0BAMFjT9fteAUAPQwrScZ2AgAuk79A/JsAAAszH/HoiAUAbsJNaW7RAwCMKJC1KuwDALjRMq4JOgEA5LRauB7oCwAerjykrHoIAHNjUtcFLwYAuq3GZr/hCAC5e9jke9IAADS0XSMnbAUANy2mDm4uBwA56G7QTGcFAPwAoiVc3QIAfogseenVAwBVvKtNchkDAAAIaHh8uQIA3eY03d+vBwCIrjWLVDAHADTj1qFLCQMACzDjpybhBgDF+/yuwIkIAIJlgx+h7goAg4d9J6KFBQDuuKjLo1EFAIbY4itCtgMAvImWQeEwBgBVqacHO2UEANsRtEM0BAMAYonUM4JfAgAx9K8Ej70GABJjmv0H+QQAm9I3x9MPBAD5DpV4YmUHAIrPhuqjcwgALZz7q+LgBgDuM+o4Kg4GABj+8ykkCwsAPmFLSL+LCgDAyB/VWc8DABhH3tagoAcAS7dvPjpcBQDVT4hfE1MDAIQbjAoW9AMAfGwTb1wvAQBM3jei2/4AAESrv868eQcACWlNP6muAwCPGFiznOcBAG6B4PXYUwkA/C7buzOFCAAwlBKWlxQJAEKGFjZuegkAHp3TUqt4DADx4/fuwzYEACYAH8LT/wcAqS0K8nvnAwDecoT8vxgEALOjs1F5XQYAWdFSktOkBgDU7ABZ45AHAIZ3l78lBwMAU6A1FlwKAQASohGkh20BAHAFTtXi1QQAdF8/s9flAgC/fog/3qULALY5Yb0k7wYApqV3tZD5CQAVYgZCWn4FAHc2mESLoQEAj28e3lLmAwDr2C7gK1MGADhfFsiHjwIA1vfoG61OBABm9DFPnXUFAEN59EmBNwAAKU8r4zufBgDWNBX+glgEAORvPJQpmQQAFVtUcnA0DADE59fOayILAN6J7UwTOggAXkDOQ/jcBwDWg3l1XTQBAM3MNEL1IgIAtNuKPUp4AQDMK4zuvm4DAG9ij1v+iAYAwDJHSkjWAACSLVPGSrkHAA+FVIcbdwUAyGEU39mNBABxMueHlnMGAMAaDMidzAUAzdSGFGeDBgBzgV4aX28HAErf+fXT1Q4A5tdojwvaBwCmdVY4FCAAAO8dPbVfFQYAfJKJLqN+AwAuqPVoplkAANzUoasVYQQAdtq1w1MZBwCBetMzImQGAL2xdoBlyQIA/xAw5oGlBQB0NuiH+KUFALlDpqDTKAYA0pMMZNgcCAArD9fKsLcIAL1EgalNhgsAG10trjc+BAARPaFwzwEDAOyRGLqhpgIA4Do/+5HyAgBS6kuBexoCANFEbmWbZgMAM+Gm7QY/BgAPB1gnNDMCAHXAnEXgmAAAG3xsrV7fBABe/dRsHqIGANCymWYSKQkA5z1gohHuCAAgTMf1wgoGAAhoGSoZmwUA6AFwsHFTDABf5kYwChcGADiepEYaQAUAqMRhVd0KAgBGnt7ttKsHAF8ZGp+/hgUAC3n4Xo0IAwDbtPwmIYwDAMPjSeG6hQYAMOmkAda8AABSDnkD++oAAB2udQ9egAgAJwqGWcxkDADuC7C35UgKAHSP73WW2QUANVRMNONKBAAvBEg3wVUFAMAyQnVB0AQAB2mGMLQhBQA5nPtAjjADACygdcasCQMA7kOlu7mJAgCeUyguWasDADrYzauCTQYAJ+NywY7HAwBG+bchUi0GACl69zom1AUAsK6JIt0/CgDruX73ZNwHACxAOIPSGwgAITk4pSlPCQBtk9AYnCkEAEmKQYNBkQUA1a4hxxgqBQBtl4K6UbECAFTHS97vwAUA9deyJdx+AQDuGwimNnMDAMPlh4gxtQcA4VsaSW2fBADgvsdlI+cFAD6zCC8GOQsAsc9X5vO7BABnWW7193oOAI7Wnn/W2wwAM7dcVSALBwB/IXFFB/wDAOtqK5vSoAMAneXdzHhkAAD63RsFTV4FAE57xAQRfwcATCwRVcUTAQDKt/kDUVMHAAghmh3tQAEAr8I7MyIlAABkoPSYQ+MAACgZSz4JCwMAEgPIfn7OCQCDj/e9deUMADjtCxl6Hw4AeKNs7a34BgDovc4+2SIFAM/24EXwJAAAoc8mNLZtAQDYD9MfOrkBAGKjaFNA5QUAmrK3/T0SAABoPFJWQzQEAF/uIXlSmgcAfoE+y/xLBwA9jexy3oAHAHIn9ADz6gcA40w1iFFFDQCryz1KytwEAMvrv9AU0wsAVyvTavzeAQC855oIRYUCAFzBoOmP4wEAezfi4EYgAQCFqApWHHIGACgZZ78o6wAAp5VR7xq+AwDrtb1iL/IGAEkwUrholwMAvf37yJQzBADSjb8B0mcEAJbnela99AYAg7cXk8haBgAyif0gO30IABVpMgjyAAgAg6NbWpzvCgCtT+90mpEGAL9SFGHUngUA7wnqBOyRBgCE6QAny8sDADy69cRDHAcAzXSe+vZtBQDfVs/klZwHAOIJxjtkvgcAeOjZKsFJAQBfDDnKWKcFAIHcYR2LkQgAm9EMJlDTCADYtDdOq6IHANcUVHPqHwIAnWN/AjinCACVJEbZECcHAFZ0AKqvWgIAG6PqKB/SAgDQXwDqcXYBALc+SySu2wIAzOH/Vy9KBwABcwhzMLwBADScAfRX7AcAJKUfLghOAwBqEjWmjGkCAA7ZPV4vcAUAx8VwSpocAwAk/HiqpTYJAAB7nzsvmQkAoq/EsATAAwB4urAyiDEFAOx88Z9L8gYAx2DgMH+kAADQyA1UhIMFAK6cxNxD+wEAK7j0BqxGAQBVc57YALUEABKKchweNQMA4y+TaZ8LAQD90RzQP7QGAPMOdj5YQg8AtxYyV8E9BwBKcdf9SK4EAAPhE4pf+AQADf/WsiA0BwBExZdGS10HAPT49//hGwEA4fdXaOEZAQDV9Vw0FIoDAC+1BXGNpgUABh6Fnsv2BADllRhHxHgCAORkPc7N7wcATEtcRW1PBgBLo/4yVtsDAMIlmIKxkAkAyCUyUdPnCACtq7fjK8EJAKWcHnh3hwUA8l1J6peRDQDY2V33K+4GAI2+NOssxwYAx140zMl5BgCkmGj5jYkHAHWd9K0hQwAArlrl5BlgAQCcIF3yxU8HAA3tnZNqVgQAt+AW52NgBgBwTR/cr14EANqxzM8kRgYAwbZygKtXCgAJb2clBxIIAO2OTtAYoAwAbNWl7jz3CwAr10WAhQEEADAtyuDlWQQA6oswGbeIBAC1MhsNSm8FAC02gLzupQUAxo1OCtG/BwD0Nmc2mcgHAAFc+eq7XgUAij+QYLBtBAAhZhKJWGACAC/ldsY8jgkAj6mV2XlgCgCxCHkhfEoIAFll5gN23AEARCQLod/eCAAE/2CDpgQHAD6L3jzMzgMA/2QPR9UcAgCJOZWNwasGABXm5MLQSgUAKlIruNVnAwDHfT249NMAAI3F20x/BgMAN3lp2lIEAgCpd6oryy4GAHQotq82KAcAQLKUIDyvAAB6NX8phcIIAOLWgFYtzAcAY1YH1RMZBgA9KxVhUnkFAL08+rrboQcA1YglxTGtBQBcaGRBOl8EAG2WmpGf5QIA2jEyGjYtBgC4AU4AhFIGAGAd6TtTVgYAn6gAbAGuBgAFHBMqvN0DABS7lieiVwoAdD5E+2DzBgDq6iBy5IAGABgM8aXy/AoAH4ONs3/uBQBLxV7O+Q8EAFuzYeKFcQUAqXAOVFTiAwD44wNAgbUBAEvASjFoiQcAjmpEQcv9BQBxKv8maSgFAPazluIx8gAAk0bIV6OEBgCgvMkzBh0GAN9z/Pi8KAsAs5X/Bt60CwCkEbonpAoLAJtt2r8x7gUAZ4DfwjqyBQBmJdv/NUkEAG5sF20BLwEArvUWD7D7BAAqQJmNt/oDAO16hP1l6QYAe1KA7lO5AgBas7HNW18FAGY8oj8LOgQACoKLOAduBwBd2Z27m5sHAGFzn46ufQkAMtoCYfcZBwCLyoAqfBENADUJXbZmGgwAyqxgFIG6CQDCJjFqQFUDAHZ9chgZDQUADo5JC+rlBgDyFDIGtqMAANKfjBVfBgUAVJlCDPtpAQAQ7uzZ7ZoFAAIYhesWmQMAOMVcVRd5BQBPiuU5H5gDAMtv5m2l3wUACFkHCYgFCACTSoXL2NMGAOOxcOn0sgUAwcvtUkQPCwCTCiNZdYoDAB+ji94cLAUAPVp01PKkAgCKotRCnX4AAM1acIPAjQMAQJd1xYInBQCtkNmXMz8FABVN6Mc5qQMA4Dl+IsQ0AgDyk6Wh2TIGAJSEDO0R/QkA4Fcn7bMhCADFwY/lHT4HAKsWRsgQ0QUAZK8o36elCwCmywe4FWsDANf+Gp6K9wMAH49gLJylAAC3gcuO3SsFANR+hEhPsgAAx+obUb7UAgCbW57ZpL0GAAFOkZZpfgEAgM9/zvCxBwCBVEd0z08DAIWqz3irHQMAt1RebiHjBACJtnM5gkkKAISI5IRJWAoANvtCMJoRCADKZ5d4TOAHADK4zygbZwEAN8Xhon7lBwBBQUTvqvsBAKbfZMG90wMAfRfC6JzYAgD0LBi6Es0GAJd2msGKCgIA2XLMsvo5BQAg3h6PCGwFAO+O8ySsXwsAAquXYVzXBwCnL6TCSz4LAESBtBDNxwkAjzVI6rc4CAAXbqgQET0FAG1GX7ZuQQYAIM5fI6YcBAASu5mK/MMFAAiRucZ0lgAA+G8xmSH4BgDp86nxVF0AAEonvdDFvAMArdXSuISyBQCeliUQ4+UGAA9iBmMO+wQAYOZHl/UwCQAZ1OyPhkEIAMU7koxeEAMAOBg91IoFCwD7k+WH9WIEAC02zqdL2QMAt2cmtfkwAwAK8OBIWtQFAI2aeBRRjwAA0GN25f0PBABHBsLURRQHAHwPF2g+ZQIA1l7F495MBgA9/k76SWUCAG5mP69JhQYAaLvUQSmeAAA8/10fMegCANL7H/meQg4A4iwT/g2hAwDW+WseRloFAIMusPTujgcAzxaMZE/TAQAyUboq6n8AAB5Axh1ukgEAoM4X6opOBwAPvD/4Q8cAAFVUv8QDywcAmH6RqYuKBgDlYdgBHfoBAKuU39EArAwAGie9ASG6AwCvxLmIiVcPAH2f9Im/8ggAn+mO0c4/BwAymFl9lFUAAJAZpCr+RgMAWxl5gEwWAAAnunv7zJkHAFynxjtWcwcAs5wTYwjpAQDWoNkHtPgEAGlPksokjgUAVmTnu0aiBwBkuAG3JvQBAD8loZHINQYAL96O0+tqAgAFrt36yG0GAIY3oEF9HAoAffqzsWu3CAABHJFBTCYBAPm9hEX0AgcA3o7GH1E8BAD5Ne06LEgAABvTcVKv4QQAm5OSf/nBAAAXwW2ViHoBAMed+V4A7gYAzDGycpGqBAAqd+th3bYHAMfSAav5qwgA5QpjhwKIAwDb7VsEyi4LAM8yXzZDfw0A9b9Ztqk/BQCSPfNQ6MEFAPX2uZoR7AEA6WPmbW/xBwDG3hbL1qcHANLx6rzpAwcAVVSIlOnIBACCrZzatcwEAHXpEMZrWQMAXp/bDQyoBwBhTFw+2ZgDAPLj59JgfAcAcDh2URAGBACq0uzgxHsGALlzEx+UuwIAMCwAycmZBgDzSOIzZ9EDAInjS+G34gAASnj22g0sBABQeMYf6okFAJHx3bUJOwUAzPFGWSOnBgBgvi+7nLkGAGJcSNal0wYAwCPpZpSDBADd/MYwrxwFALRUrBia+QoAbu5hlqOYCwDizUAeM4QDAKYZ3sQVzQQAjp8YnOIqCQAK4HR2QqcDAMF0fk8vFAYAFTqMMZPMBADnHiusG9UGAD84kqJKUAUAzwENH8vABgAz1fWeRocBAL9HN4g4cQIA6JA65Sr1AgC6jpX+FP0FAI7Lk79e/goAh+fLitomAgChfvuigwgBAETPQnhwlAgAXHJg+XPdBwAsq0Uo3y0EALt2Mv1PIQYARlIaGI0LAAAg63nVpmgCAEeG5Sb/kwAAKZgFaP4kBQAhtnzkdVsGABnM1aWwXgEAWp2SswlSAABHa8jLm/UCAO7CkbZg1QkAB87j/Lr1BwBsgBQWVs0MAIexcGGLWAwAgRDQ41WqCgBfExeZQn0EAHDweqDP6gMARG60RqveAQDfbKQ7P6UHABrl4kKLRQUAT0QHDOaSAQCqHaJDiK4FADgVC5Eh1wYAfkGmlRoyAwBop6gEkD4BAGyHOxnJAAYAZXcNihscCgChjrN/knkLABrg23l2DQcA6Y2JQGD0DQDbzi+DRYgFAHNuDH/NNQEAW+Po3/s/BQBb5QZeGS8CAM5Lgeg3OQcAjfR7KRZxAwAglwYNnloEAOxEpxr3WgIAo6uKy/AaBABeHYlOis8CAKJr0Bd+SAUAlmUtAyqHCwDfSJPAKF4GAMJAzrJrewoAaR2J8vemBwBnDxEHh/0DALItqRaHbwIAJzB1G6rNAQBhJrVYvgQFAFKC5dabBAIASe+aao39AQChbyG3Z8sHAIK5w1P/egYAKJbaEKYOAgBZVPytGgEGAH34ywLI0AYAe0xV7b9BCQBiQu9nttsGANx+hSYxjwUAQJN3i+GcDgA8+JXPbZIHAOwrDhIlLgQAFfrxbek9BgDM+fNQa/AEAC+2sMFc/AYAy3mYsihVBwA9WhLSj5oHALhqdEuNfAIADCECP4n4AAAQV66zllUBAMokUX4WMQcAP+G76Dh7CQBVkC+UW9ULAD6RvpUUnAgAbPsaJE6qAwCieZE/0jkHAMToudv6MgYASAz+K1LIBwCpWu+DCe0GAPS1h3Yj0gAA9QUzKr84AQCYZdgkXfQBAP5gIa1LJwUAKtFYHQS2AQB6aOSmyi8DAN/MhydzpAcAQAZ/fEIeCQBjjF84WTYIAPprdtnq9AUAACZsM/ZGBwD1mn3FjW4FAHhPvhe+swUASy/4jJK/AwARbwpgVS4FANbr75x+YgQAHJdsq0XzAgDp52NuKFMGAK0jirdhEAUAAUW1rJlJAQBm7QdwkbQHAMqiU90oGwwAheqHX+h7AwBBXqjS40sHAKZsyfqHvgkAzAj+IDbQCQBksISrXPsFALCFgnc+UQIAQ+AlMThXBAA9Im61o70GAE+Ebze6IgEAVOW0os0yAgBA+A+jK0IAAPVDe2bnUQcAPl/aVRcmBgCOtlK/cCwAAOFyjUW/Mg0Am7WW55YPDACinW+d9y4CAHfKvmerAQUAQ+s/fmmwBgC7LwtdS+wHAFBUWRDpAAIAXnEFcQVCBwBgD1MicPACAO8JpPA0YwIAwKNi30rwAADZtou07eAFAAPA+6RKwwcAJKxcTk7XBwCyQTT0N8wBAKauzsnxVgYA7FqtrBwDBwBXbHHQjDABAEIZlHMTHAwAlfFy90ajCwBPMsdcWlYHABFKJNWgHAAAE4dBZ7AWAQCu7VWMfaUAAAM4EJyAxgYAyGra4hJRBQBauj0KPTYGAAz0povJGQMAx26jA0voAgB87/a5EVkAANzqLlHzrAkAaCppOZhjCgAGBYM0omkGANQDBgySiwYAsmQcne9VDQC7Dt/1g5kDACaYlYkl6gEA1s0Dh2POBgAFhYl4FjEGAHCims/OswYACL1zO7pwBwDUhuH3dRQBALwrickbJQAAWsz/m6tOAgAXOBPe9HUGAAqz2jvZ9gcAJdS/pazzAQBglxwcUvoCAM35J86AIQYA0yyIC0UPDgD8ghdrA1IEAMWBdrCVLQAAsgWS+RyQBQC07F5uaJACAEwWcN+ZPQEAysDlIcNeAwApQPQ34zoBAKctP4GOAAQAOgyOLydABgDaXuXpbcABAKppbf9AKwUA+n83CYgbCwArTNFcYjYFANEXLiWvFgUAK9Pn+JaABwDixD6j1noHACHTEdzFFwcA5COYVRShBACx4qFQzgYDANvC/qE4zwQA51z6DWWqAgAVlPGoFkkFAHgS52/JDQAAuD7mhCdfBQCRYKLTynMDAJq73Yn7qAYAN37Z1TWMBwCyLO90Nm4GAI/dU6xHQwMAKhGl7UcVCgB89cmCTWMEAFLWpmiSJAQA9y9/aG0zBgCg2SZOT/4EAEFUlD0PBAAA04ZZ/TnpBQDfmwFHISoBALKc0OdmxAQA3QPSlVv6BgBUojSjUDUGADZ7VHJFWAIAdxMcgVhcBwAbF8w3xtMMAOI0fXQwPQMA16f6upKaCwA3z2m17dYHAKAs3KWUAQYAphBedFmvBQB1SAA+9agHAHivfSym7gMATieT5hPHBACks256G+0GABWOfWnOKgYAdbAqKbhmAgCcXGagNoQGAGkQIOgX0wYAyqMsXYGQCACgmRTr8T8IABjjUPBgOQoAEBbJaTY3DQAnPy8g6DUCAIAXti6fTAQAA3AdW5AwBgDR6nTSyPwEAHiraH9uewEAV1IOmqsUAACli39WOZkAAII8Qip7tAQALcR65deIBgCHj2daS8sBANQHoKJiqgwAbS32OA4eBgCCR8yPiC8IAP8b8oMrVgcA9i7Y0g/cCgBs/Eo5a8AEAMw29ksbkwQAeCMy0GArBwAli4HGJ1ECAEPnjae8MAMATnQZEYT/BgAFk+ToYMUCAHql5e9PJQcA36dgxeJ6BgDxabPhG8MDAHJCy/mTvAgALBhz2/n4AwDE4brqNbIKABlVKYe/3QIA1eeXEOwcBADuipQITYYEAB72jUM30gUAZ3AfYIWyAgBT1+a6vF0CAC0mNBG2MAMAioBtotcZBgDyvq3Cs8MDAFJ/7J58hwYAbbbh67m+AwCH8pHNRGsCAIMDc2KT8gcANpxFUXn9BwDnSS1RTFAHAF/FO37thwgAJcdJAbHeBwB1dDiPR0gAAD6KZ9mXkwYA83bJVoF8BgBsIolVTesCAArBweYJxwIAeu5mh2qvAgBs2aF5qooAALAvm9WSLwQAB5wAQCx1AQDOYv/paI4AAPnyuArVCQ0A5OV7JKu4CQCF5LLmstkNADgTmkel+gwAcI9zvRPLBACtMMFLClAFAJWGk3qhJwEAbeM0+iYqAAAozB4u0YQFAKPrfvjz8QIASrYV5XWMBADwHgdSaVsHAAZUlkJt1AUAn5+YBmF0BwDiCjw1HpoBAL29ltXNcgkAgxaI3x1zCAAUgU/WJgQJANmjqdhPGgcAaiaQOb02BwDDBfq6YHUEAKMvzKvcGAQAgobPzpFZAwBgjEupcUMCAMMgHLFGFQQAtLM0k1AtAwCqcK4sEGwBAEX0G9UNcgEAIZivL2auBQD6hytaKRIEALPqk+JhUg0Ay2WbdSZkCABHahGuZQIEALzlugQjwAYArZXRuAt2CADp1n71iJsBADmjBBm/zQQALE9OzUkrBADZCRl3LhoHANJSuz4VTgEAioHmzRcaBgAniBA0rT0FALZVXMUyKwMAo0eTXxb5AgCsM7zpS7MGAMDycWVlaQwAPkJvzmGqCACgJxvXQPkLAGnRc53xhQkA3OZie5wbCACywHg6ZC8HAHueT8BF3gMAXPowjdYGBwAkL44+9pYGAC2S8BgsAQIAKZ3IWuVVAwABcewUtOgDAJAMUnywnQMA4e93mx70BgC65IS39YoAAEsszInSFAsATbzx4lA0CgDzki85k80IAHxrlGoMNwkAl/1aHTxCBgAzJR+I3JkEAAbFdmTyTgMAlxR00gfRBACz/W69xEYDAKFjEdd5KwMAarP87dn4BQCQOb/c6OYBAArzijRPlwcAfJzxTnLmBgDiE7zvpYAEAAwizkLkTAkAyxYlp4CJCQB2ZrgN+HIIAG1S2h8zAwcAyJF21DFLCgBxIGIBC+cBAGqh+LVj8QEAF9QaNK9qBQD3MNg1lpgHAHvLAHaiegQAw/gVwO0eBABKhe8njc8HAPmTRljjiQIApwmzV3hKAADaTdGFtUUFAOEhs+PQ5AQAQKzS4x9FBwCNqe549mYGAK3+Z4aFOAgAjEzmwy3SBAAPOtSgXicHAPfM130TgQYAOJq3upznAQBqpolEISoCAKUrM5wv9gAAOV871ollBACWP+x5+eoHAKi5chXo6wQASmlhXX8bAgBxY6MB+sABAD1qk4wOKwgAIM22WDu4BgCAJufT2H4DAGIqn9s3oAgAu9KxGVQADAD/PZQitgQGAFgadPaZyAEA+zLy4hkCBgDL+aeSrl8DAMqx8xQ2+gAA8IK+ub3+AwAAFJKVSOcFAAYngjjqUwUAjMjPJHyhBQAK9K4YovsBAJQBez4EVwYA5+nvVRvBBQD7dKDGe3MHAMxV4xzk6ggAdfc/0TXFBgA+9cj6SJQEAGo16MZ0TwMAotsHBnitAAC2PrZ+OiEHAIaMqqzjkgMArzWKPuk0BQCXyQL9EIsAAAUeuKzCagIAeTvOmIydAACsUE3+F14CAKch8Xb1fwcAK3L8sPnlDADHKA2blG8EACbvF13mzQwAl5b4KKi7BgB29gQe15sAAEWh8kHIWgIAcTiCrH6kAQAaWGzDqKgBAPupQhR1VQIAATn+kGa8AQBavFovExQDACjVMlGDEQYAV4q0jkvyBQC39vcE1VkFAP1m0vbnkQgAiHMD72BgAwCGEh3siIcJAK+ORxxEhwIAvVQzauojAQDVVOuzeIMDAO6Uj6eq1AQATad16AKgBAB8sWcThQsBAOMHWC2xGgAAli3jQZAYBQAxAgkrBlsAAI+352YXyQAA7DihVQ+qAACKkSwelqMEAB4/I/NE1gcAZMACnp/GCQCXaCbl5WoDAHmL09rBjwgAQL3Z6s6KBgCgu+b44DsEADtOYfzfjwYA4Dtbqx3pBADwLyHJ1LEDANuxP85rzQIAEMLX8w7JBAAWh4Gg9ZYEALg5woz4nAcA2/hsMJzLAgCPUFsNdpUFAJAnAv3rywIABRHsKoK4CADLvCbSz9EMAL1xSfqyFQUAFUX1XSzLAgCXY6oE4b8BACVsmf+UFAEAAFg+YlFCBgC+RODFn9QAACnL7UP6CQcAyir9Y4xdAgBh/d8pzcUEAAWvSOvALgMAfLf5kZOPAQCBDM+eAg8HALmwEF6qrwoATCVVg+AdBgCNwuN9WOsIANS7fZ+78AQAvXQqWspOBAAzPu0uswcDAMLoPLCKdAYAvBC4mg18BQCM6SSiZCwEABTDptjVtwAAQ9WVezJIBAC6pOOBZhQAAAxOw60UhwMAMI4pDm/yBADexxJFInICAPx1qUKKuwsA7hdrtNXyBgDlcDEiqbYHAOa34z9xUwgAwWt//TWXAQAuNMVJr5IEAFcDWt9cNgIAYLv/pzghAwD+RkbR96ECAMxEivFdGwEAZkLIQtCQAwB13I8q4+8BADgSrudekgYAMujQgZKvBAD4HRkR+f4AAEtleXBhaXJQdWJsaWNLZXlTZWNyZXRLZXlBcnJheUxlbmd0aEVycm9ybmFtZV9hACwAAAAEAAAABAAAAC0AAABsZW5ndGhfYS4AAAAEAAAABAAAAC8AAABuYW1lX2JsZW5ndGhfYm5hbWVfY2xlbmd0aF9jVmVyaWZ5RXJyb3JCeXRlc0xlbmd0aEVycm9ybmFtZWxlbmd0aFNjYWxhckZvcm1hdEVycm9yUG9pbnREZWNvbXByZXNzaW9uRXJyb3JTaWduYXR1cmVFcnJvcgAwAAAABAAAAAQAAAAxAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYA13E8k/znDABDsrb+Qc8CAHYafQocWAcA8DJNUy0XBwDSh/pjwJAFAKjVtEJgpQEAU9GeFcyJAQAErjyq3rgFANi1EU/wqgIAkpxmWlm7BgBfepuls6gCAH8I71mzqwMArwXbxKj1BAAFQtAHqLkFAFDqE1uvAQcAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAnwn8jrlRAwAOBaekv48GABuXnZVJKgQA/Z5GGuWTAwBYHjIQ6YAGAL8YaAUKBQYAvzJVH8wqBgAl+snMQYECAIPmcfRhTQIAWkTH9DN5AgAJ/3bE6fsDAEJLLphrrwAA5Xi6URKtAACIfO7trhUHAFM19svQ+QcAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAMXEVd+vuBABBB/EVGSABAFacbNqcZgkAbDTbMsBeBADDLGq7Vx4FAKSMfXu2BgAAMynnRPqEAACKb13lThUBAJBzLoRdQgQAF+QaxGSLAwBxS+oCZzIEALUwYDc0aAAAgMP5EgXvAACEJVHyqfEAANbwqZGOCwEAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAfD7dBGZZDwA1iwUOUfwOAAzMso0MZwMALzPOmdiXAgDOGwZ2XpEIANk0kvPtXQcAVDwfqzYcAADa9Vjuj/AAADfWoBOW4QAA4CATSgKpAwAakaLJ2fUBAPj8+pR5EQcAxY3iyqjYAgCHDAmysUoHAMTswsUHaQIAHZwvYw7dBADZpSIm0c4KANlCR2HpjQkA07Xbb6mcBwDuAJrUN90GAF5RqklUYwMAq11H0HjhAwASl6ESRwsFAK30D4bC3AIAMT3w1nYNAwDH5AYhF0QEAIgt7a9REgAAWk/tm/w0BQA0Us85WtgFAGToEnFpDAEA8sdYg6AqBgCU4UgIRG8EACv1qHG3RwQAHdNpMrp3AwCAUPW6+TsIAN5fvn0nxAMAkkzUrzWjBQA+dZlAFsEAACPkbwCHBAcAb9a+ymFeAgAEZljMKOEDAOLHjy6LlgUAz2G91aNJAADm9h5bUBYBAG5YNIbXZgUAvS9axoVCDQAfdPjMYl4FAESQsWG5awwAOCBxBTQVCQA6eTRfuk8JADQIwZyfpAcAxiKKeBO1AgBbOfJuS/8FAL8H9lqO7AIAw+ylvHU5AwDU94VpFkYHAJrnCgA5mQAAevlkeUyEBQA9W/nhFzYBAMU/qM4pSAEApexxTi8LBwA8ZPyOFCgHAHZbmQM+dQgAZmersl+/DQDWNUW8w18IAMKV3ZeEewMA6P+01kkVBgA40bEtohcCAJ6wLgbPuQAAWPflcZz9AgDd3q9SrrMAAJfkGWannQEAjlXSVAb6BgDUQV7SGYIHAFHGdXR2cwMAkGUkFMuVCABnrKYq2AIIAFBIvIPxQgwAQwYKHE9GBgAHCXMFWb8GANmt0UD9mQIA9+UEmt7yBQBZHMy67sAHAAop+LGhzAQAj7HDVur7AQCKW0Hh8XgHAPTB73RY9wYAfwIZQGmKAgBN3GupNysFADWmZ88hJQAA0V4vdyBnBAAi1lnzwDIGAFLioysJsgIAgCYRfCViDgDVfJ89dQEIAJRSnQoL7gcAJ8pM6/uBAwCdYz46H4QHAF9EwzDqdgYAghPnpwD6AwA02z2WLSMBAI0HC+eSVgMAH3p3FMpHAgDQ/OhrVdsGAI4E+uJfKwEAkh5vrSZ8CwDkeyJxCWoEAEybLQ0vcgQAOuBOIEbcAwBseSA86fcGAE3j/JbE+wAAPq59a751BQAJ5s6FFaMEAP8wOQLpNwAAEvuWb7dJBwAFrqauBPYCAOsjk5PcNwYAR40Em639AwD3WgTUsKgAAAIe8BDs/AAARU4kxJ3SAgC+R8Ebe5IGADkIrDSFMAgAQD8DZDaFBACr/maRdxMEAEQe/kmmWAUAiczvrjVGBAC68odIQ/8BAEQtDiKB+QAAUTwYpxqQBADw+BqMVLcBABaBNlOMhAcA6T0452QbAACPfFiw+wkBANEmt4e4GwQAm5FmfFlMCwDDD5m2UKEHAHQikp3rKwUAGoZkce0OBwCpxnDgcagIAL5GQ3REfQAAHahkpbaCAgBrI3X4gO0EAFAMRR2++wYA2/wSjHLrBACJibxLmbUBAGAGTKh7SwcAuK7N8XhWBwAM8dawBjICAF1o8gBz7gMAGHUehEd5CgB+6NqIcywLAOgbl9OtFAQA8Q4vg1AYCACI+yxqfNQHALfWfZ7kVQIAup7VYyGMAwBFWAAqH4YDAMmuy0we4QIAEnkpdhU4AQDg1vCOFNACAPuH540qUgMA0vl0XgXuAgATCDH2OEAGAJ5M01jPSAEAWnXkmn0vBwBK/A9pHnEPABUNWzWigg0As7aF6M/cCADp6tS6/ngKACfwNHn2kgQA1ChVgdDeBwASZhpRYYQFAEQV3lAu6gUA29XroS//AwBmOZOMH2gCADUWkyEFhAMAUoYwSvF0BgCQSKmInL0DAMbpL9BNEAQApWoJ2wZOCQAjsOaJnCEJANqihtSreAoAH5VgkrJACgDJ70haWxYIACpCJBFevwIAVq5WZxRzBgAw6Iea2UoBAP2AsGXK6gEA9foKsGPIAgB2aoSgdKQAADIemO+lmQAA5r9LPK6oAgAsgxSvNFwEAOz/m322kQUAXbUYn3GzCQA204OMMVQHAJeXkbcXfAoAYJsIhLBFCQAAA2f4tIkEAPqbtIAcDQcAJUaRfX7VAwBF5WUhcsADAE/gGTi55QUA96h87ALeAwDvkus6LRACAEY6DNUijAYATomFk6guBACM81W/nl8HAMuWpLtfnwQAG1ecHoxiBQCrIugIsZgFABo2Ka6PXQUAKHup0citCAB0hihsGmoIANTPW4oQmgQAEmZ9jowXBgB1A3FzNPABAJhgSmFJOgcApr/chkpgBQC2ZBd81NEAAFEuajEIHAAARVDJRduzAgAMMI2BT2MBAHTin+iJCQIAG+zqhYsnDADN4ntlWe8IAG+HWGnRLw8ALwsmBbLpCgBYcA+VuTAPAH/MLTr9dwcAMkkS+6mUBQDwFcqAjh8AAGky7DzRFAcAZ8rQ0T5AAABSxU6HNS0DACm58Y0E8wEAI5sXO9cAAwALfaPle+YGAAODMFR0vQUAKnnnFSGTDAC3MLm7uVcEACYyGYtdjwYAVtQej04WBAB/BiOxfbsFAMJMsiiV0QIA8y8wuGasBABRrf3ZyAEHACc3W1yzwQYACjgHgKczAQC+YsrGZ/QBACzBXSojxAIAh7ATwB1VBwDNO7ARDGkAAA6P1abcQAcAPEN4BFeMAgBjpHMoUNgBAJzU3n4eZAcAcfVM1e3sAQCwwlZSP8ACAE7Oz1IH7gAA6fsWgd1gBgDr/w8TZ1EFAFyVhbiCxgEA6mOpX9JhAQB9pFN7dRgHACEvD4vhGQYABOzB5N/7BQCSux7ImNcFAGvZ24tGmQYANRmpauY9DQAam1ka+EUIAJJBIb2o9wsAGTMSpE0dBwCixObE4ZMKAM/+2vRGLwcAo/fe+o+UAgAEvPP9zR4BACXt/o/pwgMABTlHmiElBQDhElGSSxMGAO0GtCuUuwYA4t3ARcRwAACj18Qi2BEEADLwR8QFtgUAOfDn8Mb+CQB8RyxpvM4DAF6pGWqYdwgADot3oarqBgCrxUzvL/EKAIl8xCBZgAUALJf5cUeSAQBAwJ/fvYsDAIGykgAA9wEA64rq3HZKAgBAx8DfsiIFAEjhgDQZ6AcAuUFDoNk/AwC8IIpnY8gDAEOKUbIH5gUAAc+WpRxDDAAEFIB82hUIALQQj2+bPAgAFkCTImk0CABW5Dkx8wEKABgY32yPHQMAFksUS2z4AQCdPte4dZgDALOn/9nw+wIA3cy2ynoGBQBRnQMIa38CAKrfAIAvgAQAJcVioJKWAAAXWAeR6roBAGAkhqjLlwMA53kTyPvDBQACL14lvBsEAFCGmVb3ow4AQXzg1H8pCQAbHiwCtHEHALJZWfCTMAEAGMYuLzW9AQCG6oibeHUAALlI6hcRHQYA5mYHMp0zAgCnLzpRhtkFAA8b4Zk6PwYAbbLWzw6KAgCPjeE1aDsFAHGZIYmhMQMAnHJ1nTovCQDJxFPpAA0JAIkvbxHfAwYAiODgdsI9AwCaZP8ZlqwJAMaAT/tFbwYAov657jjMAwAf23ByZAcBAMgNdOrxEAcA3zu4xmcRAwBoEEtSQjgDAEX+MJ3TfQcA0KBBIUOJAQAlwrhO/ogAAIvwQWNDEgYAJSYtGuNJAwBssaZ/ehMIANt+d5KugQ4AUNz4xb8iAgCQjRejKlIJAI2JTofbQQUAMxuE+4AtBgCX+ifwbj4AAOgzlp48oAcA7+UJI75uBAA4SWFpUy8AAIcFoq3lVgMAAvlrn8gbAQDbyBlkdDYAAENSUA/nXwQAfhSVyCBJCgBdTJRh7AcJAB7AF+BSJwcAeumi3bciCQChV9v2GWYJAIwLDJamdQAASRvkxeHdBgBBo21RPy4EAJ7nqP0DagEAOQ46YtEoBAD9CKMBREoHAAmBVbnUbgAAZ4ig9vFGBwAhI29cb2MEANML1pIV2AEA1cWFe5+2DQDrUFYXLXoJAJ3Bv20+zAQADr5zOB0+BwD4ChvV9qULAF+sDaZWhwYAJuyKe3VdBQC9gF/0PTgDAKaWn4w/eAYAzZ54pzQCAgBSsnhxtg0CANoOLNqjOgcA03AcwEWQBwBZECUVe7MBAP7PUyNozQcA4PSsaGDNBQDMdHr8mgcLALNkC2WXgAUAmU6crKt/BADNsrJTAu8LALb6h9hbpAEAfMFtB0hXBgCoEaoAgLkFAHQJCMnsoQQAwL1jiIyDAgAwUEZKz7ADAC169a64IgAArSXpdwatAgB6RddnQQkEAIJqYIrLHQIAujF3vvoADQBQMxHDU8wHAIENCP5lzwcAoRsBZtnFAwD2xvbbQNgFAMifnYxGBAAAjGt5VIXaBQAlAJVwvrgDAAmmpi2J1QYAMUoZCD28AACL4Z8wDTgGAA3uuCw81wQAtsC6rYK4BgC+TN3dq24DABmsMmInpAMAuH5E23LBCAB+p7cFxfgDABA/f/lXqAYAOuB/VsD8DAAZToKeDHcIAPqEcIosQwIAaKmoPPd7BABnKCZ2kWMBAM4QgE/f6AUA3hbqfBf/AQD9tbVFmtkBAOyZJE9nIwUAEyYYJvr4AACYjASYc48FAAAV1E8mnwMAznsJ/qtKCwAyOiUD/DsMAPK3kf7HmwIAFkqE5GGnCABew3ISYlwOAJzi59sXNAUA9ZRzgnNFBQDdUPam7mUFAEnHjXRQIAQAiYhGcy1xAQDdkzHO+IkDAOV8F7gk1AIAzUA0DfpzAACXntQMAjkBAM4ZqwCYLwIAmf1umt2fCgA/KCiplMYHADpL5O7N9wYAw1yyBzJaBQCMWThNGhcMAMv4nj6KNgIAC6ziCKpUBAAAp48/kpAEAC9YpJ6qcgMAYkfWbEE/AQCMTMmZqlgHAET/ABcA9gUAvQGMSE5pBwDW7kjp/dUAAL10pU8hCAUAwwPQU7sVCgDCqCx5nhcJAKFAyGrpoAEAtjq74pMjCgDKhkyKdacLAEv+1j4VaQIAQJj4riMqBwCcaZlSvlIAABYjE+/lpQMAuvrGDpYvAgB2UK6T9hEBAJDKlKq/4wMAh7h2lHlFBAB5SEYSCUoCAH/e+BX92QUAC1LX7ipNBADkp8LSZQgFAEDqOFJbcAoAljtdsnBsDAC4fqR/GLwLAH9yY23TCAQAYmCm9vj6BQBr3qgtibsCAObix/DUaQcA+/gUWfMyAwAMwobqFQEHAKitJNqIbQEA3ypmIgaYAQCdWhm86wEFAPsG6RzYUAQAP3SuHJbYBAAOun2Mw70GAGO04ae00wcA863i3kuECACqY5YnrcsEAHVSIKahtgMAz23QkSfoAgCHPKnKcj0CAPSqaKu38AUARWO61CXeAgDNH9egJJABABoQXxFlXwEACJcUZ5DpBACvpcvR2BkBAAcg/s771wcAlJDC88VdDACuebUgUkULAIkGHmPBcAgAIJsOY8BrCgCMzW0ZzfkEAAEoayZqHgcAXd/ic66aAACjsRmy2A0EAA3eF0X7RgUAdXvoNVSXBQBoN3tq2JcCADJjTC9agwQAYEFDXzBwAACuVk4B3YMBAKCHQwjdzAcAgMxgZxiEBABhM1NlVkMHAAG4NmNoLwgAMEP2RlQiDQALGUioPFkLABcEJm0sQgYAlLsXSJASAgD1VLjeGaMFAH3aYODUqQcADB3WDr0oBACnmoRemhgDAEKyWR+7rAYADGNTR+/2BwCpLSopRvMBANaijTCYcwIAUyRwCkwOCQAz13ujr9oEAGGJPtxrnwwA5drs3P/+AQDDklSUwnIFABPUXkMojQMAWCiZGU8GBADNQ/W+D2gHADyN1YPdqgEAw+jrellpAgC+MM3WRccHAO9431V3fAIAo3+TM2h3AQBVGEQWUUAFALwFjEmF+QcAUGO/D1IVDgBp2nS/6bkIAGgRIAiD/gwAQt4nYfdzCQCwac1TJg8LABfhC5+IzgEACQdRlGpvAwC0FgBySPIHAJHP4dEeggEAH6NwxC5sBwCFDMGqOMkAAEFxee1kGwQAbV4YwbG+AQAHD2CQVO0BAEeWFT8n8QIAwAunVdeLCAAI5lyIOp4EANZaG4iFZQkAXU/TaHXCAwBf3H6ZwYoDABEe4Ip8/AEA5+hzVU0JAgDSSfW7PMoFAENBxewg+QQAtoWtcuXZBQA7sVGnF7UGAMyAsXDTzwAAGvTRJXk3BQCiCGBWVk4DAJ7+y9n8LQIAjuA7ELRZBADdKi0/S5oFAOuOu8g01wcACUpZvjw5AgDeTIJ3mP4IANkMDcPg0gMAu3FmaJf1AwCZObZ+WKoAABnGkrXH4wAAjEQFbJGyBgA7kboK0TQDANvPgbXNRQAANo86VeDjBQCy/x4EswsFAAD/B/MDwwQA7UTZDVgDBAA/ZZJ9940MAOlJs+OfigMA4a8KhYnqCABpcKtRsRYMAIWMshfWOwIAYVp95y7nBgDeTRf/cqkBAA/Gc2Nj4gMAq7J4jxvWAACwNsHp79cAANUKZIkcqwEAlx/0roJfBQAN7RfzV2kEAH4ndK+ikQEA6A5GT0MrDgD70/rAxpQCAA9Me5NogwYAW4cQKfjJBQBFBeDb5zcKADEUPMVL9wYAwtm7XQ7EAQCXXK6c+8gGANq34VxchAQAzLVQ5ODiBwAwtAFn7XUFACYAon/h0wQAU0KMiPyRBwDBigeZuvECABURm2n6GgcAw1A7Rxw8AgBIHeIdZ+cDAOihR1X6JgMA2a9fwk0ODQCIj8f7MQcIAB22UzmbbwYAucw8KPRVBQDnYBn7Z90HANT+r6EHRwEAHCucLhQhAACAGPhIGMcAAIY8I9jZSwQAMFj+jlfoBgC1QXBtWwQEABV+NPPWxAQAXRmPmPzdBADhZaM+F/YEAIhFrvnaRQ4AOmLbYzfUBwD5iApQ+YsLAMkffcHP7AcAHoOCByjKBADW17F9M7gHAPuVOO9tEQUAR36q2v2TAQBvh+g3PMkCAPqDxSgaQwMAediL2kmQBAAcwXpAqLQEANTw65n7pgYAxiPktrUiCQDV3fHfUB4KAL91TjJ2PQcAjkGVVEiIBQBeLPSp/TYBAOtVCFa7wQYASK0TfhIfBwDsWpAEs8YFAMebiI5rdQMAiTFKkXZfBwDRvQWjsd8EACkfgQX/swMALtk8KGLtBgDhUuxDFV0GAI2+EDUYIgAAbHowQwFxAgCr84u0j9gDAHqPwU7rSQoAXin/XRE2CQAD1B9EfDgJABQtrV44ZgcAXgkGi08ZAABiO4L2eIQAAAhz04mGAQYABrgXznGgBgD4ipeH0cMDALp2gsjhrwcAaK3IgfIdBQBdJKS9BkkGAO3xqiYbFwMA0UeKsti3DQDANJ4U7sICAFP8mmL1dgcAqUn8UOr0AQAkRDOmFMUGAKhMVpeQMQcAJTUjvE6EAQDh7v1DRR0CANIb/6onrQEACM9zSP0hAgBBYxU6TyACAGSkZUBBNwUAg8/tOww8BAAgpm5wflUFACS5b1mqjQQAgJdMyF0dBgCewkAw6H0EAOcHZbLeiQkAmUfc+ubUBACn6KB/g4wNAMecpVxmjgIA2Q2UFcdlAQCVHKE6X3gAAGmE49eYewUAhK3Mb912BgBYkPyWhWgBAJ9hA9RqbwYA73J3qFnXBACkvnNhboUHAFdqLD/3xAEAhDR8/G5wBgBtNuw5eJgGACZ/z5UfcwAAvOS8jnWuCwD12retWQQHALugXzC9TwIAz6F1zJgKBAAzdQoi4YwHAJfB4RB6IQYAZL/RgKyVBwCzK7SRSdsBAHJDmVtgaQQAWJpcceMxBgCPcs/vz+kHACHOSCgW/gUA9bF8XS2FAQAP5Vy+Dw0GAHV740bioQUAkNX/Be4aDQDZdzYETLQKABqWlOFPIQEAy+mpOa7hAAD3+Sa1yEMFAB3pZ4BJGQEAF8lvRJ14BACOt04Hq4cEAEPjjF470wEARhvrn0E+AQCk5l1WH3ICAJq78u5SDAYAEW2ufMLFCwAEbpWRlGoLAKUdE8m6JAkAXCsg3ve2CwBlm40kdw0HAPGL/Tu8iQUAa0Gjaj75BgBIrsHWo8AEAGpYCyaHVQUA/MwSw8kLAQBboMI+S+gCAFEVPPCinQYAe6ZhRhc6AgA48omivAkCAG+XOr1VNwYAt6zxlxgQBwC4B3u3LNgLAPRpdz0IhAYAB84tRygrDQBRfHNRN3YCAFMI0So+oAcAqzatxtwTAgDWvdVA4qYBAN/++PxPwgcAFrxIHMzYAACpGbRu0wIEAFKgFIz2zgcAOdHCWyXxAABqGDHU53MDABatp9gtDAcAAH7tuH2WBAA6Ui/Q7loJALuU0JGVFAYABnDBBPJyBgBTaoEThisLAA7sb59QlAEArKwxytgoBQD6ubhzbYIHALP54JnLSgIASDk2xvrgAgBkzUjkvvcHADwP2hAP4QQA6SCruWyTAwDQbOpP/KAHAKQ1xxWSFwQAIc1rKLkzDgCUnNu6s8oOAPm93344TgcA2Q+KxRNDCQAbJGJWqB8LACrt3NfnlAAAjhGOc/poAAAr7l8KZBsEANQZ8J1wuwYAmc0wSjQABwD0IjYuQmwCAPC1BWoG8wAApoAEj0TiBACV8NvgzUQCAFKZKjGySwIAWFz49SoMCAA+iPJMn2AIABLKobVu6AYA0czvokSLDgC0/p+v0tEIAMNn3jIX7QAANRYpacMIAwBQ0vJI8z4DALuhoV5HBAAAiOFx6OP+AADfHmIyoYoCADs1r0wkKwQAiuDCTAZrBgDTvQwCILsGADGFcXnNagEArbaHeMXGCQAqWdcf8qsNAHmGUxLUCwUAUTEncQuACwBggbE07WQBAD0dmy2vcgcAW06LRIbUBgCoGI3dWM4CAIs8UGefhAEAApNr7+AjAQCa5i8ZTNkGAA9poiJSRwUAs7iGnXiTBgDcafu9w/UBAD8HYfygjQcAgToMaPGABwBT1Pw8XaMKAPfdx83lBQgAI6x4gIjuBgA4azFLqlQIAGrGK+UoXQEAfstRAx4OAwCMH7F0LwoDAAPe1wwSnQMAsVay7l3SAgC4fCYZjUYAAPn7tancjAMA4qEsXLC7AQAzlY51FbADANq3agphNAEAFfXRd+dlCgCkOR5M9fEIAEUmUpUb8AIAbd6d29j9BADMl7qMh1QGAP6w9o3HjgMAImqjvq48AQBqX07lxusFALgOPZAEKAMADbKi2y8QAgCh5lwFBeQGANMypTVKAgUAnfLaVJD2AQDVi3oNHV0BAMuesl1yrQAAhW8Fmwy8BwDY//q//hwFAEn1Tem7SgwAIDHj17vsBwCZIzD1dfYEAFckToOxZwIAiLt4wxmuBgAS1dlee0UHAPsFPXgNKAMAAxq3//yuBAAeFxUENjYFAGV4BwkzMQIAvK80Q0RRAgDoVjeFw7ACAIYqKrfLvAAAlhL+UExeDQAMw+8T3V8IAO3lgMPGwAkAp2L74x3hAwDzCJHWj2cGAMipseovlgYAC6O5j6KsBgCYnxvKt20FAN0YcElYnwMAa521Ck8CBADCY2hjMfoGALBCfqblCgEAMdof8Lt6AgC8T+a5p4ADANTqCCEu1AIAgHVTDw17CQAthMnAY2IJAKM5RX6CqwQAOtdD2w03BgAjtHk6vyAMAJvS35QVEwUA/lKN6SemAwBhVoVBQBUBAISDn9B1kQEALY2LYLJ2BgBHK1scZboAACcQcGMjhgUA28YZwtbEAADeWIb/PfAAAM/Aqf/SRQcAV07TIVffBgAGDHp2L/MEACBux+qr1QkA4+EE4ekcDADbwVS+FW4IAL3IySseWgIA6jew88gEAQCYbKlvVwUEAG+H44hq6AIAz2C5ziOuAQBKmTIZh10CAG4LVjvWuQYActTIFCjfAgDtpArivvsAAOx4EobtjQUAlcnCtqhbAwC/hTGLpd4JAL27I81VtAQA+INIwBnsBQDVMbWWposIAFzFZvKTNwcAAjvJqYi5AADbJSOjDpsAAF58wXGufAMAX0iF3jn/AgB6xe/D7j4FAP0uAumf+gIAVIETLMeZBgD4H70edSoHAM9HSTtjIAEA9w8SSUcxBQBX0MD3za8FAO2NeBvnqQcAiAw7j3DvBQCTszy+M3QIAEIAYZF4mAQAcgFdf52dBwDEnjsBk8IDAMrKOV+4wgAAWU2bqTBdAwD0l+lcwEQBAO9/NIoLlgQA93Rd8RHaAQCt/sAZrE8FAG2v5+1z2AIAbvldTuECCgBLtT68AuoCAGQ1iLJ1iAMA3ek6UYwpCQD/FaAYNlQIAAk0N0NkMQIAryI7UJXeBQDf4uobIJkGAHpz/0lY2wMA+gdHZXPnAgDBI0yX9L0CAL1h0si5swQAKLypsuhqAgBRXBYQggYDAHnQYjNEsQQAuJxSHOlUBADPcr/GmEwKAJnYw5RlSAgAO/rXoxOuBwBmr45BOHAJAHofbrbHtwQAmNnvhaG+BAD4VRBxvPoEADj+Nnif+wEApi11RvSCBQDkTDIg03sBAMaYeBGJFAUAC0Ggkk1oAQCnxXgP2eQGACjavMShwgAAMmm9aUiBBAC4XaSRw7cHAEG2NawWcwUAagnpHeNBBgBNMQqzqaYNAEcEH2/QxwUASToL+HDbBwB4msg+SssGAH05ga3oOwQAZG8cvVjFBwA9RpbTJBUEAB0ankRrWAEAiu1KkH7xAgCOPB2G0uEHALqvoFxKQAAAvm9BKhueDABWbDELahwNANsb156ldQ0AHewfGgJMBwCOf25RJ5ULANZDpwoHQAcAgxHdy2RrAQBD6zJ7Sz8CALM1gqWrGQMA2a3cv5VjBACcml0aLdsHAC9ChQsgmgcAFt1xqr9VAwCqeF/qdwsAAC2CnqJ5ZQcA3zS0UhO1BABnJhzQezIJAKDIYDvXNAQAukOUqNrgCwB2orJLUSwIABcqwEl+jgYAtuhvNJVXBABGNY9sMIkAAPaIL2uf2AYAW+DJTTg6BABFtvGL2tUDAAltaqnW3gcATS/uT0nDBgDUa4ucmCwAAEgVliAJFgEAuk2bNhZWCABGb6yGq+wMALEA14UAxgsA6fwN4T4hCABtHknXN/YKAKrP2ilpFgUAifYxa4KQAQB9SmlnVfUEACLlsff0BQcAmFa8JeFRAwC+e/YaRpsEAJY6LHEVWQcADQxY72eaBgD8z3DvOE0FAOJ8btCC8QcAD3UhjnJLBQAoARuXkJoGAKNjqfJAGg0AvqYSrOkLCQDEQTIEzEoMAOxoAatkjgQAT2+ouL2iAgApaS1rOzQHAKPpjKoE2AEA6UPDyEp9BgB3V3pPu2sFAI8jfGIwkgIA+9csEhqtBQBk41Bupd4AANcqMcjRVgUADugbsVZnCAA9sHt+FGIMAN+/PnQZZQoAtCpoWfyCBwDHyIzjq5cIAII5jQzjQAcA/YJGf7TCBwAc3Me4kc0FAIPl+ZCnfwcAJNjRxsZGBwCkLaV+h8kBAIlhqIN7swIApQ0xSa8zBwD7BBwWgV4CAOi+NErhdwUAK9dNvb7OBgCfMkLkwUALAD6p0f9HIwMA4LssJYlKAQAJsI9LMAUHAAo7p2GsaAIAHL6+NPIGAgDo68unA7QFADVBn/BgoQcAeP2W7qcPBgDGbilNNR0FAMcWO6b1ywcAFAzPswv1AgBaxsqFs/4BADUWyuCYEwIA7lW3tPmqCADyRK61kWsCAMixeo2A3gYAsDBVZ2mnBgD3mE4o+7sJAPMzKziKBQUAPpEWGKl1AQDoimu5zfYEANKB2slHcwEAI1rZ2T6qBQBhZdnH6XcHAKzMBvBYjgIASawsu7tBBQDsTJmCMuYDAJXo5RR+oAQAm6R3xM1YCwCA5AL+iMwLAGrj9LeqIQcAU5lGyYxACAD5Stiu9woFAJn5DZjLEgQA3Cnu2I3nBQBdV4z233EBAEnv9tJdAQIAE9ORw7rwAwDlW/YVAd4HAMlNNiEsJAQAmGCmZFu3BgCFwAIBPAMAAL2uazEakgEAi8Hz2ZqtCgDqmjM4FuwFADuoWWU7cAUAEtYFTZ/6CwArBsreSbAHAPxwuN9+LwIAKLF31u5pBQCvpbDcNwkDABvqeJwDWAcAOice9I1FBgCDREQ1euMDAJl70rf9YQYA5CHWHXYXAwCJYQIwPDIHAFApvMw9CQYASwOEYL7uBgB7jQr3Ac8GAApnxlQatAgA2lW7mUvIBgBHtpgMGOMGAG1w4IWFmgMA/mMm53wWAwCXQtvsFD0GALhw+dwhvgQAeoKEoB59BQBxsCih57YCAM9ddRF1sgUAZQWTwoSFAABZQW/ae4wGAHvZ3ZnpYwMAs65L4txIAADjBeyVV7cCAMlt2sWkvwsAHTeeZciqCQCab7x5+TEKAMQf7jXBQwAA1fIZmRyhAgDNul3CTDMGANoAtBfalQIAoJOGt+mOBADG8yrMS94BAIbroxHEHwYAwC7BmtE+BQDgBLjG2wkCAJKHsKm/eQAAMkLVooDtCQB4XirH/g4HAC2CKtRRIQQA6DHWtuu1CQAFR1mxT+8JAPQNMNpROgAAchxWK7VnBACQ5RACktUEAIWWeJ52ygAAF0hof8c4AADsexZb5l4GAKlQuBnaUgAAKWRlZYZAAABMmm9ZOasHAL+gpJLudQUA7tekCkW8BgCoCzt3pvQMAEe8DgsbJAYAFZMdT5wNDAD0guPnoQAKAM8vGIqQgAAAmLq3EylTAADDhcN4z9wDAKmrXt0CgAYAP80ScU49BADFOvnqZ7kFADEKWMqsYAMAYvLG1V/GAQCr7MIVfxwHAORRJqXsUAAA6mjmYHY5DAD08pJWp8IHAO9mbH6esgsAmdq8WKYrBwAaE/oJHBUGAJwMP0XeGgMAaHhzB+7fAwAR1Kf37BEGAPZkvWx+YwIAj8UhbO6wBACWXfD9DVwFAF5Hz51WBQQAu5h0J1xcAACJw13ZiIUBAPAAqE/y/gEAc2uXMPWvCgBZhMBIWtgIAN9CNpbrlgcAJrbEUO4LBgBAg2z+BYAKAJYxpxr7UwYA+gaD7PoHBgBUUj7IXugEAP2EBZBWnwAAhvySktREBQCIhlI0n7oHAF0ttA+ihAIA/m9w2SxlAwCz5t2te/0GABbzMClHLgcAFHYq0zX2CwD9AN6s7MsIADWp6kERQQMAlMvzQh4cAgAG/gDw5/4JAE8IgZeMIAUA0iTcoWhkAQCoQMUKeL8HAAFT185+pgEAOnPC6NKpBQDl99sD2gUDAMqut5mGIgEAyWuTsiMqAQDp5mqlvaECAEDgHgWUDwAAQJevB7uTBwD9+tTstucJAEL7YBV7LAgAtl/MNGcpCgA/3SX9f3sMALIw08MjawUAptFg4wh2AwAucsjz4AoBADe2GLbZhgAAq77ox3l9AAAS3Qi8nPsDAP9wU9g9XAcArBko/gZ/BADtFZKrBtsFAGTqNQpSwwEARsBrIUBvCAC02Q+bV6ILAIvsfkAmHAcAC0+1StoqBwASbbbDUIcLAEqjy7ymUwIAGnAzBAcnBAAOh/lYjgsCAMwA22HINwMA7tB1V9DDAQAa5SKUQPEGACUtzr5rhQcAHAMvp4AzAQC686eAED4EAAQzfSweYgAA8/DbsJYXBgD11jKcLzwPAL1+U9GOqgYA9DgYyZJOBwACEMqJ5dgFAI2DWYLMYAAA85Vb89M4AAAjqUPCeGAFALIbJJMy3gIAOr2XYH0AAABLqUIIlR0HABfYx+URawQADU/LvotHBQBdHApLBcMHAMvBg3c9WAEAxyidzARHAwAA8rGY5d4DAJ5tdJgcbgEA36+VcAsFBABVPOhkgJUEAOF6ol3vogYAnZ0u4KyKAgDo8GXpWSQAADMJFdNkuAcA2B7o8qVSAgAN6GZQJpQAAKVhjZEPpgAA3g/z90tEAAAGPO2pDcQBADuEvXDBeQAAVtDVwFDNDgC5eedqYLcFAKHdayK9DwcA+R85Ux5mBQC4F3MNjHYGAP9v+mTk7AYAoGCkvEDMAwAMjfsKqeMGACgSobwagAUAn6w0XsDeBgCzwVXx5SUGAJYycm8v8wQAzu8FAZisBQA27l4WYXoBANXcTeFFFAUAQqS+K6tHAQAmMSXyQPIJAIhOMZ7ewwgAXqT8pKUeCgD85IYAmS4JAFFJFDtLKwAA6mqWd4loBQD9nzluF44BAIuTtF5c5AIAKTke84YxAQAuu99/s5YEACE+X51DwgMATWp+/mBuAQAdYpuI79cEAOnTBT8uewcAkbDdEpxjCACyes2QBBgOAHtGl4KR8wMArIEXvmhFBwCV4FJRGXoIAN7ELpzFqQcALWV5nvDpBwCGLfIi5KMGAItsgzuOrgIAMq3HX3k7BgDIX544Ao8GAAZ1h7zxWQAA7AxBDpkEBQDirv7Q15sAAPAy0IP+6AMAKdHv6I1MCAANIeYGfMYJAGkUf483gwEAidKuzlJDBgBYYpqJYC0KAJSicAW5FQMA8SWpCOEMBgAJyVMS9u8GALBwLQ7vAwAAxPqXt6NbBwCW0c1wwNsBAEdMU7GPbQEAKvqDgUkABQB13iPEWS8HAHl3uAdNkAAAuUD5SGYtAgCGPoehpZcJALtUGsTkBwoAz9ZLOws2BQByr+usCiQGAJyRut3UHwYAmVa1kenYBwBsxzxHMRsGANYx5jGWAwcA3cH7QyE+BACglaJbnHQEAAZfS/pGeQMA8VFaq8UkBwDz0514M1YGAEDbOPLaawUAnzudwWzTCABhItdwROwGAK6pGHA9hQYA68jCTT6qAwDl4QcVozoIAOszNfXjuQIAxQaoJ9etAgCjFc7IVWkFAA4pCgdPjAEAQTfYhkrSAQAfztT/SHYEAJ2eg5GVCgYAqxeB89UkBAAOwRJpxCwEALSuyR0mOwQAUROVbIs9CQApY49+AcAEAMT5U55VPgUA6m6IRgGyDAA/KSReTSsIALt5u4gZHgMAq7yzRi+4BwBBe4LOqPcAADBxFxZY4QUAdrL1XAUmAwDyjdEoy1UBAJQWoZwNwwAAGTGrJw4JAgC2SXpOYggCANPlmoBsegIAQWk9xAonBAClWVbZTO0CAPkodbMNXA8AM5Is/bzMAgDC2AM2UCEKAIixDR/N6wYAdBF9S+tMBwBcT99oYdUHAIrRbxd5vwAACvZPF2fLAgDQ4Qs5+c0GAD0rfpxRjgAAgQil0sNTAgA9M45EQRsCAA+Jc0vfsQcAjPX4BxgiBgDlizqBkvoDAHJVjcOY2gYAj0ZUVdkeCAAtNV0kmIYGACSisrPg8gIAkhwsomrFAAB4svE57P0FAAbxx/UKyQQAxY9l8s4fBgB6GBgqhV0BAHb7mrXbcAIAq5LPCxLbBwCHQHFdoucAAPDac8T0bAQALYFJ8aduBAAnhAppJQcPAPp58Ok6pwgAKsZhRJLdAgDM2FCuWgYJAPnlxJ7tJQUATGhgBtIiAABoezlwK5cHAGX501g5oAcAtU7RvIeTAgBXDSDfJUUEAIVD6Uz51wIAt+xwwQANBgDw2PMDBYsDAM7xZI4ZmgYA7crF3DRECQAffGafkMcKAHW1H52DGgYAdrvKADjyDAB+Jr2XJlsCALx4GtngsgIADPLMEgqZAwAiJh/hwkEBACAzpfrO3wAAOkmSap42BwBkaJgT+z8HAKwT97grKAMA75fyeO2cBADvHWYncGkGAORU24MGQgEA0FrMwW+7BgCdZpHVyDINADJsqE15rwkA0iRt2OngCAAHHRa0gx4DAJfRnSQevQAAj1YgGMsLAADUMIhxseoCAOaXaYH9lgMAilC/vmMLBgBPKwaeEscAAP0SW0Em5QEAPZIn/aBhBAC3pXD2rYsBAFDVYuvxXAUAP4z1feO1DgANxoY587wLAObqXIO4TwwAo3GOwd6ZCACfK6a6b6UJAFg9wmUQEAEAD4szkBKqBQAhdC6efhUDAInUFyBx6gAAiXBFVqZpBgDsyZ1cUGsGAIdS44bvdAcAXpXARNnRBAAgK9c5TC4FAFiceTZIPAEAgNCLXWr7BACbWAhJ44oNABKve5dNlQMA3EF0WeoTBABbjtyH3AsFALnhs1pGXQIARyjsJ/74AAAGT/Db5tYCAHYyG/yMAwMAe2M6yYBvBgAR4d9ugzcFAA0sezUCvgIA+NTIWO7cBgCSYR1YMtcCAP0lR0RW3QEAh8i6CADmBwBSGHw4XD0KAKcz9fFdngcAz/DF8fnmCgAvOvZQpKMLAH0SYjP4fwQA9LGCrzmOAACrffIuMogEAKShojg3lwEA9xkikUXmAAAnRjnYMS8HAPEAopTSewAAxnTiAL5lBgCLNrbx6D0EAJo6OdnIGAMAhdMdqymeBgCsa8ezhQYDAFlI8jfPZQUA+f6Owip7DQBPWTIcpAkNABn+/yoDXQQATt5sm+QvAQDxfDK8YxYCAN3xaUxeigEA1aF5xsckAgDpJfmm3G4AALh35mODjAYAz/vkJfoMBgBOQAl2wcQBABGKMgL/WwAA5BLFDd2gCQAPzV+/lAgJADacPwFJKQUAxzVHug/1CQAZ4N58J3YFAAvgyiNwEwIAxibrmTVaAQA8K1EhcmgAAOkkCDrLUwIApKI/zLiABwBfME8jvIoDAN4DwbuAogcA/l1pNqiYAwAailJBr9ADABsnJodB/wUALZW2E+hHCwC6PBzCZGgHAKh0zdtJ4AkAm3STD9a0BQAMCsq4TZ0KAJ3biRcMCAYAMace73y+BACAgJ12DfQCAAOmREx9XwMAllrCPaAGAQDQUzMzrwoFADW7PGGatQQAdprhwN8jAgBkxbIrHn0HAMtSEKU4qwQAicDdX+/RBwDZ2rnr6r4HAPusoAvTWAgAj6616pLNBQDSTrBrHAQLAJPVaGclKwQAT3tCWYToAgABB2N2OCsAAOXqBdR4SAMAigjcGt2cAgBI4VbZ+fICAP7BZa3mswYAXZ63cgmwBQCvXUwjjT0FAElAgda7BAEAUPF/1l+aDQAqNdDqmKkLAJmvpF/JgwgAbiYB/Nv6DgBxsA+i8gQKAGft8Wgx/QAAPkp45w27AQB3BLJ4y0sDAIIhLm6ipAAAp5JwxYy+BQB5sOswPTsEAAIZxqWsVwMAVSTWxXC1BQDHGB6esg8DAJEnfLEPVwIARyS4C1WpBgAlIxoK8hEFAO6bI9ckkwoAwxZ1wzw0CwAX4B35xUEKAHUVtix/NgIA34dNwJrDBgC95deLldQGADIVimP0ZgUAMDClXrbcAwCqbN5AKRcAABtFZy5bBAYAs/w+RgdsBQCRbv5ri3IAAN/81e0ghAAAuxD0BE7DCABqoNDA7UQDAG1N2IZU5A4A9GM4yy5ODAC3HTJPZU0IAEr6YoOrIAcAv9nNR0OcAgBjhF+tmOcAAP4Ly4vx/gQAdsH7PqXZAADVtb3dFsEFAM+rpbu00QYAelOlSIrSBACZCwRbjmsFAJGJYfKkpwQASyo3r5GyCwCXRP4oMA4GAAlqT8p7JgoAQrJCwu4ZBwAOPiIUY6kEAJVfsV8CGAcAlP5xg2uNBgB82fdIRIADAIBCeP5mJAQAMd3NxFAbAQDW/6QIRCcAAN00266C0wcAXTjOyc8KBAAeW6SZuygGALzm3OS89AQAbwudxG5hAgAc5mKEXfkJAMVZkZs+rQkA+E2gdaSbBwCVFVbuLAQDAIQlJOJazgcA49RTsV7SAgDJqZvQ86gDAI7rBA1p8wAAwHFL0c0/BwBBrJtEeXAGAE9IIUactwUAjWsV8mkQBgCvEDtXJusAAM6pyUDniQMAFawOV/Z4BQA3OZwz8kQGACxslbdHbgYA0FUf/jJICwBiYl1eQlwKAM653DSuswQAn6wVGml8BAAMQF1u4BgDALE++NkixAMApmWUN0UVBgBu3tfxpgYGAOcHYcTA8QQA2OX73LEpAgAnE3sKxqwDAIRUkQiaUwYABkq7FNTbBAC42/FJCJMPAO/KZqTFKQMAm+tPVCTIBgCbAe8gU/YIAHP30sN0HwIAOr0IjbgkAABRQQXPeOYGAHx0LicxNgQA0VysSl4cAQDG4P3KsdEGAJA6MGrHYgQAm/88aU7KAwD9hlfULJUDADDD3nu8ygQAidJ4P494BwAR+LMJKJQNAJvC+HcylwUAZ/7FO/kQCACxrGWBSe4HAC4KnAgklgYAcwTnyF8HAAATIx2rhD4BADuV9u0LwQIAyCEDP7k5BgDDoRGR4wgFAHovkQ4SkAIAQ66sZPTLAQBXYVfpc1MBAGBbyJP07QAAAEF2hNLEBwDsrAa//v4HAABBgnr7mgMAZf3nR460CQD5HU3FAEwIAGham1lYgQQA2dVBvHX9AQA8Xakf/NkCABG6DvIn2gcA1BkwLrkDBAD4XEaLgS8CALgJ/x2QQgMAzYPGXVkfAwCC1l90V3oDABcmqxK7VQMAGHOMWsfaAQBgNELVebYLAA1Atrf8uAYAnV++gzfHBgAqBY6vjlEHAPS7k3TMZAYA43QYdpQ9AwAT9pYXnhcAAH2G4jUFiQEA7IIhE7j5AAAybH8bxFkAAJEUUwaHngcAgrU8ZEfHBgDklNQKDOICAHWxu3E4fAQAsGZQyFBdBgB8HzZTdBYGABKzi4GjawgAIXWqm/KvBgBIjc4C6o8AAEhP7HGXUwQAKMqtizG5BwDFFuCvGQ8HACONYLF77gQAaWRXuIkLAADQ6t5odt0FAElwpAttCQQAFJEhl1knBgCu5meK2psCAF33dJqCcwQAyQI5rTpTCQB65BFr4N0JAHYLk9G+hAcAZ8i5kgrICQBMTtS0aMYGABjEeUZ12gIAWhC+MUwWAwBf75grrB8BAFaSd68aWgMAPIPEhIYHAgAMgnh6Ic8AAGnn0uckUAYAKqjd77U7AgDG0zK21J8BAKT4VGAaQQcAtHWxGD3lAgDzSiBUcj4LAMTEodXXvAsADl32KsLHBADDWCSHmuwBAG3InbkynQUArKkiXgesBgBxMxEgkgsDAG6WOKbZfwIAE7hPVzbBBwCbUKIA1KQGAByXVhB5QQAAXAduhtVVBgD4TebzKzACANZ8XIrYrQMARjA5WdSYCgC3kD3L/gsDANb4Peq42QMAeRVRlg6QAwBqQBoToRsGAPLcNbZwVwEAcZX3g82eBQC9fwscRtsCAF80galCOgcAecjMn5JJAgApkJUW8aAAAHo0sddPlwUAre0IHMzgAQATH634vXMGAI69yxADYgUA1oXid/S1BgDIbDLske0MAPyjA3VT1g4A1Ig5dtMmBgDOWDZvhOwHAEPWNElDkwEAUapeRKLUAADgb+eKcNAHAOHHw7ZHmAMA2dmkonZ2AwDHLqIdP48GAGtzojmA7QYAdTxM4H5iAgDR50emkOoGALmZM3Kv2gYAj46trL8EAwAHixB9kQIFAA/dpmwXQwgAgx0sjxXVBQA761ieRLUKAEe+PetidQIA5wsXtNeRAgDhqN9nytEFAKKY8mGAqAIAfWJxnk4wAQD+nNxq0hQAABNvoRtp8QcArG7wKBjnBQD8//AH7UkDAN3C1+KNRgQAuwdj+MbYCgByCYWhaygOANNEhLDc6QUAsmIzVGqpCQBGMuYnZNoNAJ5GGZReNQMAN4rquHuEAQBxm8+IZf4BACJr29LJsQYAS7T/xufMBgDKIqzeiMYEAFID/8N19wYAuxnkPmBlBQBGHMZWRFQGAPJ5/qspjwUA9s0Ocb9kCgBqiSeFxQgHAJQzxebqLAwAaSvoIRs4BAC0hUFyk68GAGg+542rzwYAIb3Uzu/mAwC+DVAJZgUAAN+FrSR4GwcAQX9KnGJ3BQCIqMYJRQIAAERmLrFqaQIA2IBLf6LMAACeERvxwccAAOzKsFvyAQcAE8G+fNn2AACjk3z7l84MABooEVqDOQkAVZHaepAoBwBVCQW8pSAHAO1sYeT4sAAAdbgPtcTTAQCYAdxzlvICAPoPg/Gw9AUAQNz7K8ngAgA1WoCbQwkHAIeBf1VI7AYALDqhG02KAACu+QuKNHYAAO9Escu56QAA276xXdWbBgC9MfdHTuEGAKwOJ0deowkAjd94VCJvBgDTz5FB1GYLAK0gV/uP1AIAd9+hIX97BQBFBrr/DlUFADGpmEBq7AUAN/OzThAhAgAUjLzyQxcEAMdzh62wlgcAm2i7XO6fAgA0hxdcZiIBAJPFa056FgQA24/O+GUmBgBXmMUaEJ0KAPufpbs72QQAFz83l3h7CQDstww3M0sLAAAn9nYonQMAh2wdzc4BAAB1dnQRGvAHAJCBoaUNNQIAUiXit4uTBwDM1oGG7pEFALh56rSwnQMAQgg4DyICAgCs4EK6dvICAObf4sZvFwEApQ53SYniAAByexSInlUFADDvY24eXgsAbv+nmhBbAwCQJk/lo/YJAJthnFvQbAcAlRaQsFSWBgAnf7cQN6UHAHWB0qcemgcA1XfGpMOPAADqNAfTmcEEABTMmssixgYAFgIDVQpmBQD7EZ8Z8WgAAJBrEdD68gQAJbY7tx3ZDADEEoFTgl8NAN0VmCda2AYA+ZzNsLdABwBOlPKVGUULAFROrpRBsgYAl4jt/QojAgBxUH1hEjQCAJuWNQ/T1QMA73JJSkhFBAB8feqf0PwCACrSnmsSlgIAsgUqAXGhBAAjVU3HktsBAIlCYMqJCwEAW/BFWr5BCQCmruyLs60FALvyQdtG/QsAOM61u4jUDgDT8J4dLX0JAJwoGJdJRwEAq8fkZ4qkAADjr0tUvA8DAIrlXzEBxwAAdXtXjYcLAgBqPj8HGK8CAP4kDULqOgMAlP/0iwCYAgAelttxkVMDAFzGPPYUIgcAtik79Lm3BQCzo+4x6kkJAAgWWBN3vgQAmF45YHnYCgBToVXISvIJAJOmB1NAfwMAnLbybOblAgBTnK5mQtgFALlT6H3r5AUAHBdYjPT9BQCqBZWOMggGAJrEHYSCIQIAByMdiZbsAwADLvL/Y/MCADmu4jmnCwAAJruI6vUmBADIdX/nkjADAOcZ2EA5pQEAE4aBTy4TCQCMUX3elyIHANaQh1zemAYAJetbVLhoAgDf/paLZNIGAHywHa2IeQQA13rmo4MyAAA5uQy+xx0EAAQJEGZssQEAbcbLIEyiAACBhuTv6aIEAHFihJYSXgAAUEUsJMi7BwC3NTsQBpoNADIg80p+IwcAelOzGkImBwCMJThd8owHAFpJnC2z7gIAUJcvdyWeBwAjvzuDR9cGAEnX1RbYzQYAmDbByQCcAwBonUgxjmsGALXiEH6FcwUAchSqFug7AQD4S63TZBkEAP+zdiC1BgAALQjOuRZ+CwC4PoVXL4gJAMQf0Kye0gcAFee1WWrnCgD2qWGVLt4HABx4lZ3hzwAAPEUcYswSAwB8B9rmrEUBALjpnO8rkQAAdrxDNH7VBADLXqW29NQAAM47c7uw6wcASQUgBWq6BwBpIOLk7fYEAAKm8QqpsgYACtiyWyTzCwD8bvMg9+UIAGzAYM/MuQsAJXnzI+OECADBdoIsgWUEAJce5pr89AMAJC366we8AwCg1Fy1RLcDAPMhV7JTJQcA0xKdTo/9BQDZYhAqsr4DAKjJgjsGpwYA7ZfBXaOlAADvPaUGDMgDABbLscIyWwAAgoHVeiykDAD+nnl+ZsgFAKFQyHReLggAmYZOYdvwAwAwZ4WkcRcLAP2oTdLMXgAAGHnw/buABQBqPIeGNecHAD75d9/tTAcAcbQ3alW1AwCC1E3hJMUAAFbGlnRFgwIARc22z2utAAAUJLDo0XUDADOnJ50H/AQADcWGDESLDACFO8qckjkJAC7fTOTy+AgAsaZ7ETKEDgA7risMF0ECAH8vv4mwOAEAOeo0/VugBAD1XpJMkQMCADxO4P9/SQcAmK/sfFYkAQC0c8QKhqsBAP+nhnwiwAUAd0TCvxIbBwB1MKhzpQYAAHDIZilh+AMAAI0ENvr8CACCs7szcW4GAHZWpKhCSwYAz4WaT27qDACgeOjuV28KAN4NKnjJDAIAs6pwME5dBgA2d1QxjrwHAJgtQ7G/ngAANpdnd6oEBQCx74dW1SwDAJVhL16PRAQARQNGnZFoBQAnGq3gwjQAAKPb2UMZBAQAyqpsokN3AQBkyflWkYwEANCaHo0n7wcAAb2njuUMCAAMgCkUky0JAJbM60O67gAAePiVU92EAwBy0jUaM98BAA73Sv3sBwIAQ2iXHQpCAQBPWTfTmXcGABhgj1RHFgAARfF4Vc5/BQBxKhQMIgkAAJo1FCP5tAEAsWaYpDAwBwB5JgvpK0QKAM59lNjTewcAKCBVwVX7CQCh+VYdGf8FAFEJFYmdEAQAy0ctLb0lAgDqO+eAwHwFAMsfcnUQ1wYAMvGncrU5AgBokC2sM9QGADNwpDD5KwcArQ6i9KxPBgAqQLmi92UDAPNYpybFIAAAdsxC8FnvCQAl3XZJwrEDAHJisVxmHQsAVsVw5FaGCgArYKXgz1IMALzb2J74NAAA846NlI87BwCryiPTwYYHAFFuJqnUOwQAE1NhxKwqAADfd3hkoPcAANTwkw/M4QQAkBHvJkfsBwD4EvWL1b0DALgEs9e3zwQAEu+Jl8KZBgBQvCHj6jsGADW7rUDDJQsA9SvkoeFiBQDTNMTL1LEFAP51m7hsPQQAVg6QW40zAwBTGlN9Mo0DAJ8b1WFcsgEAdZCzIkZLAQAmnwrMFSYDAN+2nLkRdwUAODzpFJymBQCZxaSAiegGAJKFJXGP+QIA7qZUT0SuCgDBxft6ORUGAPv484N3DQ4AuYbEX2eqCgATdp4uBtgJAFaeD7VMpwQAkgFkwtExBQDSf2ydPcAAAMEQZhXNfAUAaoCdJK6mAwBafJCphdoCAK9M7CE3sgYAojpopNPSBADv/Q6HxvkHACXvis64mAIA3mUhCupyCgBu0D7veYEGAB6s/sC54gwAumMbCynuCwB8OoBxYroGALIM9+9TeQIAUsUOriJPBQAkJy6pPZ8CABi9IgzKQgIAztUEhIpLAwA1M2mDtewGAE2437927AMAT6BWz5XIAgBSTdVJUTUGAOFl1L1iHQcA9V73sdq1BQClub4M1uIJAFb+XRfCJwUAH/WPK4qeDQCxYhJiM8MBAIDfeNMozAMApoyW9EEhBwANbdtraQcEAPv8L7Jx0gUAcjF/MV9NBwCBytlnVOUHAA31hjFlpQYA8S3m7IixBgBxSYQ2bcYEAJ1+VMS8rgQA/bVUc56NAABowW0LdWsCAMmsAR6IYgEApQEd822WBwAdmtydvXMJAMkBbScbBwAAXgKOkdiwAADr4p6n7lsHALhNCYQpyQMA26OVv4/YBQDfclj+Hg8AAGolGCOH2gUAYFljgeucBQBkx5N284wBAOoZO9EcbgAAUwNbnmKvCwDk6Iig8QQKAC2o7pz8DgkASqMvPIaJDQA22KihpvMHACNvFm9RrQAAGshXbfVjAgDKOEY4IjQBAFAKr/EfMwEAFm5SAwYIAwALgD1dOUQGAPzevj0guQIAVaNW5oyxBAAsGLxmND8AABPl0t4PDQMAPUe4aB6XDACV83mXzCwFAMhVgq4E6QsAOJPzRq7sBABYHDWEUGEMALMzEvIaTQEAC5yziRneAQCeb2/caSYFAMc/jLI0NAQAmcACQiGpAAAuoLmuwBkAAJLXlWnAogEARBxXsctkBgCygPo2B/8GAKVcidKgvAMAvwHMnraOCACM8y2RyLQNAA3ywot/6gUAr6/KFuUgCQAn3zhAi+oEAKRiXTy8MQAAHghMD/7ZBwAs8mcU1T4EAAnRHgzM5gEA8eja7R1jBQAC0srxCkYFAF1l0J2RtAAATMEYfWnEBwCkoruQyDECAMpCBZPgTAIAhQvz/VWhBwD5h9TlxsYJAFncSxPhSwoAMW8ycFlACQDzJHOKkkkFAAbBBv31kAAA/UMeArGrBgCgEdf6vDICADd/BDzBpQMAbaAoPE4dBAAuGu5jpzIGAE1evf9L+gYAkke6pjX9BQDonekdXrUHAM8N7G22kQQAoWTa0I5KCAC9bglF/OwNALGItJPu7Q0AjrxRGsGzBQAYcAuLa88EAKcy6sc9sQUAHhNz28KPAQDjV48fZeMHAGWpXwVWVgIA7oUMjTOPAAC9cxqZIagDAHBYj0HmOwAA8J6sjsHdAQDCjZme4EwFAHiwLqjUMAUAi7+abEVzCQCsDRAVIIkHAMv+lUDhPgMAZAl61pWtBgD7ywB+PtsIACVI+eEwNgQACUBrapXRBADgtfgt/hMCAOaREaTjXAAAdwHxU6deBgBjYwniPvwGAKxnbbk27AcAsVgHauwQBQAJIQLfh+0AABoeksFOKgAATHnP8WJhCAC4Xv7K3SQLABcyRuDVGAgAjUKSkIvnBwBnwN61Em0LAKK4JDuaJQYAnAsX9LWIAQDrXeHewIEGAEV082Xm3wQAgCcRxUPRAwBXRRV5kScFAE1CQQePnwMAPZJXs25eBABvdNtemywEAIK6hXhR7wIAUS9bMPu/BgDdEteyErEFAOLkT5d0VwMAo+OWevhKCACfswspaHkFANyuWIxOlwcAxog0CH51BwCLvOcqxgEGAHSr7MJwUwQAOhSrj7fxAgAB4SAKQ7gCAOP+iB2epAEAlk3OR7uLAwA31IS65/ABAKrCXeND3AcAGJc+J1wqCABOi7LfySsLABnb1fj0jQQAjwJsl4dMBQBQLdiB+0QAAMPZfYhlZgYAsrBqCnYpBgBsPiTH5oEEAHf8RnDjlwAAzFhnAXLvBwDZ4wepxRgHADs4a4zJuQMA3MxeJe0GAABZmiI4ZZcGAA3D+SOY9wcAuof1aPAfBABTzRsZCsAJACSeIJxvtQcAvqrMXx54CwBswDEEm0oGAOgTtaM50gQAZhAb9SOXAgDD2QTP9EIGAHqboFoJ2gQATXg9N+CkAAAZKX1bodYDANalRlCnGgQA2tPCHnWRBgDEIWerODYCAIPhrNCncQAAMUThIFI1BACBOSgqNuEAAFSWNdh8dQoAjw2xes3pCgB0F3bPm8YHAAu6h8iqLQcAYNpdrPS3AACkmAQs2r0DAGABGKpnTgcAp24Ux7zDAgBfKegE69cAAP6gbx7qpQQAYGxDXGNeBACL0dSo9I4CAMoqMqep9QYAq0TZo+vUCQDk3PMVDxAIACR4Ng5wGgYAIz2rkiKSBQDT6A5ouSoIAMXGQS8MAAEAdHFz358hAADnfRJ/chQDAB64I30n5QcAehQuGuKUBACaDeXdhYoEAPQ9STT3wQEAiWiGZNt7BADsjo8EfZoFAGukvmzXtQYAIiV4HhdBAQAffNombYAGALmaxxsd8wMAaFGfRSCfCADSPcBpuG8BAJTZDOxsVQcAClG3A5rrBQBxy5Hd0QoFAEeKtIBXqgEAd1JoPzOuAABiCbYzlxkGABFlJnwVmwYAyvGT+EBHBgCE9vsIpDoAAA33uDge+AMAEcgXXzV/CwBagTRT6HoIAI7k0t2r4wcA5UUfvuoeBgDtzTQtPq0IAP6v2X7MDwEA8m/psIwkBADiclERHDEEACVpvxzUyQQAUE8Q/BAFBQCdJG4zxQ8EAOEt+zlmOAMAeHvRcfi7BwAEgH5reV8HAKEPv1jBJwEAdLlRrsSPCgDT29K/iW4KAM5ldqAi4QwAwgU0ILHKBwB9Fp1Hgu0EAKJ5mC5CfAEAw/7IRlmKAgB3K5EuszoFAKXgn6BNtAcA9H7Qh+9UAwB12cVgIrUDANwfFzZonQcAu9RA8ZTZBwBUGFYExLYBAJJTIC3ZAgMAZPHg5LZvBAC3ZVKtlzQFAPyGE6Db6wkAO2qzDC8wCABsQuv1xe0IAD0opLyiwQMAAi+7xzA0AgDCi7Ub6qMBAGFc3mNXJgcAyvF2O10OAQBnjtpT1r8DAIoqyD6VhAUAe3CnjyheBQCBHZPDXzkFAMthE8VGWwQA0eN/it1NDQDSGcZBzM4KAJBNrGJlOgwA2L2nrKXvDAAhIfOuwMENAKF/TzG/KgAAKBWKntGRAwDHX4kT+qIGAJGl6t2OnQAAt9w2+nsXAgCP23n6vBsAAOFmNutL2AMABCKBHZIMAgDOMjs9hN0CAKvYh5NhrgQAg/tbmER+CQAhzCbGMk4NABeB8y9BlggAaSQa1kGyDgBCuuWrhVYHAC6jRFOq9gMAuxEPaIOWBgCqI/aBNUwAAKXLdVivAQcA83uxkQ2gAQCy8mHrMwkGANJNKuk/GQUAPvRQpZXZAwA9iDq5b1UDAA47YptSNQEA64Mu4rwWBwC4PrgwAT0DAKyv0LoqlQgAiRvTTvYJAwAKWVGgLpcNABjV0a3X2wAAHiPiI/gZAQDifV5u1lEEADj4cJnDAAUAo1ymgVubBwAReI/cIKwEAPoB9amJlQIASmtq0hDYBABZspYN4O0FAPMFWcnp9wQA65lSNT1ECAA47lp9fZsLAOs0L5pRkgYAeM8kSUDkDgBJFErsLpQJAC4wgVe8SwcATOyBuzUxBwA8SGEbZ+8HACnXzBRGJgcAOOaSrZMZAwCSSSOuGVMEALVP0kedIQIA9mywiETwBAASSnKeqjoFAJzvFFOmoAIAJ3kcPM0aDgDleYe3RosFAPJ6vqyaNgsA03QwdLAJBQCh3rY53FUIAMIn+fd/kwcAtqXGFPrCAAB80G3bvVYFAAjRecGs9gYAwkeGIW7PBAC2W43CfCIBACN29b/pjgcAOokfJLKMAgByZzweVFsCAKIKcQejIQEAyYN0xz5xCQDK+tVyBfcGAIH/Ik7zXgoAhxEUT5RNDQDSzqaUuycFAJdKA59eXQMAm7yFlwYmAQDwT4XHTkcFAMpIowKjlgIADqTHdvwzAwAuSFuZKpkFAMcqAAfHjQcAQRfQlGOTBQAX7xoopPsEAHoKsmmQuAYAZNvHtYz6CgAPqCqY5hgPABoaGviVngsA+mxk85TnBQA5doowPUcIAA0icGJBoAIAJdBpiyRfBwAnamUWvMsBAChn4tb/uQUAPqc6EMI7AgAFnlgDJnkGAF1ZkpjbSAIACC2tPKUGAABzuvdQAQ0CAEPg/Tv3AgEAmhxRteDaDABV1OD/fyUFAIAh69EIQQ0A+a6bD8yWCADppF1yvfYDAMZFV3+ruQAAYx3S+PDKBQAr6gikvt4HABZtiZPbngAAwKVe0pdlAwCsWGAQe40FAGnuC9L4zQMAXgFlt0wKAADJfHwzMmgDAA2mncHstwcAiPp8p1FKBgC1Dcpw9JwKANiYCG4LtgQAx+b/3QRdBQBcv2HG7TsIAA1pXGk8NwIAGM8NUsjABAC5lHRLr4QDACUioo5KqwQAQxdg11ojBAD1dYkHDcsAAEsMUz4xkgIACaUkkbuNAwDxEVpl0FADAAbfDCvO5wAA5nBL2d/+BgDUv0WXPzgKAADDxCeuvgQAPz9qQaRaBwDOrjhhJRUOAKOFjMQ6ZAQAkrg1J4yHBgB32PQjNaUDAJ3ui+0EpQMARvvYpeBmBgANy3BITvYDAFdlbbFIFQYA85Y1d2GiBwA6XSdfTXIHAE1RDYG88AcAjRNyc62dDAB0ENPl3kUHAOLbf16lsQcAoW4Xj5i6BQBa7N0HqdMJAG8T9CakawAAILcGBvzKAwDanDWi8BgFAKfsb+Tl+gUA7Y7P2/jRAADcgdA+MZMGAEIXkGajsAUAfsqkLIcMBAABngCUgPEGAL8xSrQRAAAAXKcKamkfBgDKQq1XCosLAMj9Brea5QkAzL9u1AgTCABQKC2KmD0GAAxsxj9soAcA+0e6wbrJAQCOA3XFNTkCABOcxXG98AMANegW2UisAwAuI72vUwcCAAJg0B67HwcAOq+kR66cAwDC2TQLfDMAAIo2slKtPwMA6M8ixNDIBAClcVkntGAHAD2tHLyV2gsAdXNb/1HxCACmkMtcNcwDABYe5MXGSQYAgKrm7mcGBgCQ4SsYnRcEAHlpflbZUwYAbSWaQg9sAQAxkT6QQ5QGADbd+cZKbwEAU5LiEknqAgBd0mg+ZLQCAOe6JvTqMQYA6A1wo7l1AQD7SKoAX3wHABcDyoV3kQsAmJPHsqlaCAD3ZfbH8jEEAJ/+ZtoQBAEAfda03IJNAgAtdRcO/uYDAI+wyx7e2gQAkeqxSJZZBQAZe4+FRGMCAMBaKUo99AUA1KxSXKdCAgAQDSKARJMFAFMS+RVHsAcAxrrmxIDCBgBudmGzo60LAE47XBLlLwQAIqxKTdgRCQDdfKXPCo0EAEOu9qwovQUAfZBWj6tvAQDy1RgSsawHANu0IyDgHwQAZS9cvzebBQBx5qt95CYHAMH2RudF7AIAhkbHUw5YBgB0P2cEoe0FANM2Exk0YgEAQIbzH9acCQCoG7TExmAIAG42pwz3XAcAHgFs8agYAQC5A6IHV6IEAPZ/JvbemQQAPHcIgYVuBwApy93FypMGAPSfCtARAwAABV3N/v3NAgBq7fZTimYHAFYlFC66AwMACQnBhAWIAwAdJgoAIP4EAORI0pYYcgUAO9rQoZFQDQAKBcHHv/YEAL6pLs1OTg4Ab76L8rF+CAACS/xakzwIAK4bGP0XVQYAbYF2LHflAwCKiUCWGBkAAJl03oQq7QEAwWNP1+14BQA9DCtJxnYCAC6Tv0D8mwAACzMf8eiIBQBuwk1pbtEDAIwokLUq7AMAuNEyrgk6AQDktFq4HugLAB6uPKSseggAc2NS1wUvBgC6rcZmv+EIALl72OR70gAANLRdIydsBQA3LaYObi4HADnobtBMZwUA/ACiJVzdAgB+iCx56dUDAFW8q01yGQMAAAhoeHy5AgDd5jTd368HAIiuNYtUMAcANOPWoUsJAwALMOOnJuEGAMX7/K7AiQgAgmWDH6HuCgCDh30nooUFAO64qMujUQUAhtjiK0K2AwC8iZZB4TAGAFWppwc7ZQQA2xG0QzQEAwBiidQzgl8CADH0rwSPvQYAEmOa/Qf5BACb0jfH0w8EAPkOlXhiZQcAis+G6qNzCAAtnPur4uAGAO4z6jgqDgYAGP7zKSQLCwA+YUtIv4sKAMDIH9VZzwMAGEfe1qCgBwBLt28+OlwFANVPiF8TUwMAhBuMChb0AwB8bBNvXC8BAEzeN6Lb/gAARKu/zrx5BwAJaU0/qa4DAI8YWLOc5wEAboHg9dhTCQD8Ltu7M4UIADCUEpaXFAkAQoYWNm56CQAendNSq3gMAPHj9+7DNgQAJgAfwtP/BwCpLQrye+cDAN5yhPy/GAQAs6OzUXldBgBZ0VKS06QGANTsAFnjkAcAhneXvyUHAwBToDUWXAoBABKiEaSHbQEAcAVO1eLVBAB0Xz+z1+UCAL9+iD/epQsAtjlhvSTvBgCmpXe1kPkJABViBkJafgUAdzaYRIuhAQCPbx7eUuYDAOvYLuArUwYAOF8WyIePAgDW9+gbrU4EAGb0MU+ddQUAQ3n0SYE3AAApTyvjO58GANY0Ff6CWAQA5G88lCmZBAAVW1RycDQMAMTn185rIgsA3ontTBM6CABeQM5D+NwHANaDeXVdNAEAzcw0QvUiAgC024o9SngBAMwrjO6+bgMAb2KPW/6IBgDAMkdKSNYAAJItU8ZKuQcAD4VUhxt3BQDIYRTf2Y0EAHEy54eWcwYAwBoMyJ3MBQDN1IYUZ4MGAHOBXhpfbwcASt/59dPVDgDm12iPC9oHAKZ1VjgUIAAA7x09tV8VBgB8kokuo34DAC6o9WimWQAA3NShqxVhBAB22rXDUxkHAIF60zMiZAYAvbF2gGXJAgD/EDDmgaUFAHQ26If4pQUAuUOmoNMoBgDSkwxk2BwIACsP18qwtwgAvUSBqU2GCwAbXS2uNz4EABE9oXDPAQMA7JEYuqGmAgDgOj/7kfICAFLqS4F7GgIA0URuZZtmAwAz4abtBj8GAA8HWCc0MwIAdcCcReCYAAAbfGytXt8EAF791GweogYA0LKZZhIpCQDnPWCiEe4IACBMx/XCCgYACGgZKhmbBQDoAXCwcVMMAF/mRjAKFwYAOJ6kRhpABQCoxGFV3QoCAEae3u20qwcAXxkan7+GBQALefhejQgDANu0/CYhjAMAw+NJ4bqFBgAw6aQB1rwAAFIOeQP76gAAHa51D16ACAAnCoZZzGQMAO4LsLflSAoAdI/vdZbZBQA1VEw040oEAC8ESDfBVQUAwDJCdUHQBAAHaYYwtCEFADmc+0COMAMALKB1xqwJAwDuQ6W7uYkCAJ5TKC5ZqwMAOtjNq4JNBgAn43LBjscDAEb5tyFSLQYAKXr3OibUBQCwroki3T8KAOu5fvdk3AcALEA4g9IbCAAhOTilKU8JAG2T0BicKQQASYpBg0GRBQDVriHHGCoFAG2XgrpRsQIAVMdL3u/ABQD117Il3H4BAO4bCKY2cwMAw+WHiDG1BwDhWxpJbZ8EAOC+x2Uj5wUAPrMILwY5CwCxz1fm87sEAGdZbvX3eg4Ajtaef9bbDAAzt1xVIAsHAH8hcUUH/AMA62orm9KgAwCd5d3MeGQAAPrdGwVNXgUATnvEBBF/BwBMLBFVxRMBAMq3+QNRUwcACCGaHe1AAQCvwjszIiUAAGSg9JhD4wAAKBlLPgkLAwASA8h+fs4JAIOP97115QwAOO0LGXofDgB4o2ztrfgGAOi9zj7ZIgUAz/bgRfAkAAChzyY0tm0BANgP0x86uQEAYqNoU0DlBQCasrf9PRIAAGg8UlZDNAQAX+4heVKaBwB+gT7L/EsHAD2N7HLegAcAcif0APPqBwDjTDWIUUUNAKvLPUrK3AQAy+u/0BTTCwBXK9Nq/N4BALznmghFhQIAXMGg6Y/jAQB7N+LgRiABAIWoClYccgYAKBlnvyjrAACnlVHvGr4DAOu1vWIv8gYASTBSuGiXAwC9/fvIlDMEANKNvwHSZwQAlud6Vr30BgCDtxeTyFoGADKJ/SA7fQgAFWkyCPIACACDo1tanO8KAK1P73SakQYAv1IUYdSeBQDvCeoE7JEGAITpACfLywMAPLr1xEMcBwDNdJ769m0FAN9Wz+SVnAcA4gnGO2S+BwB46NkqwUkBAF8MOcpYpwUAgdxhHYuRCACb0QwmUNMIANi0N06rogcA1xRUc+ofAgCdY38COKcIAJUkRtkQJwcAVnQAqq9aAgAbo+ooH9ICANBfAOpxdgEAtz5LJK7bAgDM4f9XL0oHAAFzCHMwvAEANJwB9FfsBwAkpR8uCE4DAGoSNaaMaQIADtk9Xi9wBQDHxXBKmhwDACT8eKqlNgkAAHufOy+ZCQCir8SwBMADAHi6sDKIMQUA7Hzxn0vyBgDHYOAwf6QAANDIDVSEgwUArpzE3EP7AQAruPQGrEYBAFVzntgAtQQAEopyHB41AwDjL5NpnwsBAP3RHNA/tAYA8w52PlhCDwC3FjJXwT0HAEpx1/1IrgQAA+ETil/4BAAN/9ayIDQHAETFl0ZLXQcA9Pj3/+EbAQDh91do4RkBANX1XDQUigMAL7UFcY2mBQAGHoWey/YEAOWVGEfEeAIA5GQ9zs3vBwBMS1xFbU8GAEuj/jJW2wMAwiWYgrGQCQDIJTJR0+cIAK2rt+MrwQkApZweeHeHBQDyXUnql5ENANjZXfcr7gYAjb406yzHBgDHXjTMyXkGAKSYaPmNiQcAdZ30rSFDAACuWuXkGWABAJwgXfLFTwcADe2dk2pWBAC34BbnY2AGAHBNH9yvXgQA2rHMzyRGBgDBtnKAq1cKAAlvZyUHEggA7Y5O0BigDABs1aXuPPcLACvXRYCFAQQAMC3K4OVZBADqizAZt4gEALUyGw1KbwUALTaAvO6lBQDGjU4K0b8HAPQ2ZzaZyAcAAVz56rteBQCKP5BgsG0EACFmEolYYAIAL+V2xjyOCQCPqZXZeWAKALEIeSF8SggAWWXmA3bcAQBEJAuh394IAAT/YIOmBAcAPovePMzOAwD/ZA9H1RwCAIk5lY3BqwYAFebkwtBKBQAqUiu41WcDAMd9Pbj00wAAjcXbTH8GAwA3eWnaUgQCAKl3qivLLgYAdCi2rzYoBwBAspQgPK8AAHo1fymFwggA4taAVi3MBwBjVgfVExkGAD0rFWFSeQUAvTz6utuhBwDViCXFMa0FAFxoZEE6XwQAbZaakZ/lAgDaMTIaNi0GALgBTgCEUgYAYB3pO1NWBgCfqABsAa4GAAUcEyq83QMAFLuWJ6JXCgB0PkT7YPMGAOrqIHLkgAYAGAzxpfL8CgAfg42zf+4FAEvFXs75DwQAW7Nh4oVxBQCpcA5UVOIDAPjjA0CBtQEAS8BKMWiJBwCOakRBy/0FAHEq/yZpKAUA9rOW4jHyAACTRshXo4QGAKC8yTMGHQYA33P8+LwoCwCzlf8G3rQLAKQRuiekCgsAm23avzHuBQBngN/COrIFAGYl2/81SQQAbmwXbQEvAQCu9RYPsPsEACpAmY23+gMA7XqE/WXpBgB7UoDuU7kCAFqzsc1bXwUAZjyiPws6BAAKgos4B24HAF3ZnbubmwcAYXOfjq59CQAy2gJh9xkHAIvKgCp8EQ0ANQldtmYaDADKrGAUgboJAMImMWpAVQMAdn1yGBkNBQAOjkkL6uUGAPIUMga2owAA0p+MFV8GBQBUmUIM+2kBABDu7NntmgUAAhiF6xaZAwA4xVxVF3kFAE+K5TkfmAMAy2/mbaXfBQAIWQcJiAUIAJNKhcvY0wYA47Fw6fSyBQDBy+1SRA8LAJMKI1l1igMAH6OL3hwsBQA9WnTU8qQCAIqi1EKdfgAAzVpwg8CNAwBAl3XFgicFAK2Q2ZczPwUAFU3oxzmpAwDgOX4ixDQCAPKTpaHZMgYAlIQM7RH9CQDgVyftsyEIAMXBj+UdPgcAqxZGyBDRBQBkryjfp6ULAKbLB7gVawMA1/4anor3AwAfj2AsnKUAALeBy47dKwUA1H6ESE+yAADH6htRvtQCAJtbntmkvQYAAU6Rlml+AQCAz3/O8LEHAIFUR3TPTwMAharPeKsdAwC3VF5uIeMEAIm2czmCSQoAhIjkhElYCgA2+0IwmhEIAMpnl3hM4AcAMrjPKBtnAQA3xeGifuUHAEFBRO+q+wEApt9kwb3TAwB9F8LonNgCAPQsGLoSzQYAl3aawYoKAgDZcsyy+jkFACDeHo8IbAUA747zJKxfCwACq5dhXNcHAKcvpMJLPgsARIG0EM3HCQCPNUjqtzgIABduqBARPQUAbUZftm5BBgAgzl8jphwEABK7mYr8wwUACJG5xnSWAAD4bzGZIfgGAOnzqfFUXQAASie90MW8AwCt1dK4hLIFAJ6WJRDj5QYAD2IGYw77BABg5keX9TAJABnU7I+GQQgAxTuSjF4QAwA4GD3UigULAPuT5Yf1YgQALTbOp0vZAwC3Zya1+TADAArw4Eha1AUAjZp4FFGPAADQY3bl/Q8EAEcGwtRFFAcAfA8XaD5lAgDWXsXj3kwGAD3+TvpJZQIAbmY/r0mFBgBou9RBKZ4AADz/XR8x6AIA0vsf+Z5CDgDiLBP+DaEDANb5ax5GWgUAgy6w9O6OBwDPFoxkT9MBADJRuirqfwAAHkDGHW6SAQCgzhfqik4HAA+8P/hDxwAAVVS/xAPLBwCYfpGpi4oGAOVh2AEd+gEAq5Tf0QCsDAAaJ70BIboDAK/EuYiJVw8AfZ/0ib/yCACf6Y7Rzj8HADKYWX2UVQAAkBmkKv5GAwBbGXmATBYAACe6e/vMmQcAXKfGO1ZzBwCznBNjCOkBANag2Qe0+AQAaU+SyiSOBQBWZOe7RqIHAGS4Abcm9AEAPyWhkcg1BgAv3o7T62oCAAWu3frIbQYAhjegQX0cCgB9+rOxa7cIAAEckUFMJgEA+b2ERfQCBwDejsYfUTwEAPk17TosSAAAG9NxUq/hBACbk5J/+cEAABfBbZWIegEAx535XgDuBgDMMbJykaoEACp362HdtgcAx9IBq/mrCADlCmOHAogDANvtWwTKLgsAzzJfNkN/DQD1v1m2qT8FAJI981DowQUA9fa5mhHsAQDpY+Ztb/EHAMbeFsvWpwcA0vHqvOkDBwBVVIiU6cgEAIKtnNq1zAQAdekQxmtZAwBen9sNDKgHAGFMXD7ZmAMA8uPn0mB8BwBwOHZREAYEAKrS7ODEewYAuXMTH5S7AgAwLADJyZkGAPNI4jNn0QMAieNL4bfiAABKePbaDSwEAFB4xh/qiQUAkfHdtQk7BQDM8UZZI6cGAGC+L7ucuQYAYlxI1qXTBgDAI+lmlIMEAN38xjCvHAUAtFSsGJr5CgBu7mGWo5gLAOLNQB4zhAMAphnexBXNBACOnxic4ioJAArgdHZCpwMAwXR+Ty8UBgAVOowxk8wEAOceK6wb1QYAPziSokpQBQDPAQ0fy8AGADPV9Z5GhwEAv0c3iDhxAgDokDrlKvUCALqOlf4U/QUAjsuTv17+CgCH58uK2iYCAKF++6KDCAEARM9CeHCUCABccmD5c90HACyrRSjfLQQAu3Yy/U8hBgBGUhoYjQsAACDredWmaAIAR4blJv+TAAApmAVo/iQFACG2fOR1WwYAGczVpbBeAQBanZKzCVIAAEdryMub9QIA7sKRtmDVCQAHzuP8uvUHAGyAFBZWzQwAh7FwYYtYDACBENDjVaoKAF8TF5lCfQQAcPB6oM/qAwBEbrRGq94BAN9spDs/pQcAGuXiQotFBQBPRAcM5pIBAKodokOIrgUAOBULkSHXBgB+QaaVGjIDAGinqASQPgEAbIc7GckABgBldw2KGxwKAKGOs3+SeQsAGuDbeXYNBwDpjYlAYPQNANvOL4NFiAUAc24Mf801AQBb4+jf+z8FAFvlBl4ZLwIAzkuB6Dc5BwCN9HspFnEDACCXBg2eWgQA7ESnGvdaAgCjq4rL8BoEAF4diU6KzwIAomvQF35IBQCWZS0DKocLAN9Ik8AoXgYAwkDOsmt7CgBpHYny96YHAGcPEQeH/QMAsi2pFodvAgAnMHUbqs0BAGEmtVi+BAUAUoLl1psEAgBJ75pqjf0BAKFvIbdnywcAgrnDU/96BgAoltoQpg4CAFlU/K0aAQYAffjLAsjQBgB7TFXtv0EJAGJC72e22wYA3H6FJjGPBQBAk3eL4ZwOADz4lc9tkgcA7CsOEiUuBAAV+vFt6T0GAMz581Br8AQAL7awwVz8BgDLeZiyKFUHAD1aEtKPmgcAuGp0S418AgAMIQI/ifgAABBXrrOWVQEAyiRRfhYxBwA/4bvoOHsJAFWQL5Rb1QsAPpG+lRScCABs+xokTqoDAKJ5kT/SOQcAxOi52/oyBgBIDP4rUsgHAKla74MJ7QYA9LWHdiPSAAD1BTMqvzgBAJhl2CRd9AEA/mAhrUsnBQAq0VgdBLYBAHpo5KbKLwMA38yHJ3OkBwBABn98Qh4JAGOMXzhZNggA+mt22er0BQAAJmwz9kYHAPWafcWNbgUAeE++F76zBQBLL/iMkr8DABFvCmBVLgUA1uvvnH5iBAAcl2yrRfMCAOnnY24oUwYArSOKt2EQBQABRbWsmUkBAGbtB3CRtAcAyqJT3SgbDACF6odf6HsDAEFeqNLjSwcApmzJ+oe+CQDMCP4gNtAJAGSwhKtc+wUAsIWCdz5RAgBD4CUxOFcEAD0ibrWjvQYAT4RvN7oiAQBU5bSizTICAED4D6MrQgAA9UN7ZudRBwA+X9pVFyYGAI62Ur9wLAAA4XKNRb8yDQCbtZbnlg8MAKKdb533LgIAd8q+Z6sBBQBD6z9+abAGALsvC11L7AcAUFRZEOkAAgBecQVxBUIHAGAPUyJw8AIA7wmk8DRjAgDAo2LfSvAAANm2i7Tt4AUAA8D7pErDBwAkrFxOTtcHALJBNPQ3zAEApq7OyfFWBgDsWq2sHAMHAFdscdCMMAEAQhmUcxMcDACV8XL3RqMLAE8yx1xaVgcAEUok1aAcAAATh0FnsBYBAK7tVYx9pQAAAzgQnIDGBgDIatriElEFAFq6PQo9NgYADPSmi8kZAwDHbqMDS+gCAHzv9rkRWQAA3OouUfOsCQBoKmk5mGMKAAYFgzSiaQYA1AMGDJKLBgCyZByd71UNALsO3/WDmQMAJpiViSXqAQDWzQOHY84GAAWFiXgWMQYAcKKaz86zBgAIvXM7unAHANSG4fd1FAEAvCuJyRslAABazP+bq04CABc4E970dQYACrPaO9n2BwAl1L+lrPMBAGCXHBxS+gIAzfknzoAhBgDTLIgLRQ8OAPyCF2sDUgQAxYF2sJUtAACyBZL5HJAFALTsXm5okAIATBZw35k9AQDKwOUhw14DAClA9DfjOgEApy0/gY4ABAA6DI4vJ0AGANpe5eltwAEAqmlt/0ArBQD6fzcJiBsLACtM0VxiNgUA0RcuJa8WBQAr0+f4loAHAOLEPqPWegcAIdMR3MUXBwDkI5hVFKEEALHioVDOBgMA28L+oTjPBADnXPoNZaoCABWU8agWSQUAeBLnb8kNAAC4PuaEJ18FAJFgotPKcwMAmrvdifuoBgA3ftnVNYwHALIs73Q2bgYAj91TrEdDAwAqEaXtRxUKAHz1yYJNYwQAUtamaJIkBAD3L39obTMGAKDZJk5P/gQAQVSUPQ8EAADThln9OekFAN+bAUchKgEAspzQ52bEBADdA9KVW/oGAFSiNKNQNQYANntUckVYAgB3ExyBWFwHABsXzDfG0wwA4jR9dDA9AwDXp/q6kpoLADfPabXt1gcAoCzcpZQBBgCmEF50Wa8FAHVIAD71qAcAeK99LKbuAwBOJ5PmE8cEAKSzbnob7QYAFY59ac4qBgB1sCopuGYCAJxcZqA2hAYAaRAg6BfTBgDKoyxdgZAIAKCZFOvxPwgAGONQ8GA5CgAQFslpNjcNACc/LyDoNQIAgBe2Lp9MBAADcB1bkDAGANHqdNLI/AQAeKtof257AQBXUg6aqxQAAKWLf1Y5mQAAgjxCKnu0BAAtxHrl14gGAIePZ1pLywEA1AegomKqDABtLfY4Dh4GAIJHzI+ILwgA/xvygytWBwD2LtjSD9wKAGz8SjlrwAQAzDb2SxuTBAB4IzLQYCsHACWLgcYnUQIAQ+eNp7wwAwBOdBkRhP8GAAWT5OhgxQIAeqXl708lBwDfp2DF4noGAPFps+EbwwMAckLL+ZO8CAAsGHPb+fgDAMThuuo1sgoAGVUph7/dAgDV55cQ7BwEAO6KlAhNhgQAHvaNQzfSBQBncB9ghbICAFPX5rq8XQIALSY0EbYwAwCKgG2i1xkGAPK+rcKzwwMAUn/snnyHBgBttuHrub4DAIfykc1EawIAgwNzYpPyBwA2nEVRef0HAOdJLVFMUAcAX8U7fu2HCAAlx0kBsd4HAHV0OI9HSAAAPopn2ZeTBgDzdslWgXwGAGwiiVVN6wIACsHB5gnHAgB67maHaq8CAGzZoXmqigAAsC+b1ZIvBAAHnABALHUBAM5i/+lojgAA+fK4CtUJDQDk5Xskq7gJAIXksuay2Q0AOBOaR6X6DABwj3O9E8sEAK0wwUsKUAUAlYaTeqEnAQBt4zT6JioAACjMHi7RhAUAo+t++PPxAgBKthXldYwEAPAeB1JpWwcABlSWQm3UBQCfn5gGYXQHAOIKPDUemgEAvb2W1c1yCQCDFojfHXMIABSBT9YmBAkA2aOp2E8aBwBqJpA5vTYHAMMF+rpgdQQAoy/Mq9wYBACChs/OkVkDAGCMS6lxQwIAwyAcsUYVBAC0szSTUC0DAKpwriwQbAEARfQb1Q1yAQAhmK8vZq4FAPqHK1opEgQAs+qT4mFSDQDLZZt1JmQIAEdqEa5lAgQAvOW6BCPABgCtldG4C3YIAOnWfvWImwEAOaMEGb/NBAAsT07NSSsEANkJGXcuGgcA0lK7PhVOAQCKgebNFxoGACeIEDStPQUAtlVcxTIrAwCjR5NfFvkCAKwzvOlLswYAwPJxZWVpDAA+Qm/OYaoIAKAnG9dA+QsAadFznfGFCQDc5mJ7nBsIALLAeDpkLwcAe55PwEXeAwBc+jCN1gYHACQvjj72lgYALZLwGCwBAgApncha5VUDAAFx7BS06AMAkAxSfLCdAwDh73ebHvQGALrkhLf1igAASyzMidIUCwBNvPHiUDQKAPOSLzmTzQgAfGuUagw3CQCX/VodPEIGADMlH4jcmQQABsV2ZPJOAwCXFHTSB9EEALP9br3ERgMAoWMR13krAwBqs/zt2fgFAJA5v9zo5gEACvOKNE+XBwB8nPFOcuYGAOITvO+lgAQADCLOQuRMCQDLFiWngIkJAHZmuA34cggAbVLaHzMDBwDIkXbUMUsKAHEgYgEL5wEAaqH4tWPxAQAX1Bo0r2oFAPcw2DWWmAcAe8sAdqJ6BADD+BXA7R4EAEqF7yeNzwcA+ZNGWOOJAgCnCbNXeEoAANpN0YW1RQUA4SGz49DkBABArNLjH0UHAI2p7nj2ZgYArf5nhoU4CACMTObDLdIEAA861KBeJwcA98zXfROBBgA4mre6nOcBAGqmiUQhKgIApSsznC/2AAA5XzvWiWUEAJY/7Hn56gcAqLlyFejrBABKaWFdfxsCAHFjowH6wAEAPWqTjA4rCAAgzbZYO7gGAIAm59PYfgMAYiqf2zegCAC70rEZVAAMAP89lCK2BAYAWBp09pnIAQD7MvLiGQIGAMv5p5KuXwMAyrHzFDb6AADwgr65vf4DAAAUkpVI5wUABieCOOpTBQCMyM8kfKEFAAr0rhii+wEAlAF7PgRXBgDn6e9VG8EFAPt0oMZ7cwcAzFXjHOTqCAB19z/RNcUGAD71yPpIlAQAajXoxnRPAwCi2wcGeK0AALY+tn46IQcAhoyqrOOSAwCvNYo+6TQFAJfJAv0QiwAABR64rMJqAgB5O86YjJ0AAKxQTf4XXgIApyHxdvV/BwArcvyw+eUMAMcoDZuUbwQAJu8XXebNDACXlvgoqLsGAHb2BB7XmwAARaHyQchaAgBxOIKsfqQBABpYbMOoqAEA+6lCFHVVAgABOf6QZrwBAFq8Wi8TFAMAKNUyUYMRBgBXirSOS/IFALf29wTVWQUA/WbS9ueRCACIcwPvYGADAIYSHeyIhwkAr45HHESHAgC9VDNq6iMBANVU67N4gwMA7pSPp6rUBABNp3XoAqAEAHyxZxOFCwEA4wdYLbEaAACWLeNBkBgFADECCSsGWwAAj7fnZhfJAADsOKFVD6oAAIqRLB6WowQAHj8j80TWBwBkwAKen8YJAJdoJuXlagMAeYvT2sGPCABAvdnqzooGAKC75vjgOwQAO05h/N+PBgDgO1urHekEAPAvIcnUsQMA27E/zmvNAgAQwtfzDskEABaHgaD1lgQAuDnCjPicBwDb+GwwnMsCAI9QWw12lQUAkCcC/evLAgAFEewqgrgIAMu8JtLP0QwAvXFJ+rIVBQAVRfVdLMsCAJdjqgThvwEAJWyZ/5QUAQAAWD5iUUIGAL5E4MWf1AAAKcvtQ/oJBwDKKv1jjF0CAGH93ynNxQQABa9I68AuAwB8t/mRk48BAIEMz54CDwcAubAQXqqvCgBMJVWD4B0GAI3C431Y6wgA1Lt9n7vwBAC9dCpayk4EADM+7S6zBwMAwug8sIp0BgC8ELiaDXwFAIzpJKJkLAQAFMOm2NW3AABD1ZV7MkgEALqk44FmFAAADE7DrRSHAwAwjikOb/IEAN7HEkUicgIA/HWpQoq7CwDuF2u01fIGAOVwMSKptgcA5rfjP3FTCADBa3/9NZcBAC40xUmvkgQAVwNa31w2AgBgu/+nOCEDAP5GRtH3oQIAzESK8V0bAQBmQshC0JADAHXcjyrj7wEAOBKu516SBgAy6NCBkq8EAPgdGRH5/gAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogcBUSAC0AAACdFRIADAAAAKkVEgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc8QVEgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAAAWEgBJAAAAEgAAAA0AAAAAAAAAsKAOSicbBgCdGI/8pdUAAGAMvZxe7wcAnkyAppWFBwAd/ARIMrgCAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTIuMC4wL3NyYy9iYWNrZW5kL3NlcmlhbC91NjQvZmllbGQucnMAiBYSAHMAAABMAQAAEQAAAIgWEgBzAAAATQEAABEAAACIFhIAcwAAAE4BAAARAAAAiBYSAHMAAABPAQAAEQAAAIgWEgBzAAAAUAEAABEAAACIFhIAcwAAAFEBAAARAAAAiBYSAHMAAABSAQAAEQAAAIgWEgBzAAAAUwEAABEAAAAAAAAAcjuM9caTDAD2JcOBcd8IALZMPgsL9QgAMUykhZMyBQBLPaPT+XwIAD6RQNcFOQAAonPWFyi6AAB85vQnKD4CADQawuDSMwEAgY8p+dJPBABoqnqHBRIBAHnVk1iVeQQAoGebMGYNBQDu5b4NLdQCAMbwibYX8QYAMJfuTKiwBQDkVXHJEB0GABBqCcicBQQATwGojWB6DAAOqLnhZKEHAGXS/KToHwEAzKpPN7i8BwBPTe/0Wi8FABCN+ZhAMQUAvVV1WJGrAgCJ2NANP5MGAJVCTLuGQwQAjFBiMW3LAwDGonK4aGMCAJsr8WqCogUAILulCES8AgBCVKDd63gIACJBNRKx/woALIb1je51CwAfbhTPXJQKALrWR6TDggEA8u825WQpAgBTAFQfgpIBAFyOeJ7x+QIAtbE+56dUAQCFgiqB8dsDAJeXP7oX+gAAIDictJz2BgCNhbMNWk0DALuzluarOgQAv6NOlNBcCgBiTRq4c1YHANTA0SW5UAkAE0Ep2Tg/CQDIg5KmvmEEALEhMqqaLAcATfd0RHdnAgCFgLLpsGQAAMknO/VO8AMAMeXS1e3WAQCis7gByG0DADBek9Sn4AAAfQ3MzrfeAQAs3SBOqVMAAPmgxrH7qQcAHGOopopnBgBls9iIN+oFAHlCmdbWGwoA4uQZWeesBwDXrTjTnksLAGSAnQN+IQYAbX4zCKTeBgAGgmISwXoFAHME42XLRwYAya0fpQWcBAAbr0WQv+gEANbgRTrjFAUAD/6LWzxTBwDJFH57VYMFAAiwISAXPAcA3iqAioQADwD25cQFRuAJAPpnlxvQwAUAizhCn4jXBwDYRiWuWicEAEhDhkkCWwcAKyZwEOEuBQDNWvtUrjcCALWqOtDRvwMAXJ0CmLWKAQDpiWD9xSwDAAWblFxQJgQA0noMiBhqBADazIgYIqQEAN9TK1Jl3AMAbX8AoiLCCADtd9ubt1YLAM0S/h7oHgQAfQkHvakgCQBuNOx+/TQCAJO/fzI7AQcADWrt7W4zAQCv87uiZbUCAFUZWYnOUwIAAnbRgngmAAB4oy5zGaEAAGwqjrrxOwYAmt+QzJSfBgBI/Jt30TEEAJeg2m+6lwQAoOrPEwPMBgCZpI2EE6MJAAkjGUJTywcAYP3e3paVAwDeEn+RIh4GAAvPjEaGzQMAgcAaIlOFBABuCk5LRskGAAMEGIS6XwcABY0h1Fw7BAAWtdCbL3YCALPL3fvnxgEAveKswwlZBwDJPi2XASEEAE2uEBLWEQUAbp0Ole92BgBY8ongGrgJAIIYlSJJPAYANzKbTdXxCgCE202SJdMOAIfeIERIhgMAAoG2XbLWAgDAcyiWtFAGAJQTJ/0cCAQAgiT+5n8aBwBUyMiluIIBAI5tQOXLPwcAUfTPMDTeBQBBjKxnuVQFAO5ZZUtsdAQAK5rGbTx7BwBu+sI+8e0EAMjqe9da6AwA2XuOsqLbBwDpT+MdpckFAEcRdGTIRgUAkCYJmd+hAwC71vTJjMoBAAM7zcl/awMAXtuXNGYZAgBnDvF5z/EAAKJ+KwrLPAQAanf/34lQAACIi9PhhN0BACIIxgNFgAQAtH+jLNCeDACDeJW1wnQEAINmgY44uAUA5Gu3VMS2DAAFZVGKOVMNAHXRNjrSIQAAbUfGczP9BAAq0O4eKQ4CABByLs8uLwYA5I2FmOBxBwDfHkV40vUCAEJzmTOxMAcAdWnrIFSWBgDPFqW/owgDAFr/aB3tpQUAgw4V/ioSDQAxArtmya8EAGiCPIN4xAEAjxT8wzl4CQD4i32Jy0oEAFlzUljF4AUAXNevc1s5AwBwueSkr3IAAG0PnjIUIgYA/f41AbYZAACDSxNeFGgAAMzDggmG5AEAmdcTX/toAAB+VEQ3KMkHANJq3p/EUAEAJRFHCZXyAwDPMcq07ikHALy/dbUinAYAEuK8VwiRDACYu3WgtbIOAGio3Jw8hgEACRdaKQ53AwAT/SA3WtgAAAarcR//4AUAX+CRd22KBwB2uaBHS3AHABerGumCrgIAzQaYQtYLBQDq2I8VVYAGAFWtxP/HJQcAspnP0RVnAgCInKZBVCAKAFNLzX1CSAQAxb2K6JHRCQAey3eSzJQHAMCY0Bz3KwAAMNJszKudBACyBfkzZQoEAKS4LqzvcwUAX4VfYlTNBABTUKzCJsQGAF4JS85epgUAtmvyhkDEAACFeBlolUIHAMj8tleDAAcA7j53OCdnCABwYZ95v1IHACMz49qmtAYA3NHqlka1BwDQGoXp924IADRKWIK7nwMAA3olj1Z6BACRrR4JiE0BACTOsRhbFAIAbZ1mo5I6AQDlfVfAHHcDAFKZi7sGygMAkAPVxYELAADsgAc0EjUEAK+i+N2WwgMAE6cU2fkVBQDVVSL/kTEHAO+9pMJcTw0AzosR/FfdAwDHkDQ5nakHAEElH7suTQMAnf8jtxXoAABDVOIWtIYCAOi+0Tj+vQAAd3QAx5KoAADoo702JO0CAOqR8gD9KgAAIaPegXO+AACTsbLUUukDAC8wKC12hgIAElvjPAk2CADO6VJ1TbYLAF+EC/7gHgcA5WnJYAadBgDZqUagHS8LAL31Ls4rjgUAim+M9+iMBgCyYZLjJu4GAJ3PC6UKPQMAF289Km9oBwBqfFltphIFAFF1pXCaYAAATEY8isAmAADhOe7IH1MEANKail8wYQUAvq6S7I2XDAAAonyurWkIAFQPKSPpHgkAa5GNiUGWBgDUNT7FrgoIANXAsOcozAIA5GyK62B7BwCmd8KFKQQEAOvTRntlNgYAfMXyrqEwAACq0joAc/cBAHYPwSxkBQAApvws+Eg7AAApQ+4QPEACAGVAwsHpCwIApnOWJNiHAwAqfJLcqL4NAO8OZdWOvQUA4UDNPw7vCACr8GEzq1AHAGBeAuJK5AAAHAQnl3v5BQDs7MByNGgFAHzOsS6IiAEAfgZFxWSXBgA3EPiigzICANEjfvmvdwQAaLu8jZW4AADWreiXWyAAAHVw+7OWTwUAZpJmKQTyBQD1QUmur48IAId268SDXQkARUHKnjfPCQB0u1Kc/tcLAM0esRbGrwUA7yKP7EqfAwAu2SUWnrMDAHOIUNRb+AUAXej7OWiOBwBrhbg39y0DAAZO8UKDYAAAdUHXiXiWAwBQpfsHGSEBAIgANY8mDwcAR1+AsYNFBgDQLIOvGywKABbX1BvAMgkAjlunw/TsBACIrc9F08AHAFXz3HAgEQQAZOQinP/cBwAlM+Bg2koFAJp2747ZXAIAjJsDbOUEBACKM3iMSx8HACMrvBb8LAYAqtmAEvV8AQBaqSBerrsDAOyqYkd1DQIARbc7x2/DBwDRS3OXx6YEAA6Vs4ok7wgAxz6lyVQxDgDtPG/k8bgKAEP1uTWx/gQArpOtktE7BgD3zRKmLk4EAKuDFZn0cAYAtJCH2oqLAwBd+VHfnEoAALiW1ftj2QUASuWsaJstAgCZxTaIjqkEAKHrLLOuSQAAMXn8dQt9CABJdbrkTG8BAEm+P8DkrAUAnBUqwQ5+CgBmD1MX7pUHAH7+3GM8fQYA7hrIrfASAQBlcYJM8D0FAPAwtDNb/gIAYo0MXmYcBQCBvexSClsCAKnk/JUG3AUAfQR1xSi5AwDlhiZR8zsCAFTcSb8ZzQYAhsOvZSFhBgD/A2KjGhcBAKqoIKguZAoADz8xe7vzCQDjKXQ6G+AFAKOcF1KQYQcA0K/wk2XBAAAodFx5xGUCAEJUXVFAHAMALgu0PQ9SBwChV5PT4wsFALanlNIzqwMAs+1ZunnEBABvMk0YDcMEADzvzMmSEAcAvB0FdKzYAwCt0EP1tgoJAI/aD6zz0A0A4+VzJR3vBQB6E7dbOhcMAIyRZAM/UgAAe4pjbfWHBgAT0IqSlgcCADNPpQWE0wUAVwI9sBXqAACKIfnwMW4FAPgC4YhfYwUAuKVp2cXLAgB6NIvJ+zMFAOOkFFZW/AUAjpiQd+bhAgASSeSai+MJAFNWB7T7SAYAcs1A2PGNCgBl1Al0TCEDAOV6bcQNVwYAbeKRG5+KAQCrQj8YtjYEAJiBT6qsUAUAVMQUxBEnBgBwF2UGdIIBAGXChvJE0QQAgZLu8Ih0AQAMdlzbbJ4BALjsc0CpvgUA+NJD82POCACNNh59qOAJAOmeAbztRQgA0NAo7ZqXDgAaT5SFB60EAOSbyBIJvwUAg4zzyq0vBgAszrOWwV4CAHsBT/9VdgcAYY8UXM2qAwABgzHDNDsGALHQBC3m4AAAAWdyM6J2BgBply0Emp4CACiQHcvwrwMA8jTF9AtDBgBEclDkw2QCAHCSoxmfTAcAR7yZ94Q/BwCZvTL3+cwKAF5AIDrrxwUA+DDZqrX9BQBHjDvmV6cEAFYkl5KUjgIA0kxv6OcQAQDk9QPWntgAAPiKAQQWHgUAGCJK3O64AADQhJOLqRsFAJOWC35VXAAAsA7CibC7BgDungv7Qd8GAG/hh+2HEA0AMKefXNsCCQBgGITw/okCAG9+yR8xzgEAH9u1Pz8CBgCY/Oh1l7QHAEVQv61wrQMAmP54wVThBgC/mtb+NmMBAOz5Kblm8AQAk1tsnv/pBAC6sku8iYwBAMqVKmS/rwYAuagT+XBQDQC7K6yeYWUHAFl09CVSqwsAR1urFO1sBwABuO08CSwJAMHS9WIM3gAAtU9zzwGWBAD28GOCw7UGAAZttfU+YgQAA5UbhUvbAAAPGbgIk38EAIIfYlwjFAQAdloa9F8fAwBtuapzZ3MGADVmnHmoOgMAnmwV/Ij1CABo8KRNQWMDAOqKttlqKQcAQ64WE3HTBABYjRwMzRIKAPJcCL0e9QcA4fXjZ/osAQBq1OPxDIABAKjwX2E3QwUAIY6e8sYzAgCBxxh/ENUEAF4apdNPSgYAN7tIBM30BAAeFUOF03EGABQZkXh32wEAthpw3WlHCQBmtrTxOYMCAHvjikshqwQA/rCg7wpfCgDRF6CoLK4HAG/Ca3w5UgMAvnsioHqKAQCLX+rBjOYFAF8dejo+/gYAKm7SetkaAwBiuSAJ7RcAAP22UzvjhwEAYxR6kClYBQCSp+BI8kEGACJmOsUf7QEALS0JHKZCBgB/0RHnNxkLACFBze1L3AwA3j2LDJ9WCgCheqVk1gMFAG7yiU2O6QEAl/78Fq4QBQB8C85yERcCAII2v+2RUQUAwIvyNiuxBQA3FamQWzkDAENZvvzm+QYAD+rm6i86AgAGHwGVjHEEAB+aXmgGaQMAHXjYTzy+BACJivxqcUIKAHY8v+T0bAkAXjL3k/XSCQBbgATP3FUDAEieabjYDQEAY42P6zpGBwAzwJFuhWAHAFXgjgArzwAAS0cIJxGxBQDbdTzLTZgFAHf5z8r+6gQAe9l+WAZmAQBbxFqc2LIHAORaIntYhAUAw36mZg/BBQAKifgycpkFAIWtEy6GyAoAv+n/p0UqBgAqmEu6J14IAKZXL/FjowMAcsZ9hXdmAwBF11DdbgEGAFQEDKTtdwcAEX24j5HYAwBNhloefaYGAODHEELFGwYAtrqWP6ugBQB1R4iwNe0CAKVkTULz+AcAr4ZIsgdIAgBjT7xfiNgLALMjVT6VFQEAPdIYqdcyCQAOMaDLVecHANFOeSQ2KQYA2mHRHh7tAADDb7gP844AAGcL/35VYgMANTKcBafKAAAjMBp2Uk8EAF8Tzd7SBAEAajiZZmWRBwB+BnojcRgBALNw7ipsUwQAw7nMIfPvCwCbEfcqpIwGAP3iaC5ajAUAh/YvMO7ZAwBJpFwPXaEGAPq3nVkCowEAA9xE+AX+BgCc07o1BsQBAH8p/A3/OAIAR7pBgN+7BwDVqL8J8eEFAMERnjhEPAcAq5NwYyFeAgAbzZyXfb0FAM01QG0gXAUAJXbekK36BwBEYRw5hsIDAEafCC5nKQUAEK7tzIcSDgBw7iI5a80FADc9RLhZgQMAKi6f7NlaBQBtzwrwe3oEAAZgCs4sXAcA6XTNi/x4AgDH6zPWlKkEAAfe9/RGzwUASUSEr1A0AwBwTxj6KRQCAIirkVJhaAQAb+tM1VE4CACH5Wytv1kFAKeItK/kiQMAjKmQVvpCAgCJODUvPlIFANLvpVScCQEANO7y8woeBAAaFNc/71MHAInHWQzu6QYATomlZts2BgDe1NB7blMCAF9TPH60bAUAloQ91DAhBwBZPtF6RMwHALBZVfaMKAUACYjZ8Cm2CgDxIc7hqnwKAOvH8u/rLgkAo8Qn9y/pCAAjRV/IcCwJAJsolwrFyAUAUvZHJVBdBwCu+mOlJNoFAAdjees2CgMAZKlVtQE/BgB/djjlpb0FAEiNGSxh+gAATKaARc1UAwDqtM9JnqoEAGKrFlQWNwQAhq393fuxBQA6vPHOllwHAP4Gtn50AwYAzIwMvLXbCABxufGF6W8EAJpL5jYoCgAAJixOp5IeAgCT2kDVkc0HAKOnkTJCHgEA3cJy3EbqAwCn3+KIhQEFAP5T3eugPwAA0OecldNxAgDsSy8HNacEADL0fcqwiAAAwGz+/lQOBwAMgrKjHHUCAHXuOnyP1gQA+hGHT/1JDADt9QpwVccDAJ2qVHwzRQQAyKT5bcjPBwA6QtthbUYEAErr0Mf2vAEA4RBhVLDVBwCWBcfXljoHABNvPmBfYQcA+eOrXgOHAABqNCMLslYFAHc6S1ZcrgEAOFkCA0ytAQBBm3BLjY8CAJvvT5CKFwoAA+BzgKIxCwCRjRlBpgEKAFuNcD6G5gAAsb9UthSZAAC3lidBdtEBAA90PpgHwwMA8YqBHs/ZBQArWaHiOx0CAHvrgxhXTAUAqm6vLDEJAQBunqS8KpMFAOAfNgwKqgMAk/bfCOVfDACCsnHwwWwFAEpAHxOV3gkAre50kyOgAQAgi3APGeYDAC7vSeEhbgQAzyAtzgBKAAAEgzPCzOIBAE+uOlXYlAAAGg0jnzDuBgB3uGesMq4AACknQdiP6gEAiojotSahAwDYexK6sKUDAB1PNpjeTAYA509stoK5DgBeCLngwxgCAGzQ4j7sVA4Awqs8kZYDCAACQhTMZ5cJAFBkHwfk1gcA4eQ+6sP3AQDa4/TNPqUAAADSfnnCGAQAU7TlgBrEAgBLxZ2O4A8GALegCcPxsgYAvLvLETspAwDtp1iGV/QBABzId3u8kwMAAozNaKhnCwAmNtmtGUcHAE8UWtFKFwwAI/tc9j1LAwDTw5pZtesOAFVHP7dFhgMAN11hcwexAQDUcn3qBQMHAOKditz7MQcATsrQu87ABwC9WWAw2sUEAFNIv8zvrAQAr7eZbFqyBgBnaAIzGEYGAJSpdhGtzgcAIuZNxggeCwBCDCqSca8PAOusHCFIwAYAEw5bm25uBQDQ5E83FrgHAINHVmjbTAYA32ZYgs06AAAdykxMj7sEAJHwyeW/qAIA1xTE13MuAwDMPxEEwRsHAFIKa04Z8QEA9PFwUZB+AQDrOs6Tx7EAAPCWzuNq9QYAprT2huGjAgDvqCavZB4MAH2ZBf7aNAkAMsftuaJ0CACqkvyWvLwKAHOSHoztlgAAp6vL2sJoAACtTX6b3MsDAGrRm8bNiwYAs6/+qSf/BgApYx9hPvcBAIEtyDkQ1QAAxc7A17C4AQDSOgJwqGYEAITibVtaKwcAwzejKEYsCQCN52D0Z2wEAF5yaN7lkAwAQYwB0jWEBgDn/aZ6WkgDACDnaO10lwYAJn6V4n0pAwAmdON3AEUGAK6ctSj+swAAt5cNFqEaBgCOElV/e4oEAKbkssWwugYALS/dMCGCAwC0ePa5WaEAAI3uAwXOxgIAB5tGduYXBwAp0WM8BDwEALMz0AwpSgQAAdxUcIfTCQA4gze1wvgIAIkoY5yx3wIAsFGeSCWFAwAzW3ppSNoDAE22cnfy1AMASSbZ0XrnAAB1XNvyHTACAOPFO6MBFQIAggN1P7V2AgBcdwFwvPoGAI0lx1QezAQAnOE6a9jhCwASF6cXMI8CAJ56DORP0AgA/s/hIsM7BwAtozciTykHAI5jQ3VmwAQAf34fyYkMBwB9mNCb7aYCAKBT1+R6cgEAFHXO/fMuBgD9Pn33F4AAAMttSD4NxwMAdkd7epcJBACnG+fUXlIBAGZW0YeMkgEAKXIIZtVHCABGyRjrslYBAIumtmykOAcAOjDUqitKBQCfSdTBDq4EADAhfrValQQAYaO+nsiyBwD+rb9lsvQCAIR2OgIhGAMAj0V0F7R9BwCnfb6im8sGAHqwug+cAQMAdqwZEv9CBwDJS9JfV4cDADHaYTQbfwEAhihsAz1rCQAzQfOcfNwJAHQd6wLsBQkAyXOs49UmCQA8RD/EgooHAFLOAzSbGQQAybEc4mxPAwCEjbLUnNoFAKK9FrtoEwMAqa0TmrnZAwDEdSZwEoEDAK3A6SiNaAUA50S//7ESBwB7rdOcIsgBALuBvQiStAAAbwcNCvtQBQB/wNod0y0OALQjqyNgAgwANszJsWAkCgBQLdpkCuQLAEFyKC2z3AIAtyaYsJK4BgBd9Ow5YKMFAHl+CdbDkAIAKB8ue+5XAQCfcMqdLqUFAP6yl//neAMAQouUVP64BAB4e9etD1oHAPtVXBF3ogUAQkyF5SHZCABnTzbG+w0HAOzxnLi5SAgAJii3sfG5DgDSLYmR4fQIAMwAgzIVMAIAYlX49LD6BwAd+yHD47YBAKy+FpwndwcA3xerAptoBADtMkHsEhwFAHe4t1YkGwMAgdGHUx7CBQAvykl6wxMDAN2evC5DsgMA3NjHgZeJCADfAoUx5w0JAGetkL4Y2wgAG7EVEdpgCACMMjAT/WELAFkujLfCzAYAd7eSLzgGBwDcZDf0WAIHAPYEmv/G3AUA27IqH1zFBgCGmRVlgQwDAEWa6KH4LgIA5FziEhHoAwBqC7SsWEMCACx7klqEzQMAzFEZLNcGDQBdov4FH70MAMyo79c5bggAI1FYtapWCQB+JMeKmV8MALDTb9+tFQcAouPW6xrPBwCpyAFxGzkAAGmrNauHaAUAkdqg6CFhAwDNPl3FKAcDAIH0ZirNiAEADYVbOzNRAQC5amGj/40BANVm8GwIOwIAfNW9tIBgBgCsMUaXxjAJAI/y9ebwsgQAgJoif6IKAwDxFJChX2wJAF4ZBeoYUQMAbbggLfhGAABFUcfKPEoDAJaEwhl1OgUA6MaIU7seAAA79XLnbkEFAOihEp1zuQAA4z8mQxxYAgCr4ZT+VygAAHOEgfFOhgQAHbjQCzqoBQChGYWGI3cLAK07GdL7VAgAgU2fN3MoCQC79teuA2wKALOaY5cywwcAAt9xGg1kBQAeH9E88IgFAB3EJWAutgcAuk3DwK2nAgDOfRxYL3oGAMOyLTUFCQQAJXrq8JAmBgDcPaVsSKoDAB2elWlRiwcALcxpV1rIBAArf2W66UoHAFT6m9ugGgYAKgvF5Q7aCADRvCQC7FcMAA0YXd9UggEAH6KMOp3/AABUGNR9xDkCAKQalauThAMAHjeQvBQjAACKkCaP/q4AAD1vWqdqvwMAzO5a6DsTAgB1m7zF3SQFAPD8NMVylQcAl5V04ABDCwCGhpiADHIMAJfcfJEmIwIAy1X7SQoOBQAZf24LDIkHAG8tW6M8sgUAcyQ3mCVXBwA2KOwSqFsGAAbEmxmCnwcADraYjd8NBwDEXdf9t0ABAJJ+0wJfCwMADsyOFhLSAgD2GHGsFVUAAKeJHmlpVwQArUOmW9w9BgAhZ20jNz0DAPtzIUJ2ngkAKgg610U8DgDGBWtwD+wCANstWzQF4wMAnGpzXYC9BgAwpx71hVcFAO73rhEBwQYAwQEvI3QLAQDYWY9glBYCAIefj6HH9wMAuDclwlE4AQAVN1soyFMDAPSjJZ361gUAyqajsv5aDACEtcwBvvMAALSzmbZyfgoAC/tlJgOOCwCdfIhB+nQNALtsbuSFQQcA20jKR+QlAAAwp6kYmfQFAPr7+r88vQQA9nX3BOdFBgD6Hone2ikFACUZ+9xFogUAz+k8RFQ4BQAUwawaeZkEAKvKTVcOQgcACUsjlD9uBgAHH4JDaNMEAIftIZdSEQcASdiZpaI6CADbPJz6YLoKADxRNKA4oQYA7L5zOt/oBQCAmD+YkhsFAMaAHFeU6QEAG1grY/ROBADJZNMhHEkGAHq0REmkjAUA7mgXXXIcAADg7Ih6q+cBAF9LxJlIBQcAo3hZE8pNAwC9bhU7KKgBACnAAWCi5wUAuzygY8Y5BwD/tuLONiAFAFnxsiaUmwYAet0qdlBQAwBSgAPARM8DAHd5QMeMcwYA/23FnW1AAgAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvY3VydmUyNTUxOS1kYWxlay0yLjAuMC9zcmMvYmFja2VuZC9zZXJpYWwvdTY0L3NjYWxhci5yc9A1EgB0AAAAKQAAAAoAAADQNRIAdAAAAC8AAAAOAAAA0DUSAHQAAABEAAAAHgAAANA1EgB0AAAAWgAAAB4AAAAAAAAA7eYhZ71IDwBa5GestboDABvlNev//w8A////////DwD//////w8AADvRUull0gkAn6a+FcdjDQAEdmjLZb4FAH8hPcfu3AMAmjB8G0EJAADt0/VcGmMCAIFlzXkv6g0A+d4UAEH97cgAC44BEAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2N1cnZlMjU1MTktZGFsZWstMi4wLjAvc3JjL3NjYWxhci5ycwAAAAA3EgBhAAAAFwEAAAoAAAAAAAAA7dP1XBpjAgCBZc15L+oNAPneFABBne/IAAu0BBAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9jdXJ2ZTI1NTE5LWRhbGVrLTIuMC4wL3NyYy93aW5kb3cucnMAAACgNxIAYQAAAH8AAAAJAAAAoDcSAGEAAACqAAAACQAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL3N0ci9wYXR0ZXJuLnJzAAAkOBIASgAAAIIEAAAUAAAAJDgSAEoAAACCBAAAIQAAACQ4EgBKAAAAjgQAABQAAAAkOBIASgAAAI4EAAAhAAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvc2xpY2UvbW9kLnJzsDgSAEgAAAAmCwAACgAAACAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvaG1hYy0wLjcuMC9zcmMvbGliLnJzAAk5EgBSAAAAdgAAABEAAAAJORIAUgAAAHcAAAARAAAACTkSAFIAAACBAAAAKAAAAAk5EgBSAAAAgQAAABEAAAAJORIAUgAAAIIAAAAeAAAACTkSAFIAAACCAAAAEQAAADIAAAAMAAAABAAAADMAAAA0AAAANQBB5PPIAAu5mwE2AAAANwAAADgAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9zbGljZS9tb2QucnPwORIASAAAACYLAAAKAAAASGFzaCB0YWJsZSBjYXBhY2l0eSBvdmVyZmxvdzw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAZDoSAB4AAAACAAAAAgAAAP////85AAAABAAAAAQAAAA6AAAAOwAAADwAAAAEAAAABAAAAD0AAAA+AAAAY2FsbGVkIGBPcHRpb246OnVud3JhcCgpYCBvbiBhIGBOb25lYCB2YWx1ZS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9vbmNlX2NlbGwtMC4xLjgvc3JjL2ltcF9wbC5ycwAAAOs6EgBaAAAAhwAAAAkAAABhYmFuZG9uCmFiaWxpdHkKYWJsZQphYm91dAphYm92ZQphYnNlbnQKYWJzb3JiCmFic3RyYWN0CmFic3VyZAphYnVzZQphY2Nlc3MKYWNjaWRlbnQKYWNjb3VudAphY2N1c2UKYWNoaWV2ZQphY2lkCmFjb3VzdGljCmFjcXVpcmUKYWNyb3NzCmFjdAphY3Rpb24KYWN0b3IKYWN0cmVzcwphY3R1YWwKYWRhcHQKYWRkCmFkZGljdAphZGRyZXNzCmFkanVzdAphZG1pdAphZHVsdAphZHZhbmNlCmFkdmljZQphZXJvYmljCmFmZmFpcgphZmZvcmQKYWZyYWlkCmFnYWluCmFnZQphZ2VudAphZ3JlZQphaGVhZAphaW0KYWlyCmFpcnBvcnQKYWlzbGUKYWxhcm0KYWxidW0KYWxjb2hvbAphbGVydAphbGllbgphbGwKYWxsZXkKYWxsb3cKYWxtb3N0CmFsb25lCmFscGhhCmFscmVhZHkKYWxzbwphbHRlcgphbHdheXMKYW1hdGV1cgphbWF6aW5nCmFtb25nCmFtb3VudAphbXVzZWQKYW5hbHlzdAphbmNob3IKYW5jaWVudAphbmdlcgphbmdsZQphbmdyeQphbmltYWwKYW5rbGUKYW5ub3VuY2UKYW5udWFsCmFub3RoZXIKYW5zd2VyCmFudGVubmEKYW50aXF1ZQphbnhpZXR5CmFueQphcGFydAphcG9sb2d5CmFwcGVhcgphcHBsZQphcHByb3ZlCmFwcmlsCmFyY2gKYXJjdGljCmFyZWEKYXJlbmEKYXJndWUKYXJtCmFybWVkCmFybW9yCmFybXkKYXJvdW5kCmFycmFuZ2UKYXJyZXN0CmFycml2ZQphcnJvdwphcnQKYXJ0ZWZhY3QKYXJ0aXN0CmFydHdvcmsKYXNrCmFzcGVjdAphc3NhdWx0CmFzc2V0CmFzc2lzdAphc3N1bWUKYXN0aG1hCmF0aGxldGUKYXRvbQphdHRhY2sKYXR0ZW5kCmF0dGl0dWRlCmF0dHJhY3QKYXVjdGlvbgphdWRpdAphdWd1c3QKYXVudAphdXRob3IKYXV0bwphdXR1bW4KYXZlcmFnZQphdm9jYWRvCmF2b2lkCmF3YWtlCmF3YXJlCmF3YXkKYXdlc29tZQphd2Z1bAphd2t3YXJkCmF4aXMKYmFieQpiYWNoZWxvcgpiYWNvbgpiYWRnZQpiYWcKYmFsYW5jZQpiYWxjb255CmJhbGwKYmFtYm9vCmJhbmFuYQpiYW5uZXIKYmFyCmJhcmVseQpiYXJnYWluCmJhcnJlbApiYXNlCmJhc2ljCmJhc2tldApiYXR0bGUKYmVhY2gKYmVhbgpiZWF1dHkKYmVjYXVzZQpiZWNvbWUKYmVlZgpiZWZvcmUKYmVnaW4KYmVoYXZlCmJlaGluZApiZWxpZXZlCmJlbG93CmJlbHQKYmVuY2gKYmVuZWZpdApiZXN0CmJldHJheQpiZXR0ZXIKYmV0d2VlbgpiZXlvbmQKYmljeWNsZQpiaWQKYmlrZQpiaW5kCmJpb2xvZ3kKYmlyZApiaXJ0aApiaXR0ZXIKYmxhY2sKYmxhZGUKYmxhbWUKYmxhbmtldApibGFzdApibGVhawpibGVzcwpibGluZApibG9vZApibG9zc29tCmJsb3VzZQpibHVlCmJsdXIKYmx1c2gKYm9hcmQKYm9hdApib2R5CmJvaWwKYm9tYgpib25lCmJvbnVzCmJvb2sKYm9vc3QKYm9yZGVyCmJvcmluZwpib3Jyb3cKYm9zcwpib3R0b20KYm91bmNlCmJveApib3kKYnJhY2tldApicmFpbgpicmFuZApicmFzcwpicmF2ZQpicmVhZApicmVlemUKYnJpY2sKYnJpZGdlCmJyaWVmCmJyaWdodApicmluZwpicmlzawpicm9jY29saQpicm9rZW4KYnJvbnplCmJyb29tCmJyb3RoZXIKYnJvd24KYnJ1c2gKYnViYmxlCmJ1ZGR5CmJ1ZGdldApidWZmYWxvCmJ1aWxkCmJ1bGIKYnVsawpidWxsZXQKYnVuZGxlCmJ1bmtlcgpidXJkZW4KYnVyZ2VyCmJ1cnN0CmJ1cwpidXNpbmVzcwpidXN5CmJ1dHRlcgpidXllcgpidXp6CmNhYmJhZ2UKY2FiaW4KY2FibGUKY2FjdHVzCmNhZ2UKY2FrZQpjYWxsCmNhbG0KY2FtZXJhCmNhbXAKY2FuCmNhbmFsCmNhbmNlbApjYW5keQpjYW5ub24KY2Fub2UKY2FudmFzCmNhbnlvbgpjYXBhYmxlCmNhcGl0YWwKY2FwdGFpbgpjYXIKY2FyYm9uCmNhcmQKY2FyZ28KY2FycGV0CmNhcnJ5CmNhcnQKY2FzZQpjYXNoCmNhc2lubwpjYXN0bGUKY2FzdWFsCmNhdApjYXRhbG9nCmNhdGNoCmNhdGVnb3J5CmNhdHRsZQpjYXVnaHQKY2F1c2UKY2F1dGlvbgpjYXZlCmNlaWxpbmcKY2VsZXJ5CmNlbWVudApjZW5zdXMKY2VudHVyeQpjZXJlYWwKY2VydGFpbgpjaGFpcgpjaGFsawpjaGFtcGlvbgpjaGFuZ2UKY2hhb3MKY2hhcHRlcgpjaGFyZ2UKY2hhc2UKY2hhdApjaGVhcApjaGVjawpjaGVlc2UKY2hlZgpjaGVycnkKY2hlc3QKY2hpY2tlbgpjaGllZgpjaGlsZApjaGltbmV5CmNob2ljZQpjaG9vc2UKY2hyb25pYwpjaHVja2xlCmNodW5rCmNodXJuCmNpZ2FyCmNpbm5hbW9uCmNpcmNsZQpjaXRpemVuCmNpdHkKY2l2aWwKY2xhaW0KY2xhcApjbGFyaWZ5CmNsYXcKY2xheQpjbGVhbgpjbGVyawpjbGV2ZXIKY2xpY2sKY2xpZW50CmNsaWZmCmNsaW1iCmNsaW5pYwpjbGlwCmNsb2NrCmNsb2cKY2xvc2UKY2xvdGgKY2xvdWQKY2xvd24KY2x1YgpjbHVtcApjbHVzdGVyCmNsdXRjaApjb2FjaApjb2FzdApjb2NvbnV0CmNvZGUKY29mZmVlCmNvaWwKY29pbgpjb2xsZWN0CmNvbG9yCmNvbHVtbgpjb21iaW5lCmNvbWUKY29tZm9ydApjb21pYwpjb21tb24KY29tcGFueQpjb25jZXJ0CmNvbmR1Y3QKY29uZmlybQpjb25ncmVzcwpjb25uZWN0CmNvbnNpZGVyCmNvbnRyb2wKY29udmluY2UKY29vawpjb29sCmNvcHBlcgpjb3B5CmNvcmFsCmNvcmUKY29ybgpjb3JyZWN0CmNvc3QKY290dG9uCmNvdWNoCmNvdW50cnkKY291cGxlCmNvdXJzZQpjb3VzaW4KY292ZXIKY295b3RlCmNyYWNrCmNyYWRsZQpjcmFmdApjcmFtCmNyYW5lCmNyYXNoCmNyYXRlcgpjcmF3bApjcmF6eQpjcmVhbQpjcmVkaXQKY3JlZWsKY3Jldwpjcmlja2V0CmNyaW1lCmNyaXNwCmNyaXRpYwpjcm9wCmNyb3NzCmNyb3VjaApjcm93ZApjcnVjaWFsCmNydWVsCmNydWlzZQpjcnVtYmxlCmNydW5jaApjcnVzaApjcnkKY3J5c3RhbApjdWJlCmN1bHR1cmUKY3VwCmN1cGJvYXJkCmN1cmlvdXMKY3VycmVudApjdXJ0YWluCmN1cnZlCmN1c2hpb24KY3VzdG9tCmN1dGUKY3ljbGUKZGFkCmRhbWFnZQpkYW1wCmRhbmNlCmRhbmdlcgpkYXJpbmcKZGFzaApkYXVnaHRlcgpkYXduCmRheQpkZWFsCmRlYmF0ZQpkZWJyaXMKZGVjYWRlCmRlY2VtYmVyCmRlY2lkZQpkZWNsaW5lCmRlY29yYXRlCmRlY3JlYXNlCmRlZXIKZGVmZW5zZQpkZWZpbmUKZGVmeQpkZWdyZWUKZGVsYXkKZGVsaXZlcgpkZW1hbmQKZGVtaXNlCmRlbmlhbApkZW50aXN0CmRlbnkKZGVwYXJ0CmRlcGVuZApkZXBvc2l0CmRlcHRoCmRlcHV0eQpkZXJpdmUKZGVzY3JpYmUKZGVzZXJ0CmRlc2lnbgpkZXNrCmRlc3BhaXIKZGVzdHJveQpkZXRhaWwKZGV0ZWN0CmRldmVsb3AKZGV2aWNlCmRldm90ZQpkaWFncmFtCmRpYWwKZGlhbW9uZApkaWFyeQpkaWNlCmRpZXNlbApkaWV0CmRpZmZlcgpkaWdpdGFsCmRpZ25pdHkKZGlsZW1tYQpkaW5uZXIKZGlub3NhdXIKZGlyZWN0CmRpcnQKZGlzYWdyZWUKZGlzY292ZXIKZGlzZWFzZQpkaXNoCmRpc21pc3MKZGlzb3JkZXIKZGlzcGxheQpkaXN0YW5jZQpkaXZlcnQKZGl2aWRlCmRpdm9yY2UKZGl6enkKZG9jdG9yCmRvY3VtZW50CmRvZwpkb2xsCmRvbHBoaW4KZG9tYWluCmRvbmF0ZQpkb25rZXkKZG9ub3IKZG9vcgpkb3NlCmRvdWJsZQpkb3ZlCmRyYWZ0CmRyYWdvbgpkcmFtYQpkcmFzdGljCmRyYXcKZHJlYW0KZHJlc3MKZHJpZnQKZHJpbGwKZHJpbmsKZHJpcApkcml2ZQpkcm9wCmRydW0KZHJ5CmR1Y2sKZHVtYgpkdW5lCmR1cmluZwpkdXN0CmR1dGNoCmR1dHkKZHdhcmYKZHluYW1pYwplYWdlcgplYWdsZQplYXJseQplYXJuCmVhcnRoCmVhc2lseQplYXN0CmVhc3kKZWNobwplY29sb2d5CmVjb25vbXkKZWRnZQplZGl0CmVkdWNhdGUKZWZmb3J0CmVnZwplaWdodAplaXRoZXIKZWxib3cKZWxkZXIKZWxlY3RyaWMKZWxlZ2FudAplbGVtZW50CmVsZXBoYW50CmVsZXZhdG9yCmVsaXRlCmVsc2UKZW1iYXJrCmVtYm9keQplbWJyYWNlCmVtZXJnZQplbW90aW9uCmVtcGxveQplbXBvd2VyCmVtcHR5CmVuYWJsZQplbmFjdAplbmQKZW5kbGVzcwplbmRvcnNlCmVuZW15CmVuZXJneQplbmZvcmNlCmVuZ2FnZQplbmdpbmUKZW5oYW5jZQplbmpveQplbmxpc3QKZW5vdWdoCmVucmljaAplbnJvbGwKZW5zdXJlCmVudGVyCmVudGlyZQplbnRyeQplbnZlbG9wZQplcGlzb2RlCmVxdWFsCmVxdWlwCmVyYQplcmFzZQplcm9kZQplcm9zaW9uCmVycm9yCmVydXB0CmVzY2FwZQplc3NheQplc3NlbmNlCmVzdGF0ZQpldGVybmFsCmV0aGljcwpldmlkZW5jZQpldmlsCmV2b2tlCmV2b2x2ZQpleGFjdApleGFtcGxlCmV4Y2VzcwpleGNoYW5nZQpleGNpdGUKZXhjbHVkZQpleGN1c2UKZXhlY3V0ZQpleGVyY2lzZQpleGhhdXN0CmV4aGliaXQKZXhpbGUKZXhpc3QKZXhpdApleG90aWMKZXhwYW5kCmV4cGVjdApleHBpcmUKZXhwbGFpbgpleHBvc2UKZXhwcmVzcwpleHRlbmQKZXh0cmEKZXllCmV5ZWJyb3cKZmFicmljCmZhY2UKZmFjdWx0eQpmYWRlCmZhaW50CmZhaXRoCmZhbGwKZmFsc2UKZmFtZQpmYW1pbHkKZmFtb3VzCmZhbgpmYW5jeQpmYW50YXN5CmZhcm0KZmFzaGlvbgpmYXQKZmF0YWwKZmF0aGVyCmZhdGlndWUKZmF1bHQKZmF2b3JpdGUKZmVhdHVyZQpmZWJydWFyeQpmZWRlcmFsCmZlZQpmZWVkCmZlZWwKZmVtYWxlCmZlbmNlCmZlc3RpdmFsCmZldGNoCmZldmVyCmZldwpmaWJlcgpmaWN0aW9uCmZpZWxkCmZpZ3VyZQpmaWxlCmZpbG0KZmlsdGVyCmZpbmFsCmZpbmQKZmluZQpmaW5nZXIKZmluaXNoCmZpcmUKZmlybQpmaXJzdApmaXNjYWwKZmlzaApmaXQKZml0bmVzcwpmaXgKZmxhZwpmbGFtZQpmbGFzaApmbGF0CmZsYXZvcgpmbGVlCmZsaWdodApmbGlwCmZsb2F0CmZsb2NrCmZsb29yCmZsb3dlcgpmbHVpZApmbHVzaApmbHkKZm9hbQpmb2N1cwpmb2cKZm9pbApmb2xkCmZvbGxvdwpmb29kCmZvb3QKZm9yY2UKZm9yZXN0CmZvcmdldApmb3JrCmZvcnR1bmUKZm9ydW0KZm9yd2FyZApmb3NzaWwKZm9zdGVyCmZvdW5kCmZveApmcmFnaWxlCmZyYW1lCmZyZXF1ZW50CmZyZXNoCmZyaWVuZApmcmluZ2UKZnJvZwpmcm9udApmcm9zdApmcm93bgpmcm96ZW4KZnJ1aXQKZnVlbApmdW4KZnVubnkKZnVybmFjZQpmdXJ5CmZ1dHVyZQpnYWRnZXQKZ2FpbgpnYWxheHkKZ2FsbGVyeQpnYW1lCmdhcApnYXJhZ2UKZ2FyYmFnZQpnYXJkZW4KZ2FybGljCmdhcm1lbnQKZ2FzCmdhc3AKZ2F0ZQpnYXRoZXIKZ2F1Z2UKZ2F6ZQpnZW5lcmFsCmdlbml1cwpnZW5yZQpnZW50bGUKZ2VudWluZQpnZXN0dXJlCmdob3N0CmdpYW50CmdpZnQKZ2lnZ2xlCmdpbmdlcgpnaXJhZmZlCmdpcmwKZ2l2ZQpnbGFkCmdsYW5jZQpnbGFyZQpnbGFzcwpnbGlkZQpnbGltcHNlCmdsb2JlCmdsb29tCmdsb3J5Cmdsb3ZlCmdsb3cKZ2x1ZQpnb2F0CmdvZGRlc3MKZ29sZApnb29kCmdvb3NlCmdvcmlsbGEKZ29zcGVsCmdvc3NpcApnb3Zlcm4KZ293bgpncmFiCmdyYWNlCmdyYWluCmdyYW50CmdyYXBlCmdyYXNzCmdyYXZpdHkKZ3JlYXQKZ3JlZW4KZ3JpZApncmllZgpncml0Cmdyb2NlcnkKZ3JvdXAKZ3JvdwpncnVudApndWFyZApndWVzcwpndWlkZQpndWlsdApndWl0YXIKZ3VuCmd5bQpoYWJpdApoYWlyCmhhbGYKaGFtbWVyCmhhbXN0ZXIKaGFuZApoYXBweQpoYXJib3IKaGFyZApoYXJzaApoYXJ2ZXN0CmhhdApoYXZlCmhhd2sKaGF6YXJkCmhlYWQKaGVhbHRoCmhlYXJ0CmhlYXZ5CmhlZGdlaG9nCmhlaWdodApoZWxsbwpoZWxtZXQKaGVscApoZW4KaGVybwpoaWRkZW4KaGlnaApoaWxsCmhpbnQKaGlwCmhpcmUKaGlzdG9yeQpob2JieQpob2NrZXkKaG9sZApob2xlCmhvbGlkYXkKaG9sbG93CmhvbWUKaG9uZXkKaG9vZApob3BlCmhvcm4KaG9ycm9yCmhvcnNlCmhvc3BpdGFsCmhvc3QKaG90ZWwKaG91cgpob3ZlcgpodWIKaHVnZQpodW1hbgpodW1ibGUKaHVtb3IKaHVuZHJlZApodW5ncnkKaHVudApodXJkbGUKaHVycnkKaHVydApodXNiYW5kCmh5YnJpZAppY2UKaWNvbgppZGVhCmlkZW50aWZ5CmlkbGUKaWdub3JlCmlsbAppbGxlZ2FsCmlsbG5lc3MKaW1hZ2UKaW1pdGF0ZQppbW1lbnNlCmltbXVuZQppbXBhY3QKaW1wb3NlCmltcHJvdmUKaW1wdWxzZQppbmNoCmluY2x1ZGUKaW5jb21lCmluY3JlYXNlCmluZGV4CmluZGljYXRlCmluZG9vcgppbmR1c3RyeQppbmZhbnQKaW5mbGljdAppbmZvcm0KaW5oYWxlCmluaGVyaXQKaW5pdGlhbAppbmplY3QKaW5qdXJ5CmlubWF0ZQppbm5lcgppbm5vY2VudAppbnB1dAppbnF1aXJ5Cmluc2FuZQppbnNlY3QKaW5zaWRlCmluc3BpcmUKaW5zdGFsbAppbnRhY3QKaW50ZXJlc3QKaW50bwppbnZlc3QKaW52aXRlCmludm9sdmUKaXJvbgppc2xhbmQKaXNvbGF0ZQppc3N1ZQppdGVtCml2b3J5CmphY2tldApqYWd1YXIKamFyCmphenoKamVhbG91cwpqZWFucwpqZWxseQpqZXdlbApqb2IKam9pbgpqb2tlCmpvdXJuZXkKam95Cmp1ZGdlCmp1aWNlCmp1bXAKanVuZ2xlCmp1bmlvcgpqdW5rCmp1c3QKa2FuZ2Fyb28Ka2VlbgprZWVwCmtldGNodXAKa2V5CmtpY2sKa2lkCmtpZG5leQpraW5kCmtpbmdkb20Ka2lzcwpraXQKa2l0Y2hlbgpraXRlCmtpdHRlbgpraXdpCmtuZWUKa25pZmUKa25vY2sKa25vdwpsYWIKbGFiZWwKbGFib3IKbGFkZGVyCmxhZHkKbGFrZQpsYW1wCmxhbmd1YWdlCmxhcHRvcApsYXJnZQpsYXRlcgpsYXRpbgpsYXVnaApsYXVuZHJ5CmxhdmEKbGF3Cmxhd24KbGF3c3VpdApsYXllcgpsYXp5CmxlYWRlcgpsZWFmCmxlYXJuCmxlYXZlCmxlY3R1cmUKbGVmdApsZWcKbGVnYWwKbGVnZW5kCmxlaXN1cmUKbGVtb24KbGVuZApsZW5ndGgKbGVucwpsZW9wYXJkCmxlc3NvbgpsZXR0ZXIKbGV2ZWwKbGlhcgpsaWJlcnR5CmxpYnJhcnkKbGljZW5zZQpsaWZlCmxpZnQKbGlnaHQKbGlrZQpsaW1iCmxpbWl0CmxpbmsKbGlvbgpsaXF1aWQKbGlzdApsaXR0bGUKbGl2ZQpsaXphcmQKbG9hZApsb2FuCmxvYnN0ZXIKbG9jYWwKbG9jawpsb2dpYwpsb25lbHkKbG9uZwpsb29wCmxvdHRlcnkKbG91ZApsb3VuZ2UKbG92ZQpsb3lhbApsdWNreQpsdWdnYWdlCmx1bWJlcgpsdW5hcgpsdW5jaApsdXh1cnkKbHlyaWNzCm1hY2hpbmUKbWFkCm1hZ2ljCm1hZ25ldAptYWlkCm1haWwKbWFpbgptYWpvcgptYWtlCm1hbW1hbAptYW4KbWFuYWdlCm1hbmRhdGUKbWFuZ28KbWFuc2lvbgptYW51YWwKbWFwbGUKbWFyYmxlCm1hcmNoCm1hcmdpbgptYXJpbmUKbWFya2V0Cm1hcnJpYWdlCm1hc2sKbWFzcwptYXN0ZXIKbWF0Y2gKbWF0ZXJpYWwKbWF0aAptYXRyaXgKbWF0dGVyCm1heGltdW0KbWF6ZQptZWFkb3cKbWVhbgptZWFzdXJlCm1lYXQKbWVjaGFuaWMKbWVkYWwKbWVkaWEKbWVsb2R5Cm1lbHQKbWVtYmVyCm1lbW9yeQptZW50aW9uCm1lbnUKbWVyY3kKbWVyZ2UKbWVyaXQKbWVycnkKbWVzaAptZXNzYWdlCm1ldGFsCm1ldGhvZAptaWRkbGUKbWlkbmlnaHQKbWlsawptaWxsaW9uCm1pbWljCm1pbmQKbWluaW11bQptaW5vcgptaW51dGUKbWlyYWNsZQptaXJyb3IKbWlzZXJ5Cm1pc3MKbWlzdGFrZQptaXgKbWl4ZWQKbWl4dHVyZQptb2JpbGUKbW9kZWwKbW9kaWZ5Cm1vbQptb21lbnQKbW9uaXRvcgptb25rZXkKbW9uc3Rlcgptb250aAptb29uCm1vcmFsCm1vcmUKbW9ybmluZwptb3NxdWl0bwptb3RoZXIKbW90aW9uCm1vdG9yCm1vdW50YWluCm1vdXNlCm1vdmUKbW92aWUKbXVjaAptdWZmaW4KbXVsZQptdWx0aXBseQptdXNjbGUKbXVzZXVtCm11c2hyb29tCm11c2ljCm11c3QKbXV0dWFsCm15c2VsZgpteXN0ZXJ5Cm15dGgKbmFpdmUKbmFtZQpuYXBraW4KbmFycm93Cm5hc3R5Cm5hdGlvbgpuYXR1cmUKbmVhcgpuZWNrCm5lZWQKbmVnYXRpdmUKbmVnbGVjdApuZWl0aGVyCm5lcGhldwpuZXJ2ZQpuZXN0Cm5ldApuZXR3b3JrCm5ldXRyYWwKbmV2ZXIKbmV3cwpuZXh0Cm5pY2UKbmlnaHQKbm9ibGUKbm9pc2UKbm9taW5lZQpub29kbGUKbm9ybWFsCm5vcnRoCm5vc2UKbm90YWJsZQpub3RlCm5vdGhpbmcKbm90aWNlCm5vdmVsCm5vdwpudWNsZWFyCm51bWJlcgpudXJzZQpudXQKb2FrCm9iZXkKb2JqZWN0Cm9ibGlnZQpvYnNjdXJlCm9ic2VydmUKb2J0YWluCm9idmlvdXMKb2NjdXIKb2NlYW4Kb2N0b2JlcgpvZG9yCm9mZgpvZmZlcgpvZmZpY2UKb2Z0ZW4Kb2lsCm9rYXkKb2xkCm9saXZlCm9seW1waWMKb21pdApvbmNlCm9uZQpvbmlvbgpvbmxpbmUKb25seQpvcGVuCm9wZXJhCm9waW5pb24Kb3Bwb3NlCm9wdGlvbgpvcmFuZ2UKb3JiaXQKb3JjaGFyZApvcmRlcgpvcmRpbmFyeQpvcmdhbgpvcmllbnQKb3JpZ2luYWwKb3JwaGFuCm9zdHJpY2gKb3RoZXIKb3V0ZG9vcgpvdXRlcgpvdXRwdXQKb3V0c2lkZQpvdmFsCm92ZW4Kb3Zlcgpvd24Kb3duZXIKb3h5Z2VuCm95c3Rlcgpvem9uZQpwYWN0CnBhZGRsZQpwYWdlCnBhaXIKcGFsYWNlCnBhbG0KcGFuZGEKcGFuZWwKcGFuaWMKcGFudGhlcgpwYXBlcgpwYXJhZGUKcGFyZW50CnBhcmsKcGFycm90CnBhcnR5CnBhc3MKcGF0Y2gKcGF0aApwYXRpZW50CnBhdHJvbApwYXR0ZXJuCnBhdXNlCnBhdmUKcGF5bWVudApwZWFjZQpwZWFudXQKcGVhcgpwZWFzYW50CnBlbGljYW4KcGVuCnBlbmFsdHkKcGVuY2lsCnBlb3BsZQpwZXBwZXIKcGVyZmVjdApwZXJtaXQKcGVyc29uCnBldApwaG9uZQpwaG90bwpwaHJhc2UKcGh5c2ljYWwKcGlhbm8KcGljbmljCnBpY3R1cmUKcGllY2UKcGlnCnBpZ2VvbgpwaWxsCnBpbG90CnBpbmsKcGlvbmVlcgpwaXBlCnBpc3RvbApwaXRjaApwaXp6YQpwbGFjZQpwbGFuZXQKcGxhc3RpYwpwbGF0ZQpwbGF5CnBsZWFzZQpwbGVkZ2UKcGx1Y2sKcGx1ZwpwbHVuZ2UKcG9lbQpwb2V0CnBvaW50CnBvbGFyCnBvbGUKcG9saWNlCnBvbmQKcG9ueQpwb29sCnBvcHVsYXIKcG9ydGlvbgpwb3NpdGlvbgpwb3NzaWJsZQpwb3N0CnBvdGF0bwpwb3R0ZXJ5CnBvdmVydHkKcG93ZGVyCnBvd2VyCnByYWN0aWNlCnByYWlzZQpwcmVkaWN0CnByZWZlcgpwcmVwYXJlCnByZXNlbnQKcHJldHR5CnByZXZlbnQKcHJpY2UKcHJpZGUKcHJpbWFyeQpwcmludApwcmlvcml0eQpwcmlzb24KcHJpdmF0ZQpwcml6ZQpwcm9ibGVtCnByb2Nlc3MKcHJvZHVjZQpwcm9maXQKcHJvZ3JhbQpwcm9qZWN0CnByb21vdGUKcHJvb2YKcHJvcGVydHkKcHJvc3Blcgpwcm90ZWN0CnByb3VkCnByb3ZpZGUKcHVibGljCnB1ZGRpbmcKcHVsbApwdWxwCnB1bHNlCnB1bXBraW4KcHVuY2gKcHVwaWwKcHVwcHkKcHVyY2hhc2UKcHVyaXR5CnB1cnBvc2UKcHVyc2UKcHVzaApwdXQKcHV6emxlCnB5cmFtaWQKcXVhbGl0eQpxdWFudHVtCnF1YXJ0ZXIKcXVlc3Rpb24KcXVpY2sKcXVpdApxdWl6CnF1b3RlCnJhYmJpdApyYWNjb29uCnJhY2UKcmFjawpyYWRhcgpyYWRpbwpyYWlsCnJhaW4KcmFpc2UKcmFsbHkKcmFtcApyYW5jaApyYW5kb20KcmFuZ2UKcmFwaWQKcmFyZQpyYXRlCnJhdGhlcgpyYXZlbgpyYXcKcmF6b3IKcmVhZHkKcmVhbApyZWFzb24KcmViZWwKcmVidWlsZApyZWNhbGwKcmVjZWl2ZQpyZWNpcGUKcmVjb3JkCnJlY3ljbGUKcmVkdWNlCnJlZmxlY3QKcmVmb3JtCnJlZnVzZQpyZWdpb24KcmVncmV0CnJlZ3VsYXIKcmVqZWN0CnJlbGF4CnJlbGVhc2UKcmVsaWVmCnJlbHkKcmVtYWluCnJlbWVtYmVyCnJlbWluZApyZW1vdmUKcmVuZGVyCnJlbmV3CnJlbnQKcmVvcGVuCnJlcGFpcgpyZXBlYXQKcmVwbGFjZQpyZXBvcnQKcmVxdWlyZQpyZXNjdWUKcmVzZW1ibGUKcmVzaXN0CnJlc291cmNlCnJlc3BvbnNlCnJlc3VsdApyZXRpcmUKcmV0cmVhdApyZXR1cm4KcmV1bmlvbgpyZXZlYWwKcmV2aWV3CnJld2FyZApyaHl0aG0KcmliCnJpYmJvbgpyaWNlCnJpY2gKcmlkZQpyaWRnZQpyaWZsZQpyaWdodApyaWdpZApyaW5nCnJpb3QKcmlwcGxlCnJpc2sKcml0dWFsCnJpdmFsCnJpdmVyCnJvYWQKcm9hc3QKcm9ib3QKcm9idXN0CnJvY2tldApyb21hbmNlCnJvb2YKcm9va2llCnJvb20Kcm9zZQpyb3RhdGUKcm91Z2gKcm91bmQKcm91dGUKcm95YWwKcnViYmVyCnJ1ZGUKcnVnCnJ1bGUKcnVuCnJ1bndheQpydXJhbApzYWQKc2FkZGxlCnNhZG5lc3MKc2FmZQpzYWlsCnNhbGFkCnNhbG1vbgpzYWxvbgpzYWx0CnNhbHV0ZQpzYW1lCnNhbXBsZQpzYW5kCnNhdGlzZnkKc2F0b3NoaQpzYXVjZQpzYXVzYWdlCnNhdmUKc2F5CnNjYWxlCnNjYW4Kc2NhcmUKc2NhdHRlcgpzY2VuZQpzY2hlbWUKc2Nob29sCnNjaWVuY2UKc2Npc3NvcnMKc2NvcnBpb24Kc2NvdXQKc2NyYXAKc2NyZWVuCnNjcmlwdApzY3J1YgpzZWEKc2VhcmNoCnNlYXNvbgpzZWF0CnNlY29uZApzZWNyZXQKc2VjdGlvbgpzZWN1cml0eQpzZWVkCnNlZWsKc2VnbWVudApzZWxlY3QKc2VsbApzZW1pbmFyCnNlbmlvcgpzZW5zZQpzZW50ZW5jZQpzZXJpZXMKc2VydmljZQpzZXNzaW9uCnNldHRsZQpzZXR1cApzZXZlbgpzaGFkb3cKc2hhZnQKc2hhbGxvdwpzaGFyZQpzaGVkCnNoZWxsCnNoZXJpZmYKc2hpZWxkCnNoaWZ0CnNoaW5lCnNoaXAKc2hpdmVyCnNob2NrCnNob2UKc2hvb3QKc2hvcApzaG9ydApzaG91bGRlcgpzaG92ZQpzaHJpbXAKc2hydWcKc2h1ZmZsZQpzaHkKc2libGluZwpzaWNrCnNpZGUKc2llZ2UKc2lnaHQKc2lnbgpzaWxlbnQKc2lsawpzaWxseQpzaWx2ZXIKc2ltaWxhcgpzaW1wbGUKc2luY2UKc2luZwpzaXJlbgpzaXN0ZXIKc2l0dWF0ZQpzaXgKc2l6ZQpza2F0ZQpza2V0Y2gKc2tpCnNraWxsCnNraW4Kc2tpcnQKc2t1bGwKc2xhYgpzbGFtCnNsZWVwCnNsZW5kZXIKc2xpY2UKc2xpZGUKc2xpZ2h0CnNsaW0Kc2xvZ2FuCnNsb3QKc2xvdwpzbHVzaApzbWFsbApzbWFydApzbWlsZQpzbW9rZQpzbW9vdGgKc25hY2sKc25ha2UKc25hcApzbmlmZgpzbm93CnNvYXAKc29jY2VyCnNvY2lhbApzb2NrCnNvZGEKc29mdApzb2xhcgpzb2xkaWVyCnNvbGlkCnNvbHV0aW9uCnNvbHZlCnNvbWVvbmUKc29uZwpzb29uCnNvcnJ5CnNvcnQKc291bApzb3VuZApzb3VwCnNvdXJjZQpzb3V0aApzcGFjZQpzcGFyZQpzcGF0aWFsCnNwYXduCnNwZWFrCnNwZWNpYWwKc3BlZWQKc3BlbGwKc3BlbmQKc3BoZXJlCnNwaWNlCnNwaWRlcgpzcGlrZQpzcGluCnNwaXJpdApzcGxpdApzcG9pbApzcG9uc29yCnNwb29uCnNwb3J0CnNwb3QKc3ByYXkKc3ByZWFkCnNwcmluZwpzcHkKc3F1YXJlCnNxdWVlemUKc3F1aXJyZWwKc3RhYmxlCnN0YWRpdW0Kc3RhZmYKc3RhZ2UKc3RhaXJzCnN0YW1wCnN0YW5kCnN0YXJ0CnN0YXRlCnN0YXkKc3RlYWsKc3RlZWwKc3RlbQpzdGVwCnN0ZXJlbwpzdGljawpzdGlsbApzdGluZwpzdG9jawpzdG9tYWNoCnN0b25lCnN0b29sCnN0b3J5CnN0b3ZlCnN0cmF0ZWd5CnN0cmVldApzdHJpa2UKc3Ryb25nCnN0cnVnZ2xlCnN0dWRlbnQKc3R1ZmYKc3R1bWJsZQpzdHlsZQpzdWJqZWN0CnN1Ym1pdApzdWJ3YXkKc3VjY2VzcwpzdWNoCnN1ZGRlbgpzdWZmZXIKc3VnYXIKc3VnZ2VzdApzdWl0CnN1bW1lcgpzdW4Kc3VubnkKc3Vuc2V0CnN1cGVyCnN1cHBseQpzdXByZW1lCnN1cmUKc3VyZmFjZQpzdXJnZQpzdXJwcmlzZQpzdXJyb3VuZApzdXJ2ZXkKc3VzcGVjdApzdXN0YWluCnN3YWxsb3cKc3dhbXAKc3dhcApzd2FybQpzd2Vhcgpzd2VldApzd2lmdApzd2ltCnN3aW5nCnN3aXRjaApzd29yZApzeW1ib2wKc3ltcHRvbQpzeXJ1cApzeXN0ZW0KdGFibGUKdGFja2xlCnRhZwp0YWlsCnRhbGVudAp0YWxrCnRhbmsKdGFwZQp0YXJnZXQKdGFzawp0YXN0ZQp0YXR0b28KdGF4aQp0ZWFjaAp0ZWFtCnRlbGwKdGVuCnRlbmFudAp0ZW5uaXMKdGVudAp0ZXJtCnRlc3QKdGV4dAp0aGFuawp0aGF0CnRoZW1lCnRoZW4KdGhlb3J5CnRoZXJlCnRoZXkKdGhpbmcKdGhpcwp0aG91Z2h0CnRocmVlCnRocml2ZQp0aHJvdwp0aHVtYgp0aHVuZGVyCnRpY2tldAp0aWRlCnRpZ2VyCnRpbHQKdGltYmVyCnRpbWUKdGlueQp0aXAKdGlyZWQKdGlzc3VlCnRpdGxlCnRvYXN0CnRvYmFjY28KdG9kYXkKdG9kZGxlcgp0b2UKdG9nZXRoZXIKdG9pbGV0CnRva2VuCnRvbWF0bwp0b21vcnJvdwp0b25lCnRvbmd1ZQp0b25pZ2h0CnRvb2wKdG9vdGgKdG9wCnRvcGljCnRvcHBsZQp0b3JjaAp0b3JuYWRvCnRvcnRvaXNlCnRvc3MKdG90YWwKdG91cmlzdAp0b3dhcmQKdG93ZXIKdG93bgp0b3kKdHJhY2sKdHJhZGUKdHJhZmZpYwp0cmFnaWMKdHJhaW4KdHJhbnNmZXIKdHJhcAp0cmFzaAp0cmF2ZWwKdHJheQp0cmVhdAp0cmVlCnRyZW5kCnRyaWFsCnRyaWJlCnRyaWNrCnRyaWdnZXIKdHJpbQp0cmlwCnRyb3BoeQp0cm91YmxlCnRydWNrCnRydWUKdHJ1bHkKdHJ1bXBldAp0cnVzdAp0cnV0aAp0cnkKdHViZQp0dWl0aW9uCnR1bWJsZQp0dW5hCnR1bm5lbAp0dXJrZXkKdHVybgp0dXJ0bGUKdHdlbHZlCnR3ZW50eQp0d2ljZQp0d2luCnR3aXN0CnR3bwp0eXBlCnR5cGljYWwKdWdseQp1bWJyZWxsYQp1bmFibGUKdW5hd2FyZQp1bmNsZQp1bmNvdmVyCnVuZGVyCnVuZG8KdW5mYWlyCnVuZm9sZAp1bmhhcHB5CnVuaWZvcm0KdW5pcXVlCnVuaXQKdW5pdmVyc2UKdW5rbm93bgp1bmxvY2sKdW50aWwKdW51c3VhbAp1bnZlaWwKdXBkYXRlCnVwZ3JhZGUKdXBob2xkCnVwb24KdXBwZXIKdXBzZXQKdXJiYW4KdXJnZQp1c2FnZQp1c2UKdXNlZAp1c2VmdWwKdXNlbGVzcwp1c3VhbAp1dGlsaXR5CnZhY2FudAp2YWN1dW0KdmFndWUKdmFsaWQKdmFsbGV5CnZhbHZlCnZhbgp2YW5pc2gKdmFwb3IKdmFyaW91cwp2YXN0CnZhdWx0CnZlaGljbGUKdmVsdmV0CnZlbmRvcgp2ZW50dXJlCnZlbnVlCnZlcmIKdmVyaWZ5CnZlcnNpb24KdmVyeQp2ZXNzZWwKdmV0ZXJhbgp2aWFibGUKdmlicmFudAp2aWNpb3VzCnZpY3RvcnkKdmlkZW8Kdmlldwp2aWxsYWdlCnZpbnRhZ2UKdmlvbGluCnZpcnR1YWwKdmlydXMKdmlzYQp2aXNpdAp2aXN1YWwKdml0YWwKdml2aWQKdm9jYWwKdm9pY2UKdm9pZAp2b2xjYW5vCnZvbHVtZQp2b3RlCnZveWFnZQp3YWdlCndhZ29uCndhaXQKd2Fsawp3YWxsCndhbG51dAp3YW50CndhcmZhcmUKd2FybQp3YXJyaW9yCndhc2gKd2FzcAp3YXN0ZQp3YXRlcgp3YXZlCndheQp3ZWFsdGgKd2VhcG9uCndlYXIKd2Vhc2VsCndlYXRoZXIKd2ViCndlZGRpbmcKd2Vla2VuZAp3ZWlyZAp3ZWxjb21lCndlc3QKd2V0CndoYWxlCndoYXQKd2hlYXQKd2hlZWwKd2hlbgp3aGVyZQp3aGlwCndoaXNwZXIKd2lkZQp3aWR0aAp3aWZlCndpbGQKd2lsbAp3aW4Kd2luZG93CndpbmUKd2luZwp3aW5rCndpbm5lcgp3aW50ZXIKd2lyZQp3aXNkb20Kd2lzZQp3aXNoCndpdG5lc3MKd29sZgp3b21hbgp3b25kZXIKd29vZAp3b29sCndvcmQKd29yawp3b3JsZAp3b3JyeQp3b3J0aAp3cmFwCndyZWNrCndyZXN0bGUKd3Jpc3QKd3JpdGUKd3JvbmcKeWFyZAp5ZWFyCnllbGxvdwp5b3UKeW91bmcKeW91dGgKemVicmEKemVybwp6b25lCnpvbwptbmVtb25pY5RuEgAIAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZTw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAzG4SAB4AAAACAAAAAgAAAGJpcDM5OjplcnJvcjo6RXJyb3JLaW5kaW52YWxpZCBlbnRyb3B5IGxlbmd0aCBiaXRzIGZvciBtbmVtb25pYyB0eXBlIAAAABNvEgAXAAAAKm8SABcAAABpbnZhbGlkIG51bWJlciBvZiB3b3JkcyBpbiBwaHJhc2U6IABUbxIAIwAAAGludmFsaWQga2V5c2l6ZTogAAAAgG8SABEAAABpbnZhbGlkIHdvcmQgaW4gcGhyYXNlAACcbxIAFgAAAGludmFsaWQgY2hlY2tzdW28bxIAEAAAAEludmFsaWRFbnRyb3B5TGVuZ3RoQwAAAAQAAAAEAAAAIAAAAEQAAAAEAAAABAAAAEIAAABJbnZhbGlkV29yZExlbmd0aEludmFsaWRLZXlzaXplSW52YWxpZFdvcmRJbnZhbGlkQ2hlY2tzdW1Xb3JkczI0V29yZHMyMVdvcmRzMThXb3JkczE1V29yZHMxMi9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL3NsaWNlL21vZC5yc2RwEgBIAAAAQxIAABUAAAAAAAAAYXR0ZW1wdCB0byBkaXZpZGUgYnkgemVyb2Fzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6IAAAANlwEgAtAAAABnESAAwAAAAScRIAAwAAAGRlc3RpbmF0aW9uIGFuZCBzb3VyY2Ugc2xpY2VzIGhhdmUgZGlmZmVyZW50IGxlbmd0aHMwcRIANAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL21hY3Jvcy9tb2QucnMAAABscRIASQAAABIAAAANAAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2Jsb2NrLWJ1ZmZlci0wLjcuMC9zcmMvbGliLnJzAADIcRIAWgAAAF0AAAAJAAAAPDo6c3RkOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAAA0chIAHQAAAAIAAAAEAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYAAAZHISAC0AAACRchIADAAAAJ1yEgABAAAANHISAB0AAAAFAAAABgAAAGFzc2VydGlvbiBmYWlsZWQ6IDQgPD0gYnVmLmxlbigpYXNzZXJ0aW9uIGZhaWxlZDogOCA8PSBidWYubGVuKCkvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvYmxvY2stYnVmZmVyLTAuNy4wL3NyYy9saWIucnMAAAhzEgBaAAAAXQAAAAkAAAA8OjpzdGQ6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAAAHRzEgAdAAAAAgAAAAQAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgAACkcxIALQAAANFzEgAMAAAA3XMSAAEAAAB0cxIAHQAAAAUAAAAGAAAAYXNzZXJ0aW9uIGZhaWxlZDogOCA8PSBidWYubGVuKCln5glqha5nu3Lzbjw69U+lf1IOUYxoBZur2YMfGc3gWwjJvPNn5glqO6fKhIWuZ7sr+JT+cvNuPPE2HV869U+l0YLmrX9SDlEfbD4rjGgFm2u9Qfur2YMfeSF+ExnN4FtGAAAACAAAAAQAAABHAAAASAAAAEkAAAAIAAAABAAAAEoAAABHZW5lcmljQXJyYXk6OmZyb21faXRlciByZWNlaXZlZCAgZWxlbWVudHMgYnV0IGV4cGVjdGVkIKx0EgAhAAAAzXQSABcAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvZ2VuZXJpYy1hcnJheS0wLjEyLjAvc3JjL2xpYi5yc/R0EgBcAAAAQAEAAAUAAABMAAAABAAAAAQAAABNAAAATgAAAE8AAAAEAAAABAAAAFAAAABRAAAAUgAAAAQAAAAEAAAAUwAAAFQAAABPbmNlIGluc3RhbmNlIGhhcyBwcmV2aW91c2x5IGJlZW4gcG9pc29uZWQvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcGFya2luZ19sb3QtMC43LjEvc3JjL29uY2UucnPGdRIAWgAAAPIAAAARAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZcZ1EgBaAAAAHgEAACgAAABjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlAFYAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcGFya2luZ19sb3RfY29yZS0wLjQuMC9zcmMvcGFya2luZ19sb3QucnMAAJh2EgBmAAAAugAAAAUAAACYdhIAZgAAABcBAAAQAAAAmHYSAGYAAAAeAQAADQAAAJh2EgBmAAAAQAEAABMAAACYdhIAZgAAAFkBAAATAAAAVHJpZWQgdG8gc2hyaW5rIHRvIGEgbGFyZ2VyIGNhcGFjaXR5PDo6Y29yZTo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+AAB0dxIAHgAAAAIAAAACAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZUZyb21FbnRyb3B5Ojpmcm9tX2VudHJvcHkoKSBmYWlsZWQ6IMx3EgAkAAAAPDo6c3RkOjptYWNyb3M6OnBhbmljIG1hY3Jvcz4AAAD4dxIAHQAAAAUAAAAGAAAAY2FsbGVkIGBPcHRpb246OnVud3JhcCgpYCBvbiBhIGBOb25lYCB2YWx1ZQBZAAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL3BhcmtpbmdfbG90X2NvcmUtMC40LjAvc3JjL3dvcmRfbG9jay5yc1h4EgBkAAAASQAAAAUAAABhc3NlcnRpb24gZmFpbGVkOiBuZXdfY2FwID49IGxlbjw6OnN0ZDo6bWFjcm9zOjpwYW5pYyBtYWNyb3M+AAAA7HgSAB0AAAACAAAABAAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4L3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC9tYWNyb3MucnM8eRIARAAAAA0AAAAXAAAAUG9pc29uRXJyb3IgeyBpbm5lcjogLi4gfWNhbGxlZCBgUmVzdWx0Ojp1bndyYXAoKWAgb24gYW4gYEVycmAgdmFsdWVaAAAACAAAAAQAAABbAAAAXAAAAAwAAAAEAAAAXQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9wYXJraW5nX2xvdF9jb3JlLTAuNC4wL3NyYy90aHJlYWRfcGFya2VyL2dlbmVyaWMucnP0eRIAcAAAACcAAAAVAAAA9HkSAHAAAAAuAAAAGAAAAPR5EgBwAAAAMAAAABQAAAD0eRIAcAAAADgAAAAYAAAA9HkSAHAAAAA+AAAAIQAAAPR5EgBwAAAASgAAABUAAABfAAAAY291bGQgbm90IGluaXRpYWxpemUgdGhyZWFkX3JuZzogAAAAyHoSACEAAAAvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcmFuZC0wLjYuNS9zcmMvcm5ncy90aHJlYWQucnMAAPR6EgBaAAAAUAAAABEAAABjYW5ub3QgYWNjZXNzIGEgVGhyZWFkIExvY2FsIFN0b3JhZ2UgdmFsdWUgZHVyaW5nIG9yIGFmdGVyIGRlc3RydWN0aW9uL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC90aHJlYWQvbG9jYWwucnOmexIASgAAAO8AAAAJAAAAYAAAAAAAAAABAAAAYQAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kLTAuNi41L3NyYy9ybmdzL2VudHJvcHkucnNObyBlbnRyb3B5IHNvdXJjZXMgYXZhaWxhYmxlQWxsIGVudHJvcHkgc291cmNlcyBmYWlsZWRpbnRlcm5hbCBlcnJvcjogZW50ZXJlZCB1bnJlYWNoYWJsZSBjb2RlAAAAEHwSAFsAAAC6AAAACQAAAGFzc2VydGlvbiBmYWlsZWQ6IGAobGVmdCA9PSByaWdodClgCiAgbGVmdDogYGAsCiByaWdodDogYGA6INx8EgAtAAAACX0SAAwAAAAVfRIAAwAAAGRlc3RpbmF0aW9uIGFuZCBzb3VyY2Ugc2xpY2VzIGhhdmUgZGlmZmVyZW50IGxlbmd0aHMwfRIANAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL21hY3Jvcy9tb2QucnMAAABsfRIASQAAABIAAAANAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogyH0SAC0AAAD1fRIADAAAAAF+EgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Rocxx+EgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAFh+EgBJAAAAEgAAAA0AAABhc3NlcnRpb24gZmFpbGVkOiBzZWxmLmNvdW50ZXIxMDI0ICUgMTYgPT0gMC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kX2hjLTAuMS4wL3NyYy9oYzEyOC5ycwDgfhIAVwAAAH0AAAAJAAAA4H4SAFcAAADhAAAACQAAAOB+EgBXAAAA/AAAAA0AAADgfhIAVwAAAP0AAAANAAAA4H4SAFcAAAD+AAAADQAAAOB+EgBXAAAA/wAAAA0AAADgfhIAVwAAAAABAAANAAAA4H4SAFcAAAABAQAADQAAAOB+EgBXAAAAAgEAAA0AAADgfhIAVwAAAAMBAAANAAAA4H4SAFcAAAAEAQAADQAAAOB+EgBXAAAABQEAAA0AAADgfhIAVwAAAAYBAAANAAAA4H4SAFcAAAAHAQAADQAAAOB+EgBXAAAACAEAAA0AAADgfhIAVwAAAAkBAAANAAAA4H4SAFcAAAAKAQAADQAAAHJldHVybiB0aGlzYXNzZXJ0aW9uIGZhaWxlZDogdGhpcyAhPSBKc1ZhbHVlOjp1bmRlZmluZWQoKS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9yYW5kX29zLTAuMS4zL3NyYy93YXNtMzJfYmluZGdlbi5ycwAAAIGAEgBgAAAAIQAAAAkAAABjcnlwdG9zZWxmLmNyeXB0byBpcyB1bmRlZmluZWRjcnlwdG8uZ2V0UmFuZG9tVmFsdWVzIGlzIHVuZGVmaW5lZAAAAGMAAAAIAAAABAAAAGQAAABlAAAAZgAAAAgAAAAEAAAAZwAAAGludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGUvaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcmFuZF9jb3JlLTAuNC4yL3NyYy9lcnJvci5ycwAAAISBEgBZAAAASgAAACsAAABub3QgcmVhZHkgeWV0dHJhbnNpZW50IGZhaWx1cmV1bmV4cGVjdGVkIGZhaWx1cmVwZXJtYW5lbnRseSB1bmF2YWlsYWJsZSAoKQAAN4ISAAAAAAA3ghIAAgAAADmCEgABAAAAKTsgY2F1c2U6IAAAN4ISAAAAAAA3ghIAAgAAAFSCEgAKAAAAX19Ob25leGhhdXN0aXZlTm90UmVhZHlUcmFuc2llbnRVbmV4cGVjdGVkVW5hdmFpbGFibGVFcnJvcmtpbmQAAGoAAAAEAAAABAAAAGsAAABtc2cAbAAAAAQAAAAEAAAAHgAAAGNhdXNlAAAAbQAAAAQAAAAEAAAAbgAAAFNvbWVvAAAABAAAAAQAAABwAAAATm9uZXEAAAAUAAAABAAAAHIAAABzAAAAdAAAAHUAAAB2AAAAVwAAAHcAAAAKCgAANIMSAAAAAAA0gxIAAgAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4L3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYnN0ZC9tYWNyb3MucnNogxIARAAAAA0AAAAXAAAAY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQB6AAAACAAAAAQAAAB7AAAAL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2ZhaWx1cmUtMC4xLjUvc3JjL2JhY2t0cmFjZS9pbnRlcm5hbC5yc/iDEgBkAAAAOgAAABwAAABSVVNUX0ZBSUxVUkVfQkFDS1RSQUNFMFJVU1RfQkFDS1RSQUNFUG9pc29uRXJyb3IgeyBpbm5lcjogLi4gfWludGVybmFsIGVycm9yOiBlbnRlcmVkIHVucmVhY2hhYmxlIGNvZGU8Ojpjb3JlOjptYWNyb3M6OnBhbmljIG1hY3Jvcz7ShBIAHgAAAAIAAAACAAAAYXNzZXJ0aW9uIGZhaWxlZDogYChsZWZ0ID09IHJpZ2h0KWAKICBsZWZ0OiBgYCwKIHJpZ2h0OiBgYDogAIUSAC0AAAAthRIADAAAADmFEgADAAAAZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzbGljZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Roc1SFEgA0AAAAL3J1c3RjLzBlYjg3OGQyYWE2ZTNhMWNiMzE1ZjNmMzI4NjgxYjI2YmI0YmZmZGIvc3JjL2xpYmNvcmUvbWFjcm9zL21vZC5ycwAAAJCFEgBJAAAAEgAAAA0AAAB9AAAACAAAAAQAAAB+AAAAfwAAAIAAAAAIAAAABAAAAIEAAACCAAAABAAAAAQAAACDAAAAhAAAAC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJzdGQvc3luYy9vbmNlLnJzACSGEgBHAAAACAEAACkAAABjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQAAhQAAAAgAAAAEAAAAhgAAAC9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9iYWNrdHJhY2UtMC4zLjM4L3NyYy9saWIucnOHAAAA5IYSAFgAAACUAAAAHAAAAFBvaXNvbkVycm9yIHsgaW5uZXI6IC4uIH1zdGFjayBiYWNrdHJhY2U6CgAAOiAAAHyHEgAAAAAAfIcSAAIAAAAAAAAAIAAAAAAAAAACAEGoj8oAC4ojBAAAAAMAAAAgLSAAfIcSAAAAAACwhxIAAwAAAAoAAAAAAAAAIAAAAAAAAAACAAAAAAAAAAEAAAABAAAAAwAAACAgICAgIAAA6IcSAAYAAAB8hxIAAAAAAA0AAAAAAAAAIAAAAAQAAAACAAAAAAAAAAIAAAAAAAAAAwAAADx1bmtub3duPgAAACSIEgAJAAAACiAgICAgICAgICAgICBhdCAAAAA5iBIAEAAAADoAAABUiBIAAQAAADiIEgABAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZS9ob21lL3J1bm5lci8uY2FyZ28vcmVnaXN0cnkvc3JjL2dpdGh1Yi5jb20tMWVjYzYyOTlkYjllYzgyMy9iYWNrdHJhY2UtMC4zLjM4L3NyYy90eXBlcy5ycwAAkIgSAFoAAABKAAAACQAAAIsAAAAUAAAABAAAAIwAAACNAAAA77+9Y2Fubm90IHJlY3Vyc2l2ZWx5IGFjcXVpcmUgbXV0ZXgvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGlic3RkL21hY3Jvcy5ycwAziRIARAAAAA0AAAAXAAAAY2Fubm90IGFjY2VzcyBhIFRocmVhZCBMb2NhbCBTdG9yYWdlIHZhbHVlIGR1cmluZyBvciBhZnRlciBkZXN0cnVjdGlvbi9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJzdGQvdGhyZWFkL2xvY2FsLnJzzokSAEoAAADvAAAACQAAAI8AAAAAAAAAAQAAAGEAAABhc3NlcnRpb24gZmFpbGVkOiBzbG90LmdldCgpL2hvbWUvcnVubmVyLy5jYXJnby9yZWdpc3RyeS9zcmMvZ2l0aHViLmNvbS0xZWNjNjI5OWRiOWVjODIzL2JhY2t0cmFjZS0wLjMuMzgvc3JjL2xpYi5yc1SKEgBYAAAAhAAAABUAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9zdHIvcGF0dGVybi5ycwAAvIoSAEoAAACCBAAAIQAAALyKEgBKAAAAjgQAABQAAAC8ihIASgAAAI4EAAAhAAAAvIoSAEoAAADZBAAAFAAAALyKEgBKAAAA2QQAACEAAAC8ihIASgAAAOUEAAAUAAAAvIoSAEoAAADlBAAAIQAAAGNhbGxlZCBgT3B0aW9uOjp1bndyYXAoKWAgb24gYSBgTm9uZWAgdmFsdWVjYWxsZWQgYFJlc3VsdDo6dW53cmFwKClgIG9uIGFuIGBFcnJgIHZhbHVlAACQAAAAAQAAAAEAAACRAAAALmxsdm0uRS5fWk5aTl9fWk4vaG9tZS9ydW5uZXIvLmNhcmdvL3JlZ2lzdHJ5L3NyYy9naXRodWIuY29tLTFlY2M2Mjk5ZGI5ZWM4MjMvcnVzdGMtZGVtYW5nbGUtMC4xLjEzL3NyYy9saWIucnMAAPGLEgBdAAAAAgEAABMAAADxixIAXQAAAAUBAAAcAAAAOjpfJC4kU1AkQCRCUCQqJFJGJCYkTFQkPCRHVCQ+JExQJCgkUlAkKSRDJCwkdTdlJH4kdTIwJCAkdTI3JCckdTNkJD0kdTViJFskdTVkJF0kdTdiJHskdTdkJH0kdTNiJDskdTJiJCskdTIxJCEkdTIyJCKUAAAABAAAAAQAAACVAAAAlgAAAJcAAACUAAAABAAAAAQAAACYAAAAYWxyZWFkeSBib3Jyb3dlZC9ydXN0Yy8wZWI4NzhkMmFhNmUzYTFjYjMxNWYzZjMyODY4MWIyNmJiNGJmZmRiL3NyYy9saWJjb3JlL2NlbGwucnMAHI0SAEMAAABuAwAACQAAAGFscmVhZHkgbXV0YWJseSBib3Jyb3dlZByNEgBDAAAAHgMAAAkAAABhc3NlcnRpb24gZmFpbGVkOiBgKGxlZnQgPT0gcmlnaHQpYAogIGxlZnQ6IGBgLAogcmlnaHQ6IGBgAACYjRIALQAAAMWNEgAMAAAA0Y0SAAEAAACUAAAAAAAAAAEAAACZAAAAYDogAJiNEgAtAAAAxY0SAAwAAAD8jRIAAwAAAGNhbGxlZCBgT3B0aW9uOjp1bndyYXAoKWAgb24gYSBgTm9uZWAgdmFsdWUAlAAAAAAAAAABAAAAmgAAAJsAAAAQAAAABAAAAJwAAACUAAAAAAAAAAEAAACdAAAAY2FsbGVkIGBSZXN1bHQ6OnVud3JhcCgpYCBvbiBhbiBgRXJyYCB2YWx1ZQCeAAAACAAAAAQAAACfAAAAaW50ZXJuYWwgZXJyb3I6IGVudGVyZWQgdW5yZWFjaGFibGUgY29kZTw6OmNvcmU6Om1hY3Jvczo6cGFuaWMgbWFjcm9zPgAA2I4SAB4AAAACAAAAAgAAAFRyaWVkIHRvIHNocmluayB0byBhIGxhcmdlciBjYXBhY2l0eZQAAAAEAAAABAAAAJIAAABBY2Nlc3NFcnJvcnNyYy9saWJzdGQvdGhyZWFkL21vZC5ycwBHjxIAGAAAAIYDAAARAAAAaW5jb25zaXN0ZW50IHBhcmsgc3RhdGUAR48SABgAAACUAwAAEwAAAAIAAABwYXJrIHN0YXRlIGNoYW5nZWQgdW5leHBlY3RlZGx5AJyPEgAfAAAAR48SABgAAACRAwAADQAAAGZhaWxlZCB0byBnZW5lcmF0ZSB1bmlxdWUgdGhyZWFkIElEOiBiaXRzcGFjZSBleGhhdXN0ZWQAR48SABgAAAAqBAAAEQAAAEePEgAYAAAAMAQAABYAAAB0aHJlYWQgbmFtZSBtYXkgbm90IGNvbnRhaW4gaW50ZXJpb3IgbnVsbCBieXRlcwBHjxIAGAAAAHMEAAAaAAAAaW5jb25zaXN0ZW50IHN0YXRlIGluIHVucGFya0ePEgAYAAAAqwQAABIAAABHjxIAGAAAALkEAAAOAAAAoAAAAAwAAAAEAAAAoQAAAKIAAACjAAAApAAAAKEAAAClAAAApgAAAC5zcmMvbGlic3RkL3BhdGgucnMuLgAAANGQEgASAAAAiwMAACAAAABhdHRlbXB0ZWQgdG8gdXNlIGEgY29uZGl0aW9uIHZhcmlhYmxlIHdpdGggdHdvIG11dGV4ZXNzcmMvbGlic3RkL3N5bmMvY29uZHZhci5ycy6REgAaAAAAPwIAABIAAABzcmMvbGlic3RkL3N5bmMvb25jZS5yc2Fzc2VydGlvbiBmYWlsZWQ6IHN0YXRlX2FuZF9xdWV1ZSAmIFNUQVRFX01BU0sgPT0gUlVOTklOR1iREgAXAAAApwEAABUAAABPbmNlIGluc3RhbmNlIGhhcyBwcmV2aW91c2x5IGJlZW4gcG9pc29uZWQAAFiREgAXAAAAiwEAABUAAABYkRIAFwAAAOgBAAAJAAAAWJESABcAAAD0AQAAHgAAAHN1cHBsaWVkIGluc3RhbnQgaXMgbGF0ZXIgdGhhbiBzZWxmc3JjL2xpYnN0ZC90aW1lLnJzAAAAN5ISABIAAAAHAQAACQAAAFBvaXNvbkVycm9yIHsgaW5uZXI6IC4uIH1zcmMvbGlic3RkL3Bhbmlja2luZy5yc3WSEgAXAAAAeAEAAA8AAAB1khIAFwAAAHkBAAAPAAAApwAAABAAAAAEAAAAqAAAAKkAAACgAAAADAAAAAQAAACqAAAAlAAAAAgAAAAEAAAAqwAAAKwAAACUAAAACAAAAAQAAACtAAAATnVsRXJyb3KUAAAABAAAAAQAAACuAAAAdGltZSBub3QgaW1wbGVtZW50ZWQgb24gd2FzbTMyLXVua25vd24tdW5rbm93bnNyYy9saWJzdGQvc3lzL3dhc20vdGltZS5ycwAAADqTEgAbAAAADQAAAAkAAABvcGVyYXRpb24gbm90IHN1cHBvcnRlZCBvbiB3YXNtIHlldGNhbid0IGJsb2NrIHdpdGggd2ViIGFzc2VtYmx5c3JjL2xpYnN0ZC9zeXMvd2FzbS9jb25kdmFyLnJzAACokxIAHgAAABUAAAAJAAAAqJMSAB4AAAAZAAAACQAAAGNhbm5vdCByZWN1cnNpdmVseSBhY3F1aXJlIG11dGV4c3JjL2xpYnN0ZC9zeXMvd2FzbS9tdXRleC5ycwiUEgAcAAAAFQAAAAkAAACvAAAABAAAAAQAAACwAAAAsQAAALIAAAAvcnVzdGMvMGViODc4ZDJhYTZlM2ExY2IzMTVmM2YzMjg2ODFiMjZiYjRiZmZkYi9zcmMvbGliY29yZS9mbXQvbW9kLnJzAABMlBIARgAAAFgBAAATAAAArwAAAAAAAAABAAAAswAAAGEgZm9ybWF0dGluZyB0cmFpdCBpbXBsZW1lbnRhdGlvbiByZXR1cm5lZCBhbiBlcnJvcnNyYy9saWJhbGxvYy9mbXQucnMAAOeUEgATAAAAOwIAAAUAAABzcmMvbGliYWxsb2MvcmF3X3ZlYy5yc2NhcGFjaXR5IG92ZXJmbG93DJUSABcAAADrAgAABQAAAGAALi5GlRIAAgAAAEJvcnJvd0Vycm9yQm9ycm93TXV0RXJyb3JjYWxsZWQgYE9wdGlvbjo6dW53cmFwKClgIG9uIGEgYE5vbmVgIHZhbHVlRJUSAAAAAAA6IAAARJUSAAAAAACclRIAAgAAALkAAAAAAAAAAQAAALoAAABpbmRleCBvdXQgb2YgYm91bmRzOiB0aGUgbGVuIGlzICBidXQgdGhlIGluZGV4IGlzIAAAwJUSACAAAADglRIAEgAAALkAAAAMAAAABAAAALsAAAC8AAAAvQAAACAgICAgewosCiwgIHsgfSB9KAooLCkKW10weDBiMDAwMTAyMDMwNDA1MDYwNzA4MDkxMDExMTIxMzE0MTUxNjE3MTgxOTIwMjEyMjIzMjQyNTI2MjcyODI5MzAzMTMyMzMzNDM1MzYzNzM4Mzk0MDQxNDI0MzQ0NDU0NjQ3NDg0OTUwNTE1MjUzNTQ1NTU2NTc1ODU5NjA2MTYyNjM2NDY1NjY2NzY4Njk3MDcxNzI3Mzc0NzU3Njc3Nzg3OTgwODE4MjgzODQ4NTg2ODc4ODg5OTA5MTkyOTM5NDk1OTY5Nzk4OTkAAAC5AAAABAAAAAQAAAC+AAAAvwAAAMAAAABzcmMvbGliY29yZS9mbXQvbW9kLnJzAAAclxIAFgAAADwEAAARAAAAHJcSABYAAABGBAAAJAAAAHRydWVmYWxzZXNyYy9saWJjb3JlL3NsaWNlL21vZC5yc2luZGV4ICBvdXQgb2YgcmFuZ2UgZm9yIHNsaWNlIG9mIGxlbmd0aCAAAAB1lxIABgAAAHuXEgAiAAAAXZcSABgAAACxCgAABQAAAHNsaWNlIGluZGV4IHN0YXJ0cyBhdCAgYnV0IGVuZHMgYXQgAMCXEgAWAAAA1pcSAA0AAABdlxIAGAAAALcKAAAFAAAAc3JjL2xpYmNvcmUvc3RyL3BhdHRlcm4ucnMAAASYEgAaAAAAEAUAABUAAAAEmBIAGgAAAD4FAAAVAAAABJgSABoAAAA/BQAAFQAAAGFzc2VydGlvbiBmYWlsZWQ6IGJyb2tlbi5pc19lbXB0eSgpc3JjL2xpYmNvcmUvc3RyL2xvc3N5LnJzAHOYEgAYAAAAnQAAABEAAABzcmMvbGliY29yZS9zdHIvbW9kLnJzAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAQfSyygALMwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAwMDAwMDAwMDAwMEBAQEBABBsrPKAAuZDlsuLi5dYnl0ZSBpbmRleCAgaXMgb3V0IG9mIGJvdW5kcyBvZiBgt5kSAAsAAADCmRIAFgAAAESVEgABAAAAnJgSABYAAACSCAAACQAAAGJlZ2luIDw9IGVuZCAoIDw9ICkgd2hlbiBzbGljaW5nIGAAAACaEgAOAAAADpoSAAQAAAASmhIAEAAAAESVEgABAAAAnJgSABYAAACWCAAABQAAAJyYEgAWAAAApwgAAA4AAAAgaXMgbm90IGEgY2hhciBib3VuZGFyeTsgaXQgaXMgaW5zaWRlICAoYnl0ZXMgKSBvZiBgt5kSAAsAAABkmhIAJgAAAIqaEgAIAAAAkpoSAAYAAABElRIAAQAAAJyYEgAWAAAAqQgAAAUAAABzcmMvbGliY29yZS91bmljb2RlL3ByaW50YWJsZS5yc9CaEgAgAAAAGgAAACgAAAAAAQMFBQYGAwcGCAgJEQocCxkMFA0SDg0PBBADEhITCRYBFwUYAhkDGgccAh0BHxYgAysELAItCy4BMAMxAjIBpwKpAqoEqwj6AvsF/QT+A/8JrXh5i42iMFdYi4yQHB3dDg9LTPv8Li8/XF1fteKEjY6RkqmxurvFxsnK3uTl/wAEERIpMTQ3Ojs9SUpdhI6SqbG0urvGys7P5OUABA0OERIpMTQ6O0VGSUpeZGWEkZudyc7PDREpRUlXZGWNkam0urvFyd/k5fAEDRFFSWRlgIGEsry+v9XX8PGDhYukpr6/xcfOz9rbSJi9zcbOz0lOT1dZXl+Jjo+xtre/wcbH1xEWF1tc9vf+/4ANbXHe3w4PH25vHB1ffX6ur7u8+hYXHh9GR05PWFpcXn5/tcXU1dzw8fVyc490dZaXL18mLi+nr7e/x8/X35pAl5gwjx/Awc7/Tk9aWwcIDxAnL+7vbm83PT9CRZCR/v9TZ3XIydDR2Nnn/v8AIF8igt8EgkQIGwQGEYGsDoCrNR4VgOADGQgBBC8ENAQHAwEHBgcRClAPEgdVCAIEHAoJAwgDBwMCAwMDDAQFAwsGAQ4VBToDEQcGBRAHVwcCBxUNUARDAy0DAQQRBg8MOgQdJV8gbQRqJYDIBYKwAxoGgv0DWQcVCxcJFAwUDGoGCgYaBlkHKwVGCiwEDAQBAzELLAQaBgsDgKwGCgYfQUwELQN0CDwDDwM8BzgIKwWC/xEYCC8RLQMgECEPgIwEgpcZCxWIlAUvBTsHAg4YCYCwMHQMgNYaDAWA/wWAtgUkDJvGCtIwEISNAzcJgVwUgLgIgMcwNQQKBjgIRggMBnQLHgNaBFkJgIMYHAoWCUgIgIoGq6QMFwQxoQSB2iYHDAUFgKURgW0QeCgqBkwEgI0EgL4DGwMPDQAGAQEDAQQCCAgJAgoFCwIQAREEEgUTERQCFQIXAhkEHAUdCCQBagNrArwC0QLUDNUJ1gLXAtoB4AXhAugC7iDwBPkG+gIMJzs+Tk+Pnp6fBgcJNj0+VvPQ0QQUGDY3Vle9Nc7P4BKHiY6eBA0OERIpMTQ6RUZJSk5PZGVaXLa3GxyoqdjZCTeQkagHCjs+ZmmPkm9f7u9aYpqbJyhVnaCho6SnqK26vMQGCwwVHTo/RVGmp8zNoAcZGiIlPj/FxgQgIyUmKDM4OkhKTFBTVVZYWlxeYGNlZmtzeH1/iqSqr7DA0Axyo6TLzG5vXiJ7BQMELQNlBAEvLoCCHQMxDxwEJAkeBSsFRAQOKoCqBiQEJAQoCDQLAYCQgTcJFgoIgJg5A2MICTAWBSEDGwUBQDgESwUvBAoHCQdAICcEDAk2AzoFGgcEDAdQSTczDTMHLggKgSYfgIEoCCqAhhcJTgQeD0MOGQcKBkcJJwl1Cz9BKgY7BQoGUQYBBRADBYCLYCBICAqApl4iRQsKBg0TOQcKNiwEEIDAPGRTDAGAoEUbSAhTHTmBB0YKHQNHSTcDDggKBjkHCoE2GYDHMg2Dm2Z1C4DEiryEL4/RgkehuYI5ByoEAmAmCkYKKAUTgrBbZUsEOQcRQAQcl/gIgvOlDYEfMQMRBAiBjIkEawUNAwkHEJNggPYKcwhuF0aAmhQMVwkZgIeBRwOFQg8VhVArgNUtAxoEAoFwOgUBhQCA1ylMBAoEAoMRREw9gMI8BgEEVQUbNAKBDiwEZAxWCg0DXQM9OR0NLAQJBwIOBoCag9YKDQMLBXQMWQcMFAwEOAgKBigIHlJ3AzEDgKYMFAQDBQMNBoVqc3JjL2xpYmNvcmUvdW5pY29kZS9tb2QucnMANaASABoAAAA4AAAADwAAADWgEgAaAAAAOQAAABAAAABraW5kRW1wdHlaZXJvUGFyc2VJbnRFcnJvcgAAuQAAAAQAAAAEAAAAwQAAAFVuZGVyZmxvd092ZXJmbG93SW52YWxpZERpZ2l0RXJyb3IEDxUbGQMSFxEAAA4WAEHnwcoACwIGEwBB/MHKAAsKAgcKAAgMHRwYGgBBmMLKAAsCBQEAQa3CygALDBAAAAAACwAJABQADQBB1sLKAAsCDxIAQeXCygALAR8AQfXCygALBElGZh0AQYXDygALAoo+AEGUw8oACwJLUwBBosPKAAsDZyNCAEGxw8oACwc9AAAAAAAjAEHBw8oACwR1AAAtAEHRw8oACwOCTjwAQeDDygALE2MAAAAlAFoAAAAAAAAAgTYAAAMAQf3DygALAS8AQYbEygALCRAAAAAAABMACABBnMTKAAsFQwByAIkAQavEygALEQcAAAB9BRg/ADeHCUBkAAAhAEHJxMoACwQKAABBAEHZxMoAC0MMADAAXAAAABl3cQBgRzVELgAAdDkRZSxRXn9QAAAANDEAAABTAAAAAAAAOgAAAAA4GgCIXytraV1PXYSAKmgUOwAXAEGpxcoACwhVAABXAAAAgwBBucXKAAsTWQAAAAAAACZuGxYAAAAAAG1KHABB1sXKAAtLJAAAfABSAHsGFQAAAABIAAAAAH4odidsKQAiWw5hDVZwYgSFIHgCAAB6HnkBVAAzAAAAhnNYAE1FbwtqAAAybEwAAImKAACKioo+AEG4xsoAC5wCAQAAAAAAAAANAAAAAAAAABwAAAAAAAAAQAAAAAAAAAC2AAAAAAAAAL8AAAAAAAAA+AMAAAAAAADwBwAAAAAAAP8HAAAAAAAAABAAAAAAAAAAHgAAAAAAAAA4AAAAAAAAAD8AAAAAAACAfwAAAAAAAACAAAAAAAAAwP8BAAAAAACA/wMAAAAAAACABwAAAAAAAAB/AAAAAAABIIAAAAAAAAAAowAAAAAAAPx/AwAAAAAAAAAGAAAAAAAA/wcAAAAAAACACQAAAAAAAAAOAAAAAIAAfg4AAAAAZCAAIAAAAABA/g8gAAAAAAEAADAAAAAAAAAAQAAAAABcAABAAAAAAAAAAGAAAAAAAIRcgAAAAAAAAADAAAAAAAAAAOAAQdzIygALtQYBAAAAAADwDAEAAABEMGAADAAAAME9YAAMAAAAHiCAAAwAAAAeIMAADAAAAP4h/gAMAAAAAAAAACAAAAAAAAAAYAAAAEQIAABgAAAAAAAAAPAAAABgAAAAAAIAAH////nbBwAAAAAAgPgHAAAAAADgvA8AAAAAAAAgIQAAAwAAADw7AADnDwAAADwAAAAAwJ+fPQAAAADA++8+AAAAAAAAwD8AAAAAAAAA8AAAAAAAAAD8AAAQAAD4/v8AAP//AAD//wAA////////AAAA+P//AAABAAAAAADA/wEAAAD/////AQAAAAAAAAADAAAAAAAAgAMAAAAAAECjAwAAAAAAAAAIAAAADAAAAAwABAAAAAD4DwAAAAAAAAAYAAAAHAAAABwAAAAAwwEAHgAAAAAAAAAfAAEAgADAHx8ABwAAAIDvHwD//////x8gAIY5AgAAACMAAgAAAAAwQAAAAAAAAH5mAAAA/P///G0AAAAAAAAAfwAAAAAAACi/AAAAAAAA8M8AAAAAAwAAoAIAAPf//SEQAwMAAAAAAHgGAAAAAACA/wYAAAAAAADABwAAAAAAAPIHAAAAAIcBBA4GAAAAAAAAEAgQAAAAAAAQBwAAAAAAABQPAAAAAADwFwAAAAAAAPIf3+D//v///x8AAAAAAAAAIAAAAAAA+A8gBwAAAAAAyDMAAAAAAACwPwAAAAAAgPc/BAAAAAAAAEAeIIAADAAAQAAAAAAAgNNAAgAAAAAAAFADAAAAAAAAWAAAAAAA4P1m/gcAAAAA+HkDAAAAAADAfwAAAAAAAP5/AAAAAAAA/38AAAAAAAAAgH8AAAAAAACAMAAAAP//A4Bu8AAAAAAAhwIAAAAAAACQAABAf+Uf+J8AAAAAAAD5pQAAAAAAAPinAAAAAACAPLAAAAAAAAB+tAAAAAAAAH+/AAD+/////78RAAAAAAAAwAAAAAAAAJ3BAgAAAAAAANAAAAAAoMMH+P///////3/4//////////u+IQAADAAA/AAAAAAAAAD/AgAAAAAAAP8AAAIAAAD//wAA+P/7////AAAAAP///////////////wMAAAAAAQAABABBq8/KAAsHAQAAAAAAAQBBwc/KAAsDBAADAEHRz8oACwIFAgBB8M/KAAsBAQBB+8/KAAsbgAAAAAAgAAAAAQAAAAA+AAABAAAA/wcAAACDAEGo+soACwE/AEHE+soACwFAAEHY+soACwECAEGA+8oACwECAEGQ+8oACwkCAAAAAAAAAAEAggEJcHJvZHVjZXJzAghsYW5ndWFnZQEEUnVzdAAMcHJvY2Vzc2VkLWJ5AwVydXN0YyUxLjQzLjAtbmlnaHRseSAoMGViODc4ZDJhIDIwMjAtMDItMjgpBndhbHJ1cwUwLjUuMAx3YXNtLWJpbmRnZW4SMC4yLjM5IChlMDc1ZDA0OTIp","base64")}).call(this,A("buffer").Buffer)},{buffer:64}],307:[function(A,e,t){"use strict";const i=(A,e)=>(...t)=>{return`[${A(...t)+e}m`},g=(A,e)=>(...t)=>{const i=A(...t);return`[${38+e};5;${i}m`},r=(A,e)=>(...t)=>{const i=A(...t);return`[${38+e};2;${i[0]};${i[1]};${i[2]}m`},n=A=>A,B=(A,e,t)=>[A,e,t],I=(A,e,t)=>{Object.defineProperty(A,e,{get:()=>{const i=t();return Object.defineProperty(A,e,{value:i,enumerable:!0,configurable:!0}),i},enumerable:!0,configurable:!0})};let o;const a=(e,t,i,g)=>{void 0===o&&(o=A("color-convert"));const r=g?10:0,n={};for(const[A,g]of Object.entries(o)){const B="ansi16"===A?"ansi":A;A===t?n[B]=e(i,r):"object"==typeof g&&(n[B]=e(g[t],r))}return n};Object.defineProperty(e,"exports",{enumerable:!0,get:function(){const A=new Map,e={modifier:{reset:[0,0],bold:[1,22],dim:[2,22],italic:[3,23],underline:[4,24],inverse:[7,27],hidden:[8,28],strikethrough:[9,29]},color:{black:[30,39],red:[31,39],green:[32,39],yellow:[33,39],blue:[34,39],magenta:[35,39],cyan:[36,39],white:[37,39],blackBright:[90,39],redBright:[91,39],greenBright:[92,39],yellowBright:[93,39],blueBright:[94,39],magentaBright:[95,39],cyanBright:[96,39],whiteBright:[97,39]},bgColor:{bgBlack:[40,49],bgRed:[41,49],bgGreen:[42,49],bgYellow:[43,49],bgBlue:[44,49],bgMagenta:[45,49],bgCyan:[46,49],bgWhite:[47,49],bgBlackBright:[100,49],bgRedBright:[101,49],bgGreenBright:[102,49],bgYellowBright:[103,49],bgBlueBright:[104,49],bgMagentaBright:[105,49],bgCyanBright:[106,49],bgWhiteBright:[107,49]}};e.color.gray=e.color.blackBright,e.bgColor.bgGray=e.bgColor.bgBlackBright,e.color.grey=e.color.blackBright,e.bgColor.bgGrey=e.bgColor.bgBlackBright;for(const[t,i]of Object.entries(e)){for(const[t,g]of Object.entries(i))e[t]={open:`[${g[0]}m`,close:`[${g[1]}m`},i[t]=e[t],A.set(g[0],g[1]);Object.defineProperty(e,t,{value:i,enumerable:!1})}return Object.defineProperty(e,"codes",{value:A,enumerable:!1}),e.color.close="",e.bgColor.close="",I(e.color,"ansi",()=>a(i,"ansi16",n,!1)),I(e.color,"ansi256",()=>a(g,"ansi256",n,!1)),I(e.color,"ansi16m",()=>a(r,"rgb",B,!1)),I(e.bgColor,"ansi",()=>a(i,"ansi16",n,!0)),I(e.bgColor,"ansi256",()=>a(g,"ansi256",n,!0)),I(e.bgColor,"ansi16m",()=>a(r,"rgb",B,!0)),e}})},{"color-convert":309}],308:[function(A,e,t){const i=A("color-name"),g={};for(const A of Object.keys(i))g[i[A]]=A;const r={rgb:{channels:3,labels:"rgb"},hsl:{channels:3,labels:"hsl"},hsv:{channels:3,labels:"hsv"},hwb:{channels:3,labels:"hwb"},cmyk:{channels:4,labels:"cmyk"},xyz:{channels:3,labels:"xyz"},lab:{channels:3,labels:"lab"},lch:{channels:3,labels:"lch"},hex:{channels:1,labels:["hex"]},keyword:{channels:1,labels:["keyword"]},ansi16:{channels:1,labels:["ansi16"]},ansi256:{channels:1,labels:["ansi256"]},hcg:{channels:3,labels:["h","c","g"]},apple:{channels:3,labels:["r16","g16","b16"]},gray:{channels:1,labels:["gray"]}};e.exports=r;for(const A of Object.keys(r)){if(!("channels"in r[A]))throw new Error("missing channels property: "+A);if(!("labels"in r[A]))throw new Error("missing channel labels property: "+A);if(r[A].labels.length!==r[A].channels)throw new Error("channel and label counts mismatch: "+A);const{channels:e,labels:t}=r[A];delete r[A].channels,delete r[A].labels,Object.defineProperty(r[A],"channels",{value:e}),Object.defineProperty(r[A],"labels",{value:t})}r.rgb.hsl=function(A){const e=A[0]/255,t=A[1]/255,i=A[2]/255,g=Math.min(e,t,i),r=Math.max(e,t,i),n=r-g;let B,I;r===g?B=0:e===r?B=(t-i)/n:t===r?B=2+(i-e)/n:i===r&&(B=4+(e-t)/n),(B=Math.min(60*B,360))<0&&(B+=360);const o=(g+r)/2;return[B,100*(I=r===g?0:o<=.5?n/(r+g):n/(2-r-g)),100*o]},r.rgb.hsv=function(A){let e,t,i,g,r;const n=A[0]/255,B=A[1]/255,I=A[2]/255,o=Math.max(n,B,I),a=o-Math.min(n,B,I),Q=function(A){return(o-A)/6/a+.5};return 0===a?(g=0,r=0):(r=a/o,e=Q(n),t=Q(B),i=Q(I),n===o?g=i-t:B===o?g=1/3+e-i:I===o&&(g=2/3+t-e),g<0?g+=1:g>1&&(g-=1)),[360*g,100*r,100*o]},r.rgb.hwb=function(A){const e=A[0],t=A[1];let i=A[2];return[r.rgb.hsl(A)[0],100*(1/255*Math.min(e,Math.min(t,i))),100*(i=1-1/255*Math.max(e,Math.max(t,i)))]},r.rgb.cmyk=function(A){const e=A[0]/255,t=A[1]/255,i=A[2]/255,g=Math.min(1-e,1-t,1-i);return[100*((1-e-g)/(1-g)||0),100*((1-t-g)/(1-g)||0),100*((1-i-g)/(1-g)||0),100*g]},r.rgb.keyword=function(A){const e=g[A];if(e)return e;let t,r=1/0;for(const e of Object.keys(i)){const g=i[e],I=(B=g,((n=A)[0]-B[0])**2+(n[1]-B[1])**2+(n[2]-B[2])**2);I.04045?((e+.055)/1.055)**2.4:e/12.92)+.3576*(t=t>.04045?((t+.055)/1.055)**2.4:t/12.92)+.1805*(i=i>.04045?((i+.055)/1.055)**2.4:i/12.92)),100*(.2126*e+.7152*t+.0722*i),100*(.0193*e+.1192*t+.9505*i)]},r.rgb.lab=function(A){const e=r.rgb.xyz(A);let t=e[0],i=e[1],g=e[2];return i/=100,g/=108.883,t=(t/=95.047)>.008856?t**(1/3):7.787*t+16/116,[116*(i=i>.008856?i**(1/3):7.787*i+16/116)-16,500*(t-i),200*(i-(g=g>.008856?g**(1/3):7.787*g+16/116))]},r.hsl.rgb=function(A){const e=A[0]/360,t=A[1]/100,i=A[2]/100;let g,r,n;if(0===t)return[n=255*i,n,n];const B=2*i-(g=i<.5?i*(1+t):i+t-i*t),I=[0,0,0];for(let A=0;A<3;A++)(r=e+1/3*-(A-1))<0&&r++,r>1&&r--,n=6*r<1?B+6*(g-B)*r:2*r<1?g:3*r<2?B+(g-B)*(2/3-r)*6:B,I[A]=255*n;return I},r.hsl.hsv=function(A){const e=A[0];let t=A[1]/100,i=A[2]/100,g=t;const r=Math.max(i,.01);return t*=(i*=2)<=1?i:2-i,g*=r<=1?r:2-r,[e,100*(0===i?2*g/(r+g):2*t/(i+t)),100*((i+t)/2)]},r.hsv.rgb=function(A){const e=A[0]/60,t=A[1]/100;let i=A[2]/100;const g=Math.floor(e)%6,r=e-Math.floor(e),n=255*i*(1-t),B=255*i*(1-t*r),I=255*i*(1-t*(1-r));switch(i*=255,g){case 0:return[i,I,n];case 1:return[B,i,n];case 2:return[n,i,I];case 3:return[n,B,i];case 4:return[I,n,i];case 5:return[i,n,B]}},r.hsv.hsl=function(A){const e=A[0],t=A[1]/100,i=A[2]/100,g=Math.max(i,.01);let r,n;n=(2-t)*i;const B=(2-t)*g;return r=t*g,[e,100*(r=(r/=B<=1?B:2-B)||0),100*(n/=2)]},r.hwb.rgb=function(A){const e=A[0]/360;let t=A[1]/100,i=A[2]/100;const g=t+i;let r;g>1&&(t/=g,i/=g);const n=Math.floor(6*e),B=1-i;r=6*e-n,0!=(1&n)&&(r=1-r);const I=t+r*(B-t);let o,a,Q;switch(n){default:case 6:case 0:o=B,a=I,Q=t;break;case 1:o=I,a=B,Q=t;break;case 2:o=t,a=B,Q=I;break;case 3:o=t,a=I,Q=B;break;case 4:o=I,a=t,Q=B;break;case 5:o=B,a=t,Q=I}return[255*o,255*a,255*Q]},r.cmyk.rgb=function(A){const e=A[0]/100,t=A[1]/100,i=A[2]/100,g=A[3]/100;return[255*(1-Math.min(1,e*(1-g)+g)),255*(1-Math.min(1,t*(1-g)+g)),255*(1-Math.min(1,i*(1-g)+g))]},r.xyz.rgb=function(A){const e=A[0]/100,t=A[1]/100,i=A[2]/100;let g,r,n;return r=-.9689*e+1.8758*t+.0415*i,n=.0557*e+-.204*t+1.057*i,g=(g=3.2406*e+-1.5372*t+-.4986*i)>.0031308?1.055*g**(1/2.4)-.055:12.92*g,r=r>.0031308?1.055*r**(1/2.4)-.055:12.92*r,n=n>.0031308?1.055*n**(1/2.4)-.055:12.92*n,[255*(g=Math.min(Math.max(0,g),1)),255*(r=Math.min(Math.max(0,r),1)),255*(n=Math.min(Math.max(0,n),1))]},r.xyz.lab=function(A){let e=A[0],t=A[1],i=A[2];return t/=100,i/=108.883,e=(e/=95.047)>.008856?e**(1/3):7.787*e+16/116,[116*(t=t>.008856?t**(1/3):7.787*t+16/116)-16,500*(e-t),200*(t-(i=i>.008856?i**(1/3):7.787*i+16/116))]},r.lab.xyz=function(A){const e=A[0],t=A[1],i=A[2];let g,r,n;const B=(r=(e+16)/116)**3,I=(g=t/500+r)**3,o=(n=r-i/200)**3;return r=B>.008856?B:(r-16/116)/7.787,g=I>.008856?I:(g-16/116)/7.787,n=o>.008856?o:(n-16/116)/7.787,[g*=95.047,r*=100,n*=108.883]},r.lab.lch=function(A){const e=A[0],t=A[1],i=A[2];let g;return(g=360*Math.atan2(i,t)/2/Math.PI)<0&&(g+=360),[e,Math.sqrt(t*t+i*i),g]},r.lch.lab=function(A){const e=A[0],t=A[1],i=A[2]/360*2*Math.PI;return[e,t*Math.cos(i),t*Math.sin(i)]},r.rgb.ansi16=function(A,e=null){const[t,i,g]=A;let n=null===e?r.rgb.hsv(A)[2]:e;if(0===(n=Math.round(n/50)))return 30;let B=30+(Math.round(g/255)<<2|Math.round(i/255)<<1|Math.round(t/255));return 2===n&&(B+=60),B},r.hsv.ansi16=function(A){return r.rgb.ansi16(r.hsv.rgb(A),A[2])},r.rgb.ansi256=function(A){const e=A[0],t=A[1],i=A[2];return e===t&&t===i?e<8?16:e>248?231:Math.round((e-8)/247*24)+232:16+36*Math.round(e/255*5)+6*Math.round(t/255*5)+Math.round(i/255*5)},r.ansi16.rgb=function(A){let e=A%10;if(0===e||7===e)return A>50&&(e+=3.5),[e=e/10.5*255,e,e];const t=.5*(1+~~(A>50));return[(1&e)*t*255,(e>>1&1)*t*255,(e>>2&1)*t*255]},r.ansi256.rgb=function(A){if(A>=232){const e=10*(A-232)+8;return[e,e,e]}let e;return A-=16,[Math.floor(A/36)/5*255,Math.floor((e=A%36)/6)/5*255,e%6/5*255]},r.rgb.hex=function(A){const e=(((255&Math.round(A[0]))<<16)+((255&Math.round(A[1]))<<8)+(255&Math.round(A[2]))).toString(16).toUpperCase();return"000000".substring(e.length)+e},r.hex.rgb=function(A){const e=A.toString(16).match(/[a-f0-9]{6}|[a-f0-9]{3}/i);if(!e)return[0,0,0];let t=e[0];3===e[0].length&&(t=t.split("").map(A=>A+A).join(""));const i=parseInt(t,16);return[i>>16&255,i>>8&255,255&i]},r.rgb.hcg=function(A){const e=A[0]/255,t=A[1]/255,i=A[2]/255,g=Math.max(Math.max(e,t),i),r=Math.min(Math.min(e,t),i),n=g-r;let B,I;return B=n<1?r/(1-n):0,I=n<=0?0:g===e?(t-i)/n%6:g===t?2+(i-e)/n:4+(e-t)/n,I/=6,[360*(I%=1),100*n,100*B]},r.hsl.hcg=function(A){const e=A[1]/100,t=A[2]/100,i=t<.5?2*e*t:2*e*(1-t);let g=0;return i<1&&(g=(t-.5*i)/(1-i)),[A[0],100*i,100*g]},r.hsv.hcg=function(A){const e=A[1]/100,t=A[2]/100,i=e*t;let g=0;return i<1&&(g=(t-i)/(1-i)),[A[0],100*i,100*g]},r.hcg.rgb=function(A){const e=A[0]/360,t=A[1]/100,i=A[2]/100;if(0===t)return[255*i,255*i,255*i];const g=[0,0,0],r=e%1*6,n=r%1,B=1-n;let I=0;switch(Math.floor(r)){case 0:g[0]=1,g[1]=n,g[2]=0;break;case 1:g[0]=B,g[1]=1,g[2]=0;break;case 2:g[0]=0,g[1]=1,g[2]=n;break;case 3:g[0]=0,g[1]=B,g[2]=1;break;case 4:g[0]=n,g[1]=0,g[2]=1;break;default:g[0]=1,g[1]=0,g[2]=B}return I=(1-t)*i,[255*(t*g[0]+I),255*(t*g[1]+I),255*(t*g[2]+I)]},r.hcg.hsv=function(A){const e=A[1]/100,t=e+A[2]/100*(1-e);let i=0;return t>0&&(i=e/t),[A[0],100*i,100*t]},r.hcg.hsl=function(A){const e=A[1]/100,t=A[2]/100*(1-e)+.5*e;let i=0;return t>0&&t<.5?i=e/(2*t):t>=.5&&t<1&&(i=e/(2*(1-t))),[A[0],100*i,100*t]},r.hcg.hwb=function(A){const e=A[1]/100,t=e+A[2]/100*(1-e);return[A[0],100*(t-e),100*(1-t)]},r.hwb.hcg=function(A){const e=A[1]/100,t=1-A[2]/100,i=t-e;let g=0;return i<1&&(g=(t-i)/(1-i)),[A[0],100*i,100*g]},r.apple.rgb=function(A){return[A[0]/65535*255,A[1]/65535*255,A[2]/65535*255]},r.rgb.apple=function(A){return[A[0]/255*65535,A[1]/255*65535,A[2]/255*65535]},r.gray.rgb=function(A){return[A[0]/100*255,A[0]/100*255,A[0]/100*255]},r.gray.hsl=function(A){return[0,0,A[0]]},r.gray.hsv=r.gray.hsl,r.gray.hwb=function(A){return[0,100,A[0]]},r.gray.cmyk=function(A){return[0,0,0,A[0]]},r.gray.lab=function(A){return[A[0],0,0]},r.gray.hex=function(A){const e=255&Math.round(A[0]/100*255),t=((e<<16)+(e<<8)+e).toString(16).toUpperCase();return"000000".substring(t.length)+t},r.rgb.gray=function(A){return[(A[0]+A[1]+A[2])/3/255*100]}},{"color-name":319}],309:[function(A,e,t){const i=A("./conversions"),g=A("./route"),r={};Object.keys(i).forEach(A=>{r[A]={},Object.defineProperty(r[A],"channels",{value:i[A].channels}),Object.defineProperty(r[A],"labels",{value:i[A].labels});const e=g(A);Object.keys(e).forEach(t=>{const i=e[t];r[A][t]=function(A){const e=function(...e){const t=e[0];if(void 0===t||null===t)return t;t.length>1&&(e=t);const i=A(e);if("object"==typeof i)for(let A=i.length,e=0;e1&&(e=t),A(e))};return"conversion"in A&&(e.conversion=A.conversion),e}(i)})}),e.exports=r},{"./conversions":308,"./route":310}],310:[function(A,e,t){const i=A("./conversions");function g(A){const e=function(){const A={},e=Object.keys(i);for(let t=e.length,i=0;i=255)throw new TypeError("Alphabet too long");for(var e=new Uint8Array(256),t=0;t>>0,a=new Uint8Array(n);A[t];){var Q=e[A.charCodeAt(t)];if(255===Q)return;for(var C=0,s=n-1;(0!==Q||C>>0,a[s]=Q%256>>>0,Q=Q/256>>>0;if(0!==Q)throw new Error("Non-zero carry");r=C,t++}if(" "!==A[t]){for(var c=n-r;c!==n&&0===a[c];)c++;var h=i.allocUnsafe(g+(n-c));h.fill(0,0,g);for(var f=g;c!==n;)h[f++]=a[c++];return h}}}return{encode:function(e){if((Array.isArray(e)||e instanceof Uint8Array)&&(e=i.from(e)),!i.isBuffer(e))throw new TypeError("Expected Buffer");if(0===e.length)return"";for(var t=0,g=0,r=0,n=e.length;r!==n&&0===e[r];)r++,t++;for(var o=(n-r)*a+1>>>0,Q=new Uint8Array(o);r!==n;){for(var C=e[r],s=0,c=o-1;(0!==C||s>>0,Q[c]=C%B>>>0,C=C/B>>>0;if(0!==C)throw new Error("Non-zero carry");g=s,r++}for(var h=o-g;h!==o&&0===Q[h];)h++;for(var f=I.repeat(t);h=4294967296&&g++,A[e]=i,A[e+1]=g}function r(A,e,t,i){var g=A[e]+t;t<0&&(g+=4294967296);var r=A[e+1]+i;g>=4294967296&&r++,A[e]=g,A[e+1]=r}function n(A,e){return A[e]^A[e+1]<<8^A[e+2]<<16^A[e+3]<<24}function B(A,e,t,i,n,B){var I=Q[n],o=Q[n+1],C=Q[B],s=Q[B+1];g(a,A,e),r(a,A,I,o);var c=a[i]^a[A],h=a[i+1]^a[A+1];a[i]=h,a[i+1]=c,g(a,t,i),c=a[e]^a[t],h=a[e+1]^a[t+1],a[e]=c>>>24^h<<8,a[e+1]=h>>>24^c<<8,g(a,A,e),r(a,A,C,s),c=a[i]^a[A],h=a[i+1]^a[A+1],a[i]=c>>>16^h<<16,a[i+1]=h>>>16^c<<16,g(a,t,i),c=a[e]^a[t],h=a[e+1]^a[t+1],a[e]=h>>>31^c<<1,a[e+1]=c>>>31^h<<1}var I=new Uint32Array([4089235720,1779033703,2227873595,3144134277,4271175723,1013904242,1595750129,2773480762,2917565137,1359893119,725511199,2600822924,4215389547,528734635,327033209,1541459225]),o=new Uint8Array([0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,10,4,8,9,15,13,6,1,12,0,2,11,7,5,3,11,8,12,0,5,2,15,13,10,14,3,6,7,1,9,4,7,9,3,1,13,12,11,14,2,6,5,10,4,0,15,8,9,0,5,7,2,4,10,15,14,1,11,12,6,8,3,13,2,12,6,10,0,11,8,3,4,13,7,5,15,14,1,9,12,5,1,15,14,13,4,10,0,7,6,3,9,2,8,11,13,11,7,14,12,1,3,9,5,0,15,4,8,6,2,10,6,15,14,9,11,3,0,8,12,2,13,7,1,4,10,5,10,2,8,4,7,6,1,5,15,11,9,14,3,12,13,0,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,10,4,8,9,15,13,6,1,12,0,2,11,7,5,3].map(function(A){return 2*A})),a=new Uint32Array(32),Q=new Uint32Array(32);function C(A,e){var t=0;for(t=0;t<16;t++)a[t]=A.h[t],a[t+16]=I[t];for(a[24]=a[24]^A.t,a[25]=a[25]^A.t/4294967296,e&&(a[28]=~a[28],a[29]=~a[29]),t=0;t<32;t++)Q[t]=n(A.b,4*t);for(t=0;t<12;t++)B(0,8,16,24,o[16*t+0],o[16*t+1]),B(2,10,18,26,o[16*t+2],o[16*t+3]),B(4,12,20,28,o[16*t+4],o[16*t+5]),B(6,14,22,30,o[16*t+6],o[16*t+7]),B(0,10,20,30,o[16*t+8],o[16*t+9]),B(2,12,22,24,o[16*t+10],o[16*t+11]),B(4,14,16,26,o[16*t+12],o[16*t+13]),B(6,8,18,28,o[16*t+14],o[16*t+15]);for(t=0;t<16;t++)A.h[t]=A.h[t]^a[t]^a[t+16]}function s(A,e){if(0===A||A>64)throw new Error("Illegal output length, expected 0 < length <= 64");if(e&&e.length>64)throw new Error("Illegal key, expected Uint8Array with 0 < length <= 64");for(var t={b:new Uint8Array(128),h:new Uint32Array(16),t:0,c:0,outlen:A},i=0;i<16;i++)t.h[i]=I[i];var g=e?e.length:0;return t.h[0]^=16842752^g<<8^A,e&&(c(t,e),t.c=128),t}function c(A,e){for(var t=0;t>2]>>8*(3&t);return e}function f(A,e,t){t=t||64,A=i.normalizeInput(A);var g=s(t,e);return c(g,A),h(g)}e.exports={blake2b:f,blake2bHex:function(A,e,t){var g=f(A,e,t);return i.toHex(g)},blake2bInit:s,blake2bUpdate:c,blake2bFinal:h}},{"./util":315}],313:[function(A,e,t){var i=A("./util");function g(A,e){return A[e]^A[e+1]<<8^A[e+2]<<16^A[e+3]<<24}function r(A,e,t,i,g,r){o[A]=o[A]+o[e]+g,o[i]=n(o[i]^o[A],16),o[t]=o[t]+o[i],o[e]=n(o[e]^o[t],12),o[A]=o[A]+o[e]+r,o[i]=n(o[i]^o[A],8),o[t]=o[t]+o[i],o[e]=n(o[e]^o[t],7)}function n(A,e){return A>>>e^A<<32-e}var B=new Uint32Array([1779033703,3144134277,1013904242,2773480762,1359893119,2600822924,528734635,1541459225]),I=new Uint8Array([0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,10,4,8,9,15,13,6,1,12,0,2,11,7,5,3,11,8,12,0,5,2,15,13,10,14,3,6,7,1,9,4,7,9,3,1,13,12,11,14,2,6,5,10,4,0,15,8,9,0,5,7,2,4,10,15,14,1,11,12,6,8,3,13,2,12,6,10,0,11,8,3,4,13,7,5,15,14,1,9,12,5,1,15,14,13,4,10,0,7,6,3,9,2,8,11,13,11,7,14,12,1,3,9,5,0,15,4,8,6,2,10,6,15,14,9,11,3,0,8,12,2,13,7,1,4,10,5,10,2,8,4,7,6,1,5,15,11,9,14,3,12,13,0]),o=new Uint32Array(16),a=new Uint32Array(16);function Q(A,e){var t=0;for(t=0;t<8;t++)o[t]=A.h[t],o[t+8]=B[t];for(o[12]^=A.t,o[13]^=A.t/4294967296,e&&(o[14]=~o[14]),t=0;t<16;t++)a[t]=g(A.b,4*t);for(t=0;t<10;t++)r(0,4,8,12,a[I[16*t+0]],a[I[16*t+1]]),r(1,5,9,13,a[I[16*t+2]],a[I[16*t+3]]),r(2,6,10,14,a[I[16*t+4]],a[I[16*t+5]]),r(3,7,11,15,a[I[16*t+6]],a[I[16*t+7]]),r(0,5,10,15,a[I[16*t+8]],a[I[16*t+9]]),r(1,6,11,12,a[I[16*t+10]],a[I[16*t+11]]),r(2,7,8,13,a[I[16*t+12]],a[I[16*t+13]]),r(3,4,9,14,a[I[16*t+14]],a[I[16*t+15]]);for(t=0;t<8;t++)A.h[t]^=o[t]^o[t+8]}function C(A,e){if(!(A>0&&A<=32))throw new Error("Incorrect output length, should be in [1, 32]");var t=e?e.length:0;if(e&&!(t>0&&t<=32))throw new Error("Incorrect key length, should be in [1, 32]");var i={h:new Uint32Array(B),b:new Uint32Array(64),c:0,t:0,outlen:A};return i.h[0]^=16842752^t<<8^A,t>0&&(s(i,e),i.c=64),i}function s(A,e){for(var t=0;t>2]>>8*(3&t)&255;return e}function h(A,e,t){t=t||32,A=i.normalizeInput(A);var g=C(t,e);return s(g,A),c(g)}e.exports={blake2s:h,blake2sHex:function(A,e,t){var g=h(A,e,t);return i.toHex(g)},blake2sInit:C,blake2sUpdate:s,blake2sFinal:c}},{"./util":315}],314:[function(A,e,t){var i=A("./blake2b"),g=A("./blake2s");e.exports={blake2b:i.blake2b,blake2bHex:i.blake2bHex,blake2bInit:i.blake2bInit,blake2bUpdate:i.blake2bUpdate,blake2bFinal:i.blake2bFinal,blake2s:g.blake2s,blake2sHex:g.blake2sHex,blake2sInit:g.blake2sInit,blake2sUpdate:g.blake2sUpdate,blake2sFinal:g.blake2sFinal}},{"./blake2b":312,"./blake2s":313}],315:[function(A,e,t){(function(A){var t="Input must be an string, Buffer or Uint8Array";function i(A){return(4294967296+A).toString(16).substring(1)}e.exports={normalizeInput:function(e){var i;if(e instanceof Uint8Array)i=e;else if(e instanceof A)i=new Uint8Array(e);else{if("string"!=typeof e)throw new Error(t);i=new Uint8Array(A.from(e,"utf8"))}return i},toHex:function(A){return Array.prototype.map.call(A,function(A){return(A<16?"0":"")+A.toString(16)}).join("")},debugPrint:function(A,e,t){for(var g="\n"+A+" = ",r=0;r=49&&o<=54?o-49+10:o>=17&&o<=22?o-17+10:o,n|=I}return i(!(240&n),"Invalid character in "+A),g}function I(A,e,t,g){for(var r=0,n=0,B=Math.min(A.length,t),I=e;I=49?o-49+10:o>=17?o-17+10:o,i(o>=0&&n"}r.isBN=function(A){return A instanceof r||null!==A&&"object"==typeof A&&A.constructor.wordSize===r.wordSize&&Array.isArray(A.words)},r.max=function(A,e){return A.cmp(e)>0?A:e},r.min=function(A,e){return A.cmp(e)<0?A:e},r.prototype._init=function(A,e,t){if("number"==typeof A)return this._initNumber(A,e,t);if("object"==typeof A)return this._initArray(A,e,t);"hex"===e&&(e=16),i(e===(0|e)&&e>=2&&e<=36);var g=0;"-"===(A=A.toString().replace(/\s+/g,""))[0]&&g++,16===e?this._parseHex(A,g):this._parseBase(A,e,g),"-"===A[0]&&(this.negative=1),this._strip(),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initNumber=function(A,e,t){A<0&&(this.negative=1,A=-A),A<67108864?(this.words=[67108863&A],this.length=1):A<4503599627370496?(this.words=[67108863&A,A/67108864&67108863],this.length=2):(i(A<9007199254740992),this.words=[67108863&A,A/67108864&67108863,1],this.length=3),"le"===t&&this._initArray(this.toArray(),e,t)},r.prototype._initArray=function(A,e,t){if(i("number"==typeof A.length),A.length<=0)return this.words=[0],this.length=1,this;this.length=Math.ceil(A.length/3),this.words=new Array(this.length);for(var g=0;g=0;g-=3)n=A[g]|A[g-1]<<8|A[g-2]<<16,this.words[r]|=n<>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);else if("le"===t)for(g=0,r=0;g>>26-B&67108863,(B+=24)>=26&&(B-=26,r++);return this._strip()},r.prototype._parseHex=function(A,e){this.length=Math.ceil((A.length-e)/6),this.words=new Array(this.length);for(var t=0;t=e;t-=6)g=B(A,t,t+6),this.words[i]|=g<>>26-r&4194303,(r+=24)>=26&&(r-=26,i++);t+6!==e&&(g=B(A,e,t+6),this.words[i]|=g<>>26-r&4194303),this._strip()},r.prototype._parseBase=function(A,e,t){this.words=[0],this.length=1;for(var i=0,g=1;g<=67108863;g*=e)i++;i--,g=g/e|0;for(var r=A.length-t,n=r%i,B=Math.min(r,r-n)+t,o=0,a=t;a1&&0===this.words[this.length-1];)this.length--;return this._normSign()},r.prototype._normSign=function(){return 1===this.length&&0===this.words[0]&&(this.negative=0),this},"undefined"!=typeof Symbol&&"function"==typeof Symbol.for?r.prototype[Symbol.for("nodejs.util.inspect.custom")]=a:r.prototype.inspect=a;var Q=["","0","00","000","0000","00000","000000","0000000","00000000","000000000","0000000000","00000000000","000000000000","0000000000000","00000000000000","000000000000000","0000000000000000","00000000000000000","000000000000000000","0000000000000000000","00000000000000000000","000000000000000000000","0000000000000000000000","00000000000000000000000","000000000000000000000000","0000000000000000000000000"],C=[0,0,25,16,12,11,10,9,8,8,7,7,7,7,6,6,6,6,6,6,6,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5],s=[0,0,33554432,43046721,16777216,48828125,60466176,40353607,16777216,43046721,1e7,19487171,35831808,62748517,7529536,11390625,16777216,24137569,34012224,47045881,64e6,4084101,5153632,6436343,7962624,9765625,11881376,14348907,17210368,20511149,243e5,28629151,33554432,39135393,45435424,52521875,60466176];r.prototype.toString=function(A,e){var t;if(A=A||10,e=0|e||1,16===A||"hex"===A){t="";for(var g=0,r=0,n=0;n>>24-g&16777215)||n!==this.length-1?Q[6-I.length]+I+t:I+t,(g+=2)>=26&&(g-=26,n--)}for(0!==r&&(t=r.toString(16)+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}if(A===(0|A)&&A>=2&&A<=36){var o=C[A],a=s[A];t="";var c=this.clone();for(c.negative=0;!c.isZero();){var h=c.modrn(a).toString(A);t=(c=c.idivn(a)).isZero()?h+t:Q[o-h.length]+h+t}for(this.isZero()&&(t="0"+t);t.length%e!=0;)t="0"+t;return 0!==this.negative&&(t="-"+t),t}i(!1,"Base should be between 2 and 36")},r.prototype.toNumber=function(){var A=this.words[0];return 2===this.length?A+=67108864*this.words[1]:3===this.length&&1===this.words[2]?A+=4503599627370496+67108864*this.words[1]:this.length>2&&i(!1,"Number can only safely store up to 53 bits"),0!==this.negative?-A:A},r.prototype.toJSON=function(){return this.toString(16,2)},n&&(r.prototype.toBuffer=function(A,e){return this.toArrayLike(n,A,e)}),r.prototype.toArray=function(A,e){return this.toArrayLike(Array,A,e)};function c(A,e,t){t.negative=e.negative^A.negative;var i=A.length+e.length|0;t.length=i,i=i-1|0;var g=0|A.words[0],r=0|e.words[0],n=g*r,B=67108863&n,I=n/67108864|0;t.words[0]=B;for(var o=1;o>>26,Q=67108863&I,C=Math.min(o,e.length-1),s=Math.max(0,o-A.length+1);s<=C;s++){var c=o-s|0;a+=(n=(g=0|A.words[c])*(r=0|e.words[s])+Q)/67108864|0,Q=67108863&n}t.words[o]=0|Q,I=0|a}return 0!==I?t.words[o]=0|I:t.length--,t._strip()}r.prototype.toArrayLike=function(A,e,t){this._strip();var g=this.byteLength(),r=t||Math.max(1,g);i(g<=r,"byte array longer than desired length"),i(r>0,"Requested array length <= 0");var n=function(A,e){return A.allocUnsafe?A.allocUnsafe(e):new A(e)}(A,r);return this["_toArrayLike"+("le"===e?"LE":"BE")](n,g),n},r.prototype._toArrayLikeLE=function(A,e){for(var t=0,i=0,g=0,r=0;g>8&255),t>16&255),6===r?(t>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t=0&&(A[t--]=n>>8&255),t>=0&&(A[t--]=n>>16&255),6===r?(t>=0&&(A[t--]=n>>24&255),i=0,r=0):(i=n>>>24,r+=2)}if(t>=0)for(A[t--]=i;t>=0;)A[t--]=0},Math.clz32?r.prototype._countBits=function(A){return 32-Math.clz32(A)}:r.prototype._countBits=function(A){var e=A,t=0;return e>=4096&&(t+=13,e>>>=13),e>=64&&(t+=7,e>>>=7),e>=8&&(t+=4,e>>>=4),e>=2&&(t+=2,e>>>=2),t+e},r.prototype._zeroBits=function(A){if(0===A)return 26;var e=A,t=0;return 0==(8191&e)&&(t+=13,e>>>=13),0==(127&e)&&(t+=7,e>>>=7),0==(15&e)&&(t+=4,e>>>=4),0==(3&e)&&(t+=2,e>>>=2),0==(1&e)&&t++,t},r.prototype.bitLength=function(){var A=this.words[this.length-1],e=this._countBits(A);return 26*(this.length-1)+e},r.prototype.zeroBits=function(){if(this.isZero())return 0;for(var A=0,e=0;eA.length?this.clone().ior(A):A.clone().ior(this)},r.prototype.uor=function(A){return this.length>A.length?this.clone().iuor(A):A.clone().iuor(this)},r.prototype.iuand=function(A){var e;e=this.length>A.length?A:this;for(var t=0;tA.length?this.clone().iand(A):A.clone().iand(this)},r.prototype.uand=function(A){return this.length>A.length?this.clone().iuand(A):A.clone().iuand(this)},r.prototype.iuxor=function(A){var e,t;this.length>A.length?(e=this,t=A):(e=A,t=this);for(var i=0;iA.length?this.clone().ixor(A):A.clone().ixor(this)},r.prototype.uxor=function(A){return this.length>A.length?this.clone().iuxor(A):A.clone().iuxor(this)},r.prototype.inotn=function(A){i("number"==typeof A&&A>=0);var e=0|Math.ceil(A/26),t=A%26;this._expand(e),t>0&&e--;for(var g=0;g0&&(this.words[g]=~this.words[g]&67108863>>26-t),this._strip()},r.prototype.notn=function(A){return this.clone().inotn(A)},r.prototype.setn=function(A,e){i("number"==typeof A&&A>=0);var t=A/26|0,g=A%26;return this._expand(t+1),this.words[t]=e?this.words[t]|1<A.length?(t=this,i=A):(t=A,i=this);for(var g=0,r=0;r>>26;for(;0!==g&&r>>26;if(this.length=t.length,0!==g)this.words[this.length]=g,this.length++;else if(t!==this)for(;rA.length?this.clone().iadd(A):A.clone().iadd(this)},r.prototype.isub=function(A){if(0!==A.negative){A.negative=0;var e=this.iadd(A);return A.negative=1,e._normSign()}if(0!==this.negative)return this.negative=0,this.iadd(A),this.negative=1,this._normSign();var t,i,g=this.cmp(A);if(0===g)return this.negative=0,this.length=1,this.words[0]=0,this;g>0?(t=this,i=A):(t=A,i=this);for(var r=0,n=0;n>26,this.words[n]=67108863&e;for(;0!==r&&n>26,this.words[n]=67108863&e;if(0===r&&n>>13,s=0|n[1],c=8191&s,h=s>>>13,f=0|n[2],E=8191&f,u=f>>>13,d=0|n[3],l=8191&d,w=d>>>13,p=0|n[4],D=8191&p,b=p>>>13,y=0|n[5],M=8191&y,m=y>>>13,G=0|n[6],k=8191&G,F=G>>>13,N=0|n[7],S=8191&N,Y=N>>>13,v=0|n[8],K=8191&v,U=v>>>13,J=0|n[9],H=8191&J,R=J>>>13,q=0|B[0],L=8191&q,x=q>>>13,Z=0|B[1],j=8191&Z,W=Z>>>13,O=0|B[2],P=8191&O,V=O>>>13,X=0|B[3],z=8191&X,T=X>>>13,_=0|B[4],$=8191&_,AA=_>>>13,eA=0|B[5],tA=8191&eA,iA=eA>>>13,gA=0|B[6],rA=8191&gA,nA=gA>>>13,BA=0|B[7],IA=8191&BA,oA=BA>>>13,aA=0|B[8],QA=8191&aA,CA=aA>>>13,sA=0|B[9],cA=8191&sA,hA=sA>>>13;t.negative=A.negative^e.negative,t.length=19;var fA=(o+(i=Math.imul(Q,L))|0)+((8191&(g=(g=Math.imul(Q,x))+Math.imul(C,L)|0))<<13)|0;o=((r=Math.imul(C,x))+(g>>>13)|0)+(fA>>>26)|0,fA&=67108863,i=Math.imul(c,L),g=(g=Math.imul(c,x))+Math.imul(h,L)|0,r=Math.imul(h,x);var EA=(o+(i=i+Math.imul(Q,j)|0)|0)+((8191&(g=(g=g+Math.imul(Q,W)|0)+Math.imul(C,j)|0))<<13)|0;o=((r=r+Math.imul(C,W)|0)+(g>>>13)|0)+(EA>>>26)|0,EA&=67108863,i=Math.imul(E,L),g=(g=Math.imul(E,x))+Math.imul(u,L)|0,r=Math.imul(u,x),i=i+Math.imul(c,j)|0,g=(g=g+Math.imul(c,W)|0)+Math.imul(h,j)|0,r=r+Math.imul(h,W)|0;var uA=(o+(i=i+Math.imul(Q,P)|0)|0)+((8191&(g=(g=g+Math.imul(Q,V)|0)+Math.imul(C,P)|0))<<13)|0;o=((r=r+Math.imul(C,V)|0)+(g>>>13)|0)+(uA>>>26)|0,uA&=67108863,i=Math.imul(l,L),g=(g=Math.imul(l,x))+Math.imul(w,L)|0,r=Math.imul(w,x),i=i+Math.imul(E,j)|0,g=(g=g+Math.imul(E,W)|0)+Math.imul(u,j)|0,r=r+Math.imul(u,W)|0,i=i+Math.imul(c,P)|0,g=(g=g+Math.imul(c,V)|0)+Math.imul(h,P)|0,r=r+Math.imul(h,V)|0;var dA=(o+(i=i+Math.imul(Q,z)|0)|0)+((8191&(g=(g=g+Math.imul(Q,T)|0)+Math.imul(C,z)|0))<<13)|0;o=((r=r+Math.imul(C,T)|0)+(g>>>13)|0)+(dA>>>26)|0,dA&=67108863,i=Math.imul(D,L),g=(g=Math.imul(D,x))+Math.imul(b,L)|0,r=Math.imul(b,x),i=i+Math.imul(l,j)|0,g=(g=g+Math.imul(l,W)|0)+Math.imul(w,j)|0,r=r+Math.imul(w,W)|0,i=i+Math.imul(E,P)|0,g=(g=g+Math.imul(E,V)|0)+Math.imul(u,P)|0,r=r+Math.imul(u,V)|0,i=i+Math.imul(c,z)|0,g=(g=g+Math.imul(c,T)|0)+Math.imul(h,z)|0,r=r+Math.imul(h,T)|0;var lA=(o+(i=i+Math.imul(Q,$)|0)|0)+((8191&(g=(g=g+Math.imul(Q,AA)|0)+Math.imul(C,$)|0))<<13)|0;o=((r=r+Math.imul(C,AA)|0)+(g>>>13)|0)+(lA>>>26)|0,lA&=67108863,i=Math.imul(M,L),g=(g=Math.imul(M,x))+Math.imul(m,L)|0,r=Math.imul(m,x),i=i+Math.imul(D,j)|0,g=(g=g+Math.imul(D,W)|0)+Math.imul(b,j)|0,r=r+Math.imul(b,W)|0,i=i+Math.imul(l,P)|0,g=(g=g+Math.imul(l,V)|0)+Math.imul(w,P)|0,r=r+Math.imul(w,V)|0,i=i+Math.imul(E,z)|0,g=(g=g+Math.imul(E,T)|0)+Math.imul(u,z)|0,r=r+Math.imul(u,T)|0,i=i+Math.imul(c,$)|0,g=(g=g+Math.imul(c,AA)|0)+Math.imul(h,$)|0,r=r+Math.imul(h,AA)|0;var wA=(o+(i=i+Math.imul(Q,tA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,iA)|0)+Math.imul(C,tA)|0))<<13)|0;o=((r=r+Math.imul(C,iA)|0)+(g>>>13)|0)+(wA>>>26)|0,wA&=67108863,i=Math.imul(k,L),g=(g=Math.imul(k,x))+Math.imul(F,L)|0,r=Math.imul(F,x),i=i+Math.imul(M,j)|0,g=(g=g+Math.imul(M,W)|0)+Math.imul(m,j)|0,r=r+Math.imul(m,W)|0,i=i+Math.imul(D,P)|0,g=(g=g+Math.imul(D,V)|0)+Math.imul(b,P)|0,r=r+Math.imul(b,V)|0,i=i+Math.imul(l,z)|0,g=(g=g+Math.imul(l,T)|0)+Math.imul(w,z)|0,r=r+Math.imul(w,T)|0,i=i+Math.imul(E,$)|0,g=(g=g+Math.imul(E,AA)|0)+Math.imul(u,$)|0,r=r+Math.imul(u,AA)|0,i=i+Math.imul(c,tA)|0,g=(g=g+Math.imul(c,iA)|0)+Math.imul(h,tA)|0,r=r+Math.imul(h,iA)|0;var pA=(o+(i=i+Math.imul(Q,rA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,nA)|0)+Math.imul(C,rA)|0))<<13)|0;o=((r=r+Math.imul(C,nA)|0)+(g>>>13)|0)+(pA>>>26)|0,pA&=67108863,i=Math.imul(S,L),g=(g=Math.imul(S,x))+Math.imul(Y,L)|0,r=Math.imul(Y,x),i=i+Math.imul(k,j)|0,g=(g=g+Math.imul(k,W)|0)+Math.imul(F,j)|0,r=r+Math.imul(F,W)|0,i=i+Math.imul(M,P)|0,g=(g=g+Math.imul(M,V)|0)+Math.imul(m,P)|0,r=r+Math.imul(m,V)|0,i=i+Math.imul(D,z)|0,g=(g=g+Math.imul(D,T)|0)+Math.imul(b,z)|0,r=r+Math.imul(b,T)|0,i=i+Math.imul(l,$)|0,g=(g=g+Math.imul(l,AA)|0)+Math.imul(w,$)|0,r=r+Math.imul(w,AA)|0,i=i+Math.imul(E,tA)|0,g=(g=g+Math.imul(E,iA)|0)+Math.imul(u,tA)|0,r=r+Math.imul(u,iA)|0,i=i+Math.imul(c,rA)|0,g=(g=g+Math.imul(c,nA)|0)+Math.imul(h,rA)|0,r=r+Math.imul(h,nA)|0;var DA=(o+(i=i+Math.imul(Q,IA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,oA)|0)+Math.imul(C,IA)|0))<<13)|0;o=((r=r+Math.imul(C,oA)|0)+(g>>>13)|0)+(DA>>>26)|0,DA&=67108863,i=Math.imul(K,L),g=(g=Math.imul(K,x))+Math.imul(U,L)|0,r=Math.imul(U,x),i=i+Math.imul(S,j)|0,g=(g=g+Math.imul(S,W)|0)+Math.imul(Y,j)|0,r=r+Math.imul(Y,W)|0,i=i+Math.imul(k,P)|0,g=(g=g+Math.imul(k,V)|0)+Math.imul(F,P)|0,r=r+Math.imul(F,V)|0,i=i+Math.imul(M,z)|0,g=(g=g+Math.imul(M,T)|0)+Math.imul(m,z)|0,r=r+Math.imul(m,T)|0,i=i+Math.imul(D,$)|0,g=(g=g+Math.imul(D,AA)|0)+Math.imul(b,$)|0,r=r+Math.imul(b,AA)|0,i=i+Math.imul(l,tA)|0,g=(g=g+Math.imul(l,iA)|0)+Math.imul(w,tA)|0,r=r+Math.imul(w,iA)|0,i=i+Math.imul(E,rA)|0,g=(g=g+Math.imul(E,nA)|0)+Math.imul(u,rA)|0,r=r+Math.imul(u,nA)|0,i=i+Math.imul(c,IA)|0,g=(g=g+Math.imul(c,oA)|0)+Math.imul(h,IA)|0,r=r+Math.imul(h,oA)|0;var bA=(o+(i=i+Math.imul(Q,QA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,CA)|0)+Math.imul(C,QA)|0))<<13)|0;o=((r=r+Math.imul(C,CA)|0)+(g>>>13)|0)+(bA>>>26)|0,bA&=67108863,i=Math.imul(H,L),g=(g=Math.imul(H,x))+Math.imul(R,L)|0,r=Math.imul(R,x),i=i+Math.imul(K,j)|0,g=(g=g+Math.imul(K,W)|0)+Math.imul(U,j)|0,r=r+Math.imul(U,W)|0,i=i+Math.imul(S,P)|0,g=(g=g+Math.imul(S,V)|0)+Math.imul(Y,P)|0,r=r+Math.imul(Y,V)|0,i=i+Math.imul(k,z)|0,g=(g=g+Math.imul(k,T)|0)+Math.imul(F,z)|0,r=r+Math.imul(F,T)|0,i=i+Math.imul(M,$)|0,g=(g=g+Math.imul(M,AA)|0)+Math.imul(m,$)|0,r=r+Math.imul(m,AA)|0,i=i+Math.imul(D,tA)|0,g=(g=g+Math.imul(D,iA)|0)+Math.imul(b,tA)|0,r=r+Math.imul(b,iA)|0,i=i+Math.imul(l,rA)|0,g=(g=g+Math.imul(l,nA)|0)+Math.imul(w,rA)|0,r=r+Math.imul(w,nA)|0,i=i+Math.imul(E,IA)|0,g=(g=g+Math.imul(E,oA)|0)+Math.imul(u,IA)|0,r=r+Math.imul(u,oA)|0,i=i+Math.imul(c,QA)|0,g=(g=g+Math.imul(c,CA)|0)+Math.imul(h,QA)|0,r=r+Math.imul(h,CA)|0;var yA=(o+(i=i+Math.imul(Q,cA)|0)|0)+((8191&(g=(g=g+Math.imul(Q,hA)|0)+Math.imul(C,cA)|0))<<13)|0;o=((r=r+Math.imul(C,hA)|0)+(g>>>13)|0)+(yA>>>26)|0,yA&=67108863,i=Math.imul(H,j),g=(g=Math.imul(H,W))+Math.imul(R,j)|0,r=Math.imul(R,W),i=i+Math.imul(K,P)|0,g=(g=g+Math.imul(K,V)|0)+Math.imul(U,P)|0,r=r+Math.imul(U,V)|0,i=i+Math.imul(S,z)|0,g=(g=g+Math.imul(S,T)|0)+Math.imul(Y,z)|0,r=r+Math.imul(Y,T)|0,i=i+Math.imul(k,$)|0,g=(g=g+Math.imul(k,AA)|0)+Math.imul(F,$)|0,r=r+Math.imul(F,AA)|0,i=i+Math.imul(M,tA)|0,g=(g=g+Math.imul(M,iA)|0)+Math.imul(m,tA)|0,r=r+Math.imul(m,iA)|0,i=i+Math.imul(D,rA)|0,g=(g=g+Math.imul(D,nA)|0)+Math.imul(b,rA)|0,r=r+Math.imul(b,nA)|0,i=i+Math.imul(l,IA)|0,g=(g=g+Math.imul(l,oA)|0)+Math.imul(w,IA)|0,r=r+Math.imul(w,oA)|0,i=i+Math.imul(E,QA)|0,g=(g=g+Math.imul(E,CA)|0)+Math.imul(u,QA)|0,r=r+Math.imul(u,CA)|0;var MA=(o+(i=i+Math.imul(c,cA)|0)|0)+((8191&(g=(g=g+Math.imul(c,hA)|0)+Math.imul(h,cA)|0))<<13)|0;o=((r=r+Math.imul(h,hA)|0)+(g>>>13)|0)+(MA>>>26)|0,MA&=67108863,i=Math.imul(H,P),g=(g=Math.imul(H,V))+Math.imul(R,P)|0,r=Math.imul(R,V),i=i+Math.imul(K,z)|0,g=(g=g+Math.imul(K,T)|0)+Math.imul(U,z)|0,r=r+Math.imul(U,T)|0,i=i+Math.imul(S,$)|0,g=(g=g+Math.imul(S,AA)|0)+Math.imul(Y,$)|0,r=r+Math.imul(Y,AA)|0,i=i+Math.imul(k,tA)|0,g=(g=g+Math.imul(k,iA)|0)+Math.imul(F,tA)|0,r=r+Math.imul(F,iA)|0,i=i+Math.imul(M,rA)|0,g=(g=g+Math.imul(M,nA)|0)+Math.imul(m,rA)|0,r=r+Math.imul(m,nA)|0,i=i+Math.imul(D,IA)|0,g=(g=g+Math.imul(D,oA)|0)+Math.imul(b,IA)|0,r=r+Math.imul(b,oA)|0,i=i+Math.imul(l,QA)|0,g=(g=g+Math.imul(l,CA)|0)+Math.imul(w,QA)|0,r=r+Math.imul(w,CA)|0;var mA=(o+(i=i+Math.imul(E,cA)|0)|0)+((8191&(g=(g=g+Math.imul(E,hA)|0)+Math.imul(u,cA)|0))<<13)|0;o=((r=r+Math.imul(u,hA)|0)+(g>>>13)|0)+(mA>>>26)|0,mA&=67108863,i=Math.imul(H,z),g=(g=Math.imul(H,T))+Math.imul(R,z)|0,r=Math.imul(R,T),i=i+Math.imul(K,$)|0,g=(g=g+Math.imul(K,AA)|0)+Math.imul(U,$)|0,r=r+Math.imul(U,AA)|0,i=i+Math.imul(S,tA)|0,g=(g=g+Math.imul(S,iA)|0)+Math.imul(Y,tA)|0,r=r+Math.imul(Y,iA)|0,i=i+Math.imul(k,rA)|0,g=(g=g+Math.imul(k,nA)|0)+Math.imul(F,rA)|0,r=r+Math.imul(F,nA)|0,i=i+Math.imul(M,IA)|0,g=(g=g+Math.imul(M,oA)|0)+Math.imul(m,IA)|0,r=r+Math.imul(m,oA)|0,i=i+Math.imul(D,QA)|0,g=(g=g+Math.imul(D,CA)|0)+Math.imul(b,QA)|0,r=r+Math.imul(b,CA)|0;var GA=(o+(i=i+Math.imul(l,cA)|0)|0)+((8191&(g=(g=g+Math.imul(l,hA)|0)+Math.imul(w,cA)|0))<<13)|0;o=((r=r+Math.imul(w,hA)|0)+(g>>>13)|0)+(GA>>>26)|0,GA&=67108863,i=Math.imul(H,$),g=(g=Math.imul(H,AA))+Math.imul(R,$)|0,r=Math.imul(R,AA),i=i+Math.imul(K,tA)|0,g=(g=g+Math.imul(K,iA)|0)+Math.imul(U,tA)|0,r=r+Math.imul(U,iA)|0,i=i+Math.imul(S,rA)|0,g=(g=g+Math.imul(S,nA)|0)+Math.imul(Y,rA)|0,r=r+Math.imul(Y,nA)|0,i=i+Math.imul(k,IA)|0,g=(g=g+Math.imul(k,oA)|0)+Math.imul(F,IA)|0,r=r+Math.imul(F,oA)|0,i=i+Math.imul(M,QA)|0,g=(g=g+Math.imul(M,CA)|0)+Math.imul(m,QA)|0,r=r+Math.imul(m,CA)|0;var kA=(o+(i=i+Math.imul(D,cA)|0)|0)+((8191&(g=(g=g+Math.imul(D,hA)|0)+Math.imul(b,cA)|0))<<13)|0;o=((r=r+Math.imul(b,hA)|0)+(g>>>13)|0)+(kA>>>26)|0,kA&=67108863,i=Math.imul(H,tA),g=(g=Math.imul(H,iA))+Math.imul(R,tA)|0,r=Math.imul(R,iA),i=i+Math.imul(K,rA)|0,g=(g=g+Math.imul(K,nA)|0)+Math.imul(U,rA)|0,r=r+Math.imul(U,nA)|0,i=i+Math.imul(S,IA)|0,g=(g=g+Math.imul(S,oA)|0)+Math.imul(Y,IA)|0,r=r+Math.imul(Y,oA)|0,i=i+Math.imul(k,QA)|0,g=(g=g+Math.imul(k,CA)|0)+Math.imul(F,QA)|0,r=r+Math.imul(F,CA)|0;var FA=(o+(i=i+Math.imul(M,cA)|0)|0)+((8191&(g=(g=g+Math.imul(M,hA)|0)+Math.imul(m,cA)|0))<<13)|0;o=((r=r+Math.imul(m,hA)|0)+(g>>>13)|0)+(FA>>>26)|0,FA&=67108863,i=Math.imul(H,rA),g=(g=Math.imul(H,nA))+Math.imul(R,rA)|0,r=Math.imul(R,nA),i=i+Math.imul(K,IA)|0,g=(g=g+Math.imul(K,oA)|0)+Math.imul(U,IA)|0,r=r+Math.imul(U,oA)|0,i=i+Math.imul(S,QA)|0,g=(g=g+Math.imul(S,CA)|0)+Math.imul(Y,QA)|0,r=r+Math.imul(Y,CA)|0;var NA=(o+(i=i+Math.imul(k,cA)|0)|0)+((8191&(g=(g=g+Math.imul(k,hA)|0)+Math.imul(F,cA)|0))<<13)|0;o=((r=r+Math.imul(F,hA)|0)+(g>>>13)|0)+(NA>>>26)|0,NA&=67108863,i=Math.imul(H,IA),g=(g=Math.imul(H,oA))+Math.imul(R,IA)|0,r=Math.imul(R,oA),i=i+Math.imul(K,QA)|0,g=(g=g+Math.imul(K,CA)|0)+Math.imul(U,QA)|0,r=r+Math.imul(U,CA)|0;var SA=(o+(i=i+Math.imul(S,cA)|0)|0)+((8191&(g=(g=g+Math.imul(S,hA)|0)+Math.imul(Y,cA)|0))<<13)|0;o=((r=r+Math.imul(Y,hA)|0)+(g>>>13)|0)+(SA>>>26)|0,SA&=67108863,i=Math.imul(H,QA),g=(g=Math.imul(H,CA))+Math.imul(R,QA)|0,r=Math.imul(R,CA);var YA=(o+(i=i+Math.imul(K,cA)|0)|0)+((8191&(g=(g=g+Math.imul(K,hA)|0)+Math.imul(U,cA)|0))<<13)|0;o=((r=r+Math.imul(U,hA)|0)+(g>>>13)|0)+(YA>>>26)|0,YA&=67108863;var vA=(o+(i=Math.imul(H,cA))|0)+((8191&(g=(g=Math.imul(H,hA))+Math.imul(R,cA)|0))<<13)|0;return o=((r=Math.imul(R,hA))+(g>>>13)|0)+(vA>>>26)|0,vA&=67108863,I[0]=fA,I[1]=EA,I[2]=uA,I[3]=dA,I[4]=lA,I[5]=wA,I[6]=pA,I[7]=DA,I[8]=bA,I[9]=yA,I[10]=MA,I[11]=mA,I[12]=GA,I[13]=kA,I[14]=FA,I[15]=NA,I[16]=SA,I[17]=YA,I[18]=vA,0!==o&&(I[19]=o,t.length++),t};function f(A,e,t){t.negative=e.negative^A.negative,t.length=A.length+e.length;for(var i=0,g=0,r=0;r>>26)|0)>>>26,n&=67108863}t.words[r]=B,i=n,n=g}return 0!==i?t.words[r]=i:t.length--,t._strip()}function E(A,e,t){return f(A,e,t)}function u(A,e){this.x=A,this.y=e}Math.imul||(h=c),r.prototype.mulTo=function(A,e){var t=this.length+A.length;return 10===this.length&&10===A.length?h(this,A,e):t<63?c(this,A,e):t<1024?f(this,A,e):E(this,A,e)},u.prototype.makeRBT=function(A){for(var e=new Array(A),t=r.prototype._countBits(A)-1,i=0;i>=1;return i},u.prototype.permute=function(A,e,t,i,g,r){for(var n=0;n>>=1)g++;return 1<>>=13,t[2*n+1]=8191&r,r>>>=13;for(n=2*e;n>=26,t+=r/67108864|0,t+=n>>>26,this.words[g]=67108863&n}return 0!==t&&(this.words[g]=t,this.length++),e?this.ineg():this},r.prototype.muln=function(A){return this.clone().imuln(A)},r.prototype.sqr=function(){return this.mul(this)},r.prototype.isqr=function(){return this.imul(this.clone())},r.prototype.pow=function(A){var e=function(A){for(var e=new Array(A.bitLength()),t=0;t>>g&1}return e}(A);if(0===e.length)return new r(1);for(var t=this,i=0;i=0);var e,t=A%26,g=(A-t)/26,r=67108863>>>26-t<<26-t;if(0!==t){var n=0;for(e=0;e>>26-t}n&&(this.words[e]=n,this.length++)}if(0!==g){for(e=this.length-1;e>=0;e--)this.words[e+g]=this.words[e];for(e=0;e=0),g=e?(e-e%26)/26:0;var r=A%26,n=Math.min((A-r)/26,this.length),B=67108863^67108863>>>r<n)for(this.length-=n,o=0;o=0&&(0!==a||o>=g);o--){var Q=0|this.words[o];this.words[o]=a<<26-r|Q>>>r,a=Q&B}return I&&0!==a&&(I.words[I.length++]=a),0===this.length&&(this.words[0]=0,this.length=1),this._strip()},r.prototype.ishrn=function(A,e,t){return i(0===this.negative),this.iushrn(A,e,t)},r.prototype.shln=function(A){return this.clone().ishln(A)},r.prototype.ushln=function(A){return this.clone().iushln(A)},r.prototype.shrn=function(A){return this.clone().ishrn(A)},r.prototype.ushrn=function(A){return this.clone().iushrn(A)},r.prototype.testn=function(A){i("number"==typeof A&&A>=0);var e=A%26,t=(A-e)/26,g=1<=0);var e=A%26,t=(A-e)/26;if(i(0===this.negative,"imaskn works only with positive numbers"),this.length<=t)return this;if(0!==e&&t++,this.length=Math.min(t,this.length),0!==e){var g=67108863^67108863>>>e<=67108864;e++)this.words[e]-=67108864,e===this.length-1?this.words[e+1]=1:this.words[e+1]++;return this.length=Math.max(this.length,e+1),this},r.prototype.isubn=function(A){if(i("number"==typeof A),i(A<67108864),A<0)return this.iaddn(-A);if(0!==this.negative)return this.negative=0,this.iaddn(A),this.negative=1,this;if(this.words[0]-=A,1===this.length&&this.words[0]<0)this.words[0]=-this.words[0],this.negative=1;else for(var e=0;e>26)-(I/67108864|0),this.words[g+t]=67108863&r}for(;g>26,this.words[g+t]=67108863&r;if(0===B)return this._strip();for(i(-1===B),B=0,g=0;g>26,this.words[g]=67108863&r;return this.negative=1,this._strip()},r.prototype._wordDiv=function(A,e){var t=(this.length,A.length),i=this.clone(),g=A,n=0|g.words[g.length-1];0!==(t=26-this._countBits(n))&&(g=g.ushln(t),i.iushln(t),n=0|g.words[g.length-1]);var B,I=i.length-g.length;if("mod"!==e){(B=new r(null)).length=I+1,B.words=new Array(B.length);for(var o=0;o=0;Q--){var C=67108864*(0|i.words[g.length+Q])+(0|i.words[g.length+Q-1]);for(C=Math.min(C/n|0,67108863),i._ishlnsubmul(g,C,Q);0!==i.negative;)C--,i.negative=0,i._ishlnsubmul(g,1,Q),i.isZero()||(i.negative^=1);B&&(B.words[Q]=C)}return B&&B._strip(),i._strip(),"div"!==e&&0!==t&&i.iushrn(t),{div:B||null,mod:i}},r.prototype.divmod=function(A,e,t){return i(!A.isZero()),this.isZero()?{div:new r(0),mod:new r(0)}:0!==this.negative&&0===A.negative?(B=this.neg().divmod(A,e),"mod"!==e&&(g=B.div.neg()),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.iadd(A)),{div:g,mod:n}):0===this.negative&&0!==A.negative?(B=this.divmod(A.neg(),e),"mod"!==e&&(g=B.div.neg()),{div:g,mod:B.mod}):0!=(this.negative&A.negative)?(B=this.neg().divmod(A.neg(),e),"div"!==e&&(n=B.mod.neg(),t&&0!==n.negative&&n.isub(A)),{div:B.div,mod:n}):A.length>this.length||this.cmp(A)<0?{div:new r(0),mod:this}:1===A.length?"div"===e?{div:this.divn(A.words[0]),mod:null}:"mod"===e?{div:null,mod:new r(this.modrn(A.words[0]))}:{div:this.divn(A.words[0]),mod:new r(this.modrn(A.words[0]))}:this._wordDiv(A,e);var g,n,B},r.prototype.div=function(A){return this.divmod(A,"div",!1).div},r.prototype.mod=function(A){return this.divmod(A,"mod",!1).mod},r.prototype.umod=function(A){return this.divmod(A,"mod",!0).mod},r.prototype.divRound=function(A){var e=this.divmod(A);if(e.mod.isZero())return e.div;var t=0!==e.div.negative?e.mod.isub(A):e.mod,i=A.ushrn(1),g=A.andln(1),r=t.cmp(i);return r<0||1===g&&0===r?e.div:0!==e.div.negative?e.div.isubn(1):e.div.iaddn(1)},r.prototype.modrn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=(1<<26)%A,g=0,r=this.length-1;r>=0;r--)g=(t*g+(0|this.words[r]))%A;return e?-g:g},r.prototype.modn=function(A){return this.modrn(A)},r.prototype.idivn=function(A){var e=A<0;e&&(A=-A),i(A<=67108863);for(var t=0,g=this.length-1;g>=0;g--){var r=(0|this.words[g])+67108864*t;this.words[g]=r/A|0,t=r%A}return this._strip(),e?this.ineg():this},r.prototype.divn=function(A){return this.clone().idivn(A)},r.prototype.egcd=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g=new r(1),n=new r(0),B=new r(0),I=new r(1),o=0;e.isEven()&&t.isEven();)e.iushrn(1),t.iushrn(1),++o;for(var a=t.clone(),Q=e.clone();!e.isZero();){for(var C=0,s=1;0==(e.words[0]&s)&&C<26;++C,s<<=1);if(C>0)for(e.iushrn(C);C-- >0;)(g.isOdd()||n.isOdd())&&(g.iadd(a),n.isub(Q)),g.iushrn(1),n.iushrn(1);for(var c=0,h=1;0==(t.words[0]&h)&&c<26;++c,h<<=1);if(c>0)for(t.iushrn(c);c-- >0;)(B.isOdd()||I.isOdd())&&(B.iadd(a),I.isub(Q)),B.iushrn(1),I.iushrn(1);e.cmp(t)>=0?(e.isub(t),g.isub(B),n.isub(I)):(t.isub(e),B.isub(g),I.isub(n))}return{a:B,b:I,gcd:t.iushln(o)}},r.prototype._invmp=function(A){i(0===A.negative),i(!A.isZero());var e=this,t=A.clone();e=0!==e.negative?e.umod(A):e.clone();for(var g,n=new r(1),B=new r(0),I=t.clone();e.cmpn(1)>0&&t.cmpn(1)>0;){for(var o=0,a=1;0==(e.words[0]&a)&&o<26;++o,a<<=1);if(o>0)for(e.iushrn(o);o-- >0;)n.isOdd()&&n.iadd(I),n.iushrn(1);for(var Q=0,C=1;0==(t.words[0]&C)&&Q<26;++Q,C<<=1);if(Q>0)for(t.iushrn(Q);Q-- >0;)B.isOdd()&&B.iadd(I),B.iushrn(1);e.cmp(t)>=0?(e.isub(t),n.isub(B)):(t.isub(e),B.isub(n))}return(g=0===e.cmpn(1)?n:B).cmpn(0)<0&&g.iadd(A),g},r.prototype.gcd=function(A){if(this.isZero())return A.abs();if(A.isZero())return this.abs();var e=this.clone(),t=A.clone();e.negative=0,t.negative=0;for(var i=0;e.isEven()&&t.isEven();i++)e.iushrn(1),t.iushrn(1);for(;;){for(;e.isEven();)e.iushrn(1);for(;t.isEven();)t.iushrn(1);var g=e.cmp(t);if(g<0){var r=e;e=t,t=r}else if(0===g||0===t.cmpn(1))break;e.isub(t)}return t.iushln(i)},r.prototype.invm=function(A){return this.egcd(A).a.umod(A)},r.prototype.isEven=function(){return 0==(1&this.words[0])},r.prototype.isOdd=function(){return 1==(1&this.words[0])},r.prototype.andln=function(A){return this.words[0]&A},r.prototype.bincn=function(A){i("number"==typeof A);var e=A%26,t=(A-e)/26,g=1<>>26,B&=67108863,this.words[n]=B}return 0!==r&&(this.words[n]=r,this.length++),this},r.prototype.isZero=function(){return 1===this.length&&0===this.words[0]},r.prototype.cmpn=function(A){var e,t=A<0;if(0!==this.negative&&!t)return-1;if(0===this.negative&&t)return 1;if(this._strip(),this.length>1)e=1;else{t&&(A=-A),i(A<=67108863,"Number is too big");var g=0|this.words[0];e=g===A?0:gA.length)return 1;if(this.length=0;t--){var i=0|this.words[t],g=0|A.words[t];if(i!==g){ig&&(e=1);break}}return e},r.prototype.gtn=function(A){return 1===this.cmpn(A)},r.prototype.gt=function(A){return 1===this.cmp(A)},r.prototype.gten=function(A){return this.cmpn(A)>=0},r.prototype.gte=function(A){return this.cmp(A)>=0},r.prototype.ltn=function(A){return-1===this.cmpn(A)},r.prototype.lt=function(A){return-1===this.cmp(A)},r.prototype.lten=function(A){return this.cmpn(A)<=0},r.prototype.lte=function(A){return this.cmp(A)<=0},r.prototype.eqn=function(A){return 0===this.cmpn(A)},r.prototype.eq=function(A){return 0===this.cmp(A)},r.red=function(A){return new y(A)},r.prototype.toRed=function(A){return i(!this.red,"Already a number in reduction context"),i(0===this.negative,"red works only with positives"),A.convertTo(this)._forceRed(A)},r.prototype.fromRed=function(){return i(this.red,"fromRed works only with numbers in reduction context"),this.red.convertFrom(this)},r.prototype._forceRed=function(A){return this.red=A,this},r.prototype.forceRed=function(A){return i(!this.red,"Already a number in reduction context"),this._forceRed(A)},r.prototype.redAdd=function(A){return i(this.red,"redAdd works only with red numbers"),this.red.add(this,A)},r.prototype.redIAdd=function(A){return i(this.red,"redIAdd works only with red numbers"),this.red.iadd(this,A)},r.prototype.redSub=function(A){return i(this.red,"redSub works only with red numbers"),this.red.sub(this,A)},r.prototype.redISub=function(A){return i(this.red,"redISub works only with red numbers"),this.red.isub(this,A)},r.prototype.redShl=function(A){return i(this.red,"redShl works only with red numbers"),this.red.shl(this,A)},r.prototype.redMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.mul(this,A)},r.prototype.redIMul=function(A){return i(this.red,"redMul works only with red numbers"),this.red._verify2(this,A),this.red.imul(this,A)},r.prototype.redSqr=function(){return i(this.red,"redSqr works only with red numbers"),this.red._verify1(this),this.red.sqr(this)},r.prototype.redISqr=function(){return i(this.red,"redISqr works only with red numbers"),this.red._verify1(this),this.red.isqr(this)},r.prototype.redSqrt=function(){return i(this.red,"redSqrt works only with red numbers"),this.red._verify1(this),this.red.sqrt(this)},r.prototype.redInvm=function(){return i(this.red,"redInvm works only with red numbers"),this.red._verify1(this),this.red.invm(this)},r.prototype.redNeg=function(){return i(this.red,"redNeg works only with red numbers"),this.red._verify1(this),this.red.neg(this)},r.prototype.redPow=function(A){return i(this.red&&!A.red,"redPow(normalNum)"),this.red._verify1(this),this.red.pow(this,A)};var d={k256:null,p224:null,p192:null,p25519:null};function l(A,e){this.name=A,this.p=new r(e,16),this.n=this.p.bitLength(),this.k=new r(1).iushln(this.n).isub(this.p),this.tmp=this._tmp()}function w(){l.call(this,"k256","ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2f")}function p(){l.call(this,"p224","ffffffff ffffffff ffffffff ffffffff 00000000 00000000 00000001")}function D(){l.call(this,"p192","ffffffff ffffffff ffffffff fffffffe ffffffff ffffffff")}function b(){l.call(this,"25519","7fffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffed")}function y(A){if("string"==typeof A){var e=r._prime(A);this.m=e.p,this.prime=e}else i(A.gtn(1),"modulus must be greater than 1"),this.m=A,this.prime=null}function M(A){y.call(this,A),this.shift=this.m.bitLength(),this.shift%26!=0&&(this.shift+=26-this.shift%26),this.r=new r(1).iushln(this.shift),this.r2=this.imod(this.r.sqr()),this.rinv=this.r._invmp(this.m),this.minv=this.rinv.mul(this.r).isubn(1).div(this.m),this.minv=this.minv.umod(this.r),this.minv=this.r.sub(this.minv)}l.prototype._tmp=function(){var A=new r(null);return A.words=new Array(Math.ceil(this.n/13)),A},l.prototype.ireduce=function(A){var e,t=A;do{this.split(t,this.tmp),e=(t=(t=this.imulK(t)).iadd(this.tmp)).bitLength()}while(e>this.n);var i=e0?t.isub(this.p):void 0!==t.strip?t.strip():t._strip(),t},l.prototype.split=function(A,e){A.iushrn(this.n,0,e)},l.prototype.imulK=function(A){return A.imul(this.k)},g(w,l),w.prototype.split=function(A,e){for(var t=Math.min(A.length,9),i=0;i>>22,g=r}g>>>=22,A.words[i-10]=g,0===g&&A.length>10?A.length-=10:A.length-=9},w.prototype.imulK=function(A){A.words[A.length]=0,A.words[A.length+1]=0,A.length+=2;for(var e=0,t=0;t>>=26,A.words[t]=g,e=i}return 0!==e&&(A.words[A.length++]=e),A},r._prime=function(A){if(d[A])return d[A];var e;if("k256"===A)e=new w;else if("p224"===A)e=new p;else if("p192"===A)e=new D;else{if("p25519"!==A)throw new Error("Unknown prime "+A);e=new b}return d[A]=e,e},y.prototype._verify1=function(A){i(0===A.negative,"red works only with positives"),i(A.red,"red works only with red numbers")},y.prototype._verify2=function(A,e){i(0==(A.negative|e.negative),"red works only with positives"),i(A.red&&A.red===e.red,"red works only with red numbers")},y.prototype.imod=function(A){return this.prime?this.prime.ireduce(A)._forceRed(this):(o(A,A.umod(this.m)._forceRed(this)),A)},y.prototype.neg=function(A){return A.isZero()?A.clone():this.m.sub(A)._forceRed(this)},y.prototype.add=function(A,e){this._verify2(A,e);var t=A.add(e);return t.cmp(this.m)>=0&&t.isub(this.m),t._forceRed(this)},y.prototype.iadd=function(A,e){this._verify2(A,e);var t=A.iadd(e);return t.cmp(this.m)>=0&&t.isub(this.m),t},y.prototype.sub=function(A,e){this._verify2(A,e);var t=A.sub(e);return t.cmpn(0)<0&&t.iadd(this.m),t._forceRed(this)},y.prototype.isub=function(A,e){this._verify2(A,e);var t=A.isub(e);return t.cmpn(0)<0&&t.iadd(this.m),t},y.prototype.shl=function(A,e){return this._verify1(A),this.imod(A.ushln(e))},y.prototype.imul=function(A,e){return this._verify2(A,e),this.imod(A.imul(e))},y.prototype.mul=function(A,e){return this._verify2(A,e),this.imod(A.mul(e))},y.prototype.isqr=function(A){return this.imul(A,A.clone())},y.prototype.sqr=function(A){return this.mul(A,A)},y.prototype.sqrt=function(A){if(A.isZero())return A.clone();var e=this.m.andln(3);if(i(e%2==1),3===e){var t=this.m.add(new r(1)).iushrn(2);return this.pow(A,t)}for(var g=this.m.subn(1),n=0;!g.isZero()&&0===g.andln(1);)n++,g.iushrn(1);i(!g.isZero());var B=new r(1).toRed(this),I=B.redNeg(),o=this.m.subn(1).iushrn(1),a=this.m.bitLength();for(a=new r(2*a*a).toRed(this);0!==this.pow(a,o).cmp(I);)a.redIAdd(I);for(var Q=this.pow(a,g),C=this.pow(A,g.addn(1).iushrn(1)),s=this.pow(A,g),c=n;0!==s.cmp(B);){for(var h=s,f=0;0!==h.cmp(B);f++)h=h.redSqr();i(f=0;i--){for(var o=e.words[i],a=I-1;a>=0;a--){var Q=o>>a&1;g!==t[0]&&(g=this.sqr(g)),0!==Q||0!==n?(n<<=1,n|=Q,(4===++B||0===i&&0===a)&&(g=this.mul(g,t[n]),B=0,n=0)):B=0}I=26}return g},y.prototype.convertTo=function(A){var e=A.umod(this.m);return e===A?e.clone():e},y.prototype.convertFrom=function(A){var e=A.clone();return e.red=null,e},r.mont=function(A){return new M(A)},g(M,y),M.prototype.convertTo=function(A){return this.imod(A.ushln(this.shift))},M.prototype.convertFrom=function(A){var e=this.imod(A.mul(this.rinv));return e.red=null,e},M.prototype.imul=function(A,e){if(A.isZero()||e.isZero())return A.words[0]=0,A.length=1,A;var t=A.imul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),r=g;return g.cmp(this.m)>=0?r=g.isub(this.m):g.cmpn(0)<0&&(r=g.iadd(this.m)),r._forceRed(this)},M.prototype.mul=function(A,e){if(A.isZero()||e.isZero())return new r(0)._forceRed(this);var t=A.mul(e),i=t.maskn(this.shift).mul(this.minv).imaskn(this.shift).mul(this.m),g=t.isub(i).iushrn(this.shift),n=g;return g.cmp(this.m)>=0?n=g.isub(this.m):g.cmpn(0)<0&&(n=g.iadd(this.m)),n._forceRed(this)},M.prototype.invm=function(A){return this.imod(A._invmp(this.m).mul(this.r2))._forceRed(this)}}(void 0===e||e,this)},{buffer:19}],317:[function(A,e,t){var i=A("base-x");e.exports=i("123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz")},{"base-x":311}],318:[function(A,e,t){"use strict";const i=(A,e)=>{if("string"!=typeof A&&!Array.isArray(A))throw new TypeError("Expected the input to be `string | string[]`");e=Object.assign({pascalCase:!1},e);return 0===(A=Array.isArray(A)?A.map(A=>A.trim()).filter(A=>A.length).join("-"):A.trim()).length?"":1===A.length?e.pascalCase?A.toUpperCase():A.toLowerCase():(A!==A.toLowerCase()&&(A=(A=>{let e=!1,t=!1,i=!1;for(let g=0;ge.pascalCase?A.charAt(0).toUpperCase()+A.slice(1):A)(A=A.replace(/^[_.\- ]+/,"").toLowerCase().replace(/[_.\- ]+(\w|$)/g,(A,e)=>e.toUpperCase()).replace(/\d+(\w|$)/g,A=>A.toUpperCase())))};e.exports=i,e.exports.default=i},{}],319:[function(A,e,t){"use strict";e.exports={aliceblue:[240,248,255],antiquewhite:[250,235,215],aqua:[0,255,255],aquamarine:[127,255,212],azure:[240,255,255],beige:[245,245,220],bisque:[255,228,196],black:[0,0,0],blanchedalmond:[255,235,205],blue:[0,0,255],blueviolet:[138,43,226],brown:[165,42,42],burlywood:[222,184,135],cadetblue:[95,158,160],chartreuse:[127,255,0],chocolate:[210,105,30],coral:[255,127,80],cornflowerblue:[100,149,237],cornsilk:[255,248,220],crimson:[220,20,60],cyan:[0,255,255],darkblue:[0,0,139],darkcyan:[0,139,139],darkgoldenrod:[184,134,11],darkgray:[169,169,169],darkgreen:[0,100,0],darkgrey:[169,169,169],darkkhaki:[189,183,107],darkmagenta:[139,0,139],darkolivegreen:[85,107,47],darkorange:[255,140,0],darkorchid:[153,50,204],darkred:[139,0,0],darksalmon:[233,150,122],darkseagreen:[143,188,143],darkslateblue:[72,61,139],darkslategray:[47,79,79],darkslategrey:[47,79,79],darkturquoise:[0,206,209],darkviolet:[148,0,211],deeppink:[255,20,147],deepskyblue:[0,191,255],dimgray:[105,105,105],dimgrey:[105,105,105],dodgerblue:[30,144,255],firebrick:[178,34,34],floralwhite:[255,250,240],forestgreen:[34,139,34],fuchsia:[255,0,255],gainsboro:[220,220,220],ghostwhite:[248,248,255],gold:[255,215,0],goldenrod:[218,165,32],gray:[128,128,128],green:[0,128,0],greenyellow:[173,255,47],grey:[128,128,128],honeydew:[240,255,240],hotpink:[255,105,180],indianred:[205,92,92],indigo:[75,0,130],ivory:[255,255,240],khaki:[240,230,140],lavender:[230,230,250],lavenderblush:[255,240,245],lawngreen:[124,252,0],lemonchiffon:[255,250,205],lightblue:[173,216,230],lightcoral:[240,128,128],lightcyan:[224,255,255],lightgoldenrodyellow:[250,250,210],lightgray:[211,211,211],lightgreen:[144,238,144],lightgrey:[211,211,211],lightpink:[255,182,193],lightsalmon:[255,160,122],lightseagreen:[32,178,170],lightskyblue:[135,206,250],lightslategray:[119,136,153],lightslategrey:[119,136,153],lightsteelblue:[176,196,222],lightyellow:[255,255,224],lime:[0,255,0],limegreen:[50,205,50],linen:[250,240,230],magenta:[255,0,255],maroon:[128,0,0],mediumaquamarine:[102,205,170],mediumblue:[0,0,205],mediumorchid:[186,85,211],mediumpurple:[147,112,219],mediumseagreen:[60,179,113],mediumslateblue:[123,104,238],mediumspringgreen:[0,250,154],mediumturquoise:[72,209,204],mediumvioletred:[199,21,133],midnightblue:[25,25,112],mintcream:[245,255,250],mistyrose:[255,228,225],moccasin:[255,228,181],navajowhite:[255,222,173],navy:[0,0,128],oldlace:[253,245,230],olive:[128,128,0],olivedrab:[107,142,35],orange:[255,165,0],orangered:[255,69,0],orchid:[218,112,214],palegoldenrod:[238,232,170],palegreen:[152,251,152],paleturquoise:[175,238,238],palevioletred:[219,112,147],papayawhip:[255,239,213],peachpuff:[255,218,185],peru:[205,133,63],pink:[255,192,203],plum:[221,160,221],powderblue:[176,224,230],purple:[128,0,128],rebeccapurple:[102,51,153],red:[255,0,0],rosybrown:[188,143,143],royalblue:[65,105,225],saddlebrown:[139,69,19],salmon:[250,128,114],sandybrown:[244,164,96],seagreen:[46,139,87],seashell:[255,245,238],sienna:[160,82,45],silver:[192,192,192],skyblue:[135,206,235],slateblue:[106,90,205],slategray:[112,128,144],slategrey:[112,128,144],snow:[255,250,250],springgreen:[0,255,127],steelblue:[70,130,180],tan:[210,180,140],teal:[0,128,128],thistle:[216,191,216],tomato:[255,99,71],turquoise:[64,224,208],violet:[238,130,238],wheat:[245,222,179],white:[255,255,255],whitesmoke:[245,245,245],yellow:[255,255,0],yellowgreen:[154,205,50]}},{}],320:[function(A,e,t){"use strict";const i=A=>A&&A.includeBoundaries?"(?:(?<=\\s|^)(?=[a-fA-F\\d:])|(?<=[a-fA-F\\d:])(?=\\s|$))":"",g="(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]\\d|\\d)(?:\\.(?:25[0-5]|2[0-4]\\d|1\\d\\d|[1-9]\\d|\\d)){3}",r="[a-fA-F\\d]{1,4}",n=`\n(\n(?:${r}:){7}(?:${r}|:)| // 1:2:3:4:5:6:7:: 1:2:3:4:5:6:7:8\n(?:${r}:){6}(?:${g}|:${r}|:)| // 1:2:3:4:5:6:: 1:2:3:4:5:6::8 1:2:3:4:5:6::8 1:2:3:4:5:6::1.2.3.4\n(?:${r}:){5}(?::${g}|(:${r}){1,2}|:)| // 1:2:3:4:5:: 1:2:3:4:5::7:8 1:2:3:4:5::8 1:2:3:4:5::7:1.2.3.4\n(?:${r}:){4}(?:(:${r}){0,1}:${g}|(:${r}){1,3}|:)| // 1:2:3:4:: 1:2:3:4::6:7:8 1:2:3:4::8 1:2:3:4::6:7:1.2.3.4\n(?:${r}:){3}(?:(:${r}){0,2}:${g}|(:${r}){1,4}|:)| // 1:2:3:: 1:2:3::5:6:7:8 1:2:3::8 1:2:3::5:6:7:1.2.3.4\n(?:${r}:){2}(?:(:${r}){0,3}:${g}|(:${r}){1,5}|:)| // 1:2:: 1:2::4:5:6:7:8 1:2::8 1:2::4:5:6:7:1.2.3.4\n(?:${r}:){1}(?:(:${r}){0,4}:${g}|(:${r}){1,6}|:)| // 1:: 1::3:4:5:6:7:8 1::8 1::3:4:5:6:7:1.2.3.4\n(?::((?::${r}){0,5}:${g}|(?::${r}){1,7}|:)) // ::2:3:4:5:6:7:8 ::2:3:4:5:6:7:8 ::8 ::1.2.3.4\n)(%[0-9a-zA-Z]{1,})? // %eth0 %1\n`.replace(/\s*\/\/.*$/gm,"").replace(/\n/g,"").trim(),B=A=>A&&A.exact?new RegExp(`(?:^${g}$)|(?:^${n}$)`):new RegExp(`(?:${i(A)}${g}${i(A)})|(?:${i(A)}${n}${i(A)})`,"g");B.v4=(A=>A&&A.exact?new RegExp(`^${g}$`):new RegExp(`${i(A)}${g}${i(A)}`,"g")),B.v6=(A=>A&&A.exact?new RegExp(`^${n}$`):new RegExp(`${i(A)}${n}${i(A)}`,"g")),e.exports=B},{}],321:[function(A,e,t){var i=A("buffer"),g=i.Buffer;function r(A,e){for(var t in A)e[t]=A[t]}function n(A,e,t){return g(A,e,t)}g.from&&g.alloc&&g.allocUnsafe&&g.allocUnsafeSlow?e.exports=i:(r(i,t),t.Buffer=n),n.prototype=Object.create(g.prototype),r(g,n),n.from=function(A,e,t){if("number"==typeof A)throw new TypeError("Argument must not be a number");return g(A,e,t)},n.alloc=function(A,e,t){if("number"!=typeof A)throw new TypeError("Argument must be a number");var i=g(A);return void 0!==e?"string"==typeof t?i.fill(e,t):i.fill(e):i.fill(0),i},n.allocUnsafe=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return g(A)},n.allocUnsafeSlow=function(A){if("number"!=typeof A)throw new TypeError("Argument must be a number");return i.SlowBuffer(A)}},{buffer:64}],322:[function(A,e,t){"use strict";e.exports={stdout:!1,stderr:!1}},{}],323:[function(A,e,t){const i=A("@polkadot/util-crypto/address/decode").default,g=A("@polkadot/util-crypto/address/encode").default;globalThis.addressChanger=(()=>{const A=document.getElementById("input"),e=document.getElementById("prefix-select"),t=document.getElementById("output"),r=e.options[e.selectedIndex].value;try{const e=i(A.value),n=g(e,r);t.textContent=n.toString()}catch(A){console.log(A)}})},{"@polkadot/util-crypto/address/decode":202,"@polkadot/util-crypto/address/encode":204}]},{},[323]); diff --git a/website/translated_docs/ar/build-protocol-info.md b/website/translated_docs/ar/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/ar/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ar/build-transaction-construction.md b/website/translated_docs/ar/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/ar/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/ar/claims.md b/website/translated_docs/ar/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/ar/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ar/getting-started.md b/website/translated_docs/ar/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/ar/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ar/grants.md b/website/translated_docs/ar/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/ar/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ar/kusama-adverserial-cheatsheet.md b/website/translated_docs/ar/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/ar/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ar/kusama-ledger.md b/website/translated_docs/ar/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/ar/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/ar/kusama-parameters.md b/website/translated_docs/ar/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/ar/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ar/learn-accounts.md b/website/translated_docs/ar/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/ar/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ar/learn-availability.md b/website/translated_docs/ar/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/ar/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/ar/learn-balance-transfers.md b/website/translated_docs/ar/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/ar/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/ar/learn-bridges.md b/website/translated_docs/ar/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/ar/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ar/learn-cryptography.md b/website/translated_docs/ar/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/ar/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ar/learn-governance.md b/website/translated_docs/ar/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/ar/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ar/learn-ledger.md b/website/translated_docs/ar/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/ar/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ar/learn-registrar.md b/website/translated_docs/ar/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/ar/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ar/learn-staking.md b/website/translated_docs/ar/learn-staking.md deleted file mode 100644 index be56cc9b61e5..000000000000 --- a/website/translated_docs/ar/learn-staking.md +++ /dev/null @@ -1,259 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ar/learn-treasury.md b/website/translated_docs/ar/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/ar/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ar/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/ar/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/ar/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/ar/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/ar/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/ar/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/ar/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/ar/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/ar/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/ar/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/ar/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/ar/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/ar/maintain-guides-society-kusama.md b/website/translated_docs/ar/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/ar/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ar/maintain-polkadot-parameters.md b/website/translated_docs/ar/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/ar/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ar/redenomination.md b/website/translated_docs/ar/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/ar/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ar/thousand-validators.md b/website/translated_docs/ar/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/ar/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/de/build-protocol-info.md b/website/translated_docs/de/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/de/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/de/build-transaction-construction.md b/website/translated_docs/de/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/de/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/de/claims.md b/website/translated_docs/de/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/de/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/de/getting-started.md b/website/translated_docs/de/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/de/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/de/grants.md b/website/translated_docs/de/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/de/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/de/kusama-adverserial-cheatsheet.md b/website/translated_docs/de/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/de/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/de/kusama-ledger.md b/website/translated_docs/de/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/de/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/de/kusama-parameters.md b/website/translated_docs/de/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/de/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/de/learn-accounts.md b/website/translated_docs/de/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/de/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/de/learn-availability.md b/website/translated_docs/de/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/de/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/de/learn-balance-transfers.md b/website/translated_docs/de/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/de/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/de/learn-bridges.md b/website/translated_docs/de/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/de/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/de/learn-cryptography.md b/website/translated_docs/de/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/de/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/de/learn-governance.md b/website/translated_docs/de/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/de/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/de/learn-ledger.md b/website/translated_docs/de/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/de/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/de/learn-registrar.md b/website/translated_docs/de/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/de/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/de/learn-staking.md b/website/translated_docs/de/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/de/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/de/learn-treasury.md b/website/translated_docs/de/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/de/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/de/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/de/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/de/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/de/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/de/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/de/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/de/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/de/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/de/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/de/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/de/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/de/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/de/maintain-guides-society-kusama.md b/website/translated_docs/de/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/de/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/de/maintain-polkadot-parameters.md b/website/translated_docs/de/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/de/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/de/redenomination.md b/website/translated_docs/de/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/de/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/de/thousand-validators.md b/website/translated_docs/de/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/de/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/es-ES/build-exchange-integration.md b/website/translated_docs/es-ES/build-exchange-integration.md deleted file mode 100644 index 27da9d2321be..000000000000 --- a/website/translated_docs/es-ES/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. Tracking the chain head - -Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). - -That will give you a stream of hashes of the most recent finalised headers. - -When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. - -If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. - -## 2. Decoding blocks - -You will need to decode blocks from the basic data into useful fields. - -All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. - -For Genesis Polkadot, the header format is a five-field structure: - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -It also relies on `Extrinsic`. An *extrinsic* is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. - -The metadata itself is provided encoded in SCALE. Its format is: - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. - -Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various *modules*. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, *extrinsics*), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. Working with SS58 and account addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) *AccountId*. This is simply the public key for the x25519 cryptography used by Substrate. - -However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this *index* to identify the account. This index is much smaller than the 32-byte *AccountId*, and can usually be encoded in just a couple of bytes. - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: - -`0x00 ` - -**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. - -Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. - -Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. - -### Looking up an index - -Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. - -The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. - -For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. - -This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. - -This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. - -Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. - -## 4. Working with balances - -In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. - -NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. - -The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10**12). For completeness, The exact denominations of the Polkadot currency are: - -| Balance value | Name | -| ------------- | ---- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### Transferring balances - -To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. - -In general, Polkadot's transactions are encoded as *signed* `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. - -The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. - -NOTE: The nonce retrieved from storage does not take into account *pending* transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. - -The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. - -The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. - -Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. - -Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -The `function` *in this case* (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. - -The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. - -### Submitting and checking transactions - -Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. - -This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. - -The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. - -## Conclusion - -This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. - -If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). - -_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/es-ES/build-extrinsic-format.md b/website/translated_docs/es-ES/build-extrinsic-format.md deleted file mode 100644 index 92d1692bb078..000000000000 --- a/website/translated_docs/es-ES/build-extrinsic-format.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: build-extrinsic-format -title: Polkadot Extrinsic Format aka Transaction Format -sidebar_label: Polkadot Extrinsic Format aka Transaction Format ---- - -## Old Format - -For reference, the **old** extrinsic format was: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] -``` - -## Current Format - -The Polkadot extrinsic format is: - -``` -[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] -``` - -The *original* fields refer to the following from the old extrinsic format: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] -``` - -The specific format for the new address type is one of 5 sub-formats, switched on the first byte: - -- `0xff, 32-byte account id` -- `0xfe, 8-byte account index` -- `0xfd, 4-byte account index` -- `0xfc, 2-byte account index` -- `[0xf0...0xfb] (invalid, reserved for future use)` -- `[0x00...0xef] 1-byte account index (less than 0xf0)` - -The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. - -In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). - -## Source - -[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/es-ES/build-protocol-info.md b/website/translated_docs/es-ES/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/es-ES/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/es-ES/build-rust-style-guide.md b/website/translated_docs/es-ES/build-rust-style-guide.md deleted file mode 100644 index 52f24a8a5b1b..000000000000 --- a/website/translated_docs/es-ES/build-rust-style-guide.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: build-rust-style-guide -title: Style Guide for Rust in Polkadot -sidebar_label: Style Guide for Rust in Polkadot ---- - -- Indent using tabs -- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. -- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. -- Never have spaces on a line prior to a non-whitespace character -- Follow-on lines are only ever a single indent from the original line. -```rust -fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { - let x = some_long_variable_a * some_long_variable_b - - some_long_variable_b / some_long_variable_a - + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); - x > 10 -} -``` -- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: -```rust -fn calculate( - some_long_variable_a: f32, - some_long_variable_b: f32, - some_long_variable_c: f32, -) -> f32 { - (-some_long_variable_b + sqrt( - // two parens open, but since we open & close them both on the - // same line, only one indent level is used - some_long_variable_b * some_long_variable_b - - 4 * some_long_variable_a * some_long_variable_c - // both closed here at beginning of line, so back to the original indent - // level - )) / (2 * some_long_variable_a) -} -``` -- `where` is indented, and its items are indented one further -- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. - -```rust -// OK -fn foo( - really_long_parameter_name_1: SomeLongTypeName, - really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, - shrt_nm_2: u8, -) { - ... -} - -// NOT OK -fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, shrt_nm_2: u8) { - ... -} - -``` - -```rust -{ - // Complex line (not just a function call, also a let statement). Full - // structure. - let (a, b) = bar( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Long, simple function call. - waz( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Short function call. Inline. - baz(a, b); -} -``` - -- Always end last item of a multi-line comma-delimited set with `,` when legal: -```rust -struct Point { - x: T, - y: T, // <-- Multiline comma-delimited lists end with a trailing , -} - -// Single line comma-delimited items do not have a trailing `,` -enum Meal { Breakfast, Lunch, Dinner }; -``` - -- Avoid trailing `;`s where unneeded. -```rust -if condition { - return 1 // <-- no ; here -} -``` - -- `match` arms may be either blocks or have a trailing `,` but not both. -- Blocks should not be used unnecessarily. -```rust -match meal { - Meal::Breakfast => "eggs", - Meal::Lunch => { check_diet(); recipe() }, -// Meal::Dinner => { return Err("Fasting") } // WRONG - Meal::Dinner => return Err("Fasting"), -} -``` diff --git a/website/translated_docs/es-ES/build-transaction-construction.md b/website/translated_docs/es-ES/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/es-ES/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/es-ES/claims.md b/website/translated_docs/es-ES/claims.md deleted file mode 100644 index 59a630263764..000000000000 --- a/website/translated_docs/es-ES/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -Si hiciste una compra de DOTs en una de las ventas previas al lanzamiento, entonces tendrás que solicitar tus tokens DOTs. Para aquellos que hicieron la solicitud previa al lanzamiento enviando una transacción de solicitud al Contrato de Reclamación en Ethereum, aún tendrán que enviar una transacción gratuita de _prueba_ que acepte los términos y condiciones de su asignación. Si no ha hecho una reclamación previa al génesis, entonces la reclamará y certificará en una sola transacción. - -Esta guía le ayudará en los pasos para hacer una reclamación o dar fe de la declaración. - -Si es la primera vez que reclama en Polkadot, por favor, lea más abajo en la sección de [reclamaciones](#making-a-claim). Si ya ha reclamado durante el período de reclamación previo al Génesis, por favor proceda a la sección de [certificar una declaración](#attesting-to-a-statement) en su lugar. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Hacer la reclamación - -Si no hizo la solicitud en el período de reclamación previo a la génesis, entonces puede reclamar sus tokens DOTs después del génesis. No hay límite de tiempo para hacer su reclamación, así que siéntase libre de hacerlo cuando se sienta más cómodo. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### Lo que necesitarás - -- La cuenta Ethereum que contiene los tokens del indicador DOT -- La cartera MyCrypto -- Una cuenta de Polkadot - -Ya deberías tener tu cuenta en Ethereum que tiene los tokens del indicador DOT de Polkadot de la venta anterior. Necesitarás tener acceso a esta cuenta para poder firmar. - -[MyCrypto][] es una cartera versátil que admite una variedad de métodos de almacenamiento para su cuenta de Ethereum. Vaya a su página de descargas y asegúrese de descargar la última versión para su sistema operativo. Esto es importante porque la última versión siempre tendrá los últimos parches de seguridad. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Reclamando tus DOTs con MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Ahora tendrás que proporcionar la dirección de Ethereum que está asociada con los tokens DOTs que reclamarás. Introduce la dirección de Ethereum en la casilla y haz clic en "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -A continuación, tu pantalla debe mostrar la imagen de abajo. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -El siguiente paso es ir a la aplicación MyCrypto y hacer clic en la pestaña "Sign & Verify Message". - -![claim-3](assets/new-claims/claim-3.png) - -Esto te pedirá que selecciones un método para desbloquear tu cartera. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -Cuando hagas clic en "Sign Message" obtendrás una salida JSON como la de abajo: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -Aparecerá un cuadro verde que te indicará la cantidad a reclamar con un botón "Claim" para hacer la solicitud. Haz clic en el botón "Claim" y luego en "Submit (no signature)" para completar la solicitud. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verificando tu reclamación - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -¿Tienes problemas? Consigue ayuda en el [canal de soporte de reclamaciones]() de DOT. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Procesos de reclamaciones de terceros - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Acreditar una declaración - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### Lo que necesitarás - -- Tu cuenta de Polkadot desbloqueada en la IU de Polkadot-JS Apps. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Vaya a Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Haga la declaración - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/es-ES/getting-started.md b/website/translated_docs/es-ES/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/es-ES/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/es-ES/grants.md b/website/translated_docs/es-ES/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/es-ES/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/es-ES/kusama-adverserial-cheatsheet.md b/website/translated_docs/es-ES/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/es-ES/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/es-ES/kusama-ledger.md b/website/translated_docs/es-ES/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/es-ES/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/es-ES/kusama-parameters.md b/website/translated_docs/es-ES/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/es-ES/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/es-ES/kusama-time-periods.md b/website/translated_docs/es-ES/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/es-ES/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/es-ES/learn-UI.md b/website/translated_docs/es-ES/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/es-ES/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/es-ES/learn-accounts.md b/website/translated_docs/es-ES/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/es-ES/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/es-ES/learn-availability.md b/website/translated_docs/es-ES/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/es-ES/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/es-ES/learn-balance-transfers.md b/website/translated_docs/es-ES/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/es-ES/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/es-ES/learn-bridges.md b/website/translated_docs/es-ES/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/es-ES/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/es-ES/learn-cryptography.md b/website/translated_docs/es-ES/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/es-ES/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/es-ES/learn-governance.md b/website/translated_docs/es-ES/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/es-ES/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/es-ES/learn-interchain.md b/website/translated_docs/es-ES/learn-interchain.md deleted file mode 100644 index a6246da9ba4e..000000000000 --- a/website/translated_docs/es-ES/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. - -The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. - -## Overview - -- Interchain messages will *not* go on to the relay chain. -- Interchain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. - -## Example - -A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. - -When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/es-ES/learn-ledger.md b/website/translated_docs/es-ES/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/es-ES/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/es-ES/learn-registrar.md b/website/translated_docs/es-ES/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/es-ES/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/es-ES/learn-staking.md b/website/translated_docs/es-ES/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/es-ES/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/es-ES/learn-treasury.md b/website/translated_docs/es-ES/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/es-ES/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/es-ES/maintain-governance-index.md b/website/translated_docs/es-ES/maintain-governance-index.md deleted file mode 100644 index f2371610e1fa..000000000000 --- a/website/translated_docs/es-ES/maintain-governance-index.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -id: maintain-governance-index -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. - -All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. - -The following steps are the governance procedure in the Polkadot network: - -- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) -- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) -- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) - -To better understand how the council is formed, please read [this section](#council). - -### Proposing Referenda - -- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. - -- **[Council](#council)**: - - Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. - - Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) - -### Voting for a proposal - -To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). - -``` -Example: - -Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes -``` - -According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. - -### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -voters - the total number of voting tokens - -electorate - the total number of DOTs tokens issued in the network -``` - -**Super-Majority Approve** - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ - -**Super-Majority Against** - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ - -**Simple-Majority** - -Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ - -*To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)*. - -``` -Example: - -Assume we only have 1,500 DOTs tokens in total. - -John - 500 DOTs -Peter - 100 DOTs -Lilly - 150 DOTs -JJ - 150 DOTs -Ken - 600 DOTs - -John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -voters = 1050 -electorate = 1500 -``` - -$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ - -$${13.887} < {15.492}$$ - -Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. - -## Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: - -``` -Max votes = tokens * periods -``` - -Based on the current testnet setting, the maximum number of lock periods is set to 6. - -**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** - - -## Adaptive Quorum Biasing - -Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. - -Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. - -Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. - -In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -## Council - -Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). - -### How to be a council member? - -![](assets/governance/approval-vote.png) - - At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. - -To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. - -Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. - -Let's take a look at the example below. - -||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. - -### Resources - -- [Governance Description](learn-governance#referenda) -- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) - -## [Usage of DOT](learn-DOT#dots-for-governance) - -## Guides - -### [How to create a proposal]() -### [How to join the council]() -### [How to propose a referenda]() diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/es-ES/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/es-ES/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/es-ES/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/es-ES/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-nominate.md b/website/translated_docs/es-ES/maintain-guides-how-to-nominate.md deleted file mode 100644 index d846a22dddd0..000000000000 --- a/website/translated_docs/es-ES/maintain-guides-how-to-nominate.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: maintain-guides-how-to-nominate -title: How to nominate -sidebar_label: How to nominate ---- - -This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. - -It has been updated for the Alexander testnet and Polkadot release PoC-4. - -## Create `stash` and `controller` accounts - -We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. - -The first step is to create two accounts by going to the *Accounts* tab on the Polkadot Dashboard and clicking on [*Add account*](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. - -![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) - -Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. - -## Nominating - -It is now time to setup our nominator. We will do the following: -- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. -- Select the `controller`. This is the account that will decide when to start or stop nominating. - -First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. - -![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. -- **Controller account** - select the `controller` account created earlier. -- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). -- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). - -Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. - -![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) - -## Nominating a validator - -Go to the *Staking Overview* tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. - -![Validators](assets/guides/how-to-nominate/validators.png) - -Go back to the *Account Actions* tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). - -![Nominating](assets/guides/how-to-nominate/nominating.jpg) - -**Congratulations!** You are now a nominator. - -If you return to the *Staking Overview* tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. - -![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) - -## How to stop nominating - -To stop nominating simply return to the *Account Actions* tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/es-ES/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/es-ES/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/es-ES/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/es-ES/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/es-ES/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/es-ES/maintain-guides-society-kusama.md b/website/translated_docs/es-ES/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/es-ES/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/es-ES/maintain-polkadot-parameters.md b/website/translated_docs/es-ES/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/es-ES/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/es-ES/redenomination.md b/website/translated_docs/es-ES/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/es-ES/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/es-ES/thousand-validators.md b/website/translated_docs/es-ES/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/es-ES/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/fi/build-exchange-integration.md b/website/translated_docs/fi/build-exchange-integration.md deleted file mode 100644 index 27da9d2321be..000000000000 --- a/website/translated_docs/fi/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. Tracking the chain head - -Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). - -That will give you a stream of hashes of the most recent finalised headers. - -When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. - -If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. - -## 2. Decoding blocks - -You will need to decode blocks from the basic data into useful fields. - -All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. - -For Genesis Polkadot, the header format is a five-field structure: - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -It also relies on `Extrinsic`. An *extrinsic* is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. - -The metadata itself is provided encoded in SCALE. Its format is: - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. - -Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various *modules*. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, *extrinsics*), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. Working with SS58 and account addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) *AccountId*. This is simply the public key for the x25519 cryptography used by Substrate. - -However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this *index* to identify the account. This index is much smaller than the 32-byte *AccountId*, and can usually be encoded in just a couple of bytes. - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: - -`0x00 ` - -**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. - -Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. - -Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. - -### Looking up an index - -Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. - -The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. - -For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. - -This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. - -This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. - -Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. - -## 4. Working with balances - -In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. - -NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. - -The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10**12). For completeness, The exact denominations of the Polkadot currency are: - -| Balance value | Name | -| ------------- | ---- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### Transferring balances - -To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. - -In general, Polkadot's transactions are encoded as *signed* `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. - -The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. - -NOTE: The nonce retrieved from storage does not take into account *pending* transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. - -The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. - -The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. - -Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. - -Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -The `function` *in this case* (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. - -The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. - -### Submitting and checking transactions - -Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. - -This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. - -The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. - -## Conclusion - -This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. - -If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). - -_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/fi/build-protocol-info.md b/website/translated_docs/fi/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/fi/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/fi/build-transaction-construction.md b/website/translated_docs/fi/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/fi/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/fi/claims.md b/website/translated_docs/fi/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/fi/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/fi/getting-started.md b/website/translated_docs/fi/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/fi/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/fi/grants.md b/website/translated_docs/fi/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/fi/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/fi/kusama-adverserial-cheatsheet.md b/website/translated_docs/fi/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/fi/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/fi/kusama-ledger.md b/website/translated_docs/fi/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/fi/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/fi/kusama-parameters.md b/website/translated_docs/fi/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/fi/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/fi/kusama-time-periods.md b/website/translated_docs/fi/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/fi/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/fi/learn-UI.md b/website/translated_docs/fi/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/fi/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/fi/learn-accounts.md b/website/translated_docs/fi/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/fi/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/fi/learn-availability.md b/website/translated_docs/fi/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/fi/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/fi/learn-balance-transfers.md b/website/translated_docs/fi/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/fi/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/fi/learn-bridges.md b/website/translated_docs/fi/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/fi/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/fi/learn-cryptography.md b/website/translated_docs/fi/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/fi/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/fi/learn-governance.md b/website/translated_docs/fi/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/fi/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/fi/learn-interchain.md b/website/translated_docs/fi/learn-interchain.md deleted file mode 100644 index a6246da9ba4e..000000000000 --- a/website/translated_docs/fi/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. - -The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. - -## Overview - -- Interchain messages will *not* go on to the relay chain. -- Interchain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. - -## Example - -A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. - -When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/fi/learn-ledger.md b/website/translated_docs/fi/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/fi/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/fi/learn-registrar.md b/website/translated_docs/fi/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/fi/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/fi/learn-staking.md b/website/translated_docs/fi/learn-staking.md deleted file mode 100644 index 8c24a9fe69a3..000000000000 --- a/website/translated_docs/fi/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/fi/learn-treasury.md b/website/translated_docs/fi/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/fi/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/fi/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/fi/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/fi/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/fi/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/fi/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/fi/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/fi/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/fi/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/fi/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/fi/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/fi/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/fi/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/fi/maintain-guides-society-kusama.md b/website/translated_docs/fi/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/fi/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/fi/maintain-polkadot-parameters.md b/website/translated_docs/fi/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/fi/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/fi/redenomination.md b/website/translated_docs/fi/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/fi/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/fi/thousand-validators.md b/website/translated_docs/fi/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/fi/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/fil-PH/build-protocol-info.md b/website/translated_docs/fil-PH/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/fil-PH/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/fil-PH/build-transaction-construction.md b/website/translated_docs/fil-PH/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/fil-PH/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/fil-PH/claims.md b/website/translated_docs/fil-PH/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/fil-PH/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/fil-PH/getting-started.md b/website/translated_docs/fil-PH/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/fil-PH/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/fil-PH/grants.md b/website/translated_docs/fil-PH/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/fil-PH/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/fil-PH/kusama-adverserial-cheatsheet.md b/website/translated_docs/fil-PH/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/fil-PH/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/fil-PH/kusama-ledger.md b/website/translated_docs/fil-PH/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/fil-PH/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/fil-PH/kusama-parameters.md b/website/translated_docs/fil-PH/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/fil-PH/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/fil-PH/learn-accounts.md b/website/translated_docs/fil-PH/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/fil-PH/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/fil-PH/learn-availability.md b/website/translated_docs/fil-PH/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/fil-PH/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/fil-PH/learn-balance-transfers.md b/website/translated_docs/fil-PH/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/fil-PH/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/fil-PH/learn-bridges.md b/website/translated_docs/fil-PH/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/fil-PH/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/fil-PH/learn-cryptography.md b/website/translated_docs/fil-PH/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/fil-PH/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/fil-PH/learn-governance.md b/website/translated_docs/fil-PH/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/fil-PH/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/fil-PH/learn-ledger.md b/website/translated_docs/fil-PH/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/fil-PH/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/fil-PH/learn-registrar.md b/website/translated_docs/fil-PH/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/fil-PH/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/fil-PH/learn-staking.md b/website/translated_docs/fil-PH/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/fil-PH/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/fil-PH/learn-treasury.md b/website/translated_docs/fil-PH/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/fil-PH/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/fil-PH/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/fil-PH/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/fil-PH/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/fil-PH/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/fil-PH/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/fil-PH/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/fil-PH/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/fil-PH/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/fil-PH/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/fil-PH/maintain-guides-society-kusama.md b/website/translated_docs/fil-PH/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/fil-PH/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/fil-PH/maintain-polkadot-parameters.md b/website/translated_docs/fil-PH/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/fil-PH/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/fil-PH/redenomination.md b/website/translated_docs/fil-PH/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/fil-PH/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/fil-PH/thousand-validators.md b/website/translated_docs/fil-PH/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/fil-PH/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/fr/build-protocol-info.md b/website/translated_docs/fr/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/fr/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/fr/build-transaction-construction.md b/website/translated_docs/fr/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/fr/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/fr/claims.md b/website/translated_docs/fr/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/fr/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/fr/getting-started.md b/website/translated_docs/fr/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/fr/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/fr/grants.md b/website/translated_docs/fr/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/fr/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/fr/kusama-adverserial-cheatsheet.md b/website/translated_docs/fr/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/fr/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/fr/kusama-ledger.md b/website/translated_docs/fr/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/fr/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/fr/kusama-parameters.md b/website/translated_docs/fr/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/fr/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/fr/learn-accounts.md b/website/translated_docs/fr/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/fr/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/fr/learn-availability.md b/website/translated_docs/fr/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/fr/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/fr/learn-balance-transfers.md b/website/translated_docs/fr/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/fr/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/fr/learn-bridges.md b/website/translated_docs/fr/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/fr/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/fr/learn-cryptography.md b/website/translated_docs/fr/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/fr/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/fr/learn-governance.md b/website/translated_docs/fr/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/fr/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/fr/learn-ledger.md b/website/translated_docs/fr/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/fr/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/fr/learn-registrar.md b/website/translated_docs/fr/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/fr/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/fr/learn-staking.md b/website/translated_docs/fr/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/fr/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/fr/learn-treasury.md b/website/translated_docs/fr/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/fr/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/fr/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/fr/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/fr/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/fr/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/fr/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/fr/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/fr/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/fr/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/fr/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/fr/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/fr/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/fr/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/fr/maintain-guides-society-kusama.md b/website/translated_docs/fr/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/fr/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/fr/maintain-polkadot-parameters.md b/website/translated_docs/fr/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/fr/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/fr/redenomination.md b/website/translated_docs/fr/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/fr/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/fr/thousand-validators.md b/website/translated_docs/fr/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/fr/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/hi-IN/build-protocol-info.md b/website/translated_docs/hi-IN/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/hi-IN/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/hi-IN/build-transaction-construction.md b/website/translated_docs/hi-IN/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/hi-IN/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/hi-IN/claims.md b/website/translated_docs/hi-IN/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/hi-IN/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/hi-IN/getting-started.md b/website/translated_docs/hi-IN/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/hi-IN/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/hi-IN/grants.md b/website/translated_docs/hi-IN/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/hi-IN/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/hi-IN/kusama-adverserial-cheatsheet.md b/website/translated_docs/hi-IN/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/hi-IN/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/hi-IN/kusama-ledger.md b/website/translated_docs/hi-IN/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/hi-IN/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/hi-IN/kusama-parameters.md b/website/translated_docs/hi-IN/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/hi-IN/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/hi-IN/kusama-time-periods.md b/website/translated_docs/hi-IN/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/hi-IN/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/hi-IN/learn-accounts.md b/website/translated_docs/hi-IN/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/hi-IN/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/hi-IN/learn-availability.md b/website/translated_docs/hi-IN/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/hi-IN/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/hi-IN/learn-balance-transfers.md b/website/translated_docs/hi-IN/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/hi-IN/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/hi-IN/learn-bridges.md b/website/translated_docs/hi-IN/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/hi-IN/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/hi-IN/learn-cryptography.md b/website/translated_docs/hi-IN/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/hi-IN/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/hi-IN/learn-governance.md b/website/translated_docs/hi-IN/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/hi-IN/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/hi-IN/learn-ledger.md b/website/translated_docs/hi-IN/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/hi-IN/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/hi-IN/learn-registrar.md b/website/translated_docs/hi-IN/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/hi-IN/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/hi-IN/learn-staking.md b/website/translated_docs/hi-IN/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/hi-IN/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/hi-IN/learn-treasury.md b/website/translated_docs/hi-IN/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/hi-IN/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/hi-IN/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/hi-IN/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/hi-IN/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/hi-IN/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/hi-IN/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/hi-IN/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/hi-IN/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/hi-IN/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/hi-IN/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/hi-IN/maintain-guides-society-kusama.md b/website/translated_docs/hi-IN/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/hi-IN/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/hi-IN/maintain-polkadot-parameters.md b/website/translated_docs/hi-IN/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/hi-IN/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/hi-IN/maintain-sync.md b/website/translated_docs/hi-IN/maintain-sync.md deleted file mode 100644 index c0fe556b443b..000000000000 --- a/website/translated_docs/hi-IN/maintain-sync.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -id: maintain-sync -title: Set up a Full Node -sidebar_label: Set up a Full Node ---- - -If you're building dapps or products on a Substrate-based chain like Polkadot, Kusama or a custom Substrate implementation, you probably want the ability to run a node-as-a-back-end. After all, it's always better to rely on your own infrastructure than on a third-party-hosted one in this brave new decentralized world. - -This guide will show you how to connect to [Kusama network](https://kusama.network), but the same process applies to any other [Substrate](https://substrate.dev/docs/en/)-based chain. First, let's clarify the term _full node_. - -### Types of Nodes - -A blockchain's growth comes from a _genesis block_, _extrinsics_, and _events_. - -When a validator seals block 1, it takes the blockchain's state at block 0. It then applies all pending changes on top of it, and emits the events that are the result of these changes. Later, the state of the chain at block 1 is used in the same way to build the state of the chain at block 2, and so on. Once two thirds of the validators agree on a specific block being valid, it is finalized. - -An **archive node** keeps all the past blocks. An archive node makes it convenient to query the past state of the chain at any point in time. Finding out what an account's balance at a certain block was, or which extrinsics resulted in a certain state change are fast operations when using an archive node. However, an archive node takes up a lot of disk space - around Kusama's 1.6 millionth block this was around 15 to 20GB. - -A **full node** is _pruned_, meaning it discards all information older than 256 blocks, but keeps the extrinsics for all past blocks, and the genesis block. A node that is pruned this way requires much less space than an archive node. In order to query past state through a full node, a user would have to wait for the node to rebuild the chain up until that block. A full node _can_ rebuild the entire chain with no additional input from other nodes and become an archive node. One caveat is that if finality stalled for some reason and the last finalized block is more than 256 blocks behind, a pruned full node will not be able to sync to the network. - -Archive nodes are used by utilities that need past information - like block explorers, council scanners, discussion platforms like [Polkassembly](https://polkassembly.io), and others. They need to be able to look at past on-chain data. Full nodes are used by everyone else - they allow you to read the current state of the chain and to submit transactions directly to the chain without relying on a centralized infrastructure provider. - -Another type of node is a **light node**. A light node has only the runtime and the current state, but does not store past extrinsics and so cannot restore the full chain from genesis. Light nodes are useful for resource restricted devices. An interesting use-case of light nodes is a Chrome extension, which is a node in its own right, running the runtime in WASM format: https://github.com/paritytech/substrate-light-ui - -### Fast Install Instructions (Mac) - -> Not recommended if you're a validator. Please see [secure validator setup](maintain-guides-secure-validator) - -- Type terminal in the ios searchbar/searchlight to open the 'terminal' application -- Install Homebrew within the terminal by running: `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"` -- Then run: `brew install openssl cmake llvm` -- Install Rust in your terminal by running: `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh` -- Once Rust is installed, run the following command to clone and build the kusama code: - ``` - git clone https://github.com/paritytech/polkadot kusama - cd kusama - ./scripts/init.sh - cargo build --release - ``` -- Run the following command to start your node: `./target/release/polkadot --name "My node's name"` -- Find your node at https://telemetry.polkadot.io/#list/Kusama - -### Fast Install Instructions (Windows) - -> This works only on Windows Pro with virtualization enabled. - -> Not recommended if you're a validator. Please see [secure validator setup](maintain-guides-secure-validator) - -- Install WSL: https://docs.microsoft.com/en-us/windows/wsl/install-win10 -- Install Ubuntu (same webpage): https://docs.microsoft.com/en-us/windows/wsl/install-win10 -- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) -- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` -- Run the following: `sudo chmod +x polkadot` -- Run the following: `./polkadot --name "Your Node Name Here"` -- Find your node at https://telemetry.polkadot.io/#list/Kusama - -### Fast Install Instructions (Linux) - -> Not recommended if you're a validator. Please see [secure validator setup](maintain-guides-secure-validator) - -For the most recent binary please see the [release page](https://github.com/paritytech/polkadot/releases/) on the polkadot repository. The URL in the code snippet below may become slightly out-of-date. - -Also please note that the nature of pre-built binaries means that they may not work on your particular architecture or Linux distribution. If you see an error like `cannot execute binary file: Exec format error` it likely means the binary is not compatible with your system. You will either need to compile the [source code yourself](#clone-and-build) or use [docker](#using-docker). - -- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) -- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` -- Run the following: `sudo chmod +x polkadot` -- Run the following: `./polkadot --name "Your Node Name Here"` -- Find your node at https://telemetry.polkadot.io/#list/Kusama - -## Get Substrate - -Follow instructions as outlined [here](https://substrate.dev/docs/en/knowledgebase/getting-started) - note that Windows users will have their work cut out for them. It's better to use a virtual machine instead. - -Test if the installation was successful by running `cargo --version`. - -```bash -λ cargo --version -cargo 1.41.0 (626f0f40e 2019-12-03) -``` - -## Clone and Build - -The [paritytech/polkadot](https://github.com/paritytech/polkadot) repo's master branch contains the latest Kusama code. - -```bash -git clone https://github.com/paritytech/polkadot kusama -cd kusama -./scripts/init.sh -cargo build --release -``` - -Alternatively, if you wish to use a specific release, you can check out a specific tag (`v0.8.3` in the example below): - -```bash -git clone https://github.com/paritytech/polkadot kusama -cd kusama -git checkout tags/v0.8.3 -./scripts/init.sh -cargo build --release -``` - -## Run - -The built binary will be in the `target/release` folder, called `polkadot`. - -```bash -./target/release/polkadot --name "My node's name" -``` - -Use the `--help` flag to find out which flags you can use when running the node. For example, if [connecting to your node remotely](maintain-wss), you'll probably want to use `--ws-external` and `--rpc-cors all`. - -The syncing process will take a while depending on your bandwidth, processing power, disk speed and RAM. On a \$10 DigitalOcean droplet, the process can complete in some 36 hours. - -Congratulations, you're now syncing with Kusama. Keep in mind that the process is identical when using any other Substrate chain. - -## Running an Archive Node - -When running as a simple sync node (above), only the state of the past 256 blocks will be kept. When validating, it defaults to [archive mode](#types-of-nodes). To keep the full state use the `--pruning` flag: - -```bash -./target/release/polkadot --name "My node's name" --pruning archive -``` - -It is possible to almost quadruple synchronization speed by using an additional flag: `--wasm-execution Compiled`. Note that this uses much more CPU and RAM, so it should be turned off after the node is in sync. - -## Using Docker - -Finally, you can use Docker to run your node in a container. Doing this is a bit more advanced so it's best left up to those that either already have familiarity with docker, or have completed the other set-up instructions in this guide. If you would like to connect to your node's WebSockets ensure that you run you node with the `--rpc-external` and `--ws-external` commands. - -```zsh -docker run -p 9944:9944 parity/polkadot:v0.8.24 --name "calling_home_from_a_docker_container" --rpc-external --ws-external -``` diff --git a/website/translated_docs/hi-IN/redenomination.md b/website/translated_docs/hi-IN/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/hi-IN/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/hi-IN/thousand-validators.md b/website/translated_docs/hi-IN/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/hi-IN/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/hr-HR/build-protocol-info.md b/website/translated_docs/hr-HR/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/hr-HR/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/hr-HR/build-transaction-construction.md b/website/translated_docs/hr-HR/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/hr-HR/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/hr-HR/claims.md b/website/translated_docs/hr-HR/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/hr-HR/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/hr-HR/getting-started.md b/website/translated_docs/hr-HR/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/hr-HR/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/hr-HR/grants.md b/website/translated_docs/hr-HR/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/hr-HR/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/hr-HR/kusama-adverserial-cheatsheet.md b/website/translated_docs/hr-HR/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/hr-HR/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/hr-HR/kusama-ledger.md b/website/translated_docs/hr-HR/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/hr-HR/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/hr-HR/kusama-parameters.md b/website/translated_docs/hr-HR/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/hr-HR/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/hr-HR/learn-accounts.md b/website/translated_docs/hr-HR/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/hr-HR/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/hr-HR/learn-availability.md b/website/translated_docs/hr-HR/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/hr-HR/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/hr-HR/learn-balance-transfers.md b/website/translated_docs/hr-HR/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/hr-HR/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/hr-HR/learn-bridges.md b/website/translated_docs/hr-HR/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/hr-HR/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/hr-HR/learn-cryptography.md b/website/translated_docs/hr-HR/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/hr-HR/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/hr-HR/learn-governance.md b/website/translated_docs/hr-HR/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/hr-HR/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/hr-HR/learn-ledger.md b/website/translated_docs/hr-HR/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/hr-HR/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/hr-HR/learn-registrar.md b/website/translated_docs/hr-HR/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/hr-HR/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/hr-HR/learn-staking.md b/website/translated_docs/hr-HR/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/hr-HR/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/hr-HR/learn-treasury.md b/website/translated_docs/hr-HR/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/hr-HR/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/hr-HR/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/hr-HR/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/hr-HR/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/hr-HR/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/hr-HR/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/hr-HR/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/hr-HR/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/hr-HR/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/hr-HR/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/hr-HR/maintain-guides-society-kusama.md b/website/translated_docs/hr-HR/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/hr-HR/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/hr-HR/maintain-polkadot-parameters.md b/website/translated_docs/hr-HR/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/hr-HR/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/hr-HR/redenomination.md b/website/translated_docs/hr-HR/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/hr-HR/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/hr-HR/thousand-validators.md b/website/translated_docs/hr-HR/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/hr-HR/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/id-ID/build-deploy-parachains.md b/website/translated_docs/id-ID/build-deploy-parachains.md deleted file mode 100644 index 12bdd37a8797..000000000000 --- a/website/translated_docs/id-ID/build-deploy-parachains.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: build-deploy-parachains -title: Cara melihat dan menggunakan parachains -sidebar_label: Cara melihat dan menggunakan parachains ---- - -Panduan ini telah diperbarui untuk bekerja dengan testnet Alexander. - -## Cara melihat parachains - -On the [Polkadot UI](https://polkadot.js.org/apps/#/explorer) navigate to the `Chain State` tab. Select the `parachains` module and the `parachains()` then hit the `+` button. It will return an array of the currently active parachains. - -## Cara menyebarkan parachain Adder - -**You will need to have the minimum deposit needed to create a referendum. Currently this minimum is 5 DOT.** - -The `adder` parachain is a simple parachain that will keep a value in storage and add to this value as messages are sent to it. It can be found in the Polkadot repository under the `test-parachains` folder. - -> A slightly out-of-date video version of this guide presented by Adrian Brink is available [here](https://www.youtube.com/watch?v=pDqkzvA4C0E). When the two guides diverge, please refer to this written text as definitive and updated. - -### Membangun kode - -Langkah pertama adalah mengunduh secara lokal kode Polkadot dan beralih ke cabang ` v0.4 `. - -```bash -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git checkout v0.4 -``` - -Sekarang pastikan Anda telah menginstal Rust. - -```bash -curl https://sh.rustup.rs -sSf | sh -sudo apt install make clang pkg-config libssl-dev -rustup update -``` - -Now navigate to the `test-parachains` folder in the Polkadot code repository and run the build script. - -```bash -cd test-parachains -./build.sh -``` - -This will create the Wasm executable of the simple `adder` parachain contained in this folder. This parachain will simply add messages that are sent to it. The Wasm executable will output into the `parachains/test/res/adder.wasm` path so make sure you are able to find it there. - -You will need to build and run the collator node in order to get the genesis state of this parachain. - -Navigasikan ke direktori ` test-parachains / adder / collator ` dan jalankan perintah ` build ` dan ` run `. - -```bash -cargo build -cargo run -[ctrl-c] -``` - -Jangan ragu untuk menghentikan node collator segera. Anda akan mendapatkan beberapa output yang terlihat seperti ini: - -``` -Starting adder collator with genesis: -Dec: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 27, 77, 3, 221, 140, 1, 241, 4, 145, 67, -207, 156, 76, 129, 126, 75, 22, 127, 29, 27, 131, 229, 198, 240, 241, 13, 137, 186, 30, 123, 206] -Hex: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000011b4d03dd8c01f1049143cf9c4c817e4b167f1d1b83e5c6f0f10d89ba1e7bce -``` - -The important information is the hex string. This is your genesis state and you will need to save it for the next steps. - -### Menjalankan parachain - -Go to [Polkadot UI](https://polkadot.js.org/apps/#/extrinsics) on the `Extrinsics` tab. Select the account you wish to deploy the parachain from. You will need to create a referendum to deploy the parachain. - -Click on `democracy` -> `propose(proposal,value)` -> `parachains` -> `registerParachain(id,code,initial_head_data)`. - -In the `id` input enter in the id of the parachain. In the case of the simple adder it will be `100`. In the `code` field click on the page button and then upload the `adder.wasm` binary that was compiled from before. In the `initial_head_data` we will copy and paste the hex data that we got from running the collator node. In the `value` field you will need to input the minimum required value for creating a referendum. At the time of writing this is _5 DOT_ on the Alexander testnet. - -![mendaftarkan parachain](assets/parachain/register.png) - -If you navigate to the `Democracy` tab you will be able to see your proposal in the proposals section. - -Once you wait for the proposal to become a referendum you will be able to vote `Nay` or `Aye` on it. Assumably, you will vote Aye as this will be a vote for the deployment of your parachain. - -![referendum parachain](assets/parachain/referendum.png) - -After the voting period of your referendum goes through you will be able to query the state of your parachain. - -You can go to the `Chain State` tab and by querying the `parachains` state you should be able to see some information on your parachain. - -![info parachain](assets/parachain/info.png) - -### Berinteraksi dengan parachain - -_Segera hadir_ diff --git a/website/translated_docs/id-ID/build-exchange-integration.md b/website/translated_docs/id-ID/build-exchange-integration.md deleted file mode 100644 index 27da9d2321be..000000000000 --- a/website/translated_docs/id-ID/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. Tracking the chain head - -Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). - -That will give you a stream of hashes of the most recent finalised headers. - -When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. - -If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. - -## 2. Decoding blocks - -You will need to decode blocks from the basic data into useful fields. - -All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. - -For Genesis Polkadot, the header format is a five-field structure: - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -It also relies on `Extrinsic`. An *extrinsic* is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. - -The metadata itself is provided encoded in SCALE. Its format is: - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. - -Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various *modules*. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, *extrinsics*), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. Working with SS58 and account addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) *AccountId*. This is simply the public key for the x25519 cryptography used by Substrate. - -However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this *index* to identify the account. This index is much smaller than the 32-byte *AccountId*, and can usually be encoded in just a couple of bytes. - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: - -`0x00 ` - -**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. - -Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. - -Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. - -### Looking up an index - -Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. - -The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. - -For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. - -This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. - -This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. - -Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. - -## 4. Working with balances - -In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. - -NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. - -The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10**12). For completeness, The exact denominations of the Polkadot currency are: - -| Balance value | Name | -| ------------- | ---- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### Transferring balances - -To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. - -In general, Polkadot's transactions are encoded as *signed* `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. - -The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. - -NOTE: The nonce retrieved from storage does not take into account *pending* transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. - -The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. - -The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. - -Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. - -Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -The `function` *in this case* (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. - -The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. - -### Submitting and checking transactions - -Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. - -This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. - -The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. - -## Conclusion - -This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. - -If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). - -_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/id-ID/build-protocol-info.md b/website/translated_docs/id-ID/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/id-ID/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/id-ID/build-smart-contracts.md b/website/translated_docs/id-ID/build-smart-contracts.md deleted file mode 100644 index 7d9aa3ba71f5..000000000000 --- a/website/translated_docs/id-ID/build-smart-contracts.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: build-smart-contracts -title: Kontrak pintar -sidebar_label: Kontrak pintar ---- - -The Polkadot Relay Chain will not support smart contracts natively. However, parachains on Polkadot will support smart contracts. There are already announced projects such as [Edgeware](https://edgewa.re), and thanks to the Substrate built-in [contract pallet](https://substrate.dev/rustdocs/latest/pallet_contracts/index.html), it is likely that more parachains will support this feature. - -Additionally, there is the EVM pallet which lets a parachain implement the Ethereum Virtual Machine, thereby supporting almost direct ports of Ethereum contracts. Some of the projects using this approach are [Edgeware](https://edgewa.re), [Moonbeam](https://moonbeam.network/) and [Frontier](https://github.com/paritytech/frontier). - -A video version of the recap of the smart contract situation on Polkadot and Kusama is available [here](https://www.youtube.com/watch?v=fKHkFBXaUxQ). - -## Sumber daya - -Here is the list of current resources available to developers who want to get started writing smart contracts to deploy on parachains based on Substrate. - -- [Edgeware Contracts](https://contracts.edgewa.re) - Edgeware's documentation on Smart Contracts -- [ink!](https://github.com/paritytech/ink) - Parity's ink to write smart contracts. -- [Substrate Contracts Workshop](https://substrate.dev/substrate-contracts-workshop/#/) - Walks you through the basics of writing and deploying an ERC20 token using `ink!`. - -## Contoh - -Collected below are some community examples of smart contracts in `ink!`. Are you working on a smart contract example? Ask us to add it to this page! - -- [ Dimiliki ](https://github.com/JesseAbram/foRust/) - Port kontrak OpenZeppelin ` Ownable `. - -## Storage Rent - -Storage rent limits the footprint that a contract can have on the blockchain's storage. - -A contract deployed to the chain produces a code hash from which new instances of the chain can be created, but there is currently no rent applied to the code hash itself. The rent applies only to instances of this contract which have their own _contract accounts_. Deploying a code hash currently has a one-time byte-fee applied to the transaction, but no recurring cost. - -An account of a contract instance is charged proportionally to the amount of storage its account uses. When a contract's balance goes below a defined limit, the contract's account is turned into a "tombstone" (a hash of the contract's current state) and its storage is cleaned up. A tombstone contract can be restored by providing the data that was cleaned up when it became a tombstone as well as any additional funds needed to keep the contract alive. This fee will retroactively apply to missed rent periods. - -Block producers or regular users of the chain can "poke" a smart contract if they think it ran out of funds for rent. This will initiate the cleanup process and the _poker_ will get a finder's fee. - -## What is the difference between developing a smart contract versus a parachain? - -### Lapisan Abstraksi - -When you write a smart contract you are creating the instructions that will be deployed and associated to a specific chain address. - -In comparison, a runtime module is the entire logic of a chain's state transitions (what's called a state transition function). - -Smart contracts must consciously implement upgradeability while parachains will have the ability to swap out their code entirely through a root command or via the governance pallet. - -When you build a smart contract, it will eventually be deployed to a target chain with its own environment. Parachains allow the developer to declare the environment of their own chain, even allowing others to write smart contracts for it. - -### Biaya Gas - -Smart contracts must find a way to limit their own execution, or else full nodes are vulnerable to DOS attacks. An infinite loop in a smart contract, for example, could consume the computational resources of an entire chain, preventing others from using it. The [halting problem](https://en.wikipedia.org/wiki/Halting_problem) shows that with a powerful enough language, it is impossible to know ahead of time whether or not a program will ever cease execution. Some platforms, such as Bitcoin, get around this constraint by providing a very restricted scripting language. Others, such as Ethereum, "charge" the smart contract "gas" for the rights to execute their code. If a smart contract does get into a state where execution will never halt, it eventually runs out of gas, ceases execution, and any state transition that would have been made by the smart contract is rolled back. - -Parachains can implement arbitrarily powerful programming languages and also contain no notion of gas for their own native logic. This means that some functionality is easier to implement for the developer, but it also means there are some constructs, such as a loop without a terminating condition, which should _never_ be implemented. Leaving certain logic, such as complex loops that could possibly run indefinitely, to a non-smart contract layer, or even trying to eliminate it entirely, will often be a wiser choice. - -## Resources - -- [When should I build a Substrate runtime versus a Substrate smart contract](https://stackoverflow.com/a/56041305) - From a technical standpoint answers the question of when a developer might choose to develop a runtime versus a smart contract. diff --git a/website/translated_docs/id-ID/build-transaction-construction.md b/website/translated_docs/id-ID/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/id-ID/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/id-ID/claims.md b/website/translated_docs/id-ID/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/id-ID/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/id-ID/contributing.md b/website/translated_docs/id-ID/contributing.md deleted file mode 100644 index c42be6789359..000000000000 --- a/website/translated_docs/id-ID/contributing.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: contributing -title: Berkontribusi -sidebar_label: Berkontribusi ---- - -The wiki was started and is maintained by the Web3 Foundation. It is an open source project and aims to be the most extensive resource of knowledge on Polkadot and the Polkadot ecosystem. A large part of the material currently focuses on Polkadot directly but it is not opposed to covering informational material for community projects. Please do not try to pull request any marketing material as this will be rejected. - -Pull requests, discussions, and contributions from the community are encouraged. Active community members who demonstrate a record of good contributions may be given write access to the repository. Otherwise, Web3 Foundation holds the administrative position and final say on the content that is included. Specifically the Technical Education team at the foundation are most directly involved. - -> There is video guide on how to contribute to the wiki [here](https://www.youtube.com/watch?v=6i55KOcy7B0). - -## Bagaimana cara Berkontribusi - -Contributing to the wiki is easy with a GitHub account. Every page is a MarkDown file, which is a [very easy to learn](https://guides.github.com/features/mastering-markdown/) syntax extension to plain text that makes creating links, rendering images, and nice-looking formatting simple. - -Each page has an "Edit" button in the top right corner of the content. By clicking this button you are taken to the GitHub sign in page, where you can either log in or create an account. - -![](assets/edit_button.png) - -Once logged in, you'll be taken to the GitHub text editor in which you can make your edits directly. When you've completed your changes, you can add any specific details on what was changed and commit to a new branch to create a new Pull Request to the repository. From there one of the maintainers will either merge it in or request changes very soon. - -![](assets/contributing.png) ![](assets/creating-pull-request.png) - -Remember that after you click "Propose Changes", you must also click on "Create Pull Request" on the next page. - -![](assets/creating-pull-request-2.png) - -## Aturan - -There are a few basic ground-rules for contributors: - -1. ** Tidak ada ` - memaksa ` mendorong ** atau memodifikasi riwayat Git dengan cara apa pun. -2. Pull requests are preferred to issues, especially for small changes such as typos. Issues should be used for generic or broad-based changes or missing content. -3. Only use **non-master branches**. -4. **Significant modifications**, even by contributors, ought to be subject to a **pull request** to solicit feedback from other contributors. -5. Pull requests to solicit feedback are _encouraged_ for any other non-trivial contribution but left to the discretion of the contributor. -6. Contributors should attempt to adhere to the prevailing MarkDown style, language, and layout. -7. Correct grammar should be used at all times. Pull requests with typos will not be merged until fixed. -8. Care should be taken to remain as objective and informative as possible. There should be no editorializing, and external bias should not be present. -9. We use a plugin called Prettier to standardize the style across documents. You can run this on your local copy with `npx run prettier --save`, but for simplicity we also have a bot which runs this for us in your PRs. - -## Heritage - -This document was based on the Level contribution guidelines located here: [https://github.com/Level/community/blob/master/CONTRIBUTING.md](https://github.com/Level/community/blob/master/CONTRIBUTING.md) diff --git a/website/translated_docs/id-ID/getting-started.md b/website/translated_docs/id-ID/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/id-ID/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/id-ID/grants.md b/website/translated_docs/id-ID/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/id-ID/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/id-ID/kusama-adverserial-cheatsheet.md b/website/translated_docs/id-ID/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/id-ID/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/id-ID/kusama-ledger.md b/website/translated_docs/id-ID/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/id-ID/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/id-ID/kusama-parameters.md b/website/translated_docs/id-ID/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/id-ID/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/id-ID/kusama-time-periods.md b/website/translated_docs/id-ID/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/id-ID/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/id-ID/learn-UI.md b/website/translated_docs/id-ID/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/id-ID/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/id-ID/learn-accounts.md b/website/translated_docs/id-ID/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/id-ID/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/id-ID/learn-availability.md b/website/translated_docs/id-ID/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/id-ID/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/id-ID/learn-balance-transfers.md b/website/translated_docs/id-ID/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/id-ID/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/id-ID/learn-bridges.md b/website/translated_docs/id-ID/learn-bridges.md deleted file mode 100644 index 5de65a4b15b5..000000000000 --- a/website/translated_docs/id-ID/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Jembatan -sidebar_label: Jembatan ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/id-ID/learn-cryptography.md b/website/translated_docs/id-ID/learn-cryptography.md deleted file mode 100644 index c90b40feac57..000000000000 --- a/website/translated_docs/id-ID/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Penjelasan Kriptografi -sidebar_label: Penjelasan Kriptografi -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Algoritma Hashing - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs dan Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/id-ID/learn-governance.md b/website/translated_docs/id-ID/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/id-ID/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/id-ID/learn-interchain.md b/website/translated_docs/id-ID/learn-interchain.md deleted file mode 100644 index a6246da9ba4e..000000000000 --- a/website/translated_docs/id-ID/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. - -The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. - -## Overview - -- Interchain messages will *not* go on to the relay chain. -- Interchain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. - -## Example - -A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. - -When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/id-ID/learn-ledger.md b/website/translated_docs/id-ID/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/id-ID/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/id-ID/learn-registrar.md b/website/translated_docs/id-ID/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/id-ID/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/id-ID/learn-staking.md b/website/translated_docs/id-ID/learn-staking.md deleted file mode 100644 index 8c24a9fe69a3..000000000000 --- a/website/translated_docs/id-ID/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/id-ID/learn-treasury.md b/website/translated_docs/id-ID/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/id-ID/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/id-ID/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/id-ID/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/id-ID/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/id-ID/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/id-ID/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/id-ID/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/id-ID/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/id-ID/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/id-ID/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/id-ID/maintain-guides-society-kusama.md b/website/translated_docs/id-ID/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/id-ID/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/id-ID/maintain-polkadot-parameters.md b/website/translated_docs/id-ID/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/id-ID/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/id-ID/redenomination.md b/website/translated_docs/id-ID/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/id-ID/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/id-ID/thousand-validators.md b/website/translated_docs/id-ID/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/id-ID/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/it/build-protocol-info.md b/website/translated_docs/it/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/it/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/it/build-transaction-construction.md b/website/translated_docs/it/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/it/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/it/claims.md b/website/translated_docs/it/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/it/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/it/getting-started.md b/website/translated_docs/it/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/it/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/it/grants.md b/website/translated_docs/it/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/it/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/it/kusama-adverserial-cheatsheet.md b/website/translated_docs/it/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/it/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/it/kusama-ledger.md b/website/translated_docs/it/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/it/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/it/kusama-parameters.md b/website/translated_docs/it/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/it/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/it/kusama-time-periods.md b/website/translated_docs/it/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/it/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/it/learn-accounts.md b/website/translated_docs/it/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/it/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/it/learn-availability.md b/website/translated_docs/it/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/it/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/it/learn-balance-transfers.md b/website/translated_docs/it/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/it/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/it/learn-bridges.md b/website/translated_docs/it/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/it/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/it/learn-cryptography.md b/website/translated_docs/it/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/it/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/it/learn-governance.md b/website/translated_docs/it/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/it/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/it/learn-ledger.md b/website/translated_docs/it/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/it/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/it/learn-registrar.md b/website/translated_docs/it/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/it/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/it/learn-staking.md b/website/translated_docs/it/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/it/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/it/learn-treasury.md b/website/translated_docs/it/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/it/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/it/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/it/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/it/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/it/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/it/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/it/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/it/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/it/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/it/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/it/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/it/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/it/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/it/maintain-guides-society-kusama.md b/website/translated_docs/it/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/it/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/it/maintain-polkadot-parameters.md b/website/translated_docs/it/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/it/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/it/redenomination.md b/website/translated_docs/it/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/it/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/it/thousand-validators.md b/website/translated_docs/it/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/it/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ja/build-exchange-integration.md b/website/translated_docs/ja/build-exchange-integration.md deleted file mode 100644 index 27da9d2321be..000000000000 --- a/website/translated_docs/ja/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. Tracking the chain head - -Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). - -That will give you a stream of hashes of the most recent finalised headers. - -When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. - -If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. - -## 2. Decoding blocks - -You will need to decode blocks from the basic data into useful fields. - -All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. - -For Genesis Polkadot, the header format is a five-field structure: - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -It also relies on `Extrinsic`. An *extrinsic* is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. - -The metadata itself is provided encoded in SCALE. Its format is: - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. - -Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various *modules*. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, *extrinsics*), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. Working with SS58 and account addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) *AccountId*. This is simply the public key for the x25519 cryptography used by Substrate. - -However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this *index* to identify the account. This index is much smaller than the 32-byte *AccountId*, and can usually be encoded in just a couple of bytes. - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: - -`0x00 ` - -**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. - -Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. - -Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. - -### Looking up an index - -Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. - -The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. - -For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. - -This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. - -This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. - -Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. - -## 4. Working with balances - -In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. - -NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. - -The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10**12). For completeness, The exact denominations of the Polkadot currency are: - -| Balance value | Name | -| ------------- | ---- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### Transferring balances - -To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. - -In general, Polkadot's transactions are encoded as *signed* `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. - -The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. - -NOTE: The nonce retrieved from storage does not take into account *pending* transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. - -The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. - -The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. - -Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. - -Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -The `function` *in this case* (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. - -The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. - -### Submitting and checking transactions - -Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. - -This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. - -The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. - -## Conclusion - -This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. - -If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). - -_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/ja/build-extrinsic-format.md b/website/translated_docs/ja/build-extrinsic-format.md deleted file mode 100644 index 92d1692bb078..000000000000 --- a/website/translated_docs/ja/build-extrinsic-format.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: build-extrinsic-format -title: Polkadot Extrinsic Format aka Transaction Format -sidebar_label: Polkadot Extrinsic Format aka Transaction Format ---- - -## Old Format - -For reference, the **old** extrinsic format was: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] -``` - -## Current Format - -The Polkadot extrinsic format is: - -``` -[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] -``` - -The *original* fields refer to the following from the old extrinsic format: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] -``` - -The specific format for the new address type is one of 5 sub-formats, switched on the first byte: - -- `0xff, 32-byte account id` -- `0xfe, 8-byte account index` -- `0xfd, 4-byte account index` -- `0xfc, 2-byte account index` -- `[0xf0...0xfb] (invalid, reserved for future use)` -- `[0x00...0xef] 1-byte account index (less than 0xf0)` - -The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. - -In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). - -## Source - -[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/ja/build-protocol-info.md b/website/translated_docs/ja/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/ja/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ja/build-rust-style-guide.md b/website/translated_docs/ja/build-rust-style-guide.md deleted file mode 100644 index 52f24a8a5b1b..000000000000 --- a/website/translated_docs/ja/build-rust-style-guide.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: build-rust-style-guide -title: Style Guide for Rust in Polkadot -sidebar_label: Style Guide for Rust in Polkadot ---- - -- Indent using tabs -- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. -- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. -- Never have spaces on a line prior to a non-whitespace character -- Follow-on lines are only ever a single indent from the original line. -```rust -fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { - let x = some_long_variable_a * some_long_variable_b - - some_long_variable_b / some_long_variable_a - + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); - x > 10 -} -``` -- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: -```rust -fn calculate( - some_long_variable_a: f32, - some_long_variable_b: f32, - some_long_variable_c: f32, -) -> f32 { - (-some_long_variable_b + sqrt( - // two parens open, but since we open & close them both on the - // same line, only one indent level is used - some_long_variable_b * some_long_variable_b - - 4 * some_long_variable_a * some_long_variable_c - // both closed here at beginning of line, so back to the original indent - // level - )) / (2 * some_long_variable_a) -} -``` -- `where` is indented, and its items are indented one further -- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. - -```rust -// OK -fn foo( - really_long_parameter_name_1: SomeLongTypeName, - really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, - shrt_nm_2: u8, -) { - ... -} - -// NOT OK -fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, shrt_nm_2: u8) { - ... -} - -``` - -```rust -{ - // Complex line (not just a function call, also a let statement). Full - // structure. - let (a, b) = bar( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Long, simple function call. - waz( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Short function call. Inline. - baz(a, b); -} -``` - -- Always end last item of a multi-line comma-delimited set with `,` when legal: -```rust -struct Point { - x: T, - y: T, // <-- Multiline comma-delimited lists end with a trailing , -} - -// Single line comma-delimited items do not have a trailing `,` -enum Meal { Breakfast, Lunch, Dinner }; -``` - -- Avoid trailing `;`s where unneeded. -```rust -if condition { - return 1 // <-- no ; here -} -``` - -- `match` arms may be either blocks or have a trailing `,` but not both. -- Blocks should not be used unnecessarily. -```rust -match meal { - Meal::Breakfast => "eggs", - Meal::Lunch => { check_diet(); recipe() }, -// Meal::Dinner => { return Err("Fasting") } // WRONG - Meal::Dinner => return Err("Fasting"), -} -``` diff --git a/website/translated_docs/ja/build-transaction-construction.md b/website/translated_docs/ja/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/ja/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/ja/claims.md b/website/translated_docs/ja/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/ja/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ja/getting-started.md b/website/translated_docs/ja/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/ja/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ja/grants.md b/website/translated_docs/ja/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/ja/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ja/kusama-adverserial-cheatsheet.md b/website/translated_docs/ja/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/ja/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ja/kusama-ledger.md b/website/translated_docs/ja/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/ja/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/ja/kusama-parameters.md b/website/translated_docs/ja/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/ja/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ja/kusama-time-periods.md b/website/translated_docs/ja/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/ja/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ja/learn-UI.md b/website/translated_docs/ja/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/ja/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/ja/learn-accounts.md b/website/translated_docs/ja/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/ja/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ja/learn-availability.md b/website/translated_docs/ja/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/ja/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/ja/learn-balance-transfers.md b/website/translated_docs/ja/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/ja/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/ja/learn-bridges.md b/website/translated_docs/ja/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/ja/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ja/learn-cryptography.md b/website/translated_docs/ja/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/ja/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ja/learn-governance.md b/website/translated_docs/ja/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/ja/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ja/learn-interchain.md b/website/translated_docs/ja/learn-interchain.md deleted file mode 100644 index a6246da9ba4e..000000000000 --- a/website/translated_docs/ja/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. - -The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. - -## Overview - -- Interchain messages will *not* go on to the relay chain. -- Interchain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. - -## Example - -A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. - -When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/ja/learn-ledger.md b/website/translated_docs/ja/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/ja/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ja/learn-registrar.md b/website/translated_docs/ja/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/ja/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ja/learn-staking.md b/website/translated_docs/ja/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/ja/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ja/learn-treasury.md b/website/translated_docs/ja/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/ja/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ja/maintain-governance-index.md b/website/translated_docs/ja/maintain-governance-index.md deleted file mode 100644 index f2371610e1fa..000000000000 --- a/website/translated_docs/ja/maintain-governance-index.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -id: maintain-governance-index -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. - -All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. - -The following steps are the governance procedure in the Polkadot network: - -- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) -- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) -- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) - -To better understand how the council is formed, please read [this section](#council). - -### Proposing Referenda - -- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. - -- **[Council](#council)**: - - Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. - - Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) - -### Voting for a proposal - -To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). - -``` -Example: - -Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes -``` - -According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. - -### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -voters - the total number of voting tokens - -electorate - the total number of DOTs tokens issued in the network -``` - -**Super-Majority Approve** - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ - -**Super-Majority Against** - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ - -**Simple-Majority** - -Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ - -*To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)*. - -``` -Example: - -Assume we only have 1,500 DOTs tokens in total. - -John - 500 DOTs -Peter - 100 DOTs -Lilly - 150 DOTs -JJ - 150 DOTs -Ken - 600 DOTs - -John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -voters = 1050 -electorate = 1500 -``` - -$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ - -$${13.887} < {15.492}$$ - -Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. - -## Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: - -``` -Max votes = tokens * periods -``` - -Based on the current testnet setting, the maximum number of lock periods is set to 6. - -**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** - - -## Adaptive Quorum Biasing - -Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. - -Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. - -Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. - -In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -## Council - -Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). - -### How to be a council member? - -![](assets/governance/approval-vote.png) - - At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. - -To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. - -Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. - -Let's take a look at the example below. - -||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. - -### Resources - -- [Governance Description](learn-governance#referenda) -- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) - -## [Usage of DOT](learn-DOT#dots-for-governance) - -## Guides - -### [How to create a proposal]() -### [How to join the council]() -### [How to propose a referenda]() diff --git a/website/translated_docs/ja/maintain-guides-how-to-join-council.md b/website/translated_docs/ja/maintain-guides-how-to-join-council.md deleted file mode 100644 index 82b47e7e7358..000000000000 --- a/website/translated_docs/ja/maintain-guides-how-to-join-council.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: maintain-guides-how-to-join-council -title: 協議会への参加 -sidebar_label: 協議会への参加 ---- - -協議会は、PolkadotおよびKusamaのステークホルダーたちを代表するチェーン上のアカウントから選ばれたもので構成されています。協議会にはガバナンスにおける主な役割が主に二つあります。それは、1) 投票を提案すること、2) 危険および悪意のある投票を拒否権を使い否認することです。協議会についてより詳しく知るためには[ガバナンスページ](learn-governance#council)　をご覧下さい。このガイドは協議会に立候補する方法について説明します。 - -## 立候補を表明する - -Submitting your candidacy for the council requires a small bond of DOT / KSM. The bond will be forfeited if your candidacy does not win or become a runner-up and will be kept otherwise. You only receive your bond back, if you manually renounce your candidacy before losing. Runners-up are selected after every round and are reserved members in case one of the winners gets forcefully removed. - -> 現在Polkadotにおいて協議会に立候補する場合の担保額は100DOT、Kusamaにおいて協議会に立候補する場合の担保額は0.1666KSMです。 - -協議会に立候補をする前には、選挙が開始され、すぐに投票してもらえるように、前以て出馬することをアナウンスし、サポーターに対し周知活動しておくことが良いでしょう。万が一、誰も投票してくれない場合は自分で自身に対し票をいれることができます。 - -Go to [Polkadot Apps Dashboard](https://polkadot.js.org/apps) and navigate to the "Council" tab. Click the button on the right that says "Submit Candidacy." - -![立候補を表明するボタン](assets/council/polkadotjs_submit_candidancy.png) - -トランザクションを行った後に、「立候補者」の下にあなたのアカウントが表示されます。 - -![立候補者リスト](assets/council/polkadotjs_candidates.png) - -まず、自分自身のアカウントに対して票を入れ、例を作っておくことが良いと考えれらます。 - -## 立候補者に対して投票する - -Next to the button to submit candidacy is another button titled "Vote." You will click this button to make a vote for yourself (optional). - -![UIの投票ボタン](assets/council/polkadotjs_vote_button.png) - -The council uses [Phragmén](learn-phragmen) approval voting, which is also used in the validator elections. This means that you can choose up to 16 distinct candidates to vote for and your stake will equalize between them. For this guide, choose to approve your own candidacy by clicking on the switch next to your account and changing it to say "Aye." - -![UIでの投票ポップアップ](assets/council/polkadotjs_voting.png) - -## 当選 - -If you are one of the lucky ones to win a council election you will see your account move underneath the row "Members". - -![council members list](assets/council/polkadotjs_council_members.png) - -これであなたも協議会に参加し、提案を行うことができます。よりアクティブなディスカッションに参加するには[Kusamaガバナンスチャンネル](https://matrix.to/#/!QXMnIJzxlnVrvRzhUA:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation)まで。 diff --git a/website/translated_docs/ja/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/ja/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/ja/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/ja/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/ja/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/ja/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/ja/maintain-guides-how-to-nominate.md b/website/translated_docs/ja/maintain-guides-how-to-nominate.md deleted file mode 100644 index d846a22dddd0..000000000000 --- a/website/translated_docs/ja/maintain-guides-how-to-nominate.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: maintain-guides-how-to-nominate -title: How to nominate -sidebar_label: How to nominate ---- - -This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. - -It has been updated for the Alexander testnet and Polkadot release PoC-4. - -## Create `stash` and `controller` accounts - -We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. - -The first step is to create two accounts by going to the *Accounts* tab on the Polkadot Dashboard and clicking on [*Add account*](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. - -![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) - -Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. - -## Nominating - -It is now time to setup our nominator. We will do the following: -- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. -- Select the `controller`. This is the account that will decide when to start or stop nominating. - -First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. - -![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. -- **Controller account** - select the `controller` account created earlier. -- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). -- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). - -Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. - -![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) - -## Nominating a validator - -Go to the *Staking Overview* tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. - -![Validators](assets/guides/how-to-nominate/validators.png) - -Go back to the *Account Actions* tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). - -![Nominating](assets/guides/how-to-nominate/nominating.jpg) - -**Congratulations!** You are now a nominator. - -If you return to the *Staking Overview* tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. - -![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) - -## How to stop nominating - -To stop nominating simply return to the *Account Actions* tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/ja/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/ja/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/ja/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/ja/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/ja/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/ja/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/ja/maintain-guides-society-kusama.md b/website/translated_docs/ja/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/ja/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ja/maintain-polkadot-parameters.md b/website/translated_docs/ja/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/ja/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ja/redenomination.md b/website/translated_docs/ja/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/ja/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ja/thousand-validators.md b/website/translated_docs/ja/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/ja/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ko/build-exchange-integration.md b/website/translated_docs/ko/build-exchange-integration.md deleted file mode 100644 index 27da9d2321be..000000000000 --- a/website/translated_docs/ko/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. Tracking the chain head - -Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). - -That will give you a stream of hashes of the most recent finalised headers. - -When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. - -If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. - -## 2. Decoding blocks - -You will need to decode blocks from the basic data into useful fields. - -All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. - -For Genesis Polkadot, the header format is a five-field structure: - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -It also relies on `Extrinsic`. An *extrinsic* is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. - -The metadata itself is provided encoded in SCALE. Its format is: - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. - -Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various *modules*. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, *extrinsics*), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. Working with SS58 and account addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) *AccountId*. This is simply the public key for the x25519 cryptography used by Substrate. - -However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this *index* to identify the account. This index is much smaller than the 32-byte *AccountId*, and can usually be encoded in just a couple of bytes. - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: - -`0x00 ` - -**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. - -Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. - -Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. - -### Looking up an index - -Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. - -The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. - -For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. - -This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. - -This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. - -Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. - -## 4. Working with balances - -In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. - -NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. - -The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10**12). For completeness, The exact denominations of the Polkadot currency are: - -| Balance value | Name | -| ------------- | ---- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### Transferring balances - -To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. - -In general, Polkadot's transactions are encoded as *signed* `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. - -The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. - -NOTE: The nonce retrieved from storage does not take into account *pending* transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. - -The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. - -The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. - -Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. - -Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -The `function` *in this case* (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. - -The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. - -### Submitting and checking transactions - -Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. - -This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. - -The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. - -## Conclusion - -This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. - -If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). - -_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/ko/build-extrinsic-format.md b/website/translated_docs/ko/build-extrinsic-format.md deleted file mode 100644 index 122980985968..000000000000 --- a/website/translated_docs/ko/build-extrinsic-format.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: build-extrinsic-format -title: Polkadot Extrinsic Format aka Transaction Format -sidebar_label: Polkadot Extrinsic Format aka Transaction Format ---- - -## 이전 포맷 - -참고로 **예전** 트랜잭션 포맷은 아래와 같습니다.: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length), 첫 세가지 필드에 서명 (account-id, index, call에 서명함 - 역자 주) (64 bytes) ] -``` - -## 현재 포맷 - -폴카닷(Polkadot) 트랜잭션 포맷은 아래와 같습니다.: - -``` -[ address (1/3/5/9/33-bytes, 첫번째 바이트에 따라 다름), index (4-bytes), call (dynamic-length), *오리지널* 필드에 서명함 (64 bytes) ] -``` - -*오리지널* 필드들은 예전 트랜잭션 포맷에서 다음과 같은 요소들을 참조합니다. - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] -``` - -새 주소 타입을 위한 특정 형식은 아래 5개의 하위 형식 중 하나이며 첫 번째 바이트로 전환됩니다. - -- `0xff, 32-byte account id` -- `0xfe, 8-byte account index` -- `0xfd, 4-byte account index` -- `0xfc, 2-byte account index` -- `[0xf0...0xfb] (유효하지 않음, 나중에 사용하기 위해 남겨놓음)` -- `[0x00...0xef] 1-byte account index (0xf0보다 작음)` - -계정 인덱스 변형들은 상당히 작지만 스테이트에서 조회가 필요합니다. 인덱스가 계정을 변경할 때 트랜잭션 리플레이 어택을 피하기 위해 서명은 첫 번째 필드인 인덱스가 아닌 계정 ID로 서명되므로 이것때문에 인덱스가 다른 ID를 조회하는 데 사용되면 이전의 모든 서명이 무효화됩니다. - -발신자 필드 뿐만 아니라 이전 형식의 AccountId(32-bytes)였던 Call/Propose(PrivCall) 필드에 대한 파라매터는 이제 Address(1/3/5/9/33-bytes)입니다. - -## 출처 - -[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/ko/build-hackathon.md b/website/translated_docs/ko/build-hackathon.md deleted file mode 100644 index 6a3a4feef48e..000000000000 --- a/website/translated_docs/ko/build-hackathon.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: build-hackathon -title: Hackathon -sidebar_label: Hackathon ---- - -As one of our objectives in the Web3 Foundation is promoting the [Web3 technology stack](http://wiki.web3.foundation/en/latest/tech_stack/tech_stack_overview/), we would like to support any individual or team who wants to organize a hackathon that gets more developers to understand Polkadot and Substrate in your city or online. - -We are not only providing technical resources for you, but we can have someone from our team give a hands-on workshop/presentation about the technology to help participants get started hacking on it more quickly. - -## Ideas - -- NFT -- Bonded Tokens -- New governance pallets with different styles of voting & democracy -- Upgrade the TCR pallet -- IPFS integration -- 분산화된 신원 인증 솔루션 (Decentralized identity solutions) -- Oracle pallet -- 제네럴 스테이트 체널/플라즈마 체인의 구현 (Implement Generalized State Channel/Plasma Chain) -- DeX (Decentralized Exchange) -- 밸리데이터 퍼포먼스 모니터링 툴 (Tools for monitoring validator performance) -- dApps across different parachains - -## 왜 해커톤을 해야만 할까요? - -- Web3의 비전을 전달하는 것을 사랑하기 때문에 -- 최신 기술을 배우기 위해서 -- 개발자들이 어플리케이션을 만들기 위해 Web3 기술 스택이 알맞다는 것을 믿으니까 -- 사람들과 만나는 것을 좋아하니까 - -## 워크샵과 해커톤은 어떻게 다른가요? - -Hackathon is aimed at participants who want to deliver their prototype and demonstrate their ideas to reality in a short period (few hours - one day). Workshops are more for getting developers familiar with the tooling and understanding more about what are the resources currently available and how they can make use of it. - -## 어떻게 당신의 도시에서 해커톤을 열 수 있나요? - -1. 해커톤 지원서를 제출합니다 (Coming soon.) -2. 리뷰하고 -3. 결정한 뒤 -4. 진행합니다. - -## 어떻게 당신을 도와드릴 수 있을까요? - -- 기술적인 리소스나 자료들을 제공하고. -- 장소를 찾아보고. -- 원활한 해커톤 진행을 할 수 있도록 합니다. - -## Upcoming Hackathons - -- [Hello World! by Polkadot](https://gitcoin.co/hackathon/polkadot/onboard) - A collaborative hackathon celebrating the integration of Polkadot and Kusama into the Gitcoin platform. Has many sets of smaller challenges that will reward in either DOT or KSM. Open from 15 October - 12 November 2020. - -## Past Hackathons - -- [Hackusama](https://hackusama.devpost.com/) - A 7-week online hackathon being launched for developers to "Build a Blockchain" or submit your wildest tools, visualizations, and ideas to the "Open Hack" category. Many high quality submissions were received. - -## 참고 자료들 - -- [Substrate Knowledge Base](https://substrate.dev/docs/en/) - -## Support / Contact - -If you have any questions regarding organizing a hackathon, please free feel to contact us by [email](mailto:events@web3.foundation) or ask us via [Riot](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org) chat. diff --git a/website/translated_docs/ko/build-networks.md b/website/translated_docs/ko/build-networks.md deleted file mode 100644 index 8bd2f21aaac0..000000000000 --- a/website/translated_docs/ko/build-networks.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -id: build-networks -title: Networks -sidebar_label: Networks ---- - -다음 커맨드들은 다른 네트워크들 끼리 연결하는데 사용 할 수 있습니다. - -## Development - -다음 명령어로 폴카닷(polkadot)을 설치하고 `polkadot` 바이너리를 `PATH`에 등록하세요. - -```bash -cargo install --git https://github.com/paritytech/polkadot.git polkadot -``` - -다음 명령어를 터미널에 입력해서 단순한 단일 노드 개발 "네트워크"를 작동 시킬 수 있습니다. - -```bash -polkadot --dev -``` - -http://github.com/paritytech/polka-ui나 http://github.com/paritytech/polkadot-ui을 클로닝하거나 만들면서 노닥거릴수 있습니다. 아니면 https://polkadot.js.org/apps을 가리킬 수도 있습니다. - -## Krumme Lanke (베를린 남서쪽에 있는 호수 이름 - 역자 주 ) - -Krumme Lanke는 PoC-2의 개발단계에서 사용했던 테스트넷 네트워크 입니다. 다음 명령어로 Polkadot PoC-2를 설치하고 `polkadot` 바이너리를 `PATH`에 등록하세요. - -글로벌 "Krumme Lanke" 테스트넷에 기본적으로 연결되어서 동작합니다. 명령어는 아래와 같습니다. - -```bash -cargo install --git https://github.com/paritytech/substrate.git --branch v0.2 polkadot -``` - -Alexander 는 PoC-3와 PoC-4 개발단계에서 사용했던 테스트넷 네트워크 입니다. 다음 명령어로 Polkadot PoC-4를 설치하고 `polkadot` 바이너리를 `PATH`에 등록하세요. - -```bash -polkadot -``` - -## Alexander (PoC-4) - -글로벌 "Alexander" 테스트넷에 기본적으로 연결되어서 동작합니다. 명령어는 아래와 같습니다. - -다중 노드 합의 알고리즘 실행을 로컬에서 보고 싶다면 로컬 testnet을 생성 할 수 있습니다. 두 개의 터미널이 열려 있어야합니다. 하나는 다음을 실행하십시오. - -```bash -cargo install --git https://github.com/paritytech/polkadot.git --branch v0.4 polkadot -``` - -다른 터미널에서는 다음 명령어를 실행하세요. - -```bash -polkadot -``` - -## 2개의 노드로 테스트넷 작동시키기 - -`ALICE_BOOTNODE_ID_HERE`를 첫 번째 터미널의 출력에서 노드 ID로 대체했는지 확인하십시오. - -```bash -polkadot --chain=local --validator --key Alice -d /tmp/alice -``` - -and in the other, run: - -```bash -polkadot --chain=local --validator --key Bob -d /tmp/bob --port 30334 --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE' -``` - -Ensure you replace `ALICE_BOOTNODE_ID_HERE` with the node ID from the output of the first terminal. diff --git a/website/translated_docs/ko/build-protocol-info.md b/website/translated_docs/ko/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/ko/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ko/build-rust-style-guide.md b/website/translated_docs/ko/build-rust-style-guide.md deleted file mode 100644 index 52f24a8a5b1b..000000000000 --- a/website/translated_docs/ko/build-rust-style-guide.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: build-rust-style-guide -title: Style Guide for Rust in Polkadot -sidebar_label: Style Guide for Rust in Polkadot ---- - -- Indent using tabs -- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. -- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. -- Never have spaces on a line prior to a non-whitespace character -- Follow-on lines are only ever a single indent from the original line. -```rust -fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { - let x = some_long_variable_a * some_long_variable_b - - some_long_variable_b / some_long_variable_a - + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); - x > 10 -} -``` -- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: -```rust -fn calculate( - some_long_variable_a: f32, - some_long_variable_b: f32, - some_long_variable_c: f32, -) -> f32 { - (-some_long_variable_b + sqrt( - // two parens open, but since we open & close them both on the - // same line, only one indent level is used - some_long_variable_b * some_long_variable_b - - 4 * some_long_variable_a * some_long_variable_c - // both closed here at beginning of line, so back to the original indent - // level - )) / (2 * some_long_variable_a) -} -``` -- `where` is indented, and its items are indented one further -- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. - -```rust -// OK -fn foo( - really_long_parameter_name_1: SomeLongTypeName, - really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, - shrt_nm_2: u8, -) { - ... -} - -// NOT OK -fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, shrt_nm_2: u8) { - ... -} - -``` - -```rust -{ - // Complex line (not just a function call, also a let statement). Full - // structure. - let (a, b) = bar( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Long, simple function call. - waz( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Short function call. Inline. - baz(a, b); -} -``` - -- Always end last item of a multi-line comma-delimited set with `,` when legal: -```rust -struct Point { - x: T, - y: T, // <-- Multiline comma-delimited lists end with a trailing , -} - -// Single line comma-delimited items do not have a trailing `,` -enum Meal { Breakfast, Lunch, Dinner }; -``` - -- Avoid trailing `;`s where unneeded. -```rust -if condition { - return 1 // <-- no ; here -} -``` - -- `match` arms may be either blocks or have a trailing `,` but not both. -- Blocks should not be used unnecessarily. -```rust -match meal { - Meal::Breakfast => "eggs", - Meal::Lunch => { check_diet(); recipe() }, -// Meal::Dinner => { return Err("Fasting") } // WRONG - Meal::Dinner => return Err("Fasting"), -} -``` diff --git a/website/translated_docs/ko/build-transaction-construction.md b/website/translated_docs/ko/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/ko/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/ko/claims.md b/website/translated_docs/ko/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/ko/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ko/getting-started.md b/website/translated_docs/ko/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/ko/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ko/grants.md b/website/translated_docs/ko/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/ko/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ko/kusama-adverserial-cheatsheet.md b/website/translated_docs/ko/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/ko/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ko/kusama-ledger.md b/website/translated_docs/ko/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/ko/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/ko/kusama-parameters.md b/website/translated_docs/ko/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/ko/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ko/kusama-time-periods.md b/website/translated_docs/ko/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/ko/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ko/learn-UI.md b/website/translated_docs/ko/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/ko/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/ko/learn-accounts.md b/website/translated_docs/ko/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/ko/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ko/learn-availability.md b/website/translated_docs/ko/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/ko/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/ko/learn-balance-transfers.md b/website/translated_docs/ko/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/ko/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/ko/learn-bridges.md b/website/translated_docs/ko/learn-bridges.md deleted file mode 100644 index d9c95378b3c6..000000000000 --- a/website/translated_docs/ko/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: 브릿지(Bridges) -sidebar_label: 브릿지(Bridges) ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ko/learn-cryptography.md b/website/translated_docs/ko/learn-cryptography.md deleted file mode 100644 index 991a5020b9dc..000000000000 --- a/website/translated_docs/ko/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: 암호화체계 부연 설명 -sidebar_label: 암호화체계 부연 설명 -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## 해시함수 알고리듬(Hashing Algorithm) - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## 키쌍과 전자서명(Keypairs and Signing) - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ko/learn-governance.md b/website/translated_docs/ko/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/ko/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ko/learn-interchain.md b/website/translated_docs/ko/learn-interchain.md deleted file mode 100644 index a6246da9ba4e..000000000000 --- a/website/translated_docs/ko/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. - -The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. - -## Overview - -- Interchain messages will *not* go on to the relay chain. -- Interchain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. - -## Example - -A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. - -When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/ko/learn-ledger.md b/website/translated_docs/ko/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/ko/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ko/learn-registrar.md b/website/translated_docs/ko/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/ko/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ko/learn-staking.md b/website/translated_docs/ko/learn-staking.md deleted file mode 100644 index 8c24a9fe69a3..000000000000 --- a/website/translated_docs/ko/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ko/learn-treasury.md b/website/translated_docs/ko/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/ko/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ko/maintain-governance-index.md b/website/translated_docs/ko/maintain-governance-index.md deleted file mode 100644 index f2371610e1fa..000000000000 --- a/website/translated_docs/ko/maintain-governance-index.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -id: maintain-governance-index -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. - -All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. - -The following steps are the governance procedure in the Polkadot network: - -- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) -- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) -- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) - -To better understand how the council is formed, please read [this section](#council). - -### Proposing Referenda - -- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. - -- **[Council](#council)**: - - Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. - - Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) - -### Voting for a proposal - -To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). - -``` -Example: - -Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes -``` - -According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. - -### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -voters - the total number of voting tokens - -electorate - the total number of DOTs tokens issued in the network -``` - -**Super-Majority Approve** - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ - -**Super-Majority Against** - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ - -**Simple-Majority** - -Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ - -*To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)*. - -``` -Example: - -Assume we only have 1,500 DOTs tokens in total. - -John - 500 DOTs -Peter - 100 DOTs -Lilly - 150 DOTs -JJ - 150 DOTs -Ken - 600 DOTs - -John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -voters = 1050 -electorate = 1500 -``` - -$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ - -$${13.887} < {15.492}$$ - -Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. - -## Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: - -``` -Max votes = tokens * periods -``` - -Based on the current testnet setting, the maximum number of lock periods is set to 6. - -**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** - - -## Adaptive Quorum Biasing - -Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. - -Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. - -Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. - -In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -## Council - -Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). - -### How to be a council member? - -![](assets/governance/approval-vote.png) - - At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. - -To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. - -Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. - -Let's take a look at the example below. - -||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. - -### Resources - -- [Governance Description](learn-governance#referenda) -- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) - -## [Usage of DOT](learn-DOT#dots-for-governance) - -## Guides - -### [How to create a proposal]() -### [How to join the council]() -### [How to propose a referenda]() diff --git a/website/translated_docs/ko/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/ko/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/ko/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/ko/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/ko/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/ko/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/ko/maintain-guides-how-to-nominate.md b/website/translated_docs/ko/maintain-guides-how-to-nominate.md deleted file mode 100644 index d846a22dddd0..000000000000 --- a/website/translated_docs/ko/maintain-guides-how-to-nominate.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: maintain-guides-how-to-nominate -title: How to nominate -sidebar_label: How to nominate ---- - -This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. - -It has been updated for the Alexander testnet and Polkadot release PoC-4. - -## Create `stash` and `controller` accounts - -We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. - -The first step is to create two accounts by going to the *Accounts* tab on the Polkadot Dashboard and clicking on [*Add account*](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. - -![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) - -Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. - -## Nominating - -It is now time to setup our nominator. We will do the following: -- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. -- Select the `controller`. This is the account that will decide when to start or stop nominating. - -First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. - -![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. -- **Controller account** - select the `controller` account created earlier. -- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). -- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). - -Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. - -![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) - -## Nominating a validator - -Go to the *Staking Overview* tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. - -![Validators](assets/guides/how-to-nominate/validators.png) - -Go back to the *Account Actions* tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). - -![Nominating](assets/guides/how-to-nominate/nominating.jpg) - -**Congratulations!** You are now a nominator. - -If you return to the *Staking Overview* tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. - -![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) - -## How to stop nominating - -To stop nominating simply return to the *Account Actions* tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/ko/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/ko/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/ko/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/ko/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/ko/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/ko/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/ko/maintain-guides-society-kusama.md b/website/translated_docs/ko/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/ko/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ko/maintain-polkadot-parameters.md b/website/translated_docs/ko/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/ko/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ko/redenomination.md b/website/translated_docs/ko/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/ko/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ko/thousand-validators.md b/website/translated_docs/ko/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/ko/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ms-MY/build-protocol-info.md b/website/translated_docs/ms-MY/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/ms-MY/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ms-MY/build-transaction-construction.md b/website/translated_docs/ms-MY/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/ms-MY/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/ms-MY/claims.md b/website/translated_docs/ms-MY/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/ms-MY/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ms-MY/getting-started.md b/website/translated_docs/ms-MY/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/ms-MY/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ms-MY/grants.md b/website/translated_docs/ms-MY/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/ms-MY/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ms-MY/kusama-adverserial-cheatsheet.md b/website/translated_docs/ms-MY/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/ms-MY/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ms-MY/kusama-ledger.md b/website/translated_docs/ms-MY/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/ms-MY/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/ms-MY/kusama-parameters.md b/website/translated_docs/ms-MY/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/ms-MY/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ms-MY/kusama-time-periods.md b/website/translated_docs/ms-MY/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/ms-MY/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ms-MY/learn-accounts.md b/website/translated_docs/ms-MY/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/ms-MY/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ms-MY/learn-availability.md b/website/translated_docs/ms-MY/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/ms-MY/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/ms-MY/learn-balance-transfers.md b/website/translated_docs/ms-MY/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/ms-MY/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/ms-MY/learn-bridges.md b/website/translated_docs/ms-MY/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/ms-MY/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ms-MY/learn-cryptography.md b/website/translated_docs/ms-MY/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/ms-MY/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ms-MY/learn-governance.md b/website/translated_docs/ms-MY/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/ms-MY/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ms-MY/learn-ledger.md b/website/translated_docs/ms-MY/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/ms-MY/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ms-MY/learn-registrar.md b/website/translated_docs/ms-MY/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/ms-MY/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ms-MY/learn-staking.md b/website/translated_docs/ms-MY/learn-staking.md deleted file mode 100644 index 0086f64daf82..000000000000 --- a/website/translated_docs/ms-MY/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on secure validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ms-MY/learn-treasury.md b/website/translated_docs/ms-MY/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/ms-MY/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/ms-MY/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/ms-MY/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/ms-MY/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/ms-MY/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/ms-MY/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/ms-MY/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/ms-MY/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/ms-MY/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/ms-MY/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/ms-MY/maintain-guides-society-kusama.md b/website/translated_docs/ms-MY/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/ms-MY/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ms-MY/maintain-polkadot-parameters.md b/website/translated_docs/ms-MY/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/ms-MY/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ms-MY/redenomination.md b/website/translated_docs/ms-MY/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/ms-MY/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ms-MY/thousand-validators.md b/website/translated_docs/ms-MY/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/ms-MY/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/pt-BR/build-protocol-info.md b/website/translated_docs/pt-BR/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/pt-BR/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/pt-BR/build-transaction-construction.md b/website/translated_docs/pt-BR/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/pt-BR/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/pt-BR/claims.md b/website/translated_docs/pt-BR/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/pt-BR/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/pt-BR/getting-started.md b/website/translated_docs/pt-BR/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/pt-BR/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/pt-BR/grants.md b/website/translated_docs/pt-BR/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/pt-BR/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/pt-BR/kusama-adverserial-cheatsheet.md b/website/translated_docs/pt-BR/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/pt-BR/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/pt-BR/kusama-ledger.md b/website/translated_docs/pt-BR/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/pt-BR/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/pt-BR/kusama-parameters.md b/website/translated_docs/pt-BR/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/pt-BR/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/pt-BR/kusama-time-periods.md b/website/translated_docs/pt-BR/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/pt-BR/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/pt-BR/learn-accounts.md b/website/translated_docs/pt-BR/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/pt-BR/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/pt-BR/learn-availability.md b/website/translated_docs/pt-BR/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/pt-BR/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/pt-BR/learn-balance-transfers.md b/website/translated_docs/pt-BR/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/pt-BR/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/pt-BR/learn-bridges.md b/website/translated_docs/pt-BR/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/pt-BR/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/pt-BR/learn-cryptography.md b/website/translated_docs/pt-BR/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/pt-BR/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/pt-BR/learn-governance.md b/website/translated_docs/pt-BR/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/pt-BR/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/pt-BR/learn-ledger.md b/website/translated_docs/pt-BR/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/pt-BR/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/pt-BR/learn-registrar.md b/website/translated_docs/pt-BR/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/pt-BR/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/pt-BR/learn-staking.md b/website/translated_docs/pt-BR/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/pt-BR/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/pt-BR/learn-treasury.md b/website/translated_docs/pt-BR/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/pt-BR/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/pt-BR/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/pt-BR/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/pt-BR/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/pt-BR/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/pt-BR/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/pt-BR/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/pt-BR/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/pt-BR/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/pt-BR/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/pt-BR/maintain-guides-society-kusama.md b/website/translated_docs/pt-BR/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/pt-BR/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/pt-BR/maintain-polkadot-parameters.md b/website/translated_docs/pt-BR/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/pt-BR/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/pt-BR/redenomination.md b/website/translated_docs/pt-BR/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/pt-BR/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/pt-BR/thousand-validators.md b/website/translated_docs/pt-BR/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/pt-BR/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/pt-PT/build-protocol-info.md b/website/translated_docs/pt-PT/build-protocol-info.md deleted file mode 100644 index aa2cff1a0017..000000000000 --- a/website/translated_docs/pt-PT/build-protocol-info.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## DOT Tokens - -- **Token decimals:** See [Redenomination](#redenomination) -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination will take effect 72 hours after transfers are enabled. The projected block numbers and times are: - -| Event | Block Number | Earliest Time | -|:----------------- |:------------:|:----------------:| -| Transfers enabled | 1,205,128 | 18 Aug 13:15 UTC | -| Redenomination | 1,248,328 | 21 Aug 13:15 UTC | - -Block explorers, wallets, and any component that displays DOT balances should use the symbol "DOT (old)" to differentiate DOTs of the original denomination. This change can be made immediately. For a period of time after the redenomination occurs, we recommend that you use the symbol "_New DOT_" to clearly indicate that you have made the change. After sufficient time has elapsed post-redenomination, you should change "_New DOT_" back to "DOT". An example of an explanation would be: - -> “On approximately August 21st at 13:15 UTC (block number 1,248,328), the DOT token will undergo a redenomination. New DOTs will be 100x smaller than DOTs (old). Therefore, your DOT balance will be 100x higher. The percentage of the DOTs you own relative to total supply will be unchanged. See the Polkadot [blog post](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) for more information.” - -If you require assistance with redenomination, please contact redenomination@web3.foundation. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOTs with two locks on it: 150 DOTs for `Transfer` purposes and 100 DOTs for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOTs, but an operation could result in reserving DOTs such that the free balance is below 150, but above 100 DOTs. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/v2.0.0-rc4/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/v2.0.0-rc4/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOTs from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/pt-PT/build-transaction-construction.md b/website/translated_docs/pt-PT/build-transaction-construction.md deleted file mode 100644 index 906ac63a0946..000000000000 --- a/website/translated_docs/pt-PT/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot JS Tools - -[Polkadot JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/pt-PT/build-wallets.md b/website/translated_docs/pt-PT/build-wallets.md deleted file mode 100644 index 4bd437840c77..000000000000 --- a/website/translated_docs/pt-PT/build-wallets.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: build-wallets -title: Polkadot Wallets -sidebar_label: Polkadot Wallets ---- - -## Polkadot Wallets - -The integration of a [wallet](https://wiki.polkadot.network/docs/en/glossary#wallet) with Polkadot allows for simple and easy access to private keys and signing transactions. Below are some wallets that support Polkadot along with their development statuses. Note that inclusion does not necessarily imply endorsement of that wallet. - -## Encryption Enhancement - -Wallets (JSON files) recently generated by the polkadot.js web app (or other applications which use the latest version of the Polkadot JS API) currently cannot be imported (restored) into some wallets, including the polkadot.js extension. This is due to an enhanced encryption method, which is also noticeable in a slight delay when encrypting/decrypting your wallet. The next version of the polkadot.js extension, which will be released soon, will support this new encryption. Other wallet software will also need to update to use the latest version of the Polkadot JS API before they will be able to use these wallets. - -If you are unable to load a JSON file in a wallet, try loading it in the Polkadot-JS web application. - -### Supported Wallets - -| Wallet Name | Development State | Team Name | Description | -| ------------------------------------------------------------------ | ----------------- | ----------- | ----------------------------------- | -| [Signer](https://www.parity.io/signer/) | Live | Parity | IOS and Android | -| [Polkadot-JS](https://polkadot.js.org/apps/#/accounts) | Live | Parity | Browser | -| [Polkadot.JS Plugin](https://github.com/polkadot-js/extension) | Live | Parity | Browser extension | -| [Polkawallet](https://polkawallet.io/) | Live | Polkawallet | IOS and Android | -| [Math Wallet](https://www.mathwallet.org/kusama-wallet/en/) | Live | Math Wallet | Browser extension | -| [Lunie](https://lunie.io/) | Live | Lunie | Browser extension | -| [ImToken](https://token.im/) | Live | ImToken | IOS and Android | -| [TokenPocket](https://www.tokenpocket.pro/) | Live | TokenPocket | IOS and Android | -| [Cobo Wallet](https://cobo.com/) | Building | Cobo | IOS and Android | -| [Polkadot{.js}](https://github.com/EthWorks/extension) | Building | EthWorks | Browser extension | -| [MetaMask](https://metamask.io/index.html) | Building | MetaMask | IOS, Android, and browser extension | -| [Speckle](https://github.com/GetSpeckle/speckle-browser-extension) | Building | Speckle | Browser extension | -| [Enzyme](https://getenzyme.dev/) | Building | BlockXLabs | Browser extension | -| [AirGap](https://airgap.it/) | Building | AirGap | IOS and Android | -| [Ledger App](https://zondax.ch/kusama.html#overview) | Building | Zondax | Hardware | -| [KodaDot](https://kodadot.netlify.app/#/accounts) | Building | Geefu | Browser | -| [Subwallet](https://github.com/yxf/subwallet) | Building | yxf | CLI Wallet | -| [Ownbit](https://ownbit.io/) | Building | Ownbit | IOS and Android | - diff --git a/website/translated_docs/pt-PT/claims.md b/website/translated_docs/pt-PT/claims.md deleted file mode 100644 index de0c114700da..000000000000 --- a/website/translated_docs/pt-PT/claims.md +++ /dev/null @@ -1,204 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOTs post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOTs with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOTs. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOTs into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.png) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.png) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.png) - -The hex-encoded string that follows the sentence: "Pay DOTs to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.png) ![claim-8](assets/new-claims/claim-8.png) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.png) - -If this claim succeeded, then you will see a success message and your DOTs will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOTs, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.png) - -Congratulations, you have now completed the process for claiming and signing for your DOTs. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.png) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.png) - -![claim-attest-4](assets/new-claims/new-attest-4.png) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOTs will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.png) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the PolkadotJS apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the PolkadotJS apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.png) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOTs to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the PolkadotJS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -![ps-claim-4](assets/new-claims/ps-claim-4.png) - -You will notice that the digit beside the "Claim Tokens" menu changed to 2. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the PolkadotJS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOTs will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/pt-PT/grants.md b/website/translated_docs/pt-PT/grants.md deleted file mode 100644 index 98e329349057..000000000000 --- a/website/translated_docs/pt-PT/grants.md +++ /dev/null @@ -1,115 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grantees sidebar_label: Grants -- - - - -This page gives an overview of accepted grants and a link to their GitHub repositories. Keep in mind that not all of the accepted grants have already delivered software. - ---- - -## Table of Contents - -- [Wave 1 - First Quarter 2019](#wave-1) -- [Wave 2 - Second Quarter 2019](#wave-2) -- [Wave 3 - Third Quarter 2019](#wave-3) -- [Wave 4 - Fourth Quarter 2019](#wave-4) -- [Wave 5 - First Quarter 2020](#wave-5) - -## Wave 1 - -- [ChainSafe](https://chainsafe.io/) - Polkadot Host in Go (via an RFP) ([GitHub](https://github.com/ChainSafeSystems/gossamer)) -- [Soramitsu](https://soramitsu.co.jp/) - Polkadot Host in C++ (via an RFP) ([GitHub](https://github.com/soramitsu/kagome)) -- [WEB3SCAN](https://www.web3scan.com/) - Polkascan: Open Source Block Explorer ([GitHub](https://github.com/polkascan)) -- [Polkawallet](https://polkawallet.io/) - Mobile Wallet ([GitHub](https://github.com/polkawallet-io/polkawallet-RN)) -- [Validators](http://validators.com/) - Open Source Scalable Cluster ([GitHub](https://github.com/Validators)) -- [BlockX Labs](http://blockxlabs.com/) - Enzyme Browser extension wallet ([GitHub](https://github.com/blockxlabs/enzyme)) -- [Speckle OS](https://www.speckleos.io/) - Browser extension wallet ([GitHub](https://github.com/SpeckleOS/speckle-browser-extension)) -- [Noise Explorer](https://symbolic.software/) - Rust code generator for formally verified (Noise/ cryptographic) handshakes ([Source Code](https://source.symbolic.software/noiseexplorer/noiseexplorer)) -- [Protos](http://protosmanagement.com/) - Open Source Node Explorer -- [Supercomputing Systems](https://www.scs.ch/) - Substrate Transaction Privacy using Intel SGX ([GitHub](https://github.com/scs/substraTEE)) - -## Wave 2 - -- [Cap9](https://cap9.io/) - A low-level security protocol and framework for smart contracts ([GitHub](https://github.com/Daohub-io/cap9)) -- Substrate Java API - Java version of our JS API ([GitHub](https://github.com/polkadot-java)) -- [Starlog](https://pact.care/) - A metadata chain for IPFS ([GitHub](https://github.com/PACTCare/Starlog)) -- [MixBytes](https://mixbytes.io/) - Benchmarking tool for Substrate and Polkadot ([GitHub](https://github.com/mixbytes/tank)) -- [Gunclear](https://gunclear.io/) - Private secure data storage solution using Plasma Cash in Substrate ([GitHub](https://github.com/GunClear)) -- [ZeroChain](https://layerx.co.jp/) - Zero knowledge transactions in Substrate ([GitHub](https://github.com/LayerXcom/zero-chain)) -- [Robonomics](https://aira.life/en/) - Substrate modules for controlling robots ([GitHub](https://github.com/airalab/substrate-node-robonomics)) -- [Avado](https://ava.do/) - Polkadot node deployment with consumer hardware (GitHub) -- [Stake Technologies](https://stake.co.jp/) - Plasma modules for Substrate ([GitHub](https://github.com/stakedtechnologies/Plasm)) -- [HOPR](https://hopr.network/) - Substrate integration with this P2P messaging protocol ([GitHub](https://github.com/validitylabs/HOPR-PL-Substrate)) -- [Mailchain](https://mailchain.xyz/) - a Multi-Blockchain Messaging Application ([GitHub](https://github.com/mailchain)) -- [Usetech](http://usetech.com/blockchain.html) - Polkadot C++ API ([GitHub](https://github.com/usetech-llc/polkadot_api_cpp)) - -## Wave 3 - -- [Supercomputing systems](http://scs.ch/) - Substrate Rust API client ([GitHub](https://github.com/scs/substrate-api-client)) -- [NGRAVE](https://ngrave.io/) - Substrate Hardware Wallet Integration -- [Caelum Labs](https://caelumlabs.com/) - Decentralised identity modules -- [Runtime Verification](https://runtimeverification.com/) - Build executable K specifications of the SRML ([GitHub](https://github.com/runtimeverification/polkadot-verification)) -- [Attic Lab](https://atticlab.net/) - VS Code and Atom plugins ([GitHub](https://github.com/everstake/VSCode-Atom-Plugin)) -- [Dock](http://dock.io/) - Verifiable Claims -- [Blockdaemon](https://blockdaemon.com/) - Polkadot Package Manager ([GitHub](https://github.com/Blockdaemon/bpm-sdk)) -- [Zondax](http://zondax.ch/) - Ledger app for Polkadot ([GitHub](https://github.com/ZondaX/ledger-polkadot)) -- [Geefu](https://www.geefu.net/) - Vue JS components for Polkadot JS apps ([GitHub](https://github.com/vue-polkadot)) -- [Centrifuge](https://centrifuge.io/) - Substrate Go API client ([GitHub](http://github.com/centrifuge)) -- [Litentry](https://www.litentry.com/) - Identity modules and corresponding UIs ([GitHub](https://github.com/litentry/litentry-runtime)) -- [Subsocial](http://subsocial.network) - Substrate modules with web UI for decentralized social networks and marketplaces ([GitHub](https://github.com/dappforce/dappforce-subsocial)) -- [pLibra ](https://plibra.io/)- Bridge between Polkadot and a Libra chain ([GitHub](https://github.com/libra-china-org)) -- [Wiv ](http://wiv.io/)- Supply chain modules and front-end UI ([GitHub](https://github.com/wivtech)) - -## Wave 4 - -- [Genesis Lab](https://genesislab.net/) - Validator Tracker ([GitHub](https://github.com/genesis-lab-team)) -- [Usetech](http://usetech.com/blockchain.html) - Substrate API in .NET ([GitHub](https://github.com/usetech-llc/polkadot_api_dotnet)) -- [BlockX Labs](http://blockxlabs.com/) - Enzyme Browser extension wallet ([GitHub](https://github.com/blockxlabs/enzyme)) -- [WEB3SCAN](https://www.web3scan.com/) - Python API client ([GitHub](https://github.com/polkascan)) -- [Galactic Council](https://github.com/galacticcouncil) - Polkalert: Validator Monitoring ([GitHub](https://github.com/galacticcouncil/polkalert)) -- [Bandot](http://bandot.io/) - Stablecoin ([GitHub](https://github.com/bandotorg/Bandot)) -- [Laminar One](https://laminar.one/) - LaminarChain: High performance Flow Protocols powering synthetic asset and margin trading ([GitHub](https://github.com/laminar-protocol/laminar-chain)) -- [Stake Technologies](https://stake.co.jp/) - Ink! Playground ([GitHub](https://github.com/staketechnologies/ink-playground)) -- [B-Harvest](https://bharvest.io/) - Node Monitoring Tool ([GitHub](https://github.com/b-harvest)) -- [Simply VC](https://simply-vc.com.mt/) - P.A.N.I.C. Validator alerting solution ([GitHub](https://github.com/SimplyVC/panic_polkadot)) -- [Ethworks](https://ethworks.io/) - Polkadot{.js} extension improvements ([GitHub](https://github.com/ethWorks)) -- [Lyken Software Solutions](https://lyken.rs/) - Investigation of runtime compilation -- [Blockchain IT](https://blockchain-it.hr) - Ink! Remix Plugin ([GitHub](https://github.com/blockchain-it-hr/ink-remix-plugin)) -- [Kadena](https://www.kadena.io/) - Pact feasibility study ([GitHub](https://github.com/kadena-io/)) -- [STAFI Protocol](http://www.stafi.io/) - Stafi is a protocol to provide liquidity for staking assets ([GitHub](https://github.com/stafiprotocol/stafi-node)) -- [Vision Baker](https://playproject.io/) - DatDot - Dat protocol for Polkadot ([GitHub](https://github.com/playproject-io/datdot)) -- [Speckle OS](https://www.speckleos.io/) - Integrating additional features into Speckle OS ([GitHub](https://github.com/SpeckleOS/speckle-browser-extension)) -- [Archipel](https://archipel.id/) - Solution to resolve high availability problem of Validator nodes in PoS ([GitHub](https://github.com/luguslabs/archipel)) -- [Zondax](https://zondax.ch/) - Flexible TrustZone-based HSM stack ([GitHub](https://github.com/ZondaX)) -- [Usetech](http://usetech.com/blockchain.html) - SR25519 library in pure C and C# ([GitHub](https://github.com/usetech-llc/)) -- [Akropolis](https://akropolis.io/) - PolkaHub - Heroku-like infrastructure for node deployment ([GitHub](https://github.com/akropolisio)) -- [Pixura](https://pixura.io/) - Substrate API client in Haskell ([GitHub](https://github.com/Pixura)) -- [HashQuark](https://www.hashquark.io/) - Validator Dashboard ([GitHub](https://github.com/hashquark-research)) -- [Stacktical](https://stacktical.com/) - Performance Management Runtime Modules ([GitHub](https://github.com/Stacktical)) -- [Sean Young](https://www.mess.org/) - Solidity to WASM compiler ([GitHub](https://github.com/hyperledger-labs/solang)) -- [Chain Security](https://chainsecurity.com/) - Tool for validating correctness of Polkadot runtimes ([GitHub](https://github.com/ChainSecurity)) - -## Wave 5 - -- [Bifrost](https://bifrost.codes/) - EOS interoperable bridge ([GitHub](https://github.com/bifrost-codes)) -- [Entropy Labs](https://entropylabs.hk) - A toolkit for building and deploying applications with substrate -- [Papers GmbH](https://airgap.it) - AirGap - Desktop (+mobile) wallet for Polkadot ([GitHub](https://github.com/airgap-it)) -- [Stake Technologies](https://stake.co.jp/) - Plasm Chain + OVM Implementation ([GitHub](https://github.com/stakedtechnologies/)) -- [Usetech](http://usetech.com/blockchain.html) - PostgreSQL Indexer and Consensus Insurer ([GitHub](https://github.com/usetech-llc/)) -- [ACALA PTE. LTD.](https://acala.network/) - A decentralized stablecoin platform -- [ETCDEV](https://emeraldpay.io/) - Polkadot Network Crawler ([GitHub](https://github.com/emeraldpay)) -- [Xaya](https://xaya.io/) - Decentralised Complex Gaming([GitHub](https://github.com/xaya)) -- [Celer](https://www.celer.network/) - Layer 2 Scaling Infrastructure ([GitHub](https://github.com/celer-network)) -- [Cryptoeconomics Lab](https://www.cryptoeconomicslab.com/) - Substrate adapter of Plasma child chain ([GitHub](https://github.com/cryptoeconomicslab)) -- [Centrifuge](https://centrifuge.io/) - Substrate / Ethereum Bridge ([GitHub](https://github.com/centrifuge/)) -- Advanca - Privacy-preserving general-purpose compute/storage layer -- [Nodle](https://nodle.io) - Securely identify, certify and verify IoT devices ([GitHub](http://github.com/NodleCode/)) -- [Figment](https://figment.network/) - DotHub: Information Hub for validators and delegators ([GitHub](https://github.com/figment-networks/dothub)) -- [Lunie](http://lunie.io/) - Web and mobile wallet ([GitHub](https://github.com/luniehq/lunie)) -- [Web3 Gardens](https://web3.garden) - Runtime modules and UI for creating stable, well-governed communities on Substrate ([GitHub](https://github.com/web3garden/sunshine)) -- [Itering](https://itering.com/) - Ruby Substrate API ([GitHub](https://github.com/itering)) -- [WEB3SCAN](https://www.web3scan.com/) - Identity Pallet for Polkascan ([GitHub](https://github.com/polkascan)) -- [Swisscom Blockchain AG](https://www.blockchain.swisscom.com/) - Kubernetes Operator for Sentry nodes or Validators deployment ([GitHub](https://github.com/swisscom-blockchain)) -- [Polkastats](https://polkastats.io/) - Polkadot/Kusama network statistics ([GitHub](https://github.com/Colm3na/polkastats-v3)) -- [Supercomputing Systems](https://www.scs.ch/) - SubstraTEE extension pack ([GitHub](https://github.com/scs/substraTEE)) -- [Encointer](https://encointer.org/) - An Ecological, Egalitarian and Private Cryptocurrency and Self-Sovereign Identity System ([GitHub](https://github.com/encointer)) -- [FlexDapps](https://flexdapps.com/) - Gantree is a full-service node infrastructure toolkit for Substrate-based blockchains ([GitHub](https://github.com/flex-dapps)) diff --git a/website/translated_docs/pt-PT/kusama-adverserial-cheatsheet.md b/website/translated_docs/pt-PT/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/pt-PT/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/pt-PT/kusama-time-periods.md b/website/translated_docs/pt-PT/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/pt-PT/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/pt-PT/learn-accounts.md b/website/translated_docs/pt-PT/learn-accounts.md deleted file mode 100644 index af0df6dc09f0..000000000000 --- a/website/translated_docs/pt-PT/learn-accounts.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are merely different representations of the same public key in a private-public keypair generated by an address generation tool (see next section). This makes the addresses cross-Substrate-chain-compatible as long as you convert the format. - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Kusama address is through the [Polkadot JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [PolkadotJS extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. Creating cold storage is as simple as securely stashing away the seed phrase for your accounts and removing all traces of the accounts from your computer. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/) but it currently only supports Kusama addresses, not Polkadot or generic Substrate. - -Alternatively, you might find some wallets on the [Polkaproject.com page](http://www.polkaproject.com/) but bear in mind that these are **unaudited** and not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -Hardware wallet integration from [Ledger](https://ledger.com) is coming soon. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit - 0.01 KSM / DOT. This deposit is paid by the account sending you tokens. The one "creating" you pays for your creation. - -Going below 0.01 causes an account to be _reaped_. Your account will be wiped from the blockchain's state to conserve space. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama address can have an index. An index is like a short and easy to remember version of an address. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -Because of this unreliability of indices, they **may not be present** in Polkadot mainnet. - -## Identities - -The _Identities_ pallet built into Kusama allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` and the DepositFactor is equal to `deposit(0,32)`. - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/kusama/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot | Kusama | -| ------------- | ------------ | --------------- | -| DepositBase | 200880000000 | 3347999999941.4 | -| DepositFactor | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit 0.20152 DOTs while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. diff --git a/website/translated_docs/pt-PT/learn-availability.md b/website/translated_docs/pt-PT/learn-availability.md deleted file mode 100644 index 94485859a3f6..000000000000 --- a/website/translated_docs/pt-PT/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Life of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/pt-PT/learn-bridges.md b/website/translated_docs/pt-PT/learn-bridges.md deleted file mode 100644 index 85d3c26f61b2..000000000000 --- a/website/translated_docs/pt-PT/learn-bridges.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible for external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -# Types of bridges - -There are two types of bridges in the Polkadot ecosystem. - -- _Bridge modules_ - Bridge modules are possibly system-level or community-deployed parachains that serve a distinct purpose as consensus-adaptors to external chains. -- _Bridge contracts_ - Similar to bridge modules, however they exist on specific parachains that support smart contracts. - -## Bridge modules - -Receiving messages on Polkadot from an external, non-parachain blockchain can be built as a parachain module. The parachain module can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -Bridge modules allow for non-parachains to act as a "virtual parachain" and extends the external chain's functionality with the interoperability benefits of Polkadot. - -Bridge modules will be written with particular chains in mind such as Bitcoin or Ethereum. This means that blockchains that are based of these will likely be easily supported as well (e.g. Litecoin and other Bitcoin-forks). - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=3) - -For the standalone chains that will not have a parachain bridging module on Polkadot, it will be necessary to deploy bridge contracts (see below). - -## Bridge contracts - -Those who are already familiar with Ethereum may know of the [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -In the case of Polkadot, it should be possible to have a bridge contract deployed on, say, an EVM-based standalone chain and a contract deployed on a smart contract capable parachain. This would not necessarily be the most efficient method of bridging, but given the generality of a Turing-complete parachain it would be possible to bridge Polkadot and any other smart contract capable blockchain. - -## Bitcoin Bridge - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XClaim](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Ethereum Bridge - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -## Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -## Resources - -### Smart Contract Bridges - -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain). -- [Parity Bridge](https://github.com/paritytech/parity-bridge) -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. - -### Runtime Module Bridges - -- [Bifrost](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [Tendermint Bridge](https://github.com/ChorusOne) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/develop/cxrml/bridge/btc) - ChainX have implemented a BTC to Substrate bridge for their parachain. - -### Design - -- [XClaim](https://eprint.iacr.org/2018/643.pdf) - XClaim design for bridging Proof-of-Work chains in a trustless way. diff --git a/website/translated_docs/pt-PT/learn-consensus.md b/website/translated_docs/pt-PT/learn-consensus.md deleted file mode 100644 index 7358a736a9b9..000000000000 --- a/website/translated_docs/pt-PT/learn-consensus.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -id: learn-consensus -title: Polkadot Consensus -sidebar_label: Polkadot Consensus -description: An explanation of the consensus model used in Polkadot and Kusama ---- - -## Why do we need consensus? - -Consensus is a method for coming to agreement over a shared state. In order for the state of the blockchain to continue to build and move forward, all nodes in the network must agree and come to consensus. It is the way that the nodes in a decentralized network are able to stay synced with each other. Without consensus for the decentralized network of nodes in a blockchain, there is no way to ensure that the state one node believes is true will be shared by the other nodes. Consensus aims to provide the _objective_ view of the state amid participants who each have their own _subjective_ views of the network. It is the process by which these nodes communicate and come to agreement, and are able to build new blocks. - -## What are PoW and PoS? - -Proof of Work (PoW) and Proof of Stake (PoS) have been inaccurately used as short hand to refer to consensus mechanisms of blockchains, but that does not capture the full picture. PoW is the method for agreeing on a block author and part of the fuller [Nakamoto consensus](#nakamoto-consensus) that also encompasses a chain selection algorithm (longest chain rule in Bitcoin). Similarly, PoS is a set of rules for selecting the validator set and does not specify a chain selection rule or how a chain might reach finality. PoS algorithms have traditionally been paired with an algorithm for coming to Byzantine agreement between nodes. For example, [Tendermint](learn-comparisons-cosmos) is a practical Byzantine fault tolerant algorithm that uses PoS as its validator set selection method. - -## Why not Proof of Work? - -Although simple and effective in coming to a decentralized consensus on the next block producer, proof of work with Nakamoto consensus consumes an incredible amount of energy, has no economic or provable finality, and has no effective strategy in resisting cartels. - -## Probabilistic vs. provable finality - -A pure Nakamoto consensus blockchain that runs PoW is only able to achieve the notion of _probabilistic finality_ and reach _eventual consensus_. Probabilistic finality means that under some assumptions about the network and participants, if we see a few blocks building on a given block, we can estimate the probability that it is final. Eventual consensus means that at some point in the future, all nodes will agree on the truthfulness of one set of data. This eventual consensus may take a long time and will not be able to be determined how long it will take ahead of time. However, finality gadgets such as GRANDPA or Ethereum's Casper FFG are designed to give stronger and quicker guarantees on the finality of blocks - specifically, that they can never be reverted after some process of Byzantine agreements has taken place. The notion of irreversible consensus is known as _provable finality._ - -In the GRANDPA paper, it is phrased in this way: - -> We say an oracle A in a protocol is _eventually consistent_ if it returns the same value to all participants after some unspecified time. - -## What is GRANDPA/BABE? - -### Hybrid Consensus - -There are two acronyms we use when we talk about the consensus protocol of Polkadot, GRANDPA and BABE. We talk about both of these acronyms because Polkadot uses what is known as _hybrid consensus_. Hybrid consensus splits up the finality gadget from the block production mechanism. - -This is a way of getting the benefits of probabilistic finality (the ability to always produce new blocks) and provable finality (having a universal agreement on the canonical chain with no chance for reversion) in Polkadot. It also avoids the corresponding drawbacks of each mechanism (the chance of unknowingly following the wrong fork in probabilistic finality, and a chance for "stalling" - not being able to produce new blocks - in provable finality). By combining these two mechanisms, Polkadot allows for blocks to be rapidly produced, and the slower finality mechanism to run in a separate process to finalize blocks without risking slower transaction processing or stalling. - -Hybrid consensus has been proposed in the past. Notably, it was proposed (now defunct) as a step in Ethereum's transition to proof of stake in [EIP 1011](http://eips.ethereum.org/EIPS/eip-1011), which specified [Casper FFG](#casper-ffg). - -### BABE - -BABE (Blind Assignment for Blockchain Extension) is the block production mechanism that runs between the validator nodes and determines the authors of new blocks. BABE is comparable as an algorithm to Ouroboros Praos, with some key differences in chain selection rule and slot time adjustments. BABE assigns block production slots to validators according to stake and using the Polkadot [randomness cycle](learn-randomness). - -Validators in Polkadot will participate in a [lottery](learn-randomness) in every slot that will tell them whether or not they are the block producer candidate for that slot. Slots are discrete units of time, nominally 6 seconds in length. Because of this randomness mechanism, multiple validators could be candidates for the same slot. Other times, a slot could be empty, resulting in inconsistent block time. - -#### Multiple Validators per Slot - -When multiple validators are block producer candidates in a given slot, all will produce a block and broadcast it to the network. At that point, it's a race. The validator whose block reaches most of the network first wins. Depending on network topology and latency, both chains will continue to build in some capacity, until finalization kicks in and amputates a fork. See Fork Choice below for how that works. - -#### No Validators in Slot - -When no validators have rolled low enough in the randomness lottery to qualify for block production, a slot can remain seemingly blockless. We avoid this by running a secondary, round-robin style validator selection algorithm in the background. The validators selected to produce blocks through this algorithm always produce blocks, but these _secondary_ blocks are ignored if the same slot also produces a primary block from a [VRF-selected](learn-randomness) validator. Thus, a slot can have either a _primary_ or a _secondary_ block, and no slots are ever skipped. - -For more details on BABE, please see the [working research draft](https://research.web3.foundation/en/latest/polkadot/BABE/Babe.html). - -#### Difference of BABE secondary blocks between Kusama and Polkadot - -Both Kusama and Polkadot uses the BABE block production mechanism outlined above. However, there is a slight difference in the secondary blocks that are produced between the two networks. Polkadot attaches the VRF output to secondary blocks (and therefore every block contributes to the Era randomness), while Kusama keeps the VRF output off the secondary blocks (meaning only the primary blocks contribute to Era randomness). The Polkadot method should give stronger randomness as more inputs are collected during every Era. Eventually, this change should make its way into Kusama too. - -### GRANDPA: Finality gadget - -GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is the finality gadget that is implemented for the Polkadot Relay Chain. - -It works in a partially synchronous network model as long as 2/3 of nodes are honest and can cope with 1/5 Byzantine nodes in an asynchronous setting. - -A notable distinction is that GRANDPA reaches agreements on chains rather than blocks, greatly speeding up the finalization process, even after long-term network partitioning or other networking failures. - -In other words, as soon as more than 2/3 of validators attest to a chain containing a certain block, all blocks leading up to that one are finalized at once. - -#### Protocol - -Please refer to heading 3 in [the paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) for a full description of the protocol. - -#### Implementation - -The [Rust implementation](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs) is part of Substrate Frame. - -For even more detail, see the [GRANDPA research page](https://research.web3.foundation/en/latest/polkadot/GRANDPA.html) on the W3F Research pages. - -### Fork Choice - -Bringing BABE and GRANDPA together, the fork choice of Polkadot becomes clear. BABE must always build on the chain that has been finalized by GRANDPA. When there are forks after the finalized head, BABE provides probabilistic finality by building on the chain with the most primary blocks. - -![Best chain choice](assets/best_chain.png) - -In the above image, the black blocks are finalized. Ones are primary, twos are secondary blocks. Even though the topmost chain is the longest chain on the latest finalized block, it does not qualify because it has fewer primaries at the time of evaluation than the one below it. - -## Comparisons - -### Nakamoto consensus - -Nakamoto consensus consists of the longest chain rule using proof of work as its sybil resistance mechanism and leader election. - -Nakamoto consensus only gives us probabilistic finality. Probabilistic finality states that a block in the past is only as safe as the number of confirmations it has, or the number of blocks that have been built on top of it. As more blocks are built on top of a specific block in a Proof of Work chain, more computational work has been expended behind this particular chain. However, it does not guarantee that the chain containing the block will always remain the agreed-upon chain, since an actor with unlimited resources could potentially build a competing chain and expend enough computational resources to create a chain that did not contain a specific block. In such a situation, the longest chain rule employed in Bitcoin and other proof of work chains would move to this new chain as the canonical one. - -### PBFT / Tendermint - -Please see the [relevant section](learn-comparisons-cosmos#consensus) in the Cosmos comparison article. - - - -### Casper FFG - -The two main differences between GRANDPA and Casper FFG (Friendly Finality Gadget) are: - -- in GRANDPA, different voters can cast votes simultaneously for blocks at different heights -- GRANDPA only depends on finalized blocks to affect the fork-choice rule of the underlying block production mechanism - -### Casper CBC - -_Coming soon!_ - - - -## Resources - -- [GRANDPA paper](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf) - The academic description of the GRANDPA finality gadget. Contains formal proofs of the algorithm. -- [Rust implementation](https://github.com/paritytech/finality-grandpa) - The reference implementation and the accompanying [Substrate pallet](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs). - - - diff --git a/website/translated_docs/pt-PT/learn-cryptography.md b/website/translated_docs/pt-PT/learn-cryptography.md deleted file mode 100644 index c4717deae73d..000000000000 --- a/website/translated_docs/pt-PT/learn-cryptography.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/pt-PT/learn-governance.md b/website/translated_docs/pt-PT/learn-governance.md deleted file mode 100644 index fa302ad8608f..000000000000 --- a/website/translated_docs/pt-PT/learn-governance.md +++ /dev/null @@ -1,262 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -The following steps are the governance procedure in the Polkadot network: - -- [Proposing Referenda](#proposing-a-referendum) -- [Voting for a proposal](#voting-on-a-referendum) -- [Tallying](#tallying) - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is planned to be 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of DOTs for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest amount of bonded support will be selected to be a referendum. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOTs each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries. - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of DOT tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -``` -Example: - -Peter: Votes `No` with 10 DOTs for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOTs for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOTs for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combining both Logan and Kevin vote with more DOTs than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (Does not include conviction) - -electorate - the total number of DOTs tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOTs tokens in total. -- Public proposal - -John - 500 DOTs -Peter - 100 DOTs -Lilly - 150 DOTs -JJ - 150 DOTs -Ken - 600 DOTs - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: - -``` -Max votes = tokens * vote_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the lock period doubles. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -Based on the genesis runtime, the maximum number of lock periods is set to 6 and the lock period is 30 days on Polkadot and eight days on Kusama. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -To represent passive stakeholders, we introduce the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. For Polkadot this number is likely to begin at around six people, and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). In general, it has a fixed number of seats (24 on Polkadot and 17 on Kusama). - -The council is called upon primarily for two tasks of governance: proposing sensible referenda, and cancelling uncontroversially dangerous or malicious referenda. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. In the case that all members vote in favor, the vote is considered unanimous and is treated as uncontroversial. - -A two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -At genesis, there will be 6 to 12 seats in the Council. All stakeholders are free to signal their approval of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referendum. - -To elect a new council member, Polkadot employs the same election scheme as used for choosing the active set of validators, a [Phragmén election](learn-phragmen). The election also chooses a set number of runners up (currently seven in Kusama) that will remain in the queue with their votes intact. - -As opposed to a "first past the post", where voters must decide only on a single candidate chosen from a list, a Phragmén election is a more expressive way to indicate voters' views. Token holders can treat it as Boolean voting to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the council. - -The Technical Committee can, along with the Polkadot Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## [Usage of DOT](learn-DOT#dots-for-governance) - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) diff --git a/website/translated_docs/pt-PT/learn-staking.md b/website/translated_docs/pt-PT/learn-staking.md deleted file mode 100644 index 63bed68e6623..000000000000 --- a/website/translated_docs/pt-PT/learn-staking.md +++ /dev/null @@ -1,240 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards equally to all validators regardless of stake. In other words, having more stake on a validator does not influence the block rewards they receive. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOTs. You can take a look at the [nominator guide](maintain-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid the **same amount of DOTs** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. Within a validator pool, a (configurable) part of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once as commission fees for validating, and once for nominating itself with stake. - -To estimate the inflation rate and how many DOTs you can get each month as a nominator or validator, you can use this [Excel sheet](https://docs.google.com/spreadsheets/d/1-9Hc3kZ23EhZC3X6feRUKSTv6gj4xR7cvUbJD2zUEZk/edit?usp=sharing) as a reference and play around with it by changing some parameters (e.g. validator pools, total supply, commission fees, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They do NOT charge any commission fees -- Reward amount is 100 DOT tokens -- The least amount of DOTs to be a validator is 350 - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOTs in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOTs), which means that validator pools with more stake get slashed more DOTs. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOTs, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOTs and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOTs. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -### Want to stake DOTs? - -- [Nominator Guide](mirror-maintain-guides-how-to-nominate-kusama) - Become a nominator on the Kusama network. -- [Validator Guide](mirror-maintain-guides-how-to-validate-kusama) - Become a validator on the Kusama network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOTs. Any slashed DOTs will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of validators that you have nominated in the past 84 eras. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOTs. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOTs. The remaining 5 DOTs would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller) or to the stash account (and either increasing the staked value or not increasing the staked value). It is also possible to top-up / withdraw some bonded DOTs without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOTs staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [PolkadotJS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces validator payouts. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators will Polkadot have? - -The plan is to start with somewhere between 50 to 100 open validator positions and open more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to frequent and voluminous peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, has over 300 validator slots. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/pt-PT/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index bfe9bd987673..000000000000 --- a/website/translated_docs/pt-PT/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: Validator Guide ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmen's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](maintain-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.3**, but you should review the output from the "git tag" command (`git tag | grep "$v\0\.8"`) to see a list of all the potential 0.8 releases. You should replace `v0.8.8` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag | grep "$v\0\.8" -git checkout v0.8.8 -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `-unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSMs - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn/staking/#reward-distribution). - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSMs staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:v0.7.28 --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/pt-PT/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/pt-PT/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index 7232150f723a..000000000000 --- a/website/translated_docs/pt-PT/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: Validator Guide ---- - -> The following information applies to the Polkadot network, which is currently in the soft launch phase. During soft launch the network starts as a Proof-of-Authority network before transitioning to Proof-of-Stake. You will be able to follow this guide to set up your validator but the first validator election and rewards will not start until later. If you want to set up a validator on Kusama, check out the [Kusama guide](mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOTs do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmen's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](maintain-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOTs that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.3**, but you should review the output from the "git tag" command (`git tag | grep "$v\0\.8"`) to see a list of all the potential 0.8 releases. You should replace `v0.8.8` with the latest build (i.e., the highest number). You can also find the latest Polkadot version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag | grep "$v\0\.8" -git checkout v0.8.8 -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-05-15 -rustup override set nightly-2020-05-15 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15 -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `-unsafe-pruning --pruning OF BLOCKS>`, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -> **Note:** If you do not already have DOTs, this is as far as you will be able to go until the end of the soft launch period. You can still run a node, but you will need to have a minimal amount of DOTs to continue, as balance transfers are disabled during the soft launch. Please keep in mind that even for those with DOTs, they will only be indicating their _intent_ to validate; they will also not be able to run a validator until the NPoS phase starts. - -## Bond DOTs - -> **Note:** Transfers are disabled during the soft launch phase of Polkadot. This means that if you are setting up a validator during this time you may not be able to make your stash and controller two separate accounts, as is recommended. You must make them the same account, meaning that you will bond the account to itself. However it is highly recommended that you change your controller as soon as possible. - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOTs of the Stash account. These DOTs will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOTs - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOTs in order to start and stop validating. -- **Value bonded** - How much DOts from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOTs in that account. Also note that you can always bond _more_ DOTs later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn/staking/#reward-distribution). - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point, omitting the `--unsafe-rpc-expose` flag as it is no longer needed. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOTs staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/pt-PT/maintain-guides-society-kusama.md b/website/translated_docs/pt-PT/maintain-guides-society-kusama.md deleted file mode 100644 index 2e0c80e79b15..000000000000 --- a/website/translated_docs/pt-PT/maintain-guides-society-kusama.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/society/dashboard.jpg) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on PolkadotJS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -`Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. - -`Rotation`: The duration between each time the membership rotates. - -`Challenge`: The time period to randomly select one of the members to defend his membership in the society. - -`Pot`: Resource that is used to support the member of society. - -`Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -`Bidder` - A token holder who intends to join the society by placing a bid. - -`Candidate` - The selected bidders that will be voted on by members of the society. - -`Suspended Candidate` - The candidates that failed to join the society. - -`Member` - Member of the society. - -`Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. - -`Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. - -`Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - -**Remember to take a look at the \[rules\]\[kapp rules\] first. And since those rules are not enforced entirely on-chain, it is recommended to join the [public chat room](https://matrix.to/#/!BUmiAAnAYSRGarqwOt:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) to ask any questions if anything is unclear.** - -### 1. Bid Phase - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -![Society Dashboard](assets/society/submit_bid.jpg) - -Anyone who wants to join the society is required to deposit 10 KSM for reserve on Kusama and place the bid amount (1 KSM in this case) that they want to get when joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://polkadot.js.org/apps/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid`. - -> unbid(pos) -> -> pos - The index of the bid. - -If you are not sure what your position is, you can check that by going to the [Society->bids chain state](https://polkadot.js.org/apps/#/chainstate) in the PolkadotJS apps. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -![Society Vote Candidate](assets/society/vote_candidate.jpg) - -> vote(candidate,approve) -> -> candidate - Select the candidate you would like to vote -> -> approve - Yes / No - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> **_NOTE:_** -> -> If the randomly selected member does not vote, it will be treated as a rejection. -> -> For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> **_NOTE:_** -> -> The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is closer to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/v2.0.0-rc4/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgment Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -![Society Vote Defender](assets/society/vote_defender.jpg) - -> defenderVote(approve) -> -> approve - Yes / No - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> **_NOTE:_** -> -> Each member can only vouch for one user at a time. -> -> A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society - -[Kappa Sigma Mu Lounge](https://matrix.to/#/!BUmiAAnAYSRGarqwOt:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - A public chat room on Riot to talk about anything about the society. - -[Substrate Society](https://www.shawntabrizi.com/substrate-society/) - It shows the Kusama society information and allowing you to directly place a bid if you have installed the [PolkadotJS extension](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd). diff --git a/website/translated_docs/ru/build-exchange-integration.md b/website/translated_docs/ru/build-exchange-integration.md deleted file mode 100644 index 27da9d2321be..000000000000 --- a/website/translated_docs/ru/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. Tracking the chain head - -Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). - -That will give you a stream of hashes of the most recent finalised headers. - -When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. - -If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. - -## 2. Decoding blocks - -You will need to decode blocks from the basic data into useful fields. - -All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. - -For Genesis Polkadot, the header format is a five-field structure: - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -It also relies on `Extrinsic`. An *extrinsic* is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. - -The metadata itself is provided encoded in SCALE. Its format is: - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. - -Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various *modules*. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, *extrinsics*), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. Working with SS58 and account addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) *AccountId*. This is simply the public key for the x25519 cryptography used by Substrate. - -However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this *index* to identify the account. This index is much smaller than the 32-byte *AccountId*, and can usually be encoded in just a couple of bytes. - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: - -`0x00 ` - -**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. - -Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. - -Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. - -### Looking up an index - -Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. - -The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. - -For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. - -This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. - -This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. - -Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. - -## 4. Working with balances - -In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. - -NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. - -The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10**12). For completeness, The exact denominations of the Polkadot currency are: - -| Balance value | Name | -| ------------- | ---- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### Transferring balances - -To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. - -In general, Polkadot's transactions are encoded as *signed* `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. - -The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. - -NOTE: The nonce retrieved from storage does not take into account *pending* transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. - -The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. - -The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. - -Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. - -Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -The `function` *in this case* (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. - -The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. - -### Submitting and checking transactions - -Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. - -This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. - -The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. - -## Conclusion - -This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. - -If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). - -_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/ru/build-extrinsic-format.md b/website/translated_docs/ru/build-extrinsic-format.md deleted file mode 100644 index 92d1692bb078..000000000000 --- a/website/translated_docs/ru/build-extrinsic-format.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: build-extrinsic-format -title: Polkadot Extrinsic Format aka Transaction Format -sidebar_label: Polkadot Extrinsic Format aka Transaction Format ---- - -## Old Format - -For reference, the **old** extrinsic format was: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] -``` - -## Current Format - -The Polkadot extrinsic format is: - -``` -[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] -``` - -The *original* fields refer to the following from the old extrinsic format: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] -``` - -The specific format for the new address type is one of 5 sub-formats, switched on the first byte: - -- `0xff, 32-byte account id` -- `0xfe, 8-byte account index` -- `0xfd, 4-byte account index` -- `0xfc, 2-byte account index` -- `[0xf0...0xfb] (invalid, reserved for future use)` -- `[0x00...0xef] 1-byte account index (less than 0xf0)` - -The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. - -In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). - -## Source - -[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/ru/build-protocol-info.md b/website/translated_docs/ru/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/ru/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ru/build-rust-style-guide.md b/website/translated_docs/ru/build-rust-style-guide.md deleted file mode 100644 index 52f24a8a5b1b..000000000000 --- a/website/translated_docs/ru/build-rust-style-guide.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: build-rust-style-guide -title: Style Guide for Rust in Polkadot -sidebar_label: Style Guide for Rust in Polkadot ---- - -- Indent using tabs -- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. -- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. -- Never have spaces on a line prior to a non-whitespace character -- Follow-on lines are only ever a single indent from the original line. -```rust -fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { - let x = some_long_variable_a * some_long_variable_b - - some_long_variable_b / some_long_variable_a - + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); - x > 10 -} -``` -- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: -```rust -fn calculate( - some_long_variable_a: f32, - some_long_variable_b: f32, - some_long_variable_c: f32, -) -> f32 { - (-some_long_variable_b + sqrt( - // two parens open, but since we open & close them both on the - // same line, only one indent level is used - some_long_variable_b * some_long_variable_b - - 4 * some_long_variable_a * some_long_variable_c - // both closed here at beginning of line, so back to the original indent - // level - )) / (2 * some_long_variable_a) -} -``` -- `where` is indented, and its items are indented one further -- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. - -```rust -// OK -fn foo( - really_long_parameter_name_1: SomeLongTypeName, - really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, - shrt_nm_2: u8, -) { - ... -} - -// NOT OK -fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, shrt_nm_2: u8) { - ... -} - -``` - -```rust -{ - // Complex line (not just a function call, also a let statement). Full - // structure. - let (a, b) = bar( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Long, simple function call. - waz( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Short function call. Inline. - baz(a, b); -} -``` - -- Always end last item of a multi-line comma-delimited set with `,` when legal: -```rust -struct Point { - x: T, - y: T, // <-- Multiline comma-delimited lists end with a trailing , -} - -// Single line comma-delimited items do not have a trailing `,` -enum Meal { Breakfast, Lunch, Dinner }; -``` - -- Avoid trailing `;`s where unneeded. -```rust -if condition { - return 1 // <-- no ; here -} -``` - -- `match` arms may be either blocks or have a trailing `,` but not both. -- Blocks should not be used unnecessarily. -```rust -match meal { - Meal::Breakfast => "eggs", - Meal::Lunch => { check_diet(); recipe() }, -// Meal::Dinner => { return Err("Fasting") } // WRONG - Meal::Dinner => return Err("Fasting"), -} -``` diff --git a/website/translated_docs/ru/build-transaction-construction.md b/website/translated_docs/ru/build-transaction-construction.md deleted file mode 100644 index f61177485444..000000000000 --- a/website/translated_docs/ru/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Создание и подписание транзакций -sidebar_label: Создание транзакций ---- - -На этой странице будет обсуждаться формат транзакций в Polkadot и способы создания, подписания и трансляции транзакций. Как и на других страницах этого руководства, на этой странице демонстрируются некоторые из доступных инструментов.**При интеграции всегда обращайтесь к документации по каждому инструменту.** - -## Формат транзакции - -У Polkadot есть базовая информация о транзакциях, которая является общей для всех транзакций. - -- Адрес/Address: SS58-кодированный адрес учётной записи отправителя. -- Хеш Блока/Block Hash: Хэш [контрольной точки/checkpoint](build-protocol-info#transaction-mortality) блока. -- Номер Блока/Block Number: номер контрольной точки блока. -- Хеш Генезиса/Genesis Hash: Хэш генезиса цепочки. -- Метаданные/Metadata: метаданные в кодировке SCALE для среды исполнения при отправке. -- Nonce: [nonce](https://ru.wikipedia.org/wiki/Nonce) для этой транзакции.\* -- Версия Spec: Текущая версия spec для среды исполнения. -- Версия транзакции: текущая версия для формата транзакции. -- Подсказка: необязательно, [советы](build-protocol-info#fees) для увеличения приоритета транзакций. -- Период Эы/Era Period: Необязательно, количество блоков после контрольной точки, для которой транзакция является действительной. Если нуль, транзакция [бессмертная](build-protocol-info#transaction-mortality). - -\*Nonce, запрошенный из системного модуля, не учитывает отложенные транзакции. Вы должны отслеживать и увеличивать nonce вручную, если хотите отправить несколько действительных транзакций одновременно. - -Каждая транзакция будет иметь свои собственные (или нет) параметры для добавления. Например, функция `transferKeepAlive` из паллета Балансов будет принимать: - -- `dest`: Адрес назначения -- `#[compact]количество`: Количество токенов (компактная кодировка) - -Как только Вы получите всю необходимую информацию, Вам нужно будет: - -1. Создать неподписанную транзакцию. -1. Создать информационное наполнение (англ. payload) для подписи. -1. Подписать полезную информацию. -1. Сериализовать подписанную полезную информацию в транзакцию. -1. Отправить сериализованную транзакцию. - -Parity предоставляет следующие инструменты для выполнения этих шагов. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -В этом примере будет использована команда `signer submit`, которая создаст и отправит транзакцию. Команда `signer sendOffline` имеет тот же API, но не будет транслировать транзакцию. `submit` и `sendOffline` должны быть подключены к узлу, чтобы получить текущие метаданные и построить действительную транзакцию. Их API имеет формат: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Подписание: - -```bash -yarn run:signer sign --account --seed --type -``` - -Например, давайте отправим 0.5 DOT от `121X5bEgTZcGQx5NZjwuTjqKoiG8B2wEAvrUFjuw24ZGZf2` до `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -Это вернёт полезную информацию для подписи и входные данные, ожидающие подписи. Возьмите эти данные и используйте свою обычную среду для подписи (например, компьютер в режиме Авиа, VM и т. д.). Подпишите данные: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Сохраните выходные данные и принесите их на машину, с которой Вы будете транслировать, введите их в поле подписи `submit` и отправьте транзакцию (или просто верните сериализованную транзакцию, если вы используете `sendOffline`). - -## Tx Оболочка/Tx Wrapper - -Если Вы не хотите использовать CLI для операций подписи, Parity предоставляет SDK с именем [TxWrapper](https://github.com/paritytech/txwrapper) для генерации и подписания транзакций в автономном режиме. Посмотреть на [примеры](https://github.com/paritytech/txwrapper/tree/master/examples) из руководства. - -**Импорт приватного ключа** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Вывод адреса из открытого ключа** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Открытый ключ может быть либо шестнадцатеричной строкой, либо Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Построить транзакцию оффлайн** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // необходимо импортировать из клиентского RPC вызов state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // количество блоков от контрольной точки, в которой транзакция является действительной - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Создать полезную информацию для подписи** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Сериализовать подписанную транзакцию** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Пример кода, замените `signWithAlice` на актуального удаленного подписанта. -// Пример приведен здесь: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Декодировать типы полезной информации** - -Вы можете декодировать полезную информацию для проверки её содержания до отправки. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Декодируем неподписанную tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Декодируем полезную информацию -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Декодируем подписанную tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Проверьте хэш транзакции** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Отправка подписанной полезной информации - -Есть несколько способов отправить подписанную полезную информацию: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) с `author_submitExtrinsic` или `author_submitAndWatchExtrinsic`, последняя из которых подписывается на события, которые будут уведомлять о том, когда транзакция будет проверена и включена в цепочку. - -## Примечания - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/ru/claims.md b/website/translated_docs/ru/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/ru/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ru/getting-started.md b/website/translated_docs/ru/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/ru/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ru/grants.md b/website/translated_docs/ru/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/ru/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ru/kusama-adverserial-cheatsheet.md b/website/translated_docs/ru/kusama-adverserial-cheatsheet.md deleted file mode 100644 index ab0b872f8bcf..000000000000 --- a/website/translated_docs/ru/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Список вероятных атак -sidebar_label: Шпаргалка враждебности ---- - -Ожидайте, что в Кусаме всё что угодно может сломаться. Чтобы лучше сориентироваться в том, что именно может пойти не так, взгляните на нашу модель угроз. - -| Цель хакера | Гарантия безопасности, которой противостоит взломщик | Стимул взлома | Урон при взломе | Детали взлома | -| ----------------------------------------------------------------------------------------------------------------- |:----------------------------------------------------:|:-------------:|:---------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Двойная трата токенов, заставляя клиентов принимать другую цепочку | Целостность (по всей системе) | Высокий | Высокий | Если злоумышленники смогут провести двойную трату токенов, они смогут получать услуги, не оплачивая их. Это прямой денежный стимул для проведения атаки. | -| Заставить систему чеканить токены на свой счет | Целостность (по всей системе) | Средний | Ниже среднего | Если злоумышленник сможет создавать токены на своём счету "из воздуха" — это будет прямым финансовым вознаграждением за проведение атаки. | -| Валидировать вредные блоки, чтобы реализовать двойную трату токенов | Доступность (в масштабе системы) | Высокий | Средний | Если злоумышленники смогут использовать двойную трату токенов, они смогут получать услуги, не оплачивая их. Это дает им высокий денежный стимул для выполнения нападения. | -| Подорвать механизм консенсуса, чтобы расколоть цепочку | Целостность (по всей системе) | Высокий | Высокий | Если злоумышленник может использовать двойную трату токенов, он способен получать услуги, не оплачивая их. Это дает им высокий денежный стимул для выполнения нападения. Ставки на снижение стоимости криптовалюты или если конкуренты хотят навредить репутации, так что стоимость их блокчейна увеличивается. | -| Фальсифисировать/манипулировать историей блокчейна для аннулирования транзакций (например, результат голосования) | Целостность (по всей системе) | Средний | Выше среднего | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Подорвать блокчейн или механизм консенсуса, чтобы нанести ущерб репутации экосистемы | Наличие (в масштабе системы) | Высокий | Высокий | Делая ставку на снижение стоимости криптовалюты или конкуренты хотят нанести ущерб репутации, так что ценность их блокчейна возрастает | -| Цензура | Наличие (в масштабе системы) | Средний | Высокий | Хакеры способны блокировать нежелательные типы транзакций (например, транзакции отраслевых конкурентов или голосование на референдуме). Это может быть достигнуто путем сговора с другими заинтересованными сторонами или иным способом получения большего числа голосов. | -| Деанонимизировать пользователей | Конфиденциальность (Узел/Нода) | Средний | Средний | Стороны, желающие деанонимизировать пользователей, могут использовать эту информацию для угнетения оппозиции (например, политических активистов). | -| Украсть токен из узла/ноды | Целостность (узел) | Высокий | Высокий | Атакующие, способные украсть токены с узлов могут претендовать на активы, что дает им высокий денежный стимул к совершению нападения. | -| Украсть токен из узла путем утечки учётных данных | Конфиденциальность (Узел/Нода) | Высокий | Высокий | Атакующие, способные украсть токены с узлов могут претендовать на активы, что дает им высокий денежный стимул к совершению нападения. | -| Запретить узлу доступ к сети Polkadot | Доступность (узел) | Низкий | Ниже среднего | Запуск целенаправленной атаки отказа в обслуживании (DDoS) из мести, денежных интересов (в случае конкурирующего обмена монет и т. д.). | -| Обманывать других участников | Целостность (узел) | Средний | Ниже среднего | Злоумышленник может злоупотребить непониманием другими участниками гарантий безопасности Polkadot, чтобы обмануть их. Кроме того, если вознаграждение за вызывающее плохое поведение может быть настроено таким образом, чтобы оно было выше соответствующего наказания, можно настроить набор саморегулируемых узлов для генерации исходного цикла. Другие участники этой атаки не нужны. | -| Обманывать других участников | Целостность (по всей системе) | Высокий | Высокий | Злоумышленник может злоупотреблять ошибками в экономической системе Polkadot, чтобы обмануть других участников. Например, злоумышленник может использовать логическую ошибку, чтобы не платить комиссию за транзакцию. | diff --git a/website/translated_docs/ru/kusama-ledger.md b/website/translated_docs/ru/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/ru/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/ru/kusama-parameters.md b/website/translated_docs/ru/kusama-parameters.md deleted file mode 100644 index 253b9b52bc99..000000000000 --- a/website/translated_docs/ru/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Параматры ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Периоды общих действий и атрибутов - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Эпоха: 1 час (600 слотов x 6 секунд) -- Сессия: 1 час (6 сессий в эре) -- Эра: 6 часов (3600 слотов x 6 секунд) - -| Kusama | Время | Слоты\* | -| ------ | -------- | --------- | -| Slot | 6 секунд | 1 | -| Эпоха | 1 час | 600 | -| Сессия | 1 час | 600 | -| Эра | 6 часов | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Управление - -| Демократия | Время | Слоты | Описание | -| ------------------ | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Период голосования | 7 дней | 100,800 | Как долго общественность может голосовать за референдум. | -| Период запуска | 7 дней | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Период принятия | 8 дней | 115,200 | Время на успешное проведение референдума в сети. | - -| Совет | Время | Слоты | Описание | -| ------------------ | ------ | ------ | ------------------------------------------------------------------------------------ | -| Срок действия | 1 день | 14,400 | Продолжительность срока полномочий члена совета до следующего избирательного раунда. | -| Период голосования | 1 день | 14,400 | Период голосования по предложениям в Совете. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Технический комитет | Время | Слоты | Описание | -| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------- | -| Период ожидания | 7 дней | 604,800 | Время вето от технического комитета длится до того, как предложение будет вновь представлено. | -| Период экстренного голосования | 3 часов | 1,800 | Период голосования после того, как технический комитет ускорит голосование. | - -### Стейкинг, валидация и номинирование - -| Kusama | Время | Слоты | Описание | -| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Срок действия | 6 часов | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Период номинации | 6 часов | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Длительность бондинга | 7 дней | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Длительность отсрочки слэшинга | 7 дней | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Казначейство - -| Казна | Время | Слоты | Описание | -| ----------------------- | ------ | ------ | ------------------------------------------------------------------------- | -| Периоды между расходами | 6 дней | 86,400 | Когда казначейство может потратить средства снова после предидущей траты. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ru/kusama-time-periods.md b/website/translated_docs/ru/kusama-time-periods.md deleted file mode 100644 index e3acda94bd2f..000000000000 --- a/website/translated_docs/ru/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: временные-периоды-kusama -title: Шпаргалка по временным периодам -sidebar_label: Параматры ---- - -### Периоды общих действий и атрибутов - -_ПРИМЕЧАНИЕ: Kusama в 4 раза быстрее Polkadot, кроме времени блока, как и в Polkadot это 6 секунд._ - -- Блок: 6 секунд -- Эпоха: 1 час (600 слотов x 6 секунд) -- Сессия: 1 час (6 сессий в эре) -- Эра: 6 часов (3600 слотов x 6 секунд) - -| Kusama | Время | Слоты\* | -| ------ | -------- | --------- | -| Блок | 6 секунд | 1 | -| Эпоха | 1 час | 600 | -| Сессия | 1 час | 600 | -| Эра | 6 часов | 3,600 | - -\*_В цепочке может быть не более одного блока на слот._ - -### Управление - -| Демократия | Время | Слоты | Описание | -| ------------------ | ------ | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Период голосования | 7 дней | 604,800 | Как долго общественность может голосовать за референдум. | -| Период запуска | 7 дней | 604,800 | Как долго общественность может выбрать, по какому предложению проводить референдум. Каждую неделю будет выбираться наиболее взвешенное предложение для проведения референдума | -| Период принятия | 8 дней | 691,200 | Время на успешное проведение референдума в сети. | - -| Совет | Время | Слоты | Описание | -| ------------------ | ------ | ------ | ------------------------------------------------------------------------------------ | -| Срок действия | 1 день | 14,400 | Продолжительность срока полномочий члена совета до следующего избирательного раунда. | -| Период голосования | 1 день | 14,400 | Период голосования по предложениям в Совете. | - -| Технический комитет | Время | Слоты | Описание | -| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------- | -| Период ожидания | 7 дней | 604,800 | Время вето от технического комитета длится до того, как предложение будет вновь представлено. | -| Период экстренного голосования | 3 часов | 1,800 | Период голосования после того, как технический комитет ускорит голосование. | - -### Стейкинг, валидация и номинирование - -| Kusama | Время | Слоты | Описание | -| ------------------------------ | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Срок действия | 6 часов | 3,600 | Время, в течение которого валидатор находится в наборе после избрания. Обратите внимание, что эта продолжительность может быть сокращена в том случае, если валидатор плохо себя ведет. | -| Период номинации | 6 часов | 3,600 | Каждые 6 часов новый набор валидаторов выбирается в соответствии с методом Phragmen. | -| Длительность бондинга | 7 дней | 604,800 | Как долго Ваши средства будут не перемещаемыми после отмены бондинга. | -| Длительность отсрочки слэшинга | 7 дней | 604,800 | Предотвращает чрезмерный слешинг и "побег" валидаторов, а так же получают своих номинаторов порезанными без каких-либо последствий для себя | - -### Казначейство - -| Казна | Время | Слоты | Описание | -| ----------------------- | ------ | ------- | ------------------------------------------------------------------------- | -| Периоды между расходами | 6 дней | 518,400 | Когда казначейство может потратить средства снова после предидущей траты. | diff --git a/website/translated_docs/ru/learn-UI.md b/website/translated_docs/ru/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/ru/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/ru/learn-accounts.md b/website/translated_docs/ru/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/ru/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ru/learn-availability.md b/website/translated_docs/ru/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/ru/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/ru/learn-balance-transfers.md b/website/translated_docs/ru/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/ru/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/ru/learn-bridges.md b/website/translated_docs/ru/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/ru/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ru/learn-cryptography.md b/website/translated_docs/ru/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/ru/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ru/learn-governance.md b/website/translated_docs/ru/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/ru/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ru/learn-interchain.md b/website/translated_docs/ru/learn-interchain.md deleted file mode 100644 index a6246da9ba4e..000000000000 --- a/website/translated_docs/ru/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. - -The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. - -## Overview - -- Interchain messages will *not* go on to the relay chain. -- Interchain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. - -## Example - -A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. - -When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/ru/learn-ledger.md b/website/translated_docs/ru/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/ru/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ru/learn-registrar.md b/website/translated_docs/ru/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/ru/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ru/learn-staking.md b/website/translated_docs/ru/learn-staking.md deleted file mode 100644 index 0086f64daf82..000000000000 --- a/website/translated_docs/ru/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on secure validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ru/learn-treasury.md b/website/translated_docs/ru/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/ru/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ru/maintain-governance-index.md b/website/translated_docs/ru/maintain-governance-index.md deleted file mode 100644 index f2371610e1fa..000000000000 --- a/website/translated_docs/ru/maintain-governance-index.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -id: maintain-governance-index -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. - -All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. - -The following steps are the governance procedure in the Polkadot network: - -- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) -- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) -- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) - -To better understand how the council is formed, please read [this section](#council). - -### Proposing Referenda - -- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. - -- **[Council](#council)**: - - Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. - - Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) - -### Voting for a proposal - -To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). - -``` -Example: - -Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes -``` - -According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. - -### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -voters - the total number of voting tokens - -electorate - the total number of DOTs tokens issued in the network -``` - -**Super-Majority Approve** - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ - -**Super-Majority Against** - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ - -**Simple-Majority** - -Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ - -*To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)*. - -``` -Example: - -Assume we only have 1,500 DOTs tokens in total. - -John - 500 DOTs -Peter - 100 DOTs -Lilly - 150 DOTs -JJ - 150 DOTs -Ken - 600 DOTs - -John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -voters = 1050 -electorate = 1500 -``` - -$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ - -$${13.887} < {15.492}$$ - -Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. - -## Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: - -``` -Max votes = tokens * periods -``` - -Based on the current testnet setting, the maximum number of lock periods is set to 6. - -**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** - - -## Adaptive Quorum Biasing - -Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. - -Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. - -Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. - -In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -## Council - -Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). - -### How to be a council member? - -![](assets/governance/approval-vote.png) - - At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. - -To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. - -Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. - -Let's take a look at the example below. - -||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. - -### Resources - -- [Governance Description](learn-governance#referenda) -- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) - -## [Usage of DOT](learn-DOT#dots-for-governance) - -## Guides - -### [How to create a proposal]() -### [How to join the council]() -### [How to propose a referenda]() diff --git a/website/translated_docs/ru/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/ru/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/ru/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/ru/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/ru/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/ru/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/ru/maintain-guides-how-to-nominate.md b/website/translated_docs/ru/maintain-guides-how-to-nominate.md deleted file mode 100644 index d846a22dddd0..000000000000 --- a/website/translated_docs/ru/maintain-guides-how-to-nominate.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: maintain-guides-how-to-nominate -title: How to nominate -sidebar_label: How to nominate ---- - -This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. - -It has been updated for the Alexander testnet and Polkadot release PoC-4. - -## Create `stash` and `controller` accounts - -We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. - -The first step is to create two accounts by going to the *Accounts* tab on the Polkadot Dashboard and clicking on [*Add account*](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. - -![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) - -Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. - -## Nominating - -It is now time to setup our nominator. We will do the following: -- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. -- Select the `controller`. This is the account that will decide when to start or stop nominating. - -First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. - -![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. -- **Controller account** - select the `controller` account created earlier. -- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). -- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). - -Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. - -![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) - -## Nominating a validator - -Go to the *Staking Overview* tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. - -![Validators](assets/guides/how-to-nominate/validators.png) - -Go back to the *Account Actions* tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). - -![Nominating](assets/guides/how-to-nominate/nominating.jpg) - -**Congratulations!** You are now a nominator. - -If you return to the *Staking Overview* tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. - -![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) - -## How to stop nominating - -To stop nominating simply return to the *Account Actions* tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/ru/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/ru/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/ru/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/ru/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/ru/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/ru/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/ru/maintain-guides-society-kusama.md b/website/translated_docs/ru/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/ru/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ru/maintain-polkadot-parameters.md b/website/translated_docs/ru/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/ru/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ru/redenomination.md b/website/translated_docs/ru/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/ru/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ru/thousand-validators.md b/website/translated_docs/ru/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/ru/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/sk-SK/build-protocol-info.md b/website/translated_docs/sk-SK/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/sk-SK/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/sk-SK/build-transaction-construction.md b/website/translated_docs/sk-SK/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/sk-SK/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/sk-SK/claims.md b/website/translated_docs/sk-SK/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/sk-SK/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/sk-SK/getting-started.md b/website/translated_docs/sk-SK/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/sk-SK/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/sk-SK/grants.md b/website/translated_docs/sk-SK/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/sk-SK/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/sk-SK/kusama-adverserial-cheatsheet.md b/website/translated_docs/sk-SK/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/sk-SK/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/sk-SK/kusama-ledger.md b/website/translated_docs/sk-SK/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/sk-SK/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/sk-SK/kusama-parameters.md b/website/translated_docs/sk-SK/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/sk-SK/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/sk-SK/kusama-time-periods.md b/website/translated_docs/sk-SK/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/sk-SK/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/sk-SK/learn-accounts.md b/website/translated_docs/sk-SK/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/sk-SK/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/sk-SK/learn-availability.md b/website/translated_docs/sk-SK/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/sk-SK/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/sk-SK/learn-balance-transfers.md b/website/translated_docs/sk-SK/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/sk-SK/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/sk-SK/learn-bridges.md b/website/translated_docs/sk-SK/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/sk-SK/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/sk-SK/learn-cryptography.md b/website/translated_docs/sk-SK/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/sk-SK/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/sk-SK/learn-governance.md b/website/translated_docs/sk-SK/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/sk-SK/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/sk-SK/learn-ledger.md b/website/translated_docs/sk-SK/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/sk-SK/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/sk-SK/learn-registrar.md b/website/translated_docs/sk-SK/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/sk-SK/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/sk-SK/learn-staking.md b/website/translated_docs/sk-SK/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/sk-SK/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/sk-SK/learn-treasury.md b/website/translated_docs/sk-SK/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/sk-SK/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/sk-SK/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/sk-SK/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/sk-SK/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/sk-SK/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/sk-SK/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/sk-SK/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/sk-SK/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/sk-SK/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/sk-SK/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/sk-SK/maintain-guides-society-kusama.md b/website/translated_docs/sk-SK/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/sk-SK/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/sk-SK/maintain-polkadot-parameters.md b/website/translated_docs/sk-SK/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/sk-SK/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/sk-SK/redenomination.md b/website/translated_docs/sk-SK/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/sk-SK/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/sk-SK/thousand-validators.md b/website/translated_docs/sk-SK/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/sk-SK/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/th-TH/build-exchange-integration.md b/website/translated_docs/th-TH/build-exchange-integration.md deleted file mode 100644 index 27da9d2321be..000000000000 --- a/website/translated_docs/th-TH/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. Tracking the chain head - -Track each finalised block by subscribing with the `chain_subscribeFinalizedHeads` RPC (or polling the `chain_getFinalizedHead` RPC). - -That will give you a stream of hashes of the most recent finalised headers. - -When a new hash arrives, you can use `chain_getBlock` to turn that hash into a block. - -If the new block is not an immediate child of the last block you processed, make sure that you iterate over all blocks between them. Because `chain_getBlock` can accept only hashes, you will need to use `chain_getBlockHash` to convert numbers into hashes and in this way iterate between any two finalised blocks. - -## 2. Decoding blocks - -You will need to decode blocks from the basic data into useful fields. - -All block data is encoded using the basic SCALE codec described in detail [here](https://substrate.dev/docs/en/overview/low-level-data-format). SCALE provides only the low-level underlying format however. Details of its fields and internal structure may alter between different chains and even different blocks of the same chain. - -For Genesis Polkadot, the header format is a five-field structure: - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -This relies on `Hash`, which is a fixed length 32-byte value or `[u8; 32]` in SCALE. It also relies on `DigestItem`, an enumeration type: - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -It also relies on `Extrinsic`. An *extrinsic* is a generalisation of a transaction and other (unsigned) external information. It is a highly extensible type which doesn't have a fixed format per se. To ensure future format compatibility, metadata concerning the extrinsic format is provided through an RPC `state_getMetadata`. - -The metadata itself is provided encoded in SCALE. Its format is: - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -`Type` is just a `String`, but the contents of the string are to be interpreted as the name of a type. - -Substrate chains (actually, specifically Substrate chains built using the SRML) such as Polkadot are composed of various *modules*. Each module can be imagined a little bit like a smart contract, with various kinds of transactions (or, in Substrate terms, *extrinsics*), data items that persist between transactions and blocks, events and constant parameters. The metadata encodes all of these things, allowing your client code to both create particular transactions or interpret what has happened on the chain, even between different Substrate blockchains or over many different upgrades or forks of the same chain. - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. Working with SS58 and account addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) *AccountId*. This is simply the public key for the x25519 cryptography used by Substrate. - -However, to keep the addresses small, we index every account with a non-zero balance on Polkadot and use just this *index* to identify the account. This index is much smaller than the 32-byte *AccountId*, and can usually be encoded in just a couple of bytes. - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -The SS58 format is a base-58 encoding (using the same alphabet as Bitcoin) of a version prefix (which is one byte and always `0x00` for Polkadot and `0x02` for Kusama) followed by one or more payload bytes and ending with one or more checksum bytes: - -`0x00 ` - -**An address does not have a fixed length.** Depending on the length, the payload may have a different meaning and there could be a different ratio of payload to checksum bytes. Here is a table to consult to determine how to interpret an address of a particular size: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -NOTE: This table contains only the most common commbinations; SS58 includes several more uncommon ones. For maximum compatibility then implement according to the full SS58 specification. - -Once decoded into the fields, then the version should be checked to be `0x00`. The checksum should then be verified as being equivalent to the beginning of the Blake2-256 hash of the SS58 data, not including the checksum itself. If the checksum is one byte, then only the first byte of the hash is checked. If it is two bytes, then the first two bytes of the hash are checked. - -Finally, in the case of an indexed address, the index should be decoded into a 32-byte account identifier. This can be done by inspecting the storage of the Indices module. - -### Looking up an index - -Looking up an index is a bit fiddly, since it involves looking up some storage and decoding and interpreting it. - -The specific storage item that we care about is `EnumSet` in the `Indices` module. Inspecting the storage is done through the `state_getStorage` RPC, to which a key must be supplied. The key encodes the entire "query". In general, the metadata should be consulted on how to generate the key. To do this, we first find the `Module` whose name is `Indices`, then find the entry in that module's `storage` field of the `Storage` item with the name `EnumSet`. This item contains all the information we need to construct and interpret the query. - -For Polkadot, we find that the item has a `type` of `Map` whose associate value is a `StorageMapType` whose `hasher` is `Blake2_256`, whose `key` is `T::AccountIndex` (equivalent to a `u32` for Polkadot) and whose `value` is `Vec`. - -This means that if our index, encoded by SCALE as a `u32`, is ``, then our storage key is determined through the Blake2 256 hash of the string `Indices EnumSet`. In fact, accounts are stored in batches of 64, so to look up a particular index, we don't query by the account index but rather the index of its batch. This just means we first need to divide the index by 64 before encoding. - -This will return a SCALE-encoded `Vec` (`T::AccountId` may be defined in SCALE as `[u8; 32]` or a 32-byte fixed quantity) of up the batch that contains the account we are interested in. To get the `AccountId` item, just take the `index % 64`th item from the vector. If that item doesn't exist (or you get an empty storage item), then the account index is invalid. - -Otherwise, you have your account ID and it can be displayed to the user along with its identicon and balance. - -## 4. Working with balances - -In Polkadot, account balances can be looked up within the `Balances` module using the metadata in a manner not dissimilar to looking up an account index. In this case, we need to query the `FreeBalance` item in storage. Here, the `StorageMapType` is similar, except that the `key` is of type `T::AccountId` (the 32-byte quantity) and the `value` is `BalanceOf`, which for the purposes of Polkadot is a `u128` (128-bit value). The hash function is the same Blake2 256, so the full storage key would be given by the Blake2 256 hash of the string `Balances FreeBalance` where `` is the 32-byte `AccountId`. - -NOTE: `FreeBalance` gives the total balance controlled by that account, but does not account for temporarily locked portions of balance, such as those locked for staking, voting or vesting. This information can be queried from the chain, but it is outside the scope of this document. - -The balance encodes the DOT token with 12 decimal places. To get the actual number of DOTs, you need to divide the 128-bit balance by 1,000,000,000,000 (10**12). For completeness, The exact denominations of the Polkadot currency are: - -| Balance value | Name | -| ------------- | ---- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### Transferring balances - -To transfer a balance, a transaction must be constructed and sent. In constructing a transaction, there are two key parts: the general part of the transaction and the module-specific `function` part of the transaction with the latter generally needing information from the chain's metadata must generally. - -In general, Polkadot's transactions are encoded as *signed* `Extrinsic`s in SCALE. To facilitate forward compatibility, extrinsics are double-encoded, so the initial encoding is passed back into SCALE (as a `Vec`) and the output of that is used. This has the effect of adding a small length prefix onto it allowing systems that cannot interpret the transaction data itself to still be able to pass them around as opaque packets of data. - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -For a transaction, the optional `tx` is always used. The `Address` type is a specially encoded SCALE type, allowing an account to be presented either as an account index or as a 32-byte account ID, whichever is more convenient. The format is described here in the SCALE [TODO]. Assuming you wish to present a 32-byte account ID, then it can be expressed as an `Address` merely by prefixing the `0xff` byte. - -The `sig` field must contain a 25519-family signature of the SCALE-encoded `SigPayload`. The key used to sign the payload must correspond to the `sender` account. Schnorr/Ristretto 25519 ("sr25519") is the recommended signing format to use. - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -The nonce is the number of transactions send so far by the sender account, much like in Ethereum. It is of type `Nonce`, logically equivalent to a `u64`. To get the correct value, the appropriate storage item must be queried, much like when querying an account's balance. In this case, it is the `System` module's `AccountNonce` item; thus the storage key required is the Blake2 256 hash of the string `System AccountNonce` where `` is the 32-byte `AccountId`. It will return a `Nonce` which may be decoded and used here. - -NOTE: The nonce retrieved from storage does not take into account *pending* transactions. If you are sending more than one transaction from a single account at a time, then you will need to increment and track this value manually. - -The `tip` is a `Balance` (logically equivalent to the `u128` type in SCALE), which denotes some additional fees paid to the block author for prioritized inclusion at busy times. It will typically be zero. - -The `checkpoint_hash` is the hash of the "checkpoint block", which is to say the first block of the era specified by the `era` field. If just making the transaction "immortal", then the genesis hash of the blockchain should be used. This can be determined through the RPC `chain_getBlockHash(0)`. - -Finally, the `function` is a `Function` type (sometimes known as a `Call` or `Proposal` in certain contexts) which describes what action shall be dispatched. It must be constructed according to metadata. In this case, we want our transaction to effect the `transfer` function in the `Balances` module, to transfer a balance from one account to another. It is important to check the index of the Balances module itself in the list of modules. In this case, it is the 6th item, or index 5. It is also necessary to inspect the `calls` field of the Balances `Module` in the metadata, and determine what index in the list of calls the transfer function is. As it happens, it is first in the list, and thus has an index of 0. - -Finally, we need to know what parameters to this function are expected in order to construct the rest of the transaction. This is provided in the `Call` item of the metadata that we just located. Two parameters are expected: -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -The `function` *in this case* (i.e. specifically and only for the Balance transfer transaction on Polkadot as of right now) would be the struct: - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -where `module_index` is `0x05` and `call_index` is `0x00`. `dest` is similar to `sender` and may be provided as either an account index or a 32-byte account ID, whichever is more convenient. If providing as an account ID, then it can be formed into an address simply by prefixing the byte `0xff` to it. - -The amount to be transferred (not including any fees payable to the system) is given by `value`, and must be a SCALE compact-encoded number. - -### Submitting and checking transactions - -Once a transaction has been crafted, you will need to submit it for inclusion in the chain and eventually want to verify that it has indeed been included. - -This can be done in two ways: one is to use the simple RPC `author_submitExtrinsic`, which will return the transaction's hash. Once submitted, you can keep checking transactions in finalised blocks manually (since you are tracking the finalised heads anyway) until you see the transaction you submitted, at which point you know it is in the chain. - -The other way is to use the pub/sub RPC `author_submitAndWatchExtrinsic`. Again, you provide the SCALE-encoded transaction, but here you receive a subscription ID. You will be notified over the RPC as the transaction gets validated, broadcast and included in the chain with separate messages that are pushed. - -## Conclusion - -This concludes the article. Here you should have a good idea of how to interact with a Substrate/Polkadot node in order to track the finalised chain head, to decode SS58 addresses, check account information like balances & nonces and to construct, submit and track transactions. You've also learnt a little about the SCALE codec, the Substrate metadata system and how to build future-proof and generic Substrate-based systems. - -If you have any questions, please come ask in [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org). - -_The original source of this page was published [here](https://hackmd.io/@gavwood/r1jTRX2Zr)._ diff --git a/website/translated_docs/th-TH/build-extrinsic-format.md b/website/translated_docs/th-TH/build-extrinsic-format.md deleted file mode 100644 index 92d1692bb078..000000000000 --- a/website/translated_docs/th-TH/build-extrinsic-format.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: build-extrinsic-format -title: Polkadot Extrinsic Format aka Transaction Format -sidebar_label: Polkadot Extrinsic Format aka Transaction Format ---- - -## Old Format - -For reference, the **old** extrinsic format was: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] -``` - -## Current Format - -The Polkadot extrinsic format is: - -``` -[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] -``` - -The *original* fields refer to the following from the old extrinsic format: - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] -``` - -The specific format for the new address type is one of 5 sub-formats, switched on the first byte: - -- `0xff, 32-byte account id` -- `0xfe, 8-byte account index` -- `0xfd, 4-byte account index` -- `0xfc, 2-byte account index` -- `[0xf0...0xfb] (invalid, reserved for future use)` -- `[0x00...0xef] 1-byte account index (less than 0xf0)` - -The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id. - -In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) in the old format are now Address (1/3/5/9/33-bytes). - -## Source - -[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/th-TH/build-protocol-info.md b/website/translated_docs/th-TH/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/th-TH/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/th-TH/build-rust-style-guide.md b/website/translated_docs/th-TH/build-rust-style-guide.md deleted file mode 100644 index 52f24a8a5b1b..000000000000 --- a/website/translated_docs/th-TH/build-rust-style-guide.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: build-rust-style-guide -title: Style Guide for Rust in Polkadot -sidebar_label: Style Guide for Rust in Polkadot ---- - -- Indent using tabs -- Lines should be longer than 80 characters long only in exceptional circumstances and certainly no longer than 120. For this purpose, tabs are considered 4 characters wide. -- Indent levels should be greater than 5 only in exceptional circumstances and certainly no greater than 8. If they are greater than 5, then consider using `let` or auxiliary functions in order to strip out complex inline expressions. -- Never have spaces on a line prior to a non-whitespace character -- Follow-on lines are only ever a single indent from the original line. -```rust -fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -> bool { - let x = some_long_variable_a * some_long_variable_b - - some_long_variable_b / some_long_variable_a - + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); - x > 10 -} -``` -- Indent level should follow open parens/brackets, but should be collapsed to the smallest number of levels actually used: -```rust -fn calculate( - some_long_variable_a: f32, - some_long_variable_b: f32, - some_long_variable_c: f32, -) -> f32 { - (-some_long_variable_b + sqrt( - // two parens open, but since we open & close them both on the - // same line, only one indent level is used - some_long_variable_b * some_long_variable_b - - 4 * some_long_variable_a * some_long_variable_c - // both closed here at beginning of line, so back to the original indent - // level - )) / (2 * some_long_variable_a) -} -``` -- `where` is indented, and its items are indented one further -- Argument lists or function invocations too long to fit on one line are indented similarly to code blocks, and once one param is indented in such a way, all others should be, too. Run-on parameter lists are also acceptable for single-line run-ons of basic function calls. - -```rust -// OK -fn foo( - really_long_parameter_name_1: SomeLongTypeName, - really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, - shrt_nm_2: u8, -) { - ... -} - -// NOT OK -fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, shrt_nm_2: u8) { - ... -} - -``` - -```rust -{ - // Complex line (not just a function call, also a let statement). Full - // structure. - let (a, b) = bar( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Long, simple function call. - waz( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // Short function call. Inline. - baz(a, b); -} -``` - -- Always end last item of a multi-line comma-delimited set with `,` when legal: -```rust -struct Point { - x: T, - y: T, // <-- Multiline comma-delimited lists end with a trailing , -} - -// Single line comma-delimited items do not have a trailing `,` -enum Meal { Breakfast, Lunch, Dinner }; -``` - -- Avoid trailing `;`s where unneeded. -```rust -if condition { - return 1 // <-- no ; here -} -``` - -- `match` arms may be either blocks or have a trailing `,` but not both. -- Blocks should not be used unnecessarily. -```rust -match meal { - Meal::Breakfast => "eggs", - Meal::Lunch => { check_diet(); recipe() }, -// Meal::Dinner => { return Err("Fasting") } // WRONG - Meal::Dinner => return Err("Fasting"), -} -``` diff --git a/website/translated_docs/th-TH/build-transaction-construction.md b/website/translated_docs/th-TH/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/th-TH/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/th-TH/claims.md b/website/translated_docs/th-TH/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/th-TH/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/th-TH/getting-started.md b/website/translated_docs/th-TH/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/th-TH/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/th-TH/grants.md b/website/translated_docs/th-TH/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/th-TH/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/th-TH/kusama-adverserial-cheatsheet.md b/website/translated_docs/th-TH/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/th-TH/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/th-TH/kusama-ledger.md b/website/translated_docs/th-TH/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/th-TH/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/th-TH/kusama-parameters.md b/website/translated_docs/th-TH/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/th-TH/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/th-TH/kusama-time-periods.md b/website/translated_docs/th-TH/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/th-TH/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/th-TH/learn-UI.md b/website/translated_docs/th-TH/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/th-TH/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/th-TH/learn-accounts.md b/website/translated_docs/th-TH/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/th-TH/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/th-TH/learn-availability.md b/website/translated_docs/th-TH/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/th-TH/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/th-TH/learn-balance-transfers.md b/website/translated_docs/th-TH/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/th-TH/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/th-TH/learn-bridges.md b/website/translated_docs/th-TH/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/th-TH/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/th-TH/learn-cryptography.md b/website/translated_docs/th-TH/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/th-TH/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/th-TH/learn-governance.md b/website/translated_docs/th-TH/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/th-TH/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/th-TH/learn-interchain.md b/website/translated_docs/th-TH/learn-interchain.md deleted file mode 100644 index a6246da9ba4e..000000000000 --- a/website/translated_docs/th-TH/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -Interchain transactions are resolved using a simple queuing mechanism based around a merkle tree to ensure fidelity. It is the task of the relay-chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. - -The input and output queue are sometimes referred to in the codebase as "ingress" and "egress" messages. - -## Overview - -- Interchain messages will *not* go on to the relay chain. -- Interchain messages will be constrained to a maximum size in bytes. -- Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. -- Collator nodes are responsible for routing messages between chains. -- Collators produce a list of "egress" messages and will receive the "ingress" messages from other parachains. -- On each block, parachains are expected to route messages from some subset of all other parachains. -- When a collator produces a new block to hand off to a validator, it will collect the latest ingress queue information and process it. -- Validators will check a proof that the new candidate for the next parachain block includes the processing of the expected ingress messages to that parachain. - -## Example - -A smart contract that exists on parachain A will route a message to parachain B in which another smart contract is called that makes a transfer of some assets within that chain. - -Charlie executes the smart contract on parachain A which initiates a new interchain message for the destination of a smart contract on parachain B. - -The collator node of parachain A will place this new interchain message into its outbound messages queue, along with a `destination` and a `timestamp`. - -The collator node of parachain B routinely pings all other collator nodes asking for new messages (filtering by the `destination` field). When the collator of parachain B makes its next ping, it will see this new message on parachain A and add it into its own inbound queue for processing into the next block. - -Validators for parachain A will also read the outbound queue and know the message. Validators for parachain B will do the same. This is so that they will be able to verify the message transmission happened. - -When the collator of parachain B is building the next block in its chain, it will process the new message in its inbound queue as well as any other messages it may have found/received. - -During processing, the message will execute the smart contract on parachain B and complete the asset transfer like intended. - -The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator will include this block for parachain B into the relay chain. - -## Resources - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/th-TH/learn-ledger.md b/website/translated_docs/th-TH/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/th-TH/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/th-TH/learn-registrar.md b/website/translated_docs/th-TH/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/th-TH/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/th-TH/learn-staking.md b/website/translated_docs/th-TH/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/th-TH/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/th-TH/learn-treasury.md b/website/translated_docs/th-TH/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/th-TH/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/th-TH/maintain-governance-index.md b/website/translated_docs/th-TH/maintain-governance-index.md deleted file mode 100644 index f2371610e1fa..000000000000 --- a/website/translated_docs/th-TH/maintain-governance-index.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -id: maintain-governance-index -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. - -All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. - -The following steps are the governance procedure in the Polkadot network: - -- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) -- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) -- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) - -To better understand how the council is formed, please read [this section](#council). - -### Proposing Referenda - -- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. - -- **[Council](#council)**: - - Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. - - Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) - -### Voting for a proposal - -To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). - -``` -Example: - -Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes -``` - -According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. - -### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -voters - the total number of voting tokens - -electorate - the total number of DOTs tokens issued in the network -``` - -**Super-Majority Approve** - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ - -**Super-Majority Against** - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ - -**Simple-Majority** - -Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ - -*To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)*. - -``` -Example: - -Assume we only have 1,500 DOTs tokens in total. - -John - 500 DOTs -Peter - 100 DOTs -Lilly - 150 DOTs -JJ - 150 DOTs -Ken - 600 DOTs - -John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -voters = 1050 -electorate = 1500 -``` - -$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ - -$${13.887} < {15.492}$$ - -Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. - -## Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: - -``` -Max votes = tokens * periods -``` - -Based on the current testnet setting, the maximum number of lock periods is set to 6. - -**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** - - -## Adaptive Quorum Biasing - -Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. - -Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. - -Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. - -In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -## Council - -Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). - -### How to be a council member? - -![](assets/governance/approval-vote.png) - - At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. - -To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. - -Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. - -Let's take a look at the example below. - -||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. - -### Resources - -- [Governance Description](learn-governance#referenda) -- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) - -## [Usage of DOT](learn-DOT#dots-for-governance) - -## Guides - -### [How to create a proposal]() -### [How to join the council]() -### [How to propose a referenda]() diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/th-TH/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/th-TH/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/th-TH/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index dcb2ab8ede50..000000000000 --- a/website/translated_docs/th-TH/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: การเป็นผู้เสนอชื่อ (Nominator) บนเครือข่าย Alexander -sidebar_label: การเป็นผู้เสนอชื่อ (Nominator) บนเครือข่าย Alexander ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-nominate.md b/website/translated_docs/th-TH/maintain-guides-how-to-nominate.md deleted file mode 100644 index d846a22dddd0..000000000000 --- a/website/translated_docs/th-TH/maintain-guides-how-to-nominate.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: maintain-guides-how-to-nominate -title: How to nominate -sidebar_label: How to nominate ---- - -This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. - -It has been updated for the Alexander testnet and Polkadot release PoC-4. - -## Create `stash` and `controller` accounts - -We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. - -The first step is to create two accounts by going to the *Accounts* tab on the Polkadot Dashboard and clicking on [*Add account*](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. - -![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) - -Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. - -## Nominating - -It is now time to setup our nominator. We will do the following: -- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. -- Select the `controller`. This is the account that will decide when to start or stop nominating. - -First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. - -![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. -- **Controller account** - select the `controller` account created earlier. -- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). -- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). - -Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. - -![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) - -## Nominating a validator - -Go to the *Staking Overview* tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. - -![Validators](assets/guides/how-to-nominate/validators.png) - -Go back to the *Account Actions* tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). - -![Nominating](assets/guides/how-to-nominate/nominating.jpg) - -**Congratulations!** You are now a nominator. - -If you return to the *Staking Overview* tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. - -![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) - -## How to stop nominating - -To stop nominating simply return to the *Account Actions* tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/th-TH/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/th-TH/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/th-TH/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/th-TH/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/th-TH/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/th-TH/maintain-guides-society-kusama.md b/website/translated_docs/th-TH/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/th-TH/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/th-TH/maintain-polkadot-parameters.md b/website/translated_docs/th-TH/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/th-TH/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/th-TH/redenomination.md b/website/translated_docs/th-TH/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/th-TH/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/th-TH/thousand-validators.md b/website/translated_docs/th-TH/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/th-TH/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/tr/build-protocol-info.md b/website/translated_docs/tr/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/tr/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/tr/build-transaction-construction.md b/website/translated_docs/tr/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/tr/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/tr/claims.md b/website/translated_docs/tr/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/tr/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/tr/getting-started.md b/website/translated_docs/tr/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/tr/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/tr/grants.md b/website/translated_docs/tr/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/tr/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/tr/kusama-adverserial-cheatsheet.md b/website/translated_docs/tr/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/tr/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/tr/kusama-ledger.md b/website/translated_docs/tr/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/tr/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/tr/kusama-parameters.md b/website/translated_docs/tr/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/tr/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/tr/kusama-time-periods.md b/website/translated_docs/tr/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/tr/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/tr/learn-accounts.md b/website/translated_docs/tr/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/tr/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/tr/learn-availability.md b/website/translated_docs/tr/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/tr/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/tr/learn-balance-transfers.md b/website/translated_docs/tr/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/tr/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/tr/learn-bridges.md b/website/translated_docs/tr/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/tr/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/tr/learn-cryptography.md b/website/translated_docs/tr/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/tr/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/tr/learn-governance.md b/website/translated_docs/tr/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/tr/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/tr/learn-ledger.md b/website/translated_docs/tr/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/tr/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/tr/learn-registrar.md b/website/translated_docs/tr/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/tr/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/tr/learn-staking.md b/website/translated_docs/tr/learn-staking.md deleted file mode 100644 index 8c24a9fe69a3..000000000000 --- a/website/translated_docs/tr/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/tr/learn-treasury.md b/website/translated_docs/tr/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/tr/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/tr/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/tr/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/tr/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/tr/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/tr/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/tr/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/tr/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/tr/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/tr/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/tr/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/tr/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/tr/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/tr/maintain-guides-society-kusama.md b/website/translated_docs/tr/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/tr/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/tr/maintain-polkadot-parameters.md b/website/translated_docs/tr/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/tr/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/tr/redenomination.md b/website/translated_docs/tr/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/tr/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/tr/thousand-validators.md b/website/translated_docs/tr/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/tr/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ur-IN/build-protocol-info.md b/website/translated_docs/ur-IN/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/ur-IN/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ur-IN/build-transaction-construction.md b/website/translated_docs/ur-IN/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/ur-IN/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/ur-IN/claims.md b/website/translated_docs/ur-IN/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/ur-IN/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ur-IN/getting-started.md b/website/translated_docs/ur-IN/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/ur-IN/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ur-IN/grants.md b/website/translated_docs/ur-IN/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/ur-IN/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ur-IN/kusama-adverserial-cheatsheet.md b/website/translated_docs/ur-IN/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/ur-IN/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ur-IN/kusama-ledger.md b/website/translated_docs/ur-IN/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/ur-IN/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/ur-IN/kusama-parameters.md b/website/translated_docs/ur-IN/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/ur-IN/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ur-IN/kusama-time-periods.md b/website/translated_docs/ur-IN/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/ur-IN/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ur-IN/learn-accounts.md b/website/translated_docs/ur-IN/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/ur-IN/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ur-IN/learn-availability.md b/website/translated_docs/ur-IN/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/ur-IN/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/ur-IN/learn-balance-transfers.md b/website/translated_docs/ur-IN/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/ur-IN/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/ur-IN/learn-bridges.md b/website/translated_docs/ur-IN/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/ur-IN/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ur-IN/learn-cryptography.md b/website/translated_docs/ur-IN/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/ur-IN/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ur-IN/learn-governance.md b/website/translated_docs/ur-IN/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/ur-IN/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ur-IN/learn-ledger.md b/website/translated_docs/ur-IN/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/ur-IN/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ur-IN/learn-registrar.md b/website/translated_docs/ur-IN/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/ur-IN/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ur-IN/learn-staking.md b/website/translated_docs/ur-IN/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/ur-IN/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ur-IN/learn-treasury.md b/website/translated_docs/ur-IN/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/ur-IN/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/ur-IN/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/ur-IN/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/ur-IN/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/ur-IN/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/ur-IN/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/ur-IN/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/ur-IN/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/ur-IN/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/ur-IN/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/ur-IN/maintain-guides-society-kusama.md b/website/translated_docs/ur-IN/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/ur-IN/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ur-IN/maintain-polkadot-parameters.md b/website/translated_docs/ur-IN/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/ur-IN/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ur-IN/redenomination.md b/website/translated_docs/ur-IN/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/ur-IN/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ur-IN/thousand-validators.md b/website/translated_docs/ur-IN/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/ur-IN/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/ur-PK/build-protocol-info.md b/website/translated_docs/ur-PK/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/ur-PK/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/ur-PK/build-transaction-construction.md b/website/translated_docs/ur-PK/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/ur-PK/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/ur-PK/claims.md b/website/translated_docs/ur-PK/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/ur-PK/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/ur-PK/getting-started.md b/website/translated_docs/ur-PK/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/ur-PK/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/ur-PK/grants.md b/website/translated_docs/ur-PK/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/ur-PK/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/ur-PK/kusama-adverserial-cheatsheet.md b/website/translated_docs/ur-PK/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/ur-PK/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/ur-PK/kusama-ledger.md b/website/translated_docs/ur-PK/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/ur-PK/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/ur-PK/kusama-parameters.md b/website/translated_docs/ur-PK/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/ur-PK/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/ur-PK/kusama-time-periods.md b/website/translated_docs/ur-PK/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/ur-PK/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/ur-PK/learn-accounts.md b/website/translated_docs/ur-PK/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/ur-PK/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/ur-PK/learn-availability.md b/website/translated_docs/ur-PK/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/ur-PK/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/ur-PK/learn-balance-transfers.md b/website/translated_docs/ur-PK/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/ur-PK/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/ur-PK/learn-bridges.md b/website/translated_docs/ur-PK/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/ur-PK/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/ur-PK/learn-cryptography.md b/website/translated_docs/ur-PK/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/ur-PK/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/ur-PK/learn-governance.md b/website/translated_docs/ur-PK/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/ur-PK/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/ur-PK/learn-ledger.md b/website/translated_docs/ur-PK/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/ur-PK/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/ur-PK/learn-registrar.md b/website/translated_docs/ur-PK/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/ur-PK/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/ur-PK/learn-staking.md b/website/translated_docs/ur-PK/learn-staking.md deleted file mode 100644 index 8c24a9fe69a3..000000000000 --- a/website/translated_docs/ur-PK/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/ur-PK/learn-treasury.md b/website/translated_docs/ur-PK/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/ur-PK/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/ur-PK/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/ur-PK/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/ur-PK/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/ur-PK/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/ur-PK/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/ur-PK/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/ur-PK/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/ur-PK/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/ur-PK/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/ur-PK/maintain-guides-society-kusama.md b/website/translated_docs/ur-PK/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/ur-PK/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/ur-PK/maintain-polkadot-parameters.md b/website/translated_docs/ur-PK/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/ur-PK/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/ur-PK/redenomination.md b/website/translated_docs/ur-PK/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/ur-PK/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/ur-PK/thousand-validators.md b/website/translated_docs/ur-PK/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/ur-PK/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/zh-CN/build-build-with-polkadot.md b/website/translated_docs/zh-CN/build-build-with-polkadot.md deleted file mode 100644 index 87681e26928e..000000000000 --- a/website/translated_docs/zh-CN/build-build-with-polkadot.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-build-with-polkadot -title: Polkadot 開發者入门指南 -sidebar_label: Polkadot 開發者入门指南 ---- - -_本文是对博文[《波卡开发入门需知》](https://medium.com/polkadot-network/everything-you-need-to-know-to-prepare-for-polkadot-32d08b929735)的维护版本。_ - -作为一个区块链协议，波卡希望达成两个目标：为所有接入的平行链提供**共享安全性**，并允许所有接入的链使用[XCMP](learn-crosschain)来实现**互操作**。随着 Parity 的 Substrate 和 Cumulus 这类[PDKs](build-pdk)的问世，开发和启动一条新链所需花费的时间已大大减少。以前开发一条新链需要几年，而现在可能只需要几周甚至几天。 - -这份指南将带你了解想要使用 Polkadot 创建你的愿景，你现在能做的事儿。我们将解释平行链和智能合约之间的区别（以及为什么其中一个可能比另一个更适合你的应用程序）。还将列出现在可用的资源和即将发布的资源，以便你可以开始创建应用程序，并为参与今年晚些时候的 Polkadot 主网发布做准备。 - -## 我们处于哪里？ - -- 主网：**Polkadot** -- Canary network: **Kusama** -- 当前主要测试网络：**Westend**(Polkadot的克隆) 和**Rococo** (平行链) -- Substrate:**2.0.0** -- ink!: **3.0** ([文献](https://substrate.dev/docs/en/knowledgebase/smart-contracts)) - -## 你需要了解的内容： - -波卡的主网已经上线。 主要的测试网有两个。 - **Wesend**, 其目标是 运行类似于当前的 波卡的主网。 **Roco**, 专门用于 测试平行链。 此外，还有一个叫做 [Kusama](https://kusama.network) 的价值承载网络，在Polkadot操作之前 会获得功能。 - -波卡[采用丰富的编程语言](learn-implementations)，支持从 Rust 到 JavaScript 等一系列语言。在Substrate框架下当前主要采用Rust进行编程。Substrate 是一套支持开发者便捷地开发完整区块链应用的框架。这套框架通过集成核心要素而得以实现，这些要素有网络协议、共识层、Wasm编译器和运行模块(也称为模块) 等。Cumulus 是一种对 Substrate 的扩展版本，它允许使用Substrate开发的链与波卡连接成为平行链。Substrate 当前发布的标签版本是2.0.0，这一版拥有稳定版API。 - -波卡的原生功能不支持智能合约，但可以通过平行链实现智能合约。用 Substrate 开发的链能够通过使用Wasm合约中的[Contracts](https://github.com/paritytech/substrate/tree/master/frame/contracts)模块和FRAME中的[EVM](https://github.com/paritytech/substrate/tree/master/frame/evm)模块来实现智能合约的功能。contracts 模块能够允许任意用户或者根据具体规则在链上部署 Wasm 编译的合约。为了促进 Wasm 智能合约的开发，Parity 也在开发一种基于Rust用来专门编写智能合约的语言[ink!](https://github.com/paritytech/ink)。 - -波卡主网自2020年5月正式上线。现在开发工具已经出现且趋于稳定，那当下正是尝试用波卡开发你项目的大好时机。但别急！在你一头扎进写代码前，你应该仔细考虑你想开发的去中心化应用的类型，并且了解一些适用于波卡开发者的不同范式。 - -## 平行链，平行线程，智能合约的区别是什么？ - -波卡为你提供了多种不同的开发应用的方式：可以作为现有平行链上部署的智能合约，也可作为你自己的平行链或者平行线程来开发。以上3种开发方式都有各自的优缺点，阅读本章节会帮助你理解三者的区别。 - -平行链是一条独立的链条，它拥有自己的运行逻辑，并且能够从波卡中继链提供的共享安全性和跨链通信机制中收益。平行链具有更高的灵活性和可定制性，但同时也需要更高的成本来开发和维护。 - -和平行链类似，平行线程使得开发者对其应用掌握更偏底层逻辑的控制。两者的主要区别在于使用成本，因为使用平行线程比用平行链更经济。平行线程的使用成本较低是因为它仅在需要时才产生新的区块，而平行链则不同，它每产生一个新的区块都需要保证插入一个中继链的插槽。当开发平行线程时，你所使用的开发工具 (如PDKs) 以及获得的好处和开发平行链是一样的，而不用担心高额的使用成本。 - -在波卡主网上，会有一条或多条充当智能合约平台的平行链。智能合约是一种仅存在一条平行链上，复杂度有限的可执行程序。因为它们仅存在某一条链上，它们可以流畅地和同一条链上的其它智能合约互操作。尽管如此，这些合约一直会受其从属的主链特征的限制。 - -如果你需要对自己的应用的设计和特点拥有更多掌控力，平行链将是更好的选择。记住一点，智能合约可以先当做试验场，时机成熟后可再将其转换为平行链。智能合约平台通常具备类似IDEs一样便捷的工具以促进快速的迭代。此外，还可以针对智能合约创建一个MVP来评估用户兴趣，进而再将其开发为平行链。 - -对于打算从0到1开发一套货币系统以及面面俱到的链的开发者，平行链将赋予他们更多的发挥空间。相较于智能合约平台所呈现的复杂逻辑，平行链显得更为简单且有效。另外，平行链在治理方式上也赋予了更多的灵活性，相较于现行的硬分叉模式，平行链可以实现争议性更少的完整升级。 - -平行链或平行线程具有以下特点： - -- 定制费用架构(例如: 固定费用交易费或按字节)。 -- 定制货币政策用作原生币币和本地经济。 -- 财政库通过状态转变函数获取资助。 -- 一个通过DAO管理的，分配你的链上财政资产的治理模式。 - -![build 1](assets/build-1.png) - -对于因采用智能合约使得成本高昂而难以执行的复杂运行逻辑，平行链为它的构建提供了可能性。然而，与智能合约不同的是，平行链缺少一个完整的gas计量系统，且很容易陷入死循环bug (在智能合约的设计中会避免) 中。这一弱点在Substrate所采用的的权重系统中得到了缓解，但这也给平行链的开发者正确执行基准增加了更多负担。 - -你也可以选择套用平行链、平行线程以及智能合约的组合。如果你的部分逻辑必需包含循环，你可以使用运行原生平行链来处理所有这些复杂逻辑，采用智能合约来调用迭代。如果你需要从预言机上导入链下数据，你可以将平行线程用作每24小时触发一次数据导入的预言机 (如果这些数据对波卡生态里的其他用户也有价值，那么这种机制就最有意义了) 。 - -你很可能已经意识到了你的应用更适用于其中的某一种方式 (或是几种的混合) ，如果你需要快速回顾来消化这些信息，你可以将这张对比图作为备忘： - -![build 2](assets/build-2.png) - -> **注意:** 此的图片不包括平行线程，但正如我们之前提到平行链所有优点同样适用于平行线程。但是它们部署和维护成本较_低_。因此如果他们在上面的图表上有一列，它会在平行链列的"易于部署"和"维护费用"的更改为 `+`。 - -根据你在构建应用时对智能合约或者是平行链的使用选择，本指南现在将划分为两部分。你可以随意地阅读这两个部分，也可只阅读适用于你的部分。 - -- [你想建立平行链或平行线程!](#so-you-want-to-build-a-parachain-or-parathread) -- [你想建立智能合约!](#so-you-want-to-build-a-smart-contract) - -## 所以你想开发平行链或是平行线程…… - -现在你已经决定将开发平行链或者平行线程作为你新项目的正确方式，下面就是决定使用哪个框架了。用于开发平行链或平行线程的框架被称为平行链开发套件 (PDKs) 。现阶段，只有Parity Technologies开发的Substrate和Cumulus可控选择。 - -未来会有很多不同语言编写的PDKs，就像波卡 HOST 有多种[实现](learn-implementations.md)一样。 - -> **立即行动:** 您是否想开发一套全新的平行链开发套件？ Web3 基金会这些团队提供资助，了解更多并且在[W3F 资助页面](https://grants.web3.foundation)申请。 - -### 开始使用 Substrate - -Substrate是用于开发波卡的底层框架。它是为区块链创新者所开发的工具包，提供了开发新链所需的模块。它包含了模块式的运行插件库，你可以用它来开发你的链条逻辑，也可以用它来编写你自己的组件或者共享到社区。 - -开始使用Substrate的最佳方式是先去探索一下[Substrate 基础知识](https://substrate.dev/docs/en/)，这是一个由 Parity Technologies 创建并维护的在线知识库。 - -我们推荐你在知识库那里多逛逛，直到你熟悉了常用的模式为止。一旦你有了扎实的理解，你就可以在提供的教程中挑战自己所学来获得进步。 - -### 如何设定你的平行链 - -当你用Substrate创建了你的链条的运行逻辑后，你就可以将它编译成 Wasm 的可执行文件。这个 Wasm 代码文件包含了你链条的所有状态转换函数，将项目作为平行链或者平行线程部署到波卡上时将用到这份文件。 - -波卡上的验证人将使用这些已提交的 Wasm 代码来验证你的链条或者线程的状态的转变，但做这一验证需要一些额外的基础设施。验证人需要设法保持对最新的状态转换的跟进，因为波卡上节点无需同时成为你的链上的节点。 - -这里正是检验节点发挥作用的地方。校验器是装载你平行链的容器，它承担着至关重要的功能，为你的链条生成新的候选区块，并将它们传给波卡上的验证人以便验证人将其装入中继链。 - -虽然 Substrate 内置了自己的网络层，但不幸的是它只支持独立的链条 (不连接中继链的链条)。不过 Substrate 的扩展版 Cumulus 内置了校验节点，允许基于 Substrate 逻辑的平行链或者平行线程与波卡兼容。 - -#### Cumulus - -建立[Cumulus](build-cumulus)的目标是作为 Substrate 的扩展，使得任意的 Substrate 运行环境都能与波卡兼容。 - -它能处理任何一条需要接入波卡的平行链其上的网络兼容性。包括： - -- 跨链的信息传递。 -- 开箱即用的收集人节点 -- 一套中继链的嵌入式的轻客户端。 -- Polkadot 出块者兼容性。 -- 将 Cumulus 集成到你的 Substrate 链上使得它能以最少修改的方式工作在波卡上，这大概和导入 crate 模块并添加一条命令行一样的轻松。 - -### 如何在 Polkadot 中部署平行链或平行线程。 - -#### 平行链 - -为了将你的平行链添加到波卡网络中，你需要持有平行链插槽。 - -平行链插槽通过公开拍卖发售，相关的发售规则请参考wiki百科中[平行链拍卖](learn-auction)的内容。 - -#### 平行线程 - -平行线程不需要平行链插槽，所以你无需参与蜡烛拍卖。但你可以付费在中继链上注册你的平行线程代码后，然后就能参加按区块进行的拍卖，以使得你的状态转换可以包含到中继链上。 - -更多关于平行线程如何按区块拍卖的信息，请详见[平行线程](learn-parathreads)这页的内容。 - -## 智能合约的创建 - -波卡的中继链本身不支持智能合约，但由于接入波卡的平行链能够支持任意的状态转换，因此这些平行链能够支持智能合约。当平行链接入后，智能合约开发者便可以使用这些选项。如今开发技术已趋于成熟，先在本地链条上启动开发随后将其部署到线上环境的方式成为可能。 - -Substrate有两种方式来支持开箱即用的智能合约开发。一种方式是使用文章[《合约》](https://github.com/paritytech/substrate/tree/master/frame/contracts)中的框架库所提供的模板，第二种方法是使用Substrate的[《EVM模块》](https://github.com/paritytech/substrate/tree/master/frame/evm)来部署EVM作为底层从Solidity或Vyper语言编译过来的字节码，并能够使用以太坊的技术栈。 - -对于以前写过智能合约的开发者而言，他们对于部署EVM的链更为熟练。然而合约模块针对EVM的设计做了一些显著的改善，它们是： - -1. **Wasm**. 此合约模块将WebAssembly用作自己的编译目标，凡是经过Wasm编译的语言都可被用作便携智能合约。不过写智能合约最好是有一个专门的特定领域语言，为此Parity提供了[ink!](#ink)语言。 - -2. **租赁**. 合约必须支付租金或者足额的抵押来证明它存在于链上的正当性。当一份合约没有做上述维护时，可能会产生一种叫做_tombstone_的引用。在某些情况下，如果合约没有达到以上要求，它将会随存储一起被彻底删除。 - -3. **缓存**. 默认情况下合约将被缓存，这意味着合约只需被部署一次，之后你就可以任意地对其做实例化。这种方式有助于最小化链上的存储负载。除此以外，当合约不再被使用且_现存的抵押_耗尽时，代码会从存储中被清除(也叫注销)。 - -或许你可能想着手开始在本地搭建测试环境，开始编写你的智能合约。将一个 Substrate 节点搭配两组智能合约模块中的一组一起使用可以完成上述工作。在完成测试环境的开发后，你需要查阅例如[用于部署智能合约的 Edgeware ](https://contracts.edgewa.re/)这样的项目以将你的项目做上线。 - -### Edgeware - -[Edgeware](https://edgewa.re)是一个附带智能合约模块的项目。Edgeware 是一个针对智能合约做的免许可平台，正被用于进行链上治理的实验。它是目前开发智能合约并部署其上线的开发者的最佳选项。 - -Edgeware 的目标是被用于在连接波卡时被视作平行链从而允许其对智能合约的操作。此时，智能合约能够通过[XCMP](learn-crosschain)实现与其它波卡生态系统部分的交互。 - -关于 Edgeware 的通用文档可以看[这里](https://docs.edgewa.re/)以及[如何使用Edgeware部署智能合约](https://contracts.edgewa.re/)。 - -## Moonbeam - -[Moonbeam](https://moonbeam.network)是另一个被计划用于将平行链部署到波卡上并且支持智能合约的项目。因为 Moonbeam 用到了[Frontier](https://github.com/paritytech/frontier)，它是一个附带了现有以太坊工具的互操作层，将以很小的摩擦支持所有针对 EVM 环境编写的应用程序。 - -跟着这篇[文档](https://docs.moonbeam.network/)试着去部署一个合约到 Moonbeam 上吧。 - -### Ink - -[ink!](https://github.com/paritytech/ink)是一种特定领域语言用于使用 Rust 语言编写智能合约并将其编译为 Wasm 代码。如README中所述，ink 目前尚处于实验阶段，所以勇敢的开发者们也许会体验一段颤栗又可行的开发之旅。一些项目使用ink!做的开发呈现出相当复杂的程度，例如 Plasm 的[Plasma 合约](https://github.com/staketechnologies/Plasm)，所以开发者需要足够熟练才能开始创造有趣的项目。 - -对于感兴趣的开发者，可以通过研究这些写好的[案例](https://github.com/paritytech/ink/tree/master/examples)开始学习编写智能合约。这些案例可以作为编写逻辑更复杂的会被部署到智能合约平行链的指引。 - -ink! 已经为新的智能合约技术栈打下了很多基础，该技术是基于 Wasm 的虚拟机并且能与 Substrate 链兼容。 - -## 智能合约的部署 - -智能合约简单讲就是一段包含链上地址并且能被外部参与者调用的代码。事实上关键的部分在于，你需要提前将代码放到链上以便任何用户都能对它做执行。 - -在链上部署智能合约的方式与您将使用的特定平行链略有不同，但通常你会发送一个特殊交易，该交易将在账本上创建智能合约。你可能需要为初始化逻辑以及合约占用的存储空间支付相关费用。 - -## 为你的智能合约付费 - -每个平台都有不同的支付方式和维护智能合约状态的方式。 - -你可能会看到为智能合约付费的不同模式，包括： - -- 与部署交易关联的交易费用 -- 订阅方式，你可以定期支付到该平台作费用 -- 您需要持有本机令牌阈值才能使用平台的访问令牌模型 (EOS具有类似的) 租金存储。 -- 免费试用或开发者促销 -- 大多数智能合约平台使用某种形式的gas费来限制用户可以执行的操作数量。用户将需要预先支付gas费，不使用的gas费将被退还。 - -您将需要考虑智能合约的存储和复杂性，以确保gas费用的数量保持在合理范围内。无论您使用哪种智能合约平台，存储费用都可能会很昂贵，因此有必要尽可能多的在链外保存数据。您可以考虑使用[IPFS](https://ipfs.io/)或[STORJ](https://storj.io/)来保留数据并仅在链上提交内容地址。 - -### 现在还处于早期 - -波卡上的智能合约仍处于早期阶段，并且直到现在才有了稳定的开发。我们正在积极地生产内容以帮助开发人员的开发加速，并将使用最新资源维护Wiki。您也应该及时跟进以下链接的内容： - -- [Edgeware](https://edgewa.re). -- [Moonbeam](https://moonbeam.network) -- [ink!](https://github.com/paritytech/ink). (请注意Wiki选项卡上的内容。) -- [Substrate 合约模块](https://github.com/paritytech/substrate/tree/master/frame/contracts) - -## 总结 - -本指南为您提供了一个心智模型，并展示了必要的资源来帮助您确定并开始以平行链或智能合约的形式构建项目。即使工具仍在日趋成熟，但尽早开发的优势将是您对项目的熟悉和超前，使您能够创新并创造出真正全新的东西。 - -如果您对Polkadot上的平行链或智能合约抱有有趣的想法，请随时进入[波卡饮水机](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org)进行讨论。开发者或许更感兴趣加入[波卡开发者小酒馆](https://riot.im/app/#/room/#polkadotnoobs:matrix.org)或者[Substrate技术交流群](https://riot.im/app/#/room/#substrate-technical:matrix.org)提问讨论。与往常一样，请关注 [社区频道](community)以便及时跟进Polkadot的最新动态。 - -祝好运！ diff --git a/website/translated_docs/zh-CN/build-deploy-parachains.md b/website/translated_docs/zh-CN/build-deploy-parachains.md deleted file mode 100644 index c3750c2a15de..000000000000 --- a/website/translated_docs/zh-CN/build-deploy-parachains.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -id: build-deploy-parachains -title: 如何部署平行链 -sidebar_label: 如何部署平行链 ---- - -这个指南经已更新到Alexander测试网络 - -## 如何查询平行链 - -前往[Polkadot UI](https://polkadot.js.org/apps/#/explorer)的`Chain State`，选择`parachains`模组和`parachains(）`之后按下`+`按钮，之后会回传有效的平行链。 - -## 如何部署Adder平行链 - -**You will need to have the minimum deposit needed to create a referendum. Currently this minimum is 5 DOT.** - -The `adder` parachain is a simple parachain that will keep a value in storage and add to this value as messages are sent to it. It can be found in the Polkadot repository under the `test-parachains` folder. - -> 由 Adrian Brink 提出的本指南的过时视频版本 [此处](https://www.youtube.com/watch?v=pDqkzvA4C0E)。 当两个指南有分歧时，请参阅此。 - -### 代码生成 - -第一步首先下载Polkadot代码到你本地目录 - -```bash -git clone https://github.com/paritytech/polkadot.git -``` - -确保你经己安装好了Rust - -```bash -curl https://sh.rustup.rs -sSf | sh -sudo apt install make clang pkg-config libssl-dev -rustup update -``` - -现在前往在Polkadot代码库裹的`test-parachains`资料夹并执行生成脚本 - -```bash -cd polkadot/test-parachains -./build.sh -``` - -它会在这个资料夹建立简单`adder`平行链的Wasm可执行文件，它将简单地添加发送到给它的消息。Wasm可执行文件会在`parachains/test/res/adder.wasm`路径，所以确保你能在那找到。 - -你需要生成并运行校对人(Collator)节点从而取得平行链的创世纪状态。 - -前往`test-parachains/adder/collator`资料夹并执行`build`和`run`指令 - -```bash -cargo build -cargo run -[ctrl-c] -``` - -停止校对人节点后你将获得如下结果： - -``` -Starting adder collator with genesis: -Dec: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 27, 77, 3, 221, 140, 1, 241, 4, 145, 67, -207, 156, 76, 129, 126, 75, 22, 127, 29, 27, 131, 229, 198, 240, 241, 13, 137, 186, 30, 123, 206] -Hex: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000011b4d03dd8c01f1049143cf9c4c817e4b167f1d1b83e5c6f0f10d89ba1e7bce -``` - -最重要的资料是Hex字串，这是你的创世纪状态，你需要将它保存用于接下来步骤。 - -### 部署平行链 - -前往[Polkadot UI](https://polkadot.js.org/apps/#/extrinsics)的`Extrinsics`标签，选择你要从中部署parachain的帐户，你需要创建公投从而部署平行链。 - -Click on `democracy` -> `propose(proposal,value)` -> `parachains` -> `registerParachain(id,code,initial_head_data)`. - -In the `id` input enter in the id of the parachain. In the case of the simple adder it will be `100`. In the `code` field click on the page button and then upload the `adder.wasm` binary that was compiled from before. In the `initial_head_data` we will copy and paste the hex data that we got from running the collator node. In the `value` field you will need to input the minimum required value for creating a referendum. At the time of writing this is _5 DOT_ on the Alexander testnet. - -![registering a parachain](assets/parachain/register.png) - -假如你前往到`Democracy`标签，你应该会看到你的提案在议案部分 - -一旦你等待的提案成为公投，你可以投票选择`赞成(Aye)`或`反对(Nay)`，投赞成票使你能够部署平行链。 - -![parachain referendum](assets/parachain/referendum.png) - -当公投结束后，你可以查询你的平行链状态。 - -前往`Chain State`标签之后选择查询`parachains`状态 ，你应该能够看到一些你的平行链资料。 - -![parachain info](assets/parachain/info.png) - -### 与Parachain互动 - -_Coming soon_ diff --git a/website/translated_docs/zh-CN/build-exchange-integration.md b/website/translated_docs/zh-CN/build-exchange-integration.md deleted file mode 100644 index 8b9cf882980e..000000000000 --- a/website/translated_docs/zh-CN/build-exchange-integration.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: build-wallet-integration -title: Wallet integration -sidebar_label: Wallet integration ---- - -``` -+--------------------+ -| | -| Substrate/Polkadot | -| | -+---------+----------+ - | - | - +--------+---------+ - | | - | Client interface | - | | - | +--------------+ | - | | Client DB | | - | +--------------+ | - | | - +--------+---------+ - | - | - +--------+---------+ - | | - | Wallet backend | - | | - +------------------+ -``` - -## 1. 追踪链头 - -通过监察 ` chain_subscribeFinalizedHeads ` RPC (或轮询 ` chain_getFinalizedHead ` RPC 跟踪每个确认了的区块。 - -这将会提供一列最新确认了的区块头。 - -当新哈希到达，你可以使用 ` chain_getBlock ` 把该哈希变成区块。 - -如果新区块不是您处理的最后区块的直接子代，确保迭代它们之间的所有区块。因为 ` chain_getBlock ` 只接受哈希，所以你需要使用 ` chain_getBlockHash` 把那些数字转换成哈希并以这种方式在任意两个最终区块之间迭代。 - -## 2. 解码区块 - -您需要将基本数据的区块解码为有用的字段。 - -所有区块数据是使用基本 SCALE 编码数据，详细资料[在此](https://substrate.dev/docs/en/overview/low-level-data-format)。但是 SCALE 仅提供底层格式，它的字段和内部结构的详细信息可能会在不同链甚至在同一链不同区块之间改变。 - -对于 Polkadot 一开始，区块头格式为五字段结构： - -``` -struct Block: - parent_hash: Hash - number: Compact Number - state_root: Hash - extrinsics_root: Hash - digest: Vec - extrinsics: Vec -``` - -这依赖于 `Hash`，固定长度的32字节值或在 SCALE ` [u8; 32] `。它还依赖` DigestItem ` (枚举类型): - -``` -enum DigestItem: - ChangesTrieRoot: Hash - PreRuntime: ConsensusItem - Consensus: ConsensusItem - Seal: ConsensusItem - Other: Vec -struct ConsensusItem: - id: [u8; 4] - data: Vec -``` - -它还依赖于 `外部交易(Extrinsic)`。*外部交易*是概括了一般和其他(未签名)外部信息的交易。它是种高度可扩展的类型，本身没有固定格式。为了确保将来格式的兼容性，可以通过 RPC `state_getMetadata` 提供外部有关格式的元数据。 - -元数据本身以 SCALE 编码提供，其格式为： - -``` -struct Metadata: - magic: u32 - version: u8 - modules: Vec -struct Module: - name: String - prefix: String - storage: Option Vec - calls: Option Vec - events: Option Vec - constants: Vec -enum StorageHasher: - Blake2_128 - Blake2_256 - Twox128 - Twox256 - Twox64Concat -struct Constant: - name: String - type: Type - value: Vec - documentation: Vec -struct Storage: - name: String - modifier: StorageModifier - type: StorageType - default: Vec - documentation: Vec -enum StorageModifier: - Optional - Default -enum StorageType: - Plain: Type - Map: StorageMapType - DoubleMap: StorageDoubleMapType -struct StorageMapType: - hasher: StorageHasher - key: Type - value: Type - iterable: bool -struct StorageDoubleMapType: - hasher: StorageHasher - first_key: Type - second_key: Type - value: Type - iterable: bool -struct Call: - name: String - arguments: Vec - documentation: Vec -struct CallArg: - name: String - type: Type -struct Event: - name: String - arguments: Vec - documentation: Vec -``` - -` Type `只是` String `，但是字符串的内容将被解释为类型的名称。 - -Substrate 链(实际上 Substrte 链是使用 SRML 构建) 例如 Polkadot 是由不同*模块*组成。每个模块可以想象有点像智能合，有各种交易(或 Substrate 术语，*外部交易*)，数据会持续在交易和区块, 事件和常量参数之间。元数据对所有东西进行编码，允许客户端代码创建特定的交易或解释链上发生了什么，甚至在不同的 Substrate 链之间或同一链不同升级或分叉之间。 - -There are two modules a wallet needs to be aware of: Balances and Indices. Balances allows you to send and receive funds between different accounts. Indices allows you to interpret user addresses. - -## 3. 处理SS58和帐户地址 - -在 Polkadot (和大多数 Substrate 链)中，用户帐户由32字节(256位)的 AccountId 识别。这只是Substrate 使用的 x25519 加密的公钥。 - -但是为了使地址细小，我们为Polkadot上余额大于零的帐户编制索引，并仅使用此*索引*来标识该帐户。该索引比32字节长的 *AccountId* 细小多个，通常仅用几个字节进行编码 。 - -Where Bitcoin has the Check58 address format and Ethereum used the `0x...` hex format, Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Check58 format such as a version prefix, a hash-based checksum suffix and base-58 encoding. Further information on it can be found here [TODO]. Of the many supported "version codes", only one particular family of subformats is especially important for Polkadot support in wallets. - -SS58 格式是版本前缀(对于Polkadot 为一个字节，并总是为` 0x00 `，而 Kusama 为` 0x02 `)的base-58编码(使用与比特币相同的字母)，后跟一个或多个有效载荷字节，并以一个或多个校验字节结尾: - -`0x00 ` - -**地址的长度没有固定长度。**根据长度，有效负载可能具有不同的含义，并且有效负载与校验和字节的比率可能不同。下面是一个表，用于参考如何解释特定大小的地址: - -| Total bytes | Version bytes | Payload bytes | Checksum bytes | Payload type | -| ----------- | ------------- | ------------- | -------------- | ------------ | -| 3 | 1 | 1 | 1 | Index | -| 4 | 1 | 2 | 1 | Index | -| 6 | 1 | 4 | 1 | Index | -| 35 | 1 | 32 | 2 | AccountId | - - -注意: 此表仅包含最常见的组合。SS58 包括几个更不常见的。为了达到最大的兼容性，然后根据完整的 SS58 规范实现。 - -一旦解码为字段，则应检查版本为` 0x00 `。然后应验证 checksum 是否等于 SS58 数据的Blake2-256 哈希的开头，不包括 checksum 本身。如果 checksum 是一个字节，则检查哈希的第一个字节。如果是两个字节，则检查哈希的前两个字节。 - -最后在使用索引地址的情况下，索引应解码为 32 字节的帐户标识符。这可以通过检查 Indices 模块的存储来实现。 - -### 查找索引 - -查找索引有点麻烦，因为涉及查找存储，解码和解释。 - -我们关心的特定存储是` Indices `模块中的` EnumSet `。通过` state_getStorage ` RPC 检查存储，必须向其提供密钥。该键对整个"查询"进行编码。通常应咨询元数据如何生成密钥。为此我们首先找到名称为` Indices `的` 模块`，然后在` Storage 模块中` `storage `字段中找到，名称为` EnumSet `。此项包含我们构造和解释查询所需的所有信息。 - -对于 Polkadot 我们发现该项目的`type`为`Map`，其关联值为` StorageMapType `，其`hasher`为 ` Blake2_256 `，其`key`是` T:: AccountIndex `(对于 Polkadot 来说是` u32 `)，并且其`value`为`Vec `。 - -这意味着如果我们的索引由 SCALE 编码为` u32 `为``，那么我们的存储键是通过字符串` Indices EnumSet `的 Blake2 256 哈希确定。 实际上帐户是按64个批次存储的，因此要查找特定的索引，我们不按帐户索引查询，而是按其批次的索引查询，这只是意味着我们首先需要在编码之前将索引除以64。 - -这会返回 SCALE-encoded `Vec` (`T::AccountId` 可能在 SCALE 定义为 `[u8; 32]` 或固定32字节数量) 包含我们感兴趣帐户的批次。要获取` AccountId `项，只需从向量中获取第` index％64 `项。如果该项目不存在（或您得到一个空的存储)，则帐户索引无效。 - -否则您将拥有您的帐户 ID，并且可以将其及其标识和显示余额给用户。 - -## 4. 处理余额 - -在 Polkadot 中，帳戶结余可以在`Balances`模块内使用元数据的方式查找帐户索引查询被锁上的结余。在这种情况下我们需要查询存储中的` FreeBalance `。这里` StorageMapType `很相似，不同之处在于` key `的类型为` T::AccountId `(32字节)和` value `是` BalanceOf `，就 Polkadot 而言，它是` u128 `(128位值)。哈希函数与 Blake2 256 相同，因此完整的存储密钥将由字符串` Balances FreeBalance `的 Blake2 256 哈希给出，其中``是32字节的` AccountId `。 - -注意: ` FreeBalance `是该帐户控制的总余额，但没有考虑暂时锁定的部分，例如抵押中，投票或归属而锁定的部分。这些信息可以从链中查询，但不在本文档的范围之内。 - -DOT 代币结余将编码为12个数位。要获得 DOT 的实际数量，您需要将128位余额除以1,000,000,000,000(10 ** 12)。 为了完整起见，Polkadot 的货币面额为: - -| 余额值 | 名称 | -| --- | -- | -| | | - 1 | Planck 10 - -**3 | Point 10**6 | Microdot (UDOT) 10**9 | Millidot (MDOT) 10**12 | Dot (DOT) 10**15 | Blob - -### 转移余额 - -要转移余额，必须准备和发送交易。在准备交易时，有两个关键部分: 一般交易部分和模块特定的交易`功能`部分通常需要来自链元数据的信息。 - -通常 Polkadot 的交易在 SCALE 中编码为 *signed*`Extrinsics`。为了便于之后兼容，外在进行双编码，因此初始编码将传回 SCALE（作为`Vec`）并输出使用的。这样做的效果是向它添加一个小长度前缀，使无法解释事务数据本身的系统仍然能够将它们传递为不透明的数据包。 - -The SCALE format is given by `Extrinsic`: - -``` -struct Extrinsic: - tx: Option TransactionInfo - function: Function -struct TransactionInfo: - sender: Address - sig: [u8; 64] - era: Era - nonce: Compact Nonce - tip: Compact Balance -struct TransactionPayload: - function: Function - era: Era - nonce: Nonce - tip: Balance - checkpoint_hash: Hash -``` - -对于交易，使用可选的` tx `。` Address `类型是经过特殊编码的 SCALE 类型，允许将帐户显示为帐户索引或32字节帐户 ID，以较方便的方式显示。格式在 SCALE [TODO] 中进行了说明。假设您希望提供一个32字节的帐户 ID，则只需在` 0xff `字节前面添加前缀，就可以将其表示为` Address `。 - -` sig `字段必须包含 SCALE 编码的` SigPayload `的25519系列签名。 用于对负载进行签名的密钥必须与` sender `帐户相对应。 建议使用 Schnorr / Ristretto 25519("sr25519")签名格式。 - -Era is a one or two byte item, again with a special SCALE encoding format and it encodes the period (as a range of blocks) for which this transaction should be considered valid. It is an important safeguard against certain transaction replay attacks and should generally be used, however a simple wallet implementation that has no plans to reuse accounts after they become empty could ignore it. To ignore it and make the transaction "immortal", use an encoded `Era` of just one byte: `0x00`. However, if an account is removed from storage and a user re-funds an address, then previous immortal transactions could be replayed. Therefore, you may want to prevent account reaping and use mortal transactions to be safe. - -随机数到目前为止，由发送人帐户发送的交易数量，就像在以太坊中一样。 它是` Nonce `类型，在逻辑上等效于` u64 `。 为了获得正确的值，必须查询适当的存储，就像查询帐户余额时一样。 在这种情况下，它是` System `模块的` AccountNonce `。 因此所需的存储密钥是字符串` System AccountNonce`的 Blake2 256 哈希，其中` `是32字节的` AccountId `。 它将返回一个` Nonce `，可以在此处对其进行解码和使用。 - -注意: 从存储中检索的 nonce 没考虑*待处理*交易。如果您从一个帐户发送多个交易，则需要手动递增和跟踪此值。 - -` tip `是` Balance `(在逻辑上等同于 SCALE 中的` u128 `类型)，它表示在繁忙的时候，为优先包含创建区块者支付一些额外费用。通常为零。 - -` checkpoint_hash `是 "区块检查点"的哈希，也就是说` era `字段指定的纪元的第一个区块。 如果只是使交易"immortal"，则应使用区块链的创始哈希。 这可以通过RPC ` chain_getBlockHash(0)`确定。 - -最后 ` function `是` Function `类型(在某些情况下有时称为` Call `或` Proposal `)，它描述了应该采取什么行动。它必须根据元数据构造。 在这种情况下，我们希望交易在` Balances `模块中实现` transfer `功能，以将余额从一个帐户转移到另一个帐户。 在模块列表中检查余额模块本身的索引很重要。 在这种情况下，它是第六项或索引5。还需要检查元数据中余额` Module `的` calls `字段，并确定其中的索引转移功能。它在列表中排在第一位，因此索引为0。 - -最后我们需要知道该函数需要哪些参数才能创建其余的交易。这在我们刚刚找到的元数据的` Call `项中提供。预期有两个参数： -- `dest` with a type of `::Source` (aka `Address`); and -- `value` with a type of `Compact` (aka `Compact Balance`). - -在这种情况下 `函数` * * (即专门针对并且仅适用于Polkadot 上的余额转帐交易) 将是以下结构： - -``` -struct BalanceTransferFunction: - module_index: u8 - call_index: u8 - dest: Address - value: Compact Balance -``` - -其中` module_index `是` 0x05 `，而` call_index `是` 0x00 `。` dest `与` sender `类似，可以作为帐户索引或32字节帐户ID提供，以较方便为准。如果提供帐户ID，则只需在其前面加上字节` 0xff `即可将其成为地址。 - -转帐的金额(不包括付给系统的任何费用)由` value `给出，并且必须是 SCALE compact 编码的数字。 - -### 提交和检查交易 - -一旦交易准备好，您将需要将其提交以包含在链中，并最终想要验证它是否真的包含在链中。 - -可以通过两种方式完成: 一种是使用简单 RPC ` author_submitExtrinsic `，它将回传交易的哈希值。 提交后您可以继续手动检查交易是否在已确认的区块内(因为您都已经跟踪已确认的区块头)，直到看到您提交的交易为止，此时您知道交易已在链中。 - -另一种方法是使用 pub/sub RPC ` author_submitAndWatchExtrinsic `。您同样提供 SCALE 编码的交易，但是在这里您会收到 subscription ID。 当交易被验证，广播并通过单独推送的消息包含在链中时，将通过 RPC 通知您。 - -## 总结 - -文章到此结束。在这里，您应该知道如何与 Substrate/Polkadot 节点进行交互，以便跟踪最终确定的链头、解码 SS58 地址、检查账户信息(如 balances & nonces) 以及构建、提交和跟踪交易。您还了解了 SCALE 编码器、Substrate 元数据系统以及如何构建面向未来的通用 Substrate 系统。 - -如果你有任何问题，请在 [Substrate Technical](https://riot.im/app/#/room/#substrate-technical:matrix.org) 问。 - -_最初版本发布在[此处](https://hackmd.io/@gavwood/r1jTRX2Zr)。_ diff --git a/website/translated_docs/zh-CN/build-extrinsic-format.md b/website/translated_docs/zh-CN/build-extrinsic-format.md deleted file mode 100644 index 63cc889ddac9..000000000000 --- a/website/translated_docs/zh-CN/build-extrinsic-format.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: build-extrinsic-format -title: Polkadot Extrinsic Format aka Transaction Format -sidebar_label: Polkadot Extrinsic Format aka Transaction Format ---- - -## 原格式 - -**原外部函数格**式可参考如下： - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ] -``` - -## 现格式 - -Polkadot外部函数格式是： - -``` -[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ] -``` - -*original*部分指的是原外部函数格式中的下面部分内容： - -``` -[ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] -``` - -新地址类型的特定格式是5种子格式中的一种，第一个字节不同。 - -- `0xff, 32-byte account id` -- `0xfe, 8-byte account index` -- `0xfd, 4-byte account index` -- `0xfc, 2-byte account index` -- `[0xf0...0xfb] (invalid, reserved for future use)` -- `[0x00...0xef] 1-byte account index (less than 0xf0)` - -帐户索引变量要小得多，但需要在状态下查找。若要避免索引更改帐户时的交易重播攻击，签名的时候不应以第一个字段作为索引，而应以第一个字段作为帐户ID。因此，一旦索引用于查找不同的ID，就会使以前的所有签名失效。 - -包括发送器字段在内，所有在旧格式中表示账户ID（32字节）的调用/提议（私下调用）字段的参数现在都是地址（1/3/5/9/33字节）。 - -## 来源 - -[Substrate #195](https://github.com/paritytech/substrate/pull/195) diff --git a/website/translated_docs/zh-CN/build-hackathon.md b/website/translated_docs/zh-CN/build-hackathon.md deleted file mode 100644 index eb4571e496cb..000000000000 --- a/website/translated_docs/zh-CN/build-hackathon.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: build-hackathon -title: 黑客马拉松 -sidebar_label: 黑客马拉松 ---- - -As one of our objectives in the Web3 Foundation is promoting the [Web3 technology stack](http://wiki.web3.foundation/en/latest/tech_stack/tech_stack_overview/), we would like to support any individual or team who wants to organize a hackathon that gets more developers to understand Polkadot and Substrate in your city or online. - -我们不仅为您提供技术资源，而且还可以安排我们团队的人来做具体的技术工作坊和讲解介绍我们的技术，从而帮助参与者可以更快地开始hacking。 - -## 一些想法 - -- NFT -- Bonded Tokens -- 具有不同類型投票 & 民主機制的新治理模块 -- 升级 TCR 模块 -- 整合 IPFS -- 分布式身份认证方案 -- 预言机模块 -- 实现通用状态通道 / Plasma 链 -- 去中心化交易所 -- 验证人监视工具 -- 跨不同平行链的 dApp - -## 为什么要举办黑客马拉松？ - -- 热爱实现 Web3 的愿景 -- 学习前沿技术 -- 相信 Web3 技术栈适合开发人员构建他们的应用程序 -- 喜欢建立联系 - -## 黑客马拉松与研讨会有何不同？ - -黑客马拉松是希望参与者在短时间内（几小时到一天）实现出原型并展示他们的想法。研讨会的目的是使开发人员熟悉该工具，并了解更多当前有哪些资源可用以及如何使用它们。 - -## 如何在您的城市里举办黑客马拉松？ - -1. 提交您的申请（即将到来） -2. 评论 -3. 决定 -4. 跟进 - -## 我们如何为您提供协助 - -- 提供技术资源 / 材料。 -- 找场地。 -- 确保黑客马拉松顺利举行 - -## Upcoming Hackathons - -- [Hello World! by Polkadot](https://gitcoin.co/hackathon/polkadot/onboard) - A collaborative hackathon celebrating the integration of Polkadot and Kusama into the Gitcoin platform. Has many sets of smaller challenges that will reward in either DOT or KSM. Open from 15 October - 12 November 2020. - -## Past Hackathons - -- [Hackusama](https://hackusama.devpost.com/) - A 7-week online hackathon being launched for developers to "Build a Blockchain" or submit your wildest tools, visualizations, and ideas to the "Open Hack" category. Many high quality submissions were received. - -## 资源 - -- [Substrate Knowledge Base](https://substrate.dev/docs/en/) - -## 支持 / 联系 - -If you have any questions regarding organizing a hackathon, please free feel to contact us by [email](mailto:events@web3.foundation) or ask us via [Riot](https://riot.im/app/#/room/#polkadot-watercooler:matrix.org) chat. diff --git a/website/translated_docs/zh-CN/build-index.md b/website/translated_docs/zh-CN/build-index.md deleted file mode 100644 index 920a719a40e8..000000000000 --- a/website/translated_docs/zh-CN/build-index.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: build-index -title: 开发者专页 -sidebar_label: 开发者专页 ---- - -欢迎访问Polkadot维基网站的构建者部份。 - -Here you will be able to find the most up-to-date information on the status of the development tools in the Polkadot ecosystem. We are always adding new tools and frameworks as we learn about them so if you are working on something that should be included please reach out to us on [Element](https://app.element.io/#/room/#polkadot-watercooler:matrix.org). - -Wiki 的这个部分分为以下: - -## 主页 - -- [入门指南](build-build-with-polkadot) - 有关您的项目应选择平行链，平行线程或智能合约的高级概述，以及现在有哪些资源可以使用。 -- [Parachain Development Kits](build-pdk) - PDKs are toolkits for building parachains and parathreads. -- [Smart Contracts](build-smart-contracts) - Smart contracts are fragments of custom logic that can be deployed to a live chain. - -## 集成指南 - -本部分适用于希望学习如何将 Polkadot 集成到其系统中的服务提供商，例如钱包或节点运营商。 - -- [Integration Initiation](build-integration) - The guide to the guide. -- [Polkadot Protocol Information](build-protocol-info) - General information and F.A.Q.s about the Polkadot protocol, e.g. address formats. -- [Node Management](build-node-management) - A short overview of the Parity Polkadot client and the most relevant options/flags for infrastructure providers. -- [Node Interaction](build-node-interaction) - Learn how to interact with your node via RPC. -- [Transaction Construction and Signing](build-transaction-construction) - Learn the transaction format for Polkadot and how to construct and sign transactions offline. - -## 工具 - -- [工具](build-tools-index)-维护的工具。 -- [Subkey](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) - Command line utility for generating and inspecting key pairs. -- [JS tools](https://github.com/polkadot-js/tools) - TypeScript tools for offline signing of transactions, RPC calls, and more. - -## 资源 - -- [例子](build-examples-index) - 来自社区的项目 - 查看其他人开发中的项目. - -### Grants - -- [Grants](grants) - Web3基金会提供赠款的所有 Polkadot 相关的项目列表。 - -### PSPs - -Polkadot 标准建议 (PSP) 是 Polkadot 生态系统的标准。 - -- [ PSP GitHub 库](https://github.com/w3f/PSPs)-阅读，创建或讨论标准和提案。 - -### 黑客马拉松 - -- [举办骇客松的资源](build-hackathon) diff --git a/website/translated_docs/zh-CN/build-networks.md b/website/translated_docs/zh-CN/build-networks.md deleted file mode 100644 index 6aac9cf0035a..000000000000 --- a/website/translated_docs/zh-CN/build-networks.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -id: build-networks -title: Networks -sidebar_label: Networks ---- - -您可以通过下面的代码来连接到不同网络。 - -## 开发 - -在以下 `路径` 安装 `Polkadot` 和 Polkadot 二进制文件： - -```bash -cargo install --git https://github.com/paritytech/polkadot.git polkadot -``` - -通过在终端上运行，您可以在机器上跑简单的单节点开发网络： - -```bash -polkadot --dev -``` - -您可以复制和创建以下网站： - -## Krumme Lanke - -http://github.com/paritytech/polka-ui 和 http://github.com/paritytech/polkadot-ui or 或前往到 https://polkadot.js.org/apps. - -Krumme Lanke 是一个在 Poc-2 开发期间使用的测试网络。请在以下路径安装 Polkadot PoC-2 和 `Polkadot 二进制` 文件： - -```bash -cargo install --git https://github.com/paritytech/substrate.git --branch v0.2 polkadot -``` - -通过默认运行以下代码连接到全球 "Krumme Lanke" 测试网： - -```bash -polkadot -``` - -## Alexander（Poc-4） - -Alexander 是一个在 PoC-3 和 PoC-4 开发期间使用的测试网络。 - -请在以下 `路径` 安装 Polkadot Poc-4 和 `polkadot` 二进制文件： - -```bash -cargo install --git https://github.com/paritytech/polkadot.git --branch v0.4 polkadot -``` - -通过默认运行以下代码来连接到全球 "Alexander测试网:" - -```bash -Polkadot -``` - -## 本地双节点测试网 - -如果您想要在本地看到多节点共识算法操作，那么您可以创建一个本地测试网。您需要开两个终端，其中一个运行以下代码： - -```bash -polkadot --chain=local --validator --key Alice -d /tmp/alice -``` - -另一个运行以下代码： - -```bash -polkadot --chain=local --validator --key Bob -d /tmp/bob --port 30334 --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE' -``` - -请确保将第一个终端的输出结果中的节点ID替换为`ALICE_BOOTNODE_ID_HERE` 。 diff --git a/website/translated_docs/zh-CN/build-pdk.md b/website/translated_docs/zh-CN/build-pdk.md deleted file mode 100644 index 02ab8f81c690..000000000000 --- a/website/translated_docs/zh-CN/build-pdk.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: build-pdk -title: 平行链开发套件 (PDKs) -sidebar_label: 平行链开发套件 (PDKs) ---- - -平行链开发工具包(PDK)是一套便于开发者创建兼容[ Polkadot ](learn-parachains)平行链的工具。 - -## 为什么要创建平行链？ - -在深入了解什么是 PDK 以及它如何使用之前，让我们回顾一下*为什么*开发者希望创建平行链并将其连接到 Polkadot 中。 - -平行链拥有两个关键的附加功能，是开发者创建独立链的不二选择： - -- *共享安全性* - 去除了自举链的验证人集的必要性。 -- *跨链通信* - 使得平行链之间通过 ICMP 协议交互操作。 - -Parachains can [lease the security](learn-security) of the Polkadot network by bonding [DOT](learn-DOT) for a parachain slot. This means that the social costs of building a community around your project and convincing validators to participate in your network security are reduced. It is anticipated that Polkadot will have strong security, and decentralized application projects wishing to benefit from this security would want to become a parachain. For more information on the mechanic of leasing a parachain slot through a candle auction see [here](learn-auction). - -所有去中心化的应用程序或链，若想要向其它已连接到 Polkadot 的平行链去信任地传递信息，都会希望成为平行链。主权链之间的互操作性需借助约束和复杂的协议才可广泛实现。在 Polkadot 中，一旦将应用程序构建为平行链，便会立即获得这一特性。[XCMP 协议](learn-crosschain)将传递平行链之间的信息，实现其互操作性。此外，连接其它链的转接桥(例如比特币或以太坊)纷纷推出，平行链也可以与它们进行交互。 - -## 什么是 PDK？ - -如上所述，PDK 是一套便于开发者创建兼容 Polkadot 的平行链的工具。实际上，这意味着 PDK 将包含以下几个关键成分： - -- _状态转变函数(State transition function)_ - 把你应用程序数据状态状变成另一个状态。 -- *收集人节点 (Collator node)* - Polkadot 网络的另一类点对点节点，专门负责平行链。 - -The state transition function (STF) can be any abstract way for an application to go from one state to another state. The only constraint that Polkadot places on this STF is that it must be easily verifiable -- usually though what we call a _witness_ or _proof_. It must be so because the Relay Chain validators will need to check that each state it receives from the collator node is correct without actually running through the entire computation. Some examples of these proofs include the Proof-of-Validity blocks or zk-SNARKs, which require less computational resources to verify than they do to generate. The verification asymmetry in proof generation of the STF is one of the integral insights that allows Polkadot to scale while keeping high security guarantees. - -A collator node is one of the types of network maintainers in the Polkadot protocol. They are responsible for **keeping availability** of the state of the parachain and the new states returned from iteration of the state transition function. They must remain online in order to keep track of the state and also of the XCMP messages that it will route between itself and other parachains. Collator nodes are responsible for passing the succinct proofs to the Relay Chain validators, and tracking the latest blocks from the Relay Chain. In essence, a collator node also acts as a light client for the Polkadot Relay Chain. For more on collator nodes see [here](learn-collator). - -## 目前存在哪些 PDK？ - -目前唯一存在的 PDK 是 Parity [Substrate](https://github.com/paritytech/substrate) & [Cumulus](https://github.com/paritytech/cumulus)。Substrate 作为区块链框架，提供了区块链的基本构建区块（例如网络层、共识和 Wasm 解释器），以及创建运行时的直观方法。Substrate 旨在简化创建新链，但它并不直接支持 Polkadot 兼容性。因此 Cumulus 附加库将包含所有 Polkadot 兼容性代码。Cumulus 目前还在开发之中，计划做到只通过导入 crates 以及添加一行代码便把你的 Substrate 链变成平行链。 - -Substrate 和 Cumulus 通过区块链格式的抽象化中提供 PDK，但平行链实际上甚至不必是区块链。例如平行链只需满足上文列出的两个要求：_状态转换函数_和_收集人节点_。其它一切功能取决于 PDK 的实现者。 - -One interesting idea for a PDK that would be nice to see is to have a [roll-up](https://ethresear.ch/t/roll-up-roll-back-snark-side-chain-17000-tps/3675) kit that allowed developers to create snark-based parachains. If we review the roll-up write-up, we see that the system uses two roles: users that update **state** and an operator that **aggregates the state updates** into a single on-chain update. It should be straightforward to see how we can translate this to the parachain terms. The state transition function for a roll-up-like parachain would be updating the state (in practice, most likely a merkle tree, which would be easily verifiable) from the user inputs. The operator would act as the collator node, which would aggregate the state and create the zk-SNARK proof that it would hand to the Relay Chain validators for verification. - -## 创建 PDK - -如果您或您的团队对开发 PDK 感兴趣，请随时在 [W3F 合作库](https://github.com/w3f/Web3-collaboration) 上创建 issue。 Web3 基金会可以为这类工作提供资助。 diff --git a/website/translated_docs/zh-CN/build-protocol-info.md b/website/translated_docs/zh-CN/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/zh-CN/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/zh-CN/build-rust-style-guide.md b/website/translated_docs/zh-CN/build-rust-style-guide.md deleted file mode 100644 index ade8df32458b..000000000000 --- a/website/translated_docs/zh-CN/build-rust-style-guide.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -id: build-rust-style-guide -title: Style Guide for Rust in Polkadot -sidebar_label: Style Guide for Rust in Polkadot ---- - -- 使用制表符缩进 -- 只有在特殊情况下，每行才应该超过80个字符但当然不能超过120个。为此，制表符应为4个字符宽度。 -- 只有在特殊情况下，缩排格数才应该大于5，但当然不能大于8。大于5时，可以考虑使用let或辅助函数来删除复杂的内联表达式。 -- 切勿在非空格字符之前的行中输入空格 -- 下一行与原始行之间只有一个缩进。 -```rust -fn calculation(some_long_variable_a: i8, some_long_variable_b: i8) -bool { - let x = some_long_variable_a * some_long_variable_b - - some_long_variable_b / some_long_variable_a - + sqrt(some_long_variable_a) - sqrt(some_long_variable_b); - x 10 -} -``` -- 应在左括号后输入缩进格数，但应折叠为实际使用的最小格数： -```rust -fn calculate( - some_long_variable_a: f32, - some_long_variable_b: f32, - some_long_variable_c: f32, -) -f32 { - (-some_long_variable_b + sqrt( - // 这里有两个左括号，但因为我们把对应的两个右括号放在同一行，所以只需要缩进一级 - some_long_variable_b * some_long_variable_b - - 4 * some_long_variable_a * some_long_variable_c - // 两个括号都在这里结束了，所以回到最初的缩进级别 - )) / (2 * some_long_variable_a) -} -``` -- `where`及其项需 -- 过长的参数列表或函数调用无法在一行中使用，需缩进为与代码区块类似。一旦某参数被以这种方式缩进，那么其它所有参数都应该进行相同操作。此外，运行参数列表也适用于基础函数调用的单行运行。 - -```rust -// OK -fn foo( - really_long_parameter_name_1: SomeLongTypeName, - really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, - shrt_nm_2: u8, -) { - ... -} - -// NOT OK -fn foo(really_long_parameter_name_1: SomeLongTypeName, really_long_parameter_name_2: SomeLongTypeName, - shrt_nm_1: u8, shrt_nm_2: u8) { - ... -} - -``` - -```rust -{ - // 符合语句（不仅有函数调用，还有一个let声明），采用完整结构 - let (a, b) = bar( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // 很长，但仅是函数调用 - waz( - really_long_parameter_name_1, - really_long_parameter_name_2, - shrt_nm_1, - shrt_nm_2, - ); - - // 短的函数调用 - baz(a, b); -} -``` - -- 合理情况下，逗号分隔的多行集合永远以“ ,”结尾： -```rust -struct Point --account --ws [param1] [...] [paramX] -``` - -签名: - -```bash -yarn run:signer sign --account --seed --type -``` - -例如我们从 `121X5bEgTZcGQx5NZjwuTjqkoiG8B2wEAvrUFjuw24ZGZf2` 发送0.5 DOT 到 `15vrtLsCQF3qRYUcaEeh4JwepolNJkpsrqojqnZPc2y` - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -这将返回 payload 签名和等待签名。 使用这个 payload 并使用 你的正常签名环境 (例如 airgapped 電腦、 VM 等) 签 payload： - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -保存输出并将其带到您要广播的电脑，输入 `submit`'s 签名字段并发送交易(或如果使用 `sendOffline`，则只是退回 serialized 的交易)。 - -## Tx Wrapper - -如果您不想使用 CLI 进行签名操作，Parity 提供了一个称为[TxWrapper](https://github.com/paritytech/txwrapper)的SDK，它可以离线生成和签名交易。请参阅[示例](https://github.com/paritytech/txwrapper/tree/master/examples)以获取指南。 - -**导入私钥:** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**从公钥中获取地址** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**离线构建交易** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**构建签名的 payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**对已签名的交易做序列化** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**解析 payload 的类型** - -您可能需要对 payload 进行解码，以在提交之前验证其内容。 - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**检查一笔交易的哈希值** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## 提交已签名的 Payload - -有几种提交签名的 payload 的方法： - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc)和`author_submitExtrinsic`或者 `author_submitAndWatchExtrinsic`，后者将使您订阅事件，并在交易得到验证且上链时得到事件的通知。 - -## 注意 - -在示例中使用的一些地址，请参阅[Subkey 文档](https://substrate.dev/docs/en/knowledgebase/integrate/subkey)。 - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/zh-CN/claims.md b/website/translated_docs/zh-CN/claims.md deleted file mode 100644 index 0fc3246e5da3..000000000000 --- a/website/translated_docs/zh-CN/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot 申领 -sidebar_label: 认领 ---- - -如果您在之前的销售中购买了 DOT，则需要通过以下程序认领 DOT 代币。对于那些已在较早创世块之前提交了认领交易到以太坊上的 Claims 合约，那么您应该已经知道您的 Polkadot 地址。您仍然需要提交一个不用交易费的 _attest_ 交易，该交易用于同意您的分配条款和条件。您必须首先声明或证明，之后 DOT 才能在您的帐户中使用。 - -本指南将带领您完成认领或证明声明的步骤。 - -如果您是首次认领 DOT，请阅读下面[认领](#making-a-claim)的部分继续。如果您在创世块之前已经认领，请前往[证明声明](#attesting-to-a-statement)部分。 - -> 了解更多如何认领您的DOT，请查看我们的攻略 [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22)和视频 [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## 认领 - -如果您在创世块之前期间没有认领，那么您就可以在创世块后的任何时间认领。认领没有时间限制，因此任何时候您都可以这样做。 - -> 注意: 申领时，您还需验证您的DOT代币分配协议。申领及验证将在一个同交易里完成，从用户的角度来看，这已是极度简化的流程。 - -### 您将需要什么 - -- 持有 DOT 代币的以太坊账户 -- MyCrypto 钱包 -- Polkadot 帐户 - -您应该已经拥有以太坊账户，该账户持有 Polkadot 的 DOT 代币。 您需要访问该帐户才能进行签名。 - -[ MyCrypto ][] 是款多功能钱包，可为您的以太坊账户提供多种存储方式。请点击链接转到其下载页面，并确保您下载了适用于您操作系统的最新版本。 这很重要，因为最新版本将有最新的安全补丁程序。 - -> **注意**: 在本地下载和使用 MyCrypto 应用程序更加安全。 您可以在其[releases page][mycrypto]上找到桌面应用程序的最新版本。 - -您需要一个 Polkadot 帐户作为获取申领的DOT的账户。请根据\[创建账户\]\[\] 页面上的说明生成新的 Polkadot 帐户。 - -#### 使用 MyCrypto 认领您的 DOT - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -一旦下载了 MyCrypto 并使其在本地运行(为了获得最大的安全性，我们建议使用完全离线的电脑)，您可以先访问 Polkadot-JS Apps 上的 Claims 程序。选择您要申请认领 DOT 的帐户，然后点蓝色的 "Continue" 按钮继续。您的屏幕应如下图所示: - -![claim-1](assets/new-claims/claim-1.jpg) - -现在您将需要提供与您将认领 DOT 代币的以太坊地址。在框中输入以太坊地址，然后点击 "Continue"。 - -![claim-2](assets/new-claims/claim-2.jpg) - -接下来，屏幕应如下图所示。 - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -句子后面的十六进制编码字符串: "Pay DOTs to the Polkadot account:" 是您 Polkadot 帐户的十六进制编码公钥，去除 `0x` 前缀。 - -下一步是转到 MyCrypto 程序，然后点击 "Sign & Verify Message" 选项。 - -![claim-3](assets/new-claims/claim-3.png) - -这将提示您选择一种解锁钱包的方法。 - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -当您点击 "Sign Message" 时，您将获得类似于以下 JSON 的内容: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -将会出现一个绿色框，告诉您要认领的金额，并带有 "Claim" 按钮以提出认领。 点击 "Claim" 按钮，然后按 "Submit (no signature)" 以完成认领。 - -![claim-9](assets/new-claims/claim-9.jpg) - -若申领成功，那么您将看到提示成功的消息，同时您的DOT将会出现在您在申领时提交的账户中。 - -#### 确认您的认领 - -当您在链上申领 DOT 后，Polkadot UI 上应即时更新了您的余额。 - -遇到麻烦? 在 DOT [Claims Support]()渠道寻求帮助。 - -![claim-10](assets/new-claims/claim-10.jpg) - -恭喜，您现在已经完成了 DOT 申领及签名的流程。 - -### 第三方认领程序 - -**我们不建议使用其它第三方应用程序或流程来进行您DOT的申领或获取。** - -使用第三方程序进行申领可能会导致代币分配失败，因此我们不建议您使用任何第三方应用程序这样做。按照我们的申领流程，手动指定您的交易数据，是确保您将收到DOT代币的唯一方法。 - -## 证明声明 - -若您已经在创世块前提出申领，您仍然需要使用您的 Polkadot 帐户签署一份协议。 - -## 使用 Polkadot-JS App UI - -### 您将需要什么 - -- 您的 Polkadot 帐户已在 Polkadot-JS Apps UI 上解锁。 - -您将通过您的 Polkadot 帐户发起一次无交易费用的交易。完成交易后，您的代币将出现在您的账户中。 - -### 前往 Polkadot-JS 程序 - -继续使用 [polkadot-js Apps][claims app]。您需要授予应用程序对您账户的访问权限。一种方法是前往到 Accounts 页面并 "创建" 新帐户，将生成的种子或助记词替换为您的帐户的seed或助记词。另一种方法是使用 Polkadot-JS 扩展程序，然后在其输入您的seed或助记词，这通常比直接在程序页面中输入更安全。 - -### 提交证明 - -当输入帐户后，您应该会在左侧导航栏的 "Claim Tokens" 标签上看到红色的提示。 - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -点击 "Claims Tokens" 选项，您将在页面顶部看到一个大型通知，告诉您需要签署验证声明。 - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -该通知将显示您已在 Polkadot-JS 中加载并需要签名的多个 Polkadot 地址。使用下拉选择来选择已申领 Polkadot 的帐户。如果您没有看到或收到通知，请仔细检查该帐户是否已加载到 Polkadot-JS 中，并且在创世块前已经进行申领。与往常一样，请随时在 [Claims Support]() 中寻求帮助。 - -点击 "Continue"，您将看到右侧的绿弹框。 - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -点击 "I Agree"，然后点击 "Sign and Submit" 提交您无交易费用的验证交易。当交易打包入区块中后，您将看到绿色的成功弹框出现在右上角，同时 DOT 将出现在您的帐户中。 - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## 使用Parity Signer - -### 您需要准备什么 - -- Parity Signer -- 已链接到 Polkadot-JS Apps UI 的 Polkadot 帐户 - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### 前往 Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### 提交验证声明 - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -点击右侧的“Add via Qr”。 - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -打开Parity Signer并选择 "Polkadot" 网络。 - -![ps-1](assets/new-claims/ps-01.jpg) - -选择你在创世块前申领DOT的地址。 - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -当二维码信息读取成功后，输入您的地址名称并点击“创建”。 - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[ MyCrypto ]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/zh-CN/community.md b/website/translated_docs/zh-CN/community.md deleted file mode 100644 index b6cb60bc9c4d..000000000000 --- a/website/translated_docs/zh-CN/community.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -id: community -title: 社区 -sidebar_label: 社区 ---- - -Polkadot社区每天都在壮大。以下是社区频道最重要的链接。请记住，没有任何管理员或主持人不会因任何原因在没有事先联系的情况下欺骗您，任何这样做的人都可能试图欺骗您。 - -## 一般 - -- [Polkadot GitHub](https://github.com/paritytech/polkadot/) - 由 Parity 负责管理和维护的 Rust 实现的 Polkadot 主机的代码库 -- [Polkadot Meetup Hub](https://www.notion.so/web3foundation/Polkadot-Meetup-Hub-4511c156770e4ba9936386d8be5fe5be) -关于主办聚会，申请资金的相关信息。 -- [Polkadot Support Knowledgebase](https://support.polkadot.network/support/home) 和 [ Polkadot Support Email](mailto:support@polkadot.network) -- [Polkadot 最新的研究](https://research.web3.foundation/en/latest/polkadot/) - -### 活动 - -Web3 基金会主办了许多线上和线下的活动。你可以通过[这个Notion Page](https://www.notion.so/Public-Events-Database-fdd2df4c29d04818a5dd403e2b85920d)来查看我们之前和现在举办的活动。 - -## Matrix 聊天 - -我们整个组织中主要使用[Matrix](https://matrix.org)与社区成员进行沟通。我们最常与Matrix协议进行交互的应用程序是[Element](https://app.element.io)信使。 - -### Polkadot - -- [PolkadotWatercooler Chat](https://app.element.io/#/room/!FdCojkeGzZLSEoiecf:web3.foundation?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 一般性问题聊天室 -- [Polkadot Validator Lounge](https://app.element.io/#/room/#polkadot-validator-lounge:matrix.org) - 验证者可以在这里学习如何架设节点 -- [Polkadot Direction](https://app.element.io/#/room/!OwgojQyBzTlUQGGLhq:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 社区治理，以及探讨 Polkadot 未来方向的聊天室 -- [Polkadot摘要](https://matrix.to/#/!vMpYyTkvjXcevxSdsQ:web3.foundation) - 有关 Polkadot 生态发生的事件新闻，每个工作日（节假日除外）发布 - -### Kusama - -- [Kusama Watercooler Chat](https://app.element.io/#/room/%23kusamawatercooler:polkadot.builders) - 关于 Kusama 的一般性问题聊天室 -- [Kusama Validator Lounge](https://app.element.io/#/room/!LhjZccBOqFNYKLdmbb:polkadot.builders?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - Kusama 的验证者可以在这里学习如何架设节点 -- [Kusama Direction](https://app.element.io/#/room/!QXMnIJzxlnVrvRzhUA:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 关于 Kusama 的社区治理，以及探讨 Kusama 未来方向的聊天室 - -### 技术 - -- [Substract Technical](https://app.element.io/#/room/#substrate-technical:matrix.org) - 关于 Substrate 的更深入的技术问题讨论聊天室 -- [Smart Contract & Parity Ink!](https://app.element.io/#/room/!tYUCYdSvSYPMjWNDDD:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 讨论基于 Parity Ink! 开发的 Substrate 智能合约的聊天室 - -## 媒体 - -### 聊天 - -- [Polkadot Discord](https://discord.gg/wGUDt2p) (推荐） -- [Kusama Discord](https://discord.gg/JSJcRwz8fp) - -### 社交媒体和论坛 - -- [Polkadot 推特](https://twitter.com/Polkadot) -- [Kusama 推特](https://twitter.com/kusamanetwork) -- [Web3 基金会推特](https://twitter.com/web3foundation) - -- [Polkadot Reddit](https://www.reddit.com/r/dot/) -- [Kusama Reddit](https://www.reddit.com/r/Kusama) - -- [Web3 基金会 YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) -- [Polkadot YouTube](https://www.youtube.com/channel/UCB7PbjuZLEba_znc7mEGNgw) -- [Kusama YouTube 频道](http://youtube.com/c/kusamanetwork) - -- [Polkadot 论坛](https://forum.polkadot.network) -- [Kusama 论坛](https://forum.kusama.network) - -### 博客和教程 - -- [Web3 Medium 博客](https://medium.com/@web3) -- [Polkadot 博客](https://polkadot.network/blog/) -- [Gavin Wood Medium 博客](https://medium.com/@gavofyork) -- [Dotleap.com 教程](https://dotleap.com) - -### 邮件公告 - -- [订阅 Polkadot 电子报](https://share.hsforms.com/1LL1CBwiASxC5pJUYZAiDVw4752a) - 在这里订阅我们的电子报。 -- [Dot Leap Newsletter](https://dotleap.substack.com/) - 非官方，每周。 - -## 生态 - -- [Polkadot上的团队建设](https://polkaproject.com/) - 社区维护的团队列表建立在Polkadot和/或Substrate上。(请注意，这里可能有些不准确，因为它是非官方的) -- [Polkadot Stack](https://github.com/w3f/General-Grants-Program/blob/master/grants/polkadot_stack.md) - 如果你对正在进行的开发感兴趣，或是想要了解你可以怎样参与贡献。 diff --git a/website/translated_docs/zh-CN/contributing.md b/website/translated_docs/zh-CN/contributing.md deleted file mode 100644 index 36ddfb5387e7..000000000000 --- a/website/translated_docs/zh-CN/contributing.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: contributing -title: 参与贡献 -sidebar_label: 参与贡献 ---- - -The wiki was started and is maintained by the Web3 Foundation. It is an open source project and aims to be the most extensive resource of knowledge on Polkadot and the Polkadot ecosystem. A large part of the material currently focuses on Polkadot directly but it is not opposed to covering informational material for community projects. Please do not try to pull request any marketing material as this will be rejected. - -Pull requests, discussions, and contributions from the community are encouraged. Active community members who demonstrate a record of good contributions may be given write access to the repository. Otherwise, Web3 Foundation holds the administrative position and final say on the content that is included. Specifically the Technical Education team at the foundation are most directly involved. - -> There is video guide on how to contribute to the wiki [here](https://www.youtube.com/watch?v=6i55KOcy7B0). - -## 如何参与贡献 - -Contributing to the wiki is easy with a GitHub account. Every page is a MarkDown file, which is a [very easy to learn](https://guides.github.com/features/mastering-markdown/) syntax extension to plain text that makes creating links, rendering images, and nice-looking formatting simple. - -Each page has an "Edit" button in the top right corner of the content. By clicking this button you are taken to the GitHub sign in page, where you can either log in or create an account. - -![](assets/edit_button.png) - -Once logged in, you'll be taken to the GitHub text editor in which you can make your edits directly. When you've completed your changes, you can add any specific details on what was changed and commit to a new branch to create a new Pull Request to the repository. From there one of the maintainers will either merge it in or request changes very soon. - -![](assets/contributing.png) ![](assets/creating-pull-request.png) - -Remember that after you click "Propose Changes", you must also click on "Create Pull Request" on the next page. - -![](assets/creating-pull-request-2.png) - -## 规则 - -There are a few basic ground-rules for contributors: - -1. **没有` --force ` pushes **或以任何方式修改 Git 历史记录。 -2. 对于某些问题，尤其是对于诸如错别字之类的较小更改，优先使用 Pull requests。 问题适用于一般或广泛的更改或内容缺少。 -3. Only use **non-master branches**. -4. **Significant modifications**, even by contributors, ought to be subject to a **pull request** to solicit feedback from other contributors. -5. 对于任何其不是非常重要的贡献，_鼓励_ Pull requests，但由贡献者自行决定。 -6. Contributors should attempt to adhere to the prevailing MarkDown style, language, and layout. -7. 应使用正确的语法。带有错别字的 Pull requests 的请求在修复之前不会合并。 -8. 应注意保持尽可能客观和有益的信息。不应故意编造 ，也不应存在外部偏见。 -9. We use a plugin called Prettier to standardize the style across documents. You can run this on your local copy with `npx run prettier --save`, but for simplicity we also have a bot which runs this for us in your PRs. - -## Heritage - -This document was based on the Level contribution guidelines located here: [https://github.com/Level/community/blob/master/CONTRIBUTING.md](https://github.com/Level/community/blob/master/CONTRIBUTING.md) diff --git a/website/translated_docs/zh-CN/getting-started.md b/website/translated_docs/zh-CN/getting-started.md deleted file mode 100644 index f2326ffd7a25..000000000000 --- a/website/translated_docs/zh-CN/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: 入门教程 -sidebar_label: 开始 ---- - -欢迎使用 Polkadot Wiki ！这是一份详细介绍如何与波卡核心系统进行交互的指南。wiki 包含三个主要内容：1. 学习 (面向科研)；2. 开发 (面向基于 Polkadot 的个人开发者)；3. 维护 (面向 Polkadot 网络维护者)。 - -## Polkadot 是什么？ - -Polkadot 允许多条专用区块链在安全的、无信任环境中相互沟通，从而实现可扩展性。 - -创建 Polkadot 的目的是为了连接及保护公链、非许可网络、企业集团私有链或是预言机及其他基于 Web3科技的区块链。它构建了一个可让不同区块链在公共安全保障下，进行信息交换的网络。 - -Polkadot 是一个有生命力的网络，其核心支柱是社区治理和可迭代性。 该网络拥有一套先进的治理工具，以 [WebAssembly](https://webassembly.org/)标准作为“元协议”，可以自动部署网络升级。 Polkadot 会适应您不断增长的需求，同时不会产生区块链网络分叉的风险。 - -> 备注: 如果您是第一次听说“社区治理”，可通过该链接学习 [Governance page](learn-governance) - -综上所述，Polkadot 作为去中心化网络的基础服务，让用户可不受信任边界的限制，自主控制自己的数据。 - -## 为什么是 Polkadot？ - -回到新世纪早期，首次获得大众关注的互联网技术仅有只读、静态等基础网页的功能。 此时的早期网络互联，却是虚拟数据、身份及更多创新的网络新世界的开始。这段时间的互联网也被称为 Web 1.0。 - -随着社交媒体平台和网络商务的出现，互联网转变为 Web 2.0 。这个我们今天仍在使用的互联网版本，其功能是动态、交互式的网页，用户可以读写信息，或与他人分享用户自己的信息。 但是该版本的网络会涉及数据控制、隐私和信任问题。 这就是 Web 3.0 的意义所在。 - -Web 3.0 正在将中心化应用转化为去中心化应用、 去信任协议。其目标是将当前版本的互联网转化为一个去中心化的网络，用户可在去信任的环境中掌控其个人数据及身份。 Web 3.0 运动旨在删除中间人并建立一个去信任的公共基础设施。 - -> 要了解更多关于 Web3 运动的信息，请查看视频 [Web3 Summit](https://youtu.be/l44z35vabvA) - -## Polkadot 如何运作？ - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -为了与其它的区块确认性程序的链条进行交互 (例如: 比特币)，Polkadot 有[桥接链（bridge parachains）](learn-bridges) 提供双向兼容性。 - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> 观看一个有关 Polkadot 简短的，适合初学者的动画，请访问我们的网站。 [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## 为何要使用 Polkadot？ - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## 入门教程 - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot 原始白皮书][white paper] 是一篇技术文档，描述了 Polkadot 网络技术可能的发展方向。文档通过对原理的阐述和技术实现的细节说明来验证其可行性。原始白皮书也描述了Polkadot的核心团队是如何协同合作来构建这个去中心化网络的。 -- [Polkadot's overview paper][overview-paper] 是更新版本的白皮书，用更专业的方式描述了该网络协议。若您有兴趣深入研究协议本身，我们建议您阅读这份白皮书。 -- [Polkadot's lightpaper ][light paper]是一个更直观，方便阅读文档。这份文档比较少使用技术数据，可以让你不需要了解太多技术知识的情况下，就可以对 Polkadot 有更深入的理解。 -- [Polkadot's specification][spec]是一个Github代码库，其中包含最新的Polkadot主机协议规范、Polkadot对网络中许多组件的测试规范，以及Polkadot Runtime规范。该代码库存有算法，并探讨各种进程如何在Polkadot网络中发挥作用。Polkadot规范将Polkadot的思想和概念从聚光灯下和白皮书中提取出来，聚焦于技术规范的技术说明。 -- [观看技术演示][teched videos]: 这些是解释及演示如何使用 Polkadot 及其 [用户界面][ui]的介绍视频。 -- 在Medium上阅读 [What is Polkadot? A Brief Introduction][article] 。您也可以在 [Polkadot's Medium][p medium] 或 [Web3 Foundation's Medium][w medium]上阅读其余优质文章。 -- [创建 Polkadot 帐户][account generation] -- [发起转账][transfer] -- [作为提名人进行抵押 (Staking)][nominator] -- [作为验证节点运行][validator] -- [身份设定][identity] -- [创建代理账户][proxy] -- [发起提案及投票][democracy] -- [加入议会][council] -- [投票选举议员][council voting] -- [使用国库][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## 相关阅读 - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - Web3基金会过往 Crowdcast 网络会议列表 -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer)-Polkadot 网络浏览器，可用于 Polkadot、Kusama 或其他基于 Substrate 的区块链网络。 -- [Polkascan](http://polkascan.io/) - Polkadot 中继链及其他 Substrate 链的实时多链数据。 -- [Subscan.io](https://subscan.io) - Substrate 链浏览器。 -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Gavin Wood 博士对Polkadot 的视频介绍。（视频） -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Jutta Steiner 博士对 Polkadot 的视频介绍。（视频） -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Gavin Wood博士对 Substrate（区块链框架及VM）和 Polkadot，并在30分钟内基于 Substrate 构建了一个可运行的区块链。（视频） -- [社区/生态 ](community) - 谈论 Polkadot 的社区频道列表。 -- [范例程序](build-examples-index) - 基于 Polkadot 的应用案例及开发中的案例。 -- [贡献手册](contributing) - wiki 贡献者奖励规则。 -- [Polkadot 知识库](https://support.polkadot.network/) - 一些特定错误和问题的疑难解答。 - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white paper]: https://polkadot.network/PolkaDotPaper. pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/zh-CN/grants.md b/website/translated_docs/zh-CN/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/zh-CN/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/zh-CN/kusama-adverserial-cheatsheet.md b/website/translated_docs/zh-CN/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 63b2486fffa0..000000000000 --- a/website/translated_docs/zh-CN/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: 对抗备忘单 -sidebar_label: 对抗备忘单 ---- - -期待Kusama 会被攻破。为了帮助对手了解哪里可能会被攻破，参考下面的威胁模型。 - -| 黑客想要 … | 防黑客安全承诺 | 黑客奖励 | 破坏性 | 攻击价值详情 | -| -------------------------- |:--------:|:----:|:-----:| ------------------------------------------------------------------------------------------------- | -| 通过让客户端接受不同的链实现代币双花 | 完整性(全系统) | 高 | 高 | 如果攻击者能够双花代币，他们就能够获得服务而无需支付费用。 这使他们有很大的金钱激励来进行攻击。 | -| 导致系统在他自己的账户中增发代币 | 完整性(全系统) | 中 | 低 - 中 | 如果攻击者能够创建在他们账户里增发代币的交易，那么这将为执行攻击提供了很高的金钱奖励。 | -| 通过验证恶意区块来实现双花 | 可用性(全系统) | 高 | 中 | 如果攻击者能够双花代币，他们就能够获得服务而无需支付费用。 这使他们有很大的金钱激励来进行攻击。 | -| 通过破坏共识机制来分裂链 | 完整性(全系统) | 高 | 高 | 如果攻击者能够双花代币，他们就能够获得服务而无需支付费用。 这使他们有很大的金钱激励来进行攻击。竞争对手押注于加密货币的价值下跌或声誉受损，使得他们自己的区块链价值相对上升。 | -| 篡改/操纵区块链历史记录以使交易无效(例如投票结果) | 完整性(全系统) | 中等 | 中 - 高 | 攻击者可以通过故意使交易发生的区块失效来回滚他们不想要的交易。 攻击者可能迫使有利于他们的治理决定（或甚至是链上更新）被作出。 | -| 破坏区块链或共识机制以破坏生态系统的信誉 | 可用性(全系统) | 高 | 高 | 竞争对手押注于加密货币的价值下跌或声誉受损，使得他们自己的区块链价值相对上升。 | -| 审查 | 可用性(全系统) | 中等 | 高 | 黑客能够阻止他们不想要的交易(例如行业竞争者的交易或公民投票)。 这可以通过与其他利益攸关方勾结或以其他方式获得更多的投票权来实现。 | -| 匿名用户 | 保密性(节点) | 中等 | 中等 | 希望取消用户匿名的政党可以利用信息镇压反对派(例如政治活动家)。 | -| 从节点盗取代币 | 完整性(节点) | 高 | 高 | 能够从节点偷窃代币的攻击者可以为自己索取资产，这给他们实施攻击提供了很高的金钱奖励。 | -| 通过泄漏凭据从节点中盗取代币 | 保密性(节点) | 高 | 高 | 能够从节点偷窃代币的攻击者可以为自己索取资产，这给他们实施攻击提供了很高的金钱奖励。 | -| 阻止节点访问 Polkadot 网络 | 可用性 (节点) | 低 | 低 - 中 | 出于报复、货币利益(如果是相互竞争的货币交易所等)，实施目标明确的拒绝服务攻击。 | -| 诈骗其他参与者 | 完整性(节点) | 中等 | 低 - 中 | 攻击者可能滥用其他参与者对Polkadot安全保证对误解，以欺骗他们。而且，如果能够建立起对揭发不良行为的奖励使其高于对应的惩罚，则可以设置一组自处理的节点来形成闭环，该攻击就不需要其他参与者。 | -| 诈骗其他参与者 | 完整性(全系统) | 高 | 高 | 攻击者可能会在Polkadot的经济系统中滥用漏洞来欺骗其他参与者。 例如，攻击者可以利用逻辑错误来不支付交易费用。 | diff --git a/website/translated_docs/zh-CN/kusama-coc.md b/website/translated_docs/zh-CN/kusama-coc.md deleted file mode 100644 index f4d50ad04e60..000000000000 --- a/website/translated_docs/zh-CN/kusama-coc.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: kusama-coc -title: Kusama 行为守则 -sidebar_label: 行为守则 ---- - -While Kusama has been its own network and has had its own ecosystem for a while now, it is still one big experiment and we need your participation for it to continue being a great success. - -## Community - -We want to foster a sense of collaboration amongst ourselves and the open source community. Kusma participants exist to encourage the open exchange of ideas and expression and require an environment that recognizes the inherent worth of every person and group. We are here to collaborate, discuss, and even disagree. The key is doing this is a manner that comes from a place of respect and professionalism. Participants in the Kusama network may consist of participants in an online forum, on-chain governance participants, parachain deployment teams, validators, enthusiasts, and ecosystem tool builders. We expect for there to be participation from all backgrounds but like to set some social boundaries on how you may be treated and treat others. - -Kusama 社区成员来自全球各地，不分种族、性别、或 背景。 社区参与者通过必要的资源阅读了解有关Kusama 的知识及其所有相关内容。这些知识使社区具备履行参与者职责时所需的必要信息。 - -## Bugs - -Please understand that this network is, despite its success, an experiment with potential flaws, so it’s appreciated that community members help report any sort of exploits directly to the team before sharing publicly. Please see the [bug bounty program](kusama-bug-bounty). - -## Examples of Unacceptable Behavior - -请注意：这仅是几个示例，如果您有任何疑问，您总是可以咨询团队成员。 - -- Angry aggressive comments towards individuals or other projects on any medium of communication. -- Knowingly distributing false information about Kusama or other projects. -- Harassing other individuals or projects. - -That said, please note that Kusama is an edgy and meme-friendly network and community member actions shouldn't be taken too seriously - try to assume jest before malice. - -## What To Do If You Witness or Are Subject To Unacceptable Behavior - -If you are being harassed, notice that someone else is being harassed, or have any other concerns relating to harassment, please contact the administrator of the channel you’re in. - -This Code of Conduct may be revised at any time. We are always willing to revise this document based on feedback from the Kusama participants and/or the Polkadot community. diff --git a/website/translated_docs/zh-CN/kusama-ledger.md b/website/translated_docs/zh-CN/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/zh-CN/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/zh-CN/kusama-parameters.md b/website/translated_docs/zh-CN/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/zh-CN/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/zh-CN/kusama-time-periods.md b/website/translated_docs/zh-CN/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/zh-CN/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/zh-CN/learn-DOT.md b/website/translated_docs/zh-CN/learn-DOT.md deleted file mode 100644 index 9683dceadcab..000000000000 --- a/website/translated_docs/zh-CN/learn-DOT.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -id: learn-DOT -title: DOT -sidebar_label: DOT ---- - -## What are DOT? - -DOT 是 Polkadot 网络的原生代币，类似于 BTC 是比特币的原生代币或以太币是以太坊区块链的原生代币。 - -The smallest unit of account in a Substrate network (Polkadot, Kusama, etc.) is the Planck (a reference to [Planck Length](https://en.wikipedia.org/wiki/Planck_length), the smallest possible distance in the physical Universe). You can compare the Planck to satoshis or wei, while the DOT is like a bitcoin or an ether. Kusama tokens (KSM) are equal to 1e12 Planck, and Polkadot mainnet DOT are equal to 1e10 Planck. - -### Polkadot - -| 单位 | 小数位 | Example | -| --------------- | --- | ------------ | -| Planck | 0 | 0.0000000001 | -| Microdot (uDOT) | 4 | 0.0000010000 | -| Millidot (mDOT) | 7 | 0.0010000000 | -| Dot (DOT) | 10 | 1.0000000000 | - -_Note: This changed at block #1,248,328. Previously, DOT were denominated as equal to 1e12 Planck, just like Kusama. This denomination is deprecrated, and, if necessary, referred to as "DOT (old)". See [Redenomination of DOT](redenomination) for more details._ - -### Kusama - -| 单位 | 小数位 | Example | -| --------------- | --- | -------------- | -| Planck | 0 | 0.000000000001 | -| Point | 3 | 0.000000001000 | -| MicroKSM (uKSM) | 6 | 0.000001000000 | -| MilliKSM (mKSM) | 9 | 0.001000000000 | -| KSM | 12 | 1.000000000000 | - -## What are the uses of DOT? - -DOT serve three key functions in Polkadot: - -- to be used for governance of the network, -- to be staked for operation of the network, -- to be bonded to connect a chain to Polkadot as a parachain. - -DOT can also serve ancillary functions by virtue of being a transferrable token. For example, DOT stored in the Treasury can be sent to teams working on relevant projects for the Polkadot network. - -> These concepts have been further explained in the video [Usage of DOT and KSM on Polkadot and Kusama](https://www.youtube.com/watch?v=POfFgrMfkTo&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=7). - -### DOT for Governance - -The first function of DOT is to entitle holders to control of the governance of the platform. Some functions that are included under the governance mechanism include determining the fees of the network, the addition or removal of parachains, and exceptional events such as upgrades and fixes to the Polkadot platform. - -Polkadot will enable any holder of DOT to participate in governance. For details on how holders can participate in governance, as well as their rights and responsibilities, see the [governance page](learn-governance). - -### DOT for Consensus - -DOT will be used to facilitate the consensus mechanism that underpins Polkadot. In order for the platform to function and allow for valid transactions to be carried out across parachains, Polkadot will rely on holders of DOT to play active roles. Participants will put their DOT at risk (via staking) to perform these functions. The staking of DOT acts as a disincentive for malicious participants who will be punished by the network by getting their DOT slashed. The DOT required to participate in the network will vary depending on the activity that is being performed, the duration the DOT will be staked for, and the total number of DOT staked. - -### DOT for Parachain Slot Acquisition - -DOT will have the ability to be locked for a duration in order to secure a parachain slot in the network. The DOT will be reserved during slot lease and will be released back to the account that reserved them after the duration of the lease has elapsed and the parachain is removed. You can learn more about this aspect by reading about the [auctions](learn-auction) that govern parachain slots. - -### 锁仓 (Vesting) - -DOT may have a lock placed on them to account for vesting funds. Like other types of locks, these funds cannot be transferred but can be used in other parts of the protocol such as voting in governance or being staked as a validator or nominator. - -Vesting funds are on a linear release schedule and unlock a constant number of tokens at each block. Although the tokens are released in this manner, it does not get reflected on-chain automatically due to the fact that locks are [lazy](#lazy-vesting) and require an extrinsic to update. - -There are two ways that vesting schedules can be created. - -- One way is as part of the genesis configuration of the chain. In the case of Polkadot and Kusama, the chain specification genesis script reads the state of the Polkadot Claims contract that exists on the Ethereum blockchain and creates vesting schedules in genesis for all the allocations registered as being vested. -- A second way is through an extrinsic type available in the Vesting pallet, `vested_transfer`. The vested transfer function allows anyone to create a vesting schedule with a transfer of funds, as long as the account for which the vesting schedule will be created does not already have one and the transfer moves at least `MinVestedTransfer` funds, which is specified as a chain constant. - -Vesting schedules have three parameters, `locked`, `per_block`, and `starting_block`. The configuration of these three fields dictate the amount of funds that are originally locked, the slope of the unlock line, and the block number for when the unlocking begins. - -#### Lazy 锁仓 - -Like [simple payouts](learn-simple-payouts), vesting is _lazy_, which means that someone must explicitly call an extrinsic to update the lock that is placed on an account. - -- The `vest` extrinsic will update the lock that is placed on the caller. -- The `vest_other` will update the lock that is placed on another "target" account's funds. - -These extrinsics are exposed from the Vesting pallet. - -If you are using Polkadot-JS, when there are DOT available to vest for an account, then you will have the ability to unlock DOT which have already vested from the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![unbond](assets/unlock-vesting.png) - -#### Calculating When Vesting DOT Will Be Available - -Generally, you should be able to see from the [Accounts](https://polkadot.js.org/apps/#/accounts) by looking at your accounts and seeing when the vesting will finish. However, some DOT vest with "cliffs" - a single block where all the DOT are released, instead of vesting over time. In this case, you will have to query the chain state directly to see when they will be available (since technically, the vesting has not yet started - all of the vesting will occur in a single block in the future). - -1. Navigate to the [Chain State](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/chainstate) page on Polkadot-JS. -2. Query chain state for `vesting.vesting(ACCOUNT_ID)` -3. Note the `startingBlock` where the unlock starts, and how much DOT is unlocked per block (`perBlock`). -4. You will have to calculate the result into “human time". To do this, remember that there are approximately 14’400 blocks per day, and you can see what the latest block is shown on the [Explorer](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/explorer) page. - -## Obtaining Testnet DOT - -DOT are required to make transactions on the Polkadot network. Testnet DOT do not have any value beside allowing you to experiment with the network. - -### 获取 Westies - -The current testnet is called [Westend](maintain-networks#westend-test-network) and you can obtain its native tokens by posting `!drip ` in the Matrix chatroom [#westend_faucet:matrix.org](https://matrix.to/#/#westend_faucet:matrix.org). - -You can also make your own WNDs (testnet DOT) by [becoming a validator](learn-validator). - -### Getting Rococo Tokens - -Rococo is a parachain testnet. It does not have a faucet, and tokens are given only to teams working on parachains or exploring the [crosschain](learn-crosschain) message passing aspects of this testnet. Learn more about Rococo on the [matching wiki page](build-parachains-rococo). - -## Kusama Tokens - -Unlike testnet DOT, Kusama tokens are not freely given away. Kusama tokens are available via the [claims process](https://claim.kusama.network/) (if you had DOT at the time of Kusama genesis) or through the [Treasury](learn-treasury). Alternatively, they can be obtained on the open market. - -## Polkadot Mainnet DOT - -Polkadot Mainnet DOT are not freely given away. If you purchased DOT in the original 2017 offering, you may claim them via the [Polkadot claims process](https://claims.polkadot.network/). Alternatively, they are available on the open market. diff --git a/website/translated_docs/zh-CN/learn-UI.md b/website/translated_docs/zh-CN/learn-UI.md deleted file mode 100644 index 4d9dd33e61c1..000000000000 --- a/website/translated_docs/zh-CN/learn-UI.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: learn-UI -title: Polkadot UI -sidebar_label: Polkadot UI ---- - -![Polkadot UI](assets/polkadot_ui_1.png) - -Polkadot comes with an open source, publicly accessible interface that makes it easy for anyone to connect to the Alexander testnet. You can find it [here](https://polkadot.js.org/apps/#/explorer). - -## Getting started - -By default the Polkadot UI will connect to the Parity hosted node at `wss://poc3-rpc.polkadot.io/`. If you are running your own node locally or on a VPS you can configure it by going into the **Settings** tab and setting a custom node endpoint. - -As mentioned the Polkadot UI project is open source and if you're interested in how it works internally you can browse the GitHub repository [here](https://github.com/polkadot-js/apps). - -### Creating an account - -To create an account navigate to the **Accounts** tab and click on the `Create account` button at the top of the display (it will be chosen by default if you have not already created an account). - -### Getting testnet DOTs - -To start playing around on the testnet you will need some testnet DOTs. Click [here](learn-DOT#getting-testnet-dots) to see ways to get testnet DOTs. - -### Sending a transaction - -Navigate to the **Extrinsics** tab and select your account which has DOTs. Enter the address you want to send DOTs into the `dest:Address` field and the amount to send in the `value: Compact` field. Click send transaction and enter your password to unlock your account. - -You will notice the value increase in the destination address after a few blocks. - -## Navigating around the interface - -### Explorer - -The Polkadot explorer lists the validated blocks as they are sealed. Each block listed includes its: - - - Block height/number. - - Hash. - - `parentHash` (hash of the previous block). - - The extrinsics root (merkle root of the ordered mapping of extrinsics, from the index to each extrinsic in the block). - - State root (merkle root of all the storage). - -### Transfer - -On this tab you can transfer DOTs to other accounts. The steps to make a transfer are as follows: - -1. Select the source account from which to send DOTs. -2. Select the recipient address which will receive the DOTs. -3. Enter the amount of DOTs to transfer. -4. Click the `Make Transfer` button, then the `Sign & Submit` button to send the transfer. - -### Staking - -On this tab you can get an overview of the current validators and information about the staking system. You can see how many validators are currently operating and how many empty slots are still available. There is a list of all the validator addresses and as they produce blocks they will update with the latest block number. - -On the `Account Actions` you will be able to set your accounts to validate, nominate or stop if they are set as controller. Or you can set a session key and bond DOTs if the account is a stash account. - -### Democracy - -The Democracy tab shows the current proposals and referendums. - -### Accounts - -This page lists your current Polkadot accounts. You can view, edit or create an account. When creating accounts, it's always good practice to back up the private key under the create from the following seed ... field. - -### Vanity - -![Polkadot UI 3](assets/polkadot_ui_3.png) - -Polkadot UI comes with a vanity address generator in the browser. To create a vanity address, enter a string and start hashing. The longer the string, the longer it will take to compute. Note that some characters are not allowed due to the hashing algorithm used in Polkadot. - -### Addresses - -You can save addresses here for later use. To add a new address to your address book, click the Add address tab at the top. - -### Chain State - -The **Chain State** tab allows you to query the Polkadot PoC-3 blockchain for statistics and information. - -Some useful queries include: - - - `consensus.authorityCount()`: the number of current validators - - `session.validators()`: the current validators by address, useful for verifying your status as a validator - - `staking.intentions()`: accounts with the desire to stake and become validators - - `consensus.code()`: the Wasm code of the current runtime, useful for monitoring changes in the state transition function - - `system.accountIndexOf(who)`: the number of extrinsics a given account has submitted - - `staking.freeBalanceOfWho()`: the balance of a given account - - -### Extrinsics - -![Polkadot UI 2](assets/polkadot_ui_2.png) - -Extrinsics are the bits of information added to the blockchain, i.e., the things 'extrinsic' from the system. These include transactions, staking, proposing, voting, and many other consensus-level actions. - -Start by selecting the account you wish to act with, then choose one of the following extrinsics from the extrinsics section. - -### Transferring and staking - -From here you can transfer, stake and unstake tokens. - - - transfer(recipient,value) - Transfer by entering the recipient's address in the 'recipient field', then entering the number of DOTs you would like to send. - -- stake() - Stake the entirety of your selected account's balance to become a Validator. However, becoming a Validator requires more than just staking. To get more information on becoming a Validator, read the requirements and tutorial in the [Validator Guide](maintain-guides-how-to-validate). - - - unstake() - Unstake the entirety of your selected account's balance to withdraw your bid to be a Validator. - -### Toolbox - -For hackers interested in submitting Raw RPC calls, you can do so from here. These calls will be updated as Polkadot evolves. - -You can also hash data, verify signed messages, and sign messages from your accounts. diff --git a/website/translated_docs/zh-CN/learn-account-generation.md b/website/translated_docs/zh-CN/learn-account-generation.md deleted file mode 100644 index 323ece4280df..000000000000 --- a/website/translated_docs/zh-CN/learn-account-generation.md +++ /dev/null @@ -1,235 +0,0 @@ ---- -id: learn-account-generation -title: 开始生成帐户 -sidebar_label: 创建帐户 -description: Step-by-step guides on generating a Polkadot account. ---- - -An address is the public part of a Polkadot account. The private part is the key used to access this address. The public and private part together make up a Polkadot account. - -There are several ways to generate a Polkadot account: - -- 推荐给大多数用户的Polkadot {.js}浏览器插件 -- **最安全的** [Subkey](#subkey) -- [Polkadot-JS 应用](#polkadotjs) -- [Parity Signer](#parity-signer) -- [Vanity Generator](#vanity-generator) -- [硬件钱包](learn-ledger) - -> If you prefer video instructions, we have an easy to follow guide [on YouTube](https://www.youtube.com/watch?v=hhUZ40ZWqkE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=19) - -## 免责声明：密钥安全 - -The _only_ ways to get access to your account are via your secret seed or your account's JSON file in combination with a password. You must keep them both secure and private. If you share them with anyone they will have full access to your account, including all of your funds. This information is a target for hackers and others with bad intentions - see also [How to Recognize Scams](learn-scams). - -On this page we recommend a variety of account generation methods that have various convienience and security tradeoffs. Please review this page carefully before making your account so that you understand the risks of the account generation method you choose and how to properly mitigate them in order to keep your funds safe. - -### 密钥的安全存储 - -The seed is your **key** to the account. Knowing the seed allows you, or anyone else who knows the seed, to re-generate and control this account. - -It is imperative to store the seed somewhere safe, secret, and secure. If you lose access to your account (i.e. you forget the password for your account's JSON file), you can re-create it by entering the seed. This also means that somebody else can have control over your account if they have access to your seed. - -For maximum security, the seed should be written down on paper or another non-digital device and stored in a safe place. You may also want to protect your seed from physical damage, as well (e.g. by storing in a sealed plastic bag to prevent water damage, storing it in a fireproof safe, etching it in metal, etc.) It is recommended that you store multiple copies of the seed in geographically separate locations (e.g., one in your home safe and one in a safety deposit box at your bank). - -You should definitely not store your seed on any kind of computer that has or may have access to the internet in the future. - -### Storing your account's JSON file - -The JSON file is encrypted with a password, which means you can import it into any wallet which supports JSON imports, but to then use it, you need the password. You don't have to be as careful with your JSON file's storage as you would with your seed (i.e. it can be on a USB drive near you), but remember that in this case your account is only as secure as the password you used to encrypt it. Do not use easy to guess or hard to remember passwords. It is good practice to use a [mnemonic password of four to five words](https://xkcd.com/936/). These are nearly impossible for computers to guess due to the number of combinations possible, but much easier for humans to remember. - -## Polkadot{.js} 浏览器插件 - -The Polkadot{.js} plugin provides a reasonable balance of security and usability. It provides a separate local mechanism to generate your address and interact with Polkadot. - -This method involves installing the Polkadot{.js} plugin and using it as a “virtual vault," separate from your browser, to store your private keys. It also allows signing of transactions and similar functionality. - -It is still running on the same computer you use to connected to the internet with and thus is less secure than using Parity Signer or other air-gapped approaches. - -### Install the Browser Plugin - -The browser plugin is available for both [Google Chrome](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd?hl=en) (and Chromium based browsers like Brave) and [FireFox](https://addons.mozilla.org/en-US/firefox/addon/polkadot-js-extension). - -If you would like to know more or review the code of the plugin yourself, you can visit the [Github source repository](https://github.com/polkadot-js/extension). - -After installing the plugin, you should see the orange and white Polkadot{.js} logo in the menu bar of your browser. - -![plugin-02](assets/accounts/polkadot_plugin_js_02.jpg) - -### Open Accounts - -Navigate to [Polkadot Apps](https://polkadot.js.org/apps). Click on the "Accounts" tab. - -### Create Account - -Open the Polkadot{.js} browser extension by clicking the logo on the top bar of your browser. You will see a browser popup not unlike the one below. - -![Initial PolkadotJS popup](assets/accounts/polkadot_plugin_js_new_01.png) - -Click the big plus button or select "Create new account" from the small plus icon in the top right. The Polkadot{.js} plugin will then use system randomness to make a new seed for you and display it to you in the form of twelve words. - -![New seed](assets/accounts/polkadot_plugin_js_new_02.png) - -You should back up these words as [explained above](#storing-your-key-safely). It is imperative to store the seed somewhere safe, secret, and secure. If you cannot access your account via Polkadot{.js} for some reason, you can re-enter your seed through the "Add account menu" by selecting "Import account from pre-existing seed". - -![New seed](assets/accounts/polkadot_plugin_js_new_03.png) - -### Name Account - -The account name is arbitrary and for your use only. It is not stored on the blockchain and will not be visible to other users who look at your address via a block explorer. If you're juggling multiple accounts, it helps to make this as descriptive and detailed as needed. - -### Enter Password - -The password will be used to encrypt this account's information. You will need to re-enter it when using the account for any kind of outgoing transaction or when using it to cryptographically sign a message. - -Note that this password does NOT protect your seed phrase. If someone knows the twelve words in your mnemonic seed, they still have control over your account even if they do not know the password. - -### 将 Polkadot 主网设置为地址 - -Now we will ensure that the addresses are displayed as Polkadot mainnet addresses. - -Click on "Options" at the top of the plugin window, and under "Display address format for" select "Polkadot Relay Chain". - -![New seed](assets/accounts/polkadot_plugin_js_new_04.png) - -Your address' format is only visual - the data used to derive this representation of your address are the same, so you can use the same address on multiple chains. However, for privacy reasons, we recommend creating a new address for each chain you're using. - -Our [Accounts page](learn-accounts#address-conversion-tools) also has a tool you can use to convert your address between the different chain formats. - -You can copy your address by clicking on the account's icon while the desired chain format is active. E.g. selecting "Substrate" as the format will change your address to start with the number 5, and clicking the colorful icon of your account will copy it in that format. While in Polkadot mode (starts with 1), that format will be copied, and so on. - -## Subkey - -Subkey is recommended for technically advanced users who are comfortable with the command line and compiling Rust code. Subkey allows you to generate keys on any device that can compile the code. Subkey may also be useful for automated account generation using an air-gapped device. It is not recommended for general users. - -For detailed build and usage instructions of subkey, please see [here](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). - -![subkey-01](assets/accounts/subkey_01.jpg) - -## Polkadot-JS Apps - -> Please note! If you use this method to create your account and clear your cookies in your browser, your account will be lost forever if you do not [back it up](learn-account-restore). Make sure you store your seed phrase in a safe place, or download the account's JSON file if using the Polkadot{.js} browser extension. Learn more about account backup and restoration [here](learn-account-restore). - -Using the Polkadot-JS user interface without the plugin is not recommended. It is the least secure way of generating an account. It should only be used if all of the other methods are not feasible in your situation. - -### Go to Polkadot-JS Apps - -Navigate to [Polkadot-JS Apps](https://polkadot.js.org/apps) and click on "Accounts" underneath the Accounts tab. It is located in the navigation bar at the top of your screen. - -![pjs-01](assets/accounts/polkadot_js_01.png) - -> To create an account on a different network than Polkadot, you'll need to click on the network selection in the top left corner of the navigation menu. A pop-up sidebar will appear listing live, testing, and custom node to choose from. Do remember to hit the "Switch" button when you want to switch your network. - -### Start Account Generation - -Click on the "Add Account" button. You should see a pop-up similar to the process encountered when using the [Polkadot JS Extension method](#polkadotjs-browser-plugin) above. Follow the same instructions and remember to [store your seed safely](#storing-your-key-safely)! - -### Create and Back Up Account - -Click “Save” and your account will be created. It will also generate a [backup JSON file](#storing-your-accounts-json-file) that you should safely store, ideally on a USB off the computer you're using. You should not store it in cloud storage, email it to yourself, etc. - -You can use this backup file to restore your account. This backup file is not readable unless it is decrypted with the password. - -### Multi-signature Accounts - -Multi-signature accounts are accounts created from several standard accounts (or even other multi-sig accounts). For a full explanation, please see the [Accounts Explainer section on multi-sigs](learn-accounts#multi-signature-accounts). - -On the [Accounts](https://polkadot.js.org/apps/#/accounts) tab, click the `Multisig` button. Enter the threshold and add signatories. The threshold must be less than or equal to the number of signatories. The threshold indicates how many members must be in agreement for an extrinsic submission to be successful. Click `Create` when done. - -![Multi-sig account creation](/img/accounts/create-multisig.png) - -This merely calculates the multi-signature's address and adds it to your UI. The account does not exist yet, and is subject to the same [Existential Deposit and Reaping](learn-accounts#existential-deposit-and-reaping) rules as regular accounts. - -Suppose we funded it with some tokens, and now want to send from the multi-sig to another account. - -![Sending from multi-sig account](/img/accounts/send-from-multi.png) - -The next step is to sign the transaction from with enough accounts to meet the threshold; in the above case, two out of three signatories must sign. - -![Signing from multi-sig account](/img/accounts/sign-from-multi-1.png) - -There is currently no indication of a pending transaction from a multi-sig in the UI. This means the second signatory must **repeat the call in full** in order to sign it. In other words: - -- 如果 Alice 发起了从多钱账户给 Ferdie 转账150个币的交易，链中将有一 个待处理的交易。 -- 如果 Bob 发起了从多钱账户给 Ferdie 转账250个币的交易，链中将有**另一个** 待处理的交易，并且第一个交易还没有完成。 -- 因为阈值是 2/3，Charlie 现在可以通过重复 执行所需交易来完成任意这两笔交易。 - -Other calls work exactly the same - if a multi-sig wants to become a Council member, the candidacy request has to come from the multi-sig, but be signed (re-requested) from each signatory until the threshold is reached. - -Signatories should communicate off-chain to prevent many pending transactions and crossed communication lines on-chain. - -> The bigger the multisig, the more of a deposit an account needs to put down when initiating a multi-sig call. This is to prevent chain storage spam with pending but never-resolved multi-sig transactions. Once a call is resolved (canceled or executed) the deposit is returned to the initiator. The deposit is not taken from the multi-sig's balance, but from the initiator. - -For a more in-depth introduction into multi signature accounts on Polkadot, please see [the accounts page section on Multi-sigs](learn-accounts#multi-signature-accounts). - -## Parity Signer - -Parity Signer is a secure way of storing your DOT on an air-gapped device. It is highly recommended that you turn off wifi, cellular network, Bluetooth, NFC, and any other communications methods after installing it. If you have any communications methods turned on, you will see an "unshielded" icon in red in the top-right corner that indicates your connection may not be secure. - -### Create Account - -Click "Create" to create an identity, or "recover" if you have previously backed up the recovery phrase. You can have multiple identities on one device. Each identity can manage multiple addresses on different networks. - -![Parity Signer Create Account 1](assets/accounts/ps-create-1.jpg) - -### Name Account - -Input the name for your identity and then click "Create". - -![Parity Signer Create Account 2](assets/accounts/ps-create-2.jpg) - -### Back Up Account - -Parity Signer will then generate a recovery phrase for you and display it in the form of 12 or 24 words. - -You should write down this recovery phrase on paper and [store it somewhere safe](#storing-your-key-safely). - -![Parity Signer Create Account 3](assets/accounts/ps-create-3.jpg) - -### Set PIN - -After confirming that you have backed up your seed, a new textbox will appear in which you can set a PIN. The PIN code should contain at least 6 digits. If the PIN codes do not match, it will not allow you to create an account. The PIN code will be used for when signing any transaction, or to protect sensitive operations such as deleting an identity or revealing the recovery phrase. - -Note that if someone knows the 12/24 words in your recovery phrase, they will still have control over your account, even if they do not know the PIN. - -![Parity Signer Create Account 4](assets/accounts/ps-create-4.jpg) - -### Get Address - -Choose which network you would like to create an address for by clicking the name of the network. For example, if you select "Polkadot", a new Polkadot address will be created for you under this identity. - -![Parity Signer Create Account 5](assets/accounts/ps-create-5.jpg) - -There is currently no way to copy your address from Parity signer in plain-text in order to send it via text or email. You must use the QR method. - -### Your Address - -The address will be shown as a QR code. You can import your address to the Polkadot-JS Apps by going to the [Accounts](https://polkadot.js.org/apps/#/accounts) page on an Internet-connected computer and click "Add via QR", and following the instructions to add the account. An account created this way will always require you to sign messages with your Parity Signer device. It will do this only by scanning and displaying QR codes, leaving even someone with total control of your internet-connected computer a very small and limited scope for interacting with the Parity Signer device, which can continue to keep your key safe. - -![Parity Signer Create Account 6](assets/accounts/ps-create-6.jpg) - -## 硬件钱包 - -To use a Ledger hardware wallet to create your address and keep your tokens in cold storage, follow the instructions on our [Ledger hardware wallet guide page](learn-ledger). - -## 靓号地址(Vanity Generator) - -The vanity generator is a tool on [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts/vanity) that lets you generate addresses which contain a specific substring. - -![Vanity Generator page](assets/polkadot_vanity_generator_page.png) - -The vanity generator takes the following parameters: - -- “搜索”: 您想要在您的新地址中包含的子字符串。 -- "区分大小写": "是", 如果搜索是区分大小写; "否" 如果不是。 -- “密钥对加密类型”：指定您要生成的帐户类型；建议在大多数情况下使用Schnorrkel，以确保安全。 - -If you've filled out all details above and hit the "Start generation" button, a list of accounts will start generating on your screen. Note that depending on the length of the substring and the processing speed of your computer, it may take some time before any accounts appear. - -![Vanity Generator search](assets/polkadot_vanity_generate.png) - -The "Save" button will allow you to save the generated accounts - they are not saved if you do not choose to do this. The next steps are identical to the [steps above on creating an account on the UI](#polkadotjs), where a password and name need to be filled in, and a backup file of your account will be downloaded. - -Note that the [Subkey tool](#subkey) also has vanity generation built-in, and is orders of magnitude faster than the web version. If you need to generate addresses with longer strings, or need plenty of them, we recommend using Subkey instead. - -![Vanity Generator chosen address](assets/polkadot_save_account.png) diff --git a/website/translated_docs/zh-CN/learn-accounts.md b/website/translated_docs/zh-CN/learn-accounts.md deleted file mode 100644 index 857b16894eed..000000000000 --- a/website/translated_docs/zh-CN/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot 账户 -sidebar_label: Polkadot 账户 -description: 账户、账户索引、账户身份和回收机制的解释 ---- - -本文档涵盖 Polkadot 和 Kusama 账户的基本地址及其在链上的保存。 欲了解更多关于加密技术背后的详细解释，请参阅 [加密页面](learn-cryptography)。 - -## 地址格式 - -基于 Substrate 的链的地址格式是SS58。SS58 是一种对于比特币的 Base-58-Check 进行小幅修改的格式。需要注意，此格式包含_地址类型_前缀，可以识别地址具体属于哪一个网络。 - -例如: - -- Polkadot 地址总是以数字1开头。 -- Kusama 地址总是以大写字母开头，如C、D、F、G、H、J... -- 通用Substrate 地址以5开头。 - -这些前缀在[此处](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58))定义。 - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## 地址的生成，派生和迁移 - -一个有效的账户只需要一个可以在[supported curves and signature scheme](build-protocol-info#cryptography)签名的私钥。多数钱包然间从助记词到生成账户需要经由许多步骤。同一组助记词，不同钱包采用不同步骤生成的账户也不会相同。 - -### 助记词(种子) 生成 - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -基于 Subkey 和 Polkadot-JS 的钱包采用BIP39词典来生成助记词，使用熵字节数组来生成私钥，这有别于其他 BIP39 钱包软件(如Ledger)采用 PBKDF2。所以，同一组助记词在经由这两种算法后并不能产生同样的私钥。更多相关细节请参阅[Substrate BIP39](https://github.com/paritytech/substrate-bip39) - -### 衍生路径 - -许多 Polkadot 密钥生成工具支持硬派和软派生。更多关于派生路径的细节和例子请参考 [Subkey 文档](https://substrate. dev/docs/en/knowledgebase/integrate/subkey) 。Polkadot-JS 的应用和拓展同 Parity Signer 也支持采用和 Subkey 相同语法的自定义派生路径。 - -一些钱包会自动将派生路径添加到生成的助记词短语的末尾。这将为单独的路径生成单独的种子，从而允许使用相同的助记符，例如`//Polkadot` 和 `//Kusama`。尽管您可以正确保存助记词短语，但除非在两个钱包中使用相同的派生路径，否则在另一个钱包中使用它将不会生成相同的地址。 - -Polkadot 和 Kusama 都在[BIP44注册表](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)中注册了路径。 - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### 可移植性 - -以上信息为我们带来了可移植性：在多个钱包中使用助记词或种子的能力。可移植性取决于许多因素： - -- 派生路径 -- 助记符格式 -- 种子衍生 -- 签名方案 - -如果要在多个钱包中使用相同的助记符，请确保它们遵循兼容生成密钥和签名消息的方法。如果找不到可理解的文档，请与项目维护人员联系。 - -| | 助记符格式 | 派生路径 | 种子衍生 | 签名支持 | -|:---------------- |:------:|:-------------:|:-------------:|:---------------------------:| -| Polkadot{.js} 扩展 | 标准 | 用户自定义 | BIP32 | sr25519 | -| Polkadot-JS 应用程序 | 标准\* | 用户自定义 | BIP32 | sr25519, ed25519, secp256k | -| 账本 | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | 标准\* | 用户自定义 | BIP32 | sr25519, ed25519, secp256k1 | - -\ * 附带 BIP39 的 Ed25519 密钥具有[有限的兼容性](https://github.com/paritytech/substrate-bip39)。 - -† [BIP44 注册表](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ 基于[Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf)的 Ed25519 和 BIP32 - -§ Sr25519 计划 - -### 好奇：前缀的工作原理 - -这是[ SS58 文档](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58))的申明： - -- Polkadot 的地址类型为`000000000`，所以`0`是十进制。 -- Kusama (Polkadot 金丝雀) 的地址类型为`00000010b`，因此`2`以十进制表示。 -- 通用 Substrate 的地址类型为`00101010b`，十进制为`42`。 - -因为 Base58-check 字母没有数字0，所以最小值确实是1。因此，`00000000b`在 Base58 中是1。如果我们尝试[解码](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder)诸如` 1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg `的Polkadot地址，则结果为` 000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8b7e7bed`。第一个字节是`00`，实际上既是二进制的`00000000`又是十进制的`0`，因此它与 Polkadot 的地址类型匹配。 - -让我们看一下 Substrate 的地址。如果我们解码` 5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`，则会得到` 2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`。第一个字节是`2a`，当[从十六进制转换为十进制](https://www.rapidtables.com/convert/number/hex-to-decimal.html)时是42。42的二进制是`00101010`，就像 SS58 文档所述的那样。 - -最后，让我们看一下 Kusama 的地址。解码` CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp`会让我们得到` 020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985`，正如被指定的那样，其中第一个字节为`02`。如果我们尝试以完全不同的字母，例如` J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`，我们仍然将`02`作为第一个字节：` 02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e2114`。从直觉上看，有些地址总是有相同的前缀，而其他一些地址像是用 Kusama 生成的却可能千差万别，但这只是对于 Base58-check 编码的怪癖。 - -## 获取和管理地址 - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -**更方便和推荐**的将帐户保存在计算机上方法是使用[ Polkadot {.js}扩展名](https://github.com/polkadot-js/extension)。此扩展程序可以记住您的帐户，让您不必担心即可清除浏览器缓存。不过，不要忘记备份您的种子短语 - 如果您无法使用这台计算机，或者扩展名以某种方式崩溃而无法修复，则该短语将派上用场。 - -请注意，由于这会将您的帐户保留在浏览器中，因此这里不是一个存放大量资产的安全之地。根据定义，浏览器是一个“热钱包”，容易受到各种各样的攻击，因此，在处理不重要的数额时，请将资金保存在冷库中。为了提高安全性，您可以安全地隐藏帐户的种子短语，并在创建帐户后从计算机中删除所有帐户痕迹。 - -除了扩展名和默认UI外，还可以使用[ 子键工具](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey)。子键旨在供用户熟悉使用命令行使用，并且看起来令人生畏，但相当平易近人。请按照[子键文档](https://substrate.dev/docs/en/knowledgebase/integrate/subkey)。如果使用得当，子键是创建帐户的**最安全**的可用方法。 - -还有一个非常安全的[奇偶校验签名人](https://www.parity.io/signer/)。这样可以将您的钥匙保持在气密的手机上。但是，这确实需要获得您常用的且仅用于 Parity Signer 的旧 Android 或 iOS 兼容手机。 - -账本可以与硬件钱包集成。完整指南可在[此处](learn-ledger)获得。 - -另外，您可能会在[钱包](build-wallets)页面上找到其他钱包，但请记住，其中一些是**未经审计的**，除非另有说明，否则它们并不隶属于Web3 Foundation或Polkadot的正式项目。 - -## 余额类型 - -在 Polkadot 上，有四种不同的余额类型，提示您的余额是否可以用于转账，支付费用，或者由于链上要求而必须冻结且不被使用。 - -余额类型由 Substrate 中的`AccountData`结构定义。四种类型的余额包括`free`，`reserved`，`misc_frozen` (驼峰体为`miscFrozen`) 和` fee_frozen` (驼峰体为`feeFrozen`)。 - -通常，帐户的**可用**余额是`自由`的金额减去任何被视为冻结的资金 (`misc_frozen`或`free_frozen`) ，具体取决于使用资金的原因。如果资金将用于转账，则可用金额为“自由”金额减去任何`misc_frozen`资金。但是，如果要使用这些资金来支付交易费用，则可用金额将是“自由”资金减去`fee_frozen `的任何资金。 - -帐户的“总”余额被认为是帐户中“自由”资金的数量减去任何“保留”的资金。保留的资金是根据链上的要求持有的，通常可以通过执行一些链上操作来释放。例如，“身份”模块在注册链上身份时保留资金，但是通过清除身份，您可以取消保留资金并再次释放它们。 - -## 现有存款和回收 - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -如果帐户低于现有存款，则会导致该帐户_被回收_。该帐户以及该地址中的所有资金将从区块链状态中删除，以节省空间。您不会失去对回收地址的访问权限 - 只要您拥有私钥或恢复短语，您仍然可以使用该地址 - 但它需要充值额外的存续金额才能与链进行交互。 - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## 索引 - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## 身份 - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## 代理账户 - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## 多签名账户 - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- 保护您自己的藏匿处：使用其他签署人作为2FA机制来保护您的资金。一个签名者可以在一台计算机上，另一个可以在另一台计算机上，或在冷库中。这减慢了您与链的交互速度，但是安全性提高了几个数量级。 -- 董事会决策：诸如企业和基金会之类的法人实体使用多重签名来共同管理实体的国库。 -- 团体参与治理：多签名帐户可以执行常规帐户可以执行的所有操作。具有多重签名的帐户可以是 Kusama 治理中的理事​​会成员，在该理事会中，一组社区成员可以作为一个实体进行投票。 - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### 生成多重签名帐户的地址 - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### 使用多重签名帐户进行交易 - -There are three types of actions you can take with a multi-sig account: - -- 执行一笔交易 -- 授权一笔交易 -- 撤销一笔交易 - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -存款=存款基数+阈值*存款因子 -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ---- | -------------- | -------------- | ----------------- | --------------- | -| 存款基数 | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| 存款因子 | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## 资源 - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/zh-CN/learn-architecture.md b/website/translated_docs/zh-CN/learn-architecture.md deleted file mode 100644 index 99a1ef74eaba..000000000000 --- a/website/translated_docs/zh-CN/learn-architecture.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: learn-architecture -title: 架构 -sidebar_label: 架构 ---- - -Polkadot 采用共享安全性和可互操作的异构多链结构。 - -## 中继链 (Relay Chain) - -中继链是 Polkadot 的中心链。所有的验证者都在中继链上抵押DOT并验证中继链。中继链仅由相对少量的交易类型构成，包括和治理机制互交，平行链拍卖，参与NPo'S。中继链是可以被设计成具有最精简的功能的 - 例如，中继链并不支持智能合约。中继链的主要只能是负责协调整个系统，包括各个平行链。其他的具体工作应该交予实现不同功能的平行链来执行。 - -## [Parachain](learn-parachains) and [Parathread](learn-parathreads) Slots - -Polkadot can support a number of execution slots. These slots are like cores on a computer's processor (a modern laptop's processor may have eight cores, for example). Each one of these cores can run one process at a time. Polkadot allots these slots using two subscription models: parachains and parathreads. Parachains have a dedicated slot (core) for their chain and are like a process that runs constantly. Parathreads share slots amongst a group, and are thus more like processes that need to be woken up and run less frequently. - -Most of the computation that happens across the Polkadot network as a whole will be delegated to specific parachain or parathread implementations that handle various use cases. Polkadot places no constraints over what parachains are able to do besides that they must be able to generate a proof that can be validated by the validators assigned to the parachain. This proof verifies the state transition of the parachain. Some parachains may be specific to a particular application, others may focus on specific features like smart contracts, privacy, or scalability — still others might be experimental architectures that are not necessarily blockchain in nature. - -Polkadot provides many ways to secure a slot for a parachain slot for a particular length of time. Parathreads are part of a pool that shares slots and must win auctions for individual blocks. Parathreads and parachains have the exact same API; their difference is economic. Parachains will have to reserve DOT for duration of their slot lease; parathreads will pay on a per-block basis. Parathreads can become parachains, and vice-versa. - -## 共享安全性 - -Parachains connected to the Polkadot Relay Chain all share in the security of the Relay Chain. Polkadot has a shared state between the Relay Chain and all of the connected parachains. If the Relay Chain must revert for any reason, then all of the parachains would also revert. This is to ensure that the validity of the entire system can persist and no individual part is corruptible. - -The shared state makes it so that the trust assumptions when using Polkadot parachains are only those of the Relay Chain validator set, and no other. Since the validator set on the Relay Chain is expected to be secure with a large amount of stake put up to back it, it is desirable for parachains to benefit from this security. - -## 角色 - -### 验证人 - -Validators, if elected to the validator set, produce blocks on the Relay Chain. They also accept proofs of valid state transition from collators. In return, they will receive staking rewards. - -### 收集人 - -Collators are full nodes on both a parachain and the Relay Chain. They collect parachain transactions and produce state transition proofs for the validators on the Relay Chain. They can also send and receive messages from other parachains using XCMP. - -### 提名人 - -Nominators bond their stake to particular validators in order to help them get into the active validator set and thus produce blocks for the chain. In return, nominators are generally rewarded with the portion of the staking rewards from that validator. - -## 白板系列 - -For a video overview of the architecture of Polkadot watch the video below for the whiteboard interview with W3F researcher Alistair Stewart: diff --git a/website/translated_docs/zh-CN/learn-availability.md b/website/translated_docs/zh-CN/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/zh-CN/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/zh-CN/learn-balance-transfers.md b/website/translated_docs/zh-CN/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/zh-CN/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/zh-CN/learn-bridges.md b/website/translated_docs/zh-CN/learn-bridges.md deleted file mode 100644 index f53697889345..000000000000 --- a/website/translated_docs/zh-CN/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: 转接桥 -sidebar_label: 转接桥 ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/zh-CN/learn-consensus.md b/website/translated_docs/zh-CN/learn-consensus.md deleted file mode 100644 index fe27fab1e82e..000000000000 --- a/website/translated_docs/zh-CN/learn-consensus.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -id: learn-consensus -title: 波卡共识 -sidebar_label: 波卡共识 -description: 对 Polkadot 和 Kusama 所用的共识解释 ---- - -## 为什么我们需要共识机制？ - -共识是一种在共享状态上达成协议的方法。为了使区块链的状态继续建立并向前进，网络中的所有节点必须达成一致共识。通过这种方式，去中心网络中的节点可以保持彼此同步。在区块链上如果去中心化网络节点没有共识，就无法确保由其他节点共享的状态 是真实的。共识旨在参与者之间提供状态的_客观_事实，每个参与者对网络都有自己的_主观_观点。这些节点间进行通信的过程并达成协议使能够构建新区块。 - -## 什么是 PoW 和 PoS？ - -工作量证明(PoW) 和权益证明(PoS) 已被用来作为区块链共识机制的简称，但这并不能完整地描述其全貌。 PoW是达成区块创造者共识的方法，也是[中本聪共识](#nakamoto-consensus)的一部分，该共识还包含链选择算法(根据比特币中最长链的规则)。同样PoS是用于选择验证人的一组规则并且没有指定链的选择规则或如何达到链的终点。传统上PoS算法已被融合到实现节点之间的拜占庭协议的算法配对。例如[Tendermint](learn-comparisons-cosmos)是实用性拜占庭容错算法，它使用PoS作为其验证人的选择方法。 - -## 为什么不使用工作量证明(PoW)? - -尽管在下一个区块生产者达成去中心化共识方面既简单又有效，但中本聪共识实现的工作量证明却消耗了大量的能源，没有经济的或可证明的终结性，也没有有效的策略来抵抗卡特尔。 - -## 概率性 vs 可证明的最终性 - -PoW 中本聪共识只能实现_概率最终性_并会达到_最终共识_。概率最终性意味着假设在某些网络和参与者之下，如果我们看到多过区块在某个区块上构建了，则有很大概率估计它是最终了。最终共识意味着在接下来的某个时间，所有节点都将就一组数据的真实性达成共识。最终共识可能需要很长时间，并且无法确定需要多长时间。但是例如 GRANDPA 或以太坊的 Casper FFG 之类的最终性工具旨在为区块提供更强的最终性 -​​ 特别是更快的保证，在经过拜占庭协议的某些处理后，它们永远无法篡改。不可逆的共识概念称为_可证明的最终性。_ - -在 GRANDPA 论文中，它的表达方式如下： - -> 如果在没有指定的时间后向所有参与者返回相同的值，oracle A 在协议中是*最终一致*。 - -## 什么是 GRANDPA / BABE? - -### 混合共识 - -在讨论 Polkadot 的共识协议时，我们使用两个首字母缩写词：GRANDPA 和 BABE。我们讨论这两个的原因是因为 Polkadot 使用的是_混合共识_。混合共识从区块生产机制中拆分了最终性工具。 - -这是在 Polkadot 中获得概率最终性（拥有产生新区块的能力）和可证明的最终性（在规范链上具有通用协议，没有任何逆转机会）的好处。它还避免了每种机制的相应缺点（在概率最终性中不知不觉地遵循了错误的分叉的机会，以及在可证明的最终性中存在"过时"的可能性- 无法产生新的区块）。通过结合这两种机制，Polkadot 可以快速生成区块，而较慢的最终机制可以在单独的流程中运行以确定区块，而不会使交易速度变慢或停顿的风险。 - -过去已经提出了混合共识。值得注意的是它被提议(现已不存在)作为以太坊转向[ EIP 1011 ](http://eips.ethereum.org/EIPS/eip-1011)的权益证明过渡的一步。 [ Casper FFG ](#casper-ffg)。 - -### BABE - -BABE (Blind Assignment for Blockchain Extension) 是在验证人节点与决定谁是产生新区块之间的产生区块机制。 BABE 与 Ouroboros Praos 相比，在链选择规则和时段调整方面存在一些关键差异。 BABE 根据抵押和使用 Polkadot [随机性周期](learn-randomness)分配区块生产插槽给验证人。 - -Polkadot 的验证人将会参与在每次的[抽奖](learn-randomness)去决定它们是否在那个时隙的生产区块候选人。时隙是用时间作单位，长度为6秒。由于这种随机性机制，多个验证人可能是同一时隙的候选人。在其余时间，时隙可能为空导致区块时间不一致。 - -#### 同一时隙多个验证人 - -当多个验证人在同一时隙也是区块生产侯选人，全部也会产生区块并广播到网络。那时侯将会是一场比赛。其那个区块到达网络大部分的验证人先获胜。取决于网络拓扑和延迟，两条链都将继续建立一定的容量，直到最终敲定并截断分叉为止。有关其工作原理，请参见下面的"分叉选择"。 - -#### 时隙里没有验证人 - -当没有任何验证人在随机抽奖中达到足够低的资格进行生产区块时，时隙便会没有区块。我们在后台通过运行辅助轮循样式验证人选择算法来避免这种情况。通过选择该算法生成区块的验证人始终生成区块，但是如果同一时隙也从[ VRF 选择](learn-randomness)验证人生成主块，则这些_次要_区块将被忽略。因此时隙可以具有_ 主要 _或_ 次要 _区块，并且不会跳过任何时隙。 - -有关更多 BABE 的详细信息，请参见[正在研究的草案](http://research.web3.foundation/zh/latest/polkadot/BABE/Babe/)。 - -#### Kusama 和 Polkadot 的 BABE 次生块的区别 - -Both Kusama and Polkadot uses the BABE block production mechanism outlined above. However, there is a slight difference in the secondary blocks that are produced between the two networks. Polkadot attaches the VRF output to secondary blocks (and therefore every block contributes to the Epoch randomness), while Kusama keeps the VRF output off the secondary blocks (meaning only the primary blocks contribute to Epoch randomness). The Polkadot method should give stronger randomness as more inputs are collected during every Epoch. Eventually, this change should make its way into Kusama too. - -### GRANDPA: 最终决定性工具 - -GRANDPA (基于 GHOST 的递归祖先派生前缀协议) 是为 Polkadot 中继链实现的最终性工具。 - -只要2/3的节点是诚实的，并且可以在异步设置中处理1/5的拜占庭节点，它就可以作为同步的网络模型中的一部分运行。 - -一个明显的区别是，即使在长期的网络分区或其他网络故障之后，GRANDPA 还是在链上达成协议，而不是在区块上达成协议，从而大大加快了最终性确定的过程。 - -换句话说，一旦超过2/3的验证者证明包含某个块的链，则导致该块的所有块都会立即完成。 - -#### 协议 - -请参阅[该文件](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf)中的标题3以获取该协议的完整说明。 - -#### 实施 - -[Rust 的执行](https://github.com/paritytech/substrate/blob/master/frame/grandpa/src/lib.rs)是 Substrate 框架的一部分。 - -更多详细的相关信息，请参见W3F研究页面上的[GRANDPA 研究页面](https://research.web3.foundation/en/latest/polkadot/GRANDPA.html)。 - -### 分叉选择 - -将 BABE 和 GRANDPA 结合在一起，Polkadot 的分叉选择变得很清晰。 BABE 必 须始终建立在 GRANDPA 最终确定的链条上。当最终确定的头后面有分叉时， BABE 通过在具有最主要区块的链上做构建来提供概率的确定。 - -![最佳链的选择](assets/best_chain.png) - -在上图中，黑色块已确认。一个是主要的，两个是次要的块。即使最上面的链是最新确定的区块上的最长链，它仍然不符合条件，因为在评估时它的基数比下面的基数少。 - -## 共识比较 - -### 中本聪共识 - -中本聪共识包括最长链规则，该规则以工作量证明作为其 sybil 反抗机制和领导者选举。 - -中本聪共识只给了我们概率上的终局性。概率终局性指出，过去的区块仅与其确认数或在其之上构建的区块数一样安全。由于在工作量证明链中特定块之上构建了更多块，因此在此特定链之后花费了更多的计算工作。但是，它不能保证包含该块的链将始终保持商定后的链，因为拥有无限资源的参与者可能会构建竞争链并消耗足够的计算资源以创建不包含特定块的链。在这种情况下，比特币和其他工作链证明中采用的最长链规则将作为规范转移到这一新链上。 - -### PBFT / Tendermint - -请参阅 Cosmos 的比较文章中的[相关部分](learn-comparisons-cosmos#consensus)。 - - - -### Casper FFG - -GRANDPA 和 Casper FFG (友好结局小工具) 之间的两个主要区别是： - -- 在GRANDPA中，不同的选民可以同时为不同高度的区块投票 -- GRANDPA 依靠最终的区块来影响底层区块生产机制的分叉选择规则 - -### Casper CBC - -_未完待续!_ - -## 资源 - -- [ GRANDPA 论文](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf)- GRANDPA 最终确定性工具的描述。 包含算法证明。 -- [Finality Grandpa - Rust 实现](https://github.com/paritytech/finality-grandpa) - 及[ Substrate Runtime 模块](https://github.com/paritytech/substrate/blob/master/srml/grandpa/src/lib.rs)。 -- [Polkadot中的区块生产和确认](https://www.crowdcast.io/e/polkadot-block-production) - 说明了 BABE 和 GRANDPA 如何与 Bill Laboon 合作在Kusama 上生产和确认区块的。 diff --git a/website/translated_docs/zh-CN/learn-crosschain.md b/website/translated_docs/zh-CN/learn-crosschain.md deleted file mode 100644 index 17e0758aedea..000000000000 --- a/website/translated_docs/zh-CN/learn-crosschain.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -id: learn-crosschain -title: 跨链消息传递 (XCMP) -sidebar_label: 跨链消息传递 (XCMP) ---- - -Polkadot使用基于Merkle树的简单排队机制实现跨链交易，并确保其真实性。中继链验证者应负责将某一平行链上输出队列中的交易移至目标平行链上的输入队列中。然而，在此过程中，中继链仅存储相关元数据的哈希值。 - -通常在代码库和相关文档中将输入和输出队列分别成为“入口”和“出口”消息。 - -## XCMP 概述 - -XCMP 目前仍处于开发阶段，其具体细节可能改变。但是，其总体架构的设计决定如下： - -- 跨链消息将_不会_转发至中继链。 -- 跨链消息有长度限制 -- 平行链可以拒绝接收从其它平行链发出的信息，在这种情况下，发送方会意识到有障碍 -- 收集人节点负责把平行链之间的信息传递 -- 收集人产生"出口"列表信息並会在"入口"接收到其它平行链信息 -- 平行链在每个区块中，将会传递所有其它平行链信息 -- 当收集人产生了区块并提交给验证人，它会收集最新入口队列信息并且处理它 -- 验证人将会对收集人提交的平行链区块进行验证，包括处理到该平行链预期入口的信息 - -XCMP queues must be initiated by first opening a channel between two parachains. The channel is identified by both the sender and recipient parachains, meaning that it's a one-way channel. A pair of parachains can have at most two channels between them, one for sending messages to the other chain and another for receiving messages. The channel will require a deposit in DOT to be opened, which will get returned when the channel is closed. - -## 水平中继消息传递（HRMP） - -当 XCMP 协议处于部署阶段时，HRMP 协议将作为其替代方案存在。HRMP 协议与 XCMP 协议具有相同的接口及功能，但是其对资源的需求明显高于 XCMP，原因在于其将所有消息都存储在中继链中。当 XCMP 完成部署时，HRMP 将被逐步淘汰。 - -> 注：stop-gap 协议是原协议功能未完全实现时的临时替代。当 XCMP 仍处于开发过程中时，HRMP 即为其替代协议。 - -## 垂直消息传递 - -垂直消息传递分为两种形式，上行消息传递（UMP）和下行消息传递（DMP）。当消息由一平行链或平行线程产生并传递至中继链时使用UMP。当中继链产生的信息需传递至平行链时使用 UMP。通过 DMP 传递的信息可能在平行链中产生。在此情况下，第一个 UMP 将被用于向中继链传递消息，DMP 用于将该信息下传至另一平行链。 - -## XCMP 消息格式 - -关于 XMCP 消息格式的描述，请参阅 GitHub 上的[xcm-format](https://github.com/paritytech/xcm-format) 库。 - -## XCMP 实例 - -平行链A上存在的智能合约会将一条消息路由到平行链B，在该消息中调用另一个智能合约，该合约在该链中转移某些资产。 - -查理(Charlie) 在平行链A上执行智能合约，这会为平行链B上智能合约的目的地发起新的跨链消息。 - -平行链A的收集人节点会将这个新的跨链消息以及`目的地`和`时间戳`放入其出站消息队列。 - -平行链B的收集人节点会定期 ping 所有其他收集人节点以询问新消息 (通过`destination`字段过滤)。当平行链B的收集人进行下一次 ping 时，它将在平行链A上看到此新消息，并将其添加到自己的入站队列中，以便将它处理到下一个块中。 - -平行链A的验证者还将读取出站队列并知晓消息。平行链B的验证者将执行相同的操作。这样，他们便可以验证消息传输是否发生。 - -当平行链B的收集人正在构建其链上的下一个区块时，它将处理入站队列中的新消息以及可能已找到/接收到的任何其他消息。 - -在处理期间，该消息将在平行链B上执行智能合约并按预期完成资产转移。 - -收集人现在将此块交给验证程序，验证程序它自己将验证此消息是否已处理。如果消息已处理且该区块的所有其他方面均有效，则验证人会将该平行链B的区块包含于中继链中。 - -请查看下面的动画视频，它探讨了 XCMP 的工作原理。 - - - - - - - -## 资源 - -- [XCMP 方案](https://research.web3.foundation/en/latest/polkadot/XCMP.html) - Web3 基金会研究维基上的跨链通信的完整技术描述。 -- [消息传递概述](https://w3f.github.io/parachain-implementers-guide/messaging.html) - 一份来自平行链开发者指南中的消息传递方案概述。 -- [XCM格式](https://github.com/paritytech/xcm-format) - XCMP 格式的说明。 diff --git a/website/translated_docs/zh-CN/learn-cryptography.md b/website/translated_docs/zh-CN/learn-cryptography.md deleted file mode 100644 index dc9b616addd7..000000000000 --- a/website/translated_docs/zh-CN/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: 密码学解释 -sidebar_label: 密码学解释 -description: An overview of the cryptographic functions used in Polkadot ---- - -这是 Polkadot 中使用密码学技术的高级概述。假设你已了解在区块链中常用的密码学术语例如哈希，椭圆曲线密码学(ECC)和公私密钥对。 - -有关所用密码学的详细说明，请参阅我们[研究团队的维基](https://research.web3.foundation)。 - -## 哈希算法 - -在 Polkadot 使用的哈希算法是 [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2)。 Blake2 被认为是非常快的加密哈希函数，也用在 [Zcash](https://z.cash) 加密货币。 - -## 密钥对和签名 - -Polkadot 使用 Schnorrkel/Ristretto x25519 ("sr25519") 作为导出密钥和签名算法。 - -Sr25519 基于 [Curve25519](https://en.wikipedia.org/wiki/Curve25519) 相同的底層作為 EdDSA 的哥哥 [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519) ，但是它使用 Schnorr 簽名而不是 EdDSA 方案。与 ECDSA / EdDSA 方案相比，Schnorr 签名带来了一些明显好处，一方面效率更高，但仍保留相同的功能和安全性假设。另外它允许通过簽名集合方式进行原生多重签名。 - -Schnorrkel 和 Ristretto 名称来自实现该方案的两个 Rust 库，分别为[ Schnorrkel ](https://github.com/w3f/schnorrkel)库用于 Schnorr 签名和 [Ristretto](https://ristretto.group/ristretto.html) 库，使可以用诸如 Curve25519 之类的 cofactor-8 曲线。 diff --git a/website/translated_docs/zh-CN/learn-governance.md b/website/translated_docs/zh-CN/learn-governance.md deleted file mode 100644 index fe8e41c81208..000000000000 --- a/website/translated_docs/zh-CN/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: 治理 -sidebar_label: 治理 ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## 机制 - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## 公投 - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### 公众投票 - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### 议会公投 - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### 投票时间表 - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### 统计 - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **实体** | **指标** | -|:---------:|:---------------------:| -| 大众 | Positive Turnout Bias | -| 议会(一致赞成) | Negative Turnout Bias | -| 议会(大部分赞成) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### 自愿锁定 - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## 议会 - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:---------:|:-:|:-------:|:-:|:-:|:-:| -| **代币持有人** | | **候选人** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **总数** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## 技术委员会 - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/zh-CN/learn-implementations.md b/website/translated_docs/zh-CN/learn-implementations.md deleted file mode 100644 index 1da080a9d3b3..000000000000 --- a/website/translated_docs/zh-CN/learn-implementations.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -id: learn-implementations -title: Polkadot 实现 -sidebar_label: Polkadot 实现 ---- - -这里 Rust，C ++，Go 和 JavaScript 开发都是 Polkadot 不同语言的实现。 - -[** Parity Polkadot **](https://github.com/paritytech/polkadot) - Rust 客户端由 Parity 与他们在[ Substrate ](https://github.com/paritytech/substrate)上的工作。 - -[ ** Kagome **](https://github.com/soramitsu/kagome) - 由 [ Soramitsu ](https://github.com/soramitsu) 实现 C++ Polkadot Host 环境 ，他们是日本的数字身份识别公司，之前开发了[ Hyperledger Iroha ](https://iroha.tech)。他们获得了 Web3 基金会的资助，并计划在[ 2019年11月](https://medium.com/web3foundation/w3f-grants-soramitsu-to-implement-polkadot-runtime-environment-in-c-cf3baa08cbe6)发布。他们正在用 C ++ 开发 libp2p 网络层。 - -[** Gossamer ** ](https://github.com/ChainSafeSystems/gossamer) - 由[ ChainSafe Systems ](https://github.com/ChainSafeSystems)，23人组成在多伦多的开发团队也正在开发 Eth2.0 Serenity 客户程序。[拨款公告](https://medium.com/web3foundation/w3f-grants-chainsafe-to-implement-polkadot-runtime-environment-in-go-ca4973c9edaf)。 - -[**Polkadot-JS**](https://github.com/polkadot-js) - A JavaScript [client](https://github.com/polkadot-js/client) and tool set developed by [Polkadot-JS](https://polkadot.js.org/). - -## 为什么要把 Polkadot 实现多个语言？ - -如 Soramitsu 拨款公告所述: - -> It is critically important to have multiple implementations of the Polkadot protocol for a number of reasons, including decentralization, knowledge dispersion, and better definitions of the protocol... Multiple implementations of Polkadot improves network resilience and adds to the decentralization of the network. The governance of the network is more democratized when multiple teams build clients that run the nodes in the network. diff --git a/website/translated_docs/zh-CN/learn-interchain.md b/website/translated_docs/zh-CN/learn-interchain.md deleted file mode 100644 index b38d2f050bff..000000000000 --- a/website/translated_docs/zh-CN/learn-interchain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: learn-interchain -title: Interchain Message Passing (XCMP) -sidebar_label: Interchain Message Passing (XCMP) ---- - -跨链交易是基于梅克尔树(Merkle tree)利用简单队列机制方案解决确保正确性。这将会是属于在中继链上验证人的工作，把在平行链上出口队列中的交易发送到刻目的地(平行链)的入口队列中。 - -入口和出口队列在代码中通常称为"入口(ingress)"和"出口(egress)"信息。 - -## 概述 - -- 跨链信息*不会*发送到中继链 -- 跨链信息将会限制于字节(bytes)最大值 -- 平行链可以拒绝接收从其它平行链发出的信息，在这种情况下，发送方会意识到有障碍 -- 校对人负责把平行链之间的信息传递 -- 校对人产生"出口"列表信息並会在"入口"接收到其它平行链信息 -- 平行链在每个区块中，将会传递所有其它平行链信息 -- 当校对人产生了区块并提交给验证人，它会收集最新入口队列信息并且处理它 -- 验证人将会对校对人提交的平行链区块进行验证，包括处理到该平行链预期入口的信息 - -## 例子 - -从平行链A里的智能合约发送信息到平行链B里的另一个智能合约，达到链与链之间资产转移。 - -Charlie通过平行链A里的智能合约发起一个新跨链信息到在平行链B的智能合约。 - -平行链A的校对人会把跨链信息连同`目的地(destination)`和`时间(timestamp)`放到出口信息队列中。 - -平行链B的校对人会持续地问其它校对人节点是否有新信息(通过筛选`目的地`)，当平行链B的校对人问是否有新信息时，它会看到从平行链A发送过来的信息并且把它加到下一个区块中的入口队列。 - -平行链A和B的验证人同样也会读取出口队列并且发现该信息，这样它们就可以验证传输中信息。 - -当平行链B的校对人在打包区块的时候，它会处理在入口队列中的新信息和其它发现或接收到的信息。 - -在处理时，平行链B里的智能合约会执行该信息并且完成资产转移。 - -然后校对人提交该区块给验证人，并且核对信息是否处已经处理。如果信息经已处理好和区块中其它方面是有效，验证人便会把该区块包括到中继链上。 - -## 资源 - -- [XCMP Scheme](https://research.web3.foundation/en/latest/polkadot/ICMP.html) - Full technical description of interchain communication on the Web3 Foundation research wiki. diff --git a/website/translated_docs/zh-CN/learn-keys.md b/website/translated_docs/zh-CN/learn-keys.md deleted file mode 100644 index 832129360125..000000000000 --- a/website/translated_docs/zh-CN/learn-keys.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -id: learn-keys -title: Polkadot 密钥 -sidebar_label: Polkadot 密钥 ---- - -公钥和私钥是大多数密码系统的重要部分，也是使像 Polkadot 这样的区块链得以存在的重要组成部分。 - -## 账户密钥 - -帐户密钥是用来控制资金的密钥，它们可以是： - -- 使用 Schnorr 签名的原版` ed25519 `实现。 -- 使用 Schnorr 签名的 Schnorrkel / Ristretto ` sr25519 `。 -- ECDSA signatures on secp256k1 - -对于简单签名，` ed25519 `和` sr25519 `之间的安全性没有区别。 - -我们希望在可预见将来，商用 HSM 将更好地支持` ed25519 `。 - -同时，` sr25519 `使实施更复杂的协议更加安全。 特别是` sr25519 `带有许多协议的安全版本，例如比特币和以太坊生态系统中常见的 HDKD。 - -### "Controller" 和 "Stash" 密钥 - -When we talk about "controller" and "stash" keys, we usually talk about them in the context of running a validator or nominating DOT, but they are useful concepts for all users to know. Both keys are types of account keys. They are distinguished by their intended use, not by an underlying cryptographic difference. All the info mentioned in the parent section applies to these keys. When creating new controller or stash keys, all cryptography supported by account keys are an available option. - -The controller key is a semi-online key that will be in the direct control of a user, and used to submit manual extrinsics. For validators or nominators, this means that the controller key will be used to start or stop validating or nominating. Controller keys should hold some DOT to pay for fees, but they should not be used to hold huge amounts or life savings. Since they will be exposed to the internet with relative frequency, they should be treated carefully and occasionally replaced with new ones. - -Stash 密钥在大多数情况下是保存在冷钱包，写在纸上也可以受硬件安全保护。如果可以的话，它应该很少在互联网上或用于提交交易。 Stash 密钥用于存储大量资金，应该将它视为银行的储蓄帐户，只有在紧急情况下才使用该帐户。或者也许更恰当的隐喻是将其视为埋藏在某个岛屿上的藏宝，并且只有最初隐藏它的海盗才知道。 - -因为 stash 密钥是保储在线下，所以它必须拥有自己的资金绑定到指定的 controller。对于非支出操作，controller 拥有其背后 stash 的资金。例如在提名，抵押或投票，controller 可以指出其偏好 stash 的权重，它永远无法移动或拥有其 stash 的资金。但是如果有人获取了你的 controller 密钥，他们可以利用它做出会被惩罚的操作，所以你应小心保存并且时常更改它。 - -## Session 密钥 - -Session 密钥是热钥，验证人必须将其保持在线才能执行网络操作。 Session 密钥通常在客户端中生成，尽管不是必须。它们_不是_意在控制资金，仅应用于其预期目的。它们可以定期更改。 Controller 仅需要通过 session 公钥签名来创建证书，然后通过外部广播该证书。 - -Polkadot 使用四款 session 密钥: - -- GRANDPA: ed25519 -- BABE: sr25519 -- I'm Online: sr25519 -- Parachain: sr25519 - -BABE 需要适用于[可验证随机函数 (VRF)](learn-randomness#vrfs)以及数字签名的密钥。 Sr25519 密钥具有两种功能，并且可用于 BABE。 - -因为 BLS 密钥允许更高效聚合签名，在将来我们计划在 GRANDPA 使用它。 - -## 常见问题 - -### 为什么在` secp256k1 `上选择了` ed25519 `？ - -为 Polkadot 和 Substrate 链实现的原有密钥导出密码学是` ed25519 `，这是在 Edward's 曲线 25519上实现的 Schnorr 签名算法(由于曲线方程的参数而命名)。 - -大部份加密货币包括比特币, 以太币现在是在 secp256k1 曲线上使用 ECDSA 签名。这曲线被认为比 NIST 曲线安全得多，因为 [NSA 可能有 NIST 曲线的后门](#appendix-a-on-the-security-of-curves)。Curve25519 被认为可能比这_更安全_，并且可以更轻松地实现 Schnorr 签名。最近它的专利即将到期，使它成为在 Polkadot 使用的首选。 - -使用 Schnorr 签名而不是使用 ECDSA 的选择并非人们所预料的。正如 Jeff Burdges (Web3 研究员)所述，[论坛帖子](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70/2): - -> 我们在帐户密钥中选择 Schnorr 签名而不是 ECDSA 做了些牺牲: 两者都需要64字节，但是只有 ECDSA 签名才能传递其公钥。有些过时的 Schnorr 变体支持从签名中恢复公钥，但它们破坏了诸如分层确定性密钥导出之类重要的功能。因此 Schnorr 签名通常会为公钥占用额外的32个字节。 - -但最终使用 Schnorr 签名的好处大于权衡，将来优化可能会解决上述指出的低效率问题。 - -### 什么是 `sr25519` 并它是从何而来? - -某些情况下: Twisted Edward's 曲线25519上的 Schnorr 签名被认为是安全，但是 Ed25519 并没有完全解决其错误。最值得注意的是，[ Monero 和所有其他 CryptoNote 货币](https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html)很容易受到双花的利用，这有可能导致未被发现的无限通胀。 - -这些漏洞的源于是由于 Ed25519 中的特点，即其8的协因子。曲线的协因子是深奥的细节，这可能对更复杂协议的安全实现产生可怕的后果。 - -更方便的是，[ Mike Hamburg's Decaf 论文](https://www.shiftleft.org/paper/decaf/index.xhtml)提供了解决这个潜在错误的途径。 Decaf 基本上是种采用 Twisted Edward's 曲线的协因子和数学变化，以很少的成本性能和获得安全的方法。 - -[ Ristretto Group ](https://ristretto.group/)的 Decaf 论文中的方法得到延伸，并在Rust 中实現，以包含诸如 Curve25519 之类的协因子8曲线，并在 Edward's 曲线上做出 Schnorr 签名使它更安全。 - -Web3 基金会已在[ Schnorrkel ](https://github.com/w3f/schnorrkel)库中的 Curve25519 上使用更安全的 Ristretto 压缩实现了 Schnorr 签名库。 Schnorrkel 在此曲线压缩的基础上实现了相关的协议，例如 HDKD，MuSig 和 VRF。它还包括各种较小的改进，例如哈希方案 STROBE，该方案理论上可以通过 Wasm 进行一次调用就可以处理大量数据。 - -在 Polkadot 中使用的 Schnorr 签名实现和通过 Curve25519 的 Ristretto 压缩 Schnorrkel 协议的实现称为** sr25519 **。 - -### BLS 签名是否在 Polkadot 使用? - -还没有，但是会。 BLS 签名允许更高效的聚合签名。由于 GRANDPA 验证人通常对同一件事情(例如区块)进行签名，所以聚合它们可以使其它协议得到优化。 - -如 BLS 库所述， - -> Boneh-Lynn-Shacham(BLS)签名速度慢，验证速度非常慢，需要慢和低安全性的友好曲线，并且可能造成危险的延展性。 但是 BLS 允许多种的聚合签名选项，这使 BLS 成为共识算法中投票和阈值签名的首选方案。 - -即使 Schnorr 签名允许进行聚合签名，但 BLS 签名在某方面还是更有效。因此它将是 session 密钥之一，供 Polkadot 网络上的验证人使用，并且对于 GRANDPA 最终确定性工具特别重要。 - -## 资源 - -- [对BIP32-Ed25519](https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44) - 论坛帖子详细描述了对 BIP32-Ed25519 的潜在攻击。 向 sr25519 变量过渡的动机。 -- [在 Polkadot 中的账户签名和密钥](https://forum.web3.foundation/t/account-signatures-and-keys-in-polkadot/70) - Web3 研究人员 Jeff Burdges 的帖子。 -- [Schnorr 签名有抗量子计算吗?](https://bitcoin.stackexchange.com/questions/57965/are-schnorr-signatures-quantum-computer-resistant/57977#57977) - -## 附录A: 曲线安全 - -From the [introduction of Curve25519](https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n10) into `libssl`: - -```text -The reason is the following: During summer of 2013, revelations from ex- -consultant at [the] NSA Edward Snowden gave proof that [the] NSA willingly inserts backdoors -into software, hardware components and published standards. While it is still -believed that the mathematics behind ECC (Elliptic-curve cryptography) are still sound and solid, -some people (including Bruce Schneier [SCHNEIER]), showed their lack of confidence -in NIST-published curves such as nistp256, nistp384, nistp521, for which constant -parameters (including the generator point) are defined without explanation. It -is also believed that [the] NSA had a word to say in their definition. These curves -are not the most secure or fastest possible for their key sizes [DJB], and -researchers think it is possible that NSA have ways of cracking NIST curves. -It is also interesting to note that SSH belongs to the list of protocols the NSA -claims to be able to eavesdrop. Having a secure replacement would make passive -attacks much harder if such a backdoor exists. - -However an alternative exists in the form of Curve25519. This algorithm has been -proposed in 2006 by DJB [Curve25519]. Its main strengths are its speed, its -constant-time run time (and resistance against side-channel attacks), and its -lack of nebulous hard-coded constants. -``` diff --git a/website/translated_docs/zh-CN/learn-ledger.md b/website/translated_docs/zh-CN/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/zh-CN/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/zh-CN/learn-parathreads.md b/website/translated_docs/zh-CN/learn-parathreads.md deleted file mode 100644 index d5baa61e32f4..000000000000 --- a/website/translated_docs/zh-CN/learn-parathreads.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: learn-parathreads -title: 平行线程 -sidebar_label: 平行线程 ---- - -Parathreads are an idea for parachains to temporarily participate (on a block by block basis) in Polkadot security without needing to lease a dedicated parachain slot. This is done through economically sharing the scarce resource of a _parachain slot_ among a number of competing resources (parathreads). Chains that otherwise would not be able to acquire a full parachain slot, or do not find it economically sensible to do so, are enabled to participate in Polkadot's shared security — albeit with an associated fee per executed block. It also offers a graceful off-ramp to parachains that no longer require a dedicated parachain slot, but would like to continue using the Relay Chain. - -## 起源 - -根据在成都的[演讲](https://v.douyu.com/show/a4Jj7llO5q47Dk01)，这个想法的起源于于80年代末和90年代早期个人电脑上有限的内存资源概念类似。由于计算机上的内存记忆体资源有限，当某个程序需要更多内存时，计算机可以在硬盘通过使用_交换空间_创建虚拟记数亿体。交换空间允许计算机内存量扩大，权衡取舍并供更多程序同时运行，某些程序需要更长的时间才能完成。 - -## 平行线程 vs. 平行链 - -Parachains and parathreads are very similar from a development perspective. One can imagine that a chain developed with Substrate can at different points in its lifetime assume one of three states: an independent chain with secured bridge, a parachain, or a parathread. It can switch between these last two states with relatively minimal effort since the difference is more of an economic distinction than a technological one. - -平行线程有着跟平行链连接 Polkadot 一样的好处。换句话说通过 ICMP 并受 Polkadot 验证人全面的经济安全保护发送信息到其它平行{链, 线程}。 - -The difference between parachains and parathreads is economic. Parachains must be registered through a normal means of Polkadot, i.e. governance proposal or parachain slot auction. Parathreads have a fixed fee for registration that would realistically be much lower than the cost of acquiring a parachain slot. Similar to how DOT are locked for the duration of parachain slots and then returned to the winner of the auction, the deposit for a parathread will be returned to the parathread after the conclusion of its term. - -除了将平行线程代码注册到 Polkadot 中继链之外，注册平行线程不提供任何保证。当平行线程产生新的区块时，使用方必须支付费用参加每个区块链的拍卖，以使包含在下一个验证的中继链区块。所有已注册的平行线程都将参与拍卖，使将包含其平行线程。 - -有两个关于平行线程的有趣发现。第一，由于它们是逐个区块竞争，这跟比特币和以太坊处理交易相似。同样将会开发费用市场，意味着当繁忙时间使用平行线程，价格将推高，而较少人使用的时侯，费用将会较低。第二，这种机制与平行链机制明显不同，后者只要持有平行链槽保证可用，而注册平行线程没有给予此权利。 - -## 平行线程将如何运作？ - -中继链上的部分平行链槽将被指定为平行线程池的一部分。换句话说某些插槽将没有附上平行链，而是将被用作拍卖平行线程候选区块的空间，供每个区块获胜者使用。 - -Collators will offer a bid designated in DOT for inclusion of a parathread block candidate. The Relay Chain block author is able to select from these bids to include a parathread block. The obvious incentive is for them to accept the block candidate with the highest bid, which would bring them the most profit. The tokens from the parathread bids will likely be split 80-20, meaning that 80% goes into Polkadot treasury and 20% goes to the block author. This is the same split that applies also to transaction fees and, like many other parameters in Polkadot, can be changed through a governance mechanism. - -## 平行线程经济学 - -There are two sources of compensation for collators: - -1. Assuming a parathread has its own local token system, it pays the collators from the transaction fees in its local token. If the parathread does not implement a local token, or its local token has no value (e.g. it is used only for governance), then it can use DOT to incentivize collators. -2. 平行线程协议补贴。平行线程可以创建新代币，为收集人提供额外的奖励。 或许为平行线程创建代币的数量将是按时间函数決定。 包含在中继链中的平行线程区块传递的时间愈多，平行线程愿意补贴的代币越多使區塊被寫入的機會提高。 创建币过程的具体实施可以是通过本地的通胀或通过国库等资金储备。 - -Collators may be paid in local parathread currency. However, the Relay Chain transacts with the Polkadot universal currency (DOT) only. Collators must then submit block candidates with an associated bid in DOT. - -## 平行链插槽交换 - -It will be possible for a parachain that holds a parachain slot to swap this slot with a parathread so that the parathread "upgrades" to a full parachain and the parachain becomes a parathread. The chain can also stop being a chain and continue as a thread without swapping the slot. The slot, if unoccupied, would be auctioned off in the next [auction period](learn-auction). - -This provides a graceful off-ramp for parachains that have reached the end of their lease and do not have sufficient usage to justify renewal; they can remain registered on the Relay Chain but only produce new blocks when they need to. - -Parathreads help ease the sharp stop of the parachain slot term by allowing parachains that are still doing something useful to produce blocks, even if it is no longer economically viable to rent a parachain slot. - -## Resources - -- [Parathreads: Pay-as-you-go Parachains](https://medium.com/polkadot-network/parathreads-pay-as-you-go-parachains-7440d23dde06) diff --git a/website/translated_docs/zh-CN/learn-polkadot-host.md b/website/translated_docs/zh-CN/learn-polkadot-host.md deleted file mode 100644 index ca750924f900..000000000000 --- a/website/translated_docs/zh-CN/learn-polkadot-host.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -id: learn-polkadot-host -title: Polkadot 组件 -sidebar_label: Polkadot 组件 ---- - -Polkadot 的架构可以分为两个不同的部分：Polkadot _runtime_和 Polkadot _主机_。 Polkadot runtime 是链的核心状态转变逻辑，可以在一段时间内升级而不需要硬分叉。 相比 Polkadot 的主机是执行 runtime 的环境并且保持稳定和在 Polkadot 的生命周期内保持静态状态。 - -The Polkadot host interacts with the Polkadot runtime in limited, and well-specified ways. For this reason, implementation teams can build an alternative implementation of the Polkadot host while treating the Polkadot runtime as a black box. For more details of the interactions between the host and the runtime, please see the [specification](https://github.com/w3f/polkadot-spec/). - -## Polkadot 主机组件 - -- 网络组件如 Libp2p 用于网络的交互 。 -- 狀態储存和 storage trie 与数据库 -- GRANDPA 和 BABE 的共识引擎。 -- Wasm 解析器和虚拟机. -- 底层原始的区块链功能例如像密码学的哈希函数。 - -编译了的 Polkadot runtime，Wasm 代码可以上传到 Polkadot 主机并用作执行状态转变的逻辑。没有 runtime，Polkadot 主机无法进行状态转变或生成任何区块。 - -## 图表 - -下面是显示了 Polkadot runtime 周围的 Polkadot 主机图表。试想像 runtime (白色) 作为是一个可以插入、交换或完全删除的组件。灰色中的部分是稳定的，如果没有明确的硬分叉，就不能更改。 - -![polkadot host](assets/updated_pre.png) - -## 资源 - -- [Polkadot Host Protocol Specification](https://github.com/w3f/polkadot-spec) - Incubator for the Polkadot Host spec, including tests. -- [ChainSafe's Go PH](https://github.com/ChainSafeSystems/go-pre) is a 25-person development team based in Toronto, Canada. ChainSafe is building an implementation of the beacon chain for Ethereum 2.0 client in TypeScript and this Go implementation of Polkadot. diff --git a/website/translated_docs/zh-CN/learn-randomness.md b/website/translated_docs/zh-CN/learn-randomness.md deleted file mode 100644 index 4a625983c332..000000000000 --- a/website/translated_docs/zh-CN/learn-randomness.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: learn-randomness -title: 随机性 -sidebar_label: 随机性 ---- - -权益证明(PoS)区块链的随机性对于验证人责任的公平并且不可预测的分配是非常重要。 ，因为计算机是确定性设备，所以它们在随机数方面很差(同样输入总是会产生同样输出)。大部份人通常在计算机上(例如游戏应用程序中)称随机数实际上是_伪随机_- 也就是说它们依赖用户或其他类型的_Oracle_ 提供足够随机的_seed_，例如[气象站的大气噪声](https://www.random.org/randomness/), [心跳率](https://mdpi.altmetric.com/details/47574324)或什至[熔岩灯](https://en.wikipedia.org/wiki/Lavarand)，就可以从中产生一系列看似随机的数字。但是如果给相同的种子，结果将会是一样。 - -这些输入将根据时间和空间而变化，但是不可能将相同的结果输入到全球特定区块链的所有节点中。如果节点获得不同的输入以创建区块，则会发生分叉。显然现实世界中的熵不适合用作区块链随机性的种子。 - -至今区块链有二种可用的随机性方法: RANDAO 和 VRF。 Polkadot 使用 VRF。 - -## VRF - -可验证随机函数(VRF)是数学运算，需要一些输入并产生随机数以及该提交者生成该随机数的真实性证明。任何挑战者都可以验证该证明，以确保随机数生成有效。 - -Polkadot 中使用的 VRF 与 Ouroboros Praos 中的大致相同。 Ouroboros 随机性对于块生产来说是安全并对 BABE 来说效果很好。它们不同之处在于 Polkadot 的 VRF 不依赖于中央时钟(问题变了-谁的中央时钟?)，而是取决于它自己过去结果来确定现在和将来的结果，并且它使用插槽数字作为时钟模拟器估计时间。 - -具体操作如下: - -Slots are discrete units of time six seconds in length. Each slot can contain a block, but may not. Slots make up epochs - on Polkadot, 2400 slots make one epoch, which makes epochs four hours long. - -In every slot, each validator "rolls a die". They execute a function (the VRF) that takes as input the following: - -- **The "secret key",** a key specifically made for these die rolls. -- **An epoch randomness value,** which is The hash of VRF values from the blocks in the epoch before last (N-2), so past randomness has an effect on the current pending randomness (N). -- **时隙号** - -![](assets/VRF_babe.png) - -输出为两个数值: ` RESULT `(随机值)和` PROOF `(证明随机数值已正确生成的证明)。 - -然后将` RESULT `与该协议实现中定义的_阈值 (threshold) _(在 Polkadot Host)进行比较。如果该值小于阈值，那么掷此数字的验证人将是可在该插槽的区块生产候选者。然后，验证人尝试创建一个区块，并将该区块与先前获得的` PROOF `和` RESULT `一起提交到网络中。 - -The fishermen - nodes watching the network for collator and validator wrongdoing - will be verifying Relay Chain blocks. Since an illegal roll will generate an illegal block, and since fishermen will have access to the `RESULT` and `PROOF` in every block produced by a validator, it'll be easy for them to automatically report cheating validators. - -总结: 在 VRF 中，每个验证人都会为自己掷出一个数字，并根据阈值对其进行检查，如果随机掷骰低于该阈值，则会生產區块。 钓鱼人监察网络并报告不良行为验证这些掷骰的有效性，并向系统报告任何作弊行为(例如尽管掷出的人数超过阈值，但有人假装成块生产區塊者)。 - -精明的读者会注意到，这种工作方式某些时隙可能没有验证人作为区块链生产者候选者，因为所有验证候选者的得分都太高而错过了阈值值。我们在[ wiki 共识页面](learn-consensus)中说明了如何解决此问题，并确保 Polkadot 出块时间保持在恒定时间。 - -## RANDAO - -[ RANDAO ](https://github.com/randao/randao) - RANDAO 要求每个验证人通过对某些种子执行一系列哈希操作来进行准备。 验证人然后在一个回合中发布最终的哈希值，加上随机数是从每个参与者进入游戏中得出。只要有一名诚实的验证人参加，随机性就被认为是安全（在经济上进行攻击是不可行）。Polkadot 不选用 VRF 的随机性方法是因为从每个区块生产者处揭示每个时隙的哈希值需要二次带宽或至少二次计算。 - -RANDAO 可选增加VDF。 - -### VDFs - -[Verifiable Delay Functions](https://vdfresearch.org/) are computations that take a prescribed duration of time to complete, even on parallel computers. They produce unique output that can be independently and efficiently verified in a public setting. By feeding the result of RANDAO into a VDF, a delay is introduced that renders any attacker's attempt at influencing the current randomness obsolete. - -VDFs will likely be implemented through ASIC devices that need to be run separately from the other types of nodes. Although only one is enough to keep the system secure, and they will be open source and distributed at nearly no charge, running them is neither cheap nor incentivized, producing unneccessary friction for users of the blockchains opting for this method. - -## 资源 - -- [ Polkadot 对区块链随机性的研究](https://research.web3.foundation/en/latest/polkadot/BABE/Babe.html) - 包含做出选择的理由以及证明 -- [关于 Polkadot 中使用随机性的讨论](https://github.com/paritytech/ink/issues/57) - W3F 研究人员讨论了 Polkadot 中的随机性，何时用以及在哪些假设下进行。 diff --git a/website/translated_docs/zh-CN/learn-registrar.md b/website/translated_docs/zh-CN/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/zh-CN/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/zh-CN/learn-relevant-links.md b/website/translated_docs/zh-CN/learn-relevant-links.md deleted file mode 100644 index 8a34fdcf4d73..000000000000 --- a/website/translated_docs/zh-CN/learn-relevant-links.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -id: learn-relevant-links -title: 链接 -sidebar_label: 链接 ---- - -## 协议 - -### 概述 - -- [Substrate, Polkadot & The Case for On-Chain Governance](https://www.youtube.com/watch?v=eP4mT19S_jg) - Epicenter interviews Gavin Wood. -- [Blockchain Infrastructure](https://softwareengineeringdaily.com/2018/11/26/parity-blockchain-infrastructure-with-gavin-wood/) - Gavin Wood presents Substrate on Software Daily. -- [Polkadot on Zero Knowledge](https://www.zeroknowledge.fm/46) - Gavin Wood chatted about the history of Polkadot and provided a great overview on Zero Knowledge podcast. -- [Epicenter and Polkadot](https://www.youtube.com/watch?v=oiunBLGHlAU) - Epicenter interviews Peter Czaban of Web3 Foundation about Polkadot. -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Interoperability Intro](https://www.youtube.com/watch?v=RSAFHhTwA8Q) - Rob Habermeier presents "Interoperability: Connecting the Dots." -- [Consensus and Finality in Polkadot](https://www.youtube.com/watch?v=qvoAf2uIF3c) - Talk by Rob Habermeier detailing the consensus mechanism for Polkadot. -- [DOT Day Seoul](https://www.youtube.com/playlist?list=PLOyWqupZ-WGt3mA_d9wu74vVe0bM37-39) - Video playlist of all talks at DOT Day Seoul. - -### Kusama - -- [Kusama 首页](https://kusama.network/) Polkadot 的金丝雀网络(Kusama)所有内容的页面。 -- [Kusama 用户指南](https://guide.kusama.network)Kusama 特定信息的来源。 -- [ Kusam 认领](https://claim.kusama.network/)供 DOT 持有者认领 Kusama 代币的资料。 -- [ Kusama 发布公告](https://medium.com/polkadot-network/kusama-network-7446706b8f4c) Kusama 网络的第一条公告。 - -### Substrate - -- [什么是 Substrate?](https://medium.com/paritytech/what-is-substrate-29af4231d7e0)-介绍用于搭建 Polkadot 的框架。 -- [ Parity Substrate ](https://github.com/paritytech/substrate)-第一个用 Rust 编写。Parity Technologies 是一支75人的开发团队，总部位于英国和德国。 Parity 的技术负责运行以太坊的主要客户端，为网络中40％的节点服务。 Parity 还为[比特币](https://github.com/paritytech/parity-bitcoin)维护客户端，并为[Zcash ](https://github.com/ZcashFoundation/zebra)建立客户端。 -- [Substrate Developer Hub](https://substrate.dev/docs/en/) - Overviews, tutorials and reference documentation for Substrate. -- [Substrate 介绍](https://youtu.be/iUMZyL5kTwc)-Gavin Wood 博士介绍 Substrate ，这是 Polkadot 的底层技术。 -- [Substrate 与Polkadot 的关系](https://medium.com/polkadot-network/a-tale-of-two-technologies-presentation-transcript-e7397c1c7a49) - 关于两种技术的详细描述 -- [Polkadot & Substrate 概述](https://www.youtube.com/watchv=0iouzddi5is&feature=youtu.be)-Gavin Wood博士展示了Substrate（区块链框架 + VM）和 Polkadot，并在15分钟内用 Substrate 构建可行的区块链系统 -- [为 Polkadot 的Substrate 发布做准备](https://medium.com/polkadot-network/preparing-for-polkadots-launch-with-substrate-cb97819ed815)-如何在发布之前开始准备 Polkadot 的概述。 -- [A brief summary of everything Substrate and Polkadot](https://medium.com/polkadot-network/a-brief-summary-of-everything-substrate-and-polkadot-f1f21071499d) - Blog post that recaps information regarding Substrate and Polkadot. -- [在Substrate](https://www.youtube.com/watch?v=IRc5Jma_eH8) - Gavin Wood 视频上提供 Substrate 的路线图摘要和 MelonportM-1 会议在 Polkadot 上的更新。 -- [The Relationship between Rust, Substrate and Polkadot](https://www.youtube.com/watch?v=aVW_eG-IH7o&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=8) - Logan Saether, from the technical education team presents a technical explaination of the relationship between Rust, Substrate and Polkadot. - -### 治理 - -- [治理](learn-governance) - 治理系统概述。 -- [治理演示](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734)-Gavin wood 博士介绍了 Polkadot 的初始治理结构。(视频) -- [Kusama 推出和治理](https://polkadot.network/kusama-rollout-and-governance/)-关于 Kusama 金丝雀网络的治理信息。 -- [Polkadot 上的治理](https://www.crowdcast.io/e/governance-on-polkadot--) - 网络研讨会解释治理如何在 Polkadot 和 Kusama 中起作用。 - -### 共识与确定性 - -- [ GRANDPA 确定性工具](https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf)-Polkadot 的确定性工具。 - -### 研究 - -- [ W3F 研究](https://research.web3.foundation)-Web3 基金会研究中心。 - -## 开发 - -- [在 Polkadot 构建的团队](https://forum.web3.foundation/t/teams-building-on-polkadot/67)-在 Polkadot上 构建的团队名单。 - -### Kusama - -- [在 Polkadot 构建的团队](https://forum.web3.foundation/t/teams-building-on-polkadot/67)-在 Polkadot上 构建的团队名单。 -- [样式指南](https://github.com/paritytech/polkadot/wiki/Style-Guide)-为 Polkadot 的 Rust 做贡献。 - -### Polkadot Host - -- [ Polkadot Host 规范](https://github.com/w3f/polkadot-re-spec/blob/master/polkadot_re_spec.pdf)- Polkadot Host 的完整规范。 -- [ Polkadot.js ](https://polkadot.js.org/)-JS中的工具和客户端。Polkadot JS 是由德国的三人团队开发，正在构建 Polkadot 的 JavaScript 实现。 -- [ChainSafe's Go PH](https://github.com/ChainSafeSystems/go-pre) is a 25-person development team based in Toronto, Canada. ChainSafe is building an implementation of the beacon chain for Ethereum 2.0 client in TypeScript and this Go implementation of Polkadot. - -### Cumulus - -- [ Cumulus ](https://github.com/paritytech/cumulus)-使 Substrate 构建的链与 Polkadot 兼容的库。 -- [Cumulus: 深入学习](https://www.youtube.com/watch?v=thgtXq5YMOo)-Polkadot 联合创始人 Robert Habermeier 于2019年3月在EthCC 上的讲话，详细介绍 Cumulus 与平行链的最新进展。 - -### Substrate - -- [ Parity Substrate ](https://github.com/paritytech/substrate)-第一个用 Rust 编写。Parity Technologies 是一支75人的开发团队，总部位于英国和德国。 Parity 的技术负责运行以太坊的主要客户端，为网络中40％的节点服务。 Parity 还为比特币维护客户端，并为Zcash 建立客户端。 -- [Parity Wasm](https://github.com/paritytech/parity-Wasm)- Rust 中的 WebAssembly 序列化/反序列化。 -- [ Wasm utils ](https://github.com/paritytech/Wasm-utils)-用于 Parity 和 Wasm 合同开发的 Wasm 实用程序合集。 - -### Cumulus - -- [ Rust libp2p ](https://github.com/libp2p/rust-libp2p)- libp2p 网络堆栈的 Rust 实现。 - -### Wasm - -- [Parity Bridge](https://github.com/paritytech/parity-bridge)-任意两个基于以太坊的网络之间的转接桥。 - -## 运行节点 - -- [安装 Kusama ](https://github.com/paritytech/polkadot#22-install-kusama-canary-network)-安装 Polkadot 的客户端并连接到 Kusama 金丝雀网络。 -- [Substrate 节点](https://github.com/paritytech/substrate#joining-the-dried-danta-testnet) -在 Dry-Danta 测试网上安装并运行 Substrate 节点。 - -### 用户界面与浏览器 - -- [Polkadot 浏览器](https://polkadot.js.org/apps/#/explorer)-Polkadot 网络浏览器，可用于Alexander、Kusama 网络或您的网络。 -- [Telemetry](http://telemetry.polkadot.io/)-节点的信息服务网站。 -- [ Polkascan ](http://polkascan.io/) - Polkadot 的中继链和Parity Substrate 链上的实时多链数据。 -- [Subscan.io](https://subscan.io) - 基于 Substrate 链的资源管理器。 - -### Crowdcast 网络研讨会 - -- [Polkadot 首页](https://www.crowdcast.io/polkadot) - Web3基金会所有过去 Crowdcast 网络研讨会的列表。 -- [Polkadot 上的治理](https://www.crowdcast.io/e/governance-on-polkadot--) - 网络研讨会解释治理如何在 Polkadot 和 Kusama 中起作用。 -- [Kusama](https://www.crowdcast.io/e/qpz8aran) - Anson Lau 的 Kusama 概述。 -- [Polkadot 上的出块和最终确定性](https://www.crowdcast.io/e/polkadot-block-production) - Bill Laboon 解释在 Kusama BABE 和 GRANDPA 如何一起运作出块和区块确定性。 -- [在 Polkadot 上验证](https://www.crowdcast.io/e/validating-on-polkadot) - 讲解如何在 Polkadot 上验证 与Joe Petrowski 和 Equity Technologies 的 David Dorgan 以及 与 Staked 的 Tim Ogilvie 合作。 -- [了解 Polkadot 中的账户和密钥](https://www.crowdcast.io/e/polkadot-keys) - 解释在 Polkadot 中使用的不同类型的账户和密钥 - Bill Laboon 和 BlockX Labs 的 Chinmay Patel。 -- [参与 Kusama](https://www.crowdcast.io/e/participating-on-kusama) - 如何参与 在 Kusama 不同的角色 - Logan Saether 。 -- [开发应用程序与 Polkadot 交互](https://www.crowdcast.io/e/developing-apps-on-polkadot) 。Bill Laboon 讲解如何通过 Polkadot API 编写你自己的脚本和程序与Polkadot 交互。 -- [将 Web3 登录添加到 Web2.0 应用程序](https://www.crowdcast.io/e/web3-logins-workshop) Bruno Skvorc 解释如何将登录过程添加到 Web2.0 应用程序中。 -- [A Distributed Drawing Program on Kusama](https://www.crowdcast.io/e/distributed-drawing) - Expanding on his previous talk, Bill Laboon uses Shawn Tabrizi's `remarkable` codebase to make a node.js app that listens to the Kusama chain and allows users to set pixels to programmatically draw a shared picture. diff --git a/website/translated_docs/zh-CN/learn-roadmap.md b/website/translated_docs/zh-CN/learn-roadmap.md deleted file mode 100644 index 442657f297dd..000000000000 --- a/website/translated_docs/zh-CN/learn-roadmap.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -id: learn-roadmap -title: 路线图 -sidebar_label: 路线图 ---- - -## Polkadot 发布 - -Polkadot 预计将于今年年底发布。 - -## 路线图 - -随着新功能的完成和推出，Polkadot 目前正在经历一系列概念验证测试网版本。此外，Kusama 是个金丝雀网络，可以测试早期未经审核 Polkadot 版本的经济状况，以帮助理解 Polkadot 最终的目标。 - -- Polkadot Genesis - 预期 2020年中。 -- Kusama - [公告](https://polkadot.network/kusama-network-the-canary-network/)于2019年7月16日。[创世块](https://polkadot.network/kusama-rollout-and-governance/)，于2019年8月23日。[Kusama CC2 ](https://polkadot.network/kusama-cc2/)，于2019年9月26日发布 。 -- Westend - (2020年1月发布) - 基于当前 Kusama codebase 的测试网。 -- PoC-4（发布日期为 2019年4月3日）-_抵押改变和 GRANDPA 优化_ 博客文章 -- PoC-3(于2018年12月21日发布) - 添加了_ GRANDPA 最终决定性工具。 测试网："Alexander" _ [发布博客文章 ](https://medium.com/coinmonks/polkadot-hello-world-3-poc-3-on-substrate-is-here-c45d100f72e3) -- BBQ-Birch 测试网（上线时间：2018年10月15日）：_添加了智能合约支持。_ -- PoC-2 (于2018年7月29日发布) - _添加了对平行链的支持， 奖励和惩罚已添加到 PoS 共识算法中。 测试网: "Krumme Lanke"。 首次通过治理进行自动升级。_ [发布博客文章](https://medium.com/polkadot-network/polkadot-poc-2-is-here-parachains-runtime-upgrades-and-libp2p-networking-7035bb141c25) -- PoC-1 (Released 16 May 2018, Testnet went live 18 May 2018) - _Initial proof of concept - included basic state transition engine for Relay Chain and on-chain governance._ [Release Blog Post](https://medium.com/polkadot-network/now-live-polkadot-proof-of-concept-1-3e718512a8d) - -有关 Polkadot 路线图和 Polkadot 代码库状态的最新信息，请参阅 Polkadot GitHub 库，尤其是里程碑页面：[ https://github.com/paritytech/polkadot/milestones ](https://github.com/paritytech/polkadot/milestones) diff --git a/website/translated_docs/zh-CN/learn-spree.md b/website/translated_docs/zh-CN/learn-spree.md deleted file mode 100644 index b1213ae760fc..000000000000 --- a/website/translated_docs/zh-CN/learn-spree.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: learn-spree -title: SPREE -sidebar_label: SPREE ---- - -Shared Protected Runtime Execution Enclaves (SPREE) sometimes referred to as "trust wormholes," are fragments of logic comparable to runtime modules in Substrate, but live on the Polkadot Relay Chain and may be opted into by parachains. - -SPREE 简要地描述了以下属性和功能： - -- 平行链可以选择加入特殊的 Runtime 逻辑（例如智能合约）。 -- 这些碎片有自己的存储空间和自己的 [XCMP](learn-crosschain) 端点。 -- 跨链的所有实例具有相同的逻辑。 -- It executes alongside parachain logic. -- 受保护：存储不能通过平行链逻辑更改，消息不能被平行链伪造。 - -## 起源 - -On 28 March, 2019 u/Tawaren, a member of the Polkadot community, made a post on [r/dot](https://www.reddit.com/r/dot/) called "SmartProtocols Idea" and laid out a proposal for [Smart Protocols](https://www.reddit.com/r/dot/comments/b6kljn/smartprotocols_idea/). The core insight of the post was that XCMP had a complication in that it was difficult to verify and prove code was executed on a parachain without trust. A solution was to install the SmartProtocols in the Relay Chain that would be isolated blobs of code with their own storage per instance that could only be changed through an interface with each parachain. SmartProtocols are the precursor to SPREE. - -## 什么是 SPREE 模块？ - -SPREE modules are fragments of logic (in concrete terms they are blobs of [WebAssembly](learn-wasm) code) that are uploaded onto Polkadot through a governance mechanism or by parachains. Once the blob is uploaded to Polkadot, all other parachains can decide to opt-in to the logic. The SPREE module would retain its own storage independent of the parachain, but would be callable through an interface with the parachain. Parachains will send messages to the SPREE module synchronously. - -SPREE 模块对整个 XCMP 结构非常重要，因为它为将在目标平行链上执行。虽然 XCMP 保证消息的传递，但它不保证什么代码将执行，即接收平行链将如何解释消息。XCMP 实现去信任传递消息，SPREE 是 XCMP 效用的关键部分。 - -SPREE 模块就像食谱。 例如如果我们向厨师下令制作舒芙蕾，对厨师的能力非常有信心，我们对将要做的事情有模糊的想法，但实际上并不确定如何做。 但是假设某位厨师的书架上有 "SouffléMaker's 手册"，自己只能从这本书制作舒芙蕾。 现在我们还可以查阅厨师所拥有的一本书，了解当我们告诉厨师做舒芙蕾时会发生什么。 在此示例中" 制作舒芙蕾" 是 XCMP 的信息而菜谱是 SPREE 模块。 - -In concrete terms, SPREE modules could be useful for various functionality on Polkadot. One suggested use case of SPREE modules is for a trustless decentralized exchange that is offered as functionality to any parachain without any extra effort from parachain developers. One can imagine this working by having a SPREE module that exposes the interface for the incrementing and decrementing of balances of various assets based on a unique identifier. - -## 为什么? - -Sending messages across parachains in XCMP only ensures that the message will be delivered but does not specify the code that will be executed, or how the message will be interpreted by the receiving parachain. There would be ways around this such as requesting a verifiable receipt of the execution from the receiving parachain, but in the naked case the other parachain would have to be trusted. Having shared code that exists in appendices that the parachain can opt-in to resolves the need for trust and makes the execution of the appendices completely trustless. - -SPREE 将有助于确保在 SPREE 模块平行链之间共享相同的逻辑。一个特别相关的用例将围绕跨平行链代币转移，在发送和接收平行链就如何更改代币的总供应量和基本接口达成一致非常重要。 - -## 例子 - -![spree example](assets/SPREE/spree_module.png) - -上图是简化 Polkadot 的系统。 - -In this diagram we see that the Wasm code for SPREE module "X" has been uploaded to the Polkadot Relay Chain. The two cylinders "A" and "B" represent two distinct parachains that have both opted-in to this SPREE module creating two distinct instances of it with their own XCMP endpoints "A.X" and "B.X". - -在示例中，我们假设此 SPREE 模块 "X" 包含用于递增或递减该模块特定资产的余额。 - -通过在 A.X 处发起交易以将特定余额减少1，XCMP上的消息可以去信任发送到 B.X 以使余额增加1。 - -Collators, represented as the green triangle are responsible for relaying this message from parachain A to parachain B, as well as mantaining the storage for each particular instance of A.X and B.X for their respective parachains. They provide proofs of valid state transitions to the Relay Chain validators, represented as blue diamonds. - -验证人可以通过提供之前的 SPREE 模块实例的状态根和实例之间的 XCMP 消息的数据以及实例的下一个状态根去验证 SPREE 模块的 A.X 和 B.X 正确状态转换。它们执行此验证是对照 SPREE 模块提供的`验证`函数对其进行检查 API。收集人是需要能够提供此信息，以便处理其平行链。 diff --git a/website/translated_docs/zh-CN/learn-staking.md b/website/translated_docs/zh-CN/learn-staking.md deleted file mode 100644 index e7bd2a189d30..000000000000 --- a/website/translated_docs/zh-CN/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: 抵押 -sidebar_label: 抵押 ---- - -波卡(Polkadot) 使用 NPoS(提名权益证明)机制选择验证人，该机制为了**验证人**和 **提名人**两种角色，以实现链安全性的最大化。对网络维护感兴趣的参与者可以负责运行验证人节点。在创世区块中，波卡链将为验证人提供有限位置，位置数量将逐步增加至 1000 以上。 - -系统鼓励 DOT 持有者作为提名人参与。提名人可以支持最多16个他们相信的验证候选人。 - -验证人角色是在 [BABE](learn-consensus#babe) 负责生成区块，验证平行链区块和确保最终性。提名人可以根据验证人抵押量而作选择。 - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## Polkadot 抵押的运作方式 - -### 1. 确定身份 - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. 提名期 - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. 抵押奖励分配 - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. 奖励机制 - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- 验证人本身不持有权益。 -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **验证人池 A** | | | -|:-------:|:----------:|:------:|:----:| -| 提名人 (4) | 权益 (600) | 所占总权益比 | 奖励 | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **验证人池 B** | | | -|:---------:|:----------:|:------:|:----:| -| 提名人 (4) | 权益 (400) | 所占总权益比 | 奖励 | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## 账户 - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** 这帐户储存资金用作绑定 DOTs 参与抵押，但将某些功能委托给 Controller。因此使用 Controller 可以积极参与，其保存 Stash 密钥在冷钱包中，这意味着它永远保持离线状态。您还可以指定代理帐户，对[治理](./learn-governance)议案进行投票。 -- **Controller** 这帐户是代表 Stash 帐户负责发出有关提名和验证的操作。它用于设置奖励发送到那个帐户和佣金。如果你是验证人，它亦用作设定[ session 密钥](learn-keys#session-keys)，并只需要足够的资金来支付交易费用。 - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## 验证人和提名人 - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## 惩罚 (Slashing) - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - 设 x = 出错节点, n = 验证人总数 - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- 提名人可以提名多个验证人，然后通过其中任何一个将惩罚。 -- 在惩罚之前，抵押在各个时代都可以重复使用。 连续提名 E 个时代的 N 币并不意味着您要惩罚 N\*E 币 - 您只有 N 币。 -- 惩罚可在事实发生后发现。 - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## 奖励分配 - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### 领取奖励 - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### 奖励分配例子 - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## 通胀率 - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-轴**: 通货膨胀, 年度化百分比 -- **蓝线**: 参与抵押者的通涨奖励 -- **绿线**: 抵押参与者的收益率 - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## 为什么参与抵押? - -- 当主网上线，每年 10% 通胀率 -- 目标抵押为 50％ -- ~20% 年回报 - -## 为什么不参与抵押? - -- 代币解锁在 Kusama 需要7天，而 Polkadot 则是28天。 -- 如果发现验证人行为不当，将执行处罚（请参见[ #slashing ](#slashing)）。 -- 您将想代币用于平行链插槽。 - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## 资源 - -- [NPoS 在 Polkadot 怎么运作](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Web3 基金会研究员 Alfonso Cevallos 描述 NPoS 在 Polkadot 的博客文章 -- [设置安全验证人](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/zh-CN/learn-transaction-fees.md b/website/translated_docs/zh-CN/learn-transaction-fees.md deleted file mode 100644 index af4497752038..000000000000 --- a/website/translated_docs/zh-CN/learn-transaction-fees.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -id: learn-transaction-fees -title: 交易费用 -sidebar_label: 交易费用 ---- - -区块链网络中的资源是有限的，例如存储和计算。交易费用是用来防止用户消耗太多资源。 Polkadot 使用基于权重的收费模式，而不是 gas-metering 模式。 因此在执行交易之前需要先收取费用；一旦费用支付，节点将执行交易。 - -[Web3 Foundation Research](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html) designed the Polkadot fee system with the following objectives: - -- 每个中继链的区块链应该有效地处理从而被免延迟生成区块链。 -- 中继链的增长率应该有界限。 -- 每个区块都应有空间给特殊高优先的交易，例如不当行为报告。 -- 该系统应能够处理需求激增的问题。 -- 费用应缓慢变化，以便用户可以准确预测既定交易的费用。 - -## 费用计算 - -Polkadot 中继链的费用是根据以下四个参数计算的: - -- 每字节费用 (亦称"长度费") -- 比重费用 -- 小费(可选) - -长度费是每字节的固定费用和交易的字节大小的结果。 - -Weights are a fixed number designed to manage the time it takes to validate a block. Each transaction has a base weight that accounts for the overhead of inclusion (e.g. signature verification) as well as a dispatch weight that accounts for the time to execute the transaction. The total weight is multiplied by a per-weight fee to calculate the transaction's weight fee. - -小费是一种可选的交易费，用户可以添加来给予交易更优先的处理。 - -这四个费用共同构成了费用。在执行交易之前，将从用户的帐户中扣除这笔费用。一部分费用将给区块生成者，其余部分将流向[库房](learn-treasury)。在 Polkadot 的一开始阶段，该比例分别设置为20％和80％。 - -## 区块限制和交易优先 - -Polkadot 中的区块既有最大长度(字节)，也有最大比重。区块生产者将用这些限制填满交易到方块。每个区块的一部分―目前为25%―保留给与该区块操作相关的重要交易。区块生产者将只能使用区块正常交易的75%。一些操作交易例子： - -- 错误报告 -- 议会操作 -- 选举中的成员操作(例如放弃候选人) - -区块生产者根据每笔交易的总费用确定交易的优先次序。由于部分费用将给区块生产者，生产者将打包最高费用的交易，以获得最大回报。 - -## 费用调整 - -区块链上的交易量非常不正常，因此交易费用需要一种调整机制。然而，用户应该能够预测交易费用。 - -Polkadot 使用缓慢调整费用机制并提供小费来平衡这两个考虑。除了区块链_限制，_ Polkadot 还有阻止填满的_目标。_根据当前区块相对于目标的充满度，下一个区块链的费用增加或减少。每次比重收费可在24小时内提高30％，这个比率反映出需求的长期趋势， 为了考虑短期跳跃，Polkadot 在底线，字节和重量费用上使用小费。用户可以选择在收费中添加小费，给予交易更高的优先等级。 - -## 分片交易 - -在 Polkadot 的分片中进行的交易 - 平行链和对平行线程 - 不会引起中继链交易费用。 分片应用程序的用户甚至不需要持有 DOT， 因为每个分片都有自己的经济模式，可能有代币，也可能没有代币。 然而在有些情况下，这些人自己在中继链上进行交易。 - -[Parachains](learn-parachains) have a dedicated slot on the Relay Chain for execution, so their collators do not need to own DOT in order to include blocks. The parachain will make some transactions itself, for example, opening or closing an [XCMP](learn-crosschain) channel, participating in an [auction](learn-auction) to renew its slot, or upgrading its runtime. Parachains have their own accounts on the Relay Chain and will need to use those funds to issue transactions on the parachain's behalf. - -[Parathreads](learn-parathreads) will also make all the same transactions that a parachain might. In addition, the collators need to participate in an auction every block to progress their chain. The collators will need to have DOT to participate in these auctions. - -## 其他资源限制策略 - -交易比重必须在执行前可以计算，因此只能是固定逻辑。有些交易需要通过其他策略限制资源。例如: - -- 绑定(Bonds)：有些交易，如投票，有可能需要绑定保证金， 并在链上发生事件后退还或惩罚。 在投票的例子中，选举结束时返回，或者如果选民试图恶意行事，就会被惩罚。 -- 存款(Deposits): 有些交易, 如设置[身份](learn-identity) 或认领索引, 无限期地使用存储空间。 如果用户决定释放存储空间，这些存款将会被退还。 -- 烧毁(Burns)：交易可能会根据其内部逻辑烧毁资金。例如如果交易创建了新的存储，从而增加了状态容量，则交易可能会从用户那里烧毁资金。 -- Limits: Some limits are part of the protocol. For example, nominators can only nominate 16 validators. This limits the complexity of [Phragmén](learn-phragmen). - -## 进阶 - -此页面仅涵盖来自普通用户的交易。 不过，如果你看到區塊鏈浏览器的區块，你可能会看到一些"extrinsics"看起来与这些交易不同。 在 Polkadot (以及建立在Substrate 上的任何链)中，extrinsic 在是一种来自链外的信息。 Extrinsics 可分为三类： - -- 签名交易 -- 无签名交易 -- Inherents - -此页面仅覆盖已签名的交易(signed transactions)，这是大多数用户与 Polkadot 互动的方式。 有签名的交易来自有资金的帐户，因此 Polkadot 可以收取交易费作为防止垃圾邮件的问题。 - -无签名的交易(unsigned transactions) 是指用户需要提交不控制资金的密钥对外在的特殊情况。 例如当用户在上线后 [领取他们的 DOT ](https://claims.polkadot.network) 他们的 DOT 地址还没有任何资金，因此是用了无签名的交易。验证人也会提交一些无签名的交易，其形式为 "heartbeat" 消息，表示它们在线。 这些 heartbeat 必须由验证人 [session keys 之一](learn-keys)签名。 Session keys 永远不会控制资金。 无签名的交易仅用于特殊情况，因为既然 Polkadot 无法为它们收取费用，每个交易需要自定义的验证逻辑。 - -最后，inherents 是没有签名或包含在交易队列中的信息。 因此，只有出块的人才能将固有的东西添加到区块中。 因为仅仅足够多的验证人已经同意它们是合理，就假定不信守者为 "真理"。 例如 Polkadot 区块包括固有的时间戳。 没有办法证明时间戳是真实的，可以证明有签字的资金的发出。 相反验证人根据他们认为时间戳的合理程度接受或拒绝区块。 在《Polkadot》中，它必须在他们自己的系统时钟的某个可接受范围之内。 - -## 了解更多 - -- [Web3 Foundation Research](https://research.web3.foundation/en/latest/polkadot/Token%20Economics.html#relay-chain-transaction-fees-and-per-block-transaction-limits) -- [Substrate Weights](https://substrate.dev/docs/en/knowledgebase/learn-substrate/weight) -- [Substrate 费用](https://substrate.dev/docs/en/knowledgebase/runtime/fees) -- [交易 (Extrinsics)](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics) diff --git a/website/translated_docs/zh-CN/learn-treasury.md b/website/translated_docs/zh-CN/learn-treasury.md deleted file mode 100644 index d76babd837c6..000000000000 --- a/website/translated_docs/zh-CN/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- 基础架构部署 -- 网络安全操作(监视服务，审核)。 -- 生态系统发展(与友好链的合作)。 -- 推广活动(广告，合作)。 -- 社区活动(聚会，比萨派对，黑客空间)。 -- 软件开发(钱包和钱包整合，客户端升级)。 - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/zh-CN/learn-validator.md b/website/translated_docs/zh-CN/learn-validator.md deleted file mode 100644 index cb38899adddf..000000000000 --- a/website/translated_docs/zh-CN/learn-validator.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: learn-validator -title: 验证人 -sidebar_label: 验证人 ---- - -Validators secure the Relay Chain by staking DOT, validating proofs from collators and participating in consensus with other validators. - -这些参与者将在向中继链以及所有平行链添加新区块方面发挥关键作用。这允许各方通过中继链完成跨链交易。 - -Validators perform two functions. First, verifying that the information contained in an assigned set of parachain blocks is valid (such as the identities of the transacting parties and the subject matter of the contract). Their second role is to participate in the consensus mechanism to produce the Relay Chain blocks based on validity statements from other validators. Any instances of non-compliance with the consensus algorithms result in punishment by removal of some or all of the validator’s staked DOT, thereby discouraging bad actors. Good performance, however, will be rewarded, with validators receiving block rewards (including transaction fees) in the form of DOT in exchange for their activities. - -## 指南 - -- [How to Validate on Polkadot](maintain-guides-how-to-validate-polkadot) - Guide on how to set up a validator on the Polkadot live network. -- [验证人奖励发放概述](maintain-guides-validator-payout) - 简短概述验证人奖励发放机制原理。 -- [如何将验证人程序作为 systemd 进程运行](maintain-guides-how-to-systemd)-有关将验证人程序作为` systemd `进程运行的指南 ，使它在背后运行，并当重新启动时自动启动。 -- [如何升级您的验证人](maintain-guides-how-to-upgrade) - 当要转换到另一台计算机或运行最新版本的客户端时 - 升级验证人指南。 -- [如何使用安全验证人设置](maintain-guides-how-to-use-polkadot-secure-validator) - 关于如何使用 Polkadot / Kusama 安全验证器设置的指南 。 - -## 其他参考 - -- [如何运行 Polkadot 节点 (Docker)](https://medium.com/@acvlls/setting-up-a-maintain-the-easy-way-3a885283091f) -- [Web 3.0 验证人节点的无服务器故障转移解决方案](https://medium.com/hackernoon/a-serverless-failover-solution-for-web-3-0-validator-nodes-e26b9d24c71d) - 博客详细介绍了如何创建可靠的故障转移解决方案运行验证人。 -- [云服务器清单](maintain-guides-how-to-validate-kusama#vps-list) -- [Polkadot 验证人休息室](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) - 验证人聊天室。 -- [ 惩罚(Slashing)后果](https://wiki.polkadot.network/docs/en/learn-staking#slashing) -了解更多有关运行验证人节点惩罚(Slashing)的后果。 -- [Why You Should be A Validator on Polkadot and Kusama](https://www.youtube.com/watch?v=0EmP0s6JOW4&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=2) -- [Roles and Responsibilities of a Validator](https://www.youtube.com/watch?v=riVg_Up_fCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=15) -- [Validating on Polkadot](https://www.crowdcast.io/e/validating-on-polkadot) - An explanation of how to validate on Polkadot, with Joe Petrowski and David Dorgan of Parity Technologies, along with Tim Ogilvie from Staked. - -## 安全 / 密钥管理 - -- [验证人安全概览](https://github.com/w3f/validator-security) - -## 监控工具 - -- [PANIC for Polkadot](https://github.com/SimplyVC/panic_polkadot) - Polkadot / Kusama 节点的监视和警报方案 -- [Polkadot Telemetry 服务](https://telemetry.polkadot.io/#list/Kusama%20CC3) - 网络信息，包括在某一条链上有什么节点在运行，正在运行的版本以及同步状态。 -- [其它有用链接](https://forum.web3.foundation/t/useful-links-for-validators/20) - -## 验证人统计 - -- [HashQuark Staking Strategy](https://polkacube.hashquark.io/#/polkadot/strategy) - The HashQuark staking strategy dashboard helps you choose the optimal set-up to maximize rewards, and provides other useful network monitoring tools. -- [ Polkastats ](https://polkastats.io/) - Polkastats 是验证程序的精心设计的网页 -- [YieldScan](https://yieldscan.onrender.com/) - Staking yield maximization platform, designed to minimize effort. -- [ Subscan 验证人页面](https://kusama.subscan.io/validator) - 显示当前验证人的信息 - 不像其他站点那样适合验证人。 diff --git a/website/translated_docs/zh-CN/maintain-errors.md b/website/translated_docs/zh-CN/maintain-errors.md deleted file mode 100644 index b292a3c7f25a..000000000000 --- a/website/translated_docs/zh-CN/maintain-errors.md +++ /dev/null @@ -1,277 +0,0 @@ ---- -id: maintain-errors -title: 出现错误如何解决 -sidebar_label: 解决错误 ---- - -Errors in Substrate-based chains are usually accompanied by descriptive messages. However, to read these messages, a tool parsing the blockchain data needs to request _chain metadata_ from a node. That metadata explains how to read the messages. One such tool with a built-in parser for chain metadata is the [Polkadot-JS Apps UI](https://polkadot.js.org/apps). - -If this page does not answer your question, try searching for your problem at the [Polkadot Knowledge Base](https://support.polkadot.network/) for more information on troubleshooting your issue. - -## PolkadotJS Apps 浏览器 - -Here's how to find out the detailed error description through Polkadot-JS Apps. - -A typical failed transactions looks something like this: - -![Error while sending a transaction](/img/errors/01.jpg) - -The image displays only the error name as defined in the code, not its error message. Despite this error being rather self-explanatory, let's find its details. - -In the [explorer tab](https://polkadot.js.org/apps/#/explorer), find the block in which this failure occured. Then, expand the `system.ExtrinsicFailed` frame: - -![Error described](/img/errors/02.jpg) - -Notice how the `details` field contains a human-readable description of the error. Most errors will have this, if looked up this way. - -[This block](https://polkadot.js.org/apps/#/explorer/query/0xa10104ed21dfe409c7871a975155766c5dd97e1e2ac7faf3c90f1f8dca89104b) is a live example of the above. - -If you cannot look up the error this way, or there is no message in the `details` field, consult the table below. - -## Polkascan and Subscan - -Polkascan and Subscan show the `ExtrinsicFailed` event when a transaction does not succeed ([example](https://polkascan.io/polkadot/event/2836233-3)). This event gives us the `error` and `index` indices of the error but does not give us a nice message to understand what it means. We will look up the error in the codebase ourselves to understand what went wrong. - -First, we should understand that the `index` number is the index of the pallet in the runtime from which the error originated. The `error` is likewise the index of that pallet's errors which is the exact one we're looking for. Both of these indices start counting from 0. - -For example, if `index` is 5 and `error` is 3, as in the example linked above, we need to look at the runtime for the fourth error (index 3) in the sixth pallet (index 5). - -By looking at the [runtime code](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/lib.rs#L914) we see that the pallet at index 5 is "Balances". Now we will check the Balances pallet's code which is hosted in the Substrate repository, and look for the fourth error in the Error enum. According to [its source](https://github.com/paritytech/substrate/blob/master/frame/balances/src/lib.rs#L270) the error that we got is `InsufficientBalance` or in other words "Balance too low to send value". - -## Common Errors - -The table below lists the most commonly encountered errors and ways to resolve them. - -| 錯誤 | 描述 | 解决方案 | -| ------------------ | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | -| BadOrigin | 不允许您执行此操作，例如尝试使用非议会帐户创建议会动议。 | 要么切换到具有必要权限的帐户，要么检查您试图执行的操作是否被允许(例如调用 `system.setCode` 直接进行 runtime 升级，无需通过投票)。 | -| BadProof | 交易签名似乎无效。 | 您所连接的节点可能会跟随一个过时的分叉—通常待它同步好后再次尝试问题会被解决。 要检查更大的问题，检查您所连接的节点的最后一个最终确定了和当前最佳的区块，并将这些值与其他公开的节点数据进行比较 - 它们是否在同步？ 如果没有，请尝试连接到另一个节点。 | -| Future | 交易 nonce 太高。 | 减少 nonce 为当前 +1。检查您正在使用的发送交易的地址。 | -| Stale | 交易 nonce 太低。 | 将当前的 nonce +1。检查您正在使用发送交易地址的 nonce。 | -| ExhaustsResources | 当前的区块没有足够的资源来提交这笔交易。 | 请在下一个区块中再试一次。 | -| Payment | 无法支付交易费用。 | 您可能没有足够可用的余额来支付这笔交易所需的费用。 | -| Temporarily banned | The transaction is temporarily banned. | The tx is already in pool. Either try on a different node, or wait to see if the initial transaction goes through. | - -## Error Table - -The below table is a reference to the errors that exists in Polkadot. It is generated from the runtime's metadata. - -| Pallet | Error | Documentation | -| ----------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -| System (0) | | | -| | InvalidSpecName (0) | The name of specification does not match between the current runtime and the new runtime. | -| | SpecVersionNeedsToIncrease (1) | The specification version is not allowed to decrease between the current runtime and the new runtime. | -| | FailedToExtractRuntimeVersion (2) | Failed to extract the runtime version from the new runtime. Either calling `Core_version` or decoding `RuntimeVersion` failed. | -| | NonDefaultComposite (3) | Suicide called when the account has non-default composite data. | -| | NonZeroRefCount (4) | There is a non-zero reference count preventing the account from being purged. | -| Scheduler (1) | | | -| | FailedToSchedule (0) | Failed to schedule a call | -| | NotFound (1) | Cannot find the scheduled call. | -| | TargetBlockNumberInPast (2) | Given target block number is in the past. | -| | RescheduleNoChange (3) | Reschedule failed because it does not change scheduled time. | -| Balances (5) | | | -| | VestingBalance (0) | Vesting balance too high to send value | -| | LiquidityRestrictions (1) | Account liquidity restrictions prevent withdrawal | -| | Overflow (2) | Got an overflow after adding | -| | InsufficientBalance (3) | Balance too low to send value | -| | ExistentialDeposit (4) | Value too low to create account due to existential deposit | -| | KeepAlive (5) | Transfer/payment would kill account | -| | ExistingVestingSchedule (6) | A vesting schedule already exists for this account | -| | DeadAccount (7) | Beneficiary account must pre-exist | -| Authorship (6) | | | -| | InvalidUncleParent (0) | The uncle parent not in the chain. | -| | UnclesAlreadySet (1) | Uncles already set in the block. | -| | TooManyUncles (2) | Too many uncles. | -| | GenesisUncle (3) | The uncle is genesis. | -| | TooHighUncle (4) | The uncle is too high in chain. | -| | UncleAlreadyIncluded (5) | The uncle is already included. | -| | OldUncle (6) | The uncle isn't recent enough to be included. | -| Staking (7) | | | -| | NotController (0) | Not a controller account. | -| | NotStash (1) | Not a stash account. | -| | AlreadyBonded (2) | Stash is already bonded. | -| | AlreadyPaired (3) | Controller is already paired. | -| | EmptyTargets (4) | Targets cannot be empty. | -| | DuplicateIndex (5) | Duplicate index. | -| | InvalidSlashIndex (6) | Slash record index out of bounds. | -| | InsufficientValue (7) | Can not bond with value less than minimum balance. | -| | NoMoreChunks (8) | Can not schedule more unlock chunks. | -| | NoUnlockChunk (9) | Can not rebond without unlocking chunks. | -| | FundedTarget (10) | Attempting to target a stash that still has funds. | -| | InvalidEraToReward (11) | Invalid era to reward. | -| | InvalidNumberOfNominations (12) | Invalid number of nominations. | -| | NotSortedAndUnique (13) | Items are not sorted and unique. | -| | AlreadyClaimed (14) | Rewards for this era have already been claimed for this validator. | -| | OffchainElectionEarlySubmission (15) | The submitted result is received out of the open window. | -| | OffchainElectionWeakSubmission (16) | The submitted result is not as good as the one stored on chain. | -| | SnapshotUnavailable (17) | The snapshot data of the current window is missing. | -| | OffchainElectionBogusWinnerCount (18) | Incorrect number of winners were presented. | -| | OffchainElectionBogusWinner (19) | One of the submitted winners is not an active candidate on chain (index is out of range in snapshot). | -| | OffchainElectionBogusCompact (20) | Error while building the assignment type from the compact. This can happen if an index is invalid, or if the weights _overflow_. | -| | OffchainElectionBogusNominator (21) | One of the submitted nominators is not an active nominator on chain. | -| | OffchainElectionBogusNomination (22) | One of the submitted nominators has an edge to which they have not voted on chain. | -| | OffchainElectionSlashedNomination (23) | One of the submitted nominators has an edge which is submitted before the last non-zero slash of the target. | -| | OffchainElectionBogusSelfVote (24) | A self vote must only be originated from a validator to ONLY themselves. | -| | OffchainElectionBogusEdge (25) | The submitted result has unknown edges that are not among the presented winners. | -| | OffchainElectionBogusScore (26) | The claimed score does not match with the one computed from the data. | -| | OffchainElectionBogusElectionSize (27) | The election size is invalid. | -| | CallNotAllowed (28) | The call is not allowed at the given time due to restrictions of election period. | -| | IncorrectHistoryDepth (29) | Incorrect previous history depth input provided. | -| | IncorrectSlashingSpans (30) | Incorrect number of slashing spans provided. | -| Session (9) | | | -| | InvalidProof (0) | Invalid ownership proof. | -| | NoAssociatedValidatorId (1) | No associated validator ID for account. | -| | DuplicatedKey (2) | Registered duplicate key. | -| | NoKeys (3) | No keys are associated with this account. | -| Grandpa (11) | | | -| | PauseFailed (0) | Attempt to signal GRANDPA pause when the authority set isn't live (either paused or already pending pause). | -| | ResumeFailed (1) | Attempt to signal GRANDPA resume when the authority set isn't paused (either live or already pending resume). | -| | ChangePending (2) | Attempt to signal GRANDPA change with one already pending. | -| | TooSoon (3) | Cannot signal forced change so soon after last. | -| | InvalidKeyOwnershipProof (4) | A key ownership proof provided as part of an equivocation report is invalid. | -| | InvalidEquivocationProof (5) | An equivocation proof provided as part of an equivocation report is invalid. | -| | DuplicateOffenceReport (6) | A given equivocation report is valid but already previously reported. | -| ImOnline (12) | | | -| | InvalidKey (0) | Non existent public key. | -| | DuplicatedHeartbeat (1) | Duplicated heartbeat. | -| Democracy (14) | | | -| | ValueLow (0) | Value too low | -| | ProposalMissing (1) | Proposal does not exist | -| | BadIndex (2) | Unknown index | -| | AlreadyCanceled (3) | Cannot cancel the same proposal twice | -| | DuplicateProposal (4) | Proposal already made | -| | ProposalBlacklisted (5) | Proposal still blacklisted | -| | NotSimpleMajority (6) | Next external proposal not simple majority | -| | InvalidHash (7) | Invalid hash | -| | NoProposal (8) | No external proposal | -| | AlreadyVetoed (9) | Identity may not veto a proposal twice | -| | NotDelegated (10) | Not delegated | -| | DuplicatePreimage (11) | Preimage already noted | -| | NotImminent (12) | Not imminent | -| | TooEarly (13) | Too early | -| | Imminent (14) | Imminent | -| | PreimageMissing (15) | Preimage not found | -| | ReferendumInvalid (16) | Vote given for invalid referendum | -| | PreimageInvalid (17) | Invalid preimage | -| | NoneWaiting (18) | No proposals waiting | -| | NotLocked (19) | The target account does not have a lock. | -| | NotExpired (20) | The lock on the account to be unlocked has not yet expired. | -| | NotVoter (21) | The given account did not vote on the referendum. | -| | NoPermission (22) | The actor has no permission to conduct the action. | -| | AlreadyDelegating (23) | The account is already delegating. | -| | Overflow (24) | An unexpected integer overflow occurred. | -| | Underflow (25) | An unexpected integer underflow occurred. | -| | InsufficientFunds (26) | Too high a balance was provided that the account cannot afford. | -| | NotDelegating (27) | The account is not currently delegating. | -| | VotesExist (28) | The account currently has votes attached to it and the operation cannot succeed until these are removed, either through `unvote` or `reap_vote`. | -| | InstantNotAllowed (29) | The instant referendum origin is currently disallowed. | -| | Nonsense (30) | Delegation to oneself makes no sense. | -| | WrongUpperBound (31) | Invalid upper bound. | -| | MaxVotesReached (32) | Maximum number of votes reached. | -| | InvalidWitness (33) | The provided witness data is wrong. | -| | TooManyProposals (34) | Maximum number of proposals reached. | -| Council (15) | | | -| | NotMember (0) | Account is not a member | -| | DuplicateProposal (1) | Duplicate proposals not allowed | -| | ProposalMissing (2) | Proposal must exist | -| | WrongIndex (3) | Mismatched index | -| | DuplicateVote (4) | Duplicate vote ignored | -| | AlreadyInitialized (5) | Members are already initialized! | -| | TooEarly (6) | The close call was made too early, before the end of the voting. | -| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | -| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | -| | WrongProposalLength (9) | The given length bound for the proposal was too low. | -| TechnicalCommittee (16) | | | -| | NotMember (0) | Account is not a member | -| | DuplicateProposal (1) | Duplicate proposals not allowed | -| | ProposalMissing (2) | Proposal must exist | -| | WrongIndex (3) | Mismatched index | -| | DuplicateVote (4) | Duplicate vote ignored | -| | AlreadyInitialized (5) | Members are already initialized! | -| | TooEarly (6) | The close call was made too early, before the end of the voting. | -| | TooManyProposals (7) | There can only be a maximum of `MaxProposals` active proposals. | -| | WrongProposalWeight (8) | The given weight bound for the proposal was too low. | -| | WrongProposalLength (9) | The given length bound for the proposal was too low. | -| ElectionsPhragmen (17) | | | -| | UnableToVote (0) | Cannot vote when no candidates or members exist. | -| | NoVotes (1) | Must vote for at least one candidate. | -| | TooManyVotes (2) | Cannot vote more than candidates. | -| | MaximumVotesExceeded (3) | Cannot vote more than maximum allowed. | -| | LowBalance (4) | Cannot vote with stake less than minimum balance. | -| | UnableToPayBond (5) | Voter can not pay voting bond. | -| | MustBeVoter (6) | Must be a voter. | -| | ReportSelf (7) | Cannot report self. | -| | DuplicatedCandidate (8) | Duplicated candidate submission. | -| | MemberSubmit (9) | Member cannot re-submit candidacy. | -| | RunnerSubmit (10) | Runner cannot re-submit candidacy. | -| | InsufficientCandidateFunds (11) | Candidate does not have enough funds. | -| | NotMember (12) | Not a member. | -| | InvalidCandidateCount (13) | The provided count of number of candidates is incorrect. | -| | InvalidVoteCount (14) | The provided count of number of votes is incorrect. | -| | InvalidRenouncing (15) | The renouncing origin presented a wrong `Renouncing` parameter. | -| | InvalidReplacement (16) | Prediction regarding replacement after member removal is wrong. | -| Treasury (19) | | | -| | InsufficientProposersBalance (0) | Proposer's balance is too low. | -| | InvalidIndex (1) | No proposal or bounty at that index. | -| | ReasonTooBig (2) | The reason given is just too big. | -| | AlreadyKnown (3) | The tip was already found/started. | -| | UnknownTip (4) | The tip hash is unknown. | -| | NotFinder (5) | The account attempting to retract the tip is not the finder of the tip. | -| | StillOpen (6) | The tip cannot be claimed/closed because there are not enough tippers yet. | -| | Premature (7) | The tip cannot be claimed/closed because it's still in the countdown period. | -| | UnexpectedStatus (8) | The bounty status is unexpected. | -| | RequireCurator (9) | Require bounty curator. | -| | InvalidValue (10) | Invalid bounty value. | -| | InvalidFee (11) | Invalid bounty fee. | -| | PendingPayout (12) | A bounty payout is pending. To cancel the bounty, you must unassign and slash the curator. | -| Claims (24) | | | -| | InvalidEthereumSignature (0) | Invalid Ethereum signature. | -| | SignerHasNoClaim (1) | Ethereum address has no claim. | -| | SenderHasNoClaim (2) | Account ID sending tx has no claim. | -| | PotUnderflow (3) | There's not enough in the pot to pay out some unvested amount. Generally implies a logic error. | -| | InvalidStatement (4) | A needed statement was not included. | -| | VestedBalanceExists (5) | The account already has a vested balance. | -| Vesting (25) | | | -| | NotVesting (0) | The account given is not vesting. | -| | ExistingVestingSchedule (1) | An existing vesting schedule already exists for this account that cannot be clobbered. | -| | AmountLow (2) | Amount being transferred is too low to create a vesting schedule. | -| Identity (28) | | | -| | TooManySubAccounts (0) | Too many subs-accounts. | -| | NotFound (1) | Account isn't found. | -| | NotNamed (2) | Account isn't named. | -| | EmptyIndex (3) | Empty index. | -| | FeeChanged (4) | Fee is changed. | -| | NoIdentity (5) | No identity found. | -| | StickyJudgement (6) | Sticky judgement. | -| | JudgementGiven (7) | Judgement given. | -| | InvalidJudgement (8) | Invalid judgement. | -| | InvalidIndex (9) | The index is invalid. | -| | InvalidTarget (10) | The target is invalid. | -| | TooManyFields (11) | Too many additional fields. | -| | TooManyRegistrars (12) | Maximum amount of registrars reached. Cannot add any more. | -| | AlreadyClaimed (13) | Account ID is already named. | -| | NotSub (14) | Sender is not a sub-account. | -| | NotOwned (15) | Sub-account isn't owned by sender. | -| Proxy (29) | | | -| | TooMany (0) | There are too many proxies registered or too many announcements pending. | -| | NotFound (1) | Proxy registration not found. | -| | NotProxy (2) | Sender is not a proxy of the account to be proxied. | -| | Unproxyable (3) | A call which is incompatible with the proxy type's filter was attempted. | -| | Duplicate (4) | Account is already a proxy. | -| | NoPermission (5) | Call may not be made by proxy because it may escalate its privileges. | -| | Unannounced (6) | Announcement, if made at all, was made too recently. | -| Multisig (30) | | | -| | MinimumThreshold (0) | Threshold must be 2 or greater. | -| | AlreadyApproved (1) | Call is already approved by this signatory. | -| | NoApprovalsNeeded (2) | Call doesn't need any (more) approvals. | -| | TooFewSignatories (3) | There are too few signatories in the list. | -| | TooManySignatories (4) | There are too many signatories in the list. | -| | SignatoriesOutOfOrder (5) | The signatories were provided out of order; they should be ordered. | -| | SenderInSignatories (6) | The sender was contained in the other signatories; it shouldn't be. | -| | NotFound (7) | Multisig operation not found when attempting to cancel. | -| | NotOwner (8) | Only the account that originally created the multisig is able to cancel it. | -| | NoTimepoint (9) | No timepoint was given, yet the multisig operation is already underway. | -| | WrongTimepoint (10) | A different timepoint was given to the multisig operation that is underway. | -| | UnexpectedTimepoint (11) | A timepoint was given, yet no multisig operation is underway. | -| | WeightTooLow (12) | The maximum weight information provided was too low. | -| | AlreadyStored (13) | The data to be stored is already stored. | diff --git a/website/translated_docs/zh-CN/maintain-governance-index.md b/website/translated_docs/zh-CN/maintain-governance-index.md deleted file mode 100644 index f2371610e1fa..000000000000 --- a/website/translated_docs/zh-CN/maintain-governance-index.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -id: maintain-governance-index -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. WebAssembly) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. - -All changes to the protocol must be agreed upon by stake-weighted referenda; the majority of the stake can always command the network. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and council together to administrate the network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or council, it finally will have to go through the [referenda](learn-governance#referenda) to let all DOT holders make the decision. - -The following steps are the governance procedure in the Polkadot network: - -- [Proposing Referenda](#proposing-referenda) (Involved info: [Referenda](learn-governance#referenda)) -- [Voting for a proposal](#voting-for-a-proposal) (Involved info: [Voluntary Locking](#voluntary-locking)) -- [Tallying](#tallying) (Involved info: [Adaptive Quorum Biasing](#adaptive-quorum-biasing)) - -To better understand how the council is formed, please read [this section](#council). - -### Proposing Referenda - -- **Public**: Anyone can propose a referenda by depositing the minimum amount of DOTs for a certain period (No. of Blocks). If someone likes the proposal, they may deposit the same amount of tokens to support it. The proposal with the highest number of support bond will be selected to be a referendum. The bonded tokens will be released once the proposal is tabled. At genesis, every two weeks there will be a referendum for the most supported proposal. - -- **[Council](#council)**: - - Unanimous Council - When all members of the council agrees on a proposal, it can be moved to a referendum. - - Majority Council - When agreement from only the simple majority of council members is needed. (More Aye votes to Nay votes for acceptance, more Nay votes to Aye votes for rejection.) - -### Voting for a proposal - -To vote, a voter must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. At the same time, holding only a small amount of DOT tokens does not mean that they cannot influence the referendum result, you can read more about the [Voluntary Locking](#voluntary-locking). - -``` -Example: - -Peter: Votes `No` with 10 DOTs for a 12 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOTs for a 2 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOTs for a 4 week lock period => 15 * 2 = 30 Votes -``` - -According to the above scenario, even though combining both Logan and Kevin's DOTs is more than Peter, the lock period for both of them is far less than Peter, leading to their voting power counting as less. - -### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so `Super-Majority Approve` formula will be applied. There is no strict quorum, but super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -voters - the total number of voting tokens - -electorate - the total number of DOTs tokens issued in the network -``` - -**Super-Majority Approve** - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{voters}} < {approve \over \sqrt{electorate}}$$ - -**Super-Majority Against** - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple-majority-carriers as below. $${against \over \sqrt{electorate}} < {approve \over \sqrt{voters}}$$ - -**Simple-Majority** - -Majority-carries, a simple comparison of votes, if there are more aye votes than nay, then the proposal is carried. $${approve} > {against}$$ - -*To know more about where these above formulas come from, please read the [democracy module](https://github.com/paritytech/substrate/blob/master/srml/democracy/src/vote_threshold.rs)*. - -``` -Example: - -Assume we only have 1,500 DOTs tokens in total. - -John - 500 DOTs -Peter - 100 DOTs -Lilly - 150 DOTs -JJ - 150 DOTs -Ken - 600 DOTs - -John: Votes `Yes`for a 2 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 2 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 6 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -voters = 1050 -electorate = 1500 -``` - -$${450 \over \sqrt{1050}} < {600 \over \sqrt{1500}}$$ - -$${13.887} < {15.492}$$ - -Based on the above result, the proposal will be approved. In addition, only the winning voter's tokens are locked, which means if that referendum hurts the network, then those who voted against it can immediately get their locked tokens back. They can exit the network and sell their tokens to the market before the proposal becomes effective. Moreover, winning proposals are autonomously enacted only after some cool-down period. - -## Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their DOTs, hence, the maximum number of votes for each token holder will be calculated by the following formula: - -``` -Max votes = tokens * periods -``` - -Based on the current testnet setting, the maximum number of lock periods is set to 6. - -**Each period takes 2 weeks, which means the longest lock period would be 12 weeks.** - - -## Adaptive Quorum Biasing - -Polkadot introduces a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If there is publicly submitted referenda only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied the `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that as more token holders vote on referenda, then the super-majority required decreases as the turnout increases. - -Suppose there is a unanimous proposal proposed by the council, `Negative Turnout Bias` would be used, so that means the proposal is passed by default. Hence, more token holders have to participate in voting to prevent it from passing if they do not like this proposal. - -Referring to the above image, when the referenda only has 25% turnout, the tally of "nay" votes has to reach 34% for it to reject. - -In short, when turnout rate is low, a super-majority is required to pass the proposal, which means a higher threshold of "aye" (yes) votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -## Council - -Since not everyone is interested in participating in governance, there is a council entity to represent the passive token holders. To understand more about what the council is responsible for, please read [here](learn-governance#council). - -### How to be a council member? - -![](assets/governance/approval-vote.png) - - At genesis, there will be 6 to 12 seats to start. All stakeholders are free to signal their approval (or not) of any of the registered candidates. For every two weeks, one of those seats is up for election and increase over the course of 9 months to 24 people (roughly one extra individual coming on every two weeks). All members have a fixed term (1 year). Council members can be removed early only by a referenda. - -To elect a new council member, Polkadot employs `approval voting` method to allow token holders that choose a list of candidates they want to support in equal weight and the one with the most approval votes wins the election, while top-N runners-up remain on the candidates' list for next election. - -Basically, instead of using one person one vote, [approval voting](https://en.wikipedia.org/wiki/Approval_voting) is a more expressive way to indicate their views. Token holders can treat it as boolean voting to support as many candidates as they want. - -Let's take a look at the example below. - -||||Round 1||| ||:\-\---:|:\---:|:\---:|:\---:|:\---:| |**Token Holders**|||**Candidates**||| ||A|B|C|D|E| |Peter|X||X|X|X|X| |Alice||X||||| |Bob|||X|X|X| |Kelvin|X||X||| |**Total**|2|1|3|2|2| - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -|||Round 2||| ||:\-\---:|:\---:|:\---:|:\---:| |**Token Holders**||**Candidates**|| ||A|B|D|E| |Peter|X|X||| |Alice|X|X||| |Bob|X|X|X|X| |Kelvin|X|X||| |**Total**|4|4|1|1| - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This would be the tentative governance configuration for Polkadot in the initial genesis. It will be changed if any security loopholes have been found after third-party auditing. - -### Resources - -- [Governance Description](learn-governance#referenda) -- [Democracy Module](https://github.com/paritytech/substrate/tree/master/srml/democracy/src) - -## [Usage of DOT](learn-DOT#dots-for-governance) - -## Guides - -### [How to create a proposal]() -### [How to join the council]() -### [How to propose a referenda]() diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/zh-CN/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/zh-CN/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-nominate.md b/website/translated_docs/zh-CN/maintain-guides-how-to-nominate.md deleted file mode 100644 index d846a22dddd0..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-how-to-nominate.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: maintain-guides-how-to-nominate -title: How to nominate -sidebar_label: How to nominate ---- - -This guide will walk you through how to nominate your DOTs to a validator node so that you can take part in the staking system and earn fresh DOTs. - -It has been updated for the Alexander testnet and Polkadot release PoC-4. - -## Create `stash` and `controller` accounts - -We will assume that you will be starting with two fresh accounts. Click [here](learn-staking#accounts) to learn more about what `stash` and `controller` accounts mean. - -The first step is to create two accounts by going to the *Accounts* tab on the Polkadot Dashboard and clicking on [*Add account*](https://polkadot.js.org/apps/#/accounts). Make sure to use `stash` and `controller` in the names of your accounts to identify them easily. - -![Creating an account](assets/guides/how-to-nominate/polkadot-dashboard-create-account.jpg) - -Once you've created your accounts you will need to acquire some DOTs. See the [DOTs page](learn-DOT#getting-testnet-dots) for recommendations on getting testnet DOTs. Each of your accounts should have at least 150 milliDOTs to cover the existential deposit and transaction fees. - -## Nominating - -It is now time to setup our nominator. We will do the following: -- Bound the DOTs of the `stash` account. These DOTs will be put at stake for the security of the network and can be slashed. -- Select the `controller`. This is the account that will decide when to start or stop nominating. - -First, go to [Staking > Account actions](https://polkadot.js.org/apps/#/staking/actions) section. Click on the "New stake" button. - -![dashboard bonding](assets/guides/how-to-nominate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your `stash` account, we will bound 100 milliDOTs, make sure it has this amount of funds. -- **Controller account** - select the `controller` account created earlier. -- **Value bonded** - how many DOTs from the `stash` account you want to bond/stake. You can top up this amount and bound more DOTs later, however, withdrawing any bounded amount requires the bounding duration period to be over (several months at the time of writing). -- **Payment destination** - where the rewards get sent. More info [here](learn-staking#reward-distribution). - -Once everything is filled properly, click `Bond` and sign the transaction (with your `stash` account). You will then see the following. You can ignore the `Set Session Key` button, it is only useful if you want to validate and we will not need it in this tutorial. - -![dashboard overview](assets/guides/how-to-nominate/polkadot-dashboard-set-session-key.jpg) - -## Nominating a validator - -Go to the *Staking Overview* tab on the staking page of the Polkadot Dashboard. On the left side, you will see a list of validators (on the right side are validators who have signaled their intention to join the validator set and you can ignore them for now). From this list of validators, find ones that you would like to nominate and copy their address (by clicking on the identicon) or better, add them to your Address book. - -![Validators](assets/guides/how-to-nominate/validators.png) - -Go back to the *Account Actions* tab and click the `Nominate` button. Fill in the blank field with the address of the validators you have chosen to nominate. After signing and submitting your transaction you should see the button `Stop Nominating` and you should see the accounts you are nominating showing up under the `Nominating` section. Your nomination will be effective in the next era (this can take up to one hour). - -![Nominating](assets/guides/how-to-nominate/nominating.jpg) - -**Congratulations!** You are now a nominator. - -If you return to the *Staking Overview* tab after an era has changed and scroll until you find your validator you should see your own `stash` account appear as one of the nominators. - -![Nominating2](assets/guides/how-to-nominate/nominating2.jpg) - -## How to stop nominating - -To stop nominating simply return to the *Account Actions* tab and click the `Stop Nominating` button. Your account will be set to `chill` and at the next era will no longer be nominating to the validator. This may take up to an hour to take effect! diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-unbond.md b/website/translated_docs/zh-CN/maintain-guides-how-to-unbond.md deleted file mode 100644 index 10b9e8726506..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-how-to-unbond.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: maintain-guides-how-to-unbond -title: Unbonding and Rebonding -sidebar_label: Unbonding and Rebonding ---- - -The following describes how to stop nominating or validating and retrieve your tokens. Please note that all networks on which you can nominate have a delayed exit period, called the _unbonding period_, which serves as a cooldown. You will not be able to transfer your tokens before this period has elapsed, and you will not receive any staking rewards during this period (as you are not nominating any validators). - -### 第1步：停止提名 - -On the [Polkadot-JS Apps](https://polkadot.js.org/apps) navigate to the "Staking" tab. - -在页面左上角点击 "Account Actions"。 - -Here, click "Stop Nominating" or "Stop Validating" (depending on your role) on an account you're staking with and would like to free the funds for. - -![Stop Nominating Button](/img/NPoS/unbond1.png) - -After you confirm this transaction, your tokens will remain _bonded_. This means they stay ready to be distributed among nominees or used as validator self-stake again. To actually withdraw them, you need to unbond. - -### 第2步：取消绑定 - -To unbond the amount, click the little gear icon next to the account you want to unbond tokens for, and select "Unbond funds". - -![Unbonding](/img/NPoS/unbond2.png) - -选择您要取消绑定的金额，然后单击 "Unbond"，然后确认交易。 - -![Unbonding all](/img/NPoS/unbond3.png) - -如果成功，您的余额将显示为 "unbonding"，并显示还剩余多少区块，你就会完全解锁该数量。 - -![Unbonding duration](/img/NPoS/unbond4.png) - -该持续时间会因您所使用的网络而异，在 Kusama 上的速度通常是 Polkadot 上速度的四倍。 - -Once this process is complete, you will have to issue another, final transaction: Withdraw Unbonded. - -![Unbonding withdraw](/img/NPoS/unbond5.png) - -You can also check how long you have to wait in order to withdraw your stake in the [Accounts](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/accounts) page by expanding your account balance. There is a tiny icon beside the word "unbonding" that will eventually become an unlock icon once the remaning blocks get passed. - -Then, you can click that icon directly to submit the withdraw transaction. Finally, your transferrable balance will increase by the amount of tokens you've just fully unbonded. - -## Rebonding before the end of the unbonding period - -If you want to rebond your tokens before the unbonding period is over you can do this by issuing a `rebond` extrinsic. This allows you to bond your tokens that are still locked without waiting until the end of the unbonding period. - -In order to do this you will need to issue an extrinsic manually from [Polkadot-JS Apps](https://polkadot.js.org/apps). - -Go to the "Extrinsics" option that's located in the "Developer" dropdown in the top menu. - -![extrinsic menu](assets/rebonding-1.png) - -Select the "staking" pallet and the "rebond" extrinsic. Enter the amount of tokens that are currently locked in unbonding that you want to rebond. Then click "Submit Transaction". - -![confirm](assets/rebonding-2.png) - -Confirm the transaction in the next pop-up. Once the transaction is included in the next block your tokens will be rebonded again and you can start staking with them. diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-upgrade.md b/website/translated_docs/zh-CN/maintain-guides-how-to-upgrade.md deleted file mode 100644 index ef95651bc90f..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-how-to-upgrade.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: maintain-guides-how-to-upgrade -title: 如何升级验证人节点 -sidebar_label: 如何升级验证人节点 ---- - -验证人负责执行网络上的重要工作，所以对在线有严格的要求。验证人有机会更新客户端或系统同时离线一段时间。这教程将会指导您如何升级并保持验证人在线。 - -这过程可能需要数小时，所以确保您先理解说明并制定相应的计划。 - -## 重要组件 - -### Session 密钥 - -Session 密钥储存在客户瑞并供验证人作签名操作。它是把验证人节点和 Controller 帐户联系起来。您不能在 Session 中段更改它。 - -[关于 Polkadot 密钥资料。](learn-keys) - -### 数据库 - -验证人数据库保留所有他们的投票，如果二台电脑在不同数据库拥有相同 Session 密钥，他们会有 equivocating 风险。因此每次更换电脑时，我们都会生成新 Session 密钥。 - -[有关 equivocation 更多信息。](learn-staking#slashing) - -## 步骤 - -当您升级主机验证人时，您需要启动另一台验证人。在升级步骤中，我们将需要升级的验证人称为 "验证人A"，而第二个称为 "验证人B"。 - -### Session `N` - -1. 启动另外节点并且连接到你的哨兵节点。一旦同步数据完成，使用 `--validator` 标志。这是 "验证人 B"。 -1. 在验证人 B 生成Session 密钥。 -1. 在你 Controller 帐户提交 `set_key` 交易设定新的 Session 密钥。 -1. 记下交易执行后的结果。 - -**验证人 A 必须在当下 Session 继续运行** ` set_key ` 仅在下一个 Session 生效。 - -### Session `N+1` - -现在验证人 B 充当验证人，你可以把验证人 A 停下来。请留意底部的注释。 - -1. 停止验证人 A。 -1. 把您的系统或客户端进行升级。 -1. 启动验证人 A，同步数据库并连接你的哨兵节点。 -1. 在验证人 A 生成新的 Session 密钥。 -1. 在你 Controller 帐户提交 `set_key` 交易设定验证人 A 新的 Session 密钥。 -1. 记下交易执行后的结果。 - -**再重复一次验证人 B 必须在当下 Session 继续运行直至下一个 Session。** - -一旦 Session 改变，验证人 A 将接管。你可以把验证人 B 停下来。 - -**注意:**: 为了确保 Session 已更改，请确保新 Session 中有一个区块已确认。如果成功，您应该看到类似以下的日志消息: - -``` -2019-10-28 21:44:13 Applying authority set change scheduled at block #450092 -2019-10-28 21:44:13 Applying GRANDPA set change to new set with 20 authorities -``` diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/zh-CN/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 0c18dacdd602..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: 成为验证人 (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -本指南将指导您如何在 Kusama 网络上设置验证人节点。 - -## 首先 - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## 初始设置 - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- ** 中央处理器:** 1 - 2。一个 CPU 是可以，但是2个更好。 同样地这是一种性能偏好。 - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> 注意：如果您喜欢使用 SSH 而不是 HTTPS，则可以将下面的第一行替换为 `git clone git@github.com:paritytech/polkadot.git`。 - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## 绑定 KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- 选择 Controller，Controller 是决定何时开始或停止验证的帐户。 - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## 设置 Session 密钥 - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## 验证 - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/zh-CN/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/zh-CN/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index 259fbe58df86..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: 运行验证人 (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -本指南将指导您如何在 Polkadot 网络上设置验证人节点。 - -## 首先 - -在主网上运行验证人有很大的责任！你不仅要对自己抵押的 DOTs 负责，还有目前提名你的提名人抵押。如果你犯了错误并且被惩罚，你的钱和声誉将处于危险之中。但是运行验证人也有非常可观的回报，您为安全性做出了贡献，使网络更分散。 - -由于安全性对运行验证人至关重要，因此您最好看一下[设定安全验证人](maintain-guides-secure-validator)资料使您了解在构建网络架构时要考虑的要素。 Web3 基金会也会保持更新[安全验证人设置的参考](https://github.com/w3f/polkadot-secure-validator)使您也可以自己部署来使用(视频教程在[这里](https://www.youtube.com/watch?v=tTn8P6t7JYc))。随着您成为验证人愈长时间，您可能使用此库作为自己的_起点_进行修改和自定义。 - -如果您需要帮助，请前往 [ Riot 上的 Polkadot 验证人聊天室](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) 。团队和其他验证人在那里帮助回答问题并提供经验。 - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## 初始设置 - -### 要求 - -初学者运行验证人的最常见方法是在 Linux 云服务器 上。 您可以选择自己喜欢的[ VPS ](#vps-list)服务商，以及自己喜欢的操作系统。 在本指南中，我们将使用** Ubuntu 18.04 **，但其他平台的设置应相似。 - -Polkadot 中的交易权重以标准硬件为基准。 建议验证人至少运行标准硬件，以确保它们能够及时处理所有区块。以下不是_最低要求_，但是如果您决定以低于此的速度运行，则可能会遇到性能问题。 - -#### 标准硬件 - -关于标准硬件的详细信息，请在[这里](https://github.com/paritytech/substrate/pull/5848)查看。 - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -上面发布的规格绝不是运行验证人时可以使用的最低规格，但是您应该意识到，如果使用的规格较少，则可能需要切换一些额外的优化才能与其他运行标准验证人相同。 - -### 安裝 Rust - -当你选择云端服务供应商并设置新服务器后，第一件您要做的事就是安装 Rust。 - -如果您从未安装过 Rust，则应先执行此指令。该指令将下载最新版本的 Rust 并安装。 - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -相反如果您已经安装了 Rust，请运行以下指令以确保您使用的是最新版本。 - -```sh -rustup update -``` - -最后运行此指令以安装必要的相关依赖，以编译和运行 Polkadot 节点。 - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -注意 - 如果您使用的是 OSX，并且已安装[ Homebrew ](https://brew.sh)，则可以执行以下指令而不是之前的指令： - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### 安装 & 配置网络时间协议 (NTP) 客户端 - -[ NTP ](https://en.wikipedia.org/wiki/Network_Time_Protocol)是种网络协议，旨在通过网络同步计算机的时钟。NTP 允许您同步网络中所有系统的时钟。 验证人现在要求本地时钟保持合理的同步，因此您应该运行 NTP 或类似的服务。 您可以通过运行以下命令检查是否具有 NTP 客户端： - -_如果您正在使用 Ubuntu 18.04 / 19.04, NTP 客户端应默认已安装。_ - -```sh -timedatectl -``` - -如果已安装并正在运行 NTP，则应该看到`System clock synchronized: yes`(或类似的消息)。如果看不到它，可以通过执行以下命令进行安装: - -```sh -sudo apt-get install ntp -``` - -ntpd 将在安装后自动启动。您可以查询 ntpd 获取状态信息以验证一切是否正常: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### 构建并安装 `polkadot` 二进制文件 - -您需要从[ paritytech/polkadot ](https://github.com/paritytech/polkadot) GitHub 库的** v0.8 **分支中构建 ` polkadot ` 二进制文件。 - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -这步将需要一段时间(通常需要 10 - 40 分钟，具体取决于您的硬件)。 - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -如果您想在本地生成密钥，您还可以在同一目录安装` subkey `。然后您可以把生成好的` subkey `可执行文件，并将其转移到与世隔绝的电脑中，以提高安全性。 - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### 同步链数据 - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -您可以通过运行以下指令来开始同步您的节点: - -```sh -./target/release/polkadot --pruning=archive -``` - -如果您不想马上运行验证模式下。 - -`--pruning=archive`选项意味着` --validator `和`-sentry `选项，因此仅如果在没有这两个选项之一的情况下启动节点，则必须明确要求。 如果您不设置为 archive 节点，即使不在运行验证人和哨兵模式时，也需要切换时重新同步数据库。 - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -根据当时链的大小，此步可能需要几分钟到几个小时不等。 - -如果您想估计还需要再多少时间，服务器日志(在 ` polkadot ` STDOUT 程序中显示)显示了您的节点已处理和最新验证的区块。 然后您可以与[ Telemetry ](https://telemetry.polkadot.io/#list/Polkadot%20CC1)或当前[ PolkadotJS 区块链浏览器](https://polkadot.js.org/apps/#/explorer)比较。 - -## Bond DOT - -强烈建议您将 controller 和 stash 帐号设为两个单独的帐号。 为此，您将创建两个帐号，并确保每个帐号至少有足够的资金来支付进行交易的费用。 将您的大部分资金保留在 stash 帐号中，因为这是您存入资金的托管人。 - -确保不对所有 DOT 余额进行绑定，因为您将无法从绑定的余额中支付交易费用。 - -现在可以开始设定验证人，首先我们将会做以下步骤： - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- 选择 Controller，Controller 是决定何时开始或停止验证的帐户。 - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -当所有资料填写好后，使用 Stash 帐号按下`Bond`并签署交易。 - -几秒钟后您应该看到 "ExtrinsicSuccess" 信息。现在您应该会看到包含所有帐号的新卡 (注意: 您可能需要重新整理页面)。 右侧的保证金金额对应于 Stash 的绑定帐号。 - -## 设置 Session 密钥 - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -您可以为验证者人改任何名称，但其他人也可以看到。该名称也会显示在 telemetry 服务器里。由于多人也在使用 telemetry，因此建议您的名称尽可能独特一点。 - -### 生成 Session 密钥 - -您需要通过签名并提交交易设定 Session 密钥。这就是用来与您的验证节点和 Controller 帐号连接起来。 - -#### 选项 1: PolkadotJS-APPS - -您可以使用客户端通过 RPC 生成[ Session 密钥](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key)。 如果执行此操作，确保已将 PolkadotJS-Apps 浏览器连接到验证人节点。 您可以在 "Settings" 标签中将应用程序设置连接到验证人的地址。如果您连接到 Web3 Foundation 的 Parity 托管的地址，则不能使用此方法，因为向该节点发出 RPC 请求是_公开节点_上托管的 keystore，因此您需要确认正在与_您的节点_的 keystore 连接。 - -一旦确定已连接到节点，最简单为节点设置 session 密钥的方法是调用 ` author_rotateKeys ` RPC 请求在验证人的 keystore 中创建新密钥。前往到工具箱选项卡并调用 RPC，然后选择 author > rotateKeys() 选项并记住保存回传结果。 - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### 选项 2: CLI - -如果您在远程服务器上，运行此指令在同一台电脑上会更容易(当节点是运行中并且配置默认 HTTP RPC 端口): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -结果将是十六进制编码的 "result"。這结果是四个公钥的合并。保存结果供后续使用。 - -You can restart your node at this point. - -### 提交` setKeys `交易 - -您需要通过签名并提交交易设定你的 Session 密钥。 这是把您的 Controller 帳戶与验证人连接起来。 - -前往 [ Stake > Account Actions](https://polkadot.js.org/apps/#/staking/actions)，然后在您先前生成的绑定(Stash)帐户。 按下 "Set Session Key" 之后输入之前在` author_rotateKeys `的结果。 - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -提交交易，现在您可以开始验证了。 - -## 验证 - -要核实您的节点是否处于运行状态并已同步，前往[Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) 并找您的节点。注意: 这里显示 Polkadot 网络上的所有节点，因此拥有一个独一无二的名字很重要。 - -如果一切看起来顺利，请继续操作，在 Polkadot UI 中按下 "Validate"。 - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** -您可以指定将获得报酬的百分比。剩余的将与您的提名人之间进行分配。 - -按下 "Validate"。 - -如果您前往 "Staking" 标签，将看到当前在网络上运行的验证人列表。 在页面顶部，它显示了验证人的数量，以及已发出有意表示希望成为验证人节点的数量。 您可以转到 "Waiting" 标签仔细检查以查看是否在此处列出了您的节点。 - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**恭喜你!** 如果你有按照以上步骤操作，你经已设定好 Polkadot 网络的验证人！若果你需要帮助，请前往 **NOTE:** Session keys can also be generated outside the client and inserted into the client's keystore via RPC. For most users, we recommend using the key generation functionality within the client. - -### 客户端外部签署 - -In the future, Polkadot will support signing payloads outside the client so that keys can be stored on another device, e.g. a hardware security module (HSM) or secure enclave. For the time being, however, Session key signatures are performed within the client. - -> **NOTE:** HSMs are not a panacea. They do not incorporate any logic and will just sign and return whatever payload they receive. Therefore, an attacker who gains access to your validator node could still commit slashable behavior. - -An example of highly available, secure setup would be a layer of sentry nodes in front of multiple validators connected to a single signing machine. This machine could implement signing logic to avoid equivocation, even if an attacker gained access to a validator node. - -## 监视工具 - -- [Telemetry](https://github.com/paritytech/substrate-telemetry) This tracks your node details including the version you are running, block height, CPU & memory usage, block propagation time, etc. - -- [Prometheus](https://prometheus.io/)-based monitoring stack, including [Grafana](https://grafana.com) for dashboards and log aggregation. It includes alerting, querying, visualization, and monitoring features and works for both cloud and on-premise systems. The data from `substrate-telemetry` can be made available to Prometheus through exporters like [this](https://github.com/w3f/substrate-telemetry-exporter). - -## Linux 最佳实践 - -- 永不使用 root 用户 -- 保持更新系统的安全补丁 -- 启动并设置防火墙 -- 永不允许基于密码的ssh，只能使用基于密钥的访问。 -- Disable non-essential SSH subsystems (banner, motd, scp, X11 forwarding) and harden your SSH configuration ([reasonable guide to begin with](https://stribika.github.io/2015/01/04/secure-secure-shell.html)). -- 定期备份您的存储。 - -## 结论 - -- At the moment, Polkadot/Substrate can't interact with HSM/SGX, so we need to provide the signing key seeds to the validator machine. This key is kept in memory for signing operations and persisted to disk (encrypted with a password). - -- Given that HA setups would always be at risk of double-signing and there's currently no built-in mechanism to prevent it, we propose having a single instance of the validator to avoid slashing. Slashing penalties for being offline are much less than those for equivocation. - -### 验证人 - -- Validators should only run the Polkadot binary, and they should not listen on any port other than the configured p2p port. - -- Validators should run on bare-metal machines, as opposed to VMs. This will prevent some of the availability issues with cloud providers, along with potential attacks from other VMs on the same hardware. The provisioning of the validator machine should be automated and defined in code. This code should be kept in private version control, reviewed, audited, and tested. - -- Session 密钥应以安全的方式生成和提供。 - -- 如果任何原因导致 Polkadot 停止运行(supervisor 程序)，Polkadot 应该在开机和重新启动时重新启动。 - -- Polkadot 应该以非 root 用户身份运行。 - -### Monitoring - -- There should be an on-call rotation for managing the alerts. - -- There should be a clear protocol with actions to perform for each level of each alert and an escalation policy. - -## 资源 - -- [Figment Network's Full Disclosure of Cosmos Validator Infrastructure](https://medium.com/figment-networks/full-disclosure-figments-cosmos-validator-infrastructure-3bc707283967) -- [Certus One's Knowledge Base](https://kb.certus.one/) -- [EOS Block Producer Security List](https://github.com/slowmist/eos-bp-nodes-security-checklist) -- [Sentry Node Architecture Overview](https://forum.cosmos.network/t/sentry-node-architecture-overview/454) -- [HSM Policies and the Important of Validator Security](https://medium.com/loom-network/hsm-policies-and-the-importance-of-validator-security-ec8a4cc1b6f) diff --git a/website/translated_docs/zh-CN/maintain-guides-society-kusama.md b/website/translated_docs/zh-CN/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/zh-CN/maintain-guides-validator-payout.md b/website/translated_docs/zh-CN/maintain-guides-validator-payout.md deleted file mode 100644 index 9a9104123658..000000000000 --- a/website/translated_docs/zh-CN/maintain-guides-validator-payout.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -id: maintain-guides-validator-payout -title: 验证人奖励发放概述 -sidebar_label: 验证人奖励发放概述 ---- - -## Era Points - -对于每个时代(era) (在 Kusama 大约6小时，在 Polkadot 大约24小时），验证人将按照他们的_era points_的数量按比例支付。era points 是指通过以下方式获得的奖励积分: - -- 为[ 平行链 ](learn-parachains)区块发布有效性声明。 -- producing a non-uncle block in the Relay Chain. -- 生成一个引用到以前未引用的叔块。 -- 生成一个引用的叔块。 - -_Note: An uncle block is a Relay Chain block that is valid in every regard, but which failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. We call the lagging blocks uncle blocks._ - -奖励发放在每个时代结束时。 - -## 奖励方式 - -No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on [era points](#era-points), as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. - -Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. - -Validators will receive staking rewards in the form of the native token of that chain (KSM for Kusama and DOT for Polkadot). - -For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1): 18 tokens -Validator 2 Stake (v2): 9 tokens -Validator 3 Stake (v3): 8 tokens -Validator 4 Stake (v4): 7 tokens -Payout (p): 8 DOT - -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 tokens -``` - -Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator `v1`, who had 18 tokens staked, received the same reward (2 tokens) in this era as `v4` who had only 7 tokens staked. - -## 运行多个验证人节点 - -It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough DOT, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. - -For the following example, assume you have 18 DOT to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 DOT in this era. - -Note that while DOT is used as an example, this same formula would apply to KSM when running a validator on Kusama. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1): 18 DOT <- Your validator -Validator 2 Stake (v2): 9 DOT -Validator 3 Stake (v3): 8 DOT -Validator 4 Stake (v4): 7 DOT -Payout (p): 8 DOT - -Your payout = (p / v) * 1 = (8 / 4) * 1 = 2 -``` - -Running two validators, and splitting the stake equally, would result in the original validator `v4` to be kicked out of the validator set, as only the top `v` validators (as measured by stake) are selected to be in the validator set. More important, it would also double the reward that you get from each era. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1): 9 DOT <- Your first validator -Validator 2 Stake (v2): 9 DOT <- Your second validator -Validator 3 Stake (v3): 9 DOT -Validator 4 Stake (v4): 8 DOT -Payout (p): 8 DOT - -Your payout = (p / v) * 1 = (8 / 4) * 2 = 4 -``` - -With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. - -The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. - -## 惩罚 (Slashing) - -Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough DOT to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more DOT for a validator with 18 DOT staked than one with 9 DOT staked. - -Running multiple validators does not absolve you of the consequences of misbehavior. Polkadot punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. - -Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator. - -To clarify this, let us imagine two validators, `v1` and `v2`. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that `v1` has 90 DOT nominating it and `v2` only has 10. If you nominate `v1`, it now has `90 + 10 = 100` DOT, and you will get 10% of the staking rewards for the next era. If you nominate `v2`, it now has `10 + 10 = 20` DOT nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 DOT in each case. - -## 提名人和验证人支付 - -Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. - -> **NOTE:** Validators set their preference as a percentage of the block reward, _not_ an absolute number of DOT. Polkadot's block reward is based on the _total_ amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, and 100% commission means that the validator operator gets all rewards and gives none to its nominators. - -In the following examples, we can see the results of several different validator payment schemes and split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 DOT, and there are four nominators with equal stake bonded, each will receive 0.5 DOT. Note also that a single nominator may stake different validators. - -Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in DOT, although the same calculations work for KSM) is listed in brackets (`[]`) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. - -``` -Validator Set Size (v): 4 -Validator 1 Stake (v1) [20% commission]: 18 DOT (9 validator, 9 nominator) -Validator 2 Stake (v2) [40% commission]: 9 DOT (3 validator, 6 nominator) -Validator 3 Stake (v3) [10% commission]: 8 DOT (4 validator, 4 nominator) -Validator 4 Stake (v4) [ 0% commission]: 6 DOT (1 validator, 5 nominator) -Payout (p): 8 DOT - -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 DOT - -v1: -(0.2 * 2) = 0.4 DOT -> validator payment -(2 - 0.4) = 1.6 -> shared between all stake -(9 / 18) * 1.6 = 0.8 -> validator stake share -(9 / 18) * 1.6 = 0.8 -> nominator stake share -v1 validator total reward: 0.4 + 0.8 = 1.2 DOT -v1 nominator reward: 0.8 DOT - -v2: -(0.4 * 2) = 0.8 DOT -> validator payment -(2 - 0.8) = 1.2 -> shared between all stake -(3 / 9) * 1.2 = 0.4 -> validator stake share -(6 / 9) * 1.2 = 0.8 -> nominator stake share -v2 validator total reward: 0.8 + 0.4 = 1.2 DOT -v2 nominator reward: 0.8 DOT - -v3: -(0.1 * 2) = 0.2 DOT -> validator payment -(2 - 0.2) = 1.8 -> shared between all stake -(4 / 8) * 1.8 = 0.9 -> validator stake share -(4 / 8) * 1.8 = 0.9 -> nominator stake share -v3 validator total reward: 0.2 + 0.9 DOT = 1.1 DOT -v3 nominator reward: 0.9 DOT - -v4: -(0 * 2) = 0 DOT -> validator payment -(2 - 0) = 2.0 -> shared between all stake -(1 / 6) * 2 = 0.33 -> validator stake share -(5 / 6) * 2 = 1.67 -> nominator stake share -v4 validator total reward: 0 + 0.33 DOT = 0.33 DOT -v4 nominator reward: 1.67 DOT -``` diff --git a/website/translated_docs/zh-CN/maintain-index.md b/website/translated_docs/zh-CN/maintain-index.md deleted file mode 100644 index a21b94d70ac9..000000000000 --- a/website/translated_docs/zh-CN/maintain-index.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: maintain-index -title: 网络参与者 -sidebar_label: 网络参与者 ---- - -欢迎来到 Polkadot 维基的网络参与者部分。 在这里您将找到有关设置节点和运行指南。 - -## 节点 - -- [网络指南](maintain-networks) - 可以连接到 Polkadot 网络的节点列表。 -- [设置全节点](maintain-sync)-通过运行全节点，同步 Kusama 网络来开始。 该指南中的步骤还将广泛应用于任何基于 Substrate 的网络 (如Polkadot)。 -- [使用 Nginx 设置WSS](maintain-wss) - 为您的节点设置安全连接 WebSockets 的服务器。 - -## 收集人 - -- [Learn about Collators](learn-collator) - High level overview of collators and related links. - -## 提名人 - -- [Learn about Nominators](learn-nominator) - High level overview of nominators and related links. -- [提名人指南 (Polkadot)](maintain-guides-how-to-nominate-polkadot)- 如何在 Polkadot 网络上进行提名。 -- [提名人指南 (Kusama)](maintain-guides-how-to-nominate-kusama)- 如何在 Kusama 金丝雀网络上进行提名。 -- [How to stop being a Nominator](maintain-guides-how-to-unbond) - Guide on how to stop nominating. - -## 验证人 - -- [Learn about Validators](learn-validator) - High level overview of validator and related links. -- [验证人奖励收益](maintain-guides-validator-payout) - 验证人奖励的计算和收益 -- [验证人指南 (Polkadot)](maintain-guides-how-to-validate-polkadot)- 如何在 Polkadot 网络上进行验证。 -- [验证人指南 (Kusama)](maintain-guides-how-to-validate-kusama)-逐步介绍如何在 Kusama 金丝雀网络上运行节点。 -- [Using systemmd for the Validator Node](maintain-guides-how-to-systemd) - Configuring systemmd with the Validator node. -- [Secure Validator](maintain-guides-secure-validator) - Best tips and practices for validating. -- [How to use Polkadot Secure Validator](maintain-guides-how-to-use-polkadot-secure-validator) - Walkthrough on how to set up a validator securely. -- [How to upgrade a Validator Node](maintain-guides-how-to-upgrade) - Guide on upgrading your validator node. -- [How to Chill](maintain-guides-how-to-chill) - Walkthrough on how to chill as a validator. - -## 治理 - -- [How to pariticipate in Governance](maintain-guides-democracy) - Walkthrough on how to participate in governance. -- [How to join the Council](maintain-guides-how-to-join-council) - Step by step guide for running for the Council. -- [How to vote for a Councillor](maintain-guides-how-to-vote-councillor) - Step by step guide for voting for your favorite councillors. diff --git a/website/translated_docs/zh-CN/maintain-polkadot-parameters.md b/website/translated_docs/zh-CN/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/zh-CN/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/zh-CN/maintain-sync.md b/website/translated_docs/zh-CN/maintain-sync.md deleted file mode 100644 index b33d96cfc262..000000000000 --- a/website/translated_docs/zh-CN/maintain-sync.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -id: maintain-sync -title: 设置全节点 -sidebar_label: 设置全节点 ---- - -如果你是使用 Substrate 开发 dapp 或产品如 Polkadot，Kusama 或自定义 Substrate 链，你需要具有节点作为运行的功能。另外，依靠自己的架构总是比依靠第三方托管的结构更好，毕竟这个是新的去中心世界。 - -This guide will show you how to connect to [Kusama network](https://kusama.network), but the same process applies to any other [Substrate](https://substrate.dev/docs/en/)-based chain. First, let's clarify the term _full node_. - -### 节点类型 - -区块链的增长来自 _创世块_, _交易 (extrinsics)_, 和 _事件 (events)_。 - -当验证人盖章区块1时，它将在区块0处获取区块链的状态。然后将所有待处理的更改写上 其顶部，并发出由这些更改导致的事件。 以后，以相同的方式使用区块1处的链状态来构建区块2处的链状态，依此类推。 一旦三分之二的验证人同意某个特定的区块有效，就将其最终性确定。 - -**archive 节点** 保存所有过去的区块。 archive 节点方便查询任何时间链上过去的状态。 查找在某个区块账户的余额或者那些导致特定状态变化的外观操作会在使用 archive 节点时快速操作。 然而，archive 节点占用了大量储存空间― Kusama 大约有 160万个这个区块大约是15至20GB。 - -**全节点**被_pruned_，这意味着它将丢弃所有早于 256 个区块的信息，但保留过去区块的所有 extrinsics 信息，以及创世块。以这种方式的节点所需的空间比 archive 节点要少得多。为了通过一个完整的节点查询过去的状态，用户必须等待该节点重建链，直到该区块为止。 一个完整的节点_可以_重建整条链，而无需其他节点的额外输入，即可成为 archive 节点。 唯一警告是，如果最终性由于某种原因而停滞，并且最后一个最终确定的区块落后256个以上块，则 pruned 的全节点将无法同步到网络。 - -Archive 节点是供需要过去信息的实用程序使用，例如区块浏览器，议会程序，讨论平台(例如[ Polkassembly ](https://polkassembly.io)等)。 他们需要能够查看过去的链上数据。 完整节点供其他所有人使用-它们使您可以读取链的当前状态，并直接向链提交事务，而无需依赖集中式基础架构提供程序。 - -另一种类型的节点是**轻节点**。 轻节点仅具有 runtime 和当前状态，但不存储过去的 extrinsics，因此无法从中恢复整条链。 轻型节点对于资源受限的设备很有用。 一个有趣的轻型节点用例是 Chrome 扩展，它是一个独立的节点，以 WASM 格式运行 runtime：https://github.com/paritytech/substrate-light-ui - -### 快速安装说明 (Mac) - -> 如果您是验证人，则不建议使用。 请参阅 [设置安全验证人](maintain-guides-secure-validator) - -- 在 ios searchbar/searchlight 中键入 terminal 以打开 'terminal' 应用程序 -- 在终端机内安装 Homebrew 程序: `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"` -- 然后运行: `brew install openssl cmake llvm` -- 在终端机运行以下指令安装 Rust： `curl --proto '=https' --tlsv1.2 -sf https://sh.rustupp.rs | sh` -- 安装 Rust 后，运行以下命令 clone 并构建 kusama 代码： - ``` - git clone https://github.com/paritytech/polkadot kusama - cd kusama - ./scripts/init.sh - cargo build --release - ``` -- 运行以下命令以启动您的节点: `./target/release/polkadot --name "我节点的名称" ` -- 在 https://telemetry.polkadot.io/#list/Kusama 找您的节点 - -### 快速安装说明 (Windows) - -> 这仅适用于启用虚拟化的 Windows Pro 。 - -> 如果您是验证人，则不建议使用。 请参阅 [设置安全验证人](maintain-guides-secure-validator) - -- 安装 WSL: https://docs.microsoft.com/en-us/windows/wsl/install-win10 -- 安装 Ubuntu (同一个网页): https://docs.microsoft.com/en-us/windows/wsl/install-win10 -- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) -- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` -- Run the following: `sudo chmod +x polkadot` -- Run the following: `./polkadot --name "Your Node Name Here"` -- Find your node at https://telemetry.polkadot.io/#list/Kusama - -### 快速安装说明 (Linux) - -> 如果您是验证人，则不建议使用。 请参阅 [设置安全验证人](maintain-guides-secure-validator) - -For the most recent binary please see the [release page](https://github.com/paritytech/polkadot/releases/) on the polkadot repository. The URL in the code snippet below may become slightly out-of-date. - -Also please note that the nature of pre-built binaries means that they may not work on your particular architecture or Linux distribution. If you see an error like `cannot execute binary file: Exec format error` it likely means the binary is not compatible with your system. You will either need to compile the [source code yourself](#clone-and-build) or use [docker](#using-docker). - -- Determine the latest version of the Polkadot binary (you can see the latest releases here: https://github.com/paritytech/polkadot/releases) -- Download the correct Polkadot binary within Ubuntu by running the following command. Replace `*VERSION*` with the tag of the latest version from the last step (e.g. `v0.8.22`): `curl -sL https://github.com/paritytech/polkadot/releases/download/*VERSION*/polkadot -o polkadot` -- Run the following: `sudo chmod +x polkadot` -- Run the following: `./polkadot --name "Your Node Name Here"` -- Find your node at https://telemetry.polkadot.io/#list/Kusama - -## 获取 Substrate - -Follow instructions as outlined [here](https://substrate.dev/docs/en/knowledgebase/getting-started) - note that Windows users will have their work cut out for them. It's better to use a virtual machine instead. - -Test if the installation was successful by running `cargo --version`. - -```bash -λ cargo --version -cargo 1.41.0 (626f0f40e 2019-12-03) -``` - -## Clone 及 Build - -The [paritytech/polkadot](https://github.com/paritytech/polkadot) repo's master branch contains the latest Kusama code. - -```bash -git clone https://github.com/paritytech/polkadot kusama -cd kusama -./scripts/init.sh -cargo build --release -``` - -Alternatively, if you wish to use a specific release, you can check out a specific tag (`v0.8.3` in the example below): - -```bash -git clone https://github.com/paritytech/polkadot kusama -cd kusama -git checkout tags/v0.8.3 -./scripts/init.sh -cargo build --release -``` - -## 运行 - -The built binary will be in the `target/release` folder, called `polkadot`. - -```bash -./target/release/polkadot --name "我的节点名称" -``` - -Use the `--help` flag to find out which flags you can use when running the node. For example, if [connecting to your node remotely](maintain-wss), you'll probably want to use `--ws-external` and `--rpc-cors all`. - -The syncing process will take a while depending on your bandwidth, processing power, disk speed and RAM. On a \$10 DigitalOcean droplet, the process can complete in some 36 hours. - -Congratulations, you're now syncing with Kusama. Keep in mind that the process is identical when using any other Substrate chain. - -## 运行 Archive 节点 - -When running as a simple sync node (above), only the state of the past 256 blocks will be kept. When validating, it defaults to [archive mode](#types-of-nodes). To keep the full state use the `--pruning` flag: - -```bash -./target/release/polkadot --name "我的节点名称" --pruning archive -``` - -It is possible to almost quadruple synchronization speed by using an additional flag: `--wasm-execution Compiled`. Note that this uses much more CPU and RAM, so it should be turned off after the node is in sync. - -## Using Docker - -Finally, you can use Docker to run your node in a container. Doing this is a bit more advanced so it's best left up to those that either already have familiarity with docker, or have completed the other set-up instructions in this guide. If you would like to connect to your node's WebSockets ensure that you run you node with the `--rpc-external` and `--ws-external` commands. - -```zsh -docker run -p 9944:9944 parity/polkadot:v0.8.24 --name "calling_home_from_a_docker_container" --rpc-external --ws-external -``` diff --git a/website/translated_docs/zh-CN/redenomination.md b/website/translated_docs/zh-CN/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/zh-CN/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/zh-CN/thousand-validators.md b/website/translated_docs/zh-CN/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/zh-CN/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/website/translated_docs/zh-TW/build-protocol-info.md b/website/translated_docs/zh-TW/build-protocol-info.md deleted file mode 100644 index 37d53e495764..000000000000 --- a/website/translated_docs/zh-TW/build-protocol-info.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: build-protocol-info -title: Polkadot Protocol Information -sidebar_label: Polkadot Protocol ---- - -This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain. - -## Tokens - -- **Token decimals:** - - Polkadot (DOT): 10 - - Kusama (KSM): 12 -- **Base unit:** "Planck" -- **Balance type:** [`u128`](https://doc.rust-lang.org/std/u128/index.html) - -### Redenomination - -Polkadot conducted a poll, which ended on 27 July 2020 (block 888,888), in which the stakeholders decided to redenominate the DOT token. The redenomination does not change the number of base units (called "plancks" in Polkadot) in the network. The only change is that a single DOT token will be 1e10 plancks instead of the original 1e12 plancks. See the Polkadot blog posts explaining the [details](https://medium.com/polkadot-network/the-first-polkadot-vote-1fc1b8bd357b) and the [results](https://medium.com/polkadot-network/the-results-are-in-8f6b1ca2a4e6) of the vote. - -The redenomination took effect 72 hours after transfers were enabled, at block 1,248,326, which occurred at approximately 16:50 UTC on 21 Aug 2020. - -## Addresses - -In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit) `AccountId`. This is simply the public key for the cryptography used by Substrate. - -Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding. - -See the [SS58 page](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) in the Substrate wiki for encoding information and a more comprehensive list of network prefixes. - -Relevant SS58 prefixes for this guide: - -- Polkadot: 0 -- Kusama: 2 -- Westend: 42 - -### Cryptography - -Polkadot supports the following [cryptographic](learn-cryptography) key pairs and signing algorithms: - -- Ed25519 -- Sr25519 - Schnorr signatures on the Ristretto group -- ECDSA signatures on secp256k1 - -Note that the address for a secp256k1 key is the SS58 encoding of the _hash of the public key_ in order to reduce the public key from 33 bytes to 32 bytes. - -## Existential Deposit - -Polkadot uses an _existential deposit_ (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be _reaped,_ i.e. completely removed from storage and the nonce reset. Polkadot's ED is 1 DOT, while Kusama's is 0.0016666 KSM. - -Likewise, if you send a transfer with value below the ED to a new account, it will fail. Custodial wallets should set a minimum withdrawal amount that is greater than the ED to guarantee successful withdrawals. - -Wallets and custodians who track account nonces for auditing purposes should take care not to have accounts reaped, as users could refund the address and try making transactions from it. The Balances pallet provides a `transfer_keep_alive` function that will return an error and abort rather than make the transfer if doing so would result in reaping the sender's account. - -## Free vs. Reserved vs. Locked vs. Vesting Balance - -Account balance information is stored in [`AccountData`](https://substrate.dev/rustdocs/latest/pallet_balances/struct.AccountData.html). Polkadot primarily deals with two types of balances: free and reserved. - -For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used. - -Locks are an abstraction over free balance that prevent spending for certain purposes. Several locks can operate on the same account, but they overlap rather than add. Locks are automatically added onto accounts when tasks are done on the network (e.g. leasing a parachain slot or voting), these are not customizable. For example, an account could have a free balance of 200 DOT with two locks on it: 150 DOT for `Transfer` purposes and 100 DOT for `Reserve` purposes. The account could not make a transfer that brings its free balance below 150 DOT, but an operation could result in reserving DOT such that the free balance is below 150, but above 100 DOT. - -Bonding tokens for staking and voting in governance referenda both utilize locks. - -Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable. - -More info: - -- [Lockable Currency](https://substrate.dev/rustdocs/latest/frame_support/traits/trait.LockableCurrency.html) -- [Lock Withdraw Reasons](https://substrate.dev/rustdocs/latest/frame_support/traits/enum.WithdrawReason.html) -- [Vesting](https://substrate.dev/rustdocs/latest/pallet_vesting/struct.Vesting.html) - -## Extrinsics and Events - -### Extrinsics - -Extrinsics constitute information from the outside world and take on three forms: - -- Inherents -- Signed Transactions -- Unsigned Transactions - -As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the [Substrate documentation](https://substrate.dev/docs/en/knowledgebase/learn-substrate/extrinsics). - -Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks. - -Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin. - -Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOT from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees. - -### Transaction Mortality - -Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue. - -The chain only stores a limited number of prior block hashes as reference. You can query this parameter, called `BlockHashCount`, from the chain state or metadata. This parameter is set to 2400 blocks (about four hours) at genesis. If the validity period is larger than the number of blocks stored on-chain, then the transaction will only be valid as long as there is a block to check it against, i.e. the minimum value of validity period and block hash count. - -Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal". - -**NOTE:** If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic. - -### Unique Identifiers for Extrinsics - -> Note: The assumption that a transaction's hash is a unique identifier is the number one mistake that indexing services and custodians make. This error will cause major issues for your users. Make sure that you read this section carefully. - -Many infrastructure providers on existing blockchains, e.g. Ethereum, consider a transaction's hash as a unique identifier. In Substrate-based chains like Polkadot, a transaction's hash only serves as a fingerprint of the information within a transaction, and there are times when two transactions with the same hash are both valid. In the case that one is invalid, the network properly handles the transaction and does not charge a transaction fee to the sender nor consider the transaction in the block's fullness. - -Imagine this contrived example with a [reaped account](#existential-deposit). The first and last transactions are identical, and both valid. - -| Index | Hash | Origin | Nonce | Call | Results | -|:-----:|:----:|:--------- |:-----:|:------------------- |:----------------------------- | -| 0 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Account A reaped | -| 1 | 0x02 | Account B | 4 | Transfer 7 DOT to A | Account A created (nonce = 0) | -| 2 | 0x01 | Account A | 0 | Transfer 5 DOT to B | Successful transaction | - -In addition, not every extrinsic in a Substrate-based chain comes from an account as a public/private key pair; Substrate, rather, has the concept of dispatch “origin”, which could be created from a public key account, but could also form from other means such as governance. These origins do not have a nonce associated with them the way that an account does. For example, governance might dispatch the same call with the same arguments multiple times, like “increase the validator set by 10%.” This dispatch information (and therefore its hash) would be the same, and the hash would be a reliable representative of the call, but its execution would have different effects depending on the chain’s state at the time of dispatch. - -The correct way to uniquely identify an extrinsic on a Substrate-based chain is to use the block ID (height or hash) and the extrinsic's index. Substrate defines a block as a header and an array of extrinsics; therefore, an index in the array at a canonical height will always uniquely identify a transaction. This methodology is reflected in the Substrate codebase itself, for example to [reference a previous transaction](https://substrate.dev/rustdocs/latest/pallet_multisig/struct.Timepoint.html) from the Multisig pallet. - -### Events - -While extrinsics represent information from the outside world, events represent information from the chain. Extrinsics can trigger events. For example, the Staking pallet emits a `Reward` event when claiming staking rewards to tell the user how much the account was credited. - -If you want to monitor deposits into an address, keep in mind that several transactions can initiate a balance transfer (such as `balances.transferKeepAlive` and a `utility.batch` transaction with a transfer inside of it). Only monitoring `balances.transfer` transactions will not be sufficient. Make sure that you monitor events in each block for events that contain your addresses of interest. Monitor events instead of transaction names to ensure that you can properly credit deposits. - -### Fees - -Polkadot uses weight-based fees that, unlike gas, are charged _pre-dispatch._ Users can also add a "tip" to increase transaction priority during congested periods. See the [transaction fee](learn-transaction-fees) page for more info. - -### Encoding - -Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the [SCALE codec](https://substrate.dev/docs/en/knowledgebase/advanced/codec). - -## Runtime Upgrades - -Runtime upgrades allow Polkadot to change the logic of the chain without the need for a hard fork. A hard fork would require node operators to manually upgrade their nodes to the latest runtime version. In a distributed system, this is a complex process to coordinate and communicate. Polkadot can upgrade without a hard fork. The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. - -Generally there is no need to upgrade your nodes manually before the runtime upgrade as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions or there is a change in networking or consensus. - -Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you don't think you can submit a transaction before the upgrade, it is better to wait and construct it after the upgrade takes place. - -Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Polkadot releases and upgrading in a timely manner, especially for high priority or critical releases. - -## Smart Contracts - -The Polkadot Relay Chain does not support smart contracts. - -## Other Networks - -Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet. - -**Kusama Canary Network:** Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot. - -**Westend Testnet:** Westend is Polkadot's testnet and uses the Polkadot runtime. - -## Other F.A.Q. - -**Can an account's balance change without a corresponding, on-chain transaction?** - -No, but not all balance changes are in a _transaction,_ some are in _events._ You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to _locking_ operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock. - -**What chain depth is considered "safe"?** - -Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe. - -Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head. - -**Do users need to interact with any smart contracts?** - -No, users interact directly with the chain's logic. - -**Does Polkadot have state rent?** - -No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state. - -**What is an external source to see the current chain height?** - -- [Polkadot-JS explorer](https://polkadot.js.org/apps/#/explorer) -- [Polkascan block explorer](https://polkascan.io/) diff --git a/website/translated_docs/zh-TW/build-transaction-construction.md b/website/translated_docs/zh-TW/build-transaction-construction.md deleted file mode 100644 index 188e521a6162..000000000000 --- a/website/translated_docs/zh-TW/build-transaction-construction.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -id: build-transaction-construction -title: Transaction Construction and Signing -sidebar_label: Transaction Construction ---- - -This page will discuss the transaction format in Polkadot and how to create, sign, and broadcast transactions. Like the other pages in this guide, this page demonstrates some of the available tools. **Always refer to each tool's documentation when integrating.** - -## Transaction Format - -Polkadot has some basic transaction information that is common to all transactions. - -- Address: The SS58-encoded address of the sending account. -- Block Hash: The hash of the [checkpoint](build-protocol-info#transaction-mortality) block. -- Block Number: The number of the checkpoint block. -- Genesis Hash: The genesis hash of the chain. -- Metadata: The SCALE-encoded metadata for the runtime when submitted. -- Nonce: The nonce for this transaction.\* -- Spec Version: The current spec version for the runtime. -- Transaction Version: The current version for transaction format. -- Tip: Optional, the [tip](build-protocol-info#fees) to increase transaction priority. -- Era Period: Optional, the number of blocks after the checkpoint for which a transaction is valid. If zero, the transaction is [immortal](build-protocol-info#transaction-mortality). - -\*The nonce queried from the System module does not account for pending transactions. You must track and increment the nonce manually if you want to submit multiple valid transactions at the same time. - -Each transaction will have its own (or no) parameters to add. For example, the `transferKeepAlive` function from the Balances pallet will take: - -- `dest`: Destination address -- `#[compact] value`: Number of tokens (compact encoding) - -Once you have all the necessary information, you will need to: - -1. Construct an unsigned transaction. -1. Create a signing payload. -1. Sign the payload. -1. Serialize the signed payload into a transaction. -1. Submit the serialized transaction. - -Parity provides the following tools to help perform these steps. - -## Polkadot-JS Tools - -[Polkadot-JS Tools](https://github.com/polkadot-js/tools) contains a set of command line tools for interacting with a Substrate client, including one called "Signer CLI" to create, sign, and broadcast transactions. - -This example will use the `signer submit` command, which will create and submit the transaction. The `signer sendOffline` command has the exact same API, but will not broadcast the transaction. `submit` and `sendOffline` must be connected to a node to fetch the current metadata and construct a valid transaction. Their API has the format: - -```bash -yarn run:signer --account --ws [param1] [...] [paramX] -``` - -Signing: - -```bash -yarn run:signer sign --account --seed --type -``` - -For example, let's send 0.5 DOT from `121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2` to `15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y`. - -```bash -yarn run:signer submit --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --ws ws://127.0.0.1:9944 balances.transferKeepAlive 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y 500000000000 -``` - -This will return a payload to sign and an input waiting for a signature. Take this payload and use your normal signing environment (e.g. airgapped machine, VM, etc.). Sign the payload: - -```bash -yarn run:signer sign --account 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 --seed "pulp gaze fuel ... mercy inherit equal" --type sr25519 0x040300ff4a83f1...a8239139ff3ff7c3f6 -``` - -Save the output and bring it to the machine that you will broadcast from, enter it into `submit`'s signature field, and send the transaction (or just return the serialized transaction if using `sendOffline`). - -## Tx Wrapper - -If you do not want to use the CLI for signing operations, Parity provides an SDK called [TxWrapper](https://github.com/paritytech/txwrapper) to generate and sign transactions offline. See the [examples](https://github.com/paritytech/txwrapper/tree/master/examples) for a guide. - -**Import a private key** - -```ts -import { importPrivateKey } from '@substrate/txwrapper'; - -const keypair = importPrivateKey(“pulp gaze fuel ... mercy inherit equal”); -``` - -**Derive an address from a public key** - -```ts -import { deriveAddress } from '@substrate/txwrapper'; - -// Public key, can be either hex string, or Uint8Array -const publicKey = “0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235”; -const address = deriveAddress(publicKey); -``` - -**Construct a transaction offline** - -```ts -import { methods } from "@substrate/txwrapper"; - -const unsigned = methods.balances.transferKeepAlive( - { - dest: "15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y", - value: 500000000000, - }, - { - address: "121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2", - blockHash: "0x1fc7493f3c1e9ac758a183839906475f8363aafb1b1d3e910fe16fab4ae1b582", - blockNumber: 4302222, - genesisHash: "0xe3777fa922cafbff200cadeaea1a76bd7898ad5b89f7848999058b50e715f636", - metadataRpc, // must import from client RPC call state_getMetadata - nonce: 2, - specVersion: 1019, - tip: 0, - eraPeriod: 64, // number of blocks from checkpoint that transaction is valid - transactionVersion: 1, - }, - { - metadataRpc, - registry, // Type registry - } -); -``` - -**Construct a signing payload** - -```ts -import { methods, createSigningPayload } from '@substrate/txwrapper'; - -// See "Construct a transaction offline" for "{...}" -const unsigned = methods.balances.transferKeepAlive({...}, {...}, {...}); -const signingPayload = createSigningPayload(unsigned, { registry }); -``` - -**Serialize a signed transaction** - -```ts -import { createSignedTx } from "@substrate/txwrapper"; - -// Example code, replace `signWithAlice` with actual remote signer. -// An example is given here: -// https://github.com/paritytech/txwrapper/blob/630c38d/examples/index.ts#L50-L68 -const signature = await signWithAlice(signingPayload); -const signedTx = createSignedTx(unsigned, signature, { metadataRpc, registry }); -``` - -**Decode payload types** - -You may want to decode payloads to verify their contents prior to submission. - -```ts -import { decode } from "@substrate/txwrapper"; - -// Decode an unsigned tx -const txInfo = decode(unsigned, { metadataRpc, registry }); - -// Decode a signing payload -const txInfo = decode(signingPayload, { metadataRpc, registry }); - -// Decode a signed tx -const txInfo = decode(signedTx, { metadataRpc, registry }); -``` - -**Check a transaction's hash** - -```ts -import { getTxHash } from ‘@substrate/txwrapper’; -const txHash = getTxHash(signedTx); -``` - -## Submitting a Signed Payload - -There are several ways to submit a signed payload: - -1. Signer CLI (`yarn run:signer submit --tx --ws `) -1. [Substrate API Sidecar](build-node-interaction#substrate-api-sidecar) -1. [RPC](build-node-interaction#polkadot-rpc) with `author_submitExtrinsic` or `author_submitAndWatchExtrinsic`, the latter of which will subscribe you to events to be notified as a transaction gets validated and included in the chain. - -## Notes - -Some addresses to use in the examples. See [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). - -```bash -$ subkey --network polkadot generate -Secret phrase `pulp gaze fuel ... mercy inherit equal` is account: - Secret seed: 0x57450b3e09ba4598 ... ... ... ... ... ... ... .. 219756eeba80bb16 - Public key (hex): 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - Account ID: 0x2ca17d26ca376087dc30ed52deb74bf0f64aca96fe78b05ec3e720a72adb1235 - SS58 Address: 121X5bEgTZcGQx5NZjwuTjqqKoiG8B2wEAvrUFjuw24ZGZf2 - -$ subkey --network polkadot generate -Secret phrase `exercise auction soft ... obey control easily` is account: - Secret seed: 0x5f4bbb9fbb69261a ... ... ... ... ... ... ... .. 4691ed7d1130fbbd - Public key (hex): 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - Account ID: 0xda04de6cd781c98acf0693dfb97c11011938ad22fcc476ed0089ac5aec3fe243 - SS58 Address: 15vrtLsCQFG3qRYUcaEeeEih4JwepocNJHkpsrqojqnZPc2y -``` diff --git a/website/translated_docs/zh-TW/claims.md b/website/translated_docs/zh-TW/claims.md deleted file mode 100644 index a4259335bc71..000000000000 --- a/website/translated_docs/zh-TW/claims.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -id: claims -title: Polkadot Claims -sidebar_label: Claims ---- - -If you made a DOT purchase in one of the pre-launch sales, then you will need to claim your DOT tokens. For those who made a pre-genesis claim by sending a claim transaction to the Claims Contract on Ethereum, you will still need to send a free _attest_ transaction that will agree to the terms and conditions of your allocation. If you did not make a pre-genesis claim, then you will claim and attest in a single transaction. - -This guide will walk you through the steps for either making a claim or attesting to the statement. - -If you are making a claim on Polkadot for the first time, please read on below in the [making a claim](#making-a-claim) section. If you've already claimed during the pre-genesis claims period, please proceed to the [attesting to a statement](#attesting-to-a-statement) section instead. - -> To learn more on How to claim your DOT post genesis, check out our walkthrough [video](https://www.youtube.com/watch?v=rjhWfKXJTCg&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22) and our video on [Claiming DOT with an Ethereum address generated using an old mnemonic phrase](https://www.youtube.com/watch?v=AlwrM27x3As&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=16) - -## Making a Claim - -If you did not make a claim in the pre-genesis claims period, then you are able to claim your DOT tokens after genesis. There is no time limit for making your claim so feel free to do this whenever you are most comfortable. - -> Note: When you make a claim, you will also attest to the agreement that corresponds to your DOT allocation. The two actions "claim" and "attest" are done in a single transaction, but for the most part this is simplified from the perspective of the user. - -### What You Will Need - -- The Ethereum account that holds the DOT indicator tokens -- The MyCrypto wallet -- A Polkadot account - -You should already have your Ethereum account that holds the DOT indicator tokens from Polkadot's prior sales. You will need to have access to this account in order to make a signature. - -[MyCrypto][] is a versatile wallet that supports a variety of storage methods for your Ethereum account. Go to their downloads page and ensure that you download the latest version for your operating system. This is important because the latest version will always have the latest security patches. - -> **NOTICE**: It is much more secure to download and use the MyCrypto app locally. You can always find the most up-to-date releases of the desktop app on their [releases page][mycrypto]. - -You will need a Polkadot account to claim your DOT. Please follow the instructions on the \[account generation\]\[\] page for generating a new Polkadot account. - -#### Claiming your DOT with MyCrypto - -The Polkadot-JS [Claims app][] helps you sign a message from MyCrypto. MyCrypto is a good choice in case you have stored the key to the Ethereum account holding your DOT indicator tokens on a hardware device like a Ledger Nano S or a Trezor. It also supports raw private keys, mnemonics, and Parity signer. - -Once you've downloaded MyCrypto and have it running locally (we recommend an air-gapped computer for maximum security), you can start by navigating to the Claims app on Polkadot-JS Apps. Select the account you would like to claim the DOT into and click the blue "Continue" button to proceed. Your screen should look something like this: - -![claim-1](assets/new-claims/claim-1.jpg) - -Now you will need to provide the Ethereum address that is associated with the DOT indicator tokens that you will claim. Enter the Ethereum address into the box and click "Continue". - -![claim-2](assets/new-claims/claim-2.jpg) - -Next your screen should look the image below. - -![claim-2-1](assets/new-claims/claim-2-1.jpg) - -The hex-encoded string that follows the sentence: "Pay DOT to the Polkadot account:" is the hex-encoded public key of your Polkadot account, minus the `0x` prefix. - -The next step is to go to the MyCrypto application and click on "Sign & Verify Message" tab. - -![claim-3](assets/new-claims/claim-3.png) - -This will prompt you to select a method for unlocking your wallet. - -![claim-4](assets/new-claims/claim-4.png) - -After unlocking your wallet, paste the message from Polkadot-JS into the "Message" box. - -![claim-5](assets/new-claims/claim-5.png) - -When you click "Sign Message" you will get a JSON output like the one below: - -![claim-6](assets/new-claims/claim-6.png) - -Copy and paste the JSON output of the signed message from MyCrypto into the input box on the Polkadot-JS UI and click "Confirm Claim." - -![claim-7](assets/new-claims/claim-7.jpg) ![claim-8](assets/new-claims/claim-8.jpg) - -A green box will appear telling you the amount to claim with a "Claim" button to make the claim. Click on the "Claim" button and click "Submit (no signature)" to complete the claim. - -![claim-9](assets/new-claims/claim-9.jpg) - -If this claim succeeded, then you will see a success message and your DOT will be in the account that you claimed to. - -#### Verifying your Claim - -After you make an on-chain claim for DOT, your balance should be updated on the Polkadot UI immediately. - -Having trouble? Get support in the DOT [Claims Support]() channel. - -![claim-10](assets/new-claims/claim-10.jpg) - -Congratulations, you have now completed the process for claiming and signing for your DOT. - -### Third Party Claims Processes - -**We do not recommend using third-party apps or processes to perform your claim or acquire DOT.** - -Claiming using a third-party process can lead to the loss of your allocation, therefore we cannot recommend using any third party apps to do so. Manually specifying your transaction data, as specified in our claims process, is the only way to be certain you will receive your allocation. - -## Attesting to a Statement - -If you've already made a pre-genesis claim, you still have to agree to a statement using your Polkadot account. - -## Using Polkadot-JS Apps - -### What you will need - -- Your Polkadot account unlocked on Polkadot-JS Apps UI. - -You will be sending a free transaction from your Polkadot account on the Polkadot-JS Apps UI. Once you make this transaction you will have the tokens available in your account. - -### Go to Polkadot-JS Apps - -Proceed to [polkadot-js Apps][claims app]. You will need to grant Apps access to your account in some way. One way would be to go to the Accounts page and "create" a new account, replacing the generated seed or mnemonic with the one belonging to your account. The other way is by using the Polkadot-JS extension and entering your seed or mnemonic there, which is generally safer than entering it directly to the Apps page. - -### Make the Attestation - -After entering your account, you should see a red counter appear on the "Claim Tokens" tab on the left navigation drawer. - -![claim-attest-1](assets/new-claims/new-attest-1.jpg) - -Click on the "Claim Tokens" tab and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -![claim-attest-2](assets/new-claims/new-attest-2.png) - -The notification will display one or more Polkadot addresses that you have loaded in Polkadot-JS that you need to sign. Select a Polkadot account with a claim using the drop down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the preclaim period. As always, feel free to reach out for help in the [Claims Support]() channel. - -Click "Continue" and you will see a green box appear on the right. - -![claim-attest-3](assets/new-claims/new-attest-3.jpg) - -![claim-attest-4](assets/new-claims/new-attest-4.jpg) - -Click on "I Agree" and then "Sign and Submit" to make your free attest transaction. When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - -![claim-attest-5](assets/new-claims/new-attest-5.jpg) - -## Using Parity Signer - -### What you will need - -- Parity Signer -- Your Polkadot account linked to Polkadot-JS Apps UI - -Before claiming, you should import your Polkadot address on Parity Signer to the Polkadot-JS Apps. All operations will use Parity Signer to sign the transaction, but will broadcast it via the Polkadot-JS Apps remote node. If you do not have a Polkadot address, please follow the instructions on the Parity Signer section in the [account generation][] page for generating a new Polkadot account. - -### Go to Polkadot-JS Apps - -Proceed to [Polkadot-JS Apps][claims app]. You will need to import your address on Parity Signer to the Accounts page first. - -### Make the Attestation - -![ps-claim-1](assets/new-claims/ps-claim-1.jpg) - -Click "Add via Qr" on the right side. - -![ps-claim-2](assets/new-claims/ps-claim-2.png) - -Open Parity Signer and choose "Polkadot" network. - -![ps-1](assets/new-claims/ps-01.jpg) - -Select the address that you have claimed DOT to during pre-genesis. - -![ps-2](assets/new-claims/ps-02.jpg) - -![ps-3](assets/new-claims/ps-03.jpg) - -Your address will be displayed in QR code format. You can move the QR code to the camera so that the Polkadot-JS Apps can decode it. - -![ps-claim-3](assets/new-claims/ps-claim-3.png) - -Once decoded successfully, input the name for your address and click "Create". - -You will notice that the digit beside the "Claim Tokens" menu increased by 1. It means the number of addresses on the Accounts page that need to do attestations. - -Go to the [Claim Tokens](https://polkadot.js.org/apps/#/claims) page and and you will see a large notification at the top of the page that tells you that you need to sign an attestation. - -Select the Polkadot account that you just have imported with a claim using the drop-down selection. If you don't see a notification or don't see the selector, please double check that the account has been loaded into Polkadot-JS and that it has already claimed during the pre-genesis period. As always, feel free to reach out for help in the [Claims Support]() channel. - -![ps-claim-5](assets/new-claims/ps-claim-5.png) - -Then click "Continue" and you will see a green box appear on the right. - -![ps-claim-6](assets/new-claims/ps-claim-6.png) - -Click on "I Agree" and then "Sign via Qr". - -![ps-claim-7](assets/new-claims/ps-claim-7.png) - -Now you need to sign the transaction using the Parity Signer with your Polkadot address. - -![ps-claim-8](assets/new-claims/ps-claim-8.png) - -First, you need to press the "QR Scanner" on the Parity Signer to scan the QR code that's shown on the authorize transaction window to generate the raw transaction. Next, you may be required to input the PIN on the Parity Signer to generate the signed transaction as a QR code. Then move the QR code to the camera on the Polkadot-JS Apps to continue. - -![ps-3r](assets/new-claims/ps-3r.jpg) - -When the transaction is included in the block, you will see a green success box appear in the upper right corner and the DOT will be in your account. - https://riot.im/app/#/room/!kwIkVteRpPRjjTyvTe:web3.foundation?via=web3.foundation&via=matrix.org&via=matrix.parity.io - -[MyCrypto]: https://download.mycrypto.com/ - -[mycrypto]: https://download.mycrypto.com/ -[account generation]: learn-account-generation -[Claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims -[claims app]: https://polkadot.js.org/apps/#/claims diff --git a/website/translated_docs/zh-TW/getting-started.md b/website/translated_docs/zh-TW/getting-started.md deleted file mode 100644 index 447083cd281e..000000000000 --- a/website/translated_docs/zh-TW/getting-started.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: getting-started -title: Getting Started -sidebar_label: Getting Started ---- - -Welcome to the Polkadot Wiki! This central source of truth contains guides for interacting with the core functionality. Our wiki has three main sections: Learn (for learners), Build (for individuals that want to build on Polkadot), and Maintain (for people that want to maintain the network). - -## What is Polkadot? - -Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment. - -Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees. - -Polkadot is a living network with the core pillars of governance and upgradability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks. - -> Note: If you haven't heard of Governance before, a great place to start is the [Governance page](learn-governance) - -By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network. - -## Why Polkadot? - -Back in the early 2000's, when the internet was gaining popularity for the first time, the internet featured read-only, static, basic webpages. The online connected world at the time was only the beginning of virtual data, identities, and more. The internet during this time was also called the Web 1.0. - -As social media platforms and online businesses began to emerge, the internet transformed into the Web 2.0. This upgraded internet, which we still use today, features dynamic, interactive webpages, where users can read and write information plus publish their own for others to see. This version of the web though, comes with downsides dealing with data control, privacy issues, and trust. This is where the Web 3.0 comes into the picture. - -The Web 3.0 is taking centralized applications and turning them into decentralized, trust-free protocols. The goal is to transform the internet into a decentralized web, where users control their own data and identity in a trust-free environment. The Web 3.0 movement aims to remove intermediaries and build a trustless infrastructure. - -> To learn more of the Web3 movement, check out this video from the [Web3 Summit](https://youtu.be/l44z35vabvA) - -## How does Polkadot work? - -The Polkadot network uses a [sharded model](https://en.wikipedia.org/wiki/Shard_(database_architecture)) where shards - called "[parachains](learn-parachains)", allow transactions to be processed in parallel instead of sequentially. Each parachain in the network has a unique state transition function (STF). Based on Polkadot's design, as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can connect to the Polkadot network as a parachain. - -Polkadot has a Relay Chain acting as the main chain of the system. Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo rigorous [availability and validity](learn-availability) checks before being added to the finalized chain. As the Relay Chain provides the security guarantees, [collators](learn-collator) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. - -![polkadot-relay-chain](assets/polkadot_relay_chain.png) - -In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), Polkadot has [bridge parachains](learn-bridges) that offer two-way compatibility, meaning that transactions can be made between different parachains. - -The [Cross-Chain Messaging Protocol (XCMP)](learn-crosschain) allows parachains to send messages of any type to each other. The shared security and validation logic of the Relay Chain provide the environment for trust-free message passing that opens up true interoperability. - -> To watch a short, beginner-friendly animation on Polkadot, check out our [Polkadot Explainer video](https://www.youtube.com/watch?v=_-k0xkooSlA) - -## Why should you use Polkadot? - -Whether you're a blockchain developer or if you're interested in taking part of [Polkadot's community](https://polkadot.network/polkadot-ambassador-program/), Polkadot offers a platform for everyone. This wiki offers a place for builders and maintainers to utilize [tools](build-tools-index) and for brand-new learners to dive into educational material. - -## Getting Started - -For brand-new learners of Blockchain technology: - -- The [Blockchain Fundamentals MOOC course][mooc] is a great introduction to familiarizing yourself with cryptography, blockchain concepts, decentralization, networks, crytocurrency, and so much more. This is recommended for users with backgrounds of all levels, and is also a free course. - -For brand-new learners of Polkadot: - -- [Polkadot's original white paper][white-paper] is a technical summary around one possible direction of implementing the Polkadot network. This paper uses rationale and technical details to support why this direction is beneficial. This original white paper also explains how Polkadot's core components work together to build this decentralized network. -- [Polkadot's overview paper][overview-paper] is an updated version of the white paper that describes the protocol in more technical terms. We would recommend reading this overview paper if you are interested in digging more into the protocol itself. -- [Polkadot's light paper][light-paper] is a visual, easy to read, and less technical introduction into its blockchain technology. This paper dives into the components of Polkadot but is understandable for both a non-technical and technical reader. -- [Polkadot's specification][spec] is a Github repository that holds the latest Polkadot Host protocol specification, Polkadot's specification tests of the many components of the network, and the Polkadot Runtime specification. This repo holds algorithms and explores how various processes function in the Polkadot network. The Polkadot specification takes Polkadot's ideas and concepts from the light and the white paper but focuses on the technical specs of the technology. -- [Watching the Technical Explainer Videos][teched videos]: These are great introductory videos that explain and demonstrate how to use Polkadot and its [User Interface][ui]. -- Reading [What is Polkadot? A Brief Introduction][article] on Medium. There are also other great articles to read on [Polkadot's Medium][p medium] or [Web3 Foundation's Medium][w medium]. -- [Creating a Polkadot Account][account generation] -- [Sending a Balance transfer][transfer] -- [Staking as Nominator][nominator] -- [Running a Validator][validator] -- [Setting an Identity][identity] -- [Creating a Proxy Account][proxy] -- [Making Proposals and Voting for Referenda][democracy] -- [Running for the Council][council] -- [Voting for Councillors][council voting] -- [Using the Treasury][treasury] - -For brand-new learners of Kusama, Polkadot's canary cousin network: To learn more about how to build and maintain on the Kusama network, please head over to our [Kusama Guide][kusama guide]. - -## Resources - -- [Polkadot Crowdcast](https://www.crowdcast.io/polkadot) - List of all Crowdcast webinars that the Web3 Foundation has done. -- [Polkadot Explorer](https://polkadot.js.org/apps/#/explorer) - Browser for the Polkadot network; can be used for Polkadot, Kusama, or any Substrate-based chain. -- [Polkascan](http://polkascan.io/) \- Real-time multi-chain data for Polkadot Relay Chain and Parity Substrate chains. -- [Subscan.io](https://subscan.io) - Explorer for Substrate based chains. -- [Polkadot Overview](https://youtu.be/lIghiCmHz0U) - Dr. Gavin Wood presents an overview of Polkadot. (Video) -- [Polkadot Overview](https://techcrunch.com/video/fireside-chat-with-jutta-steiner-parity-technologies/) - Dr. Jutta Steiner presents Polkadot. (Video) -- [Polkadot & Substrate Overview](https://www.youtube.com/watch?v=0IoUZdDi5Is&feature=youtu.be) - Dr. Gavin Wood presents Substrate (blockchain in-a-box + VM) and Polkadot, and builds a blockchain on-stage in 30 minutes using Substrate. (Video) -- [Community / Ecosystem](community) - List of community rooms and channels to talk to others about Polkadot. -- [Sample Applications](build-examples-index) - Sample applications that are built on or currently being built for Polkadot. -- [Contributing Guide](contributing) - Rules for contributing to the wiki. -- [Polkadot Knowledge Base](https://support.polkadot.network/) - Troubleshooting resources for specific errors and problems. - -[mooc]: https://mooc.web3.foundation/course/blockchain-fundamentals/ -[white-paper]: https://polkadot.network/PolkaDotPaper.pdf -[overview-paper]: https://github.com/w3f/research/blob/master/docs/papers/OverviewPaper-V1.pdf -[light-paper]: https://polkadot.network/Polkadot-lightpaper.pdf -[spec]: https://github.com/w3f/polkadot-spec -[teched videos]: https://www.youtube.com/watch?v=mNStMPZjiHM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8 -[article]: https://medium.com/polkadot-network/what-is-polkadot-a-brief-introduction-ca3eac9ddca5 -[p medium]: https://medium.com/polkadot-network -[w medium]: https://medium.com/web3foundation -[ui]: https://polkadot.js.org/apps/ -[account generation]: learn-account-generation -[transfer]: learn-balance-transfers -[nominator]: maintain-guides-how-to-nominate-polkadot -[validator]: maintain-guides-how-to-validate-polkadot -[identity]: learn-identity -[proxy]: learn-proxies -[democracy]: maintain-guides-democracy -[council]: maintain-guides-how-to-join-council -[council voting]: maintain-guides-how-to-vote-councillor -[treasury]: learn-treasury -[kusama guide]: https://guide.kusama.network/ diff --git a/website/translated_docs/zh-TW/grants.md b/website/translated_docs/zh-TW/grants.md deleted file mode 100644 index 4c369541775d..000000000000 --- a/website/translated_docs/zh-TW/grants.md +++ /dev/null @@ -1,30 +0,0 @@ -- - - -id: grants title: Web3 Foundation Grants sidebar_label: Grants -- - - - -The Web3 Foundation offers two types of grants: - -- The [Open Grants Program](https://github.com/w3f/Open-Grants-Program) is our standard program, which offers fast funding of up to \$30k for initial grants and \$100k for follow-up ones. Applications are tracked transparently on GitHub and disbursed in cryptocurrencies. -- The [General Grants Program](https://github.com/w3f/General-Grants-Program) offers funding of up to \$100k per grant and covers all other cases, including private applications and fiat payments. - -More information regarding guidelines, support, and the application process for each program can be found at the above links. - -Accepted applications for both programs can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). - -## Alternitive Funding Sources - -### Treasury - -The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both Polkadot and Kusama offer everyone the opportunity to apply for funding via the treasury. See: - -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) -- [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) -- [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) - -### Other Grant Programs - -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - -- [Darwinia Grants Program](https://docs.darwinia.network/docs/en/dev-bounty#grant-program) -- [Moonbeam Grants Program](https://moonbeam.network/community/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) diff --git a/website/translated_docs/zh-TW/kusama-adverserial-cheatsheet.md b/website/translated_docs/zh-TW/kusama-adverserial-cheatsheet.md deleted file mode 100644 index 7363705d235b..000000000000 --- a/website/translated_docs/zh-TW/kusama-adverserial-cheatsheet.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: kusama-adversarial-cheatsheet -title: Adversarial Cheatsheet -sidebar_label: Adversarial Cheatsheet ---- - -Expect things to break on Kusama. To help you break some things, take a look at the following threat model. - -| Hacker wants to … | Security promise that should prevent the hack | Hacking Incentive | Hacking Damage | Hacking value details | -| -------------------------------------------------------------------------------------- |:---------------------------------------------:|:-----------------:|:--------------:| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Double spend tokens via getting the clients to accept a different chain | Integrity (System-wide) | High | High | If attackers are able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Cause system to mint tokens to his own account | Integrity (System-wide) |  Medium | Low - Medium | If an attacker is able to craft transactions that mint tokens to their account, then this provides a high monetary incentive to execute this attack. | -| Validate malicious blocks to double spend tokens | Availability (System-wide) |  High | Medium | If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. | -| Undermine consensus mechanism to split chain | Integrity (System-wide) | High | High | "If an attacker is able to double spend tokens, they are able to get services without paying for them. This gives them a high monetary incentive to execute the attack. Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases. | -| Tamper/manipulate blockchain history to invalidate transactions (e.g. a voting result) | Integrity (System-wide) | Medium | Medium - High | Attacker can rollback undesired transactions by intentionally invalidating the block where transaction has happened. Attacker can force a governance decision (or even an on-chain update) that favors them. | -| Undermine blockchain or consensus mechanism to damage the ecosystem's reputation | Availability (System-wide) | High | High | Betting on decrease in value of the cryptocurrency or competitors want to damage the reputation, so that the value of their blockchain increases | -| Censorship | Availability (System-wide) | Medium | High | Hackers are able to block undesirable types of transactions (e.g. industry competitor transactions or referendum votes). This could be achieved by colluding with other stakeholders or by otherwise obtaining more voting power. | -| Deanonymize users | Confidentiality (Node) | Medium | Medium | Parties that want to de-anonymize users can use the information to oppress the opposition (e.g. political activists). | -| Steal token from node | Integrity (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Steal token from node by leaking credentials | Confidentiality (Node) | High | High | Attackers that are able to steal tokens from nodes can claim assets for themselves, which gives them a high monetary incentive to execute the attack. | -| Prevent node from accessing the Polkadot network | Availability (Node) | Low | Low - Medium | Run a targeted denial-of-service attack out of revenge, monetary interests (in case of a competing coin exchange, etc.). | -| Defraud other participants | Integrity (Node) | Medium | Low - Medium | Attacker can abuse other participants’ misunderstanding of Polkadot's security guarantees to defraud them. Also, if the reward for calling out bad behavior can be set up so that it is higher than the according punishment, a set of self-handled nodes can be set up to generate a source cycle. Other participants are not needed for this attack. | -| Defraud other participants | Integrity (System-wide) | High | High | An attacker could abuse bugs in Polkadot's economic system to defraud other participants. For example, an attacker could exploit a logic bug to not pay transaction fees. | diff --git a/website/translated_docs/zh-TW/kusama-ledger.md b/website/translated_docs/zh-TW/kusama-ledger.md deleted file mode 100644 index 60ad7605de35..000000000000 --- a/website/translated_docs/zh-TW/kusama-ledger.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: kusama-ledger -title: Using Ledger Devices -sidebar_label: Ledger Devices ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -Kusama has a [Ledger][] application that is compatible with the Ledger Nano S and Ledger Nano X devices. The Ledger devices are hardware wallets that keep your private key secured on a physical device that does not get directly exposed to your computer or the internet. - -The Kusama application allows you to manage Kusama's native asset, the KSM token. It supports most of the available transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-5 on the Nano X). -- Ledger Live is installed and at version 2.19 or newer (see settings -> about to find out if you're up to date). -- A web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Kusama in the app catalog and install it. ![The Kusama App in the Ledger Manager](assets/ledger/manager-app-kusama.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases is written [on the README][prerelease instructions] for the Kusama Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` help command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Kusama-1.2011.1] [Warning: use only for test/demo apps] - load - Load Kusama app - delete - Delete Kusama app - version - Show Kusama app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware. If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Kusama". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your Pin code and you should enter it in the device. - -At the end of the process you should have the newly installed Kusama application on the device. - -## Using on Polkadot-JS Apps - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first option lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -If you would like to send a transfer from your account housed on the Ledger device, the easiest method is to use [Polkadot-JS Apps][]. - -- Click on the "Transfer" button in "Accounts" dropdown in the top navigation menu. -- In the top input, select "Ledger" as your sending account. -- In the second input, select the account that you want to transfer funds to. -- In the third input, enter the amount of KSM you want to transfer. -- Click the "Make Transfer" button. -- Confirm the transaction on your device. -- A green success notification will be displayed when the transaction is included in a block. - -> Note the "Transfer with Keep-Alive Checks" toggle. While this toggle is in the _On_ state, your account will be unable to make transactions which would get its balance below the existential deposit. This prevents reaping of accounts with low balances. If you toggle this to _Off_, you will be able to go below existential deposit balance, causing your account to be deleted and any dust amount of KSM to be burned. If you encounter KeepAlive errors when making transactions, this might be the reason. - -A detailed guide on doing transfers is available [here](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger devivce. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -## Support - -If you need support please send an email to [support@kusama.network](mailto:support@kusama.network) or visit [our Support page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-kusama#download-and-install -[releases page]: https://github.com/Zondax/ledger-kusama/releases -[Polkascan]: https://polkascan.io/kusama -[Subscan]: https://kusama.subscan.io/ diff --git a/website/translated_docs/zh-TW/kusama-parameters.md b/website/translated_docs/zh-TW/kusama-parameters.md deleted file mode 100644 index ae8f874e862e..000000000000 --- a/website/translated_docs/zh-TW/kusama-parameters.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: kusama-parameters -title: Kusama Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama generally runs 4x as fast as Polkadot, except Polkadot also has 6 second slots. See [Polkadot Parameters](https://wiki.polkadot.network/docs/en/maintain-polkadot-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 7 days | 100,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 100,800 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 8 days | 115,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -The Kusama Council consists of up to 19 members and up to 19 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case the a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | How often a new validator set is [elected](learn-phragmen). | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------ | ------------------------------------------------------------ | -| Periods between spends | 6 days | 86,400 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `0.20%`, though instead of being burned this amount is temporarily redirected into the [Society](maintain-guides-society-kusama)'s treasury to fund growth. - -### Precision - -KSM have 12 decimals of precision. In other words, 1e12 (1,000,000,000,000 or one trillion) Plancks make up a single KSM. diff --git a/website/translated_docs/zh-TW/kusama-time-periods.md b/website/translated_docs/zh-TW/kusama-time-periods.md deleted file mode 100644 index 15d51ca78447..000000000000 --- a/website/translated_docs/zh-TW/kusama-time-periods.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: kusama-time-periods -title: Time Period Cheat Sheet -sidebar_label: Parameters ---- - -### Periods of common actions and attributes - -_NOTE: Kusama is 4x as fast as Polkadot will be, except for blocktimes where Polkadot will also have 6 second blocktimes._ - -- Block: 6 seconds -- Epoch: 1 hour (600 slots x 6 seconds) -- Session: 1 hour (6 sessions per Era) -- Era: 6 hours (3600 slots x 6 seconds) - -| Kusama | Time | Slots\* | -| ------- | --------- | --------- | -| Block | 6 seconds | 1 | -| Epoch | 1 hour | 600 | -| Session | 1 hour | 600 | -| Era | 6 hours | 3,600 | - -\*_A maximum of one block per slot can be in a chain._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Voting period | 7 days | 604,800 | How long the public can vote on a referendum. | -| Launch period | 7 days | 604,800 | How long the public can select which proposal to hold a referendum on. i.e., Every week, the highest-weighted proposal will be selected to have a referendum | -| Enactment period | 8 days | 691,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ----- | ------ | -------------------------------------------------------------------- | -| Term duration | 1 day | 14,400 | The length of a council member's term until the next election round. | -| Voting period | 1 day | 14,400 | The council's voting period for motions. | - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 604,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 6 hours | 3,600 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 6 hours | 3,600 | Every 6 hours, a new validator set is elected according to Phragmen's method. | -| Bonding duration | 7 days | 604,800 | How long until your funds will be transferrable after unbonding. | -| Slash defer duration | 7 days | 604,800 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------ | ------- | ------------------------------------------------------------ | -| Periods between spends | 6 days | 518,400 | When the treasury can spend again after spending previously. | diff --git a/website/translated_docs/zh-TW/learn-accounts.md b/website/translated_docs/zh-TW/learn-accounts.md deleted file mode 100644 index c892db1389a1..000000000000 --- a/website/translated_docs/zh-TW/learn-accounts.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -id: learn-accounts -title: Polkadot Accounts -sidebar_label: Polkadot Accounts -description: An explanation of accounts, indices, identity, and reaping ---- - -This document covers the basics of Polkadot and Kusama account addresses and how they exist on-chain. For a more in-depth explanation of the cryptography behind them, please see [the cryptography page](learn-cryptography). - -## Address Format - -The address format used in Substrate-based chains is SS58. SS58 is a modification of Base-58-check from Bitcoin with some minor modifications. Notably, the format contains an _address type_ prefix that identifies an address as belonging to a specific network. - -For example: - -- Polkadot addresses always start with the number 1. -- Kusama addresses always start with a capital letter like C, D, F, G, H, J... -- Generic Substrate addresses start with 5. - -These prefixes are defined [here](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)). - -It's important to understand that the different formats for different networks are **merely different representations of the same public key in a private-public keypair** generated by an address generation tool. This makes the addresses compatible across Substrate-based chains as long as you convert the format. - -> Many wallets allow you to convert between formats. Stand-alone tools exist as well, you can find them in the [address coversion tools](#address-conversion-tools) section. - -## Address Generation, Derivation, and Portability - -A valid account only requires a private key that can sign on one of the [supported curves and signature schemes](build-protocol-info#cryptography). Most wallets take many steps from a mnemonic phrase to account key, which affects the ability to use the same mnemonic phrase in multiple wallets. Wallets that use different steps will arrive at a different set of addresses from the same mnemonic. - -### Seed Generation - -Most wallets generate a mnemonic phrase for users to back up their wallets and generate a private key from the mnemonic. Not all wallets use the same algorithm to convert from mnemonic phrase to private key. - -Subkey and Polkadot-JS based wallets use the BIP39 dictionary for mnemonic generation, but use the entropy byte array to generate the private key, while full BIP39 wallets (like Ledger) use 2048 rounds of PBKDF2 on the mnemonic. As such, the same mnemonic will not generate the same private keys. See [Substrate BIP39](https://github.com/paritytech/substrate-bip39) for more information. - -### Derivation Paths - -Many Polkadot key generation tools support hard and soft derivation. See the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey) for details and examples of derivation path formats. The Polkadot-JS Apps and Extension as well as Parity Signer support custom derivation paths using the same syntax as Subkey. - -Some wallets will automatically add derivation paths to the end of the generated mnemonic phrase. This will generate separate seeds for separate paths, which allows separate signing keys with the same mnemonic, e.g. `//polkadot` and `//kusama`. Although you may correctly save the mnemonic phrase, using it in another wallet will not generate the same addresses unless both wallets use the same derivation paths. - -Polkadot and Kusama both have paths registered in the [BIP44 registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md). - -> **Warning:** You must have both the parent private key as well as the derivation path to arrive at the key for an address. Do not use custom derivation paths unless you are comfortable with your understanding of this topic. - -### Portability - -The above information brings us to portability: the ability to use a mnemonic phrase or seed across multiple wallets. Portability depends on a number of factors: - -- Derivation path -- Mnemonic format -- Seed derivation -- Signature scheme - -If you want to use the same mnemonic across multiple wallets, make sure that they follow compatible methods for generating keys and signing messages. If you cannot find understandable documentation, reach out to the project maintainers. - -| | Mnemonic Format | Derivation Path | Seed Derivation | Signature Support | -|:----------------------- |:---------------:|:---------------:|:---------------:|:---------------------------:| -| Polkadot{.js} Extension | Standard | User-Defined | BIP32 | sr25519 | -| Polkadot-JS Apps | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k | -| Ledger | BIP39 | BIP44† | BIP32‡ | ed25519§ | -| Subkey | Standard\* | User-Defined | BIP32 | sr25519, ed25519, secp256k1 | - -\* Ed25519 keys have [limited compatibility](https://github.com/paritytech/substrate-bip39) with BIP39. - -† [BIP44 Registry](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) - -‡ Ed25519 and BIP32 based on [Khovratovich](https://github.com/LedgerHQ/orakolo/blob/master/papers/Ed25519_BIP%20Final.pdf) - -§ Sr25519 planned - -### For the Curious: How Prefixes Work - -The [SS58 document](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58)) states that: - -- Polkadot has an address type of `00000000b`, so `0` in decimal. -- Kusama (Polkadot Canary) has an address type of `00000010b`, so `2` in decimal. -- Generic Substrate has `00101010b` as address type, which is `42` in decimal. - -Because Base58-check alphabet has no number 0, the lowest value is indeed 1. So `00000000b` is 1 in Base58-check. If we try to [decode](https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder) a Polkadot address like `1FRMM8PEiWXYax7rpS6X4XZX1aAAxSWx1CrKTyrVYhV24fg`, the result is `000aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b29d7`. The first byte is `00`, which is indeed `00000000` in binary and `0` in decimal and thus matches the address type of Polkadot. - -Let's take a look at Substrate addresses. If we decode `5CK8D1sKNwF473wbuBP6NuhQfPaWUetNsWUNAAzVwTfxqjfr`, we get `2a0aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b77e5`. The first byte is `2a` which when [converted from hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html) is 42. 42 is `00101010` in binary, just as the SS58 document states. - -Finally, let's look at Kusama addresses. Decoding `CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp` gives us `020aff6865635ae11013a83835c019d44ec3f865145943f487ae82a8e7bed3a66b0985` with the first byte being `02`, just as specified. If we try a Kusama address that starts with a completely different letter, like `J4iggBtsWsb61RemU2TDWDXTNHqHNfBSAkGvVZBtn1AJV1a`, we still get `02` as the first byte: `02f2d606a67f58fa0b3ad2b556195a0ef905676efd4e3ec62f8fa1b8461355f1142509`. It seems counterintuitive that some addresses always have the same prefix and others like Kusama can vary wildly, but it's just a quirk of Base58-check encoding. - -## Obtaining and Managing an Address - -The **most user-friendly** way to create a Polkadot or Kusama address is through the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts). Remember to back up the seed phrase used to generate your account - the accounts are stored only in your browser, so purging the cache will wipe your accounts as well. You would then have to recreate them using the seed phrase given to you by the UI - this will also restore all your previously held balances. - -A **more convenient and recommended** method of keeping the accounts stored on your computer is using the [Polkadot{.js} extension](https://github.com/polkadot-js/extension). This extension remembers your accounts and allows you to clear your browser cache without fear. Still, don't forget to back up your seed phrase - if you lose access to this computer, or the extension somehow crashes beyond repair, the phrase will come in handy. - -Please note that as this keeps your accounts in the browser, it is not a safe place to keep large holdings. By definition, a browser is a "hot wallet" and susceptible to a wide range of attacks, so keep your funds in cold storage when dealing with non-trivial amounts. For improved security, you can securely stash away the seed phrase for your accounts and remove all traces of the accounts from your computer after creating them. - -Other than the extension and the default UI, Polkadot and Kusama addresses can also be created with the [Subkey tool](https://github.com/paritytech/substrate/tree/master/bin/utils/subkey). Subkey is intended for users comfortable with using the command line and can seem intimidating, but is quite approachable. Follow the instructions in the [Subkey documentation](https://substrate.dev/docs/en/knowledgebase/integrate/subkey). When used properly, Subkey is the **most secure** available method of creating an account. - -There is also the very secure [Parity Signer](https://www.parity.io/signer/). This keeps your keys on an air-gapped mobile phone. However, it does require obtaining an old Android or iOS-compatible phone that you are comfortable using only for Parity Signer. - -Hardware wallet integration is possible with Ledger. A full guide is available [here](learn-ledger). - -Alternatively, you might find other wallets on the [Wallet](build-wallets) page, but bear in mind that some of these are **unaudited** and are not officially affiliated with Web3 Foundation or the Polkadot project unless otherwise stated. - -## Balance Types - -On Polkadot there are four different balance types that indicate whether your balance can be used for transfers, to pay fees, or must remain frozen and not used due to an on-chain requirement. - -The balance types are defined by the `AccountData` struct in Substrate. The four types of balances include `free`, `reserved`, `misc_frozen` (`miscFrozen` in camel-case), and `fee_frozen` (`feeFrozen` in camel-case). - -In general, the **usable** balance of the account is the amount that is `free` minus any funds that are considered frozen (either `misc_frozen` or `free_frozen`) and depends on the reason for which the funds are to be used. If the funds are to be used for transfers then the usable amount is the "free" amount minus any `misc_frozen` funds. However, if the funds are to be used to pay transaction fees than the usable amount would be the "free" funds minus any funds that are `fee_frozen`. - -The "total" balance of the account is considered the amount of "free" funds in the account subtracted by any funds that are "reserved." Reserved funds are held due to on-chain requirements and can usually be freed by making some on-chain action. For example, the "Identity" pallet reserves funds while an on-chain identity is registered, but by clearing the identity you can unreserve the funds and make them free again. - -## Existential Deposit and Reaping - -When you generate an account (address), you only generate a _key_ that lets you access it. The account does not exist yet on-chain. For that, it needs the existential deposit: 0.001666666667 KSM (on Kusama) or 1 DOT (on Polkadot mainnet). - -Having an account go below the existential deposit causes that account to be _reaped_. The account will be wiped from the blockchain's state to conserve space, along with any funds in that address. You do not lose access to the reaped address - as long as you have your private key or recovery phrase, you can still use the address - but it needs a top-up of another existential deposit to be able to interact with the chain. - -Transaction fees cannot cause an account to be reaped. Since fees are deducted from the account before any other transaction logic, accounts with balances _equal to_ the existential deposit cannot construct a valid transaction. Additional funds will need to be added to cover the transaction fees. - -Here's another way to think about existential deposits. Ever notice those `Thumbs.db` files on Windows or `.DS_Store` files on Mac? Those are junk, they serve no specific purpose other than making previews a bit faster. If a folder is completely empty save for such a file, you can remove the folder to clear junk off your hard drive. That does not mean you lose access to this folder forever - you can always recreate it. You have the _key_, after all - you're the computer's owner. It just means you want to keep your computer clean until you maybe end up needing this folder again, and then recreate it. Your address is like this folder - it gets removed from the chain when nothing is in it, but gets put back when it has at least the existential deposit. - -## Indices - -A Kusama or Polkadot address can have an index. An index is like a short and easy to remember version of an address. Claiming an index requires a deposit which is released when the index is cleared. - -Indices are populated in order. Think of them like slots going from 0 to any arbitrary number: - -`[0][1][2][3][4][5][6]...` - -If slots 0-2 are populated by addresses A, B and C respectively, and I add an existential deposit to address X, that address will automatically be put into slot 3. Henceforth, you can send me money by just sending to `[3]` rather than remembering my whole address. - -```js -[0][1][2][3][4][5][6]... -[A][B][C][X][ ][ ][ ]... -``` - -But what if an account gets reaped as explained above? In that case, the index is emptied. In other words, the slot frees up again. If someone creates a new account, they may end up using the same index another address was using before. - -It is possible to _freeze_ an index and permanently assign it to an address. This action consumes a deposit but makes sure that the index can never be reclaimed unless released by the holding account. - -To register an index, submit a `claim` extrinsic to the `indices` pallet, and follow up with a `freeze` extrinsic. The easiest way to do this is via PolkadotJS UI through the _Developer -> Extrinsics_ menu: - -![Indices extrinsics](assets/accounts/index.png) - -To find available indices to claim, [this helper tool may come in handy](https://www.shawntabrizi.com/substrate-js-utilities/indices/). - -## Identities - -The [_Identities pallet_](https://github.com/paritytech/substrate/tree/master/frame/identity) built into Polkadot allows users to attach on-chain metadata to their accounts. This metadata can be verified by independent registrars to provide trustworthiness. To learn more about how to set or release an identity, how to define sub-accounts, or how to become a registrar, please read [this guide](learn-identity). - -## Proxy Accounts - -Polkadot comes with a generalized proxy account system that allows users to keep keys in cold storage while proxies act on their behalf with restricted (or unrestricted) functionality. See the [proxies](learn-proxies) page for more information. - -## Multi-signature Accounts - -It is possible to create a multi-signature account in Substrate-based chains. A multi-signature account is composed of one or more addresses and a threshold. The threshold defines how many signatories (participating addresses) need to agree on the submission of an extrinsic in order for the call to be successful. - -For example, Alice, Bob, and Charlie set up a multi-sig with a threshold of 2. This means Alice and Bob can execute any call even if Charlie disagrees with it. Likewise, Charlie and Bob can execute any call without Alice. A threshold is typically a number smaller than the total number of members but can also be equal to it, which means they all have to be in agreement. - -> Learn more about multisig accounts from our [technical explainer video](https://www.youtube.com/watch?v=ZJLqszvhMyM&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=25&ab_channel=Polkadot). - -Multi-signature accounts have several uses: - -- securing your own stash: use additional signatories as a 2FA mechanism to secure your funds. One signer can be on one computer, another can be on another, or in cold storage. This slows down your interactions with the chain, but is orders of magnitude more secure. -- board decisions: legal entities such as businesses and foundations use multi-sigs to collectively govern over the entity's treasury. -- group participation in governance: a multi-sig account can do everything a regular account can. A multi-sig account could be a council member in Kusama's governance, where a set of community members could vote as one entity. - -Multi-signature accounts **cannot be modified after being created**. Changing the set of members or altering the threshold is not possible and instead requires the dissolution of the current multi-sig and creation of a new one. As such, multi-sig account addresses are **deterministic**, i.e. you can always calculate the address of a multi-sig just by knowing the members and the threshold, without the account existing yet. This means one can send tokens to an address that does not exist yet, and if the entities designated as the recipients come together in a new multi-sig under a matching threshold, they will immediately have access to these tokens. - -### Generating Addresses of Multi-signature Accounts - -> NOTE: Addresses that are provided to the multi-sig wallets must be sorted. The below methods for generating sort the accounts for you, but if you are implementing your own sorting then be aware that the public keys are compared byte-for-byte and sorted ascending before being inserted in the payload that is hashed. - -Addresses are deterministically generated from the signers and threshold of the multisig wallet. For a code example (in TypeScript) of generating you can view the internals of `@w3f/msig-util` [here](https://github.com/lsaether/msig-util/blob/master/src/actions/deriveAddress.ts). - -The `@w3f/msig-util` is a small CLI tool that can determine the multisignature address based on your inputs. - -```zsh -$ npx @w3f/msig-util@1.0.7 derive --addresses 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr,1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU --threshold 1 -npx: installed 79 in 7.764s --------------------------------- -Addresses: 15o5762QE4UPrUaYcM83HERK7Wzbmgcsxa93NJjkHGH1unvr 1TMxLj56NtRg3scE7rRo8H9GZJMFXdsJk1GyxCuTRAxTTzU -Threshold: 1 -Multisig Address (SS58: 0): 15FKUKXC6kwaXxJ1tXNywmFy4ZY6FoDFCnU3fMbibFdeqwGw --------------------------------- -``` - -The Polkadot-JS Apps UI also supports multi-sig accounts, as documented in the [Account Generation page](learn-account-generation#multi-signature-accounts). This is easier than generating them manually. - -### Making Transactions with a Multi-signature Account - -There are three types of actions you can take with a multi-sig account: - -- Executing a call. -- Approving a call. -- Cancelling a call. - -In scenarios where only a single approval is needed, a convenience method `as_multi_threshold_1` should be used. This function takes only the other signatories and the raw call as its arguments. - -However, in anything but the simple one approval case, you will likely need more than one of the signatories to approve the call before finally executing it. When you create a new call or approve a call as a multi-sig, you will need to place a small deposit. The deposit stays locked in the pallet until the call is executed. The reason for the deposit is to place an economic cost on the storage space that the multi-sig call takes up on the chain and discourage users from creating dangling multi-sig operations that never get executed. The deposit will be reserved in the caller's accounts so participants in multi-signature wallets should have spare funds available. - -The deposit is dependent on the `threshold` parameter and is calculated as follows: - -``` -Deposit = DepositBase + threshold * DepositFactor -``` - -Where `DepositBase` and `DepositFactor` are chain constants set in the runtime code. - -Currently, the DepositBase is equal to `deposit(1, 88)` (key size is 32; value is size 4+4+16+32 = 56 bytes) and the DepositFactor is equal to `deposit(0,32)` (additional address of 32 bytes). - -The deposit function in JavaScript is defined below, cribbed from the [Rust source](https://github.com/paritytech/polkadot/blob/master/runtime/polkadot/src/constants.rs#L26). - -```js -// Polkadot -const DOLLARS = 10000000000; // planck -const MILLICENTS = 100000; // planck - -// Kusama -// const DOLLARS = 166666666666.67; -// const MILLICENTS = 1666666.66; - -const deposit = (items, bytes) => { - return items * 20 * DOLLARS + bytes * 100 * MILLICENTS; -}; - -console.log("DepositBase", deposit(1, 88)); -console.log("DepositFactor", deposit(0, 32)); -``` - -Thus the deposit values can be calculated as shown in the table below. - -| | Polkadot (DOT) | Kusama (KSM) | Polkadot (planck) | Kusama (planck) | -| ------------- | -------------- | -------------- | ----------------- | --------------- | -| DepositBase | 20.088 | 3.347999999942 | 200880000000 | 3347999999942 | -| DepositFactor | .032 | 0.005333333312 | 320000000 | 5333333312 | - -Let's consider an example of a multi-sig on Polkadot with a threshold of 2 and 3 signers: Alice, Bob, and Charlie. First, Alice will create the call on chain by calling `as_multi` with the raw call. When doing this Alice will have to deposit `DepositBase + (2 * DepositFactor) = 20.152 DOT` while she waits for either Bob or Charlie to also approve the call. When Bob comes to approve the call and execute the transaction, he will not need to place the deposit and Alice will receive her deposit back. - -### Example with Polkadot.JS - -For this example, we will be using the [Westend](https://wiki.polkadot.network/docs/en/maintain-networks#westend-test-network) testnet and [Polkadot.JS Apps](https://wiki.polkadot.network/docs/en/learn-balance-transfers#polkadot-js-apps) to create a 2-of-3 multisig address and send a transaction with it. - -> While Westend is meant to replicate the Polkadot mainnet as closely as possible, there are a few notable differences: -> -> - Existential deposit is equal to 0.01 WND (Westies; Westend's native coin) instead of 1 DOT. -> - The multisignature transaction deposit is equal to ~1 WND instead of ~20.2 DOT. -> -> The photos below reflects values in WND, but instructions are the same for DOT. - -**To create a multisig address and send a transaction using it, you will need the following:** - -- List of the multisig member's addresses. We will use Alice, Bob, and Charlie. -- DOT to deposit into the multisig address. -- ~20.2 DOT refundable deposit to send a multisig tarnsaction. This needs to be in the address that initiates a multisignature transaction (in this example, Alice). - -You should already have your own account with some coins in it. - -![Account page](assets/accounts/multisig-addy.png) - -To generate the multisig address, we need to **add the multisig member addresses to the contact book** under "Accounts > Address book". - -![Address book](assets/accounts/multisig-1.png) - -For each address, click "Add contact" in the upper right and provide the address and a name. - -![Add Contact](assets/accounts/multisig-2.png) - -Here, Bob and Charlie have been added. - -![Address books 2](assets/accounts/multisig-3.png) - -**Next, we need to create the new multisignature address.** Navitage to the Accounts page (from the toolbar, "Accounts > Accounts") and click the "+ Multisig" button. We will supply the three multisig member addresses, with a value '2' for the threshold. - -![New multisig](assets/accounts/multisig-4.png) - -Click 'Create', and you should see the new multisig address appear on this Accounts page. - -![5](assets/accounts/multisig-5.png) - -**Let's fund the address now.** For this example, we will transfer some coins from Alice's account to the multisig address. Under Alice's address, click 'Send', select the multisig wallet as the destination, and provide an amount. Then, click 'Make Transfer', and then 'Sign and Submit'. - -![6](assets/accounts/multisig-6.png) ![7](assets/accounts/multisig-7.png) - -We can see that the multisig account now has a balance. - -![9](assets/accounts/multisig-9.png) - -**To send a transaction, we need one of the members to initiate it.** Let's use Alice to initiate the transaction. - -Make sure Alice has enough coins to cover the multisig transaction deposit and the transaction fees. Then, click 'Send' under the "Multisig Test Address", select a destination address (we generated an address locally) and a transfer amount, and click 'Make Transfer'. - -![10](assets/accounts/multisig-10.png) - -To sign as Alice, make sure she is selected as the 'multisig signatory', click 'Sign and Submit', and sign the transaction. - -![11](assets/accounts/multisig-11.png) - -You will now see a pending transaction the 'Multisig Test Address' (the red '1' icon), and if you click the dropdown under Alice's balance, you will see that a value equivalent to the multisig deposit has been 'reserved', rendering that value untransferable until the multisig transaction completes. - -![12](assets/accounts/multisig-12.png) - -**Next, we need a second signature.** Let's get it from Bob. In Bob's browser, repeat the following from the above steps. - -1. Add Alice, Charlie, and the multisig transaction destination addresses to Bob's Address book. -2. Create a new multisig address with the same parameters (Bob, Alice, and Charlie's addresses, and a threshold value of '2'). - -> NOTE: Since multisig address genereation is deterministic, if Bob (or any other member), on his computer, were to generate a multisig address using Alice's, Charlie's and his addresses, with a threshold value of '2', he would produce the **same** multisig address that Alice has here. - -If done correctly, we should see that the **same** multisig address is produced in Bob's browser, and that a pending transaction is displayed, too. - -![13](assets/accounts/multisig-13.png) - -Next, to get Bob's signature, he needs to craft the same multisig transaction that Alice did by providing the same destination address and transfer amount (together, transaction parameters), signing, and submitting it. Alice initiated the transaction by uploading a signature of the hash of the transaction and the hash. These transaction parameters will allow Bob to produce and sign the same transaction (the same hash) that Alice signed earlier. - -![14](assets/accounts/multisig-14.png) - -Click 'Make Transfer', ensure that Bob is the 'multisig signatory', and click 'Sign and Submit'. Note that 'Multisig message with call (for final approval)' is automatically enabled; this means that, since the transaction will reached the signature threshold, it will execute the actual transaction on chain after adding the second signature. - -![15](assets/accounts/multisig-15.png) - -Assuming no errors, 'Multisig Destination Account' has a balance of 0.3 WND, and Alice's account has released the multisig transaction deposit. - -![16](assets/accounts/multisig-16.png) - -## Address Conversion Tools - -You can use the tool below to convert any SS58 address for any network for use on different networks. - -
    - - - -
    - -Alternatively, use [this handy subscan tool](https://polkadot.subscan.io/tools/ss58_transform) or [this simple address address convertor](https://polkadot-address-convertor.netlify.app/). - -## Resources - -- [Understanding Accounts and Keys in Polkadot](https://www.crowdcast.io/e/polkadot-keys) - An explanation of what the different kinds of accounts and keys are used for in Polkadot, with Bill Laboon and Chinmay Patel of BlockX Labs. diff --git a/website/translated_docs/zh-TW/learn-availability.md b/website/translated_docs/zh-TW/learn-availability.md deleted file mode 100644 index 12186d10b0a4..000000000000 --- a/website/translated_docs/zh-TW/learn-availability.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -id: learn-availability -title: Availability and Validity -sidebar_label: Availability and Validity ---- - -The Availability and Validity (AnV) protocol of Polkadot is what allows for the network to be efficiently sharded among parachains while maintaining strong security guarantees. - -## Phases of the AnV protocol - -There are six phases of the Availability and the Validity protocol. - -1. Parachain phase. -2. Relay chain submission phase. -3. Availability and unavailability subprotocols. -4. Secondary GRANDPA approval validity checks. -5. Objection procedure for fishermen. -6. Invocation of a Byzantine fault tolerant _finality gadget_ to cement the chain. - -### Parachain phase - -The parachain phase of AnV is when the _collator_ of a parachain proposes a _candidate block_ to the validators that are currently assigned to the parachain. - -> A **candidate block** is a new block from a parachain collator that may or may not be valid and must go through validity checks before being included into the Relay Chain. - -### Relay chain submission phase - -The validators then check the candidate block against the verification function exposed by that parachain's registered code. If the verification succeeds, then the validators will pass the candidate block to the other validators in the gossip network. However, if the verification fails, the validators immediately reject the candidate block as invalid. - -When more than half of the parachain validators agree that a particular parachain block candidate is a valid state transition, they prepare a _candidate receipt_. The candidate receipt is what will eventually be included into the Relay Chain state. It includes: - -- The parachain ID. -- The collator's ID and signature. -- A hash of the parent block's candidate receipt. -- A Merkle root of the block's erasure coded pieces. -- A Merkle root of any outgoing messages. -- A hash of the block. -- The state root of the parachain before block execution. -- The state root of the parachain after block execution. - -This information is **constant size** while the actual PoV block of the parachain can be variable length. It is enough information for anyone that obtains the full PoV block to verify the state transition contained inside of it. - -### Availability and unavailability subprotocols - -During the availability and unavailability phases, the validators gossip the [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the PoV block of the parachain _available_. - -## Erasure Codes - -Erasure coding transforms a message into a longer _code_ that allows for the original message to be recovered from a subset of the code and in absence of some portion of the code. A code is the original message padded with some extra data that enables the reconstruction of the code in the case of erasures. - -The type of erasure codes used by Polkadot's availability scheme are [Reed-Solomon](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) codes, which already enjoys a battle-tested application in technology outside the blockchain industry. One example is found in the compact disk industry. CDs use Reed-Solomon codes to correct any missing data due to inconsistencies on the disk face such as dust particles or scratches. - -In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their individual pieces of the data. - -**Note:** The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot's security assumption in regard to Byzantine nodes. - -## Fishermen - -Fishermen are full nodes of parachains, same as collators, but perform a different role in relationship to the Polkadot network. Instead of packaging the state transitions and producing the next parachain blocks as collators do, fishermen will watch this process and ensure no invalid state transitions are included. Fishermen will be moderately staked on the Relay Chain, unlike collators that require no stake on the Relay Chain. Fishermen will submit invalidity reports if they find that misconduct has occurred during the production of a parachain. If they are proven right about the reported misconduct, they will be handsomely rewarded, but they risk losing their stake if they're proven wrong. For this reason, fishermen are similar to bounty hunters that get a large payout on completing a job but no steady payout otherwise. - -### How to run a fisherman node - -It is expected that the requirements of running a fisherman will be moderate compared to the staking requirements of validator nodes. Some amount of tokens will be needed to register the "fishing" status on the Relay Chain. These tokens can be potentially slashed by the protocol if the fisherman submits an incorrect invalidity report. The slashing risk is to prevent fishermen from spamming the network since the reconstruction of parachain state is an expensive procedure for the Relay Chain to process. - -On the hardware end of requirements, a moderately powerful machine should be capable of running a full node of one or more parachains. The biggest requirement will likely be the storage of data for each of the parachains that are being fished. However, improvements such as [pruning](https://example.org) mean that the eventual storage size needed to maintain a full node of a parachain will level off at a non-exorbitant amount. RAM and CPU requirements will likely scale with the amount of parachains being fished, with low to moderate requirements for fishing one parachain and increasing from there. A $10 or $20 /month cloud instance will be enough to get started. - -**Note:** Fishermen are not available on Kusama or Polkadot yet! This page will be updated with a guide on setting one up once it becomes possible. - -## Further Resources - -- [Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - Article by Parity analyst Joe Petrowski expounding on the validity checks that a parachain block must pass in order to progress the parachain. -- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) - Paper by the W3F Research Team that specifies the availability and validity protocol in detail. diff --git a/website/translated_docs/zh-TW/learn-balance-transfers.md b/website/translated_docs/zh-TW/learn-balance-transfers.md deleted file mode 100644 index 8dac723ad45c..000000000000 --- a/website/translated_docs/zh-TW/learn-balance-transfers.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: learn-balance-transfers -title: Balance Transfers -sidebar_label: How to transfer Balances ---- - -Balance transfers are used to send balance from one account to another account. To start transferring balances, we will begin by using [Polkadot-JS Apps][]. This guide assumes that you've already [created an account](learn-account-generation) and have some funds that will be transferred. - -## Polkadot-JS Apps - -> NOTE: In this walkthrough we will be using the Polkadot network. If you would like to switch to Kusama or a different network, you can change it by clicking the top left navigation dropdown and selecting a different network. - -Let's begin by opening [Polkadot-JS Apps][]. There are two ways to make a balance transfer: - -1. By using the "Transfer" tab in the "Accounts" dropdown (located on the top navigational menu). -2. Clicking the "send" button while in the "Accounts" page. - -### Using the Transfer Tab - -Click on the "Transfer" tab in the "Accounts" dropdown. - -![transfer](assets/transfer-1.png) - -Now a modal window will appear on the page. The modal asks you to enter 3 inputs: - -- "send from account": Your account with funds that you will send from. -- "send to address": The address of the account that will receive the funds. -- "amount": The amount of tokens you will transfer. - -The "existential deposit" box shows you the minimum amount of funds you must keep in the account for it to remain active. See the [existential deposit][] section for more information. - -![transfer](assets/transfer-2.png) - -After setting your inputs correctly, click the "Make Transfer" button and confirm. Once the transfer is included in a block you will see a green notification in the top-right corner of your screen. - -### Keep-Alive Checks - -At an [extrinsic](glossary#extrinsic) level, there are two main ways to transfer funds from one account to another. These are `transfer` and `transfer_keep_alive`. `transfer` will allow you to send DOTs regardless of the consequence; `transfer_keep_alive` will not allow you to send an amount that would allow the sending account to be removed due to it going below the existential deposit. - -By default, Polkadot-JS Apps will use `transfer_keep_alive`, ensuring that the account you send from cannot drop below the existential deposit (1 DOT or 0.001666 KSM). However, it may be that you do not want to keep this account alive (for example, because you are moving all of your funds to a different address). In this case, click on the "keep-alive" toggle at the bottom of the modal window. The label should switch from "Transfer with account keep-alive checks"(`transfer_keep_alive` will be used) to "Normal transfer without keep-alive checks" (`transfer` extrinsic will be used). As a common use case for using normal transfers is to entirely clear out the account, a second toggle will appear if you have the keep-alive check turned off that will send all the tokens in the account, minus a transaction fee, to the destination address. - -Note that attempting to send less than the existential deposit to an account with 0 DOT will always fail, no matter if the keep-alive check is on or not. For instance, attempting to transfer 0.1 DOT to an account you just generated (and thus has no DOT) will fail, since 0.1 is less than the existential deposit of 1 DOT and the account cannot be initialized with such a low balance. - -Note that even if the transfer fails due to a keep-alive check, the transaction fee will be deducted from the sending account if you attempt to transfer. - -### From the Accounts Page - -Navigate to the "Accounts" page by selecting the "Accounts" tab from the "Accounts" dropdown located on the top navigational menu of Polkadot-JS Apps. - -You will see a list of accounts you have loaded. Click the "Send" button in the row for the account you will like to send funds from. - -![transfer](assets/transfer-3.png) - -Now you will see the same modal window as if using the "Transfer" tab. Fill in the inputs correctly and hit "Make Transfer" then confirm the balance transfer. You will see a green notification in the top-right corner of the screen when the transfer is included in a block. - -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[existential deposit]: build-protocol-info#existential-deposit diff --git a/website/translated_docs/zh-TW/learn-bridges.md b/website/translated_docs/zh-TW/learn-bridges.md deleted file mode 100644 index 4828d64e745d..000000000000 --- a/website/translated_docs/zh-TW/learn-bridges.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -id: learn-bridges -title: Bridges -sidebar_label: Bridges ---- - -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem, however there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there has not been too many that have been used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available. - -> Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated [crosschain](learn-crosschain) page on the Wiki. - -## Bridging Methods - -Building a bridge that is as decentralized and trustless as possible can be done through any of the following methods (ordered by suggested methodology): - -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (eg. Kusama <> Polkadot bridge, since both networks parachains use Substrate). -- _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (eg. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages). -- _Higher-order protocols_ - If your chain does not support smart contracts (eg. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. - -### via Bridge Pallets - -Receiving messages on Polkadot from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level parachain (native extension to the core Polkadot software) or as a community-operated parachain. - -An example of a bridge that would strictly use bridge pallets would be a Kusama <> Polkadot bridge, since both use parachains based on Substrate. - -For the standalone chains that will not have a parachain bridging module on Polkadot (non-Substrate), it will be necessary to deploy bridge contracts (see below). - -### via Smart Contracts - -Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Polkadot and any other smart contract capable blockchain (Ethereum, EOS, Tezos, etc). - -Those who are already familiar with Ethereum may know of the now archived [Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. - -> To learn more on how Bitcoin and Ethereum can Cooperate and Collaborate Through Polkadot, check out this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) - -### via Higher-Order Protocols - -Higher-order protocols (like [XCLAIM](https://eprint.iacr.org/2018/643.pdf)) can be used to bridge, but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead. - -An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <> Polkadot) - As explained by Dr. Gavin Wood in a [blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from late 2019, there are three ways that the Polkadot and Substrate ecosystem can be bridged to the Ethereum ecosystem. - -1. Polkadot <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. - -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <> Substrate <> Polkadot) - -The Interlay team has written a [specification](https://interlay.gitlab.io/polkabtc-spec/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain. - -The Bitcoin bridge as documented in the specification is composed of two logically different components: - -- The XCLAIM component that maintains all accounts that own PolkaBTC. -- The BTC-Relay that is responsible for verifying Bitcoin state when a new transaction is submitted. - -For full details on how it works please refer to the specification. - -## Additional Resources and Examples - -### For Bridge Builders - -If your team is interested in building a bridge between an external chain and Polkadot, there may be funding available from the W3F [grants program](https://github.com/w3f/General-Grants-Program). Please first check that the chain you are intending to bridge between hasn't already been built or is in the process of being built by another team. More popular chains with clear use cases will be given priority, and novel bridge designs are welcome. - -### Resources and Examples - -- [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) -- [Substrate/Ethereum Bridge](https://github.com/ChainSafe/ChainBridge) - ChainSafe and Centrifuge were awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a Substrate to Ethereum two-way bridge. -- [PolkaBTC (Bitcoin <> Polkadot Bridge)](https://docs.polkabtc.io/#/) -- [EOS Bridge](https://github.com/bifrost-codes/bifrost) - The Bifrost team was awarded a grant in W3F Grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a bridge to EOS. -- [Tendermint Bridge](https://github.com/ChorusOne/tendermint-light-client) - ChorusOne was awarded a grant in [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a GRANDPA light client in Tendermint. -- [Interlay BTC Bridge](https://interlay.gitlab.io/polkabtc-spec/) - The Interlay team was awarded a grant in W3F grants [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. -- [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xrml/xbridge/bitcoin) - ChainX have implemented a BTC to Substrate bridge for their parachain. -- [POA Network](https://poa.network/) -- [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. -- [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. -- [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. diff --git a/website/translated_docs/zh-TW/learn-cryptography.md b/website/translated_docs/zh-TW/learn-cryptography.md deleted file mode 100644 index 2fe3ecec16aa..000000000000 --- a/website/translated_docs/zh-TW/learn-cryptography.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: learn-cryptography -title: Cryptography Explainer -sidebar_label: Cryptography Explainer -description: An overview of the cryptographic functions used in Polkadot ---- - -This is a high-level overview of the cryptography used in Polkadot. It assumes that you have some knowledge about cryptographic primitives that are used in blockchains generally such as hashes, elliptic curve cryptography (ECC), and public-private keypairs. - -For detailed descriptions on the cryptography used please see the more advanced [research wiki](https://research.web3.foundation). - -## Hashing Algorithm - -The hashing algorithm used in Polkadot is [Blake2b](https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2). Blake2 is considered to be a very fast cryptographic hash function that is also used in the cryptocurrency [Zcash](https://z.cash). - -## Keypairs and Signing - -Polkadot uses Schnorrkel/Ristretto x25519 ("sr25519") as its key derivation and signing algorithm. - -Sr25519 is based on the same underlying [Curve25519](https://en.wikipedia.org/wiki/Curve25519) as its EdDSA counterpart, [Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519). However, it uses Schnorr signatures instead of the EdDSA scheme. Schnorr signatures bring some noticeable benefits over the ECDSA/EdDSA schemes. For one, it is more efficient and still retains the same feature set and security assumptions. Additionally, it allows for native multisignature through [signature aggregation](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/). - -The names Schnorrkel and Ristretto come from the two Rust libraries that implement this scheme, the [Schnorrkel](https://github.com/w3f/schnorrkel) library for Schnorr signatures and the [Ristretto](https://ristretto.group/ristretto.html) library that makes it possible to use cofactor-8 curves like Curve25519. diff --git a/website/translated_docs/zh-TW/learn-governance.md b/website/translated_docs/zh-TW/learn-governance.md deleted file mode 100644 index 2ead22315e71..000000000000 --- a/website/translated_docs/zh-TW/learn-governance.md +++ /dev/null @@ -1,290 +0,0 @@ ---- -id: learn-governance -title: Governance -sidebar_label: Governance ---- - -Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its assembled stakeholders. The stated goal is to ensure that the majority of the stake can always command the network. - -To do this, we bring together various novel mechanisms, including an amorphous state-transition function stored on-chain and defined in a platform-neutral intermediate language (i.e. [WebAssembly](learn-wasm)) and several on-chain voting mechanisms such as referenda with adaptive super-majority thresholds and batch approval voting. All changes to the protocol must be agreed upon by stake-weighted referenda. - -## Mechanism - -In order to make any changes to the network, the idea is to compose active token holders and the council together to administrate a network upgrade decision. No matter whether the proposal is proposed by the public (DOT holders) or the council, it finally will have to go through a referendum to let all DOT holders, weighted by stake, make the decision. - -To better understand how the council is formed, please read [this section](#council). - -## Referenda - -Referenda are simple, inclusive, stake-based voting schemes. Each referendum has a specific _proposal_ associated with it that takes the form of a privileged function call in the runtime (that includes the most powerful call: `set_code`, which is able to switch out the entire code of the runtime, achieving what would otherwise require a "hard fork"). They are discrete events, have a fixed period where voting happens, and then are tallied and the function call is made if the vote is approved. Referenda are always binary; your only options in voting are "aye", "nay", or abstaining entirely. - -Referenda can be started in one of several ways: - -- Publicly submitted proposals; -- Proposals submitted by the council, either through a majority or unanimously; -- Proposals submitted as part of the enactment of a prior referendum; -- Emergency proposals submitted by the Technical Committee and approved by the Council. - -All referenda have an _enactment delay_ associated with them. This is the period of time between the referendum ending and, assuming the proposal was approved, the changes being enacted. For the first two ways that a referendum is launched, this is a fixed time. For Kusama, it is 8 days; in Polkadot, it is 28 days. For the third type, it can be set as desired. - -Emergency proposals deal with major problems with the network that need to be "fast-tracked". These will have a shorter enactment time. - -### Proposing a Referendum - -#### Public Referenda - -Anyone can propose a referendum by depositing the minimum amount of tokens for a certain period (number of blocks). If someone agrees with the proposal, they may deposit the same amount of tokens to support it - this action is called _seconding_. The proposal with the highest amount of bonded support will be selected to be a referendum in the next voting cycle. Note that this may be different than the absolute number of seconds; for instance, three accounts bonding 20 DOT each would "outweigh" ten accounts bonding a single DOT each. The bonded tokens will be released once the proposal is tabled (that is, brought to a vote). - -There can be a maximum of 100 public proposals in the proposal queue. - -#### Council Referenda - -Unanimous Council - When all members of the council agree on a proposal, it can be moved to a referendum. This referendum will have a negative turnout bias (that is, the smaller the amount of stake voting, the smaller the amount necessary for it to pass - see "Adaptive Quorum Biasing", below). - -Majority Council - When agreement from only a simple majority of council members occurs, the referendum can also be voted upon, but it will be majority-carries (51% wins). - -There can only be one active referendum at any given time, except when there is also an emergency referendum in progress. - -#### Voting Timetable - -Every 28 days on Polkadot or 7 days on Kusama, a new referendum will come up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues. - -The "top" proposal is determined by the amount of stake bonded behind it. If the given queue whose turn it is to create a referendum has no proposals (is empty), and there are proposals waiting in the other queue, the top proposal in the other queue will become a referendum. - -Multiple referenda cannot be voted upon in the same time period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public- or council-proposed) is the only time that multiple referenda will be able to be voted on at once. - -#### Voting on a referendum - -To vote, a voter generally must lock their tokens up for at least the enactment delay period beyond the end of the referendum. This is in order to ensure that some minimal economic buy-in to the result is needed and to dissuade vote selling. - -It is possible to vote without locking at all, but your vote is worth a small fraction of a normal vote, given your stake. At the same time, holding only a small amount of tokens does not mean that the holder cannot influence the referendum result, thanks to time-locking. You can read more about this at [Voluntary Locking](#voluntary-locking). - -> To learn more about voting on referenda, please check out our [technical explainer video](https://www.youtube.com/watch?v=BkbhhlsezGA&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=31&ab_channel=Polkadot). - -``` -Example: - -Peter: Votes `No` with 10 DOT for a 128 week lock period => 10 * 6 = 60 Votes - -Logan: Votes `Yes` with 20 DOT for a 4 week lock period => 20 * 1 = 20 Votes - -Kevin: Votes `Yes` with 15 DOT for a 8 week lock period => 15 * 2 = 30 Votes -``` - -Even though combined both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter, leading to their voting power counting as less. - -#### Tallying - -Depending on which entity proposed the proposal and whether all council members voted yes, there are three different scenarios. We can use following table for reference. - -| **Entity** | **Metric** | -|:----------------------------:|:----------------------------------------------:| -| Public | Positive Turnout Bias (Super-Majority Approve) | -| Council (Complete agreement) | Negative Turnout Bias (Super-Majority Against) | -| Council (Majority agreement) | Simple Majority | - -Also, we need the following information and apply one of the formulas listed below to calculate the voting result. For example, let's use the public proposal as an example, so the `Super-Majority Approve` formula will be applied. There is no strict quorum, but the super-majority required increases as turnout lowers. - -``` -approve - the number of aye votes - -against - the number of nay votes - -turnout - the total number of voting tokens (does not include conviction) - -electorate - the total number of DOT tokens issued in the network -``` - -##### Super-Majority Approve - -A `positive turnout bias`, whereby a heavy super-majority of aye votes is required to carry at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{turnout}}&space;<&space;{approve&space;\over&space;\sqrt{electorate}}) - -##### Super-Majority Against - -A `negative turnout bias`, whereby a heavy super-majority of nay votes is required to reject at low turnouts, but as turnout increases towards 100%, it becomes a simple majority-carries as below. - -![](https://latex.codecogs.com/svg.latex?\large&space;{against&space;\over&space;\sqrt{electorate}}&space;<&space;{approve&space;\over&space;\sqrt{turnout}}) - -##### Simple-Majority - -Majority-carries, a simple comparison of votes; if there are more aye votes than nay, then the proposal is carried, no matter how much stake votes on the proposal. - -![](https://latex.codecogs.com/svg.latex?\large&space;{approve}&space;>&space;{against}) - -_To know more about where these above formulas come from, please read the [democracy pallet](https://github.com/paritytech/substrate/blob/master/frame/democracy/src/vote_threshold.rs)_. - -``` -Example: - -Assume: -- We only have 1,500 DOT tokens in total. -- Public proposal - -John - 500 DOT -Peter - 100 DOT -Lilly - 150 DOT -JJ - 150 DOT -Ken - 600 DOT - -John: Votes `Yes` for a 4 week lock period => 500 * 1 = 500 Votes - -Peter: Votes `Yes` for a 4 week lock period => 100 * 1 = 100 Votes - -JJ: Votes `No` for a 16 week lock period => 150 * 3 = 450 Votes - -approve = 600 -against = 450 -turnout = 750 -electorate = 1500 -``` - -![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}) - -![\Large {16.432}&space;<&space;{15.492}](https://latex.codecogs.com/svg.latex?\large&space;{16.432}&space;<&space;{15.492}) - -Since the above example is a public referendum, `Super-Majority Approve` would be used to calculate the result. `Super-Majority Approve` requires more `aye` votes to pass the referendum when turnout is low, therefore, based on the above result, the referendum will be rejected. In addition, only the winning voter's tokens are locked. If the voters on the losing side of the referendum believe that the outcome will have negative effects, their tokens are transferrable so they will not be locked in to the decision. Moreover, winning proposals are autonomously enacted only after some enactment period. - -#### Voluntary Locking - -Polkadot utilizes an idea called `Voluntary Locking` that allows token holders to increase their voting power by declaring how long they are willing to lock-up their tokens, hence, the number of votes for each token holder will be calculated by the following formula: - -``` -votes = tokens * conviction_multiplier -``` - -The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. - -| Lock Periods | Vote Multiplier | -|:------------:|:---------------:| -| 0 | 0.1 | -| 1 | 1 | -| 2 | 2 | -| 4 | 3 | -| 8 | 4 | -| 16 | 5 | -| 32 | 6 | - -The maximum number of "doublings" of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days on Polkadot and 8 days on Kusama. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5, for instance. - -While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account. - -Votes are still "counted" at the same time (at the end of the voting period), no matter for how long the tokens are locked. - -#### Adaptive Quorum Biasing - -Polkadot introduces a concept, "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective super-majority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it. - -![](assets/governance/adaptive-quorum-biasing.png) - -Let's use the above image as an example. - -If a publicly submitted referendum only has 25% turnout, the tally of "aye" votes has to reach 66% for it to pass since we applied `Positive Turnout Bias`. - -In contrast, when it has 75% turnout, the tally of "aye" votes has to reach 54%, which means that the super-majority required decreases as the turnout increases. - -When the council proposes a new proposal through unanimous consent, the referendum would be put to a vote using "Negative Turnout Bias". In this case it is easier to pass this proposal with low turnout and requires a super-majority to reject. As more token holders participate in voting, the bias approaches a plain majority carries. - -Referring to the above image, when a referendum only has 25% turnout, the tally of "aye" votes has to reach 34% for it to pass. - -In short, when turnout rate is low, a super-majority is required to reject the proposal, which means a lower threshold of "aye" votes have to be reached, but as turnout increases towards 100%, it becomes a simple-majority. - -All three tallying mechanisms - majority carries, super-majority approve, and super-majority against - equate to a simple majority-carries system at 100% turnout. - -## Council - -> [Video explainer on Council](https://www.youtube.com/watch?v=837Vv3gdRzI) - -To represent passive stakeholders, Polkadot introduces the idea of a "council". The council is an on-chain entity comprising a number of actors, each represented as an on-chain account. On Polkadot, the council currently consists of 13 members. This is expected to increase over the next few months to 24 seats. In general, the council will end up having a fixed number of seats. On Polkadot, this will be 24 seats while on Kusama it is 19 seats. - -Along with [controlling the treasury](learn-treasury), the council is called upon primarily for three tasks of governance: proposing sensible referenda, cancelling uncontroversially dangerous or malicious referenda, and electing the technical committee. - -For a referendum to be proposed by the council, a strict majority of members must be in favor, with no member exercising a veto. Vetoes may be exercised only once by a member for any single proposal; if, after a cool-down period, the proposal is resubmitted, they may not veto it a second time. Council motions which pass with a 3/5 (60%) super-majority - but without reaching unanimous support - will move to a public referendum under a neutral, majority-carries voting scheme. In the case that all members of the council vote in favor of a motion, the vote is considered unanimous and becomes a referendum with negative adaptive quorum biasing. - -### Canceling - -A proposal can be canceled if the [technical committee](#technical-committee) unanimously agrees to do so, or if Root origin (e.g. sudo) triggers this functionality. A canceled proposal's deposit is burned. - -Additionally, a two-thirds majority of the council can cancel a referendum. This may function as a last-resort if there is an issue found late in a referendum's proposal such as a bug in the code of the runtime that the proposal would institute. - -If the cancellation is controversial enough that the council cannot get a two-thirds majority, then it will be left to the stakeholders _en masse_ to determine the fate of the proposal. - -### Blacklisting - -A proposal can be blacklisted by Root origin (e.g. sudo). A blacklisted proposal and its related referendum (if any) is immediately [canceled](#canceling). Additionally, a blacklisted proposal's hash cannot re-appear in the proposal queue. Blacklisting is useful when removing erroneous proposals that could be submitted with the same hash, i.e. [proposal #2](https://polkascan.io/polkadot/democracy/proposal/2) in which the submitter used plain text to make a suggestion. - -Upon seeing their proposal removed, a submitter who is not properly introduced to the democracy system of Polkadot might be tempted to re-submit the same proposal. That said, this is far from a fool-proof method of preventing invalid proposals from being submitted - a single changed character in a proposal's text will also change the hash of the proposal, rendering the per-hash blacklist invalid. - -### How to be a council member? - -![](assets/governance/approval-vote.png) - -All stakeholders are free to signal their approval of any of the registered candidates. - -Council elections are handled by the same [Phragmén election](learn-phragmen) process that selects validators from the available pool based on nominations. However, token holders' votes for councillors are isolated from any of the nominations they may have on validators. Council terms last for one day on Kusama and one week on Polkadot. - -At the end of each term, [Phragmén election algorithm](learn-phragmen) runs and the result will choose the new councillors based on the vote configurations of all voters. The election also chooses a set number of runners up (currently 19 on Kusama and 20 on Polkadot) that will remain in the queue with their votes intact. - -As opposed to a "first-past-the-post" electoral system, where voters can only vote for a single candidate from a list, a Phragmén election is a more expressive way to include each voters' views. Token holders can treat it as a way to support as many candidates as they want. The election algorithm will find a fair subset of the candidates that most closely matches the expressed indications of the electorate as a whole. - -Let's take a look at the example below. - -| Round 1 | | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | | -| | A | B | C | D | E | -| Peter | X | | X | X | X | -| Alice | | X | | | | -| Bob | | | X | X | X | -| Kelvin | X | | X | | | -| **Total** | 2 | 1 | 3 | 2 | 2 | - -The above example shows that candidate C wins the election in round 1, while candidate A, B, D & E keep remaining on the candidates' list for the next round. - -| Round 2 | | | | | -|:-----------------:|:-:|:--------------:|:-:|:-:| -| **Token Holders** | | **Candidates** | | | -| | A | B | D | E | -| Peter | X | X | | | -| Alice | X | X | | | -| Bob | X | X | X | X | -| Kelvin | X | X | | | -| **Total** | 4 | 4 | 1 | 1 | - -For the top-N (say 4 in this example) runners-up, they can remain and their votes persist until the next election. After round 2, even though candidates A & B get the same number of votes in this round, candidate A gets elected because after adding the older unused approvals, it is higher than B. - -This is the tentative governance configuration for Polkadot post-genesis. It will be changed if any security loopholes have been found after several rounds of third-party auditing. Further changes can be made through on-chain governance. - -### Prime Members - -The council, being an instantiation of Substrate's Collective pallet, implements what's called a _prime member_ whose vote acts as the default for other members that fail to vote before the timeout. - -The prime member is chosen based on a [Borda count](https://en.wikipedia.org/wiki/Borda_count). - -The purpose of having a prime member of the council is to ensure a quorum, even when several members abstain from a vote. Council members might be tempted to vote a "soft rejection" or a "soft approval" by not voting and letting the others vote. With the existence of a prime member, it forces councillors to be explicit in their votes or have their vote counted for whatever is voted on by the prime. - -## Technical Committee - -The Technical Committee was introduced in the [Kusama rollout and governance post](https://polkadot.network/kusama-rollout-and-governance/) as one of the three chambers of Kusama governance (along with the Council and the Referendum chamber). The Technical Committee is composed of the teams that have successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host. Teams are added or removed from the Technical Committee via simple majority vote of the [Council](#council). - -The Technical Committee can, along with the Council, produce emergency referenda, which are fast-tracked for voting and implementation. These emergency referenda are intended for use only under urgent circumstances. - -Fast-tracked referenda are the only type of referenda that can be active alongside another active referendum. Thus, with fast tracked referenda it is possible to have two active referendums at the same time. Voting on one does not prevent a user from voting on the other. - -## Frequently Asked Questions - -### How can I appeal to the council to enact a change on my behalf? - -In some circumstances you may want to appeal to the on-chain council to enact a change on your behalf. One example of this circumstance is the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network). Another example is if you participated in the 2017 Polkadot ICO with a multi-sig address which now does not let you sign a message easily. When these circumstances can be proven beyond a reasonable doubt to be an error, the council _may_ consider a governance motion to correct it. - -The first step to appeal to the council is to get in contact with the councillors. There is no singular place where you are guaranteed to grab every councillor's ear with your message. However, there are a handful of good places to start where you can get the attention of some of them. The [Polkadot Direction](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io) matrix room is one such place. After creating an account and joining this room, you can post a well thought-through message here that lays down your case and provides justification for why you think the council should consider enacting a change to the protocol on your behalf. - -At some point you will likely need a place for a longer form discussion. For this, making a post on [Polkassembly](https://polkadot.polkassembly.io/) is the recommended place to do so. When you write a post on Polkassembly make sure you present all the evidence for your circumstances and state clearly what kind of change you would suggest to the councillors to enact. Remember - the councillors do not need to make the change, it is your responsibility to make a strong case for why the change should be made. - -## Resources - -- [Initial Governance Description](https://github.com/paritytech/polkadot/wiki/Governance) -- [Democracy Pallet](https://github.com/paritytech/substrate/tree/master/frame/democracy/src) -- [Governance Demo](https://www.youtube.com/watch?v=VsZuDJMmVPY&feature=youtu.be&t=24734) - Dr. Gavin Wood presents the initial governance structure for Polkadot. (Video) -- [Governance on Polkadot](https://www.crowdcast.io/e/governance-on-polkadot--) - A webinar explaining how governance works in Polkadot and Kusama. diff --git a/website/translated_docs/zh-TW/learn-ledger.md b/website/translated_docs/zh-TW/learn-ledger.md deleted file mode 100644 index df0500de3720..000000000000 --- a/website/translated_docs/zh-TW/learn-ledger.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: learn-ledger -title: Using the Polkadot Ledger Application -sidebar_label: Ledger Application ---- - -> Note: Because of required WebUSB support, Ledger wallets currently only work on Chromium-based browsers like Brave and Chrome. - -The Polkadot [Ledger][] application is compatible with both the Ledger Nano S and the Ledger Nano X devices. Ledger devices are hardware wallets that keep your secret secured on a physical device that does not expose it to your computer or the internet. - -The Polkadot Ledger application allows you to manage Polkadot's native token, the DOT. It supports most of the transaction types of the network (a notable exception is the "Batch" transaction from the Utility pallet). - -If you have trouble using Ledger or following the directions below, you can try searching for your issue on the [Polkadot Knowledge Base](https://support.polkadot.network/). - -> Please check out our [intro to Ledger video on Youtube for more information](https://www.youtube.com/watch?v=p24yOcLLFmI&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=33&ab_channel=Polkadot). - -## Requirements - -Here is a list of what you will need before starting: - -- A Ledger Nano S or a Ledger Nano X. -- The latest firmware installed (at the time of writing this is 1.6.1 on the Nano S, and 1.2.4-4 on the Nano X). -- Ledger Live is installed and at version 2.1 or newer (see settings -> about to find out if you're up to date). -- A Chromium-based web browser is installed that you can use to access [Polkadot-JS Apps][]. - -## Installing the Ledger Application - -### Using Ledger Live - -- Open the "Manager" tab in Ledger Live. -- Connect and unlock your Ledger device. -- If asked, allow the manager on your device by pressing both buttons on the YES screen. -- Find Polkadot in the app catalog and install it. - -![The Polkadot App in the Ledger Manager](assets/ledger/manager-app-polkadot.png) - -Please proceed to the [usage instructions](#using-on-polkadot-js-apps) below. - -### Using the Developer Release - -> NOTE: These instructions are for development installation only. It is recommended to install the application from Ledger Live unless you _know exactly what you're doing_. - -Instructions for downloading the prerelease binary from the GitHub releases are written [in the README][prerelease instructions] for the Polkadot Ledger application GitHub repository. - -On the [releases page][] you can download the shell script `install_app.sh` and then make it executable in your shell by typing the command `chmod +x install_app.sh`. - -Using `install_app.sh` `help` command will show you the available options: - -```zsh -$ ./install_app.sh --help -Zondax Installer [Polkadot-1.2011.1] [Warning: use only for test/demo apps] - load - Load Polkadot app - delete - Delete Polkadot app - version - Show Polkadot app version -``` - -Next, you must make sure your Ledger device is plugged in and unlocked and you're using the latest firmware (1.6.1 at the time of writing). If everything is prepared, then type `./install_app.sh load` and accept the prompts on your Ledger device to install the application. - -First it will prompt you to allow an unsafe manager - confirm this by switching the screen to the allow screen and pressing the corresponding buttons. - -After some processing time, the screen of your device will update to say "Install app Polkadot". Navigate all the way to the right, verify the Identifier hash matches the one that is printed in your terminal. Click both buttons on "Perform Installation" to install the application. It will ask again for your PIN code. - -At the end of the process you should have the newly installed Polkadot application on the device. - -## Using on Polkadot-JS Apps - -> Note: Ledger Live should be off while using Ledger with Polkadot JS Apps as it can interfere with normal operation. - -### Loading Your Account - -[Polkadot-JS Apps][] already has an integration with the Ledger application so that your device will work with the browser interface after installation. The functionality is currently gated behind a feature setting that you will need to turn on. - -In order to turn on the interoperability with the Polkadot Ledger application, go to the "Settings" tab in Polkadot-JS Apps. Find the option for attaching Ledger devices and switch the option from the default "Do not attach Ledger devices" to "Attach Ledger via WebUSB". Be aware: if you are not seeing this it is because there is [no Ledger support](https://github.com/polkadot-js/apps/issues/3771) on FireFox. - -![Dropdown selector for allowing Ledger connections in PolkadotJS Settings](assets/ledger.png) - -Click "Save" to keep your settings. - -Now when you go to the "Accounts" tab you will see a new button that says "Add Ledger". Ensure that your Ledger device is unlocked and you have navigated into the Polkadot application, then click this button. - -![Add Ledger button in PolkadotJS](assets/ledger/query-ledger.png) - -A popup will appear asking you to select an account and derivation path. - -![Picking an account and derivation path](assets/ledger/add-account.png) - -The first input will let you name your account if you have not done so already. If you have already named your account, this will not change the existing name. The first dropdown lets you select an account. You can have multiple accounts on a single Ledger device. The second dropdown lets you pick a derivation path - think of it like a formula from which child accounts are generated. If in doubt, pick the first option for both. 0 / 0 is a good default. - -Once you confirm your selection, depending on your browser and its security settings, you might need to confirm the USB connection through a popup like the one below when adding the Ledger device for the first time: - -![Display the device connection popup](assets/ledger/query-device.png) - -Click on the "Unknown device" line and the "Connect" button will become available. - -You should now be able to scroll down and find a new account on the page with the type "ledger". - -![Displaying the Ledger account in the list](assets/ledger/ledger-balance.png) - -You can now use this account to interact with Polkadot on Polkadot-JS Apps and it will prompt your ledger for confirmation when you initiate a transaction. - -### Confirming the Address on your Device - -On the "Accounts" tab, find your Ledger-connected account. Click on the three vertical dots at the end of the row. This will open a new menu, here you can click the "Show address on hardware device" option to display the address on your device. - -![Options menu of an account in the Accounts screen of PolkadotJS](assets/ledger-4.png) - -Here you can scroll through and make sure the address matches to what is displayed on Polkadot-JS Apps. - -### Checking the Balance of Your Account - -There are a few methods to check the balance of your account. You can use Polkadot-JS Apps or you can use a block explorer like [Polkascan][] or [Subscan][]. - -#### Using Polkadot-JS Apps - -Once you have your account loaded on the "Accounts" tab it should show a row with your Ledger account. At the far right of the row is located your account's DOT balance. If you expand the balance arrow, it will show details of your balance such as locks or reserved amounts. - -![Account row showing empty balance](assets/ledger/ledger-balance.png) - -### Sending a Transfer - -Instructions to send a transfer can be found on the [balance transfer page](learn-balance-transfers). - -### Receiving a Transfer - -In order to receive a transfer on the accounts stored on your Ledger device, you will need to provide the sender (i.e. the payer) with your address. - -The easiest way to get your address is to click on the account name which will open a sidebar. Your address will be shown in this sidebar, along with some other information. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. - -> **Warning**: before giving anyone your address, make sure it matches what's really on the Ledger by [confirming the address on your device](#confirming-the-address-on-your-device). Some malware will intercept clicks and clipboard requests and can change your copied value in-flight, so being extra vigilant around copy-paste operations makes sense. - -### Staking - -Since Ledger does not support batch transactions, you must do two separate transactions when you want to stake using an account stored on a Ledger device. - -- Go to the "Staking" tab found under the "Network" dropdown in the top navigation menu. -- Click the "Account Actions" pane in the inner navigation. -- Click "+ Stash" instead of "+ Nominator" or "+ Validator" (selecting the latter two will not work). -- Input the amount of tokens to bond and confirm the transaction. -- Confirm the transaction on the Ledger device. -- When the transaction is included you will see the newly bonded account in the "Account Actions" page. -- Select "Start Nominating" or "Start Validating" to start nominating or validating. -- Confirm the transaction on Apps and on the Ledger device. - -### Removing Expired Democracy Locks - -Since Ledger does not support batch transactions, you must issue several extrinsics manualy when you want remove expired democracy locks on an account stored on a Ledger device. - -- Go to https://polkadot.js.org/apps/#/accounts. Look at your expired locks and note which referenda they were for. -- Go to https://polkadot.js.org/apps/#/extrinsics -- For each referendum with an expired lock, issue a "democracy.removeVote(X)" extrinsic, where X = the referendum you voted on and has an expired lock. Make sure you do it from the account with the expired locks - you can't do it from another account. -- Once you have removed all of the votes, issue a "democracy.unlock(ACCOUNT)" extrinsic, where ACCOUNT is the account you just removed the votes from. -- Go back to https://polkadot.js.org/apps/#/accounts. You'll see that the locks are now removed. - -## Support - -If you need support please send an email to [support@polkadot.network](mailto:support@polkadot.network) or visit our [Support Page](https://support.polkadot.network). - -[Ledger]: https://www.ledger.com/ -[Polkadot-JS Apps]: https://polkadot.js.org/apps -[prerelease instructions]: https://github.com/Zondax/ledger-polkadot#download-and-install -[releases page]: https://github.com/Zondax/ledger-polkadot/releases -[Polkascan]: https://polkascan.io/polkadot -[Subscan]: https://polkadot.subscan.io/ diff --git a/website/translated_docs/zh-TW/learn-registrar.md b/website/translated_docs/zh-TW/learn-registrar.md deleted file mode 100644 index aae5b92cc224..000000000000 --- a/website/translated_docs/zh-TW/learn-registrar.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: learn-registrar -title: Using W3F Registrar -sidebar_label: How to use W3F Registrar ---- - -An on-chain identity is a good way to build up your reputation and let the community know more about you if you plan on running a validator or being a councilor. Web3 Foundation provides a registrar service in the Kusama and Polkadot networks that only charges a small fee (0.04 KSM) on Kusama, and no fees on Polkadot (although there may be a small fee in the future). However, you will of course need to reserve some DOT in your account while you have an identity, no matter which registrar you use. For details on amount necessary to reserve, as well as the identity system as a whole, see the [identity](learn-identity) page. - -> **Note**: The registrar bot will not ask you to send any DOT, and never expose your private keys to anyone! - -If you have provided `display name`, `email`, `twitter`, or `element name (previously called Riot)` when setting an on-chain identity, these will be required to verify one by one by signing a challenge message. Be aware that the `display name` cannot be too similar to others that have verified already. There is no need to set all of the fields when using the service. You are free to set whichever field or fields that you like. - -Free feel to join the [Polkadot's community](community#polkadot) to ask questions if there is anything unclear. - -## Setting an On-chain Identity - -> **Note**: The W3F Registrar currently **does not** support KYC or web verification. Make sure to leave it blank when you fill in your identity information. - -Go to [Accounts]((https://polkadot.js.org/apps/#/accounts)) page in Polkadot-JS Apps. The easiest way to add the built-in fields is to click the vertical three dots next to one's account and select "Set on-chain identity". - -![registrar](assets/registrar/1.jpg) - -A popup will appear, offering the default fields. - -Currently, the registrar only supports the following fields: - -- Display Name. -- Element (formerly known as Riot) -- Email -- Twitter - -![registrar](assets/registrar/2.jpg) - -Once you have filled in the information you would like to store on-chain, click `Set Identity` to submit the transaction. - -![registrar](assets/registrar/3.jpg) - -Now you have set the identity information on-chain, but that is not verified yet, so you should see a little grey icon beside your name. It is the time to interact with the W3F's verification bot by submitting the judgment request to the W3F's registrar. - -## Request Judgement - -![registrar](assets/registrar/4.jpg) - -Go to [Developer->Extrinics](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics) and select your account to submit the `identity -> requestJudgement(reg_index, max_fee)` transaction. This will request the registrar to validate the information you set on-chain earlier. - -The `reg_index` is the position of the registrar. For W3F, use 0. - -The `max_fee` is the amount of DOT or KSM to pay the registrar. For Kusama use **0.04 KSM** and for Polkadot use **0 DOT**. - -Note that in the future, a fee may be charged for the Polkadot registrar. - -## Element Verification - -Since we provided the Element, Twitter, and Email information in this example, we would start to receive the verification requests from those platforms. As for Element, an invitation will be sent by the bot named "W3F Registrar Verification". - -> Note: The handle of the W3F bot is called @registrar:web3.foundation. If you are not sure whether that is ours or not, ask in the Polkadot community chat first. - -![registrar](assets/registrar/5.jpg) - -Once you accept the invitation, you should see the following information. - -![registrar](assets/registrar/6.jpg) - -Then go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message". - -![registrar](assets/registrar/7.jpg) - -Copy the result of the "signature of supplied data" and paste it to the W3F Registrar Verification chat. - -![registrar](assets/registrar/8.jpg) - -If the information is correct, you should see a message like the above image that indicates your address has been verified. This basically proves you are the owner of the account. - -## Email Verification - -Next, you should receive an email called "W3F Registrar Verification Service". Below is an example for reference. - -> Note: Please double-check the sender is "registrar@web3.foundation", not the others. - -![registrar](assets/registrar/9.jpg) - -You would do what you did in the above again. Copy the "Challenge" data and go to [Sign and Verify](https://polkadot.js.org/apps/#/signing) under the Developer tab in the PolkadotJS and select your account, paste the "Challenge" data to the "sign the following data" field and click "Sign message" - -![registrar](assets/registrar/10.jpg) - -And reply with your signed data only in the email. Then click "Send". - -> Note: Do not add anything in the email except the signed data. - -![registrar](assets/registrar/11.jpg) - -Wait 1 or 2 minutes. You should receive another email that shows your email has been verified successfully. - -## Twitter Verification - -Lastly, if you have provided Twitter handle, you would have to follow [@w3f_registrar](https://twitter.com/w3f_registrar) first. - -After following the Registrar account on Twitter, you will need to send it a DM. A simple "hello" will do the trick. - -![registrar](assets/registrar/12.jpg) - -After waiting a few mintues you should receive a challenge similar to the previous two. - -![registrar](assets/registrar/13.jpg) - -Again, just like how you did in the above. By using your account to sign the "Challenge" data that you received on Twitter in the [Sign and Verify](https://polkadot.js.org/apps/#/signing) page. - -![registrar](assets/registrar/14.jpg) - -Paste the signed data to the chat and you would receive the verification status after 1 to 2 minutes. - -If everything has been verified successfully, you would see your account verification status has been marked as "reasonable" with a green tick icon on the [Accounts](https://polkadot.js.org/apps/#/accounts) page. - -![registrar](assets/registrar/15.jpg) - -Congratulations! Your identity should now show as a green "verified" checkmark on Polkadot-JS Apps. diff --git a/website/translated_docs/zh-TW/learn-staking.md b/website/translated_docs/zh-TW/learn-staking.md deleted file mode 100644 index dcca4d25b8df..000000000000 --- a/website/translated_docs/zh-TW/learn-staking.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: learn-staking -title: Staking -sidebar_label: Staking ---- - -Polkadot uses NPoS (Nominated Proof-of-Stake) as its mechanism for selecting the validator set. It is designed with the roles of **validators** and **nominators**, to maximize chain security. Actors who are interested in maintaining the network can run a validator node. At genesis, Polkadot will have a limited amount of slots available for these validators, but this number will grow over time to over one thousand. - -The system encourages DOT holders to participate as nominators. Nominators may back up to 16 validators as trusted validator candidates. - -Validators assume the role of producing new blocks in [BABE](learn-consensus#babe), validating parachain blocks, and guaranteeing finality. Nominators can choose to back select validators with their stake. - -The staking system pays out rewards essentially equally to all validators regardless of stake. Having more stake on a validator does not influence the amount of block rewards it receives. However, there is a probabilistic component to reward calculation (discussed below), so rewards may not be exactly equal for all validators in a given era. - -Distribution of the rewards are pro-rata to all stakers after the validator payment is deducted. In this way, the network incents the nomination of lower-staked validators to create an equally-staked validator set. - -## How does staking work in Polkadot? - -### 1. Identifying which role you are - -In staking, you can be either a [nominator or a validator](#validators-and-nominators). - -As a nominator, you can nominate one or more (up to 16) validator candidates that you trust to help you earn rewards in DOT. You can take a look at the [nominator guide](learn-nominator) to understand what you are required to do when the mainnet launches. - -A validator node is required to be responsive 24/7, perform its expected duties in a timely manner, and avoid any slashable behavior. You can follow our [Kusama validator guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) if you would like to run a validator on Kusama. - -### 2. Nomination period - -Any potential validators can indicate their intention to be a validator candidate. Their candidacies are made public to all nominators, and a nominator in turn submits a list of any number of candidates that it supports. In the next epoch (lasting several hours), a certain number of validators having the most DOT backing get elected and become active. There are no particular requirements for a DOT holder to become a nominator, though we expect each nominator to carefully track the performance and reputation of validators. - -Once the nomination period ends, the NPoS election mechanism takes the nominators and their associated votes as input, and outputs a set of validators of the required size, that maximizes the stake backing of any validator, and that makes the stakes backing validators as evenly distributed as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read [here](http://research.web3.foundation/en/latest/polkadot/NPoS.html). - -### 3. Staking Rewards Distribution - -To explain how rewards are paid to validators and nominators, we need to consider **validator pools**, where a validator pool consists of an elected validator together with the nominators backing it. (Note: if a nominator `n` with stake `s` backs several elected validators, say `k`, the NPoS election mechanism will split its stakes into pieces `s_1`, `s_2`, …, `s_k`, so that it backs validator `i` with stake `s_i`. In that case, nominator `n` will be rewarded essentially the same as if there were `k` nominators in different pools, each backing a single validator `i` with stake `s_i`). For each validator pool, we keep a list of nominators with the associated stakes. - -The general rule for rewards across validator pools is that two validator pools get paid essentially the **same amount of DOT** for equal work, i.e. they are NOT paid proportional to the stakes in each pool. There is a probabilistic component to staking rewards in the form of [era points](maintain-guides-validator-payout#era-points) and [tips](https://wiki.polkadot.network/docs/en/learn-transaction-fees#fee-calculation) but these should average out over time. Within a validator pool, a (configurable) percentage of the reward goes to pay the validator's commission fees and the remainder is paid **pro-rata** (i.e. proportional to stake) to the nominators and validator. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with stake. - -To estimate the inflation rate and how many DOT you can get each month as a nominator or validator, you can use this [tool](https://www.stakingrewards.com/earn/polkadot/calculate) as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator. - -### 4. Rewards Mechanism - -We highlight two features of this payment scheme. The first is that since validator pools are paid the same regardless of stake level, pools with less stake will generally pay more to nominators per-DOT than pools with more stake. We thus give nominators an economic incentive to gradually shift their preferences to lower staked validators that gain a sufficient amount of reputation. The reason for this is that we want the stake across validator pools to be as evenly distributed as possible, to avoid a concentration of power among a few validators. In the long term, we expect all validator pools to have similar levels of stake, with the stake being higher for higher reputation validators (meaning that a nominator that is willing to risk more by backing a validator with a low reputation will get paid more). - -The following example should clarify the above. For simplicity, we have the following assumptions: - -- These validators do not have a stake of their own. -- They each receive the same number of era points. -- There are no tips for any transactions processed. -- They do NOT charge any commission fees. -- Total reward amount is 100 DOT tokens. -- The current minimum amount of DOT to be a validator is 350 (note that this is _not_ the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see [here](https://wiki.polkadot.network/docs/en/faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator)). - -| | **A - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (600) | Fraction of the Total Stake | Rewards | -| Jin | 100 | 0.167 | 16.7 | -| **Sam** | 50 | 0.083 | 8.3 | -| Anson | 250 | 0.417 | 41.7 | -| Bobby | 200 | 0.333 | 33.3 | - -| | **B - Validator Pool** | | | -|:-------------:|:----------------------:|:---------------------------:|:-------:| -| Nominator (4) | Stake (400) | Fraction of the Total Stake | Rewards | -| Alice | 100 | 0.25 | 25 | -| Peter | 100 | 0.25 | 25 | -| John | 150 | 0.375 | 37.5 | -| **Kitty** | 50 | 0.125 | 12.5 | - -_Both validator pools A & B have 4 nominators with the total stake 600 and 400 respectively._ - -Based on the above rewards distribution, nominators in validator pool B get more rewards per DOT than those in pool A because pool A has more overall stake. Sam has staked 50 DOT in pool A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake. - -There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Polkadot and Kusama, this limit is currently {{ polkadot_max_nominators }}, although this can be modified via runtime upgrade. A validator with more than -{{ polkadot_max_nominators }} nominators is _oversubscribed_. When payouts occur, only the top -{{ polkadot_max_nominators }} nominators as measured by amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so. - -We also remark that when the network slashes a validator slot for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and NOT a fixed amount of DOT), which means that validator pools with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy. - -The second point to note is that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validator pools are paid the same, pools with lower commission fees pay more to nominators than pools with higher fees. Thus, each validator can choose between increasing their fees to earn more DOT, or decreasing their fees to attract more nominators and increase their chances of being elected. We will let the market regulate itself in this regard. In the long term, we expect that all validators will need to be cost efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair). - -## Accounts - -There are two different accounts for managing your funds: `Stash` and `Controller`. - -![staking](assets/NPoS/staking-keys_stash_controller.png) - -- **Stash:** This account holds funds bonded for staking, but delegates some functions to a Controller. As a result, you may actively participate with a Stash key kept in a cold wallet, meaning it stays offline all the time. You can also designate a Proxy account to vote in [governance](./learn-governance) proposals. -- **Controller** This account acts on behalf of the Stash account, signalling decisions about nominating and validating. It set preferences like payout account and commission. If you are a validator, it also sets your [session keys](learn-keys#session-keys). It only needs enough funds to pay transaction fees. - -We designed this hierarchy of separate key types so that validator operators and nominators can protect themselves much better than in systems with only one key. As a rule, you lose security anytime you use one key for multiple roles, or even if you use keys related by derivation. You should never use any account key for a "hot" session key in particular. - -Controller and Stash account keys can be either sr25519 or ed25519. For more on how keys are used in Polkadot and the cryptography behind it [see here](learn-keys). - -## Validators and nominators - -Since validator slots will be limited, most of those who wish to stake their DOT and contribute economic security to the network will be nominators. Validators do most of the heavy lifting: they produce new block candidates in BABE, vote and come to consensus in GRANDPA, validate the state transition function of parachains, and possibly some other responsibilities regarding data availability and [XCMP](learn-crosschain). Nominators, on the other hand, do not need to do anything once they have bonded their DOT. The experience of the nominator is similar to "set it and forget it," while the validator will be doing active service for the network by performing the critical operations. For this reason, the validator has certain privileges regarding the payout of the staking mechanism and will be able to declare its own allocation before the share is divided to nominators. - -![staking](assets/NPoS/article-2.png) - -> Note: while the experience of a nominator is _similar_ to "set it and forget it", in reality there are many reasons to keep an eye on one's validators and keep optimizing the nominations for best returns and reduced risk. We talk more about this on the [How to Nominate](maintain-guides-how-to-nominate-polkadot) page. - -### Want to stake DOT? - -- [Nominator Guide](maintain-guides-how-to-nominate-polkadot) - Become a nominator on the Polkadot network. -- [Validator Guide](maintain-guides-how-to-validate-polkadot) - Become a validator on the Polkadot network. - -## Slashing - -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs modified software) in the network. They and their nominators will get slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the Treasury. The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the Council by simply paying out from the Treasury. This would be useful in situations such as a faulty runtime causing slashing or forcing validators offline through no fault of their own. In the case of legitimate slashing, it moves tokens away from malicious validators to those building the ecosystem through the normal Treasury process. - -Validator pools with larger total stake backing them will get slashed more harshly than less popular ones, so we encourage nominators to shift their nominations to less popular validators to reduce the possible losses. - -It is important to realize that slashing only occurs for active validations for a given nominator, and slashes are not mitigated by having other inactive or waiting nominations. They are also not mitigated by the validator operator running separate validators; each validator is considered its own entity for purposes of slashing, just as they are for staking rewards. - -As an example, assume BIG_COMPANY has 50 validators that all go offline at the same time, thus causing a 1% unresponsiveness slash to their nominators. In this example, the nominator has nominated five validators, two of which are with BIG_COMPANY (BC_1 and BC_2) and three are with other validators that do not belong to BIG_COMPANY (OV_1, OV_2, and OV_3). In this era, BC_1 is the active validator for this nominator, BC_2 and OV_1 are inactive, and OV_2 and OV_3 are waiting. The nominator will be slashed 1% of bonded stake, since BC_1 is the active validator. The inactive and waiting validators (BC_2 and OV_1 through 3) don't have any effect on this, since they are not actively validating. Any nominator actively nominating BC_2 also receives a 1% slash, but any nominator actively nominating OV_1 is unaffected. - -In rare instances, a nominator may be actively nominating several validators in a single era. In this case, the slash is proportionate to the amount staked to that specific validator. For instance, if another nominator had their stake split 50% to BC_1 and 50% to OV_1, they would receive a slash of 0.5% (50% of 1%). If a nominator were actively nominating BC_1 and BC_2, again with 50% of their stake allocated to each, they would still end up with a 1% slash, since a 1% slash is applied to both halves of their stake. Note that you cannot control the percentage of stake you have allocated to each validator or choose who your active validator will be (except in the trivial case of nominating a single validator). Staking allocations are controlled by the [Phragmén algorithm](learn-phragmen). - -Once a validator gets slashed, it goes into the state as an "unapplied slash". You can check this via [Polkadot-JS Apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/staking/slashes). The UI shows it per validator and then all the affected nominators along with the amounts. While unapplied, a governance proposal can be made to reverse it during this period (7 days on Kusama, 28 days on Polkadot). After the grace period, the slashes are applied. - -The following levels of offence are [defined](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html) (for specific slash amounts, see the equations in the section below): - -- Level 1: isolated unresponsiveness, i.e. being offline for an entire [epoch](glossary#epoch). No slashing, only [_chilling_](#chilling). -- Level 2: concurrent unresponsiveness or isolated equivocation. Slashes a very small amount of the stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses a serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. - -Let's look at these offences in a bit more detail. - -### Unresponsiveness - -For every session, validators will send an "I'm Online" heartbeat to indicate they are online. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Depending on the repeated offences and how many other validators were unresponsive or offline during the epoch, slashing may occur. - -Here is the formula for calculation: - - Let x = offenders, n = total no. validators - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -Note that if less than 10% of all validators are offline, no penalty is enacted. - -Validators should have a well-architected network infrastructure to ensure the node is running to reduce the risk of being slashed. A high availability setup is desirable, preferably with backup nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing and being slashed for equivocation - see below). -A comprehensive guide on validator setup is available [here](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator). - -### GRANDPA Equivocation - -A validator signs two or more votes in the same round on different chains. - -### BABE Equivocation - -A validator produces two or more blocks on the Relay Chain in the same time slot. - -GRANDPA and BABE equivocation slashing penalty is calculated as below: - - Let x = offenders, n = total no. validators - - Min( (3 * x / n )^2, 1) - -Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down. It should be noted that if they do not have good coordination to manage signing machines, then equivocation is possible. - -If a validator is reported for any one of the offences they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and gather support from nominators. - -If you want to know more details about slashing, please look at our [research page](https://research.web3.foundation/en/latest/polkadot/slashing/amounts.html). - -### Chilling - -Chilling is the act of removing a validator from the active validator set, also disqualifying them from the set of electable candidates in the next NPoS cycle. - -This may be voluntary and validator-initiated, e.g. if there is a planned outage in the validator's surroundings or hosting provider, and the validator wants to exit to protect themselves against slashing. When voluntary, chilling will keep the validator active in the current session, but will move them to the inactive set in the next. The validator will not lose their nominators. - -When used as part of a punishment, being chilled carries an implied penalty of being un-nominated. It also disables the validator for the remainder of the current era and removes the offending validator from the next election. - -Polkadot allows some validators to be disabled, but if the number of disabled validators gets too large, Polkadot will trigger a new validator election to get a full set. Disabled validators will need to resubmit their intention to validate and regarner support from nominators. - -For more on chilling, see the [How to Chill](maintain-guides-how-to-chill) page on this wiki. - -### Slashing Across Eras - -There are 3 main difficulties to account for with slashing in NPoS: - -- A nominator can nominate multiple validators and be slashed via any of them. -- Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N\*E coins to be slashed - you've only ever had N. -- Slashable offences can be found after the fact and out of order. - -To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the time span over which maximum slashes are computed are finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out. - -## Reward Distribution - -Note that Kusama runs approximately 4x as fast as Polkadot, except for block production times. Polkadot will also produce blocks at approximately six second intervals. - -Rewards are recorded per session (approximately one hour on Kusama and four hours on Polkadot) and calculated per era (approximately six hours on Kusama and twenty-four hours on Polkadot). Thus, rewards will be calculated four times per day on Kusama and once per day on Polkadot. - -Rewards are calculated based on era points, which have a probabilistic component. In other words, there may be slight differences in your rewards from era to era, and even amongst validators in the active set at the same time. These variations should cancel out over a long enough timeline. See the page on [Validator Payout Guide](maintain-guides-validator-payout) for more information on how these are calculated. - -In order to be paid your staking rewards, someone must claim them for each validator that you nominate. Staking rewards are kept available for 84 eras, which is approximately 84 days on Polkadot and 21 days on Kusama. For more information on why this is so, see the page on [simple payouts](learn-simple-payouts). - -> WARNING: If nobody claims your staking rewards by this time, then you will not be able to claim them and some of your staking rewards will be lost. - -### Claiming Rewards - -If you go to the Staking payouts page on [Polkadot-JS](https://polkadot.js.org/apps/#/staking/payout), you will see a list of all validators that you have nominated in the past 84 eras and for which you have not yet received a payout. Each one has the option to trigger the payout for all unclaimed eras. Note that this will pay everyone who was nominating that validator during those eras, and anyone can call it. Therefore, you may not see anything in this tab, yet still received a payout if somebody (generally, but not necessarily, another nominator or the validator operator) has triggered the payout for that validator for that era. - -If you wish to check if you received a payout, you will have to check via a block explorer. See [the relevant Support page](https://support.polkadot.network/support/solutions/articles/65000168954-how-can-i-see-my-staking-rewards-) for details. - -### Reward Distribution Example - -``` - PER_ERA * BLOCK_TIME = **Reward Distribution Time** - - 3600 * 6 seconds = 21,600 s = 6 hours - - ***These parameters can be changed by proposing a referendum*** -``` - -Validators can create a cut of the reward that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the value gets deducted, the remaining portion is based on their staked value and split between the validator and all of the nominators who have voted for this validator. - -For example, assume the block reward for a validator is 10 DOT. A validator may specify `validator_payment = 50%`, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that validators can put up their own stake, and for this calculation, their stake acts just as if they were another nominator. - -Rewards can be directed to the same account (controller), to the stash account (and either increasing the staked value or not increasing the staked value), or to a completely custom account. It is also possible to top-up / withdraw some bonded DOT without having to un-stake everything. - -For specific details about validator payouts, please see [this guide](maintain-guides-validator-payout). - -## Inflation - -DOT is inflationary; there is no maximum number of DOT as in Bitcoin. Inflation is designed to be 10% in the first year, with validator rewards being a function of amount staked and the remainder going to treasury. - -![staking](assets/NPoS/staking-participation-rate.png) - -

    Source: Research - Web3 Foundation

    - -- **x-axis**: Proportion of DOT staked -- **y-axis**: Inflation, annualized percentage -- **Blue line**: Inflation rewards to stakers -- **Green line**: Staker rate of return - -You can determine the inflation rewards by checking the current staking rate at [Polkadot-JS](https://polkadot.js.org/apps/#/staking/targets). The above chart shows the inflation model of the network. Depending on the staking participation, the distribution of the inflation to validators/nominators versus the treasury will change dynamically to provide incentives to participate (or not participate) in staking. For instance, all of the inflation would go to the validators/nominators if 50% of all KSM / DOT are staked, but any deviation from the 50% - positive or negative - sends the proportional remainder to the treasury and effectively reduces staking rewards. - -For those who are interested in knowing more about the design of inflation model for the network, please see [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#npos-payments-and-inflation). - -## Why stake? - -- 10% inflation/year when the network launches -- 50% targeted active staking -- ~20% annual return - -## Why not stake? - -- Tokens will be locked for about 28 days on Polkadot after unbonding, seven days on Kusama. -- Punishment in case of validator found to be misbehaving (see [#slashing](#slashing)). -- You want to use the tokens for a parachain slot. - -## How many validators does Polkadot have? - -Polkadot started with 20 open validator positions and has opened more gradually. The top bound on the number of validators has not been determined yet, but should only be limited by the bandwidth strain of the network due to peer-to-peer message passing. The estimate of the number of validators that Polkadot will have at maturity is around 1000. Kusama, Polkadot's canary network, currently has over 500 validator slots, and the plan is also to slowly grow this number to approximately 1000. - -## Resources - -- [How Nominated Proof of Stake will work in Polkadot](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43) - Blog post by Web3 Foundation researcher Alfonso Cevallos covering NPoS in Polkadot. -- [Secure validator setup](https://wiki.polkadot.network/docs/en/maintain-guides-secure-validator) diff --git a/website/translated_docs/zh-TW/learn-treasury.md b/website/translated_docs/zh-TW/learn-treasury.md deleted file mode 100644 index 581bdc9ea615..000000000000 --- a/website/translated_docs/zh-TW/learn-treasury.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: learn-treasury -title: Treasury -sidebar_label: Treasury -description: Details about Polkadot's on-chain treasury. ---- - -The Treasury is a pot of funds collected through transaction fees, slashing, [staking inefficiencies](learn-staking#inflation), etc. The funds held in the Treasury can be spent by making a spending proposal that, if approved by the [Council](learn-governance#Council), will enter a waiting period before distribution. This waiting period is known as the budget period, and its duration is subject to [governance](learn-governance), with the current default set to -{{ spend_period }} days. The Treasury attempts to spend as many proposals in the queue as it can without running out of funds. - -If the Treasury ends a budget period without spending all of its funds, it suffers a burn of a percentage of its funds -- thereby causing deflationary pressure. -{{ polkadot: This percentage is currently at 1% on Polkadot. :polkadot }} {{ kusama: This percentage is currently 0.2% on Kusama, with the amount currently going to [Society](https://guide.kusama.network/docs/en/maintain-guides-society-kusama) rather than being burned. :kusama }} - -When a stakeholder wishes to propose a spend from the Treasury, they must reserve a deposit totaling 5% of the proposed spend (see below for variations). This deposit will be slashed if the proposal is rejected, and returned if it is accepted. - -Proposals may consist of (but are not limited to): - -- Infrastructure deployment and continued operation. -- Network security operations (monitoring services, continuous auditing). -- Ecosystem provisions (collaborations with friendly chains). -- Marketing activities (advertising, paid features, collaborations). -- Community events and outreach (meetups, pizza parties, hackerspaces). -- Software development (wallets and wallet integration, clients and client upgrades). - -The Treasury is ultimately controlled by the [Council](learn-governance#Council), and how the funds will be spent is up to their judgment. - -## Funding the Treasury - -The Treasury is funded from different sources: - -1. Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator or a fisherman). The reward is taken from the slash amount and varies per offence and number of reporters. -2. Transaction fees: A portion of each block's transaction fees goes to the Treasury, with the remainder going to the block author. -3. Staking inefficiency: [Inflation](learn-staking#inflation) is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury. -4. Parathreads: [Parathreads](learn-parathreads) participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury. - -## Creating a Treasury Proposal - -The proposer has to deposit 5% of the requested amount or {{ proposal_min_bond }} (whichever is higher) as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to [governance](learn-governance) so they may change in the future. - -Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned. - -### Announcing the Proposal - -To minimize storage on chain, proposals don't contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms: - -- Many community members participate in discussion in the [Kusama Element (previously Riot)](https://riot.w3f.tech/#/room/#kusama:matrix.parity.io) chat. -- The [Polkassembly](https://kusama.polkassembly.io) discussion platform that allows users to log in with their KSM address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote. -- The {{ polkadot: [Polkadot forum](https://forum.polkadot.network) :polkadot }} -{{ kusama: [Kusama forum](https://forum.kusama.network) :kusama }} can be used for proposal explanations. -- [Commonwealth.im](https://commonwealth.im) is a community site that allows users to log in with their {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} address and automatically reads proposals from the chain, turning them into discussion threads. - -Spreading the word about the proposal's explanation is ultimately up to the proposer - the recommended way is using official Element channels like {{ polkadot: the [Polkadot Watercooler](https://app.element.io/#/room/#polkadot-watercooler:web3.foundation) and [Polkadot Direction room](https://app.element.io/#/room/#polkadot-direction:matrix.parity.io) :polkadot }} -{{ kusama: the [Kusama Direction room](https://app.element.io/#/room/#kusama:matrix.parity.io) or the [Kusama Watercooler](https://app.element.io/#/room/#kusamawatercooler:polkadot.builders) :kusama }}. - -### Creating the Proposal - -One way to create the proposal is to use the Polkadot-JS Apps [website](https://polkadot.js.org/apps). From the website, use either the [extrinsics tab](https://polkadot.js.org/apps/#/extrinsics) and select the Treasury pallet, then `proposeSpend` and enter the desired amount and recipient, or use the [Treasury tab](https://polkadot.js.org/apps/#/treasury) and its dedicated Submit Proposal button: - -![A proposal being created](assets/treasury/submit-new.png) - -The system will automatically take the required deposit, picking the higher of the two values mentioned [above](#creating-a-treasury-proposal). - -Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it. - -![Pending proposals](assets/treasury/proposals.png) - -Remember that the proposal has no metadata, so it's up to the proposer to create a description and purpose that the Council could study and base their votes on. - -At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented. - -The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council. - -![Motions in action](assets/treasury/motion.png) - -## Tipping - -Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value; the final value of the tip is decided based on the median of all tips issued by the tippers. - -Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts. - -A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that timeframe, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the `close_tip` extrinsic, and the tip will be paid out. - -There are two types of tips: public and tipper-initiated. With public tips, a small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently {{ tip_deposit_amount }}. Public tips carry a finder's fee of -{{ tip_finders_fee }}% which is paid out from the total amount. Tipper-initiated tips, i.e. tips that a Council member published, do not have a finder's fee or a bond. - -To better understand the process a tip goes through until it is paid out, let's consider an example. - -### Example - -Bob has done something great for {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }}. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve. - -Alice begins the process by issuing the `report_awesome` extrinsic. This extrinsic requires two arguments, a reason and the address to tip. Alice submits Bob's address with the reason being a UTF-8 encoded URL to a post on -{{ polkadot: [polkassembly](https://polkadot.polkassembly.io) :polkadot }} -{{ kusama: [polkassembly](https://kusama.polkassembly.io) :kusama }} that explains her reasoning for why Bob deserves the tip. - -As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain's parameter list plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly, it was cheaper for her to do so. - -For her trouble, Alice is able to claim the eventual finder's fee if the tip is approved by the tippers. - -Since the tipper group is the same as the Council on Kusama, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. - -Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Kusama. - -Charlie tips {{ polkadot: 10 DOT :polkadot }} {{ kusama: 1 KSM :kusama }}. Dave tips -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }}. Eve tips -{{ polkadot: 100 DOT :polkadot }} {{ kusama: 10 KSM :kusama }}. - -The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known. - -Now the actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out -{{ polkadot: 30 DOT :polkadot }} {{ kusama: 3 KSM :kusama }} from the Treasury. - -In order for Bob to be paid his tip, some account must call the `close_tip` extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone. - -## Bounties Spending - -There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics. - -Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem. - -A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward. - -When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty. - -In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator. - -After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise. - -To minimize storage on chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). [This template](https://docs.google.com/document/d/1-IBz_owspV5OcvezWXpksWDQReWowschD0TFuaVKKcU/edit?usp=sharing) can help as a checklist of all needed information for the Council to make an informed decision. - -The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism. - -### Creating a Bounty Proposal - -Anyone can create a Bounty proposal using Polkadot JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted. - -To submit a bounty, please visit [Polkadot JS Apps](https://polkadot.js.org/apps) and click on the governance tab in the options bar on the top of the site. After, click on 'Bounties' and find the button '+ Add Bounty' on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator's fee) and confirm the call. - -After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the -{{ polkadot: Polkadot Direction [channel](https://parity.link/polkadot-direction) :polkadot }} -{{ kusama: Kusama Direction [channel](https://parity.link/kusama-direction) :kusama }} in Element or joining our -{{ polkadot: Polkadot Discord [server](https://parity.link/polkadot-discord) :polkadot }} -{{ kusama: Kusama Discord [server](https://parity.link/kusama-discord) :kusama }} and publishing a short description of your bounty, with a link to one of the [forums](#announcing-the-proposal) for contextual information. - -A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active. - -### Closing a bounty - -The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee. - -A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then `Award_bounty`, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling `Claim_bounty` after the curator closed the allocation. - -To understand more about Bounties and how this new mechanism works, read this [Polkadot Blog post](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). - -## FAQ - -### What prevents the Treasury from being captured by a majority of the Council? - -The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself. - -For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn't have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter - as is the case currently on Kusama with a 0.2% burn. - -However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady. - -Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack - or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or - in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low. - -## Further Reading - -- [Substrate's Treasury Pallet](https://github.com/paritytech/substrate/blob/master/frame/treasury/src/lib.rs) - The Rust implementation of the Treasury. ([Docs](https://substrate.dev/rustdocs/latest/pallet_treasury/index.html)) diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-monitor-your-node.md b/website/translated_docs/zh-TW/maintain-guides-how-to-monitor-your-node.md deleted file mode 100644 index 3f6a43754305..000000000000 --- a/website/translated_docs/zh-TW/maintain-guides-how-to-monitor-your-node.md +++ /dev/null @@ -1,453 +0,0 @@ ---- -id: maintain-guides-how-to-monitor-your-node -title: Monitor your node -sidebar_label: Monitor your node ---- - -This guide will walk you through how to set up [Prometheus](https://prometheus.io/) with [Grafana](https://grafana.com/) to monitor your node using Ubuntu 18.04 or 20.04. - -A Substrate-based chain exposes data such as the height of the chain, the number of connected peers to your node, CPU, memory usage of your machine, and more. To monitor this data, Prometheus is used to collect metrics and Grafana allows for displaying them on the dashboard. - -## Preparation - -First, create a user for Prometheus by adding the `--no-create-home` flag to disallow `prometheus` from logging in. - -```bash -sudo useradd --no-create-home --shell /usr/sbin/nologin prometheus -``` - -Create the directories required to store the configuration and executable files. - -```bash -sudo mkdir /etc/prometheus -sudo mkdir /var/lib/prometheus -``` - -Change the ownership of these directories to `prometheus` so that only prometheus can access them. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus -sudo chown -R prometheus:prometheus /var/lib/prometheus -``` - -## Installing and Configuring Prometheus - -After setting up the environment, update your OS, and install the latest Prometheus. You can check the latest release by going to their GitHub repository under the [releases](https://github.com/prometheus/prometheus/releases/) page. - -```bash -sudo apt-get update && apt-get upgrade -wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz -tar xfz prometheus-*.tar.gz -cd prometheus-2.20.1.linux-amd64 -``` - -The following two binaries are in the directory: - -- prometheus - Prometheus main binary file -- promtool - -The following two directories (which contain the web interface, configuration files examples and the license) are in the directory: - -- consoles -- console_libraries - -Copy the executable files to the `/usr/local/bin/` directory. - -```bash -sudo cp ./prometheus /usr/local/bin/ -sudo cp ./promtool /usr/local/bin/ -``` - -Change the ownership of these files to the `prometheus` user. - -```bash -sudo chown prometheus:prometheus /usr/local/bin/prometheus -sudo chown prometheus:prometheus /usr/local/bin/promtool -``` - -Copy the `consoles` and `console_libraries` directories to `/etc/prometheus` - -```bash -sudo cp -r ./consoles /etc/prometheus -sudo cp -r ./console_libraries /etc/prometheus -``` - -Change the ownership of these directories to the `prometheus` user. - -```bash -sudo chown -R prometheus:prometheus /etc/prometheus/consoles -sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries -``` - -Once everything is done, run this command to remove `prometheus` directory. - -```bash -cd .. && rm -rf prometheus* -``` - -Before using Prometheus, it needs some configuration. Create a YAML configuration file named `prometheus.yml` by running the command below. - -```bash -sudo nano /etc/prometheus/prometheus.yml -``` - -The configuration file is divided into three parts which are `global`, `rule_files`, and `scrape_configs`. - -- `scrape_interval` defines how often Prometheus scrapes targets, while `evaluation_interval` controls how often the software will evaluate rules. - -- `rule_files` block contains information of the location of any rules we want the Prometheus server to load. - -- `scrape_configs` contains the information which resources Prometheus monitors. - -The configuration file should look like this below: - -```yaml -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - # - "first.rules" - # - "second.rules" - -scrape_configs: - - job_name: "prometheus" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9090"] - - job_name: "substrate_node" - scrape_interval: 5s - static_configs: - - targets: ["localhost:9615"] -``` - -With the above configuration file, the first exporter is the one that Prometheus exports to monitor itself. As we want to have more precise information about the state of the Prometheus server we reduced the `scrape_interval` to 5 seconds for this job. The parameters `static_configs` and `targets` determine where the exporters are running. The second exporter is capturing the data from your node, and the port by default is `9615`. - -You can check the validity of this configuration file by running `promtool check config /etc/prometheus/prometheus.yml`. - -Save the configuration file and change the ownership of the file to `prometheus` user. - -```bash -sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml -``` - -## Starting Prometheus - -To test that Prometheus is set up properly, execute the following command to start it as the `prometheus` user. - -```bash -sudo -u prometheus /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries -``` - -The following messages indicate the status of the server. If you see the following messages, your server is set up properly. - -```bash -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:308 msg="No time or size retention was set so using the default time retention" duration=15d -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:343 msg="Starting Prometheus" version="(version=2.20.1, branch=HEAD, revision=983ebb4a513302315a8117932ab832815f85e3d2)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:344 build_context="(go=go1.14.6, user=root@7cbd4d1c15e0, date=20200805-17:26:58)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:345 host_details="(Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 Ethereum-Archive-Node (none))" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:346 fd_limits="(soft=1024, hard=1048576)" -level=info ts=2020-08-12T21:39:05.453Z caller=main.go:347 vm_limits="(soft=unlimited, hard=unlimited)" -level=info ts=2020-08-12T21:39:05.455Z caller=web.go:524 component=web msg="Start listening for connections" address=0.0.0.0:9090 -level=info ts=2020-08-12T21:39:05.455Z caller=main.go:684 msg="Starting TSDB ..." -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:641 component=tsdb msg="Replaying on-disk memory mappable chunks if any" -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:655 component=tsdb msg="On-disk memory mappable chunks replay completed" duration=2.846µs -level=info ts=2020-08-12T21:39:05.459Z caller=head.go:661 component=tsdb msg="Replaying WAL, this may take a while" -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:713 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0 -level=info ts=2020-08-12T21:39:05.464Z caller=head.go:716 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=26.822µs wal_replay_duration=4.649295ms total_replay_duration=4.737874ms -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:700 fs_type=EXT4_SUPER_MAGIC -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:701 msg="TSDB started" -level=info ts=2020-08-12T21:39:05.466Z caller=main.go:805 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:833 msg="Completed loading of configuration file" filename=/etc/prometheus/prometheus.yml -level=info ts=2020-08-12T21:39:05.467Z caller=main.go:652 msg="Server is ready to receive web requests." -``` - -Go to `http://SERVER_IP_ADDRESS:9090/graph` to check whether you are able to access the Prometheus interface or not. If it is working, exit the process by pressing on `CTRL + C`. - -Next, we would like to automatically start the server during the boot process, so we have to create a new `systemd` configuration file with the following config. - -```bash -sudo nano /etc/systemd/system/prometheus.service -``` - -```bash -[Unit] - Description=Prometheus Monitoring - Wants=network-online.target - After=network-online.target - -[Service] - User=prometheus - Group=prometheus - Type=simple - ExecStart=/usr/local/bin/prometheus \ - --config.file /etc/prometheus/prometheus.yml \ - --storage.tsdb.path /var/lib/prometheus/ \ - --web.console.templates=/etc/prometheus/consoles \ - --web.console.libraries=/etc/prometheus/console_libraries - ExecReload=/bin/kill -HUP $MAINPID - -[Install] - WantedBy=multi-user.target -``` - -Once the file is saved, execute the command below to reload `systemd` and enable the service so that it will be loaded automatically during the operating system's startup. - -```bash -sudo systemctl daemon-reload && systemctl enable prometheus && systemctl start prometheus -``` - -Prometheus should be running now, and you should be able to access its front again end by re-visiting `IP_ADDRESS:9090/`. - -## Installing Grafana - -In order to visualize your node metrics, you can use Grafana to query the Prometheus server. Run the following commands to install it first. - -```bash -sudo apt-get install -y adduser libfontconfig1 -wget https://dl.grafana.com/oss/release/grafana_7.1.3_amd64.deb -sudo dpkg -i grafana_7.1.3_amd64.deb -``` - -If everything is fine, start the Grafana server and access it by going to the `http://SERVER_IP_ADDRESS:3000/login`. The default user and password is admin/admin. - -Now configure Grafana to auto-start on boot. - -> Note: If you want to change the port on which Grafana runs (3000 is a popular port), edit the file `/usr/share/grafana/conf/defaults.ini` with a command like `sudo vim /usr/share/grafana/conf/defaults.ini` and change the `http_port` value to something else. Then restart grafana with `sudo systemctl restart grafana-server`. - -```bash -sudo systemctl daemon-reload && sudo systemctl enable grafana-server && sudo systemctl start grafana-server -``` - -![grafana-1](assets/guides/how-to-monitor/1-grafana-login.png) - -In order to visualize the node metrics, click _settings_ to configure the `Data Sources` first. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source.png) - -Click `Add data source` to choose where the data is coming from. - -![grafana-1](assets/guides/how-to-monitor/2-add-data-source-2.png) - -Select `Prometheus`. - -![grafana-1](assets/guides/how-to-monitor/3-select-prometheus.png) - -The only thing you need to input is the `URL` that is `https://localhost:9090` and then click `Save & Test`. If you see `Data source is working`, your connection is configured correctly. - -![grafana-1](assets/guides/how-to-monitor/4-configure-data-source.png) - -Next, import the dashboard that lets you visualize your node data. Go to the menu bar on the left and mouse hover "+" then select `Import`. - -`Import via grafana.com` - It allows you to use a dashboard that someone else has created and made public. You can check what other dashboards are available via [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards). In this guide, we use ["My Polkadot Metrics"](https://grafana.com/grafana/dashboards/12425), so input "12425" under the id field and click `Load`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard.png) - -Once it has been loaded, make sure to select "Prometheus" in the Prometheus dropdown list. Then click `Import`. - -![grafana-1](assets/guides/how-to-monitor/5-import-dashboard-2.png) - -In the meantime, start your Polkadot node by running `./polkadot`. If everything is done correctly, you should be able to monitor your node's performance such as the current block height, CPU, memory usage, etc. on the Grafana dashboard. - -![grafana-1](assets/guides/how-to-monitor/6-dashboard-metric.png) - -## Installing and Configuring Alertmanager (Optional) - -In this section, let's configure the Alertmanager that helps to predict the potential problem or notify you of the current problem in your server. Alerts can be sent in Slack, Email, Matrix, or others. In this guide, we will show you how to configure the email notifications using Gmail if your node goes down. - -First, download the latest binary of AlertManager and unzip it by running the command below: - -``` -wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz) -tar -xvzf alertmanager-0.21.0.linux-amd64.tar.gz -mv alertmanager-0.21.0.linux-amd64.tar.gz/alertmanager /usr/local/bin/ -``` - -### Gmail Setup - -To allow AlertManager to send an email to you, you will need to generate something called an `app password` in your Gmail account. For details, click [here](https://support.google.com/accounts/answer/185833?hl=en) to follow the whole setup. - -You should see something like below: - -![grafana-am-1](assets/guides/how-to-monitor/1-alert-manager.png) - -Copy and save it somewhere else first. - -### AlertManager Configuration - -There is a configuration file named `alertmanager.yml` inside the directory that you just extracted in the previous command, but that is not of our use. We will create our `alertmanager.yml` file under `/etc/alertmanager` with the following config. - -> Ensure to change the ownership of "/etc/alertmanager" to `prometheus` by executing -> -> sudo chown -R prometheus:prometheus /etc/alertmanager - -``` -global: - resolve_timeout: 1m - -route: - receiver: 'gmail-notifications' - -receivers: -- name: 'gmail-notifications' - email_configs: - - to: YOUR_EMAIL - from: YOUR_EMAIL - smarthost: smtp.gmail.com:587 - auth_username: YOUR_EMAIL - auth_identity: YOUR_EMAIL - auth_password: YOUR_APP_PASSWORD - send_resolved: true -``` - -With the above configuration, alerts will be sent using the the email you set above. Remember to change `YOUR_EMAIL` to your email and paste the app password you just saved earlier to the `YOUR_APP_PASSWORD`. - -Next, create another `systemd` configuration file named `alertmanager.service` by running the command `sudo nano /etc/systemd/system/alertmanager.service` with the following config. - -> SERVER_IP - Change to your host IP address amd make sure port 9093 is opened - -``` -[Unit] -Description=AlertManager Server Service -Wants=network-online.target -After=network-online.target - -[Service] -User=root -Group=root -Type=simple -ExecStart=/usr/local/bin/alertmanager --config.file /etc/alertmanager/alertmanager.yml --web.external-url=http://SERVER_IP:9093 --cluster.advertise-address='0.0.0.0:9093' - - -[Install] -WantedBy=multi-user.target -``` - -To the start the Alertmanager, run the following commands: - -``` -sudo systemctl daemon-reload && systemctl start alertmanager && systemctl enable alertmanager && systemctl status alertmanager -``` - -``` -● alertmanager.service - AlertManager Server Service - Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2020-08-20 22:01:21 CEST; 3 days ago - Main PID: 20592 (alertmanager) - Tasks: 70 (limit: 9830) - CGroup: /system.slice/alertmanager.service -``` - -You should see the process status is "active (running)" if you have configured properly. - -There is a Alertmanager plugin in Grafana that can help you to monitor the alert information. To install it, execute the command below: - -``` -sudo grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource -``` - -And restart Grafana once the plugin is successfully installed. - -``` -sudo service grafana-server restart -``` - -Now go to your Grafana dashboard `SERVER_IP:3000` and configure the Alertmanager datasource. - -![grafana-am-5](assets/guides/how-to-monitor/5-alert-manager.png) - -Go to Configuration -> Data Sources, search "Prometheus AlertManger" if you cannot find it at the top. - -![grafana-am-2](assets/guides/how-to-monitor/2-alert-manager.png) - -Fill in the `URL` to your server location followed by the port number used in the Alertmanager. - -Then click "Save & Test" at the bottom to test the connection. - -![grafana-am-3](assets/guides/how-to-monitor/3-alert-manager.png) - -To monitor the alerts, let's import dashboard "[8010](https://grafana.com/dashboards/8010)" that is used for Alertmanager. And make sure to select the "Prometheus AlertManager" in the last column. Then click "Import". - -You will end up having the follwing: - -![grafana-am-4](assets/guides/how-to-monitor/4-alert-manager.png) - -### AlertManager Integration - -To let the Prometheus server be able to talk to the Alertmanger, we will need to add the following config in the `etc/prometheus/prometheus.yml`. - -``` -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 -``` - -That is the updated `etc/prometheus/prometheus.yml`. - -``` -global: - scrape_interval: 15s - evaluation_interval: 15s - -rule_files: - - 'rules.yml' - -alerting: - alertmanagers: - - static_configs: - - targets: - - localhost:9093 - -scrape_configs: - - job_name: 'prometheus' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9090'] - - job_name: 'substrate_node' - scrape_interval: 5s - static_configs: - - targets: ['localhost:9615'] -``` - -We will need to create a new file called "rules.yml" under `/etc/prometheus/` that is defined all the rules we would like to detect. If any of the rules defined in this file is fulfilled, an alert will be triggered. The rule below checks whether the instance is down. If it is down for more than 5 minutes, an email notification will be sent. If you would like to learn more about the details of the rule defining, go [here](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). There are other interesting alerts you may find useful [here](https://awesome-prometheus-alerts.grep.to/rules.html). - -``` -groups: - - name: alert_rules - rules: - - alert: InstanceDown - expr: up == 0 - for: 5m - labels: - severity: critical - annotations: - summary: "Instance [{{ $labels.instance }}] down" - description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute." -``` - -Change the ownership of this file to `prometheus` instead of `root` by running: - -``` -sudo chown prometheus:prometheus rules.yml -``` - -To check the rules defined in the "rules.yml" is syntactically correct, run the following command: - -``` -promtool check rules rules.yml -``` - -Finally, restart everthing by running: - -``` -sudo systemctl stop prometheus && systemctl start prometheus && systemctl stop alertmanager && systemctl start alertmanager -``` - -Now if one of your target instances down, you will receive an alert on the AlertManager and Gmail like below. - -![grafana-am-6](assets/guides/how-to-monitor/6-alert-manager.png) diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-nominate-alexander.md b/website/translated_docs/zh-TW/maintain-guides-how-to-nominate-alexander.md deleted file mode 100644 index 8492c29aedc5..000000000000 --- a/website/translated_docs/zh-TW/maintain-guides-how-to-nominate-alexander.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: maintain-guides-how-to-nominate-alexander -title: Be a Nominator (Alexander) -sidebar_label: Be a Nominator (Alexander) ---- - -**The Alexander testnet (PoC-4) has been deprecated.** - -If you are interested in nominating, please see our page on [how to nominate on Kusama](maintain-guides-how-to-nominate-kusama). - - - diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-validate-kusama.md b/website/translated_docs/zh-TW/maintain-guides-how-to-validate-kusama.md deleted file mode 100644 index 50caa2526e7f..000000000000 --- a/website/translated_docs/zh-TW/maintain-guides-how-to-validate-kusama.md +++ /dev/null @@ -1,265 +0,0 @@ ---- -id: maintain-guides-how-to-validate-kusama -title: Run a Validator (Kusama) -sidebar_label: How to run a Validator on Kusama ---- - -This guide will instruct you how to set up a validator node on the Kusama network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself. As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Kusama validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders) on Riot. The team and other validators are there to help answer questions and provide experience. - -### How Many KSM Do I Need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-are-the-ways-to-find-out-the-minimum-stake-necessary-for-the-validators). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough KSM to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any KSM that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of KSM tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your KSM to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -You will likely run your validator on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -You will not need a very powerful machine to run your validator, but you should be aware of the resource constraints. The most important resource for your validator node is networking bandwidth, followed by its storage and memory capabilities. The bare minimum requirements for a machine to run a validator are as follows: - -- **Storage:** 160GB - 200GB. Kusama doesn't have very heavy storage requirements yet so something in this range will be fine, just keep in mind you may have to upgrade it later if the chain state becomes very big. -- **Memory:** 2GB - 8GB. 2GB is really the minimum memory you should operate your validator with, anything less than this make build times too inconvenient. For better performance you can bump it up to 4GB or 8GB, but anything more than that is probably over-kill. In order to compile the binary yourself you will likely need ~8GB. -- **CPU:** 1 - 2. One CPU is okay, but 2 is better. Again, this is a performance preference. - -On most cloud service providers, these specs are usually within the $10 - $20 per month range. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Kusama node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. At the time of writing, this was **0.8.26-1**, but you should review the output from the "git tag" command to see a list of all the potential 0.8 releases. You should replace `VERSION` with the latest build (i.e., the highest number). You can also find the latest Kusama version on the [release](https://github.com/paritytech/polkadot/releases) tab. - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> `sh - rustup install nightly-2020-05-15 - rustup override set nightly-2020-05-15 - rustup target add wasm32-unknown-unknown --toolchain nightly-2020-05-15` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, but note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive --chain kusama -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. In the future, it is recommended to switch to using the faster and more efficient ParityDb option. Switching between database backends will require a resync. -> -> If you want to test out ParityDB you can add the flag `--database paritydb`. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Kusama) or the [Polkadot-JS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond KSM - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your KSM balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the KSM of the Stash account. These KSM will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "New stake" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliKSM - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of KSM in order to start and stop validating. -- **Value bonded** - How much KSM from the Stash account you want to bond/stake. Note that you do not need to bond all of the KSM in that account. Also note that you can always bond _more_ KSM later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](https://wiki.polkadot.network/en/latest/polkadot/learn-staking/#reward-distribution). Starting with runtime version v2023 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/api/substrate/rpc.html#haskey-publickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/api/substrate/rpc.html#hassessionkeys-sessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node in validator mode with a flag allowing unsafe RPC calls, needed for some advanced operations. - -```sh -./target/release/polkadot --validator --name "name on telemetry" --chain kusama -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: Polkadot-JS Apps - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the Polkadot-JS Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#/Kusama) and find your node. Note that this will show all nodes on the Kusama network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot-JS UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - Rewards you will keep, the rest will be shared among you and your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows how many validator slots are available as well as how many nodes have signaled their intention to be a validator. You can also go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of KSM staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Kusama validator! If you need help, reach out on the [Kusama forum](https://forum.kusama.network/) or in the [Kusama Validator chat](https://riot.im/app/#/room/#KusamaValidatorLounge:polkadot.builders). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" --chain kusama -``` diff --git a/website/translated_docs/zh-TW/maintain-guides-how-to-validate-polkadot.md b/website/translated_docs/zh-TW/maintain-guides-how-to-validate-polkadot.md deleted file mode 100644 index e54ae939b2b4..000000000000 --- a/website/translated_docs/zh-TW/maintain-guides-how-to-validate-polkadot.md +++ /dev/null @@ -1,276 +0,0 @@ ---- -id: maintain-guides-how-to-validate-polkadot -title: Run a Validator (Polkadot) -sidebar_label: How to run a Validator on Polkadot ---- - -> The following information applies to the Polkadot network. If you want to set up a validator on Kusama, check out the [Kusama guide](https://guide.kusama.network/docs/en/mirror-maintain-guides-how-to-validate-kusama) instead. - -This guide will instruct you how to set up a validator node on the Polkadot network. - -## Preliminaries - -Running a validator on a live network is a lot of responsibility! You will be accountable for not only your own stake, but also the stake of your current nominators. If you make a mistake and get slashed, your money and your reputation will be at risk. However, running a validator can also be very rewarding, knowing that you contribute to the security of a decentralized network while growing your stash. - -Since security is so important to running a successful validator, you should take a look at the [secure validator](maintain-guides-secure-validator) information to make you understand the factors to consider when constructing your infrastructure. The Web3 Foundation also maintains a [reference implementation for a secure validator set-up](https://github.com/w3f/polkadot-secure-validator) that you can use by deploying yourself (video walkthrough is available [here](https://www.youtube.com/watch?v=tTn8P6t7JYc)). As you progress in your journey as a validator, you will likely want to use this repository as a _starting point_ for your own modifications and customizations. - -If you need help, please reach out on the [Polkadot Validator Lounge](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation) on Riot. The team and other validators are there to help answer questions and provide tips from experience. - -### How many DOT do I need? - -You can have a rough estimate on that by using the methods listed [here](faq#what-is-the-minimum-stake-necessary-to-be-elected-as-an-active-validator). Validators are elected based on [Phragmén's algorithm](learn-phragmen). To be elected into the set, you need a minimum stake behind your validator. This stake can come from yourself or from [nominators](learn-nominator). This means that as a minimum, you will need enough DOT to set up Stash and Controller [accounts](learn-keys) with the existential deposit, plus a little extra for transaction fees. The rest can come from nominators. - -**Warning:** Any DOT that you stake for your validator is liable to be slashed, meaning that an insecure or improper setup may result in loss of DOT tokens! If you are not confident in your ability to run a validator node, it is recommended to nominate your DOT to a trusted validator node instead. - -## Initial Set-up - -### Requirements - -The most common way for a beginner to run a validator is on a cloud server running Linux. You may choose whatever [VPS](#vps-list) provider that your prefer, and whatever operating system you are comfortable with. For this guide we will be using **Ubuntu 18.04**, but the instructions should be similar for other platforms. - -The transactions weights in Polkadot were benchmarked on standard hardware. It is recommended that validators run at least the standard hardware in order to ensure they are able to process all blocks in time. The following are not _minimum requirements_ but if you decide to run with less than this beware that you might have performance issue. - -#### Standard Hardware - -For the full details of the standard hardware please see [here](https://github.com/paritytech/substrate/pull/5848). - -- **CPU** - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz -- **Storage** - A NVMe solid state drive. Should be reasonably sized to deal with blockchain growth. Starting around 80GB - 160GB will be okay for the first six months of Polkadot, but will need to be re-evaluated every six months. -- **Memory** - 64GB. - -The specs posted above are by no means the minimum specs that you could use when running a validator, however you should be aware that if you are using less you may need to toggle some extra optimizations in order to be equal to other validators that are running the standard. - -### Install Rust - -Once you choose your cloud service provider and set-up your new server, the first thing you will do is install Rust. - -If you have never installed Rust, you should do this first. This command will fetch the latest version of Rust and install it. - -```sh -curl https://sh.rustup.rs -sSf | sh -``` - -Otherwise, if you have already installed Rust, run the following command to make sure you are using the latest version. - -```sh -rustup update -``` - -Finally, run this command to install the necessary dependencies for compiling and running the Polkadot node software. - -```sh -sudo apt install make clang pkg-config libssl-dev build-essential -``` - -Note - if you are using OSX and you have [Homebrew](https://brew.sh) installed, you can issue the following equivalent command INSTEAD of the previous one: - -```sh -brew install cmake pkg-config openssl git llvm -``` - -### Install & Configure Network Time Protocol (NTP) Client - -[NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) is a networking protocol designed to synchronize the clocks of computers over a network. NTP allows you to synchronize the clocks of all the systems within the network. Currently it is required that validators' local clocks stay reasonably in sync, so you should be running NTP or a similar service. You can check whether you have the NTP client by running: - -_If you are using Ubuntu 18.04 / 19.04, NTP Client should be installed by default._ - -```sh -timedatectl -``` - -If NTP is installed and running, you should see `System clock synchronized: yes` (or a similar message). If you do not see it, you can install it by executing: - -```sh -sudo apt-get install ntp -``` - -ntpd will be started automatically after install. You can query ntpd for status information to verify that everything is working: - -```sh -sudo ntpq -p -``` - -> _WARNING_: Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks making it on chain. - -### Building and Installing the `polkadot` Binary - -You will need to build the `polkadot` binary from the [paritytech/polkadot](https://github.com/paritytech/polkadot) repository on GitHub using the source code available in the **v0.8** branch. - -You should generally use the latest **0.8.x** tag. You should either review the output from the "git tag" command or visit the [Releases](https://github.com/paritytech/polkadot/releases) to see a list of all the potential 0.8 releases. You should replace `VERSION` below with the latest build (i.e., the highest number). - -> Note: If you prefer to use SSH rather than HTTPS, you can replace the first line of the below with `git clone git@github.com:paritytech/polkadot.git`. - -```sh -git clone https://github.com/paritytech/polkadot.git -cd polkadot -git tag -l | sort -V | grep -v -- '-rc' -echo Get the latest version and replace VERSION (below) with it. -git checkout VERSION -./scripts/init.sh -cargo build --release -``` - -This step will take a while (generally 10 - 40 minutes, depending on your hardware). - -> Note if you run into compile errors, you may have to switch to a less recent nightly. This can be done by running: -> -> ```sh -rustup install nightly-2020-10-06 -rustup target add wasm32-unknown-unknown --toolchain nightly-2020-10-06 -cargo +nightly-2020-10-06 build --release -``` - -If you are interested in generating keys locally, you can also install `subkey` from the same directory. You may then take the generated `subkey` executable and transfer it to an air-gapped machine for extra security. - -```sh -cargo install --force --git https://github.com/paritytech/substrate subkey -``` - -### Synchronize Chain Data - -> **Note:** By default, Validator nodes are in archive mode. If you've already synced the chain not in archive mode, you must first remove the database with `polkadot purge-chain` and then ensure that you run Polkadot with the `--pruning=archive` option. -> -> You may run a validator node in non-archive mode by adding the following flags: `--unsafe-pruning --pruning `, a reasonable value being 1000. Note that an archive node and non-archive node's databases are not compatible with each other, and to switch you will need to purge the chain data. - -You can begin syncing your node by running the following command: - -```sh -./target/release/polkadot --pruning=archive -``` - -if you do not want to start in validator mode right away. - -The `--pruning=archive` flag is implied by the `--validator` and `--sentry` flags, so it is only required explicitly if you start your node without one of these two options. If you do not set your pruning to archive node, even when not running in validator and sentry mode, you will need to re-sync your database when you switch. - -> **Note:** Validators should sync using the RocksDb backend. This is implicit by default, but can be explicit by passing the `--database RocksDb` flag. -> -> In the future, it is recommended to switch to the faster and more efficient ParityDB option. Note that **ParityDB is still experimental and should not be used in production.** If you want to test out ParityDB, you can add the flag `--database paritydb`. Switching between database backends will require a resync. - -Depending on the size of the chain when you do this, this step may take anywhere from a few minutes to a few hours. - -If you are interested in determining how much longer you have to go, your server logs (printed to STDOUT from the `polkadot` process) will tell you the latest block your node has processed and verified. You can then compare that to the current highest block via [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) or the [PolkadotJS Block Explorer](https://polkadot.js.org/apps/#/explorer). - -## Bond DOT - -It is highly recommended that you make your controller and stash accounts be two separate accounts. For this, you will create two accounts and make sure each of them have at least enough funds to pay the fees for making transactions. Keep most of your funds in the stash account since it is meant to be the custodian of your staking funds. - -Make sure not to bond all your DOT balance since you will be unable to pay transaction fees from your bonded balance. - -It is now time to set up our validator. We will do the following: - -- Bond the DOT of the Stash account. These DOT will be put at stake for the security of the network and can be slashed. -- Select the Controller. This is the account that will decide when to start or stop validating. - -First, go to the [Staking](https://polkadot.js.org/apps/#/staking/actions) section. Click on "Account Actions", and then the "+ Stash" button. - -![dashboard bonding](assets/guides/how-to-validate/polkadot-dashboard-bonding.jpg) - -- **Stash account** - Select your Stash account. In this example, we will bond 100 milliDOT - make sure that your Stash account contains _at least_ this much. You can, of course, stake more than this. -- **Controller account** - Select the Controller account created earlier. This account will also need a small amount of DOT in order to start and stop validating. -- **Value bonded** - How much DOT from the Stash account you want to bond/stake. Note that you do not need to bond all of the DOT in that account. Also note that you can always bond _more_ DOT later. However, _withdrawing_ any bonded amount requires the duration of the unbonding period. On Kusama, the unbonding period is 7 days. On Polkadot, the planned unbonding period is 28 days. -- **Payment destination** - The account where the rewards from validating are sent. More info [here](learn-staking/#reward-distribution). Starting with runtime version v23 natively included in client version [0.8.23](https://github.com/paritytech/polkadot/releases/tag/v0.8.23), payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that it is extremely unsafe to set an exchange address as the recipient of the staking rewards. - -Once everything is filled in properly, click `Bond` and sign the transaction with your Stash account. - -After a few seconds, you should see an "ExtrinsicSuccess" message. You should now see a new card with all your accounts (note: you may need to refresh the screen). The bonded amount on the right corresponds to the funds bonded by the Stash account. - -## Set Session Keys - -> **Note:** The session keys are consensus critical, so if you are not sure if your node has the current session keys that you made the `setKeys` transaction then you can use one of the two available RPC methods to query your node: [hasKey](https://polkadot.js.org/docs/substrate/rpc/#haskeypublickey-bytes-keytype-text-bool) to check for a specific key or [hasSessionKeys](https://polkadot.js.org/docs/substrate/rpc/#hassessionkeyssessionkeys-bytes-bool) to check the full session key public key string. - -Once your node is fully synced, stop the process by pressing Ctrl-C. At your terminal prompt, you will now start running the node. - -```sh -./target/release/polkadot --validator --name "name on telemetry" -``` - -You can give your validator any name that you like, but note that others will be able to see it, and it will be included in the list of all servers using the same telemetry server. Since numerous people are using telemetry, it is recommended that you choose something likely to be unique. - -### Generating the Session Keys - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator node with your Controller account on Polkadot. - -#### Option 1: PolkadotJS-APPS - -You can generate your [Session keys](https://wiki.polkadot.network/en/latest/polkadot/learn/keys/#session-key) in the client via the apps RPC. If you are doing this, make sure that you have the PolkadotJS-Apps explorer attached to your validator node. You can configure the apps dashboard to connect to the endpoint of your validator in the Settings tab. If you are connected to a default endpoint hosted by Parity of Web3 Foundation, you will not be able to use this method since making RPC requests to this node would effect the local keystore hosted on a _public node_ and you want to make sure you are interacting with the keystore for _your node_. - -Once ensuring that you have connected to your node, the easiest way to set session keys for your node is by calling the `author_rotateKeys` RPC request to create new keys in your validator's keystore. Navigate to Toolbox tab and select RPC Calls then select the author > rotateKeys() option and remember to save the output that you get back for a later step. - -![Explorer RPC call](assets/guides/how-to-validate/polkadot-explorer-rotatekeys-rpc.jpg) - -#### Option 2: CLI - -If you are on a remote server, it is easier to run this command on the same machine (while the node is running with the default HTTP RPC port configured): - -```sh -curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 -``` - -The output will have a hex-encoded "result" field. The result is the concatenation of the four public keys. Save this result for a later step. - -You can restart your node at this point. - -### Submitting the `setKeys` Transaction - -You need to tell the chain your Session keys by signing and submitting an extrinsic. This is what associates your validator with your Controller account. - -Go to [Staking > Account Actions](https://polkadot.js.org/apps/#/staking/actions), and click "Set Session Key" on the bonding account you generated earlier. Enter the output from `author_rotateKeys` in the field and click "Set Session Key". - -![staking-change-session](assets/guides/how-to-validate/set-session-key-1.jpg) ![staking-session-result](assets/guides/how-to-validate/set-session-key-2.jpg) - -Submit this extrinsic and you are now ready to start validating. - -## Validate - -To verify that your node is live and synchronized, head to [Telemetry](https://telemetry.polkadot.io/#list/Polkadot%20CC1) and find your node. Note that this will show all nodes on the Polkadot network, which is why it is important to select a unique name! - -If everything looks good, go ahead and click on "Validate" in Polkadot UI. - -![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate.jpg) ![dashboard validate](assets/guides/how-to-validate/polkadot-dashboard-validate-modal.jpg) - -- **Payment preferences** - You can specify the percentage of the rewards that will get paid to you. The remaining will be split among your nominators. - -Click "Validate". - -If you go to the "Staking" tab, you will see a list of active validators currently running on the network. At the top of the page, it shows the number of validator slots that are available as well as the number of nodes that have signaled their intention to be a validator. You can go to the "Waiting" tab to double check to see whether your node is listed there. - -![staking queue](assets/guides/how-to-validate/polkadot-dashboard-staking.jpg) - -The validator set is refreshed every era. In the next era, if there is a slot available and your node is selected to join the validator set, your node will become an active validator. Until then, it will remain in the _waiting_ queue. If your validator is not selected to become part of the validator set, it will remain in the _waiting_ queue until it is. There is no need to re-start if you are not selected for the validator set in a particular era. However, it may be necessary to increase the number of DOT staked or seek out nominators for your validator in order to join the validator set. - -**Congratulations!** If you have followed all of these steps, and been selected to be a part of the validator set, you are now running a Polkadot validator! If you need help, reach out on the [Polkadot Validator chat](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=web3.foundation). - -## Thousand Validators Programme - -The Thousand Validators Programme is a joint initiative by Web3 Foundation and Parity Technologies to provide support for community validators. If you are interested in applying for the programme, you can find more information [on the wiki page](thousand-validators.md). - -## FAQ - -### Why am I unable to synchronize the chain with 0 peers? - -![zero-peer](assets/guides/how-to-validate/polkadot-zero-peer.jpg) - -Make sure to enable `30333` libp2p port. Eventually, it will take a little bit of time to discover other peers over the network. - -### How do I clear all my chain data? - -```sh -./target/release/polkadot purge-chain -``` - -## VPS List - -- [OVH](https://www.ovh.com.au/) -- [Digital Ocean](https://www.digitalocean.com/) -- [Vultr](https://www.vultr.com/) -- [Linode](https://www.linode.com/) -- [Contabo](https://contabo.com/) -- [Scaleway](https://www.scaleway.com/) - -## Using Docker - -If you have Docker installed, you can use it to start your validator node without needing to build the binary. You can do this with a simple one line command: - -```sh -$ docker run parity/polkadot:latest --validator --name "name on telemetry" -``` diff --git a/website/translated_docs/zh-TW/maintain-guides-society-kusama.md b/website/translated_docs/zh-TW/maintain-guides-society-kusama.md deleted file mode 100644 index 4d8ab28a2421..000000000000 --- a/website/translated_docs/zh-TW/maintain-guides-society-kusama.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -id: maintain-guides-society-kusama -title: Join Kappa Sigma Mu -sidebar_label: Join Kappa Sigma Mu ---- - -Kappa Sigma Mu is a membership club using the Substrate [Society](https://substrate.dev/rustdocs/latest/pallet_society/index.html) pallet. It is an economic game to incentivize users to join a society that coordinates around whatever the rules are decided to be. The members of the society are incentivized to participate in the society via the rewards paid by the treasury. Currently, there is only one society on Kusama but it is possible to have multiple societies in the future through a runtime upgrade. - -![Society Dashboard](assets/kusama/kusama_society_page.png) ![Society Dashboard](assets/kusama/kusama_society_page2.png) - -Before joining the society, let's take a brief look at the [Society UI](https://polkadot.js.org/apps/#/society) on Polkadot-JS apps and read through all the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) to become a member. - -## UI Overview - -- `Members`: The number of members in the society. Currently, the maximum number of members is set to `150`. It can be changed by using governance to increase the number. -- `Rotation`: The time period for membership rotations. -- `Challenge`: The time period to randomly select one of the members to defend his membership in the society. -- `Pot`: Resource balance that is used to support members of the society. -- `Bids`: A list of users who submitted a bid to join the society. - -## User Types - -Below are the various types of users at different stages. - -- `Bidder` - A token holder who intends to join the society by placing a bid. -- `Candidate` - The selected bidders that will be voted on by members of the society. -- `Suspended Candidate` - The candidates that failed to join the society. -- `Member` - Member of the society. -- `Suspender Member` - A member of the society who has accumulated too many strikes or failed their membership challenge. -- `Head` - One winning candidate will be randomly chosen as head of the members, weighted by the number of approvals the winning candidates accumulated. -- `Defender` - In every challenge period, one of the members will be randomly selected to defend their membership in the society. The rules for defending the membership are documented [in the rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17). - -## Procedure - Remember to take a look at the [rules](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) first. And since those rules are not enforced entirely on-chain, it is recommended to join the [Kappa Sigma Mu Lounge](https://app.element.io/#/room/!BUmiAAnAYSRGarqwOt:matrix.parity.io) to ask any questions if anything is unclear. - -### 1. Bid Phase - -To submit a bid, click the Submit Bid button on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society). - -Anyone can submit a bid to join the society by reserving a deposit or finding an existing member to create a bid on their behalf by vouching for them. At every rotation period, as many bids as the society pot can support will be selected. The selected bids will be moved to the candidate phase, whereas bids that were not selected will stay in the bidder pool until they are selected or a user chooses to unbid. - -Anyone who wants to join the society is required to deposit 1.6 KSM for reserve on Kusama and declare the bid amount (1 KSM in this case) that they will receive for joining the society. - -![Society Dashboard](assets/society/test_bid.jpg) - -Once you have submitted the transaction, your bid will be shown on the [Society page](https://ipfs.io/ipns/kusama.dotapps.io/#/society) under the bids section. You can cancel the bidding if you changed your mind about joining the society by calling `unbid` on the same page. - -You can find an existing member to place a bid on your behalf if you do not have KSM and you are willing to give them a tip. An existing member can submit a `vouch` transaction through the Extrinsics page. - -> vouch(who,value,tip) -> -> who - The user you are vouching for -> -> value - The value that the user would like to get when joining the society -> -> tip - Fees you get -> -> Note: The final value that the candidate will get = (value - tip) - -![Society Dashboard](assets/society/vouch.jpg) - -### 2. Candidate Phase - -Bids selected in this phase will be voted on by the existing members to decide whether or not you will be approved to join the society. Members will vote for all the candidates and the final outcome will be randomly selected by one of the votes. Let's take a look the example shown below: - -> Note: If the randomly selected member does not vote, it will be treated as a rejection. For each rotation period, the maximum number of members that can be accepted is set as 10. - -A - Accept, R - Reject, S - Skeptic - -| Member | 1 | 2 | 3 | 4 | 5 | -| -------- | - | - | - | - | - | -| Vote | A | A | A | R | S | -| Selected | | | X | | | - -In this example, a candidate will be approved to join the society since member 3 was selected as a final voting outcome. A number of members will also be randomly chosen as "skeptics" to vote for the candidates during the rotation period. - -Since member 5 was chosen as a skeptic, they are required to participate in the voting process. If they do not participate in voting, they will be punished with one strike per missing vote. If one accumulates too many strikes, one's membership is suspended which means they may need to re-apply and their unclaimed payouts will be slashed. Moreover, each member who voted opposite to the randomly selected vote will have their unclaimed payouts slashed and strikes increased. In this case, member 4 will be punished. - -> Note: The maximum number of strikes you can have is on Kusama is 10. - -The slashed funds (2 KSM currently) will be given to a random member who voted the same as the selected vote as a reward for participating in the vote. The reward is escrowed for some period of time - see below. - -#### Lock-up Time - -It would take the number of members of the society as the variable to determine how many blocks you have to wait in order to get the payout. The longest lock-up time is close to 3 years. The formula is defined [in the society pallet](https://substrate.dev/rustdocs/latest/pallet_society/index.html) if you would like to have a look. - -Example: - -``` -Let's assume we have 5 members in the society. - -lock_duration = 100 - 50,000 / (5 + 500) -lock_duration * MAX_LOCK_DURATION_IN_BLOCKS - -Result = 1% * 15,552,000 ~ 11 days -``` - -Based on the above calculation, it is required to wait close to 11 days to get the slashed funds. - -If the candidate wins the vote, they receive their bid reward as a future payout. If the bid was placed by a voucher, they will get back the reward that was set during vouching with the remainder given to the candidate - both escrowed for some time. - -If the candidate loses the vote, they are suspended and it is up to the founder of the society (the `Suspension Judgement Origin`) to determine if the candidate should go through the bidding process again, should be accepted into the membership society, or rejected and their deposit slashed. - -### 3. Member Phase - -Once you become a member of the society, you will get back the deposit that you have reserved during the bidding. A few things you need to be aware of. First, you should vote on candidates who applied for the membership in every rotation period. - -Second, you will need to claim your payout manually by calling `payout` after the lock-up time. It is the same as the above mentioned lock-up formula. - -![Society Payout](assets/society/payout.jpg) - -Third, there will be a membership challenge every seven days on Kusama. So one of the members will be randomly selected as a defender. Then, other members can vote whether this defender should stay in the society or not. A simple majority wins the vote. You can take a look [here](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) and search for "Existing Members (Challenges)". Besides that, you can earn extra KSM by helping a user apply for the membership and requesting a tip. This is useful when a user does not have enough balance to reserve a deposit. The tip will be given when a user successfully joins the society. - -> Note: Each member can only vouch for one user at a time. A member is not required to reserve the deposit when vouching for a user. - -If a member accumulates too many strikes or fails their membership challenge, they will become suspended. While a member is suspended, they are unable to claim matured payouts. It is up to the suspension judgment origin to determine if the member should re-enter society or be removed from society with all their future payouts slashed. - -## Useful links - -[Convention of Approval of Membership](https://polkascan.io/pre/kusama/transaction/0x948d3a4378914341dc7af9220a4c73acb2b3f72a70f14ee8089799da16d94c17) - Rules about joining the Kusama society diff --git a/website/translated_docs/zh-TW/maintain-index.md b/website/translated_docs/zh-TW/maintain-index.md deleted file mode 100644 index abf6b741edc9..000000000000 --- a/website/translated_docs/zh-TW/maintain-index.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: maintain-index -title: Network Maintainers -sidebar_label: Network Maintainers ---- - -Welcome to the network maintainers section of the Polkadot wiki. Here you will find information and guides to set up a node and run the network. - -## Node - -- [Networks Guide](maintain-networks) - A list of the available Polkadot networks that you can connect to with a node. -- [Set up a Full Node](maintain-sync) - Get up and started by syncing a full node for the Kusama network. The steps in the guide will broadly apply also to any Substrate-based network (like Polkadot). -- [Set up WSS using Nginx](maintain-wss) - Set up a Secure WebSockets server for your node's WebSockets connection. - -## Collator - -- [Learn about Collators](learn-collator) - High level overview of collators and related links. - -## Nominator - -- [Learn about Nominators](learn-nominator) - High level overview of nominators and related links. -- [Nomination Guide (Polkadot)](maintain-guides-how-to-nominate-polkadot) - Walkthrough on how to nominate on the Polkadot network. -- [Nomination Guide (Kusama)](maintain-guides-how-to-nominate-kusama) - Walkthrough on how to nominate on the Kusama canary network. -- [How to stop being a Nominator](maintain-guides-how-to-unbond) - Guide on how to stop nominating. - -## Validator - -- [Learn about Validators](learn-validator) - High level overview of validator and related links. -- [Validator Payouts](maintain-guides-validator-payout) - Overview on how validator rewards are calculated and paid. -- [Validation Guide (Polkadot)](maintain-guides-how-to-validate-polkadot) - Walkthrough on how to validate on the Polkadot network. -- [Validation Guide (Kusama)](maintain-guides-how-to-validate-kusama) - Walkthrough on how to validate on the Kusama canary network. -- [Using systemmd for the Validator Node](maintain-guides-how-to-systemd) - Configuring systemmd with the Validator node. -- [Secure Validator](maintain-guides-secure-validator) - Best tips and practices for validating. -- [How to use Polkadot Secure Validator](maintain-guides-how-to-use-polkadot-secure-validator) - Walkthrough on how to set up a validator securely. -- [How to upgrade a Validator Node](maintain-guides-how-to-upgrade) - Guide on upgrading your validator node. -- [How to Chill](maintain-guides-how-to-chill) - Walkthrough on how to chill as a validator. - -## Governance - -- [How to pariticipate in Governance](maintain-guides-democracy) - Walkthrough on how to participate in governance. -- [How to join the Council](maintain-guides-how-to-join-council) - Step by step guide for running for the Council. -- [How to vote for a Councillor](maintain-guides-how-to-vote-councillor) - Step by step guide for voting for your favorite councillors. diff --git a/website/translated_docs/zh-TW/maintain-polkadot-parameters.md b/website/translated_docs/zh-TW/maintain-polkadot-parameters.md deleted file mode 100644 index cf37a141c23a..000000000000 --- a/website/translated_docs/zh-TW/maintain-polkadot-parameters.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: maintain-polkadot-parameters -title: Polkadot Parameters -sidebar_label: Parameters ---- - -Many of these parameter values can be updated via on-chain governance. If you require absolute certainty as to their values, it is recommended you directly check the constants by looking at the [chain state](https://polkadot.js.org/apps/#/chainstate/constants) and/or [storage](https://polkadot.js.org/apps/#/chainstate). - -### Periods of common actions and attributes - -_NOTE: Kusama runs 4x as fast as Polkadot, except Polkadot also has 6 second blocktimes. See [Kusama Parameters](https://guide.kusama.network/docs/en/kusama-parameters) for more details on how Kusama's parameters differ from Polkadot's._ - -- Slot: 6 seconds \*(generally one block per slot, although see note below) -- Epoch: 4 hours (2,400 slots x 6 seconds) -- Session: 4 hours (Session and Epoch lengths are the same) -- Era: 24 hours (6 sessions per Era, 2,400 slots x 6 epochs x 6 seconds) - -| Polkadot | Time | Slots\* | -| -------- | --------- | --------- | -| Slot | 6 seconds | 1 | -| Epoch | 4 hours | 2,400 | -| Session | 4 hours | 2,400 | -| Era | 24 hours | 14,400 | - -\*_A maximum of one block per slot can be in a canonical chain. However, occasionally a slot will be without a block in the chain. Thus, the times given are estimates. See [Consensus](learn-consensus) for more details._ - -### Governance - -| Democracy | Time | Slots | Description | -| ---------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Voting period | 28 days | 403,200 | How long the public can vote on a referendum. | -| Launch period | 28 days | 403,200 | How long the public can select which proposal to hold a referendum on, i.e., every week, the highest-weighted proposal will be selected to have a referendum. | -| Enactment period | 28 days | 403,200 | Time it takes for a successful referendum to be implemented on the network. | - -| Council | Time | Slots | Description | -| ------------- | ------ | ------- | -------------------------------------------------------------------- | -| Term duration | 7 days | 100,800 | The length of a council member's term until the next election round. | -| Voting period | 7 days | 100,800 | The council's voting period for motions. | - -The Polkadot Council consists of up to 13 members and up to 20 runners up. - -| Technical committee | Time | Slots | Description | -| ----------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------- | -| Cool-off period | 7 days | 100,800 | The time a veto from the technical committee lasts before the proposal can be submitted again. | -| Emergency voting period | 3 hours | 1,800 | The voting period after the technical committee expedites voting. | - -### Staking, Validating, and Nominating - -| Kusama | Time | Slots | Description | -| -------------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Term duration | 1 Day | 14,400 | The time for which a validator is in the set after being elected. Note, this duration can be shortened in the case that a validator misbehaves. | -| Nomination period | 1 Day | 14,400 | How often a new validator set is elected according to Phragmén's method. | -| Bonding duration | 28 days | 403,200 | How long until your funds will be transferrable after unbonding. Note that the bonding duration is defined in eras, not directly by slots. | -| Slash defer duration | 28 days | 403,200 | Prevents overslashing and validators "escaping" and getting their nominators slashed with no repercussions to themselves. Note that the bonding duration is defined in eras, not directly by slots. | - -### Treasury - -| Treasury | Time | Slots | Description | -| ---------------------- | ------- | ------- | ------------------------------------------------------------ | -| Periods between spends | 24 days | 345,600 | When the treasury can spend again after spending previously. | - -Burn percentage is currently `1.00%`. - -### Precision - -DOT have 10 decimals of precision. In other words, 10 \*\* 10 (10,000,000,000 or ten billion) Plancks make up a DOT. - -The denomination of DOT was changed from 12 decimals of precision at block #1,248,328 in an event known as _Denomination Day_. See [Redenomination](redenomination) for details. diff --git a/website/translated_docs/zh-TW/redenomination.md b/website/translated_docs/zh-TW/redenomination.md deleted file mode 100644 index 36d2c664435e..000000000000 --- a/website/translated_docs/zh-TW/redenomination.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: redenomination -title: Redenomination of DOT -sidebar_label: Redenomination of DOT ---- - -> Note: The DOT redenomination took place on 21 August, now known as Denomination Day, at block -> -> # 1,248,328. - -While [DOT](learn-dot) is the unit of currency on Polkadot that most people use when interacting with the system, the smallest unit of account is called the Planck. A Planck's relation to DOT is like the relation of a Satoshi to Bitcoin. Before 21 August, the DOT was denominated as 1e12 Plancks, that is twelve decimal places. After this date, DOT is denominated as 1e10 Plancks, as in ten decimal places. DOT denominated to twelve decimal places is referred to as "DOT (old)" and DOT denominated to ten decimal places is generally referred to as "DOT". When the difference must be made explicit, the current ten-decimal-denominated DOT is referred to as "_New DOT_". - -> Check out our [technical explainer video that explains more of Redenomination](https://www.youtube.com/watch?v=xXIcnBV4uUE&list=PLOyWqupZ-WGuAuS00rK-pebTMAOxW41W8&index=22&ab_channel=Polkadot). - -The change in denomination, henceforth referred to as the _redenomination_, was voted on by the community of DOT holders. The community decided between four options, to change the DOT denomination by a factor of ten, one hundred, one thousand, or not at all. The end result was to change the denomination by a factor of one hundred. - -The overall effect of this change was that the number of Polkadot's smallest unit, the Planck, remained constant, while the DOT balance for all holders was increased by a factor of one hundred. As one can see from the example below, the number of Plancks that a user has does not change, only the number of Plancks that constitute a single DOT. A user with 1,000,000,000,000 Plancks still has the same number of Plancks, but will have 100 DOT under the new denomination, as opposed to one DOT under the old denomination. - -``` - Before the change the decimal was here - v - 1.000000000000 DOT - - 100.0000000000 DOT - ^ - After the change the decimal is here -``` - -**There are no state changes with redenomination. There are no transfers. The real change regards the social consensus around where to put the decimal place when we talk about what constitutes a DOT.** - -## Origins - -The initial vote for redenomination occurred as a [referendum][referendum 52] on the Kusama blockchain. The referendum was summarized as having four effects if approved by KSM holders. - -> - The total allocations of DOT will increase one hundred times from 10 million to 1 billion. -> - DOT allocation balances will increase by a factor of one hundred, such that 1 DOT will be 100 DOT. -> - The distribution of DOT does not change, and holders of DOT still own an equal share of the network as before the change. -> - The precision of DOT will change from 12 decimal places to 10 decimal places. -> - The main benefit of this change is to avoid using small decimals when dealing with DOT and to achieve an easier calculation system. - -The initial referendum was proposed prior to the Polkadot genesis block under the assumption that making a redenomination would be simpler before the Polkadot chain was live. However, many in the community pointed out the disconnect of the two networks and how it was unfair for holders of DOT to be impacted by a vote by a different token holder set. For this reason, the Web3 Foundation [decided to make a new vote on Polkadot][blog 1] when it went live, although the Kusama vote ended with a majority in favor of the redenomination change. - -Web3 Foundation summarized the decision not to change: - -> However, given the non-negligible amount of opposition, including from some within the ranks of Web3 Foundation and Parity, **the Foundation decided that we cannot, in good faith, sponsor redenomination at present.** - -## The Vote - -After the genesis block of Polkadot was created and the network was running with a decentralized community of validators securing the network, Web3 Foundation decided to put the redenomination topic up to a vote again. This time, the vote was explicitly binding — meaning that it would be executed if voted through. In comparison, the vote on Kusama was of course non-binding, being at best a way to capture a signal without a direct way to affect the Polkadot chain. - -Based on the feedback received during the Kusama referendum, the [Polkadot vote][blog 2] was held as an approval vote, with four available options. DOT holders could issue votes for any configuration of the four options: no change, a change of 10x, a change of 100x, or a change of 1000x. The vote logic was contained in a specially-built Substrate pallet that was included in Polkadot's runtime for this poll. - -The important notes of the Polkadot vote were as follows: - -> - Any combination of the four options may be approved of by the voter. There is no need to select only one option! -> - Approving of all or none of the options is equivalent and will not affect the outcome. -> - All voters may alter their votes any number of times prior to the close of the poll. -> - Voting costs nothing other than the transaction fee and can be done from all accounts with a non-zero spendable balance. (If you managed to lock up all of your funds in staking to the point that none is left for transacting and you would like to vote, please contact a representative of the Web3 Foundation.) -> - Locked funds (e.g. for staking) are counted. -> - No discretionary lock-voting is in place; all DOT used to vote counts the same. -> - Voting is made on a per-account basis; a single account must all vote the same way and cannot split its vote. -> - This vote does not affect any economics of the Polkadot platform. Staking rewards, inflation, effective market capitalization and the underlying balances of every account remain completely unchanged. It is “merely” about what units we use to denominate the balances into “DOT” for the purpose of display. - -With a voting period of two weeks set, the redenomination was now in the hands of the Polkadot community for a final, binding decision. - -## The Outcome - -![redenomination](assets/redenomination.png) - -After two weeks of voting, the [results][blog 3] of the redenomination vote were tallied. About one third of the total DOT in the network participated in the vote. The redenominaton proposal passed with 86% of the voters favoring a 100x factor increase (or two decimal places of precision loss). - -Polkadot's redenomination then took place on 21 August, now known as Denomination Day, at block -# 1,248,328. - -### What This Means for the Community - -If you are a DOT holder or user of the network, then you do not need to take any action. The DOT redenomination was a purely front-end change. You still hold the same amount of Plancks after the change, but now it will appear that you hold 100x more DOT. This change applies proportionally to every account. - -### What This Means for Builders of Tools - -If you are the builder of a tool that consumes the `@polkadot/api` package — then there should be no real changes that need to be made in your application. The denomination is technically a cosmetic change and every value is still a constant amount of Plancks. - -However — if you are a builder of a tool that displays DOT balances to users (e.g. a wallet) or handles DOT balances in an off-chain or custodial way, then you will need to ensure that you display the correct denomination of DOT to users. - -Please see our [Ecosystem Redenomination Guide]() for recommendations. - -Please reach out to [support@polkadot.network](mailto:support@polkadot.network) if you need any assistance in making sure your software is compatible with the redenomination. - https://docs.google.com/document/d/1yAzoDh99PgR_7dYAKTWLMVu2Fy5Ga-J6t9lof4f4JUw/edit# - -[referendum 52]: https://kusama.polkassembly.io/referendum/52 -[blog 1]: https://polkadot.network/results-of-dot-redenomination-referendum/ -[blog 2]: https://polkadot.network/the-first-polkadot-vote/ -[blog 3]: https://polkadot.network/the-results-are-in/ diff --git a/website/translated_docs/zh-TW/thousand-validators.md b/website/translated_docs/zh-TW/thousand-validators.md deleted file mode 100644 index 4930994ebf7e..000000000000 --- a/website/translated_docs/zh-TW/thousand-validators.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: thousand-validators -title: Thousand Validators Programme -sidebar_label: Thousand Validators Programme ---- - -The Thousand Validators Programme is an initiative by Web3 Foundation and Parity Technologies to use the funds held by both organizations to nominate validators in the community. - -It serves two major purposes: 1) to give validators a structured on-ramp to join the active set of validators on Kusama and Polkadot and 2) to further decentralize the validator active set. - -## How it Works - -The nominating backend will routinely change its nominations at every era (or every 4 eras on Kusama). It will nominate validators which fit all the requirements and are eligbile. Of this pool, it will nominate as many as possible although some validators which are eligible might not receive nominations every round (due to the constraint of nominating a maximum of 16 validators per nominator). If a validator is active during a single nomination period (the time after a new nomination and before the next one) and does not break any of the requirements, it will have its rank increased by 1. Validators with higher rank have performed well within the programme for a longer period of time. - -## Setting up a Validator - -Please see the wiki page for [setting up a validator](maintain-guides-how-to-validate-polkadot.md) as well as additional information on [making your validator secure](maintain-guides-secure-validator.md). - -## How to Apply - -### Kusama - -In order to apply to the Kusama programme, set up your node to adhere to the requirements below and fill in the [application form][kusama 1kv form]. You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Minimum of 50 KSM self-stake -- No more than 10% commission -- Separate controller and stash (or have a Staking proxy set up) -- Must be on latest release -- Max two nodes (under same sub/super identity) - -#### Leaderboard - -The leaderboard is available at https://thousand-validators.kusama.network/#/leaderboard. - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Kusama Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `G1rrUNQSk7CjjEmLSGcpNu72tVtyzbWdUvgmSer9eBitXWf` / `H9BFvNPTqDEmWZ63M82ohrFmvEFASm25ErUMzmXDrbAr1kq` -- `HgTtJusFEn2gmMmB5wmJDnMRXKD6dzqCpNR7a99kkQ7BNvX` / `H4UgNEEN92YXz96AyQgwkJQSpXGdptYLkj9jXVKrNXjQHRJ` -- `EX9uchmfeSqKTM7cMMg8DkH49XV8i4R7a7rqCn8btpZBHDP` / `H54GA3nq3xeNrdbHkepAufSPMjaCxxkmfej4PosqD84bY3V` -- `H4635Bjj3X7TjnQhd55p9DyFPK39JiRypmCnsDhS3NHSMS5` / `CeB8SLnJivXRtC5PgXchrece8j3TBQRaqfGqHngvhD3LRHD` -- `Hs94zeHrSUWG1VBzsvHPxR2VRN5mq1Rib1PEfjH7wkGzv2Z` / `HCbe2ZFujLNYsrKGub8XKGJuky3LTAF6NhWnRTs6NyDaVkQ` -- `CdWjVn5J9ct4D3yK8HbwXmmGyLcxjkDitaBLxwH5g5Vh7pi` / `Dicn4AxJRsnJ6sRsYPNZvC3xrRhvNBanfPP79haVL7ywyPn` -- `HxRmQTVrMxMkhyZquYLu2hSL1QDYvVwSpDfBHvVJhEMVzRj` / `CbFFE91fYzkKsuFjSjfQrc7Bz2bbM9vYcQgzijxHd4LtoKw` -- `FJbKWFGCfZFZiNQtAZ5uqbUhKeB3P3a6RVRw6GqTbgiqtem` / `Gt2p2gZHPvHCvPUuT2BKaeAAADPgVEa9eXMQBn74RwMa6mX` - -A time delay proxy is used as the interaction method for some of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - -### Polkadot - -> Note: Entrance to the Polkadot programme requires a rank of 25 or higher in the Kusama programme. This usually takes about a month. - -In order to apply to the Polkadot programme, set up your node to adhere to the requirements below and fill in the [application form](). You will hear back from the team shortly. - -#### Requirements - -- Verified identity (see [here]() for instructions) -- Connect to dedicated Telemetry (use `--telemetry-url 'wss://telemetry-backend.w3f.community/submit 1'` when starting the node) -- Rank 25 or higher on Kusama Thousand Validators Programme -- Mininmum of 10K DOTs self stake (exceptions by approval for good intentions) -- Reward destination 'Staked' -- No more than 3% commission -- Separate stash and controller (or have a Staking proxy set up) -- Must be on latest release - -#### Nominators - -The below addresses are the stash / controller pairs for the nominators involved in the Polkadot Thousand Validators programme. They are formatted like "`stash` / `controller`". - -- `14Ns6kKbCoka3MS4Hn6b7oRw9fFejG8RH5rq5j63cWUfpPDJ` / `16XJHQ58dEPnZn5J5YqmRcJmKtvVFFMoMrXgj6fWJfeGGkQw` -- `12RYJb5gG4hfoWPK3owEYtmWoko8G6zwYpvDYTyXFVSfJr8Y` / `13GLXK1TZKKDM9aRBBK3VYZymHjKChtQjJznsRqaR9dwwrQU` -- `16GMHo9HZv8CcJy4WLoMaU9qusgzx2wxKDLbXStEBvt5274B` / `16eM1npMwKzpGy48NDna1jC6P71S783wjpbdeKT8RgzQx8Jd` - -A time delay proxy is used as the main interaction method for all of these accounts. - -Since approximately early January 2021, the nominators will select an automatic number of validators to nominate based on the lowest amount staked for a validator and the amount of funds it holds. This can be anywhere from a few validators receiving nomination from a single nominator to the max of 16. - https://docs.google.com/forms/d/e/1FAIpQLSdS-alI-J2wgIRCQVjQC7ZbFiTnf36hYBdmO-1ARMjKbC7H9w/viewform https://guide.kusama.network/docs/en/mirror-learn-identity#setting-an-identity - -[kusama 1kv form]: https://forms.gle/xqYLoceTwg1qvc9i6 diff --git a/yarn.lock b/yarn.lock index 8862d0883af2..f5bfa974d06a 100644 --- a/yarn.lock +++ b/yarn.lock @@ -1189,7 +1189,7 @@ "@docsearch/css" "3.0.0-alpha.39" algoliasearch "^4.0.0" -"@docusaurus/core@2.0.0-beta.4": +"@docusaurus/core@2.0.0-beta.4", "@docusaurus/core@^2.0.0-beta.4": version "2.0.0-beta.4" resolved "https://registry.yarnpkg.com/@docusaurus/core/-/core-2.0.0-beta.4.tgz#b41c5064c8737405cfceb1a373c9c5aa3410fd95" integrity sha512-ITa976MPFl9KbYchMOWCCX6SU6EFDSdGeGOHtpaNcrJ9e9Sj7o77fKmMH/ciShwz1g8brTm3VxZ0FwleU8lTig== @@ -1431,7 +1431,7 @@ sitemap "^7.0.0" tslib "^2.2.0" -"@docusaurus/preset-classic@2.0.0-beta.4": +"@docusaurus/preset-classic@^2.0.0-beta.4": version "2.0.0-beta.4" resolved "https://registry.yarnpkg.com/@docusaurus/preset-classic/-/preset-classic-2.0.0-beta.4.tgz#7f57be3368ed645ab634928d8564fe29b45136cd" integrity sha512-fW8/iyGLJfBTtbCBQtnRcbDa+ZZMq6Ak20+8+ORB8mzjK4BNYmt9wIbfq0oV9/QBLyryQBYcsRimJoXpLZmWOg==